Requirements Engineering - PowerPoint PPT Presentation

Loading...

PPT – Requirements Engineering PowerPoint presentation | free to view - id: 25a4c0-NmM5Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Requirements Engineering

Description:

Construction. 7-3-2001. 9-25-2001. 7-5-2001. 10-9-2001. Design. 5-3-2001. N/A. 5-3-2001. N/A ... IX. Appendices. 34. Identify Tasks ... – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0
Slides: 68
Provided by: bost75
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Requirements Engineering


1
Requirements Engineering
  • Lesson 3
  • PROJECT MANAGEMENT

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.

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
    organizations chosen methodology (the process)
    for system development. Process management is
    concerned with the activities, deliverables, and
    quality standards to be applied to all projects.

4
Causes of Project Failure
  • Failure to establish upper-management commitment
    to the project
  • Lack of organizations 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

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.)
6
Project Management Functions
  • Scoping
  • Planning
  • Estimating
  • Scheduling
  • Organizing
  • Directing      
  • Controlling
  • Closing

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.

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

9
Bullseye Figure for Project Variables
cost
Target 70K
Target 100
capability
duration
Target 30 wks
Target 4 defects/Kloc
defect density
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
10
Bullseye Figure for Project Variables
cost
Target 70K
Target 100
Actual 90K
Actual 100
this project
capability
duration
Target 30 wks
Target 4 defects/Kloc
Actual 20 wks
Actual 1 defect/Kloc
defect density
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
11
A Road Map for Project Management Planning
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.
13
Horizontal Project Management Organizations
Ian Corliss Team member
Gil Warner Team leader
Nel Tremont Team member
Team facilitator?
Fran Smith Team member
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
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.
15
Organize a Team
  • 1. 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

One way to ...
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
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.
17
The Risk Management Mindset
Identification
Retirement
2. Java skills not high enough.
2. Retirement by avoidance Use C
Project finish
Project finish
Risk 2
Risk 2
Risk 1
Risk 1
1. Retirement by conquest Demonstrate image
super- imposition
1. May not be possible to superimpose images
adequately.
Project start
Project start
Graphics reproduced with permission from Corel.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
18
Identify and Mitigate Risks
One way to ...
  • 1. Each team member spends 10 mins. exploring
    his or her greatest fears for the projects
    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 engineers
  • 6. Responsible engineers do risk retirement
    work
  • 7.M Team reviews risks for 10 mins. at weekly
    meetings
  • responsible engineers report progress
  • team discusses newly perceived risks and adds them

in advance of first meeting M at
meeting between meetings
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

20
Creating schedules high level planning
  • Methods
  • Backward Planning
  • Forward Planning

21
High Level Task Chart with Fixed Delivery Date
Month 1
Month 2
Month 3
Month 4
Month 5
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
SRS Complete
SCMP complete
SQAP complete
Milestones
Delivery
SPMP rel. 1 complete
Freeze requirements
Iteration 1
Iteration 2
Risk identification retirement
Prep. for maintenance
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
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.
23
Level Labor Allocation for Fixed Labor Total
Month 1
Month 2
Month 3
Month 4
Month 5
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
1
2
3
4
Milestones
Complete testing
Freeze requirements
Release to production
Karen vacation
2
2
2
3
2
2
3
Iteration 1
Hal vacation
4
4
4
3
3
4
4
4
4
4
4
4
Iteration 2
2
2
2
1
1
1
4
To be assigned
Risk ID retire
4
4
4
4
4
3
3
4
4
4
4
3
3
4
4
4
4
4
4
4
Given team size
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
24
Project Management Tools Techniques
  • A PERT chart is a graphical network model that
    depicts a projects 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.

25
PERT Chart
Project Initiation
Legend
5-3-2001
N/A
Task
Task
5-3-2001
N/A
Scheduled
Scheduled
Scheduled
Scheduled
intertask
Start
Finish
Start
Finish
dependency
Actual
Actual
Actual Start
Actual Start
Finish
Finish
Preliminary Investigation
5-3-2001
5-12-2001
5-3-2001
5-11-2001
Problem Analysis
Requirements Analysis
Decision Analysis
5-28-2001
7-15-2001
6-13-2001
7-30-2001
5-12-2001
6-12-2001
5-30-2001
7-18-2001
6-13-2001
8-3-2001
5-12-2001
6-14-2001
Construction
Design
7-19-2001
11-13-2001
7-3-2001
9-25-2001
7-20-2001
In Progress
7-5-2001
10-9-2001
Implementation
9-10-2001
12-14-2001
TBD
TBD
26
Gantt Chart
27
Microsoft Project Gantt Chart
28
Microsoft Project PERT Chart
29
Project Management Life Cycle
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.)

31
Negotiate Scope
  • Scope defines the boundaries of a projectWhat
    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.

32
Statement of Work
  • I. Purpose
  • II. Background
  • A. Problem, opportunity, or directive statement
  • B. History leading to project request
  • C. Project goal and objectives
  • D. Product description
  • III. Scope
  • (notice the use of your information system
    building blocks)
  • A. Stakeholders
  • B. Data
  • C. Processes
  • D. Locations
  • IV. Project Approach
  • A. Route
  • B. Deliverables
  • V. Managerial Approach
  • A. Team building considerations
  • B. Manager and experience
  • C. Training requirements

33
Statement of Work (concluded)
  • VI. Constraints
  • A. Start date
  • B. Deadlines
  • C. Budget
  • D. Technology
  • VII. Ballpark Estimates
  • A. Schedule
  • B. Budget
  • VIII. Conditions of Satisfaction
  • A. Success criteria
  • B. Assumptions
  • C. Risks
  • IX. Appendices

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.

35
Work Breakdown Structures
  • 1 Phase 1 of the project
  • 2 Phase 2 of the project
  • 2.1 Activity 1 of Phase 2
  • 2.2 Activity 2 of Phase 2
  • 2.2.1 Task 1 of Activity 2.2 in Phase 2
  • 2.2.2 Task 2 of Activity 2.2 in Phase 2
  • 2.2.3 Task 3 of Activity 2.2 in Phase 2
  • 2.3 Activity 3 of Phase 2
  • 3 Phase 3 of the project


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

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.

38
Entering Intertask Dependencies
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.

40
A Project Calendar
41
Assign Resources
  • Peopleinclusive 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.
  • Servicesa service such as a quality review that
    may be charged on a per use basis.
  • Facilities and equipmentincluding all rooms and
    technology that will be needed to complete the
    project.
  • Supplies and materialseverything from pencils,
    paper, notebooks, toner cartridges, etc.
  • MoneyA translation of all of the above into the
    language of accountingbudgeted dollars!

42
Defining Project Resources
43
Assigning Project Resources
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

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

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)

47
Monitor and Control Progress
  • Progress reporting
  • Change management
  • Expectations management
  • Schedule adjustmentscritical path analysis (CPA)

48
Progress on a Gantt Chart
49
Critical Path Analysis (and Slack Time)
  • Using intertask dependencies, determine every
    possible path through the project.
  • For each path, sum the durations of all tasks in
    the path.
  • 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.

50
Critical Path
51
Sample Outline for a Progress Report
  • I. Cover Page
  • A. Project name or identification
  • B. Project manager
  • C. Date or report
  • II. Summary of progress
  • A. Schedule analysis
  • B. Budget analysis
  • C. 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 analysis
  • A. Tasks completed since last report
  • B. Current tasks and deliverables
  • C. Short term future tasks and deliverables
  • IV. Previous problems and issues
  • A. Action item and status
  • B. New or revised action items
  • 1. Recommendation
  • 2. Assignment of responsibility




52
Sample Outline for a Progress Report (concluded)
  • V. New problems and issues
  • A. 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)




53
PowerPoint Alternative
  • Sample initial status report

54

Two Week
Status Report
Integrated Strategic Systems Plan
May 30, 2000
55
The purpose of today's meeting
  • Report on first two weeks
  • Agree on hypothesis
  • Agree of business issues
  • Next step - detailed IT assessment

56
The project objective is to
57
The project scope is focused on the processes and
technologies that drive manufacturing capacities,
costs and efficiencies.
58
The study deliverables will be linked to the NMMC
business strategies and processes.
59
The work-plan is aggressive covering fourteen
weeks we are on schedule for 18 August 2000
We are here
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

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"

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

63
Last week we met with four major areas of
production control to understand the current
process
  • Tuesday, 5/23 230-500 Production Planning
  • Takeshi (Todd)
  • Steve
  • Wednesday, 5/24 730-1130 Production
    Scheduling
  • Bill
  • Roy D
  • Bruce
  • Mike
  • Wednesday, 5/24 100-500 Inventory Control
  • Art
  • Pete
  • Tommy
  • Bob
  • Terry

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.

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

66
Issues
  • None

67
Questions?
About PowerShow.com