Software project management 3

1
Software Project Management
Indu Sharma
HOD(CSE)
CPTC,Rajsamand

2
Introduction
 Project Management is an integrated part of software
development.
 It refers to manage the complete software project.
 The goal is to provide the necessary support for
development to proceed smoothly and reduce any
development problem. Its basic task is to ensure that,
once a development process is chosen, it is
implemented optimally.
 Effective s/w project management focuses on the 4
P’s: The People, The Product, The Process, and The
Project.

3
Introduction
I. The People:
 People-intensive
 SEI has developed a “People Management-
Capability Maturity Model” (PM-CMM):
 This model defines the key practice areas for s/w
people: recruitment, selection, performance
management, training, compensation, career
development, organization and work design, and
team/culture development.
 Team leaders: Motivation, Innovative, Problem
solving, influence and team building.

4
Introduction
II. The Product:

Product objectives: Overall goals (from the
customer’s point of view) without considering
how these goals will be achieved.

Scope: identifies its primary data, functions, and
behaviors.

Alternative Solutions: Once the project objectives
and scope are understood, alternative solutions
are considered. The alternative solutions enable
managers to select a “best” approach, given the
constraints imposed by the delivery deadlines,
budgetary restrictions, personnel availability,
technical interfaces etc.

5
Introduction
III. The Process:
 The way in which we produce the software.
 Provides a framework from which a comprehensive
plan for s/w development can be established.
 Problem is to select the appropriate process model.
 The project manager must decide which process
model is appropriate for:

The customer who have requested the product

The characteristics of the product itself, and

The projcect environment in which the s/w team
works.

6
Introduction
IV. The Project:
 In order to manage successful s/w projects, we must
understand what can go wrong and how to do it
right. Ten signs that indicate the project is in danger:
i. S/w people don’t understand their customer’s need.
ii. The product scope is poorly defined.
iii. Changes are managed poorly.
iv. The chosen technology changes.
v. Business needs change (or ill defined).

7
Introduction
vi. Deadlines are unrealistic.
vii. Users are resistant.
viii. Sponsorship is lost ( or was never properly obtained)
ix. The project team lacks people with appropriate skills.
x. Managers avoid practices and lessones learned.

8
Introduction
 Five commonsense approach to avoid problems to s/w
projects:

Start on the right foot:
 Working hard to understand the problem.
 Building the right team and giving the team
autonomy, authority, and technology needed to
the job.

Maintain Momentum:
 Good start and then slowly disintegrate
 To maintain momentum, the project manager
must provide incentives, should emphasize
quality in every task it performs etc.

Track progress:
 Progress is tracked as work products.

9
Introduction

Make smart decisions:
 Keep it simple.
 Use of existing s/w components
 Decide to avoid custom interfaces when standard
approaches are available.
 Decide to identify and then avoid obvious risks.
 Decide to allocate more time than you think is
needed to complex or risky tasks.

10
Introduction

Conduct a postmortem analysis:
 Establish consistent mechanism for extracting
lessons learned for each project.
 Evaluate the planned and actual schedules,
collect and analyze s/w project metrics, get
feedback from team members and customers,
and record finding is in written form.

11
Activities
 The activities in the management
process for a project can be grouped
broadly into three phases:
 Project planning
 Project Monitoring & Control
 Project Termination

12
Project Planning
 Project management begins with planning,
which is the perhaps most critical project
management activity.
 Lack of proper planning is sure ticket to
failure for a large s/w project.
 A s/w plan is usually produced before the
development activity begins and is updated
as development proceeds and data about
progress of the project becomes available.

13
Project Planning
 The major issues project planning
addresses are:
I. Process Planning
II. Effort estimation
III. Project scheduling and staffing
IV. Configuration Management Plan
V. Quality Plans
VI. Risk Management
VII. Project Monitoring plans

14
I Process Planning
 For a project during planning, a key activity is
to plan and specify the process that should
be used in the project.
 It means the various stages in the process,
the entry criteria for each stage, the exit
criteria, the verification activities that will be
done at the end of the stage.
 Some standard process model may be used
as a standard process and tailored to suit the
needs of the project.

15
II Effort Estimation
 For a given set of requirements it is desirable
to know how much it will cost to develop the
s/w and how much time the development will
take. These estimates are needed before
development is initiated.
 The primary reason for cost and schedule
estimation are:
 Cost and benefit analysis
 Project monitoring and control
 More practical use: bidding for s/w projects

16
Effort Estimation
 Because the s/w development is labour-
intensive(i.e. human resources), most cost
estimation procedures focuses on estimating
effort in terms of Person-Months(PM).
 Effort and schedule estimation is required to
answer the questions like:
 Is the project late?
 Are there cost overruns?
 When is the project likely to complete?
 What staffing level is required during different
phases?

17
Effort Estimation
 To achieve reliable effort estimation in terms of
cost , a no. of options arise:
a) Delay estimates until late in the project.
Not practical, as cost estimation must be provided “up-
front”
b) Base estimates on similar projects that have already
been completed
Can work reasonably well, if the current project is quite
similar to past efforts.
c) Use relatively simple decomposition techniques to
generate project cost and effort estimation.
d) Use one or more empirical models for s/w cost and effort
estimation.
(c) And (d) are viable approaches to s/w project estimation.

18
Measure, Measurement, Metrics
and Indicators
 Although, the terms measure, measurement, and
metrics are often used interchangeably, but it is
important to note the subtle differences between
them.
 Measure: A measure provides a quantitative
indication of the extent, amount, dimension, capacity,
or size of some attributes of a product or process.
 Measurement: Measurement is the act of determining
a measure.
 Metric: A quantitative measure of the degree to which
a system, component, or process possesses a given
attribute.

19
and Indicators
 Example:
 When a single data point has been collected (e.g.,
the number of errors uncovered in the review of a
single module), a measure has been established.
Measurement occurs as the result of the collection
of one or more data points (e.g., a number of
module reviews are investigated to collect
measures of the number of errors in each
module). A software metric relates the individual
measures in some way (e.g., the average number
of errors found per review).

20
and Indicators
 A software engineer collects measures and
develops metrics so that indicators will be
obtained. An indicator is a metric or
combination of metrics that provide insight
into the software process, a software project,
or the product itself.
 An indicator provides insight that enables the
project manager or software engineers to
adjust the process, the project, or the process
to make things better.

21
and Indicators
 For example, four software teams are working on a
large software project. Each team must conduct
design reviews but is allowed to select the type of
review that it will use. Upon examination of the
metric, errors found per person-hour expended, the
project manager notices that the two teams using
more formal review methods exhibits an errors found
per person-hour expended that is 40% higher than
the other teams. Assuming all parameters are equal,
this provides the project manager with an indicator
that formal review methods may provide a higher
return on time investment than another, less formal
review approach. She may decide to suggest that all
teams use the more formal approach.

22
Metrics
 Because the s/w has not physical attributes,
conventional metrics are not much help in
designing metrics of s/w. A number of metrics
have been proposed to quantify things like
the size, complexity, and reliability of a s/w
product.
 A s/w metrics relates the individual
measures in some way.
Eg. Avg lines of code: KLOC per module
Avg number of errors found per module

23
Metrics
 There are three types of metrics:
 Product Metrics: Product metrics are used to
quantify characteristics of the product being
developed i.e. Software. Eg. Size, complexity,
performance, efficiency, portability, reliability etc.
 Process Metrics: Process metrics are used to
quantify characteristics of the process being used
to develop the s/w. Eg. Effort required in the
process, time to produce the product, effect of
development techniques and tools, no. of defects
found during testing etc.

24
Metrics
 Project Metrics: are used for strategic
purposes. That is, project metrics and indicators
derived from them are used by a project manager
and a software team to adapt project work flow
and technical activities.
 Two purpose:

First, to minimize the development schedule by making
necessary adjustments in order to avoid delays and
alleviate potential risks and problems.

Secondly, these metrics are used to assess the product
quality on a regular basis and modify the technical issues
if required. As the quality improves, the number of errors
and defects are reduced, which in turn leads to a
decrease in the overall cost of a software project.

25
Metrics
 Values of metrics can be measured directly
or indirectly.
 Directly:
 eg. Size of the s/w (LOC), cost, execution
speed etc.
 Indirectly:
 eg. Reliability has to be estimated from
other possible measurements, quality,
complexity, maintainability etc.

26
Decomposition Techniques
 Decomposition techniques take a “divide
and conquer” approach to s/w project
estimation.
 Decomposition techniques are used to
estimate cost and effort by decomposing the
complete project problem into subsequent
parts. Now, first these parts or subdivisions
are solved one-by-one and after their
solutions can be combined to form a whole.

27
Decomposition Techniques
 The project planner begins with a bounded
statement of software scope and from this
statement attempts to decompose software
into problem functions that can be estimated
individually.
 The s/w size is the most important factor that
effects the cost. LOC and FP-Based are
distinct estimate techniques for s/w size.
 If a direct approach is chosen, size can be
measured in LOC. If an indirect approach is
chosen, size is represented in FP.

28
LOC-Based Estimation
 It simply refers to the no. of lines of the
delivered source code.
 Eg. 5000 KLOC
 LOC
 From this a set of simple size-oriented
metrics can be developed:
 Errors / KLOC, $ / KLOC
 Other Metrics:
 Errors / person-month
 LOC / Person-month
 $ / page of documentation

29
LOC-Based Estimation
 Advantages:
 Simple to measure
 It can be determined uniquely by automated tools
once the project is completed.
 Drawbacks:
 It is defined on code. For example it can’t measure
the size of specification.
 It characterize only one specific view of size, name
length, it takes no account of functionality or
complexity.
 Bad s/w design may cause excessive line of code
 It is language dependent.

30
FP(Function Points)-Based
Estimation
 The basis of function points is that the
“functionality” of a system, that is, what the
system performs, is the measure of the
system. For computing the FPs:
1. Compute the count of five different
parameters, namely:
 No. of user inputs, no. of user outputs, no. of
user inquires, no. of files, and no. of external
interfaces
 According to FP approach, these five
parameters capture the entire functionality of
a system.

31
Estimation
 No. of user inputs (or External Input): Each
unique input that is given as input to the
application from the outside is considered of
external input type and is counted. Eg.
Forms, files etc.
 No. of user outputs (or External Output): Each
unique output that leaves the system
boundary is counted as a external output
type. Eg. reports, screens, error messages
etc.

32
Estimation
 No. of user inquiries ( or External inquiry):
Include queries, where a query is defined as
an input-output pair where the input caused
the output to be generated immediately. Each
input-output pair is counted as an external
inquiry type.
 No. of files (or Logical internal files): Each
logical group of data used and maintained by
the application is counted as logical internal
file type.

33
Estimation
 No. of external interface (or External
Interface File): Files that are passed or
shared between applications are counted as
external interface file type.
2. Now, the above five functional units are
ranked according to their complexity i.e. low,
average, or high using a set of perspective
standards. Organizations that use FP
methods develop criteria for determining
whether a particular entry is simple,
average, or complex.

34
Estimation
 Eg. A logical internal file is simple, if it
contains a few record types, complex if it
has many record types, and average if it is
between.
3. Once the counts for all five different types
are known for all three different complexity
classes, the Unadjusted Function Point
(UFP) is calculated using predefined
weights for each function type as shown in
table.

35
Estimation
complexity multiplier
function points
number of user inputs
number of user outputs
number of user inquiries
number of files
number of ext.interfaces
measurement parameter
3
4
3
7
5
count
w eighting factor
simple avg. complex
4
5
4
10
7
6
7
6
15
10
=
=
=
=
=
count-total
X
X
X
X
X

36
Estimation
4. To compute FP, the following relationship is
used:
FP = UFP * [0.65 + 0.01 * Σ(Fi)]
Or FP = UFP * CAF
Where CAF is Complexity Adjustment Factor
and
CAF = 0.65 + 0.01 * Σ(Fi)
The Fi (i=1 to 14) are “complexity adjustment
values” based on to the following questions:

37
Estimation
1. Does ths system require reliable backup and
recovery?
2. Are data communication required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized
operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input
transaction to be built over multiple screens or
operations?
8. Are the master files updated on-line?

38
Estimation
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the
design?
13. Is the system designed for multiple installations in
different organizations?
14. Is the application designed to facilitate chang and
ease of use by the user?

39
Estimation
 The degree of influence of each of
these factors is taken to be from 0 to 5
representing the six different levels i.e.
0 -> No 1 -> Insignificant
2 -> Moderate 3 -> Average
4 -> Significant 5 -> Strong

40
Estimation
 Once function points have been calculated,
they are used in a manner analogous to LOC
as a way to normalize measures for software
productivity, quality, and other attributes:
 Errors per FP
 Defects per FP
 $ per FP
 Pages of documentation per FP
 FP per person-month

41
Estimation
 Advantages:
 It is not restricted to code
 Language independent
 The definition of FPs depends only on information
available from specifications, whereas the size in
KLOC can’t be directly determined from
specifications.
 The necessary data is available early in a project
and thus only a detailed specification is needed.
 More accurate than estimated LOC.

42
Estimation
 Drawbacks:
 Subjective counting
 Hard to automate and difficult to compute
 Ignore quality of output
 Oriented to traditional data processing applications
 It does not take into account the algorithmic
complexity of a software. That is, the function
point metric implicitly assume that the effort
required to design and develop any two
functionalities of the system is same.

43
Problems
1. Consider a project with the following
functional units:
 No. of user inputs =50
 No. of user outputs =40
 No. of user enquiries =35
 No. of user files =06
 No. of external interfaces =04
Assuming all complexity factors and
weighing factors are average. Compute the
function points for the project.

44
Problems
2. An Application has the following:
10 low external inputs, 12 high external
outputs, 20 low internal logical files, 15 high
external interface files, 12 average external
inquiries, and a value of complexity
adjustment factor of 1.10.
what are the unadjusted and adjusted
function point counts?

45
Empirical Estimation Models
 Empirical means based on observations
and experiments not on theory.
 An empirical model for computer
softwares is used to predict effort as a
function of LOC or FP.
 Effort (E) = a * (KLOC) b

46
The COCOMO Model –I (The
Constructive Cost Model):
 Most widely used and discussed cost estimation
model in the industry.
 Produced by B. W. Bohem in 1981.
 COCOMO is a hierarchy of s/w cost estimation
models, which include, basic, intermediate, and
detailed sub models.
 It was based on the data of 63 completed projects.
 Size 5000 LOC to more than 10,00000 LOC.
 Project Complexity: simple, general applications to
complex real time applications.
 COCOMO-I COCOMO-II

47
The COCOMO Model-I
 This approach implies that size is the primary
factor for cost; other factors have a lesser effect.
 This model estimates the total effort in terms of
person-months.
 In COCOMO, projects are categorized into three
categories, based on project size, nature of
project, development environment etc.:
 Organic,
 Semidetached, and
 Embedded

48
The COCOMO Model-I
 Organic: These projects have the following
characteristics:
 Small product size (less than 50,000 LOC)
 Small, in-house development team.
 Development team has experienced in application area.
 Requirements are less stringent (i.e. Negotiable, informal)
 Minimal communication overhead.
 Stable development environment.
 Minimal schedule pressure.
 Existing, proven technology is used.
 Examples: simple business systems, simple
inventory management systems, and data processing
systems.
 Pay roll etc.

49
The COCOMO Model-I
 Semidetached: These systems fall between the
other two types and have the following
characteristics:
 Size may range typically 50 – 300 KLOC
 Medium size team.
 Development team personnel is mix of experienced and
inexperienced in the application area and development
environment.
 Mix of relaxed and rigid specification on function and
performance requirements, interfaces and product
acceptance criteria.
 Moderate schedule pressure.
 Eg.: developing a new OS, a database management system,
simple transaction processing systems etc.

50
The COCOMO Model-I
 Embedded: These projects have the following
characteristics:
 Size may range over 300 KLOC.
 Large project team.
 Very little previous experience.
 Requirements are stringent for such aspects as interfacing and reliability.
 Product must operate within time constraints on internal and external
interface service, processing and interrupt service.
 Product must meet rigid, formal quality standards.
 Extensive testing required.
 These systems have tight constraints from the environment (s/w, h/w, and
people).
 Leading edge technology employed.
 Strong schedule pressure.
 Other system components developed concurrently with s/w.
 Eg.: Avionic systems, real-time systems etc.

51
The Basic COCOMO Model
 It is very simple to use.
 This model aims at estimating, in a quick and rough
fashion, most of small to medium sized s/w projects.
 The effort, cost, and development time to develop an
application can be calculated by using the following
equations:
 Effort (E) = Ab (KLOC) B
b in (Person-Months)
 Development time (D) = Cb (E)D
b in (Months)
 E-> Effort is the total effort required to develop the software
product, expressed in Person-Months (PMs)
 D->Development Time in Months
 The coefficients Ab, Bb, Cb, Db are given in table:

52
Project Ab Bb Cb Db
Organic 2.4 1.05 2.5 0.38
Semidetache
d
3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

53
 When Effort and development time is
known, the average staff size to
complete the project may be calculated
as follows:
 Average Staff Size (SS) = E / D Persons
 When project size is known the
productivity level may be calculated as:
 Productivity (P) = KLOC / E KLOC/PM

54
Problem 3
Assume that the size of an organic type
software product has been estimated to
32,000 lines of source code. Assume
that the average salary of software
developers is Rs. 15,000 per month.
Determine the effort required to develop
the software product, the nominal
development time, and the cost to
develop the product.

55
Intermediate COCOMO Model
 The basic model allowed for a quick and rough
estimate, but it resulted in a lack of accuracy.
 Bohem introduced an additional 15 different attributes
called cost driver attributes. These factors depend on
product, computer, personnel and technology
attributes (called project attributes).
 Cost drivers are used to adjust the nominal cost of a
project to the actual project environment, hence
increasing the accuracy of the estimate.
 See figure: Effort Multiplier for different cost drivers.

56
Effort Multiplier for different cost
drivers.

57
 Now, the Efforts and development time can
be calculated as:
 Initial Effort (Ei) = Ai * (KLOC)B
i
 Compute Effort Adjustment Factor (EAF)
EAF = Multiplication of all 15 cost drivers
(Typical values for EAF range from 0.9 to 1.4)
 Final Effort Estimation (E) = EAF * Ei
 Development Time (D) = Ci (E) D
i
 The coefficients Ai, Bi, Ci, Di are given in the
table on next slide.

58
Project Ab Bb Cb Db
Organic 3.2 1.05 2.5 0.38
Semidetache
d
3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

59
Detailed COCOMO Model
 Detailed COCOMO incorporates all characteristics of
the intermediate version with an assessment of the
cost driver’s impact on each phase of the
development process. This helps in determining the
manpower allocation for each phase of the project.
 The phases are:
 Requirements and Product Design

Plans and requirements

System Design
 Detailed Design
 Code & Unit Test
 Integration & Test

60
 Effort for a phase is a defined percentage of
the overall effort.
 The percentage of total effort spent in a
phase varies with the type and size of the
project.
 The percentage for an organic software
project are given in Table:
 Using this table, the estimate of the effort
required for each phase can be determined
from the total effort estimate.

61
Phase Size
Small
2 KLOC
Intermediate
8 KLOC
Medium
32
KLOC
Product design 16 16 16
Detailed Design 26 25 24
Code & Unit Test 42 40 38
Integration & Test 16 19 22

62
COCOMO-II
 Revise version of the COCOMO-I.
 Since its formulation (COCOMO-I), there
have been many changes in software
engineering practice and COCOMO-II is
designed to accommodate different
approaches to software development.
 Use of tools & techniques, Reuse, GUI
builders etc.

63
COCOMO-II
 Like its predecessor, COCOMO-II is actually
a hierarchy of estimation models.
 COCOMO-II model hierarchy:
 Application Composition Model – used at the early
stages of the process;
 Early Design Stage Model – used once
requirements have been stabilized and basic
software architecture are available;
 Post Architectural Stage Model – used during the
actual development of the software.

64
The Application Composition
Model
 Supports prototyping projects and projects
where there is extensive reuse.
 Takes CASE tool use into account.
 This model uses Object-Points (alternatively
named Application Points). Like FPs the
object point is an indirect s/w measure that is
computed using:
 Screens (at the user interface)
 Reports, and
 Components likely to be required to build
application.

65
Model
 Steps for the estimation of effort in
Person-Months:
1. The first step is to count all of the object
points in the application.
2. The next step is to weight them according
to the table on next slide.

66
Model
Object Type Complexity Weight
Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3 GL
Component
- - 10

67
Model
3. Multiply each object by its weight and
sum over all objects to give the Total
Object Point Count.

68
Model
Object Type Coun
t
Complexity Weight Object
Point
Count
Simpl
e
Mediu
m
Difficult
Screens X 1 2 3 =
Reports X 2 5 8 =
3 GL
Components
X - - 10 =
Total Object Point Count (Object Points) =

69
Model
4. Compute the New Object Point (NOP): When
component based development or general s/w
reuse is to be applied, the percentage or reuse(%
reuse) is estimated and the object-point count is
adjusted as below:
NOP=(Object-points) * [(100 - % reuse) / 100]
5. Determine the Productivity Rate (PROD): To derive
an estimate of effort based on computed NOP
value, a “Productivity Rate” must be derived. Table
on next slide presents the productivity rate.
PROD=NOP/person-month

70
Model
 The productivity rate for different levels of
developer experience and development
environment maturity is given by this
table:
Developer’s
experience/capability
Very
Low
Low Nominal High Very
High
Environment
maturity/capability
Very
Low
Low Nominal High Very
High
PROD 4 7 13 25 50

71
Model
6. Compute the effort in PM as:
Estimated effort = NOP/PROD

72
The Early Design Stage Model
 This model uses the equation of the form:
Effort = A * (Size)B
* M
Here, A-> a constant representing the nominal
productivity, provisionally set to 2.5
B -> Scale factor. It depends on the novelty of the
project, development flexibility, team management
skills, and process maturity.
Size -> Size of the s/w
M -> Multipliers reflect the capability of the
developers, the non-functional requirements, the
familiarity with the development platform, etc.
(7 cost drivers)

73
The Early Design Stage Model
 There are 7 cost drivers
1. RCPX - product reliability and complexity;
2. RUSE - the reuse required;
3. PDIF - platform difficulty;
4. PREX - personnel experience;
5. PERS - personnel capability;
6. SCED - required schedule;
7. FCIL - the team support facilities.
 M = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED;
 The degree of influence of each of these factors is taken to be
from 1 to 6 representing the six different levels i.e.
1 -> Very Low 2 -> Low
3 -> Nominal 4 -> High
5 -> Very High 6 -> Extra High

74
The Post Architecture Model
 It is the most detailed estimation model
and assumes that the system
architecture is known, and the
information on various cost drivers of
the system is available.
 There are 17 cost drivers. They are

75
The Post Architecture Model
1. Reliability Required (RELY).
2. Database Size (DATA).
3. Product Complexity (CPLX).
4. Required Reusability (RUSE).
5. Documentation (DOCU).
6. Execution Time Constraint (TIME).
7. Main Storage Constraint (STOR).
8. Platform Volatility (PVOL).
9. Analyst Capability (ACAP).
10. Programmers Capability (PCAP).
11. Personnel Continuity (PCON).
12. Analyst Experience (AEXP).
13. Programmer Experience (PEXP).
14. Language & Tool Experience (LTEX).
15. Use of Software Tools (TOOL).
16. Site Locations & Communication Technology between Sites (SITE).
17. Schedule (SCED).

76
Delphi Cost Estimation
 This strategy is not based on the use of
models and prototypes to assess the cost of
s/w or system. It is based on the subjective
assessment by group meetings.
 In this method a group of people discusses
the problem of estimation and finally
converges on a consensus estimate.
 The Delphi technique can be adapted to s/w
cost estimation in the following manner:

77
Delphi Cost Estimation
1. The coordinator provides each estimator with a
system definition and estimation form.
2. The estimators study the definition, and the
coordinator calls a group meeting so that
estimators can discuss estimation issues with the
coordinator and one another.
3. Estimators complete their estimates anonymously.
4. The coordinator prepares a summary of the
estimates.
5. The coordinator calls a group meeting to focus on
issues where the estimates vary widely.
6. Estimators complete another estimate, again
anonymously. The process is iterated for as many
rounds as necessary.

78
Automated Estimation Tools
 The decomposition techniques and empirical
estimation models are available as part of a
wide variety of s/w tools.
 The automated estimation tools allow the
planner to estimate cost and effort and to
perform “what-if” analyses for important
project variables such as delivery date or
staffing.
 Automated tools perform the following six
generic functions:

79
Automated Estimation Tools
1. Sizing of project deliverables:
 Work products include:

The external representation of s/w (eg. Screen, reports)
 The s/w itself (e.g. KLOC).

Functionality (EG. FPs).

Descriptive information (e.g. documents)
1. Selecting project activities:

The appropriate process framework.
1. Predicting staff levels:
2. Predicting software efforts:
 Estimation tools use one or more models that relate the size of
the project deliverables to the effort required to produce them.
1. Predicting s/w costs:
2. Predicting s/w schedules:

80
Factors affecting the s/w
engineering productivity
1. Application domain experience:
 Knowledge of the application domain is essential for effective s/w
development. Engineers who already understand a domain are
likely to be the most positive.
1. Process quality:
 The development process used can have a significant effect on
productivity.
1. Project Size:
 The larger a project, the more time required for team
communications. Less time is available for development so
individual productivity is reduced.
1. Technology support:
 Good support of technology such as CASE tools, supportive
configuration management system etc. can improve productivity.

81
Factors affecting the s/w
engineering productivity
5. Working Environment:
 A quiet working environment such as privacy (programmer
requires an area where they can concentrate and work without
interruption), outside awareness, personalization (the ability to
rearrange the workplace to suit working practices and to
personalize that environment is important).

82
Solution Problem1
We know
FP = UFP * [0.65 + 0.01 * Σ(Fi)]
UFP=50*4+40*4+35*4+6*10+4*7
=200+160+140+60+28=628
Σ(Fi)=14*3=42
CAF=0.65+0.01*42=1.07
FP = UFP * CAF=628*1.07=672

83
Solution Problem 2
We know
FP = UFP * [0.65 + 0.01 * Σ(Fi)]
UFP=10*3+12*7+20*7+15*10+12*4
=30+84+140+150+48=452
CAF=1.10
FP = UFP * CAF=452*1.10=497.2

84
Solution Problem 2
From the basic COCOMO estimation for
organic software:
Effort (E) = Ab (KLOC) B
b
= 2.4 * (32)1.05
= 91 PM
Development time (D) = Cb (E)D
b
=2.5 * (91)0.38
= 14 months
Cost required to develop the product=
91*15,000 = Rs. 13,65,000

Software project management 3

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software project management 3

Similar to Software project management 3 (20)

More from Indu Sharma Bhardwaj

More from Indu Sharma Bhardwaj (18)

Recently uploaded

Recently uploaded (20)

Software project management 3