Software project estimation Unit 4 Objectives To introduce

Software project estimation Unit 4

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

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 t proceed smoothly and reduce any development problem. Its basi task is to ensure that, once a development process is chosen, it i implemented optimally. �Effective s/w project management focuses on the 4 P’s: The People, The Product, The Process, and The Project.

The People �People-intensive � SEI has developed a “People Management. Capability 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.

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.

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.

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.

Metrics for Size Estimation

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-month Quality = Defects / KLOC Cost = Cost $ / LOC Documentation = 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

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.

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

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

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

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.

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

• 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 complex 9. 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?

• Once function points have been calculated, productivity, quality, cost and documentation can be evaluated. • Productivity = FP / person-month Quality = defects / FP Cost = $ / FP Documentation = pages of documentation / FP

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

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.

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

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.

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.

Halstead metrics are : • Halstead Program Length – The total number of operator occurrences and the total number of operand occurrences. N = N 1 + N 2 And • estimated program length is, N = n 1 log 2 n 1 + n 2 log 2 n 2 • Halstead Vocabulary – The total number of unique operator and unique operand occurrences. n = n 1 + n 2 • 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 * (log 2 vocabulary) = N * log 2(n)

• • • • 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 ( ) {…} 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.

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"

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

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

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.

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.

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

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

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

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

Steps for Risk Management 1) Identify possible risks; recognize what can go wrong 2) 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 3) Rank the risks by probability and impact - Impact may be negligible, marginal, critical, and catastrophic 4) Develop a contingency plan to manage those risks having high probability and high impact

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

Risk Identification

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? "

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

Known and Predictable Risk Categories 1 -Product size risks associated with overall size of the software to be built 2 -Business impact risks associated with constraints imposed by management or the marketplace 3 -Customer characteristics risks associated with sophistication of the customer and the developer's ability to communicate with the customer in a timely manner 4 -Process definition risks associated with the degree to which the software process has been defined and is followed 5 -Development environment risks associated with availability and quality of the tools to be used to build the project 6 -Technology to be built risks associated with complexity of the system to be built and the "newness" of the technology in the system 7 -Staff size and experience risks associated with overall technical and project experience of the software engineers who will do the work

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 71 -96

Questionnaire on Project Risk (Questions are ordered by their relative importance to project success) 1) 2) 3) 4) 5) 6) 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)

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

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, and frequent

Risk Projection (Estimation)

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

Risk Projection/Estimation Steps 1) Establish a scale that indicates the probability of risk being real. (e. g. , 1 -low, 10 high) 2) Enlist the consequences of the risk 3) Estimate the impact of the risk on the project and product 4) Note the overall accuracy of the risk projection so that there will be no misunderstandings

Contents of a Risk Table • A risk table provides a project manager with a simple technique for risk projection • It consists of five columns – Risk Summary – short description of the risk – Risk Category – one of seven risk categories – Probability – estimation of risk occurrence based on group input – Impact – (1) catastrophic (2) critical (3) marginal (4) negligible – RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring, and Management Plan Risk Summary Risk Category Probability Impact (1 -4) RMMM

Risk Mitigation, Monitoring, and Management

Background • An effective strategy for dealing with risk must consider three issues (Note: these are not mutually exclusive) – Risk mitigation (i. e. , avoidance) – Risk monitoring – Risk management and contingency planning • Risk mitigation (avoidance) is the primary strategy and is achieved through a plan – Example: Risk of high staff turnover (see next slide) (More on next slide)

Background (continued) Strategy for Reducing Staff Turnover q Meet with current staff to determine causes for turnover (e. g. , poor working conditions, low pay, competitive job market) q Mitigate those causes that are under our control before the project starts q Once the project commences, assume turnover will occur and develop techniques to ensure continuity when people leave q Organize project teams so that information about each development activity is widely dispersed q Define documentation standards and establish mechanisms to ensure that documents are developed in a timely manner q Conduct peer reviews of all work (so that more than one person is "up to speed") q Assign a backup staff member for every critical technologist

Background (continued) • During risk monitoring, the project manager monitors factors that may provide an indication of whether a risk is becoming more or less likely • Risk management and contingency planning assume that mitigation efforts have failed and that the risk has become a reality • RMMM steps incur additional project cost – Large projects may have identified 30 – 40 risks • Risk is not limited to the software project itself – Risks can occur after the software has been delivered to the user

Background (continued) • Software safety and hazard analysis – These are software quality assurance activities that focus on the identification and assessment of potential hazards that may affect software negatively and cause an entire system to fail – If hazards can be identified early in the software process, software design features can be specified that will either eliminate or control potential hazards

The RMMM Plan • The RMMM plan may be a part of the software development plan or may be a separate document • Once RMMM has been documented and the project has begun, the risk mitigation, and monitoring steps begin – Risk mitigation is a problem avoidance activity – Risk monitoring is a project tracking activity – Risk management is a project management activity

Seven Principles of Risk Management Maintain a global perspective View software risks within the context of a system and the business problem that is intended to solve Take a forwardlooking view Think about risks that may arise in the future; establish contingency plans Encourage open communication Encourage all stakeholders and users to point out risks at any time Integrate risk management Integrate the consideration of risk into the software process Emphasize a continuous process of risk management Modify identified risks as more becomes known and add new risks as better insight is achieved Develop a shared product vision A shared vision by all stakeholders facilitates better risk identification and assessment Encourage teamwork when managing risk Pool the skills and experience of all stakeholders when conducting risk management activities

COCOMO Model (by Barry Boehm in 1981) • Cocomo (Constructive Cost Model) is a regression model based on LOC, i. e number of Lines of Code. • The key parameters which define the quality of any software products, which are also an outcome of the Cocomo are primarily Effort & Schedule: • Effort: Amount of labor that will be required to complete a task. It is measured in person-months units. • Schedule: Simply means the amount of time required for the completion of the job, which is, of course, proportional to the effort put. It is measured in the units of time such as weeks, months.

Organic – Project includes The team size required is adequately small, The problem is well understood and has been solved in the past and The team members have a nominal experience regarding the problem. Semi-detached – Intermediate projects in which team with mixed experience level. Mix of rigid and less than rigid requirements Embedded – A software project with requiring the highest level of complexity, creativity, and experience requirement

Types of Models • COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. Any of the three forms can be adopted according to our requirements. These are types of COCOMO model: – Basic COCOMO Model – Intermediate COCOMO Model – Detailed COCOMO Model

Basic COCOMO • Use Only Lines of code • Equations are

Intermediate COCOMO • Intermediate COCOMO takes these Cost Drivers into account • Addition to basic cocomo , various other factors such as reliability, experience, Capability includes in Intermediate COCOMO. • These factors are known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for cost estimation.

The effort calculation: E = a * (KLOC)b * EAF (person-months) D= c*(E)d P=E/D Where, E- Effort applied in person-months D – Development time in duration-in-month (use c and d coefficient from basic model) P- Total number of persons required to accomplish the project KLOC. . . kilo lines of code a, b, c, d depend on the project type

Detailed COCOMO Model – • Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step of the software engineering process. • • • The Four phases of detailed COCOMO are: Requirements Planning and Product Design Detailed design Code and unit test Integration and test

COCOMO II • To help people reason about the cost and schedule implications of their software decisions. • The original COCOMO model has been very successful, but it doesn't apply to newer software development practices as well as it does to traditional practices. • COCOMO II targets modern software projects, and will continue to evolve over the next few years.

Sub models of COCOMO II • COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates. • The sub-models in COCOMO 2 are: • Application composition model. Used when software is composed from existing parts. • Early design model. Used when requirements are available but design has not yet started. • Reuse model. Used to compute the effort of integrating reusable components. • Post-architecture model. Used once the system architecture has been designed and more information about the system is available.

The Application Composition Model Supports prototyping projects and projects where there is extensive reuse. �Takes CASE tool use into account. � This model uses Object-Points (alternatively named Application Points). Like FPs the object point is an indirect s/w measure that is computed using: �Screens (at the user interface) �Reports, and �Components likely to be required to build application.

Steps for the estimation of effort in Person. Months: 1. The first step is to count all of the object points in the application. 2. The next step is to weight them according to the table. Multiply each object by its weight and sum over all objects to give the Total Object Point Count.

• The productivity rate for different levels of developer experience and development environment maturity is given by this table:

• Effort computation PM= NAP(1 -%reuse/100) /PROD WHERE PM: effort in terms of person-months NAP: number of application points. %reuse: eg. screen, reports, modules used. PROD: object point productivity

The Early Design Stage Model • Early stage of project development • After requirements and before actual project development starts • Approximate cost estimation • Estimation based on functional points

Effort = A * (Size)B * M • Here, A-> a constant representing the nominal productivity, provisionally set to 2. 5(2. 94) • B -> Scale factor. It depends on the development flexibility, team management skills, and process maturity. • Size -> Size of the s/w • M -> Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc. (7 cost drivers)

There are 7 cost drivers 1. RCPX - product reliability and complexity; 2. RUSE - the reuse required; 3. PDIF - platform difficulty; 4. PREX - personnel experience; 5. PERS - personnel capability; 6. SCED - required schedule; 7. FCIL - the team support facilities. M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED The degree of influence of each of these factors is taken to be from 1 to 6 representing the six different levels i. e. 1 -> Very Low 2 -> Low 3 -> Nominal 4 -> High 5 -> Very High 6 -> Extra High

The Reuse Model • Code reused from earlier software system.

• Takes into account black-box code that is reused without change and code that has to be adapted to integrate it with new code. • There are two versions: • Black-box reuse where code is not modified. An effort estimate (PM) is computed. • White-box reuse where code is modified. A size estimate equivalent to the number of lines of new source code is computed. This then adjusts the size estimate for new code.

• Third category of code: • Generated automatically standard templates are integrated. • Effort for automatically generated code: PM= (ASLOC * AT/100)/ATPROD where • PM: person-month • ASLOC is the number of lines of generated code • AT is the percentage of code automatically generated. • ATPROD is the productivity of engineers in integrating this code.

When code has to be understood and integrated: ESLOC = ASLOC * (1 -AT/100) * AAM • ASLOC is the number of lines of generated code • AT is the percentage of code automatically generated • AAM is the adaptation adjustment multiplier computed from the costs of changing the reused code, the costs of understanding how to integrate the code and the costs of reuse decision making.

Post-architecture level Uses the same formula as the early design model but with 17 rather than 7 associated multipliers. • The code size is estimated as: • Number of lines of new code to be developed; • Estimate of equivalent number of lines of new code computed using the reuse model; • An estimate of the number of lines of code that have to be modified according to requirements changes.

• Detailed model Effort= A*size. B *M The exponent term (B) • This depends on 5 scale factors. Their sum/100 is added to 1. 01 • A company takes on a project in a new domain. The client has not defined the process to be used and has not allowed time for risk analysis. The company has a CMM level 2 rating.

• Precedenteness new project (4) • Development flexibility - no client involvement- Very high(1) • Architecture/risk resolution - No risk analysis - V. Low. (5) • Team cohesion - new team - nominal (3) • Process maturity - some control - nominal (3)

• Product attributes • Concerned with required characteristics of the software product being developed. • Computer attributes • Constraints imposed on the software by the hardware platform. • Personnel attributes • Multipliers that take the experience and capabilities of the people working on the project into account. • Project attributes • Concerned with the particular characteristics of the software development project.

Product Factors RELY- Required Software Reliability DATA - Data Base Size CPLX - Product Complexity RUSE - Required Reusability DOCU - Documentation match to life-cycle needs Platform Factors TIME - Execution Time Constraint STOR - Main Storage Constraint PVOL - Platform Volatility Personnel Factors ACAP - Analyst Capability PCAP - Programmer Capability AEXP - Applications Experience PEXP - Platform Experience LTEX - Language and Tool Experience PCON - Personnel Continuity Project Factors TOOL - Use of Software Tools SITE - Multisite Development SCED - Required Development Schedule