To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
ANSWERED August 2009:
A life cycle describes a way, most commonly a sequence of phases or major events and activities, that has been found to lead to success in some endeavor. Life cycles typically go from cradle to grave. There are life cycles for all kinds of things, including life: you're born, grow up, go to school, earn a living, raise a family, retire, and die. It sounds kind of boring when stated this way, so most literature tends to glamorize it (thank goodness).
The life cycle most of us probably are most familiar with is the system development life cycle (SDLC), which is closely allied with the project management life cycle. The diagram below shows both together.
Requirements, design and development
The rectangles depict the common SDLC phases. Corresponding project management phases are listed on the left. The bulk of a systems project is spent identifying requirements, designing the system or product to be created, and then developing the system as designed by programming and testing that the programs meet the design.
Correspondingly, the bulk of project management time is spent directing and controlling the execution of these three phases, which ordinarily are performed iteratively several times within one or more increments. Each iteration identifies and elaborates additional requirements, adds design elements to satisfy them, and then develops the additional design elements.
Requirements analysis should discover the detailed REAL, business requirements deliverable whats that provide value when delivered. Design of a way to satisfy the requirements usually starts with a product, system, or software definition which often is referred to as "functional requirements," even though it's actually a form of high-level design. This high-level design often focuses on features, each of whose functionality then typically is described in more detailed designs. Low-level designs then lead to even more detailed engineering and technical designs, which are very physical and are implemented in hardware and software by the developers.
Sound development includes reviews of each of the development deliverables—requirements, designs, and code. Reviews are the most economical way to catch and fix errors before they affect subsequent artifacts. Unit, integration, and system testing of developed code should be integrated with the development of the code, which further helps catch errors earlier when they are easier and cheaper to fix.
Many organizations treat testing as a separate phase which is performed at the end of each major increment; but this is less effective because too many errors are not detected until late, when they are harder and more expensive to fix. Moreover, testing is more effective when it is planned and designed as much as possible during design, prior to development.
All development methodologies define requirements, design solutions, and develop the design—in that order. Few methodologies explicitly identify test planning and design as important life cycle activities, especially not as part of System Design prior to Development. Methodologies mainly differ in how explicitly they recognize they're following the three phases and in the number of times they repeat this sequence of phases. Typically the more times the phases are repeated, the smaller the size of functionality in each repetition.
At one extreme is the "waterfall" methodology, which many people erroneously believe must be slavishly inflexible, defining all the requirements before designing all the system before developing all the design and never having feedback or going back to a prior phase. Waterfall projects often define, design, and develop large pieces of functionality at a time. Agile development is at the other extreme, focusing on very small pieces of functionality and revisiting and reworking much of what already has been done.
Implementation, operations and maintenance
An increment represents a major piece of added functionality which is implemented into production as it becomes workable, often in the form of builds or releases. Frequently, each increment must pass user acceptance testing (UAT) before being released into production.
Once implemented, each increment must be operated and maintained until it eventually is retired or replaced. Most organizations make the mistake of failing to include the operations and maintenance phase in their life cycle. Instead they characterize implementation as the end of development, which places a premium on hitting a deadline without taking into account adequately the impact on costs of supporting whatever they've too often rushed into production.
Closure occurs when the development project is considered completed, typically after all the key functionality has been implemented. The project could represent multiple increments, although many projects have only one increment. Conversely, a big project may be broken into several sub-projects, each of which is treated as a separate project, follows the life cycle, and can have its own iterations and increments.
It's common shortly after the end of a project to conduct a post-implementation review, which tellingly often is dubbed the unfortunate term, "post-mortem." The purpose of this type of review is to learn lessons from the project experience so that they can be applied to improve the development and project processes on subsequent projects. However, most organizations find that their lessons learned remain pretty much the same project after project. In other words, they haven't really learned the lessons because they don't apply them. Effective project management learns and applies lessons throughout the project, as well as from project to project.
Feasibility
Although it comes first, I'm discussing the Feasibility Analysis phase last, partly because it's an important methodology differentiator that is often omitted from life cycles and partly because I've already discussed it quite a bit in my Ask the Experts response, "Which SDLC Model is best for frequently changing requirements," and in my tip, "Defining requirements during software project feasibility analysis."
Feasibility Analysis compares major alternative solution approaches to determine whether each approach could achieve desired results and which approach is most economically effective. While Return on Investment (ROI) should be calculated at various key points throughout a project to make sure the project still is worth doing, most projects calculate ROI only once if at all, at the very beginning during Feasibility Analysis.
Regardless whether it's conducted explicitly, every project includes a Feasibility Analysis phase, because that's when the project management life cycle Initiation, Planning, and Organization phases occur. This phase defines the project and sets its budget and schedule. Impossible budgets and schedules usually result and destine a project to fail when Feasibility Analysis is done implicitly, unconsciously, and inadequately.
A main project-dooming cause of inadequate feasibility analysis stems from failing first to discover the top-level REAL business requirements that provide value when met. Each alternative approach's feasibility should be evaluated with respect to its ability and cost to meet those REAL business requirements. During the later Systems (or Requirements) Analysis phase, the top-level business requirements are driven down to detail, which then becomes the basis for high- and low-levels of System Design.
However, most projects fail to adequately identify the business requirements. Instead, they start with the high-level design of the product, system, or software they expect to create and thus have no meaningful basis for assuring it will provide value, let alone reliably measuring its financial ROI. Such projects invariably suffer extensive creep in order to fix inevitable functional shortcomings, which in turn lead to budget and schedule overruns.
In addition, as commonly carried out, projects following various iterative development methodologies generally suffer from a second Feasibility Analysis phase form of inadequacy. When used effectively, such methodologies perform overall product planning during Feasibility Analysis to identify and sequence the requirements, design, and development iterations needed.
In contrast, most iterative development simply plunges into coding pieces of the product without suitable prior planning to determine what pieces are needed, how they will fit together, and what the most appropriate sequence is for creating and integrating them. By not taking advantage of the Feasibility Analysis phase, time-consuming and expensive excessive iterations often are needed to correct architectural shortcoming.
Life cycles are defined to help one succeed, not to create a mass of bureaucratic busywork. Using the life cycle to guide one's work, when applied in an informed and flexible manner, indeed can increase chances of success.
|
