Domain:
PowerFrame is a system designed for the computer-aided engineering/design (CAE/CAD) field and essentially shields its user from any notion of a file system and configuration management.
Users see only their domain-specific world and any CM is transparent to them. All they may see includes the appropriate tools for a particular task, and certain forms of presentation such as a logic-schema or a layout design, data that are pertinent to a particular task, and the form of commands that are pertinent to that domain. The user does not have to worry about such tasks as version control or relationships between files, since the system handles that behind the scenes. The users' working setup looks just like their domain's working environment.
In effect, the CM features are hidden under the guise of domain-specific concepts.
Life Cycle Phase:
The Change and Configuration Control (CCC) system provides some notions for supporting a particular lifecycle model in the sense of supporting phases in the lifecycle. In particular, CCC separates out development, product testing and releasing a product. This separation allows different kinds of users such as software engineers and testers to work on apparently the same code at the same time. This is achieved by passing the code through to separate directories that represent each phase. Work can continue independently in each directory, but, in essence, progresses from phase to phase, from person to person. As the independent work is completed, all changes are merged into a final product in the repository, tested and approved. A new release can be created and the cycle can begin again. In effect, the lifecycle model is achieved via parallel activities on versions of configurations.
Change Requests:
In CCC, a change-request is a documented request to make a change and is presented as an on-line form with fill-in-the-blank screen panels. The request is for changes to be made to a section of code or to many related parts of the product such as a configuration.
The scope of the change is user-defined, but CCC keeps a record of the request and what is affected by the change. The request is assigned a unique name. Once the form is completed with details of all ramifications (such as which components will be affected), the form can be electronically mailed to the CM manager who can mail back an approval or rejection to the software engineer. If approved, engineers are assigned to make the change, and those engineers are given access to the repository based on the change request assignment.
The change request is resolved by making the changes. Once the changes are tested and approved, the affected components can then be passed to the approved configuration. Change requests provide a history of all changes to the repository, a status report for changes in progress, and an audit trail of changes done and changes rejected.
Contracts:
The ISTAR environment provides for modeling some parts of a software development process. It models information flow and the completion of tasks. It does this via contracts. Contracts incorporate information flow, roles, tasks and components of the product and are "exchanged". A contract is fulfilled by the "passing" of a particular version of the product (or part thereof). The components are passed to certain elements of the process model such as a person or, logically, to a new phase, that is, the repository of part of the product is passed on.
