Unit 3 : Managing Software Project

Syllabus Topics
• Software Metrics
- People
-Process
- Product
- Project
• Software measurement
• Software Project Estimations
• Software Project Planning (MS Project Tool)
• Project Scheduling & Tracking
• Risk Analysis & Management
-Risk Identification
- Risk Projection
- Risk Refinement
2
- Risk Mitigation
Questions asked in GTU
1. Explain Software Project management and W5HH principle ( Winter
2017)
2. Explain Risk Management. (summer 2016,s-19)
3. Explain project scheduling and tracking with suitable example.
(summer 2016)
4. What is Software Measurement? Explain Software metrics used for
software cost estimation. (Summer 2016, Winter 2017,w-19)
5. Explain project scheduling process. Explain Gantt Chart(Timeline chart)
in detail. (Summer 2016)
6. Explain RMMM plan ( Winter 2017,Winter 2016, Summer 2017,w-19)
7. Explain COCOMO model ( Winter 2017, Winter 2018,s-19)
8. Draw the Time-line chart for the Library Management System. (winter
2018)
 9. Explain Project Scheduling Process. Also Explain Gantt Chart in
detail. (w-2019)
10. Explain 4 P’s of Effective Project Management in detail. (s-19)

4
 Software Project Management

“Software project management is concerned with activities

involved in ensuring that software is delivered on time and on
schedule and in accordance with the requirements of the
organisations developing and producing the software”

5
Importance of software project management

• Project management includes identifying requirements,

establishing clear and achievable objectives, balancing the
competing demands from the different stakeholders and
ensuring that a commonality of purpose is achieved.
• It is the art of managing the project and its deliverables with a
view to produce finished products or service.
• An effective software management will ensure that all
stakeholders are involved in decision making process and
understand their role in achieving their objectives.
Basic Terms:
• Measure
• It provides a quantitative indication of the extent (range),
amount, dimension, capacity or size of some attributes of a
product or process.
• Ex., the number of uncovered errors.
• Metrics
• It is a quantitative measure of the degree (limit) to which a
system, component or process obtain a given attribute.
• It relates individual measures in some way.
• Ex., number of errors found per review.

7
• Indicators
• It is a metric or combination of metrics that provides insight
into the software process, project or the product itself.
• It enables the project manager or software engineers to adjust
the process, the project or the product to make things better.
• Ex., Product Size (analysis and specification metrics) is an indicator of
increased coding, integration and testing effort
• Direct Metrics
• Immediately measurable attributes.
• Ex., Line of Code (LOC), Execution Speed, Defects Reported
• Indirect Metrics
• Aspects that are not immediately quantifiable.
• Ex., Functionality, Quantity, Reliability
• Faults
• Errors
• Faults found by the practitioners during software development.
• Defects
• Faults found by the customers after release.

9
Why Measure Software?
• To determine (to define) quality of a product or process.
• To predict qualities of a product or process.
• To improve quality of a product or process.

10
 Software metrics
Effective software project management focuses
on the four P’s:
• People
• Product Product
• Process
• Project.
People Process

Project
11
 • People — The most important element of a successful
project. It Consists of the stakeholders, the team leaders,
and the software team
• Product — The software to be built. Product objectives
and scope should be established before a project can be
planned
• Process — The set of framework activities and software
engineering tasks to get the job done
• Project — all work required to make the product a reality

12
 People

Stakeholders Software team Team Leader Agile Team

Senior Project Practitioners Customers End-users

Manager Manager

13
 People : Stakeholders
• Senior managers who define the business issues
• 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.

14
People : Software Teams

How to lead?
How to organize?
How to
collaborate?

How to motivate? How to create good

ideas?

15
Software Teams
The following factors must be considered when selecting
a software project team structure ...

• The difficulty of the problem to be solved

• The size of the resultant program(s) in lines of code or
function points to be considered
• The time that the team will stay together (team
lifetime)
• The required quality and reliability of the system to be
built
• The Flexibility of the delivery date
• The degree of sociability (communication) required for
the project
16
People: Team Leader
• The MOI Model for leadership
• 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.

17
People : Agile Teams

• Team members must have trust in one another.

• The distribution of skills must be appropriate to the
problem. .
• Team is “self-organizing”
• An adaptive team structure
• Agile team is allowed to select its own approach for
software development
• The only condition is that business requirements must
be satisfied during development

18
Product : Scope
Scope is defined by answering the following questions:
• Context. How does the software to be built fit into
a larger system, 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?
• Software project scope must be unambiguous and
understandable at the management and technical levels.
19
 Product : Problem
Decomposition
• Sometimes called partitioning or problem
elaboration
• Once scope is defined …
• It is decomposed into constituent functions
• It is decomposed into user-visible data objects
or
• It is decomposed into a set of problem classes
• Decomposition process continues until all
functions or problem classes have been defined

20
 Process
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
• Project planning begins as a melding of the product and the
process based on the various framework activities

21
 Process: Melding the Problem
and the Process
• Project planning begins with the melding of the product
and the process.
• Each function to be engineered by your team must pass
through the set of framework activities that have been
defined for your software organization.

22
 Process: Process decomposition
• Once the process model has been chosen, the process
framework is adapted to it.
• A software team should have a significant degree of
flexibility in choosing the software process model that is
best for the project and the software engineering tasks
that populate the process model once it is chosen.
• projects with other characteristics (e.g., uncertain
requirements, breakthrough technology, difficult
customers, significant reuse potential) will lead to the
selection of other process models.

23
The Project
• Projects get into trouble when …
• 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 ill-defined].
• Deadlines are unrealistic.
• 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.

24
Project : 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
• 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.

25
 • 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 : Evaluate the planned

and actual schedules, collect and analyze software project
metrics, get feedback from team members and customers,
and record findings in written form.

26
 5
The W HH Principle
A series of questions that lead to a definition of key project
characteristics and the resultant project plan

• Why is the system being developed?

• Assesses the validity of business reasons and
justifications
• What will be done?
• Establishes the task set required for the project
• When will it be done?
• Establishes a project schedule
• Who is responsible for a function?
• Defines the role and responsibility of each team
member

27
• Where are they organizationally located?
• Notes the organizational location of team members,
customers, and other stakeholders
• How will the job be done technically ?
• Establishes the management and technical strategy for
the project
• How much of each resource is needed?
• Establishes estimates based on the answers to the
previous questions

28
What is Risk ??
• Risk is an expectation of loss, a potential problem that
may or may not occur in the future..
• A possibility of suffering from loss in software
development process is called a software risk

Two characteristics of risk

• Uncertainty
• The risk may or may not happen, so there are no 100%
risks (some of those may called constraints).
• Loss
• The risk becomes a reality and unwanted consequences or
losses occur.
29
 Types of Software risk

Project Risk Business risk Technical risk

Market Strategic Management Budget Sales

Risk Risk Risk Risk Risk

30
Types of Risk
Project risks
• They threaten the project plan.
• If they become real, it is likely that the project schedule will slip
and that costs will increase.
Ex- Loss of an experienced developer and designer
Technical risks
• They threaten the quality and timeliness of the software to be
produced.
• If they become real, implementation may become difficult or
impossible.
Business risks
• They threaten the feasibility of the software to be built.
• If they become real, they threaten the project or the product.
31
Ex- A Competitor of organization introduce a new product
Sub-categories of Business risks
• Market risk
• Building an excellent product or system that no one really wants.
• Strategic risk
• Building a product that no longer fits into the overall business strategy
for the company.
• Sales risk
• Building a product that the sales force doesn't understand how to sell.
• Management risk
• Losing the support of senior management due to a change in focus or a
change in people.
• Budget risk
• Losing budgetary or personnel commitment.

32
 Another general categorization of risks has been
proposed by Charette :
• Known risks
• Those risks that can be uncovered after careful evaluation of
• the project plan,
• the business and technical environment in which the
project is being developed, and
• other reliable information sources (Ex. unrealistic delivery
date)
• Predictable risks
• Those risks that are deduced (draw conclusion) from past
project experience (Ex. past turnover)
• Unpredictable risks
• Those risks that can and do occur, but are extremely difficult to
identify in advance. 33
Reactive vs. Proactive Risk Strategies
• Reactive risk strategies
• "Don't worry, I will think of something“.
• The majority of software teams and managers rely on this
approach.
• Nothing is done about risks until something goes wrong.
• The team then flies into action in an attempt to correct the problem
rapidly (fire fighting).
• Proactive risk strategies
• Avoid the risk initially when actually technical work begins.
• Steps for risk management are followed.
• Primary objective is to avoid risk and to have an emergency
plan in place
• to handle unavoidable risks in a controlled and effective manner.
34
Risk Analysis and Management
• Risk Identification
• Risk Projection
• Risk Refinement
• Risk Mitigation

35
Steps for Risk Management
• Identify possible risks and recognize what can go wrong.
• Analyze each risk to estimate the probability that it will
occur and the impact (i.e., damage) that it will do if it
does occur.
• Rank the risks by probability and impact
• Impact may be negligible, marginal, critical, and catastrophic.
• Develop a contingency plan to manage those risks having
high probability and high impact.

36
Risk Identification
• Risk identification is a systematic attempt to specify
threats to the project plan.
• By identifying known and predictable risks, the project
manager takes a first step toward,
• avoiding them when possible
• controlling them when necessary
• There are two types of risk :
1) Generic Risks
• Risks that are a potential threat to every software project.
2) Product-specific Risks
• Risks that can be identified only by clear understanding of the
technology, the people and the environment, that is specific to
the software that is to be built.
37
 Known and Predictable Risk
Categories
• One method for identifying risks is to create a risk item checklist.
• The checklist can be used for risk identification which focuses on
some subset of known and predictable risks in the following
generic subcategories:
• Product Size
• Risks associated with overall size of the software to be built.
• Business Impact
• Risks associated with constraints imposed by management
or the marketplace.
• Customer Characteristics
• Risks associated with sophistication of the customer and the
developer's ability to communicate with the customer in a
timely manner.

38
• Process Definition
• Risks associated with the degree to which the software
process has been defined and is followed.
• Development Environment
• Risks associated with availability and quality of the tools to
be used to build the project.
• Technology to be Built
• Risks associated with complexity of the system to be built
and the “newness” of the technology in the system.
• Staff Size and Experience
• Risks associated with overall technical and project
experience of the software engineers who will do the work.

39
Risk Projection (Estimation)
• Risk projection (or estimation) attempts to rate each risk
in two ways.
• The probability that the risk is real.
• The consequence (effect) of the problems associated with the
risk.
• Risk Projection/Estimation Steps
• Establish a scale that reflects the probability of a risk.
• Ex., 1-low, 10-high
• Explain the consequences of the risk.
• Estimate the impact of the risk on the project and product.
• Note the overall accuracy of the risk projection so that there
will be no misunderstandings.

40
Building a Risk Table
Risk Probability Impac RMM
t M

Risk
Mitigation
Monitoring
&
Managemen
t

41
 Building the Risk Table
• Estimate the probability of occurrence
• Estimate the impact on the project on a scale
of 1 to 5, where
• 1 = low impact on project success
• 5 = catastrophic impact on project success
• sort the table by probability and impact

42
 Risk Exposure (Impact)
Risk exposure is the measure of potential future loss
resulting from a specific activity or event.

The overall risk exposure, RE, is determined using the

following relationship:
RE = P x C
where
P is the probability of occurrence for a risk, and
C is the cost to the project should the risk occur.

43
Risk Exposure Example
• Risk identification. Only 70 percent of the software
components scheduled for reuse will, in fact, be integrated
into the application. The remaining functionality will have
to be custom developed.
• Risk probability. 80%
• Risk impact. 60 software components were planned. If
only 70 percent can be used, 18 components would have
to be developed from scratch (in addition to other custom
software that has been scheduled for development). Since
the average component is 100 LOC and local data indicate
that the software engineering cost for each LOC is $14.00,
the overall cost (impact) to develop the components
would be 18 x 100 x 14 = $25,200.
• Risk exposure. RE = 0.80 x 25,200 ~ $20,200.
44
 Risk Refinement
• Process of restating the risks as a set of more
detailed risks that will be easier to mitigate,
monitor, and manage.
• CTC (condition-transition-consequence) format
may be a good representation for the detailed
risks (e.g. given that <condition> then there is a
concern that (possibly) <consequence>)
• Condition is a description of the current
conditions prompting concern. Transition is the
part that involves change (time). Consequence is a
description of the potential outcome.
45
 Risk Mitigation, Monitoring, and Management
(RMMM Plan)
Following are three important issues or steps that must be
considered for developing effective strategies:
• Risk mitigation (proactive planning for risk avoidance)
• Risk monitoring (assessing whether predicted risks occur or not,
ensuring risk aversion steps are being properly applied, collect
information for future risk analysis, attempt to determine which
risks caused which problems)
• Risk management and contingency planning (actions to be taken in
the event that mitigation steps have failed and the risk has become
a live problem)

46
 • The goal - identify as many potential risks as possible.
• When all risks have been identified, they will then be
evaluated to determine their probability of occurrence,
Plans will then be made to avoid each risk, to track each
risk to determine if it is more or less likely to occur, and to
plan for those risks should they occur.
• It is the organization’s responsibility to perform risk
mitigation, monitoring, and management in order to
produce a quality product.
• The quicker the risks can be identified and avoided, the
smaller the chances of having to face that particular risk’s
consequence.
• The fewer consequences suffered as a result of good
RMMM plan, the better the product, and the smoother the
development process.

47
Risk Mitigation
• Risk mitigation (avoidance) is the primary strategy and is
achieved through a plan
• For Ex., Risk of high staff turnover
• To mitigate this risk, you would develop a strategy for reducing
turnover.
• The possible steps to be taken are:
• Meet with current staff to determine causes for turnover
(e.g., poor working conditions, low pay, and competitive job
market).
• Mitigate those causes that are under your control before
the project starts.
• Once the project commences, assume turnover will occur
and develop techniques to ensure continuity when people
leave.
• Organize project teams so that information about each
development activity is widely dispersed. 48
Risk Mitigation
• Define work product standards and establish mechanisms
to be sure that all models and documents are developed in
a timely manner.
• Conduct peer reviews of all work (so that more than one
person is “up to speed”).
• Assign a backup staff member for every critical technologist.

49
 Risk Monitoring
• The project manager monitors factors that may provide an
indication of whether the risk is becoming more or less
likely.
• In the case of high staff turnover, the general attitude of
team members based on project pressures, the degree to
which the team has jelled, inter-personal relationships
among team members, potential problems with
compensation and benefits, and the availability of jobs
within the company and outside it are all monitored.

50
 • In addition to monitoring these factors, a project manager
should monitor the effectiveness of risk mitigation steps.
• The project manager should monitor work products
carefully to ensure that each can stand on its own and that
each imparts information that would be necessary if a
newcomer were forced to join the software team
somewhere in the middle of the project.

51
 Risk Management
• Risk management and contingency planning assumes that
mitigation efforts have failed and that the risk has become
a reality.
• If the mitigation strategy has been followed, backup is
available, information is documented, and knowledge has
been dispersed across the team.
• In addition, you can temporarily refocus resources (and
readjust the project schedule) to those functions that are
fully staffed, enabling newcomers who must be added to
the team to “get up to speed.” Those individuals who are
leaving are asked to stop all work and spend their last
weeks in “knowledge transfer mode.”

52
Why Do We Measure
software?
• assess the status of an ongoing project
• track potential risks
• uncover problem areas before they go “critical,”
• adjust work flow or tasks,
• evaluate the project team’s ability to control quality
of software work products.

53
Types of Measures
• Two categories of software measurement
1. Direct measures of the
• Software process
• Ex., cost, effort, etc.
• Software product
• Ex., lines of code produced,defects reported, etc.
2. Indirect measures of the
• Software product
• Ex. functionality, quality, complexity, efficiency, reliability, etc.

54
Software Measurement
• Software Metrics for Software Cost & Effort Estimations.
1. Size-Oriented Metrics
2. Function-Oriented Metrics
3. Object-Oriented Metrics
4. Use-Case–Oriented Metrics
5. Web-App Project Metrics

55
1. Size-Oriented Metrics
• Derived by normalizing (standardizing) quality and/or
productivity measures by considering the size of the
software produced.
• Thousand lines of code (KLOC) are often chosen as the
normalization value.
• A set of simple size-oriented metrics can be developed for
each project
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $ per KLOC
• Pages of documentation per KLOC

56
• In addition, other interesting metrics can be computed,
like
• Errors per person-month
• KLOC per person-month
• $ per page of documentation
• Size-oriented metrics are not universally accepted as the
best way to measure the software process.

57
2. Function-Oriented Metrics

• Function-oriented metrics use a measure of the functionality

delivered by the application as a normalization value

• Most widely used metric of this type is the Function Point

FP = Total count* [0.65 + 0.01 * ∑ (Value Adjustment Factors)]

• Function Point values on past point projects can be used to

compute,
• for example, the average number of lines of code per function

58
Function Point Components
• Information domain values (components) are defined in the
following manner
• Number of external inputs (EIs)
• input data originates from a user or is transmitted from
another application.
• Number of external outputs (EOs)
• external output is derived data within the application that
provides information to the user.
• output refers to reports, screens, error messages, etc.
• Number of external inquiries (EQs)
• external inquiry is defined as an online input that results in
the generation of some immediate software response in the
form of an online output.

59
Function Point Components
• Number of internal logical files (ILFs)
• internal logical file is a logical grouping of data that resides
within the application’s boundary and is maintained via
external inputs.
• Number of external interface files (EIFs)
• external interface file is a logical grouping of data that
resides external to the application but provides
information that may be of use to the another application.

60
Compute Function Points
• Formula
• FP = Total count * [ 0.65 + 0.01 * ∑(Fi) ]
• Total count = Information Domain Value Count * weighting factor

• Weighting factor is determined for each organization via empirical

(based on experience) data.
• Fi (i=1 to 14) are complexity value adjustment factors (VAF).

complexity adjustment values are ranked from 0 to

5:
0 - No influence
1 - Incidental
2- Moderate
3- Average
4- Significant
5- Essential 61
Compute total count for Function
Points

62
Value Adjustment Factors
• F1. Data Communication • F8. Online Update
• F2. Distributed Data • F9. Complex Processing
Processing • F10. Reusability
• F3. Performance • F11. Installation Ease
• F4. Heavily Used • F12. Operational Ease
Configuration
• F13. Multiple Sites
• F5. Transaction Role
• F14. Facilitate Change
• F6. Online Data Entry
• F7. End-User Efficiency
Note :
• Fi for moderate case=2
• Fi for average case = 3.
• So sum of all Fi ( 1 to 14)
• So sum of all Fi ( 1 to 14)
• = 14 * 2 = 28 63
• = 14 * 3 = 42
Function Point Example

64
Function Point Example (Cont…)
• Adjustment calculation
• Adjusted FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]
= count total x [ 0.65 + (0.01 x Adjustment Factor) ]
= 50 x [ 0.65 + (0.01 x (14*2)) ]
= 50 x [ 0.42 ]
= 50.42

65
 Function point Example ( GTU-
Summer 2017)
Compute function point value for a project with
following domain characteristics :
No. of I/P =30
No. of O/P=62
No. of User inquires =24
No. of files= 8
No. of External Interfaces= 2
Assume that all the complexity adjustment values
and weighting factors are average.

66
 Solution

FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]

= (30*4 + 62*5 + 24*4 + 8*10 + 7*2 ) x [ 0.65
+ (0.01 x ( 14*3) ]
= 620x [ 0.65 + (0.01 x 42) ]
= 629 x [1.07 ]
= 663.4

67
Example 2
Compute function point value for a project with
following domain characteristics :
• No. of I/P =35
• No. of O/P=67
• No. of User inquires =22
• No. of files= 12
• No. of External Interfaces=4
• Assume that all the complexity adjustment values
are moderate & weighting factors are average.

68
 Solution
all the complexity adjustment values and
weighting factors are average .

FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]

= (35*4 + 67*5 + 22*4 + 12*10 + 4*7 ) x [
0.65 + (0.01 x ( 14*3) ]
= (149 +335+ 88+120+28) *[0.65 +(0.01*42)]
= 711*1.07
= 760.77

69
 Solution-2
all the complexity adjustment values are
moderate and weighting factor are average .

FP = Count Total * [ 0.65 + 0.01 * ∑(Fi) ]

= (35*4 + 67*5 + 22*4 + 12*10 + 4*7 ) x [
0.65 + (0.01 x ( 14*2) ]
= (149 +335+ 88+120+28) *[0.65 +(0.01*28)]
= 711*0.93
= 661.23

70
3. Object-Oriented Metrics
• Conventional software project metrics (LOC or FP) can be used to
estimate object-oriented software projects.
• However, these metrics do not provide enough granularity
(detailing) for the schedule and effort adjustments that are
required as you iterate through an evolutionary or incremental
process.
• Lorenz and Kidd suggest the following set of metrics for OO
projects
• Number of scenario scripts (Sequence of steps that describe
the interaction between user and application)
• Number of key classes (the highly independent components)
• Number of support classes
• Average number of support class per key class
• Number of Subsystem
71
4. Use-Case–Oriented Metrics
• Like FP, the use case is defined early in the software process,
allowing it to be used for estimation before significant (valuable)
modeling and construction activities are initiated.
• Use cases describe (indirectly, at least) user-visible functions and
features that are basic requirements for a system.
• The use case is independent of programming language, because
use cases can be created at vastly different levels of abstraction,
there is no standard “size” for a use case.
• Without a standard measure of what a use case is, its application as
a normalization measure is suspect (doubtful).
• Ex., effort expended / use case

72
73
5. WebApp Project Metrics
• Number of static Web pages (the end-user has no control over the
content displayed on the page)
• Number of dynamic Web pages (end-user actions result in customized
content displayed on the page)
• Number of internal page links (internal page links are pointers that
provide a hyperlink to some other Web page within the WebApp)
• Number of persistent data objects (eg. Database )
• Number of static content objects (already exist within app,
eg. Static Text based ,animation, video etc)
• Number of dynamic content objects( generated based on user action , eg.
Text based ,animation, video etc)
• Number of executable functions

74
 Software Project Estimation

75
Estimation Accuracy
• Predicated on …
• the degree to which the planner has properly estimated
the size of the product to be built
• the ability to translate the size estimate into human effort,
calendar time, and dollars (a function of the availability of
reliable software metrics from past projects)
• the degree to which the project plan reflects the abilities
of the software team
• the stability of product requirements and the
environment that supports the software engineering
effort.

76
Software Project Decomposing
• Software project estimation is a form of problem solving
and in most cases, the problem to be solved is too
complex to be considered in one piece.
• For this reason, decomposing the problem,
re-characterizing it as a set of smaller problems is
required.
• Before an estimate can be made, the project planner
must understand the scope of the software to be built
and must generate an estimate of its “size”.

77
Functional Decomposition
Statement functional
of decomposition
Scope
Perform a
Decomposition

78
COCOMO model – Estimation model
• Stands for COnstructive COst MOdel.
• Introduced by Barry Boehm in 1981.
• It became one of the well-known and widely-used
estimation models in the industry.
• It has evolved into a more comprehensive (complete)
estimation model called COCOMO II.

79
 Organic, Semidetached and Embedded software projects
• Organic
• A development project can be considered of organic type,
• if the project deals with developing a well understood
application program,
• the size of the development team is reasonably small, and
• the team members are experienced in developing similar
types of projects.
• Semidetached
• A development project can be considered of semidetached
type,
• if the development consists of a mixture of experienced
and inexperienced staff.
• Team members may have limited experience on related
systems but may be unfamiliar with some aspects of the
80
system being developed.
• Embedded
• A development project is considered to be of embedded type,
• if the software being developed is strongly coupled to
complex hardware, or
• if the stringent regulations (strong rules) on the operational
procedures exist.

81
• The basic COCOMO model gives an approximate estimate
of the project parameters.
• The basic COCOMO estimation model is given by
following expressions:
• Effort = a x (KLOC)b PM (person Month)
• Time of Development = c x (Effort)d Months
• Where, a,b,c,d are constants for each category of software products
• Estimation of Effort
Project Type a b
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20
• Effort = 2.4 (KLOC)1.05 PM
• Effort = 3.0 (KLOC)1.12 PM
• Effort = 3.6 (KLOC)1.20 PM
82
• Estimation Time of Development
Project Type c d
Organic 2.5 0.38
Semi-detached 2.5 0.35
Embedded 2.5 0.32

• Organic: Time of Development = 2.5 (Effort)0.38 Months

• Semi-detached: Time of Development = 2.5 (Effort)0.35 Months
• Embedded: Time of Development = 2.5 (Effort)0.32 Months

83
Example 1
• Assume that the size of an organic software product has
been estimated to be 32,000 lines of source code.
Assume that the average salary of software be Rs.
15,000/- month. Determine the effort required to
develop the software product and the nominal
development time.

• Effort= 2.4 x (32)1.05 = 91 PM

• Time of development = 2.5 x (91)0.38 = 14 months
• Cost= 91*14 * 15,000 = Rs. 19110000

84
 Example 2:
Estimate the effort and time required to develop
the semi-detached software. Following are Various
modules of software with their line of code :
module 1: 400 LOC
module 2: 150 LOC
module 3: 450 LOC
module 4: 1300 LOC
module 5: 250 LOC
module 6: 350 LOC
module 7: 150 LOC
module 8: 150 LOC
module 9: 500 LOC

85
 • Total line of code = 400 + 150 + 450 + 1300 + 250 +
350 + 150 + 150 + 500
=3700 LOC
=3.7 KLOC
• Effort= 3.0 x (3.7)1.12 = 13
• Time of development = 2.5 x (effort)0.35 = 6.14

86
• Example 3:
Estimate the effort and time required to develop the
semi-detached software. Following are Various
modules of software with their line of code :
module 1: 300 LOC
module 2: 150 LOC
module 3: 255 LOC
module 4: 2300 LOC
module 5: 250 LOC
module 6: 460 LOC
• Compare the time of development with organic
software

87
• Total line of code = 300+150+255+2300+250+460
=3715 LOC
=3.715 KLOC
For Semi-Detached Software:
• Effort= 3.0 x (3.715)1.12 = 13.04 PM
• Time of development = 2.5 x (13.04)0.35 = 6.14

88
Project Scheduling

“Software project scheduling is an activity that

distributes estimated effort across the planned project
duration by allocating the effort to specific software
engineering tasks”

89
Scheduling Principles
• 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 completed serially.
• Time Allocation
• every task has start and completion dates that take the task
interdependencies into account.
• Effort Validation
• project manager must ensure that on any given day there are
enough staff members assigned to completed the tasks within
the time estimated in the project plan.

90
• Defined Responsibilities
• every scheduled task needs to be assigned to a specific team
member.
• 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 quality review.

91
 Effort Distribution
• General guideline: 40-20-40 rule
• 40% or more of all effort allocated to analysis and design tasks.
• 20% of effort allocated to programming.
• 40% of effort allocated to testing.
• Characteristics of each project dictate the distribution of
effort.

92
Effort Allocation

• “front end” activities

40-50% • customer communication
• analysis
• design
• review and modification
• construction activities
15-20% • coding or code generation
• testing and installation
• unit, integration
• white-box, black box
• regression
30-40%

93
Scheduling Methods
• project scheduling tools and techniques can be applied
with little modification for software projects.
• Two project scheduling methods that can be applied to
software development.
• Program Evaluation and Review Technique (PERT)
• Critical Path Method (CPM)

94
• Both techniques are driven by information already
developed in earlier project planning activities:
• estimates of effort
• a decomposition of the product function
• the selection of the appropriate process model and task set
• decomposition of the tasks that are selected
• Both PERT and CPM provide quantitative tools that allow
you to:
1. Determine the critical path—The chain of tasks that
determines the duration of the project.
2. Establish “most likely” time estimates for individual tasks by
applying statistical models.
3. Calculate “boundary times” that define a “time window” for
a particular task.
95
Timeline Charts ( Gantt chart )
• It is generated on the basis of start date inputs for
each task.
Tasks Week 1 Week 2 Week 3 Week 4 Week n

Task 1
Task 2
Task 3
Task
4Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task
11
Task 12

96
Project Schedule Tracking
“The project schedule provides a road map that defines
the tasks and milestones to be tracked”

• Several ways to track a project schedule:

• Conducting periodic project status meeting.
• Evaluating the review results in the software process.
• Determine if formal project milestones have been
accomplished.
• Compare actual start date to planned start date for each task.
• Informal meeting with practitioners.
• Using Earned value analysis to assess progress quantitatively.

97
• Project manager takes the control of the schedule in the
aspects of:
• Project Staffing
• Project Problems
• Project Resources
• Reviews
• Project Budget

98
Earned Value Analysis (EVA)
• Earned value
• is a measure of progress
• enables us to assess the “percent of completeness” of
a project using quantitative analysis
• “provides accurate and reliable readings of
performance

99
Computing Earned Value
• To determine the earned value , Following steps are
performed:

1) The budgeted cost of work scheduled (BCWS) is

determined for each work task
2) The BCWS values for all work tasks are summed to
derive the budget at completion, BAC. Hence,

BAC = ∑ (BCWSk) for all tasks k

100
3) Next, the value for budgeted cost of work performed (BCWP)
is computed.
• The value for BCWP is the sum of the BCWS values for all
work tasks that have actually been completed by a point in
time on the project schedule.
BCWP= ∑(BAC)

Given values for BCWS, BAC, and BCWP, important progress

indicators can be computed:

• Schedule performance index, SPI = BCWP/BCWS

• Schedule variance, SV = BCWP – BCWS
• Percent schedule for completion = BCWS/BAC
• Percent Complete = BCWP/BAC

101
 • Actual cost of work performed, ACWP, is the sum of the
effort actually expended on work tasks that have been
completed by a point in time on the project schedule. It is
then possible to compute
• Cost performance index, CPI = BCWP/ACWP
• Cost variance, CV = BCWP – ACWP

102
103