Unit 5 Syllabus

Software project management : Project managment, Project planning and control, Cost
estimation, Project scheduling using PERT and GANTT charts, Software configuration
management
 Software Project Management (SPM)

What is Project?
• A project is a set of inputs and outputs which are required to achieve a goal.
• Once a project is found to be feasible, software project managers undertake project planning.
• Project planning is undertaken and completed even before any development activity starts.
• For good project development, some teams split the project into specific tasks so they can
manage responsibility and utilize team strengths.
 Software Project Management (SPM)

Software Project Management (SPM)

• It is a part of project management in which software projects are planned, implemented,
monitored and controlled.
• It is necessary for an organization to deliver quality product, keeping the cost within client’s
budget constrain and deliver the project as per scheduled.
 Software Project Management (SPM)

Essential activities in Project Planning:

• Project size: What will be problem complexity in terms of the effort and time required to
develop the product?
• Cost: How much is it going to cost to develop the project?
• Duration: How long is it going to take to complete development?
• Effort: How much effort would be required?
The effectiveness of the subsequent planning activities is based on the accuracy of these
estimations.
• Scheduling manpower and other resources
• Staff organization and staffing plans
• Risk identification, analysis, and abatement planning
• Miscellaneous plans such as quality assurance plan, configuration management plan, etc
 Software Project Management (SPM)

Precedence ordering among project planning activities:

 Software Project Management (SPM)

Problem in Project Planning

• Commitment to unrealistic time and resource estimates result in schedule slippage.
• Schedule delays can cause customer dissatisfaction and adversely affect team morale.
• However, project planning is a very challenging activity. Especially for large projects, it is very
much difficult to make accurate plans.
• A part of this difficulty is due to the fact that the proper parameters, scope of the project,
project staff, etc. may change during the span of the project.
 Software Project Management (SPM)

Prerequisite of software project management

• Time
• Cost
• Quality
 Software Project Management (SPM)

Project Manager
• A project manager is a character who has the overall responsibility for the planning, design,
execution, monitoring, controlling and closure of a project.
• A project manager represents an essential role in the achievement of the projects.
Role of a Project Manager:
• Leader
• Medium
• Mentor
 Software Project Management (SPM)

Responsibilities of a Project Manager

• Managing risks and issues.A project manager represents an essential role in the achievement of
the projects.
• Create the project team and assigns tasks to several team members.
• Activity planning and sequencing.
• Monitoring and reporting progress
• Modifies the project plan to deal with the situation.
 Software Project Management (SPM)

Activities
• Project planning and Tracking
• Project Resource Management
• Scope Management
• Estimation Management
• Project Risk Management
• Scheduling Management
• Project Communication Management
• Configuration Management
 Software Project Management (SPM)
Software Project Management Plan (SPMP)
1. Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraints
2. Project Estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates
3. Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation
 Software Project Management (SPM)

Software Project Management Plan (SPMP)

4. Project Resources
(a) People
(b) Hardware and Software
(c) Special Resources
5. Staff Organization
(a) Team Structure
(b) Management Reporting
6. Risk Management Plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
7. Project Tracking and Control Plan
 Software Project Management (SPM)

Software Project Management Plan (SPMP)

8. Miscellaneous Plans
(a) Process Tailoring
(b) Quality Assurance Plan
(c) Configuration Management Plan
 Software Project Management (SPM)

Project Estimation techniques

• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
 Software Project Management (SPM)

Empirical Estimation Techniques

• Based on making an educated guess of the project parameters.
• Prior experience with development of similar products is helpful.
• Although empirical estimation techniques are based on common sense, different activities
involved in estimation have been formalized over the years
Two popular empirical estimation techniques are:
1) Expert judgment technique
2) Delphi cost estimation
 Software Project Management (SPM)

Expert Judgment Technique

• An expert makes an educated guess of the problem size after analyzing the problem
thoroughly.
• Estimates the cost of the different components (i.e. modules or subsystems) of the system and
then combines them to arrive at the overall estimate.
• However, this technique is subject to human errors and individual bias.
• For example, he may be conversant with the database and user interface parts but may not be
very knowledgeable about the computer communication part.
• A more refined form of expert judgment is the estimation made by group of experts.
 Software Project Management (SPM)

Delphi cost estimation

• It overcomes some of the shortcomings of the expert judgment approach.
• Delphi estimation is carried out by a team comprising of a group of experts and a coordinator.
• No discussion among the estimators is allowed during the entire estimation process.
• The coordinator provides each estimator with a copy of the SRS document and a form for
recording his cost estimate.
• Estimators complete their individual estimates anonymously and submit to the coordinator.
• The coordinator prepares and distributes the summary of the responses of all the estimators,
and includes any unusual rationale noted by any of the estimators.
• Based on this summary, the estimators re-estimate.
• This process is iterated for several rounds.
 Software Project Management (SPM)

Heuristic Techniques
• It assumes that the relationships among the different project parameters can be modelled using
suitable mathematical expressions.
• Once the basic (independent) parameters are known, the other (dependent) parameters can be
easily determined by substituting the value of the basic parameters in the mathematical
expression.
• Two classes:
1) single variable model and
2) multi variable model
 Software Project Management (SPM)

Single variable estimation models

• It provides a means to estimate the desired characteristics of a problem, using some previously
estimated basic (independent) characteristic of the software product such as its size.

Estimated Parameter =

• e is the characteristic of the software which has already been estimated (independent variable)
• c1 and d1 are constants determined using data collected from past projects (historical data).
 Software Project Management (SPM)

Multivariable cost estimation model

• Where e1, e2, … are the basic (independent) characteristics of the software already estimated,
and c1, c2, d1, d2, … are constants.
• Multivariable estimation models are expected to give more accurate estimates.
 COCOMO Model

COCOMO Model
• The COCOMO (Constructive Cost Model) is one of the most popularly used software cost
estimation models i.e. it estimates or predicts the effort required for the project, total project
cost and scheduled time for the project.
• Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines
of Code
• It was developed by a software engineer Barry Boehm in 1981.
• The COCOMO estimates the cost for software product development in terms of effort
(resources required to complete the project work) and schedule (time required to complete the
project work) based on the size of the software product.
• It estimates the required number of Man-Months (MM) for the full development of software
products.
 COCOMO Model

COCOMO Model
• It aims at estimating small to medium sized software projects.
 COCOMO Model

Project Types
• Organic Project
It belongs to small & simple software projects which are handled by a small team with good
domain knowledge and few rigid requirements.
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 methods of projects.

Example - Small data processing or Inventory management system

 COCOMO Model

Project Types
• Semidetached Project
It is an intermediate (in terms of size and complexity) project, where the team having mixed
experience (both experience & inexperience resources) to deals with rigid/nonrigid
requirements..
Team members may have finite experience in related systems but may be unfamiliar with some
aspects of the order being developed.

Example - Database design or OS development.

 COCOMO Model

Project Types
• Embedded Project
This project having a high level of complexity with a large team size by considering all sets of
parameters (software, hardware and operational).
The software being developed is strongly coupled to complex hardware, or if the stringent
regulations on the operational method exist

Example - ATM, Air Traffic control..

 COCOMO Model

COCOMO Model Types

 COCOMO Model

The Basic COCOMO

• It is the one type of static model to estimates software development effort quickly and roughly.
• It mainly deals with the number of lines of code and the level of estimation accuracy is less as
we don’t consider the all parameters belongs to the project
• The estimated effort and scheduled time for the project are given by the relation:

Where
Effort (E) = Total effort required for the project in Man-Months
(MM).
D = Total time required for project development in Months (M).
KLOC = the size of the code for the project in Kilo lines of code.
a, b, c, d = The constant parameters for a software project.
 COCOMO Model

The Basic COCOMO

PROJECT TYPE a b c d

Organic 2.4 1.05 2.5 0.38

Semidetached 3 1.12 2.5 0.35

Embedded 3.6 1.2 2.5 0.32

 COCOMO Model

The Basic COCOMO

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

Solution: As per the basic COCOMO estimation formula for organic software:

Effort = 2.4*(32)1.05 = 91 PM

Nominal development time = 2.5 * (91)0.38 = 14 months

Cost required to develop the product = 14 * 15,000 = Rs. 210,000/

 COCOMO Model

The Basic COCOMO

Question - Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & embedded.
Solution: The basic COCOMO equation takes the form:
Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
Semidetached Mode Embedded Mode
E = 3.0 * (400)1.12=2462.79 PM E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (2462.79)0.35=38.45 PM D = 2.5 * (4772.8)0.32 = 38 PM
 COCOMO Model

The Basic COCOMO

Question - A project size of 200 KLOC is to be developed. Software development team has
average experience on similar type of projects. The project schedule is not very tight. Calculate
the Effort, development time, average staff size, and productivity of the project.
Solution: The semidetached mode is the most appropriate mode, keeping in view the size,
schedule and experience of development time.:

E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM
 COCOMO Model

The Intermediate COCOMO

• The intermediate model estimates software development effort in terms of size of the program
and other related cost drivers parameters (product parameter, hardware parameter, resource
parameter, and project parameter) of the project.
• The basic COCOMO model by using a set of 15 cost drivers based on various attributes of
software engineering
Classification of Cost Drivers and their attributes
Product attributes - Hardware attributes - Personnel attributes - Project attributes
• Required software reliability • Run-time performance • Analyst capability • Use of software tools
extent constraints • Software engineering • Application of software
• Size of the application • Memory constraints capability engineering methods
database • The volatility of the virtual • Applications experience • Required development
• The complexity of the machine environment • Virtual machine experience schedule
product •Required turnabout time Programming language
experience
 COCOMO Model

The Intermediate COCOMO

The estimated effort and scheduled time are given by the relationship:

Effort (E) = a*(KLOC)b *EAF MM

Scheduled Time (D) = c*(E)d Months(M)
 COCOMO Model

The Intermediate COCOMO

 COCOMO Model

The Intermediate COCOMO

 COCOMO Model

The Intermediate COCOMO

Question - For a given project was estimated with a size of 300 KLOC. Calculate the Effort,
Scheduled time for development by considering developer having high application experience
and very low experience in programming.

Solution - Given the estimated size of the project is: 300 KLOC
Developer having highly application experience: 0.82 (as per above table)
Developer having very low experience in programming: 1.14(as per above table)

EAF = 0.82*1.14 = 0.9348

Effort (E) = a*(KLOC)b *EAF = 3.0*(300)1.12 *0.9348 = 1668.07 MM
Scheduled Time (D) = c*(E)d = 2.5*(1668.07)0.35 = 33.55 Months(M)
 COCOMO Model

The Detailed COCOMO

• A major shortcoming of both the basic and intermediate COCOMO models is that they
consider a software product as a single homogeneous entity
• Most large systems are made up several smaller sub-systems. These sub-systems may have
widely different characteristics.
• The Detailed COCOMO Model differs from the Intermediate COCOMO model in that it uses
effort multipliers for each phase of the project
The Six phases of detailed COCOMO are:
• Planning and requirements
• System structure
• Complete structure
• Module code and test
• Integration and test
• Cost Constructive model
 Staffing level estimation

• Once the effort required to develop a software has been determined, it is necessary to
determine the staffing requirement for the project.
• Norden and Putnam studied the staffing patterns of several R & D projects.
 Staffing level estimation

Norden’s Work
• He found that the staffing pattern can be approximated by the Rayleigh distribution curve.
• Norden represented the Rayleigh curve by the following equation:

Where
E is the effort required at time t. E is an indication of the number of engineers (or the staffing level) at any particular time during
the duration of the project
K is the area under the curve, and
td is the time at which the curve attains its maximum value.
 Staffing level estimation

Norden’s Work
 Staffing level estimation

Work breakdown structure

• Work Breakdown Structure (WBS) is used to decompose a given task set recursively into small
activities.
• The root of the tree is labeled by the problem name.
• Each node of the tree is broken down into smaller activities that are made the children of the
node.
• Each activity is recursively decomposed into smaller sub-activities until at the leaf level, the
activities requires approximately two weeks to develop.
 Staffing level estimation

Work breakdown structure

 Project scheduling

• It involves deciding which tasks would be taken up when. Activities undertaken:

1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to complete the
activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path. A critical path is the chain of activities that determines the
duration of the project.
 Project scheduling

Gantt Chart
• Generalized Activity Normalization Time Table (GANTT) chart is a type of a bar chart that
is used for illustrating project schedules.
• Series of horizontal lines are present that show the amount of work done in given period of
time in relation to amount planned for those projects
• Developed by Henry L. Gantt (American engineer and social scientist) in 1917 as production
control tool
• It is simply used for graphical representation of schedule that helps to plan in an efficient way,
coordinate, and track some particular tasks in project.
• The purpose of Gantt chart is to emphasize scope of individual tasks
• Gantt chart is also known as timeline chart.
• It can be developed for entire project or it can be developed for individual functions.
Gantt Chart
Gantt Chart
 Gantt Chart

Gantt chart represents following things

• All the tasks are listed at leftmost column.
• The horizontal bars indicate or represent required time by corresponding particular task.
• When occurring of multiple horizontal bars takes place at same time on calendar, then that
means concurrency can be applied for performing particular tasks.
• The diamonds indicate milestones.
 Gantt Chart

Advantages
• Simplify Project
• Establish Schedule
• Provide Efficiency
• Emphasize on scope
• Ease at understanding
• Visualize project
• Organize thoughts and Highly visible
• Make Practical and Realistic planning
 Gantt Chart

Disadvantages
• Gantt chart makes project more complex.
• The size of bar chart dost not necessarily indicate amount of work done in project.
• Gantt charts and projects are needed to be updated on regular basis.
• It is not possible or difficult to view this chart on one sheet of paper.
 Gantt Chart

Tools
• Instagantt
• TeamGantt
• ProofHub
• Wrike
• Smartsheet
• GanttPRO.
• Microsoft Project
 PERT Chart

Introduction
• PERT stands for Project Evaluation and Review Technique
• Developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program.
• It is a project management tool used to schedule, organize and coordinate tasks within a project
• It provides a graphical representation of a project's timeline that enables project managers to
break down each individual task in the project for analysis.
• PERT charts provide project managers with an estimation of the minimum amount of time
needed to complete a project.
• The PERT chart template uses nodes -- drawn as rectangles or circles -- to represent events and
milestones throughout the project. The nodes are connected by vectors -- drawn as lines --
which represent the various tasks that need to be complete
PERT Chart
 PERT Chart

Terminology
• Nodes are visual representations of milestones or events within the project. They are drawn as
either numbered boxes or numbered circles.
• Arrows are visual representations of the tasks that occur throughout the project. The direction
of the arrow indicates the sequence of the task. Diverging arrows show that various tasks can
be completed at the same time.
• Fast tracking is when tasks and activities are performed simultaneously.
• A PERT event is the point at which one or more tasks are started or completed.
• Crashing critical path is when the completion time of a task is shortened.
• Lag time refers to the earliest point at which a task can follow another.
 PERT Chart

Terminology
• Expected time is the best estimation of how long a task will take to complete, taking into
consideration any problems or obstacles that might arise.
• Optimistic time refers to the minimum amount of time it will take to complete a task.
• Pessimistic time is the maximum amount of time it will take to finish a task.
• Most likely time is the best guess of how long a task will take, assuming no problems arise.
 PERT Chart

Steps
• Define all activities involved in the project.
• Consider any dependencies between tasks.
• Draw nodes and arrows based on the information gathered in the first two steps.
• Identify the completion time for each task.
 PERT Chart

Advantages
• Estimation of completion time of project is given by the PERT.
• It supports the identification of the activities with slack time.
• The start and dates of the activities of a specific project is determined.
• It helps project manager in identifying the critical path activities.
• PERT makes well organized diagram for the representation of large amount of data
 PERT Chart

Disadvantages
• The complexity of PERT is more which leads to the problem in implementation.
• The estimation of activity time are subjective in PERT which is a major disadvantage.
• Maintenance of PERT is also expensive and complex.
• The actual distribution of may be different from the PERT beta distribution which causes
wrong assumptions.
• It under estimates the expected project completion time as there is chances that other paths can
become the critical path if their related activities are deferred
 PERT Chart

Difference
• PERT charts are flowcharts while Gantt charts are bar graphs:
• Gantt charts offer organization while PERT charts offer customization
• PERT charts can be used before the project begins
 PERT Chart

Difference
 Software Configuration Management (SCM)

Need of SCM
• There are multiple people working on software which is continually updating
• It may be a case where multiple version, branches, authors are involved in a software config
project, and the team is geographically distributed and works concurrently
• Changes in user requirement, policy, budget, schedule need to be accommodated.
• Software should able to run on various machines and Operating Systems
• Helps to develop coordination among stakeholders
• SCM process is also beneficial to control the costs involved in making changes to a system
 Software Configuration Management (SCM)

Tasks in SCM
• Configuration Identification
• Baselines
• Change Control
• Configuration Status Accounting
• Configuration Audits and Reviews
 Software Configuration Management (SCM)

Configuration Identification
• Configuration identification is a method of determining the scope of the software system
• It is a description that contains the CSCI type (Computer Software Configuration Item), a
project identifier and version information.
Activities during this process:
• Identification of configuration Items like source code modules, test case, and requirements
specification.
• Identification of each CSCI in the SCM repository, by using an object-oriented approach
• The process starts with basic objects which are grouped into aggregate objects. Details of what,
why, when and by whom changes in the test are made
• Every object has its own features that identify its name that is explicit to all other objects
• List of resources required such as the document, the file, tools, etc.
 Software Configuration Management (SCM)

Baseline
• It is designated and fixed at a specific time while conducting the SCM process. It can only be
changed through formal change control procedures.

Activities during this process:

• Facilitate construction of various versions of an application
• Defining and determining mechanisms for managing various versions of these work products
• The functional baseline corresponds to the reviewed system requirements
• Widely used baselines include functional, developmental, and product baselines
 Software Configuration Management (SCM)

Change Control
• Change control is a procedural method which ensures quality and consistency when changes
are made in the configuration object
• Change request is submitted to software configuration manager.

Activities during this process:

• Control ad-hoc change to build stable software development environment. Changes are
committed to the repository
• The request will be checked based on the technical merit, possible side effects and overall
impact on other configuration objects.
• It manages changes and making configuration items available during the software lifecycle
 Software Configuration Management (SCM)

Configuration Status Accounting

• Configuration status accounting tracks each release during the SCM process
• This stage involves tracking what each version has and the changes that lead to this version.

Activities during this process:

• Keeps a record of all the changes made to the previous baseline to reach a new baseline
• Identify all items to define the software configuration
• Monitor status of change requests
• Complete listing of all changes since the last baseline
• Allows tracking of progress to next baseline
• Allows to check previous releases/versions to be extracted for testing
 Software Configuration Management (SCM)

Configuration Audits and Reviews

• Software Configuration audits verify that all the software product satisfies the baseline needs.
• It ensures that what is built is what is delivered.

Activities during this process:

• Configuration auditing is conducted by auditors by checking that defined processes are being
followed and ensuring that the SCM goals are satisfied.
• To verify compliance with configuration control standards. auditing and reporting the changes
made
• SCM audits also ensure that traceability is maintained during the process.
• Ensures that changes made to a baseline comply with the configuration status reports
• Validation of completeness and consistency
 Software Configuration Management (SCM)

Participant of SCM process

Configuration Manager

• Configuration Manager is the head who is

Responsible for identifying configuration items.
• CM ensures team follows the SCM process
• He/She needs to approve or reject change
requests
 Software Configuration Management (SCM)

Participant of SCM process

Developer

• The developer needs to change the code as per

standard development activities or change
requests. He is responsible for maintaining
configuration of code.
• The developer should check the changes and
resolves conflicts
 Software Configuration Management (SCM)

Participant of SCM process

Auditor

• The auditor is responsible for SCM audits and

reviews.
• Need to ensure the consistency and
completeness of release.
 Software Configuration Management (SCM)

Participant of SCM process

Project Manager:

• Ensure that the product is developed within a

certain time frame
• Monitors the progress of development and
recognizes issues in the SCM process
• Generate reports about the status of the software
system
• Make sure that processes and policies are
followed for creating, changing, and testing