Hitting a moving target

This chapter is dedicated the goals for a successful software project.

Change control procedure

The basic change control procedure involves.

  1. The initial development work for a work product  (such as the project requirements) is performed without change control coming into play.
  2. The work product is subjected to a technical review.
  3. When initial development is complete, the work product is submitted to a “change board”.
  4. The work product is placed under “revision control.” Revision control refers to a software revision control program that is capable of archiving multiple versions of anything stored electronically.
  5. Further changes are treated systematically.
    1. Changes are proposed via change proposal.
    2. The change board identifies parties that might be affected by the change and distributes the change proposal for their review.
    3. The concern parties each assess the cost and benefits of the proposed change.
    4. The change board members conbine their assessments and prioritize the change proposal.
    5. The change board notifies all concerned parties about how the change proposal was resolved.

Change control benefits

The primary benefit of change control is that it protects the project from unnecessary changes by ensuring that change proposals are considered systematically. Change control combats “Mushy milestones”. One of the more subtle risks on a software project is that the project team will reach a milestone and declare that milestone to have been met even though the team’s work doesn’t really satisfy the milestone criteria.

The elimination of mushy milestones also improves status visibility. If you know that milestones are hard, the fact that the project has completed a milestone is a meaningful status indicator.

Benefits of automated revision control

Enable project members to easily retrieve any version of any major document that has been produced on the project. They can retrieve initial project plans, revised project plans, and current project plans. They can re-create any version of the product that has ever been released to a customer.

Common change control issues

When to consider changes.

How to handle small changes.

How to handle political issues.

Which work products to place under change control.

 

committing to change control

Software change control activities need to be planned. The change control plan procedure and list of work products described in this chapter should be expressed within a written change control plan. The software development plan should reference the change control plan as part of the official software process.

Project members must be given time to carry out their change control responses.

Bibliography

McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Author: enroblog

Computer science student at ITESM

2 thoughts on “Hitting a moving target”

  1. Change control procedure is always important. And it is also important for people to know the changes. Changes cannot be secret, and I think it is remarkable how the book treats that theme. We all have lived situations in which changes have screwed all up, knowing this before could’ve been great.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: