MCA II SEM

Software Effort Estimation and Activity Planning

[1]. Basis for Software Estimation,
A successful project is one delivered ‘on time, within budget and with the required quality’. A project
manager prepares the estimates of effort, which affect costs, and of activity durations, which affect the
delivery time. Due to the complexity of software, some difficulties arise in estimation. Other difficulties
include:
• Subjective nature of estimating
• Political implications
• Changing technology
• Lack of homogeneity of project experience

Parameters to be estimated
The project manager estimates two project parameters: Effort and duration.
Duration is usually measured in months. Work-month (wm) and person-month (pm). The person-month
estimate defines the productivity.
Measure of work
Measure of work is also called the size of the project. Direct calculation of cost or time is difficult at the
early stages of planning. The time may vary according to the experience of the software developers.
The size of a project is obviously not the number of bytes, neither is it the size of the executable code.
The project size defines the problem complexity in terms of the effort and time required to develop the
product.
Two methods can be used for this purpose : Source Lines of Code (SLOC) and Function Point
(FP).
the SLOC measure is easy to use and it is widely used. The SLOC method suffers from various types of
disadvantages:
1. ● No precise definition. SLOC is a very imprecise measure. Unfortunately, researchers have not been
consistent on points like does it include comment lines or are data declarations to be included? The writers’ view is
that comment lines are excluded in determining the SLOC measure. This can be debated, but the main point is that
consistency is essential.x
2. Difficult to estimate at start of a project.
3. Only a code measure
4. Programmer-dependent. SLOC gives a numerical value to the problem size that can vary widely with the
coding style of individual programmers.
5. Does not consider code complexity.

The idea behind the function point metric is that the size of a software product is directly dependent on
the number of different functions, files and interfaces. A software product supporting many features would
certainly be of larger size than a product with less number of features. Each function when invoked reads
some input data and transforms it to the corresponding output data.

[2]. Software Effort Estimation Techniques

Barry Boehm, suggested following methods for software estimation:
● algorithmic models, which use ‘effort drivers’ representing characteristics of the target system and the
implementation environment to predict effort;
● expert judgement, based on the advice of knowledgeable staff;
● analogy, where a similar, completed, project is identified and its actual effort is used as the basis of the
estimate;

1
● price to win, where the ‘estimate’ is a figure that seems sufficiently low to win a contract;
● top-down, where an overall estimate for the whole project is broken down into the effort required for
component tasks;
● bottom-up, where component tasks are identified and sized and these individual estimates are
aggregated.

[3]. Bottom-up Approach

This approach breaks the project into its component tasks. The process of breaking down is iterative. Each
task is decomposed into its subtasks and these could be further analysed. This process repeated until we
get individual tasks that can be done in a week or two. Why is this not a ‘top-down approach’?
Because, It provides a work breakdown schedule (WBS). The bottom-up part comes in adding up the
calculated effort for each activity to get an overall estimate. The bottom-up approach is best, more detailed
stages of project planning. It can help to identify characteristics of the final system. When a project is
completely new or there is no historical data available, the estimator uses the bottom-up approach.

A procedural code-oriented approach

The bottom-up approach described works at the level of activities. In software development a major
activity is writing code. Here we describe how a bottom-up approach can be used at the level of software
components.
(a) Predict the number and type of software modules in the final system
Most information systems are built from a small set of system operations, e.g. Insert, Amend, Update,
Display, Delete, Print.
(b) Estimate the SLOC of each identifi ed module
One way to judge the number of SLOC, is to draw a program structure diagram and to visualize how many
instructions would be needed to implement each procedure. The estimator may look at existing programs
which have a similar functional description to assist in this process.
(c) Estimate the work content, taking into account complexity and technical diffi culty
To know the complexity and technical difficulty, the SLOC is multiplied by a factor. This factor depends
on the subjective judgement of the estimator.
(d) Calculate the work-days effort
Historical data can be used to provide ratios to convert SLOC to effort.

[4]. The Top-down Approach and Parametric Models

The top-down approach is normally associated with parametric (or algorithmic) models. These may be
explained using the analogy of estimating the cost of rebuilding a house.
Suppose a person needs insurance cover to rebuild their property if destroyed. The person may not be able
to calculate the rebuild cost. Most insurance companies produce a set of tables where you can look up
such variables as the number of storeys your house has, the number of bedrooms, the area of floor space,
the material out of which it has been constructed, carpenter-hours, electrician-hours, and the region in
which it is located. For each combination of these characteristics, a rebuilding cost will be suggested. The
insurance company can produce such tables as it has records of the actual cost of rebuilding houses.

2
This is essentially a top-down approach because only one global figure is produced.
A parametric model will normally have one or more formulae in the form:
effort = (system size) x (productivity rate)
For example, system size might be in the form ‘thousands of lines of code’ (KLOC) and have the specific
value of 3 KLOC while the productivity rate was 40 days per KLOC. These values will often be matters
of judgement.
Suppose, Amit may estimate that the first software module to be constructed is 2 KLOC. He may then
judge that if Sumit undertook the development of the code, with her expertise he could work at a rate of
40 days per KLOCy and complete the work in 2 x 40 days, i.e. 80 days, while Vijay, who is less
experienced, would need 55 days per KLOC and take 2 x 55, i.e. 110 days to complete the task. In this
case KLOC is a size driver indicating the amount of work to be done, while developer experience is a
productivity driver influencing the productivity or work rate.
productivity = effort/size
Some parametric models, such as that implied by function points, are focused on system or task size, while
others, such are COCOMO, are more concerned with productivity factors.

[5]. Albrecht Function Point Analysis

This is a top-down method that was devised by Allan Albrecht. He developed the idea of function points
(FPs). FPA is used to make estimate of the software project in terms of functionality or function size of
the software product. The functional size of the product is measured in terms of the function point

The basis of function point analysis is that information systems comprise five major Components:
● External input (EI) are input transactions which update internal computer files.
● External output (EO)are transactions where data is output to the user. Typically these would be
printed reports, as screen displays
● External inquiry (EQ)– are transactions initiated by the user which provide information but do not
update the internal files.
● Internal Logical file (ILF)- are the files used by the system.
● External interface file (EIF)- allow for output and input that may pass to and from other computer
applications. Examples of this would be the transmission of accounting data from an
order processing system to the main ledger system
Following are the points regarding FPs
FPs are calculated by counting the number and types of functions used. Various functions used in an
application can be put under five types are EI, EO, EQ, ILF, and EIF. These five parameters are also
known as information domain characteristics. All these parameters are then individually assessed for
complexity.
All the parameters mentioned above are assigned some weights (Low, Average or High) that have been
experimentally determined and are shown in Table.
External user type Multiplier
Low Average High
External input (EI) 3 4 6
External output (EO) 4 5 7
External inquiry (EQ) 3 4 6
Internal Logical file (ILF) 7 10 15
External interface file (ELF) 5 7 10

3
After classifying each of the five function types, the UFP is computed using predefined weights for each
function type.

Once the UFP is computed, the technical complexity factor (TCF) is computed next. TCF consider 14.
Each of these 14 factors is assigned from 0 (not present or no influence) to 5 (Essential). The resulting
numbers are summed, yielding the TCF. TCF is computed as
TCF = [0.65 + 0.01 *∑(fi)]).
Finally, FP=UFP*TCF.

Ex-1 Given the following values, compute function point when all complexity adjustment factor (CAF)
and weighting factors are average.
User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Ans: As Complexity is average so ∑(fi) = 14*3 = 42
So Complexity Adjustment Factor = 0.65 + ( 0.01 * 42 ) = 1.07
As weighting factors are average so
Unadjusted Function Point = (EI*4) + (EO*5) + (EQ*4) + (ILF*10) + (ELF*7)
= (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
Function Point = UFP * CAF
= 628 * 1.07 = 671.96

[6]. Objectives of Activity Planning

A detailed project plan includes a schedule that shows the start and completion times for different activities
involved in a project.
The objectives of activity planning may be summarized as follows:
4
● Feasibility assessment Is the project possible within required timescales and resource constraints?
There are many methods to estimate cost and effort for a project. These estimates are possible only after
the activity planning.
● Resource allocation What are the most effective ways of allocating resources to the project? When
should the resources be available? The project plan allows us to investigate the relationship between
timescales and resource availability
● Detailed costing How much will the project cost and when is that expenditure likely to take place?
After producing an activity plan and allocating specific resources, we can obtain more detailed estimates
of costs and their timing.
● Motivation By the use of Activity paln we can monitor the project development and motivate the staff
as and when required.
● Coordination When do the staff in different departments need to be available to work on a particular
project and when do staff need to be transferred between projects? The project plan provides an effective
way for communication and coordination among teams. In situations where staff may need to be
transferred between project teams, a project plan ensures that such staff are available when required.
One effective way of shortening project durations is to carry out activities in parallel. Clearly we cannot
start all the activities at the same time – some require the completion of others before they can start.

[7]. Project Schedules

A project schedule can be prepared in four main stages.
1. First all types of activities are identified. Then, the order of activity execution is decided. From
this we can construct an ideal activity plan. This plan shows the staring of each activity.
2. In this step, risk associated with each activity is identified. Generally, the major risk is resources
unavailability. At this stage, the ideal activity plan may be changed.
3. The third step is resource allocation. The expected availability of resources might place
constraints on when certain activities can be carried out.
4. The final step is schedule production. Once resources have been allocated to each activity, we
will be in a position to draw up and publish a project schedule, which indicates planned start and
completion dates and a resource requirements statement for each activity.

[8]. Sequencing and Scheduling Activities

The project manager monitors the timely completion of the tasks and takes any corrective action whenever
there is a chance of schedule. In order to schedule the project activities, a software project manager needs
to do the following:
1. Identify all the major activities.
2. Break down each activity into tasks.
3. Determine the dependency among different tasks.
4. Establish the time estimates for the tasks.
5. Represent the information in the form of an activity network.
6. Determine task starting and ending dates.
7. Determine the critical path. A critical path is a chain of tasks that determines the duration of the project.
8. Allocate resources to tasks.

5
The first step in scheduling a software project involves identifying all the activities necessary to complete
the project. A good knowledge of the details of the project and the development process helps the
managers to effectively identify the important activities of the project. Next, the activities are broken down
into a logical set of smaller activities(subactivities). The smallest subactivities are called tasks which are
assigned to different developers.

After the project manager has broken down the activities into tasks, he has to find the dependency among
the tasks. Dependency among the different tasks determines the order in which the different tasks would
be carried out. If a task A requires the results of another task B, then task A must be scheduled after task
B and A is said to be dependent on B.

8.1. Activity Networks

An activity network shows the different activities making up a project, their estimated durations, and their
interdependencies. Two equivalent representations for activity networks are possible and are in use:

Activity on Node (AoN): In this representation, each activity is represented by a rectangular node and
the duration of the activity is shown alongside each task in the node. The inter-task dependencies are
shown using directional edges.

Activity on Edge (AoE): In this representation tasks are associated with the edges. The edges are also
marked with the task duration. The nodes in the graph represent project milestones.

PROBLEM Determine the Activity network representation for the MIS development project for which
the relevant data is given in Table.
TABLE Project Parameters Computed from Activity Network

Task Number Task Duration Dependent on Tasks

T1 Specification 15 -
T2 Design database 45 T1
T3 Design GUI 30 T1
6
 T4 Code database 105 T2
T5 Code GUI part 45 T3
T6 Integrate and test 120 T4 and T5
T7 Write user manual 60 T1

FIGURE: Activity network representation of the MIS problem.

[9]. Network Planning Models

These project scheduling techniques model the project’s activities and their relationships as a network. In
the network, time flows from left to right. The two best known being CPM (Critical Path Method) and
PERT (Program Evaluation Review Technique). Both of these techniques used an activity-on-arrow
approach to visualizing the project as a network. The activities are drawn as arrows joining circles, or
nodes.
A PERT chart, also known as a PERT diagram, is a tool used to schedule, and organize, tasks within a
project. It provides a visual representation of a project's timeline. These charts are similar to Gantt charts,
but structured differently.

7
PERT chart example

Another Example

[10]. Time Dimension

The critical path approach is concerned with two primary objectives:
• Planning the project in such a way that it is completed as quickly as possible
• Identifying those activities in which there may be delay.

In this method, duration of each activity is mentioned. The network is then analysed using a forward pass,
to calculate the earliest dates at which the project will be completed, and a backward pass, to calculate
the latest start dates for activities and the critical path.

8
The description and example is shown below. A project composed of eight activities whose durations
have been estimated as shown in the table.

The Forward Pass

The forward pass is carried out to calculate the earliest dates on which each activity may be started and
completed.

FIGURE : The precedence network for the example project

The forward pass and the calculation of earliest start dates are carried out according to the following
reasoning.
● Activities A, B and F may start immediately, so the earliest date for their start is zero.

● Activity A will take 6 weeks, so the earliest it can finish is week 6.

● Activity B will take 4 weeks, so the earliest it can finish is week 4.

● Activity F will take 10 weeks, so the earliest it can finish is week 10.

9
● Activity C can start as soon as A has finished so its earliest start date is week 6. It will take 3 weeks so
the earliest it can finish is week 9.
● Activities D and E can start as soon as B is complete so the earliest they can each start is week 4.
Activity D, which will take 4 weeks, can therefore finish by week 8 and activity E, which will take 3
weeks, can therefore finish by week 7.
● Activity G cannot start until both E and F have been completed. It cannot therefore start until week 10
– the later of weeks 7 (for activity E) and 10 (for activity F). It takes 3 weeks and finishes in week 13.
● Similarly, Activity H cannot start until week 9 – the later of the two earliest finish dates for the
preceding activities C and D.
● The project will be complete when both activities H and G have been completed. Thus the earliest
project completion date will be the later of weeks 11 and 13 – that is, week 13.
The results of the forward pass are shown in Figure.

FIGURE: The network after the forward pass

The Backward Pass

The second stage in the analysis of a critical path network is to carry out a backward pass to calculate the
latest date at which each activity may be started and finished. Figure illustrates network after carrying out
the backward pass. The latest activity dates are calculated as follows.
● The latest completion date for activities G and H is assumed to be week 13.

● Activity H must therefore start at week 11 at the latest (13 – 2) and the latest start date for activity G
is week 10 (13 – 3).
● The latest completion date for activities C and D is the latest date at which activity H must start – that
is, week 11. They therefore have latest start dates of week 8 (11 – 3) and week 7 (11 – 4) respectively.
● Activities E and F must be completed by week 10 so their earliest start dates are weeks 7 (10 – 3) and
0 (10 – 10) respectively.
● Activity B must be completed by week 7 (the latest start date for both activities D and E) so its latest
start is week 3 (7 – 4).

10
● Activity A must be completed by week 8 (the latest start date for activity C) so its latest start is week
2 (8 – 6).
● The latest start date for the project start is the earliest of the latest start dates for activities A, B and F.
This is week zero. This is, of course, not very surprising since it tells us that if the project does not start
on time it won’t finish on time.

FIGURE: The network after the backward pass

[11]. Identifying Critical Path

There will be at least one path in the network that defines the duration of the project. This is known as the
critical path. The difference between an activity’s earliest start date and its latest start date is known as
the activity’s float. It is a measure of how much the start or completion of an activity may be delayed
without affecting the end date of the project. Any activity with a float of zero is critical in the sense that
any delay in carrying out the activity will delay the completion date of the project. There will always be
at least one path through the network joining those critical activities – this path is known as the critical
path.

11