1. University of Southern California Center for Systems and Software Engineering Barry Boehm, USC CS 510 Software Planning Guidelines

2. University of Southern California Center for Systems and Software Engineering 2 Outline Motivation Software Project Plans –General Outline –Content of Sections

3. University of Southern California Center for Systems and Software Engineering Problems With Computer System Acquisition and Use in U.S. Government, 1965-1976 3

4. University of Southern California Center for Systems and Software Engineering Software Life-Cycle Plans 4

5. University of Southern California Center for Systems and Software Engineering Project Plans May Look Complicated, But They Aren’t! 5

6. University of Southern California Center for Systems and Software Engineering 1. Objectives (Why?) Software Product Objectives –Functions Performed –Concept of Operation –Expected User Benefits Development Plan Objectives –Basis for Project Control –Make Best Use of People, Resources –Provide Evidence That Developers Know What They’re Doing 6

7. University of Southern California Center for Systems and Software Engineering 2. Milestones and Products (What? When?) Overall Development Strategy Detailed Schedule of Deliverables Detailed Milestones and Schedules 7

8. University of Southern California Center for Systems and Software Engineering 2.1 Overall Development Strategy with the Incremental Commitment Model chart Major Phases and Milestones Nature and Phasing of Prototypes Nature and Phasing of Development Increments Other Departures From “Waterfall” Model Top-Level Milestones Charts, Activity Networks 8

9. University of Southern California Center for Systems and Software Engineering 2.2. Detailed Schedule of Deliverables Deliverable Items - Plans - Data - Specs - Equipment - Manuals - Facilities - Reports - Training Materials - Code - Manhours, etc. Nature of Deliverables - Name or Title - Date Due - Required Format - Completion Criteria –Produced, Delivered, Received, Reviewed, Tested, --- - Pointers to Contract Requirements 9

10. University of Southern California Center for Systems and Software Engineering 2.3. Detailed Milestones and Schedules More Detail Than Strategy Section –Overall Order of Integration –Intermediate Test Stages –Synchronization With Support S/W, H/W But Less Detail Than Full (Test) Plan –Integration Order-of-Build –Individual Test Descriptions –Requirements/Test Matrices 10

11. University of Southern California Center for Systems and Software Engineering 3. Responsibilities (Who? Where?) 3.1 Organizational Responsibilities 3.1.1 Global Org. Charts 3.1.2 Org. Commitment Responsibilities 3.2 Development Responsibilities 3.2.1 Development Org. Charts 3.2.2 Staffing 3.2.3 Training Internal External 11

12. University of Southern California Center for Systems and Software Engineering Life Cycle Plan - Basic Activities (I) 12

13. University of Southern California Center for Systems and Software Engineering Life Cycle Plan - Basic Activities (II) 13

14. University of Southern California Center for Systems and Software Engineering 4. Approach (How?) 4.1 Risk Management 4.2 Development Phases 4.3 Reviews 4.4 Documentation 4.5 Configuration Management 4.6 Quality Assurance 4.7 Facilities & Related Concerns 14

15. University of Southern California Center for Systems and Software Engineering Review Sequence 15

16. University of Southern California Center for Systems and Software Engineering Why Write Documents? To Stimulate Decisions To Record Decisions To Record Agreements To Facilitate Training 16 These Objectives Drive the Size, Form and Content of the Documentation

17. University of Southern California Center for Systems and Software Engineering Configuration Management Purview 17

18. University of Southern California Center for Systems and Software Engineering 4.5 Configuration Management Configuration Identification Systematically Identify Each Product Component –Types, Hierarchy, Media, Versions Change Control Controlled Mechanism for Product Changes –Forms, Procedures, Approval Authority Configuration Status Accounting Keep Accurate Track of Product Status –Forms, Logs, Files, Reports Configuration Audits Verify Product Integrity Project Library Management Controlled Product Storage & Distribution 18

19. University of Southern California Center for Systems and Software Engineering 4.6 Quality Assurance Functions Documentation and Code Standards Standards Compliance Monitoring Plans & Policies Compliance Monitoring Review & Test Monitoring Corrective Action Monitoring 19

20. University of Southern California Center for Systems and Software Engineering Facilities Plans Form: Similar to Project Plans Candidate Contents –Computer Rooms, Flooring, Power, Air Conditioning –Computers, Peripherals, Supplies –Data Communications –Office Space, Furniture, Utilities, etc. –Transportation, Parking, Employee Services 20

21. University of Southern California Center for Systems and Software Engineering Related Concerns Support Services Support Software Customer Furnished Facilities, etc. Security Subcontractor Operations Commercial Software 21

22. University of Southern California Center for Systems and Software Engineering 5. Resources 5.1 Work Breakdown Structure (WBS) 5.2 Budgets 5.3 Status Monitoring & Control 22

23. University of Southern California Center for Systems and Software Engineering The Work Breakdown Structure (WBS) Defines Project Jobs to be Done Associates Budgets With Work Packages Serves as Basis for Cost-vs.-Progress Monitoring and Control 23

24. University of Southern California Center for Systems and Software Engineering Status Monitoring & Control Progress: Milestones Budget: Expenditure Reports Schedule: PERT, Gantt Charts Combinations –Earned Value –Summary Task Planning Sheet –Budget-Schedule-Milestone 24

25. University of Southern California Center for Systems and Software Engineering 6. Assumptions Conditions Necessary to Meet Plans –Otherwise, Renegotiate Examples –Requirements Stability –Schedule Stability –Continuity of Funding –Customer-Furnished Items On-Schedule, Acceptable –Customer Response Time on Approvals 25

26. University of Southern California Center for Systems and Software Engineering Simple Software Development PERT Chart 26 Start Requireme nts,3 Test plan,2 Design,4 Test data,2 Test drivers, 6 Code, 4 Document, 2 Product test, 4 Finish

27. University of Southern California Center for Systems and Software Engineering PERT chart development step1 and step2 27 Document, 2 Product test, 4 Finish

28. University of Southern California Center for Systems and Software Engineering PERT chart development step3 28 Code, 4 Document, 2 Product test, 4 Finish

29. University of Southern California Center for Systems and Software Engineering PERT chart development step4 29 Design,4 Test data,2 Test drivers, 6 Code, 4 Document, 2 Product test, 4 Finish

30. University of Southern California Center for Systems and Software Engineering PERT chart development steps 5, 3, 4, 5, 3, 4, 5 30 Requireme nts,3 Test plan,2 Design,4 Test data,2 Test drivers, 6 Code, 4 Document, 2 Product test, 4 Finish

31. University of Southern California Center for Systems and Software Engineering Critical Path Procedure 1. Label the Start node (0, 0) 2. For all unlabeled nodes N whose predecessors are all labeled nodes, compute the earliest possible start time as the latest finishing time of all its predecessor nodes where P(N) is the set of predecessor nodes of N Compute the corresponding finish time F N =S N +D N,where D N is the duration of activity N, Label the node N as (S N, F N ) 3. Repeat Step 2 until no unlabeled nodes remain. 31

32. University of Southern California Center for Systems and Software Engineering Critical path determination after two iterations 32 Start Requireme nts,3 Test plan,2 Design,4 Test data,2 Test drivers, 6 Code, 4 Document, 2 Product test, 4 Finish (0, 0) (0, 3) (0, 2) (3, 7) (3, 5) (2, 8)

33. University of Southern California Center for Systems and Software Engineering Critical path determination after five iterations 33 Start Requireme nts,3 Test plan,2 Design,4 Test data,2 Test drivers, 6 Code, 4 Document, 2 Product test, 4 Finish (0, 0) (0, 3) (0, 2) (3, 7) (3, 5) (2, 8) (0, 3) (3, 5) (0, 0) (3, 7) (7, 11) (9, 11) (5, 11) (11, 15) (13, 15) (7, 9) (15, 15)

34. University of Southern California Center for Systems and Software Engineering Latest-Start Procedure 1. Underlabel the Finish node F with its start and finish times as determined from the critical-path procedure, that is (S’ F, F’ F ) = ( S F, F F ) 2. For all non-underlabeled nodes N whose successors are all underlabeled nodes, compute the latest possible finish time as the earliest starting time of all its successor nodes. where S(N) is the set of successor nodes of N. Compute the corresponding latest-start time S’ N =F’ N - D N where D N is the duration of activity N, Underlabel the node as (S’ N, F’ N ),Compute the slack time for the activity as L N =S’ N - S N (or L N =F’ N - F N ) 3. Repeat Step 2 until no non-underlabeled nodes remain. 34

35. University of Southern California Center for Systems and Software Engineering Shortening the Critical Path 35 Start Requireme nts,3 Test plan,2 Design,3 Test data,2 Test drivers, 6 Code, 2 Document, 2 Product test, 4 Finish (0, 0) (0, 3) (0, 2) (3, 6) (3, 5) (2, 8) (6, 8) (8, 12) (6, 8) (12, 12)