Tailored Software Development Life Cycle Models

Tailored Software Development Life Cycle Models

Often a project manager can pick a life cycle model from a book and run with it. Other times, there seems to be nothing that quite fits the project needs, although one of the extensively used and pretested models comes close. Need a life cycle that deals with risk, but the spiral seems like overkill? Then start with the spiral and pare it down. Required to deliver functionality in increments but must examine serious reliability issues? Then combine the incremental model with the V-shaped model. Many examples of tailored models follow.

Fast Track

A fast-track life cycle methodology speeds up, or bypasses, one or more of the life cycle phases or development processes. Many or most of the normal development steps are carried out as usual, while the formality or scope of others may be reduced.

Tailoring of the life cycle is required for a fast-track approach best used on nonmajor software development and acquisition projects. Fast tracking may be required to serve a time criticality such as being the first to market for a commercial product, or a national threat for a government agency. In addition to a shortened life cycle, one tailored for fast tracking is generally less formal. The overall life of the delivered product may be short, indicating a short maintenance phase.

Fast-track projects should be attempted only in organizations accustomed to discipline. An institutionalized, defined development environment minimizes risk when employing this type of extreme measure. With a clearly defined, stable set of requirements and a method in place to accommodate changes, fast-track projects have an increased chance of success.

Concurrent Engineering

Concurrent engineering (CE) is concerned with making better products in less time. A basic tenet of the approach is that all features of the product's life cycle should be considered as early as possible in the design-to-manufacturing process. Early consideration of later phases of the life cycle brings to light problems that will happen downstream and, therefore, supports intelligent and informed decision-making throughout the process.

Though borrowed from other engineering disciplines, concurrent engineering works for software as well. Particularly on large projects, status tracking by major phases in a life cycle may be an oversimplified model. A snapshot in time would show that there are generally various activities (requirements gathering, design, coding, testing, etc.) going on at the same time. Additionally, any internal or external project deliverable may be in one of various states (being developed, being reviewed, being revised, waiting for the next step, etc.). Concurrent engineering deals with all aspects of the life cycle as early as possible. Concurrent process models allow an precise view of what state the project is in - what activities are being conducted and how the deliverables are progressing.

When using this approach, it is wise to evaluate technical risks involved to determine whether the technology being attempted is compatible with an accelerated strategy, leave some room in the schedule, assess the technological process periodically to see if it is still well-matched with the plan, and, as with more usual life cycles, make sure that there is a provision for testing and assessment because there is great risk in skipping these activities.

The spiral model, being risk-driven, is a good model to use in guiding multistakeholder concurrent engineering of software-intensive systems. It offers a cyclic approach for incrementally growing a system's definition and implementation, as well as providing anchor-point milestones for ensuring continued stakeholder commitment.

Win-Win Spiral Model

Boehm also offers a modified spiral model called the "win-win spiral model", shown in figure (a). It includes more customer-focused phases by adding Theory W activities to the front of each cycle. Theory W is a management approach elevating the importance of the system's key stakeholders (user, customer, developer, maintainer, interfacer, etc.), who must all be "winners" if the project is declared a success. In this negotiation-based approach, the cycles include these phases or steps: Identify next-level stakeholders; identify stakeholders win conditions; reconcile win conditions; establish next-level objectives, constraints, and alternatives; evaluate process and product alternatives and resolve risks; define the next level of the product and process, including partitions; authenticate the product and process definitions; and review and comment.

The Win-Win Spiral Model

Not shown in figure (a), but an important step, is to then plan the next cycle and update the life-cycle plan, including partitioning the system into subsystems to be addressed in parallel cycles. This can contain a plan to end the project if it is too risky or infeasible. Secure the management's commitment to proceed as planned.

Advantages of the win-win spiral model have been noted as: faster software via facilitated collaborative involvement of relevant stakeholders, cheaper software via rework and maintenance reduction, greater stakeholder satisfaction up-front, better software via use of architecture-level quality-attribute trade-off models, and early exploration of many architecture options.

Evolutionary / Incremental

Due to their nature, the evolutionary / incremental acquirements sometimes come across complications. Questions arise because each incremental build provides but a small part of the capability of the system to be acquired. In addition to normal development decision criteria, additional questions must be answered:

■  Is the decision to develop this functionality for this amount of money a good idea?

■  Is this the time to address the functionality question (user priorities, dictates of the evolution itself)?

■  Is this a reasonable price for the functionality being added (or are we "gold-plating" one functional area before developing all required capabilities)?

■  Will we run out of money before we complete the required system?

Incremental V

Figure (b) shows a combination model fashioned by Krasner. In Constructing Superior Software, he is approaching the software development life cycle model from teamwork considerations.

Incremental V Project Process Model

Fashioning a good project life cycle model is a valuable up-front investment that puts all project staff on the same page such as the traditional V model blended with the incremental, iterative development model. This model attempts to balance the need for management controls with the need for technical innovation and situation dynamics. The keys to success of the Incremental V model are what happen at the control points. These are the formal mechanisms when management and development must jointly make explicit decisions to proceed to the next phase. Along with periodic management reviews and previews, these control points force the discussion of issues, risks, and alternatives. The meaning of each control point should be explicitly defined within the overall process. Behind such a high-level model are concrete plans based on rigorous estimates and well-defined milestones that lead down the path to success.

Object-Oriented Rapid Prototyping

It is normal to wonder why the subtle differences between the structured rapid prototyping, RAD, and spiral models matter - all three are user-involved, evolutionary approaches. The waterfall, V-shaped, and incremental models also have features in common, such as the entry and exit phase criteria. The spiral can be thought of as an overlay of incremental, with the addition of risk management. All the models have some kind of scoping, requirements gathering, designing, developing, testing, and implementation activities.

Actually, most life cycles are adaptations and combinations, and all software evolves. Commercial products are always evolving, and government and IT shops call the later evolutionary loops "maintenance".

The project manager should feel free to select and modify a software development life cycle to suit the project requirements, but he must also remember the importance of naming the phases and clearly demarking the transition from "developing" to "implementing". The importance of the implementation or deployment line is all about control and management. There is a need for every software product to be considered "in production" at some point in time, or customers don't know when to pay the bill, users have no assurance of when functionality is stable, and the project team will not be able to baseline the product for configuration management purposes.


software development, spiral model, milestones
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus