1University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 7:Software Processes What is a Software Development Process The Lifecycle of a Software Project Agile vs. Disciplined Some common approaches: RUP, SCRUM, XP, ICONIX,… Where UML fits inUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Project TypesReasons for initiating a software development projectProblem-driven: competition, crisis,…Change-driven: new needs, growth, change in business or environment,…Opportunity-driven: exploit a new technology,…Legacy-driven: part of a previous plan, unfinished work, …Relationship with Customer(s):Customer-specific - one customer with specific problemMay be another company, with contractual arrangementMay be a division within the same companyMarket-based - system to be sold to a general marketIn some cases the product must generate customersMarketing team may act as substitute customerCommunity-based - intended as a general benefit to some communityE.g. open source tools, tools for scientific researchfunder ≠ customer (if funder has no stake in the outcome)Hybrid (a mix of the above)2University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3Project ContextExisting SystemThere is nearly always an existing systemMay just be a set of ad hoc workarounds for the problemStudying it is important:If we want to avoid the weaknesses of the old system……while preserving what the stakeholders like about itPre-Existing ComponentsBenefits:Can dramatically reduce development costEasier to decompose the problem if some subproblems are already solvedTension:Solving the real problem vs. solving a known problem (with ready solution)Product FamiliesVertical families: e.g. ‘basic’, ‘deluxe’ and ‘pro’ versions of a systemHorizontal families: similar systems used in related domainsNeed to define a common architecture that supports anticipated variabilityUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Lifecycle of an Engineering ProjectLifecycle modelsUseful for comparing projects in general termsNot enough detail for project planningExamples:Sequential models: Waterfall, V modelPhased Models: Incremental, EvolutionaryIterative Models: SpiralProcess ModelsUsed for capturing and improving the development processDetailed guidance on steps and products of each stepProcess FrameworksPatterns and principles for designing a specific process for your project3University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5Waterfall Modelrequirementsdesigncodeintegratetestperceived needView of development:a process of stepwise refinementlargely a high level management viewProblems:Static view of requirements - ignoresvolatilityLack of user involvement oncespecification is writtenUnrealistic separation ofspecification from designDoesn’t accommodate prototyping,reuse, etc.University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6V-Modelsystemrequirementssoftwarerequirementspreliminarydesigndetaileddesigncode anddebugunittestcomponenttestsoftwareintegrationacceptancetestsystemintegration“analyseanddesign”“testandintegrate”timeLevel of abstraction4University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Prototyping lifecycleSpecify fullrequirementsdesign code test integratePreliminaryrequirementsdesignprototypebuildprototypeevaluateprototypePrototyping is used for:understanding the requirements for the user interfaceexamining feasibility of a proposed design approachexploring system performance issuesProblems:users treat the prototype as the solutiona prototype is only a partial specificationUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8design code test integrate O&MreqtsPhased Lifecycle ModelsRequirementsdesign code test integrate O&MSource: Adapted from Dorfman, 1997, p10design code test integrate O&Mdesign code test integrate O&Mdesign code test integrate O&Mdesign code test integrate O&Mreqtsdesign code test integratereqtsversion 1version 2version 3Release 1release 2release 3release 4lessons learntlessons learntIncremental development(each release adds morefunctionality)Evolutionary development(each version incorporatesnew requirements)5University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9The Spiral ModelDetermine goals,alternatives,constraintsEvaluatealternativesand risksPlanDevelopandtestbudget1budget2budget3budget4prototype1prototype2prototype3prototype4alternatives4alternatives3Altern-atives2constraints4constraints3Constr-aints2alternativesconstraintsrisk analysis4risk analysis3riskanalysis2riskanalysis1concept ofoperationsoftwarerequirementsvalidatedrequirementssoftwaredesignvalidated,verified designdetaileddesigncodeunittestsystemtestacceptancetestrequirements,lifecycle plandevelopment planintegration and test planimplementation planSource: Adapted from Pfleeger, 1998, p57University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10“Agile” vs “Disciplined”IterativeSmall incrementsAdaptive planningEmbrace changeInnovation and explorationTrendyHighly fluidFeedback drivenIndividuals and InteractionsHuman communicationSmall teamsPlannedAnalysis before designPrescriptive planningControl changeHigh
View Full Document