Software Life CyclesKenneth M. AndersonFoundations of Software EngineeringCSCI 5828 - Spring Semester, 2001(Guest Lecture)March 16, 2001 © Kenneth M. Anderson, 2001 2Today’s Lecture• Discuss Software Life Cycles– Why do we need them?– What types exist?• Code and Fix (hacking)• Waterfall• Iterative• Rapid Prototype• Spiral– Advantages and DisadvantagesMarch 16, 2001 © Kenneth M. Anderson, 2001 3Background• In Software Engineering:“Process is King”– We want our activities to be coordinated and planned,e.g. “engineered”– The reason? A high quality process should increase ourability to create a high quality productMarch 16, 2001 © Kenneth M. Anderson, 2001 4Use of Process• Car Assembly– An assembly line is a process for producing cars.– A significant amount of work goes into not justdesigning a car but into designing the process used tobuild that car• Software Engineering– The same principles can be applied to developing asoftware systemMarch 16, 2001 © Kenneth M. Anderson, 2001 5Key Difference• There is a key difference between software engineeringand car assembly, however.• In car assembly, design time for the car is “short”, themajority of the work lies in manufacturing– In software engineering, we face the reverse situation, creatingnew copies of a software system is trivial, it’s the design that ishard– Thus, there will be significant differences in the processes used todevelop softwareMarch 16, 2001 © Kenneth M. Anderson, 2001 6Software Life Cycle• A series of steps that organizes the development ofa software product• Duration can be from days to years• Consists of– people!– overall process– intermediate products– stages of the processMarch 16, 2001 © Kenneth M. Anderson, 2001 7Phases 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 provide organizationMarch 16, 2001 © Kenneth M. Anderson, 2001 8Requirements 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 planMarch 16, 2001 © Kenneth M. Anderson, 2001 9Design• 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 to requirements– check module interactions– develop integration test planMarch 16, 2001 © Kenneth M. Anderson, 2001 10Implementation 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 correctlyMarch 16, 2001 © Kenneth M. Anderson, 2001 11Operation 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 systemfunctionalityMarch 16, 2001 © Kenneth M. Anderson, 2001 12Build FirstVersionRetirementOperations ModeModify untilClient is satisfiedCode-and-Fix (Not a Life Cycle!)March 16, 2001 © Kenneth M. Anderson, 2001 13Discussion of Code-and-Fix• Useful for “hacking”• Problems become apparent in any serious codingeffort– No process for things like versioning, configurationmanagement, testing, etc.– Difficult to coordinate activities of multipleprogrammers– Non-technical users cannot explain how the programshould work– Programmers do not know or understand user needsMarch 16, 2001 © Kenneth M. Anderson, 2001 14RequirementsVerifyRetirementOperationsTestImplementationVerifyDesignReq. ChangeWaterfall ModelMarch 16, 2001 © Kenneth M. Anderson, 2001 15Discussion of Waterfall• Proposed in early 70s• Widely used (even today)• Advantages– Measurable Progress– Experience applying steps in past projects can be usedin estimating duration of steps in future projects– Produces software artifacts that can be re-used in otherprojectsMarch 16, 2001 © Kenneth M. Anderson, 2001 16Waterfall, continued• The original waterfall model had disadvantages because itdisallowed iteration– Inflexability– Monolithic– Estimation is difficult– Requirements change over time– Maintenance not handled well• These are problems with other life cycle models as well• The “waterfall with feedback” model was created inresponse– Our slides show this modelMarch 16, 2001 © Kenneth M. Anderson, 2001 17Rapid PrototypingRapid PrototypeVerifyRetirementOperationsTestImplementationVerifyDesignReq. ChangeMarch 16, 2001 © Kenneth M. Anderson, 2001 18Discussion of Rapid Prototyping• Prototypes are used to develop reqs. spec.• Once reqs. are known, waterfall is used• Prototypes are discarded once design begins– Prototypes should not be used as a basis for implementation.Prototyping tools
View Full Document
Unlocking...