Project Planning

1. Project Planning Instructor: Dr. Jerry Gao

2. Project Planning - Software Scope - Obtaining Information Necessary for Scope - A Scoping Example - Resources - Software Project Estimation - Decomposition Techniques - Software Sizing - Problem-based Estimation - Process-Based Estimation - Empirical Estimation Models - The Structure of Estimation Models - The COCOMO Model - The Software Equation - The Make-Buy Decision Jerry Gao, Ph.D. Jan. 1999

3. Project Planning Project planning is one of the first activity in a software process. The quality and accuracy of a software project ---> affect the process, product quality, and schedule. Objectives: reasonable estimation on resources, cost, and schedule Major problem in project planning is the uncertainty of a project plan. The risks caused by: - Project complexity - Project size - The degree of structural uncertainty - Understanding of the project and system - Changes of requirements Note: a project manager should not become obsessive about estimation. Modern software engineering approaches take an iterative view of development. Revisit the estimation and revise it when the customer makes changes to requirements.

4. Software Scope The first activity in software project planning --> determination of software scope. Goal: To define a unambiguous and understandable project scope at management and technical levels. Software scope: function, performance, constraints, interfaces, and reliability. delivery deadlines, budgetary restrictions, personnel availability technical interfaces, and so on. Without these information, it is impossible - To define reasonable estimates of the cost - To conduct an effective assessment of risk - To do realistic breakdown of project tasks - To come out a manageable project schedule

5. Obtaining Information To define a project scope, we need a lot of information through a communication process. A preliminary meeting or interview is a common technique to bridge the communication gap between engineers and the customer. Analysts must ask context free questions to lead a basic understanding of the problem and the desired solutions. Communication with the customer --> - definition of the data, functions, and behavior, - the performance and constraints. Questions focus on the customer, goals, and the benefits: - 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?

6. Obtaining Information Questions focus on solutions (from the customer’s perceptions): - How would you 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 where the solution will be used? - Are there special performance issues (or constraints)? The final set of questions: (meta-questions) - Are you the right person to answer these questions? Are your answers “official”? - Are my questions relevant to the problem that you have? - Am I asking too many questions? - Is there anyone else who can provide additional information? - Is there anything else that I should be asking you? The Q&A session should be used for the first encounter only.

7. Resources People Reusable Software Components Hardware/Software Tools Reusable Software Resources: Bennatan [Ben92] suggests four software resource categories: - Off-the-shelf components: third-party software, ready for use and validated. - Full-experience components: existing specification, design, code or test data from past projects. ---> small changes and low risk. - Partial-experience components: existing specification, design, code, or test data from past projects. ---> needs a lot of changes, a fair degree of risk. - New components: new software components must be built by the software team .

8. Resources People Reusable Software Components Hardware/Software Tools Reusable Software Resources: Bennatan [Ben92] suggests four software resource categories: - Off-the-shelf components: third-party software, ready for use and validated. - Full-experience components: existing specification, design, code or test data from past projects. ---> small changes and low risk. - Partial-experience components: existing specification, design, code, or test data from past projects. ---> needs a lot of changes, a fair degree of risk. - New components: new software components must be built by the software team .

9. Resources Guidelines used by software planner when reusable components are specified as a resource: - If off-the-shelf components meet project requirements, acquire them. Because: cost is low, risk is small. - If full-experience components are available, the risks associated with modification and integration are generally acceptable. The project plan should reflect this. - If partial-experience components are available, their use for the current project should be analyzed in detail.

10. Software Project Estimation Software cost and effort estimation will never be an exact science. Too many variables can affect the ultimate cost of software and effort. For example, human, technical, environmental, political,…. To achieve reliable cost and effort estimation, a number of options arise: - Delay estimation until late in the project. --> not practical. - Base estimation on similar completed projects --> work reasonability well if the current project is quit similar to the past projects. However, past experience has not always been a good indicator. - Use relatively simple “decomposition techniques” to generate project cost and effort estimation --> a viable approach to software project estimation. - Use one or more empirical models for software cost and effort estimation. --> can be used to complement decomposition techniques and offer a potentially valuable estimation approach. --> based on the past experience in a specific environment for application projects.

11. Decomposition Techniques --> Problem decomposition and process decomposition Before an estimate can be made, the project planner must understand the scope of the software to be built and generate an estimate of its “size”. Software Sizing: The accuracy of a software project estimate is predicated on a number things: - The degree to which the planner has properly estimated the size of the product to be built. - The ability to translate the size estimate into human effort in time and cost. - The degree to which the project plan reflects the abilities of the software team - The stability of product requirements and the environment that supports the software engineering effort. Putnam and Myers [PUT92] suggest four different approaches to the sizing problem: a) Fuzzy-logic sizing b) Function point sizing c) Standard component sizing d) Change sizing

12. Problem-Based Estimation Line of code (LOC) and function points (FP) are basic metrics to measure productivity. LOC and FP data are used in two ways during software project estimation. - As an estimation variable that is used to “size” each element of the software. - As baseline metrics collected from past projects and used in conjunction with estimation variables to predict project cost and effort. As a project planner, he/she first decompose software into problem functions until each of them can be estimated individually. Next, Baseline productivity metrics (LOC/pm or FP/pm) are then applied to the appropriate estimation variable and cost (or effort) for each function. Alternatively, the planner may choose another component for sizing such as classes (or objects), changes, or business processes. For FP estimation, decomposition works differently. --> Focus on each of the information domain characteristics, such as inputs, outputs, data files, inquires, and external interfaces, and so on.

13. Problem-Based Estimation A three-point or expected value: EV = (Sopt + 4Sm + Spess)/6 (one typical example) - EV - Expected value for the estimation variable (size). - the optimistic (Sopt) estimate. - the most likely (Sm). - the pessimistic (Spess) estimate. This assumes that there is a very small probability that the actual size result will fall outside the optimistic or pessimistic values. Once the expected value for the estimation variable has been determined, historical LOC or FP productivity data are applied. Are the estimates correct? The only answer to this question is: “We can’t be sure.”

14. An Example of LOC-based Estimation A preliminary statement of software scope can be developed: The CAD software will accept two- and three- dimensional geometric data from an engineer. The engineer will interact and control the CAD system through a user interface that will exhibit characteristics of good human-machine interface design. All geometric data and other supporting information will be maintained in a CAD database. Design and analysis modules will be developed to produce required output which will be displayed on a variety of graphics devices. The software will be designed to control and interact with peripheral devices that include a mouse, digitizer, and laser printer. User interface and control facilities (UICF) 2,300 Two-dimensional geometric analysis (2DGA) 5,300 Three-dimensional geometric analysis (3DGA) 6,800 Database management (DBM) 3,350 Computer graphics display facilities (CGDF) 4,950 Peripheral control (PC) 2,100 Design analysis modules (DAM) 8,400 --------------------------------------------------------------------------- estimated lines of code 33,200 The range of LOC estimates for the 3D geometric analysis function is: Sopt = 4600, Sm = 6900 Spess = 8600

15. An Example of FP-based Estimation Information Domain Value opt. Likely pess. Est. count weight FP-count --------------------------------------------------------------------------------------------------- no. of inputs 20 24 30 24 4 96 no. of outputs 12 16 22 16 5 80 no. of inquires 16 22 28 22 4 88 no. of files 4 4 5 4 10 40 no. of external interfaces 2 2 3 2 7 14 --------------------------------------------------------------------------------------------------- count-total 318 --------------------------------------------------------------------------------------------------- Factor Value Factor Value Backup and recover 4 Data communications 2 Distributed processing 0 Performance critical 4 Existing op env. 3 On-line data entry 4 Input transaction 5 Master files updated 3 over multiple screens Information domain value complex.5 Internal processing complex 5 Code designed for reuse 4 Conversion/installation in design 3 Multiple installations 5 Application designed for change 5 Complexity adj. Factor 1.17

16. Empirical Estimation Models An estimation model for computer software uses empirically derived formulas to predict effort as a function of LOC or FP. The empirical data that support most estimation models is derived from a limited sample of projects. ---> The results from such models must be used judiciously. The Structure of 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: C E = A + B X (ev) 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).

17. The COCOMO Model Barry Boehm [BOE81]’s COCOMO stands for COnstructuve COst Model. COCOMO model is a comprehensive empirical model for software estimation. Three forms: Model 1: The Basic COCOMO model - computes the cost as a function of program size expressed in estimated lines of code. Model 2: The Intermediate COCOMO model - computes the cost as function of program size and a set of “cost drivers”, such as hardware, personnel, project attributes, .. product attribute. Model 3: The Advanced COCOMO model - incorporates all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step of the software process.

18. The COCOMO Model Basic COCOMO model: bb E = ab KLOC db D = cb E E- the effort applied in person-months. D - the development time in chronological months. Software project ab bb cb db organic 2.4 1.05 2.5 0.38 semi-detached 3.0 1.12 2.5 0.35 embedded 3.6 1.20 2.5 0.32 1.05 1.05 Example: E = 2.4 (KLOC) = 2.4(33.3) = 95 person-months 0.35 0.35 D = 2.5 E = 2.5 (95) = 12.3 months, N=E/D=95/12.3= ~8 people.

19. The COCOMO Model Intermidiate COCOMO model: bi E = ai KLOC X EAF E- the effort applied in person-months. EAF - An effort adjustment factor (EAF) typical values range from 0.9 to 1.4. Software project ai bi organic 3.2 1.05 semi-detached 3.0 1.12 embedded 2.8 1.20

20. The Software Equation The software equation [PUT92] - a multivariable model. --> assume a specific distribution of effort over the life of a software development project. (based on data from 4000 projects) 0.333 3 4 E = [LOC X B / P ] X (1 / t ) E - effort in person-months or person-years. t - project duration in months or years B - special skill factor. For small programs (KLOC = 5 - 15), B = 0.16. For programs greater than 70 KLOC, B = 0.39. P - “productivity parameter” that reflects: - overall process maturity and management practices - the extent to which good software engineering practices are used - the level of programming languages used - the state of the software environment - the skill and experience of the software team - the complexity if the application P = 2000 for real-time embedded software P = 10,000 for telecommunication systems, P = 28,000 for business application systems

21. The Make-Buy Decision In many cases, it is often more cost effective to acquire, rather than develop, computer software. Mangers are faced with a make-buy decision based on three acquisition options: - software may be purchased (or licensed) off-the-shelf - “full-experience” or “partial-experience” software components - customer-built software For more expensive software products, the following guidelines can be applied: - 1) Develop a specification for the desirable function and performance. - 2) Estimate the internal cost to develop and delivery date. - 3a) Select 3 or 4 candidate applications that best meet your specification. - 3b) Select reusable software components for applications. - 4) Develop a comparison matrix for key functions. - 5) Evaluate each software package or component. - 6) Contact other users for opinions.

22. The Make-Buy Decision- Creating a Decision Tree In the final analysis, checking the following questions: - Will the delivery date of the software product be sooner than for internally developed software? - Will the cost of acquisition plus the cost of customization be less than the cost of developing the software internally? - Will the cost of outside support be less than the cost of internal support? simple (0.30) $380,000 $450,000 difficult (0.70) $275,000 build minor changes (0.40) $310,000 reuse simple (0.20) complex (0.80) System X $490,000 Major changes (0.60) buy minor changes (0.70) $210,000 major changes (0.30) contract $400,000 Without changes (0.60) $500,000 With changes (0.40)