January 21, 2010 1
Ronald E. Giachetti, Ph.D. Associate Professor
Industrial and Systems Engineering, FIU
One Extreme – Too much planning!
Another Extreme – No planning!
Project Management -- 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
Work Breakdown Schedule (WBS)
Estimation
Ronald E. Giachetti January 21, 2010
Slide 13
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)
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
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
Unlikely Possible Highly likely
Almost 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 Objective
Very Low (0.5)
Low (0.1) Moderate (0.2)
High (0.4) Very High (0.8)
Costs Insignificant cost increase
<5% cost increase
5-10% cost increase
10-20% 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
Low Risk/Impact
High 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 Day 2 Module 8 Slide 21
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.
August 18, 2006 slide 22
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 23
QA Feedback
ERP Implementation Process
QA QA
Objective Feedback via
QA Criteria
Should be part of a continuous improvement plan
(i) Evaluations
(ii) Noncompliance reports
(iii) Corrective actions
August 18, 2006 slide 24
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 25
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
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
January 21, 2010 Day 3 Module 2 Slide 27
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 28
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 29
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 30
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 31
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 32
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 33
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
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