Lifecycles: Organizing Development Phases

Lifecycles: Organizing Development Phases

DOI: 10.4018/978-1-5225-5589-6.ch001
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This chapter discusses lifecycle model application for software development. It compares the benefits and shortcomings of different models. The authors argue that there is no universal lifecycle model. For agility, this chapter recommends combining prototyping with the other models. The authors suggest this to achieve a common understanding of the key product features and to reduce project risks. The lifecycle model choice determines project economics and time to market. The model also influences product quality and overall project success. However, product success essentially depends on human factors. The authors analyze the applicability of the lifecycle models to large-scale, mission-critical software systems. Finally, this chapter introduces a methodology. It includes a spiral-like lifecycle and a set of formal models and visual tools for software product development. This methodology helps to optimize the software product lifecycle. It fits large-scale, complex heterogeneous software products.
Chapter Preview
Top

Simple Lifecycles

One of the lifecycle models is the build-and-fix (see Figure 1). This is a model of an incomplete lifecycle. The build-and-fix is too simple for large-scale projects. Large-scale typically means above 100 KLOC; however, the authors recommend using this model for the projects below one KLOC. The build-and-fix model may be a possible option for a small-scale software solution. This downsized solution lacks agility. Therefore, it only applies for a very small product with clear requirements.

The other model the authors discuss here is rapid prototyping (see Figures. 4 and 5). It is also somewhat limited. The fact that it includes all the basic stages of the lifecycle does not change its limitations. These stages are the analysis and specification of requirements, preliminary and detailed design, implementation, unit testing, integration, product testing, maintenance, and retirement. The limit of rapid prototyping is lack of self-consistency. Actually, prototyping yields low quality code. It is true for both individual modules and the prototype as a whole. The prototype documentation is usually insufficient and incomplete. The resulting code differs from a software product. It only simulates the key functionality and certain aspects of the future software system of operational quality.

Figure 1.

Build-and-fix model

978-1-5225-5589-6.ch001.f01

Complete Chapter List

Search this Book:
Reset