PBCA504: Software Engineering

Unit-II
S/W Project planning Objectives, Decomposition techniques: S/W Sizing, Problem-
based estimation, Process based estimation, Cost Estimation Model: COCOMO Model.

Software Project Planning

A Software Project is the complete methodology of programming advancement
from requirement gathering to testing and support, completed by the execution
procedures, in a specified period to achieve intended software product.

Need of Software Project Management

Software development is a sort of all new streams in world business, and there's
next to no involvement in structure programming items. Most programming items
are customized to accommodate customer's necessities. The most significant is
that the underlying technology changes and advances so generally and rapidly
that experience of one element may not be connected to the other one. All such
business and ecological imperatives bring risk in software development; hence, it
is fundamental to manage software projects efficiently.

Software Project Manager

Software manager is responsible for planning and scheduling project

development. They manage the work to ensure that it is completed to the required
standard. They monitor the progress to check that the event is on time and within
budget. The project planning must incorporate the major issues like size & cost
estimation scheduling, project monitoring, personnel selection evaluation & risk
management. To plan a successful software project, we must understand:

o Scope of work to be completed

1
 o Risk analysis
o The resources mandatory
o The project to be accomplished
o Record of being followed

Software Project planning starts before technical work start. The various steps of
planning activities are:

The size is the crucial parameter for the estimation of other activities. Resources
requirement are required based on cost and development time. Project schedule
may prove to be very useful for controlling and monitoring the progress of the
project. This is dependent on resources & development time.

Once a project is found to be possible, computer code project managers

undertake project designing. Project designing is undertaken and completed even
before any development activity starts. Project designing consists of subsequent
essential activities. Estimating the subsequent attributes of the project:

• Project size:
What’s going to be downside quality in terms of the trouble and time needed to
develop the product?
• Cost:
What proportion is it reaching to value to develop the project?

2
• Duration:
However long is it reaching to want complete development?
• Effort:
What proportion effort would be required?
The effectiveness of the following designing activities relies on the accuracy of
those estimations.

• planning force and alternative resources

• workers organization and staffing plans
• Risk identification, analysis, and abatement designing
• Miscellaneous arranges like quality assurance plan, configuration,
management arrange, etc.

Precedence ordering among project planning activities

The different project connected estimates done by a project manager have
already been mentioned. The below diagram shows the order during which vital
project coming up with activities is also undertaken. It may be simply discovered
that size estimation is that the 1st activity. It’s conjointly the foremost basic
parameter supported that all alternative coming up with activities square measure
dispensed, alternative estimations like the estimation of effort, cost, resource, and
project length also are vital elements of the project coming up with.

3
 Sliding Window Planning:

Project designing needs utmost care and a spotlight since commitment to

unrealistic time and resource estimates end in schedule slippage. Schedule
delays will cause client discontent and adversely have an effect on team morale. It
will even cause project failure.
However, project designing could be a terribly difficult activity. particularly for giant
comes, it’s pretty much troublesome to create correct plans. A region of this issue
is thanks to the actual fact that the correct parameters, the scope of the project,
project workers, etc. might amendment throughout the span of the project. So as
to beat this drawback, generally project managers undertake project designing
little by little. Designing a project over a variety of stages protects managers from
creating huge commitments too early. This method of staggered designing is
thought of as window designing. Within the window technique, beginning with
associate initial set up, the project is planned additional accurately in sequential
development stages.

At the beginning of a project, project managers have incomplete information

concerning the main points of the project. Their info base step by step improves
because the project progresses through completely different phases. When the
completion of each section, the project managers will set up every ulterior section
additional accurately and with increasing levels of confidence.

4
 Objectives of Software Project Planning
Planning aims to achieve several objectives which are as follows:

1. Feasibility Assessment

In the project possible within the required time scale and resource constraints. It is
only after we have constructed a detailed plan, that we can forecast a completion
date with some reasonable knowledge of its achievability.

2. Resource Allocation

• What are the most effective ways of allocating resources to a project?

• When should the resources be available?
• A project plan answers these questions and also allows us to find the relationship
between time scales and resource availability.

3. Detailed Costing

How much will the project cost? After creating the plan and allocating the
resources we can obtain more detailed estimates of costs and the timing.

4. Motivation

Providing the targets and monitoring the achievements is an effective way of

motivating the staff.

5. Coordination

Project Plan, particularly with large projects involving more than a single team,
provides an effective means for communication and coordination among the
teams and members. Thus, planning and scheduling aim for completing the
project in minimum time with an acceptable cost, meeting a set target date at
minimum cost.

5
 Project size estimation
Project size estimation is a crucial aspect of software engineering, as it helps in
planning and allocating resources for the project. Here are some of the popular
project size estimation techniques used in software engineering:
Expert Judgment: In this technique, a group of experts in the relevant field estimates
the project size based on their experience and expertise. This technique is often used
when there is limited information available about the project.
Analogous Estimation: This technique involves estimating the project size based on
the similarities between the current project and previously completed projects. This
technique is useful when historical data is available for similar projects.
Bottom-up Estimation: In this technique, the project is divided into smaller modules
or tasks, and each task is estimated separately. The estimates are then aggregated to
arrive at the overall project estimate.
Three-point Estimation: This technique involves estimating the project size using
three values: optimistic, pessimistic, and most likely. These values are then used to
calculate the expected project size using a formula such as the PERT formula.
Function Points: This technique involves estimating the project size based on the
functionality provided by the software. Function points consider factors such as inputs,
outputs, inquiries, and files to arrive at the project size estimate.
Use Case Points: This technique involves estimating the project size based on the
number of use cases that the software must support. Use case points consider factors
such as the complexity of each use case, the number of actors involved, and the
number of use cases.
Each of these techniques has its strengths and weaknesses, and the choice of
technique depends on various factors such as the project’s complexity, available data,
and the expertise of the team.

Estimation of the size of the software

Estimation of the size of the software is an essential part of Software Project

Management. It helps the project manager to further predict the effort and time which
will be needed to build the project. Various measures are used in project size
estimation. Some of these are:

6
• Lines of Code
• Number of entities in ER diagram
• Total number of processes in detailed data flow diagram
• Function points
1. Lines of Code (LOC): As the name suggests, LOC counts the total number of lines
of source code in a project. The units of LOC are:
• KLOC- Thousand lines of code
• NLOC- Non-comment lines of code
• KDSI- Thousands of delivered source instruction
The size is estimated by comparing it with the existing systems of the same kind. The
experts use it to predict the required size of various components of software and then
add them to get the total size.

It’s tough to estimate LOC by analyzing the problem definition. Only after the whole
code has been developed can accurate LOC be estimated. This statistic is of little
utility to project managers because project planning must be completed before
development activity can begin.

Two separate source files having a similar number of lines may not require the same
effort. A file with complicated logic would take longer to create than one with simple
logic. Proper estimation may not be attainable based on LOC.

The length of time it takes to solve an issue is measured in LOC. This statistic will differ
greatly from one programmer to the next. A seasoned programmer can write the same
logic in fewer lines than a newbie coder.

Advantages:
• Universally accepted and is used in many models like COCOMO.
• Estimation is closer to the developer’s perspective.
• Both people throughout the world utilize and accept it.
• At project completion, LOC is easily quantified.
• It has a specific connection to the result.
• Simple to use.
Disadvantages:
• Different programming languages contain a different number of lines.

7
• No proper industry standard exists for this technique.
• It is difficult to estimate the size using this technique in the early stages of the
project.
• When platforms and languages are different, LOC cannot be used to normalize.
2. Number of entities in ER diagram: ER model provides a static view of the project.
It describes the entities and their relationships. The number of entities in ER model can
be used to measure the estimation of the size of the project. The number of entities
depends on the size of the project. This is because more entities needed more
classes/structures thus leading to more coding.
Advantages:
• Size estimation can be done during the initial stages of planning.
• The number of entities is independent of the programming technologies used.
Disadvantages:
• No fixed standards exist. Some entities contribute more to project size than others.
• Just like FPA, it is less used in the cost estimation model. Hence, it must be
converted to LOC.
3. Total number of processes in detailed data flow diagram: Data Flow
Diagram(DFD) represents the functional view of software. The model depicts the main
processes/functions involved in software and the flow of data between them. Utilization
of the number of functions in DFD to predict software size. Already existing processes
of similar type are studied and used to estimate the size of the process. Sum of the
estimated size of each process gives the final estimated size.
Advantages:
• It is independent of the programming language.
• Each major process can be decomposed into smaller processes. This will increase
the accuracy of the estimation
Disadvantages:
• Studying similar kinds of processes to estimate size takes additional time and effort.
• All software projects are not required for the construction of DFD.

8
4. Function Point Analysis: In this method, the number and type of functions
supported by the software are utilized to find FPC(function point count). The steps in
function point analysis are:
• Count the number of functions of each proposed type.
• Compute the Unadjusted Function Points(UFP).
• Find the Total Degree of Influence(TDI).
• Compute Value Adjustment Factor(VAF).
• Find the Function Point Count(FPC).
The explanation of the above points is given below:

• Count the number of functions of each proposed type: Find the number of
functions belonging to the following types:
• External Inputs: Functions related to data entering the system.
• External outputs: Functions related to data exiting the system.
• External Inquiries: They lead to data retrieval from the system but don’t
change the system.
• Internal Files: Logical files maintained within the system. Log files are not
included here.
• External interface Files: These are logical files for other applications which
are used by our system.
• Compute the Unadjusted Function Points(UFP): Categorise each of the five
function types like simple, average, or complex based on their complexity. Multiply
the count of each function type with its weighting factor and find the weighted sum.
The weighting factors for each type based on their complexity are as follows:

Function type Simple Average Complex

External Inputs 3 4 6

External Output 4 5 7

External Inquiries 3 4 6

9
 Function type Simple Average Complex

Internal Logical Files 7 10 15

External Interface Files 5 7 10

• Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to
find the degree of influence of each of them. The sum of all 14 degrees of influence
will give the TDI. The range of TDI is 0 to 70. The 14 general characteristics are:
Data Communications, Distributed Data Processing, Performance, Heavily Used
Configuration, Transaction Rate, On-Line Data Entry, End-user Efficiency, Online
Update, Complex Processing Reusability, Installation Ease, Operational Ease,
Multiple Sites and Facilitate Change. Each of the above characteristics is evaluated
on a scale of 0-5.
• Compute Value Adjustment Factor(VAF): Use the following formula to calculate
VAF
VAF = (TDI * 0.01) + 0.65

• Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF

Advantages:
• It can be easily used in the early stages of project planning.
• It is independent of the programming language.
• It can be used to compare different projects even if they use different technologies
(database, language, etc).
Disadvantages:
• It is not good for real-time systems and embedded systems.
• Many cost estimation models like COCOMO use LOC and hence FPC must be
converted to LOC.

10
 Software Engineering-Problem-Based Estimation
Lines of code and function points were described as measures from which
productivity metrics can be computed. LOC and FP data are used in two ways
during software project estimation: (1) as an estimation variable to "size" each
element of the software and (2) as baseline metrics collected from past projects
and used in conjunction with estimation variables to develop cost and effort
projections.

LOC and FP estimation are distinct estimation techniques. Yet both have a
number of characteristics in common. The project planner begins with a bounded
statement of software scope and from this statement attempts to decompose
software into problem functions that can each be estimated individually. LOC or
FP (the estimation variable) is then estimated for each function. Alternatively, the
planner may choose another component for sizing such as classes or objects,
changes, or business processes affected.

Baseline productivity metrics (e.g., LOC/pm or FP/pm) are then applied to the
appropriate estimation variable, and cost or effort for the function is derived.
Functionestimates are combined to produce an overall estimate for the entire
project.It is important to note, however, that there is often substantial scatter in
productivity metrics for an organization, making the use of a single baseline
productivity metric suspect. In general, LOC/pm or FP/pm averages should be
computed by project domain. That is, projects should be grouped by team size,
application area, complexity, and other relevant parameters. Local domain
averages should then becomputed. When a new project is estimated, it should
first be allocated to a domain, and then the appropriate domain average for
productivity should be used in generating the estimate.

The LOC and FP estimation techniques differ in the level of detail required for
decomposition and the target of the partitioning. When LOC is used as the
11
estimation variable, decomposition is absolutely essential and is often taken to
considerable levels of detail.

Software Engineering-Process-Based Estimation

The most common technique for estimating a project is to base the estimate on
the process that will be used. That is, the process is decomposed into a relatively
small set of tasks and the effort required to accomplish each task is estimated.
Like the problem-based techniques, process-based estimation begins with a
delineation of software functions obtained from the project scope. A series of
software process activities must be performed for each function. Functions and
related software process activities may be represented as part of a table .

Once problem functions and process activities are melded, the planner estimates
the effort (e.g., person-months) that will be required to accomplish each software
process activity for each software function. These data constitute the central
matrix of the table. Average labor rates (i.e., cost/unit effort) are then applied to
the effort estimated for each process activity. It is very likely the labor rate will vary
for each task. Senior staff heavily involved in early activities is generally more
expensive than junior staff involved in later design tasks, code generation, and
early testing. Costs and effort for each function and software process activity are
computed as the last step. If process-based estimation is performed
independently of LOC or FP estimation, we now have two or three estimates for
cost and effort that may be compared and reconciled. If both sets of estimates
show reasonable agreement, there is good reason to believe that the estimates
are reliable. If, on the other hand, the results of these decomposition techniques
show little agreement, further investigation and analysis must be conducted.

12
Cost Estimation Models in Software Engineering
Cost estimation simply means a technique that is used to find out the cost estimates.
The cost estimate is the financial spend that is done on the efforts to develop and test
software in Software Engineering. Cost estimation models are some mathematical
algorithms or parametric equations that are used to estimate the cost of a product or a
project. Various techniques or models are available for cost estimation, also known as
Cost Estimation Models as shown below.

1. Empirical Estimation Technique –

Empirical estimation is a technique or model in which empirically derived formulas

are used for predicting the data that are a required and essential part of the
software project planning step. These techniques are usually based on the data that
is collected previously from a project and also based on some guesses, prior
experience with the development of similar types of projects, and assumptions. It
uses the size of the software to estimate the effort. In this technique, an educated
guess of project parameters is made. Hence, these models are based on common
sense. However, as there are many activities involved in empirical estimation
techniques, this technique is formalized. For example Delphi technique and Expert
Judgement technique.

13
2. Heuristic Technique –
Heuristic word is derived from a Greek word that means “to discover”. The heuristic
technique is a technique or model that is used for solving problems, learning, or
discovery in the practical methods which are used for achieving immediate goals.
These techniques are flexible and simple for taking quick decisions through
shortcuts and good enough calculations, most probably when working with complex
data. But the decisions that are made using this technique are necessary to be
optimal.In this technique, the relationship among different project parameters is
expressed using mathematical equations. The popular heuristic technique is given
by Constructive Cost Model (COCOMO). This technique is also used to increase or
speed up the analysis and investment decisions.

3. Analytical Estimation Technique –

Analytical estimation is a type of technique that is used to measure work. In this
technique, firstly the task is divided or broken down into its basic component
operations or elements for analyzing. Second, if the standard time is available from
some other source, then these sources are applied to each element or component
of work. Third, if there is no such time available, then the work is estimated based
on the experience of the work. In this technique, results are derived by making
certain basic assumptions about the project. Hence, the analytical estimation
technique has some scientific basis. Halstead’s software science is based on an
analytical estimation model.

Software Engineering | COCOMO Model

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number
of Lines of Code. It is a procedural cost estimate model for software projects and is
often used as a process of reliably predicting the various parameters associated with
making a project such as size, effort, cost, time, and quality. It was proposed by Barry
Boehm in 1981 and is based on the study of 63 projects, which makes it one of the
best-documented models.

14
The key parameters which define the quality of any software products, which are also
an outcome of the Cocomo are primarily Effort & Schedule:

• Effort: Amount of labor that will be required to complete a task. It is measured in

person-months units.
• Schedule: Simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of
time such as weeks, and months.
Different models of Cocomo have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required. All of
these models can be applied to a variety of projects, whose characteristics determine
the value of the constant to be used in subsequent calculations.

These characteristics pertaining to different system types are mentioned below.

Boehm’s definition of organic, semidetached, and embedded systems:

1. Organic – A software project is said to be an organic type if the team size required
is adequately small, the problem is well understood and has been solved in the past
and also the team members have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team size, experience, and knowledge of the various
programming environment lie in between that of organic and Embedded. The projects
classified as Semi-Detached are comparatively less familiar and difficult to develop
compared to the organic ones and require more experience and better guidance and
creativity. Eg: Compilers or different Embedded Systems can be considered Semi-
Detached types.
3. Embedded – A software project requiring the highest level of complexity, creativity,
and experience requirement fall under this category. Such software requires a larger
team size than the other two models and also the developers need to be sufficiently
experienced and creative to develop such complex models.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model

15
 1. Basic Model –
The above formula is used for the cost estimation of for the basic COCOMO model,
and also is used in the subsequent models. The constant values a,b,c, and d for the
Basic Model for the different categories of the system:

Software Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

The effort is measured in Person-Months and as evident from the formula is dependent
on Kilo-Lines of code. The development time is measured in months. These formulas
are used as such in the Basic Model calculations, as not much consideration of
different factors such as reliability, and expertise is taken into account, henceforth the
estimate is rough.

2. Intermediate Model –
The basic Cocomo model assumes that the effort is only a function of the number of
lines of code and some constants evaluated according to the different software
systems. However, in reality, no system’s effort and schedule can be solely calculated
on the basis of Lines of Code. For that, various other factors such as reliability,
experience, and Capability. These factors are known as Cost Drivers and the
Intermediate Model utilizes 15 such drivers for cost estimation. Classification of Cost
Drivers and their Attributes:
(i) Product attributes –
• Required software reliability extent
• Size of the application database
• The complexity of the product
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment

16
• Required turnabout time
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
• Use of software tools
• Application of software engineering methods
• Required development schedule

3. Detailed Model –
Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering
process. The detailed model uses different effort multipliers for each cost driver
attribute. In detailed cocomo, the whole software is divided into different modules and
then we apply COCOMO in different modules to estimate effort and then sum the
effort. The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
Advantages of the COCOMO model:
1. Provides a systematic way to estimate the cost and effort of a software project.
2. Can be used to estimate the cost and effort of a software project at different stages
of the development process.
3. Helps in identifying the factors that have the greatest impact on the cost and effort
of a software project.
4. Can be used to evaluate the feasibility of a software project by estimating the cost
and effort required to complete it.

17
 Disadvantages of the COCOMO model:
1. Assumes that the size of the software is the main factor that determines the cost
and effort of a software project, which may not always be the case.
2. Does not take into account the specific characteristics of the development team,
which can have a significant impact on the cost and effort of a software project.
3. Does not provide a precise estimate of the cost and effort of a software project, as it
is based on assumptions and averages.

18