Software project estimation

1. Software project estimation Unit 4

2. Objectives • To introduce the fundamentals of software costing and pricing • To describe three metrics for software productivity assessment • To explain why different techniques should be used for software estimation • To describe the principles of the COCOMO 2 algorithmic cost estimation model

3. Project Management is an integrated part of software development.  It refers to manage the complete software project.  The goal is to provide the necessary support for development to proceed smoothly and reduce any development problem. Its basic task is to ensure that, once a development process is chosen, it is implemented optimally.  Effective s/w project management focuses on the 4 P’s: The People, The Product, The Process, and The Project.

4. The People  People-intensive  SEI has developed a “People ManagementCapability Maturity Model” (PM-CMM):  This model defines the key practice areas for s/w people: recruitment, selection, performance management, training, compensation, career development, organization and work design, and team/culture development.  Team leaders: Motivation, Innovative, Problem solving, influence and team building.

5. The Product  Product objectives: Overall goals (from the customer’s point of view) without considering how these goals will be achieved.  Scope: identifies its primary data, functions, and behaviors.  Alternative Solutions: Once the project objectives and scope are understood, alternative solutions are considered. The alternative solutions enable managers to select a “best” approach, given the constraints imposed by the delivery deadlines, budgetary restrictions, personnel availability, technical interfaces etc.

6. The Process  The way in which we produce the software.  Provides a framework from which a comprehensive plan for s/w development can be established.  Problem is to select the appropriate process model.  The project manager must decide which process model is appropriate for:  The customer who have requested the product  The characteristics of the product itself, and  The projcect environment in which the s/w team works.

7. The Project  In order to manage successful s/w projects, we must understand what can go wrong and how to do it right. Ten signs that indicate the project is in danger: i. S/w people don’t understand their customer’s need. ii. The product scope is poorly defined. iii. Changes are managed poorly. iv. The chosen technology changes. v. Business needs change (or ill defined). vi. Deadlines are unrealistic. vii. Users are resistant. viii. Sponsorship is loss ix. The project team lacks people with appropriate skills. x. Managers avoid practices and less ones learned.

9. Metrics for Size Estimation

10. lines of code (LOC) The expected value for estimation variable has been determined, historical LOC or FP data are applied and person months, costs etc are calculated using the following formula. Productivity = KLOC / Person-monthQuality = Defects / KLOCCost = Cost $ / LOCDocumentation = pages of documentation / KLOC • Where, • KLOC stand for no. of lines of code (in thousands). • Person-month stand for is the time(in months) taken by developers to finish the product. • Defects stand for Total Number of errors discovered

11. Advantages:  Simple to measure  It can be determined uniquely by automated tools once the project is completed. Drawbacks:  It is defined on code. For example it can’t measure the size of specification.  It characterize only one specific view of size, name length, it takes no account of functionality or complexity.  Bad s/w design may cause excessive line of code  It is language dependent.

12. In this example we have: 1 Physical Line of Code (LOC) 2 Logical Lines of Code (LLOC) (for statement and printf statement) 1 comment line

13. Advantages • Easily counted • Many existing methods use LOC as key input. • Disadvantages • Depend upon programming language • Difficult in early stage

14. Function point (FP) • Function oriented metrics focus on program "functionality" or "utility". • 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

16. To compute function points, we use FP = count-total X [ 0.65 + 0.01 * SUM(Fi) ] • Where, count-total is the sum of all entries obtained from fig. • Fi(I= 1 to 14) 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.

17. Rate each factor on a scale of 0 to 5 • 0 - No influence1 - Incidental2 - Moderate3 - Average4 - Significant5 - Essential • Count-total is sum of all FP entries.

18. Fi1. 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?

19. Once function points have been calculated, productivity, quality, cost and documentation can be evaluated. • Productivity = FP / person-monthQuality = defects / FPCost = $ / FPDocumentation = pages of documentation / FP

21. Project Cost Estimation Approach • Basic activity in project planning and measurement. • Three categories • Heuristic technique • Empirical technique • Analytical technique

22. Heuristic technique • This techniques basically uses the concept of learning from the previous project and estimate the cost. • The objective is to find a similar system produced earlier and through knowing how the properties of the new system vary from the existing one. • COCOMO is one of this type of models example.

23. Analytical and Empirical technique • Empirical estimation technique are based on the data taken from the previous project and some based on guesses and assumptions. There are many empirical estimation technique but most popular are • Expert Judgement Technique • Delphi Cost Technique

24. Expert judgement technique: • An expert makes an educated guess of the problem size after analyzing the problem thoroughly. • Expert estimate the cost of different components that is modules and sub modules of the system. Disadvantages: • Human error, considering not all factors and aspects of the project, individual bias, more chances of failure. • Estimation by group of experts minimizes factors such as individual oversight, lack of familiarity with a particular aspect of a project, personal bias and desired to win a contract through overly optimistic estimate.

25. Delphi cost estimation Experts Group E Estimation By Coordinators Role of Members: Coordinator provide a copy of Software Requirement Specification(SRS) document and a form of recording it cost estimate to each estimator. This process is Iterated for several rounds.

27. Halstead metrics are : • Halstead Program Length – The total number of operator occurrences and the total number of operand occurrences.N = N1 + N2 And • estimated program length is, N = n1log2n1 + n2log2n2 • Halstead Vocabulary – The total number of unique operator and unique operand occurrences.n = n1 + n2 • Program Volume – Proportional to program size, represents the size, in bits, of space necessary for storing the program. Minimum number of bits needed to encode program. • V = Size * (log2 vocabulary) = N * log2(n)

28. Counting rules for C language – • Comments are not considered. • The identifier and function declarations are not considered • All the variables and constants are considered operands. • Global variables used in different modules of the same program are counted as multiple occurrences of the same variable. • Local variables with the same name in different functions are counted as unique operands. • Functions calls are considered as operators. • All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators. • In control construct switch ( ) {case:…}, switch as well as all the case statements are considered as operators. • The reserve words like return, default, continue, break, sizeof, etc., are considered as operators. • All the brackets, commas, and terminators are considered as operators. • GOTO is counted as an operator and the label is counted as an operand. • The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*” (multiplication operator) are dealt separately. • In the array variables such as “array-name [index]” “array-name” and “index” are considered as operands and [ ] is considered as operator. • All the hash directive are ignored.

29. main() { int a, b, c, avg; scanf("%d %d %d", &a, &b, &c); avg = (a + b + c) / 3; printf("avg = %d", avg); } The unique operators are: main, (), {}, int, scanf, &, =, +, /, printf, ',', ; The unique operands are: a, b, c, avg, "%d %d %d", 3, "avg = %d"

31. Risk Management Introduction Risk identification Risk projection (estimation) Risk mitigation, monitoring, and management (Source: Pressman, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 2005)

32. Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it?

33. What Is Software Risk? • Risk is an expectation of loss, a potential problem that may or may not occur in the future. • It is generally caused due to lack of information, control or time. • A possibility of suffering from loss in software development process is called a software risk. • Loss can be anything, increase in production cost, development of poor quality software, not being able to complete the project on time.

34. Types of software risks • Software risk exists because the future is uncertain and there are many known and unknown things that cannot be incorporated in the project plan. • A software risk can be of two types • (1) internal risks that are within the control of the project manager and • (2) external risks that are beyond the control of project manager.

35. Definition of Risk • A risk is a potential problem – it might happen and it might not • Conceptual definition of risk • Risk concerns future happenings • Risk involves change in mind, opinion, actions, places, etc. • Risk involves choice and the uncertainty that choice entails • Two characteristics of risk • Uncertainty – the risk may or may not happen, that is, there are no 100% risks (those, instead, are called constraints) • Loss – the risk becomes a reality and unwanted consequences or losses occur

36. Risk Categorization – Approach #1 • Project risks • They threaten the project plan • If they become real, it is likely that the project schedule will slip and that costs will increase • Technical risks • They threaten the quality and timeliness of the software to be produced • If they become real, implementation may become difficult or impossible • Business risks • They threaten the posibility of the software to be built • If they become real, they put risk in the project or the product

37. Risk Categorization – Approach #1 (continued) • Market risk – building an excellent product or system that no one really wants • Strategic risk – building a product that no longer fits into the overall business strategy for the company • Sales risk – building a product that the sales force doesn't understand how to sell • Management risk – losing the support of senior management due to a change in focus or a change in people • Budget risk – losing budgetary or personnel commitment

38. Risk Categorization – Approach #2 • Known risks • Those risks that can be uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed, and other reliable information sources (e.g., unrealistic delivery date) • Predictable risks • Those risks that are guesses from past project experience (e.g., past turnover) • Unpredictable risks • Those risks that can and do occur, but are extremely difficult to identify in advance

39. Steps for Risk Management • Identify possible risks; recognize what can go wrong • Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that it will do if it does occur • Rank the risks by probability and impact - Impact may be negligible, marginal, critical, and catastrophic • Develop a contingency plan to manage those risks having high probability and high impact

40. Steps for Risk Management Identify possible risks; recognize what can go wrong Analyze each risk to estimate the probability that it will occur and the impact (i.e., damage) that it will do if it does occur Rank the risks by probability and impact - Impact may be negligible, marginal, critical, and catastrophic Develop a contingency plan to manage those risks having high probability and high impact

41. Risk Identification

42. Background • Risk identification is a systematic attempt to specify threats to the project plan • By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling them when necessary • Generic risks • Risks that are a potential threat to every software project • Product-specific risks • Risks that can be identified only by those a with a clear understanding of the technology, the people, and the environment that is specific to the software that is to be built • This requires examination of the project plan and the statement of scope • "What special characteristics of this product may threaten our project plan?"

43. Risk Item Checklist Used as one way to identify risks Focuses on known and predictable risks in specific subcategories (see next slide) Can be organized in several ways • A list of characteristics relevant to each risk subcategory • Questionnaire that leads to an estimate on the impact of each risk • A list containing a set of risk component and drivers and their probability of occurrence

44. Known and Predictable Risk Categories

45. 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

46. Questionnaire on Project Risk (Questions are ordered by their relative importance to project success) • Have top software and customer managers formally committed to support the project? • Are end-users enthusiastically committed to the project and the system/product to be built? • Are requirements fully understood by the software engineering team and its customers? • Have customers been involved fully in the definition of requirements? • Do end-users have realistic expectations? • Is the project scope stable? (More on next slide)

47. Questionnaire on Project Risk (continued) • Does the software engineering team have the right mix of skills? • Are project requirements stable? • Does the project team have experience with the technology to be implemented? • Is the number of people on the project team adequate to do the job? • Do all customer/user constituencies agree on the importance of the project and on the requirements for the system/product to be built?

48. Risk Components and Drivers • The project manager identifies the risk drivers that affect the following risk components • Performance risk - the degree of uncertainty that the product will meet its requirements and be fit for its intended use • Cost risk - the degree of uncertainty that the project budget will be maintained • Support risk - the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance • Schedule risk - the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time • The impact of each risk driver on the risk component is divided into one of four impact levels • Negligible, marginal, critical, and catastrophic • Risk drivers can be assessed as impossible, improbable, probable, and frequent

49. Risk Projection (Estimation)

50. Background • Risk projection (or estimation) attempts to rate each risk in two ways • The probability that the risk is real • The consequence of the problems associated with the risk, should it occur • The project planner, managers, and technical staff perform four risk projection steps (see next slide) • The intent of these steps is to consider risks in a manner that leads to prioritization • By prioritizing risks, the software team can allocate limited resources where they will have the most impact