software management

Software
Management

1st Edition

Project Planing

An overview

•An overview: software
•An overview: software

•What are the attributes of good

software?

The software should deliver the required
functionality and performance (efficient) to
the user and should be maintainable,
dependable and acceptable.

• Efficiency

–Software should not make wasteful use of system
resources

• Maintainability

–Software must evolve to meet changing needs

• Dependability

–Software must be trustworthy

• Acceptability

–Software must be accepted by the users for which it
was designed: understandable, usable and
compatible with other systems.

•Are software projects really

different from other projects?

Not really …but

• Invisibility: You Can See Project Progress Of

Building Bridge. Software Project Not
Immediately Visible.

• Complexity: Per RM Spent, Software Products

Contain More Complexity Than Other
Engineered Artefacts.

• Conformity: Physical Systems Of Bridge

Conform To Physical Law. Software
Developers Conform To Requirements Of
Human Clients. Individuals Can Be
Inconsistent.

• Flexibility: Software Systems Are Subject To

Change.

•What is a Project?

• A Project is A Temporary Endeavor
Undertaken To Produce A Unique Product Or
Service

• Temporary – definitive beginning and
end

• Unique – new undertaking, unfamiliar
ground

• Some ways of categorizing projects

Distinguish
ing
Different
Types Of

Project Is
Important
As
Different
Types Of

Task Need
Different
Project
Approache
s E.G.

•Voluntary

Systems
(Such As
Computer

Games)
Versus
Compulsor
y Systems
E.G. The

Order
Processing
System In
An

Organizati
on

•Informatio

n Systems

Versus
Embedded
Systems

•Objective-

based
Versus
Product-
based

•Project Life Cycle

• The Project Life Cycle

•Initiation Phase

• Define the need, problem, or opportunity.
• Develop project charter

• Justification
• Project objective
• Expected benefits
• General requirements and conditions

• Decide if RFP needed
• Return on investment analysis
• Make or buy decision
• Budget development

•Definition Phase

•Determine goals, scope and project
constraints

•Identify members and their roles
•Define communication channels,

methods, frequency and content

•Risk management planning

•Planning Phase

•Do detailed planning for how to
accomplish the project.

•Resource planning
•Work breakdown structure

•Project schedule development
•Quality assurance plan

• Develop Baseline Line:

• What Needs To Be Done
• How It Will Get Done
• Who Will Do It
• How Long It Will Take
• How Much It Will Cost
• What The Risks Are

•Implementation Phase

•Execute project plan and accomplish
project goals

•Training plan
•System build

•Quality assurance
•Increase pace as more resources are

added

•Monitor and control progress
•Take corrective action as needed
•Manage and control changes with

sponsor approval

•Achieve customer satisfaction with
acceptance of deliverable

•Deployment Phase

•User training
•Production review
•Start using

•Closing Phase

•Contractual closeout
•Post production transition
•Lessons learned

•Common processes in

SM

•The sdlc
•References

•Watts S. Humphrey, Software
Management, 7th Ed., PP. 21-25, 2006

•Donald J. Reifer, Software
Management, 7th Ed., pp. 5-8, 2006

•Pressman, R. S. & Maxim B.R. 2014.
Software Engineering: A Practitioner’s
Approach, 8th Edition, Boston:
McGraw-Hill.

•Kathy Schwalbe (6th Ed, 2010).
Managing Information Technology
Projects, Course Technology.

Any

Question?

• Tutorial
• Form a group of 4 persons
• Brainstorms the individual FYP project
• Select the most suitable in terms of ROI by doing SWOT

analysis.

• Post your finalised topic for your project.

Project Planning- An Overview
The Goals for Project Planning
Element in Project Planning
Write It Down!
A. Estimation

Project Estimation

First step in project planning

Fundamental Estimation Questions –
Triple Constraints

What is the total cost of an activity?

How to estimate?

The software team first estimates
The work to be done  scope document, WBS
The resources required  WBS
The time that will elapse from start to finish 
Gantt Chart, Milestones

Estimation is risky business

Observations on estimation

Observations on estimation (cont.)

When software metrics are available from past
projects

Estimates can be made with greater assurance
Schedules can be established to avoid past difficulties
Overall risk is reduced

Estimation risk is measured by the degree of
uncertainty in the quantitative estimates for cost,
schedule, and resources
Nevertheless, a project manager should not
become obsessive about estimation

Plans should be iterative and allow adjustments as time
passes and more is made certain

Task Set for Project Planning

Activities associated with project

planning

Decomposition (Strategy)
Statement of Work
Work Breakdown Structure
Project Schedule

Software scope

Want to establish a project scope that is
unambiguous and understandable at management
and technical levels
Describes:

Resources

Estimate resources required to accomplish the
development effort
Resources comprise of:

Hardware and software tools

CASE tools for the planning

Word processor, spreadsheet
Automated intermediate
COCOMO/COCOMO II

Management tools assist with
planning and monitoring

Mac project
Microsoft project

Reusable Software ARTEFACTS /

COMPONENTS

Valuable for reducing:

Development costs
Time to market

Can greatly increase productivity
Reuse considerations often ignored*

Planners need to select the number and the kind
of people skills needed to complete the project
They need to specify the organizational position
and job specialty for each person
Small projects of a few person-months may only
need one individual

Large projects spanning many person-months or
years require the location of the person to be
specified also
The number of people required can be
determined only after an estimate of the
development effort

Each resource specified with 4
characteristics

Description of resource
Statement of availability
Chronological time resource will be
needed
Duration of time resource used

B. Project Scoping

To Understand Scope ...

Project scoping means….

Scoping a project tells you to :

Set boundaries
Determine what to do & what not to do

Questions focusing on:

Customer
Who is behind the request for this
work? Who will use the solution?
What will be the economic benefit
of a successful solution? …

Problem and solution
What problem(s) will this solution
address? How would you
characterize “good” output that
would be generated by a successful
solution? …

The effectiveness of the meeting
Are you the right person to answer
these questions? Are answers
“official”? Can anyone else
provide additional information? …

Plan a project

in SMART way….

Risk Plan
Risk is:

an uncertain event or condition that, if
it occurs, has a positive or negative
effect on a project's objectives
A risk plan is:
a list of all risks that threaten the
project,
with a plan to mitigate some or all of
those risks.

May contain a risk assessment matrix.

The project manager selects team
members to participate in a risk planning
session:

The team members brainstorm
potential risks

The probability and impact of each
risk is estimated
A risk plan is constructed

Risk Plan Example

Analyzing risk and uncertainty
Can apply basic micro economic analysis
to these questions
In software engineering, must make
decisions under conditions of uncertainty
Can reduce uncertainty, and therefore
make better decisions, by buying
information
Example, Prototyping is a way of buying
information to reduce uncertainty about
risky functionality

D. Schedule

Gross scheduling

Identify the major activities which
must be completed.
Identify the constraints on start
times of these activities.
Balance the times for activities so
that they fit into the schedule.
Identify the critical paths. Use
critical path analysis (PERT).

Observation

Have not yet considered number of
people allocated to any one gross
activity. Why?
The number of people allocated to a
task is largely irrelevant when doing
initial gross scheduling.
A tasks will take a definable amount
of time if it is assumed that the right

number of people are assigned to
complete this task.
More or less people will only delay
task.

Subdivide gross

activities

Attach clear
milestones/deliverables to each of
the steps needed to complete a gross
task/activity.
Allow no more than 3 months
between identifiable milestones
with an activity.
Does the schedule still seem doable
when viewed in more detail?

Allocate resources to activities

Identify who [or what type of individual
if not yet hired] should undertake each of
the gross activities.
Avoid targeting individuals at one
delayable activity, if they could usefully
be involved in multiple concurrent
activities.
Try to allocate work to all individuals
throughout lifetime of project.
Sketch out probable division of time per
person involved in project.

Sanity check

Are there any glaring responsibilities
which no one seems competent to
assume:

Do you have people who can interact
with the customer and the developers
effectively.
Do you have people who enjoy the
challenge of the unknown.

Do you have people who enjoy
testing.
Do you have people who enjoy
technical writing.
How do people feel about your schedule?

Who needs software?

Most software is built in
organizations for people with
specific needs.

A stakeholder is a anyone who has an
interest (or stake) in the software
being completed
A user is someone who will need to
use the software to perform tasks.
Sometimes stakeholders will be users;
but often the stakeholder will not use
the software.

For example, a senior manager
(like a CEO or CTO in a company)

will usually have a stake in the
software that is built (since it
affects the bottom line), even if she
won’t ever use it.

Who builds software?

Software is typically built by a team
of software engineers, which
includes:

Business analysts or requirements
analysts who talk to users and
stakeholders, plan the behavior of
software and write software
requirements
Designers and architects who plan the
technical solution
Programmers who write the code
Testers who verify that the software
meets its requirements and behaves as
expected

E. Control strategy

Control Strategy

Planning & Documenting!

Project plan?
Resource Lists?
Estimate schedules?
Work
Distributions/Decompositio
n?

Project Plan
The project plan defines the work that
will be done on the project and who will
do it. It consists of:

A Statement of Work (SOW) that
describes all work products that will
be produced and a list of people who
will perform that work
A Resource List that contains a list of
all resources that will be needed for
the product and their availability
A Work Breakdown Structure
(WBS) and a set of estimates
A Project Schedule (Milestone,
Gantt Chart)

A Risk Plan that identifies any risks

that might be encountered and
indicates how those risks would be
handled should they occur

Statement of work

The statement of work (SOW) is a

detailed description of all of the work

products which will be created over the
course of the project. It includes:

A list of features that will be
developed
A description of each intermediate
deliverable or work product that will
be built.
The estimated effort involved for
each work product to be delivered

Resource list

The project plan should contain a
list of all resources that will be
used on the project.

A resource is a person, hardware,
room or anything else that is
necessary for the project but limited
in its availability
The resource list should give each
resource a name, a brief one-line

description, and list the availability
and cost (if applicable) of the
resource

Estimates and Project Schedule
The project plan should also include
estimates and a project schedule:

A work breakdown structure (WBS) is
defined. This is a list of tasks which,
if performed, will generate all of the
work products needed to build the
software.
An estimate of the effort required for
each task in the WBS is generated.
A project schedule is created by
assigning resources and determining
the calendar time required for each
task.

Estimates and project schedules will be
discussed in detail in later slides.

Planning Works Distributions in Project

PRINCE 2

Various Approaches Towards Identifying
Project Activities

Activity-based approach (WBS)
Product-based approach
Hybrid approach

Activity-based Approach

Use Work Breakdown Structure (WBS) to generate a task
list
WBS involves

identifying the main tasks
break each main task down into subtasks
The subtasks can further be broken down into
lower level tasks.

Work Breakdown Structure

Activity-based Approach Pros & Cons

Advantages

More likely to obtain a task catalogue that is
complete and is composed of non-overlapping
tasks
WBS represents a structure that can be refined
as the project proceeds
The structure already suggests the
dependencies among the activities

Disadvantage
Very likely to miss some activities if an
unstructured activity list is used

Product-based Approach

Product Breakdown Structure (PBS)
To show how a system can be broken down into
different products for development

Product Flow Diagram (PFD)
To indicate, for each product, which products are
required as ‘inputs’

Advantages
Less likely to miss a product unexpectedly from
a PBS

Product-based Approach – An example

Hybrid Approach

A mix of the activity-based approach and the product-

based approach

More commonly used approach

The WBS consists of
a list of the products of the project; and
a list of activities for each product

Hybrid Approach (cont’d)

PROJECT PLANNING
Part 2
• Learning Outcomes
• At the end of this lecture, student
should be able to:

Describe the five elements in

planning a software project

Elaborate the three questions in

project estimation

Write a brief project scope and

determine its feasibility for a given
software project scenario
• Identify the risk plan for a software
project

• Sketch a brief plan for identifying
project activities for a software

project

• Risk Plan

• Risk is:
• an uncertain event or condition that,
if it occurs, has a positive or
negative effect on a project's
objectives

• A risk plan is:
• a list of all risks that threaten the
project,
• with a plan to mitigate some or all
of those risks.

• May contain a risk assessment matrix.

• The project manager selects team
members to participate in a risk
planning session:
• The team members brainstorm
potential risks
• The probability and impact of
each risk is estimated
• A risk plan is constructed

• Risk Plan Example

• Analyzing risk and uncertainty
• Can apply basic micro economic

analysis to these questions
• In software engineering, must make

decisions under conditions of
uncertainty
• Can reduce uncertainty, and therefore
make better decisions, by buying
information
• Example, Prototyping is a way of
buying information to reduce
uncertainty about risky functionality
• D. Schedule

•Gross scheduling

• Identify the major activities which
must be completed.

• Identify the constraints on start
times of these activities.

• Balance the times for activities so
that they fit into the schedule.

• Identify the critical paths. Use
critical path analysis (PERT).

•Observation

• Have not yet considered number
of people allocated to any one
gross activity. Why?

• The number of people allocated to
a task is largely irrelevant when
doing initial gross scheduling.

• A tasks will take a definable
amount of time if it is assumed
that the right number of people are
assigned to complete this task.

• More or less people will only
delay task.

•Subdivide gross

activities

• Attach clear
milestones/deliverables to each of
the steps needed to complete a
gross task/activity.

• Allow no more than 3 months
between identifiable milestones
with an activity.

• Does the schedule still seem
doable when viewed in more
detail?

•Allocate resources to

activities

• Identify who [or what type of
individual if not yet hired] should
undertake each of the gross activities.

• Avoid targeting individuals at one
delayable activity, if they could usefully
be involved in multiple concurrent
activities.

• Try to allocate work to all individuals
throughout lifetime of project.

• Sketch out probable division of time
per person involved in project.

• Sanity check

• Are there any glaring responsibilities
which no one seems competent to
assume:
• Do you have people who can
interact with the customer and the
developers effectively.
• Do you have people who enjoy the
challenge of the unknown.

• Do you have people who enjoy
testing.

• Do you have people who enjoy
technical writing.

• How do people feel about your
schedule?

• Who needs software?

• Most software is built in
organizations for people with
specific needs.

• A stakeholder is a anyone who has
an interest (or stake) in the software
being completed

• A user is someone who will need to
use the software to perform tasks.

• Sometimes stakeholders will be
users; but often the stakeholder will
not use the software.

• For example, a senior manager
(like a CEO or CTO in a
company) will usually have a
stake in the software that is built
(since it affects the bottom line),
even if she won’t ever use it.

• Who builds software?

• Software is typically built by a
team of software engineers, which
includes:

• Business analysts or requirements
analysts who talk to users and
stakeholders, plan the behavior of
software and write software
requirements

• Designers and architects who plan
the technical solution

• Programmers who write the code

• Testers who verify that the software
meets its requirements and behaves
as expected

• E. Control strategy
• Control Strategy

• Planning & Documenting!

• Project plan?
• Resource Lists?
• Estimate schedules?
• Work
Distributions/Decompositio
n?

• Project Plan

• The project plan defines the work that
will be done on the project and who will
do it. It consists of:
• A Statement of Work (SOW) that
describes all work products that will
be produced and a list of people who
will perform that work
• A Resource List that contains a list
of all resources that will be needed
for the product and their availability
• A Work Breakdown Structure
(WBS) and a set of estimates
• A Project Schedule (Milestone,
Gantt Chart)

• A Risk Plan that identifies any

risks that might be encountered and
indicates how those risks would be
handled should they occur
• Statement of work