Computer Society
categories: Predictive and Adaptive.
Predictive life cycle models "favor optimization over adaptability" (Russell D Archibald,
Desaulniers and Anderson 2002) and include:
►Waterfall: (Also known as traditional and top-down) linear ordering of the phases, which can be
strictly sequential or overlapping to some extent. No phase is normally repeated.
►Prototyping: Functional requirements and physical design specifications are generated
simultaneously.
►Rapid application development (RAD): based on an evolving prototype that is not thrown away.
Incremental build: decomposition of a large development effort into a succession of smaller
components.
►Spiral: repetition of the same set of life-cycle phases such as plan, develop, build, and evaluate
until development is complete.
Adaptive life cycle models "accept and embrace change during the development process and
resist detailed planning " (Russell D Archibald, Desaulniers and Anderson 2002) and include:
►Adaptive software development/ASD: Mission driven, component based, iterative cycles, time
boxed cycles, risk-driven, and change-tolerant.
►Extreme programming/XP: Teams of developers, managers, and users; programming done in
pairs; iterative process, collective code ownership.
►SCRUM: Similar to above adaptive life cycle models with iterations called "sprints" that typically last
30 days with defined functionality to be achieved in each sprint; active management role throughout.
Agile Software Development Models
These adaptive models are also referred to as "agile " life cycle models (Bullock 2003). In 2001 the
"Agile Software Development Manifesto " was issued by a group of seventeen representatives of
these adaptive life cycle model users, and this movement has gained considerable momentum in
the IT industry. See http://www.agilemanifesto.org/.
Project Environment Impact on the Life Cycle Model
Design and adaptation of the life cycle model for each project category or subcategory must reflect the
important characteristics of the project environment. "The organizational characteristics, the degree of
familiarity with the technology to be used, and the competitive demands for initiating the project are
just some of the environmental factors that can vary from project to project " (Russell D Archibald,
Desaulniers and Anderson 2002.)
Project life cycle models
Managing Software Development Projects with the Rational Unified Process/RUPÆ
RUP is a widely used process model developed by IBM that consists of six best practices:
►Develop software iteratively
►Manage requirements
►Use component-based architectures
►Visually model software
►Continuously verify software quality, and
►Control changes to the software.
Wideman (2002) presents a comprehensive treatise on RUP that can be seen at http://www.
maxwideman.com/papers/acquisition/intro.htm. RUPÆ is a process product developed, maintained
and integrated with a suite of software tools available from IBM on CD-ROM or on the Internet at http:
//www.us.ibm.com/.
Generic and for various project categories
[Source: Archibald 2003, pp 45-46]
Improving the Project Life Cycle Management Process
Once the life cycles have been designed and documented for each category or subcategory of
projects, it is then possible to define and document the project life cycle management system for
each. Only when such documentation exists can the system be improved in a systematic, integrated
manner. To establish a total quality management (TQM) approach to an organization's project
management capabilities and to avoid sub-optimal improvements being introduced on a disjointed,
piece-meal basis, the following approach is recommended:
1. Document the integrated life cycle process model: As discussed earlier.
2. Document and describe the resulting Project Life Cycle Management System (PLCMS) for each
project category within the organization: also discussed earlier.
3. Re-engineer the integrated process to apply appropriate re-engineering methods to each
category's PLCMS to:
a. Identify system constraints, gaps and weaknesses.
b. Identify 'speed bumps' that inadvertently slow the process down and potential 'accelerators' that
can speed it up (Githens 2002).
c. Relate the undesirable project results and possible causes to the PLCMS wherever possible.
d. Redesign the PLCMS beginning with the most obvious constraints, gaps and weaknesses and
document the results.
4. Implement the Improvements:
a. Obtain needed agreements and conduct appropriate tests or analyses to prove out the validity and
feasibility of the proposed system revisions.
b. Plan, approve and execute the improvement project to implement the revised PLCMS.
5. Repeat the steps as required until an optimum achievable PLCMS has been implemented.
The PLCMS improvement team must include experienced practitioners from within the organization
who are familiar with the existing project management practices: Project Life Cycle Models Project
Management Planning and Control Practices, Systems, and Tools
Although examples for information system development projects are given here, these may also
apply to some other high-technology projects.
