New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

CSE 360 Week 3 Notes

by: Alexandra Notetaker

CSE 360 Week 3 Notes CSE 360

Alexandra Notetaker
GPA 3.5

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

Chapter 2: Process Models
Software Engineering
Debra Calliss
Class Notes
CSE360, Computer Science, software engineering, Engineering, software, notes, study
25 ?




Popular in Software Engineering

Popular in Computer Science and Engineering

This 4 page Class Notes was uploaded by Alexandra Notetaker on Tuesday September 6, 2016. The Class Notes belongs to CSE 360 at Arizona State University taught by Debra Calliss in Fall 2016. Since its upload, it has received 3 views. For similar materials see Software Engineering in Computer Science and Engineering at Arizona State University.

Similar to CSE 360 at ASU

Popular in Computer Science and Engineering


Reviews for CSE 360 Week 3 Notes


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 09/06/16
CSE 360 CHAPTER 2: PROCESS MODELS  The SoftwareProcess  Structuressetofactivitiesrequiredtodevelop asoftware system.  Specification- designing whatthesystemwilldo.  Development(design& implementation)-defining the organizationofthesystem.  Validation- checking thatthe systemmeetsthe customer’srequirements.  Evolution- changing the systemin responseto changing needs.  Abstractrepresentation ofaprocess,presenting adescription ofaprocessfromsome particular perspective.  Plan- Driven & Agile Processes  Plan-driven:processeswhere alloftheprocessactivitiesareplannedin advanceandprogressis measuredagainstthisplan.(perspective process)  Agile process:planning isincrementalandeasier tochange theprocesstoreflectchanging customerrequirements.  Mostpracticalprocessesinclude bothplan-driven andagile processes  Noright/wrong softwareprocesses  The SoftwareProcessModels  The WaterfallModel  Plan-driven model:separate anddistinctphasesofspecification anddevelopment.  Incrementaldevelopment  Specification,developmentandvalidation areinterleaved.Maybe plan-driven or agile.  Integration andConfiguration  Systemisassembledfromexisting components.Maybe plan-driven or agile.  Mostlarge systemsaredevelopedusing aprocessthatincorporateselementsfromallofthese models.  The WaterfallModel:  Separatephases:  Requirementsanalysis/definition  System/Software Design  Implementation/testing  Integration& systemtesting  Operation & maintenance  Main drawback:difficultyof accommodating changeafter processbegins.  WaterfallModelProblems:  Inflexible partitioning ofthe projectintodistinctstagesmakesitdifficulttorespondto changing customerrequirements.  The modelonlyappropriate when requirementsareestablishedandlimitedchangesare requiredduring thedesign process.  Mostlyusedfor large systemsengineering projectswhere asystemisdevelopedatseveral sites  Plan-drive ==coordinatedwork  IncrementalDevelopment  Reducesthecostofaccommodating tochangingcustomerrequirements.  Amountofanalysisanddocumentation ismuchless.  Easiertogetcustomer feedback.  Morerapiddeliveryofdevelopmentandsoftware.  IncrementalDevelopmentProblems  Processisnotvisible  Regulardeliverablesarerequired(notcosteffective)  Systemstructuredegradesasnew incrementsare added.  Unlesstime andmoneyisspentrefactoring toimprove software,regularchangetendsto corruptstructure.Incorporating further change becomesdifficultandcostly.  ProcessActivities  Realprocessesareinterleavedsequences oftechnical,collaborative,andmanagedactivities with theoverallgoalofspecifying,designing,implementing,andtesting software systems.  4 basicprocessactivitiesareorganizeddifferentlyin differentdevelopmentprocesses.  Copingwith Change  Changeisinevitable in allsoftware projects  Businessesleadtonew andchangedrequirements  New techopensnew possibilitiesfor improving implementation  Change leadstorework,socostsofchangeinclude bothrework(re-analyzing requirements) andimplementing new functionality.  Reducing the costofrework  Change anticipation:where thesoftwareprocessincludesactivitiesthat can anticipatepossible changesbefore significantreworkisrequired.  Change Tolerance:where the processisdesignedsothatchangescan be accommodatedatlow costs  Involvesincrementaldevelopment.  Copingwith changing Requirements  SystemPrototyping:where aversion ofthesystemisdevelopedquicklytocheck the customers’requirementsandfeasibilityofdesign decisions  Supportschangeanticipation  Incrementaldelivery:where thesystemincrementsare deliveredtothecustomer for comment andexperimentation  Supportsbothchangeavoidance andchangetolerance.  SoftwarePrototyping  Prototype:initialversion ofasystem usedtodemonstrate conceptsandtryoutdesign options.  Can be usedin:  Requirementsengineering process:helpwith requirementvalidation and elicitation  Design process:toexploreanddevelopUI system  Testing process:torun back-to-backtests.  Benefitsofprototyping  Improvedsystemuse  Matchusersrealneeds  Improveddesign quality  Improvedmaintainability  Reduceddevelopmenteffort  Prototype development  Basedon rapidprototyping tools/languages  Involveleaving outfunctionality:  Focuson areasofproductthat arewellunderstood  Errorcheckingandrecoverymaynotbe included  Focuson functionalityratherthannon-functionalrequirements(i.e.reliabilityandsecurity)  Throw awayprototypes  Discardafter development–notgoodbasisfor systemproduction  Maybe impossible totune systemtomeet non-functionalrequirements  Normallyundocumented  Structureisusuallydegradedthrough rapidchange.  Willnotmeet normalorganization/qualitystandards.  Incrementaldelivery  The developmentanddeliveryisbroken down intoincrementswith eachdelivering partofthe requiredfunctionality.  Userrequirementsareprioritized.  Oncethedevelopment ofan incrementisstarted,therequirementsarefrozen,through requirementsfor laterincrementscan continue toevolve.  Incrementaldevelopmentanddelivery  Incrementaldevelopments  Developthe systemin incrementsandevaluate eachbefore proceeding tothe developmentofthenext.  Normalapproachusedin agile methods  Evaluation done byuser/customaryproxy  Incrementaldelivery  Deployan incrementfor use byend-users  Morerealisticevaluation aboutpracticaluseof software  Difficulttoimplementfor replacementsystemsasincrementshave lessfunctionalitythan thesystembeing replaced.  ProcessImprovement:  Wayofenhancing qualityandreduce costs/ accelerating thedevelopmentprocess  Understandexisting processandchanging processesto increaseproductquality/reduce costs anddevelopmenttime.  ProcessImprovementactivities  ProcessMeasurement:measure attributesofsoftware processor productformbaseline for improvementdecisions  ProcessAnalysis:assesscurrentprocessweakness/bottlenecksidentifiedandprocess mapsdeveloped.  ProcessChange:addressweaknessintroducedandcycle resumestocollectdataof effectiveness.  ProcessMeasurement:  Collectquantitative processdata  Processmayhave tobe designedfirst  Usedtoassessprocessimprovements  Measurementsshouldnotdrive improvements  Driven byorganizationalobjectives  ProcessMetrics  Timetaken for processactivitiestobe complete (calendartime/effort)  Resourcesrequiredfor process(totaleffort in persondays)  Number ofoccurrences ofaparticularevent(i.e.numberofdefectsdiscovered)  CapabilityMaturityLevels  SEICapabilityMaturityLevels  Initial:  Essentiallycontrolled  Repeatable:  Productmanagement proceduresdefinedandused.  Defined:  Processmanagementproceduresandstrategiesdefinedandused  Managed:  Qualitymgmt.strategiesdefinedandused  Optimizing:  Processimprovementstrategies define andused.


Buy Material

Are you sure you want to buy this material for

25 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Steve Martinelli UC Los Angeles

"There's no way I would have passed my Organic Chemistry class this semester without the notes and study guides I got from StudySoup."

Jennifer McGill UCSF Med School

"Selling my MCAT study guides and notes has been a great source of side revenue while I'm in school. Some months I'm making over $500! Plus, it makes me happy knowing that I'm helping future med students with their MCAT."

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."


"Their 'Elite Notetakers' are making over $1,200/month in sales by creating high quality content that helps their classmates in a time of need."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.