requirements engineering

67
1 Requirements Engineering Lesson 3 PROJECT MANAGEMENT

Upload: tricia

Post on 04-Jan-2016

42 views

Category:

Documents


0 download

DESCRIPTION

Requirements Engineering. Lesson 3 PROJECT MANAGEMENT. Project and Project Management. A project is a [temporary] sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by specific time, within budget, and according to specification. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Requirements Engineering

1

Requirements Engineering

Lesson 3

PROJECT MANAGEMENT

Page 2: Requirements Engineering

2

Project and Project Management

A project is a [temporary] sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by specific time, within budget, and according to specification.

Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.

Page 3: Requirements Engineering

3

Project versus Process Management

Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.

Process management is an ongoing activity that documents, manages the use of, and improves an organization’s chosen methodology (the “process”) for system development. Process management is concerned with the activities, deliverables, and quality standards to be applied to all projects.

Page 4: Requirements Engineering

4

Causes of Project Failure Failure to establish upper-management commitment to the project Lack of organization’s commitment to the system development

methodology Taking shortcuts through or around the system development

methodology Poor expectations management Premature commitment to a fixed budget and schedule Poor estimating techniques Overoptimism The mythical man-month (Brooks, 1975) Inadequate people management skills Failure to adapt to business change Insufficient resources Failure to “manage to the plan”

Page 5: Requirements Engineering

5

Project Manager Competencies

Business awareness Business partner orientation Commitment to quality Initiative Information gathering Analytical thinking Conceptual thinking Interpersonal awareness Organizational awareness

Anticipation of impact Resourceful use of influence Motivating others Communication skills Developing others Monitoring and controlling Self-confidence Stress management Concern for credibility Flexibility

(Adapted from Wysocki, Beck, and Crane, Effective Project Management: How to Plan, Manage, and Deliver Projects on Time

and within Budget.)

Page 6: Requirements Engineering

6

Project Management Functions

Scoping Planning Estimating Scheduling Organizing Directing       Controlling Closing

Page 7: Requirements Engineering

7

Measures of Project Success

The resulting information system is acceptable to the customer.

The system was delivered “on time.” The system was delivered “within

budget.” The system development process had

a minimal impact on ongoing business operations.

Page 8: Requirements Engineering

8

The Variables of Project Management

Can somewhat vary the following factors.

1. The total cost of the project,

e.g., increase expenditures

2. The capabilities of the product,

e.g., subtract from a list of features

3. The quality of the product,

e.g., increase the mean time between failure

4. The date on which the job is completed.

e.g., reduce the schedule by 20%

e.g., postpone project's completion date one month

Page 9: Requirements Engineering

9

Bullseye Figure for Project Variablescost

capability duration

defectdensity

Target :$70K

Target : 30 wks

Target : 4 defects/Kloc

Target:100%

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 10: Requirements Engineering

10

Bullseye Figure for Project Variablescost

capability duration

defectdensity

Target :$70K

Actual: 100%

Target : 30 wksTarget :

4 defects/Kloc

thisproject

Actual:1 defect/Kloc

Actual:20 wks

Actual:$90K

Target:100%

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 11: Requirements Engineering

11

A Road Map for Project Management Planning

1. Understand project content, scope, & time frame2. Identify development process (methods, tools, languages, documentation and support)

3. Determine organizational structure (organizational elements involved)

4. Identify managerial process (responsibilities of the participants)

6. Develop staffing plan

5. Develop schedule (times at which the work portions are to be performed)

7. Begin risk management

8. Identify documents to be produced

9. Begin process itself

Page 12: Requirements Engineering

12

Hierarchical Project Management Organizations

Larger Projects:Smaller Projects:No separate Marketing?No separate QA organization?

Subdivide QA into testing, …?Subdivide Engineering into

system engineering, …?Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 13: Requirements Engineering

13

Horizontal Project Management Organizations

Gil WarnerTeam leader

Ian CorlissTeam member

Nel TremontTeam member

Fran SmithTeam member

Team facilitator?

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 14: Requirements Engineering

14

Peer Organizations for Larger Projects

Team of leaders

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 15: Requirements Engineering

15

Organize a Team1. Select team leader: responsibilities:

ensure all project aspects active fill all gaps

3. Designate leader roles & document responsibilities team leader: proposes and maintains… SPMP configuration management leader: ... SCMP quality assurance leader: ... SQAP, STP requirements management leader: ... SRS design leader: ... SDD implementation leader: ... code base

2. Leaders’ responsibilities: propose a straw man artifact (e.g. SRS, design) seek team enhancement & acceptance ensure designated artifact maintained & observed maintain corresponding metrics if applicable

4. Designate a backup for each leader

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 16: Requirements Engineering

16

The Four Risk Activities

(1) Identification

Mindset: try to continually identify risks

(2) Retirement (Mitigation) planning

(3) Prioritization

(4) Retirement or mitigation

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 17: Requirements Engineering

17

Projectfinish

The Risk Management Mindset

Projectstart

Identification Retirement

2. “Java skills not high enough.”

1. “May not be possible to superimpose images adequately.”

1. Retirement by conquest: Demonstrate image super- imposition

Risk 1

Risk 2

Risk 1

Projectfinish

Risk 2

2. Retirement by avoidance: Use C++

Projectstart

Graphics reproduced with permission from Corel.Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 18: Requirements Engineering

18

*:in advance of first meeting M: at meeting **: between meetings

Identify and Mitigate Risks

1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success

2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader

3.* Team leader integrates and prioritizes results 4.M Group spends 10 mins. seeking additional risks 5.M Team spends 10 mins. finalizing the risk table

Designates responsible risk retirement engineers6.** Responsible engineers do risk retirement work7.M Team reviews risks for 10 mins. at weekly meetings

responsible engineers report progress team discusses newly perceived risks and adds them

Page 19: Requirements Engineering

19

Choosing development tools and support – [CASE Tools ]-

To support project management schedule work breakdown

To support configuration management

For managing requirements

For drawing designs functional object-oriented use-case-based

Tracing tools requirements to

designs designs to code

To support testing To support

maintenance

Page 20: Requirements Engineering

20

Creating schedules: high level planning

Methods Backward Planning Forward Planning

Page 21: Requirements Engineering

21

High Level Task Chart with Fixed Delivery Date:

Month 1

1 2 3 4

Month 2

1 2 3 4

Month 3

1 2 3 4

Month 4

1 2 3 4

Month 5

1 2 3 4

Milestones Delivery

SRS Complete

Iteration 1

Iteration 2

Freeze requirements

Risk identification & retirement

SCMP complete

SQAP complete

SPMP rel. 1 complete

Prep. for maintenance

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 22: Requirements Engineering

22

Create an Initial Schedule

1. Indicate the milestones your must observe usually includes delivery date

2. Back these up to introduce the milestones you need e.g., begin system testing well before delivery

3. Designate a time at which all requirements frozen

The remaining steps depend on the process used.

We will assume an iterative process.

4. Show first iteration: establishes minimal capability usually: keep it very modest, even trivial, in capability benefit: exercises the development process itself

5. Show task of identifying & retiring risks starting from project inception

6. Show unassigned time (e.g., week) near middle?

7. Complete the schedule

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 23: Requirements Engineering

23

Level Labor Allocation for Fixed Labor Total

Month 1

1 2 3 4

Month 2

1 2 3 4

Month 3

1 2 3 4

Month 4

1 2 3 4

Month 5

1 2 3 4

MilestonesRelease to production

Complete testing

Iteration 1

Iteration 2

Freeze requirements

Risk ID & retire

2 2 2 3 2 2 3

2 2 2 1 1 1

4 4 4 3 3 4

4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4

4 4 4 4 4

4 4

4

Given team size:

To be assigned4

Halvacation

Karenvacation

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 24: Requirements Engineering

24

Project Management Tools & Techniques

A PERT chart is a graphical network model that depicts a project’s tasks and the relationships between those tasks.

A Gantt chart is a simple horizontal bar chart that depicts project tasks against a calendar. Each bar represents a named project task. The tasks are listed vertically in the left-hand column. The horizontal axis is a calendar timeline.

Page 25: Requirements Engineering

25

PERT Chart

5-3-2001 5-12-2001

5-3-2001 5-11-2001

Preliminary Investigation

5-12-2001 6-12-2001

5-12-2001 6-14-2001

Problem Analysis

5-28-2001 7-15-2001

5-30-2001 7-18-2001

Requirements Analysis

6-13-2001 7-30-2001

6-13-2001 8-3-2001

Decision Analysis

9-10-2001 12-14-2001

TBD TBD

Implementation

7-19-2001 11-13-2001

7-20-2001 In Progress

Construction

7-3-2001 9-25-2001

7-5-2001 10-9-2001

Design

5-3-2001 N/A

5-3-2001 N/A

Project Initiation

ScheduledStart

ScheduledFinish

Actual Start ActualFinish

Task

ScheduledStart

ScheduledFinish

Actual Start ActualFinish

Task

intertaskdependency

Legend

Page 26: Requirements Engineering

26

Gantt Chart

Incomplete Task

Complete Task

Legend

ID

1

2

3

4

5

6

7

Preliminary investigation

Problem analysis

Requirements analysis

Decision analysis

Design

Construction

Implementation

May Jun Jul Aug Sep Oct Nov Dec

2001Task Name

Today

Page 27: Requirements Engineering

27

Microsoft Project Gantt Chart

Page 28: Requirements Engineering

28

Microsoft Project PERT Chart

Page 29: Requirements Engineering

29

Project Management Life Cycle

Page 30: Requirements Engineering

30

Joint Project Planning Strategy

Joint project planning (JPP) is a strategy wherein all stakeholders in a project (meaning system owners, users, analysts, designers, and builders) participate in a one-to-three day project management workshop, the result of which is consensus agreement on project scope, schedule, resources, and budget. (Of course, subsequent workshops or meetings may be required to adjust scope, budget, and schedule.)

Page 31: Requirements Engineering

31

Negotiate Scope

Scope defines the boundaries of a project—What part of the business is to be studied, analyzed, designed, constructed, implemented, and ultimately improved?

Product Quality Time Cost Resources

A statement of work is a narrative description of the work to be performed as part of a project. Common synonyms include scope statement, project definition, project overview, and document of understanding.

Page 32: Requirements Engineering

32

Statement of WorkI. PurposeII. Background

A. Problem, opportunity, or directive statementB. History leading to project requestC. Project goal and objectivesD. Product description

III. Scope(notice the use of your information system building blocks)A. StakeholdersB. DataC. ProcessesD. Locations

IV. Project ApproachA. RouteB. Deliverables

V. Managerial ApproachA. Team building considerationsB. Manager and experienceC. Training requirementsD. Meeting schedulesE. Reporting methods and frequencyF. Conflict managementG. Scope management (continued)

Page 33: Requirements Engineering

33

Statement of Work (concluded)

VI. ConstraintsA. Start dateB. DeadlinesC. BudgetD. Technology

VII. Ballpark EstimatesA. ScheduleB. Budget

VIII. Conditions of SatisfactionA. Success criteriaB. AssumptionsC. Risks

IX. Appendices

Page 34: Requirements Engineering

34

Identify Tasks

A work breakdown structure (WBS) is a hierarchical decomposition of the project into phases, activities, and tasks.

Milestones are events that signify the accomplishment or completion of major deliverables during a project.

Page 35: Requirements Engineering

35

Work Breakdown Structures1 Phase 1 of the project …2 Phase 2 of the project …

2.1 Activity 1 of Phase 2 …

2.2 Activity 2 of Phase 22.2.1 Task 1 of Activity

2.2 in Phase 22.2.2 Task 2 of Activity

2.2 in Phase 22.2.3 Task 3 of Activity

2.2 in Phase 22.3 Activity 3 of Phase 2

…3 Phase 3 of the project …

=

PROJECT

GOAL

0

PHASE

2

PHASE

3

PHASE

1

ACTIVITY

2.2

ACTIVITY

2.1

ACTIVITY

2.3

TASK

2.2.2

TASK

2.2.1

TASK

2.2.3

Page 36: Requirements Engineering

36

Estimate Task Durations

1.  Estimate the minimum amount of time it would take to perform the task. We'll call this the optimistic duration (OD).

2.  Estimate the maximum amount of time it would take to perform the task. We'll call this the pessimistic duration (PD).

3.  Estimate the expected duration (ED) that will be needed to perform the task.

4.  Calculate the most likely duration (D) as follows:

D = (1 x OD) + (4 x ED) + (1 x PD) 6

Page 37: Requirements Engineering

37

Specify Intertask Dependencies

Finish-to-start (FS)—The finish of one task triggers the start of another task.

Start-to-start (SS)—The start of one task triggers the start of another task.

Finish-to-finish (FF)—Two tasks must finish at the same time.

Start-to-finish (SF)—The start of one task signifies the finish of another task.

Page 38: Requirements Engineering

38

Entering Intertask Dependencies

Page 39: Requirements Engineering

39

Scheduling Strategies

Forward scheduling establishes a project start date and then schedules forward from that date. Based on the planned duration of required tasks, their interdependencies, and the allocation of resources to complete those tasks, a projected project completion date is calculated.

Reverse scheduling establishes a project deadline and then schedules backward from that date. Essentially, tasks, their duration, interdependencies, and resources must be considered to ensure that the project can be completed by the deadline.

Page 40: Requirements Engineering

40

A Project Calendar

Page 41: Requirements Engineering

41

Assign Resources

People—inclusive of all the system owners, users, analysts, designers, builders, external agents, and clerical help that will be involved in the project in any way, shape, or form.

Services—a service such as a quality review that may be charged on a per use basis.

Facilities and equipment—including all rooms and technology that will be needed to complete the project.

Supplies and materials—everything from pencils, paper, notebooks, toner cartridges, etc.

Money—A translation of all of the above into the language of accounting—budgeted dollars!

Page 42: Requirements Engineering

42

Defining Project Resources

Page 43: Requirements Engineering

43

Assigning Project Resources

Page 44: Requirements Engineering

44

Resource Leveling

Resource leveling is a strategy used to correct resource overallocations by some combination of delaying or splitting tasks.

There are two techniques for resource leveling:

task delaying task splitting

Page 45: Requirements Engineering

45

Task Splitting and Delaying

The critical path for a project is that sequence of dependent tasks that have the largest sum of most likely durations. The critical path determines the earliest possible completion date of the project.

Tasks that are on the critical path cannot be delayed without delaying the entire project schedule. To achieve resource leveling, critical tasks can only be split.

The slack time available for any noncritical task is the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.

Tasks that have slack time can be delayed to achieve resource leveling

Page 46: Requirements Engineering

46

Direct the Team Effort

Supervision resources The DEADLINE – A

Novel About Project Management

The One Minute Manager

The Care and Feeding of Monkeys

Stages of Team Maturity (see figure to the right)

Ÿ Establish structure and rulesŸ Clarify team member relationshipsŸ Identify responsibilitiesŸ Develop a plan to achieve goals

ORIENTATION STAGE

Ÿ Resolve interpersonal conflictŸ Further clarify rules and goalsŸ Develop a participative climate

INTERNAL PROBLEM-SOLVING STAGE

Ÿ Direct team activity toward goalsŸ Provide and get feedbackŸ Share ideas–growing cohesionŸ Individuals feel good about each other

GROWTH AND PRODUCTIVITY STAGE

Ÿ More feedback and evaluationŸ Adherence to team normsŸ Roles of team strengthenedŸ Strong team motivation to share goals

EVALUATION AND CONTROL STAGE

FORMING

STORMING

NORMING

PERFORMING

Page 47: Requirements Engineering

47

Monitor and Control Progress

Progress reporting Change management Expectations management Schedule adjustments—critical path

analysis (CPA)

Page 48: Requirements Engineering

48

Progress on a Gantt Chart

Page 49: Requirements Engineering

49

Critical Path Analysis (and Slack Time)

1. Using intertask dependencies, determine every possible path through the project.

2. For each path, sum the durations of all tasks in the path.3. The path with the longest total duration is the critical path.

The critical path for a project is that sequence of dependent tasks that have the largest sum of most likely durations. The critical path determines the earliest completion date of the project.

The slack time available for any noncritical task is the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.

Page 50: Requirements Engineering

50

Critical Path

The critical path is highlighted in red

TASKC

Fri 2/9/01 2 days

Fri 2/9/01 0 days

TASKD

Tue 2/20/017 days

Tue 2/20/010 days

TASKI

Tue 2/27/015 days

Tue 2/27/010 days

TASKE

Mon 2/19/016 days

Tue 2/20/011 day

TASKB

Wed 2/7/01 2 days

Wed 2/7/01 0 days

TASKA

Mon 2/5/01 3 days

Mon 2/5/01 0 days

TASKH

Thu 2/15/011 day

Tue 2/20/013 days

TASKF

Wed 2/14/013 days

Fri 2/16/01 2 days

TASKG

Fri 2/16/01 2 days

Tue 2/20/012 days

Duration

Slack Time

Page 51: Requirements Engineering

51

Sample Outline for a Progress Report

I. Cover PageA. Project name or identificationB. Project managerC. Date or report

II. Summary of progressA. Schedule analysisB. Budget analysisC. Scope analysis (describe any changes that may have an impact on future progress)D. Process analysis (describe any problems encountered with strategy or methodology)E. Gantt progress chart(s)

III. Activity analysisA. Tasks completed since last reportB. Current tasks and deliverablesC. Short term future tasks and deliverables

IV. Previous problems and issuesA. Action item and statusB. New or revised action items 1. Recommendation 2. Assignment of responsibility 3. Deadline

(continued)

Page 52: Requirements Engineering

52

Sample Outline for a Progress Report (concluded)

V. New problems and issuesA. Problems (actual or anticipated)B. Issues (actual or anticipated)C. Possible solutions 1. Recommendation 2. Assignment of responsibility 3. Deadline

VI. Attachments(include relevant printouts from project management software)

Page 53: Requirements Engineering

53

PowerPoint Alternative

Sample initial status report

Page 54: Requirements Engineering

54

May 30, 2000

Integrated Strategic Systems Plan

Two Week Status Report

Page 55: Requirements Engineering

55

The purpose of today's meeting:

Report on first two weeks Agree on hypothesis Agree of business issues Next step - detailed IT assessment

Page 56: Requirements Engineering

56

The project objective is to:

Develop an Integrated Strategic Systems Plan and Roadmap to enable attainment of NMMC Smyrna's manufacturing goals.

- Supported by a project plan detailing timing of investments, and impact on manufacturing capacity and effectiveness

Page 57: Requirements Engineering

57

The project scope is focused on the processes and technologies that drive manufacturing capacities, costs and

efficiencies. Process Scope

Manufacturing PlanningManufacturing SchedulingInventory Control/Materials ManagementCross-dock operations

Geographic ScopeFocus will be on the Smyrna operations

Potential Geographic Scope

Identification of potential impacts on Nissan North America Operations

Impact on Nissan Global processes and systems enablers

Time Scope

Two to three years to support Smyrna increased production goal

Page 58: Requirements Engineering

58

The study deliverables will be linked to the NMMC business strategies and processes.

Future I/TEnvironment

and Plan

Technology Governance ProcessesSkills

Current I/TEnvironment

MotorCo Corporate and Business Unit

Strategies and Processes Technology

Governance ProcessesSkills

Requirementsfor

Linkage

Best PracticesTechnologies& Solutions

Competitor's Technology

Gap ClosingMeasures

Potential Technology Usage

Deliverables:2-3 year strategic plan to align with Smyrna production goalsI/T infrastructure assessment

I/T Strategic Systems Plan - Time-phased Plan - Cost/Benefit Analysis

Page 59: Requirements Engineering

59

The work-plan is aggressive covering fourteen weeks we are on schedule for 18 August 2000

Steering Committee Reviews

1-2Steps Weeks 3-4 5-6 7-8 9-10 11-12 13-14

High Level Business Architecture Models

Manufacturing I/T Strategy

Manufacturing I/T Program Identification

Implementation Plan

Management Controls

Business Strategy Documentation

Initialization

I/T Assessment

We are here

Page 60: Requirements Engineering

60

sTs has committed the following resources to this project

Full Time : Engagement Manager & IT Strategist - Tony Sullivan Process Analyst - Kumar Bhatt IT Architect - Stephen Perun

Part Time: IT Strategy: Carl Straub IT Assessment: MotorCo IT Support

Page 61: Requirements Engineering

61

We are working under the following hypothesis

MotorCo intends to significantly increase it's North American production. The current information technology base will not allow increase in product mix, multiple plants or three shift operations

Systems are old and difficult to change Batch operation precludes real time

information Knowledge of some systems is "retiring"

Page 62: Requirements Engineering

62

The last two weeks was spent ......

We collected requirements from all the meetings and held a special meeting for your direct reports or representatives to gather their requirements (5/25): completing the current process understanding completing the current IT architecture map developing business requirements for the expanded production scope

Page 63: Requirements Engineering

63

Last week we met with four major areas of production control to understand the current process

Tuesday, 5/23 2:30-5:00 Production Planning Takeshi (Todd) Steve

Wednesday, 5/24 7:30-11:30 Production Scheduling Bill Roy D Bruce Mike

Wednesday, 5/24 1:00-5:00 Inventory Control Art Pete Tommy Bob Terry

Thursday, 5/25 7:30-11:30 Crossdock Art Pete Bob Beth L Melody Elmer H Greg J

Page 64: Requirements Engineering

64

Problem: We do not have a complete understanding of MotorCo's current Business Objectives to completely align a new IT Strategy

To properly align IT plans a complete understanding of Business Objectives is required........

Example: Increase production throughput

Optimizing throughput tends to group like units (Build to Plan)

e-business looks at order quantities of one.

Page 65: Requirements Engineering

65

Over the next two weeks we plan to meet with the following groups

PMCS (6/7) Bryan Dan t Earl Randy

Production Purchasing (6/9)

Financial Systems (6/8) Vince Bill Mary

Transportation

Decherd (6/8) Brent

Page 66: Requirements Engineering

66

Issues

None

Page 67: Requirements Engineering

67

Questions?