Chapter 16, Methodologies: Putting it all together

1
Chapter 16, Methodologies Putting it all
together
2
Outline

• A Mountaineering Example
• Project Context
• Goals, Environment, Methods, Tools, Methodology
• Methodology Issues
• Planning, Design Reuse, Modeling, Process,
  ControlMonitoring, Redefinition
• Methodology Spectrum
• Royces Methodology based on the unified process
  (Separate Slides)
• Extreme Programming (Separate Slides)
• Methodological Heuristics

3
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

4
Key Decisions in an Software Project

• Project goals
• Schedule
• Cost
• Project organization
• Software life cycle Model
• Tools
• Methods
• Team members

5
Project Context

• Project environment
• Defined by the client and by the current state of
  the development organization. The environment
  constrains the project manager.
• Examples Participants background, problem type,
  location of the project.
• 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 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.

6
Project Environment

• Participants expertise
• Client type(Application Domain Knowledge,
  Decision Power)
• End user access
• Technological climate
• Geographical distribution
• Project duration vs rate of change

7
Client Type

• Local King Client
• Can make decisions
• 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.

• Proxy Client
• Stands in for real client, who has no time or
  physical distance makes collaboration with the
  organization difficult.
• Has sufficient knowledge of application domain
• Cannot make major decisions.

Low
High
Domain Knowledge
Decision Power
Local King Client
Pseudo Client
High

• Pseudo Client
• Often member of the development organization
  (e.g. marketing)
• The system is targeted at new market segment.
• Can make decisions in a short time
• Collaborates well with developers
• Limited knowledge of application domain.

• No Client
• Many projects start without a client.
• Example A visionary product is developed before
  a market segment is opened.

No Client
Proxy Client
Low
8
Local King Client

• The local king client is a client who can answer
  developer questions and make decisions without
  having to ask anybody else.
• The local king has deep knowledge of the
  application domain and is usually collocated with
  the project.
• Local kings do not report to anybody else and can
  effectively collaborate with the developers and
  the project manager.

9
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.

10
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.

11
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.

12
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

13
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.

14
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

15
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?

16
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

17
European Navigation
Event Course deviation.
18
Polynesian Navigation
We need a new place for living. Lets go to
Auckland
Event Birds seen
19
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.

20
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

21
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

22
Example Running a rapid
A quiet river
Unplanned event A Hydraulic!
Desired Location
Current Location
What can we do?
23
Change

• Change
• Something becomes clear (crystalizes)
• Something new appears (technology enabler)
• Something becomes important (change of
  requirements)

24
Project duration vs Rate of Change

• Three Definitions
• PT Project Time

• TBC Time Between Any Type of Change
  (Requirements, Technology)

• MTBC Mean Time Between Change

Phase 1
Phase 2
Phase 3
to
tn
t1
t2
25
Frequency of Change determines the Choice of the
Software Lifecycle Model

• Mean Time between Change gtgt 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 Boehms spiral model, Unified Process
  
• Mean Time between Change ltlt Project Time
• Changes are normal (Change is constant)
• Choose an entity-oriented model Issue-based
  model, Feature-driven model

26
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

27
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?

28
How much Reuse?

• Reuse can significantly reduce the development
  effort required to deliver a system.

29
(No Transcript)
30
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.

31
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.

32
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.
• Models are beginning to support Model-Driven
  Architecture RJL
• UML2.0/MDA includes Code Generation
• Persistent database management from static
  information models
• Behavioral control flow from state transition
  models
• Concurrent distributed systems from Activity
  Diagrams
• Use cases validated from Sequence Diagrams (event
  history traces)

33
The Future of Models? RJL - 05s523

• Models are beginning to support Model-Driven
  Architecture
• This implies complete consistent unambiguous
  specification
• UML2.0/MDA anticipates Code Generation for
• Persistent database management from static
  information models
• Behavioral control flow from state transition
  models
• Concurrent distributed systems from Activity
  Diagrams
• Use cases validated from Sequence Diagrams (event
  history traces)
• This is state-of-the art in specialized
  application domains
• CCITTs SDL for Telecommunications apps
• MicroSofts initiative for Domain-Specific
  Languages (SDL)
• (Possibly in response to OMGs UML2/MDA)
• For embedded software applications using
  ExecutableUML tools
• Project Technology/Bridgeport/Steve Mellor
• Kennedy-Carter, LTD/Alan Carter
• PathFinder Solutions/Peter Fontaine

34
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 dont know UML.
• Communication Media
• Can be on a Whiteboard, on a slide or even on a
  napkin.
• .

35
Napkin Design
36
Model for Bus Stops (used in Slide Presentation)
Street Segments
Bus Stop
Adresses, length
Schedule
Bus Route
Street
name
name
Bus
37
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.

38
A UML Model for Bus Stops
next to

located on
Bus Stop
Street Segment
location
Addresses(left, right) length

Day
number


line id
Schedule
line id
Bus Route
Street
Time

name type
name
traverses
stops at
exactly 2

Intersection
Bus

id x,y
39
Input for User Interface Generator
40
Models to support Archival
41
Screen Snapshot of Graphical User Interface
42
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.

43
Model of a Software Project



44
Model of a Software Process
Example V-Model
45
Models for Platos and Aristotles Views of
Reality
Aristotle
Plato
46
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

47
Example A More Complex Model of a Software
Project
48
Another attempt to navigate through the same model
49
Another attempt to navigate through the same model
50
(No Transcript)
51
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.

52
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.

53
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

54
Controlling Projects involving Novices

• Projects involving novices are hard to control.
  Two reasons
• 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
• 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

55
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.

56
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).

57
Methodologies

• Separate Slide Set for Royces Methodology
• Separate Slide Set For Extreme Programming

58
Methodology Dos and Do Nots

• 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

59
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.

60
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

61
Backup Slides
62
More White Water pictures