4/1/2015. Great Software Development (through iteration) Outline. Motivation. Pleasing the Customer. A view from the research university

Transcription

1 Great Software Development (through iteration) A view from the research university Pleasing the Customer 1 Outline Motivation Why we need software engineering What will we learn What is software engineering Risk and Tradeoff Analysis Key Engineering Concepts Detailed class structure Class project Structure and motivation Testing your knowledge Background on software process Waterfall Plan-driven Agile 2 Motivation Why do we need software engineering 3 1

2 Released Software is Buggy 4 Important + Late = Disaster Allstate set out in 1982 to automate all of its office operations. They set a 5-year timetable and an $8 million budget. Six years and $15 million later, Allstate set a new deadline and readjusted its sights on a new budget of $100 million. from Rapid Development, McConnell 5 June 4, 1996: Ariane-5 Catastrophe Cause Superfluous calibration program for inertia sensors runs in-flight; the software was reused from Ariane-4. Costs of the Ariane-5-program until 1996: ~ $ 8 Billion Value of destroyed satellite: ~ $ 500 Million Measured values in Ariane-5 exceed those assumed for the Ariane-4 software. The corresponding (Ada-) exception is handled by stopping the control computer and switching over to a redundant system. The second system contains the same error and deals with the exception the same way... 2

3 Important + Buggy = Disaster Cause Race condition. Error message not clear could be ignored. Therac-25: a radiation therapy machine produced by Atomic Energy of Canada Limited (AECL) Some patients were given approximately 100 times the intended dose of radiation. At least 3 patients died Reuse of software used in the previous generation New machine did not have mechanical interlock: depended entirely on software Attributed to the bad software design and development practices! * Leveson, N.G.; Turner, C.S., "An investigation of the Therac-25 accidents," Computer, vol.26, no.7, pp.18,41, July : Therac-25 Accidents Therac-25 Radiation Machine ( An Investigation of the Therac-25 Accidents, Leveson) On June 3, 1985, the patient was set up for a 10-MeV electron treatment to the clavicle area. When the machine turned on, she felt a "tremendous force of heat... this red-hot sensation. she developed a reddening and swelling in the center of the treatment area. Her pain had increased to the point that her shoulder froze. But her oncologists continued to send her [for] Therac-25 treatments.the physicist at Kennestone noticed that the patient had a matching reddening on her back as though a burn had gone through her body, and the swollen area had begun to slough off layers of skin. She had received a 100x excess dose. 8 S.E. Practices Make a Difference Rework Cost (% of total) Productivity Increase (%) 3

4 What will we learn What is software engineering 10 In this class you will learn the: Why, What, and How Of great software development: Software that is built to support needs of its users and will withstand the test of time Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. In principle, we could certify software by testing, but by then it s rather late, it s already been built. Quality must be built in, that requires real engineering. 11 Software engineering is about doing Always bring pen and paper I will ask you do answer questions in class Why? Learning Requires Your Effort I will not grade the assignment but the participation If you try answering you will get points for participation even for wrong answers I you do not try you will not get points Because software engineering is about tradeoffs, in this class you will be often asked to choose one of multiple correct answers We are interested in understanding the tradeoffs Group discussion helps in understanding tradeoffs Often I will ask you to work in groups of 3 And now an example of question 4

5 2 definitions of Software Engineering Bauer, 1972 ISO/IEC/IEEE 24765, 2010 The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. * the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software Which is Better? Porsche Panamera GTS Ford F-350 It really depends on what you need or want, right? 14 Which is Better? OK, maybe we should compare apples to apples, eh? How about luxury compact cars? Volkswagen CC Sport vs. Mercedes Benz CLA

6 Which is Better? OK, maybe we should compare apples to apples, eh? How about luxury compact cars? Volkswagen CC Sport vs. Mercedes Benz CLA 250 A. B. There are many variables to consider when deciding which car is best. 16 Which is the Better Value? Subaru Forester, $26,800 Hyundai Tucson, $24, Which is the Better Value? [W]e found the Tucson to be noisy and hard-riding, with limited rear visibility and roominess. It also got an unimpressive 22 mpg overall. For about $2,000 more, the Subaru Forester,, is more comfortable, provides great visibility and handling, gets an impressive 26 mpg, and has excellent reliability. Subaru Forester, $26,800 Hyundai Tucson, $24,

7 Many Q s will be about tradeoffs Decisions in software development are complex, involving tradeoffs Cost/benefit Choice, balance among conflicting alternatives Discussing tradeoffs and persuading others to your view is authentic engineering practice In team engineering, if you can t speak it, it s like you didn t think it It s not enough to be smart, you have to communicate The way you get good is to practice Can t do this at home alone debate a team activity Get ready for your internships! 19 Key Engineering Concepts Design Variable Any feature of a product design that may be chosen or influenced by a designer Examples: Number of seats, weight, top speed, MPG, cost Independent variables are design choices; dependent variables are determined or influenced by choices made for other variables Tradeoff A conflict, compromise, or balance between two desirable design variables Increasing seats while holding cost constant may reduce cargo space Design Space The range of all independent variables in a design Seats: 2-8; Cargo Space: cubic feet; Maximize the important variables Cost is a dependent result variable, not an independent variable Value The degree to which benefits outweigh costs in a design Identify beneficial points in design space; choose on cost 20 The Clay Model A prototype of the car literally made out of clay. Simulations of the engineering aspects Software engineers: technology feasibility explorations Is the way the technologies will be combined going to work, given the constraints we have? Rapid build and test cycles, with feedback to improve are needed 21 7

8 Everyday Engineering Language It depends I can t really answer that question until I know more about our design goals [F-350 vs. Porsche Panamera] The cost outweighs the benefits It s an OK design, but the cost is more than the customer is willing to pay (or more than it will benefit the customer) [Mercedes-Benz CLA 250] It s a tradeoff We can t have it all, but if we re careful, we can balance these two design criteria to get a good result. [Subaru Forester] 22 Risk What is your definition of the word risk? 24 Risk = Danger? Google: A situation involving exposure to danger: "flouting the law was too much of a risk". This is the classic definition used by most Works most of the time However, it only looks at the downside (loss, failure) 8

9 Risk = Danger + Opportunity Economics The spread on the distribution of possible outcomes Investing in the stock market is more risky than savings, but has better chance of higher returns 26 Class structure Development Process Agile & plan-driven development processes Waterfall Spiral Agile: Scrum, XP Test-driven Development Behavioral-Driven Development Refactoring Requirements engineering Software Design Design patterns Strategy Observer Mediator Dependency Injection Factory Façade Decorator Adapter Singleton Composite MVC Class structure (2) Development Process The software development pipeline and tools IDEs Version control Continuous build and integration Issue tracking Shared source code ownership Pair programming Quality assurance Unit-testing Integration/acceptance-testing Code Inspection Software Development Software architecture Conceptual Integrity Architectural Styles Design principles Modeling with the UML Class Diagrams Sequence Diagrams State Diagrams 9

10 Class Project Structure and motivation 29 Project summary Goal A useful program Customer Students Technology You choose (and you are responsible for your choice) Teams 9 to 10 students Each responsible for one area (role) Process Agile but with some plan driven elements Metaphor Development team in CSE 110 Inc company Discussion session customer meeting 30 Risk Assessment Now is your turn to dicuss! What are the biggest risks you can foresee in your project? You will have to come up with a n updated risk matrix every week! 31 10

11 Basic knowledge you will need Java and Object-Oriented Development Test 32 A Quick Background on (Software) Process From improvisation to planning 33 Quality Control: A Short History Quality control in early manufacturing was Product-Centric ( what ) Regularly test product outputs Make adjustments to factory as needed But what to fix? In mid 20 th century, shift to Process- Centric quality control ( how ) Still test product outputs Also measure process elements Plans, people, tools Use cause-and-effect model to adjust factory as needed Statistics to precisely track variation Buzzword: Statistical Process Control SE has inherited this legacy SE methods are process-centric 34 11

12 What s a Software Process Anyway? It s the how that produces the what quality software desired, on time, under budget A prescribed sequence of steps The loop include: Plan Do Check: Measurement Product, and process itself Examples: bugs, progress, time, conflicts, re-work Adapt A software process is a self-referral algorithm Observes and adapts according to measurements Agile processes are adaptive to the customer Features, schedule, budget, priorities, markets, change Must measure these as well as internal elements (correctness) 35 Big bang development process Picture from Dan Pilone and Russ Miles: Head First Software Development, O Reilly, 2008 Big bang: where does it come from? Picture from Royce, Winston W. "Managing the development of large software systems." proceedings of IEEE WESCON. Vol. 26. No

13 The Waterfall Process First published in 1970 by Royce (not named Waterfall in the paper) This is THE example of a big bang approach! Picture from Royce, Winston W. "Managing the development of large software systems." proceedings of IEEE WESCON. Vol. 26. No The Waterfall Process (in DOD-STD-2167) Approved is 1985 as the mandatory way to develop software for DoD Picture from DOD-STD-2167, Military Standard, Defense System Software Development, 1985 The Cost of Waterfall By the late 1980s, the DoD was experiencing significant failure in acquiring software based on the strict, document-driven, single-pass waterfall model that DoD- Std-2167 required. A 1999 review of failure rates in a sample of earlier DoD projects drew grave conclusions: Of a total $37 billion for the sample set, 75% of the projects failed or were never used, and only 2% were used without extensive modification. Consequently, at the end of 1987, the DoD changed the waterfall-based standards to allow IID, on the basis of recommendations in an October 1987 report from the Defense Science Board Task Force on Military Software, chaired by Brooks. The report recommended replacing the waterfall, a failing approach on many large DoD projects, with iterative development:* * Larman, C.; Basili, V.R., "Iterative and incremental developments. a brief history," Computer, vol.36, no.6, pp.47,56, June

14 The Cost of Waterfall By the late 1980s, the DoD was experiencing significant failure in acquiring software based on the strict, document-driven, single-pass $37 billions total waterfall model that DoD- Std % failed required. or were never A used 1999 review = of $27.75 failure billions rates in a sample lost of earlier DoD projects drew grave conclusions: Of 23% a required total extensive $37 billion modification for the sample = $8.51 set, more 75% of the projects time/cost failed or were never used, and only 2% were used 2% without successful extensive modification. Consequently, = $0.74 at the success end of 1987, the DoD changed the waterfall-based standards to allow IID, on the basis of recommendations in an October 1987 report from the Defense Science Board Task Force on Military Software, chaired by Brooks. The report recommended replacing the waterfall, a failing approach on many large DoD projects, with iterative development:* * Larman, C.; Basili, V.R., "Iterative and incremental developments. a brief history," Computer, vol.36, no.6, pp.47,56, June 2003 The Waterfall Process (Question!) Royce 1970 How can we fix the Waterfall? Form teams of 3 with people sitting next to you. Discuss what is wrong with waterfall and come up with a solution. Discussion Points: where is the problem? In the order of activities In how design is documented. In how many time the process runs. In the testing procedures. In the customer involvement. The Waterfall Process (Royce Opinion) Comment on the Waterfall Picture I believe in this concept, but the implementation described above is risky and invites failure. Problem: The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. Rationale: The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. * Royce, Winston W. "Managing the development of large software systems." proceedings of IEEE WESCON. Vol. 26. No

15 The Waterfall Process (the next figure) Unfortunately they took the wrong picture! Picture from Royce, Winston W. "Managing the development of large software systems." proceedings of IEEE WESCON. Vol. 26. No The Waterfall Process (Royce Opinion) /2 The remainder of the Paper 5 features to fix Waterfall 1. Program design comes first 2. Document the design The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks. 3. Do it twice 4. Plan control and monitor testing Basically: improve testing at all levels 5. Involve the customer * Royce, Winston W. "Managing the development of large software systems." proceedings of IEEE WESCON. Vol. 26. No Risk management Boehm s spiral process 48 15

16 The Spiral Development Model 4 quadrants Evaluate alternatives/identify and resolve risks Design and Verify Plan next phase Determine goals and constraints Iterative approach Risk driven! Picture from Boehm, B.W., "A spiral model of software development and enhancement," Computer, vol.21, no.5, pp.61,72, May 1988 Risks in Development Picture from Boehm, B.W., "A spiral model of software development and enhancement," Computer, vol.21, no.5, pp.61,72, May 1988 Risks in Development Picture from Boehm, B.W., "A spiral model of software development and enhancement," Computer, vol.21, no.5, pp.61,72, May

17 Top ten risks according to Boehm 1. Personnel shortfalls 2. Unrealistic schedules and budgets 3. Developing the wrong software functions 4. Developing the wrong user interface 5. Gold plating 6. Continuing stream of requirement changes 7. Shortfalls in externally furnished components 8. Shortfalls in externally performed tasks 9. Real-time performance shortfalls 10.Straining computer-science capabilities From table 4 in Boehm, B.W., "A spiral model of software development and enhancement," Computer, vol.21, no.5, pp.61,72, May 1988 Iteration The Heart of Agile Process 53 Planning with the customer With customer, you work out: 1. List of requirements or features 2. Budget 3. Deadline This triangle has a couple of names: Project management triangle Iron triangle Conveys tradeoffs 54 17

18 Reading questions What is the biggest risk of Big Bang according to the book? What is the general solution suggested? 55 Iterations are mini-projects Big Bang Waterfall Development Few well-defined quality measurement points, little data to guide process improvement Quality measures can be performed more frequently, informing frequent adjustments 57 Bite-sized Planning: User Stories Iterations 58 18

19 Take-Aways 59 19