IT314 - Software Engineering

Asim Banerjee

27th January 2011

[email protected]
 Software Size Metrics (1/2)
• Lines Of Code (LOC) Metric
– Measures the number of source code instructions
required to solve the problem
NOTE: Headers and comment lines are
ignored
– Simplest and easy to use
– LOC approach in estimation:
• It is difficult to use at the beginning of the project
• It is easy to use at the end of the project

IT314 - Software Engineering 2

 Software Size Metrics (2/2)
• Function Point Metric
– FP approach involves computing the size of
software product using the unit of FP
– Conceptual idea behind FP metric: size of
software product is directly proportional to:
• Types of functions that it performs
• Number of functions that it performs
– FP of a software product is computed as:
• Weighted sum of different type of functions performed
by the product.

IT314 - Software Engineering 3

 Phase Effort Estimation (1/2)
• The final effort estimate
E = (EAF) * Ei
gives the overall cost of the project (in person
months)
• For planning and monitoring purposes,
estimates of the effort required for the different
phases is also desirable.
• In COCOMO, effort for a phase is considered
as a defined percentage of the overall effort.

IT314 - Software Engineering 4

 Phase Effort Estimation (2/2)
NOTE: The percentage of the total effort spent
in a phase varies with the type (organic,
semidetached and embedded) and size
(small (<=2KDLOC), intermediate (~8
KDLOC), medium (~32KDLOC), large
(>=128KDLOC)) of the project.
• An estimate of percentages for project sizes
different from the one specified can be
obtained by linear interpolation.

IT314 - Software Engineering 5

 Project Complexity
• COCOMO provides three levels of models of
increasing complexity viz.
– Basic
– Intermediate
– Detailed
NOTE: The detailed model is the most
complex. It has different multiplying factors for
the different phases for a given cost driver.
The set of cost drivers applicable to a system
or module is also not the same as the drivers
for the system level.
IT314 - Software Engineering 6
Any Questions?

IT314 - Software Engineering 7

 Project Scheduling (1/2)
• Schedule estimate and staff requirement
estimation may be the most important
activities after cost estimation.
NOTE: Both are related, if phase wise cost is
available.
• The goal of schedule estimation is to
determine the total duration of the project and
the duration of the different phases.

IT314 - Software Engineering 8

 Project Scheduling (2/2)
NOTE: Though there is a relationship between
the person-month cost and the project
duration, it is not obtained by dividing the total
effort by the average staff size.

IT314 - Software Engineering 9

 Average Duration Estimation
• Single variable models can be used to determine the
overall duration of the project.
• Generally, schedule is modeled as depending on the
total effort (which in turn depends on size).
IBM Federal Systems Division uses total duration D
(in calendar months) as
D = 4.1 E0.36 (months)
COCOMO model, for organic type
D = 2.5 E0.38 (months)
NOTE: For other projects the constants vary slightly.
IT314 - Software Engineering 10
 Phase Duration Estimation
• The duration or schedule of the different
phases is obtained in the same manner as in
effort distribution i.e. by using the percentages
for the different phases.
NOTE: In COCOMO, sometimes, the detailed
design, coding and unit testing phases are
combined into one “programming phase”.

IT314 - Software Engineering 11

 Project Scheduling & Milestones
• Once we have the estimates of the effort and
time requirement for the different phases, a
schedule for the project can be prepared.
• This schedule will be used to monitor the
progress of the project.
• A conceptually simple and effective
scheduling technique is the Gantt chart, which
uses a calendar-oriented chart to represent
the project schedule.
IT314 - Software Engineering 12
Any Questions?

IT314 - Software Engineering 13

Software Development Life Cycle (1/2)
• Software life cycle:
– Series of identifiable phases that a software undergoes during its
lifetime
• Life cycle phases:
– Feasibility
– Requirements specifications
– Design
– Coding & Unit testing
– Integration
– Testing
– Maintenance

IT314 - Software Engineering 14

Software Development Life Cycle (2/2)
• Life cycle activities:
– Each life cycle phase consists of several activities
e.g. project management activities, developmental
activities, etc.
• Entry criteria for each phase:
– Preconditions for initiating a phase
• Exit criteria for each phase
– Preconditions for concluding a phase

IT314 - Software Engineering 15

Software Life Cycle Models: Comments (1/2)
• Large development teams cannot function without formal
definitions of work e.g. work breakdown structure
• Defining life cycle model encourages development of software in
systematic and disciplined manner
• Entry and exit criteria associated with the phases help in:
– Better monitoring and controlling of projects
– Better reporting of project progress e.g. no 90% complete syndrome

IT314 - Software Engineering 16

Software Life Cycle Models: Comments (2/2)
• Some well known life cycle models are:
– Classical waterfall model
– Iterative waterfall model
– Prototyping model
– Evolutionary model
– Spiral model

IT314 - Software Engineering 17

 Waterfall Model (1/3)
Feasibility Feasibility Report

Requirements Requirements document,

Project Plan, Test Plan, etc.
Design System & Detailed
design
document
Diagrammatically
the Coding
Programs
phases resemble a
Finished Product
group of cascading Testing
waterfalls Test Report

Maintenance

time
IT314 - Software Engineering 18
 Waterfall
% Effort
Model (2/3)

Each phase 60
requires 50
relatively 40
different 30
amount of
20
effort
10
Note:
Maintenance 0
and Testing Requirements
Feasibility

Coding

Testing

Maintenance
Design
phases
consume
sizable effort

IT314 - Software Engineering 19

 Waterfall Model (3/3)
• Waterfall model:
– Most easy to understand model
• Too simplistic
– Well suited for only well-understood problems
• Not very good for improving “product
visualization”
Note: Without adequate product visualization, it
is very difficult to manage software
development projects i.e. if it is difficult to
visualize, it will be difficult to manage
IT314 - Software Engineering 20
Waterfall Model - Work Products (1/2)
Some of the work products of the waterfall model are:
• Systems Requirements Specification Document
• Project Plan
• System Design Document
• Detailed Design Document
• Test Plan (with test cases)
• Test Report
• Final Code
• Software manuals (e.g. User manual, Installation
manual, etc.)
• Review Reports
IT314 - Software Engineering 21
Waterfall Model - Work Products (2/2)
NOTE: Any other document that enables the
project team to achieve its project objectives,
should be maintained as one of the work
products of the project.

IT314 - Software Engineering 22

 Waterfall model – Limitations (1/2)
• Real projects rarely follow the sequential flow
that the model proposes.
• The model requires that all the requirements
are stated explicitly.
• Changes can cause confusion as the project
proceeds.
• The model has difficulty in accommodating the
natural uncertainty that exists in many
projects.

IT314 - Software Engineering 23

 Waterfall model – Limitations (2/2)
• The working versions of the programs are
available only late in the project time span,
hence the customer must have patience.
• A major blunder, if undetected until working
program is reviewed, can be disastrous.

IT314 - Software Engineering 24

Any Questions?

IT314 - Software Engineering 25

 That’s all for now…

We’ll continue in the next class.

IT314 - Software Engineering 26