"Life is the state of ceaseless change and functional activity peculiar to organized matter."The terms ‘development cycle’ and ‘life cycle,’ are synonymous in engineering and have been in common use in the fields of computing and software since the 1960s. From the early 1900s it is used next in sociology applied to the individual’s life history and is then applied to businesses and manufactured products from the 1950s onwards (OED, 2010). The earliest references to ‘life cycle’ use it to refer to the entirety of a biological life described scientifically. The life cycle describes an entire biological life (birth, maturation, death) as an abstract sequence of events and transformations. The idea of a ‘life cycle’ is a relatively modern concept. Its published use commences in the mid 1800s when the idea of ‘cycles’ with connotations of lunar, diurnal, mechanical, of recurring events and events recurring in a chronological cycle. Implicit within the definition of a life is the idea of a beginning and an ending, birth and death, the span of a life, or in the case of technology, the duration of a project or product. Ultimately the idea of life cycle is a metaphorical description of projects applied over relatively long durations. It links the idea of activity with the passage of time but emphasising the long term processes under which activities become transformed into the cohering thing that projects produce, be they a business model, a technology, a business process, service etc.
(Fowler and Fowler, 1929)
For the purpose of the following discussion I focus on life cycles as a subset of management systems for development and so propose the following definition: a life cycle is a process that describes how to start and finish a high-tech project. Applying this definition, an organization may employ different life cycles for different projects. Life cycles simply provide local guidance on how to organize a development project team and (should) generally steer clear of prescribing the operational structure of the wider organization.
LIFE CYCLE MODELS IN SYSTEMS DEVELOPMENT
The life cycle concept is much used (perhaps overused) and maligned in the informatics discipline; assuming informatics to encompass Information Systems, Computer Science, Software Engineering, programming, and computing more generally. The Systems Development Life Cycle has been described as harmful because it is a blinkered (though comforting) world-view that imposes a project management structure on system development (McCracken and Jackson, 1982). Furthermore there are a number of common and well known circumstances in which a unified staged development cycle (SDLC) is known to fail. In these situations alternate approaches like mock-ups, rapid prototypes, and end-user development are indicated (Gladden, 1982, McCracken and Jackson, 1982).
In 1991 Peter DeGrace and Leslie Stahl created an inventory of the life cycles and software engineering methods in use. Fully half of all approaches were waterfall model in one guise or another, consequently they spent half of their time critiquing waterfall (DeGrace and Stahl, 1991). But what are we talking about when we use the ‘life cycle’ term? The following table (below) summarizes DeGrace & Stahl and complements their catalogue by including more recent inventories of software engineering management/design concepts. These concepts are variously labeled as life cycles, methodologies, design methods, models, even systems themselves.
Table: Life cycles and development methods
DeGrace & Stahl (1991), McConnell (1996) and Avison & Fiztgerald (2006) provide detailed descriptions of the life cycles or methodologies they document. Boehm’s (2006) presentation summarizes the historical development of software engineering and possibilities for computer technology and its management into the 21st Century. We may make some generalizations based on this overview.
Over the 25 years represented by these snapshots the number of life cycles and methods has steadily increased. It is not immediately obvious whether one or other approach is simply a life cycle, or a design method, or if indeed is intended for wider application for governing organizational operations. Boehm characterized life cycles into four categories (Boehm, 1988):
- Code and Fix
- Stagewise and Waterfall Models
- Transform Model (4GLs, code generators, very high level)
- The Spiral Model
Wider operational structures are of course necessary but would instead be the focus of what we might term management ‘frameworks’ and general organizational theory (see following section). A life cycle is therefore an organizational template for managing a project and will therefore be largely concerned with addressing issues affecting scope, cost/effort, time and quality.
A further distinction is necessary to help us reduce confusion among this variety of life cycles, methods and methodologies. Life cycle should not become conflated with design method. Design methods are many and various, and sometimes mandate wider organizational structures and events, but they are ultimately techniques for ‘representing’ and manipulating design objects or a particular technology itself. For example, design methods are may be closely linked to a particular software tool or programming paradigm e.g. Z and Formal specification, functional design and structured programming, ERD and data flow with DBMS design, UML and OOAD etc. (Bell, 2000).
THE WATERFALL MODEL (AKA SDLC)
"If the only model we have is the waterfall, then we will see the world in terms of problems that can be solved using it. Our world and our field are richer than that. We need a toolbox of models." (DeGrace and Stahl, 1991)Waterfall theories of system development still abound so we should investigate their origin and definition. The peculiar thing is the death of waterfall was heralded years ago but the idea persists (Hanna, 1995, Gladden, 1982, McCracken and Jackson, 1982). Waterfall thinking was (and perhaps still is) entrenched in industry and general thinking. In spite of numerous critiques the waterfall is still with us (Table 2). The waterfall has become an almost subconscious assumption in management, with the risk that this subliminal view of high-tech projects shapes our world-view of production and innovation more generally.
Table: Development life cycles in firms; Ireland 2010 (Higgins et al, unpublished)
One of the earliest descriptions of the waterfall method for software development is often attributed Winston W. Royce’s in his article “Managing the Development of Large Software Systems” (Royce, 1970). Royce drew on his own experience working as a programmer on early high-tech Department of Defense projects in the 1960s. He described the difficulties of achieving success in terms of operational state (functionality), on time, and within costs. Royce’s goal was to improve our capability to program large-scale developments, to better produce and deliver, from concept through to implementation, large computer systems. Royce presented a detailed description of the SDLC’s step-wise model for development, which he dismisses as infeasible. He terms these kinds of systems the 'grandiose approach' to software development but concluded that the grandiose approach is an "intrinsically risky development process."
Figure: A sketch of the SDLC; The Grandiose Approach (from Royce, 1970)
Figure: The essential activities of software development (from Royce, 1970)
Royce identified the central challenge for large computer systems in dealing with the essential character of computing, the so-called 'essence of programming.' The work of software development centers on two main activities; analysis and coding. No other activities contribute as directly to the final product. These activities together "involve genuinely creative work which directly contributes to the final product." (Royce, 1970) However as a project becomes sufficiently large it becomes necessary to revert to the grandiose model to formally highlight other necessary activities. But the central problem with the grandiose model is that task and leakage inevitably takes place between successive process steps. Task leakage and linkage (see below) occurs complexly between all steps in the process, from the very last stage right back into the earliest. The central problem is that 'design' involves everything; analysis, coding, testing, how the product is used etc. Furthermore he claims it is futile to treat the high-tech development process as a linear flow. Simply put, a linear process model breaks down for anything other than the most trivial commodity task.
Figure: Task leakage and unexpected linkage complicates the SDLC on real systems development projects (from Royce, 1970).
In the absence of an alternative to the development lifecycle Royce identified additional necessary steps to ensure large scale software systems satisfy requirements, to ensure they are stable, usable, maintainable etc. Leakage in the development lifecycle should be dealt with explicitly through additional activities (below) rather than by hiding them “under the rug” (Brooks Jr., 1995).
Figure: Remedies to the SDLC (adapted from Royce, 1970)
Royce's Remedies
"Begin the design process with program designers, not analysts or programmers [so that] preliminary program design is complete before analysis begins"Royce proposed 5 steps to overcome the shortcomings of the development lifecycle. The alternative is in fact an iterative interactive approach, albeit described in the terms of the grandiose development lifecycle. System design is reduced to five tenets or principles for minimizing development risk:
(Royce, 1970)
- Program design comes first
- Document the design
- Do it twice
- Plan, control and monitor testing
- Involve the customer.
These ideas presage Fred Brooks’ (Brooks Jr., 1995) own conclusions from working on the IBM System/360 and OS/360 development project. The principles also hint at what is now labeled Agile Development (see following section). They were a radical departure from centrally planned approaches of the day where analysts worked apart from designers who kept aloof from programmers and users or customers were almost entirely absent from development projects (some might argue the same conditions still hold in many organizations).
Royce was conscious that development life cycles can become a self defeating remedy to the challenge of managing high-tech projects; the cure may be worse than the disease. The extra steps and activities of the development life cycle drive up the cost and complexity of managing the development of a large system. Additional management activity further complicates systems projects and potentially drives down the probability of success while at the same time driving up cost. This introduces its own problems as customers may be reluctant to pay for the cost and complexity of additional management, and designers are often reluctant go along with the demands imposed by additional management activities all of which pull time away from software design and development. Royce concludes therefore that…
“The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.” (Royce, 1970)
A SPIRAL MODEL OF SOFTWARE DEVELOPMENT AND ENHANCEMENT
The spiral model was presented in 1988 as a general life cycle model (Boehm, 1988). Lifecycles, or to use Boehm’s label ‘software process models,’ define the order of events and activities for software development projects. The spiral model he proposed was an attempt to address the deficiencies of linear stage-wise development models. The spiral was presented as a unified life cycle model, generally useful in so far as it specifies the all necessary activities and transformations experienced over the life of a software development project. Boehm introduced the idea that a development life cycle could be designed as a process for managing risk rather than introducing risk. The spiral redefined software development as a process (below) and popularized the notion that development could be considered an on-going cycle of iterations rather than an end-to-end production line. The spiral process allows for requirements to evolve and for the project to account for its own changing environment.
Figure: Spiral model of the software process (adapted from Boehm, 1988)
Delivery of a version of the evolving project is a key milestone for each cycle. The project is reviewed and could potentially be stopped at the end of each cycle of the spiral. Each review event commits the project to further exploration and taking on additional risk, which is clarified and resolved in prototypes and simulations. Working prototypes or partial versions of the product are then produced and validated. Turns through the spiral expand progressively to include more and more of the waterfall’s activities (design, code, test, implementation, operations). The spiral can be used to manage small incremental project improvements or large uncertain product development projects.
A way of understanding the relationship between a development project’s cost, completion and risk is depicted (see below). The expanding circles reflect the cumulative cost of the project; the phase or % completion of each cycle is evident by progress along each cycle or turn. Risk and its trend (increasing or decreasing) are represented as a vector from the project origin (which shifts) to the current point in the cycle.
Figure: Spiral model 'risk, completion, cost disk'
The idea of ‘design risk’ reduces to being a factor of the people involved in a project. A low risk design element for an experienced engineer may be a challenging and risky job for an inexperience engineer. However managing the risk by reverting to the experienced engineer may be a short-term solution to what is in fact a different game running over the long term. Involving customers and users in prototype evaluation is a way of exploring requirements and further reducing risk.
By championing prototyping Boehm also provided a place for Royce’s advice to plan to ‘do it twice’ (Royce, 1970), i.e. a preliminary design and implementation that exercises all the other stages of the lifecycle. A development project undergoes a series of iterations or rounds; proceeding to the next round depends on how the preceding round went and on continuing viability of the business case driving the project.
Boehm’s spiral was the last significant theoretically driven contribution to high-tech project management up until 1999. Subsequent contributions to the burgeoning business of creating new life cycles and development methodologies were either hybrids of spiral/waterfall or techniques rather than whole project life cycles. For example Rapid Application Development (RAD) was founded on a single big idea, working prototypes. Iterative development is conceptually equivalent to spiral. Dynamic Systems Development Methodology (DSDM) was designed around the key concept of iterations. Participatory design, user driven development and Joint Application Development (JAD) give emphasis to user/customer engagement in the development process. The Rational Unified Process (RUP) gave credence to the manageability of large sets of projects and popularized the idea of automatic code generation from UML designs.
The break Boehm makes with the thinking of the day was to present a concrete actionable model for organizations to shift systems development from a batch thinking to process thinking perspective. That development was more like a process than assembly, where assembly lines move a product-in-progress from stage to stage to completion. The spiral model characterized development as an on-going cycle of expanding requirements (and risk) followed by resolving the requirement (removing risk) by creating new parts. An initially uncertain product idea gradually comes into focus over repeated cycles in an on-going process of discovery and refinement.
The process view of product development encompasses the batch view as each cycle can be considered a small batch.
CONCLUSIONS
New technologies in the form of better programming languages, more powerful computing hardware, new languages and development environments have held out the promise of improved production cycles for software and high-tech development. Unfortunately technological remedies are slow to evolve or when developed result in pushing the problem of design into other zones of the development ecosystem.
While the life cycle metaphor is certainly a useful way of characterising development activities and helps order or structure the working environment practitioners assert that the microscopic activities of programming are intrinsically bound up with each other and cannot be meaningfully separated. Cyclic or iterative process models like spiral are certainly better approximations of the underlying process of software design and production, and are therefore an improvement on earlier models. But at a macroscopic level, the level of teams and projects and organizations, stage-wise, and even cyclic process models like spiral simply do not capture the practical reality of programming. Ultimately life cycle models are mere organizational constructs, ways of ordering projects; they do not address the detailed production of systems design.
We have noted that stage-wise development models like the SDLC and waterfall become unmanageable for well-understood reasons:
- Software development tasks are complexly interdependent.
- Task interdependency demands close communication and coordination between workers.
- High-tech products are subject to uncertain and evolving requirements.
- The high-tech environment is constantly evolving.
