Module 5

Managing Software Projects

 The Management Spectrum
The
The 4 P’s of project management Software to
The most be built
important element
of a successful
project.
People Product

The set of All work required

framework The Management to make a product
activities
Spectrum

Process Project
 The Management Spectrum
1. People
• This is virtually any type of stakeholder who is involved in the project. The most important
element of a successful project.

• People of a project include from manager to developer, from client to End user. however
principally people of a project highlight the developers.

People Capability Maturity Model (People-CMM),

• Staffing, • Competency analysis and development,

• Communication and coordination, • Career development,
• Work environment, • Workgroup development,
• Performance management, • Team/culture development,
• Training, • and others..,
• Compensation,
 The Management Spectrum
1. People Cont’d
People

The Stakeholders Team Leaders The Software Team

• Senior managers
• Project (technical)
managers
• Practitioners
• Customers
• End users
 The Management Spectrum
1. People Cont’d
Stakeholders
• Senior managers who define the business issues that often have a significant influence on
the project.

• Project (technical) managers who must plan, motivate, organize, and control the practitioners
who do software work.

• Practitioners who deliver the technical skills that are necessary to engineer a product or
application.

• Customers who specify the requirements for the software to be engineered and other
stakeholders who have a peripheral interest in the outcome.

• End-users who interact with the software once it is released for production use.
 The Management Spectrum
1. People Cont’d
Team Leader
• A Software Engineering Team Leader is responsible for their team’s
execution, the quality they produce, the speed and cadence at which they
produce, but most importantly, they are responsible for the team’s culture,
environment, and overall growth of the people on it.

The MOI Model

Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best
ability.
Organization. The ability to mold existing processes (or invent new ones) that will enable the initial
concept to be translated into a final product.
Ideas or innovation. The ability to encourage people to create and feel creative even when they must
work within bounds established for a particular software product or application.
 The Management Spectrum
1. People Cont’d
Project manager
• Software project managers are in charge of the planning, scheduling, budgeting, execution,
and delivery of software and web projects.

The characteristics that define an effective project manager emphasizes four key traits:

• Problem solving

• Managerial identity

• Achievement

• Influence and team building

 The Management Spectrum
1. People Cont’d
The Software Team
The seven project factors should be considered when planning the
structure of software engineering teams
• The difficulty of the problem to be solved

• The size of the resultant program(s) in lines of code or function points

• The time that the team will stay together (team lifetime)

• The degree to which the problem can be modularized

• The required quality and reliability of the system to be built

• The rigidity of the delivery date

• The degree of sociability (communication) required for the project

 The Management Spectrum
1. People Cont’d
The Software Team Cont’d
Organizational paradigms suggested by Constantine [Con93]

• Closed paradigm—structures a team along a traditional hierarchy of authority

• Random paradigm—structures a team loosely and depends on the individual

initiative of the team members

• Open paradigm—attempts to structure a team in a manner that achieves some of

the controls associated with the closed paradigm but also much of the innovation
that occurs when using the random paradigm

• Synchronous paradigm—relies on the natural compartmentalization of a problem

and organizes team members to work on pieces of the problem with little active
communication among themselves
 The Management Spectrum
1. People Cont’d
The Software Team Cont’d
To achieve a high-performance team
• Team members must have trust in one another.

• The distribution of skills must be appropriate to the problem.

• Mavericks may have to be excluded from the team, if team

cohesiveness is to be maintained.
Avoid Team “Toxicity”
(1) a frenzied work atmosphere,
(2) high frustration that causes friction among team members,
(3) a “fragmented or poorly coordinated” software process,
(4) an unclear definition of roles on the software team, and
(5) “continuous and repeated exposure to failure.
 The Management Spectrum
1. People Cont’d
Agile Teams
• The small, highly motivated project team,
also called an agile team,

Team is “self-organizing”
• An adaptive team structure

• Uses elements of Constantine’s random,

open, and synchronous paradigms

• Significant autonomy
 The Management Spectrum
1. People Cont’d
Team Coordination & Communication
• Formal, impersonal approaches include software engineering documents and work
products (including source code), technical memos, project milestones, schedules,
and project control tools, change requests and related documentation, error
tracking reports, and repository data.

• Formal, interpersonal procedures focus on quality assurance activities applied to

software engineering work products.
• Informal, interpersonal procedures include group meetings for information dissemination and problem
solving and “collocation of requirements and development staff.”
• Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-
based conferencing systems.

• Interpersonal networking includes informal discussions with team members and those outside the project
who may have experience.
 The Management Spectrum
2. The Product
• The software product is software that has been developed and maintained for the benefit of a user base
and often to satisfy a need in the market.

1. Software Scope
The first software project management activity is the determination of software scope.
Scope is defined by answering the following questions

• Context. How does the software to be built fit into a larger system, product, or business context, and
what constraints are imposed as a result of the context?

• Information objectives. What customer-visible data objects are produced as output from the
software? What data objects are required for input?
• Function and performance. What function does the software perform to transform input data into
output? Are any special performance characteristics to be addressed?
 The Management Spectrum
2. The Product Cont’d

2. Problem Decomposition
• Problem decomposition, sometimes called partitioning or problem elaboration, is an activity
that sits at the core of software requirements analysis.
• It involves breaking down a complex problem or system into smaller parts that are more
manageable and easier to understand.

• The smaller parts can then be examined and solved, or designed individually, as they are
simpler to work with.

The decomposition process continues until all functions or problem classes have been defined.

If a problem is not decomposed, it is much harder to solve

 The Management Spectrum
3. The Process
• The framework activities that characterize the software process are applicable to all
software projects.

• The problem is to select the process model that is appropriate for the software to be
engineered.

The team must decide which process model is most appropriate for

(1) The customers who have requested the product and the people who will do the work,

(2) The characteristics of the product itself, and

(3) The project environment in which the software team works.

 The Management Spectrum
3. The Process Cont’d
Melding the Product and the Process
The generic framework activities:
• Communication,

• Planning,

• Modeling,

• Construction,

• and Deployment

• Each major product function is listed in the

left-hand column. Framework activities are
listed in the top row.
 The Management Spectrum
4. The Project
• A project is a well-defined task, which is a collection of several operations done in order to achieve a
goal (for example, software development and delivery).

Projects get into trouble when (John Reel,1999)

6. Deadlines are unrealistic.

1. Software people don’t understand their
7. Users are resistant.
customer’s needs.
8. Sponsorship is lost [or was never properly obtained].
2. The product scope is poorly defined.
[Link] project team lacks people with appropriate
3. Changes are managed poorly.
skills.
4. The chosen technology changes.
[Link] [and practitioners] avoid best practices
5. Business needs change [or are ill-defined].
and lessons learned.
 The Management Spectrum
4. The Project Cont’d
Common-sense Approach To Projects
• Start on the right foot. This is accomplished by working hard (very hard) to understand the problem that is to be
solved and then setting realistic objectives and expectations.

• Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute
minimum, the team should emphasize quality in every task it performs, and senior management should do everything
possible to stay out of the team’s way.

• Track progress. For a software project, progress is tracked as work products (e.g., models, source code, sets of
test cases) are produced and approved (using formal technical reviews) as part of a quality assurance activity.

• Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep
it simple.”

• Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.
 The Management Spectrum
To Get to the Essence of a Project

• Why is the system being developed?

• What will be done?

• When will it be accomplished?

• Who is responsible?

• Where are they organizationally located?

• How will the job be done technically and managerially?

• How much of each resource (e.g., people, software, tools, database) will be
needed?
 The Management Spectrum
Critical Practices
• Formal risk management

• Empirical cost and schedule estimation

• Metrics-based project management

• Earned value tracking

• Defect tracking against quality targets

• People aware project management

Estimation for Software Projects
 Introduction
Estimation
• Estimation is the technique of calculating or computing the various quantities and the
expected expenditure to be incurred on a particular work or project.

• Software project management begins with a set of activities that

are collectively called project planning.

• Before the project can begin, the software team should estimate
the work to be done, the resources that will be required, and the
time that will elapse from start to finish.

• The overall goal of project planning is to establish a pragmatic strategy for

controlling, tracking, and monitoring a complex technical project.
 Software Project Planning
Project Planning
• This phase is the longest and most important of the project cycle. Without proper scope planning, a
project has a poor chance of success.

• The two sets of tasks will be accomplished during project planning.

Project Planning

Task Set-I Task Set-II

• Establish project scope

• Determine feasibility • Estimate cost and effort

• Analyze risks • Develop a project schedule

• Define required resources

 Project Planning Task Set-I

• Software scope describes the functions and features that are to be delivered to end
users, the data that are input and output.

• The second planning task is an estimation of the resources

required to accomplish the software development effort.
• Human Resources
• Reusable Software Resources
▪ Component-based software engineering
Off-the-shelf components
Full-experience components
Partial-experience components.
New components.
• Environmental Resources
 Software Project Estimation
• Software cost and effort estimation will never be an exact science.
• Too many variables—human, technical, environmental, political—can affect the ultimate cost
of software and the effort applied to develop it.

Estimation of resources, cost, and schedule for a software engineering effort requires

▪ Experience

▪ Access to good historical information (metrics)

▪ The courage to commit to quantitative predictions when qualitative information is all
that exists

Estimation carries inherent risk and this risk leads to uncertainty.

 Software Project Estimation

So good software Project Estimation,

• Project scope must be understood

• Elaboration (decomposition) is necessary

• Historical metrics are very helpful

• At least two different techniques should be used

• Uncertainty is inherent in the process

 Software Project Estimation

Project Estimation Process

• Estimating the size of the software to be developed is the
very first step to making an effective estimation of the
project.

• The next step is to estimate the effort based on the size

(Efforts are estimated in the number of man-months)

• Estimating the project schedule from the effort estimated.

• the cost of a project is derived not only from the estimates of

effort and size but from other parameters such as hardware,
travel expenses, telecommunication costs, training cost etc.
should also be taken into account.
 Software Project Estimation
Project Estimation Process
• Software managers, cognizant engineers,
and software estimators are responsible
for project estimation.
 Software Project Estimation
Estimation Techniques
Estimation Techniques

Past (similar) Conventional

Empirical models Automated tools
project experience estimation techniques
 Software Project Estimation
Estimation Accuracy
• Accuracy is an indication of how close something is to reality. Whenever you generate an estimate,
everyone wants to know how close the numbers are to reality.
Important factors that affect the accuracy of estimates are −
• The accuracy of all the estimate’s input data.

• The accuracy of any estimate calculation.

• How closely is the historical data or industry data used to calibrate the match the project you are
estimating?

• The predictability of your organization’s software development process.

• The stability of both the product requirements and the environment that supports the software
engineering effort.
• Whether or not the actual project was carefully planned, monitored and controlled, and no major
surprises occurred that caused unexpected delay.
Software Project Estimation
Software Project Estimation Techniques

• Experience (historical data)

• The Decomposition Techniques

• The Empirical Estimation Model

 Software Project Estimation Techniques Cont’d
1. Experience (historical data) based Project Estimation
• A model is based on experience (historical data) and takes the form

• where d is one of a number of estimated values (e.g., effort, cost, project duration)
and vi are selected independent parameters (e.g., estimated LOC or FP).
 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach
• The Project Estimation Approach that is widely used
is Decomposition Technique.

• Decomposition techniques take a divide-and-conquer

approach. Size, Effort and Cost estimation are
performed in a stepwise manner by breaking down a
Project into major Functions or related Software
Engineering Activities.
 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
1. Software Sizing
• A project estimate is only as good as the estimate of the size of the work
to be accomplished.
• In project planning, size refers to a quantifiable outcome of the software
project.

• Direct approach - lines of code (LOC)

• An indirect approach - Function points (FP)

 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2.1 Software Sizing (cont’d)
• Four different approaches to the sizing problem proposed by Putnam and Myers (1992)
▪ Fuzzy logic sizing - the approximate reasoning techniques that are the cornerstone of
fuzzy logic.

▪ Function point sizing - The planner develops estimates of the information domain
characteristics.

▪ Standard component sizing - the standard components for an information system are
subsystems, modules, screens, reports, interactive programs, batch programs, files, LOC,
and object-level instructions.

▪ Change sizing - the use of existing software that must be modified in some way as part of a
project.
 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2. Problem-Based Estimation
LOC and FP data are used in two ways during software project estimation:
(1) As estimation variables 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.

• Other components for sizing, such as classes or objects, changes, or business

processes affected
 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
2.2 Problem-Based Estimation Cont’d
• A three-point or expected value can then be computed.

• The expected value for the estimation variable (size) S can be computed as a weighted average of
the optimistic (sopt), most likely (sm), and pessimistic (spess) estimates.

• gives the heaviest credence to the

“most likely” estimate and follows a
beta probability distribution.

• Once the expected value for the estimation variable has been determined, historical LOC or FP
productivity data are applied.

• Productivity = KLOC / Person-month

• Quality = Defects / KLOC
• Cost = $ / LOC
• Documentation = pages of documentation / KLOC
 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
Lines of Code (LOC)

• It is one of the earliest and simpler metrics for calculating the size of the computer program.

• It is generally used in calculating and comparing the productivity of programmers.

• These metrics are derived by normalizing the quality and productivity measures by considering the
size of the product as a metric.

• As Lines of Code (LOC) only counts the volume of code, you can only use it to compare or estimate
projects that use the same language and are coded using the same coding standards
 Software Project Estimation Techniques Cont’d
2. The Decomposition Approach Cont’d
An example of LOC based Estimation
• Take the Library management system case. Software developed for the library will accept data
from the operator for issuing and returning books. Issuing and returning will require some validity
checks. For issue, it is required to check if the member has already issued the maximum number of
books allowed. In case of a return, if the member is returning the book after the due date then a
fine has to be calculated. All the interactions will be through the user interface. Other operations
include maintaining the database and generating reports at regular intervals.

Major software functions identified.

• User interface
• Database management
• Report generation
Software Project Estimation Techniques Cont’d

For user interface(Assumptions of LOC). Expected Value(EV) for user interface

• Sopt : 1800 EV = (1800 + 4*2000 + 4000) / 6
• Sm : 2000 EV = 2300
• Spess : 4000
Expected Value(EV) for database management
EV = (4600 + 4*6900 + 8600) / 6
For database management
• Sopt: 4600 EV = 6800
• Sm: 6900
Expected Value(EV) for user interface
• Spess : 8600
EV = (1200 + 4*1600 + 3200) / 6
For report generation EV = 1800
• Sopt: 1200
• Sm: 1600
Estimated lines of code
• Spess : 3200 =2300+6800+1800
=10900
 Software Project Estimation Techniques Cont’d

• For example, A review of historical data indicates that the organizational average productivity for
systems of this type is 500 LOC/pm. Based on a burdened labor rate of $6000 per month.

• The cost per line of code is approximate.

• Cost/LOC=(6000/500)=$12
• Based on the LOC estimate and the historical productivity data and By Considering the total
estimated LOC as 10900,

The total Estimated project cost =(10900*12)=$130800.

• The estimated effort is

The total estimated project effort = (10900/500) =21.8 Persons- Months
 Software Project Estimation Techniques Cont’d

The problems of lines of code (LOC)

• Different languages lead to different lengths of code

• It is not clear how to count lines of code

• A report, screen, or GUI generator can generate thousands of lines of code

in minutes

• Depending on the application, the complexity of the code is different.

 Software Project Estimation Techniques Cont’d

FP-Based Estimation
• Decomposition for FP-based estimation focuses on information domain values rather than software
functions.

FP=320*1.17=375
• The organizational average productivity for systems of this
type is 6.5 FP/pm.

• Based on a burdened labour rate of $8000 per month, the

cost per FP is approximately $1230.
• Based on the FP estimate and the historical productivity
Value adjustment factor 1.17
data, the total estimated project cost is $461,000 and the
estimated effort is 58 person-months.
 Software Project Estimation Techniques Cont’d

2.3 Process-Based Estimation

• The most common technique for estimating a project is to base the estimate on the process that
will be used.

• The process is decomposed into a relatively small set of tasks and the effort required to accomplish
each task is estimated.

• Like problem-based techniques, process-based estimation begins with a delineation of software

functions obtained from the project scope.

• A series of framework activities must be performed for each function.

• Once problem functions and process activities are melded, you estimate the effort (e.g., person-
months) that will be required to accomplish each software process activity for each software function.
 Software Project Estimation Techniques Cont’d

2.3 Process-Based Estimation Cont’d

 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points
• A Use-Case is a series of related interactions between a user and a system that enables the user to
achieve a goal.
• Use-Case Points (UCP) is a software estimation technique used to measure the software size with use
cases. The concept of UCP is similar to FPs.

• The Use-Case Point estimation method was introduced by Gustav Karner in 1993. The work was later
licensed by Rational Software which merged into IBM.

The number of UCPs in a project is based on the following

• The number and complexity of the use cases in the system.

• The number and complexity of the actor in the system.

• Various non-functional requirements such as portability, performance, and maintainability that are
not written as use cases.

• The environment in which the project will be developed such as the language, the team’s
motivation, etc.
 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d

The Use-Case Points counting process has the following steps −

• Unadjusted Use Case Weight (UUCW)

Use Case Points (UCP)
• Unadjusted Actor Weight (UAW)

• Technical Complexity Factor (TCF) UCP = (UUCW + UAW) x TCF x ECF

• Environmental Complexity Factor (ECF)

Unadjusted Use Case Weight (UUCW)

UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No. Complex Use Cases x 15)
 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Unadjusted Actor Weight (UAW)

UAW = (Total No. of Simple actors x 1) + (Total No. Average actors x 2) + (Total No. Complex actors x 3)

Technical Complexity Factor (TCF)

• The TCF is one of the factors applied to the estimated size of the software in order to account for
technical considerations of the system

TCF = 0.6 + (TF/100)

 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Environmental Complexity Factor (ECF)
• The ECF is another factor applied to the estimated size of the software in order to account for the
environmental considerations of the system.

ECF = 1.4 + (-0.03 x EF)

 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Example Unadjusted Use Case Weight (UUCW)
UUCW = (Total No. of Simple Use Cases x 5) + (Total No. Average Use Cases x 10) + (Total No.
Complex Use Cases x 15).

UUCW = (1x 5) + (1 x 10) + (3 x 15) = 60

Unadjusted Actor Weight (UAW)
UAW = (Total No. of Simple Actors x 1) + (Total No. Average Actors x 2)
+ (Total No. Complex Actors x 3)

UAW = (1 x 1) + (0 x 2) + (2 x 3) = 7
Technical Complexity Factor (TCF) Environmental Complexity Factor (ECF)
TCF = 0.6 + (TF/100) • ECF = 1.4 + (-0.03 x EF)
TCF = 0.6 + (49/100) = 1.09 • ECF = 1.4 + (-0.03 * 10.0) = 1.1

Use Case Points (UCP)

• UCP = (UUCW + UAW) x TCF x ECF = (60+7)*1.09*1.1= 80.33
 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d

Use cases are problematic for the following reasons

• Use cases are described using many different formats and styles—there is no standard form.

• Use cases represent an external view (the user’s view) of the software and can therefore be
written at many different levels of abstraction.

• Use cases do not address the complexity of the functions and features that are described.

• Use cases can describe complex behavior (e.g., interactions) that involve many functions and
features.
 Software Project Estimation Techniques Cont’d
3. Estimating With Use Case Points cont’d
Use-Case–Based LOC Calculation

• N – the actual number of use cases

• LOCavg -historical average LOC per use case for this type of subsystem
• LOCadjust - represents an adjustment based on n percent of LOCavg where n is defined locally and
represents the difference between this project and “average” projects.

• Sa - actual scenarios per use case

• Sh - average scenarios per use case for this type of subsystem

• Pa - actual pages per use case

• Ph - average pages per use case for this type of subsystem

Empirical Estimation Models
 Empirical Estimation Models
Introduction
• An estimation model for computer software uses derived formulas to predict effort as a
function of LOC or FP.
• The empirical data that support most estimation models are derived from a limited sample
of projects.

• No estimation model is appropriate for all classes of software and in all development
environments. Therefore, you should use the results obtained from such models judiciously.
• An estimation model should be calibrated to reflect local conditions
The Structure of Estimation Models
• A typical estimation model is derived using regression analysis on data collected from past software
projects.

• where A, B, and C are empirically derived constants, E is an effort in person-months, and ev is the
estimation variable (either LOC or FP).
 Empirical Estimation Models
The Structure of Estimation Models Cont’d

• The following are the LOC-oriented estimation models proposed in the literature.

• The following are the FP-oriented estimation models proposed in the literature.
 Empirical Estimation Models
COCOMO Model
• COCOMO (Constructive Cost Model) is a regression model based on the number of Lines of Code
(LOC).
• It is a procedural cost estimation model for software projects.
• This model is used for predicting the various parameters associated with developing a project such
as size, effort, cost, and time.
• COCOMO was proposed by Barry Boehm in 1970 and is based on the study of 63 projects.

Effort and schedule parameters are outcomes of the COCOMO model.

• Effort: Amount of labor (staff) that will be required to complete a task. It is measured in person-
months units.

• Schedule: means the amount of time required for the completion of the job, which is proportional
to the effort. It is measured in the units of time such as weeks, and months.
 Empirical Estimation Models
Boehm’s categorizes the projects
1. Organic: If the team size required to develop a software project is small then the software project is
called as Organic project. In this 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: If the main features such as team size, experience, and knowledge of the various
programming environment lie in between Organic and Embedded then the software project is called a
Semi-detached type project. Eg: Compilers or different Embedded Systems.

3. Embedded: Embedded software projects require the highest level of complexity, creativity, and
experience. This type of 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.
 Empirical Estimation Models
Boehm’s categorizes the projects
 Empirical Estimation Models

Types of COCOMO Models

There are three types of COCOMO models:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
COCOMO model levels:
• Basic-predicted software size (lines of code) was used to estimate development effort.

• Intermediate - predicted software size (lines of code), plus a set of 15 subjectively assessed 'cost
drivers' was used to estimate development effort.

• Advanced - on top of the intermediate model, the advanced model allows phase-based cost driver
adjustments and some adjustments at the module, component, and system levels.
 Empirical Estimation Models
1. Basic COCOMO model
• The Basic COCOMO can be used for quick and slightly rough calculations of Software Costs.

• The following formulas are used to calculate effort and time estimates.

Effort ( E ) = A*(KLOC)B

Time (T) = C*(Effort)D

Persons required = Effort / Time

• The constant values A, B, C and D for the Basic Model for the different categories of software
projects.
 Empirical Estimation Models
1. Example of Basic COCOMO model
• Supposed that a project was estimated to be 400 KLOC. Calculate effort and development time for each
of three modes i.e. Organic, semi-detached and embedded.

• Effort ( E ) = A*(KLOC)B
• Time (T) = C*(Effort)D
• Estimated size of project = 400 KLOC.

Organic mode Semi-detached mode

E = 2.4 * (400)1.05 = 1295.31 Person-Months E = 3.0 * (400)1.12 = 1295.31 Person-Months

T = 2.5 * (1295.31).38 = 38.07 Months T = 2.5 * (12462.79).35 = 38.45 Months

Embedded Mode
E = 3.6 * (400)1.2 = 4772.81 Person-Months
T = 2.5 * (4772.81).32 = 38 Months
 Empirical Estimation Models
Try this
• A project size of 200 KLOC is to be developed. The software development team has average
experience on similar types of projects. The project schedule is not very tight. Calculate the effort,
development time, average staff size, and productivity of the project.
 Empirical Estimation Models
2. Intermediate COCOMO Model
• In the intermediate COCOMO model, various other factors such as reliability, experience, and
Capability are considered along with LOC to estimate effort and time schedule.

• These factors are known as Cost Drivers and the Intermediate Model utilizes 15 such drivers for
cost estimation.
(iii) Personnel attributes:
(i) Product attributes:
8. Analyst capability
1. Required software reliability extent
9. Software engineering capability
2. Size of the application database
10. Applications experience
3. The complexity of the product
11. Virtual machine experience
(ii) Hardware attributes: 12. Programming language experience
4. Run-time performance constraints
(iv) Project attributes:
5. Memory constraints
13. Use of software tools
6. The volatility of the virtual machine environment
14. Application of software engineering methods
7. Required turnabout time
15. Required development schedule
 Empirical Estimation Models
2. Intermediate COCOMO Model Cont’d

The Intermediate COCOMO model formulas are

Effort ( E ) = (A*(KLOC)B ) * EAF.

Time (T) = C*(Effort)D

Persons required = Effort / Time

• The constant values A, B, C and D for the Intermediate

Model for the different categories of software projects.
 Empirical Estimation Models
3. Detailed COCOMO Model
• The 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.

Planning and requirements

• The effort is calculated as a
System design function of program size and
a set of cost drivers are
given according to each phase
Detailed design of the software lifecycle.
The Six phases of detailed
COCOMO
Module code and test

Integration and test

Cost Constructive mode

 Empirical Estimation Models
COCOMO II Model
COCOMO II is a hierarchy of estimation models that address the following areas

• Application composition model: Used during the early stages of software engineering, when prototyping
of user interfaces, consideration of software and system interaction, assessment of performance, and
evaluation of technology maturity are paramount.

• Early design stage model: Used once requirements have been stabilized and basic software architecture
has been established.

• Post-architecture-stage model: Used during the construction of the software

• COCOMO II models require sizing information. Three different sizing options are available as part of
the model hierarchy. They are object points, function points, and lines of source code.
 Empirical Estimation Models
COCOMO II Model Cont’d
• The COCOMO II application composition model uses object points.

• Like function points, the object point is an indirect software measure that is computed using
counts of the number of

(1) screens (at the user interface)

(2) reports, and

(3) components likely to be required to build the application

• The object point count is determined by

multiplying the original number of object
instances by the weighting factor.
 Empirical Estimation Models
COCOMO II Model Cont’d
 Empirical Estimation Models
COCOMO II Model Cont’d
• When component-based development or general software reuse is to be applied, the percent of reuse
(%reuse) is estimated and the object point count is adjusted:

NOP = (Object points) * [(100 - % reuse)/100]

• Where NOP = New Object Points. Now Productivity rate is defined based on the computed NOP value
to derive an estimate of effort.

Productivity rate (PROD) = NOP/ Person-Month

Estimated effort = NOP/PROD

 Empirical Estimation Models
COCOMO II Model Cont’d
The productivity rate for different levels of developer experience and development environment
maturity.
 Empirical Estimation Models
COCOMO II Model Cont’d
Example
i) The application has 4 screens with 4 views each and 7 data tables for 3 servers and 4 clients.
ii)The application may generate two reports of 6 sections each from 7 data tables for two servers
and 3 clients. There is a 10% reuse of object points.

The developer’s experience and capability in a similar environment is low. The maturity of the
organization in terms of capability is also low.

Calculate the object point count, new object points, and effort to develop such a project

Number of screens = 4 with 4views each

Number of reports = 2 with 6 sections each.

The Complexity weights, Object point count = 4 * 2 + 2 * 8 = 24

( screen medium complexity = 2, report difficult complexity =8)

 Empirical Estimation Models
COCOMO II Model Cont’d
Example Cont’d

New Object Points (NOP) = (object points) * [(100 - %reuse)/100]

= 24 * (100-10)/100

= 24 * 90/100 = 21.6

The low value of productivity (PROD) = 7

Efforts in Person – Months = NOP/PROD = 21.6 / 7 = 3.086 = 3 Person-months.

 Empirical Estimation Models
The Software Equation (Putnam-1992)
• The software equation is a dynamic multivariable model that assumes a specific distribution of
effort over the life of a software development project.

• This model has been derived from productivity data collected for over 4000 contemporary software
projects.

where
E - effort in person-months or person-years

t - project duration in months or years

B - “special skills factor”

P - “productivity parameter”.

• Typical values might be P 2000 for the development of real-time embedded software, P 10,000 for
telecommunication and systems software, and P 28,000 for business systems applications
 Empirical Estimation Models
The Software Equation (Putnam-1992)

• Minimum development time is defined as

t – Represent in years.

For Example, P 12,000 (Recommended value for scientific software), and suppose the total LOC
of the project is 33,200 then
 Estimation for Object-oriented Projects
Lorenz and Kidd suggested the following approach:
[Link] estimates using effort decomposition, FP analysis, and any other method that is applicable to conventional
applications.

2. Using the requirements model, develop use cases and determine a count. Recognize that the number of use cases may
change as the project progresses.

3. From the requirements model, determine the number of key classes.

4. Categorize the type of interface for the application and develop a multiplier for support classes.

Multiply the number of key classes (step 3) by the multiplier to obtain an

estimate for the number of support classes

[Link] the total number of classes (key + support) by the average number of work units per class. Lorenz and Kidd
suggest 15 to 20 person-days per class.

6. Cross-check the class-based estimate by multiplying the average number of work units per use case.
 Specialized Estimation Techniques
1. Estimation for Agile Development
• Estimation for agile projects uses a decomposition approach

[Link] user scenario (the equivalent of a mini-use case created at the very start of a project by end users or
other stakeholders) is considered separately for estimation purposes.

2. The scenario is decomposed into the set of software engineering tasks that will be required to develop it.
3a. The effort required for each task is estimated separately. Note: Estimation can be based on historical data,
an empirical model, or “experience.”

3b. Alternatively, the “volume” of the scenario can be estimated in LOC, FP, or some other volume-oriented
measure (e.g., use-case count).

4a. Estimates for each task are summed to create an estimate for the scenario.

4b. Alternatively, the volume estimate for the scenario is translated into effort using historical data.

5. The effort estimates for all scenarios that are to be implemented for a given software increment are
summed to develop the effort estimate for the increment.
 Specialized Estimation Techniques Cont’d
2. Estimation for WebApp Projects

• Inputs are each input screen or form (for example, CGI or Java), each maintenance screen, and if you
use a tab notebook metaphor anywhere, each tab.

• Outputs are each static Web page, each dynamic Web page script (for example, ASP, ISAPI, or other
DHTML script), and each report (whether Web based or administrative in nature).

• Tables are each logical table in the database plus, if you are using XML to store data in a file, each
XML object (or collection of XML attributes).

• Interfaces retain their definition as logical files (for example, unique record formats) into our out-of-
the-system boundaries.

• Queries are each externally published or use a message-oriented interface. A typical example is DCOM
or COM external references.
 The Make/Buy Decision
• It may be more cost-effective to acquire a piece of software rather than develop it.

• Decision tree analysis provides a systematic way to sort through the make/buy decision.

• As a rule, outsourcing software development requires more skillful management than in-house
development of the same product.

Decision Tree helps “make / Buy Decisions”

Question Related to COCOMO model - 1

Suppose that a project was estimated to be 400 KLOC. Calculate effort & time for each
of 3 modes of development.

Software Product Type 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

Solution:
As we know that 3 modes of development are

1. Organic
2. Semi-detached
3. Embedded
Also we know that

Effort = a (KLOC)b person month

Time = c (Effort)d Months

Here, we are given KLOC = 400

1. Organic:
Effort = a (KLOC)b person month

= 2.4 (400)1.05 person month

= 1295 person month

Time = c (Effort) d Months

= 2.5 (1295) 0.38 Months

= 38 Months
2. Semi-detached

Effort = a (KLOC)b person month

= 3 (400)1.12 person month

= 2462 person month

Time = c (Effort) d Months

= 2.5 (2462) 0.35 Months

= 38.4 Months

3. Embedded

Effort = a (KLOC)b person month

= 3.6 (400)1.2 person month

= 4772 person month

Time = c (Effort) d Months

= 2.5 (4772) 0.32 Months

= 38 Months
Software Project Scheduling
 Software Project Scheduling
Project Scheduling
• Project-task scheduling is a significant project-planning activity.

• It comprises deciding which functions would be taken up when.

Scheduling Principles - 1
Compartmentalization
• The product and process must be decomposed into a manageable number of activities
and tasks
Interdependency
• Tasks that can be completed in parallel must be separated from those that must be
completed serially
Time allocation
• Every task has a start and completion dates that take the task interdependencies into
account
 Software Project Scheduling
Scheduling Principles - 2
Effort validation
• The project manager must ensure that on any given day there are enough staff members assigned to
complete the tasks within the time estimated in the project plan.

Defined Responsibilities

• every scheduled task needs to be assigned to a specific team member.

Scheduling Principles - 3
Defined outcomes
• Every task in the schedule needs to have a defined outcome (usually a work product or deliverable)
Defined milestones
• A milestone is accomplished when one or more work products from an engineering task have passed a
quality review
 Software Project Scheduling
Step :1 List the Deliverables
• Documents.
• Demonstration of function.
• Demonstration of subsystem.
• Demonstration of accuracy.
• Demonstration of reliability, security, or speed.
Step :2 Define the Milestones
• Completion of an activity or deliverable (must be measurable).
• Activities must have definite a start and stop.
• A milestone is a point in time not a time period like an activity.
Step :3 Work Breakdown Structure
• Create the work breakdown structure
• Separate the project into phases composed of steps
• Subdivide steps into activities as needed
 Software Project Scheduling
Project Effort Distribution

Generally accepted guidelines are:

• 02-03 % planning
• 10-25 % requirements analysis
• 20-25 % design
• 15-20 % coding
• 30-40 % testing and debugging
 Software Project Scheduling
The Relationship Between People and Effort
• The Putnam Norden Rayleigh (PNR) curve is an
indication of the relationship which exists between
effort applied and delivery time for the software
project.

• The curve indicates a minimum time value which

indicates test cost time for delivery as users move
to the left to right. It is observed that curved
raised non-linearly.

• It is possible to make delivery fast; the curve rises

very sharply to the left of td.
• The PNR curve indicates that project delivery time
should not be compressed much behind on td.
 Software Project Scheduling
Task Networks

• A task network, also called an activity network, is a graphic representation of the task flow for a
project
 Software
Scheduling Methods
Project Scheduling
1. Two project scheduling methods can be applied to software development

• PERT: Program Evaluation and Review Technique

• CPM: Critical Path Method

2. Both techniques are driven by information already developed in earlier project planning activities

• Estimates of efforts

• A decomposition of product function

• Selection of appropriate process and task set

• Decomposition of task

3. Both PERT and CPM provide quantitative tools that allow software planners to :

• Determine the critical path

• The chain of tasks that determines project duration

• Establish "most likely" time schedules for individual tasks

• Calculate "boundary times"

 Software Project Scheduling
Time-Line Charts
• When creating a software project schedule, the
planner begins with a set of tasks. If automated
tools are used, work breakdown is input as a task
network. As a consequence, a timeline chart is
generated.

• A timeline chart also calla as GANTT CHART can

be developed for the entire project. Also,
separate charts can be developed for each
project function.

• A timeline chart enables you to determine what

works will be conducted at a given point in time.
 Software Project Scheduling
Earned Value Analysis (EVA)

• Earned Value Analysis (EVA) is a technique used in project management for monitoring and
controlling purposes.

• a simple and powerful tool that helps managers to analyze the progress of their projects.

• Initially, EVA focuses on the budget (cost) and schedule.

• It compares the actual work completed at any time to the original budget and schedule.

• It forecasts the final budget and schedule and analyses the path to get there. It gives you the
essential early warning signal that things are going awry.
 Software Project Scheduling
Steps to Calculate Earned Value Analysis (EVA)
1. Determine the percent completion of each task.
2. Determine Planned Value (PV).
3. Determine Earned Value (EV).
4. Obtain Actual Cost (AC).
5. Calculate Schedule Variance (SV).
6. Calculate Cost Variance (CV).
7. Calculate Other Status Indicators (SPI, CPI, CR)
 Software Project Scheduling
Steps to Calculate Earned Value Analysis (EVA)
1. Determine Percent Complete

• To start the process, the percentage completed of each task needs to be determined.

2. Determine Planned Value (PV)

Planned Value, also known as Budgeted Cost of Work Scheduled (BCWS), is defined as the amount
of the task that is supposed to have been completed.

For example.

The task budget is $5,000, (10 days)

- Now we are on the 6th day (60% complete)

So , PV is = $5,000 *60% = $3,000

 Software Project Scheduling
Steps to Calculate Earned Value Analysis (EVA)
3. Determine Earned Value (EV)
• Earned Value, also known as Budgeted Cost of Work Performed (BCWP), is the amount of task that is actually
completed.
For example.

The task budget is $5,000, (10 days)

- the actual percent completion of the task (step 1) is 40%
So , EV is = $5,000 *40% = $2,000

4. Obtain Actual Cost (AC)

• The Actual Cost, also known as Actual Cost of Work Performed (ACWP) is the actual cost of the work.
• Generally, employee hours need to be converted into a cost, and all project costs need to be added up, such as the
following items:
• Labour
• Materials
For the example, AC is $1,500
• Equipment
• Fixed cost items
 Software Project Scheduling
Steps to Calculate Earned Value Analysis (EVA)
5. Calculate Schedule Variance (SV)

• The Schedule Variance represents the schedule status of the project.

• SV=EV-PV

• In this example, the schedule variance is SV = $2,000 – $3,000 = -$1,000.

• A negative schedule variance means the task is behind schedule. A positive schedule variance means it
is ahead of schedule.
6. Calculate Cost Variance (CV)
• The Cost Variance represents the cost status of the project.

CV=EV-AC

• In this example, the cost variance is CV = $2,000 – $1,500 = $500.

A negative cost variance means the task is over budget. A positive cost variance means it is under
budget.
 Software Project Scheduling
Steps to Calculate Earned Value Analysis (EVA)
7. Calculate Other Status Indicators

• Although the SV and CV are the minimum requirement and work well for small projects, there are
other variables that are derived from them that you might want to calculate:
• Schedule Performance Index (SPI): The schedule variance expressed in percentage terms, for
example, SPI = 0.8 means the project is 20% behind schedule.

SPI=EV/PV

• Cost Performance Index (CPI): The cost variance expressed in percentage terms, for example, CPI =
0.9 means the project is 10% over budget.
• Each metric is calculated for each individual task in the
CPI=EV/AC project.
• Critical Ratio • Therefore, they need to be added up into overall project

CR=SPI*CPI variances to get the overall progress indicator for the

project.