Software Engineering

Project Management & Estimation

Course Supervisor: Ms. Hadiqua Fazal

Bahria University
Karachi Campus
Chapter-24: Project Management

• Objectives
– SPM
– Team organization
– Project management Activities
– Risk Management
– Software metrics
– Summary
 Project
• Definition: A group of tasks performed in a
definable time period in order to meet a
specific set of objectives
• Project Features:
– likely to be unique (one-time program)
– have specific start and end time (life cycle)
– have work scope that can be categorized into
definable tasks
– has a budget, require use of resources

3
 The Four P’s
• People — the most important element of a
successful project
• Product — the software to be built
• Process — the set of framework activities and
software engineering tasks to get the job done
• Project — all work required to make the
product a reality

4
 Software Teams
How to lead?
How to organize?
How to collaborate?

How to motivate? How to create good ideas?

5
 A Simple Project

“Plan for a friendly match”

People ?
Product ?
Process ?

6
 Management

• The planning, organizing, staffing, directing

and controlling of a company’s resources to
meet the company’s objectives

7
Definition of Project Management

• The planning, organizing, directing, and

controlling of resources for a specific time
period to meet a specific set of one-time
objectives

8
 Software Teams
The following factors must be considered when
selecting a software project team structure ...
• the difficulty of the problem to be solved
• the size of the resultant program(s) in lines of code or function
points
• the time that the team will stay together (team lifetime)
• the degree to which the problem can be modularized
• the required quality and reliability of the system to be built
• the rigidity of the delivery date
• the degree of sociability (communication) required for the
project
9
 Assembling a team
• May not be possible to appoint the ideal people to work on a
project
– Project budget may not allow for the use of highly-paid staff;
– Staff with the appropriate experience may not be available;
– An organisation may wish to develop employee skills on a software
project.
• Managers have to work within these constraints especially when
there are shortages of trained staff.

Chapter 22 Project management 10

 Groupcomposition
In creating a group for assistive technology development, Alice is aware of the
importance of selecting members with complementary personalities. When interviewing
potential group members, she tried to assess whether they were task-oriented, self-
oriented, or interaction-oriented. She felt that she was primarily a self-oriented type
because she considered the project to be a way of getting noticed by senior
management and possibly promoted. She therefore looked for one or perhaps two
interaction-oriented personalities, with task-oriented individuals to complete the team.
The final assessment that she arrived at was:

Alice—self-oriented
Brian—task-oriented
Bob—task-oriented
Carol—interaction-oriented
Dorothy—self-oriented
Ed—interaction-oriented
Fred—task-oriented

Chapter 22 Project management 11

 Activity or set of activities that
span the duration of the
Project Project
For instance :
Project management
Documentation , Training
Quality Control (Verification and validation)
Configuration Management

Smallest unit of work subject to

management

Small enough for adequate planning

and tracking

Large enough to avoid micro management

Write user manual , Write meeting minutes and post them
 Project Management Activities

• Establish project objectives

• Defining work requirement
• Determining work timing
• Establishing resource availability and
requirements
• Establishing a cost baseline
• Evaluating and optimising the baseline plan

13
 Project Management Activities
(Continued)

• Freezing the baseline plan

• Tracking the actual costs
• Comparing the progress and cost to the
baseline plan
• Evaluating performance
• Forecasting, analysing and recommending
corrective action

14
 The Process
• Once a process framework has been established
– Consider project characteristics
– Determine the degree of rigor required
– Define a task set for each software engineering
activity
• Task set =
– Software engineering tasks
– Work products
– Quality assurance points
– Milestones

15
 The Project
• Projects get into trouble when …
– Software people don’t understand their customer’s needs.
– The product scope is poorly defined.
– Changes are managed poorly.
– The chosen technology changes.
– Business needs change [or are ill-defined]. 
– Deadlines are unrealistic.
– Users are resistant.
– Sponsorship is lost [or was never properly obtained].
– The project team lacks people with appropriate skills.
– Managers [and practitioners] avoid best practices and lessons
learned.
Project Management Concerns
product quality?
risk assessment?
measurement?
cost estimation?
project scheduling?
customer communication?
staffing?
other resources?
project monitoring?
 To Get to the Essence of a Project
• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be done technically and
managerially?
• How much of each resource (e.g., people,
software, tools, database) will be needed?

Barry Boehm [Boe96]

 Resources of A Company
• Money
• Manpower
• Equipment
• Facilities
• Materials
• Information/technology
 Project Management Skills
• Communication Skills
• Organizational Skills
• Team Building Skills
• Leadership Skills
• Coping Skills
• Technological Skills
 Project Plan Elements
• Project Objective & Scope
• Schedule
• Team Organization
• Project Standards and Procedures
• Documentation Plan
• Quality Assurance Plan
• Resource Management Plan
• Configuration Management Plan
 Examples of common project,
product, and business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it
is finished.
Management change Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been underestimated.

CASE tool Product CASE tools, which support the project, do not
underperformance perform as anticipated.
Technology change Business The underlying technology on which the system
is built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
22
 The 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
– Monitor the risks throughout the project;

23
The risk management process

24
 Organizational Paradigms
random paradigm—structures closed paradigm—structures a
a team loosely and depends team along a traditional
on individual initiative of the hierarchy of authority.
team members
 Project Planning and Control
System
Goals/ Work Description Network
Objectives and Instructions Scheduling

Management Master/
Decision- Detailed
Making Schedules

Time/Cost/
System
Performance Budgets
Reports
Tracking

26
 Hierarchical Planning System
1. Goals must be specified.
2. Identifying the set of required activities to
achieve the goals.
3. Each activities and events can be
decomposed into sub-activities and sub-
events.

27
 Planning Steps
1. Establish objectives
2. Develop a plan
3. Construct project planning diagram
4. Identify timing duration of each activity in
planning diagram
5. Identify costs and labor/personnel
associated with each activity

28
 Establish Objectives
• State objectives
– Project start/end dates
– Budgets
– Technical results
• List milestones
• Milestone: a scheduled event for which some person
is held accountable and which is used to measure
and control progress.
• Designate responsible personnel to meet objectives

29
 Develop A Plan
• List activities
• Develop Work Breakdown Structure (WBS): The WBS
reflects the decomposition of a project into subtasks
down to the level for effective planning and control.
• Determine relationships of activities
– job precedence/succession
– concurrent jobs

30
Manageable WBS Example
Integrateable
Level 1
ABC Project

Level 2

Definition Analysis Design Programming ...

Level 3

Requirements Feasibility ...

Risk Analysis
Documentation Study

Measureable
Independent 31
 WBS of a simple project
Project

Design Test Code Test

plan

Code A Code B

•Each activity has a duration and consumes resources.

•Each activity has a constraint(example: one must be
finished before the other starts; so activities are
executed in order).
 Example of WBS: “Holiday”

holiday

travel
documents booking household

choose
passport tickets confirm cat!
resort

insurance brochures

33
 List of activities

•Booking:
• get brochures •Household:

• choose resort • feeding the cat!

• make booking •This is a simple

• confirm booking example:

•Travel documents: • inoculations

• check passport • visas

• book tickets • travel money

• get insurance • etc.

34
 Program Evaluation and Review
Technique (PERT) diagram
Test plan
10

Design Code A 18
Test 15
15

Code B 18

•The numerical number represents the duration

of each activity.
•PERT is mainly concerned with time of each
activity and interrelations among activities.
35
Activity-on-Arrow (AOA) Diagram
D
2 5
A G
E
B
1 3 6

C
4

Each activity has only one arrow associated

with it.
 Activity Precedence

Activity Immediate Duration

Predecessor
A - 2
B - 1
C - 3
D A 2
E B,C 4
F C 5
G D,E 3
 Critical Path Method (CPM)

• By drawing a network diagram, you can figure out

the critical path of your project.
• The critical path is the longest path through the
network. If something falls behind schedule on the
critical path, the whole project falls behind schedule
unless time is made up elsewhere.
• It’s easier to adjust other activities (allocate
more/less resources) when you know the
interdependencies of activities

39
 Terms
• Activity - A task or job which takes time & use up
resources
Represented by labeled arrow A
• Event - An instantaneous point representing the start or
finish of an activity Represented by node 1
• Slack time: indicates that the corresponding activity may
consume more than its estimated time, or start later than
the earliest possible start time, without affecting the
total duration of the project.
• Critical path: a path that has activities without any slack
time

40
 What is Scope?
• Software scope describes
– the functions and features that are to be delivered to end-
users
– the data that are input and output
– the “content” that is presented to users as a consequence of
using the software
– the performance, constraints, interfaces, and reliability that
bound the system.
• Scope is defined using one of two techniques:
• A narrative description of software scope is developed after
communication with all stakeholders.
• A set of use-cases is developed by end-users.

41
 Problem Decomposition
• Sometimes called partitioning or problem
elaboration
• Once scope is defined …
– It is decomposed into constituent functions
– It is decomposed into user-visible data objects
or
– It is decomposed into a set of problem classes
• Decomposition process continues until all
functions or problem classes have been defined

42
 Project Estimation

• Project scope must be understood

• Elaboration (decomposition) is
necessary
• Historical metrics are very helpful
• At least two different techniques
should be used
• Uncertainty is inherent in the
process

43
 A Good Manager Measures
process
process metrics

project metrics
measurement
product metrics

product
What do we
use as a
basis?
• size?
• function?

44
 Software Process Improvement
Process model

Process improvement
Improvement goals recommendations

Process metrics
SPI

45
 Why Do We Measure?
• assess the status of an ongoing project
• track potential risks
• uncover problem areas before they go “critical,”
• adjust work flow or tasks,
• evaluate the project team’s ability to control
quality of software work products.

46
 Principles of Measurement
“You Cannot Control What You Cannot Measure”

➜ Good metrics are:

• simple (to collect and interpret)
• valid (measure what they purport to measure)
• robust (insensitive to manipulation)
• prescriptive
• analyzable
➜ 5 types of scale
• nominal (=, ≠ make sense; discrete categories)
• ordinal (<, >, =, make sense; e.g. oven temps: cool, warm, hot, very
hot)
• interval (+, -, <, >, = make sense; e.g. temperature in centigrade)
• ratio (x, ÷, +, -, <, >, = make sense; e.g. temperature in Kelvin)
• absolute (a natural number count)
 Some suggested metrics
• Plot planned and actual staffing levels over time
• Record number & type of code and test errors
• Plot number of resolved & unresolved problem
reports over time
• Plot planned & actual number of units whose V&V is
completed over time:
a) design reviews completed
b) unit tests completed
c) integration tests completed
Plot software build size over time
• Plot average complexity for the 10% most complex
units over time
(using some suitable measure of complexity)
• Plot new, modified and reused SLOCs over time
SLOC = Source Lines Of Code
• Plot estimated schedule to completion based on
deliveries achieved
 Typical Project Metrics
• Effort/time per software engineering task
• Errors uncovered per review hour
• Scheduled vs. actual milestone dates
• Changes (number) and their characteristics
• Distribution of effort on software
engineering tasks
 Process Metrics
• Quality-related
– focus on quality of work products and deliverables
• Productivity-related
– Production of work-products related to effort expended
• Statistical SQA data
– error categorization & analysis
• Defect removal efficiency
– propagation of errors from process activity to activity
• Reuse data
– The number of components produced and their degree of reusability

50
 Typical Size-Oriented Metrics
• errors per KLOC (thousand lines of code)
• defects per KLOC
• $ per LOC
• pages of documentation per KLOC
• errors per person-month
• errors per review hour
• LOC per person-month
• $ per page of documentation

51
 Typical Function-Oriented
Metrics
• errors per FP (thousand lines of code)
• defects per FP
• $ per FP
• pages of documentation per FP
• FP per person-month

52
 Comparing LOC and FP
Programming LOC per Function point
Language avg. median low high
Ada 154 - 104 205
Assembler 337 315 91 694
C 162 109 33 704
C++ 66 53 29 178
COBOL 77 77 14 400
Java 63 53 77 -
JavaScript 58 63 42 75
Perl 60 - - -
PL/1 78 67 22 263
Powerbuilder 32 31 11 105
SAS 40 41 33 49
Smalltalk 26 19 10 55
SQL 40 37 7 110
Visual Basic 47 42 16 158

53
 Why Opt for FP?
• Programming language independent
• Used readily countable characteristics that are
determined early in the software process
• Does not “penalize” inventive (short)
implementations that use fewer LOC that
other more clumsy versions
• Makes it easier to measure the impact of
reusable components

54
 Object-Oriented Metrics

• Number of scenario scripts (use-cases)

• Number of support classes (required to
implement the system but are not immediately
related to the problem domain)
• Average number of support classes per key class
(analysis class)
• Number of subsystems (an aggregation of classes
that support a function that is visible to the end-
user of a system)
55
 WebApp Project Metrics
• Number of static Web pages (the end-user has no control over the
content displayed on the page)
• Number of dynamic Web pages (end-user actions result in
customized content displayed on the page)
• Number of internal page links (internal page links are pointers that
provide a hyperlink to some other Web page within the WebApp)
• Number of persistent data objects
• Number of external systems interfaced
• Number of static content objects
• Number of dynamic content objects
• Number of executable functions

56
 Measuring Quality
• Correctness — the degree to which a program
operates according to specification
• Maintainability—the degree to which a
program is amenable to change
• Integrity—the degree to which a program is
impervious to outside attack
• Usability—the degree to which a program is
easy to use

57
 Defect Removal Efficiency
DRE = E /(E + D)

where:
E is the number of errors found before
delivery of the software to the end-user
D is the number of defects found after
delivery.

58
 Metrics for Small Organizations
• time (hours or days) elapsed from the time a request is made until
evaluation is complete, tqueue.
• effort (person-hours) to perform the evaluation, Weval.
• time (hours or days) elapsed from completion of evaluation to assignment
of change order to personnel, teval.
• effort (person-hours) required to make the change, Wchange.
• time required (hours or days) to make the change, tchange.
• errors uncovered during work to make change, Echange.
• defects uncovered after change is released to the customer base, Dchange.

59
 Establishing a Metrics Program
• Identify your business goals.
• Identify what you want to know or learn.
• Identify your subgoals.
• Identify the entities and attributes related to your subgoals.
• Formalize your measurement goals.
• Identify quantifiable questions and the related indicators that you
will use to help you achieve your measurement goals.
• Identify the data elements that you will collect to construct the
indicators that help answer your questions.
• Define the measures to be used, and make these definitions
operational.
• Identify the actions that you will take to implement the measures.
• Prepare a plan for implementing the measures.

60
 Summary

• Software project Management involves

planning and risk management .
• Typical metrics help to estimate cost and effort
• FP & LOC are used to do estimation for a project
• References: www.fkm.utm