A baseline is a software
configuration management concept that helps us to control change without
seriously impeding justifiable change.
Software Configuration Management:
In the extreme, a SCI could be considered be a single section of a large specification or one test case in a large suite of tests. More realistically, an SCI is a document, a entire suite of test cases, or a named program component (e.g., a C++ function or an Ada package)
In addition to the SCIs that are derived from software work products, many software engineering organizations also place software tools under configuration control. That is, specific versions of editors, compilers, and other CASE tools are "frozen" as part of the software configuration. Because these tools were used to produce documentation, source code, and data, they must be available when changes to the software configuration are to be made. Although problems are rare, it is possible that a new version of a tool (e.g., a compiler) might produce different results than the original version. For this reason, tools, like the software that they help to produce, can be baseline as part of a comprehensive configuration management process.
In reality, SCIs are organized to form configuration objects that may be cataloged in the project database with a single name. A configuration object has a name, attributes, and is "connected" to other objects by relationships.
the configuration objects, Design Specification, data model, component N, source code and Test Specification are each defined separately. However, each of the objects is related to the others as shown by the arrows. A curved arrow indicates a compositional relation. That is, data model and component N are part of the object Design Specification. A double-headed straight arrow indicates an interrelationship.
Software Configuration Management:
In the extreme, a SCI could be considered be a single section of a large specification or one test case in a large suite of tests. More realistically, an SCI is a document, a entire suite of test cases, or a named program component (e.g., a C++ function or an Ada package)
In addition to the SCIs that are derived from software work products, many software engineering organizations also place software tools under configuration control. That is, specific versions of editors, compilers, and other CASE tools are "frozen" as part of the software configuration. Because these tools were used to produce documentation, source code, and data, they must be available when changes to the software configuration are to be made. Although problems are rare, it is possible that a new version of a tool (e.g., a compiler) might produce different results than the original version. For this reason, tools, like the software that they help to produce, can be baseline as part of a comprehensive configuration management process.
In reality, SCIs are organized to form configuration objects that may be cataloged in the project database with a single name. A configuration object has a name, attributes, and is "connected" to other objects by relationships.
the configuration objects, Design Specification, data model, component N, source code and Test Specification are each defined separately. However, each of the objects is related to the others as shown by the arrows. A curved arrow indicates a compositional relation. That is, data model and component N are part of the object Design Specification. A double-headed straight arrow indicates an interrelationship.
No comments:
Post a Comment