04lifecycles

04lifecycles - Software process life cycles CSE 432:...

Info iconThis preview shows pages 1–10. Sign up to view the full content.

View Full Document Right Arrow Icon
    Software process life cycles CSE 432: Object-Oriented Software Engineering
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
    Software and entropy A virtue of software: relatively easy to change Otherwise it might as well be hardware Nevertheless, the more complex a software system gets, the harder it is to change- -why? Larger software systems are harder to understand The more changes get introduced into a system, the more it tends toward entropy I.e., its internal order breaks down
Background image of page 2
    Planning for change How can good comments facilitate and reduce the cost of software maintenance? Hint: think about invariants, things that don’t change. Comments describe meaning of code Assuming programmers maintain comments when they change the code! How can modularity help manage change? Modules help to isolate and localize change
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
    A software process requires resources…
Background image of page 4
    A software life cycle is a  process A process involves activities, constraints and resources that produce an intended output. Each process activity, e.g., design, must have entry and exit criteria— why? A process uses resources, subject to constraints (e.g., a schedule or a budget) A process is organized in some order or sequence, structuring activities as a whole A process has a set of guiding principles or criteria that explain the goals of each activity
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
    Waterfall model  of software process Cascades from one stage down to the next, in stately, lockstep, glorious order. Gravity only allows the waterfall to go downstream; it’s very hard to swim upstream Department of Defense contracts prescribed this model for software deliverables for many years, in DOD Standard 2167-A.
Background image of page 6
    Corporate manager types change  slowly…
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
    Why would corporate manager types like  the waterfall life cycle model? Minimizes change, maximizes predictability Costs and risks are more predictable Each stage has milestones and deliverables: project managers can use to gauge how close project is to completion Sets up division of labor: many software shops associate different people with different stages: Systems analyst does analysis, Architect does design, Programmers code, Testers validate, etc.
Background image of page 8
    Testing in the waterfall model Let’s look more carefully at Pfleeger’s version of the waterfall model Many waterfall models show 5 stages—why more here? What’s the difference between unit and system testing?
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 10
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 22

04lifecycles - Software process life cycles CSE 432:...

This preview shows document pages 1 - 10. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online