Download IJC - IPM

Iterative Project
Management
Chapter 3.3 - Controlling an Iterative Project
Modified considerably by Instructor
Many notes from authors not directly found in
chapters.
The Role of Documentation
• Documentation has many roles to play on a project
• Enable communication
– Much documentation tends to be temporary artifacts to support
development.
– Generally used for communications among team members.
– Explanation, education, reporting what’s going on in project…
• Establish a permanent record
– System’s structure and behaviors;
– May provide info for maintenance / change in the future.
– History, justification of decisions, description of key
decisions..
• Provide evidence
–
–
–
–
Agreements among stakeholders;
Achievements;
Records of what has been done.
Results of management and technical reviews.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
2
Bittner and Spence have thoughts on ‘progress:’
• Progress is NOT indicated by production of documentation in
itself.
• Progress is much better indicated by:
• Increased understanding,
• shared and accepted decisions,
• agreements reached between parties, and, importantly
• working software
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
3
Documentation: How much is enough?
• Enough documentation is required to
–
–
–
–
–
establish a shared vision,
reduce risk,
enable management control,
preserve the integrity of the design and
involve the stakeholders in the project.
– GOTO 11
– You are responsible for slides in between…
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
4
The Role of Requirements
• Goals related to requirements include, to:
–
–
–
–
–
Establish a shared vision
Bridge the gap between the business and the supplier
Communicate the intent of the system
Define the capabilities required of the system
Occasionally: Act as a contract between the stakeholders and the
development team
To establish and maintain agreement with the
customers and other stakeholders on what the
system should do.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
5
According to the RUP: Purpose of Requirements is:
• To establish and maintain agreement with the
customers and other stakeholders on what the system
should do.
• To provide system developers with a better
understanding of the system requirements.
• To define the boundaries of (delimit) the system.
•  To provide a basis for planning the technical
contents of iterations.
•  To provide a basis for estimating cost and time to
develop the system.
• To define a user-interface for the system, focusing on
the needs and goals of the users
• (Right arrows are mine. Our emphasis here…)
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
6
From a Management Perspective, Requirements:
• Define the scope of the system
– Form the basis of agreement and negotiation with the
stakeholders
• Define the releases
– Both internal and external
• Drive development activities
– Particularly testing and assessment
• Form the basis for estimating and measuring progress
Managers need to be aware of the
requirements set and how they are managed.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
7
The Role of Architecture
• The architecture represents the significant decisions
about the organization of the system
– It’s the 20% of ‘stuff’ that makes 80% of the difference
– Architecture constrains Design and Implementation
• We talked about this quite a bit! How so?
Discuss.
• Proving the architecture is a significant milestone for
any technology project:
– Get the architecture right
• before committing significant resources to the project. Why?
• before worrying about completeness and precision in the
requirements, test cases, design and code
• How do you ‘prove’ the architecture is correct?
Managers need to be aware of the architecture and
the set of components it defines.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
8
Architecture continued….If you agree, HOW SO???
• Software architecture encompasses the set of significant
decisions about the organization of a software system
– Selection of structural elements & interfaces by which a system is
composed
– Behavior as specified in collaborations among those elements
– Composition of these structural and behavioral elements into larger
subsystems
– Architectural style that guides the overall organization and
communications.
• Software architecture also involves
–
–
–
–
–
Functionality & Usability
Resilience & Performance
Reuse & Comprehensibility
Economic and technology constraints and tradeoffs
Aesthetic concerns (elegance)
• Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner;
Rational (derived from Mary Shaw)
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
9
Iterative Development Requires Discipline
Iterative Project Management
Requirements
Analysis &
Design
Code &
Unit Test
Continuous
Assessment
Architecture
Environment / Configuration and Change Management
To iterate, all of the core software development disciplines are applied every
iteration to produce a release. Some of the disciplines are particularly strained
by iterative and incremental development.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
10
Selecting A Development Process
Method
Comments
Unified Process &
Variants
Use-case driven and architecture-centric. Widely
applicable and variable.
Extreme
Programming
Light weight, disciplined, developer focussed process.
Scrum and DSDM
(Dynamic Systems
Development Process)
More management approaches than development
methodologies.
The iterative and incremental development
process you select should be based on reducing
project risk.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
11
• There are many other iterative and incremental methods
–
–
–
–
–
–
Adaptive Software Development,
MBASE
Alistair Cockburn’s Crystal Methods
Feature Driven Development (FDD),
Lean Development (LD)
Pragmatic Programming, and more
• Most methods (certainly including the UP), are compatible with, or
recommend, a use-case driven approach.
• Nearly all methods adopt OO / component-based development
• All methods listed will work when applied by the right people to the
right kind of problem.
• All the methods contain good practices you could apply to your
projects.
• All of the methods are agile and adaptive in one way or another.
GOTO 17
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
12
The Unified Process’s Key Requirement Artifacts
Key Requirement Artifacts
Vision
Use-Case Model
© 2005 Ivar Jacobson International
Supplementary
Specification
Iterative Project Management / 02 - Controlling an Iterative Project
13
An Introduction to Use-Case Modeling
• A way to establish the requirements of the system
– Use cases place requirements in context
• A way to establish the system boundary
– The model identifies who or what interacts with the system and
what the system should do
• A way to iteratively evolve the requirements
• A way to communicate the requirements to all the
stakeholders
– The use cases provide a common thread through all project
activities
A planning instrument for the management of
iterative and incremental development projects
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
14
Use-Case Modeling: Actors and Use Cases
Icon
Definition
An actor defines a role that a user can play when
interacting with the system. A user can either be an
individual or another system or a device.
An Actor
A use case describes how an actor uses a system to
achieve a goal, and what the system does for the actor
to achieve that goal. It tells the story of how the system
and its actors collaborate to deliver something of
value for at least one of the actors.
A Use Case
Bolding is mine.
Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
15
• The two main concepts involved in use-case modeling are
Actors and Use Cases.
• The definitions above are taken from Use Case Modeling,
Kurt Bittner & Ian Spence, Addison Wesley 2002.
• The more formal UML definitions are:
• Actor: A coherent set of roles that users of use cases play
when interacting with these use cases.
• Use Case: A description of a set of sequence of actions,
including variants, that a system performs that yields an
observable result of value to a particular actor.
• We prefer Bittner and Spence’s more expansive, but
compatible definitions, as they are less self-referential,
and hopefully, more approachable.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
16
Looking Inside A Use Case
• Basic Flow
– The normal way of attaining the value,
• The expected path through the use case
• Alternative Flows
– Other ways of attaining the value
– Exception and error conditions
• Scenarios
– A description of one particular path through the use case (the
basic flow plus 0 or more alternative flows)
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
17
Use Cases: Evolving Requirement Definitions
“Maturity Levels” or “Levels of Granularity.”
One version is not necessarily ‘better’ than another….
Can be individually used at different times for different purposes:
Briefly
Described
Discovered
Bulleted
Outline
Detailed
Description
Essential
Outline
Fully Described
Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
18
Use Cases Drive Other Development Activities
Authoring State
Primary Purpose
Downstream Activities : Used for:
Discovered
Identify the use case.
Scope Management
Briefly Described
Summarize the use case’s
purpose.
Scope Management
Bulleted Outline
Summarize the shape and
extent of the use case.
Scope Management
Low Fidelity Estimation
Identify Risks
Identification of the components involved in
delivering the use case (See next slide)
Essential Outline
Summarize the essence of
the use case.
User Interface Design and prototyping.
Collaborative, creative Analysis and Design
Architectural Analysis
Detailed Description
To allow the detail to be
added incrementally.
None – this is purely an intermediate step.
Fully Described
Provide a full requirements
specification for the behavior
encapsulated by the use
case.
Full Analysis and Design
Implementation and Testing
User Documentation.
High Fidelity Estimation.
Adapted from: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
19
IMPORTANT.
• What is interesting here is how the early, less complete
use-case states but still very useful can be used to
identify and support a host of very important activities.
• This is achieved by doing broad brush stroke
use-case realizations based upon the bulleted or
essential outlines.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
20
Architecture: Component Definition
Sample architectural layout –
layered model showing components and associations.
Some components may already exist; others may require development.
Components grouped into ‘layers.’
Applicationspecific
Businessspecific
Middleware
Systemsoftware
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
21
Architectural Robustness Analysis and Design
Very high level interaction diagram (sequence diagram) analysis model or
initial component-based high level design model showing high-level responsibilities.
Payment
Buyer
Bank
Customer
Management
Get
invoices
Invoice
Management
Get
header
Account
Management
Sequence diagram may be
developed from less than
fully developed use-cases!
Schedule
invoice
Transfer
Invoice
paid
Invoice
paid
Adapted from Software Reuse, Jacobson et al, Addison Wesley 1997
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
22
Other Approaches to Requirements
Technique
Source
Comments
User Stories
Extreme
Programming (XP)
Act in the same way as
briefly described use cases
and flows. (‘briefly-described’
was one of the maturity /
granularity levels of author’s
use cases.)
Features
Feature Driven
Development (FDD)
Typically individual functions.
May be ‘lists.’
Scenarios
Traditional
Can be considered
instances of use cases.
Yes.
Declarative
Statements
Traditional
Usually grouped by subject
area not value delivered.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
23
Releases must provide a clear value.
• To support iterative development we must be able to
subset the requirements to produce intelligent
definitions of the releases produced by each iteration.
• It is important that releases provide value
• This can only be achieved by implementing end-to-end
threads through the system.
– Use cases, user stories and scenarios allow us to do this.
Declarative statements, typically, do not.
• All approaches can be used for iterative and incremental
development.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
24
The Lifecycle of a Use Case
Requirements
Identified
Development
Analyzed
Testing
Verified
Designed
Authored
Accepted
Implemented
Agreed
Source: Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley 2002
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
26
Use Cases and Testing
Follow the ‘dependency’ arrows…
Use Case
Test Design
and
Preparation
Scenario
Test Scenario
<< White Box Testing >>
Use Case Realization
Test Suite
w. Test Cases
Component
Definition
System Design
and
Implementation
© 2005 Ivar Jacobson International
Unit Tested
Component
Testable
Release
Iterative Project Management / 02 - Controlling an Iterative Project
27
Testing with Use Cases: Test cases; black box and white box..
• Use cases constitute the basis for identifying test cases and
procedures.
• System is verified by performing scenarios based on the
use cases.
• Black Box View of the system is provided by Use cases.
• White Box View is provided by the Analysis and Design
products and relate requirements to individual pieces of the
system.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
28
Testing with Use Cases: Test cases; black box and white box..
• Based upon the use cases, test design and test case
preparation activities can proceed in parallel with the
software design and implementation.
• This enables the test suite to be available when the
testable release becomes available.
• Test cases derived from the use cases take advantage
of the way that use cases gather together the
requirements to ensure good functional test coverage
of the system and to produce robust, repeatable test
suites.
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
29
Use Case and Scenario-Based Planning
• Use cases providing the end to end threads required to
successfully set the objectives for the iterations
• Scenarios (threads through the uses cases) drive the iterations.
Iteration 1
Iteration 2
Iteration 3
Out of
Scope
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
30
Measuring Progress with Use Cases
Project Progress
Number of Use Cases
25
20
Identified
Agreed
15
Analyzed
Designed
10
Implemented
5
Verified
0
1
2
3
4
5
6
7
8
Iteration
Use case ‘states’ can be used to track project progress
Use Cases drive the process…
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
31
Summary and Review
• Every iteration should produce an executable
release
– The release should fulfill more of the project’s
requirements than the previous release (from the
last iteration).
– This increase in delivered requirements is called an
increment.
– Iterations are defined by their intended results as
well as the evaluation criteria for these results.
– Every iteration should actively address and reduce
project risk
•
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
32
Summary and Review
• Every iteration should be treated as a discrete
time box.
• During an iteration, the project team should focus
on objectives of the current iteration – no more.
• The results of every iteration should be objectively
assessed; the team should be prepared to rework
the solution and project plan as required.
• Use ‘Anchor Point’ Milestones to provide focus to
the series of iterations.
– The milestones (and their phases) measure the state of
the project in terms of its risk
© 2005 Ivar Jacobson International
Iterative Project Management / 02 - Controlling an Iterative Project
33