CS2110: Software Development Methods

1. CS2110: Software Development Methods • Textbook readings: • MSD: Chapter 1 Intro. to Software Engineering

2. Goals for this Course Unit • To introduce students to all aspects of software development (not just programming) • Course objective #5: • Comprehend important basic concepts of software engineering and the development of large software systems, including the software lifecycle, requirements, design, and software quality… • Software development is about more than: • Syntax, rules, libraries to use, a Java environment • Computer Science is also about more than these things and also more than SW development

3. How many classes in your largest program? • 3 or fewer • 4-6 classes • 6-12 classes • 13-20 classes • more than 20 classes

4. Lines of code in your largest program? • 200 or fewer • 200 – 400 • 400 - 1,000 • 1,000 – 2,000 • 2,000 or more

5. What’s a Big Program? • Table from the textbook:

6. Roadmap of Topics in Unit 1 • What is software engineering? What problems does it address? • What is the software development lifecycle? • What is involved in the phases of the SDLC? • Requirements and specification • Design (high-level and low-level) • Implementation • Integration and verification • Maintenance (AKA evolution) • What is a SW development methodology?

7. What’s the Problem? • Software costs are increasing as hardware costs decline. • Many software development disasters: • Cost overruns, late delivery • Reduced or wrong functionality, non-existent documentation • Many failures attributed to software • Cost of failure becoming very high: • Financial • Loss of life or loss of equipment • Inconvenience

8. Software Failures or Disasters • Shuttle launch anomaly • Launch 3 years late, millions over cost • 1st launch cancelled on pad • 2 years earlier, delay factor changed in software from 50 ms to 80 ms • Outages of AT&T Long Distance switches • Network unusable for about 9 hours Jan 15, 1990. • 1st major network problem in AT&T's 114 years • Ariane 5 launch explosion, 4 June 1996 • Short summary of report: http://www.esa.int/esaCP/Pr_33_1996_p_EN.html

9. Ariane 5 • What we wanted:

10. Ariane 5 • What we got! • “The failure of Ariane 501 was caused by the complete loss of guidance and attitude information… This loss of information was due to specification and design errors in the software of the inertial reference system. The extensive reviews and tests carried out during the Ariane 5 development programme did not include adequate analysis and testing of the inertial reference system or of the complete flight control system, which could have detected the potential failure."

11. Software Failures or Disasters (cont’d) • Social Security disaster • System started in 1980 by Sperry • In 1985, inadequate, 100% cost overrun • $90M equipment added • Late refunds caused the IRS to pay: • $40.2M in interest • $22.3M in over-time • Space Defense Operations Center (SPADOC) • $147M more than estimate • 7-8 years late • Death and injury from Therac 25

12. We have a “software crisis” (1968) • “Software Engineering” term coined in 1968 • NATO conference in Garmisch, Germany • An “early” study of “problem” DOD projects • 47% of software delivered could not be used • Usually didn’t meet requirements • 29% of funded software never delivered • Usually canceled due to cost/schedule overruns • 19% of software useful after extensive rework • Costs 36 times more to fix problems after release

13. Definition of Software Engineering • Fairley’s definition: • Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modifiedon time and within cost estimates. • Engineering versus science: • Production, practical, quality, maintenance, reuse, standards, teams, management, etc.

14. SW Engineering Is About... • It’s about: • Engineering • A systematic, careful, disciplined, scientific activity • Building software systems, particularly larger ones • Hacking or debugging until it works won’t work • Modifying software systems over time • Not just focused on creating new applications. • Programming may be fun, but SW Engin. should not be considered: • Easy, simple, boring or pointless

15. One Way to Think About It • Build a bridge to cross a small creek • Cut down a tree. Drop a board across it. • Build a bridge across the Golden Gate • Need a big tree! • What’s different? • Size of project matters. Number of people involved. How long does it has to last. Risk. Economics. • “Programming in the large” vs. “Programming in the small”

16. What’s a Big Program? • Table from the textbook:

17. Software Lifecycle and Phases • Stages or phases that are typical in software development, from “birth” to “death” • There are various different lifecycle models of how we move through these (more later) • Phases might include: • Requirements phase (also a Specification phase) • Design phase • Implementation phase • Integration or “testing” phase • Maintenance phase • Also maybe “conception” and “planning”

18. Analogy: SE is like Construction • Think about how buildings come to be: • Requirements • Architecture • Construction • Differences? • Maintenance • Buildings don’t change much • Design • Buildings really are less complex • Number of states • Remove one brick

19. Requirements, Design, and Implementation • Requirements • Statements of what the system should do (or what qualities it should have) • From the customer or client point of view • Not expressed in terms of a solution • Design • A description of how we will implement a solution • A model or blueprint for meeting requirements • Done before implementation, so it can be evaluated • Many possible designs for a set of requirements. How to choose? • Often models are used to describe either of these. We’ll see UML soon!

20. Relative Cost per Phase

21. Engineering Design (a la ENGR 1620) • Some sections of ENGR 1620 talk about a three-phase view of engineering design • Problem Formulation • Recognize needs; gather info on needs; determine requirements of the project • Problem Solving • Identify and analyze alternatives to meet requirements; choose and specify details for one alternative • Solution Implementation • Create a plan for implementation and testing; build it; evaluate it against requirements

22. More on Requirements • Reminder: Requirements are… • Statements of what the system should do (or what qualities it should have) • From the customer or client point of view • Not expressed in terms of a solution • Class program assignments are and are not like requirements documents. How? • Like: Should be clear, unambiguous statements of what must be done. Must be consistent, complete, feasible, “testable” • Not like: Often say how to do it (what classes, what methods, etc). Also, not for a “real” customer.

23. Types of Requirements • Functional requirements • describes a function or activity the system will carry out • Perhaps in response to input(s) • Describes the state of the system (or parts of the system) before and after an activity occurs • Non-functional requirements • What else might we want to describe? Suggestions? • Qualities: efficiency, reliability, usability, etc. • Constraints: • On its design: Must run on certain platform, use particular components, etc. • On how its built: Must be built in a certain way (i.e. DOD standard process)

24. More on Design • High-level or architectural design • Describe major components of a larger system • What they do, how they interact with other sub-systems (control, information flow) • Often diagrams (but few standard notations) • Lower-level or detailed design • For OO, what are the classes • Even lower, how are certain methods implemented • Algorithms • Notations: the Unified Modeling Language (UML) for OO design • Note: Should have good requirements descriptions before doing any of this!

26. Is this a requirements statement? • Yes • No The software will allow the user to enter and edit document information saved by the system.

27. Is this a requirements statement? • Yes • No User query operations will complete in less than 5 seconds.

28. Is this a requirements statement? • Yes • No The system will be written in Java and make use of the HooGUI interface library.

29. Is this a requirements statement? • Yes • No The connection manager in the system will encapsulate all data related to network connections and handle the cancel operation.

30. Reminders: Requirements vs. Design • Requirements: • The problem statement: what the system should do • Functional requirements • Non-functional requirements: constraints, qualities • Design • Describes one possible solution: how to meet the requirements • Must meet requirements • Can be used to build (like blueprints) • High-level vs. low-level design • E.g. “Subsystems” vs. class-design

31. Why Is Maintenance Expensive? • Good software is maintained. Bad software is discarded. (Success has a long-term cost!) • Different types of maintenance • Corrective maintenance • Fix defects after release • Perfective maintenance • Enhance to add new features etc. • Adaptive maintenance • Make it work in changing environment • Maintenance matters and costs even if released code has zero defects!

32. Costs of types of maintenance? • Different types of maintenance • Corrective maintenance: Fix defects after release • Perfective maintenance: Enhance to add new features etc. • Adaptive maintenance: Make it work in changing environment • How much of total maintenance costs goes to each? • 75%, 15%, 10% • 60%, 20%, 20% • 20%, 60%, 20% • 40%, 20%, 40%

33. Why Is Maintenance Expensive? • Good software is maintained. Bad software is discarded. (Success has a long-term cost!) • Different types of maintenance • Corrective maintenance [20%] • Fix defects after release • Perfective maintenance [60%] • Enhance to add new features etc. • Adaptive maintenance [20%] • Make it work in changing environment • Maintenance matters and costs even if released code has zero defects!

34. Source of Defects by Phase • 60 to 70 % of faults are from specification or design • One example: (Data of Bhandari et al. [1994])Faults found at end of design phase of new version of a product • 13% of faults from previous version of product • 16% of faults in new specifications • 71% of faults in new design • Faults discovered later in the lifecycle cost significant more to fix? Why?

35. Cost to Correct Faults Increases by Phase • If found late, how much more expensive to fix? • Say the problem is in the requirements • If you found it immediately, it costs $X to fix • But you find it later in the lifecycle -- how much more does it cost to fix? • 4x as expensive if found and corrected in design • 10x as expensive … in implementation • 30 – 52 x as expensive … in integration • 200 – 368 x as expensive … in maintenance

36. Importance of “Front-End” Activities • Much better to find problems early! • Reminder: • More serious errors occur there • More expensive to fix them • Thus, a principle: • Do better early (requirements and design)! • And also: • Coding matters, but in the big picture other things matter a lot too

37. Development Lifecycles, Other Fields • SW development lifecycle vs. other development lifecycles in engineering: Different? • Tell me! What have you learned about this in ENGR 1620 or other engineering classes? • Systems Engineering • See “what is systems engineering” on INCOSE’s website:http://www.incose.org/practice/whatissystemseng.aspx • Is there a lot that’s common? What’s different?

38. What’s Next? • Software quality • Testing software • Then, on to OO class design • Inheritance • Interfaces • Etc.

39. Unused slides

40. Risk and SW Engineering • Many problems arise because of risk • Things happen that we didn’t anticipate • Example problems • Wrong requirements • Critical staff leave project • Bad design requires later re-design • Expected new HW or SW fails to arrive or work • Schedule plan turns out to be too optimistic • Tools don’t work well enough • etc. • Good SEs work to manage and reduce risk

41. Managing Risk • Risk areas • Personnel • Schedule and budgets • Wrong functionality created • Requirements are volatile • SW Development is harder than we thought! • How to identify, manage and reduce risk • Prototyping • Simulation • Modeling • Planning and management

42. Comparative Cost Per Phase • Data on this slide from two sets of projects: • Various projects between 1976 and 1981 • 132 more recent Hewlett-Packard projects [Grady, 1994] • Note: not including maintenance costs