2. Process Metrics – All those measurements of a software product which depend upon the development environment are called ‘Process Metrics’
6.2.4 COCOMO (COnstructive COst estimation MOdel) – An Empirical Estimation Model for Effort
The Constructive Cost Model (COCOMO) was developed by ‘Boehm’ in 1981 and is based on study of 63 projects. It estimates the total effort in terms of ‘person-months’ of the technical project staff. The effort estimate includes ‘development’, ‘management’, and ‘support tasks’.
The estimation through this model starts with to obtain an initial estimate of the development effort from the estimate of thousands of delivered lines of source code (KDLOC). After this step determine a set of 15 multiplying factors from different attributes of the project; and then adjust the effort estimate by multiplying the initial estimate with all the multiplying factors.
According to the COCOMO, Software projects are categorized into three types –
1. Organic : Project area in which the organization has considerable experience and requirements are less. Such systems usually developed by a small team. For example, ‘Simple business system’.
2. Embedded : The organization has little experience. System is highly affected from the environment like software, people or hardware. For example, Real time systems.
3. Semidetached : This is the combination of both systems. For example, developing a new operating system and a simple business management system.
The basic features of these three types of project are shown in the given table-Table 6.2 Types of Project
Organic Embedded Semidetached
Project Size Small Any Size Large
Type of Project Independent Product embedded in environment with several constraints
Independent
Development Experience
Extensive Moderate Moderate
Environment Knowledge
Extensive Normal Considerable
Constant Values a = 2.4, b=1.05 a = 3.6, b=1.20 a = 3.0, b=1.12
The ‘initial estimate’ which is also called ‘nominal estimate’ is determined by an equation, using KDLOC as the measurement of size. To determine the effort E in person-months, the following equation is used
-E = a * (SIZ-E) b Where, E = effort in ‘person-month’
a, b = Constants, values depends on the type of the project SIZE = in KDLOC
So, effort formulas for three types of project are-Organic : E = 2.4 * (KDLOC)1.05 Embedded : E = 3.6 * (KDLOC)1.20 Semidetached : E = 3.0 * (KDLOC)1.12
According to the ‘Intermediate COCOMO’ and ‘Detailed COCOMO’, Boehm proposed fifteen different attributes which are used to measure cost called ‘Cost driven attributes’. All these factors depend on
‘Product attributes’, ‘Computer attributes’, ‘Personnel attributes’’ and ’Project attributes’ attributes.
The ‘Cost Driven Attributes’ are shown below,
Product Attributes Software Reliability Size of application database Complexity
Computer Attributes Performance Requirements Memory Constraints Volatility of Virtual Machine Environment Turn Around Time
Personnel Attributes Analyst Capability Software Engineering Capability Applications Experience Virtual Machine Experience Programming Language Expertise Project Attributes Use of Software Tools Application of Software Engineering Methods
Required Development Schedule
Each of these cost drivers for a given project is rated at a scale:
Very Low
High
Very High
Extra High
The scale describes the proportion in which cost driver applies to a project. Values corresponding to each of the six ratings are also defined. The multiplying factors for all 15 cost drivers are multiplied to get the
‘Effort Adjustment Factor’ (EAF). The ‘Final Effort Estimate’ (E) is obtained by multiplying the initial estimate by the EAF:
E = a (KDLOC) *EAFb
Boehm also proposed standard development time (D) based on the project type and project size in months. For different types of projects, D is computed using formulas given as under –
For ‘Organic Project’ : D = 2.5 * (E)0.38 For ‘Semidetached’ : D = 2.5 * (E)0.35 For ‘Embedded’ : D = 2.5 * (E)0.32 Exercise
-The values of size in KDLOC and different cost drivers for a project are given below-Size = 200 KDLOC
Cost driver:
Software Reliability: 1.15 Use of Software Tools: 0.91 Product Complexity: 0.85 Execution Time Constraint: 1.00
Calculate the effort for three types of projects i.e. Organic, Semidetached, and Embedded using COCOMO Model.
Solution –
Effort Adjustment Factor (EAF) is:
EAF = 1.15 * 0.91*0.85*1.00 = 0.8895 Effort for three types of projects is:
Organic Project
E = 3.2 * (200) 1.05 * 0.8895 = 742 person months Semidetached Project
E = 3.0 * (200) 1.12 * 0.8895 = 1012 person months Embedded Project
E = 2.8 * (200) 1.2 * 0.8895 = 1437 person months 6.3 Risk Management
Software Engineering is the technical and managerial discipline and it is concerned with the systematic invention, production, and maintenance of high quality software products delivered on time, at minimum cost. The global IT software industry stands to lose billions each year in project overruns, and reworking software. According to survey reports, as much as 40% of software development costs alone can be spent reworking software. Furthermore, on average only one in six software projects will be delivered on time and to budget, and in some large organizations only 10% of their projects will come in on time and to budget.
Given figure outlines some major causes of project failure.
Managerial Issues - account for 65 percent of failure
•
Technical Issues - account for 35 per cent of failure
Inappropriate project structure and channels of communication Inappropriate resources (poor skill and knowledge mix) Inappropriate estimates
Inappropriate planning methods (poor scheduling and tracking) Inappropriate user buy-in
Inappropriate technical reviews (and quality audits)
•
Figure 6.2: Major causes of project failure
The term software risk management can mean different things to many different people, in considering what is meant by risk we need to understand the qualitative, quantitative and philosophical aspects of what constitutes risk. There are numerous definitions on what constitutes risk; an appropriate definition is as follows:
Risk is a combination of an abnormal event or failure and the consequences of that event or failure to a system’s operators, users or environment. A risk can range from catastrophic (loss of an entire system; loss of life or permanent disability) to negligible (no system damage or injury).
(Glutch, 1994)
If not examined at the outset the threats listed below, usually end up downstream as major causes of project failure.
Business Technological
• Pricing strategy • Production limitations
• • Payments and royalties Degree of innovation Potential for customer participation Proprietary technology
Timing of introduction Patents (s)
Stakeholder influence Technology uniqueness
Figure 6.3: Some threats to industry-wide software projects
Regardless of size and scope, every project is threatened by risk. Software projects are especially susceptible to risk due to the speed of development in the field and its rapidly changing environment. ‘Barry Boehm’
identified a ‘Top-10’ list of major software development areas where risk must be addressed:
1. Skill shortfalls
2. Unrealistic schedules and budgets
3. Stability of external or off-the-shelf software 4. Requirements mismatch
5. User interface mismatch
6. Architecture, performance, quality 7. Requirement changes
8. Legacy software
9. Externally performed tasks
10. Straining computer science capabilities.
According to ‘McManus’ other key risk area includes the
following-1. Infrastructure limitations
2. Procurement of infrastructure
3. Multi-site software development
4. Untested development methodologies
5. Regulatory standards (for example, health and safety)
6. Inadequate test strategy
7. Development team involved in multiple projects or other activities
8. Communication problems
9. Availability of test sites or personnel.
Software development is a very complex activity. The software problem has numerous elements with extremely complicated interrelationships. Problem element relationships can be multidimensional. The laws of proportionality do not govern changes in elements. It is well documented that adding more people to a project that is behind schedule, in many instances, will make it even later. Software problem elements are unstable and changeable. Although cost and schedule may be fixed, actual costs in labour and time to complete are difficult to project. The development process is dynamic. Conditions ceaselessly change;
thus, project equilibrium is rarely achieved. The environment is never static – hardware malfunctions, personnel quit, and contractors do not deliver. People are an essential software development element and a major source of risk.
Additionally, there are other interrelated factors that contribute to software risk. These factors are:
Communication about risk is one of the most difficult, yet important. People do not want to talk about potential problems. Effective risk planning only occurs when people are willing to talk about risks in a non-threatening, constructive environment.
Software size can affect the accuracy and efficacy of estimates. Interdependence amongst software elements increases exponentially as size increases. With extremely large software systems, handling complexity through decomposition becomes increasingly difficult because even decomposed elements may be unmanageable.
Software architecture also affects software risk. Architectural structure is the ease with which functions can be modularized and the hierarchical nature of information to be processed. It is also development team structure, its relationship with the user and to one another, and the ease with which the human structure can develop the software architecture.
Identification and prioritization of risks enable project managers and project staff to focus on the areas with the most impact to their project. Appropriate risk mitigation actions reduce overall project risk thus accelerating project completion. Projects that finish sooner cost less, plus risk mitigation actions can further reduce project cost. Projects using software risk management have more predictable schedules; they experience fewer surprises, since they have identified risks before they can become problems. Risk management doesn’t necessarily mean avoiding projects that could incur a high level of risk. Preparing a detailed risk assessment for a software project is costly and time consuming; however, in the long run the benefits that accrue normally outweigh the cost involved. Software risk management experts agree that the costs associated with taking a few preventative measures early on are negligible when compared to the dramatic costs that can be incurred when proper risk management techniques are neglected.
6.4 Summary
Cost and Schedule estimation are the fundamental requirements to the project management. A software project estimate is the most knowledgeable statement that can be made at a particular point in time regarding effort, cost, schedule, and risk. A complete estimate covers definitions, uncertainties, ground rules, and assumptions. The ‘Software Decomposition’ is usually defined as breaking up a system into its component parts. There are two main software decomposition techniques- 1). Object Oriented Programming and 2). Component-based Development (CBD) or Software Componentry. The software decomposition techniques are used to estimate the size, cost and effort by three main different ways – a). Software Sizing; b). Problem based estimation and c). Process- based estimation. SLOC is a software metric used to measure the amount of code in a program. SLOC is used to estimate the amount of effort that will be required to develop a program as well as to quantify productivity or effort once the software is produced. ‘Token Count’ measure is the solution of the drawback of SLOC size measure. Function points measure delivered functionality in a way that is independent of the technology used to develop the system. Function points compute size by counting functional components (inputs, outputs, external interfaces, files, and inquiries). The Constructive Cost Model (COCOMO) was developed by ‘Boehm’ in 1981. It estimates the total effort in terms of ‘person-months’ of the technical project staff. The effort estimate includes ‘development’, ‘management’, and ‘support tasks’.
6.5 Self Assessment Questions
1. Discuss the usefulness of ‘Software Decomposition’.
2. What are the decomposition techniques? Discuss problem based estimation and process based estimation in brief.
3. Explain the ‘SLOC’ method of software size measurement.
4. Give your critical views, whether SLOC based estimation is an effective method or not.
5. What is ‘COCOMO’? Describe the various modes of COCOMO estimation model given examples of application falling in each area.
6.6 References
Pressman R.S., ‘Software Engineering: A Practitioner’s Approach’, (Fifth Edition), McGraw-Hill, 2001.
Keswani Bright, ‘Software Engineering’, (First Edition), Genius Publications, 2009.
Jalote Pankaj, ‘An Integrated Approach to Software Engineering’, (Second Edition), Narosa Publishing House, 1997.
Puri S. and Singh G., ‘Software Engineering Vol. 1’, (Fourth Edition), Genius Publications, 2008.
Sommerville I., ‘Software Engineering’, (Sixth Edition), Pearson Education, 2002.
Schach S.R., ‘Software Engineering’, (Seventh Edition), Tata McGraw-Hill, New Delhi, 2007.
Mall R., ‘Fundamentals of Software Engineering’, (Sixth Edition), Prentice-Hall of India, 2002.
Gill N.S., ‘Software Engineering: Software Reliability, Testing and Quality Assurance’, Khanna Book Publishing Co (P) Ltd, New Delhi, 2002
Sabharwal S., ‘Software Engineering: Principles, Tools and Techniques’, (Second Edition), Umesh Publications, Delhi, 2005.