Software Engineering Lifecycles. Controlling Complexity

Transcription

1 Software Engineering Lifecycles Class url: Controlling Complexity Separation of Concerns Planning Ahead Do a little work now to make later work easier The sooner a problem is found the less costly it is to repair 1

2 Phases of Software Engineering Phases separate concerns over time Concentrate on one aspect at a time And space Different teams can specialize skills Main Engineering Phases: Development Validation and Verification Maintenance/Evolution Development Phases specification Define problem before designing solution Decide how to tell if it was built right Design: Architecture, High-Level Design Low-Level Design Decide higher-level structure before lower-level structure Implementation Capture the design in code 2

3 V and V Validation: Are we building the right thing? A range of techniques for assessing the quality of a system or any of its artifacts Verification: Are we building the thing right? Is the system, or any of its artifacts, consistent with the requirements Techniques: Testing --most common Formal verification Static analysis Reviews/Inspections/Walk-thrus Maintenance/Evolution Fix bugs Add features Respond to environment changes New compilers New hardware Improve product Faster, smaller, easier to use, easier to maintain Re-do development and testing 3

4 Planning Ahead in Development Each phase produces artifacts that: Help the next phase Might also help other phases Increase our understanding of the problem Lay a foundation for further development Address concerns uncovered so far More efficient than just code it up Usually don t know what it is Basic Waterfall Model Specification Design Designs Implementation V&V Finished Product 4

5 Waterfall Model (2) Specification Test Plan Design Designs Customer Ideas Implementation V&V Finished Product Specification Phase Take customer input, produce requirements document Defines WHAT system should do Functional vs. non-functional requirements Develop a test plan Sometimes produce a prototype Customer needs to review and concur Usually takes several iterations 5

6 Design Phase Take requirements document, produce design Demonstrates HOW system will meet requirements Includes various levels of design: Architecture/High-Level/Low-Level Diagrams help explain design Sometime produce a prototype Implementation Take design, produce code According to adopted standards Sometime produce a prototype 6

7 Testing Take code, test plan, and requirements document, then run tests Given system inputs from test plan, verify outputs against requirements Functional and non-functional requirements can be tested Different Phases to Testing Unit testing Integration testing System testing Acceptance testing Regression testing 7

8 Waterfall Model (2) Specification Test Plan Design Designs Customer Ideas Implementation Test Finished Product Waterfall Model Critique Linear Rigid Monolithic 8

9 Waterfall is Linear, then design, then code No feedback Testing is intended to provide feedback Sometimes (often) Can t design until we try to code part Can t decide requirements without knowing how they will be satisfied Waterfall is Rigid Each artifact is frozen before proceeding Assumes requirements and design can be frozen early BUT our understanding is weakest early on, so we might freeze poor requirements or design 9

10 Waterfall is monolithic Aims to deliver a single product on a single date Can t get feedback from customer until whole process is complete After much time/money has been spent When it is too costly to fix problems Called the wait, wait, wait, SURPRISE! model Waterfall Model (3) w/ rework Specification Test Plan Architecture/ Design Low-Level Design Customer Ideas New Req Ideas New Design Ideas New ideas Test Finished Product 10

11 Modified waterfall model critique recognizes distinct activities actual processes are complex numerous iterations among phases not purely top down decomposition into subsystems many variations of the waterfall model prototyping re-engineering... Do-It-Twice Model Produce a prototype using waterfall lite model Learn about what works well Get feedback from customer Throw prototype away Develop again based on: Customer feedback Better understanding Called Rapid Prototyping 11

12 Rapid Prototyping Model Used to: Understand requirements To get feedback from customer Understand how to design system To assess feasibility Particularly useful for user interfaces Incremental Development Model Specification Test Plan Architecture/ Design Low-Level Design Customer Ideas Test Finished Product Working, but incomplete product Specification Test Plan Architecture/ Design Low-Level Design Customer Ideas Working, but incomplete product Test Finished Product Specification Test Plan Architecture/ Design Low-Level Design Customer Ideas Test Finished Product 12

13 Incremental Development Critique Less monolithic Deliver lots of working systems to get: feedback better understanding Often used to get to market faster deliver essential features first work on other features later Spiral Model Set objectives, alternatives, constraints Evaluate alternatives Identify & resolve risks Plan Develop and Verify alternative 13

14 What We Will Do Mostly waterfall, with some incremental development For each phase: Perform phase Present results Get feedback from customer, other groups Revise artifacts/documents What We Will Do HL Design Customer Ideas LL Design = Revision Coding Coding 14

15 What is the cost of producing software??% Design?%?% Testing?% Software Costs Development costs! reqts and design! 35%! code! 15%! testing! 50%! Full lifecycle costs! code! reqts/design! testing! maintenance! 15

16 Software Maintenance! Software Development! Software! Maintenance! 50-80% of software product's cost goes to maintenance! Decisions made throughout a project affect the cost of maintenance planning for maintenance increases front end cost Industry is often unwilling to pay these costs up-front Time to market Job turn-over 16

17 Relative Costs to Fix Errors! Design! Coding! Testing! After delivery! Relative Cost! Some interesting numbers Failure rate for projects About 25% of s/w projects fail Failure rate increases as the size of the project increases Cost per LOC Typically $100/LOC Ranges between $10-$1000 LOC/day for a typical programmer Typical: 30 LOCs a day Ranges between LOCs Ranges between 3-10 faults/kloc 17

18 PITAC report, February 1999 Software; The demand for software has grown far faster than our ability to produce it. Furthermore, the Nation needs software that is far more usable, reliable, and powerful than what is being produced today. We have become dangerously dependent on large software systems whose behavior is not well understood and which fail in unpredicted ways. High-level Goals of Software Engineering improve productivity reduce resources e.g., time, cost, personnel improve predictability improve maintainability improve quality 18