CS451 Lecture 5: Software Project Planning [Pressman, Chap 4-7]

1. CS451Lecture 5: Software Project Planning[Pressman, Chap 4-7] Yugi Lee STB #555 (816) 235-5932 leeyu@umkc.edu www.sice.umkc.edu/~leeyu CS451 - Lecture 5

2. Software Project Planning • The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project. Why? • So the end result gets done on time, with quality! CS451 - Lecture 5

3. The Steps • Scoping—understand the problem and the work that must be done • Estimation—how much effort? how much time? • Risk—what can go wrong? how can we avoid it? what can we do about it? • Schedule—how do we allocate resources along the timeline? what are the milestones? • Control strategy—how do we control quality? how do we control change? CS451 - Lecture 5

4. Write it Down! Project Scope Estimates Risks Schedule Control strategy Software Project Plan CS451 - Lecture 5

5. To Understand Scope ... • Understand the customers needs • understand the business context • understand the project boundaries • understand the customer’s motivation • understand the likely paths for change • understand that … Even when you understand, nothing is guaranteed! CS451 - Lecture 5

6. Cost Estimation • project scope must be explicitly • task and/or functional decomposition is necessary • historical measures (metrics) are very helpful • at least two different techniques should be used • remember that uncertainty is inherent CS451 - Lecture 5

7. Functional Decomposition functional decomposition Statement perform of Scope a "grammatical parse" CS451 - Lecture 5

8. Creating a Task Matrix Obtained from process framework” framework activities application functions Effort required to accomplish each framework activity for each application function CS451 - Lecture 5

9. Conventional Methods: LOC/FP Approach • compute LOC/FP using estimates of information domain values • use historical effort for the project CS451 - Lecture 5

10. Normalization for Metrics Normalized data are used to evaluate the process and the product (but never individual people) size-oriented normalization —the line of code approach function-oriented normalization —the function point approach CS451 - Lecture 5

11. Typical Size-Oriented Metrics • errors per KLOC (thousand lines of code) • defects per KLOC • $ per LOC • page of documentation per KLOC • errors / person-month • LOC per person-month • $ / page of documentation CS451 - Lecture 5

12. CAD System Example: LOC Approach LOC/pm (line of code per month):Organizational average productivity for systems of this type UICF: User interface and control facilities, 2DGA: Two-dimensional geometric analysis 3DGA: Three-dimensional geometric analysis, DBM: Database management CGDF: Computer graphics display facilities, PCF: Peripheral control function DAM: Design analysis modules CS451 - Lecture 5

13. Typical Function-Oriented Metrics • errors per FP (thousand lines of code) • defects per FP • $ per FP • pages of documentation per FP • FP per person-month CS451 - Lecture 5

14. Why Opt for FP Measures? CS451 - Lecture 5

15. Computing Function Points CS451 - Lecture 5

16. Example: FP(function point) Approach CS451 - Lecture 5

17. Tool-Based Estimation project characteristics calibration factors LOC/FP data CS451 - Lecture 5

18. Empirical Estimation Models General form: exponent effort = tuning coefficient * size usually derived empirically as person-months derived of effort required usually LOC but may also be function point either a constant or a number derived based on complexity of project CS451 - Lecture 5

19. Estimation Techniques • past (similar) project experience • conventional estimation techniques • task breakdown and effort estimates • size (e.g., FP) estimates • tools (e.g., Checkpoint) CS451 - Lecture 5

20. Estimation Guidelines estimate using at least two techniques get estimates from independent sources avoid over-optimism, assume difficulties you've arrived at an estimate, sleep on it adjust for the people who'll be doing the job—they have the highest impact CS451 - Lecture 5

21. The Make-Buy Decision CS451 - Lecture 5

22. Computing Expected Cost expected cost = (path probability) x (estimated path cost) i i For example, the expected cost to build is: expected cost = 0.30($380K)+0.70($450K) build = $429 K similarly, expected cost = $382K reuse expected cost = $267K buy expected cost = $410K contr CS451 - Lecture 5

23. Risk Management [Pressman chap 6] CS451 - Lecture 5

24. Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it? CS451 - Lecture 5

25. Reactive Risk Management • project team reacts to risks when they occur • mitigation—plan for additional resources in anticipation of fire fighting • fix on failure—resource are found and applied when the risk strikes • crisis management—failure does not respond to applied resources and project is in jeopardy CS451 - Lecture 5

26. Proactive Risk Management • formal risk analysis is performed • organization corrects the root causes of risk • TQM concepts and statistical SQA • examining risk sources that lie beyond the bounds of the software • developing the skill to manage change CS451 - Lecture 5

27. Risk Management Paradigm control track RISK identify plan analyze CS451 - Lecture 5

28. Building a Risk Table Risk Probability Impact RMMM Risk Mitigation Monitoring & Management CS451 - Lecture 5

29. Risk Mitigation, Monitoring, Management • mitigation—how can we avoid the risk? • monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely? • management—what contingency plans do we have if the risk becomes a reality? CS451 - Lecture 5

30. Risk Due to Product Size Attributes that affect risk: • estimated size of the product in LOC or FP? • estimated size of product in number of programs, files, transactions? • percentage deviation in size of product from average for previous products? • size of database created or used by the product? • number of users of the product? • number of projected changes to the requirements for the product? before delivery? after delivery? • amount of reused software? CS451 - Lecture 5

31. Risk Due to Business Impact Attributes that affect risk: • affect of this product on company revenue? • visibility of this product by senior management? • reasonableness of delivery deadline? • number of customers who will use this product • interoperability constraints • sophistication of end users? • amount and quality of product documentation that must be produced and delivered to the customer? • governmental constraints • costs associated with late delivery? • costs associated with a defective product? CS451 - Lecture 5

32. Risks Due to the Customer Questions that must be answered: • Have you worked with the customer in the past? • Does the customer have a solid idea of requirements? • Has the customer agreed to spend time with you? • Is the customer willing to participate in reviews? • Is the customer technically sophisticated? • Is the customer willing to let your people do their job—that is, will the customer resist looking over your shoulder during technically detailed work? • Does the customer understand the software engineering process? CS451 - Lecture 5

33. Risks Due to Process Maturity Questions that must be answered: • Have you established a common process framework? • Is it followed by project teams? • Do you have management support for software engineering? • Do you have a proactive approach to SQA? • Do you conduct formal technical reviews? • Are CASE tools used for analysis, design and testing? • Are the tools integrated with one another? • Have document formats been established? CS451 - Lecture 5

34. Technology Risks Questions that must be answered: • Is the technology new to your organization? • Are new algorithms, I/O technology required? • Is new or unproven hardware involved? • Does the application interface with new software? • Is a specialized user interface required? • Is the application radically different? • Are you using new software engineering methods? • Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks? • Are there significant performance constraints? • Is there doubt the functionality requested is "do-able?" CS451 - Lecture 5

35. Staff/People Risks Questions that must be answered: • Are the best people available? • Does staff have the right skills? • Are enough people available? • Are staff committed for entire duration? • Will some people work part time? • Do staff have the right expectations? • Have staff received necessary training? • Will turnover among staff be low? CS451 - Lecture 5

36. Recording Risk Information Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low ... 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using software simulation Estimated resources: 6 additional person months beginning 7-1-96 CS451 - Lecture 5

37. Project Scheduling and Tracking Pressman Chap 7 CS451 - Lecture 5

38. Why Are Projects Late? • an unrealistic deadline established by someone outside the software development group • changing customer requirements that are not reflected in schedule changes; • an honest underestimate of the amount of effort and/or the number of resources that will be required to do the job; • predictable and/or unpredictable risks that were not considered when the project commenced; • technical difficulties that could not have been foreseen in advance; • human difficulties that could not have been foreseen in advance; • miscommunication among project staff that results in delays; • a failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem CS451 - Lecture 5

39. Scheduling Principles • compartmentalization—define distinct tasks • interdependency—indicate task interrelationshipsffort validation—be sure resources are available • defined responsibilities—people must be assigned • defined outcomes—each task must have an output • defined milestones—review for quality CS451 - Lecture 5

40. Defining Task Sets • determine type of project • assess the degree of rigor required • identify adaptation criteria • compute task set selector (TSS) value • interpret TSS to determine degree of rigor • select appropriate software engineering tasks CS451 - Lecture 5

41. Example CS451 - Lecture 5

42. Define a Task Network CS451 - Lecture 5

43. Effort Allocation • “front end” activities • customer communication • analysis • design • review and modification • construction activities • coding or code generation • testing and installation • unit, integration • white-box, black box • regression 40-50% 15-20% 30-40% CS451 - Lecture 5

44. Tools: Timeline Chart CS451 - Lecture 5