DOC PREVIEW
UMD CMSC 132 - Software Process Models

This preview shows page 1-2-20-21 out of 21 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 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 21 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 21 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 21 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CMSC 132: Object-Oriented Programming IISoftware Process ModelsDepartment of Computer ScienceUniversity of Maryland, College ParkOverviewSoftware process modelsWaterfallIterativeChoosing a software process modelLevel of understandingCost of changeSoftware Process ModelsSoftware methodologyCodified set of practices Repeatable process for producing quality softwareSoftware process modelMethodology for organizing software life cycleMajor approachesWaterfall modelIterative developmentFormal methodsWaterfall ModelApproachPerform steps in orderBegin new step only when previous step is completeResult of each step flow into next stepWaterfall ModelAdvantagesSimplePredictable resultsSoftware follows specificationsReasonable for small projectsProblemsIn real lifeMay need to return to previous step Steps may be more integratedSteps may occur at same timeUnworkable for large projectsIterative Software DevelopmentApproachIteratively add incremental improvementsTake advantage of what was learned from earlier versions of the systemUse working prototypes to refine specificationsIterative Software DevelopmentGoalsEmphasize adaptability instead of predictabilityRespond to changes in customer requirementsExamplesUnified modelAgile software developmentExtreme programming (XP)Unified Model Development divided into phases (iterations)1.Inception2.Elaboration3.Construction4.TransitionDuring each phaseMultiple iterations of software developmentDevelopment treated as mini-waterfallsEmphasis gradually shifts from specification to testingUnified Software Life Cycle ModelAgile Software DevelopmentAgile approachBased on iterative developmentShort iterations (timeboxes) lasting 1- 4 weeksWorking software as principal measure of progressProduced at end of each iterationAdds a more people-centric viewpointFace-to-face communication preferredCo-locate programmers, testers, “customers”Relies on adapting to feedback rather than planning as the primary control mechanismLess specification & documentationExtreme Programming (XP)Prominent example of Agile methodologyIterative, adaptive software developmentDescribes set of day-to-day practicesFollowed by managers & programmersIntended to encourage a set of valuesAppropriate for environments withSmall teamsRapidly-changing requirementsExtreme Programming ValuesCommunicationRapidly building & disseminating institutional knowledge among programming team SimplicityImplement simplest code needed by customer without emphasis on future versionsFeedbackFrom testing, team members, customersCourageWillingness to rewrite / refactor software to add or change featuresExtreme Programming PracticesPair programmingPairs of programmers combine software development efforts at one computerEspecially useful for novice programmersTest-driven developmentTests are designed first, before writing softwareContinuous integrationTests performed throughout development processOn-site customerCustomer available at all times to answer questionsFormal MethodsMathematically-based techniques for Specification, development, and verification Software and hardware systems Intended for high-integrity systemsSafetySecurityLevels0 – Informal implementation of formal specifications1 – Formal code development & verification2 – Theorem prover to ensure correctnessChoosing A Software ModelWhich software life cycle model is appropriate?For class programming projectsCode and test probably sufficesBut software in real world not like class projectsSome big questionsDo you understand what you are trying to build?What is the cost of change?How many people have to interact with the design?How easy is it to get the entire thing in your head?Do You Understand The Problem?In many cases, the things we want software to do are not well understoodExamplesProvide a web interface for student applicationsAllow users to view and manipulate photographsBuild a better search engineHard to understand constraints / interactionsMay have to build prototypeTo understand how users can effectively use itWhat Is The Cost Of Change?Possible situationMost coding already completeRealize need to change something In the design Or even the requirementsHow expensive is that?If hugely expensiveBetter get requirements & design right Before completing too much codeHas The Cost Of Change Changed?Some people believe Recent software development techniques have substantially reduced cost of changePossible reasonsSafer programming languagesE.g., not C/C++/assembly languageObject-oriented design & programmingTest-driven developmentSometimes, Change Is Still ExpensiveExpensive to change software thatIs key nexus in a large systemAffects many lines of codeInteracts with co-designed hardwareMay need to change hardware designInteracts with software being developed externallyCan’t easily change API once publishedHow Many People Interact With Its Design?People interacting with software designPart of the cost of changeNeed to alert / consult people on design changeDesign changes that interact with a lot of people Expensive and need to be minimizedTry to get design choices right early and documentedHow Easy Is Software To Understand?When building and developing software, you need to understand it (at least, parts of it)For 100 lines of code, just read the codeDoesn’t work for 100,000 lines of codeNeed to have ways of documenting the requirements & design at a higher


View Full Document

UMD CMSC 132 - Software Process Models

Documents in this Course
Notes

Notes

8 pages

Recursion

Recursion

12 pages

Sorting

Sorting

31 pages

HTML

HTML

7 pages

Trees

Trees

19 pages

HTML

HTML

18 pages

Trees

Trees

19 pages

Honors

Honors

19 pages

Lecture 1

Lecture 1

11 pages

Quiz #3

Quiz #3

2 pages

Hashing

Hashing

21 pages

Load more
Download Software Process Models
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 Software Process Models 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 Software Process Models 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?