My Profile
Active Members
TodayLast 7 Days
more...
Awards & Gifts
Online Exams
Fresher Jobs
Our fresher job section is exclusively for fresh graduates! Find jobs for freshers in major Indian
cities including Bangalore, Chennai, Hyderabad, Pune or Kochi
Resources
Find educational articles, blogs, discussion threads and other resources.
Colleges
Find details about any college in India or search for courses.
Advertisements
|
Software-Cost Estimation
Posted Date: 26 Apr 2008 Resource Type: Articles/Knowledge Sharing Category: Computer & Technology
|
Posted By: CONFIDENCE IS THE COMPANION OF SUCCESS Member Level: Diamond
Rating:  Points: 6
|
|
|
1.4. Cost Estimation
1.4.1. Definition
Cost estimation is the process of predicting the amount of effort required to build a software system (or) it is to determine how many resources are needed to complete the project. It is in programmer-months (PM).
1.4.2. Measurement of software size
• Lines of code (LOC) - measure of source code program length.
NCLOC is used to represent a non-commented source line of code. Therefore, NCLOC is a measure of the uncommented length. CLOC is used to represent a commented source line of code.
total length (LOC) =[ NCLOC + CLOC] (in terms of KLOC)
KLOC is used to denote thousands of lines of code.
• Function points
Function points (FP) measure size in terms of the amount of functionality in a system. Function points are computed by first calculating an unadjusted function point count (UFC).
Counts are made for the following categories:
1. External inputs – those items provided by the user that describe distinct application-oriented data (such as file names and menu selections)
2. External outputs – those items provided to the user that generate distinct application-oriented data (such as reports and messages, rather than the individual components of these)
3. External inquiries – interactive inputs requiring a response
4. External files – machine-readable interfaces to other systems
5. Internal files – logical master files in the system
i) Unadjusted Function Point Count
The individual function point items are identified and then classified as simple, average, or complex. The weights from Table 1.2a are then assigned to each item and the total is summed. This total is called the unadjusted function points.
Table 1.2a Function point weights.
Weighting Factor
Item Simple Average Complex
External inputs 3 4 6
External outputs 4 5 7
External inquiries 3 4 6
External files 7 10 15
Internal files 5 7 10
Adjusted function point count (FP) = UFC * [ a technical complexity factor (TCF)]
Components of the TCF are listed in Table 1.2b.
Table 1.2b.Components of the technical complexity factor.
F1 Reliable back-up and recovery F2 Data communications
F3 Distributed functions F4 Performance
F5 Heavily used configuration F6 Online data entry
F7 Operational ease F8 Online update
F9 Complex interface F10 Complex processing
F11 Reusability F12 Installation ease
Each component is rated from 0 to 5, where 0 means the component has no influence on the system and 5 means the component is essential. The TCF can then be calculated as:
TCF = 0.65 + 0.01(SUM(Fi))
The factor varies from 0.65 (if each Fi is set to 0) to 1.35 (if each Fi is set to 5). The final function point calculation is:
FP = UFC x TCF
1.4.3. Models
Models are used to estimate cost. It can be categorized as either cost models or constraint models. COCOMO is an example of a cost model and SLIM is an example of a constraint model.
i) Constructive Cost Model (COCOMO)
Boehm derived a cost model called COCOMO (Constructive Cost Model) using data from a large set of projects. The original COCOMO is a collection of three models:
1. a Basic model that is applied early in the project
2. an Intermediate model that is applied after requirements are specified
3. an Advanced model that is applied after design is complete. All three models take the form:
E = aS^b x EAF
where E is effort in person months, S is size measured in thousands of lines of code (KLOC), and EAF is an effort adjustment factor (equal to 1 in the Basic model) (Fenton, 1997). The factors a and b depend on the development mode.
Boehm has defined three development modes:
1. Organic mode – relatively simple projects in which small teams work to a set of informal requirements (ie. thermal transfer program developed for a heat transfer group).
2. Semi-detached mode – an intermediate project in which mixed teams must work to a set of rigid and less than rigid requirements (ie. a transaction processing system with fixed requirements for terminal hardware and software).
3. Embedded mode – a project that must operate within a tight set of constraints (ie. flight control software for aircraft).
1) Basic
The Basic COCOMO model computes effort as a function of program size. The Basic COCOMO equation is:
E = aKLOC^b
The factors a and b for the Basic COCOMO model are shown in Table 1.2c.
Table 1.2c. Effort for three modes of Basic COCOMO.
Mode a b
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20
2) Intermediate
The Intermediate COCOMO model computes effort as a function of program size and a set of cost drivers. The Intermediate COCOMO equation is:
E = aKLOC^b x EAF
The factors a and b for the Intermediate COCOMO model are shown in Table 1.3d.
Table 1.3d. Effort parameters for three modes of Intermediate COCOMO.
Mode a b
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
The effort adjustment factor (EAF) is calculated using 15 cost drivers. The cost drivers are grouped into four categories: product, computer, personnel, and project. Each cost driver is rated on a six-point ordinal scale ranging from low to high importance. Based on the rating, an effort multiplier is determined using Table 1.3e. The product of all effort multipliers is the EAF.
Table 1.3e. Software Development Effort Multipliers.
Cost Driver Description Rating
Very Low Low Nominal High Very High Extra High
Product
RELY Required software reliability 0.75 0.88 1.00 1.15 1.40 -
DATA Database size - 0.94 1.00 1.08 1.16 -
CPLX Product complexity 0.70 0.85 1.00 1.15 1.30 1.65
Computer
TIME Execution time constraint - - 1.00 1.11 1.30 1.66
STOR Main storage constraint - - 1.00 1.06 1.21 1.56
VIRT Virtual machine volatility - 0.87 1.00 1.15 1.30 -
TURN Computer turnaround time - 0.87 1.00 1.07 1.15 -
Personnel
ACAP Analyst capability 1.46 1.19 1.00 0.86 0.71 -
AEXP Applications experience 1.29 1.13 1.00 0.91 0.82 -
PCAP Programmer capability 1.42 1.17 1.00 0.86 0.70 -
VEXP Virtual machine experience 1.21 1.10 1.00 0.90 - -
LEXP Language experience 1.14 1.07 1.00 0.95 - -
Project
MODP Modern programming practices 1.24 1.10 1.00 0.91 0.82 -
TOOL Software Tools 1.24 1.10 1.00 0.91 0.83 -
SCED Development Schedule 1.23 1.08 1.00 1.04 1.10 -
3) Advanced
The Advanced COCOMO model computes effort as a function of program size and a set of cost drivers weighted according to each phase of the software lifecycle. The Advanced model applies the Intermediate model at the component level, and then a phase-based approach is used to consolidate the estimate.
The four phases used in the detailed COCOMO model are: requirements planning and product design (RPD), detailed design (DD), code and unit test (CUT), and integration and test (IT). Each cost driver is broken down by phase as in the example shown in Table 1.3f.
Table 1.3f. Analyst capability effort multiplier for Detailed COCOMO.
Cost Driver Rating RPD DD CUT IT
ACAP Very Low 1.80 1.35 1.35 1.50
Low 0.85 0.85 0.85 1.20
Nominal 1.00 1.00 1.00 1.00
High 0.75 0.90 0.90 0.85
Very High 0.55 0.75 0.75 0.70
Estimates made for each module are combined into subsystems and eventually an overall project estimate. Using the detailed cost drivers, an estimate is determined for each phase of the lifecycle.
ii) SLIM
Putnam developed a constraint model called SLIM to be applied to projects exceeding 70,000 lines of code. Putnam’s model assumes that effort for software projects is distributed similarly to a collection of Rayleigh curves. Putnam suggests that staffing rises smoothly during the project and then drops sharply during acceptance testing. The SLIM model is expressed as two equations describing relation between the development effort and the schedule. The first equation, called the software equation, states that development effort is proportional to the cube of the size and inversely proportional to the fourth power of the development time. The second equation, the manpower-buildup equation, states that the effort is proportional to the cube of the development time.
1) The Norden-Rayleigh Curve
The Norden-Rayleigh curve represents manpower as a function of time. SLIM uses separate Rayleigh curves for design and code, test and validation, maintenance, and management. A Rayleigh curve is shown in Figure 1.11.
Figure 1.11. A Rayleigh curve.
2) The Software Equation
Putnam used some empirical observations about productivity levels to derive the software equation from the basic Rayleigh curve formula. The software equation is expressed as:
Size = CE^1/3( t^4/3)
where C is a technology factor, E is the total project effort in person years, and t is the elapsed time to delivery in years.
3) The Manpower-Buildup Equation
To allow effort estimation, Putnam introduced the manpower-buildup equation:
D = E / t^3
Where D is a constant called manpower acceleration, E is the total project effort in years, and t is the elapsed time to delivery in years.
1.4.4. Automated Tools
Many models are available as automated tools. These tools allow the planner to estimate cost and effort and to perform what if analyses for important project variables.
1) Costar
Costar is an estimation tool developed by Softstar Systems. Costar will produce estimates of a project's duration, staffing levels, effort, and cost based on the original COCOMO or COCOMO II models. Planners can adjust the estimate to arrive at an optimal project plan. The main screen is shown in Figure 1.12.
Figure 1.12. Costar main screen.
2) SLIM
Putnam has extended the SLIM model to include an automated tool. The SLIM tool was developed by Quantitative Software Management. SLIM produces the chart shown in Figure 1.13.
Figure 1.13. SLIM manpower distribution.
3) Checkpoint
Checkpoint is a tool developed by Software Productivity Research. Checkpoint predicts effort at four levels: project, phases, activity, and task. Checkpoint facilitates the comparison of actual and estimated performance to various industry standards included in an internal estimation knowledge base.
|
Responses
|
| Author: Olufemi 26 Apr 2008 | Member Level: Diamond Points : 2 | This is a good paper for software professionals and it will go along way to help software developer that are thinking of standing alone or starting their software company in cost estimation of their products. It is a pity that most of the diagram in the presentation are not showing. I hope Mr. Tony will help us so that diagrams will be allowed in our write up.
Olufemi
| | Author: CONFIDENCE IS THE COMPANION OF SUCCESS 27 Apr 2008 | Member Level: Diamond Points : 2 | thnks for ur response
|
|
|