SDLC A Brief Introduction

Contents

Product, Process and Methods Methodologies followed in late 60s for software Development What is SDLC?

SDLC Models
Classifications of SDLC Model

Sequential Model

Progressive Model
Iterative Model Spiral model

Lifecycle Models

Incremental Model
Differences between Exploratory & SDLC Models

Product, Process and Methods

Product includes some of: hardware , software , documentation , installation, etc. Process
Process

defines a framework for a set of key process areas that must be established for effective delivery of software engineering technology. all of: communication (internal and external) , standards (definition and adherence) , planning and monitoring , tools and methodologies , quality assurance

involves

Role of Processes
Increasingly, software

suppliers recognize that software development process capability is a key source of competitive advantage. forces suppliers to improve processes to meet the conflicting demands of higher quality, lower cost, and compressed schedules.

Competition

Method
Methods

provides the technical how tos for building software

Methodologies followed in late 60s for software Development

Methodologies followed in late 60s for software Development

The Software was developed on a Trial & Error basis. No Specific Process was followed during the development of the Product. Defects were detected only after the product is delivered to the external Users. This resulted in software crisis Software fail to meet user requirements.

Softwares used to crash frequently. Development of Software became expensive. Software became difficult to alter, debug, and enhance. The Software was often delivered late. Software use resources non-optimally.

Common Symptoms of Failed Software Development Projects

Inaccurate understanding of end-user-needs Inability to deal with changing requirements

Modules that do not fit together

Software that is too hard to maintain or extend Late discovery of serious flaws Poor software quality Unacceptable software performance

Some Root Causes for Failure

Ad hoc requirements management Ambiguous and imprecise communication

Overwhelming complexity
Undetected inconsistencies in requirements, design and implementations Insufficient testing Failure to attack risk Insufficient use of automation tools

Software Development Life Cycle (SDLC)

What is SDLC ?

The various activities which are undertaken when developing software are commonly modeled as a software development lifecycle. The software development lifecycle begins with the identification of a requirement for software and ends with the formal verification of the developed software against that requirement. The software development lifecycle does not exist by itself, it is in fact part of an overall product lifecycle.

Within the product lifecycle, software will undergo maintenance to correct errors and to comply with changes to requirements.
The simplest overall form is where the product is just software, but it can become much more complicated, with multiple software developments each forming part of an overall system to comprise a product.

SDLC - Models

Software Life-Cycle Model

Definition

The series of steps through which the product progresses

The models specifies

the various phases of the process

e.g., requirements, specification, design

the order in which they are carried out

SDLC Models

There are a number of different models for software development lifecycles. Life cycle models describe the interrelationships between software development phases. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. Typically, a life cycle model addresses the following phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance.

Importance of Lifecycle Models

Provide guidance for project management

what major tasks should be tackled next? milestones! what kind of progress has been made?

The necessity of lifecycle models

character of software development has changed

early days: programmers were the primary users

modest designs; potential of software unknown

more complex systems attempted

more features, more sophistication greater complexity, more chances for error

heterogeneous users

Classifications of SDLC Model

SDLC Model

Sequential

Progressive

Iterative

V Model

Waterfall

1. Sequential Model

The models used for the software development lifecycle have been sequential, with the development progressing through a number of well defined phases.

The sequential phases are usually represented

V Model Waterfall Model.

a. V Model
Requirement Specifications User Acceptance Testing

High Level Design

System Testing

Detail Design

Integration Testing

Program Specification

Unit Testing

Coding

b. Waterfall Model

Requirements Specification Architectural Design Detailed Design Code and Unit Testing Software Integration System Integration Acceptance Testing

Different Phases of Sequential Model :

Requirements phase - in which the requirements for the software are gathered and analyzed, to produce a complete and unambiguous specification of what the software is required to do Detailed Design phase - where the detailed implementation of each component is specified. Code and Unit Test phase - in which each component of the software is coded and tested to verify that it faithfully implements the detailed design. Software Integration phase - in which progressively larger groups of tested software components are integrated and tested until the software works as a whole.

System Integration phase - in which the software is integrated to the overall product and tested.
Acceptance Testing phase, where tests are applied and witnessed to validate that the software faithfully implements the specified requirements. Software specifications will be products of the first three phases of this lifecycle model. The remaining four phases all involve testing the software at various levels, requiring test specifications against which the testing will be conducted as an input to each of these phases.

Advantages of Waterfall Model

Enforced discipline through documents

no phase is complete until the docs are done & checked by SQA group concrete evidence of progress

Testing is inherent in every phase

continuously as well as at end of phases

Verification of the Software is easy.

Drawbacks of Waterfall Model

Document-driven model

customers cannot understand these

imagine an architect just showing you a textual spec!

first time client sees a working product is after it has been coded. Problem here?

leads to products that dont meet customers needs

Assumes feasibility before implementation

re-design is problematic works best when you know what youre doing

when requirements are stable & problem is well-known

2. Progressive Model

A common problem with software development is that software is needed quickly, but it will take a long time to fully develop. The solution is to form a compromise between timescales and functionality, providing "interim" deliveries of software, with reduced functionality, but serving as a stepping stones towards the fully functional software. It is also possible to use such a stepping stone approach as a means of reducing risk. The usual names given to this approach to software development are progressive development or phased implementation. Within a progressive development lifecycle, each individual phase of development will follow its own software development lifecycle, typically using a V or waterfall model.

2. Progressive Model - Structure

Phase 1 Development

Interim Delivery 1

Phase 2 Development

Interim Delivery 2

Final Phase

Final Delivery 2

3. Iterative Model

Requirements

Design

Review

Implementation and Test

An iterative lifecycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

3. Iterative Model - Phases

Requirements phase, in which the requirements for the software are gathered and analyzed. Iteration should eventually result in a requirements phase which produces a complete and final specification of requirements.

Design phase, in which a software solution to meet the requirements is designed. This may be a new design, or an extension of an earlier design.
Implementation and Test phase, when the software is coded, integrated and tested.

Review phase - in which the software is evaluated, the current requirements are reviewed, and changes and additions to requirements proposed

3. Spiral model

The Spiral Model - an iterative (evolutionary) system development life cycle developed by Boehm (1988) which incorporates risk assessment. Developed in recognition of the fact that systems development projects tend to repeat the stages of analysis, design and code as part of the prototyping process. Model closely related to RAD, as it implies iterative development with a review possible after each iteration or spiral - which corresponds to the production of one prototype or incremental version. Spiral model includes best features of both the classic Waterfall SDLC and the Prototyping approach.

Spiral model contd

Each spiral consists of four main activities: Planning: setting project objectives; defining alternatives; further planning on the next spiral; etc. Risk Analysis: analysis of alternatives & the identification & solution of risks. Development: designing, coding and testing etc. in increments. Evaluation: user evaluation of each spiral and then the final product.

Other SDLC Models Used

Build and fix Model Incremental Model

Lifecycle Models

Build-and-fix

develop system

without specs or design

modify until customer is satisfied

Why doesnt build-and-fix scale?

changes during maintenance

Relative Costs of Phases

Integration (8%) Module testing (7%)

most expensive!

Module coding (5%) Design (6%)

Specification (5%) Requirements (2%)

Maintenance (67%)

Incremental Model

Requirements phase Verify

Divide project into builds

each adds new functions each build integrated w/ structure & product tested as a whole

Specification phase Verify

Advantages ?

Architectural design Verify

operation product in weeks less traumatic to organization smaller capital outlay

For each build: Perform detailed design, implementation, and integration. Test. Deliver to client.

Disadvantages ?

need an open architecture

a big advantage come maintenance!

Operations mode Development Retirement

too few builds build-and-fix too many builds overhead

Maintenance

Differences Between the Exploratory Style and Modern Software Development Practices

Use of Life Cycle Models Software is developed through several well-defined stages:

Emphasis has shifted

from error correction to error prevention.

Modern practices emphasize:

detection of

errors as close to their point of introduction as possible. In exploratory style, errors are detected only during testing, Now, focus is on detecting as many errors as possible in each phase of development.

Differences Between the Exploratory Style and Modern Software Development Practicescontinued

In exploratory style, coding is synonymous with program development. Now, coding is considered only a small part of program development effort.

A lot of effort and attention is now being paid to:

requirements

specification.

Also, now there is a distinct design phase:

standard

design techniques are being used.

reviews are being carried out testing techniques are available.

During all stages of development process:

Periodic

Software testing has become systematic:

standard

Differences Between the Exploratory Style and Modern Software Development Practices continued

There is better visibility of design and code: visibility means production of good quality, consistent and standard documents. In the past, very little attention was being given to producing good quality and consistent documents. We will see later that increased visibility makes software project management easier. Because of good documentation:
fault

diagnosis and maintenance are smoother now. in software project management, quality assurance, etc.

Several metrics are being used:

help

Projects are being thoroughly planned:

estimation, scheduling, monitoring

mechanisms.

Q&A

Thank You