Umbrella Task 4. Software Configuration Management
U.4.1 Select an appropriate set SCM tasks as part of the SCM plan developed in Task U.1.15.
U.4.1.1 Identify project SCIs and baselines.
U.4.1.2 Define the project database (repository) and the tools required to manage it.
U.4.1.3 Establish how the librarian function is to be accomplished.
U.4.1.4 Define the change control process for the project.
U.4.1.5 Identify change control authority (CCA) responsibility.
U.4.1.6 Establish SCM documentation requirements.
U.4.1.7 Define auditing and reporting requirements.
Intent: The intent of this task is to identify the change management approach to be used.
Mechanics: See Pressman, R.S., A Manager's Guide to Software Engineering, McGraw-Hill, 1993, Chapter 15 and IEEE Std. 828-1990.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Have all deliverables been identified as SCIs?
2. Have criteria for baselining been established and are these criteria followed?
3. Can you acquire an SCI from the project database easily?
4. Are changes requested in a uniform manner?
5. Is it possible to get a list of all changes made on a software project within one hour of requesting the list?
Do's & Don'ts
Do: Define the number of SCIs in a way that will enable you to balance the need for specific control against the complexity of large numbers of SCIs.
Don't Impose baselines too quickly. It makes the process overly bureaucratic.
Don't Assume that a code control tool is the equivalent of a complete SCM approach. It isn't.
Helpful Hints
Be sure that SCM activities begin early in the project. When changes are requested in one framework activity, and these changes will impact deliverables created in an earlier framework activity, it's likely that SCM tasks will be required to control change.
Deliverables: SCM Plan
U.4.2 Initiate change control process whenever a change is requested that may affect a baselined deliverable.
U.2.2.1 Accept a change request submitted to the team.
U.2.2.2 Evaluate change request.
U.2.2.3 Generate change report.
U.2.2.4 Evaluate change report (by CCA) to determine whether change should be made.
U.2.2.5 Generate engineering change order (ECO).
U.2.2.6 Queue the change for processing.
U.2.2.7 Make the change.
U.2.2.8 FTR/SQA: Review and audit the change.
U.2.2.9 Release the change.
Intent: The intent of this task is to make a change to a software deliverable in a controlled manner.
Mechanics: See Pressman, R.S., A Manager's Guide to Software Engineering, McGraw-Hill, 1993, Chapter 15 and IEEE Std. 828-1990.
Application of Formal Methods: none
Application of CASE Tools: t.b.d.
SQA Checklist:
1. Can each change be traced to a change request?
2. Can each change be traced to a change report?
3. Is each change evaluated by a CCA?
4. Can each change be traced to a ECO?
5. Are tasks similar to Tasks II, III or IV conducted when making the change?
Do's & Don'ts
Do: Stream line the change control process to keep the mean time to make a change as low as is possible. To do this, try to keep CCA decision-making as close to the people making the change as is possible.
Don't Allow customers to circumvent the process.
Don't Forget the SQA activities are part of the change control process.
Helpful Hints
Timing is everything in change control. Impose it too early and your project schedule suffers. Impose it too late and chaos reigns. Err on the side of imposing it too early, and at the same time work hard to keep the flow through the process moving at a rapid rate.
Deliverables:
1. Change request
2. Change report
3. Engineering change order (ECO)
4. Deliverables (SCIs) that have been changed
U.4.3 Record and report all changes to those individuals with a need to know.
Changes should be recorded by type and disposition. In additional project related metrics (e.g., effort, number of people, duration errors uncovered) should be collected for each change. These data should be published and reported to those with a need to know.
Use Browser "back" arrow or return to APM Process Design Language Description
