Ronald E. Giachetti, Ph.D.

Associate Professor
Industrial and Systems Engineering, FIU

January 21, 2010 1

One Extreme Too much planning!
Another Extreme No planning!
 Project Management -- WBS
Work Breakdown Schedule (WBS)

Each task should

have a well-defined
start and end
By easy to track
(schedule & budget)
Single individual is
responsible
Have budget allocated
to it
Task duration should be
proportional to overall
project

Ronald E. Giachetti Slide 12

January 21, 2010
 Estimation

For each Work Breakdown Activity

Assign project team role to activity
Estimate person-hours
work measurement
regression analysis
expert
Determine start date and end date
Estimate budget for activity (Rate *
Hrs)

Ronald E. Giachetti Slide 13

January 21, 2010
 Cross Life-cycle activities
Project Management
Requirements Management
Quality Assurance
Configuration Management & Control
Risk Management

Ronald E. Giachetti Slide 14

January 21, 2010
 Requirements Management
Requirements Management is the process of
managing change to the requirements.
It is during the analysis phase that requirements are
elicited, specified, and documented.
The project team establishes and maintains a plan
for performing requirements management.
Included in requirements
" management is a plan for ensuring bi-directional
requirements traceability.
" Additionally, requirements are a configuration item to be
tracked and controlled as part of the configuration
management process.

Ronald E. Giachetti Slide 15

January 21, 2010
 Risk Management
The systematic process of identifying,
analyzing, and responding to project
risk.
Risk is the possibility of suffering
diminished project success (scope,
cost, schedule)
Risk management is proactive
identify risk and take action to prevent
or mitigate

Ronald E. Giachetti Slide 16

January 21, 2010
 Risk Probability

Often from Expert Opinion without value of

historical data.
Cannot assign valid probabilities with any reliability.
Ordinal Scale

Very Unlikely Possible Highly Almost

unlikely likely certain
0.1 0.3 0.5 0.7 0.9
0.05 0.1 0.2 0.4 0.8

January 21, 2010

Risk Impact (ordinal scale)
Project Very Low Low (0.1) Moderate High (0.4) Very High
Objective (0.5) (0.2) (0.8)

Costs Insignificant <5% cost 5-10% cost 10-20% cost > 20% cost
cost increase increase increase increase
increase

Schedule Insignificant Schedule Overall Overall project Overall

schedule slippage < project slippage project
slippage 5% slippage 10-20% slippage >
5-10% 20%
Scope Scope Minor areas Major areas Scope Project end
decrease of scope are of scope are reduction item is
barely affected affected unacceptable effectively
noticeable to client useless
Quality Quality Only very Quality Quality Project end
degradation demanding reduction reduction item is
barely applications requires unacceptable effectively
noticeable are client to client unusable
affected approval
January 21, 2010
 Probability Impact Matrix

High Risk/
Impact

Low Risk/
Impact CAUTION: do not put too much stock in
actual values.

January 21, 2010

 Sample Probability/Impact Matrix

Taken from IT Project Mgmt, 3rd edition, Course

Technology Publishing

January 21, 2010

 Strategies
Avoidance change project plan to
eliminate risk or to protect project objectives
from risk impact.
Transference shift the consequence of the
risk to a third party with ownership of the
response. (usually for financial risks, use of
insurance, warranties, and so forth).
Mitigation reduce the probability and/or
consequence of the risk to an acceptable
threshold. Earlier the better. Mitigation costs
should be appropriate.
Acceptance do not change project plan.
Develop a contingency plan if risk event
should occur.
Day 2 Module 8 Slide 21
January 21, 2010
 Quality Assurance

Quality Assurance (QA) is a planned

and systematic approach necessary
to provide adequate confidence that
an item or product conforms to
established standards, procedures
and policies
QA is an umbrella activity that is applied at each
step in the process of building the system
QA is a CMMI Level 2 Process
Dont equate QA with Test (although testing is
important)

slide 22
August 18, 2006
QA Feedback

QA QA QA
Criteria

Objective
Feedback via
Should be part of a
(i) Evaluations
continuous
(ii) Noncompliance improvement plan
reports
(iii) Corrective
actions

ERP Implementation Process

August 18, 2006 slide 23
 Famous Software errors
ATT Long Distance phone lines down for 9 hours in
1990.
" (caused by a software upgrade)
Patriot missile failure to track an incoming SCUD
missile in the 1991 Gulf War. 28 soldiers killed.
" (an arithmetic error accumulated over time)
Gemini V orbiter missed its landing site by 100 miles.
(Failure to take into account Earths motion
around the sun)
Mariner I Venus probe veered off course after lift-off
and had to be destroyed.
" (A period in the code should have been a comma).

slide 24
August 18, 2006
 Types of Tests

Unit Test: Test each individual component to ensure

it is as defect free as possible
Integration test: Occurs between unit and system
testing to test functionally grouped components
" Interface Test: Test the interfaces in the end-to-end
business process
" Security Test: Test users security access provides proper
authority for their roles in the business processes
User Acceptance test: Is an independent test
performed by the end user prior to accepting the
delivered system users sign off on test results
System Test: Test the system as a whole
Regression Test: Test that changes do not adversely
impact already tested components

slide 25
August 18, 2006
 Configuration Management & Control

The purpose of Software Configuration

Management is to establish and maintain the
integrity of the products of the software project?
throughout the project's software life cycle.

Software Configuration Management involves

identifying the configuration of the software (i.e.,
selected software works products and their
descriptions) at given points in time, systematically
controlling changes to the configuration, and
maintaining the integrity and traceability of the
configuration throughout the software lifecycle.

Standards (approved by ANSI)

" IEEE 828: Software Configuration Management Plans
" IEEE 1042: Guide to Software Configuration Management
Ronald E. Giachetti Slide 26
January 21, 2010
 Configuration Items

A configuration item (CI) is any part of the

development and/or deliverable system which needs
to be independently identified, stored, tested,
reviewed, used, changed, delivered and/or
maintained
CIs can differ widely in complexity and may contain
other CIs in a hierarchy
Includes code, modules, and documentation
" all type of code files

" drivers for tests

" analysis or design documents

" user or developer manuals

" system configurations (e.g. version of compiler used)

Day 3 Module 2 Slide 27

January 21, 2010
 Finding Configuration Items

Large projects typically produce thousands of

entities (files, documents, data ...) which must be
uniquely identified
Any entity managed in the software engineering
process can potentially be brought under
configuration management control
But not every entity needs to be under configuration
management control all the time
Two Issues:
" What: Selection of Configuration Items to be under
configuration control
" When: When do you start to place entities under
configuration control?

Day 3 Module 2 Slide 28

January 21, 2010
 Finding Configuration Items (continued)

Some items must be maintained for the lifetime of the

software
An entity naming scheme should be defined so that
related documents have related names
Selecting the right configuration items is a skill that
takes practice
" Very similar to object modeling in object-oriented design
" Use techniques similar to object modeling for finding CIs!
Find the CIs
Find relationships between CIs

Day 3 Module 2 Slide 29

January 21, 2010
 Which of these Entities should be Configuration Items?

Problem Statement Source code

Software Project API Specification
Management Plan (SPMP)
Requirements Analysis Input data and data bases
Document (RAD) Test plan
System Design Document Test data
(SDD)
Project Agreement Support software that is part
Object Design Document of the final system
(ODD) Support software that is not
Dynamic model part of the product
Object model User manual
Functional model
Administrator manual
Unit tests
Integration test strategy

Day 3 Module 2 Slide 30

January 21, 2010
Possible Selection of Configuration Items

Problem Statement Source code

Software Project
Management Plan (SPMP) API Specification
Requirements Analysis Input data and data bases
Document (RAD)
Test plan
System Design Document
(SDD) Test data
Project Agreement Support software (part of the
Dynamic Model product)
Object model Support software (not part of
Functional Model the product)
Unit tests User manual
Integration test strategy
Administrator manual

Once the Configuration Items are selected, they are usually organized in a tree

Day 3 Module 2 Slide 31
January 21, 2010
Baseline
A specification or product that has been
formally reviewed and agreed upon, that
serves as the basis for further development,
and that can be changed only through
formal change control procedures
Examples:
" Baseline A: All the APIs have completely been
defined; the bodies of the methods are empty
" Baseline B: All data access methods are
implemented and tested
" Baseline C: The GUI is implemented

Day 3 Module 2 Slide 32

January 21, 2010
 Change Management
Change management is the handling of change requests
" A change request leads to the creation of a new release
General change process
The change is requested (this can be done by anyone including
"

users and developers)

" The change request is assessed against project goals

" Following the assessment, the change is accepted or rejected

" If it is accepted, the change is assigned to a developer and

implemented
" The implemented change is audited

The complexity of the change management process varies with the

project. Small projects can perform change requests informally and
fast while complex projects require detailed change request forms
and the official approval by one more managers

Day 3 Module 2 Slide 33

January 21, 2010
 Summary
This chapter establishes the overall
architecture and methodology to do
an enterprise project
Understand life-cycle phases, their
inputs, outputs, and activities
Cross life-cycle activities
Project initiation and project charter to
start project