Software Engineering Best Practices

1. Software Engineering Best Practices Dennis J. Frailey Frailey@ACM.ORG Things that make a big difference for real software development projects

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

3. 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

4. Frequent Problems 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 do we do about it if there is? • In what format should we deliver the code? • Vague understanding of the big picture • How does the software fit into the overall customer environment? • Are the networks and computers suitable for the software? • Will the customer understand how to use it? • Do the software developers know how it will be used?

5. 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?” • Ignorance about risks • Do we have any idea what the real risks are? • Is there something we can do to mitigate them? (Make them less likely or lower their potential impact) • Do we know what to do if they happen?

6. 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? • 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”

7. 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

8. 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.

9. 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

10. Sample Work Breakdown Structure Hierarchy 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

11. 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.1 (detailed steps for building test suite) 1.3 Write Documentation 1.4 Write Installation Software 1.5 Manage the Above

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

13. 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)

14. 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

15. Using the WBS to Estimate

16. Using the WBS to Track

17. Graph to Show Progress

18. Using the WBS for Historical Records Facts about New Project New WBS Previous WBS Previous WBS Previous WBS Previous WBS Old Projects

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. Computer Keyboard System Unit Display Printer Power Supply Processor and Memory System Software Systems EngineeringA Sample System

21. Systems Engineering - Step 1 - Analyze the Requirements of the Overall System • Determine what the customer really wants • >> Analysis of the problem and the need • Produce testable 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

22. Systems Engineering - Step 2 - Design the System • Select 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 • Allocate the requirements to the various parts

23. Example of Requirements Allocation Requirements: - Sense Status - A/D conversion - Display Temperature Sensor Analog Device A/D Converter Software

24. 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

25. 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

26. 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

27. 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 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

28. Risk Assessment Chart

29. 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

30. Risk Control Chart

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

32. Requirements Stability Monitoring PDR CDR

33. Risk Monitoring Thresholds • Establish thresholds so you know when to act • Beware of the “frog in the water” problem • Historical experience is a good basis to judge when things are getting out of hand

34. 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

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

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

37. module • component • data file • macro • simulator • specification • document • compiler used to develop • development tool • data set used for simulating • special equipment • operating system • test code • test data • library • procedure • hardware • etc. If any of the above is wrong, the product lacks integrity and may not work What Is The Configuration? • All components that make up or relate to a version of a product • The proper version of each:

38. Main, rel 2.3 Sub1, rel 1.7 Sub2, rel 3.1 ... Object code What is Integrity? Having the right parts that all fit together to form a correct product. User’s Guide Listing

39. Why is SW Configuration Management Needed? • Because software is flexible, changeable, and intangible • It is too easy to lose integrity of software because of these factors Unmanaged change is very possibly the largest single cause of failure to deliver systems on time and within budget. NASA SCM Guidebook, August, 1995

40. Examples of Loss of Integrity • Performance 2 years ago cannot be duplicated with the current release • Source code will not compile without errors • Compiled code will not execute with the same results as the released code • It worked in the factory but not in the field • All records of a particular feature are gone, and the programmer/designer left the company

41. More Examples of Loss of Integrity • Compiled code has different object code or code size from released code • A bug that we fixed once before has reappeared • Code does not match the design specification • A feature that we added and fully tested has suddenly stopped working • We cannot figure out which version of each module is needed to reproduce a problem we found in the field

42. Configuration Management Has Five Major Functions 1) Configuration Identification • Which parts are combined in what way to make a given release/version 2) Configuration Control • The rules for making changes to software 3) Change Management • Deciding who is allowed to make changes and when? 4) Status accounting • Where is each component? 5) Configuration Authentication • Verifying that everything is right

43. 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

44. Software Quality Assurance Purposes: • To prevent defective products from being shipped to the customer • To arbitrate disputes when there are debates about whether the product is “good enough” • To provide management and developers with visibility into the process being followed and the products being built • So they can manage the outcome

45. Quality Assurance Looks at the Entire Process Process and Design Standards Fail Pass Development QC Inspection Requirements Standards of Quality

46. Software Quality Assurance Typical Practices: • Inspections • Reviews • Audits • Communication • Measurements • Independent confirmation of compliance • Standards, requirements, procedures

47. Professional Software Engineering Is ... Building Software Systems that People can Rely On “The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software.” IEEE Standard Glossary of Software Engineering Terminology

48. Questions?