DOC PREVIEW
Toronto CSC 302 - Lecture 7 - Software Processes

This preview shows page 1-2-3 out of 10 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

Toronto CSC 302 - Lecture 7 - Software Processes

Documents in this Course
Load more
Download Lecture 7 - Software Processes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 7 - Software Processes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 7 - Software Processes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?