Project Management for
Modern Software Development
Keeping Manager Activities up to date with Technology
Timothy Korson
Southern Adventist University
Software Project Management
Direct
Restricted Use
This copyrighted material is provided to attendees of courses taught by
Timothy Korson under a restricted licensing agreement exclusively for
the personal use of the attendees. Dr. Korson retains ownership rights
to the material contained in these course notes.
Please respect these rights.
Copyright © 2008 Timothy D. Korson. All rights reserved.
Version 1.5
3 -263
Successful Project Management
“Why do some companies succeed in managing objectoriented projects and others fail? Most companies prepare
their technical staffs by sending them to language and
object-oriented analysis and design classes. Unfortunately,
these same companies often ignore the training needs of
managers who’ll be directing these technical staffs.
Managers are left to fend for themselves, armed with
yesterdays tools with little insight into the potential of
today’s technologies.”
John D. Williams
“Managing Iteration in Object Oriented Projects”
IEEE Computer, September 1996, p. 39
4 -263
Tutorial Prerequisites
 This course assumes previous project management
experience either as Project Manager or Project Team
Member.
 This course is not an in-depth introduction to project
management activities. Rather, it generally focuses on
the differences in project management between
classical, procedural software development and object
oriented software development.
For an excellent compilation of information on
general project management see the Project
Management Body of Knowledge published by the
Project Management Institute. Information on it
can be found at www.pmi.org
5 -263
Recommended Reading
Addison Wesley
ISBN-0-201-30958-0
6 -263
Course Objectives
 Be a more effective project manager or
team member of a modern software
development project.
 Understand the differences between
modern and classical project management.
 Effectively use an iterative/ incremental
software development life cycle.
7 -263
Course Objectives
 Perform these project management activities
for object oriented software development:
Manage risk
Planning the work
Measure the project
Resource planning
Ensure quality
Foster reuse
Communicate with stakeholders
Manage the project team
8 -263
Table Of Contents
Chapter 1 Introduction To Project
Management
Chapter 2 Modern Software Engineering:
Activities, Principles, and Processes
Chapter 3 Direct Project Management Issues
Chapter 4 Pitfalls Of Modern Development
Chapter 5 Summing it up
9 -263
Chapter 1
Introduction To
Project Management
10 -263
Chapter Objectives
 At the end of this chapter you will be able
to:
 List the top 10 Principles of Modern
Software Management
 Define Project, Stakeholder, and Project
Management.
 Give examples of why software development
projects fail.
11 -263
Top 10 Principles of Modern Software
Management
Direct
1. Base the process on an architecture first approach.
2. Establish an iterative lifecycle process that confronts risk early.
3. Transition design methods to emphasize component-based
development.
4. Establish a change management environment.
5. Enhance change freedom through tools that support round-trip
engineering.
6. Capture design artifact in rigorous, model-based notation.
7. Instrument the process for objective quality control and progress
assessment.
8. Use a demonstration-based approach to assess intermediate
artifacts.
9. Plan intermediate releases in groups of usage scenarios with
evolving levels of detail.
10. Establish a configurable process that is economically scalable.
State your conclusions first.
Royce
12 -263
Definitions
 Project
Define
 Stakeholder
 Project Management
13 -263
Project
 Organizations perform work. This work is
done by people; constrained by limited
resources; and planned, executed, and
controlled.
Operations
Project
• Ongoing
• Temporary
• Repetitive
• Unique
14 -263
Project
 A project is a temporary endeavor undertaken
to create a unique product or service.
Define
 Temporary means that every project has a
definite beginning and a definite end.
 The end is reached when the project’s
objectives have been met or when it becomes
clear that the objectives will not or can not be
met and the project is terminated.
15 -263
Project
 Projects involve doing something that has not been
done before and are therefore unique.
 The presence of repetitive elements does not change
the fundamental uniqueness.
 “Because the product of each project is unique, the
characteristics that distinguish the product or service
must be progressively elaborated. Progressively
means ‘proceeding in steps; continuing steadily by
increments’ while elaborated means ‘worked out
with care and detail; developed thoroughly.’”
[Project Management Body Of Knowledge www.pmi.org]
16 -263
Stakeholders
 A stakeholder is any individual who
affects or is affected by the
application being built:
Define
 Client (those who are paying)
 User (those who interact with the application)



17 -263
Stakeholders
“Involve real users [stakeholders]
throughout the software development
process; their presence is a constant
reminder why and for whom the
software is being crafted.” [Booch]
 What is your approach for formally
identifying stakeholders and gathering their
combined knowledge?
18 -263
Project Management
 Project management is the application of
knowledge, skills, tools, and techniques to project
activities in order to meet or exceed stakeholder
needs and expectations from a project.
Define
 Meeting or exceeding stakeholder needs and
expectations involves balancing competing
demands:
 Scope, time, cost, and quality
 Differing needs and expectations among stakeholders
 Identified requirements vs. unidentified requirements
19 -263
Joke*
What is the difference
between many software
development projects
and the Boy Scouts?
The Boy Scouts
have adult
leadership!
Can you give an example of a project you
have observed that did not have “adult
leadership”?
20 -263
Why Do Software Projects Fail?
 We fail to properly manage risks
 We don’t build the right thing
Question
 We are blindsided by technology
Notice the “We”. As project managers, we develop
idealistic plans, we set unrealistic schedules, we deceive
ourselves and others, and we refuse to face reality. These
projects eventually enter “free fall” with no one taking
responsibility and everyone waiting for the crash (while
sending out resumes).
21 -263
Fail To Properly Manage Risks
 “Management must actively attack a project’s
risks, otherwise they will actively attack you.”
[Gilb]
 Examples:




22 -263
Don’t Build The Right Thing
 Often, projects lose their way because there is no
shared vision of clients, users, problems to be
solved, methods to be used, or goals to be
achieved.
 Examples:




23 -263
Blindsided By Technology
 Concepts are more difficult than they seem, tools
don’t scale up or they introduce errors, suppliers
don’t deliver promised functionality or
performance
 Examples:




24 -263
Blindsided By Technology
 Is OO for you? Ask the following questions:
 Is it possible? Will OO work for us?
 Is it attractive? Can OO make a difference?
What advantages will it achieve for us?
 Is it practical? Can we really do it?
 Is is desirable? Does it provide significant return on
our investment?
 If not, is this a project you want to be
associated with?
25 -263
Project Management To The Rescue
 Effective project management actively
works to minimize these problems by:
 Explicitly identifying and creating written
mitigation and contingency plans for project
risks
 Evaluating the product being built against the
clients’ documented needs and expectations
 Assessing the suitability of the technologies for
use on the project
26 -263
Summary




27 -263
28 -263
This is what your staff
should be doing.
Chapter 2
Modern Software Engineering
Activities, Principles and Processes
29 -263
Chapter Objectives
 At the end of this chapter you will be able
to understand and apply the following
concepts:
 System requirements
 Development phases
 Sequencing the development work
 Fundamental principals of modern software
engineering.
30 -263
Start With System Requirements
 What do we mean by “requirements”?
Question
31 -263
Classical Requirements
Mandatory
Define
FUNCTIONS
ATTRIBUTES
Preferences
EXPECTATIONS
“The difference between delight
and disappointment.” [Weinberg]
32 -263
IEEE 830 Standard
1. Introduction
1.1
Purpose
1.2
Scope
1.3
Definitions, acronyms, abbreviations
1.4
References
1.5
Overview
2. Overall description
2.1
Product perspective
2.2
Product functions
2.3
User characteristics
2.4
Constraints
2.5
Assumptions and dependencies
33 -263
IEEE 830 Standard
3. Specific requirements
3.1
External interfaces
3.1.1
User interfaces
3.1.2
Hardware interfaces
3.1.3
Software interfaces
3.1.4
Communications interfaces
3.2 Functions
3.2.1
Information flows
3.2.2
Process descriptions
3.2.3
Data dictionary
34 -263
IEEE 830 Standard
3.3
3.4
3.5
3.6
3.6.1
3.6.2
3.6.3
3.6.4
3.6.5
Performance requirements
Logical database requirements
Design constraints
Software system attributes
Reliability
Availability
Security
Maintainability
Portability
35 -263
Modern Requirements
 Replace section 3.2 with …
Question
36 -263
Modern Requirements
Information Needed
Define
Information Representation

Stakeholders

Enhanced actor model

Business goals

Textual descriptions - must be
traced to the architecture

System functions

Use case hierarchy

Technical system requirements

Textual descriptions cross
referenced to the use cases

Fundamental domain concepts
and relationships

Domain class model

Domain algorithms

Interaction diagrams

Domain level state behavior

state transition diagrams

application behavior, look and
feel

prototypes
37 -263
Management
 Don’t let yourself be talked into being satisfied
with old style functional requirements. Insist on
all the artifacts specified on the previous page.
Direct
 You, as a manager, need to be familiar with each
of these means of representing information.
 Be prepared to hold the architects responsible for
implementing the business goals.
38 -263
Development Phases* - Activities
Requirements
Use Cases
Systems
Engineering
Domain
Analysis
Application
Analysis
Class Spec
Application
Design
Class Design
and development
* called workflows in the Rational Unified Process
Code
Use Cases
Incremental Application
Assembly and Testing
39 -263
Development Phases - Activities
Systems
Engineering
Domain
Analysis
Models of bodies of knowledge are constructed. The scope of these
areas are only loosely constrained by the purpose of the application to
be developed.
The domain models and specific system requirements are used to
produce a set of models that define the application to be built.
Application
Analysis
A skeleton outline of the system is created. Utilizing standard frameworks
for the various subsystems, interfaces for the subsystem interactions are
defined.
Application
Design
Detailed designs of classes and small clusters of classes are created and
implemented. Use of class libraries is an important part of this phase.
Class Design
and development
Detailed designs of classes and small clusters of classes are
created and implemented. Use of class libraries is an important
part of this phase.
Incremental Application
Assembly and Testing
The various classes, clusters, and subsystems are
integrated incrementally to form larger units. A complete
system will evolve after sufficient iterations. The completed
portion of the system is tested from a functional point of
view.
40 -263
Development Phases - Expertise
Systems
Engineering
Domain
Analysis
Business stakeholders; Business re-engineering experts
Domain experts; Business modeling experts
Application
Analysis
Clients; Use case experts
Application
Design
Software Architects; Great designers
Class Design
and development
Incremental Application
Assembly and Testing
Technology experts; Programmers
Testers; Integration experts
41 -263
Management
Direct
 Must schedule the right people at the right
time.
 Given the iterative nature of modern
software engineering processes this is not
an easy task
42 -263
Systems Engineering
• Business Requirements
• Customer wants
Define
• Constraints
Systems
Engineering
• Allocation of functionality
• High-level software
requirements
43 -263
Management
Direct
•Make sure the software
perspective is heard during
systems engineering.
44 -263
Domain Analysis
• High-level software
requirements
• Domain Knowledge
Define
• Existing Domain Models
Domain
Analysis
• New Domain models
• Updated Domain Models
45 -263
Domain Analysis
 The goal of domain analysis is to understand the
problem domain, the context or environment in which
the problem exists.
Discover
 We identify things and relationships we perceive to be
important in the problem domain:
 Things, categories of things, concepts, attributes, and
behaviors
 Relationships between concepts
 We use the abstractions and relationships we find in
the problem domain as the abstractions and
relationships in the system being developed.
46 -263
Domain Models
 Actor models
 Top level of the Use Case hierarchy
 Class models
 State Models
 Behavior Models
47 -263
Use Cases
Define
 A use case is an end-to-end scenario
(sequence of actions) that describes a use of
the system by a user (actor) to accomplish a
specific goal.
 Use cases can be used to:
 Describe a system’s functional requirements
 Form the basis of the system requirements
document
48 -263
Use Cases
 Use cases provide the following benefits:
 Capture requirements from the users’
perspective
 Involve users in the requirements gathering
process
 Provide a basis for the identification of
classes and relationships
 Provides traceability from requirements
through analysis and into design
 Serve as the foundation for system test cases
49 -263
Use cases are best developed iterativaly
and incrementally
 The only way to get quality is to iterate
 Requirements change while the system is
being developed
 As the development team better understands
the domain, the are better able to review the
use cases
50 -263
Each Level is Complete
1. Define course policies
1.1 Define late policy
1.2 Define category weights
Use case 1.1 is a specific, more detailed, complete use case within the
category of use cases defined by use case 1.
51 -263
Class Diagrams
Define
 Class diagrams are UML diagrams that
document the important concepts, their
relationships, and their interactions at the
domain level.
52 -263
53 -263
54 -263
Management
 Without domain analysis, you will not get the
correct requirements, nor get the requirements
correct.
Direct
 You must have the courage to formally bound
the domain
 Insist that the top level use cases are complete
 Don’t let design or implementation
considerations creep into the domain model
55 -263
Application Analysis
• Domain bounds
• Domain-level class diagrams
• Domain-level interaction
diagram
• Domain-level state-transaction
diagram
• Business requirements
Define
Application
Analysis
• Application level use cases
• Application model
• Detailed requirements
specification
• Application-level interaction
diagram
• Application-level statetransition diagram
56 -263
Application And Domain Models
 The domain model is pruned and software
specific detail is added as we move from
the domain to the application level.
Domain Model
Database
Reports
Application
Model
Networking
GUI
57 -263
Application Models
Define
 Application models include class
diagrams that document all of the classes
and their relationships. In addition,
attributes and methods may be included.
58 -263
Requirements
 During Application Analysis the
requirements for the current increment are
fleshed out.
 Use cases
 Standard components and frameworks
 Hardware platforms and other resource
requirements and constraints
 GUI layouts
 Overall performance objectives
59 -263
Management
 Don’t start the design or implementation of
an increment until the requirements are
complete.
Direct
 An iterative/incremental process is no
excuse for not having written requirements.
60 -263
Application Design
Define
• Application level use cases
• Application model
• Detailed requirements
specification
• Application-level interaction
diagram
• Application-level statetransition diagram
• Reusable Components,
patterns, and frameworks
Application
Design
• Detailed class specifications
(pre-conditions, postconditions, invarients,
state-transition diagrams)
• Interaction diagrams
• Application architecture
61 -263
The old days are gone forever
62 -263
You can no longer afford to build your
architecture from scratch
 Product lines
 Frameworks within a unique product
 Patterns and components everywhere
63 -263
Patterns
 I would no more hire a C++ or Java
programmer that wasn’t familiar with
patterns than I would hire a c programmer
that didn’t understand recursion or binary
sorts.
64 -263
Pattern Fever
CAUTION
INTELLEGENCE
REQUIRED
 Many patterns aren’t
 Many are misapplied
 The terminology is often incorrectly used
65 -263
Architecture
 An architecture for a system is the pattern of connections among the
basic components of the system; the pattern embodies the relations
and constraints among the constituent pieces of the system.
 Our preferred method of documenting an OO architecture uses:
 static, dynamic, and functional models of the architecture
 A pattern language that describes the interrelationships and
constraints of the architecture, and governs instantiation of the
architecture.
66 -263
Architectural Quality
Metric
 “A good architecture provides a clear
separation of concerns among disparate
elements of a system, creating firewalls
that prevent a change in one part of the
system from rending the fabric of the entire
architecture.”
Booch
67 -263
Convergence
Distributed Objects
(e.g. CORBA)
Scalability unproven,
Immature, flexible,
easy to program
TPM (e.g. CICS)
Scaleable, Mature,
hard to program
EJB?, MTS? TUXEDO?
MetaData Approach
 PeopleSoft
 SAP
 Applets
Client runs a virtual machine/translator
Frameworks
 A framework is a set of related and interacting
classes that provide the basic structure, design,
and functionality to implement a business
process.
Define
 Commercial applications frameworks are a set
of core business classes that cooperate in fixed
ways to implement core business processes.
 As such, a framework is a significantly large
“chunk” that can be reused to implement a
number of similar applications.
70 -263
Frameworks
 Frameworks allow analysts, designers,
programmers, and testers to concentrate their
efforts on building the unique parts of
applications while reusing the standard, nonunique parts.
Framework
Hot Spots
Application
71 -263
Components vs. Frameworks
Library of
Components
Framework
Define
72 -263
Components vs. Frameworks
Component
Framework
Complexity
Fairly low
Very high
Type of structure
Static
Dynamic
Control flow
Designer selects
Framework defines
Embodies
Design and code
Process, architecture, design
and code
Usability
Can be used "as is"
Can not be used "as is"
Encapsulation
Functionality and data
Application
73 -263
Management
 Components, patterns and frameworks are
here to stay, but there is much
misinformation about reuse
Direct
 When and where to invest in reuse assets is
more of a business decision than a
technology decision
 It is no longer “will we use OO?” but “to
what level will we use OO?”
74 -263
Management
There should be at least three types of design reviews
Direct
Architecture review
Do you know why
cluster design reviews
are so important?
Cluster design review
Detail design review
75 -263
Class Design And Development
Define
• Detailed class specifications
(pre-conditions, postconditions, invarients,
state-transition diagrams)
• Interaction diagrams
• Application architecture
• Performance considerations
Class Design
And
Development
• Classes, completely coded
and tested
• Test plan, test cases
76 -263
Management
 Review the code to make sure it
implements the specified design
Direct
 Programmers are used to having the final
say. This is not a good practice!
 Clients should have the final say about the product
 Architects should have the final say about the
implementation
77 -263
Application Assembly
• Application models
• Classes, completely coded
and tested
Define
Application
Assembly
• Application
78 -263
Application Assembly
 Traditional integration issues for this
increment
 but smaller in scale
 Test case development
 based on use cases for this increment
 Integration of this increment with previous
increments
 Regression testing issues
79 -263
Management
 Make sure each current increment is tested
and debugged as it is produced
Direct
 Insist on a regression testing framework
80 -263
Sequencing
Waterfall Model
Analysis
Define
High-level design
Detailed design
Implementation
Testing
Production
 The waterfall model is very good for
automating a known solution to a well
understood problem.
82 -263
Waterfall Model
 The Waterfall Model is based on three
(rarely considered) assumptions:
 We can know everything from the beginning
 Nothing ever changes
 We never make mistakes
 What do you think of the validity of these
assumptions?
83 -263
Why Can’t We Cookbook It
 The system’s stakeholders
typically do not know exactly
what they want.
 The stakeholders are often unable to articulate
what they do know.
 Even if we could state all the requirements, many
details can be discovered only as we implement.
 Even if we could know all the details, there are
limits to what we can understand and remember.
84 -263
Why Can’t We Cookbook It
 As we begin each new project we bring
intellectual baggage (both good and bad) from
our previous experience that shape our decisions
independent of a system’s real requirements.
 Systems built by humans are always subject to
error.
“For all of these reasons, the picture of the software
designer deriving his design in a rational, error-free
way from a statement of requirements is quite
unrealistic. Fortunately, it is possible to fake it.”
[Parnas]
85 -263
Riddle
Question: How
do you eat an
elephant?
Answer:
86 -263
How We Can Fake It
 Iterative – Discovery, invention, and
implementation come in cycles.
 Incremental – Deliverables build on earlier
ones, each moving closer to the delivery of
the final application.
 “One important habit that distinguishes
healthy projects from unhealthy ones is the
use of an iterative and incremental software
development life cycle.” [Booch]
87 -263
Iterative Model
Define
 Since we can’t know it all from the beginning,
get it totally correct, and freeze the world
outside, let’s use a development model that
takes into account the fluid nature of software
development.
Analysis
Design
Code
•
•
•
•
•
Analyze a little
Design a little
Code a little
Test a little
Learn a LOT!
88 -263
Management
 Developers have always iterated on an ad hoc
basis as needed; the problem is that managers
have pretended that the project was following a
waterfall.
Direct
 When using an iterative model, the manager
plans for development activities to be revisited
Analysis
Design
Code
•
•
•
•
•
Analyze a little
Design a little
Code a little
Test a little
Learn a LOT!
89 -263
Planing Iteration
 Why plan to do certain activities over
again?
 Add more detail
 Correct mistakes
 iterate within an increment
 Improve quality
 Account for cyclical
dependencies
90 -263
Incremental Model
 Build a system in increments that represent
increasing levels of functionality:
 This is different from waterfall until implementation,
then incremental development.
Domain Analysis
Application Analysis
Application design
Implementation
Testing
Production
91 -263
Incremental Model
 An increment is some subset of the system that is
completely coded and tested.
Define
Analysis
High-level design
Detailed design
Implementation
Testing
Production
92 -263
Planning Incremental Development
 Rather than focusing on milestones,
let’s consider inch-pebbles.
 Increments should generally be 2-6 weeks in
length.
 Shorter and you spend too much time planning
and evaluating and not enough time working.
Longer and development can get out of control.
93 -263
It’s Incremental Everything
A n aly ze
A n aly ze
D esig n
D esig n
Im p lem en t
R eq u irem en ts
S p ecificatio n
D o m ain
M o d el
Im p lem en t
D esig n
D o cu m en t
Other important documents, such as the user manual
and test plan, are also developed, and verified
incrementally.
94 -263
Management
 As a manager you want to get the project
done on schedule, but you also want it done
correctly
Direct
 Use iterative techniques to get it done right
 Use incremental development to schedule
getting it done on time
95 -263
Prototyping Model
 Some advocate a process with little formal analysis and
design, evolving the prototype into the product.
 This is good for small, short lived, in-house projects that
will forever be supported by the same person(s).
 Today’s systems need a well documented solid architecture
that is matched to the business needs of the product.
 It is a temptation to skip Domain Analysis and Architecture
when using a powerful IDE such as JBuilder from Borland
Note: We will use the term prototype to designate a disposable product.
96 -263
Good Architects Create Lots of
Disposable Protypes:
 Analysis Prototypes
 Answer questions about requirements
 Design Prototypes
 Answer questions about the architecture. Design
prototyping is facilitated by simulation tools
 Implementation prototypes
 Answer questions about feasibility, performance, memory
requirements, etc.
97 -263
Management
•How much code do you plan to throw
away?
Direct
98 -263
An OO Development Process
 Basic process is incremental
 Iterate within increments, with prototype support as necessary. Often this
will involve reworking one piece of the system several times before an
increment is finished. Previous increments are only revisited to fix errors
or serious flaws.
 How does one incrementally build an
architecture?
 Do enough analysis and design to form a context, then concentrate on
driving an increment through to completion (running, tested code).
Basic Development Process
Programmer-analysts teams work best
Activity
Increment
In
I n+1
I n+2 I n+3
light activity
Domain Analysis
Application Analysis
Application Design
Class Development
heavy activity
Application Assembly
Getting Started
Establishing a basic context
Activity
Increment
I 0a
I 0b
I 0c
I 01
light activity
Domain Analysis
Application Analysis
Application Design
Class Development
heavy activity
Application Assembly
Stepping through the process
Getting Started
DA
AA
AD
CD
Phase
IT
Project Scope
Stepping through the process
Increment 1
DA
AA
AD
CD
Phase
IT
I1
Project Scope
Stepping through the process
Increment 2
DA
I1
Project Scope
I2
AA
AD
CD
Phase
IT
When performing the Ith increment, bring the entire analysis and design up to date.
Choosing Increments based on Risk Analysis
 What are the benefits of doing high risk
increments first?
 What are the benefits of doing low risk
increments first?
 How does one balance scheduling high risk
increments with low risk increments?
105 -263
Choosing Increments - “Use Case” versus
Architectural
 A use-case driven (external) increment implements
some subset of the user requirements (e.g. traffic
controller works for non-rush hour straight traffic. No
turn traffic, pedestrians or emergency vehicles are yet
considered).
 An architecturally based (internal) increment
implements some subset of system functionality (e.g.
database access mechanism, inter-process
communication).
 How does one balance scheduling external increments
with internal increments?
106 -263
Quality Engineered
 Architectural increments imply
architectural test cases
 The specification of an architecture should
include a set of “architectural use cases”
107 -263
Building Complex Systems is Fundamentally
an Incremental Process
“A complex system that works is invariably
found to have evolved from a simpler system
that worked ... . A complex system designed
from scratch never works and cannot be
patched up to make it work. You have to start
over, beginning with a working simple
system.”
Ramamoorthy, C., and Sheu, IEEE Expert, Vol. 3 (3), p. 14
108 -263
Incremental Architecture - Example
J im D a v e n p o rt
W eak
p re c o n d itio n s
th a t th ro w
e x c e p tio n s
in c lu d in g
s e c u rity
A d v e n tis t A c c o u n tin g In te rn a tio n a l
O bje c t M ode l:
S tro n g
p re c o n d itio n s
R e v is io n 1 .0
D a ta b a se
S e rve r
JD B C
B u sin e ss
M odel
A rc hite c ture
D B T o o ls (S tu d io .J )
GUI
R e v is e d by :
IM R e s o lv e r
C lie n t
4 /1 /9 8
B u s in e s s M o d e l
API
R e v is ion D a te :
N o access except
v ia b u s in e s s m o d e l
109 -263
C o m p a n y C o n fid e n tia l
Architecture - Increment 2
J im D a v e n p o rt
W eak
p re c o n d itio n s
th a t th ro w
e x c e p tio n s
in c lu d in g
s e c u rity
A d v e n tis t A c c o u n tin g In te rn a tio n a l
O bje c t M ode l:
S tro n g
p re c o n d itio n s
R e v is io n 1 .0
D a ta b a se
S e rve r
JD B C
B u sin e ss
M odel
A rc hite c ture
D B T o o ls (S tu d io .J )
API
ODMG
GUI
C O RB A
R e v is e d by :
IM R e s o lv e r
C lie n t
4 /1 /9 8
B u s in e s s M o d e l
API
R e v is ion D a te :
N o access except
v ia b u s in e s s m o d e l
110 -263
C o m p a n y C o n fid e n tia l
Management
 With the incremental approach every
project plan is unique (as it should be)
Direct
 defining and scheduling increments is a skill
that improves with experience
 Multiple teams mean that there will be
multiple increments being developed in
parallel
 the schedule for each team should depend on
the nature of that team’s increment
111 -263
The Impedance Mismatch
 Our Project – Iterative/Incremental
 Everything else in the world –
Waterfall





You

112 -263
Modern Software Engineering
 The iterative/incremental approach is at the
heart of modern software development
techniques
 There are additional issues
113 -263
Rational Unified Process - Terminology
114 -263
Milestones (inch pebbles)
115 -263
Terminology




Typical
Unified
Development Phase
Increment
Iteration
Project Stage
Core Workflow
Release
Iteration
Phase
116 -263
Basic Goals of a Software Development Process
 Correct, Robust, High Quality Software that is
easy to use and meets real business needs
 Modifiable Software
 Extensible Software
 Portable, Integrable Software
 Rapid Development Capability
 Maximize Productivity
 Minimize Costs
117 -263
The Object-Oriented Paradigm Promises to:
 Support RAD through reuse of components, design patterns,
architectural frameworks, and domain models
 Improve product quality
 Facilitate business process reengineering
 Solve problems of greater complexity
 Improve maintainability and extensibility
 Improve communication with customers
 Improve communication between developers
118 -263
Potential Benefits
 An optimal use of object-oriented technology requires a
new development process
 Any promised benefits from the use of OT are only
potential benefits. They do not magically happen. They
require specific management practices to make them
happen
 Rarely however, do corporate policies and practices
encourage managers to follow good, modern software
engineering techniques
119 -263
In Fact:
 Most corporate policies and practices actively discourage
managers from following good, modern software
engineering techniques
 Can you think of examples from your own experience?
120 -263
The Object-Oriented Paradigm
Traditional Mind-set
Object-Oriented Mind-set
u What does the system do?
u What are the fundamental business
concepts in the domain?
u How do I design a system to
provide these functions?
u How can I model the problem and
distribute responsibilities to achieve the
system's functionality?
u Focus on version 1 of this
system
u Focus on extensibility and families of
systems
121 -263
A Use Case Driven Approach
122 -263
Good Software Engineering is NOT Use
Case Driven
123 -263
Unified Process
 Architect-Centric
 Use-Case Driven
 Component Based
124 -263
Good Software Engineering is...
 Domain Analysis Based
 Architecture-Centric
 Use-Case Configured
 Component Biased
 Quality Engineered
125 -263
Domain Analysis Based
 First major activity in
software development is
the identification of the
fundamental business
concepts and relationships
 Design of the application
server is based on the
classes and relationships
in the domain model
126 -263
Architecture-Centric
 Architecture definition and refinement is viewed
as a core development activity
 Architecture is not ad hoc, but is based on
industry standards, patterns, commercial
frameworks and components
 All detail design and coding is done within a well
defined architectural framework, often according
to a specific pattern
 Architecture team plays a key role throughout the
entire product lifecycle
127 -263
From Domain Analysis to Architecture
Grading Domain Model
(Major Domain)
Registration
Domain
Reporting
Domain
Spreadsheet
Domain
Grading
Application Model
 The architecture for each separate domain describes the way
the classes within the domain interact and is based on domain
relationships
 The architecture for the application describes the way
the different domains interact
128 -263
Use-Case Configured
Domain
Relationships
Business Goals &
Technical System
Requirements
Commercial
Standards &
Frameworks
Architecture
Use Cases
Application
129 -263
Uses cases STOP at the system interface
boundary
130 -263
Do not directly derive your design from your
use cases
 Use cases DO describe sequences of actions that actors
follow in using the system
 Use cases must NEVER specify what steps the system
takes internally in responding to the stimulus from an actor
Interface
System
131 -263
Example Architectural Drivers
 Finance
 Extensibility
 Telecommunications
 24X7 hot switchover
 Aerospace
 COTS and GOTS contract mandate
132 -263
Watch out for Shortcuts
 RAD tools that tie screens directly to databases give you
RAD development, but not RAD modifiability
 Screens should be tied to the business model.
 The business model should not directly embed SQL, or
any other implementation technology, in it’s methods
GUI
Report
Writer
Business Model
Technology Interface
Relational Database
What are the trade-offs?
133 -263
Component Biased
 Robust libraries of domain-specific and domainindependent components
 Frameworks that supply substantial portions of an
application
 Packaging techniques that requires loose coupling and well
specified interfaces between modules
 Supporting management techniques that enable
us to integrate these components
134 -263
Quality Engineered
 Testing starts with requirements
 Iterative techniques are used to improve quality
 set up and prototyping
 functional increment
 engineering increment
 Extensive prototyping and demonstration by early
increments.
 Reviews, inspections and walkthroughs are used to
improve quality, not just to rubber stamp or find errors
 A culture of refusing to sacrifice quality for functionality
135 -263
A Software Development Process MetaModel
1.
Emphasis
3.
Domain Analysis Based
Architecture-Centric
Use Case Configured
Component Biased
Quality Engineered
2.
Activities
Notation
UML
4.
Scope
Comprehensive
5. Process Model
Iterative Process
Domain Analysis
Incremental Application
Development
Application Analysis
Prototype-supported
Application Design
Class Design / Development
Incremental Integration and
System Testing
136 -263
Management
 Management is more than the ability to
estimate, plan and track
Direct
 Good managers understand the
fundamentals of good software engineering,
and build an environment and culture that
reward quality.
137 -263
Measurable Progress
 “Every healthy software project I
have encountered has a natural
rhythm whose beat is sounded by
a steady and deliberate forward
motion toward the delivery of a
meaningful product at a reasonably
defined point in time.” – Grady Booch
 This is a fancy way of saying that healthy
projects meet their deadlines for the defined
increments.
138 -263
Whirlpool Model
Domain
Analysis
Application
Assembly
Application
Analysis
Class Design/
Development
Application
Design
Advanced
 Retains the distinct phases while supporting
incremental development.
 Phase order is not fixed. At any point in time we
can choose the most effective thing to do next.
 What do you think of this idea?
139 -263
Management
 The basic questions:
 Where are we?
Question
 Are we making progress?
 When will we be finished?
 How much will it cost?
 What is the quality?
140 -263
7(±2) Habits Of Successful Projects
 A ruthless focus on developing a system that provides a
set of essential but minimal characteristics.
 A culture that is centered on results, encourages
communication, and yet is not afraid to fail.
 The application of a well-managed iterative and
incremental development life cycle.
 Creating and communicating a strong, coherent, and
resilient architectural vision.
 Effective use of object-oriented modeling.
 A management team that is obsessed with quality through
adherence to the fundamental principles of software
development
141 -263
Top 30 Principles of Conventional
Software Engineering
1.
Make quality #1.
•
2.
Depends what one means by quality
High–quality software is possible.
•
3.
Agreed, but bug free software is next to impossible
Give products to customers early.
•
4.
Yes, but
ISBN: 0070158401 McGraw Hill
Determine the problem before
writing the requirements.
•
•
Domain analysis before detailed use cases
Develop the requirements incrementally
142 -263
Top 30 Principles of Software Engineering cont.
5) Evaluate design alternatives.
•
Make sure to to test the design against the business goals
6) Use an appropriate process model.
•
Configure yes, but don’t neglect the fundamentals
7) Use different languages for different phases.
•
Use cases, class diagrams, …
8) Minimize intellectual distance.
•
Absolutely
143 -263
Top 30 Principles of Software Engineering cont.
9) Put techniques before tools.
•
The good old days are long gone….
10)Get it right before you make it faster.
•
Yes, but
11)Inspect code.
•
Not in the top 30
12)Good management is more important than good
technology.
•
Let me explain...
144 -263
Top 30 Principles of Software Engineering cont.
13) People are the key to success.
•
Should be in the top 5
14) Follow with care.
•
Good advice
15) Take responsibility.
•
Your parents should have taught you this
16) Understand the customer’s priorities.
•
Change customer to stakeholder.
17) The more they see, the more they need.
•
True, but don’t let that stop you
145 -263
Top 30 Principles of Software Engineering cont.
18)Plan to throw one away.
•
Too waterfall...
19)Design for change
•
Absolutely, but formally define the scope of anticipated change
20)Design without documentation is not design.
•
False
21)Use tools, but be realistic.
•
Also be realistic about what will happen if you don’t use tools!
22)Avoid tricks.
•
How about: “document your tricks”
146 -263
Top 30 Principles of Software Engineering cont.
23) Encapsulate.
•
Move this to the top 10
24) Use coupling and cohesion.
•
A bit simplistic
25) Use the McCabe complexity measure.
•
If you suspect the quality of your software engineers ...
26) Don’t test your own software.
•
Don’t be the only one to test ...
147 -263
Top 30 Principles of Software Engineering cont.
27)Analyze causes for errors.
•
A principle of process improvement
28)Realize that software’s entropy increases.
•
Only if you let it
29)People and time are not interchangeable.
•
But they are linked
30)Expect Excellence.
•
And you may get it
148 -263
Summary





149 -263
150 -263
This is what your staff
should be doing.
Chapter 3
Direct
Project Management
Issues
151 -263
Chapter Objectives
 At the end of this chapter you will be able to
understand and apply the following concepts:
 Planning the work
 Managing risk
 Planning for resources
 Measuring the project
 Managing the project team  Communicating with stakeholders
 Ensuring quality
 Automated tools
 Fostering reuse
152 -263
Overview of the Development Artifact Set
Requirements Set
1. Vision
document
2. Requirements
model(s)
1. domain
models
2. Use Cases
Design Set
1. Software
architecture
description
2. Platform and
process
deployment
model
3. Cluster and
detail design
model(s)
Implementation Set
1. Source code
baselines
2. Associated
compile-time
files
3. Component
executables
Deployment Set
1. Integrated
product
executable
2. Associated
run-time files
3. User manual
4. Technical
documentation
Test Set
1. Test cases
2. Test scripts
3. Regression test
environment
153 -263
Overview of the Management Artifact Set
Planning Artifacts
1.
2.
3.
4.
Business case
Software development plan
Work breakdown structure
Release specifications
Operational Artifacts
5.
6.
7.
8.
9.
10.
Release descriptions
Status assessments
Software change order database
Bug tracking database
Deployment documents
Environment
154 -263
Planning The Work
 A WBS is simply a hierarchy of
elements that decompose the overall
project plan into a discrete set of tasks.
It is:
Define
 A delineation of all significant work
 A clear task decomposition for assignment of
responsibilities
 A framework for scheduling, budgeting, and
tracking
 A good work breakdown structure (WBS) is
key to a project’s success.
155 -263
Planning The Work
 But, the content of a WBS are very
dependent on management style,
organizational culture, customer preference,
financial constraints, and other project
parameters.
156 -263
Planning The Work
 Conventional Work Breakdown Structure:
Management
System requirements and design
Document
Subsystem 1
Component 11
Requirements
Design
Code
Test
Documentation
Component 1m (same as above)
Integration and test
Test planning
Test procedure preparation
Testing
Test reports
Other support areas
Configuration control
Quality assurance
System administration
From:
Software Project Management
Walker Royce
Subsystem n (same as above)
157 -263
Planning The Work
 A WBS for iterative/incremental
development should be organized
around the process rather than the
product.
158 -263
Planning The Work
 The basic format is:
 First level – workflows (management, environment,
requirements, design, …)
 Second level – life cycle phases (Inception - systems
engineering/domain and application analysis;
Elaboration - application design; Construction - class
design and development and application assembly;
Transition - installation)
 Third level – activities that produce the artifacts
(deliverables)
159 -263
Planning The Work
 Iterative/Incremental Work Breakdown
Structure:
Document
Management
Inception phase management
Business case development
Software development plan
Elaboration phase management
Construction phase management
Transition phase management
Environment
Inception phase environment
specification
Elaboration phase environment
baselining
Development environment
installation and administration
Change order database formulation
Construction phase environment
maintenance
Change order database
maintenance
Transition phase environment
maintenance
Requirements
Inception phase requirements
development
Vision specification
Use case modeling
Elaboration phase requirements
baselining
Construction phase requirements
maintenance
Transition phase requirements
maintenance
From:
Software Project Management
Walker Royce
160 -263
Planning The Work
 Iterative/Incremental WBS (continued):
Implementation
Design
Inception phase component
Inception phase architecture
prototyping
prototyping
Elaboration phase component
Elaboration phase architecture
implementation
baselining
Critical component coding
Architecture design modeling
demonstration
Design demonstration planning and
Construction phase component
conduct
implementation
Software architecture description
Initial release component coding and
Construction phase design
stand-alone testing
modeling
Transition phase component
Architecture design model
maintenance
maintenance
Component design modeling
Transition phase design
maintenance
161 -263
Planning The Work
 Iterative/Incremental WBS (continued):
Assessment
Inception phase assessment
planning
Elaboration phase assessment
Test modeling
Architecture test scenario
implementation
Construction phase assessment
Transition phase assessment
Product release assessment and
release descriptions
Deployment
Inception phase deployment
planning
Elaboration phase deployment
planning
Construction phase deployment
Transition phase deployment
Product transition to user
162 -263
Planning The Work
 Defining Increments – Example
Increment 1 – Eclipse Project
basic business model classes - post a
transaction, no database, no distribution
Increment 2 – Eclipse Project
posted transaction is saved in the RDBMS
163 -263
Don’t Be Afraid of Early Increments
APPARENT RESULT
REAL RESULT
Early demonstrations expose design
issues and ambiguities in a tangible
form.
Demonstration expose the important
assets and risks of complex systems
early, when they can be resolved
within the context of life-cycle goals
The design is noncompliant (so far).
Understanding of compliance
matures from important perspectives
(architecturally significant
requirements and use cases).
Driving requirements issues are
exposed, but detailed requirements
traceability is lacking.
Requirements changes are
considered in balance with design
trade-offs.
The design is considered “guilty
until proven innocent.”
Engineering progress and issues are
tangible, for incorporation into the
next iteration’s plans.
164 -263
Planning For Resources
 Planning requires estimating.
 What to estimate:
 Size and scope
 Schedule
 Time
 Money
 People
 Stability
165 -263
Planning For Resources
 Estimating techniques:
 Top-down (this is not estimating – it is allocation)
 Bottom-up
 Parametric
subsystems


modules

size
weight*factor
Example: Reusable class = 4 weeks
Non-reusable class = 2 weeks
Utility class = 2 weeks
GUI screen class = 3 weeks
166 -263
Planning For Resources
 Most parametric techniques use the following
approach:
Effort = (Personnel)(Environment)(Quality)(SizeProcess)
One model, COCOMO, was developed by Barry
Boehm in the 1980’s. It has been used and refined
over the years.
 The accuracy of COCOMO model has been
described as “within 20% of actuals, 70% of the
time”.
167 -263
Planning For Resources
 Remember:
 Use common sense; don’t expect miracles.
 Example: It’s your first object oriented project, everything is new,
your people are inexperienced, the requirements are ill defined
so … estimate the project at 1/2 the time and cost you would
have for a conventional project.
 Estimate incrementally; you won’t get it right the
first time, incrementally improve your estimates.
168 -263
Managing The Project Team
 The days of the lone
hero/cowboy
are over.
 Today’s systems are far too
complex and the timeframes are
far too short for them to be built
by individuals.
169 -263
Managing The Project Team
 “Organize around outcomes [deliverables],
not tasks.”
– Hammer and Champy
 Teams must be:
 Cohesive
 Focused
 Specialized (System Planning, Project Monitoring,
Architecture, Technology)
 Linked
170 -263
Managing The Project Team
 Core Team Roles:
Define
 Executive Sponsor – critical to success; has clout!
Can be from executive management, the user
community, or the technical leadership.
 System Architect – wholistic, high-level, artistic
director.
 Requirements Analyst – to gather the requirements.
 Technical Lead – technical excellence combined
with superior communication skills.
171 -263
Managing The Project Team
 Core Team Roles (continued):
 Technicians – get the best team you can.
 Testers – participating from the beginning.
 Stakeholders
 Clients – it’s their money
 Users – get real ones full time, not intermediaries or
surrogates. They must understand the operation;
they must understand the business rules.
172 -263
Managing The Project Team
 Core Team Roles (continued):
 Mentor – responsible for improving the team’s
ability, not for project work.
 Project Manager – You! Have you got what it
takes?
173 -263
Managing The Project Team
 Involve clients and users in:
 Domain Analysis
 Development of the Use Case
Hierarchy
– Facilitated teams
– Tests
– User interface prototypes
– Bulletin boards
– Usability labs
– Observational study
– Surveys
– User groups
– Requirements prototype
– Trade shows
– Interviews
– Focus groups
Other Standard Techniques
174 -263
Managing the Project Team
 Organizing the team:
The Detroit Model
The Volvo Model
Specialists
Generalists
175 -263
Managing The Project Team
 Organizing the team:
System
Analysts
Architects
Developers
176 -263
Managing The Project Team
Service Team Roles:
Define
 Process Preacher – processes, techniques, standards,
metrics
 Technical Writer – documentation specialist
 Toolsmith – locate, evaluate, install, support
 System Administrator – development environment
 Librarian – configuration management
 Component Specialist – locate, evaluate, install, support
 Technical specialists (GUI designer, DB
administrator, …
177 -263
Managing The Project Team
 Skills, Size, Timing
 Analysis, design, code, test, tools, environment, …
 Generalize vs. specialize
 Training and Mentoring
 Concentrated vs. spread out
 Organizational patterns: Training team/ progress
team, architect also implements, developer as user
 Reward and recognition
178 -263
Managing The Project Team
 “Retraining in object-think swamps all
other costs.” (Alistair Cockburn)
179 -263
Ensuring Quality
 Organizations typically are in one of the
following six states of quality awareness:
Feeling of
complacency
and market
dominance
(no
awareness)
Awareness
of the
importance
of quality as
market share
erodes
Slogans:
Work harder,
work smarter
Massive
inspection
and testing
efforts to
detect errors
Defect
prevention
that focuses
on the
process, not
the product
Quality is
everyone’s job
and overall it is
management’s
responsibility
Search for
“Silver Bullet”
Where is your organization?
180 -263
Ensuring Quality
 “Quality comes not from inspection but from
improvement of the process.”
(W. Edwards Deming)
 Poorly managed organizations often spend 90% of
their quality efforts on treating symptoms.
 Well managed organizations spend 80% of their
quality efforts on building and maintaining a
quality culture. Quality is “built in”
 The question is not “How much does quality cost?”
The question is “How much does quality save?”
181 -263
Ensuring Quality
 Quality comes not so much from inspection as from
requiring early demonstration
 You can’t tell nearly as much about the quality of a
system from its artifacts as from its realization.
182 -263
Fostering Reuse
 Mid 90’s the focus was on class libraries
 Worked well for stacks, queues, GUI
components, certain system level and
middleware components
 Royal failure of reusable business classes
 account class
Credit Suisse
183 -263
Class Libraries
 Much of the blame has been placed on
management and cultural issues
 Failure of libraries of Business Objects was
mainly technical
 the cost of employing current technology to
capture commonality among business objects
is more than the benefit achieved.
184 -263
Detail Design Reuse
 Patterns have
caught on
because they are
widely
applicable and
save effort.
185 -263
Frameworks
 Successes:
 generic application and middleware levels
 MVC, MFC
 specific design mechanism level
 routing
 ingest
 “variations on a theme” component level
 spreadsheets
 reports
186 -263
Framework Technical Failures
 Applications with not enough commonality
 Application frameworks only work well
when there are only fairly small variations
from application to application
 game framework may work for checkers and
chess, but not for chess and Monopoly
187 -263
Framework Failures - Corporation’s fault
 Numerous frameworks that could have
succeeded from a technical viewpoint have
failed for management reasons
 managers are only responsible for getting
version 1 to market as quickly and cheaply as
possible
 similar applications under different managers
188 -263
Product Lines
 Best current practice is to use components,
patterns, and frameworks to produce
software product lines
http://www.sei.cmu.edu/plp/plp_prod_serv.html
189 -263
Fostering Reuse
 Why is it rarely done?
 It’s actually easier not to develop for reuse.
 Input from other projects must be sought, evaluated,
and incorporated.
 The product being developed must be more generic.
 Increased testing is required to guarantee quality in
many different environments.
 This causes delays in our project and probably
means additional expense.
190 -263
Fostering Reuse
 Why is it rarely done?
 Clients and customers don’t want additional
delays.
 Besides, Fred and Ethyl wrote this and we all
know the quality of their work.
191 -263
Development Cost and Time
Product Line Economics
2.25 d
2.5 m
1.5 d
2.0 m
d dollars
m months
1
2
5
Number of Projects
192 -263
Fostering Reuse
 Reuse approaches:
 End-lifecycle model
 Generalization after the project is complete.
(Often not done because of next project
pressures. Often not done because of
funding questions.)
193 -263
Fostering Reuse
 Reuse approaches (continued):
 Constant creation model
Created during the project (Funding
covered, reuse as a by-product of
development, increased time and cost dropped with budget or delivery
pressure).
194 -263
Fostering Reuse
 Reuse approaches (continued):
 Two-library model
 Develop->library1 (potentially reusable)
[during project], then [after project]
evaluate, if fairly good then generalize and
add to library 2 else drop.
195 -263
Fostering Reuse
 Reuse motivation:
 Exhortation (“You really oughta
wanta reuse!”)
 Pay a bonus for putting things into the reuse
library.
 Pay a bonus for taking
things out of the reuse
library (minimum number or class reuse
ratio).
196 -263
Fostering Reuse
 When we reuse correctly “reuse” is just
“use”.
 Using is not the problem. Creating a high
quality reuse asset is the problem.
 When it becomes a corporate goal as well
as a technical goal, reuse happens.
 Trying to achieve all possible reuse is not
a good idea
197 -263
Managing Risk
 Risk analysis is the process used to decide
where to allocate limited resources.
Define
 In the object oriented paradigm, risk
analysis becomes the basis for determining
the development and testing priorities.
 Use risk analysis to determine the types of
problems that are more critical to system
success and focus resources in these areas.
198 -263
Managing Risk
 Risk Dimensions
 Uncertainty – An event may or may not
happen. What is the probability of its
occurrence?
 Loss – What is the cost to the organization if
the risk occurs? This is usually expressed in
monetary units.
 Problem
 A risk that has occurred.
199 -263
Managing Risk
The most serious risk factors that affect development
projects are:
1) Requirements Problems
Incorrect, incomplete, misunderstood, or creeping
2) Management Malpractice
2.1 Excessive cost or schedule pressure
2.2 Failure to plan, track or control within the framework of a modern
development process
-- inaccurate resource estimation
-- denial
2.3 Poor Team Management
3) Poor Quality Software Engineering
…inadequate technical expertise
4) Technology Failure
200 -263
Managing Risk
 Acceptance – The “whatever”
approach.
Define
 Mitigation – Take steps to minimize the
loss.
 Prevention – Take steps to minimize
the probability.
201 -263
Managing Risk
 Establish risk criteria:
 Complexity of idea
 Stability of specification
 Risk of injury – financial, safety, etc.
 Use risk analysis to:
 Prioritize component tests
 Allocate testing resources
 Choose the number of test cases level of coverage
202 -263
Managing Risk
 Risk management strategies:
 Clear the fog
 Early and regular
delivery
 Prototype
 Microcosm
 Holistic diversity
 Gold rush
 Owner per
deliverable
 Someone always
makes progress
 Team per task
 Sacrifice one
person
For further information see:
www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns
203 -263
Early Risk Resolution
 80% of the engineering is consumed by 20% of the
requirements.
 80% of the software cost is consumed by 20% of the
components.
 80% of the errors are caused by 20% of the components.
 80% of software scrap and rework is caused by 20% of the
changes.
 80% of the resource consumption (execution time, disk space,
memory) is consumed by 20% of the components.
 80% of the engineering is accomplished by 20% of the tools.
 80% of the progress is made by 20% of the people.
Royce
204 -263
Risk profile of a typical modern project
across its life cycle.
Inception
Elaboration
Construction--Transition
High
Project Risk Exposure
Controlled Risk
Management Period
Conventional
Project Risk Profile
Modern Project
Risk Profile
Risk Exploration
Period
Risk Resolution
Period
Low
Project Life Cycle
Royce
205 -263
Measuring The Project
“When you can measure what
you are speaking about, and
express it in numbers, you know
something about it; but when
you cannot measure it, when you
cannot express it in numbers,
your knowledge is of a meager
and unsatisfactory kind; it may
be the beginning of knowledge,
but you have scarcely in your
thoughts advanced to the stage
of science.”
- Lord Kelvin
206 -263
Measuring The Project
 What project measurements do you currently
make?
 What have you learned from these
measurements? How have you changed your
development process because of this
information?
207 -263
Measuring The Project
 Goal-Question-Metric (GQM) approach
 Goal – an organizational objective
Discover
 Question – to determine whether a goal is
being met
 Metric – to answer a question
208 -263
Measuring The Project
 A good measure must:
 Be considered meaningful by the customer,
manager, and technician.
Metric
 Demonstrate quantifiable correlation between
the process and business performance.
 Be objective and unambiguously defined.
 Be a natural by-product of the process and be
supported by automation.
 Indicate trends
209 -263
Example: Number of Defects in the Defect Tracking Database
Measuring The Project
 The following types of metrics are
important:
 Management indicators
 Quality indicators
210 -263
Measuring The Project
Top 3 Management Metrics
Metric
Purpose
Perspectives
Work and progress
Iteration planning, plan vs.
actuals, management
indicator
SLOC, function points, object points,
scenarios, test cases, SCOs
Budgeted cost and
expenditures
Financial insight, plan vs.
actuals, management
indicator
Cost per month, full-time staff per
month, percentage of budget
expended
Staffing and team
dynamics
Resource plan vs. actuals,
hiring rate, attrition rate
People per month added, people per
month leaving
211 -263
Measuring The Project
Top 4 Quality Metrics
Metric
Purpose
Perspectives
Change traffic and
stability
Iteration planning,
management indicator of
schedule convergence
SCOs opened vs. SCOs closed, by
type (0,1,2,3,4), by
release/component/ subsystem
Breakage and
modularity
Convergence, software
scrap, quality indicator
Reworked SLOC per change, by type
(0,1,2,3,4), by
release/component/subsystem
Rework and
adaptability
Convergence software
rework, quality indicator
Average hours per change, by type
(0,1,2,3,4), by
release/component/subsystem
MTBF and maturity
Test coverage/adequacy,
robustness for use, quality
indicator
Failure counts, test hours until
failure, by
release/component/subsystem
212 -263
Measuring The Project
 But, in the object oriented paradigm, how
do we measure things like:
 System size
 Design quality
213 -263
Measuring The Project
 Proposed System Size metric
 Number of Classes
 What problems do you see with this
metric?




214 -263
Measuring The Project
 Proposed Design Quality metric
 Depth of Inheritance Structure
 What problems do you see with this
metric?




215 -263
Measuring The Project
 Proposed Design Quality metric
 Superclass:Subclass Ratio
 What problems do you see with this
metric?




216 -263
Measuring The Project
 Brian Henderson-Sellers has written the
following:
 “There has been a natural tendency in industry to
focus on easily obtained counts.” (p. 124)
 “It is a sad indictment on much of the metrics
literature that prognostic equations have been
inferred where none exists.” (p.31)
 “While managers might want a number as an
‘indicator’ …
it is our professional responsibility not to
succumb to delivering a number that has
neither empirical nor theoretical
217 -263
validation.” (p. 32)
Measuring The Project
 “Researchers have not yet been able to find
measures that are practical, scientifically
sound, and cost-effective to capture and
analyze.”
Pfleeger, Jeffery, Curtis, and Kitchenham
Status Report on Software Measurement
IEEE Software
42(2) 32-43, 1997
218 -263
Measuring The Project
 Jerry Weinberg’s rules of
metrics:
 Don’t measure it unless
you know what it means.
 Don’t measure it unless you are going to do
something differently depending on the
measurement.
219 -263
Communicating with Stakeholders
 What to communicate?
“The CCPDS-R acquisition included two distinct phases:
CD and FSD. During CD a total of 4,163 source lines of
prototype components were developed and executed. The
Common Subsystem is comprised of six CSCIs. These
are a first-generation middleware solution that enabled a
true component-based approach to distributed architecture
through the use of generic tasks, processes, sockets, and
circuits in a real-time run-time infrastructure.”
220 -263
Communicating With Stakeholders
 When to communicate?
“Thank you for explaining the system requirements to us. I
propose we meet back here three years from today at 9:00
am at which time we will demonstrate the completed
system.”
221 -263
Communicating With Stakeholders
 How to communicate?
222 -263
Automated Tools
• Developer
• Project Management
– CASE
– Project tracking
– Compiler
– Estimating
– Debugger
– Scheduling
– Class browsers
– GUI and DB
builder
– Configuration
management
– Testing
– Installshield
• Both
– Word processor
– Spreadsheet
– Group
communications
– Defect tracking
Summary




224 -263
225 -263
“I cannot tell you all the things
whereby ye may commit sin; for
there are … so many that I cannot
number them.” -Mosiah 4:29
Chapter 4
Pitfalls Of Object
Oriented
Development
226 -263
Chapter Objectives
 At the end of this chapter you will be able
to identify some of the pitfalls of object
oriented development and, for each:
 Identify its symptoms
 Predict its consequences
 Aid in prevention
227 -263
Credit
 Some of of the ideas in this chapter are
taken from Bruce Webster’s book Pitfalls
of Object-Oriented Development.
228 -263
Pitfalls

Let’s consider the following pitfalls:
1) Going Object Oriented For All The Wrong Reasons
2) Confusing Training With Skill
3) Confusing Prototypes With Finished Products
4) Not Enrolling Management Before Starting
5) Underestimating The Resistance
6) Abandoning Good Software Engineering Practices
7) Lying To Yourself And Others
8) Focus on Design, Neglect of Analysis
9) Ignorant Management
10) Overconfidence in the Technology
229 -263
For All The Wrong Reasons
 There are many good reasons to move to the
object-oriented paradigm. Unfortunately,
there are many more bad reasons:
Pitfall #1
 Your boss read an article about it
 You want to immediately cut back the size of the
development staff
 You think it will reduce the need for testing
 You think you can complete the project five to
ten times faster
 You think it will eliminate all your
software engineering problems
230 -263
Confusing Training With Skill
 Training is “the acquisition of information,
knowledge and understanding toward a certain
end.”
Pitfall #2
 Skill is the ability to properly apply the
knowledge gained through training. Skill comes
only through experience; experience comes
only through time and effort.
 Knowing the language syntax does not mean
you know how to best program in a language.
Programming effectively does not guarantee
skill in discovering classes and
organizing them into useful hierarchies. 231 -263
Prototypes vs. Finished Products
 Object-oriented development combined
with powerful class libraries and tools can
significantly speed prototype
development.
Pitfall #3
 But, people not involved in development –
management, investors, and customers –
often see prototypes as almost completed
applications.
232 -263
Not Enrolling Management
 “It is easier to beg forgiveness than ask for
permission” is an often quoted maxim but
“easier” doesn’t necessarily mean “better”.
Pitfall #4
 It is often common for a development group to
begin using object-oriented technology with
only minimal involvement and education of
upper management.
 When additional tools and training are needed,
when the schedule slips, when other
unfortunate things happen, what will
management say?
233 -263
Underestimating The Resistance
 Objects are wonderful. So you push
ahead to use the technology.
Pitfall #5
 You are surprised that people are
pushing back.
 Sometimes it a guerrilla attack, other
times its a full frontal assault, but you
are becoming fully involved in a
political battle.
234 -263
Underestimating The Resistance
 Why are people resisting:
 They don’t understand object technology
 They don’t want to understand object technology
 They are afraid they won’t be able to understand
object technology
 They like how they currently do things
 They don’t like the language, methodology, or tools
you are proposing
 They want to adopt object technology, but want to
do it their way
235 -263
Abandoning Software Engineering
 Many good software engineering practices
are already under pressure.
Pitfall #6
 Many developers don’t know them and
aren’t willing to learn them. Those who do
know are not given the opportunity to
practice them.
 And, since object-technology is so
wonderful, we don’t really need planning,
estimating, tracking, reviews,
testing, …
236 -263
Lying To Yourself And Others
Pitfall #7
 Self delusion and group delusion is not
uncommon in software development projects.
This is not surprising. We have to be eternal
optimists in this business; otherwise, we would
never even try many of the projects we do.
237 -263
Lying To Yourself And Others
 We often deceive ourselves:
 About the time needed to specify and design what
will be developed
 That no major roadblocks or difficulties will be
encountered
 By assuming that because a project must be
completed by a certain date that it can and will be



238 -263
Focus on Design, Neglect of Analysis
Pitfall #8
239 -263
Ignorant Management
Pitfall #9
240 -263
Over Confidence In The Technology
Pitfall #10
241 -263
Summary




242 -263
243 -263
Chapter 5
Summing it up
244 -263
What Do Project Managers Do?
 Team Management
 Plan, Schedule, Track
Direct
 Resource Allocation
 Project Direction
 Politics
245 -263
How Does The Use of New Technology Affect
These Management Tasks?
 Team Management
Direct
 Plan, Schedule, Track
 Resource Allocation
 Project Direction
 Politics
What’s Different?
246 -263
Team Management
Direct
 Manage the people on the team
 Motivation
 Conflict resolution
 Evaluation, promotion
 Recruitment, retention
 Career development
 Task assignment
What’s Different?
247 -263
Scheduling
 Plan and Track the project
 Detailed planning and scheduling
Direct




Per person planning and tracking
Iterations
Increments
Testing, Deployment, Support
 Big Picture
 Functionality vs Time Tradeoffs
 Delivery dates
What’s Different?
248 -263
Resource Allocation
Direct







Staffing
Software development tools
Software components
Computer resources
External resources
Space
Etc.
What’s Different?
249 -263
Direction
Direct
 Keep the project direction aligned
with the stakeholders vision
 Quality vs. Functionality vs. Cost
tradeoffs
What’s Different?
250 -263
Politics
 Project interface and team buffer
Direct
 Manage stakeholder relationships
 Protect the team from the whims of
exterior forces
 Negotiate with upper level
management and project
stakeholders
 Manage interaction with other
teams, such as testing and quality
assurance
 Fight for resources
What’s Different?
251 -263
Top 10 Principles of Modern Software
Management
Direct
1. Base the process on an architecture first approach.
2. Establish an iterative lifecycle process that confronts risk early.
3. Transition design methods to emphasize component-based
development.
4. Establish a change management environment.
5. Enhance change freedom through tools that support round-trip
engineering.
6. Capture design artifact in rigorous, model-based notation.
7. Instrument the process for objective quality control and progress
assessment.
8. Use a demonstration-based approach to assess intermediate
artifacts.
9. Plan intermediate releases in groups of usage scenarios with
evolving levels of detail.
10. Establish a configurable process that is economically scalable.
Royce
252 -263
Software Management Best Practices

Formal risk management - using an iterative process.

Agreement on interfaces - same intent as architecture-first
principle.

Formal inspections

Metric-based scheduling and management - directly related to
model-based notation and objective quality control principles.

Binary quality gates at the inch-pebble level - evolving levels of
detail principle.

Programwide visibility of progress versus plan.

Defect tracking against quality targets - directly related to
architecture-first and objective quality control principles.

Configuration management - same reasoning behind the
change management principle.

People-aware management accountability.
Direct
Software Acquisition Best Practices Initiative
Airlis Software Council
253 -263
Thanks!
 Thanks for attending this course.
 Let us know about your project management
work. We’d like to hear about your
successes and your difficulties.
 My e-mail address is:
[email protected]
254 -263
255 -263
Descargar

No Slide Title