ZeePedia buy college essays online


Software Project Management

<<< Previous Estimation – Tools Next >>>
 
img
Software Project Management (CS615)
LECTURE # 31
6. ESTIMATION
6.5
Estimation ­ Tools
iii.
Measuring effort for a project
c) Constructive Cost Model (COCOMO)
The COCOMO technique is another popular estimation technique. Dr: Barry
Boehm propounded this technique in 1981. COCOMO uses cost driver attributes
to calculate the effort and duration of a project. The COCOMO technique has
three levels of implementation. With each level, the complexity of the model
increases. The levels of the COCOMO technique are:
i.
Basic
ii.
Intermediate
iii.
Advanced
i.
Basic COCOMO
The basic COCOMO technique estimates the effort and cost of a software project
by using only the lines of code. You, use basic COCOMO when you need a rough
estimate of effort, such as during maintenance projects. This is because in such
projects, a majority of the work is already completed. Estimating the effort in the
basic COCOMO technique involves three steps.
1. Estimating the total delivered lines of code
2. Determining the effort constants based on the type of the project
3. Substituting values for lines of code and effort constant in a formula
You have already seen how the total delivered lines of code are estimated. The
next step in the COCOMO model is to determine the type of the project being
developed. The basic COCOMO technique considers three types of projects to
calculate effort.
­ Organic
­ Embedded
­ Semidetached
Organic projects have sufficient and defined objectives. The organizations that
undertake organic projects have ample experience in development and use small
development teams. These are simple business and financial applications; such as
a banking system and inventory system.
233
img
Software Project Management (CS615)
Embedded projects have stringent and specialized hardware, software, and human
resources requirements. Organizations usually have less experience in developing
such projects. Examples of such projects include real-time operating systems
(RTOS), industrial automation systems, and sophisticated space and aviation
systems.
Semidetached projects are a combination of the preceding two types of software
projects. A new operating system and a database management system (DBMS)
are examples of such projects.
The last step in calculating effort by using the COCOMO technique is to
substitute the values of lines of code and effort constants in the following
formula:
Ej = a1 * (KLOC)a2
In the formula, Ei is the effort for a project. The effort constants, al and a2
depend on the type of project being developed.
ii.
Intermediate COCOMO
Calculation of effort by using the intermediate COCOMO technique involves an
additional step of calculating the effort adjustment factor (EAF). The effort
adjustment factor is calculated by assigning ratings to 15 cost driver attributes.
These cost driver attributes relate to the various aspects of a software project, such
as project, product, personnel, and computer attributes. Using the intermediate
COCOMO technique, you can accurately estimate effort and cost required for a
project. Accurate estimates are very helpful to start new development projects.
Calculating the effort by using the intermediate COCOMO technique is a three-
step process:
1. Estimate the initial development effort by using SLOC. To do this, you use
the following formula:
Ei = a1 * (KLOC)a2
In the formula the initial development effort, KLOC refers to 1,000 lines of code.
The constant values a1 and a2 differ with every project.
2. The second step is to determine the relevant cost driver attributes that affect
your project intensively. This provides you with the value for EAF.
234
img
Software Project Management (CS615)
Table 1 summarizes 15 commonly used projects, personnel, and product-related
cost driver attributes. The values for each cost driver under each rating are filled
in by an organization based on past experience.
Table 1: Cost Driver Attributes
Rating
Cost Drivers
Very
Extremely
Negligible Low Average High
high
critical
Analyst Capability (ACAP)
Programmer Capability (PCAP)
Programming Language
Experience (LEXP)
Virtual Machine
Experience(VEXP)
Required Software Reliability
(RELY)
Database Size (DATA)
Software Product Complexity
(CPLX)
Execution Time Constraint
(TIME)
Main Storage Constraint
(STOR)
Computer Turnaround Time
(TURN)
Virtual Machine Volatility
(VIRT)
Use of Software Tools (TOOL)
Modern Programming Practices
(MODP)
Required Development
Schedule (SCED)
3. Finally, you calculate the actual effort by multiplying the weighted cost driver
attributes with the initial effort estimate. Typically, the val1,les that rate each
cost driver attribute range from 0.9 through 1.4. For example, if software
reliability (RELY) is of prime importance according to the requirements
specifications, it is provided a rating of high or a value of 1.4. Similarly, if the
time to execute a software program is of negligible importance, you assign a
rating of low or a value of 0.9. For software attributes that are of mediocre
importance, you can assign a value between 0.9 and 1.4.
235
img
Software Project Management (CS615)
Usually, in organizations, the average rating is assigned a static value of 1.0. To
calculate the estimated effort using the intermediate COCOMO technique, you
use the formula:
E = EAF * Ei
Consider an example for using the intermediate COCOMO technique to calculate
the estimated total effort of a project life cycle. In a customized insurance project,
there are four modules. The total effort estimate of the modules is 3.0 KLOC. The
management has identified four cost driver attributes with the respective
multiplying factors that might affect the project most. In this situation, the values
of al and a2 are 3.2 and 1.05, respectively, because the insurance project is an
organic project. Therefore, you apply the following formula to calculate the initial
effort estimate.
Ei = a1 (KLOC)a2
Ei =3.2 * 31.05
Ei = 3.2 * 3.16
Ei = 10.11
The values assigned to the cost driver attributes that are applicable to a particular
software application are displayed in Table 2. According to the table, the time to
execute a software program is of high importance. Therefore, the attribute TIME
is assigned a value of 1.35. In contrast, the software application does not require a
very high analyst involvement. Therefore, the value assigned to ACAP is very
low or 0.95. Using the same logic, the values for other cost driver attributes are
assigned.
Table 2: Applicable Cost Driver Attributes
Applicable cost driver attributes
Rating
Multiplying factors
CPLX
High
1.2
TIME
Very high
1.35
ACAP
Low
.95
MODP
Average
1.00
Referring to Table 7.9, EAP can be calculated as,
EAF = 1.2 * 1.35 * 0.95 * 1.0 EAF = 1.53
After obtaining the values for the variables Ei and EAF, you can substitute these
values in the formula to calculate the total effort.
E = EAF * Ei
E = 1.53 * 10.11
236
img
Software Project Management (CS615)
E = 15.5 person months
iii.
Advanced COCOMO
The advanced COCOl\l10 technique uses the steps of the intermediate COCOMO
technique. In addition, it uses costs driver attributes assigned to each phase of the
SDLC such as analysis and design.
·
Applicability of COCOMO
COCOMO is flexible and capable of using SLOC, FP, and even object points.
Object points are measurable code sections in an object-oriented programming
language, such as C++, Ada, and Java.
You can use COCOMO when the size of a project is extensive and the
requirements of the project are vague. In contrast, SLOC and FP can be used for
projects where either the requirements are more or less known or developers
possess the relevant experience in developing projects.
COCOMO is suitable for complex and sophisticated projects that are expected to
operate within intensive hardware, software, and personnel constraints.
Generally, you can use COCOMO when the software development environment
is new to an organization. In addition, you can use COCOMO when you do not
have baseline data about past projects. However, you need complete data about
your current project to assign weight age to each cost driver attribute. You can use
FP or SLOC techniques when you have enough past project data to assign
accurate weight age to the 14 GSC s and the various information domain value
elements.
d) Delphi Technique
The Delphi technique is a Human-based estimation technique. Human-based
estimation techniques use human experience and analytical skills to estimate the
size, productivity, and effort required for a project. This is a trusted technique and
is widely used in many established organizations to facilitate practical and
reasonable estimation.
The rationale of using the Delphi technique is that when many experts
independently arrive at the same estimate on the basis of similar assumptions, the
estimate is likely to be correct.
The Delphi technique has eight basic steps:
1. Identify the terms that need to perform the estimation activity. In an estimation
activity meeting, three distinct groups of people need to be present.
237
img
Software Project Management (CS615)
·
Estimation experts: They usually consist of groups of five or six experienced
project managers. The estimation values provided by the project managers are
based on past project history and their knowledge. However, only those
project managers should b~ invited for estimation whose experience of a past
project matches that of the current project. Otherwise, estimation values may
turn out to be far from realistic.
·
Estimation coordinator: An estimation coordinator is very similar to a
moderator in a usual meeting. The coordinator facilitates the meeting and
ensures that the goals of the meeting are fully achieved.
·
Author: An author is similar to a recorder of minutes in a meeting.
2. The author presents the project details including clients' needs and system
requirements to the group of experts. The author also describes the expectations
from the group. The author and experts jointly identify the tasks that need to be
estimated. They also identify the valid assumptions that they need to consider
while estimating. For example, while estimating the effort needed to create a
high-level design, they can assume that the SRS document is approved by the
client.
3. The author and experts arrive at a consensus that any estimation with a specific
variance value will not be accepted. For example, they may decide that any
variance above 25 percent will not be accepted as an estimation value for
computing the project effort or the productivity.
4. The coordinator prepares a list of tasks jointly decided by the team and
distributes the list to all experts. These tasks comprise a project plan.
5. The experts independently make their estimates for each task. After recording
their estimates, they hand over their estimates to the coordinator. This is a critical
step. While making estimates, no discussions or consultations are permitted
because a mutual discussion may influence the estimation logic of the fellow
experts. The coordinator and the author jointly ensure this.
6. The coordinator prepares a summary of estimates for each task in a table as
represented in Table 7.10. After calculating the percentage of variance, the
coordinator marks each task as accepted or not accepted based on the agreed
accepted value.
7. The coordinator hands over the summary to the group of experts and the author.
The group of experts and the author discuss tasks and assumptions where the
percentage of variance is more than the acceptable level. The maximum and
minimum estimates of tasks are not disclosed or discussed. For example, in Table
7.10, the group and the coordinator do not accept the high-level design task
because it exceeds the agreed variance value of 25%. Therefore, the team would
discuss this task to estimate its maximum and minimum effort afresh. To resolve
238
img
Software Project Management (CS615)
the high percentage of the variance value, some tasks may be broken down
further or combined. This activity of breaking down tasks into smaller levels
involves fresh estimates for those tasks at the smaller levels.
8. Revert to step 5 and repeat the steps. You do this until all tasks are assigned
estimates that have an acceptable percentage of variance value. Figure 7.4.
summarizes the steps of the Delphi technique in the form of a flowchart.
Identify the teams that will
estimate.
Present project details to the expert
group.
Finalize the acceptable variance
value.
Prepare a list of tasks.
Estimate done by the expert group
Prepare a summary of estimates
for each task.
Discuss tasks and assumptions for
not acceptable estimates.
239
img
Software Project Management (CS615)
Repeat steps until all estimates are
finalized.
Figure 1: Steps of the Delphi Technique
The Delphi technique is a simple and subjective method of estimation. However,
it is a very effective method because most of the estimates are tried and tested.
You can use this method if the project is small or if you have the data and
expertise that can enable unambiguous estimates.
240
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration