with regard to when where and under which conditions the targets apply, so there is no risk of us inadvertently applying them inappropriately.
COMPLETE REQUIREMENT SPECIFICATION
A complete set of all critical quality and cost aspects shall be specified, avoiding the risk of failing to consider a single critical attribute.
COMPLETE DESIGN SPECIFICATION and IMPACT ESTIMATION
A complete set of designs or strategies for meeting the complete set of quality and cost targets will be specified. They will be validated against all specified quality and cost targets (using Impact Estimation Tables). They will meet a reasonable level of safety margin. They will then be evolutionarily validated in practice before major investment is made. The Evo steps will be made at a rate of maximum 2% of budget, and 2% of 'project time', per 'incremental trial' (Evo step) of designs or strategies.
SPECIFICATION QUALITY CONTROL NUMERICALLY EXITED
All requirements, design, impact estimation and Evolutionary project plans, as well as all other related critical documents such as contracts, management plans, contract modifications, marketing plans, shall be 'quality controlled' using the Inspection method [GILB93]. A normal process Exit level shall be that 'no more than 0.2 Major Defects per page maximum, can be calculated to remain, as a function of those found and fixed before release, when checking is done properly' (e.g. at optimum checking rates of 1 logical page or less per hour).
EVOLUTIONARY PROOF-OF-CONCEPT PRIORITIES
The Evolutionary Project Management method [GILB98, GILB88] will be used to sense and control risk in mid-project. The dominant paradigms will be
2% steps, high value to cost with regard to risk delivered first. high risk strategies tested 'offline to customer delivery', in the Backroom of development process, or at cost-to-vendor, or with 'research funds' as opposed to project budget.
TABLE 7: Twelve Tough Questions
- Why isn't the improvement quantified?
- What is degree of the risk or uncertainty and why?
- Are you sure? If not, why not?
- Where did you get that from? How can I check it out?
- How does your idea affect my goals, measurably?
- Did we forget anything critical to survival?
- How do you know it works that way? Did it before?
- Have we got a complete solution? Are all objectives satisfied?
- Are we planning to do the 'profitable things' first?
- Who is responsible for failure or success?
- How can we be sure the plan is working, during the project, early?
- Is it 'no cure, no pay' in a contract? Why not?
DION93: Raymond Dion, "Process Improvement and the Corporate Balance Sheet", IEEE Software, July 1993, Pages 28-35.
DION95: Raymond Dion, Tom Haley, Blake Ireland and Ed Wojtaszek of Raytheon Electronic Systems, "The Raytheon Report: Raytheon Electronic Systems Experience in Software Process Improvement", November 1995, SEI web-site.
This is an important update of earlier reports. GILB88: Tom Gilb, "Principles of Software Engineering Management", Addison-Wesley, 1988, 442 pages. ISBN 0-201-19246-2. See particularly Chapter 6, Estimating the Risk (reproduced in Boehm, Software Risk Management, IEEE CS Press, 1989 page 53).
GILB93: Tom Gilb and Dorothy Graham, "Software Inspection", Addison-Wesley, 1993, ISBN 0-201-63181-4, 5 TH printing 1998, 471 pages.
This book covers the Defect Detection Process and the Defect Prevention Process, as well as giving sample Rules to check by, defined processes and a well defined set of Glossary terms to aid quantification and comparison. It is a next-generation Inspection, with hundreds of larger and smaller improvements over initial Inspection practices.
GILB98: Tom Gilb, Various papers and manuscripts on www.Result-Planning.com. The manuscripts include: 'Requirements-Driven Management using Planguage' (1995-6), Evolutionary Project Management' (1997), 'Requirements Engineering Language' (1998).
HALL98: Elaine M. Hall,