Modern software development processes have moved away from the conventional waterfall model, in which each stage of the development process is dependent on completion of the previous stage. Although there are variations, modern approaches generally require that an initial version of the system be rapidly constructed early in the development process, with an emphasis on addressing the high-risk areas, stabilizing the basic architecture, and refining the driving requirements (with extensive user input where possible). Development then proceeds as a series of iterations, building on the core architecture until the desired levels of functionality, performance, and robustness are achieved. (These iterations have been called spirals, increments, generations, or releases.) An iterative process emphasizes the whole system rather than the individual parts. Risk is reduced early in the life cycle through continuous integration and refinement of requirements, architecture, and plans. The downstream surprises that have plagued conventional software projects are avoided.
The economic benefits inherent in transitioning from the conventional waterfall model to an iterative development process are significant but difficult to quantify. As one benchmark of the expected economic impact of process improvement, consider the process exponent parameters of the COCOMO II model. (Appendix B provides more detail on the COCOMO model.) This exponent can range from 1.01 (virtually no diseconomy of scale) to 1.26 (significant diseconomy of scale). The parameters that govern the value of the process exponent are application precedentedness, process flexibility, architecture risk resolution, team cohesion, and software process maturity.
The following paragraphs map the process exponent parameters of COCOMO II to my top 10 principles of a modern process.
• Application precedentedness. Domain experience is a critical factor in understanding how to plan and execute a software development project. For unprecedented systems, one of the key goals is to confront risks and establish early precedents, even if they are incomplete or experimental. This is one of the primary reasons that the software industry has moved to an iterative life-cycle process. Early iterations in the life cycle establish precedents from which the product, the process, and the plans can be elaborated in evolving levels of detail.
• Process flexibility. Development of modern software is characterized by such a broad solution space and so many interrelated concerns that there is a paramount need for continuous incorporation of changes. These changes may be inherent in the problem understanding, the solution space, or the plans. Project artifacts must be supported by an efficient change management environment commensurate with project needs. Both a rigid process and a chaotically changing process are destined for failure except with the most trivial projects. A configurable process that allows a common framework to be adapted across a range of projects is necessary to achieve a software return on investment.
• Architecture risk resolution. Architecture-first development is a crucial theme underlying a successful iterative development process. A project team develops and stabilizes an architecture before developing all the components that make up the entire suite of applications components. An architecture-first and component-based development approach forces the infrastructure, common mechanisms, and control mechanisms to be elaborated early in the life cycle and drives all component make/buy decisions into the architecture process. This approach initiates integration activity early in the life cycle as the verification activity of the design process and products. It also forces the development environment for life-cycle software engineering to be configured and exercised early in the life cycle, thereby ensuring early attention to testability and a foundation for demonstration-based assessment.
• Team cohesion. Successful teams are cohesive, and cohesive teams are successful. I am not sure which is the cause and which is the effect, but successful teams and cohesive teams share common objectives and priorities. Cohesive teams avoid sources of project turbulence and entropy that may result from difficulties in synchronizing project stakeholder expectations. While there are many reasons for such turbulence, one of the primary reasons is miscommunication, particularly in exchanging information solely through paper documents that present engineering information subjectively. Advances in technology (such as programming languages, UML, and visual modeling) have enabled more rigorous and understandable notations for communicating software engineering information, particularly in the requirements and design artifacts that previously were ad hoc and based completely on paper exchange. These model-based formats have also enabled the round-trip engineering support needed to establish change freedom sufficient for evolving design representations.
• Software process maturity. The Software Engineering Institute's Capability Maturity Model (CMM) is a well-accepted benchmark for software process assessment. Just as domain experience is crucial for avoiding the application risks and exploiting the available domain assets and lessons learned, software process maturity is crucial for avoiding software development risks and exploiting the organization's software assets and lessons learned. (The pros and cons of the CMM are discussed at length in Appendix E.) One of my key themes is that truly mature processes are enabled through an integrated environment that provides the appropriate level of automation to instrument the process for objective quality control.
Was this article helpful?
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.