The Management Spectrum:

In software engineering, the management spectrum describes the management of a software

project. The management of a software project starts from requirement analysis and finishes
based on the nature of the product, it may or may not end because almost all software products
faces changes and requires support. It is about turning the project from plan to reality.

The management spectrum focuses on the four P’s; people, product, process and project. Here,
the manager of the project has to control all these P’s to have a smooth flow in the progress of
the project and to reach the goal.

The four P's of management spectrum are

1. People
2. Product
3. Process
4. Project
The four P’s of management spectrum has been described briefly in below.

The People:
People of a project includes from manager to developer, from customer to end user. But mainly
people of a project highlight the developers. It is so important to have highly skilled and
motivated developers that the Software Engineering Institute has developed a People
Management Capability Maturity Model (PM-CMM),
Organizations that achieve high levels of maturity in the people management area have a higher
likelihood of implementing effective software engineering practices.

The Product:
The product is the ultimate goal of the project. This is any types of software product that has to
be developed. To develop a software product successfully, all the product objectives and scopes
should be established, alternative solutions should be considered, and technical and management
constraints should be identified beforehand. Lack of these information, it is impossible to define
reasonable and accurate estimation of the cost, an effective assessment of risks, a realistic
breakdown of project tasks or a manageable project schedule that provides a meaningful
indication of progress.

The Process:
A software process provides the framework from which a comprehensive plan for software
development can be established. A number of different tasks sets— tasks, milestones, work
products, and quality assurance points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the project team. Finally, umbrella
activities overlay the software process model. Umbrella activities are independent of any one
framework activity and occur throughout the process.

The Project:
The project is the complete software project that includes requirement analysis, development,
delivery, maintenance and updates. The project manager of a project or sub-project is responsible
for managing the people, product and process. The responsibilities or activities of software
project manager would be a long list but that has to be followed to avoid project failure.

A software project could be extremely complex and as per the industry data the failure rate is
high. Its merely due to the development but mostly due to the steps before development and
sometimes due to the lack of maintenance.
The Stakeholders -The software process is populated by stakeholders who can be categorized
into one of five constituencies:
1. Senior managers - Who define the business issues that often have a significant influence on
the project?
2. Project (technical) managers - Who must plan, motivate, organize, and control the
practitioners who do software work.
3. Practitioners - Who deliver the technical skills that are necessary to engineer a product or
application? 4. Customers -who specify the requirements for the software to be engineered and
other stakeholders who have a peripheral interest in the outcome.
5. End users - Who interact with the software once it is released for production use?
Team Leaders - MOI model of leadership:
1. Motivation - The ability to encourage (by “push or pull”) technical people to produce to their
best ability.
2. Organization. - The ability to mold existing processes (or invent new ones) that will enable the
initial concept to be translated into a final product.
3. 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.Another view of the characteristics that define an effective project manager
emphasizes four key traits:
•Problem solving. - An effective software project manager can diagnose the technical and
organizational issues that are most relevant, systematically structure a solution or properly
motivate other practitioners to develop the solution, apply lessons learned from past projects to
new situations, and -remain flexible enough to change direction if initial attempts at problem
solution are fruitless.
•Managerial identity. - A good project manager must take charge of the project. She must have
the confidence to assume control when necessary and the assurance to allow good technical
people to follow their instincts.
•Achievement. -A competent manager must reward initiative and accomplishment to optimize
the productivity of a project team. She must demonstrate through her own actions that controlled
risk taking will not be punished.
•Influence and team building.
An effective project manager must be able to “read” people; she must be able to understand
verbal and nonverbal signals and react to the needs of the people sending these signals. The
manager must remain under control in high-stress situations.
The Software Team
Mantei suggests three generic team organizations:
Democratic decentralized (DD)
This software engineering team has no permanent leader. Rather, "task coordinators are
appointed for short durations and then replaced by others who may coordinate different tasks."
Decisions on problems and approach are made by group consensus. Communication among team
members is horizontal.
Controlled decentralized (CD)
This software engineering team has a defined leader who coordinates specific tasks and
secondary leaders that have responsibility for subtasks. Problem solving remains a group
activity, but implementation of solutions is partitioned among subgroups by the team leader.
Communication among subgroups and individuals is horizontal. Vertical communication along
the control hierarchy also occurs. Controlled Centralized (CC)
Top-level problem solving and internal team coordination are managed by a team leader.
Communication between the leader and team members is vertical.
-Mantei describes seven project factors that 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 Product
• Before a project can be planned, product objectives and scope should be established and
alternative solutions should be considered and technical management constrains should
 be identified. The software developer and customer must meet to define product
objectives and scope. Once the product objectives and scope are understood, alternative
solutions are considered.
• Generic products: The generic software products are stand-alone systems that are
produced by a development organization and sold on the open market to any customer
who is able to buy them. For examples of generic product include software for personal
computers (PCs) such as databases management, word processors environment, Art,
drawing and animation packages and project management tools.
• Customized (or bespoke) products: The customized products software is systems which
are commissioned by a particular customer. A software contractor/vendor develops the
software especially for that customer according to the requirement of the customers. For
examples of customized products of software system include control systems for
electronic devices, banking software, Voice communication software system, systems
written to support a particular business process and air traffic control systems.
The Process
• A software process provides the framework from which a comprehensive plan for
software development can be established.
The project manager must decide which process model is most appropriate based on
• The customers who have requested the product and the people who will do the work
• The characteristics of the product itself
• The project environment in which the software team works
• Once a process model is selected, a preliminary project plan is established based on the
process framework
• activities
• Process decomposition then begins
• The result is a complete plan reflecting the work tasks required to populate the
framework activities
The Process models
• The linear sequential model
• The prototyping model
• The RAD model
• The incremental model
• The spiral model
• The component-based development model
• The concurrent development model
• The formal methods
• The fourth generation techniques model
The Project
• The activity through which the software builds.
 • Five-part commonsense approach to software project:
1. Start on the right foot: working hard to understand the problem
2. Maintain momentum: provide incentives
3. Track progress: track work products
4. Make smart decisions: decisions should be “keep it simple”
5. Conduct a postmortem analysis: lessons learned and evaluation of project
The Project: Signs it
• Software people don't understand their customer's needs
• The product scope is poorly defined
• Changes are managed poorly
• The chosen technology changes
• Business needs change (or are poorly defined)
• Deadlines are unrealistic
• Users are resistant
• Sponsorship is lost (or was never properly obtained)
• The project team lacks people with appropriate skills
• Managers (and practitioners) avoid best practices and lessons learned

The W5HH Principle in Software Project Management

Barry Bohem suggested an approach that addresses project objectives, milestones and schedules,
responsibilities, management and technical approaches and required resources. This is called
W5HH principle. The questions that are answered in this principle are:
- Why is the system being developed?
- What will be done by When?
- Who is responsible for a function?
- Where are they organizationally located?
- How will the job be done technically and managerially?
- How much of each resource is needed?
WHY IS THE SYSTEM BEING DEVELOPED?
It enables the parties to assess the validity of business reasons for the software work. It justifies
the expenditure of people, time, and money.
WHAT WILL BE DONE?
It specifies the task set required for the project.
WHEN WILL IT BE DONE?
It helps to determine the project schedule. It helps in determining when tasks are conducted and
when milestones are reached.
WHO IS RESPONSIBLE FOR A FUNCTION?
It helps to accomplish the role and responsibilities of each member of the software team.
WHERE ARE THEY ORGANIZATIONALLY LOCATED?
The software team does not contain all the roles and responsibilities. The customers, users and
stakeholders also have responsibilities.
HOW WILL THE JOB BE DONE TECHNICALLY AND MANAGERIALLY?
The management and technical strategy of project is defined once the scope of the product is
established.
HOW MUCH OF EACH RESOURCE IS NEEDED?
It helps in deriving estimates based on the answers to the above questions.
Why the W5HH?
Bonnie and her colleague, Clyde, are software project managers for the fictitious company,
Software-R-Us. Bonnie works in the business side of software applications while Clyde's work is
focused on entertainment-based products. They've each been tasked with bringing a new
software product to market in the third quarter of the year and, while both have smart teams,
good ideas and big plans, one project manager is more successful in developing an end product.
Clyde is more laid back and likes to lead his team loosely, tackling each item as it comes, while
Bonnie follows a more detailed principle for project management known as W5HH. Who do you
think will be more successful and what exactly is W5HH anyway?
Process and Project Metrics
Software Process and Project Metrics
Overview
Software process and project metrics are quantitative measures that enable software engineers to
gain insight into the efficiency of the software process and the projects conducted using the
process framework. In software project management, we are primarily concerned with
productivity and quality metrics. The four reasons for measuring software processes, products,
and resources (to characterize, to evaluate, to predict, and to improve).
Measures, Metrics, and Indicators
Measure - provides a quantitative indication of the size of some product or process attribute
Measurement - is the act of obtaining a measure
Metric - is a quantitative measure of the degree to which a system, component, or process
possesses a given attribute

Process and Project Indicators

Metrics should be collected so that process and product indicators can be ascertained
Process indicators enable software project managers to: assess project status, track potential
risks, detect problem area early, adjust workflow or tasks, and evaluate team ability to control
product quality
1. Process Metrics
Process metrics are collected over all project and long period of time.

It allows a project manager:

• Access the status of ongoing project.
• Track the potential risks.
• Uncover the problem area before going to critical.
• Adjust the tasks.
• To control the quality of the software work products evaluate the project team's ability.
2. Project Metrics
• On most software projects the first application of project metrics occurs through the estimation.
• Metrics are collected from the previous projects act as base using which effort and time
estimates are created for current software work.
• The time and effort are compared to original estimates as a project goes on.
• If the quality is improved then the defects are minimized and if the defect goes down, then the
amount of rework needed during the project is also reduced.

a) Process Metrics
• These are the metrics pertaining to the Process Quality. They measure efficiency and
effectiveness of various processes.
b) Project Metrics
• These are the metrics pertaining to the Project Quality. They measure defects, cost,
schedule, productivity and estimation of various project resources and deliverables.
Project Metrics -
1. Schedule Variance : Any difference between the scheduled completion of an activity and
the actual completion is known as Schedule Variance. Schedule variance = ((Actual
calendar days – Planned calendar days) + Start variance)/ Planned calendar days x 100.
2. Effort Variance: Difference between the planned outlined effort and the effort required to
actually undertake the task is called Effort variance. Effort variance = (Actual Effort –
Planned Effort)/ Planned Effort x 100.
3. Size Variance: Difference between the estimated size of the project and the actual size of
the project (normally in KLOC or FP) Size variance = (Actual size – Estimated size)/
Estimated size x 100.
4. Requirement Stability Index: Provides visibility and understanding into the magnitude
and impact of requirements changes. RSI = 1- ((No of changed + No of deleted + No of
added) / Total no of Initial requirements) x100
5. Productivity (Project): It is a measure of output from a related process for a unit of input.
Project Productivity = Actual Project Size / Actual Effort spent for the project
6. Productivity (for test case preparation) Productivity in test case preparation = Actual no
of test cases/ actual effort spent on test case preparation
7. Productivity (for test case execution) Productivity in test case execution = actual number
of test cases / actual effort spend on testing.
8. Productivity (defect detection) Productivity in defect detection = Actual number of
defects (review + testing) / actual effort spent on (review + testing)
9. Productivity (defect fixation) Productivity in defect fixation = actual no of defects fixed/
actual effort spent on defect fixation
 10. Schedule variance for a phase: The deviation between planned and actual schedule for the
phases within a project. Schedule variance for a phase = (Actual Calendar days for a
phase – Planned calendar days for a phase + Start variance for a phase)/ (Planned
calendar days for a phase) x 100
11. Effort variance for a phase: The deviation between planned and actual effort for various
phases within the project. Effort variance for a phase = (Actual effort for a phase –
planned effort for a phase)/ (planned effort for a phase) x 100
Process Metrics:
1. Cost of Quality: It is a measure in terms of money for the quality performance within an
organization Cost of quality = (review + testing + verification review + verification
testing + QA + configuration management + measurement + training + rework review +
rework testing)/ total effort x 100
2. Cost of poor Quality: It is the cost of implementing imperfect processes and products.
Cost of poor quality = rework effort/ total effort x 100
3. Defect Density: It is the number of defects detected in the software during the
development divided by the size of the software (typically in KLOC or FP) Defect
density for a project = Total number of defects/ project size in KLOC or FP
4. Review Efficiency: defined as the efficiency in harnessing/ detecting review defects in
the verification stage. Review efficiency = (number of defects caught in review)/ total
number of defects caught) x 100
5. Testing Efficiency: Testing efficiency = 1 – ((defects found in acceptance)/ total no of
testing defects) x 100
6. Defect removal efficiency: Gives the efficiency with which defects were detected and
minimum defects were filtered down to the customer. Defect removal efficiency = (1 –
(total defects caught by customer/ total no of defects)) x 100
Software project Estimation
Estimation is the process of finding an estimate, or approximation, which is a value that can be
used for some purpose even if input data may be incomplete, uncertain, or unstable.
Estimation determines how much money, effort, resources, and time it will take to build a
specific system or product. Estimation is based on −
• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks
The four basic steps in Software Project Estimation are −
• Estimate the size of the development product.
• Estimate the effort in person-months or person-hours.
• Estimate the schedule in calendar months.
• Estimate the project cost in agreed currency.
Observations on Estimation
• Estimation need not be a one-time task in a project. It can take place during −
 o Acquiring a Project.
o Planning the Project.
o Execution of the Project as the need arises.
• Project scope must be understood before the estimation process begins. It will be helpful
to have historical Project Data.
• Project metrics can provide a historical perspective and valuable input for generation of
quantitative estimates.
• Planning requires technical managers and the software team to make an initial
commitment as it leads to responsibility and accountability.
• Past experience can aid greatly.
• Use at least two estimation techniques to arrive at the estimates and reconcile the
resulting values. Refer Decomposition Techniques in the next section to learn about
reconciling estimates.
• Plans should be iterative and allow adjustments as time passes and more details are
known.
General Project Estimation 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.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.
• Start with the statement of scope.
• Decompose the software into functions that can each be estimated individually.
• Calculate the size of each function.
• Derive effort and cost estimates by applying the size values to your baseline productivity
metrics.
• Combine function estimates to produce an overall estimate for the entire project.
Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost
estimates by breaking down a project into related software engineering activities.
• Identify the sequence of activities that need to be performed for the project to be
completed.
• Divide activities into tasks that can be measured.
• Estimate the effort (in person hours/days) required to complete each task.
• Combine effort estimates of tasks of activity to produce an estimate for the activity.
• Obtain cost units (i.e., cost/unit effort) for each activity from the database.
 • Compute the total effort and cost for each activity.
• Combine effort and cost estimates for each activity to produce an overall effort and cost
estimate for the entire project.
Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from
Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if
widely divergent estimates occur conduct further investigation concerning whether −
• The scope of the project is not adequately understood or has been misinterpreted.
• The function and/or activity breakdown is not accurate.
• Historical data used for the estimation techniques is inappropriate for the application, or
obsolete, or has been misapplied.
Step 5 − Determine the cause of divergence and then reconcile the estimates.
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. You will want every
estimate to be as accurate as possible, given the data you have at the time you generate it. And
of course you don’t want to present an estimate in a way that inspires a false sense of
confidence in the numbers.
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 the historical data or industry data used to calibrate the model matches 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 delays.
Following are some guidelines for achieving reliable estimates −
• Base estimates on similar projects that have already been completed.
• Use relatively simple decomposition techniques to generate project cost and effort
estimates.
• Use one or more empirical estimation models for software cost and effort estimation.
Refer to the section on Estimation Guidelines in this chapter.
To ensure accuracy, you are always advised to estimate using at least two techniques and
compare the results.
Estimation Guidelines
One should keep the following guidelines in mind while estimating a project −
• During estimation, ask other people's experiences. Also, put your own experiences at
task.
• Assume resources will be productive for only 80 percent of their time. Hence, during
estimation take the resource utilization as less than 80%.
• Resources working on multiple projects take longer to complete tasks because of the
time lost switching between them.
• Include management time in any estimate.
• Always build in contingency for problem solving, meetings and other unexpected events.
• Allow enough time to do a proper project estimate. Rushed estimates are inaccurate,
high-risk estimates. For large development projects, the estimation step should really be
regarded as a mini project.
• Where possible, use documented data from your organization’s similar past projects. It
will result in the most accurate estimate. If your organization has not kept historical
data, now is a good time to start collecting it.
• Use developer-based estimates, as the estimates prepared by people other than those who
will do the work will be less accurate.
• Use several different people to estimate and use several different estimation techniques.
• Reconcile the estimates. Observe the convergence or spread among the estimates.
Convergence means that you have got a good estimate. Wideband-Delphi technique can
be used to gather and discuss estimates using a group of people, the intention being to
produce an accurate, unbiased estimate.
• Re-estimate the project several times throughout its life cycle.

Loc-based Cost Estimation

The LOC (Line of Code) is a product size metric in software engineering. Here, the number of
lines in the code are counted and based on the number of lines the cost is calculated. There is no
definite clear picture of how to count number of lines because the length and complexity of the
code is different in different languages. It only depends on the length but not on complexity and
functionality.
1. Lines of Code (LOC): As the name suggest, LOC count 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 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.
Advantages:
• Universally accepted and is used in many models like COCOMO.
• Estimation is closer to developer’s perspective.
• Simple to use.
Disadvantages:
• Different programming languages contains different number of lines.
• No proper industry standard exist for this technique.
• It is difficult to estimate the size using this technique in early stages of project.
LOC‐based Estimation •
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 code is different
• LOC‐based Estimation ‐ Example
• Function • Estimated LOC
• User interface 2,300
• 2‐D geometric analysis 5,300
• 3 D geometric analysis 6, 800
• Database management 3,500
• Graphic display facilities 4,950
• I/O control function 2,100
• Analysis function 8,400
• Total estimated 33,350
• LOC‐based Estimation ‐ Exercise
• Average productivity based on historical data
620 LOC/pm
• Rs. 8,000 per month/PP
• Rs. 12.90/LOC (8000/620)
• If the estimated project is 33,350 LOC,
• then the total estimated project cost is Rs.430215 (33350*12.90) and
• the estimated effort is 54(430215/8000)person‐months
Functional point
Consider a project with the following functional units :
• Number of user inputs = 50
• Number of user outputs = 40
• Number of user enquiries = 35
• Number of user files = 06
• Number of external interfaces = 04
Assuming all complexity adjustment factors and weighing factors as average, the function points
for the project will be;
1. Typical complexity averages are as follows:

AVERAGE complexity weights = {4, 5, 4, 10, 7} for the 5 complexities respectively.

2. Typical Characteristic weights are as follows:

AVERAGE characteristic weight = 3.

The calculation of VAF (Value added Factor) which is based on the TDI (Total Degree of
Influence of the 14 General system characteristics)
General System Characteristic Brief Description

1. Data communications How many communication facilities are there to

aid in the transfer or exchange of information
with the application or system?

2. Distributed data processing How are distributed data and processing

functions handled?

3. Performance Was response time or throughput required by the

user?

4. Heavily used configuration How heavily used is the current hardware

platform where the application will be executed?

5. Transaction rate How frequently are transactions executed daily,

weekly, monthly, etc.?

6. On-Line data entry What percentage of the information is entered

On-Line?
7. End-user efficiency Was the application designed for end-user
efficiency?

8. On-Line update How many ILF’s are updated by On-Line

transaction?

9. Complex processing Does the application have extensive logical or

mathematical processing?

10. Reusability Was the application developed to meet one or

many user’s needs?

11. Installation ease How difficult is conversion and installation?

12. Operational ease How effective and/or automated are start-up,

back-up, and recovery procedures?

13. Multiple sites Was the application specifically designed,

developed, and supported to be installed at
multiple sites for multiple organizations?

14. Facilitate change Was the application specifically designed,

developed, and supported to facilitate change?
These GSC are on a scale of 0-5
0 = No Influence , 1 = Incidental, 2 = Moderate, 3 = Average, 4 = Significant, 5 = Essential
3. Function point = FP = UFP x VAF
UFP = Sum of all the complexities i.e. the 5 parameters provided in the question,
VAF = Value added Factor i.e. 0.65 + (0.01 * TDI),
TDI = Total Degree of Influence of the 14 General System Characteristics.

Thus function points can be calculated as:

= (200 + 200 + 140 + 60 + 28) x (0.65 + (0.01 x (14 x 3))
= 628 x (0.65 + 0.42)
= 628 x (1.07)
= 672

FP: Advantages & Disadvantages

 l Advantages
Available early .. We need only a detailed specification
Not restricted to code
Language independent
More accurate than LOC
l Disadvantages
Ignores quality issues of output
Subjective counting ..depend on the estimator
Hard to automate..Automatic function-point counting is impossible
Example
Convert FPC to lines of source code (SLOC)
Language SLOC per Function Point
1GL Default Language 320
2GL Default Language 107
3GL Default Language 80
4GL Default Language 20
Assembler 320
C 128
Basic 107
Cobol 107
C++ 53
Java 2 46
Visual Basic 6 24
Delphi 18
HTML 4 14
SQL 13

Example : LOC Approach

Example : FP Approach
Example : FP Approach
Software Project Estimation:-
Software project estimation is necessary to achieve reliable cost and effort prediction. A project
estimation method usually involves the following steps:
• identify the project scope
o perform project decomposition
o compute the empirical metrics KLOC and/or FP
o apply an empirical model to obtain estimates of software cost, effort and duration.
o use for comparison automated estimation tools (optional)
The contemporary software projects are usually extremely large, and require decomposition and
re-characterization as a set of smaller, more manageable sub-problems.
The decomposition techniques take the "divide and conquer" approach to software project
estimation. Software estimation activities can be performed in a stepwise fashion when the
project is decomposed in major functions and related tasks.
The expected values for KLOC and FP can be computed as follows:
E=(a+4m+b)/6
where: a is the optimistic value m is the most likely value b is the pessimistic value.
Empirical Estimation Models:-
An estimation model for computer software uses empirically derived formulas to predict effort as
a function of LOC or FP.
Structure of the Estimation Models:-
E = A + B * ( ev )C
where: E is effort in person-months A, B, and C are empirically derived constants ev is the
estimated variable (LOC or FP).
Concrete Estimation Models:-
LOC oriented models
E = 5.2 * ( KLOC )0.91 Walston-Felix model

E = 5.5 + 0.73 * ( KLOC )1.16 Bailey-Basili model

E = 3.2 * ( KLOC )1.05 Boehm simple model

E = 5.288 * ( KLOC )1.047 Doty model for KLOC>9

FP oriented models
E = -91.4 + 0.355 * FP Alvrecht and Gaffney model
E = -37 + 0.96 *FP Kemerer model
E = -12.88 + 0.0405* FP Small project regression model
A quick examination of these models indicates that each will yield a different result
for the same values of LOC or FP. The implication is clear. Estimation models must
be calibrated for local needs!
The COCOMO Models: Constructive Cost Models:-
The Constructive Cost model was developed by Barry Boehm; this is a type of software that is
used to determine cost estimate. It works by combining a regression formula with predetermined
parameters that are derived through the data of a particular project. The main cocomo model
advantage is that you can determine the costs that will be incurred when investing in a particular
project
COCOMO is a cost estimation model used by thousands of software project managers and is
based on a study of scores of software projects.
The most fundamental calculation in the COCOMO model is the use of the Effort Equation to
estimate the number of Staff-Months required to develop a project.
Most other COCOMO results, including estimates for Requirements and Maintenance, are
derived from this quantity.
COCOMO II is an extension to the COCOMO model. COCOMO II takes into account new
development processes, increased flexibility in software development, need for decision making
with incomplete information and new data about projects.

COCOMO II
In his classic book on “software engineering economics,” Barry Boehm introduced a hierarchy of
software estimation models bearing the name COCOMO, for COnstructiveCOstMOdel. The
original COCOMO model became one of the most widely used and discussed software cost
estimation models in the industry. It has evolved into a more comprehensive estimation model,
called COCOMO II. Like its predecessor, COCOMO II is actually 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. Like all estimation
models for software, the COCOMO II models require sizing information. Three different sizing
options are available as part of the model hierarchy: object points, function points, and lines of
source code.
The COCOMO II application composition model uses object points and is illustrated in the
following paragraphs. It should be noted that other, more sophisticated estimation models (using
FP and KLOC) are also available as part of COCOMO II.
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. Each object instance (e.g., a screen or report) is classified
into one of three complexity levels (i.e., simple, medium, or difficult) using criteria suggested by
Boehm. In essence, complexity is a function of the number and source of the client and server
data tables that are required to generate the screen or report and the number of views or sections
presented as part of the screen or report.
Once complexity is determined, the number of screens, reports, and components are weighted
according to the table illustrated in Figure. The object point count is then determined by
multiplying the original number of object instances by the weighting factor in the figure and
summing to obtain a total object point count. 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) x[(100 - %reuse)/100]
Where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, a “productivity rate” must be
derived. Table presents the productivity rate
PROD = NOP/person-month
For different levels of developer experience and development environment maturity.
Once the productivity rate has been determined, an estimate of project effort is computed using
Estimated effort = NOP/PROD

The Software Equation

The software equation is a dynamic multivariable model that assumes a specific distribution of
effort over the life of a software development project. The model has been derived from
productivity data collected for over 4000 contemporary software projects. Based on these data,
we derive an estimation model of the form
E=(LOC x B0.333/P3) x 1/t4
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter” that reflects: overall process maturity and management practices,
the extent to which good software engineering practices are used, the level of programming
languages used, the state of the software environment, the skills and experience of the software
team, and the complexity of the application.
Typical values might be P = 2000 for development of real-time embedded software, P = 10,000
for telecommunication and systems software, and P = 28,000 for business systems applications.
The productivity parameter can be derived for local conditions using historical data collected
from past development efforts.
You should note that the software equation has two independent parameters: (1) an estimate of
size (in LOC) and (2) an indication of project duration in calendar months or years.
To simplify the estimation process and use a more common form for their estimation model,
Putnam and Myers suggest a set of equations derived from the software equation. Minimum
development time is defined as
tmin = 8.14x LOC/p0.43 in months for tmin > 6 months
E =180 Bt3 in person-months for E >=20 person-months
t in Equation is represented in years.
P = 12,000 (the recommended value for scientific software) for the CAD software
tmin = 8.14x 33200/120000.43 =12.6 calendar months
E = 180 x 0.28 x (1.05)3 = 58 person-months
Estimation is the process of finding an estimate, or approximation, which is a value that can be
used for some purpose even if input data may be incomplete, uncertain, or unstable.
Estimation determines how much money, effort, resources, and time it will take to build a
specific system or product. Estimation is based on −
• Past Data/Past Experience
• Available Documents/Knowledge
• Assumptions
• Identified Risks
The four basic steps in Software Project Estimation are −
• Estimate the size of the development product.
• Estimate the effort in person-months or person-hours.
• Estimate the schedule in calendar months.
• Estimate the project cost in agreed currency.
Observations on Estimation
• Estimation need not be a one-time task in a project. It can take place during −
o Acquiring a Project.
o Planning the Project.
o Execution of the Project as the need arises.
• Project scope must be understood before the estimation process begins. It will be helpful
to have historical Project Data.
• Project metrics can provide a historical perspective and valuable input for generation of
quantitative estimates.
• Planning requires technical managers and the software team to make an initial
commitment as it leads to responsibility and accountability.
• Past experience can aid greatly.
• Use at least two estimation techniques to arrive at the estimates and reconcile the
resulting values. Refer Decomposition Techniques in the next section to learn about
reconciling estimates.
• Plans should be iterative and allow adjustments as time passes and more details are
known.
General Project Estimation 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.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.
• Start with the statement of scope.
 • Decompose the software into functions that can each be estimated individually.
• Calculate the size of each function.
• Derive effort and cost estimates by applying the size values to your baseline productivity
metrics.
• Combine function estimates to produce an overall estimate for the entire project.
Step 3 − Generate an estimate of the effort and cost. You can arrive at the effort and cost
estimates by breaking down a project into related software engineering activities.
• Identify the sequence of activities that need to be performed for the project to be
completed.
• Divide activities into tasks that can be measured.
• Estimate the effort (in person hours/days) required to complete each task.
• Combine effort estimates of tasks of activity to produce an estimate for the activity.
• Obtain cost units (i.e., cost/unit effort) for each activity from the database.
• Compute the total effort and cost for each activity.
• Combine effort and cost estimates for each activity to produce an overall effort and cost
estimate for the entire project.
Step 4 − Reconcile estimates: Compare the resulting values from Step 3 to those obtained from
Step 2. If both sets of estimates agree, then your numbers are highly reliable. Otherwise, if
widely divergent estimates occur conduct further investigation concerning whether −
• The scope of the project is not adequately understood or has been misinterpreted.
• The function and/or activity breakdown is not accurate.
• Historical data used for the estimation techniques is inappropriate for the application, or
obsolete, or has been misapplied.
Step 5 − Determine the cause of divergence and then reconcile the estimates.
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. You will want every
estimate to be as accurate as possible, given the data you have at the time you generate it. And
of course you don’t want to present an estimate in a way that inspires a false sense of
confidence in the numbers.
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 the historical data or industry data used to calibrate the model matches 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 delays.
Following are some guidelines for achieving reliable estimates −
• Base estimates on similar projects that have already been completed.
• Use relatively simple decomposition techniques to generate project cost and effort
estimates.
• Use one or more empirical estimation models for software cost and effort estimation.
Refer to the section on Estimation Guidelines in this chapter.
To ensure accuracy, you are always advised to estimate using at least two techniques and
compare the results.
Estimation Issues
Often, project managers resort to estimating schedules skipping to estimate size. This may be
because of the timelines set by the top management or the marketing team. However, whatever
the reason, if this is done, then at a later stage it would be difficult to estimate the schedules to
accommodate the scope changes.
While estimating, certain assumptions may be made. It is important to note all these
assumptions in the estimation sheet, as some still do not document assumptions in estimation
sheets.
Even good estimates have inherent assumptions, risks, and uncertainty, and yet they are often
treated as though they are accurate.
The best way of expressing estimates is as a range of possible outcomes by saying, for example,
that the project will take 5 to 7 months instead of stating it will be complete on a particular date
or it will be complete in a fixed no. of months. Beware of committing to a range that is too
narrow as that is equivalent to committing to a definite date.
• You could also include uncertainty as an accompanying probability value. For example,
there is a 90% probability that the project will complete on or before a definite date.
• Organizations do not collect accurate project data. Since the accuracy of the estimates
depend on the historical data, it would be an issue.
• For any project, there is a shortest possible schedule that will allow you to include the
required functionality and produce quality output. If there is a schedule constraint by
management and/or client, you could negotiate on the scope and functionality to be
delivered.
• Agree with the client on handling scope creeps to avoid schedule overruns.
 • Failure in accommodating contingency in the final estimate causes issues. For e.g.,
meetings, organizational events.
• Resource utilization should be considered as less than 80%. This is because the resources
would be productive only for 80% of their time. If you assign resources at more than
80% utilization, there is bound to be slippages.
Estimation Guidelines
One should keep the following guidelines in mind while estimating a project −
• During estimation, ask other people's experiences. Also, put your own experiences at
task.
• Assume resources will be productive for only 80 percent of their time. Hence, during
estimation take the resource utilization as less than 80%.
• Resources working on multiple projects take longer to complete tasks because of the
time lost switching between them.
• Include management time in any estimate.
• Always build in contingency for problem solving, meetings and other unexpected events.
• Allow enough time to do a proper project estimate. Rushed estimates are inaccurate,
high-risk estimates. For large development projects, the estimation step should really be
regarded as a mini project.
• Where possible, use documented data from your organization’s similar past projects. It
will result in the most accurate estimate. If your organization has not kept historical
data, now is a good time to start collecting it.
• Use developer-based estimates, as the estimates prepared by people other than those who
will do the work will be less accurate.
• Use several different people to estimate and use several different estimation techniques.
• Reconcile the estimates. Observe the convergence or spread among the estimates.
Convergence means that you have got a good estimate. Wideband-Delphi technique can
be used to gather and discuss estimates using a group of people, the intention being to
produce an accurate, unbiased estimate.
• Re-estimate the project several times throughout its life cycle.

What Is Project Scheduling?

Project scheduling is a mechanism to communicate what tasks need to get done and which
organizational resources will be allocated to complete those tasks in what timeframe. A project
schedule is a document collecting all the work needed to deliver the project on time.
What and who is being scheduled, and for what purposes, and where is this scheduling taking
place, anyway?
A project is made up of many tasks, and each task is given a start and end (or due date), so it can
be completed on time. Likewise, people have different schedules, and their availability and
vacation or leave dates need to be documented in order to successfully plan those tasks.
Whereas people in the past might have printed calendars on a shared wall in the water-cooler
room, or shared spreadsheets via email, today most teams use online project scheduling tools.
Typically, project scheduling is just one feature within a larger project management software
solution, and there are many different places in the software where scheduling takes place.
For example, most tools have task lists, which enable the manager to schedule multiple tasks,
their due dates, sometimes the planned effort against that task, and then assign that task to a
person. The software might also have resource scheduling, basically the ability to schedule the
team’s availability, but also the availability of non-human resources like machines or buildings
or meeting rooms.
Because projects have so many moving parts, and are frequently changing, project scheduling
software automatically updates tasks that are dependent on one another, when one scheduled task
is not completed on time. It also generates automated email alerts, so team members know when
their scheduled tasks are due or overdue, and to let the manager know when someone’s
availability has changed.
Project scheduling is simple when managed online, thankfully, especially since the software does
all the hard part for you!
How to Schedule a Project
Before going deeper into project scheduling, let’s review the fundamentals to project scheduling.
Project scheduling occurs during the planning phase of the project. You have to ask yourself
three questions to start:
1. What needs to be done?
2. When will it be done?
3. Who will do it?
Once you’ve got answers to these questions, then you can begin to plan dates, link activities, set
the duration, milestones and resources. The following are the steps needed to schedule a project:
Define Activities
What are the activities that you have to do in the project? By using a Work Breakdown Structure
(WBS) and a deliverables diagram, you can begin to take these activities and organize them by
mapping out the tasks necessary to complete them in an order than makes sense.
Do Estimates
Now that you have the activities defined and broken down into tasks, you next have to determine
the time and effort it will take to complete them. This is an essential piece of the equation in
order to calculate the correct schedule.
Determine Dependencies
Tasks are not an island, and often one cannot be started until the other is completed. That’s
called a task dependency, and your schedule is going to have to reflect these linked tasks. One
way to do this is by putting a bit of slack in your schedule to accommodate these related tasks.
Assign Resources
The last step to finalizing your planned schedule is to decide on what resources you are going to
need to get those tasks done on time. You’re going to have to assemble a team, and their time
will need to be scheduled just like the tasks.
How to Maintain Your Schedule Once the Project Is Initiated
Once you’ve got all the pieces of your schedule together, the last thing you want to do is
manually punch it into a static document like an Excel spreadsheet. Project management
software can automate much of the process for you. But not all project management software is
the same.
There are programs on the market that are great for simple scheduling duties, but when you’re
leading a project, big or small, you need a tool that can adapt to the variety of scheduling issues
you’re going to need to track. Like noted above, there are three tiers of scheduling: tasks, people
and projects.

Scheduling Tasks
What you want when scheduling tasks is not a glorified to-do list, but a smart software that gives
you the flexibility to handle the variety of responsibilities attached to each tasks in your project.
An interactive Gantt chart is crucial. You can add tasks and dates into your Gantt chart to have a
visual representation of each task’s duration. Better still, as dates change—as they inevitably
do—you can simply drag and drop those changes and the whole Gantt chart is updated instantly.
Related: Free Gantt Chart Template
There’s also automating processes to help with efficiencies. Email notifications are a great way
to know immediately when a team member has completed a task. When they update, you know
because your software is online and responding in real-time.
Continuing with automation, it’s one way to scheduling tasks more efficiently. If there are
recurring tasks on a project, they can be scheduled in your PM tool so that once set you don’t
have to worry about scheduling the same task over and over again.

Scheduling People
Your tasks aren’t going to complete themselves. That’s why you have assembled a team, but if
that team isn’t scheduled the way you have carefully scheduled your task list, then you’re not
managing your project.
Over the course of a project’s lifecycle team members are going to take off for holidays, personal
days or vacation. If you’re not prepared for these times, and have scheduled other team members
to pick up the slack in their absence, your schedule will suffer.
Integrating your calendar into a project management software is a simple way to stay on top of
your resources. There’s no reason to use a standalone calendar that sends you to another
application every time you need to check on a team member’s availability.
Another way to stay on top of your scheduling is by integrating your task scheduling view on the
Gantt chart with resource and workload scheduling features. You can schedule your team’s
workload through color-coding, so you know at-a-glance who is behind, ahead or on schedule
with their tasks.
Scheduling Projects
We’re gone from the task level to the resources level of scheduling, but there’s no law that says
you’re not working on a portfolio of projects. How can you keep on scheduling when juggling so
many balls in the air at once?
The project dashboard is your best friend, whether you’re working on one or many projects. The
dashboard is collecting all the real-time data collected by you and your teams, and then it’s
organizing it according to any number of metrics to show you a picture of where you stand in
real-time on the project or many projects.
With a project dashboard you can note where tasks are being blocked and immediately adjust
your schedule to resolve delays before they become a problem. You can also use the graphs and
charts the dashboard automatically generates to drill down deeper and filter or customize the
results to get the information you need, when you need it.
And that’s just a fraction of what we could say about project scheduling. Our ongoing series
explains and explores new and relevant terms in project management, focusing on a specific
definition and summarizing what it means for anyone leading a project.
But to really get to know scheduling, it’s best to dive in with a project tool, your tasks and your
team and create a new project schedule today.
Scheduling is one of the more difficult jobs in project management, but coordinating delivery
dates on your estimates can be streamlined and made more efficient when you employ the tools.
From interactive Gantt charts, resource and workload management that can be easily integrated
to a real-time reporting dashboard, you’ve never had a tighter hand on your project schedule.
What is a Timeline Chart?
A timeline chart is an effective way to visualize a process using chronological order. Since
details are displayed graphically, important points in time can be easy seen and understood.
Often used for managing a project’s schedule, timeline charts function as a sort of calendar of
events within a specific period of time.

Project Management Tools

The risk and uncertainty rises multifold with respect to the size of the project, even when the
project is developed according to set methodologies.
There are tools available, which aid for effective project management. A few are described -
Gantt Chart
Gantt chart is a type of a bar chart that is used for illustrating project schedules. Gantt charts can
be used in any projects that involve effort, resources, milestones and deliveries.
At present, Gantt charts have become the popular choice of project managers in every field.
Gantt charts allow project managers to track the progress of the entire project. Through Gantt
charts, the project manager can keep a track of the individual tasks as well as of the overall
project progression.
In addition to tracking the progression of the tasks, Gantt charts can also be used for tracking
the utilization of the resources in the project. These resources can be human resources as well as
materials used.

Gantt charts was devised by Henry Gantt (1917). It represents project schedule with respect to
time periods. It is a horizontal bar chart with bars representing activities and time scheduled for
the project activities.
5 Gantt Charts benefits
Companies apply these charts to become more productive, increase communication, forecast and
track their results.
You can define and list many advantages of Gantt charts, but we are going to highlight the 5 key
benefits:
1. As Gantt charts keep users on track and provide a visual timeline for starting and
finishing tasks, they really help to avoid project’s completion confusion. The charts
propose an understandable method of maintaining timescale-based tasks and deliverables.
2. If you manage a complex task, Gantt project plan diagrams eliminate misunderstandings
and keep everyone on the page. It’s quite important if there is a visual framework for the
objectives to be done. The charts allow everyone in a team to have the same information
and set mutually understood expectations.
3. The diagrams help to clarify task relationships and get the best workflow and overall
success.
4. Users can clearly understand where resources need to be allocated or shared. That’s why
we can confidently say that the charts effectively divide resources.
5. The charts help decision makers to look ahead to ensure each given project is working
toward the achievement of the company’s strategic goals.

PERT Chart
PERT (Program Evaluation & Review Technique) chart is a tool that depicts project as network
diagram. It is capable of graphically representing main events of project in both parallel and
consecutive way. Events, which occur one after another, show dependency of the later event
over the previous one.
Events are shown as numbered nodes. They are connected by labeled arrows depicting sequence
of tasks in the project.
Resource Histogram
This is a graphical tool that contains bar or chart representing number of resources (usually
skilled staff) required over time for a project event (or phase). Resource Histogram is an
effective tool for staff planning and coordination.
What are the purposes of timeline charts?
If you work with complex or simple objectives, you know that they may have many moving
parts. Sometimes these parts can be time-sensitive, so make sure everything is planned properly
and runs according to your schedule.
Timeline charts are good for projects involving many people. It doesn’t demand a lot of time or
efforts to make a chart and keep it.
Online project timelines are similar to Gantt charts as these both diagram types deal with time
and events.
Tracking Project Schedules
• Periodic project status meetings with each team member reporting progress and problems
• Evaluation of results of all work product reviews
• Comparing actual milestone completion dates to scheduled dates
• Comparing actual project task start-dates to scheduled start-dates
• Informal meeting with practitioners to have them asses subjectively progress to date and
future problems
• Use earned value analysis to assess progress quantitatively
Tracking Increment Progress for OO Projects
• Technical milestone: OO analysis complete
o All hierarchy classes defined and reviewed
o Class attributes and operations are defined and reviewed
o Class relationships defined and reviewed
o Behavioral model defined and reviewed
o Reusable classed identified
• Technical milestone: OO design complete
o Subsystems defined and reviewed
o Classes allocated to subsystems and reviewed
o Task allocation has been established and reviewed
o Responsibilities and collaborations have been identified
o Attributes and operations have been designed and reviewed
o Communication model has been created and reviewed
• Technical milestone: OO programming complete
o Each new design model class has been implemented
o Classes extracted from the reuse library have been implemented
o Prototype or increment has been built
• Technical milestone: OO testing complete
 The correctness and completeness of the OOA and OOD models has been
o
reviewed
o Class-responsibility-collaboration network has been developed and reviewed
o Test cases are designed and class-level tests have been conducted for each class
o Test cases are designed, cluster testing is completed, and classes have been
integrated
o System level tests are complete
WebApp Project Scheduling
• During the first iteration a macroscopic is developed by allocating effort to specific tasks
(it is understood that this is changeable schedule)
• The project is broken up into increments and the increments are refined in to detailed
schedules as each is begun (some increments may be developed in parallel)
• Each task on the task list for each increment is adapted in one of four ways as its detailed
schedule is created
o task is applied as is
o task is eliminated because it is not necessary for the increment
o new (custom) task is added
o task is refined (elaborated) into a number of named subtasks that each becomes
part of the schedule
• This process continues until each planned increment is completed
Earned Value Analysis
• Earned value is a quantitative measure given to each task as a percent of project
completed so far.
1. The total hours to complete each project task are estimated (BCWS - budgeted cost of
work scheduled)
2. The effort to complete the project is computed by summing the effort to complete each
task (BAC - budget at completion)
3. Each task is given an earned value based on its estimated percentage contribution to the
total (BCWP - budgeted cost of work completed).
• It is compute the actual cost of work performed (ACWP) at any point in the project and
to compute progress indicators for both schedule and costs based on these measures