CSC 492 The Practice of Software Engineering. Lecture 3 University of Mount Union Software Life Cycle Models

Transcription

1 CSC 492 The Practice of Software Engineering Lecture 3 University of Mount Union Software Life Cycle Models

2 Software Life Cycle Models Every program (no matter what size) has several distinct phases that occur in its development Requirements (what) Design (how) Coding (how) Testing Release Maintenance/Evolution (change)

3 Software Life Cycle Models Every life cycle model is a variation on two fundamental types Do each phase in order Do a complete life cycle, release, then start again

4 Software Life Cycle Models The software life cycle describes the sequence in which all major activities will occur May cover from concept development to product retirement May include planning, reviews, documentation, and baselines Decision points between activities

5 Code and Fix Model In other words, the lack of any SLC model lack of formal SE process No formal requirements, documentation, QA, testing, etc. Works okay for quick, disposable tasks (e.g. proof of concept) - no maintenance Works well for single person projects VERY DANGEROUS model for anything larger

6 Code and Fix Model

7 Waterfall Model One of the first models to be developed at the dawn of SE Covers all major software development activities Based on an assembly-line mentality Assumption is you finish phase N - 1 before proceeding to phase N Little or no communication among life cycle phases

8 Waterfall Model Originated from the manufacturing and construction industries Highly structured physical environments in which after-thefact changes are prohibitively costly (if not impossible). Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adopted for software development. It turns out that software is different from other products small changes are almost free (debugging and recompiling) even major changes

9 Properties of Waterfall Model Works well for: Known requirements AND known technologies Weak or inexperienced staff (lots of structure) High quality requirements (must have!) Problems: Very rigid if used without modification For the majority of projects, it is nearly impossible to define requirements adequately to make Waterfall work Few signs of ongoing progress (easy to fall behind) In practice, unmodified waterfall is almost never used but it s useful as a starting point to describe models

10 Waterfall Model

11 Waterfall With Subprojects After Requirements and Architectural Design of project, break out next 3 phases [Detailed Design, Coding, and Unit Testing] for several subprojects Then integrate the whole system and do complete system testing for a single release of the product Pros include faster development of known tasks, and possibly better use of resources Cons include unforeseen dependencies between subprojects You re much more likely to see this than classic waterfall

12 Waterfall With Subprojects

13 Waterfall With Feedback Take the phases of a classic waterfall and add explicit feedback loops. Recognizes that you have to start work with incomplete requirements, design, tests, etc. You will have to go back and do re-work Problems: Much more difficult to establish schedule & benchmarks When is product complete (when to stop)?

14 Waterfall With Feedback

15 Staged Delivery Also known as: Rapid Application Development (RAD) Like Waterfall model for Requirements Analysis and Architectural Design; then [Design, Code, Test, and Deliver] the product in stages Project defined from the start and is delivered in stages, based on feature priorities Increases chance of getting key features into product Key idea: overlapping stages makes for more efficient division of labor on team

16 Staged Delivery (RAD)

17 Spiral LCM First incremental delivery model. Focuses on addressing major risk areas for a project (requirements, architecture, etc.) Each mini-project addresses one or more risk areas, then start the next mini-project think of a cinnamon roll

18 Spiral LCM Each mini-project has four steps: 1) Determine objectives, alternatives, and constraints for this mini-project 2) Identify and resolve risks 3) develop products/deliverables and test 4) plan for next iteration

19 Spiral LCM Risks: a potential problem that may affect the project, its timing and/or its budget lawsuits equipment failure buggy release inadequate performance/quality Risks may be classified during Requirements Analysis as low, medium or high Risk Exposure: (probability of risk) (cost of occurrence) Team should address areas of highest risk exposure first

20 Spiral LCM

21 Spiral LCM Pros: Handles risk very well Cons: Very complicated Hard to define and resolve many mini-projects Hard to stay focused on overall project goals

22 Evolutionary Prototyping (aka Incremental Prototyping) Develop visible parts of system first, then work on the rest of the system, prioritizing requirements as you get them Keep refining the prototype until customer accepts it as the final product Good for changing requirements, or a poorly understood application area

23 Evolutionary Prototyping Very hard to plan full project from the start Risky, but has good track record Pros: improved progress visibility, good customer and end user input to requirements Cons: danger of unrealistic schedule, budget, and progress expectations possibility of bad design low maintainability may have lots of re-work

24 Evolutionary Prototyping

25 Design-To-Schedule The usual Requirements Analysis and Architectural Design; then do stages of [design, code, and fully test] until time or money runs out. Then deliver product. Good for non-critical portions of product. Put highest priority features in first stages. Usually done when you ve got a hard deadline Needs very good schedule estimates to succeed

26 Design-To-Schedule

27 Evolutionary Delivery Cross between Evolutionary Prototyping and Staged Delivery Draft initial Requirements Analysis and Architectural Design do { Prioritize the features Develop the product within a fixed timeframe Deliver it to the customer, receive feedback to modify requirements } while ( needed ); Deliver final version when customer is happy.

28 Evolutionary Delivery Pros: good project visibility reduced risk strong customer interaction with requirements definition Cons: reduced project control may result in feature creep or unrealistic estimates This is the way many software products are developed (e.g. OS s, embedded systems,...)

29 Evolutionary Delivery

30 Extreme Programming A relatively new lightweight model (meaning less documentation and fewer process controls) Useful for small teams (up to 20 developers; is optimal) Main focus: customer satisfaction Relies on: Heavy customer involvement Continuous Unit Testing and reviews Pair Programming Short release cycles and frequent releases

31 How to Choose a Life Cycle? Questions to consider: How well known and stable are your requirements? How big is the project? (How many features?) How well known and stable is your architecture? What are your reliability needs? Will there be many versions of your product? How much risk do you expect?

32 How to Choose a Life Cycle? Questions to consider (continued): How constrained is the schedule? (drop-dead date?) Will midcourse corrections be likely? Does the customer need visible progress? Does your management need visible progress? How sophisticated is your team with respect to the life cycle you pick? How big is your team?

33 How to Choose a Life Cycle? See table 7.1 in section 7.11 of McConnell s Rapid Development, 3/e (available on Safari) Some guidelines: High Risk, Big Budget: Spiral Legacy system or well-defined reqs: Waterfall, or one of the Waterfall variants Visible Progress needed, working model needed quickly, features can be added later: Staged Delivery Hard Deadline (can t be extended): Design-To-Schedule

34 How to Choose a Life Cycle? More guidelines: Lots of changes probable, or requirements not well understood: Evolutionary Prototyping or Evolutionary Delivery My favorite (not that my opinion matters a great deal ): Evolutionary Delivery important consideration: skills and experience of team members

35 CSC 492 The Practice of Software Engineering Lecture 3 University of Mount Union Software Life Cycle Models