Difference between revisions of "OSEE/Users Guide/Concepts"
|Line 5:||Line 5:|
An '''attribute''' is data attached to an artifact. A
An '''attribute''' is data attached to an artifact. A Userartifact might have Email, Name, and Phone Numberattributes. A Software Requirementartifact might have attributes such as Qualification Method, Safety Criticality, or Subsystem.
The default attribute <tt>Name</tt> is required for all artifacts. Other attribute types can be created and associated with any artifact
The default attribute <tt>Name</tt> is required for all artifacts. Other attribute types can be created and associated with any artifact in the system.
Revision as of 19:24, 11 September 2009
The artifact is the fundamental object in OSEE. All data objects stored within OSEE are artifacts. Artifacts are strongly typed and can store any data throughout the systems engineering lifecycle. Any type of data can be stored in OSEE as an artifact; not only systems engineering data (such as processes and requirements), but also anything from meeting minutes to architecture diagrams.
An attribute is data attached to an artifact. A User artifact might have Email, Name, and Phone Number attributes. A Software Requirement artifact might have attributes such as Qualification Method, Safety Criticality, or Subsystem.
The default attribute Name is required for all artifacts. Other attribute types can be created and associated with any artifact in the system.
A relation is a link between two artifacts. Like artifacts, they are strongly typed; a relation with the type "attend" might relate a "User" artifact to a "Meeting" artifact. Similarly, a "Customer Requirement" might be linked to the low-level "Software Requirement" that satisfies it.
A fundamental feature provided by OSEE is the concurrent management of multiple variants or lines of a product. After a set of requirements is developed, it may become the baseline for variant sets of requirements for similar products. In other words, you may develop the same product for another customer, but have slight changes to the requirements, code, and test for features specific to that customer.
Historically, this would mean maintaining completely separate "copies" of all the requirements and other artifacts. This is costly to maintain when changes from the baseline artifacts must be propagated to the other product line. The expense of this undertaking increases dramatically as more customers are added, each with their own set of requirements changes.
For this reason, OSEE provides full branching functionality. Using OSEE, it is possible to create these variant branches, record where they originated, and to apply changes made to a baseline branch to its variants.
By default, OSEE has two system branches. The System Root Branch is the parent of all other branches in the system. The Common branch is used to store OSEE configuration information, such as users. Common is a child of System Root Branch.
On complex projects, artifacts can be subject to modification by any one of hundreds of engineers. To have requirements "locked" while they are being modified by one user can cause significant delays in schedule. The need for parallel development (multiple users working on the same requirements) is a necessity to keeping a project moving forward. In addition, users making mistakes need the ability to revert or throw away their changes and start over without polluting the baseline branch. This is done using working branches. A working branch is a sandbox area used to prepare a commit to a baseline branch.
BLAM Lightweight Artifact Manipulation (BLAM) allows non-programmers to graphically construct workflows to automate repetitive tasks. A given workflow can be used for variety of similar tasks by using customizable controls to specify workflow parameters. BLAM also provides programmers the ability to interact with the OSEE Artifact Framework API to build and execute tasks.