Project Management Software Guide

Outline
 The Management Spectrum (4 Ps in
Project Management)
 Detailed discussion on each P
 W5HH Principle

4P’s in Project Management
Spectrum
 People
 Product
 Process
 Project

People…
 …the most important factor in success of
software project.
 “Companies That sensibly manage their
investment in people will prosper in the long
run” .
 Cultivation of motivated and highly skilled
software people has always been important
for software organizations.
 The “people-factor” is so important that has
developed People Management Capability
Maturity Model.

PM
 In simple words - to enhance the people’s
capabilities through personnel
development
 Organizations that achieve high levels of
maturity in PM-CMM have a higher
likelihood of implementing effective software
engineering practices

PM-CMM (Contd.)
 Key Practice Areas of PM-CMM
 Recruiting
 Selection
 Performance Management
 Training
 Compensation
 Career development
 Organization and work design
 Team/culture development

People Involved in Software
Process
 The Stakeholders
 They can be categorized into one of the following
 Senior Managers
 they define business issues that often have significant influence on
business
 Project (technical) managers
 they must plan, motivate, organize and control the practitioners who
do software work
 Practitioners
 They deliver the technical skills necessary to engineer a product or
application
 Customers
 They specify the requirements for the software to be engineered
 End Users
 They interact with the software after it is released for production use

The Product
 The product and the problem it is intended
to solve must be examined at very
beginning of the software project.
 The scope of product must be established
and bounded.
 Bounded scope means
 establishing quantitative data like no. of simultaneous
users, max. allowable response time. etc.
 Constraints and limitations

Software scope
 Scope is defined by
 Context (1st step in scope determination)
 Functional location of the software product into a large
system, product or business context
 Constraints involved
 Information Objectives (2nd step)
 What data objects are required as i/p or o/p
 Function and Performance (3rd step)
 What function does the software system perform on i/p to
produce o/p
 What level of performance is required

Common Process Framework
Activities
 These characterize a software process and
are applicable to all software projects
 Communication
 Planning
 Modeling
 Construction
 Deployment
 These are applied to software engineering
work tasks (e.g., different product functions).

The Process Models
 Different process models:
 Linear sequential, Prototyping, RAD, Spiral,
Formal …
 Project manager must decide about which
model to use depending on
 Customers who have requested the product
 People who would work on project
 Product characteristics
 Project environment
 Project planning begins once model is
selected

Process decomposition
 The way a process is decomposed
depends on project complexity
 Decomposition involves outlining of
work tasks involved in each process
framework activity

Signs of Projects Risk
 Software people don’t understand
customer needs
 Product scope is poorly defined
 Changes are managed poorly
 The chosen technology changes
 Business needs change
 Deadlines are unrealistic

Signs of Projects Risk
(Cont…)
 Users are resistant
 Sponsorship is lost
 Team lacks skills
 Managers avoid best practices

How to avoid problems?
 Start on the right foot
 Involves detailed understanding of project
 setting realistic objectives & expectations
 Selecting the right team
 Facilitating the team
 Maintain Momentum
 Provide incentives
 Reduce bureaucracy and give autonomy to team
members but with supervision
 Track Progress
 Assess progress as work products are produced

How to avoid problems? (Contd..)
 Make smart decisions
 When possible, use existing software components / COTS
software
 Choose standard approaches and keep it simple
 Avoid risks and allocate more time than needed for
complex/risky tasks
 Conduct a postmortem analysis
 Compare planned and actual schedule
 Collect and analyze project metrics (standards)
 Get feedback from team and customers
 Establish record of lessons learnt for each project

Metrics
Definition
 Measure - quantitative indication of extent, amount,
dimension, capacity, or size of some attribute of a
product or process.
E.G., Number of errors
 Metric - quantitative measure of degree to which a
system, component or process possesses a given
attribute. “A handle or guess about a given attribute.”
E.g., Number of errors found per person hours
expended

Metrics –Measures
A measurement is an indication of
the size, quantity, amount or dimension
of a particular attribute of a product or
process. For example the number of
errors in a system is a measurement.

Measures, Metrics, and
Indicators
These three terms are often used
interchangeably, but they can have subtle
differences
 Measure
Provides a quantitative indication of the
extent, amount, dimension, capacity, or size of
some attribute of a product or process
 Measurement
The act of determining a measure

 Metric
A quantitative measure of the degree
to which a system, component, or process
possesses a given attribute
 Indicator
A metric or combination of metrics that
provides insight into the software process, a
software project, or the product itself.

Types of metrics-Size oriented
 Derived by normalizing quality and/or productivity measures
by considering the size of the software produced
 Thousand lines of code (KLOC) are often chosen as the
normalization value
 Metrics include
 Errors per KLOC - Errors per person-month
 Defects per KLOC - KLOC per person-month
 Dollars per KLOC - Dollars per page of
documentation
 Pages of documentation per KLOC
 Size-oriented metrics are not universally accepted as the
best way to measure the software process
Types of metrics-Size oriented

 Opponents argue that KLOC
measurements
 Are dependent on the programming
language
 Penalize well-designed but short programs
 Cannot easily accommodate nonprocedural
languages
 Require a level of detail that may be difficult
to achieve

Function-oriented metrics
 Function-oriented metrics use a measure of the
functionality delivered by the application as a
normalization value
 Most widely used metric of this type is the function
point:
 FP = count total * [0.65 + 0.01 * sum (value adj.
factors)]
 Function point values on past projects can be used
to compute, for example, the average number of
lines of code per function point (e.g., 60).

Metrics for software quality
 Functionality - features of system
 Usability – aesthesis, documentation
 Reliability – frequency of failure,
security
 Performance – speed, throughput
 Supportability – maintainability.

Measures of Software
Quality
Correctness – degree to which a program operates
according to specification
 Defects/KLOC
 Defect is a verified lack of conformance to requirements
 Failures/hours of operation
Maintainability – degree to which a program is open to
change
 Mean time to change
 Change request to new version (Analyze, design etc)
 Cost to correct

Integrity - degree to which a program is
resistant to outside attack
 Fault tolerance, security & threats
Usability – easiness to use
 Training time, skill level necessary to use,
Increase in productivity, subjective
questionnaire or controlled experiment

Jalote - Project Planning 32
Risk Management
 Any project can fail - reasons can be
technical, managerial, etc.
 Project management aims to tackle the
project management aspect
 Engineering life cycles aim to tackle the
engineering issues
 A project may fail due to unforeseen
events - risk management aims to tackle
this

Risk Management
 Risk: any condition or event whose
occurrence is not certain but which can
cause the project to fail
 Aim of risk management: minimize the
effect of risks on a project

Risk Management Tasks
RISK
MANAGEMENT
RISK ASSESSMENT
RISK IDENTIFICATION
RISK ANALYSIS
RISK PRIORITIZATION
RISK MANAGEMENT
PLANNING
RISK RESOLUTION
RISK MONITORING
RISK CONTROL
Risk Management Activities

Risk Identification
 To identify possible risks to a project,
i.e. to those events that might occur
and which might cause the project to
fail
 No “algorithm” possible, done by “what
ifs”, checklists, past experience
 Can have a list of “top 10” risks that
projects have seen in past

Top Risk Examples
 Shortage of technically trained
manpower
 Too many requirement changes
 Unclear requirements
 Not meeting performance
requirements
 Unrealistic schedules
 Insufficient business knowledge

Risk Prioritization
 The number of risks might be large
 Must prioritize them to focus attention
on the “high risk” areas
 For prioritization, impact of each risk
must be understood
 In addition, probability of the risk
occurring should also be understood

Risk Prioritization ...
 Risk exposure (RE) = probability of risk
occurring * risk impact
 RE is the expected value of loss for a
risk
 Prioritization can be done based on
risk exposure value
 Plans can be made to handle high RE
risks

A Simple approach to Risk Prioritization
 Classify risk occurrence probabilities as:
Low, Medium, High
 Classify risk impact as: Low, Medium, High
 Identify those that are HH, or HM/MH
 Focus on these for risk mitigation
 Will work for most small and medium sized
projects

Risk Analysis
Project Risk Analysis is a process which enables the
analysis of the risks associated with a project.
Properly undertaken it will increase the likelihood of
successful completion of a project to cost, time and
performance objectives.
This stage of process is generally split into 2 ‘sub-
stages’; a qualitative analysis ‘sub-stage’ that
focuses on identification and subjective assessment
of risks and a quantitative analysis ‘sub-stage’ that
focuses on a objective assessment of the risk

Risk Projection
Risk projection, also called risk estimation, attempts to rate each
risk in two ways-the likelihood or probability that the risk is real
and the consequences of the problems associated with the
risk, should it occur. The project planner, along with other
managers and technical staff, performs four risk projection
activities:
(1) Establish a scale that reflects the perceived likelihood of a risk,
(2) Delineate the consequences of the risk,
(3) Estimate the impact of the risk on the project and the product,
and
(4) Note the overall accuracy of the risk projection so that there
will be no misunderstandings

Risk Management Plan
1 Failure to meet the
high performance
H H H Study white papers and guidelines on
performance; train team on performance
tuning; Update review checklist to look for
performance pitfalls; Test application for
performance during system testing
2 Lack of people with
right skills
M M M Train resources; review prototype with
customer; develop coding practices
3 Complexity of
application
M M M Ensure ongoing knowledge transfer; deploy
persons with prior experience with the
domain
4 Manpower attrition M M M Train a core group of four people; rotate
assignments among people; identify backups
for key roles
5 Unclear requirements M M M Review a prototype; conduct a mid-stage
review
Probability, Impact, Expectation

Risk Monitoring
 Software risk monitoring is integrated into project activities
and regular checks are conducted on top risks. Software risk
monitoring comprises of:
 Tracking of risk plans for any major changes in actual plan,
attribute, etc.
 Preparation of status reports for project management.
 Review risks and risks whose impact or likelihood has reached
the lowest possible level should be closed.
 Regularly search for new risks

Risk Planning
Software risk planning is all about:
 Defining preventive measure that would
lower down the likelihood or probability of
various risks.
 Define measures that would reduce the
impact in case a risk happens.
 Constant monitoring of processes to identify
risks as early as possible.

Risk Control
 Can the risk be avoided?
 E.g. if new hardware is a risk, it can be
avoided by working with proven hardware
 For others, risk mitigation steps need
to be planned and executed
 Actions taken in the project such that if
the risk materializes, its impact is minimal
 Involves extra cost

DFD info
 Data flow diagrams are used to give a
graphical representation of the flow of data
through an ICT system.
 A top level data flow diagram shows the
main processes (or tasks) that are
performed by the system.
 A low level data flow diagram provides
more detail than a top level diagram by
showing how a main process is divided into
a number of sub-processes.

Symbol Meaning Example
An entity. A source of data or a
destination for data.
A process or task that is
performed by the system.
A data store, a place where data
is held between processes.
A data flow.

The diagram below shows a data flow diagram for an
ICT system that is used to manage the SALE, supply
and payment for goods in a business.

49
Observations on Estimation
 Planning requires technical managers and the software team to
make an initial commitment
 Process and project metrics can provide a historical
perspective and valuable input for generation of quantitative
estimates
 Past experience can aid greatly
 Estimation carries inherent risk, and this risk leads to
uncertainty
 The availability of historical information has a strong influence
on estimation risk
(More on next slide)

50
Observations on Estimation
(continued)
 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
"It is the mark of an instructed mind to rest satisfied with the degree of precision
that the nature of the subject admits, and not to seek exactness when only an
approximation of the truth is possible." ARISTOTLE

52
Software Scope
 Software scope describes
 The functions and features that are to be delivered to end users
 The data that are input to and output from the system
 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 can be define using 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

53
Software Scope (continued)
 After the scope has been identified, two questions are asked
 Can we build software to meet this scope?
 Is the project feasible?
 Software engineers too often rush (or are pushed) past these
questions
 Later they become mired in a project that is doomed from the onset

54
Feasibility
 After the scope is resolved, feasibility is addressed
 Software feasibility has four dimensions
 Technology – Is the project technically feasible? Is it within the state of
the art? Can defects be reduced to a level matching the application's
needs?
 Finance – Is is financially feasible? Can development be completed at
a cost that the software organization, its client, or the market can afford?
 Time – Will the project's time-to-market beat the competition?
 Resources – Does the software organization have the resources
needed to succeed in doing the project?
Another view recommends the following feasibility dimensions: technological,
economical, legal, operational, and schedule issues (TELOS)

56
Resource Estimation
 Three major categories of software engineering resources
 People
 Development environment
 Reusable software components
 Often neglected during planning but become a paramount concern
during the construction phase of the software process
 Each resource is specified with
 A description of the resource
 A statement of availability
 The time when the resource will be required
 The duration of time that the resource will be applied
Time window

57
Categories of Resources
People
- Number required
- Skills required
- Geographical location
Development Environment
- Software tools
- Computer hardware
- Network resources
Reusable Software Components
- Off-the-shelf components
- Full-experience components
- Partial-experience components
- New components
The
Project

58
Human Resources
 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

59
Development Environment
Resources
 A software engineering environment (SEE) incorporates
hardware, software, and network resources that provide
platforms and tools to develop and test software work
products
 Most software organizations have many projects that require
access to the SEE provided by the organization
 Planners must identify the time window required for hardware
and software and verify that these resources will be available

60
Reusable Software Resources
 Off-the-shelf components
 Components are from a third party or were developed for a previous
project
 Ready to use; fully validated and documented; virtually no risk
 Full-experience components
 Components are similar to the software that needs to be built
 Software team has full experience in the application area of these
components
 Modification of components will incur relatively low risk
 Partial-experience components
 Components are related somehow to the software that needs to be
built but will require substantial modification
 Software team has only limited experience in the application area of
these components
 Modifications that are required have a fair degree of risk
 New components
 Components must be built from scratch by the software team
specifically for the needs of the current project
 Software team has no practical experience in the application area

Estimation of Project Cost and
Effort

62
Factors Affecting Project
Estimation
 The accuracy of a software project estimate is predicated on
 The degree to which the planner has properly estimated the size
(e.g., KLOC) of the product to be built
 The ability to translate the size estimate into human effort, calendar
time, and money
 The degree to which the project plan reflects the abilities of the
software team
 The stability of both the product requirements and the environment
that supports the software engineering effort

63
Project Estimation Options
 Options for achieving reliable cost and effort estimates
1) Delay estimation until late in the project (we should be able to
achieve 100% accurate estimates after the project is complete)
2) Base estimates on similar projects that have already been
completed
3) Use relatively simple decomposition techniques to generate
project cost and effort estimates
4) Use one or more empirical estimation models for software cost
and effort estimation
 Option #1 is not practical, but results in good numbers
 Option #2 can work reasonably well, but it also relies on other
project influences being roughly equivalent
 Options #3 and #4 can be done to cross check each other

64
Project Estimation Approaches
 Decomposition techniques
 These take a "divide and conquer" approach
 Cost and effort estimation are performed in a stepwise fashion by
breaking down a project into major functions and related
software engineering activities
 Empirical estimation models
 Offer a potentially valuable estimation approach if the historical
data used to seed the estimate is good

66
Introduction
 Before an estimate can be made and decomposition
techniques applied, the planner must
 Understand the scope of the software to be built
 Generate an estimate of the software’s size
 Then one of two approaches are used
 Problem-based estimation
 Based on either source lines of code or function point estimates
 Process-based estimation
 Based on the effort required to accomplish each task

67
Problem-Based Estimation
1) Start with a bounded statement of scope
2) Decompose the software into problem functions that can each
be estimated individually
3) Compute an LOC or FP value for each function
4) Derive cost or effort estimates by applying the LOC or FP
values to your baseline productivity metrics (e.g.,
LOC/person-month or FP/person-month)
5) Combine function estimates to produce an overall estimate for
the entire project

68
(continued)
 In general, the LOC/pm and FP/pm metrics should be computed by
project domain
 Important factors are team size, application area, and complexity
 LOC and FP estimation differ in the level of detail required for
decomposition with each value
 For LOC, decomposition of functions is essential and should go into
considerable detail (the more detail, the more accurate the estimate)
 For FP, decomposition occurs for the five information domain
characteristics and the 14 adjustment factors
 External inputs, external outputs, external inquiries, internal logical files,
external interface files
pm = person month

69
(continued)
 For both approaches, the planner uses lessons learned to estimate
an optimistic, most likely, and pessimistic size value for each
function or count (for each information domain value)
 Then the expected size value S is computed as follows:
S = (Sopt + 4Sm + Spess)/6
 Historical LOC or FP data is then compared to S in order to cross-
check it

71
Introduction
 Estimation models for computer software use empirically
derived formulas to predict effort as a function of LOC or FP
 Resultant values computed for LOC or FP are entered into an
estimation model
 The empirical data for these models are derived from a limited
sample of projects
 Consequently, the models should be calibrated to reflect local
software development conditions

Introduction
 COCOMO is one of the most widely
used software estimation models in the
world
 It was developed by Barry Boehm in
1981
 COCOMO predicts the effort and
schedule for a software product
development based on inputs relating
to the size of the software and a

COCOMO Models
 COCOMO has three different models
that reflect the complexity:
 the Basic Model (or) Organic Mode
 the Intermediate Model (or) Semi
detached Mode
 the Detailed Model (or) Embedded Mode

The Development Modes:
Project Characteristics
 Organic Mode
• Relatively small, simple software projects
• Small teams with good application
experience work to a set of less than
rigid requirements
• relatively small and requires little
innovation
 Semidetached Mode
• Intermediate (in size and complexity)
software projects in which teams with
mixed experience levels must meet a
mix of rigid and less than rigid
requirements.

Contd…
 Embedded Mode
• Software projects that must be developed
within a set of tight hardware, software,
and operational constraints.

Basic COCOMO Model:
Formula
E=ab (KLOC) b
b
D=cb (E) d
b
P=E/D
where E is the effort applied in person-months,
D is the development time in chronological
months, KLOC is the estimated number of
delivered lines of code for the project
(expressed in thousands), and P is the number
of people required. The coefficients ab, bb, cb
and db are given in next slide.

Contd…
Software project ab bb cb db
 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:
Example
 We have determined our project fits the characteristics of
Semi-Detached mode
 We estimate our project will have 32,000 Delivered Source
Instructions. Using the formulas, we can estimate:
 Effort = 3.0*(32) 1.12 = 146 man-months
 Schedule = 2.5*(146) 0.35 = 14 months
 Average Staffing = 146 MM /14 months
= 10 FSP

Software Quality assurance
 Software quality assurance (SQA) consists of a means of monitoring the
software engineering processes and methods used to ensure quality.
 Basic Principles for Project Scheduling
 Compartmentalization
 The project must be compartmentalized into a number of manageable
activities, actions, and tasks; both the product and the process are
decomposed
 Interdependency
 The interdependency of each compartmentalized activity, action, or task
must be determined
 Some tasks must occur in sequence while others can occur in parallel
 Some actions or activities cannot commence until the work product
produced by another is available

 Time allocation
 Each task to be scheduled must be allocated some number of work units
 In addition, each task must be assigned a start date and a completion date
that are a function of the interdependencies
 Start and stop dates are also established based on whether work will be
conducted on a full-time or part-time basis.

 Effort validation
 Every project has a defined number of people on the team
 As time allocation occurs, the project manager must ensure that no more
than the allocated number of people have been scheduled at any given time
 Defined responsibilities
 Every task that is scheduled should be assigned to a specific team member
 Defined outcomes
 Every task that is scheduled should have a defined outcome for software
projects such as a work product or part of a work product
 Work products are often combined in deliverables

 Defined milestones
 Every task or group of tasks should be
associated with a project milestone
 A milestone is accomplished when one or
more work products has been reviewed
for quality and has been approved.

Time Line Chart
 Also called a Gantt chart; invented by Henry Gantt, industrial engineer, 1917
 All project tasks are listed in the far left column
 The next few columns may list the following for each task: projected start date, projected
stop date, projected duration, actual start date, actual stop date, actual duration, task inter-
dependencies (i.e., predecessors)
 To the far right are columns representing dates on a calendar
 The length of a horizontal bar on the calendar indicates the duration of the task
 When multiple bars occur at the same time interval on the calendar, this implies task
concurrency
 A diamond in the calendar area of a specific task indicates that the task is a milestone; a
milestone has a time duration of zero

Formal Technical review
Objectives of FTR:
 - to uncover errors in function, logic, or implementation
 - to verify the software under review meets its requirements
 - to ensure that the software has been represented according to predefined standards
 - to develop software in a uniform manner
 - to make projects more manageable
Purposes of FTR:
 - serves as a training ground for junior engineers
 - promote backup and continuity
Review meeting’s constraints:
 - 3-5 people involved in a review
 - advanced preparation (no more than 2 hours for each person)
 - the duration of the review meeting should be less than 2 hours
 - focus on a specific part of a software product
People involved in a review meeting:
 - producer, review leader, 2 or 3 reviewers (one of them is recorder)

Project Management Software Guide

Project Management Software Guide

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Project Management Software Guide

Similar a Project Management Software Guide (20)

Último

Último (20)

Project Management Software Guide