Presentation on theme: "Software Life-Cycle Models"— Presentation transcript:
1Software Life-Cycle Models Life-cycle model (formerly, process model)The steps through which the product progressesRequirements phaseSpecification phaseDesign phaseImplementation phaseIntegration phaseMaintenance phaseRetirement
2Overview Build-and-fix model Waterfall model Rapid prototyping model Incremental modelExtreme programmingSynchronize-and-stabilize modelSpiral modelV modelObject-oriented life-cycle modelsComparison of life-cycle models
3Build and Fix ModelProduct is constructed with no specifications
4Build and Fix Model Problems Totally unsatisfactory No specificationsNo designTotally unsatisfactoryNeed life-cycle model“Game plan”PhasesMilestones
5Build and Fix Model Disadvantages Cost: changes are made in the later phases of software development life cycleMaintenance is difficult
6Waterfall ModelRequirements determined and checked by the client and SQA group.Specifications drawnSpecification checked by the SQA group and shown to the client.Sign off the specification document,Software project management plan - checked by SQA group
7Waterfall ModelDesign -“how to do”. If some problems in specification (Incomplete, contradictory and ambiguous.)Incomplete-: some features of the product have been omitted.Contradictory-: two or more statements in the specification document differ.Ambiguous-: the specification document has more than one possible interpretation.
8Waterfall Model Implementation: If flaws-- Feedback loops permits modification to be made to design document, specification document and requirement if needed.Documentation :No phase without documentationAlso approved by SQA group.
9Waterfall ModelAcceptance Testing: when the product is completed it is given to the client for testing. Deliverables at this stage include the user manual and other documentation listed in the contract. When the client agrees that that the product is as per the specification document, the product is installed on the client’s machine.InstallationMaintenance- changes made after the installation of the product are handled in this phase.
10Waterfall Model (contd) Characterized byFeedback loopsDocumentation-drivenAdvantagesEnforce the documentation after every phaseProducts of each phase checked by SQA.Testing is Inherent in every phaseDynamic model-feedback loopsMaintenance easier
11Waterfall Model (contd) DisadvantagesSpecification documents are long, detailed and very boring to read.Client is inexperienced in reading software specification document because the specification document is written in the style client won’t understand.The first time the client see a working product is only after the entire product has been coded.
12Rapid Prototyping Model Build a rapid prototypeThe client and future users interact and experiment with it.Once the client is satisfied, the developer can draw up specification document.The feedback loops are not required in this model as the working prototype has been validated by the client, it is reasonable to expect that the resulting specification document will be correct..
13Rapid Prototyping Model In the rapid prototyping model, the fact that a preliminary working model has been built tends to lessen the need to repair the design during or after the implementation.
14Rapid Prototyping Model Construct the prototype as rapidly as possibleThe developers should develop the rapid prototype as rapidly as possible the speed up the software development process.Use of rapid prototype - determine what the client’s real needs are;Rapid prototype implementation is discardedInternal structure of rapid prototype is not relevant.Prototype is modified rapidly to reflect client need.
15Waterfall and Rapid Prototyping Models Waterfall modelMany successesClient needsRapid prototyping modelNot provedHas own problemsSolutionRapid prototyping for requirements phaseWaterfall for rest of life cycle
16Rapid Prototyping Model AdvantagesAs compared to waterfall model –Development of the process is linear preceding from rapid prototype to delivered product.Feedback loops are less likely to be (needed) in this case.
17Rapid Prototyping Model DisadvantagesIf user cannot be involved throughout the life cycle this model is not useful.Development time may not be reduced if reusable components are not available.Highly specialized and skilled developers are expected and such developers may not be available easily.Client expects changes to made as rapidly as the rapid prototype
18Incremental ModelThe product is designed, implemented, integrated and tested as a series of incremental builds, where a build consist of code pieces from various modules interacting to provide a specific functional capability.
19Incremental ModelAt each stage- a new build is coded and then integrated and tested as a whole.Break up the target product into builds subject to constraint that each build is integrated into existing software, the resulting product must be testable.
20Incremental ModelIf a product has too many builds, then at each stage, considerable time is spent in the integration testing of only a small amount of additional functionality. On the other hand, if a product has too few build then the incremental model degenerated into build and fix model.Analysis –In waterfall and rapid prototyping model –deliver to client a complete productThere is project delivery dateIncremented Model – It deliver an operational quality product at each stage
21Incremental Model (contd) AdvantagesGradual introduction of the product via this model provides time for the client to adjust to the new product.Change and Adoptions are natural
22Incremental Model (contd) DisadvantagesEach additional build has to be incorporated into existing structure without destroying what has been made till date.Addition of new build should be simple and straightforward.Incremental model does not distinguish between developing a product and maintaining it.Begin with a design that support entire productView product as a sequence of builds, each independent of next.
23Incremental Model (contd) More risky concurrent version—pieces may not fit
24Extreme Programming Somewhat controversial new approach Software development team determines the various features (Stories)Estimate duration and cost of each featureClient select features for next build using cost benefit analysisEach build is divided into tasksTest cases for task are drawn up firstPair programming (working with a partner on one screen)Continuous integration of tasks
25Extreme ProgrammingTasks are integrated into the current version of the productTest cases used for the tasks are retained and utilized in all further integration testing
26Unusual Features of XPComputers are put in center of large room lined with small cubiclesClient representative is always presentNo individual can work overtime for 2 successive weeksNo specialization. All members of XP team work on specifications, design, code and testingThere is no overall design is modified while the product is being built. The design is modified while product is being built. This procedure is known as refactoring
27Evaluating XPXP has had some successes on small and medium sized projectsGood when requirements are vague or changingToo soon to evaluate XP
28Synchronize-and Stabilize Model Microsoft’s life-cycle modelRequirements analysis—interview potential customers and extract a list of features with priorities set up by the customersDraw up specificationsDivide project into 3 or 4 buildsFirst build consists of the most critical features, the second build consists of the next most critical features and so on.Each build is carried out by small teams working in parallel
29Synchronize-and Stabilize Model (contd) At the end of the day all the teams—put together the partially completed components and synchronize (test and debug)At the end of the build—stabilize (freeze build i.e. any remaining faults that have been detected are fixed).Repeated synchronization steps ensure that the components always work togetherDevelopers get early insights into operation of product and can modify the requirements
30Spiral Model Simplified form Precede each phase by Waterfall model plus risk analysisPrecede each phase byAlternativesRisk analysisFollow each phase byEvaluationPlanning of next phase
31Simplified Spiral Model If risks cannot be resolved, project is immediately terminatedPrototypes can be effectively used to provide information about certain classes of risks
32Full Spiral ModelRepresents cumulative cost to date and progress through the spiralEach cycle of the spiral corresponds to a phasePhase begins by determining objectives of that phase, alternatives for achieving those objectives, and constraints imposed on these alternativesStrategy is analyzed from view point of riskIf all risks are successfully resolved development startsThen the results of the phase are evaluated
34Analysis of Spiral Model StrengthsIncorporation of software qualityEasy to judge how much to test as risks for too much and too low testing are analyzedNo distinction between development, maintenance i.e. maintenance is treated same way as developmentWeaknessesFor large-scale software only. In case of contract all risk analysis should be made before the contract is signed.Skilled developers are required for analyzing and detecting potential risksFor internal (in-house) software only
35Object-Oriented Life-Cycle Models Need for iteration within and between phasesFountain modelRecursive/parallel life cycleRound-trip gestaltUnified software development processAll incorporate some form ofIterationParallelismIncremental development
36Fountain Model Features Overlap (parallelism) Arrows (iteration) Smaller maintenance circle
40Conclusions Different life-cycle models Each with own strengths Each with own weaknessesCriteria for deciding on a model includeThe organizationIts managementSkills of the employeesThe nature of the productBest suggestion“Mix-and-match” life-cycle model
41Conclusions Life cycle model Strengths Weaknesses Build and fix Fine for short programs that will not require any maintenanceTotally unsatisfactory for nontrivial programsWaterfall modelDisciplined approachDocument drivenDelivered product may not meet client’s needsRapid prototype modelEnsure that delivered product meets client’s needsNot yet proven beyond all doubtIncremental modelMaximizes early return on investmentPromotes maintainabilityRequires open architectureMay degenerate into build-and-fix
42Conclusions Life cycle model Strengths Weaknesses Extreme programming Maximizes early return on investmentWorks well when client’s requirement are vagueHas not yet been widely usedSynchronize and stablize modelFuture user’s needs are metEnsures components can be successfully integratedHas not been widely used other than MicrosoftSpiral modelIncorporates features of all the modelsCan be used only for large scale in-house productsDevelopers have to be competent in risk analysis and risk resolution
43Conclusions Life cycle model Strengths Weaknesses V shaped model Incorporates testing at each phaseUsable product will be deliver very lateObject-oriented modelsSupport iteration within phases, parallelism between phasesMay degenerate into code a bit test a bit (CABTAB)