all models of sdlcs
DESCRIPTION
sdlcTRANSCRIPT
Adapted from a presentation by John Petlicki of DePaul University, USA
OverviewSDLC ModelWaterfall ModelV-Shaped ModelPrototypingRapid Application DevelopmentSpiral ModelConclusion
SDLC Model A framework that describes the activities
performed at each stage of a software development project.
Waterfall ModelRequirements – defines
needed information, function, behavior, performance and interfaces.
Design – data structures, software architecture, interface representations, algorithmic details.
Implementation – source code, database, user documentation, testing.
Waterfall ModelTest – check if all code
modules work together and if the system as a whole behaves as per the specifications.
Installation – deployment of system, user-training.
Maintenance – bug fixes, added functionality (an on-going process).
Waterfall StrengthsEasy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodSets requirements stabilityGood for management control (plan, staff,
track)
Waterfall DeficienciesAll requirements must be known upfrontDeliverables created for each phase are
considered frozen – inhibits flexibilityDoes not reflect problem-solving nature of
software development – iterations of phases
Integration is one big bang at the endLittle opportunity for customer to preview
the system (until it may be too late)
When to use the Waterfall ModelRequirements are very well knownWhen it is possible to produce a stable
designE.g. a new version of an existing productE.g. porting an existing product to a new
platform.
V-Shaped SDLC ModelA variant of the
Waterfall that emphasizes the verification and validation of the product.
Testing of the product is planned in parallel with a corresponding phase of development
V-Shaped Steps Project and Requirements
Planning – allocate resources
Product Requirements and Specification Analysis – complete specification of the software system
Architecture or High-Level Design – defines how software functions fulfill the design
Detailed Design – develop algorithms for each architectural component
Coding – transform algorithms into software
Unit testing – check that each module acts as expected
Integration and Testing – check that modules interconnect correctly
System and acceptance testing – check the entire software system in its environment
Production, operation and maintenance – provide for enhancement and corrections
V-Shaped StrengthsEmphasize planning for verification and
validation of the product in early stages of product development
Each deliverable must be testableProject management can track progress by
milestonesEasy to use
V-Shaped WeaknessesDoes not easily handle concurrent eventsDoes not handle iterations or phasesDoes not easily handle dynamic changes in
requirements
When to use the V-Shaped ModelExcellent choice for systems requiring high
reliability – hospital patient control applications
All requirements are known up-frontWhen design is stable Solution and technology are known
Prototyping ModelDevelopers build a prototype during the
requirements phasePrototype is evaluated by end usersUsers give corrective feedback Developers further refine the prototypeWhen the user is satisfied, the prototype code
is brought up to the standards needed for a final product.
Prototyping StepsA preliminary project plan is developedAn partial high-level paper model is createdThe model is source for a partial requirements
specificationA prototype is built with basic and critical
functionsThe designer builds
the database user interface algorithmic functions
The designer demonstrates the prototype, the user evaluates for problems and suggests improvements.
This loop continues until the user is satisfied
Prototyping Strengths
Customers can “see” the system requirements as they are being gathered
Developers learn from customers A more accurate end productUnexpected requirements accommodatedAllows for flexible design and developmentSteady, visible signs of progress producedInteraction with the prototype stimulates
awareness of additional needed functionality
Prototyping WeaknessesTendency to abandon structured program
development for “code-and-fix” development
Bad reputation for “quick-and-dirty” methods
Overall maintainability may be overlookedProcess may continue forever (scope
creep)
When to use PrototypingRequirements are unstable or have to be
clarified As the requirements clarification stage of
a waterfall modelDevelop user interfacesNew, original development
Rapid Application Development Model (RAD)Requirements planning phase (a workshop
utilizing structured discussion of business problems)
User design phase – users to participate in the nontechnical design of the system
Construction phase – productivity tools, such as code generators, screen generators.
Cutover phase -- installation of the system, user acceptance testing and user training
Rapid Application Development Model (RAD)
Requirements planning phase
User design phase
Construction phase
Cutover phase
Pro
totyp
ing
RAD StrengthsReduced cycle time and improved
productivity with fewer people means lower costs
Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
Focus moves from documentation to codeUses modeling concepts to capture
information about business, data, and processes.
RAD WeaknessesAccelerated development process must give
quick responses to the userRisk of never achieving closure Hard to use with legacy systemsRequires a system that can be modularizedDevelopers and customers must be committed to
rapid-fire activities in an abbreviated time frame. May compromises functionality and performance
in exchange for faster development and better application maintenance
When to use RADWhen requirements are not fully understood.User involved throughout the life cycleFunctionality delivered in incrementsHigh performance not requiredSystem can be modularized
Incremental SDLC ModelConstruct a partial
implementation of a total system
Then slowly add increased functionality
The incremental model prioritizes requirements of the system and then implements them in groups.
Each subsequent release of the system adds functions to the previous release, until all designed functionality has been implemented.
Incremental Model Strengths Develop high-risk or major functions firstEach release delivers an operational product Customer can respond to each buildUses “divide and conquer” breakdown of
tasksLowers initial delivery cost Initial product delivery is fasterCustomers get important functionality early
Incremental Model Weaknesses Requires good planning and designRequires early definition of a complete and
fully functional system to allow for the definition of increments
Well-defined module interfaces are required (some will be developed long before others)
Total cost of the complete system is not lower
When to use the Incremental Model Most of the requirements are known up-
front but are expected to evolve over timeA need to get basic functionality to the
market earlyOn projects which have lengthy
development schedules
Spiral SDLC ModelAdds risk analysis,
and 4gl RAD prototyping to the waterfall model
Each cycle involves the same sequence of steps as the waterfall process model
Spiral QuadrantDetermine objectives, alternatives and constraints
Objectives: functionality, performance, hardware/software interface, critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.Constraints: cost, schedule, man-power,
experience etc.
Spiral QuadrantEvaluate alternatives, identify and resolve risks Study alternatives relative to objectives and
constraintsIdentify risks (lack of experience, new
technology, tight schedules, etc.)Resolve risks
Spiral QuadrantDevelop next-level productTypical activites:
Create a designReview designDevelop codeInspect codeTest product
Spiral QuadrantPlan next phaseTypical activities
Develop project planDevelop a test planDevelop an installation plan
Spiral Model StrengthsProvides early indication of
insurmountable risks, without much costUsers see the system early because of
rapid prototyping toolsCritical high-risk functions are developed
firstUsers can be closely tied to all lifecycle
stepsEarly and frequent feedback from users
Spiral Model WeaknessesTime spent for evaluating risks too large
for small or low-risk projectsTime spent planning, resetting objectives,
doing risk analysis and prototyping may be excessive
The model is complex Risk assessment expertise is requiredSpiral may continue indefinitelyDevelopers must be reassigned during
non-development phase activities
When to use Spiral ModelWhen creation of a prototype is
appropriateWhen costs and risk evaluation is
importantFor medium to high-risk projectsUsers are unsure of their needsRequirements are complexNew product line Significant changes are expected
Tailored SDLC ModelsNo single model fits all projectsIf there is no suitable model for a
particular project, pick a model that comes close and modify it for your needs.If project should consider risk but complete
spiral model is too much – start with spiral and simplify it
If project should be delivered in increments but there are serious reliability issues – combine incremental model with the V-shaped model
Each team must pick or customize a SDLC model to fit its project
Quality – the degree to which the software satisfies stated and implied requirementsAbsence of system crashesCorrespondence between the software and the
users’ expectationsAdherence to specified requirements
Quality must be controlled because it lowers production speed, increases maintenance costs and can adversely affect business
the good enough is enemy of the excellent
Quality Assurance PlanThe plan for quality assurance activities should
be in writing so all stakeholders can review it during the lifecycle.
Some elements that should be considered by the plan are: defect tracking, unit testing, source-code tracking, integration testing and system testing.
Quality Assurance PlanDefect tracing – keeps track of each defect found,
its source, when it was detected, when it was resolved, how it was resolved, etc
Unit testing – each individual module is testedSource code tracing – step through source code
line by lineIntegration testing - test new code in
combination with code that already has been integrated
System testing – execution of the software for the purpose of finding defects.
ConclusionSDLC
A framework that describes the activities performed at each stage of a software development project.
Waterfall and V-Shaped and Incremental models need requirements to be known up-front.E.g. when creating new versions of existing systems.
Prototyping, RAD and Spiral models do not need all requirements to be knownE.g. New systems. Uses series of prototypes that evolve into the
finished system.
Referenceshttp://condor.depaul.edu/~jpetlick/extra/
394/Session2.ppt