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 Park1OverviewSoftware process modelsWaterfallIterativeChoosing a software process modelLevel of understandingCost of change2Software Process ModelsSoftware methodologyCodified set of practices Repeatable process for producing quality softwareSoftware process modelMethodology for organizing software life cycleMajor approachesWaterfall modelIterative developmentFormal methods3Waterfall ModelApproachPerform steps in orderBegin new step only when previous step is completeResult of each step flow into next step4Waterfall 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 projects5Iterative Software DevelopmentApproachIteratively add incremental improvementsTake advantage of what was learned from earlier versions of the systemUse working prototypes to refine specifications6Iterative Software DevelopmentGoalsEmphasize adaptability instead of predictabilityRespond to changes in customer requirementsExamplesUnified modelAgile software developmentExtreme programming (XP)7Unified 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 testing8Unified Software Life Cycle Model 9Agile 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 & documentation10Extreme 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 requirements11Extreme 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 features12Extreme 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 questions13Formal 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 correctness14Choosing 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?15Do 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 it 16What 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 code17Has 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 development18Sometimes, 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 published19How 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 documented20How 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?