Lifecycle

Page Updated: Mon, 23 Sep 2019 23:40 AEST (UTC+1000)

What is a lifecycle?

The "full software development lifecycle" could describe the period from initial recognition of the need for a software application to the time version 5.63 is uninstalled off the last user's computer. It is the "process" of software development (which includes maintenance). Here "software development lifecycle", or just "lifecycle", will refer to the shorter period between integer releases, e.g. between initial idea and 1.0, between 2.0 and 3.0, or for analogous periods of development for websites.

We do well to distinguish:

  1. Lifecycle taxonomy: a categorization of the development activities; from
  2. Lifecycle method (aka "the process"): structuring the development activities are over time. E.g Evolutionary Prototyping; Throwaway Prototyping; Spiral; below Waterfall; Staged Release.

Different software projects will generally warrant different lifecycle taxonomies and methods. However, we have a default lifecycle taxonomy and method to serve as a starting point for departure.

Default lifecycle taxonomy

This is our default lifecycle taxonomy. We have four phases that overarch 15 - 20 subphases.
Database Applications Websites (without Databases)
Specification Phase: Specification Phase:
Client requirements write up. Client requirements and content write up.
Requirements interviews. Requirements interviews.
Requirements analysis. Requirements analysis.
Developer system synchronization. 1 Developer system synchronization. 1
Development environment configuration. Development environment configuration.
Architectural design (prototypes and design spikes). Architectural design with design spikes. (wireframes). 2
Detailed design. Detailed design (including Graphic design basics).
Specification write-up. Specification write-up.
The specification sign off milestone.3 The specification sign off milestone.3
Build Phase: Build Phase:
Graphic design.
Code Code (CSS styling, markup, client and server programming, etc)
Functionality freeze milestone. Functionality freeze milestone.
Testing alpha, local. Testing alpha, local.
On site install. On site install (production server, dev folder).
Testing alpha, on site. Testing alpha, remote (dev folder).
No known major bugs milestone. No known major bugs milestone.
User and developer documentation.
User training.
Delivery Phase: Delivery Phase:
Acceptance testing. 4 Acceptance testing and content review. 4
On site install (production server, production folder).
Testing alpha, remote (production folder).
Release milestone (go live). Release milestone (go live).
Testing beta, on site. Testing beta, remote (production folder).
Delivery milestone: after 7 days of trouble free operation from "release", operating according to the specification, you, the client, sign off software as "delivered". Delivery milestone: after 7 days of trouble free operation and no content updates (content that is implied or defined in the specification), you, the client, sign off the website as "delivered".
Maintenance Phase: Maintenance Phase:
Maintenance (user support and bug fixing). Maintenance (user support, bug fixing, and content updates).

Table notes:

  1. Developer System Synchronization: For projects requiring more than one developer disparate Software Development Systems need to be resolved. For example, Okcana's preferred Software Development System is extreme programming; Jack's preference is for Rapid Application Development. We need to mesh these. For a justification see Meta Issues, Who Does Methodology?
  2. Wireframes: A diagram of the basic structure of a web page or pages. For example, Menu type and placement, footer and headers, logos, and page title. Content and graphic design is excluded.
  3. You, the client, sign off the specification as representing what you wish. We quote against this specification.
  4. Acceptance Testing: Automatic and/or user conducted testing (directed by the developer) to verify to you, the client, that the system works according to specification.

Default lifecycle method

The pure, or "classic", waterfall model is rightly satirised. When Winston Royce coined the "waterfall" lifecycle he did so in order to illustrate an alternative. Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, August 1970, 1-9, (accessed 04 Sep 2006). A pure waterfull lifecycle method is not wise.

However in avoiding the traps of the pure waterfall lifecycle method we don't have to abandon the model entirely.

Minimimally, and as mentioned under Rapid Development System, regardless of which lifecycle method you choose the subphases identified in Pure Waterfall are essential to software development. (McConnell 1996 p143). To succeed you can't avoid these subphases. We choose to give more detail by further subdividing those subphases and grouping them into phases, as above.

Our default lifecycle method is a modified waterfall method combined from:

  1. Waterfall with overlapping subphases. "Sashimi" (McConnell 1996 p143).
  2. Waterfall with to-and-fro between the subphases. Although we have overlap and to-and-fro between the subphases, we will be able to make progress visible by identifying the which subphase we have arrived at. That is, progression maintains a large degree of linearity.
  3. Waterfall with risk reduction in the specification phase. (See "Waterfall with risk reduction" McConnell 1996 p146).
  4. Throwaway prototyping. This can be considered to be a requirements solitication method. It is the chief tool to reduce risk in the specification phase.
  5. A Specification Gateway. The build phase doesn't start until the specification is signed off by the client.

This lifecycle method is partly justified under A Simplified History Of Software Development.

Feature 2. is worth expanding on:

Any lifecycle must allow some to-and-fro between the software development subphases.

Many authors have written about this necessity. That to-and-fro is required can perhaps be best understood through Jack Reeve's lens. Everything is design:

The overwhelming problem with software development is that everything is part of the design process. Coding is design, testing and debugging are part of design, and what we typically call software design is still part of design...

On any software project of typical size, problems like these are guaranteed to come up. Despite all attempts to prevent it, important details will be overlooked...

Programming is a design activity...

There are other design activities -- call them top level design, module design, structural design, architectural design, or whatever. A good software design process recognizes this and deliberately includes the steps...

In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be...

All design activities interact.

What is Software Design?, Jack W. Reeves, C++ Journal - 1992, accessed 28 aug 2006. Emphasis original.

If everything is understood as design it becomes apparent why to-and-fro between the subphases may be needed regardless of what formal subphase you are currently in.

For example, when you are in the nominal "code" subphase you may unearth a design choice. It may be necessary to phone the client: a kind of jumping back to the requirements gathering subphase.

Conversely, during the nominal "requirements gathering" subphase the options you can offer the client will depend on what's technically feasible. You may have to do some experimental coding (known as a "design spike" in extreme programming) to determine those options: a kind of jumping ahead to the code subphase.

References