Ronald E. Giachetti, Ph.D.

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
January 21, 2010
Slide 12

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
January 21, 2010
Slide 13

Cross Life-cycle activities
Project Management
Requirements Management
Quality Assurance
Configuration Management & Control
Risk Management
Ronald E. Giachetti
January 21, 2010
Slide 14

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
January 21, 2010
Slide 15

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
January 21, 2010
Slide 16

Risk Probability
Often from Expert Opinion without value of
historical data.
Cannot assign valid probabilities with any reliability.
Ordinal Scale
Very
unlikely
Unlikely
Possible Highly
likely
0.1 0.3 0.5 0.7 0.9
0.05 0.1 0.2 0.4 0.8
Almost
certain
January 21, 2010

Risk Impact (ordinal scale)
Project
Objective
Very Low
(0.5)
Low (0.1)
Moderate
(0.2)
High (0.4)
Very High
(0.8)
Costs
Insignificant
cost
increase
20% cost
increase
Schedule
Insignificant
schedule
slippage
Schedule
slippage <
5%
Overall
project
slippage
5-10%
Overall project
slippage
10-20%
Overall
project
slippage >
20%
Scope
Scope
decrease
barely
noticeable
Minor areas
of scope are
affected
Major areas
of scope are
affected
Scope
reduction
unacceptable
to client
Project end
item is
effectively
useless
Quality
Quality
degradation
barely
noticeable
Only very
demanding
applications
are
affected
Quality
reduction
requires
client
approval
Quality
reduction
unacceptable
to client
Project end
item is
effectively
unusable
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, 3 rd 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.
January 21, 2010
Day 2 Module 8 Slide 21

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
Don’t equate QA with Test (although testing is
important)
August 18, 2006
slide 22

QA Feedback
QA
QA
QA
Criteria
Objective
Feedback via
(i)
(ii)
Evaluations
Noncompliance
reports
(iii) Corrective
actions
Should be part of a
continuous
improvement plan
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 Earth’s 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).
August 18, 2006
slide 24

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
August 18, 2006
slide 25

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
January 21, 2010
Slide 26

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)
January 21, 2010
Day 3 Module 2 Slide 27

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?
January 21, 2010
Day 3 Module 2 Slide 28

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
January 21, 2010
Day 3 Module 2 Slide 29

Which of these Entities should be Configuration Items?
Problem Statement
Software Project
Management Plan (SPMP)
Requirements Analysis
Document (RAD)
System Design Document
(SDD)
Project Agreement
Object Design Document
(ODD)
Dynamic model
Object model
Functional model
Unit tests
Integration test strategy
Source code
API Specification
Input data and data bases
Test plan
Test data
Support software that is part
of the final system
Support software that is not
part of the product
User manual
Administrator manual
January 21, 2010
Day 3 Module 2 Slide 30

Possible Selection of Configuration Items
Problem Statement
Software Project
Management Plan (SPMP)
Requirements Analysis
Document (RAD)
System Design Document
(SDD)
Project Agreement
Dynamic Model
Object model
Functional Model
Unit tests
Integration test strategy
Source code
API Specification
Input data and data bases
Test plan
Test data
Support software (part of the
product)
Support software (not part of
the product)
User manual
Administrator manual
Once the Configuration Items are selected, they are usually organized in a tree
January 21, 2010
Day 3 Module 2 Slide 31

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
January 21, 2010
Day 3 Module 2 Slide 32

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
January 21, 2010
Day 3 Module 2 Slide 33

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