Software Development Process and Management

(or how to be officious and unpopular)

The Problem

300,000 projects 1/3 to 2/3 will exceed budget and

schedule ½ will be cancelled More will be cancelled in other

ways Declaring victory without completion Shelving without cancellation

Project Expectations

The Customer’s Bill of Rights1. To set project objectives and have the followed.

2. To know how long it will take and how much it will cost.

3. To decide which features are in which release.

4. The right to make changes in requirements and to know the cost of those changes.

5. To know the project’s status.

6. To have access to deliverables throughout the project.

Project Expectations

The Developer’s Bill of Rights1. To know the project’s objectives and priorities.

2. To know in detail the product to be produced.

3. Open access to those making decisions about functionality.

4. To approve effort and schedule estimates.

5. The right to revise effort and schedule estimates when requirements change.

6. To work in a distraction and interruption free environment.

The Process

1. All requirements in writing.

2. A systematic procedure for modifying requirements.

3. Frequent reviews of requirements, design and source code.

4. A quality assurance plan including defect tracking.

5. Revision of cost estimates with each milestone.

6. Automated source code control with versions and releases.

“Restrictive and Inefficient”

1. Process control adds unnecessary overhead.

2. We can correct mistakes later.

3. What processes we need, we will add when we need them.

4. Process limits programmer creativity.

5. Process reduces moral.

“An investment made in process at the beginning of the project produces large returns later in the project”

Steve McConnel, “The Software Project Survival Guide”

Process Overhead

1. Process reduces time to market by a factor of 3 to 10.

2. Process reduces defect rate by 75 to 90 percent.

(from figures compiled at Lockheed, NASA, Motorola, Xerox, Loral, and Hughes)

Sooner Is Better Than LaterPoor work early in a project can severely impair the

project downstream.

Morale

1. In only 20% of developers non-process oriented companies rated staff morale as “good”.

2. In process oriented companies 50% of programmers rated staff morale as “good” or “excellent”.

Programmers feel best when they are most productive. Good communication fosters

clear leadership and vision.

Uncertainty

1. Upstream decisions in a project tend to much more far reaching than those made downstream. Earlier decisions in a project will affect the decisions made later on. Software development is a process of refinement.

The less uncertainty at the beginning, the clearer the project requirements, the more on target the early

most important project development decisions will be.

Uncertainty

1. The project team can only make educated guesses about what decisions will be required later in the project.

The less uncertainty at the beginning, the clearer the time and cost estimation will be.

Two Phased Funding

To reduce project uncertainty, introduce two phased funding:

• An exploratory phase where the spec and 10 to 20 percent of the project is completed.

• A checkpoint review phase where management and the customer reviews the spec and funding request and gives a go/no go decision.

• The project continues.

Check Point Review

At the check point review, the following materials are made available:

• Name of the project’s key decision maker.

• Vision statement and business case for project.

• Effort and schedule, goals and estimates.

• Top 10 risks list and quality assurance plan.

• User interface style guide and prototype.

• User manual requirements/specification.

• Detailed development plan.

Check Point Review AgendaThe actual checkpoint review should focus on the

following topics:

• Is the original product concept still viable?

• Is the original business case still viable considering more reliable cost and effort estimates?

• Can the major project risks be surmounted?

• Can the users and developers agree on the software and interface project plans and do they adequately define the project?

• Setting the true cost and schedule for developing the project.

Intellectual Phases

In the conceptual phases of a software, the kind of work performed in each phase varies, but each kind of work occurs to some extent throughout the project

Intellectual Phases

In the Discovery Phase we seek to understand the nature of the problem. In the Invention Phase we transform uncertainty into certainty. In the Implementation Phase we attempt to realize the potential that has been mapped out in Discovery and Invention.

Project plans must allow discovery, invention, and implementation to coexist.

Staged Development

The software team develops a software concept first, then generates and analyzes requirements, and then completes the architectural design. In staged development you are allowed to step back a phase when new requirements are discovered.

Staged Development

Staged delivery emphasizes project planning and risk reduction. In each Implementation Phase, the design team does design, coding, debugging and testing, creating a potentially releasable product.

Staged Development

Staged delivery reduces the administrative time developers spend creating progress reports. On the down side, staged releases creates more overhead in the effort spent in creating the releases.

“Working Software is a more accurate status report than any paper report could ever be.”

Project Activity

Effort is measured by line thickness. Notice that no activity ever completely goes away.

Change Control

Change control allows all necessary changes to be made while ensuring that change impacts are understood project wide.

Change Control Procedure

1. Changes can be made at any time during initial development.

2. Once initial development is complete, changes must be submitted to a “Change Board” in the form of a “Change Proposal”.

3. The Change Board identifies all parties that might be affected by the change and allows them to review the proposal.

Change Control Procedure

4. Concerned parties assess the cost, both financial and in delay an submit their viewpoints to the board.

5. The board member combine their assessments and either veto the change or prioritize it.

6. The Change Board notifies all parties of the final status of the change.

Change control increases accountability. Changes have to be justified before they are implemented. Change control also improves communication.

Revision Control

1. Involves project documents as well as code.

2. Documents are saved with project versions in the document library.

In this way, project documentation can always be found. Version specific can always be found with its attending software.

Change and Revision Control

People who are used to getting their way can still get their way with systematic change control, but they’ll have to do it through a process that emphasizes visible decision making and accountability.