Figure 1-4. Suboptimal software component organization resulting from a requirements-driven approach

The following sequence of events was typical for most contractual software efforts:

1. The contractor prepared a draft contract-deliverable document that captured an intermediate artifact and delivered it to the customer for approval.

2. The customer was expected to provide comments (typically within 15 to 30 days).

3. The contractor incorporated these comments and submitted (typically within 15 to 30 days) a final version for approval.

This one-shot review process encouraged high levels of sensitivity on the part of customers and contractors. The overhead of such a paper exchange review process was intolerable. This approach also resulted in customer-contractor relationships degenerating into mutual distrust, making it difficult to achieve a balance among requirements, schedule, and cost.

Focus on Documents and Review Meetings

The conventional process focused on producing various documents that attempted to describe the software product, with insufficient focus on producing tangible increments of the products themselves. Major milestones were usually implemented as cer-

Table 1-2. Results of conventional software

project design reviews

apparent results

real results

Big briefing to a diverse audience

Only a small percentage of the audience understands the software.

Briefings and documents expose few of the important assets and risks of complex software systems.

A design that appears to be compliant

There is no tangible evidence of compliance.

Compliance with ambiguous requirements is of little value.

Coverage of requirements (typically

Few (tens) are design drivers.


Dealing with all requirements dilutes the focus on the critical drivers.

A design considered "innocent until

The design is always guilty.

proven guilty"

Design flaws are exposed later in the life cycle.

emoiiious meetings defined solely in terms of specific documents. Contractors were driven to produce literally tons of paper to meet milestones and demonstrate progress to stakeholders, rather than spend their energy on tasks that would reduce risk and produce quality software. Typically, presenters and the audience reviewed the simple things that they understood rather than the complex and important issues. Most design reviews therefore resulted in low engineering value and high cost in terms of the effort and schedule involved in their preparation and conduct. They presented merely a facade of progress. Table 1-2 summarizes the results of a typical design review.

Diagnosing the five symptoms of projects headed for trouble (just discussed) can be difficult, especially in early phases of the life cycle when problems with the conventional approach would have been most easily cured. Consequently, modern software projects must use mechanisms that assess project health in early life-cycle phases and that continue with objective, periodic checkups.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment