Associate Professor Industrial and Systems Engineering, FIU · ERP Implementation Process QA QA...

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


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


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.


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


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)


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


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).


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


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)


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?


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


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


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


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


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

Associate Professor Industrial and Systems Engineering, FIU · ERP Implementation Process QA QA...

Documents

Transcript of Associate Professor Industrial and Systems Engineering, FIU · ERP Implementation Process QA QA...