Software Project Planning

1. Software Project Planning SEN-269 : Software Engineering Engr. Tazeen Muzammil

2. Project Planning • The overall goal of project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost and schedule. Why? • So the end result gets done on time, under budget and with quality!

3. Project Planning Task • Establish project scope • Determine feasibility • Analyze risks (Done in previous lecture) • Define required resources • Determine require human resources • Define reusable software resources • Identify environmental resources • Estimate cost and effort • Decompose the problem • Develop two or more estimates using size, function points, process tasks or use-cases • Reconcile the estimates • Develop a project schedule (Done in previous lecture)

4. Software Sope

5. What is Scope? • Software scope describes • the functions and features that are to be delivered to end-users • the data that are input and output • the “content” that is presented to users as a consequence of using the software • the performance, constraints, interfaces, and reliability that bound the system. • Scope is defined using one of two techniques: • A narrative description of software scope is developed after communication with all stakeholders. • A set of use-cases is developed by end-users.

6. Obtaining Information Necessary for 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!

7. Feasibility • Once the scope has been identified, then we ask the following questions: • Technology: Do we have the requisite technology. • Finance: Do we have the requisite finances/budget. • Resources: Do we have the requisite skilled resources.

8. Resources

9. Resources

10. Estimation

11. Estimation • Estimation of resources, cost, effort and schedule requires • experience • access to good historical information (metrics) • the courage to commit to quantitative predictions when qualitative information is all that exists • Project scope must be understood • Elaboration (decomposition) is necessary • At least two different techniques should be used • Uncertainty is inherent in the process • Estimation should define • Best case scenario • Worst case scenario

12. Why Estimate Software? • 30% of project never complete • 100-200% cost overruns not uncommon • Average project exceeds cost by 90%; schedule by 120% • 15% of large project never deliver anything • Only 16.2% of projects are successful

13. What are the consequences? • Economic • Loss of contracts • Company failure • Technical • Dependency on software growing • Managerial • Change of personnel

14. Estimation Techniques • Expert Judgment • Estimation by Analogy • Pricing to win • Decomposition Techniques (e.g. LOC, FP Based ) • Empirical models (e.g. COCOMO) • Automated EstimationTools

15. Expert Judgement • One or more experts in both software development and the application domain use their experience to predict software costs. • Process iterates until some consensus is reached. • Pros: • Little or no historical data needed. • Suitable for new or unique projects. • Relatively cheap method; Accurate if experts have direct experience of similar systems • Cons: • Very subjective. • Experts may introduce bias. • Larger number of experts will help to reduce bias • Qualification of experts may be questioned.

16. Expert Judgement-Steps • Gather a group of experts together, • Describe overall program in enough detail so experts can provide an estimate. • Each member of the expert group then does an independent of the resources needed. • Estimates are gathered anonymously and compared, • If there exists significant divergence among the estimates, the estimates will be returned to the expert group, • The expert group then discusses the estimates and the divergence and works to resolve differences, and • The expert group once again submits anonymous, independent estimates which continues until a stable estimate results.

17. Expert Judgement-Example • Three software engineers are renown in the ERP software development. • You hold interviews with each explaining the requirements, sizing level, and development process for your new system. • Each member of the group submits their opinion of the final cost and the estimate converges to $50M.

18. Estimation by Analogy • Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available. • Actual costs of similar existing system are adjusted for complexity, technical, or physical differences to derive new cost estimates • Analogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approach • Compares similarities and differences • Focus is on main cost drivers.

19. Estimation by Analogy • Pros: • Inexpensive • Easily changed • Based on actual experience (of the analogous system) • Cons: • Very Subjective • Large amount of uncertainty • Truly similar projects must exist and can be hard to find • Must have detailed technical knowledge of program and analogous system • Needs systematically maintained cost database

20. Estimation by Analogy-Steps • Determine estimate needs/ground rules, • Define new system, • Breakout new system into subcomponents for analogy estimating, • Assess data availability of historical similar systems, • Collect historical system component technical and cost data, • Process/normalize data into constant year dollars (e.g., constant FY2003$), • Develop factors based on prior system, • Example: Program Management is 10% of total development cost • Develop new system component costs. • Obtain complexity (and other translation) factors • Example: Historical database is for 4 million records and new database will need to house 24 million records => complexity factor of 6 (4*6 = 24) times the historical database cost • Apply factors to historical costs to obtain new system costs

21. Estimation by Analogy- Example Your company is developing a new IT payroll system serving 5,000 people and containing 100,000 lines of C++ code. Another company developed a similar 100,000 lines of code system for $20M for only 2,000 people. Your software engineers tell you that the new system is 25% more complicated than the other system. Other system development cost was $20M. Estimated cost for new system = 1.25 * $20M = $25M Plus 5,000/2,000, or 2.5 * $25M = $62.5M total cost

22. Pricing to win • The project costs whatever the customer has to spend on it. • This approach may seem unethical and un-businesslike. • However, when detailed information is lacking it may be the only appropriate strategy. • The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost. • A detailed specification may be negotiated or an evolutionary approach used for system development • Advantages: • You get the contract. • Disadvantages: • The probability that the customer gets the system he or she wants is small. Costs do not accurately reflect the work required.

23. Decomposition Techniques

24. Decomposition Techniques • To obtain an estimation, we can decompose the problem to be solved, or decompose the process. • Decomposition should be done in such a way that 1. size can be properly estimated, 2. cost or effort required for each component can be accurately estimated, 3. the team's ability to handle the components is well known, and

25. Problem-Based Estimation • Based on the software scope, decompose the software into problem functions that can be estimated individually. 2. Estimate LOC or FP of each function. 3. Make optimistic (sopt), most likely (sm), and pessimistic (spess) estimates for each item. Then compute the expected value: EV (Expected Value) = (sopt + 4 sm + spess)/6 4. Apply baseline productivity metrics to compute estimated cost or effort.

26. Example • Problem Statement: Take the Library management system case. Software developed for library will accept data from operator for issuing and returning books. Issuing and returning will require some validity checks. For issue it is required to check if the member has already issued the maximum books allowed. In case for return, if the member is returning the book after the due date then fine has to be calculated. All the interactions will be through user interface. Other operations include maintaining database and generating reports at regular intervals.

27. Example • Major software functions identified. • User interface • Database management • Report generation • For user interfaceSopt : 1800Sm : 2000Spess : 4000 • For database managementSopt : 4600Sm : 6900Spess : 8600 • For report generationSopt : 1200Sm : 1600Spess : 3200 EV for user interfaceEV = (1800 + 4*2000 + 4000) / 6EV = 2300 EV for database managementEV = (4600 + 4*6900 + 8600) / 6EV = 6800 EV for report generationEV = (1200 + 4*1600 + 3200) / 6EV = 1800

28. Lines of code (LOC) • Effort = 54 P-M • Cost per LOC = $ 13 P-M • Project Cost= $ 431600 • Given: • LOC Estimate = 33200 LOC • Productivity = 620 LOC/P-M(Person-Month) • Labor Rate = $ 8000 P-M Effort = LOC/Productivity Cost per LOC = Labor Rate/Productivity Project Cost= LOC estimate * Cost per LOC

29. LOC-Example

30. Function Point • Five information domain characteristics are determined and counts for each are provided and recorded in a table. • Number of user inputs • Number of user outputs • Number of user inquires • Number of files • Number of external interfaces • Once the data have been collected, a complexity value is associated with each count. Each entry can be simple, average or complex. Depending upon these complexity values is calculated.

31. Function Point • Function Point Formula: FP = Count Total * [0.65+0.01*Sum(Fi)] Fi are complexity adjustment values based on response to questions(1-14) given below. The constant values in the equation and the weighing factors that are applied to information domain are determined empirically. • Rate each factor on a scale of 0 to 5 0 - No influence 1 - Incidental 2 - Moderate 3 - Average 4 - Significant 5 - Essential • Count-total is sum of all FP entries.

32. Fi • 1. Does the system require reliable backup and recovery?2. Are data communications required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational environment?6. Does the system require on-line entry?7. Does the on-line data entry require the input transaction to be built over multiple screens or operations?8. Are the inputs, outputs, files, or inquiries complex9. Is the internal processing complex?10. Is the code designed to be reusable?11. Are master files updated on-line?12. Are conversion and installations included in the design?13. Is the system designed for multiple installations in different organizations?14. Is the application designed to facilitate change and ease of use by the user?

33. Function Point • Once function points have been calculated, productivity, quality, cost and documentation can be evaluated. • Productivity = FP / person-month • Quality = defects / FP • Documentation = pages of documentation / FP • Effort = FP Estimate/Productivity • Cost per FP = Labor rate/Productivity • Project Cost Estimate = FP * Cost per FP

34. Computing function-point metrics

35. Example (Same as LOC) 202

36. Example • Complexity weighing factors are determined and the following results are obtained.

37. Example • Estimated number of FP : • FPestimated = count-total * [0.65 + .01 * sum(Fi) ]FPestimated = 206 • From historical data, productivity is 55.5 FP/person-month and development cost is $8000 per month. • Productivity = FP/ person-monthperson-month = FP/Productivity= 202/55.5 • = 3.64 person-month • Total Cost = Development cost * person-month= 8000 * 3.64=$29100 • Cost per FP = Cost/FP= 29100/202= $144.2per FP

38. Function Point-Example Given Productivity = 6.5 FP/P-M Labor Rate = $8000/P-M

39. Process-based estimation • Most commonly-used technique for project estimation • Project is broken down into a relatively small set of tasks and the effort required to accomplish each task is estimated • Begins with a delineation of software functions obtained from the project scope

40. Process-based estimation • A series of framework activities must be performed for each function • Representative framework activities: • Customer communication • Planning / risk analysis • Engineering • Construction / release • Functions and activities may be shown together as a table:

41. Process-based estimation table

42. Process-based estimation • Once functions and activities are melded, the planner estimates the effort (person-months) required to accomplish each activity per function • Average labor rates are then applied to the estimated efforts (may vary per task) • Cost and effort for each function and activity (row and column totals) are computed as the last step

43. Empirical Estimation Models • An estimation model provides empirically derived formulas to predict effort as a function of LOC or FP. • The data used to support these models are derived from a limited sample. Thus no model is appropriate for all classes of software.

44. Empirical models Examples of Commercially Available Models • COCOMO • The Software Equation • COSTXPERT • SLIM • SEER • Costar, REVIC, etc.

45. Structure of Estimation Model E = A + B XC where A, B, and C are empirically derived constants, E is the effort in person months, and X is the estimation variable, either in LOC or FP.

46. COCOMO • COCOMO, COnstructive COst MOdel is static single-variable model. Barry Boehm introduced COCOMO models. There is a hierarchy of these models. • Model 1: • Basic COCOMO model is static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code. • Model 2: • Intermediate COCOMO model computes software development effort as a function of program size and a set of "cost drivers" that include subjective assessments of product, hardware, personnel, and project attributes. • Model 3: • Advanced COCOMO model incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step, like analysis, design, etc. • COCOMO can be applied to the following software project's categories.

47. Three Software Project's Categories • Organic -- a relatively small simple project in which small teams with good application experience work to a set of less than rigid requirements. • Semi-detached -- an intermediate project in which teams with mixed experience must meet a mix of rigid and less than rigid requirements. • Embedded -- a project that must meet tight hardware, software, and operational constraints.

48. COCOMO • The COnstructiveCOstMOdel • It is LOC-based. • Formula: E = a(KLOC)b T = cEd where E is the effort required in person-months, T is the required development time in chronological months, KLOC is the estimated size of software in thousand lines of delivered source code. The constants a, b, c, and d are listed below:

49. The Software Equation • A dynamic multivariable model E = [LOC x B0.333/P]3 x (1/t4) where • E = effort in person-months or person-years • t = project duration in months or years • B = “special skills factor” • P = “productivity parameter”

50. Automated Estimation Tools • The automated estimation tools allow the planner to estimate cost and effort and to perform what if analysis for important project variables such as delivery date or staffing. • Six generic functions: • Sizing of project deliverables • Selecting project activities • Predicting staffing levels • Predicting software effort • Predicting software cost • Predicting software schedules