Software Engineering Best Practices – Things You Seldom Learn Much About in School

1. Software Engineering Best Practices – Things You Seldom Learn Much About in School Dennis J. Frailey ACM Distinguished Speaker Frailey@ACM.ORG This talk discusses several practices that make a big difference for real software development projects

2. The Distinguished Speakers Program is made possible by For additional information, please visit http://dsp.acm.org/

3. Objective • To present some basic techniques used in professional software development projects • Some of these are not widely covered in academic computing programs

4. Would You Buy This Car? • The price is 50% more than what you agreed to pay • Delivered to the dealer 3 months late • Not the right color • Some of the options you selected aren’t there (“we’ll install them later”) • The speakers and the CD player are incompatible, so you can only use the CD player through headphones • Although “new”, it has 5,000 miles on it from the extensive testing that was done • Despite that testing, it still won’t start if it’s below freezing and it has a number of other problems

5. Frequent Problems for Product Developers on Real Software Projects • Nobody knows what work must be done • Do we need to provide an installation guide? • Is there a warranty on this software? • and what should we do about it if there is? • In what format should we deliver the code? • Do we have to provide training for the end users?

6. Frequent Problems on Real Software Projects (continued) • Vague understanding of the big picture • Has the customer used a computer before? • How does the software fit into the overall customer environment? • Are the networks and computers suitable for the software? • How will the customer use the software?

7. Air Traffic Control Replacement System The New System The Old System

8. Frequent Problems on Real Software Projects(continued) • Unclear understanding of how much has been accomplished and how much is left to do • “How much longer will it take?” • “How much more money is required?”

9. Frequent Problems on Real Software Projects(continued) • Ignorance about risks • What are our biggest potential project problems? • Do we have any idea what the real risks are? • Do we know which ones to worry about the most? • Can we mitigate the risks? (make them less likely or lower their potential impact) • Do we have a contingency plan? (what to do if the risks happen?

10. Frequent Problems on Real Software Projects(continued) • Confusion about different versions of software • Which version of the data base goes with the latest version of the user interface? • How come it does one thing in the customer’s site but something else in our testing lab? • Does the design match the code? If not, which one is right?

11. Frequent Problems on Real Software Projects(continued) • Haphazard approaches to quality • “We didn’t have time to test it thoroughly” • “We tested it for weeks but it still had lots of bugs”

12. Best Practices for Managing These Problems • The Work Breakdown Structure • Documenting and organizing the work to be done • Estimating and Tracking • So you know where you are • Systems Engineering • Designing the big system before designing the software • Risk Management • Configuration Management • Quality Assurance

13. Software for “C” Compiler Build “C” Compiler Build Test Suite Write Documentation Write Installation Software Manage Software Development User Interface File System Parser Code Generator Run Time System The Work Breakdown Structure Definition: A work breakdown structure is a hierarchical list of the work activities required to complete a project. This includes tasks for: - Software development - Management of software development - Support of software development - Any other activities required to meet customer requirements, such as: • creation of documents, • training programs, • tool development or acquisition, • travel, etc.

14. Sample Work Breakdown Structure for Taking a Course • Take a Course on Programming in Java 1.1 Do Assignment 1 – Simple Program 1.2 Do Assignment 2 – Program with Arrays 1.3 Take Midterm Exam 1.4 Do Assignment 3 – Program with Pointers 1.5 Do Assignment 4 – Program with I/O 1.6 Take Final Exam These are the tasks you must complete in order to finish the course

15. Sample Work Breakdown StructureHierarchy Allows Additional Detail • Take a Course on Programming in Java 1.1 Do Assignment 1 – Simple Program 1.1.1 Study Chapters 1 and 2 of textbook 1.1.2 Write a Simple Java Program 1.2 Do Assignment 2 – Program with Arrays 1.2.1 Study Chapters 3 and 4 1.2.2 Review Graded Assignment 1 1.2.3 Write Java Program with Arrays 1.3 Take Midterm Exam 1.3.1 Study Chapters 1-5 1.3.2 Meet with study group to review 1.3.3 Go to exam room at designated time

16. Sample WBS for a Software Project (top levels only) 1.0 Software for Payroll system 1.1 Build the Payroll software 1.1.1 Build a User Interface 1.1.2 Build a File System 1.1.3 Build a Data Base 1.1.4 Build a Table of Rules 1.1.5 Build a Check Printing System 1.2 Build the Test Suite for the Software 1.2.x (detailed steps for building test suite) … 1.3 Write Documentation 1.4 Write Installation Software 1.5 Manage the Above

17. The WBS Is ... A “table of contents” for the project.

18. Top Level Role of WBS Cost Estimate (proposal &/ project start) Source Documents (Statement of Work, Requirements, contract, test criteria, etc,) WBS Cost Tracking (during execution) Historical Records (at end of project)

19. Best Practices for Managing These Problems • The Work Breakdown Structure • Documenting and organizing the work to be done • Estimating and Tracking • So you know where you are • Systems Engineering • Designing the big system before designing the software • Risk Management • Configuration Management • Quality Assurance

20. Using the WBS to Estimate

21. Using the WBS to Track When the project is over, you have a detailed record of how much time and effort were required.

22. Graph to Show Progress

23. Using the WBS for Historical Records Facts about New Project New WBS Previous WBS Previous WBS Previous WBS Previous WBS You can make more accurate estimates for the next project. Old Projects

24. Best Practices for Managing These Problems • The Work Breakdown Structure • Documenting and organizing the work to be done • Estimating and Tracking • So you know where you are • Systems Engineering • Designing the big system before designing the software • Risk Management • Configuration Management • Quality Assurance

25. Computer Keyboard System Unit Display Printer Power Supply Processor and Memory System Software Systems EngineeringA Sample System

26. Systems Engineering - Step 1 - Analyze the Requirements of the Total System • Determine what the customer really wants • >> Analysis of the problem and the need • Produceverifiable specifications (specifications may be in the form of simulations of expected behavior, use cases, specification documents, system requirements models, or other things) • Confirm the specifications are right by conferring with the customer

27. Systems Engineering - Step 2 - Design the System • Determine the architecture of the system • >> Synthesis, not analysis • Done by Systems engineer and/or chief architect • Determine the major parts (functional decomposition into sub-systems) • Determine the interfaces between the subsystems

28. Systems Engineering - Step 3 - Allocate the Requirements to the Components of the System • Determine what each part will do • Assign requirements to each part based on what it is supposed to do • This is how you get some of the software requirements when software is part of a larger system

29. Typical Requirements Flowdown 3000 pounds 0-60mph in 9 sec Automobile Original Requirements System Analysis & Design Allocated Requirements Engine Transmission Drive Train Chassis ... 500 pounds 250 hp 100 pounds torque ... 50 pounds 2000 pounds

30. When the Product is FinishedVerify that it Satisfies the Requirements Development Testing or Other Verification Methods Requirements Verification Methods derived from requirements When the requirements (specifications) are verifiable by testing, you are much more likely to have effective tests

31. Ideal Requirements (some but not all desirable characteristics) • Cohesive (each requirement addresses only one thing) • Complete (each requirement is fully stated; all requirements are known and allocated) • Sufficient (every required feature is specified) • Consistent (no requirements contradict each other) • Unambiguous (only one possible interpretation) • Verifiable (you can tell when they are met)

32. Actual Requirements • Some requirements will • Contradict others • Not be readily verified • Change in mid-stream • Technology changes • Customer understanding of problem changes • Problem changes • Some requirements will be: • TBD (unknown - to be determined) • Wrong • Missing • Vague or unclear

33. Risk Management for Imperfect Requirements • Define a lifecycle/process that is adaptable – it will readily accommodate requirements changes • Assign someone to be responsible to manage requirements changes • including involvement of software staff • Select a lifecycle based on level of expected requirements stability • Get ranges for “TBD” (to be determined) requirements • Work to eliminate wrong and missing requirements

34. Interface Requirements • How does your software interface with other parts of the system? • This is just as important as other requirements • Make sure the interface requirements are • Documented • Under Control • If possible, requirements should be • Contained in (or controlled by) a SINGLE document or other control point

35. Who is Establishing the Requirements? All Stakeholders! • End user -- will use the software • Champion -- will pay for it • Marketing -- will sell it • Accountants and Lawyers -- will protect but may not understand the product or the process • Political factors • Such as engineers -- who “know better” than the customer

36. “V” Model of Software DevelopmentA General Model of Software Development This model underlies almost all others Test Cases Based on Requirements Requirements Analysis Acceptance Test Test Cases Based on Architecture Integration Test Architecture Design Test Cases Based on Design Detailed Design Unit Test Test Planning Begins with Requirements! Implementation

37. Are we Asking the Right Question? • The usual question: • How can we verify the software (make sure we have satisfied the requirements)? • A better question: • How can we define requirements that are readily verified? • The requirement can be verified through one of these basic methods: • inspection, • demonstration, • test (instrumented) or • analysis (to include validated modeling & simulation).

38. Best Practices for Managing These Problems • The Work Breakdown Structure • Documenting and organizing the work to be done • Estimating and Tracking • So you know where you are • Systems Engineering • Designing the big system before designing the software • Risk Management • Configuration Management • Quality Assurance

39. Risk Management • Risks are: • things that can go wrong • If it has already happened, or is certain to happen, it is an issue, not a risk! • You should be discussing your action plan for managing the problem

40. Risk Management Phases Risk Assessment The things you do before you start the project to identify What can go wrong? How it can hurt you? How likely is it to happen? Why it may happen? How you can mitigate (reduce) the risk? Risk Control The things you do during the project Preventing the unexpected Responding when you cannot prevent

41. Risk Assessment Chart

42. Risk Control A) Risk Monitoring - Watching to see if risks happen • Metrics to warn you of problems • Periodic reviews B) Risk Abatement - Counteracting risks - Taking contingency actions as needed

43. Risk Control Chart

44. Risk Management is Ongoing Risk Management (planning, analysis) Product Development Data and reports to identify and monitor risks Actions to mitigate or abate risks

45. Example of Risk Monitoring:Requirements Stability Monitoring PDR CDR

46. Expected Range of Values Setting Thresholds Abnormally High Values Abnormally Low Values

47. Thresholds Help You Monitor Risks • Thresholds tell you when to act • Beware of the “contented frog” problem • Historical experience is a good basis to judge when things are getting out of hand It’s only a little hotter than yesterday!

48. Best Practices for Managing These Problems • The Work Breakdown Structure • Documenting and organizing the work to be done • Estimating and Tracking • So you know where you are • Systems Engineering • Designing the big system before designing the software • Risk Management • Configuration Management • Quality Assurance

49. What Is Software Configuration Management? Definition: Software Configuration Managementis the process of identifying, organizing and managing modifications to software

50. Purpose ofConfiguration Management The purpose of configuration management is to maintain integrity of the product by controlling change to the product