Chapter 2: Project Management

Ronald J. Leach

Copyright Ronald J. Leach, 1997, 2009,

1
2014, 2015
 Project Management
• Soft skills
– motivating people
• Hard skills
– making plans
– obtaining and managing resources
– setting deadlines
– quality control

Copyright Ronald J. Leach, 1997, 2009,

2
2014, 2015
 Every Project Has
Stakeholders Resources
Schedules Organization
Coordination Communication
Deliverables Documentation
Risk Life cycle

Each of these must be managed

Copyright Ronald J. Leach, 1997, 2009,

3
2014, 2015
 Sub-teams
Systems Analysis Team Planning Team
Requirements Team System Design Team
Implementation Team Testing and Integration
Team
Training Team Delivery & Installation
Team
Maintenance Team Quality Assurance Team
Metrics Team Documentation Team
System Administration Reuse & Reengineering
Team Team

Copyright Ronald J. Leach, 1997, 2009,

4
2014, 2015
 Some Specific Activities
• Managing people
• Allocating resources
• Defining roles
• Motivating project personnel
• Dealing with inevitable slippage in the
schedule

Copyright Ronald J. Leach, 1997, 2009,

5
2014, 2015
 Some Specific Activities, cont.
• Handling changes in requirements
• Handling changes in designs
• Handling changes in code
• Handling changes in anything, while
maintaining consistency
– Operating systems, databases, APIs, IDEs,
COTS products, components, …

Copyright Ronald J. Leach, 1997, 2009,

6
2014, 2015
 Some Specific Activities, cont.
• Measuring system progress and quality
• Reacting to unexpected events
• Informing upper level management
• Ensuring proper reviews of major milestones
• Interacting with prospective customer or
customer representatives

Copyright Ronald J. Leach, 1997, 2009,

7
2014, 2015
Project Cost Estimation

Copyright Ronald J. Leach, 1997, 2009,

8
2014, 2015
 Estimating Project Costs
• Bigger projects are more expensive
• Complex projects are more expensive
• “Experience databases” can be helpful in
estimating costs

Copyright Ronald J. Leach, 1997, 2009,

9
2014, 2015
 Work Breakdown Structure
• Examine the list of detailed requirements.
• For each requirement, estimate the effort
needed to implement the requirement.
• Ignore any requirements for which an existing
component can be reused as is.
• Compute the total of all new lines of code.

Copyright Ronald J. Leach, 1997, 2009,

10
2014, 2015
 COCOMO Model (Boehm)
Effort
• E = ab * K * exp(bb)

Development Time
• D = cb * E * exp(db)

• Constants depend on software project type

Copyright Ronald J. Leach, 1997, 2009,
11
2014, 2015
 COCOMO Model (Boehm), cont.
Project type ab bb cb db
“Small” 2.4 1.05 2.5 0.38
“Embedded” 3.6 1.2 2.5 0.32
“Intermediate” 3.0 1.12 2.5 0.35

COCOMO has been extended to COCOMO 2

(Constants are determined empirically)

Copyright Ronald J. Leach, 1997, 2009,

12
2014, 2015
Project Scheduling

Copyright Ronald J. Leach, 1997, 2009,

13
2014, 2015
 Project Scheduling
Team sizes vary over time

Copyright Ronald J. Leach, 1997, 2009,

14
2014, 2015
 Typical milestone chart for
waterfall development

A typical milestone chart for a software project with multiple releases, following
the classical waterfall software development process.
Copyright Ronald J. Leach, 1997, 2009,
15
2014, 2015
 Ideas
and Tools

Copyright Ronald J. Leach, 1997, 2009,

16
2014, 2015
 Ideas and Tools
• Coordination
• Groupware

Copyright Ronald J. Leach, 1997, 2009,

17
2014, 2015
 Some useful ideas
• Standard format for graphical files.
• Make sure that the format is compatible with
the browser to be used.
• Mechanism for feedback about deficiencies in
on-line documents.
• Make on-line documents subject to
configuration management and revision
control.
Copyright Ronald J. Leach, 1997, 2009,
18
2014, 2015
 Some useful ideas, cont.
• Use reviews and inspections.
• Use e-mail to coordinate meetings and to
notify members of the project team that
documents have been changed.
• Use “chat rooms” for project management.
• Use wikis for concurrent access to documents
by multiple users if appropriate.

Copyright Ronald J. Leach, 1997, 2009,

19
2014, 2015
 Groupware
• Use this if it is available to all and has been
installed and tested.
• Either free or commercial groupware can be
used.
• Google Docs?

Copyright Ronald J. Leach, 1997, 2009,

20
2014, 2015
Project Life Cycles

Copyright Ronald J. Leach, 1997, 2009,

21
2014, 2015
 Project Life Cycles
• Classical Waterfall Model
• Rapid Prototyping Model
• Spiral Model
• Market-Driven Model
• Open Source Model
• Agile Development Model

Copyright Ronald J. Leach, 1997, 2009,

22
2014, 2015
The classical waterfall model
SPECIFICATION

DESIGN

CODE

TESTING AND INTEGRATION

MAINTENANCE

Copyright Ronald J. Leach, 1997, 2009,

23
2014, 2015
Copyright Ronald J. Leach, 1997, 2009,
24
2014, 2015
 The rapid prototyping model
• Assumes that, unlike the waterfall model,
requirements are not completely known in
advance.
• Requirements are developed in an iterative
manner, along with prototypes that are
created iteratively.
• An initial set of requirements is created in
order to create the first prototype.

Copyright Ronald J. Leach, 1997, 2009,

25
2014, 2015
 The rapid prototyping model, cont.
Initial
specific Develop prototype
ations

Create new
specifications

Test and Evaluate

integrate prototype
prototype

System

Copyright Ronald J. Leach, 1997, 2009,

26
2014, 2015
The spiral model

Copyright Ronald J. Leach, 1997, 2009,

27
2014, 2015
 The spiral model, one quadrant
Goals, objectives Evaluate

Analyze risks

Prototype
Analyze
risks
Prototype

Prototype

Initial plans Requirements

Design Code
Copyright Ronald J. Leach, 1997, 2009,
28
2014, 2015
 Prototype

The spiral model, one quadrant

Analyze
risks
Prototype

Prototype

Initial plans Requirements

Design Code

New plans Validate

design Test

System
integration

Plan Develop

Copyright Ronald J. Leach, 1997, 2009,

29
2014, 2015
 Prototype

The spiral model, one quadrant

Analyze
risks
Prototype

Prototype

Initial plans Requirements

Design Code

New plans Validate

design Test

System
integration

Plan Develop

Copyright Ronald J. Leach, 1997, 2009,

30
2014, 2015
The spiral model, one quadrant
Goals, objectives Evaluate

Analyze risks

Prototype
Analyze
risks
Prototype

Prototype

Initial plans Requirements

Design Code

Copyright Ronald J. Leach, 1997, 2009,

31
2014, 2015
 Open-Source Projects
• All source code is freely available
• Repositories must be managed
• A select group of experts often is used to
determine quality

Copyright Ronald J. Leach, 1997, 2009,

32
2014, 2015
Case Study: Project Management
for Agile Processes

Copyright Ronald J. Leach, 1997, 2009,

33
2014, 2015
 Agile Processes – the Team
• It all starts with the team
– Small – seven members
– Highly experienced in the application domain
(spacecraft and satellite control systems)
– Worked well together
– Charismatic leader
– Excellent relationship with upper-level
management
Copyright Ronald J. Leach, 1997, 2009,
34
2014, 2015
Agile Processes – the Management
• Highly supportive
• Trusted the team
• Had the same goals
– More
– Better
– Cheaper
– Faster

Copyright Ronald J. Leach, 1997, 2009,

35
2014, 2015
 Agile Processes – the Customers
• Really wanted
– More
– Better
– Cheaper
– Faster

Copyright Ronald J. Leach, 1997, 2009,

36
2014, 2015
 Agile Processes - The context
• The seven-member team was part of a larger
effort in which multiple teams and internal
organizations competed to get their ideas
implemented.
• Multi-year effort

Copyright Ronald J. Leach, 1997, 2009,

37
2014, 2015
 Goal: Improve the Team’s
Self-Organizing Factor (SOF)
SOF =
(management + external test)
/
( management + systems engineering +
requirements gathering + implementation +
internal test + external test + maintenance +
system administration + documentation)

Copyright Ronald J. Leach, 1997, 2009,

38
2014, 2015
 Why improve the SOF?

Self-organizing factor (SOF) for development of eight projects.

Copyright Ronald J. Leach, 1997, 2009,

39
2014, 2015
 Why improve the SOF?
• Because projects with a low SOF made greater
improvements in costs and greater reduction
of testing costs

Copyright Ronald J. Leach, 1997, 2009,

40
2014, 2015
Configuration Management

Copyright Ronald J. Leach, 1997, 2009,

41
2014, 2015
 Configuration Management
• Necessary to coordinate team activities

Copyright Ronald J. Leach, 1997, 2009,

42
2014, 2015
Configuration Management
• Every non-trivial software system or
component is developed under Software
Configuration Management (SCM).
• Most software development environments,
especially CASE tools, provide support for
SCM.
• SCM can provide insight into component or
system quality.

Copyright Ronald J. Leach, 1997, 2009,

43
2014, 2015
The SCM Process
• Includes identification of the elements
of every software configuration, both
before and after release?
• Helps manage all versions of a system
(both active and pre-release)
• How does an organization control
changes before and after software is
released to a customer?
• How are changes approved?

Copyright Ronald J. Leach, 1997, 2009,

44
2014, 2015
The SCM Process, cont.
• How can we ensure that changes have
been made properly?
• How are users and developers notified
of changes?

Copyright Ronald J. Leach, 1997, 2009,

45
2014, 2015
SCM, cont.
• The first widely accepted SCM system was
developed by Marc Rochkind.
• It was called SCCS, for Source Code Control
System, and worked on UNIX environments.
• Source code components to be developed
were placed in a special directory named
SCCS.

Copyright Ronald J. Leach, 1997, 2009,

46
2014, 2015
SCM, cont.
• Developers could work on components
separately.
– Developers had to check components out,
blocking others from working on it.
– Files were stored as an original file, with a set of
incremental changes.
– The SCCS software showed the developers the
latest version by default.
– Developers could work on any earlier version, if
they found errors later.
Copyright Ronald J. Leach, 1997, 2009,
47
2014, 2015
SCM, cont.
• The number of changes provided insight into
the volatility of the software.
• Too many changes often meant overly
complex software.
• The UNIX prs utility allowed the changes made
to a system developed under SCCS to be
analyzed for certain patterns that indicated
potential testing problems.

Copyright Ronald J. Leach, 1997, 2009,

48
2014, 2015
SCM, cont.
• The system worked well for projects of
moderate size that were to be hosted on a
single computer.
– SCCS directories usually were hosted on a
single computer!
• The process became unwieldy in larger, more
distributed development environments.
• Marc Rochkind himself moved to RCS
(Revision Control System)
Copyright Ronald J. Leach, 1997, 2009,
49
2014, 2015
SCM, cont.
• SCCS and several of the early SCM systems
were fine stand-alone systems, but did not
integrate well with modern development
practices.
• Data was hard to link directly to databases.
• Hard to link to the cause of software problems
that cut across several products, as is common
in software product-line architectures.

Copyright Ronald J. Leach, 1997, 2009,

50
2014, 2015
SCM, cont.
• One of the newer SCM systems is Razor, produced by
Visible Systems.
• This tool can be used either stand-alone, or as an
integrated part of a larger system.
• For example, Razor can be integrated with any set of
files that are under a source code control system
that is Microsoft-compliant.

Copyright Ronald J. Leach, 1997, 2009,

51
2014, 2015
The Razor SCM Tool

Copyright Ronald J. Leach, 1997, 2009,

52
2014, 2015
The Razor SCM Tool, cont.

Copyright Ronald J. Leach, 1997, 2009,

53
2014, 2015