methodology or process?
Method/Process = step-by-step description
of the steps involved in doing a particular job
No two projects are ever identical, so
method is specific to one project
Methodology = set of general principles
that guide the choice of a method suited
to a specific task or project
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 1
method/process vs methodology
Level of
abstraction
Task
Technique
Method/Process
Methodology
University of Toronto at Scarborough
Example of
application
Typical
product
Developing a first-cut class
diagram
Specific version of a
class diagram
Description of how to carry out a
technique, e.g. UML class
modelling
Any UML class
diagram
Specific techniques used on a
particular project that lead to a
specific software product
A product costing
system
General selection and sequence
of techniques capable of
producing a range of software
products
A range of business
software
applications
© Kersti Wain-Bantin
CSCC40 other methodologies 2
Contribution
of users
Initial analysis
and design
Implement
exploratory prototype
(mock-up)
Contribution of
developers
Evaluate prototype,
further analysis and
design
Design
Implement
‘conventional’ prototype
typical
participatory
design
lifecycle
Evaluate ‘conventional’
prototype
‘Traditional’ specification
Build ‘final’ system
Continuing development
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 3
elements of a methodology
Technique: the UML class diagram
Tool: Rational Rose (CASE software)
Procedure: Find classes by inspecting use case descriptions
Structure: Operation specifications should not be written until
class model is stable (also the stages)
Stages: Inception, Elaboration, Construction…
Activities: Requirements, Analysis, Design…
Philosophy: OO development promotes software which is robust
and resilient to change
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 4
Unified Software Development Process
(USDP)
Public domain methodology for Object-Oriented
software development
Main principles:
Use-case driven
Architecture-centric
Iterative development
Incremental development
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 5
Unified Software Development Process (USDP)
http://en.wikipedia.org/wiki/Unified_Software_Development_Process
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 6
Unified Software Development Process (USDP)
Agile Unified Process (AUP),
a lightweight variation developed by Scott W. Ambler
Basic Unified Process (BUP),
a lightweight variation developed by IBM and a
precursor to OpenUP
Enterprise Unified Process (EUP),
an extension of the Rational Unified Process
Essential Unified Process (EssUP),
a lightweight variation developed by Ivar Jacobson
Open Unified Process (OpenUP),
the Eclipse Process Framework software development process
Rational Unified Process (RUP),
the IBM / Rational Software development process
Oracle Unified Method (OUM),
the Oracle development and implementation process
Rational Unified Process-System Engineering (RUP-SE),
a version of RUP tailored by Rational Software
for System Engineering
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 7
Dynamic Systems Development Method
(DSDM)
= a management and control framework for
Rapid Application Development
Prototyping
DSDM fixes resources for the project, fixes the time available
and then sets out to deliver only what can be achieved within
these constraints
The DSDM life cycle has these phases:
feasibility study
business study
functional model iteration (using prototypes)
design and build iteration (continue with prototypes)
implementation
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 8
Dynamic Systems Development Method
(DSDM)
http://en.wikipedia.org/wiki/DSDM
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 9
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 10
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 11
DSDM is based upon 9 underlying principles
1. Active user involvement is imperative.
2. DSDM teams are empowered to make decisions including
refining or changing requirements without the direct
involvement of higher management.
3. The focus is on frequent product delivery. A team delivers
product(s) within a timebox (2 – 6 weeks) and adopts the
most appropriate approach.
4. Fitness for purpose is the key criterion. DSDM is geared to
delivering essential functionality at the specified time.
5. Iterative and incremental development is necessary to
converge on an accurate business solution. Incremental
development allows user feedback to inform later
development.
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 12
DSDM is based upon 9 underlying principles
6.
All changes during development are reversible. This allows
inappropriate iterations to be undone.
7.
Requirements are initially agreed at a high level. These
provide objectives for prototyping and can be investigated by
the teams. Normally the scope of the high level requirements
are not changed significantly.
8.
Testing is integrated throughout the life cycle — this is
essential with an incremental approach. Developers test for
technical compliance, user team members for functional
compliance.
9.
A collaborative and co-operative approach between all
stakeholders is essential. Includes resource managers and
quality assurance teams.
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 13
Principles of Extreme Programming (XP)
Communication - XP highlights the importance of good
communication among developers and between developers and
users.
Simplicity - XP focuses on the simplest solution for the
immediate known requirements.
Feedback - Feedback in XP is geared to giving the developers
frequent and timely feedback from users and also in terms of
test results. Work estimates are based on the work actually
completed in the previous iteration.
Courage - Urges the developer to throw away code that is not
quite correct and start again. Essentially the developer has to
leave unproductive lines of development despite personal
investment in the ideas.
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 14
Principles of Extreme Programming (XP)
Based on user stories that describe the requirements
– written by the user
– the basis of project planning and the development of test
harnesses
Very similar to use cases though some proponents of XP suggest
that there are key differences in granularity
– typical user story is about three sentences with no
technology indicated
– developers get detailed descriptions from the customer when
they start developing
Best suited to projects with a relatively small number of
programmers—say no more than ten
Critical to maintain clear communicative code and to have rapid
feedback (If these are not possible then XP would be
problematic)
XP not sympathetic to using UML for analysis & design
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 15
XP Activities
The planning game involves quickly defining the scope of the next
release from user priorities and technical estimates.
The plan is updated regularly as the iteration progresses.
The information system should be delivered in small releases that
incrementally build up functionality through rapid iteration.
A unifying metaphor or high level shared story focuses the
development. The system should be based on a simple design.
Programmers prepare unit tests in advance of software
construction and customers define acceptance tests.
The programme code should be restructured to remove duplication,
simplify the code and improve flexibility (refactoring).
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 16
XP Activities
Pair programming means that code is written by two programmers
using one workstation.
The code is owned collectively and anyone can change any code.
The system is integrated and built frequently each day. This gives
the opportunity for regular testing and feedback.
Normally staff should work no more than forty hours a week.
A user should be a full-time member of the team.
All programmers should write code according to agreed standards
that emphasise good communication through the code.
University of Toronto at Scarborough
© Kersti Wain-Bantin
CSCC40 other methodologies 17