Transcript 1 - University of Hawaii - Department of Electrical Engineering

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Chapter 16, Methodologies:
Putting it all together
Outline





A Mountaineering Example
Project Context
 Goals, Environment, Methods, Tools, Methodology
Methodology Issues
 Planning, Design Reuse, Modeling, Process, Control&Monitoring,
Redefinition
Methodology Spectrum
 Royce’s Methodology based on the unified process (Separate Slides)
 Extreme Programming (Separate Slides)
Methodological Heuristics
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
Key Decisions in an Expedition


A leader has to answer several key questions to create a successful
expedition
 What mountain should be climbed?
 What process should be used?
 What types of tools should be used?
 Who should be member of the team?
 Does the expedition need a leader?
Different answers to these questions lead to different styles
 Fixed-rope Style
 Alpine Style
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
Key Decisions in an Software Project








Project goals
Schedule
Cost
Project organization
Software life cycle Model
Tools
Methods
Team members
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
4
Project Context

Project environment
 Defined by the client and by the current state of the development
organization. The environment constrains the project manager.


Methods
 Recipes that the project manager can select in the given environment.


Examples: use case requirements elicitation or design pattern reuse.
Tools
 Devices or programs that support specific activities.


Examples: Participants’ background, problem type, location of the project.
Examples: modeling tools, compilers, debuggers, change tracking tools.
Software engineering methodology
 Collection of methods and tools for developing and managing a software
system to achieve a specific project goal in a given project environment.
 Specifies when methods or tools should be used, when not and what to do
when unexpected events occur.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
Project Environment






Participants’ expertise
Client type(Application Domain Knowledge, Decision Power)
End user access
Technological climate
Geographical distribution
Project duration vs rate of change
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Local King Client
Proxy Client
Client
Type
• Can
make decisions
• Stands in for real client, who has no
• Deep knowledge of application
domain
• Usually collocated with the project.
• Does not report to anybody else
• Can answer developer questions
• Can effectively collaborate with
developers and project manager.
time or physical distance makes
collaboration with the organization
difficult.
• Has sufficient knowledge
High
Lowof application
domain
• Cannot make major decisions.
Pseudo Client
• Often memberHigh
of the developmentLocal King Client
Pseudo Client
No Client
organization (e.g. marketing)
• Many projects start without a client.
• The system is targeted at new
• Example: A visionary product is
market segment.
developed before a market segment is
• Can make decisions in a short time
opened.
• Collaborates well
Lowwith developers Proxy Client
No Client
• Limited knowledge of application
domain.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
Proxy Client



Proxy clients are sent for the “real client”. Reasons:
 Real client has no time
 Physical distance would make collaboration of real client with the
organization difficult.
Proxy clients have sufficient knowledge of the application domain to
answer clarification questions from the developers
Proxy clients do not have sufficient power of representation to make
major decisions.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Pseudo Client





The pseudo client is a member of the development organization (e.g.,
the marketing department)
The pseudo client acts as a client, because the system is targeted at a
new market segment, as opposed to a single individual or company.
Pseudo clients can make decisions within a short time and can
collaborate well with the development organization
Pseudo clients have a limited knowledge of the application domain.
Often developers act as pseudo clients.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
“No Client”


A project can start without a client, for example, when a visionary
product is developed before a market segment is opened.
In most of these cases, however, the project selects a pseudo client, so
that the stakes of the developers can be balanced against the stakes of
the future user.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
End User Access




Clients and end users usually do not have the same interests
Clients are interested in
 an early delivery date
 as much functionality as possible
 low cost.
End users are interested in
 a familiar user interface
 an easy to learn user interface
 A system that supports their specific task well
The project success may also depend on a usability test to be
conducted by end users
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Technological climate

Depending on the requirements expressed by the client, a project may
be constrained in the technological components it has to use.
Examples:
 A project improving a legacy system deals with well-known and
mature technology. But the technology might be out of date
 A project developing a first-of-a-kind prototype based on a
technology enabler may have to deal with preliminary versions of
components and immature technology.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
Geographical Distribution



“Single room projects”: All participants are located in a single room, they
can get to know each other, much of the important coordination can occur
informally.
There are situations when single-room projects are not possible or not
desirable.
 The organization may have resulted from the merger or acquisition of several
individual companies with different skills.
 The organization is a consortium or a temporary alliance of several
subcontractors, located in different geographical locations.
 Some part of the development organization may need to be collocated with
the client.
Geographical distribution has advantages and disadvantages:
 Increases the availability of skill and lower cost labor
 May take advantage of different time zones
 Slows communication
 Lowers awareness among teams
 Leads to loss of information between sites
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Methodology Issues


Methodologies provide guidance, general principles and strategies for
selecting methods and tools in a given project environment.
The key questions for which methodologies typically provide
guidance include:
 How much planning should be done in advance?
 How much of the design should result from reusing past solutions?
 How much of the system should be modeled before it is coded?
 In how much detail should the process be defined?
 How often should the work be controlled and monitored? When
should the project goals be redefined?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
How much Planning?

Two styles of navigation [Gladwin 1964]
 European navigation:



Current Location and Desired Location
Planned Route
Route Deviation and Route Correction
 “Polynesian navigation”
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
“European Navigation”
Planned Route
Lima
(Current Location)
Auckland
(Desired Location)
Actual Route
Event: Course deviation.
Action: Course correction
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
Polynesian Navigation
“We need a new place
for living.
Let’s go to Auckland”
Lima
(Current location)
Event: “Birds seen”
Action: “Follow the birds”
Tahiti
(Empty island, great
place for Living)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
Auckland Project Plan (European Navigation)







Project Goal: Auckland
Desired Outcome: Auckland is found
Team: Captain and 50 sailors
Organization: Flat hierarchy
Tools: Compass, speed meter, map
Methods: Determine planned course, write planned course before departure.
Example: Start Lima. Sail West, keep the compass constantly at 97 degrees,
stay at latitude 20 degrees)
Work breakdown structure





Task T1 (Check direction): Determine current direction of ship
Task T2 (Compute deviation): Determine deviation from desired course
Task T3 (Course Correction): Bring ship back on course
Process:
 T1 and T2 are executed hourly. If there is a deviation, T3 is executed to bring
the ship back on the planned course.
Schedule: With good wind 50 days, if doldrums are encountered, 85 days.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Auckland Project Plan (Polynesian Navigation)









Project Goal: Auckland
Desired Outcome: A new place for living is found
Team: Captain and 50 sailors
Organization: Flat hierarchy
Tools: Use stars for navigation, measure water temperature with hand
Methods: Set up a set of event-action rules. When an event occurs, determine
the action to be executed in the given context.
Work breakdown structure
 Task T1 (Determine direction): Set direction of ship to a certain course
 Task T2 (Check Clouds): Look for non-moving clouds in the distance
 Task T3 (Check Birds): Look for birds and determine their direction
 Task T4 (Compute course): Determine new course for ship
 Task T5 (Change course): Change direction to follow new course
Process:
 Start with T1. Tasks T2 and T3 are executed regularly. The result (cloud
detected, birds detected, nothing happened) is interpreted in the current context.
If the interpretation makes a new course more promising, execute task T4 and
T5.
Schedule: None
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Situated action



Situated action [Suchman 1990]
 Selection of action depends on the type of event, the situation and the
skill of the developer. Also called context-dependent action.
Examples of navigation events: “Course deviation”, “Birds seen”,
“Clouds seen”.
European Navigation is context independent:
 Event: “Course deviation in the morning”

Action: “Course correction towards planned route”
 Event: “Course deviation in the evening”


Action: “Course correction towards planned route”
Polynesian Navigation is context dependent:
 Event: “Birds seen”, Context: Morning

Action: “Sail opposite to the direction the birds are flying”
 Event: “Birds seen”, Context: Evening

Action: “Sail in the direction the birds are flying
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Example: Running a rapid
A quiet river
Unplanned event: A Hydraulic!
Desired
Location
QuickTime™ and
a
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
TIFF (Uncompressed) decompressor
are needed to see this picture.
Current Location
Bernd Bruegge & Allen H. Dutoit
What can we do?
Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
Change

“Change”:
 Something becomes clear (“crystalizes”)
 Something new appears (“technology enabler”)
 Something becomes important (“change of requirements”)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Frequency of Change determines the Choice of
the Software Lifecycle Model
Mean Time between Change >> Project Time
 Change is rare
 Choose an activity-oriented model: Waterfall model, V-Model
 Mean Time between Change ≈ Project Time
 Changes occur occasionally during the project
 Choose an activity-oriented model with iterations: Boehm’s
spiral model, Unified Process
 Mean Time between Change << Project Time
 Changes are normal (“Change is constant”)
 Choose an entity-oriented model: Issue-based model, Featuredriven model

Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
Pros and Cons of Project Plans for Software Projects



Plus
 Very useful to kick off a software project (to establish the goals,
organize the teams, and start with development)
 Useful also controlling a software project if the outcome is
predictable or when no major change occurs.
Con:
 Of limited value to control the project when the outcome is
unpredictable or when unexpected (“unusual”) events occur in the
project that change the project context.
Examples of unexpected events:
 Appearance of new technology which was unknown at project start.
 A visionary scenario turns out to be not implementable
 Company is merged with another one during the project
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
26
Methodology Issues
How much planning should be done in advance?
 How much of the design should result from reusing past
solutions?
 How much of the system should be modeled before it is
coded?
 In how much detail should the process be defined?
 How often should the work be controlled and monitored?
When should the project goals be redefined?

Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
How much Reuse?

Reuse can significantly reduce the development effort required to
deliver a system.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
How much Modeling?


Advantages of modeling:
 Modeling enables developers to deal with complexity
 Modeling makes implicit knowledge about the system explicit
 Modeling formalizes it so that a number of participants can share this
knowledge.
If one is not careful, models can become as complex as the system
being modeled.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
Managerial Challenges of Modeling




Modeling presents several challenges to the manager
Formalizing knowledge is expensive.
 It takes time and effort from developers, and requires validation and
consensus so that every participants agrees on the same meanings.
Models introduce redundancy.
 If changes are made to the system, the models must be updated as
well. If several models depict the same aspects of the system, all must
be updated. If one model becomes out of sync, it loses its value.
Models become complex.
 As the model complexity becomes similar to the complexity of the
system, the benefit of having a model is reduced significantly.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Where do we need Models?

Models support three different types of activities:
 Communication: The model provides a common vocabulary. An
informal model is often used to communicate an idea.
 Analysis/Design: Models enable developers to reason about the
future system.
 Archival: Compact representation for storing the design and rationale
of the system.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Models to support Communication



Most often used in the early phases of a project and during informal
communications.
 The model does not have to be consistent or complete
 The notation does not even have to be correct
The model is used only to communicate an idea to another person.
 If the idea is understood, the model has served its purpose.
UML is our preferred notation for models to support communication.
 Other notations are acceptable, especially if the other person does not
speak UML.


Example: The customer or the future end users usually don’t know UML.
Communication Media:
 Can be on a Whiteboard, on a slide or even on a napkin.
.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
“Napkin Design”
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
Model for Bus Stops (used in Slide Presentation)
Street Segments
Adresses, length
Bus Stop
Schedule
Street
name
Bus Route
name
Bus
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
Models to support Analysis and Design






The model provides a representation that enables developers to reason about
the system.
The model also forms the basis for coding, as CASE tools are able to convert
models into source code templates
Used during analysis, design and implementation.
 The model needs to be made consistent or complete
 The notation should be correct so it the model can be entered into a
CASE tool.
The model is used to communicate the idea to a tool.
UML is our preferred notation for models to models that support analysis and
design. Other notations are not acceptable.
Models to support analysis and design are eventually entered into a CASE tool.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
36
A UML Model for Bus Stops
next to
located on
Street Segment
* Bus Stop
location
Addresses(left, right)
length
number
*
*
Day
*
line id
line id
Bus Route
Street
name
type
name
Schedule
Time
*
traverses
stops at
{exactly 2}
Intersection
id
x,y
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
*
Bus
*
37
Input for User Interface Generator
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
Models to support Archival
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
Screen Snapshot of Graphical User Interface
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
UML can model more than Software Systems



UML has been designed to model software artifacts.
However, UML is a modeling language that can be used to model a
variety of phenomena
 projects and processes, even philosophical systems.
The models for projects and processes used in the book are models
intended for communication.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Model of a Software Project
Pr ojec t
*
Wo rk P rodu ct
Bernd Bruegge & Allen H. Dutoit
*
Sc hedu le
Ta sk
Object-Oriented Software Engineering: Using UML, Patterns, and Java
*
Pa rtic ipan t
42
Model of a Software Process
Example: V-Model
Sy stem
Re quir emen ts
An alys is
Op erat ion
So ftwa re
Re quir emen ts
El icit atio n
Cl ient
Ac cept ance
Sy stem
In tegr atio n
& Test
Re quir emen ts
An alys is
Co mpon ent
In tegr atio n
& Test
Pr elim inar y
De sign
Un it
Te st
De tail ed
De sign
Im plem enta tion
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Models for Plato’s and Aristotle’s Views of Reality
Aristotle
Plato
Reality
Reality
*
*
Substance
Thing
Form
Particular
Bernd Bruegge & Allen H. Dutoit
Matter
Form
Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
How do we Communicate a Complex Model?

To communicate a complex model we use navigation and reduction of
complexity
 Do not simply use a picture from the CASE tool and dump it in front
of the user
 The key is navigate through the model so the user can follow it.

Start with a simplified model and then decorate it incrementally
 Start with key abstractions (use animation)
 Then decorate the model with the additional classes
To reduce the complexity of the model even further
 Show the use of inheritance (for taxonomies, and for design patterns)


If the model is still too complex, show the subclasses on a separate slide
 Then show the use of any patterns used in the model

Make sure to use the name of the patterns
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
45
Example: A More Complex Model of a Software Project
Taxonomies
Basic Abstractions
Equ ipme nt
Pro ject
*
Fac ilit y
Res ourc e
Composite Patterns
Sch edul e
*
Out come
*
pro duce s
*
*
Set of Work
Wor k
Pro duct s Pro duct
*
con sum es
des Wor k
cri besPac kage
*
Org anizat ion
*
Org aniz atio nal
res ponWor k
Uni t
*
sib le pla ys
dep ends for
Rol e
Act ivit y Tas k
Pro ject
Int erna l
Wor k Pr oduc t Del iver able
Bernd Bruegge & Allen H. Dutoit
Wor k
Bre akdo wn
Str uctu re
Fun d
Par tici pant Sta ff
Pro ject Fun ctio n
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Dep artm ent Tea m
46
Another attempt to navigate through the same model
Pro ject
Sch edul e
Wor k
Pro duct
Bernd Bruegge & Allen H. Dutoit
Tas k
Par tici pant
Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
Another attempt to navigate through the same model
Pro ject
Sch edul e
Wor k
Pro duct
Bernd Bruegge & Allen H. Dutoit
Tas k
Par tici pant
Object-Oriented Software Engineering: Using UML, Patterns, and Java
48
Equ ipme nt
Pro ject
*
Fac ilit y
Res ourc e
Fun d
*
Sch edul e
*
*
Out come
*
*
Set of Work
Pro duct s
Wo rk
Br eakd own
St ruct ure
Wor k
Pro duct
Bernd Bruegge & Allen H. Dutoit
co nsu mes
des Wor k
cri bes Pac kage
*
Org anizat ion
*
Org aniz atio nal
res
ponUni t
Wo rk
*
sib le pla ys
de pend s for
Rol e
Ac tivi ty Tas k
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Par tici pant Sta ff
49
How much Process?






Modeling a software life cycle similar to modeling a system.
+ The process allows to reason over it, devise and implement improvements
+ Participants can share process knowledge with the rest of the
organization.
- Process knowledge is difficult to make explicit and maintain up-to-date
Trade-off faced by the project manager:
 From no modeling of the process to detailed process that may be
tailored.
Well-known application domain or solution domain:
 Use a repeatable process model [Paulk et al., 1995]
Distributed organization:
 Use of a process model enables a high degree of standardization and a
lower level of miscommunication.
Prototyping or concept exploration
 Trying to control such a process is difficult or not useful, as it is usually
not repeated. Best to follow an entity-based life cycle.
Colocated experienced developers
 Follow an entity-based life cycle or use no process.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Pitfalls when repeating a process


When modeling a software life cycle process and reusing it in a
different project, the project manager should make sure that the
correct knowledge is being generalized and reused.
Example: First ascent of K2
 Mahdi had experienced one climb (Nanga Parbat) which started as a
hierarchical, fixed rope expedition.
 At the end he saw one climber (Buhl), refusing to listen to the
expedition leader and going solo for the summit (in alpine style, so to
speak).
 He concluded that this was the way such expeditions were
conducted.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
How much Control and Monitoring?




If the project has a detailed plan the actual progress can be checked against
the planned progress
 On one end of the spectrum, a plan could be so detailed as to plan and
monitor the progress of each participant on each day.
 At the other end of the spectrum, a plan could include a single milestone
indicating the delivery, leaving participants to plan their own work
accordingly.
 While both approaches are unreasonable, the project manager must choose a
point somewhere in between that fits the project environment.
Control and monitoring is especially critical during an iterative process.
 The change process needs to track changes, from request, to approval,
assignment, and implementation. Metrics such as the amount of code that was
scraped or reworked and the size of the change are critical to control the
overall quality of the system.
In general, both planning and assessing the actual progress requires
experience.
Two major problem areas:
 Projects with novices
 Projects involving the development of innovative systems
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Controlling Projects involving Novices
Projects involving novices are hard to control. Two reasons
1. Estimation of tasks is difficult



Novice project managers are poor judges of time estimates for tasks.
Project managers without technological experience are poor judges of time
estimates for development tasks.
Novice participants are poor judges of their progress
2. Difficult issues are not recognized/communicated in a timely manner
Heuristics to deal with these problems:
 Select a hierarchical reporting organization with more experienced
participants in the middle levels.
 Define milestones as demonstration and scenario-based reviews (as opposed
to documents) to force participants to confront difficult issues early.
 Select peer-reviews, walkthrough, and peer programming techniques, to
facilitate the transfer of knowledge from experts to novices
 Create the possibility of informal communication channels
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Controlling projects for innovative systems
 The development of an innovative system makes it difficult to plan
accurately as there is a lack of precedents.
 To control an innovative development, a project manager can
increase the frequency of milestones, while leaving their exact
content flexible, providing more opportunities for project goals to be
refined and redirected.
 If the developers are experienced, a project manager can leverage off
the knowledge of experienced developers by enabling them to
provide estimates for tasks and revise the project plan or the process
model accordingly.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
If the Project Goal cannot be achieved



A project goal is too ambitious or the original goal is simply wrong.
Continuing is not an option.
Option 1: Ask for more resources or a revised schedule.
 Often not really an option, because there is no more money and the
schedule is fixed.
Option 2: Admit the problem and turn the project into a “successful
failure”:
 Do a thorough analysis to understand what went wrong.
 Focus on the failure to determine lessons learned.
 Try to recycle the work that has been achieved so far for another
project.

Option 3: Revise the project goal
 Turn the current project status into the goal.
 Sometimes the revised project goal is actually as good or better
than the originally envisioned goal (“Polynesian navigation”).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
Methodologies


Separate Slide Set for Royce’s Methodology
Separate Slide Set For Extreme Programming
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
Methodology Do’s and Do Not’s







Try to train the client.
Train the developers about the process
Try to find a dedicated lab for all the developers
Think carefully about how to maintain the infrastructure
Use version control as an integration tool
Make sure to have resources to deal with iteration overlaps
Make sure to allow informal communication
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
57
Methodological Heuristics






Be prepared to change the system
 Functional requirements can change during a project when the client
becomes more experienced
 Technological change can occur any time
Be prepared to change the organization
 Move from hierarchical organization to participatory management when
project participants are becoming capable of making decisions
Be prepared to change the process
 Move from activity-oriented to entity-oriented during a project when
beginners become experienced developers
Shorten client decision time
 Train the client
Build trust
Learn the right lessons and nothing more.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
58
Summary







Invest time to train the client.
Train the developers about the process
Try to find a dedicated lab for all the developers
Think carefully about how to maintain the infrastructure
Use version control as an integration tool
Make sure to have resources to deal with iteration overlaps
Make sure to allow informal communication
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
59
Backup Slides
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
60
More White Water pictures
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
61