1. 1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 5 Software Project Planning

3. 3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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!

4. 4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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?

5. 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Write it Down! SoftwareProjectPlan Project Scope EstimatesRisksSchedule Control strategy

6. 6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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  Then ask: Can we build software to meet this scope? Is the project feasible?  understand that... Even when you understand, nothing is guaranteed!

7. 7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Feasibility  Once scope has been identified we ask:  Can we built software to meet this scope?  Is the project feasible?  Remember:  Technical feasibility is important, but business need is even more important. It does no good to build a high tech system or product that no one really wants.

8. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Resources and Cost Estimation project scope must be explicitly defined 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

9. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Resources  Resources to be measured include:  Human resources (# of people required, skills, etc.)  Reusable Software resources in four possible categories:  Off-the-shelf components: Exist software which we either have or buy from a third party.  Full-experience components: Existing modules developed for past projects similar to the currently developed one.  Partial-experience components: Existing modules developed for past projects, related to the current project but which will required extensive modifications.  New components  Environmental resources (hardware and software)

10. 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Estimation Techniques  past (similar) project experience  conventional estimation techniques  task breakdown and effort estimates  size (e.g., FP) estimates  tools (e.g., Checkpoint)

11. 11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Remember:  Project complexity, project size, and the degree of structural uncertainty all affect the reliability of estimates.  The availability of historical information has a strong influence on estimation risk.  The more you know, the better you estimate. Therefore, update your estimates as the project progresses.

12. 12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Functional Decomposition Statement of Scope perform a "grammatical parse“* functionaldecomposition * We isolate all nouns and verbs in the scope statement

13. 13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Creating a Task Matrix Obtained from “process framework” applicationfunctions framework activities Effort required to accomplish each framework activity for each application function

14. 14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Conventional Methods: LOC/FP Approach  compute project size using the direct measure LOC or the indirect measure FP and estimates of information domain values  use historical effort for the project  S = (S opt +4S m +S pess )/6 S (Size), S opt (optimistic), S pess (pessimistic), Sm (most likely) S (Size), S opt (optimistic), S pess (pessimistic), Sm (most likely)

15. 15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Example: LOC Approach

16. 16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Example: FP Approach

17. 17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Tool-Based Estimation project characteristics calibration factors LOC/FP data

18. 18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Empirical Estimation Models General form: effort = tuning coefficient * size exponent usually derived as person-months of effort required either a constant or a number derived based on complexity of project usually LOC but may also be function point empirically derived E = A + B*(ev) C

19. 19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 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

20. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Software Equation  E = [LOC*B 0.333 /P] 3 *1/t 4  Effort in person-months = [LOC * Special skills factor 0,333 / productivity parameter] 3 * 1/project duration 4

21. 21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The Make-Buy Decision

22. 22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Computing Expected Cost (path probability) x (estimated path 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) similarly, expected cost = $382K expected cost = $267K expected cost = $410K build reuse buy contr expected cost = = $429 K