Copyright , Dennis J. Frailey Software Engineering Best Practices Dennis J. Frailey Things that make a big difference for real software development projects

2 Copyright , Dennis J. Frailey 2 Objective  To present some basic techniques used in professional software development projects –Some of these are not widely covered in undergraduate programs

3 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 8 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. Parser Code Generator File System Run Time System User Interface Manage Software Development Build “C” Compiler Build Test Suite Write Documentation Write Installation Software Software for “C” Compiler

9 Copyright , Dennis J. Frailey 9 Sample Work Breakdown Structure for Taking a Course 1.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 Copyright , Dennis J. Frailey 10 Sample Work Breakdown Structure Hierarchy Allows Additional Detail 1.Take a Course on Programming in Java 1.1 Do Assignment 1 – Simple Program Study Chapters 1 and 2 of textbook Write a Simple Java Program 1.2 Do Assignment 2 – Program with Arrays Study Chapters 3 and Review Graded Assignment Write Java Program with Arrays 1.3 Take Midterm Exam Study Chapters Meet with study group to review Go to exam room at designated time

11 Copyright , Dennis J. Frailey 11 Sample WBS for a Software Project (top levels only) 1.0 Software for Payroll system 1.1Build the Payroll software Build a User Interface Build a File System Build a Data Base Build a Table of Rules Build a Check Printing System 1.2Build the Test Suite for the Software (detailed steps for building test suite) 1.3Write Documentation 1.4Write Installation Software 1.5Manage the Above

12 Copyright , Dennis J. Frailey 12 The WBS Is... A “table of contents” for the project.

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

14 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 15 Using the WBS to Estimate WBS # Task Estimated Hours Estimated Completion 1.1 Do Assignment 1 159/ Read Chapters 1, 2 39/ Write Simple Java Pgm 129/ Do Assignment 2 219/ Read Chapters 3, 4 49/ Review Graded Assign. 1 19/ Write Java Pgm with Arrays 169/30

16 Copyright , Dennis J. Frailey 16 Using the WBS to Track WBS # Task Estimated Hours Actual Hours Estimated Completion Actual 1.1 Do Assignment /229/ Read Chapters 1, /159/ Write Simple Java Pgm 12109/229/ Do Assignment 2 219/ Read Chapters 3, 4 49/ Review Graded Assign. 1 19/ Write Java Pgm with Arrays 169/30

17 Copyright , Dennis J. Frailey 17 Graph to Show Progress

18 Copyright , Dennis J. Frailey 18 Using the WBS for Historical Records Previous WBS New WBS Facts about New Project Previous WBS Old Projects

19 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 20 Systems Engineering A Sample System DisplayPrinterKeyboard Processor and Memory System Software Power Supply Computer System Unit

21 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 23 Example of Requirements Allocation Requirements: - Sense Status - A/D conversion - Display Temperature Sensor Analog Device A/D Converter Software

24 Copyright , Dennis J. Frailey 24 Typical Requirements Flowdown Transmission System Analysis & Design Allocated Requirements Automobile Drive TrainChassisEngine 100 pounds torque pounds2000 pounds500 pounds 250 hp... Original Requirements 3000 pounds 0-60mph in 9 sec

25 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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

Copyright , Dennis J. Frailey Risk Management Phases 1)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 2)Risk Control – The things you do during the project – Preventing the unexpected – Responding when you cannot prevent

28 Copyright , Dennis J. Frailey 28 Risk Assessment Chart RiskEvidenceHow Likely ImpactPriorityMitigation Late project due to employee turnover Unplanned turnover rate has been running high 7749Employee bonuses if they stay to end of project Bottleneck at testing due to changing require- ments Past experience with this customer 8648Iterative development Customer workshops Etc.

29 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 30 Risk Control Chart RiskMonitoringCounteracting / Contingency Ongoing Mitigation Late project due to employee turnover Measure turnover rate and project schedule Get management help in identifying alternate employees Periodic employee mini- bonuses Bottleneck at QA due to changing require- ments Track requirements changes and QA backlog Requirements freeze; Multiple releases Feature prioritization Etc.

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

32 Copyright , Dennis J. Frailey 32 Requirements Stability Monitoring CDRPDR

33 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 35 What Is Software Configuration Management? Definition: Software Configuration Management is the process of identifying, organizing and managing modifications to software

36 Copyright , Dennis J. Frailey 36 Purpose of Configuration Management The purpose of configuration management is to maintain integrity of the product by controlling change to the product

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

38 Copyright , Dennis J. Frailey 38 What is Integrity? Having the right parts that all fit together to form a correct product. ListingUser’s Guide Main, rel 2.3 Sub1, rel 1.7 Sub2, rel Object code

39 Copyright , Dennis J. Frailey 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 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 45 Quality Assurance Looks at the Entire Process Requirements DevelopmentQC Inspection Pass Fail Standards of Quality Process and Design Standards

46 Copyright , Dennis J. Frailey 46 Software Quality Assurance Typical Practices: –Inspections –Reviews –Audits –Communication –Measurements –Independent confirmation of compliance  Standards, requirements, procedures

47 Copyright , Dennis J. Frailey 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 Copyright , Dennis J. Frailey 48 Questions?