B. Traceability to vision and business case

Figure 6-5. Typical release specification outline

Figure 6-5. Typical release specification outline thresholds). These management-oriented requirements may be represented by use cases, use case realizations, annotations on use cases, or structured text representations.

The system requirements (user/buyer concerns) are captured in the vision statement. Lower levels of requirements are driven by the process (organized by iteration rather than by lower level component) in the form of evaluation criteria (typically captured by a set of use cases and other textually represented objectives). Thus, the lower level requirements can evolve as summarized in the following conceptual example for a relatively large project:

1. Inception iterations. Typically, 10 to 20 evaluation criteria capture the driving issues associated with the critical use cases that have an impact on architecture alternatives and the overall business case.

2. Elaboration iterations. These evaluation criteria (perhaps 50 or so), when demonstrated against the candidate architecture, verify that the critical use cases and critical requirements of the vision statement can be met with low risk.

3. Construction iterations. These evaluation criteria (perhaps hundreds) associated with a meaningful set of use cases, when passed, constitute useful subsets of the product that can be transitioned to formal test or to alpha or beta releases.

4. Transition iterations. This complete set of use cases and associated evaluation criteria (perhaps thousands) constitutes the acceptance test criteria associated with deploying a version into operation.

This process is naturally evolutionary and is loosely coupled to the actual design and architecture that evolves. In the end, 100% traceability becomes important, but intermediate activities and milestones are far less concerned with consistency and completeness than they were when the conventional approach to software development was used. Each iteration's evaluation criteria are discarded once the milestone is completed; they are transient artifacts. A better version is created at each stage, so there is much conservation of content and lessons learned in each successive set of evaluation criteria. Release specification artifacts and their inherent evaluation criteria are more concerned early on with ensuring that the highest risk issues are resolved.

Software Development Plan

The software development plan (SDP) elaborates the process framework into a fully detailed plan. It is the defining document for the project's process. It must comply with the contract (if any), comply with organization standards (if any), evolve along with the design and requirements, and be used consistently across all subordinate organizations doing software development. Two indications of a useful SDP are peri-

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