Software Project

Management
SIS 3104 Software Engineering
Topics
● Project management activities
● Project planning
● Project size estimation techniques
● Project scheduling
● Risk management

Software Project Management

● Software project management is concerned with activities
involved in ensuring that software is delivered on time and
on schedule and in accordance with the requirements of
the organizations developing and procuring the software
● Project management is needed because software
development is always subject to budget and schedule
constraints that are set by the organization developing the
software.

What make software PM different?

● The product is intangible
○ Software cannot be seen or touched. Software project managers cannot see
progress by simply looking at the artifact that is being constructed.
● Many software projects are 'one-off' projects
○ Large software projects are usually different in some ways from previous
projects. Even managers who have lots of previous experience may find it
difficult to anticipate problems.
● Software processes are variable and organization specific.
 ○ We still cannot reliably predict when a particular software process is likely to
lead to development problems.

Software Project success criteria

● Deliver the software to the customer at the agreed time.

● Keep overall costs within budget.

● Deliver software that meets the customer's expectations.

● Maintain a happy and well-functioning development team.

Roles of a project manager
● Steer project to success
○ Proposal writing
○ Project cost estimation
○ Project planning, scheduling, staffing ○
Software process tailoring
○ Software configuration management
○ Risk management
○ Interfacing with clients
○ Managerial report writing and presentations e.t.c
● Broadly project planning and project monitoring and control activities
Project planning
● Usually Undertaken and completed before any development starts.

● Practically continuous from initial concept through to system delivery.

● Plans must be regularly revised as new information becomes available.

● Involves several activities

Project planning activities
● Estimating the project size, cost, duration and effort

● Scheduling manpower and other resources

 ● Staff organization and staffing plans

● Risk identification and analysis

● Miscellaneous plans such as quality assurance plan, configuration management

plan, e.t.c.

Software project estimation metrics

● Accurate estimation of problem size is fundamental to satisfactory estimation of
effort, time duration and cost of a software project.

● Project size is a measure of the problem complexity in terms of the effort and
time required to develop the product.
● Two popular metrics in use:
○ Lines of code (LOC)
○ Function point (FP)

Lines of code
● Simplest method
● Count number of source instructions in the developed program
● Ignore comments and headers
● Not easy to accurately estimate at project start
● Need to modularize the project
● Relies a lot on past experience in developing similar projects
Function point (FP)
● Easy to specify project size right from the specification
● Size of the software is directly dependent on the number of different functions
or features it supports.
● Software product with many features is then larger than one with less
● Computed in two steps
○ Compute unadjusted function point (UFP)
○ Then compute technical complexity factor (TCF) or commonly known as Complexity Adjustment
Factor (CAF)
○ FP = UFP * CAF
● Doesn’t account for algorithmic complexity of the software
Unadjusted Function Point
●
External Data Source

ELF EI EO EQ

EI

EO
ILF
ILF
EQ
Users
UFP computation
● Number of external inputs (EI): count each data item input by the user.
● Number of external outputs (EO): these refer to reports printed, screen outputs,
error messages, e.t.c
● Number of external inquiries (EI): distinctive interactive queries made by the
user e.g print-account-balance
● Number of internal logical files (ILF): count each logical file.
● Number of external logical interfaces (ELI): used to exchange information with
other systems e.g communication links with other systems

● UFP = (EI)*4 + (EO)*5 + (EQ)*4 + (ILO)*10 + (ELI)*10

 ● The constants represent the complexity levels e.g complexity level 4 for number
of inputs indicates average complexity.

Counting Function Points

● Each function unit can have its complexity weighted as presented in the table
below
Function Units Low Average High
EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10
CAF = 0.65 + ( 0.01 * F )
CAF = 0.65 + ( 0.01 * F )
Complexity Adjustment Factor
● Scale varies from 0 to 5 according to character of Complexity Adjustment
Factor (CAF). Below table shows scale:
○ 0 - No Influence
○ 1 - Incidental ○ 2
- Moderate
○ 3 - Average
○ 4 - Significant ○ 5
- Essential

● CAF = 0.65 + ( 0.01 * F )

○ Where F = 14 * scale
Example
● Given the following values, compute function point when all complexity
adjustment factor (CAF) and weighting factors are average.
○ User Input = 50

○ User Output = 40

○ User Inquiries = 35

○ User Files = 6

○ External Interface = 4

Example solution…
● As complexity adjustment factor is average (given in question), hence,
○ scale = 3. ○ F = 14

* 3 = 42
● CAF = 0.65 + ( 0.01 * 42 ) = 1.07
● As weighting factors are also average (given in question) hence we
will multiply each individual function point to corresponding values in TABLE
(slide 14).
● UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
● Function Point = 628 * 1.07 = 671.96

Project estimation techniques

● Important parameters to estimate are
○ Project size
○ Effort required to develop the software
○ Project duration
○ Cost
● 3 broad categories of estimation techniques
○ Empirical estimation techniques ○ Heuristic techniques
 ○ Analytical estimation techniques

Empirical estimation techniques

● Make educated guess of the project parameters
● Expert judgement technique
○ An expert makes an educated guess after analyzing the problem thoroughly
○ Estimates cost of different components and combines get total.
○ Subject to human errors
● Delphi cost estimation
○ Carried out by a team comprising a group of experts and a coordinator
○ Each gets copy of srs and a form to record estimate.
○ Coordinator collects and forms a summary then reshares for re-estimation
○ Several iterations
○ Coordinator prepares final estimate
Heuristic techniques
● Assume relationships among parameters can be modelled using mathematical
expressions
● Analytical estimation techniques – Halstead’s software science
○ Useful for estimating maintenance efforts

● COCOMO model – general software cost estimation for organic, semidetached

and embedded software projects
○ Organic –if project deals with well understood application program, small team size, and
experienced team members
○ Semidetached – if project has mixture of experienced and inexperienced staff
○ Embedded – if software is strongly coupled to complex hardware or if stringent regulations on
operational procedures exist.
Basic COCOMO model
● Effort = a(KLOC)b
● Tdev = c(Effort)d
Software Projects
a b c d

Organic 2.4 1.05 2.5 0.38

Semi Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Basic COCOMO model

● Estimation of development effort
○ Organic: Effort = 2.4(KLOC)1.05 PM
 ○ Semi-detached: Effort = 3.0(KLOC)1.12 PM
○ Embedded: Effort = 3.6(KLOC)1.20 PM

● Estimation of development time

○ Organic: Tdev = 2.5(Effort)0.38 Months
○ Semi-detached: Tdev = 2.5(Effort)0.35 Months ○
Embedded: Tdev = 2.5(Effort)0.32 Months

Example
● 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 1,500,000/= per month. Determine the effort required to develop
the software product and the nominal development time. ● From the COCOMO
estimation formula for organic software:
○ Effort = 2.4 x (32)1.05 = 91 PM
 ○ Development time = 2.5 x (91)0.38 = 14 months
○ Cost required = 14 x 1,500,000

Project scheduling
● Involves deciding which tasks will be taken up when
○ Identify all the tasks to complete project – requires good knowledge of the project development
process
○ Breakdown large tasks into small activities – work breakdown structure
○ Determine dependency among activities – determine order of execution using activity network
diagram
○ Establish most likely time estimates for the tasks – can be part of the activity network
representation
○ Allocate resources to activities – done using gantt chart
○ Plan starting and end dates for various activities
○ Determine the critical path: chain of activities that determines the duration of the project.
Milestones and deliverables
● Milestone is the end-point of each project activity
● Used to track progress of a project
○ Monitor timely completion of milestones

● Deliverables are work products / project results that are delivered to the
customer e.g. SRS

Work breakdown structure

● Used to decompose a given task set recursively into small activities

● Representation of major tasks for problem solving

● Root of tree is the problem name

 ● Breakdown each activity into smaller sub-activities that require approx. 2 weeks
to develop.
Work breakdown structure of an MIS software
MIS Application

SRS Design Code Test Document

Database Part GUI Part Database Part GUI Part

Critical Path method
● Can provide insight on how to plan prjects, allocate resources and schedule
tasks
● Why you should use it:
○ Improves future planning – compare expectations with actual progress
○ Facilitates more effective resource management – thru task prioritization
○ Helps avoid bottlenecks – from lost valuable time

● Assign start and end time for each activity

● Sequence of activities with the longest duration is the critical path
Determining critical path
Consider the table below. Develop the activity diagram or network diagram
Determining critical path
Derived network diagram
Gantt chart
● Used to allocate resources to activities

● Useful for resource planning

● Special type of bar chart with each bar representing an activity

PERT chart
● Project Evaluation and Review Technique (PERT) is a network of boxes and
arrows

● Makes three estimates for each activity: pessimistic (P), most likely (M) and
optimistic (O) estimates
● Estimated time = (O + 4M + P)/6

● PERT is used to estimate time required to complete activities while CPM is used
when the activity durations are already estimated.

Risk Management – categories of risk

● Project risks
○ Budgetery, schedule, personnel, resource and customer related ○ Schedule slippage

● Technical risks
○ Concern potential design, implementation, interfacing, testing and maintenance problems.
○ Ambiguous, incomplete, changing specification
○ Caused due to developers’ insufficient knowledge about the project
● Business risks
○ Risk of building an excellent product that no one wants
○ losing personnel commitments
Risk assessment
● Objective is to rank the risks in terms of their damage causing
potential ● Rate in two ways
○ Likelihood of risk coming true (r)
○ The consequence of problems associated with the risk (s) ○ Priority
=r*s

Risk containment
● Plans to contain the most damaging and most likely risks

● Strategies for risk containment include

○ Avoid the risk:- reduce scope of work, incentives to developers e.t.c

○ Transfer the risk:- get the risk component developed by third party, buy insurance cover, etc.
 ○ Risk reduction:- e.g if there is risk that some key personnel might leave, plan new recruitment.

Configuration Management
● Large software consists of many deliverables along the development process
● E.g code, SDD, SRS, test document….
● Usually modified by many stakeholders throughout the process
● Their state at any time is called the configuration of the software product
● Configuration management (CM) helps control access to those deliverables

CM – problems incurred if not used

● Inconsistency problem when deliverables are replicated

● Problems associated with concurrent access

● Providing a stable development environment

● System accounting and maintaining status information

● Handling variants