Embed Size (px)
Citation preview
SDLC Concepts
IVS Task Group
SDLC – A Brief Introduction
SDLC – A BRIEF INTRODUCTIONIVS-TRAINING
Ground Rules
Please mute your mobile phones
Stick to timeliness
Help each other in learning – as learning is a continuous process
Please participate actively to make the session interactive:
Session Objectives
Life Cycle of Software Development.
Models of SDLC
Concepts of various models of SDLC
At the End of Session you would be able to:
What is SDLC?
Various SDLC Models.
Difference between SDLC and Exploratory models.
Contents Product, Process and Methods
Methodologies followed in late 60’s for software Development
What is SDLC?
SDLC Models
Classifications of SDLC Model
Sequential Model
Progressive Model
Iterative Model
Spiral model
Other Models
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.
involves all of: communication (internal and external) , standards (definition and adherence) , planning and monitoring , tools and methodologies , quality assurance
Role of Processes
Increasingly, software suppliers recognize that software development process capability is a key source of competitive advantage.
Competition forces suppliers to improve processes to meet the conflicting demands of higher quality, lower cost, and compressed schedules.
Method
Methods provides the technical “how to’s” for building software
SDLC Concepts
IVS Task Group
Methodologies followed in late 60’s for software Development
Methodologies followed in late 60’s for software Development
Methodologies followed in late 60’s 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 crisisSoftware 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.
Some Root Causes for Failure
Inaccurate understanding of end-user-needs
Ad hoc requirements management
Ambiguous and imprecise communication
Overwhelming complexity
Undetected inconsistencies in requirements, design and implementations
Insufficient testing resulting in late discovery of serious flaws
Poor software quality
Failure to attack risk
Insufficient use of automation tools
SDLC Concepts
IVS Task Group
Software Development Life Cycle (SDLC)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 Concepts
IVS Task Group
SDLC - ModelsSDLC - Models
SDLC Models
There are a number of different models for software development lifecycles which explains the series of steps through which the product progresses.
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 Iterative
WaterfallV Model
Progressive
Spiral Incremental
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.
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.
Note: 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.
a. V Model
Requirement Specifications
System Testing
High Level Design
IntegrationTesting
Detail Design
ProgramSpecification
Unit Testing
User AcceptanceTesting
Coding
b. Waterfall Model
Requirements Specification
Architectural Design
Detailed Design
Code and Unit Testing
Software Integration
System Integration
Acceptance Testing
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 don’t meet customers needs
Assumes feasibility before implementation
re-design is problematic
works best when you know what you’re 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
Phase 2 Development
Final Phase
Interim Delivery 1
Interim Delivery 2
Final Delivery 2
3. Iterative Model
Requirements Design
Implementation and Test
Review
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
Prototyping Model
Rapid Application Development Model
Lifecycle Models
Build-and-fix
develop system
without specs or design
modify until customer is satisfied
Why doesn’t build-and-fix scale?
changes during maintenance
most expensive!
Relative Costs of Phases
Maintenance (67%)Requirements (2%)
Specification (5%)
Design (6%)
Module coding (5%)
Module testing (7%)Integration (8%)
Incremental Model
Divide project into builds
each adds new functions
each build integrated w/ structure & product tested as a whole
Advantages ?
operation product in weeks
less traumatic to organization
smaller capital outlay
Disadvantages ?
need an open architecture
a big advantage come maintenance!
too few builds build-and-fix
too many builds overhead
Development
Maintenance
Verify
Requirements
phase
Verify
Specification
phase
Verify
Architectural design
Operations mode
Retirement
Perform detailed design, imple-mentation, and integration. Test.
Deliver to client.
For each build:
Differences Between the Exploratory Style and Modern Software Development Practices
Exploratory Style
Software developed on Trail and Error basis
Emphasis on Error correction
Errors detected only during testing
Emphasis only on coding during the entire development cycle
Review at the end of the development phase
No specific testing process
Less attention was being given to producing good quality and consistent documents
Inefficient planning
Modern Software Development Use of Life Cycle Models resulting in
software development through several well-defined stages
Emphasis on detection of errors as close to their point of introduction as possible.
Errors detected in each phase of development
The entire development cycle is divided into distinct phases
Periodic reviews during each phase of development cycle
Software testing has become systematic Better visibility of design and code resulting
in production of good quality and consistent and standard documents
Thorough planning in terms of
estimation
scheduling
monitoring mechanisms
Questions?
Thank You!!
IVS-TRAINING
Any doubts or suggestions for improvement can be forwarded to: [email protected]
