SDLC

Kamalapriya D

SDLC


SDLC stands for

Software Development Life Cycle

SDLC


SDLC stands for

Software Development Life Cycle First, SDLC is a Life Cycle. Cycle. All systems have a life cycle or a series of stages they naturally undergo.
 

The number and name of the stages varies, but the primary stages are conception, development, maturity and decline. development, The Software development life cycle (SDLC) therefore, refers to the development stage of the system s life cycle. cycle.

Software Development Life Cycle



Every textbook has different names for the stages of the SDLC
Usually they stages are
Planning (just after Conception)  Analysis  Design  Implementation  Maintenance (starting Maturity)


1.4

Software Development Life Cycle



This text highlights 6 distinct phases:

Project Identification and Selection Project Initiation and Planning Analysis Design Implementation Maintenance

Stages of the SDLC

Phases of the Software Development Life Cycle

1.

Project Identification and Selection

Two Main Activities
 

Identification of need Prioritization and translation of need into a development schedule

Helps organization to determine whether or not resources should be dedicated to a project.

2.

Project Initiation and Planning

Two Activities
 

Formal preliminary investigation of the problem at hand Presentation of reasons why system should or should not be developed by the organization

Software Development Life Cycle



Analysis
Study of current procedures and information systems


Determine requirements
Study current system Structure requirements and eliminate redundancies

Generate alternative designs  Compare alternatives  Recommend best alternative



Software Development Life Cycle



Design
Logical Design


Concentrates on business aspects of the system Technical specifications

Physical Design


Implementation
Implementation
   

Hardware and software installation Programming User Training Documentation

Software Development Life Cycle



Maintenance
System changed to reflect changing conditions  System obsolescence


A good way to learn the stages of the SDLC is to create deliverables (output) of each stage in the process.

Life Cycle Models (SDLC)

 

A Life Cycle model describes how the phases combine together to form a complete project. Some of the common life cycle models that are used in the software projects include

Waterfall model Spiral or Iterative Model V Model Prototype RAD Incremental

Waterfall Model:
Overall business requirements Software requirements

Planning

High-level design

Low-level design

Coding

Testing

Waterfall model Contd..

A Waterfall model is characterized by three attributes: The project is divided into separate, distinct phases Each phase communicates to the next through pre-specified outputs pre When an error is detected, it is traced back to one previous phase at a time until it gets resolved at some earlier phase This model is useful when all the requirements are clear for the system development and very clearly demarcated phases are present Applicable when deliverables of each phase can be frozen before proceeding to the next phase The major drawback in this model arises from the delay in feedback among the phases, and thus the ineffectiveness of verification and validation activities.

Waterfall Strengths
    

Easy to understand, easy to use understand, Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

Waterfall Deficiencies
     

All requirements must be known upfront Deliverables created for each phase are considered frozen inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of problemsoftware development iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

Spiral Model or Iterative Model

Spiral or Iterative Model Contd..



The Spiral model is a software development model combining elements of both design and prototyping-in-stages, so it's a healthy mix of top-down and prototyping-intopbottombottom-up concepts The spiral model was defined by Barry Boehm. This model was not the first Boehm. model to discuss iteration, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long Each phase starts with a design goal (such as a user interface prototype as an early phase) and ends with the client (which may be internal) reviewing the progress thus far Analysis and engineering efforts are applied to each phase of the project, with an eye toward the end goal of the project

V Model
Overall Business Requirements Acceptance test design Acceptance Testing System Testing design

Software requirements

Integration Testing in the Large

High-level design

Integration test design

System Testing

Low-level design

Component test design

Integration Testing in the Small

Coding Design Tests

Unit test design

Unit Testing Run Tests

V model


V- model is a process where the development and testing phases can do parallely. parallely. Test design is done early while test execution is done in the end. There are different types of tests for each phase of the life cycle. Development phases are called as verification whereas testing phases are called as validation Verification means the software implements correctly or not. Validation means the software that has been built is traceable to the customer requirements or not. Left hand side of the V model contains SDLC in downhill direction whereas right hand side of the V model contains STLC in uphill direction

V model Contd..


Applicable when design of tests can be separated from the actual execution Verification - It is the activity, which ensures the work products of a given phase fully implement the inputs to that phase, or "the product is built right Validation - In its simplest terms, is the demonstration that the software implements each of the software requirements correctly and completely. In other words, the "right product is built "

Structured Evolutionary Prototyping Model



  

Developers build a prototype during the requirements phase Prototype is evaluated by end users Users give corrective feedback Developers further refine the prototype When the user is satisfied, the satisfied, prototype code is brought up to the standards needed for a final product.

Structured Evolutionary Prototyping Steps

    

A preliminary project plan is developed An partial high-level paper model is created highThe model is source for a partial requirements specification A prototype is built with basic and critical attributes The designer builds
the database user interface algorithmic functions

The designer demonstrates the prototype, the user prototype, evaluates for problems and suggests improvements. This loop continues until the user is satisfied

Structured Evolutionary Prototyping Strengths

      

Customers can see the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality

Structured Evolutionary Prototyping Weaknesses



 

Tendency to abandon structured program development for code-and-fix code-anddevelopment Bad reputation for quick-and-dirty quick-andmethods Overall maintainability may be overlooked The customer may want the prototype delivered. delivered. Process may continue forever (scope creep)

When to use Structured Evolutionary Prototyping



   

Requirements are unstable or have to be clarified As the requirements clarification stage of a waterfall model Develop user interfaces ShortShort-lived demonstrations New, original development With the analysis and design portions of objectobject-oriented development. development.

Rapid Application Model (RAD)



 

Requirements planning phase (a workshop utilizing structured discussion of business problems) User description phase automated tools capture information from users Construction phase productivity tools, such as code generators, screen generators, etc. inside a time-box. ( Do until done ) timeCutover phase -- installation of the system, user acceptance testing and user training

RAD Strengths


 

 

Reduced cycle time and improved productivity with fewer people means lower costs TimeTime-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code (WYSIWYG). WYSIWYG). Uses modeling concepts to capture information about business, data, and processes.

RAD Weaknesses
    

Accelerated development process must give quick responses to the user Risk of never achieving closure Hard to use with legacy systems Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an rapidabbreviated time frame.

When to use RAD

      

Reasonably well-known requirements wellUser involved throughout the life cycle Project can be time-boxed timeFunctionality delivered in increments High performance not required Low technical risks System can be modularized

Any Q s??