Software life cycle models

Software life cycle models

Software life cycle models is a process.

A process involves activities, constraints and resources that produce an intended output.

Each process activity, e.g., design,
must have entry and exit criteria—why?

A process uses resources, subject to constraints (e.g., a schedule or a budget)

A process is organized in some order or sequence, structuring activities as a whole

A process has a set of guiding principles or criteria that explain the goals of each activity

BUILD & FIX MODEL

Characteristics

1. Product is constructed without specifications or any attempt at design

2. Adhoc approach and not well defined

3. Simple two phase model

Drawbacks of build and fix model :-

·         Suitable for small programming exercises of 100 or 200 lines

·         Unsatisfactory for software for any reasonable size

·         Code soon becomes unfixable &unenhanceable

·         No room for structured design

·         Maintenance is practically not possible.

WATERFALL MODEL

Characteristics

·         This model is named “waterfall model” because its diagrammatic representation resembles a cascade of waterfalls.

·         This model is easy to understand and reinforces the notion of “define before design” and “design before code”.

·         The model expects complete & accurate requirements early in the process, which is unrealistic

Why would corporate manager types like the waterfall life cycle model?

·         Minimizes change, maximizes predictability

·         Costs and risks are more predictable

·         Each stage has milestones and deliverables:  project managers can use to gauge how close project is to completion

·         Sets up division of labor: many software shops associate different people with different stages:

1.      Systems analyst does analysis,

2.      Architect does design,

3.      Programmers code,

4.      Testers validate, etc.

Problems of waterfall model

1.      It is difficult to define all requirements at the beginning of a project

2.      This model is not suitable for accommodating any change

3.      A working version of the system is not seen until late in the project’s life

4.      It does not scale up well to large projects.

5.      Real projects are rarely sequential.

ITERATIVE MODEL

This model has the same phases as the waterfall model, but with fewer restrictions. Generally the phases occur in the same orderas in the waterfall model, but they may be conducted in several cycles.  Useable product is released at the end of the each cycle, with each release providing additional functionality.

Characteristics

·         Customers and developers specify as many requirements as possible and prepare a SRS document.

·         Developers and customers then prioritize these requirements

·         Developers implement the specified requirements in one or more cycles of design, implementation and test based on the defined priorities.

 

Drawbacks of iterative model

·         Each phase of an iteration is rigid with no overlaps

·         Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle

1.Requirements planning:- Requirements are captured using any group elicitation technique.

2. User description:-     Joint teams of developers and users are constituted to prepare, understand and review the requirements. The team may use automated tools to capture information from the other users

3. Construction:- This phase combines the detailed design, coding and testing phase of waterfall model. Here, we release the product to customers.

4. Cut over phase:- This phase incorporates acceptance testing by users, installation of the system , and user training.

Drawbacks of RAD model

·         Not an appropriate model in the absence of user participation.

·         Reusable components are required to reduce development time.

·         Highly specialized & skilled developers are required and such developers are not easily available.

PROTOTYPING MODEL

Introduction

This model adds prototyping as sub-process. A prototype is a partially developed product that enables customers and developers to examine some aspect of a proposed system and decide if it is suitable for a finished product.

Why add prototypes to the life cycle?

Used to explore the risky aspects of the system:

·         Risk of developing the “wrong” system (what customer doesn’t want), can be a user interface without functionality.

·         Other technical risks – e.g. performance, using a new technology, alternative algorithms, etc. Prototype may be thrown away or evolve into product.

Characteristics

The prototype may be a usable program but is not suitable as the final software product.

Ø  The code for the prototype is thrown away. However experience gathered helps in developing the actual system.

Ø  The development of a prototype might involve extra cost, but overall cost might turnout to be lower than that of an equivalent system developed using the waterfall model.

Evolutionary Process Models

Characteristics

Evolutionary process model resembles iterative enhancement  model. The same phases as defined for the waterfall model occur here in a cyclical fashion. This model differs from iterative enhancement model in the sense that this does not require a useable product at the end of each cycle. In evolutionary development, requirements are implemented by category rather than by priority.

This model is useful for projects using new technology that is not well understood. This is also used for complex projects where all functionality must be delivered at one time, but the requirements are unstable or not well understood at the beginning.

Applicability

·         For small or medium-size interactive systems;

·         For parts of large systems (e.g. the user interface);

·         For short-lifetime systems.

Evolutionary development

Drawbacks of evolutionary model

·         Lack of process visibility

·         Systems are often poorly structured

·         Special skills (e.g. in languages for rapid prototyping) may be required.

SPIRAL MODEL

Characteristics

·         Models do not deal with uncertainly which is inherent to software projects.

·         Important software projects have failed because project risks were neglected & nobody was prepared when something unforeseen happened.

·         Barry Boehm recognized this and tired to incorporate the “project risk”factor into a life cycle model.

·         The result is the spiral model, which was presented in 1986.

The radial dimension of the model represents the cumulative costs. Each path around the spiral is indicative of increased costs. The angular dimension represents the progress made in completing each cycle. Each loop of the spiral from X-axis clockwise through 360^o represents one phase. One phase is split roughly into four sectors of major activities.

1.      Planning: Determination of objectives, alternatives & constraints.

2.      Risk Analysis: Analyze alternatives and attempts to identify and resolve the risks involved.

3.      Development: Product development and testing product.

4.      Assessment: Customer evaluation

Advantages

·         An important feature of the spiral model is that each phase is completed with a review by the people concerned with the project (designers and programmers)

·         The advantage of this model is the wide range of options to accommodate the good features of other life cycle models.

·         It becomes equivalent to another life cycle model in appropriate situations.

Drawbacks of spiral model

The spiral model has some difficulties that need to be resolved before it can be a universally applied life cycle model. These difficulties include lack of explicit process guidance in determining objectives, constraints, alternatives; relying on risk assessment expertise; and provides more flexibility than required for many applications.

·         This model is the most costly model.

·         This model cannot be used for small projects.

V Model

The V-model represents a software development process (also applicable to hardware development) which may be considered an extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represents time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively.

Advantages :

·         supports flexibility and agility throughout the development process

·         it promotes meticulous design, development, and documentation necessary to build stable software products

·         Lately, it is being adopted by the medical device industry.

Drawbacks :

·         It lacks coherence and precision.

·         It is inflexible and encourages a rigid and linear view of software development and has no inherent ability to respond to change.