Page 265 -
P. 265

236           PART TWO  MANAGING SOFTWARE PROJECTS


         FIGURE 9.6
         Access and
         synchronization                         Check- in
         control           Configuration object
                           (modified version)
                                                             Configuration object
                                                Unlock        (baseline version)
                                 Audit info
                                                           Ownership
                         Software            Access          info             Project
                         engineer            control                         database



                             Configuration object  Lock      Configuration object
                              (extracted version)             (baseline version)


                                                 Check- out





                       many have none) have created a number of layers of control to help avoid the prob-
                       lems alluded to here.
                          Prior to an SCI becoming a baseline, only informal change control need be applied.
                       The developer of the configuration object (SCI) in question may make whatever
         Opt for a bit more  changes are justified by project and technical requirements (as long as changes do
         change control than  not affect broader system requirements that lie outside the developer's scope of work).
         you think you’ll need.  Once the object has undergone formal technical review and has been approved, a
         It’s likely that “too  baseline is created. Once an SCI becomes a baseline, project level change control is
         much” will be the right  implemented. Now, to make a change, the developer must gain approval from the
         amount.
                       project manager (if the change is "local") or from the CCA if the change affects other
                       SCIs. In some cases, formal generation of change requests, change reports, and ECOs
                       is dispensed with. However, assessment of each change is conducted and all changes
                       are tracked and reviewed.
                          When the software product is released to customers, formal change control is insti-
                       tuted. The formal change control procedure has been outlined in Figure 9.5.
                          The change control authority plays an active role in the second and third layers of
                       control. Depending on the size and character of a software project, the CCA may be
                       composed of one person—the project manager—or a number of people (e.g., repre-
                       sentatives from software, hardware, database engineering, support, marketing). The
         “Change is inevitable,  role of the CCA is to take a global view, that is, to assess the impact of change beyond
          except from vending  the SCI in question. How will the change affect hardware? How will the change affect
          machines.”   performance? How will the change modify customer's perception of the product?
          Bumper sticker   How will the change affect product quality and reliability? These and many other
                       questions are addressed by the CCA.
   260   261   262   263   264   265   266   267   268   269   270