Ronald E. Giachetti, Ph.D.

Transcription

1 Ronald E. Giachetti, Ph.D. Associate Professor Industrial and Systems Engineering, FIU 1

2

3

4

5

6

7

8

9

10 One Extreme Too much planning!

11 Another Extreme No planning!

12 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

13 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

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

15 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

16 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

17 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

18 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

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

20 Sample Probability/Impact Matrix Taken from IT Project Mgmt, 3 rd edition, Course Technology Publishing

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. Day 2 Module 8 Slide 21

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 22

23 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

24 Famous Software errors ATT Long Distance phone lines down for 9 hours in " (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

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

26 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

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) Day 3 Module 2 Slide 27

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? Day 3 Module 2 Slide 28

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 Day 3 Module 2 Slide 29

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 Day 3 Module 2 Slide 30

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 Day 3 Module 2 Slide 31

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 Day 3 Module 2 Slide 32

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 Day 3 Module 2 Slide 33

34 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