Lecture 3: Software Life CyclesKenneth M. AndersonFoundations of Software EngineeringCSCI 5828 - Spring Semester, 2000January 25, 2000 © Kenneth M. Anderson, 2000 2Today’s Lecture• Briefly Review Software Life Cycles• Discuss problems associated with themJanuary 25, 2000 © Kenneth M. Anderson, 2000 3Software Life Cycle• A series of steps that organizes thedevelopment of a software product• Duration can be from days to years• Consists of– people!– overall process– intermediate products– stages of the processJanuary 25, 2000 © Kenneth M. Anderson, 2000 4Software Artifacts• Intermediate Software Products– Demarcate end of phases– Enable effective reviews– Specify requirements for next phase• Form– Rigorous– Machine processible (highly desirable)• Content– Specifications, Tests, DocumentationJanuary 25, 2000 © Kenneth M. Anderson, 2000 5Example Artifacts• Options Document– Problem Definition– Potential Solutions– Proposed System• Cost-Benefit Analysis– Benefits• Achievable Goals– Costs• Development & Maint.– Analysis• Net improvement• Requirements– Boilerplate– Project scope– Project history– Current System– New System– Requirements• Preliminary Plan– Statement of WorkMgmt, Docs, Testing Plans– SchedulesJanuary 25, 2000 © Kenneth M. Anderson, 2000 6Phases of a Software Life Cycle• Standard Phases– Requirements Analysis & Specification– Design– Implementation and Integration– Operation and Maintenance– Change in Requirements– Testing throughout!• Phases promote manageability and provideorganizationJanuary 25, 2000 © Kenneth M. Anderson, 2000 7Requirements Analysis andSpecification• Problem Definition —> Requirements Specification– determine exactly what client wants and identify constraints– develop a contract with client– Specify the product’s task explicitly• Difficulties– client asks for wrong product– client is computer/software illiterate– specifications may be ambiguous, inconsistent, incomplete• Validation– extensive reviews to check that requirements satisfy client needs– look for ambiguity, consistency, incompleteness– check for feasibility, testability– develop system/acceptance test planJanuary 25, 2000 © Kenneth M. Anderson, 2000 8Design• Requirements Specification —> Design– develop architectural design (system structure)• decompose software into modules with module interfaces– develop detailed design (module specifications)• select algorithms and data structures– maintain record of design decisions• Difficulties– miscommunication between module designers– design may be inconsistent, incomplete, ambiguous• Verification– extensive design reviews (inspections) to determine that design conforms torequirements– check module interactions– develop integration test planJanuary 25, 2000 © Kenneth M. Anderson, 2000 9Implementation and Integration• Design —> Implementation– implement modules and verify they meet their specifications– combine modules according to architectural design• Difficulties– module interaction errors– order of integration has a critical influence on product quality• Verification and Testing– code reviews to determine that implementation conforms to requirements and design– develop unit/module test plan: focus on individual module functionality– develop integration test plan: focus on module interfaces– develop system test plan: focus on requirements and determine whether product as a wholefunctions correctlyJanuary 25, 2000 © Kenneth M. Anderson, 2000 10Operation and Maintenance• Operation —> Change– maintain software after (and during) user operation– determine whether product as a whole still functions correctly• Difficulties– design not extensible– lack of up-to-date documentation– personnel turnover• Verification and Testing– review to determine that change is made correctly and all documentation updated– test to determine that change is correctly implemented– test to determine that no inadvertent changes were made to compromise system functionality(check that no affected software has regressed)January 25, 2000 © Kenneth M. Anderson, 2000 11Build FirstVersionRetirementOperations ModeModify untilClient is satisfiedBuild-and-FixJanuary 25, 2000 © Kenneth M. Anderson, 2000 12RequirementsVerifyRetirementOperationsTestImplementationVerifyDesignReq. ChangeWaterfall ModelJanuary 25, 2000 © Kenneth M. Anderson, 2000 13Two views on Waterfall• Business Systems– Enterprise initiatives lead to feasibility studies• This starts the waterfall in motion• Engineering Applications– Waterfall starts much later in the process• Software may not be considered until after conceptexploration and experimental prototyping of globalengineering systemJanuary 25, 2000 © Kenneth M. Anderson, 2000 14Rapid PrototypingRapid PrototypeVerifyRetirementOperationsTestImplementationVerifyDesignReq. ChangeJanuary 25, 2000 © Kenneth M. Anderson, 2000 15For each build:Perform detaileddesign, implement.Test. Deliver.IncrementalRequirementsVerifyRetirementOperationsVerifyArch. DesignJanuary 25, 2000 © Kenneth M. Anderson, 2000 16Concept ofOperationRequirements PlanRequirementsOACRiskAssessmentRisk Item SetRisk Management PlanRequirementsRiskControlRequirementsValidationAbstract Specification Plan AbstractSpecifcationOACRiskAssessmentRiskControlAbstractSpecificationAbstract SpecificationValidationConcrete Specification Plan ConcreteSpecificationOACConcreteSpecificationConcreteSpecification Validationand VerificationSoftware Development PlanRiskAssessmentRiskControlProgressthroughstepsCumulative costEvaluate alternatives,identify, resolve risksDevelop, verifynext-level productPlan next phasesCommitReviewpartitionDetermineobjectives,alternatives,constraints(OAC)The Spiral Model [Boehm,1988]January 25, 2000 © Kenneth M. Anderson, 2000 17Object-Oriented Life Cycles• Obtain customer requirements for the OO System– Identify scenarios or use cases– Build a requirements model• Select classes and objects using basic requirements• Identify attributes and operations for each object• Define structures and hierarchies that organize classes• Build an object-relationship model• Build an object-behavior model• Review the OO analysis model against use casesJanuary 25, 2000 © Kenneth M. Anderson, 2000 18Life Cycle Problems• The user’s view of
View Full Document
Unlocking...