CS615 – Software Engineering I |
Lecture 10 |
COCOMO II
·
COCOMO is a model designed by Barry Boehm
to give an estimate of the number of programmer-months it will take to develop
a software product.
·
This "COnstructive
COst MOdel" is based on a study of about sixty projects at TRW, a Californian
automotive and IT company, acquired by Northrop
Grumman in late 2002. The programmes examined ranged in size from 2000 to
100,000 lines of code, and programming languages used ranged from assembly to
PL/I.
·
Cocomo consists of a
hierarchy of three increasingly detailed and accurate forms.
Important
observation: personnel motivation
overwhelms all other parameters.
·
suggests that
leadership and teamsmanship are the most important skills of all, but this
point was largely ignored.
Interface
type
|
Multiplier
|
No GUI
|
2.0
|
Text-based user interface
|
2.25
|
GUI
|
2.5
|
Complex GUI
|
3.0
|
expected cost = SUM[ (path probability)i x (estimated path cost)i ]
For example, the expected cost to build is:
expected costbuild = 0.30($380K)+0.70($450K) = $429 K
similarly,
expected costreuse = $382K
expected costbuy = $267K
expected costcontract = $410K
Causes of Software
Lateness:
·
Software project
scheduling - activity that distributes estimated effort across the
planned project duration by allocating the effort to specific software
engineering tasks.
·
Schedule evolves over
time.
o
Early stages of
planning - macroscopic schedule - identifies all major
software engineering activities and the product functions to which they are
applied.
o
Project under way - detailed
schedule - each entry on the macroscopic schedule is refined.
Here, s
§
specific software tasks
are identified and scheduled.
·
Two Points of view
for Scheduling
·
Principles guiding
software project scheduling:
o Compartmentalization. The project must be compartmentalized into a number
of manageable activities and tasks.
o Interdependency. The interdependency of each compartmentalized activity or task must be
determined. Some tasks must occur in sequence while others can occur in
parallel.
o Time allocation.
§
Each task to be
scheduled allocated some number of work units
§
Each task assigned a
start date and a completion date that are a function of the interdependencies
and whether work will be conducted on a full-time or part-time basis.
o Effort validation.
§
Every project has a
defined number of staff members.
§
As time allocation
occurs, the project manager ensures that no more than the allocated number of
people has been scheduled at any given time.
o Defined responsibilities. Every task that is scheduled should be assigned to a
specific team member.
o Defined outcomes. Every task that is scheduled should have a defined outcome. For software
projects, the outcome is normally a work product or a part of a work product.
o Defined milestones. Every task or group of tasks should be associated
with a project milestone. A milestone is accomplished when one or more work
products has been reviewed for quality and has been approved.
·
40–20–40 rule - Recommended distribution of effort across the
definition and development phases.
o
Forty percent of all
effort is allocated to front-end analysis and design.
o
Forty percent is
applied to back-end testing.
o
Twenty percent is
applied to coding.
·
Task set - collection
of software engineering work tasks, milestones, and deliverables that must be
accomplished to complete a particular project.
·
Task sets are designed
to accommodate different types of projects and different degrees of rigor.
o determine type of project
o
assess
the degree of rigor required
o
identify
adaptation criteria
select appropriate software engineering tasks
·
Most software
organizations encounter the following projects:
·
Degree of rigor is a
function of many project characteristics.
Four different degrees of rigor
can be defined:
·
Project manager must
develop a systematic approach for selecting the degree of rigor that is
appropriate for a particular project.
·
To accomplish this, project
adaptation criteria are defined and a task set selector value is computed
·
Adaptation
criteria are used to determine the recommended degree of rigor
with which the software process should be applied on a project.
Eleven
adaptation criteria are defined for software
projects:
·
Each adaptation
criterion is assigned a grade that ranges between 1 and 5
·
To select the
appropriate task set for a project, the following steps should be conducted:
o Enter grade into table.
o Value of a weighting factor ranges from 0.8 to 1.2
and provides an indication of the relative importance of a particular
adaptation criterion to the types of software developed within the local
environment.
o Entry point multiplier takes on a value of 0 or 1 and
indicates the relevance of the adaptation criterion to the project type.
o Result of the product
grade
x weighting factor x entry point multiplier
o Placed in the Product column of table for each
adaptation criteria individually.
·
This value will be used
to help select the task set that is most appropriate for the project.
·
Interpreting the TSS
Value and Selecting the Task Set
·
Once the task set
selector is computed, the following guidelines can be used to select the
appropriate task set for a project:
Task set
selector value |
Degree
of rigor |
TSS <
1.2 |
casual |
1.0 <
TSS < 3.0 |
structured |
TSS >
2.4 |
strict |
·
Overlap in TSS values
from one recommended task set to another is intended to illustrate that sharp
boundaries are impossible to define when making task set selections.
·
The task set selector
value, past experience, and common sense must all be factored into the choice
of the task set for a project.
·
Table illustrates how
TSS might be computed for a hypothetical project.
o Project manager selects the grades shown in the Grade
column.
o Project type is new application development.
o Therefore, entry point multipliers are selected from
the NDev column. T
o he entry in the Product column is computed using
Grade
x Weight x NewDev entry point multiplier
·
Value of TSS (computed
as the average of all entries in the product column) is 2.8.
·
The manager has the
option of using either the structured or the strict task set.
·
Development projects
are approached by applying the following major tasks:
1. Concept scoping determines the overall scope of the project.
2. Preliminary concept planning establishes the organization's ability to undertake
the work implied by the project scope.
3. Technology risk assessment evaluates the risk associated with the technology to
be implemented as part of project scope.
4. Proof of concept demonstrates the viability of a new technology in the software context.
5. Concept implementation implements the concept representation in a manner
that can be reviewed by a customer and is used for "marketing"
purposes when a concept must be sold to other customers or management.
6. Customer reaction to the concept solicits feedback on a new technology concept and
targets specific customer applications.
·
Development framework
activities are iterative in nature.
·
Actual development
project might approach these activities in a number of planned increments, each
designed to produce a deliverable that can be evaluated by the customer.
·
Model Selection:
o Linear process model
o Evolutionary model
·
Major tasks may be used
to define a macroscopic schedule for a project.
·
Macroscopic schedule
must be refined to create a detailed project schedule.
·
Refinement begins by
taking each major task and decomposing it into a set of subtasks (with related
work products and milestones).
Example of task
decomposition - concept scoping
for a development project:
·
Individual tasks and
subtasks have interdependencies based on their sequence.
·
It is likely that
development activities and tasks will be performed in parallel.
·
Concurrent tasks must
be coordinated so that they will be complete when later tasks require their
work product(s).
·
Task network ( activity network ) is a
graphic representation of the task flow for a project.
o
The task network
depicts major software engineering tasks.
·
Parallel tasks occur
asynchronously
o
Planner must determine
intertask dependencies to ensure continuous progress toward completion.
o Project manager should be aware of those tasks that
must be completed on schedule if the project as a whole is to be completed on
schedule.
·
Generalized project
scheduling tools and techniques can be applied with little modification to
software projects.
·
Program evaluation
and review technique (PERT) and critical
path method (CPM) are two project scheduling methods that can be applied to
software development.
·
Both techniques are
driven by information already developed in earlier project planning activities:
o Estimates of effort
o A decomposition of the product function
o The selection of the appropriate process model and
task set
o Decomposition of tasks
·
Interdependencies among
tasks may be defined using a task network.
·
Tasks (work
breakdown structure (WBS)) are defined for the product as a whole or for
individual functions.
·
PERT and CPM provide
quantitative tools that allow the software planner to
·
Important boundary
times discerned from a PERT or CPM network:
1. the earliest time that a task can begin when all
preceding tasks are completed in the shortest possible time
2. the latest time for task initiation before the
minimum project completion time is delayed
3. the earliest finish—the sum of the earliest start and
the task duration
4. the latest finish—the latest start time added to task
duration
5. the total float—the amount of surplus time or
leeway allowed in scheduling tasks so that the network critical path is
maintained on schedule.
·
Boundary time
calculations lead to a determination of critical path and provide the manager
with a quantitative method for evaluating progress as tasks are completed.
·
PERT and CPM
implemented in a variety of automated tools that are available for the personal
computer
·
Such tools are easy to
use and make the scheduling methods described previously available to every
software project manager
·
Software project
schedule - planner begins with a set of tasks
·
Effort, duration, and
start date are input for each task.
·
Tasks may be assigned
to specific individuals.
·
Timeline chart, ( Gantt
chart) generated.:
·
The project schedule
provides a road map for a software project manager.
·
Project schedule
defines the tasks and milestones that must be tracked and controlled as the
project proceeds.
·
Tracking can be
accomplished in a number of different ways:
o
Conducting periodic
project status meetings in which each team member reports progress and
problems.
o
Evaluating the results
of all reviews conducted throughout the software engineering process.
o
Determining whether
formal project milestones have been accomplished by the scheduled date.
o
Comparing actual
start-date to planned start-date for each project task listed in the resource
table
o
Meeting informally with
practitioners to obtain their subjective assessment of progress to date and
problems on the horizon.
·
Time-boxing strategy recognizes that the complete product may not
be deliverable by the predefined deadline.
o
An incremental software
paradigm is chosen and a schedule is derived for each incremental delivery.
o
Tasks associated with
each increment are time-boxed.
o
The schedule for each
task is adjusted by working backward from the delivery date for the increment.
o
A "box" is
put around each task.
o
When a task hits the
boundary of its time box (plus or minus 10 percent), work stops and the next
task begins.
·
Earned value
analysis (EVA) - qualitative approaches to project tracking
o Provides a common value scale for every software
project task, regardless of the type of work being performed.
o
The total hours to do
the whole project are estimated, and every task is given an earned value based
on its estimated percentage of the total.
·
Earned value is a
measure of progress
o Able to assess the "percent of
completeness" of a project using quantitative analysis
Following steps
performed:
1. The budgeted cost of work scheduled (BCWS) is
determined for each work task represented in the schedule.
1. The work (in person-hours or person-days) of each
software engineering task is planned.
2. BCWSi is
the effort planned for work task i.
3. To determine progress at a given point along the
project schedule, the value of BCWS is the sum of the BCWSi
values for all work tasks that should have been completed by that
point in time on the project schedule.
2. The BCWS values for all work tasks are summed to
derive the budget at completion, BAC. Hence,
BAC
= S (BCWSk) for all tasks k
3. Next, the value for budgeted cost of work
performed (BCWP) is computed.
1. The value for BCWP is the sum of the BCWS values for
all work tasks that have actually been completed by a point in time on the
project schedule.
·
The distinction between
BCWS and BCWP is that the former represents the budget of the activities that
were planned to be completed and the latter represents the budget of the
activities that actually were completed.
·
Given values for BCWS,
BAC, and BCWP, progress indicators can be computed:
Schedule performance index,
SPI = BCWP/BCWS
Schedule variance, SV = BCWP
- BCWS
·
SPI is an indication of
the efficiency with which the project is utilizing scheduled resources.
o An SPI value close to 1.0 indicates efficient
execution of the project schedule.
·
SV is an absolute
indication of variance from the planned schedule.
·
Percent scheduled for
completion = BCWS/BAC
o provides an indication of the percentage of work that
should have been completed by time t.
·
Percent complete =
BCWP/BAC
o provides a quantitative indication of the percent of
completeness of the project at a given point in time, t.
·
Actual cost of work
performed, ACWP - the sum of the
effort expended on work tasks that have been completed by a point in time on
the project schedule.
o
It is then possible to
compute
Cost
performance index, CPI = BCWP/ACWP
Cost
variance, CV = BCWP - ACWP
o CPI close to 1.0 provides a strong indication that
the project is within its defined budget.
o CV is an absolute indication of cost savings (against
planned costs) or shortfall at a particular stage of a project.
·
Throughout the software
process, a project team errors associated with each work product.
·
Error-related measures
and resultant metrics are collected over many software projects, can be used as
a baseline for comparison against error data collected in real time.
·
Error tracking can be
used as one means for assessing the status of a current project.
·
Software team performs
formal technical reviews (and, later, testing) to find and correct errors, E,
in work products produced during software engineering tasks.
·
Any errors that are not
uncovered (but found in later tasks) are defects, D.
·
Defect removal
efficiency is defined as
DRE
= E/(E + D)
·
DRE is a process metric
that provides a strong indication of the effectiveness of quality assurance
activities
·
DRE can also be used to
assist a project manager in determining the progress that is being made as a
software project moves through its scheduled work tasks.
o e.g. a software organization has collected error and
defect data over the past 24 months and has developed averages for the
following metrics:
§
Errors per requirements
specification page, Ereq
§
Errors per
component—design level, Edesign
§
Errors per
component—code level, Ecode
§
DRE—requirements
analysis
§
DRE—architectural
design
§
DRE—component level
design
§
DRE—coding
·
As the project
progresses through each software engineering step, the software team records
and reports the number of errors found during requirements, design, and code
reviews.
·
The project manager
calculates current values for Ereq, Edesign,
and Ecode.
·
Compared to averages
for past projects.
·
If current results vary
by more than 20% from the average, there may be cause for concern and there is
certainly cause for investigation.
·
For example, if Ereq
= 2.1 for project X, yet the organizational average is 3.6, one of two
scenarios is possible:
·
Each step in the
software engineering process should produce a deliverable that can be reviewed
and that can act as a foundation for the steps that follow.
·
The Software Project
Plan is produced at the culmination of the planning tasks.
·
It provides baseline
cost and scheduling information that will be used throughout the software
process.
·
The Software
Project Plan must
1. communicate scope and resources to software
management, technical staff, and the customer
2. define risks and suggest risk aversion techniques
3. define cost and schedule for management review
4. provide an overall approach to software development
for all people associated with the project
5. outline how quality will be ensured and change will
be managed.