1. Developed by Reneta Barneva, SUNY Fredonia Software Project Planning

2. Developed by Reneta Barneva, SUNY Fredonia Observations on Estimation Estimate what? resources, cost, and schedule for a software engineering effort What does it require? experience, access to good historical information, and … the courage to commit to quantitative predictions when qualitative information is all that exists. Estimation carries inherent risk and this risk leads to uncertainty.

3. Developed by Reneta Barneva, SUNY Fredonia Observations on Estimation Factors: Project complexity has a strong effect on the uncertainty inherent in planning. Complexity is a relative measure: beginner or experienced team. Project size can affect the accuracy and efficacy of estimates. As size increases, the interdependency among various elements of the software grows rapidly. Murphy's law: "What can go wrong will go wrong"—and if there are more things that can fail, more things will fail. Degree of structural uncertainty: structure refers to the ease with which the task can be subdivided.

4. Developed by Reneta Barneva, SUNY Fredonia Project Planning Objectives The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule. These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses. In addition, estimates should attempt to define best case and worst case scenarios so that project outcomes can be bounded.

5. Developed by Reneta Barneva, SUNY Fredonia Software Scope The first activity in software project planning is the determination of software scope. A statement of software scope must be bounded. Software scope describes the data and control to be processed, function, performance, constraints, interfaces, and reliability.

6. Developed by Reneta Barneva, SUNY Fredonia Software Scope Functions described in the statement of scope are evaluated and in some cases refined to provide more detail prior to the beginning of estimation. Because both cost and schedule estimates are functionally oriented, some degree of decomposition is often useful. Performance considerations encompass processing and response time requirements. Constraints identify limits placed on the software by external hardware, available memory, or other existing systems.

7. Developed by Reneta Barneva, SUNY Fredonia Software Scope: Obtaining Information Necessary for Scope How should we initiate communication between the developer and the customer? Gause and Weinberg suggest that the analyst start by asking context-free questions: Who is behind the request for this work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution?

8. Developed by Reneta Barneva, SUNY Fredonia Software Scope: Obtaining Information Necessary for Scope The next set of questions enables the analyst to gain a better understanding of the problem: How would you (the customer) characterize "good" output that would be generated by a successful solution? What problem(s) will this solution address? Can you show me (or describe) the environment in which the solution will be used? Will any special performance issues or constraints affect the way the solution is approached?

9. Developed by Reneta Barneva, SUNY Fredonia Software Scope: Obtaining Information Necessary for Scope The final set ("meta-questions”) of questions focuses on the effectiveness of the meeting: Are you the right person to answer these questions? Are answers "official"?  Are my questions relevant to the problem that you have?  Am I asking too many questions?  Can anyone else provide additional information?  Should I be asking you anything else?

10. Developed by Reneta Barneva, SUNY Fredonia Software Scope: Feasibility Once scope has been identified, it is reasonable to ask: "Can we build software to meet this scope? Is the project feasible?" Software feasibility has four solid dimensions: Technology—Is a project technically feasible? Is it within the state of the art? Can defects be reduced to a level matching the application's needs? Finance—Is it financially feasible? Can development be completed at a cost the software organization, its client, or the market can afford? Time—Will the project's time-to-market beat the competition? Resources—Does the organization have the resources needed to succeed?

11. Developed by Reneta Barneva, SUNY Fredonia Resources

12. Developed by Reneta Barneva, SUNY Fredonia Resources The development environment—hardware and software tools— provides the infrastructure to support the development effort. At a higher level are the reusable software components—software building blocks that can dramatically reduce development costs and accelerate delivery. The primary resource is people. Each resource is specified with four characteristics: description of the resource, a statement of availability, time when the resource will be required; duration of time that resource will be applied.

13. Developed by Reneta Barneva, SUNY Fredonia Resources Human Resources: The number of people required for a software project can be determined only after an estimate of development effort (e.g., person-months) is made.

14. Developed by Reneta Barneva, SUNY Fredonia Resources Reusable software components: Off-the-shelf components. Existing software that can be acquired from a third party or that has been developed internally for a past project. Full-experience components. Existing specifications, designs, code, or test data developed for past projects that are similar to the software to be built for the current project. Partial-experience components. Existing specifications, designs, code, or test data developed for past projects that are related to the software to be built for the current project but will require substantial modification. New components. Software components that must be built by the software team specifically for the needs of the current project.

15. Developed by Reneta Barneva, SUNY Fredonia Software Project Estimation In the early days of computing, software costs constituted a small percentage of the overall computer- based system cost. Today, software is the most expensive element of virtually all computer-based systems. Software cost and effort estimation will never be an exact science. Too many variables—human, technical, environmental—can affect the ultimate cost of software and effort applied to develop it.

16. Developed by Reneta Barneva, SUNY Fredonia Software Project Estimation To achieve reliable cost and effort estimates, a number of options arise: Delay estimation until late in the project (obviously, we can achieve 100% accurate estimates after the project is complete!). Base estimates on similar projects that have already been completed. Use relatively simple decomposition techniques to generate project cost and effort estimates. Use one or more empirical models for software cost and effort estimation.

17. Developed by Reneta Barneva, SUNY Fredonia Software Project Estimation Critics: First option is not practical. Cost estimates must be provided "up front." Secon option: unfortunately, past experience has not always been a good indicator of future results. Ideally, the techniques noted for each option should be applied in tandem; each used as a cross-check for the other.

18. Developed by Reneta Barneva, SUNY Fredonia Software Project Estimation Decomposition techniques take a "divide and conquer" approach to software project estimation; cost and effort estimation can be performed in a stepwise fashion. Empirical estimation models can be used to complement decomposition techniques and offer a potentially valuable estimation approach in their own right. Automated estimation tools implement one or more decomposition techniques or empirical models. In such systems, the characteristics of the development organization (e.g., experience, environment) and the software to be developed are described. Cost and effort estimates are derived from these data.

19. Developed by Reneta Barneva, SUNY Fredonia Decomposition Techniques Software sizing problem. Size refers to a quantifiable outcome of the software project. If a direct approach is taken, size can be measured in LOC. If an indirect approach is chosen, size is represented as FP.

20. Developed by Reneta Barneva, SUNY Fredonia Decomposition Techniques LOC-Based Estimation

21. Developed by Reneta Barneva, SUNY Fredonia Decomposition Techniques FP-based estimation Decomposition for FP-based estimation focuses on information domain values rather than software functions. The project planner estimates inputs, outputs, inquiries, files, and external interfaces. For the purposes of this estimate, the complexity weighting factor is assumed to be average.

22. Developed by Reneta Barneva, SUNY Fredonia Decomposition Techniques FP-based estimation

23. Developed by Reneta Barneva, SUNY Fredonia Decomposition Techniques FP-based estimation Finally, the estimated number of FP is derived: FP estimated = count-total x [0.65 + 0.01 x S (F i )] FP estimated = 375 The organizational average productivity for systems of this type is 6.5 FP/pm. Based on a burdened labor rate of $8000 per month, the cost per FP is approximately $1230. Based on the LOC estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.

24. Developed by Reneta Barneva, SUNY Fredonia Empirical Estimation Models An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP. Values for LOC or FP are estimated, but instead of using the tables described in those sections, the resultant values for LOC or FP are plugged into the estimation model.

25. Developed by Reneta Barneva, SUNY Fredonia Empirical Estimation Models A typical estimation model is derived using regression analysis on data collected from past software projects. The overall structure of such models takes the form E = A+ B (ev) C where A, B, and C are empirically derived constants, E is effort in person-months, and ev is the estimation variable (either LOC or FP). The majority of estimation models have some form of project adjustment component that enables E to be adjusted by other project characteristics (e.g., problem complexity, staff experience, development environment).

26. Developed by Reneta Barneva, SUNY Fredonia Empirical Estimation Models LOC - oriented

27. Developed by Reneta Barneva, SUNY Fredonia Empirical Estimation Models FP- oriented

28. Developed by Reneta Barneva, SUNY Fredonia The Make/Buy Decision Software engineering managers are faced with a make/buy decision. It may be further complicated by a number of acquisition options: (1) software may be purchased (or licensed) off- the-shelf, (2) "full-experience" or "partial-experience" software components may be acquired and then modified and integrated to meet specific needs, or (3) software may be custom built by an outside contractor to meet the purchaser's specifications.

29. Developed by Reneta Barneva, SUNY Fredonia The Make/Buy Decision: Decision Tree

30. Developed by Reneta Barneva, SUNY Fredonia The Make/Buy Decision: Decision Tree If the system is to be built from scratch, there is a 70 percent probability that the job will be difficult. Using the estimation techniques discussed earlier in this chapter, the project planner projects that a difficult development effort will cost $450,000. A "simple" development effort is estimated to cost $380,000. The expected value for cost, computed along any branch of the decision tree, is expected cost = Sum (path probability) i x (estimated path cost) i where i is the decision tree path. For the build path, expected cost build = 0.30 ($380K) + 0.70 ($450K) = $429K

31. Developed by Reneta Barneva, SUNY Fredonia The Make/Buy Decision: Decision Tree Following other paths of the decision tree, the projected costs for reuse, purchase and contract, under a variety of circumstances, are also shown. The expected costs for these paths are expected cost reuse = 0.40 ($275K) + 0.60 [0.20($310K) + 0.80($490K)] = $382K expected cost buy = 0.70($210K) + 0.30($400K)] = $267K expected cost contract = 0.60($350K) + 0.40($500K)] = $410K