Systems Analysis and Design
With UML 2.0
An Object-Oriented Approach, Second Edition
Dennis, Wixom, and Tegarden, Wiley 2005
Chapter 4: Project Management
Copyright © 2005
John Wiley & Sons, Inc.
•
•
•
•
All rights reserved. Reproduction or translation of this work beyond that
permitted in Section 117 of the 1976 United States Copyright Act without
the express written permission of the copyright owner is unlawful.
Request for further information should be addressed to the Permissions
Department, John Wiley & Sons, Inc.
The purchaser may make back-up copies for his/her own use only and not
for redistribution or resale.
The Publisher assumes no responsibility for errors, omissions, or damages,
caused by the use of these programs or from the use of the information
contained herein.
2
Introduction
• Project Management (PM) has many definitions:
– Process of planning and controlling the development of
a system within a specified time frame at a minimum
cost with the proper functionality.
– Application of knowledge, skills, tools, and techniques
to project activities to meet project requirements
– Art of directing and coordinating human and material
resources throughout the project lifetime using modern
management techniques to achieve predetermined
objectives of scope, cost, time, quality, and participant
satisfaction
• PM makes trade-offs among three concepts
– The size of the system (in terms of what it does)
– The time to complete the project
– The cost of the project
3
• A project is defined as
– A temporary endeavor undertaken to create a unique
product, service, or result
– Any undertaking with a defined starting point and defined
objectives by which completion is defined
• A Project Manager has the primary responsibility
for managing the tasks & roles that need to be
coordinated.
• Critical factor for success is to start with a realistic
assessment of the work that needs to be done
• We’ll follow a four step process
–
–
–
–
Identify project size
Create and manage the workplan
Staff the project
Coordinate the project activities
4
Outline
1.
2.
3.
4.
5.
Identify project size
Create and manage the workplan
Staff the project
Coordinate the project activities
Examples & Case Studies
5
Step 1: Identify Project Size/Time
• Two basic ways to estimate the time
required to build a system
– Simple: Industry Standard Estimate
• Multiple of the time spent in the planning phase
– Complicated: Use Function Points
• Estimate system size
• Estimate effort required
• Estimate time required
6
Industry Standards Methods
• Predict total completion time based on the time
spent in the planning phase
• Industry standards for a typical system
–
–
–
–
15% Planning
20% Analysis
35% Design
30% Implementation
• If planning took X months, then the whole project
is expected to take X/.15 months
• Limitation: Is your system typical?
7
Example
Planning
Analysis
Design
Implementation
Typical
15%
Industry
Standard for
business
apps
20%
35%
30%
Time
required
Estimated:
5.33 months
Estimated:
Estimated:
9.33 months 8 months
Actual:
4 months
Total = 26.66 months
8
Function Points Method
• More sophisticated approach uses function points
– A function point is a measure of program size that is based on
the system’s number and complexity of inputs, outputs, queries,
files, and program interfaces
– Software oriented
• Three steps
– Estimate system size
•
•
•
•
Total Unadjusted Function Points (TUFP)
Adjusted Project Complexity (APC)
Total Adjusted Function Points (TAFP)
Convert function points to lines of code
– Estimate effort required
• Person-months
– Estimate time required
• Schedule-time
9
Estimate the system size
• Estimate the system size using function points
• A function point is a measure of program size
that is based on the system’s number and
complexity of inputs, outputs, queries, files, and
program interfaces
• Total Unadjusted Function Points (TUFP)
– List major elements of system
– Determine total number of each element
– Specify a complexity index of each component (low,
medium, high)
– Total index is multiplied by number of components to
compute the total unadjusted function points (TUFP)
10
Complexity
Description
Low
Medium
High
Total
Inputs
__x 3
__x 4
__x 6
____
Outputs
__x 4
__x 5
__x 7
____
Queries
__x 3
__x 4
__x 6
____
Files
__x 7
__x 10
__x 15
____
Program
Interfaces
__x 5
__x 7
__x 10
____
TOTAL UNADJUSTED FUNCTION POINTS
____
11
TUPF Example
12
• Adjusted Project Complexity (APC)
– Need to scale the function points because the
complexity of system is greater than sum of its parts.
– Method 1:
• Assess the impact of 14 additional factors to determine the
project complexity (PC)
• Compute the Adjusted Project Complexity
APC = .065 + (0.01 * PC)
– Method 2: Guess the APC
• 0.65 = Simple system
• 1.00 = Normal system
• 1.35 = complex system
• Total Adjusted Function Points (TAFP)
– TAFP = APC * TUFP
13
Adjusted Project Complexity
14
Function Point Estimation
Project Complexity (PC):
(From Step 2)
Adjusted Project
Complexity (PCA) =
__7______
0.65 + (0.001 * __7_ )
Total Adjusted
Function Points: _0.72 * _338_ = 243
(TUFP -- From Step 1)
15
Final Step
• Convert function points to lines of code
• Multiply function points to get approximate
lines of code in chosen language
• If you chose C, then 243 function Points
times 130 lines of code = 31,590 total lines
of code
16
Function Points to Lines of Code
Language
Lines of Code Per
Function Point
C
130
Cobol
110
Java
55
C++
50
Visual Basic
30
PowerBuilder
15
HTML
15
Packages (e.g. Access, Excel) 10-40
Source: Capers Jones, Software Productivity Research
17
Outline
1. Identify project size (function points)
•
Estimate system size
•
•
•
•
•
•
2.
3.
4.
5.
Total Unadjusted Function Points (TUFP)
Adjusted Project Complexity (APC)
Total Adjusted Function Points (TAFP)
Convert function points to lines of code
Estimate effort required (person-months)
Estimate time required (schedule-time)
Create and manage the workplan
Staff the project
Coordinate the project activities
Examples & Case Studies
18
Estimate the Effort Required
• Effort is a combination of system size and
production rates
• COCOMO model
– Converts a lines-of-code estimate into a personmonth estimate
– For moderate-size projects multiply thousands of lines
of code by 1.4 to get the number of person months
required to complete the project, i.e.
• Effort (person months) = 1.4 * lines of code (1000s)
– If LOC = 2000,
Effort = (1.4 * 2000) = 28 Person Months
19
Estimate the time required
• With effort established, we can now estimate the
schedule time
• Rule of thumb uses
– Schedule time (months) = 3.0 * person months1/3
• This is for analysis, design, and implementation.
It does not include planning.
• Example: if effort = 14 person months, the
schedule time should be 3 * 141/3 = 7 months
20
Outline
1.
2.
3.
4.
5.
Identify project size (function points)
Create and manage the workplan
Staff the project
Coordinate the project activities
Examples & Case Studies
21
Step 2: Creating the Workplan
• A dynamic schedule that records and tracks the tasks to
be accomplished over the course of the project
• Level of detail provided for each task depends on the
needs of the project
– Who will perform the work
– When completed
– Deliverables, etc
• Steps to create
–
–
–
–
–
Identify project tasks
Estimate task length
Organize and determine task dependencies
Specify to whom task will be assigned
List deliverables
22
Sample Workplan Information
Workplan Info
Task Name
Start Date
Completion Date
Person assigned
Deliverables
Completion status
Priority
Required resources
Estimated Time
Actual Time
Example
Perform eco feas
Jan 05, 2003
Jan 19, 2003
Project Sponsor: Mary Smith
Cost-Benefit Analysis
Open
High
Spreadsheet Software
16 Hours
14.5 Hours
23
Identifying Tasks
• Need to determine the tasks required to meet the
objectives listed on the system request.
• Method 1: Standard Methodologies
– Start with a standard list of tasks Select steps and
deliverables appropriate for the current project
– Most organizations will have a standard methodology
they use for all projects
• Method 2: Structured top-down approach
– Identify high level tasks
– Break them into increasingly smaller units
– Create the work breakdown structure
24
Work Breakdown Structure (WBS)
• A WBS is a list of the project tasks
– Specify high level tasks
– Break down each step into smaller tasks
– Number them in a hierarchical fashion
• WBS is the backbone of the project
workplan
• Number of tasks and level of detail
depends on the complexity of the project
• WBS can be organized in two ways
– SDLC phases
– Product Lines
25
WBS based on SDLC
Number Name
1
1.1
1.1.1
1.1.2
1.1.3
2
3
4
Dur Dep Status
Planning
Feasibility Analysis
Technical Feasibility
Economic Feasibility
Org. Feasibility
Analysis
Design
Implementation
26
WBS based on Product Lines
(Web Site Development)
Number Name
1
2
3
4
5
Dur Dep Status
Applets
Application Servers
Database servers
Sets of web pages
Site Map
27
WBS to Implement an IT Training Class
28
Project Workplan
• Primary tool for managing the project (i.e. tasks
in WBS)
– Determine if project is on schedule
– How well it was estimated
– Changes necessary to meet the deadline
• Lists information for all tasks in the WBS.
–
–
–
–
–
People assigned to perform the work
Estimated and actual time to complete
Current status (open, in progress, complete, etc)
Task dependencies
Key milestones
• Various formats
– Tabular (Expansion of the WBS)
– Gantt Chart
– PERT Chart
29
Gantt Chart
• Horizontal bar chart for workplan information
– Time laid out across the top
– Each task is a row
• Horizontal bar denotes the duration of the task.
• Bars are filled in to show the amount completed
– Upside-down triangles or diamonds denote a milestone
– Arrows between task bars show dependencies
– Names of people assigned to the task listed by task bar
• To limit the number of tasks, create a hierarchy of
Gantt charts for each level of detail
• Useful for determining
– Which tasks are on schedule
– How each task is progressing
– Which tasks will be active at the same time
30
31
PERT Chart
• Project Evaluation & Review Technique (PERT)
• Network flow graph for the workplan
–
–
–
–
–
Nodes represent tasks
Nodes contain time estimates
Arcs between nodes represent dependencies
Partially completed tasks have a diagonal line through the node
For completed tasks, the node is crossed out.
• PERT uses weighted average of three estimates:
– O = Optimistic, M = Most likely, P = Pessimistic
– PERT Average = (O + 4*M + P)/6
• Useful for
– Viewing task dependencies and identifying key tasks
– Finding critical path (longest from inception to completion)
32
Pert Chart
33
Refining Estimates
• Initial estimates are broad ranges that
must be refined throughout the SDLC to
– In planning phase, initial estimates based on
little knowledge of the system
– As we proceed through the SDLC, more
information is gathered and the system
concept is developed so the estimates
become more accurate and precise
• A well-done project plan has 100% margin
of error for project cost.
34
Error Margins
Phase
Deliverable
Typical Error Margins
Cost (%) Time (%)
Planning System Request
Project Plan
Analysis System
Proposal
Design
System
Specification
400
100
50
60
25
15
25
10
35
Missed Deadlines
• Case 1:
– Remaining tasks are simpler than task which missed its
deadline, so they will not miss their deadlines
– Remaining tasks are believed to be simpler than when the
schedule was made, so we can make up the lost time
– Do not change the schedule
• Case 2:
– Remaining tasks are simpler than task which missed its
deadline, so they will not miss their deadlines
– Remaining tasks are believed to be as complicated as when the
schedule was made, so we cannot make up the lost time
– Shift entire schedule by current delay (i.e. if deadline was missed
by 2 weeks, shift all remaining start and stop times by 2 weeks)
• Case 3:
– Remaining tasks are as complicated as task which missed its
deadline, so they will miss their deadlines
– Scale all time estimates (i.e. if the task duration was over by
25%, scale all remaining task times by 25%)
36
Scope Management
• Major reason for schedule and cost overruns is not poor
estimates, but rather from Scope Creep
• Scope creep occurs when new requirements are added
after project was defined and “frozen”
– Users may gain a better understanding of the system and find
new functionality that would be useful.
– Designers may get creative and want to explore new capabilities
– Management may want additional features
• Solutions
– Uncover and clarify all requirements early in SDLC through
prototypes that give users experience with the system and let
them visualize how it will support their needs
– Assess extra time and cost to implement new requirements
– Only allow changes for absolutely necessary requirements
– Postpone new functionality until later product version
– Time boxing
37
Time Boxing
• Most of the time, users only need a small
subset of the system’s features. These can
be provided relatively quickly.
• Instead of letting the requirements and tasks
drive the schedule, set the schedule and
provide only the functionality that can be
delivered in that time frame.
• Note:
– Deadline must be realistic
– Reduce functionality, but do not sacrifice quality
– Fewer “finishing touches”
38
Time Boxing Steps
1. Set the date for system delivery
2. Prioritize the functionality that needs to
be included in the system
3. Build the core of the system (the
functionality ranked as most important).
4. Postpone functionality that cannot be
provided within the time frame
5. Deliver the system with core functionality
6. Repeat steps 3 thru 5, to add refinements
and enhancements
39
WBS Problems
• They are too specific to the design of the system
being developed
– To create the WBS we need to decompose the system
design and tasks too soon
– If the problem domain is not well understood we may
need to commit to an architecture before the
requirements are understood
• Detail level
– Too many levels of detail too early in the SDLC for
large projects
– Too few level for small projects.
• Since they are project specific, they can be very
difficult to compare across projects
– Difficult to learn from previous projects managed by
40
Evolutionary WBS
• Addresses problems by allowing the development
of an iterative workplan
• Evolutionary WBS
– Organize in a standard manner across all projects: by
workflows, phases, then tasks
• Decouples the structure of the WBS from the structure of the
project, so we do not need to commit to a system architecture
– Create in an incremental and iterative manner
• First evolutionary WBS done with initial aspects of the project
which are well understood
• Later on more details are added to the WBS.
• This encourages a more realistic view of cost and schedule
estimates
– Comparable to earlier projects based on cost and
schedule estimation
41
Outline
1.
2.
3.
4.
5.
Identify project size (function points)
Create and manage the workplan
Staff the project
Coordinate the project activities
Examples & Case Studies
42
Staff The Project
• Determining number of people for the
project
• Matching people’s skills with project needs
• Motivating people to meet project
objectives
• Minimizing conflicts
43
Staffing Plan
• Determine who will work on the project
• Staffing Levels
– Num people = total effort (person months) divided by opt schedule
– Increasing staff does not necessarily shorten the project’s length
because more people are harder to coordinate and manage, i.e.
adding staff may add more overhead than additional labor
– Teams of 8-10 reporting in a hierarchical structure can reduce
complexity
• Reporting Structure
– Project Manager oversees overall progress of the development effort
– Functional Lead manages a group of analysts
– Technical Lead oversees progress of programmers & technical staff
• With roles and reporting structure in place, assign people
– Consider both technical and interpersonal skills
– One person can fill multiple roles
• Staffing levels will change over a project’s lifetime
44
Possible Reporting Structure
45
Motivation
• Use monetary rewards cautiously
• Use intrinsic rewards
– Recognition
– Achievement
– The work itself
– Responsibility
– Advancement
– Chance to learn new skills
46
Handling Conflict
• Group cohesiveness contributes more to
productivity than the capabilities and experience
of individual project members
• Conflict avoidance strategies
– Clearly define roles and responsibilities
– Hold individuals accountable
– Establish ground rules and operating procedures
• How the group will communicate with each other
• Procedures for updating the work plan
– Develop schedule commitments ahead of time
– Forecast other priorities and their possible impact on
the project
47
Outline
1.
2.
3.
4.
5.
Identify project size (function points)
Create and manage the workplan
Staff the project
Coordinate the project activities
Examples & Case Studies
48
Coordinate the Project Activities
• Need to put in place efficient development
practices and mitigate risk
• Case Tools
• Standards
• Documentation
• Risk Management
49
CASE Tools
• Computer Aided Systems Engineering
(CASE)
• Benefits
– Tasks are easier and quicker
– Development information is located in a
central repository
– Standardized documentation (typically in
diagrams)
– Can reduce costs and improve quality
• Need training and experience to achieve
benefits
50
CASE Tools
Initiation
Analysis
Upper CASE
Design
Implementation
Lower CASE
Integrated CASE (I-CASE)
51
CASE Components
Diagrams
Screen
Designs
CASE Repository
Procedural
Logic
Metadata
52
• Create standards the project team must follow
–
–
–
–
Formal rules for naming files
Forms indicating goals reached
Programming guidelines
Documentation standards
• Document early and often
– Good doc practices are essential to any project
– Developers will move in and out of the project
– Document the system as it evolves while it is fresh in
your mind
• Risk assessment
– Track and re-evaluate risk throughout the SDLC
– Scope creep, personnel issues, schedule problems
53
Classic Mistakes
• Overly optimistic schedule
– Use realistic estimates & include slack time at end of
each phase
• Failing to monitor schedule
– Schedule regular progress reports, otherwise you will not
know if the project is on schedule.
• Failing to update schedule
– If team falls behind, do not assume you can make up
time. This may be a sign the schedule was too optimistic
– Revise the schedule or use time boxing
• Adding people to a late project
– Increases coordination problems
– Slows development while new members are trained
– Revise the schedule or use time boxing
54
Summary
• Project management is critical to
successful development of new systems
• Project management involves planning,
controlling and reporting on time, labor,
and costs.
• For more detail on project management,
visit the project management institute at
– http://www.pmi.org
55
Outline
1.
2.
3.
4.
5.
Identify project size (function points)
Create and manage the workplan
Staff the project
Coordinate the project activities
Examples & Case Studies
56
Case Study:
CD Selections
57
CD Selections
• Short deadline so phased development with time
boxing to ensure some version of the product
would be in place in time (although full system
might come later)
• Project size
–
–
–
–
–
–
Estimated components to get TUFP = 158
Estimated APC factor at 1.2, so TAFP = 190
Lines of code equal 19,200
COCOMO formula 1.5 x 19.2 = 27 person months
Schedule time equals 3 x 271/3 = 9 months
Pad by 10% so 10 months
• Workplan
– Used an in-house evolutionary WBS (Fig 4-22)
• Staffing
– 27 person months/ 10 month deadlin = 3 people
58
CD: Function Points
Description
Complexity
Num
Low
Medium
Total
High
Inputs
6
0x3
4x4
2x6
28
Outputs
7
2x4
4x5
1x7
35
Queries
8
3x3
4 x4
1x6
31
Files
4
0x7
4 x 10
0 x 15
40
Program
3
0x5
2x7
1 x 10
Interfaces
Total Unadjusted Function Points (TUFP)
24
Adjusted Project Complexity
1.2
Total Adjusted Function Points (TAFP)
190
158
59
CD: Staffing Plan
Role
Description
Person
Project
Manager
Oversees project to make sure it meets objectives Alec
in time and within budget
Infrastructur
e Analyst
Ensures system conforms to infrastructure
Ian
standards & infrastructure can support the system
Systems
Analyst
Designs system: Focus on interface with
distribution system
Ian
Systems
Analyst
Designs system: Focus on analysis models and
interface design
K.C.
Systems
Analyst
Designs system: Focus on analysis models and
performance
Anne
Programmer Codes the system
K.C.
Programmer Codes the system
Anne
Reporting Structure: All team members report to Alec
60
CD: Project Charter
• Project Objectives
– The project team will create a working web-based
system to sell CDs in time for the holiday season
• The internet order team members will:
– Attend a staff meeting each Friday at 2 pm to report on
the status of the assigned tasks
– Update the workplan with actual data by Fridays at 5 pm
– Discuss problems with Alec as soon as they are
detected
– Support each other when help is needed, especially for
critical tasks that could delay the progress of the project
– Post important changes to the project on the team
bulletin board as they are made
61