SOFTWARE ENGINEERING

Software Project Management

Introduction
 Many software projects fail due to faulty project management practices.
 Goal of software project management:
 enable a group of engineers to work efficiently towards successful completion of a software
project.
 Effective software project management focuses on the four Ps
 People
 Product
 Process
 Project
Introduction
 People
 The Software Engineering Institute has developed a People Capability Maturity Model (People-CMM),
in recognition of the fact that “every organization needs to continually improve its ability to attract,
develop, motivate, organize, and retain the workforce needed to accomplish its strategic business
objectives”.
 Organizations that achieve high levels of People-CMM maturity have a higher likelihood of
implementing effective and mature software project management practices.
 Product
 Before a project can be planned, product objectives and scope should be established, alternative
solutions should be considered, and technical and management constraints should be identified.
 Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an
effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule
that provides a meaningful indication of progress
Introduction
 Process
 A software process provides the framework from which a comprehensive plan for software
development can be established.
 A small number of framework activities are applicable to all software projects, regardless of
their size or complexity.
 Project
 Planned and controlled software projects is the only known way to manage complexity.
 To avoid project failure, a software project manager and the software engineers who build the
product must avoid a set of common warning signs, understand the critical success factors that
lead to good project management, and develop a common sense approach for planning,
monitoring, and controlling the project.
Project Manager’s Responsibility
 A project manager’s activities can be broadly classified into:
 project planning
 project monitoring and control activities.
 Activities:
 Project proposal writing,
 Project cost estimation,
 Scheduling,
 Project staffing,
 Project monitoring and control,
 Software configuration management,
 Risk management,
 Managerial report writing and presentations, etc.

Once a project found to be feasible, project manager undertake project planning.

Project Planning
 Software planning begins before technical work starts, continues
as the software evolves from concept to reality, and culminates
only when the software is retired.
 Sliding Window Planning
 It involves project planning over several stages:
 protects managers from making big commitments too early.
 More information becomes available as project progresses.
 Facilitates accurate planning

 After Planning is complete, document the plans in a Software

Project Management Plan (SPMP) document.
Project Planning
 Organization of SPMP Document:
 Introduction (Objectives, Major Functions, Performance Issues, Management and Technical
Constraints)
 Project Estimates (Historical Data, Estimation Techniques, Effort, Cost, and Project Duration
Estimates)
 Schedules (Work Breakdown Structure, Task Network, Gantt Chart Representation, PERT
Chart Representation)
 Project Resources Plan (People, Hardware and Software, Special Resources)
 Staff Organization (Team Structure, Management Reporting)
 Risk Management Plan (Risk Analysis, Risk Identification, Risk Estimation, Abatement
Procedures)
 Project Tracking and Control Plan (Metrics to be tracked, Tracking Plan, Control Plan)
 Miscellaneous Plans (Process Tailoring, Quality Assurance Plan, Configuration Management
Plan, Validation and Verification, System Testing Plan, Delivery, Installation and
Maintenance Plan)
Cost and Estimates
 Determine size of the product.
 From the size estimate,
 determine the effort needed.
 From the effort estimate,
 determine project duration, and cost.

 Three Main approaches to estimation

 Empirical
 Heuristics
 Analytical
Cost and Estimates
 Empirical
 An educated guess based on past experience.
 Ex.: Expert Judgement, Delphi Estimation
 Heuristics
 assume that the characteristics to be estimated can be expressed in terms of
some mathematical expression.
 Ex.: Function Point, COCOMO
 Analytical
 derive the required results starting from certain simple assumptions.
 Ex.: Halstead’s Software Science
Function Point
 Developed by Allan Albrecht in the late 1970s while working at IBM
 The function point technique was refined and a counting manual was
produced by IBM's GUIDE organization in the early 1980s
 The International Function Point Users Group (IFPUG) was founded in the
late 1980s and produced its own Counting Practices Manual
 The Function Point Counting Practices Manual 4.1 was released in 1999.
 Function Points measure software size by quantifying the functionality
provided to the user based solely on logical design and functional
specifications.
 It is independent of the computer language, development methodology,
technology or capability of the project team used to develop the
application
Function Point Counting Steps
 Determine the type of function point count
 Identify the counting scope and
application boundary
 Determine the Unadjusted Function Point
Count
 Count Data Functions
 Count Transactional Functions
 Determine the Value Adjustment Factor
 Calculate the Adjusted Function Point
Count
Function Point Counting Steps
 Step – 1: Determine the type of function point count
 Development project
 Enhancement project
 Application

 Step – 2: Identify the counting scope and application boundary

 The counting scope defines the functionality which will be included in a
particular function point count.
 The application boundary indicates the border between the software
being measured and the user.
Function Point Counting Steps
 Step – 3: Determine the Unadjusted Function Point (UFP) Count
 The unadjusted function point count (UFP) reflects the specific countable
functionality provided to the user by the project or application.
 The UFP calculation is broken into two categories with five sub-
categories:
 Data Functions
 Internal Logical Files
 External Interface Files
 Transactional Functions
 External Inputs
 External Outputs
 External Inquiries
Function Point Counting Steps
 Step – 3.1: Count Data Function
 Data functions represent the functionality provided to the user to meet
internal and external data requirements
 Data functions are either internal logical files or external interface files.
 An internal logical file (ILF) is a user identifiable group of logically related
data or control information maintained within the boundary of the
application
 An external interface file (EIF) is a user identifiable group of logically
related data or control information referenced by the application, but
maintained within the boundary of another application
 Assign each identified ILF and EIF a functional complexity based on the
number of data element types (DETs) and record element types (RETs)
associated with the ILF or EIF
Function Point Counting Steps
 Step – 3.1: Count Data Function
 Data functions represent the functionality provided to the user to meet
internal and external data requirements
 Data functions are either internal logical files or external interface files.
 An internal logical file (ILF) is a user identifiable group of logically related
data or control information maintained within the boundary of the
application
 An external interface file (EIF) is a user identifiable group of logically
related data or control information referenced by the application, but
maintained within the boundary of another application
 Assign each identified ILF and EIF a functional complexity based on the
number of data element types (DETs) and record element types (RETs)
associated with the ILF or EIF
Function Point Counting Steps
Function Point Counting Steps
 Step – 3.2: Count Transaction Function
 Transactional functions represent the functionality provided to the user to
process data
 Transactional functions are either external inputs, external outputs, or
external inquiries
 An external input (EI) is an elementary process that processes data or
control information that comes from outside the application’s boundary
 An external output (EO) is an elementary process that sends data or control
information outside the application’s boundary
 An external inquiry (EQ) is an elementary process that sends data or control
information outside the application boundary
 Assign each identified EI, EO and EQ a functional complexity based on the
number of file types referenced (FTRs) and data element types (DETs)
Function Point Counting Steps
 Step – 4: Determine the Value Adjustment Factor
 The value adjustment factor (VAF) indicates the general functionality
provided to the user of the application
 The VAF is comprised of 14 general system characteristics (GSCs) that
assess the general functionality of the application
 Each characteristic has associated descriptions that help determine the
degree of influence of the characteristic.
 The degrees of influence range on a scale of zero to five, from no
influence to strong influence
Function Point Counting Steps
 Step – 4: Determine the Value Adjustment Factor
 14 general system characteristics (GSCs)

Data Communications Online Update

Distributed Data Processing Complex Processing
Performance Reusability
Heavily Used Configuration Installation Ease
Transaction Rate Operational Ease
Online Data Entry Multiple Sites
End-User Efficiency Facilitate Change
Function Point Counting Steps
 Step – 4: Determine the Value Adjustment Factor
 Degree of Influence (DI)
 0 Not present, or no influence
 1 Incidental influence
 2 Moderate influence
 3 Average influence
 4 Significant influence
 5 Strong influence throughout
Function Point Counting Steps
 Step – 4: Determine the Value Adjustment Factor
 Evaluate each of the 14 general system characteristics on a scale from zero
to five to determine the degree of influence (DI)
 Add the degrees of influence for all 14 general system characteristics to
produce the total degree of influence (TDI)
 Insert the TDI into the following equation to produce the value adjustment
factor.
VAF = (TDI * 0.01) + 0.65
 For example, the following value adjustment factor is calculated if there are
three degrees of influence for each of the 14 GSC descriptions (3*14)
VAF = (42 * 0.01) + 0.65
VAF = 1.07
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 The adjusted function point count is calculated using a specific formula for a
development project, enhancement project, or application (system baseline)
function point count.
 Development Project Function Point Calculation
DFP = (UFP + CFP) * VAF
 DFP is the development project function point count
 UFP is the unadjusted function point count for the functions that will be available after
installation
 CFP is the unadjusted function points added by the conversion unadjusted function point
count
 VAF is the value adjustment factor
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Application Functionality
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Application Functionality
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Conversion Functionality
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Unadjusted Function Point Count
(Application Contribution)
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Unadjusted Function Point Count
(Conversion Contribution)
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Using the complexity and contribution counts for this example, the
development project count is shown below. The value adjustment factor
for this example is 1.05
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Enhancement Project Function Point Calculation
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL* VAFB)
 EFP is the enhancement project function point count.
 ADD is the unadjusted function point count of those functions that were or will be added by the
enhancement project.
 CHGA is the unadjusted function point count of those functions that were or will be modified by the
enhancement project. This number reflects the size of the functions after the modifications.
 CFP is the function point count of those functions added by the conversion
 VAFA is the value adjustment factor of the application after the enhancement project is complete.
 DEL is the unadjusted function point count of those functions that were or will be deleted by the
enhancement project.
 VAFB is the value adjustment factor of the application before the enhancement project begins.
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Added Functionality

 Changed Functionality
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Deleted Functionality
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Unadjusted Function Point Count
(Added, Changed and Deleted)
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 The application value adjustment factor was 1.05 before the project
began.
 The value adjustment factor remained the same after the project was
completed.
 Using the complexity and contribution counts for this example, the
enhancement project function point count is shown below.
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Use the formula in this section to establish the initial function point count for
an application. Initially, the user is receiving new functionality. There are no
changes to the existing functionality or deletions of obsolete or unneeded
functionality. The application function point count does not include conversion
requirements.
 Establish the Initial Count
AFP = UFP * VAF
 AFP is the initial application function point count.
 UFP is the unadjusted function point count of those functions that were installed by the
development project.
 VAF is the value adjustment factor of the application.
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 calculate the application function point count after an enhancement project:
AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA
 AFP is the application's adjusted function point count.
 UFPB is the application's unadjusted function point count before the enhancement project begins.
 ADD is the unadjusted function point count of those functions that
 were added by the enhancement project.
 CHGA is the unadjusted function point count of those functions that were changed by the
enhancement project. This number reflects the size of the functions after the changes.
 CHGB is the unadjusted function point count of those functions that were changed by the
enhancement project. This number reflects the size of the functions before the changes were made.
 DEL is the unadjusted function point count of those functions that were deleted by the enhancement
project.
 VAFA is the value adjustment factor of the application after the enhancement project is complete.
Function Point Counting Steps
 Step – 5: Calculate the Adjusted Function Point Count
 Initial Count
 The initial application project count is shown below. The value adjustment factor is
1.05
AFP = UFP * VAF
AFP = 115 * 1.05
AFP = 120.75 or 121
 Count after Enhancement
 The application project function point count to reflect enhancements is shown
below. The value adjustment factor is 1.05.
Function Point Example
Function Point Example
Function Point Example
Function Point Example
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 ?.

Empirical Model (COCOMO – I)
 COCOMO (CONSTRUCTIVE COST MODEL)
 First published by Dr. Barry Boehm, 1981
 Also Called as COCOMO’81

 Interactive cost estimation software package that models the cost, effort
and schedule for a new software development activity.
 Can be used on new systems or upgrades

 Derived from statistical regression of data from a base of 63 past

projects
COCOMO Mode & Model
 Three development environments (modes)
 Organic Mode
 Semidetached Mode
 Embedded Mode

 Three increasingly complex models

 Basic Model
 Intermediate Model
 Detailed Model
COCOMO Mode & Model
 Organic Mode
 Developed in familiar, stable environment
 Product similar to previously developed product
 <50,000 DSIs (ex: accounting system)
 Semidetached Mode
 somewhere between Organic and Embedded
 Embedded Mode
 new product requiring a great deal of innovation
 inflexible constraints and interface requirements (ex: real-time systems)
COCOMO Mode & Model
COCOMO Mode & Model
 Basic model
 single-valued, static model that computes software development effort (and cost) as
a function of program size expressed in estimated thousand delivered source
instructions (KDSI).
 Intermediate model
 computes software development effort as a function of program size and a set of
fifteen "cost drivers" that include subjective assessments of product, hardware,
personnel, and project attributes.
 Advanced or detailed model
 incorporates all characteristics of the intermediate version with an assessment of the
cost driver’s impact on each step (analysis, design, etc.) of the software engineering
process.
Basic Model Effort Equation
 Effort = A (size)exponent
 A is a constant based on the developmental mode
 organic = 2.4
 semi = 3.0
 embedded = 3.6
 Size = 1000s Source Lines of Code (KSLOC / KDSI)
 Exponent is constant given mode
 organic = 1.05
 semi = 1.12
 embedded = 1.20
Basic Model Effort Equation
 MTDEV (Minimum time to develop) = 2.5 * (Effort)exponent
 2.5 is constant for all modes
 Exponent based on mode
 organic = 0.38
 semi = 0.35
 embedded = 0.32
 Note: MTDEV does not depend on number of people assigned.
Basic Model Effort Equation
 When effort and development time are known, the average staff
size to complete the project may be calculated as:
𝐸𝑓𝑓𝑜𝑟𝑡
Average Staff Size (SS) = Persons
𝑀𝑇𝐷𝐸𝑉
 When project size is known, the productivity level may be
calculated as:
𝑆𝑖𝑧𝑒
Productivity (P) = KLOC/PM
𝐸𝑓𝑓𝑜𝑟𝑡
Basic COCOMO assumptions
 Implicit productivity estimate
 Organic mode = 16 LOC/day
 Embedded mode = 4 LOC/day

 Time required is a function of total effort NOT team size

 Not clear how to adapt model to personnel availability
Basic COCOMO Example
Suppose that a project was estimated to be 400 KLOC. Calculate
the effort and development time for each of the three modes i.e.,
organic, semidetached and embedded.
Basic COCOMO Example
Solution:
Effort = A (size)exponent
MTDEV = 2.5 * (Effort)exponent
Organic Mode
Effort = 2.4 (400)1.05 = 1295.31 PM
MTDEV = 2.5(1295.31)0.38 = 38.07 Months
Semidetached Mode
Effort = 3.0 (400)1.12 = 2462.79 PM
MTDEV = 2.5(2462.79)0.35 = 38.45 Months
Embedded Mode
Effort = 3.6 (400)1.20 = 4772.81 PM
MTDEV = 2.5(4772.81)0.32 = 38 Months
Basic COCOMO Example
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.
Basic COCOMO Example
Solution:
The semi-detached mode is the most appropriate mode; keeping in view the size,
schedule and experience of the development team.

Semidetached Mode
Effort = 3.0 (200)1.12 = 1133.12 PM
MTDEV = 2.5(1133.12)0.35 = 29.3 Months
1133.12
Average Staff Size (SS) = = 38.67 Persons
29.3
𝐾𝐿𝑂𝐶 200
Productivity = = = 0.1765 KLOC/PM
𝐸𝑓𝑓𝑜𝑟𝑡 1133.12
= 176 LOC/PM
Intermediate COCOMO
 Takes basic COCOMO as starting point
 Identifies personnel, product, computer and project attributes
which affect cost and development time.
 Multiplies basic cost by attribute multipliers which may increase or
decrease costs
 Intermediate COCOMO
 Personnel attributes  Computer attributes
 Analyst capability  Execution time constraints
 Virtual machine experience  Storage constraints
 Programmer capability  Virtual machine volatility
 Programming language experience
 Computer turnaround time
 Application experience

 Product attributes  Project attributes

 Reliability requirement  Modern programming practices
 Database size  Software tools
 Product complexity  Required development schedule
Intermediate COCOMO
 Effort = EAF * A (size)exponent
 EAF (effort adjustment factor) is the product of effort multipliers
corresponding to each cost driver rating
 A is a constant based on the developmental mode
 organic = 3.2
 semi = 3.0
 embedded = 2.8
 Size = 1000s Delivered Source Instruction (KDSI)
 Exponent is constant given mode (same as Basic COCOMO)
Intermediate COCOMO (Cost Drivers)
Intermediate COCOMO (Cost Drivers)
Intermediate COCOMO Example
A new project with estimated 400 KLOC embedded project has to be
developed. Project manager has a choice of hiring from two pools of
developers:
Very highly capable with very little experience in the programming
language being used.
Or
Developers of low quality but a lot of experience with the programming
language.

What is the impact of hiring all developers from one or the other pool ?
Intermediate COCOMO Example
Solution:
This is the case of embedded mode and model is intermediate COCOMO.
Embedded Mode
CASE – I: Developers are very highly capable with very little experience in
the programming being used.
EAF = 0.82 x 1.14 = 0.9348
Effort = 0.9348 x 2.8 (400)1.20 = 3470 PM
MTDEV = 2.5(3470)0.32 = 33.9 Months
Intermediate COCOMO Example
Solution:
Embedded Mode
CASE – II: Developers are of low quality but lot of experience with the
programming language being used.
EAF = 1.29 x 0.95 = 1.22
Effort = 1.22 x 2.8 (400)1.20 = 4528 PM
MTDEV = 2.5(4528)0.32 = 36.9 Months

Case II requires more effort and time. Hence, low quality developers with lot of
programming language experience could not match with the performance of very
highly capable developers with very litter experience.
COCOMO Family
 COCOMO 81, Revised Enhanced Version of Intermediate
COCOMO (REVIC), and COCOMO II
 COCOMO 81
 15 cost drivers
 REVIC
 Developed by Mr Raymond Kile, Hughes Aerospace
 Uses PERT statistical method to determine SLOCs
 PC compatible
 The latest version of AFCAA REVIC is 9.2 released in 1994.
COCOMO Family
 COCOMO II
 Sensitivity analysis and calibration very important
 17 cost drivers
 In 1995 COCOMO II was developed and finally published in 2000 in
the book Software Cost Estimation with COCOMO II
 Accuracy based on 89 projects
COCOMO - II
 COCOMO 81 was developed with the assumption that a waterfall process
would be used and that all software would be developed from scratch.
 Since its formulation, there have been many changes in software engineering
practice and COCOMO II is designed to accommodate different approaches to
software development.
COCOMO - II
 COCOMO - II incorporates a range of sub-models that produce increasingly
detailed software estimates.
 The sub-models in COCOMO - II are:
 Application composition model - Used when software is composed from
existing parts.
 Early design model - Used when requirements are available but design has
not yet started.
 Reuse model - Used to compute the effort of integrating reusable
components.
 Post-architecture model - Used once the system architecture has been
designed and more information about the system is available.
COCOMO - II
Application Prototype systems
Number of Based on Used for developed using
application points composition model scripting, DB
programming etc.

Based on Used for Initial effort

Number of function Early design model estimation based on
points system requirements
and design options

Number of lines of Based on Used for Effortto integrate

code reused or Reuse model reusable components
generated or automatically
generated code

Number of lines of Based on Post-architecture Used for Development effor t

source code model based on system
design specification
COCOMO - II
 Application Composition Estimation Model
COCOMO - II
 Application Composition Estimation Model
COCOMO - II
 Application Composition Estimation Model
COCOMO - II
 Application Composition Estimation Model
COCOMO - II
 Application Composition Estimation Model
COCOMO - II
 Application Composition Estimation Model
COCOMO - II
 Application Composition Estimation Model
COCOMO – II Example
Consider a database application project with the following characteristics:
 I. The application has 4 screens with 4 views each and 7 data tables for 3
servers and 4 clients.
 II. The application may generate two report of 6 sections each from 07 data
tables for two server and 3 clients.
 III. There is 10% reuse of object points.
The developer’s experience and capability in the similar environment is low. The
maturity of organization in terms of capability is also low.
Calculate the object point count, New object points and effort to develop such a
project.
COCOMO – II Example
This project comes under the category of application composition estimation model.
Number of screens = 4 with 4 views each
Number of reports = 2 with 6 sections each
From complexity table, we know that each screen will be of medium complexity
and each report will be difficult complexity.
Using complexity weights table, we may calculate
object point count = 4 x 2 + 2 x 8 = 24

24 ∗(100 −10)
NOP = 100
= 21.6
COCOMO – II Example
Low value of Productivity (PROD) is 7

𝑁𝑂𝑃 21.6
Efforts in PM = 𝑃𝑅𝑂𝐷 = 7
= 3.086 PM
Project Scheduling
 Scheduling is an important activity for the project managers.
 To determine project schedule:
 Identify tasks needed to complete the project.
 Determine the dependency among different tasks.
 Determine the most likely estimates for the duration of the identified
tasks.
 Plan the starting and ending dates for various tasks.
Project Scheduling
 Key Steps:
 Project Scope and Requirements
 Work Breakdown Structure (WBS)
 Task Estimation
 Determine Task Dependencies
 Task Prioritization
 Allocate Resources
 Develop a Project Schedule
 Identify Critical Path
Work Breakdown Structure
 Work Breakdown Structure (WBS) provides a notation for
representing task structure:
 Activities are represented as nodes of a tree.
 The root of the tree is labelled by the problem name.
 Each task is broken down into smaller tasks and represented as
children nodes.
 A WBS is arranged in a hierarchy and constructed to allow for
clear and logical groupings, either by activities or deliverables.
Work Breakdown Structure
 Example
Work Breakdown Structure
 Example
 Hierarchical Levels – contains three levels of work
 Numbering Sequence – uses outline numbering as a unique identifier for all
levels
 Level one is 1.0, which illustrates the project level.
 Level two is 1.X (1.1, 1.2, 1.3, etc.), which is the summary level, and often the level at
which reporting is done.
 Level three is 1.X.X (1.1.1, 1.1.2, etc.), which illustrates the work package level. The
work package is the lowest level of the WBS where both the cost and schedule can be
reliably estimated.
 Lowest Level Descriptions – expressed using verbs and objects, such as
“make menu.”
Work Breakdown Structure
 Three Types of WBS Structures
 Product
 Process / Service
 Result / Outcome
Work Breakdown Structure
 Product WBS
 Decomposition of the Natural, Physical Structure of the Deliverable
 The Deliverable is a Tangible Product
Work Breakdown Structure
 Process / Service WBS
 No Tangible Output Product
 Main Event or “Service”
 Decomposition Based on a Logical Grouping (not Physical Structure)
 Often Developed Bottom-up
 Detailed Activities May be Checklists
 Lend Themselves to Templates
Work Breakdown Structure
 Process / Service WBS
Work Breakdown Structure
 Result / Outcome WBS
 Project Does not have a Well-Structured Primary Product as a
Deliverable
 May Have Several Products that Collectively Achieve the Planned
“Result”
Work Breakdown Structure
 Result / Outcome WBS
Work Breakdown Structure
 WBS is The Basis For......
 Cost estimates and budgets.
 Milestones & schedules.
 Responsibility assignment.
 Allocation of resources.
 Schedule horizontal and vertical traceability.
 Risk analysis.
 Concurrence of participants.
 Integrating the total project effort.
 Summarizing costs, schedules, performance.
 Forcing the Project Manager to think through all elements of the project.
Work Breakdown Structure
 Methodology
 Top-Down
 Bottom- Up
 Analogy
 Mind Mapping
Project Scheduling
 Project network representation involves using diagrams to
visualize the flow of activities in a project.

 In the network diagram, each activity must start at the node in

which its immediate predecessors ended.
Project Scheduling
 There are two main methods for representing project networks:
 Activity-on-Node (AON)
 Activity-on-Arc (AOA)
Project Scheduling
 There are two approaches to plan, schedule, and control large,
complex projects with many activities.
 Critical Path Method (CPM)
 Deterministic/Known Activity Duration
 Program Evaluation and Review Technique (PERT)
 Probabilistic/Uncertain Activity Duration
Project Scheduling
 Queries addressed by CPM / PERT
 Starting and Completion time of each activity
 Total time required to complete the project
 Identify critical activities
 Delay for Non-critical activities

 Additional Queries addressed using PERT

 Probability of project completion for a given time frame
 Variability in the project completion time
Project Scheduling
 Sample Problem
Project Scheduling
 Activity Network / Network Diagram
Project Scheduling
 Key Terminologies
 Earliest Start time (ES) – The earliest time at which an activity can start if no
delays occur in the project;
 Earliest Finish time (EF) – The earliest time at which an activity can finish if
no delays occur in the project;
 The EF is computed as (ES of the activity + Duration of the activity)
 Latest Start time (LS) - The latest time at which an activity can finish without
delaying the completion of the project.
 Latest Finish time (LF) - The latest time at which an activity can finish without
delaying the completion of the project.
 The LS is computed as (LF of the activity – Duration of the activity)
Project Scheduling
 Key Terminologies
 Forward Pass – Traverse from starting node to finish node. This path is used
to compute ES and EF
 Backward Pass – Traverse from finish node to start node. This path is used to
compute LS and LF
 Slack Time – It refers to the length of time that can be tolerated without
incurring a delay in the scheduled project completion time. It is computed as
either (LS – ES) or (LF – EF).
 If slack time of an activity is computed as Zero (0), then the activity is
termed as Critical Activity. If any deviation in schedule is observed for
critical activity, it will impact the overall completion of schedule of the
project.
Project Scheduling
 Activity Network / Network Diagram
Project Scheduling
 Compute Critical Path
Project Scheduling
 Compute Critical Path
Project Scheduling
 Project Duration and Critical Activity
 Hence, the critical activities are
T2, T4, T7, T9, T10

 The critical path is calculated as

T2  T4  T7  T9  T10

 The project completion time is 59 weeks.

 If required, the activities T1, T3 and T6 can be delayed, since they have
largest slack times.
Project Scheduling
 Project Duration and Critical Activity
 Hence, the critical activities are
T2, T4, T7, T9, T10

 The critical path is calculated as

T2  T4  T7  T9  T10

 The project completion time is 59 weeks.

 If required, the activities T1, T3 and T6 can be delayed, since they have
largest slack times.
Project Scheduling
 Project Scheduling with Probabilistic Activity Durations
 The CPM approach assumes that the duration of activities are known with certainty and
the actual duration will turn out to be exactly as estimated.
 However, in practice this is not always possible and many projects involve variability in
activity times due to factors such as lack of prior experience, equipment breakdown,
unpredictable weather conditions, late delivery of supplies, and others.
 PERT analysis is used when the duration of activities are not known with certainty.
 PERT (Program Evaluation and Review Technique) is a variation of CPM:
 incorporates uncertainty about duration of tasks.
 Gantt charts can be derived automatically from PERT charts.
 Gantt chart representation of schedule is helpful in planning the utilization of resources,
while PERT chart is more useful for monitoring the timely progress of activities.
Project Scheduling
 Project Scheduling with Probabilistic Activity Durations
 It involves three types of estimates of the duration of an activity instead of one
single value as in the case of CPM.
 The optimistic duration a = the time an activity will take under the most
favourable conditions.
 The pessimistic duration b = the time an activity will take under the most
unfavourable conditions.
 The most likely duration m = the most realistic time an activity will require to be
completed, that is, the time an activity will take under normal conditions.
Project Scheduling
 Project Scheduling with Probabilistic Activity Durations
Project Scheduling
 Project Scheduling with Probabilistic Activity Durations
WHAT IS THE PROBABILITY OF COMPLETING THE PROJECT WITHIN 46 WEEKS?

 The approach consists of converting X into a standard normal distribution and

determining the area under the normal curve.

 To that end the z value is computed as follows,

Project Scheduling
 Project Scheduling with Probabilistic Activity Durations
Project Scheduling
 Project Scheduling with Probabilistic Activity Durations

WHAT IS THE PROBABILITY OF COMPLETING THE PROJECT WITHIN 46 WEEKS?

Agile Project Management
 The standard approach to project management is plan-driven.
 A plan-based approach really requires a manager to have a stable
view of everything that has to be developed and the development
processes.
 However, it does not work well with agile methods where the
requirements are developed incrementally; where the software is
delivered in short, rapid increments; and where changes to the
requirements and the software are the norm.
 Agile development requires a different approach to project
management, which is adapted to incremental development and the
particular strengths of agile methods.
Agile Project Management
 To address this issue, the Scrum agile method was developed to
provide a framework for organizing agile projects and, to some
extent at least, provide external visibility of what is going on.
 The developers of Scrum wished to make clear that Scrum was
not a method for project management in the conventional sense,
so they deliberately invented new terminology, such as
ScrumMaster, which replaced names such as project manager.
 Scrum can be more easily integrated with existing practice in a
company
Agile Project Management
Estimation for Agile Development
 Because the requirements for an agile project are defined by a set of
user scenarios (e.g., “stories” in Extreme Programming), it is possible to
develop an estimation approach that is informal, reasonably
disciplined, and meaningful within the context of project planning for
each software increment.
 Estimation for agile projects uses a decomposition approach that
encompasses five steps.
 This estimation approach serves two purposes:
a) To be certain that the number of scenarios to be included in the increment
conforms to the available resources
b) To establish a basis for allocating effort as the increment is developed.
Estimation for Agile Development
1) Each user scenario (the equivalent of a mini use case created at the very start
of a project by end users or other stakeholders) is considered separately for
estimation purposes.
2) The scenario is decomposed into the set of software engineering tasks that will
be required to develop it.
3) Task and Volume Estimation
a) Each task is estimated separately. Note: Estimation can be based on
historical data, an empirical model, or “experience.”
b) Alternatively, the “volume” of the scenario can be estimated in LOC, FP, or
some other volume-oriented measure (e.g., use case count).
Estimation for Agile Development
3) Scenario and Effort Estimation
a) Estimates for each task are summed to create an estimate for the scenario.
b) Alternatively, the volume estimate for the scenario is translated into effort
using historical data.
4) The effort estimates for all scenarios that are to be implemented for a given
software increment are summed to develop the effort estimate for the
increment.
 Disclaimer
The material for the presentation has been compiled
from various sources such as prescribed text books by
Roger S pressman and Ian Sommerville and other
tutorials and lecture notes. The information contained
in this lecture/ presentation is for educational purpose
only.
Thank You for Your Attention !