UNIT – V: PROJECT MANAGEMENT

Software Project Management: Estimation – LOC and FP Based Estimation, make / buy
decision, COCOMO I & II Model – Project Scheduling – Scheduling, Earned Value Analysis –
Planning: project plan, planning process, RFP - Risk Management: identification, projection – RMMM
plan – CASE Tools.

Software Project Management - Introduction

The job pattern of an IT company engaged in software development can be seen split in two parts:
 Software Creation
 Software Project Management
A project is well-defined
defined task, which is a collection of several operations done in order to achieve a
goal (for example, software development and delivery). A Project can be characterized as:
 Every project may has a unique and distinct goal.
 Project is not routine
utine activity or day-to-day
day operations.
 Project comes with a start time and end time.
 Project ends when its goal is achieved hence it is a temporary phase in the lifetime of an
organization.
 Project needs adequate resources in terms of time, manpower, finance,
finance, material and
knowledge-bank.
Software Project
A Software Project is the complete procedure of software development from requirement
“A
gathering to testing and maintenance, carried out according to the execution methodologies, in a
specified period of time to achieve intended software product.”
product.
Need of software project management
Software is said to be an intangible product. Software development is a kind of all new stream
in world business and there’s very little experience in building software products.
produ Most software
products are tailor made to fit client’s requirements. The most important is that the underlying
technology changes and advances so frequently and rapidly that experience of one product may not
be applied to the other one. All such business
business and environmental constraints bring risk in software
development hence it is essential to manage software projects efficiently.

The image above shows triple constraints for software projects. It is an essential part of
software organization to deliverer quality product, keeping the cost within client’s budget constrain and
deliver the project as per scheduled. There are several factors, both internal and external, which may
impact this triple constrain triangle. Any of three factor can severely impact the other two. Therefore,
software project management is essential to incorporate user requirements along with budget and
time constraints.
Software Project Manager
A software project manager is a person who undertakes the responsibility of executing the
software project. Software project manager is thoroughly aware of all the phases of SDLC that the
software would go through. Project manager may never directly involve in producing the end productpro
but he controls and manages the activities involved in production.
A project manager closely monitors the development process, prepares and executes various
plans, arranges necessary and adequate resources, maintains communication among all team
membersers in order to address issues of cost, budget, resources, time, quality and customer
satisfaction. Let us see few responsibilities that a project manager shoulders –

1
Managing People
 Act as project leader
 Liaison with stakeholders
 Managing human resources
 Setting up reporting hierarchy etc.
Managing Project
 Defining and setting up project scope
 Managing project management activities
 Monitoring progress and performance
 Risk analysis at every phase
 Take necessary step to avoid or come out of problems
 Act as project spokesperson
Software Project Management consists of several different types of managements:
1. Conflict Management: Conflict management is the process to restrict the negative features of
conflict while increasing the positive features of conflict. The goal of conflict management is to
improve learning and group results including efficacy or performance in an organizational
setting. Properly managed conflict can enhance group results.
2. Risk Management: Risk management is the analysis and identification of risks that is followed
by synchronized and economical implementation of resources to minimize, operate and control
the possibility or effect of unfortunate events or to maximize the realization of opportunities.
3. Requirement Management: It is the process of analyzing, prioritizing, tracing and documenting
on requirements and then supervising change and communicating to pertinent stakeholders. It is
a continuous process during a project.
4. Change Management: Change management is a systematic approach for dealing with the
transition or transformation of an organization’s goals, processes or technologies. The purpose
of change management is to execute strategies for effecting change, controlling change and
helping people to adapt to change.
5. Software Configuration Management: Software configuration management is the process of
controlling and tracing changes in the software, part of the larger cross-disciplinary field of
configuration management. Software configuration management include revision control and the
inauguration of baselines.
6. Release Management: Release Management is the task of planning, controlling and scheduling
the build in deploying releases. It ensures that organization delivers new and enhanced services
required by the customer, while protecting the integrity of existing services.
Software Management Activities
Software project management comprises of a number of activities, which contains planning of
project, deciding scope of software product, estimation of cost in various terms, scheduling of tasks
and events, and resource management. Project management activities may include:
 Project Planning
 Scope Management
 Project Estimation
Project Planning
Software project planning is task, which is performed before the production of software
actually starts. It is there for the software production but involves no concrete activity that has any
direction connection with software production; rather it is a set of multiple processes, which facilitates
software production.
Scope Management
It defines the scope of project; this includes all the activities, process need to be done in order
to make a deliverable software product. Scope management is essential because it creates
boundaries of the project by clearly defining what would be done in the project and what would not
be done. This makes project to contain limited and quantifiable tasks, which can easily be
documented and in turn avoids cost and time overrun. During Project Scope management, it is
necessary to -
 Define the scope
 Decide its verification and control
 Divide the project into various smaller parts for ease of management.
 Verify the scope
 Control the scope by incorporating changes to the scope

2
Advantages of Software Project Management:
 It helps in planning of software development.
 Implementation of software development is made easy.
 Monitoring and controlling are aspects of software project management.
 It overall manages to save time and cost for software development.

Project Estimation
For an effective management accurate estimation of various measures is a must. With correct
estimation managers can manage and control the project more efficiently and effectively. Project
estimation may involve the following:
 Software size estimation
Software size may be estimated either in terms of KLOC (Kilo Line of Code) or by
calculating number of function points in the software. Lines of code depend upon coding
practices and Function points vary according to the user or software requirement.
 Effort estimation
The managers estimate efforts in terms of personnel requirement and man-hour
required to produce the software. For effort estimation software size should be known. This
can either be derived by managers’ experience, organization’s historical data or software size
can be converted into efforts by using some standard formulae.
 Time estimation
Once size and efforts are estimated, the time required to produce the software can be
estimated. Efforts required is segregated into sub categories as per the requirement
specifications and interdependency of various components of software. Software tasks are
divided into smaller tasks, activities or events by Work Breakthrough Structure (WBS). The
tasks are scheduled on day-to-day basis or in calendar months.
The sum of time required to complete all tasks in hours or days is the total time invested to
complete the project.
 Cost estimation
This might be considered as the most difficult of all because it depends on more
elements than any of the previous ones. For estimating project cost, it is required to consider
o Size of software
o Software quality
o Hardware
o Additional software or tools, licenses etc.
o Skilled personnel with task-specific skills
o Travel involved
o Communication
o Training and support
Project Estimation Techniques
We discussed various parameters involving project estimation such as size, effort, time and
cost. Project manager can estimate the listed factors using two broadly recognized techniques –
Decomposition Technique
This technique assumes the software as a product of various compositions.
There are two main models -
 Line of Code Estimation is done on behalf of number of line of codes in the software
product.
 Function Points Estimation is done on behalf of number of function points in the
software product.
Empirical Estimation Technique
This technique uses empirically derived formulae to make estimation.These formulae are based
on LOC or FPs.
 Putnam Model
This model is made by Lawrence H. Putnam, which is based on Norden’s frequency
distribution (Rayleigh curve). Putnam model maps time and efforts required with software
size.
 COCOMO
COCOMO stands for COnstructive COst MOdel, developed by Barry W. Boehm. It divides
the software product into three categories of software: organic, semi-detached and
embedded.

3
I. Project size estimation techniques
Estimation of the size of software is an essential part of Software Project Management. It
helps the project manager to further predict the effort and time which will be needed to build the
project. Various measures are used in project size estimation. Some of these are:
 Lines of Code
 Number of entities in ER diagram
 Total number of processes in detailed data flow diagram
 Function points
1. Lines of Code (LOC): As the name suggest, LOC count the total number of lines of source code in
a project. LOC approach deals with computing the Lines of Code (LOC) and thereby estimating the
cost and effort involved in developing the software project from information domain values.
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. This approach uses historical data to build estimates for the project as illustrated below,
Function Estimated LOC
User interface and control facilities (UICF) 2,300
Two-dimensional geometric analysis (2DGA) 5,300
Three-dimensional geometric analysis (3DGA) 6,800
Database management (DBM) 3,350
Computer graphics display facilities (CGDF) 4,950
Peripheral control function (PCF) 2,100
Design analysis modules (DAM) 8,400
Estimated lines of code 33,200

An Example of LOC-Based Estimation:

 Estimated lines of code = W = 33,200
 Let,
o Average productivity = 620 LOC/pm = X
o Labor rate = $8,000 per month = Y
 So,
o Cost per line of code = Z = Y/X = $13 (approx.)
o Total estimated project cost = W*Z = $431,000 (approx.)
o Estimated effort = W/X = 54 person-months (approx)
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.

2. Number of entities in ER diagram: ER model provides a static view of the project. It describes the
entities and its relationships. The number of entities in ER model can be used to measure the
estimation of size of project. Number of entities depends on the size of the project. This is because
more entities needed more classes/structures thus leading to more coding.
Advantages:
 Size estimation can be done during initial stages of planning.
 Number of entities is independent of programming technologies used.
Disadvantages:
 No fixed standards exist. Some entities contribute more project size than others.
 Just like FPA, it is less used in cost estimation model. Hence, it must be converted to LOC.

4
3. Total number of processes in detailed data flow diagram: Data Flow Diagram(DFD) represents
the functional view of a software. The model depicts the main processes/functions involved in
software and flow of data between them. Utilization of number of functions in DFD to predict software
size. Already existing processes of similar type are studied and used to estimate the size of the
process. Sum of the estimated size of each process gives the final estimated size.
Advantages:
 It is independent of programming language.
 Each major processes can be decomposed into smaller processes. This will increase the
accuracy of estimation
Disadvantages:
 Studying similar kind of processes to estimate size takes additional time and effort.
 All software projects are not required to construction of DFD.

4. Function Point Analysis: In this method, the number and type of functions supported by the
software are utilized to find FPC(function point count).
The function point (FP) metric can be used effectively as a means for measuring the
functionality delivered by a system. Using historical data, the FP metric can then be used to
(1) Estimate the cost or effort required to design, code, and test the software;
(2) Predict the number of errors that will be encountered during testing; and
(3) Forecast the number of components and/or the number of projected source lines in the
implemented system.
Function points are derived using an empirical relationship based on countable (direct) measures of
software‘s information domain and qualitative assessments of software complexity. Function Point
Analysis (FPA) is a method or set of rules of Functional Size Measurement. It assesses the
functionality delivered to its users, based on the user’s external view of the functional requirements. It
measures the logical view of an application not the physically implemented view or the internal
technical view
Objectives of FPA:
1. The objective of FPA is to measure functionality that the user requests and receives.
2. The objective of FPA is to measure software development and maintenance independently of
technology used for implementation.
3. It should be simple enough to minimize the overhead of the measurement process.
4. It should be a consistent measure among various projects and organizations.
Types of FPA:
1. Transactional Functional Type –
 (i) External Input (EI): EI processes data or control information that comes from outside
the application’s boundary. The EI is an elementary process.
 (ii) External Output (EO): EO is an elementary process that generates data or control
information sent outside the application’s boundary.
 (iii) External Inquiries (EQ): EQ is an elementary process made up of an input-output
combination that results in data retrieval.
2. Data Functional Type –
 (i) Internal Logical File (ILF): A user identifiable group of logically related data or control
information maintained within the boundary of the application.
 (ii) External Interface File (EIF): A group of user recognizable logically related data
allusion to the software but maintained within the boundary of another software.

5
The steps in function point analysis are:
 Count the number of functions of each proposed type.
 Compute the Unadjusted Function Points(UFP).
 Find Total Degree of Influence(TDI).
 Compute Value Adjustment Factor(VAF).
 Find the Function Point Count(FPC).
The explanation of above points given below:
 Count the number of functions of each proposed type: Find the number of functions
belonging to the following types:
 External Inputs: Functions related to data entering the system.
 External outputs:Functions related to data exiting the system.
 External Inquiries: They leads to data retrieval from system but don’t change the system.
 Internal Files: Logical files maintained within the system. Log files are not included here.
 External interface Files: These are logical files for other applications which are used by our
system.
 Compute the Unadjusted Function Points(UFP): Categorise each of the five function types as
simple, average or complex based on their complexity. Multiply count of each function type with
its weighting factor and find the weighted sum. The weighting factors for each type based on
their complexity are as follows:
FUNCTION TYPE SIMPLE AVERAGE COMPLEX
External Inputs 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10
 Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to find the
degree of influence of each of them. The sum of all 14 degrees of influences will give the TDI.
The range of TDI is 0 to 70. The 14 general characteristics are: Data Communications,
Distributed Data Processing, Performance, Heavily Used Configuration, Transaction Rate, On-
Line Data Entry, End-user Efficiency, Online Update, Complex Processing Reusability,
Installation Ease, Operational Ease, Multiple Sites and Facilitate Change.
Each of above characteristics is evaluated on a scale of 0-5.
 Compute Value Adjustment Factor(VAF): Use the following formula to calculate VAF
VAF = (TDI * 0.01) + 0.65

 Find the Function Point Count: Use the following formula to calculate FPC
FPC = UFP * VAF
Advantages:
 It can be easily used in the early stages of project planning.
 It is independing on the programming language.
 It can be used to compare different projects even if they use different technologies(database,
language etc).
Disadvantages:
 It is not good for real time systems and embedded systems.
Many cost estimation models like COCOMO uses LOC and hence FPC must be converted to LOC.

6
EXAMPLE for FP Calculation

1. Calculation of UFP:

2. Determing DI

3. Function Points Estimation

• FP=UFP*(0.65+0.01*DI)= 55*(0.65+0.01*30)=52.25
• That means the is FP=52.25

Relation between LOC and FP

– Relationship: LOC = Language Factor * FP
Where,
• LOC (Lines of Code)
• FP (Function Points)

3D function points (Extended Function Point (EFP) Metrics):

 Data, Functional, and control are three dimensions represented by 3D function points.
1. Data: User interfaces and data as in the original method.

7
 2. Control: Real-time behavior(s)
3. Function: Internal processing
 Data dimension calculation is the same as the FPs. Feature-Transformation is done in the
functional dimension. While in the control dimension, feature-Transition is added.
 The 3D Function Point method was proposed by Boeing.
 It is designed to solve two problems with the Albrecht approach.
Example:
Compute the FP, feature point and 3D-function point value for an embedded system with the following
characteristics:
1. Internal data structures = 8
2. No. of user inputs = 32
3. No. of user outputs = 60
4. No. of user inquiries = 24
5. No. of external interfaces = 2
6. No. of transformation = 23
7. No. of transition = 32
Assume complexity of the above counts is average case = 3.
Explanation:
Step-1: We draw the Table first for computing FPs.
SR. MEASUREMENT COUNT SIMPLE AVERAGE COMPLEX CALCULA
NO. PARAMETER WEIGHTING WEIGHTING WEIGHTING TED
FACTOR FACTOR FACTOR VALUE
1 Number of external 32 3 4 6 128
inputs(EI)
2 Number of external 60 4 5 7 300
outputs(EO)
3 Number of external 24 3 4 6 96
Inquiries(EQ)
4 Number of internal 8 7 10 15 80
files (ILF)
5 Number of external 2 5 7 10 14
interfaces(EIF)
6 Number of 23 23
Transformation
7 Number of 32 32
Transition
Count – Total —–> 673
Step-2: Find the sum of all fi (1 to 14)
Σ(&fi) = 14 * 3 = 42
Step-3: Calculate the functional point:
FP = Count-total * [0.65 + 0.01 *Σ(&fi) ]
= 618 * [0.65 + 0.01 * 42]
= 618 * [0.65 + 0.42]
= 618 * 1.07
= 661.26
Step-4: Calculate the Feature point:
= (32 *4 + 60 * 5 + 24 * 4 + 80 +14) * 1.07 + {12 * 15 *1.07}
= 853.86
Step-5: Calculate the 3D function point, it is calculated by counting the total calculated values. So, for
3D function points, the required index is 673.

II. Empirical Estimation Models

 Uses empirically derived formulas to predict effort as a function of LOC or FP
 The empirical data are derived from a limited sample of projects
 So, no estimation model is appropriate for all classes of s/w and in all development
environments
 The results obtained from such models must be used judiciously
 An estimation model should be calibrated to reflect local conditions

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

The key parameters which define the quality of any software products, which are also an
outcome of the Cocomo are primarily Effort & Schedule:
 Effort: Amount of labor that will be required to complete a task. It is measured in person-months
units.
 Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put. It is measured in the units of time such as weeks, months.
Different models of Cocomo have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be applied
to a variety of projects, whose characteristics determine the value of constant to be used in
subsequent calculations.
THE DEVELOPMENT MODE
Boehm’s definition of organic, semidetached, and embedded systems:
1. Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and also the
team members have a nominal experience regarding the problem.
2. Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as Semi-
Detached are comparatively less familiar and difficult to develop compared to the organic ones
and require more experience and better guidance and creativity. Eg: Compilers or different
Embedded Systems can be considered of Semi-Detached type.
3. Embedded – A software project with requiring the highest level of complexity, creativity, and
experience requirement fall under this category. Such software requires a larger team size
than the other two models and also the developers need to be sufficiently experienced and
creative to develop such complex models.
All the above system types utilize different values of the constants used in Effort Calculations.

PRODUCTIVITY
• Productivity equation
(DSI) / (PM)
• where PM = number of person-month (=152 working hours),
• DSI = "delivered source instructions"
SCHEDULE
• Schedule equation
TDEV = C * (PM)n (months)
• where TDEV = number of months estimated for software development.
AVERAGE STAFFING
• Average Staffing Equation
(PM) / (TDEV)(FSP)
• where FSP means Full-time-equivalent Software Personnel.

9
Types of Models: COCOMO consists of a hierarchy of three increasingly detailed and accurate
forms. Any of the three forms can be adopted according to our requirements. These are types of
COCOMO model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
The first level, Basic COCOMO can be used for quick and slightly rough calculations of
Software Costs. Its accuracy is somewhat restricted due to the absence of sufficient factor
considerations. Intermediate COCOMO takes these Cost Drivers into account and Detailed
COCOMO additionally accounts for the influence of individual project phases, i.e in case of Detailed it
accounts for both these cost drivers and also calculations are performed phase wise henceforth
producing a more accurate result.

Cost Estimation Process

Cost = Size of the Project * Productivity

Basic COCOMO model

The above formula is used for the cost estimation of for the basic COCOMO model, and also
is used in the subsequent models. The constant values a and b for the Basic Model for the different
categories of system:
Effort Computation
• The Basic COCOMO model computes effort as a function of program size. The
Basic COCOMO equation is:
^b
E = a * KLOC
Effort for three modes of Basic COCOMO
Mode a b
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20

The effort is measured in Person-Months and as evident from the formula is dependent on
Kilo-Lines of code. These formulas are used as such in the Basic Model calculations, as not much

10
consideration of different factors such as reliability, expertise is taken into account, henceforth the
estimate is rough

Intermediate COCOMO Model

The basic Cocomo model assumes that the effort is only a function of the number of lines of
code and some constants evaluated according to the different software system. However, in reality,
no system’s effort and schedule can be solely calculated on the basis of Lines of Code. For that,
various other factors such as reliability, experience, Capability. These factors are known as Cost
Drivers and the Intermediate Model utilizes 15 such drivers for cost estimation.
• The Intermediate COCOMO equation is:
^b
– E = a * KLOC * EAF
The values of a and b in case of the intermediate model are as follows:
SOFTWARE PROJECTS A B
Organic 3.2 1.05
Semi Detached 3.0 1.12
Embeddedc 2.8 1.20

Classification of Cost Drivers and their attributes:

(i) Product attributes –
 Required software reliability extent
 Size of the application database
 The complexity of the product
(ii) Hardware attributes –
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
(iii) Personnel attributes –
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
(iv) Project attributes –
 Use of software tools
 Application of software engineering methods
 Required development schedule

COST DRIVERS VERY LOW LOW NOMINAL HIGH VERY HIGH

Product Attributes
Required Software Reliability 0.75 0.88 1.00 1.15 1.40
Size of Application Database 0.94 1.00 1.08 1.16
Complexity of The Product 0.70 0.85 1.00 1.15 1.30
Hardware Attributes
Runtime Performance Constraints 1.00 1.11 1.30
Memory Constraints 1.00 1.06 1.21
Volatility of the virtual machine 0.87 1.00 1.15 1.30
environment
Required turnabout time 0.94 1.00 1.07 1.15
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer capability 1.42 1.17 1.00 0.86 0.70
Virtual machine experience 1.21 1.10 1.00 0.90
Programming language experience 1.14 1.07 1.00 0.95
Project Attributes
Application of software engineering 1.24 1.10 1.00 0.91 0.82
methods

11
 Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10

The project manager is to rate these 15 different parameters for a particular project on a scale
of one to three. Then, depending on these ratings, appropriate cost driver values are taken from the
above table. These 15 values are then multiplied to calculate the EAF (Effort Adjustment Factor).
Detailed COCOMO Model
Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering process. The
detailed model uses different effort multipliers for each cost driver attribute. In detailed cocomo, the
whole software is divided into different modules and then we apply COCOMO in different modules to
estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
1. Planning and requirements
2. System design
3. Detailed design
4. Module code and test
5. Integration and test
6. Cost Constructive model
The effort is calculated as a function of program size and a set of cost drivers are given
according to each phase of the software lifecycle.

COCOMO-II Model
The 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.
The COCOMO II application composition model uses object points. Object point is computed using
counts of the number of
o Screens (at the user interface)
o Reports
o Components likely to be required to build the application

12
  NOP = (object points)  [(100-%reuse)/100]
– NOP = New Object Points
– Object Points = Weighted Total
– %reuse = Percent of reuse
 Estimated effort = NOP/PROD
– PROD = Productivity Rate
– PROD = NOP/person-month
The Software Equation
 It is a multivariate model
 Has been derived from productivity data collected for over 4000 contemporary s/w
projects
 E = [LOC  B0.333/P]3  (1/t4)
– Here, E = effort in person-months or person-years
– t = project duration in months or years
– B = ―special skills factor‖
– P = ―productivity parameter‖
 For small programs (KLOC = 5 to 15)
– B = 0.16
 For programs greater than 70 KLOC
– B = 0.39
 P = 2000 for development of real-time embedded s/w
 P = 10,000 for telecommunication and systems s/w
 P = 28,000 for business systems applications
 Simplified formulas
– tmin = 8.14 (LOC/P)0.43 in months for tmin > 6 months
tmin = minimum development time
– E = 180 Bt3 in person-months for E  20 person-months
Here t is represented in years

Project Scheduling
Project Scheduling in a project refers to roadmap of all activities to be done with specified
order and within time slot allotted to each activity. Project managers tend to define various tasks and
project milestones and arrange them keeping various factors in mind. They look for tasks lie in
critical path in the schedule, which are necessary to complete in specific manner (because of task
interdependency) and strictly within the time allocated. Arrangements of tasks which lie out of critical
path are less likely to impact over all schedule of the project.

For scheduling a project, it is necessary to -

 Break down the project tasks into smaller, manageable form
 Find out various tasks and correlate them
 Estimate time frame required for each task
 Divide time into work-units
 Assign adequate number of work-units for each task
 Calculate total time required for the project from start to finish

Software project scheduling is an action that distributes estimated effort across the
planned project duration by allocating the effort to specific software engineering tasks. The schedule
evolves over time. During early stages of project planning, a macroscopic schedule is developed.
This type of schedule identifies all major process framework activities and the product functions to
which they are applied. As the project development starts, each entry on the macroscopic schedule
is refined into a detailed schedule. Here, specific software actions and tasks (required to accomplish
an activity) are identified and scheduled. Scheduling for software engineering projects can be viewed
from two rather different perspectives.
 In the first,
 An end date for release of a computer-based system has already been established.
 The software organization is constrained to distribute effort within the prescribed time
frame.
13
  The second view of software scheduling assumes that
 Rough chronological bounds have been discussed but that the end date is set by
the software engineering organization.
 Effort is distributed to make best use of resources, and an end date is defined after
careful analysis of the software.
Unfortunately, the first situation is encountered far more frequently than the second.
Scheduling Principles
 compartmentalization—define distinct tasks
 interdependency—indicate task interrelationship
 effort validation—be sure resources are available
 defined responsibilities—people must be assigned
 defined outcomes—each task must have an output
 defined milestones—review for quality

Effort and Delivery Time

Effort Allocation
 Front End Activities
• Customer Communication
• Analysis
• Design
• Review And Modification
 Construction Activities
Defining Task Sets
 Determine type of project
 Concept development, new application development, application
enhancement, application maintenance, and reengineering projects
 Assess the degree of rigor required
 Identify adaptation criteria
 Select appropriate software engineering tasks
• Coding or Code Generation
• Testing and Installation
- Unit, Integration
- White-Box, Black Box
- Regression

Earned Value Analysis (EVA)

Earned Value Analysis (EVA) is an industry standard method of measuring a project's
progress at any given point in time, forecasting its completion date and final cost, and analyzing
variances in the schedule and budget as the project proceeds.
It compares the planned amount of work with what has actually been completed, to determine
if the cost, schedule, and work accomplished are progressing in accordance with the plan. As work is
completed, it is considered "earned".

14
Earned Value Formulas
Earned Value is a method of calculating project status. It does this from two perspectives: Time
(schedule) and Cost. After applying the earned value method the project manager will know whether
the project is:
Behind or ahead of schedule. Over or under budget.
Planned Value (PV)
Also known as Budgeted Cost of Work Scheduled (BCWS), Planned Value is the amount of
the task that is supposed to have been completed, in terms of the task budget. It is calculated from
the project budget.
PV = Percent Complete (planned) x Task Budget
For example, if it’s Feb. 12 today, and the task is supposed to last from Feb. 10 to Feb. 20, it should
be 20% complete. If the task budget is $10,000, PV = 20% x $10,000 = $2,000.
Earned Value (EV)
Also known as Budgeted Cost of Work Performed (BCWP), Earned Value is the amount of the
task that is actually completed. It is also calculated from the project budget.
EV = Percent Complete (actual) x Task Budget
For example, if the actual percent complete is 25% and the task budget is $10,000, EV = 25% x
$10,000 = $2,500.
Actual Cost (AC)
Also known as Actual Cost of Work Performed (ACWP), Actual Cost is the actual to-date cost
of the task.
AC = Actual Cost of the Task
For example, if the actual cost is $3,500, AC = $3,500.

Schedule Variance (SV)

In this, the first output calculated in the earned value analysis, the project manager obtains a
value which tells you the amount that the task is ahead or behind schedule.
SV = EV – PV
 If SV is negative, the task is behind schedule.
 If SV is zero, the task is on schedule
 If SV is positive, the task is ahead of schedule.
In our example, SV = $2,500 – $2,000 = $500. This task is ahead of schedule.

PROJECT PLAN
A project plan is an essential document for keeping a project on track. In your project plan, you
identify the scope, goals, deliverables and deadlines of your project.
A project plan should answer these questions:
 What is the purpose of this project (what problem is it going to solve)?
 What are the main deliverables?
 What will the timeline be, including deadlines?
 Who will be on the team for this project and what role will they play?
 What resources are required to complete this project?

SOFTWARE PROJECT PLANNING

• Software project planning encompasses five major activities
– Estimation,
- Scheduling,
- Risk analysis,
- Quality Management Planning,
- Change Management Planning
• Estimation determines how much money, effort, resources, and time will take to build a
specific system or product
• The software team first estimates
– The work to be done
– The resources required
– The time that will elapse from start to finish
• Then they establish a project schedule that
– Defines tasks and milestones
– Identifies who is responsible for conducting each task

15
 – Specifies the inter-task dependencies
• Planning requires technical managers and the software team to make an initial commitment
• Process and project metrics can provide a historical perspective and valuable input for
generation of quantitative estimates
• Past experience can aid greatly
• Estimation carries inherent risk, and this risk leads to uncertainty.
• The availability of historical information has a strong influence on estimation risk.

Task Set for Project Planning

1) Establish project scope
2) Determine feasibilityy
3) Analyze risks
4) Define required resources
a) Determine human resources required
b) Define reusable software resources
c) Identify environmental resources
5) Estimate cost and effort
a) Decompose the problem
b) Develop two or more estimates using different approaches
c) Reconcile the estimates
6) Develop a project schedule
a) Establish a meaningful task set
b) Define a task network
c) Use scheduling tools to develop a timeline chart
d) Define schedule tracking mechanisms
S/w project management process begins with project planning objective of s/w project
planning - to provide a framework for manager to make reasonable estimates of resources, costs and
schedules.

Activities associated with project planning

 Software scope
 resources
 project estimation
 decomposition
Software Scope
It wants to establish a project scope that is unambiguous and understandable at management
and technical levels. It describes:
 Function
 Performance
 Constraints
 Interfaces
 Reliability
Resources
must estimate resources required to accomplish the development effort
Three major categories of software engineering resources
o People
o Development environment
o Reusable software components
Often neglected during planning but become a paramount concern during the construction
phase of the software process.
Each resource is specified with
o A description of the resource
o A statement of availability
o The time when the resource will be required
o The duration of time that the resource will be applied
Off-the-shelf Components
o Components are from a third party or were developed for a previous project
o Ready to use; fully validated and documented; virtually no risk

16
Full-experience Components
o Components are similar to the software that needs to be built
o Software team has full experience in the application area of these components
o Modification of components will incur relatively low risk
Partial-experience Components
o Components are related somehow to the software that needs to be built but will require
substantial modification
o Software team has only limited experience in the application area of these components
o Modifications that are required have a fair degree of risk
New Components
o Components must be built from scratch by the software team specifically for the needs of the
current project.
o Software team has no practical experience in the application area.
o Software development of components has a high degree of risk.

RISK MANAGEMENT
Risk is an expectation of loss, a potential problem that may or may not occur in the future. It is
generally caused due to lack of information, control or time. A possibility of suffering from loss in
software development process is called a software risk. Loss can be anything, increase in production
cost, development of poor quality software, not being able to complete the project on time. Software
risk exists because the future is uncertain and there are many known and unknown things that cannot
be incorporated in the project plan.
A software risk can be of two types
(a) Internal risks that are within the control of the project manager and
(b) External risks that are beyond the control of project manager.
Risk management is carried out to:
1. Identify the risk
2. Reduce the impact of risk
3. Reduce the probability or likelihood of risk
4. Risk monitoring
Software risk management is all about risk quantification of risk. This includes:
1. Giving a precise description of risk event that can occur in the project
2. Defining risk probability that would explain what are the chances for that risk to occur
3. Defining How much loss a particular risk can cause
4. Defining the liability potential of risk
RISK MANAGEMENT PROCESS
 Risk identification
• Identify project, product and business risks;
 Risk analysis
• Assess the likelihood and consequences of these risks;
 Risk planning
• Draw up plans to avoid or minimise the effects of the risk;
 Risk monitoring
• Constantly monitor risks & plans for risk mitigation.

1. Software Risk Identification

In order to identify the risks that your project may be subjected to, it is important to first study
the problems faced by previous projects.
The best ways of analyzing a project plan is by converting it to a flowchart and examine all
essential areas.
It is important to conduct few brainstorming sessions to identify the known unknowns that can
affect the project.

17
 Any decision taken related to technical, operational, political, legal, social, internal or external
factors should be evaluated properly.

Fig: Software Risk Identification

In this phase of Risk management you have to define processes that are important for risk
identification. All the details of the risk such as unique Id, date on which it was identified, description
and so on should be clearly mentioned.

2. Software Risk Analysis

Software Risk analysis is a very important aspect of risk management. In this phase the risk is
identified and then categorized. After the categorization of risk, the level, likelihood (percentage) and
impact of the risk is analyzed. Likelihood is defined in percentage after examining what are the
chances of risk to occur due to various technical conditions. These technical conditions can be:
1. Complexity of the technology
2. Technical knowledge possessed by the testing team
3. Conflicts within the team
4. Teams being distributed over a large geographical area
5. Usage of poor quality testing tools
With impact we mean the consequence of a risk in case it happens. It is important to know
about the impact because it is necessary to know how a business can get affected:
1. What will be the loss to the customer
2. How would the business suffer
3. Loss of reputation or harm to society
4. Monetary losses
5. Legal actions against the company
6. Cancellation of business license
Level of risk is identified with the help of:
Qualitative Risk Analysis: Here you define risk as: (i) High (ii) Low (iii) Medium
Quantitative Risk Analysis: can be used for software risk analysis but is considered inappropriate
because risk level is defined in % which does not give a very clear picture.

3. Software Risk Planning

Software risk planning is all about:
 Defining preventive measure that would lower down the likelihood or probability of various
risks.
 Define measures that would reduce the impact in case a risk happens.
 Constant monitoring of processes to identify risks as early as possible.

18
 Fig: Software Risk Planning

4. Software Risk Monitoring

Software risk monitoring is integrated into project activities and regular checks are conducted on
top risks. Software risk monitoring comprises of:
 Tracking of risk plans for any major changes in actual plan, attribute, etc.
 Preparation of status reports for project management.
 Review risks and risks whose impact or likelihood has reached the lowest possible level
should be closed.
 Regularly search for new risks.

Risk Mitigation, Monitoring and Management (RMMM)

Risk analysis supports the project team in constructing a strategy to deal with risks.
There are three important issues considered in developing an effective strategy:
 Risk avoidance or mitigation - It is the primary strategy which is fulfilled through a plan.
 Risk monitoring - The project manager monitors the factors and gives an indication whether
the risk is becoming more or less.
 Risk management and planning - It assumes that the mitigation effort failed and the risk is a
reality.

RMMM Plan:
 It is a part of the software development plan or a separate document.
 The RMMM plan documents all work executed as a part of risk analysis and used by the
project manager as a part of the overall project plan.
 The risk mitigation and monitoring starts after the project is started and the documentation of
RMMM is completed.

Risk 1: Computer Crash

Mitigation: The cost associated with a computer crash resulting in a loss of data is crucial. A
computer crash itself is not crucial, but rather the loss of data. A loss of data will result in not being
able to deliver the product to the customer. This will result in a not receiving a letter of acceptance
from the customer. Without the letter of acceptance, the group will receive a failing grade for the
course. As a result the organization is taking steps to make multiple backup copies of the software in
development and all documentation associated with it, in multiple locations. ·

Monitoring: When working on the product or documentation, the staff member should always be
aware of the stability of the computing environment they’re working in. Any changes in the stability of
the environment should be recognized and taken seriously.

19
Management: The lack of a stable-computing environment is extremely hazardous to a software
development team. In the event that the computing environment is found unstable, the development
team should cease work on that system until the environment is made stable again, or should move
to a system that is stable and continue working there.

Risk 2: Late Delivery

Mitigation: The cost associated with a late delivery is critical. A late delivery will result in a late
delivery of a letter of acceptance from the customer. Without the letter of acceptance, the group will
receive a failing grade for the course. Steps have been taken to ensure a timely delivery by gauging
the scope of project based on the delivery deadline.

Monitoring: A schedule has been established to monitor project status. Falling behind schedule
would indicate a potential for late delivery. The schedule will be followed closely during all
development stages.

Management: Late delivery would be a catastrophic failure in the project development. If the project
cannot be delivered on time the development team will not pass the course. If it becomes apparent
that the project will not be completed on time, the only course of action available would be to request
an extension to the deadline from the customer.

RISK TABLE

Software Case Tools Overview

CASE stands for Computer Aided Software Engineering. It means development and
maintenance of software projects with help of various automated software tools.
CASE Tools
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to develop
software system. There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools, Database
Management tools, Documentation tools are to name a few. Use of CASE tools accelerates the
development of project to produce desired result and helps to uncover flaws before moving ahead
with next stage in software development.
Components of CASE Tools
CASE tools can be broadly divided into the following parts based on their use at a particular
SDLC stage:
 Central Repository - CASE tools require a central repository, which can serve as a source of
common, integrated and consistent information. Central repository is a central place of
storage where product specifications, requirement documents, related reports and diagrams,
other useful information regarding management is stored. Central repository also serves as
data dictionary.

20
  Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of
SDLC.
 Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from
Requirement gathering to Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process activities and
capability of getting integrated with other tools.
Scope of Case Tools
The scope of CASE tools goes throughout the SDLC.
Case Tools Types
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart Maker tool
for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it as per
the requirement of software product. For example, EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project execution with every mentioned step in
software project management. Project management tools help in storing and sharing project
information in real-time throughout the organization. For example, Creative Pro Office, Trac Project,
Basecamp.
Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all
phases of SDLC and after the completion of the project. Documentation tools generate documents
for technical users and end users. Technical users are mostly in-house professionals of the
development team who refer to system manual, reference manual, training manual, installation
manuals etc. The end user documents describe the functioning and how-to of the system such as
user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example, Accept 360,
Accompa, CaseComplete for requirement analysis, Visible Analyst for total analysis.
Design Tools
These tools help software designers to design the block structure of the software, which may
further be broken down in smaller modules using refinement techniques. These tools provides
detailing of each module and interconnections among modules. For example, Animated Software
Design.
Configuration Management Tools
An instance of software is released under one version. Configuration Management tools deal with –
 Version and revision management
 Baseline configuration management
 Change control management
CASE tools help in this by automatic tracking, version management and release management. For
example, Fossil, Git, Accu REV.
Change Control Tools
These tools are considered as a part of configuration management tools. They deal with
changes made to the software after its baseline is fixed or when the software is first released. CASE
tools automate change tracking, file management, code management and more. It also helps in
enforcing change policy of the organization.
Programming Tools
These tools consist of programming environments like IDE (Integrated Development
Environment), in-built modules library and simulation tools. These tools provide comprehensive aid in
building software product and include features for simulation and testing. For example, Cscope to
search code in C, Eclipse.

21
Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype provides
initial look and feel of the product and simulates few aspect of actual product. Prototyping CASE
tools essentially come with graphical libraries. They can create hardware independent user
interfaces and design. These tools help us to build rapid prototypes based on existing information. In
addition, they provide simulation of software prototype. For example, Serena prototype composer,
Mockup Builder.
Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text, script,
graphic and so on. Web tools also provide live preview of what is being developed and how will it
look after completion. For example, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process and
methods adopted to develop the software product in order to ensure conformance of quality as per
organization standards. QA tools consist of configuration and change control tools and software
testing tools. For example, SoapTest, AppsWatch, JMeter.
Maintenance Tools
Software maintenance includes modifications in the software product after it is delivered.
Automatic logging and error reporting techniques, automatic error ticket generation and root cause
Analysis are few CASE tools, which help software organization in maintenance phase of SDLC. For
example, Bugzilla for defect tracking, HP Quality Center.

Possible Questions
Part – A
1. Define error, fault and failure.
2. List two advantages of using COCOMO model.
3. Compare: Project Risk vs Business Risk
4. List CASE tools for the following phases of SDLC: Design, Testing.
5. What is budgeted cost of work scheduled?
6. Write any two differences between “known risks” and “Predictable risks”.
7. What are the processes of risk management?
8. Differentiate between size oriented and function oriented metrics.
9. What are the types of metrics?
10. An organic software occupies 15000 LOC. How many programmers are needed to
complete?
11. What is EVA?
12. State the need for software configuration review.
13. What is project planning?
14. How is productivity and cost related to function points?
15. What is COCOMO model?
16. List down the process and product metrics.
17. What is error tracking?
18. What are the productivity measures and list its types?
19. List out the principles of project scheduling.
20. Write a note on Risk information sheet.
21. List two customers related and technology related risks.
22. What is RMMM?
23. Explain the common risk tools and techniques.
24. What are the factors that lead to Risk?
25. Distinguish between direct and indirect measures of metrics.

Part – B
1. List the features of LOC and FP based estimation models. Compare the two models and list
the advantages of one over other.
2. Define: Risk. List the types of Risk and give examples for each. List and explain the phases in
risk management.
3. Elaborate the cost estimation COCOMO II cost estimation model.
4. Explain about all COCOMO models.

22
 5. Present a detailed note on risk management.
6. Outline the steps in function point analysis with an example.
7. Explain make/buy decision and discuss putnam resource allocation model. Drive time and
effort equation.
8. Explain the various CASE tools for project management and how they are useful in achieving
the objectives.
9. Brief about calculating Earned value measures.
10. Describe the steps involved in project scheduling process, project timeline chart and task
network.
11. Elaborate the series of tasks of a software configuration management process. (b)Describe
function point analysis with a neat example.

Part – C
1. Describe in detail COCOMO model for software cost estimation. Use it to estimate the effort
required to build software for a simple ATM that produce 12 screens, 10 reports and has 80
software components. Assume average complexity and average developer maturity. Use
application composition model with object points.
2. Explain the process of function point analysis? Explain function point analysis with sample
cases for component for different complexity.
3. Consider the following function point components and their complexity. If the total degree of
influence is 52. Find the estimated function point
Function type Estimated count Complexity
ELF 2 7
ILF 4 10
EQ 22 4
EO 16 5
EI 24 4

4. Suppose you have a budgeted cost of the project as Rs.9, 00,000. The project is completed in
9 months. You have completed 10 % of the project at the total expenses of Rs.1, 00,000. The
planned completion should have been 15 %. You need to determine whether the project is on-
time and on-budget?
5. Consider 7 function with their estimated LOC’s are given below fun1 – 2340, fun2- 5380, fun3-
6800, fun4- 3350, fun5-4950, fun6 -2140, fun7 – 8400. Average productivity based on historical
data is 620 Loc/pm and labour rate is Rs. 8000 per month. Find total estimated cost and effort.
Analyze on how effort is calculated using the FP based complexity measure for a system in which
the following data exists: No. of User inputs-40 No. of user Outputs-10 No. of Inquiries-5 No. of
Internal Logical Files-5 No. of External Interface-2 Assume your own Complexity level for each of
the categories and your own values for the 14 questions raised to the customers.

SOFTWARE RISKS

23
RISK TYPES

RISK MANAGEMENT STRATEGIES

24