Upload
guestc990b6
View
9.130
Download
1
Embed Size (px)
DESCRIPTION
Comparative Development Methodologies
Citation preview
Comparative Development Methodologies
Lecture 10
Niki Trigoni
Department of Computer Science
and Information Systems
Birkbeck College, University of London
Email: [email protected]
Office Hours: Wednesdays, 6 - 7 pm
Web Page: http://www.dcs.bbk.ac.uk/~niki
Review of lecture 9
Two different kinds of methodologies:
rapid development methodologies and
organizational-oriented methodologies
Overview of Extreme Programming (XP), a rapid development
methodology suitable for small to medium systems. The most
important features are user stories, early feedback from the
customer, unit test code, pair programming, refactoring and
acceptance tests.
Overview of Soft Systems Methodology (SSM), an
organizational-oriented methodology suitable for approaching
more fuzzy problem situations where different stakeholders view
the system from different perspectives.
Overview of lecture 10
1. Frameworks
2. Methodology issues
3. Methodology comparisons
Frameworks
Frameworks provide guidance to the developer in choosing
methods, techniques, and tools rather than a prescriptive
(methodology-style) step-by-step approach.
Examples of frameworks:
Multiview
Strategic Options Development and Analysis (SODA)
Capability Maturity Model (CMM)
Euromethod
Frameworks: Multiview
It is a „multi-view‟ in the following sense:
As an information systems project develops, it takes on
different perspectives or views: organizational, technical,
human-oriented, economics and so on.
It brings together techniques from multiple methodologies.
It incorporates five different views in five stages:
Analysis of human activity
Analysis of information
Analysis and design of socio-technical aspects
Design of the human-computer interface
Design of technical aspects
Frameworks: Multiview stages
1. Analyze human
activity
2. Analyze
information
3. Analyze and
design socio-technical
aspects
4. Design human-
computer interface
5. Design
Technical
aspects
primary
task
model
function
model
entity
modelentity
model computer tasks
role set
people tasks
technical
requirements
Frameworks: Multiview concerns
The methodology must help answer the following questions:
Q1: How will the computer system further the aims of the
organization installing it? (top management concern)
Q2: How will it be fitted into the working lives of the people in
the organization that are going to use it? (trade union concern)
Q3: How can the individuals concerned best relate to the
machine in terms of operating it and using the output from it?
(users concern)
Q4: What information system processing function is the
system to perform? (systems analysts concern)
Q5: What is the technical specification of a system that will
come close enough to doing the things written down in the
answers to the other four questions? (designers concern)
Frameworks: Multiview framework
1.
2.
3..
4.
5.
1.Human activity
(Q1)
2. Information
(Q4)
3. Socio-technical
(Q2)
4. Human-computer
interface (Q3)
5. Technical
(Q5)
Frameworks: Multiview framework
Stage 1: Analysis of human activity
Based on SSM (Mode 1)
Central focus: Search for a particular world view
Form rich pictures of the problem situation
Let rich pictures stimulate discussion between the problem
solver and the problem owner
Extract problem themes from rich pictures
Form root definition
Construct a conceptual model
Compare the completed conceptual model to the representation
of the „real world‟ in the rich picture
Debate possible changes to improve the problem situation …
Frameworks: Multiview framework
Stage 2: Analysis of information
Takes as input the root definition/conceptual model from stage 1
Two main phases:
the development of a functional model:
identify the main function
decompose functions successively (4-5 levels)
provide hierarchical model and DFDs as input into stage 3
the development of an entity model
Extract and name entities from the area of concern
Establish relationships between entities
Construct an entity model and provide it as input to stages
4 and 5
Frameworks: Multiview framework
Stage 3: Analysis and design of the socio-technical aspects
Philosophy: people should be allowed to participate in the analysis
and design of the systems that they will be using
Human considerations: job satisfaction, task definition, morale
Consider both social and technical objectives
Specify both social and technical alternatives
Match socio-technical alternatives
Rank in terms of meeting socio/technical objectives
Consider costs/resources/constraints and rank accordingly
Select best socio-technical solution
Define computer task, role set, and people tasks for solution
Frameworks: Multiview framework
Stage 4: Design of the human-computer interface
Takes as input the entity model from stage 2, and the computer
tasks, role-set, and people tasks from stage 3
Philosophy: the ways in which users will interact with the
computer will have an important influence on whether the users
will accept the system
Works on the technical design of the human-computer interface
batch vs. online facilities
conversations and interactions with particular types of user
necessary inputs and outputs, error checking, minimization of
number of keystrokes
Frameworks: Multiview framework
Stage 5: Design of the technical aspects
Takes as input the entity model from stage 2 and the technical
requirements from stage 4
Takes a technical view towards an efficient design of the system
Final outputs are:
application subsystem (impl. functions in the function chart)
information retrieval subsystem (responds to data enquiries)
database (and db maintenance subsystem)
control subsystem (alerts for user/program/operator errors)
recovery subsystem (repairs system after error detection)
monitoring subsystem (records all system activities)
Frameworks: SODA
Strategic Options Development and Analysis (SODA)
“SODA is an approach designed to provide consultants with a
set of skills, a framework for designing problem solving
situations and a set of techniques and tools to help their clients
work with messy problems” [Eden and Ackerman, 2001]
Four perspectives:
individual (tries to make sense of the organization)
nature of organizations (political and power aspects play an
important role in decision making; role negotiation)
consulting practice (role of negotiation in effective problem
solving, managing consensus and commitment)
technology and techniques (used to bring together the first
three elements)
Frameworks: CMM
Capability Maturity Model (CMM) [Paulk 1993, Weber 1991]
CMM is a framework for evaluating processes used to develop
software projects
Processes are grouped into five levels based on their „maturity‟
1. Initial level (“heroic level”):
adhoc (and chaotic) development
success/failure depends on the individuals involved
not sustainable
late and over-budget software delivery
2. Repeatable level
identifiable policies for managing software development
realistic plans based on performance of previous projects
cost estimates, schedules, project standards
Frameworks: CMM (cont.)
Continuing enumeration of maturity levels
3. Defined level
standard S/E processes documented
well-defined, stable development approach
includes readiness criteria, inputs, standards, procedures,
verification mechanisms, outputs and completion criteria
organization-wide training program for learning process
quality and technical progress monitoring by management
4. Managed level
quantitative quality and productivity measures
software process db used to collect process-related data
analysis of methodology effectiveness
predictable processes and quick exception handling
Frameworks: CMM (cont.)
Continuing enumeration of maturity levels
5. Optimizing level
proactive and continuous process improvement
ability to identify strengths and weaknesses
assess new technologies and process innovations
standard activity of planning and managing process change
Frameworks: Euromethod
Euromethod: part of the IT standardization policy of the EU
Objective: to facilitate cross-border trading by providing a
common understanding of requirements and solutions among
users from different countries
Problem: diversity in approaches, methods and techniques in
information systems used in Europe
Based on experiences with existing methods:
SSADM (from the UK)
Merise (from France)
IE (from the UK/US)
SDM (from the Netherlands)
DAFNE (Italy), MEIN (Spain), Vorgehensmodell (Germany)
Frameworks: Euromethod
Euromethod applies to any information systems adaptation:
development or modification of an information system providing
that the initial (or current) state and the required final state can
be defined.
Euromethod focuses on the understanding, planning and
management of the contractual relationships between
customers and suppliers of information systems adaptations.
Types of transactions in an IS adaptation
Call for tender
Tender response
Supplier selection
Contract award
Approval of deliverables
Approval of status
and plans
Contract change control
Approval of final
deliverables
Contract
completion
TENDERING PRODUCTION COMPLETION
Frameworks: Euromethod
Euromethod includes elements relating to „procurement‟ rather
than development of information systems
Its concept is to bridge different methodologies by following
three models: the transaction model, the deliverable model and
the strategy model
The transaction model helps manage customer/supplier
interactions across organizational boundaries
The deliverable model defines the target domain (data,
functions, architecture) for an information systems
adaptation, incl. the goals, the key roles and responsibilities
of the customer and the supplier
The strategy model assesses the problem situation and selects
a strategy with well defined decision points to get
successfully to the final state of the adaptation.
Overview of lecture 10
1. Frameworks
Multiview
Strategic Options Development and Analysis (SODA)
Capability Maturity Model (CMM)
Euromethod
2. Methodology issues
Components of a methodology
Rationale for a methodology
Adopting a methodology in practice
Evolution of methodologies
3. Methodology comparisons
Issues: methodology components
How a project is to be broken down into stages
What tasks are to be carried out at each stage
What outputs are to be produced
When, and under what circumstances, thay are to be carried out
What constraints are to be applied
Which people should be involved
How the project should be managed and controlled
What support tools may be utilized
What are the training needs of the methodology users
Which is the philosophy, i.e. the underlying theories and
assumptions of the methodology authors that have shaped the
development of the methodology
Issues: rationale for a methodology
1. A better end product
Acceptability (do people find the product satisfactory?)
Availability (is the product accessible when/where required?)
Cohesiveness (are information and manual systems integrated?)
Compatibility (does the system fit with other parts of the organization?)
Documentation
Ease of learning
Economy (is the system cost effective, within resources and constraints?)
Effectiveness (does the system meet business/organizational objectives?)
Efficiency (does the system utilizes resources to their best advantage?)
Fast development rate (time relative to project size and complexity)
Flexibility (is the system easily modifiable?)
Functionality (does the system cater for the requirements?)
Implementability (feasible changeover from the old to the new system?)
Low coupling (is there low interaction between subsystems so that
changes of one does not affect the others significantly?)
Issues: rationale for a methodology
1. A better end product (cont.)
Maintainability
Portability (can the system run on other equipment or in other sites?)
Reliability (is the error rate minimized and are outputs consistent?)
Robustness (is the system fail-safe and fault-tolerant?)
Security
Simplicity
Testability
Timeliness (does the system operate well under normal, peak, and every
condition?)
Visibility (is it possible for users to trace why certain actions occurred?)
Issues: rationale for a methodology
2. A better development process
Tight control of the development process
Well-specified deliverables at each stage
Improved management, planning and project control
Increase of productivity
Reduction of skills required of analysts => reduction of cost
3. A standardized process
Staff can change between projects without retraining
Common experience and knowledge can be accumulated
Easy system maintenance
Better systems integration
Issues: adopting a methodology in practice
Variation points of different methodologies:
fully fledged product detailing every stage and task or vague
outline of basic principles
high-level strategic and organizational problem solving or
details of implementing a computer system
conceptual issues or physical design procedures or the whole
range of intermediate stages
applicable to specific problem types or all-encompassing
general-purpose methodology
usable with or without special training
people it requires to complete tasks (if specified)
tools and toolsets used
Issues: adopting a methodology in practice
Methodology adopters should be aware of these variations and of
their particular needs in order to make an educated decision of
using a methodology
Methodology-related costs
initial purchase
training of personnel
required hardware and software
ongoing consultancy
Involve users, analysts and managers in the decision of selecting a
methodology (it should not be purely an IT department decision)
Are we guaranteed successful information systems as a result of
using a methodology?
Issues: adopting a methodology in practice
Developers may interpret the demands of the methodology
differently and thus end up with different results
Flexibility in how specified tasks are performed is another source
of uncertainty about the expected results
Despite variations, multiple uses of a methodology should yield
roughly the same results. Of course, this also depends on the
methodology itself
The adoption of a methodology can be viewed as an attempt to
reduce the degrees of freedom, by embodying a good practice for
developing an information system
Main criteria for selecting a methodology:
Whether it fits with the organization‟s way of working
Whether it specifies deliverables at the end of each stage
Whether it enables better control and improved productivity
Whether is supports a particular set of tools
Issues: evolution of methodologies
Pre-methodology era: until early 1970s
Information systems were developed without the use of an
explicit development methodology
Emphasis on programming and solving technical problems
Individualistic development approach
Lack of regard for the organizational context
Poor project control and management
Growing interest in standards and a more disciplined approach
Issues: evolution of methodologies
Early-methodology era: from early 1970s to early 1980s
Focused on identification of phases and stages to control and
manage systems development
Waterfall model: feasibility study, systems investigation,
analysis, design, development, implementation, maintenance
Well-defined set of deliverables upon the completion of a stage
Trained users and developers
Documentation standards
Issues: evolution of methodologies
Methodology era: from mid 1980s to mid/late 1990s
Methodologies emerging both from theory and from practice
The methodology, rather than consultancy about the
methodology, became the product, resulting in:
Write-up of the methodology
Consistency and comprehensiveness
Marketability and maintainability
Evolution into training packages
Provide with supporting software
Whilst creating methodology products
Many gaps were filled
The scope of methodologies was expanded (to more stages
and higher organizational levels)
Strategic and planning aspects were introduced (to gain
competitive advantage
Issues: evolution of methodologies
Era of methodology reassessment: from late 1990s onward
Reappraisal of methodologies (change or abandon of specific
methodologies)
Criticisms of methodologies:
Productivity: time consuming and resource intensive
Complexity: designed for large projects
Encouraging the creation of „wish lists‟ by users
Skills: training is required for their use
Tools: shift focus to documentation rather than
analysis/design, complex to use
Not contingent upon the type of project or its size
One-dimensional approach: narrow solution
Inflexible: not allowing changes to requirements
Invalid or impractical assumptions (e.g. coherent business
strategy)
Issues: evolution of methodologies
Era of methodology reassessment: from late 1990s onward
Criticisms of methodologies (cont.):
Goal displacement: focus on the procedures to the
exclusion of the real needs of the project
Problems of building understanding into methods: it is not
enough to understand methods in order to understand the
problem situation
Insufficient focus on social and contextual issues:
overemphasis on the narrow technical development
Difficulties in adopting a methodology: resistance from
developers and users
No improvements: not only it did not help, but it also
hindered development
Issues: evolution of methodologies
Era of methodology reassessment: from late 1990s onward
New directions:
Ad hoc development: rely on the experiences of developers
Further developments in the methodology arena: evolution
of existing methodologies or development of new ones
(object-oriented, RAD, prototyping, CRM approaches
seem to be gaining ground)
Contingency: use the methodology as a general structure,
and pick tools and techniques depending on the situation
External development: use of packages and outsourcing is
effective for organizations with well-defined requirements,
Enterprise Resource Packages (ERPs)
Overview of lecture 10
1. Frameworks
Multiview
Strategic Options Development and Analysis (SODA)
Capability Maturity Model (CMM)
Euromethod
2. Methodology issues
Components of a methodology
Rationale for a methodology
Adopting a methodology in practice
Evolution of methodologies
3. Methodology comparisons
Criteria
Framework
Comparison
Methodology comparison criteria
What aspects of the development process does the methodology
cover?
What overall framework or model does it utilize? (SDLC, linear,
spiral)
What representation, abstractions and models are employed?
What tools and techniques are used?
Is the content of the methodology well defined, such that a
developer can understand and follow it? (stages, tasks, philosophy,
objectives)
What is the focus of the methodology? (processes, data, blended,
organization, people) Does it address strategic issues?
How are the results at each stage expressed?
Methodology comparison criteria
What situations and types of application is it suited to?
Does it aim to be scientific/systemic/behavioral?
Is a computer solution assumed? What other assumptions are
made?
Who plays what role? Does it assume professional developers,
require a methodology facilitator, involve users and managers, and
if so, to what degree?
What particular skills are required of the participants?
How are conflicting views and findings handled?
What control features does it provide and how is success
evaluated?
What claim does it make as to its benefits? How are these claims
substantiated?
What are the philosophical assumptions of the methodology?
Methodology comparison criteria
Other criteria you would consider:
Rules and standardization
Coverage …
Methodology comparison framework
1. Philosophy
• Paradigm
• Objectives
• Domain
• Target
2. Model
3. Techniques and tools
4. Scope
5. Outputs
6. Practice
• Background
• User base
• Participants
7. Product
Method. comp. framework: philosophy
Philosophy
Set of principles that underlie a methodology
Four distinguishing factors:
1. Paradigm: specific way of thinking about problems
science vs. systems paradigm
science paradigm (by reductionism, repeatability and
hypotheses refutation)
systems paradigm (concern for the whole picture,
emergent properties, and interrelationships between
parts of the whole)
2. Objectives, e.g.
to develop a computerized information system?
to discover if there is a need for a computerized
system?
Method. comp. framework: philosophy
Philosophy (cont.)
Four distinguishing factors (cont.):
3. Domain: situations that methodologies address
narrow problem vs. wider organization-level problems
individual problems vs. many interrelated problems
viewed as a whole
4. Target: applicability of the methodology
general-purpose vs. application/organization specific
Method. comp. framework: model
Model: abstraction and representation of the important factors
of the information system or the organization
Verbal
Analytic or mathematical
Iconic, pictorial or schematic
Simulation
Most methodologies are iconic, pictorial or schematic.
Models are used as a means of communication, particularly
between users and analysts
Method. comp. fram.: techniques & tools
Techniques and Tools:
Are techniques and tools essential to the methodology?
Which techniques/tools are used in a methodology?
Examples:
Rich pictures, root definitions, etc
Entity modeling and normalization
DFDs, decision tables, decision trees, entity life cycles
OO design and UML
Various organizational and people techniques
Method. comp. framework: scope
Scope: indication of the stages of the life cycle of systems
development that the methodology covers
Recall SDLC (Systems development life cycle)
Feasibility study
System investigation
Systems analysis
Systems design
Implementation
Review and maintenance
Method. comp. fram.: outputs & product
Outputs: what the methodology is producing
Deliverables at each stage
Nature of final deliverable
Decision about whether to computerize a process
Analysis specification
Working implementation of a system
…
Product: what purchasers actually get for their money
Software
Written documentation
Agreed number of hours training, consultancy
Telephone help service
...
Method. comp. framework: practice
Practice:
Methodology background: academic vs. commercial
User base: numbers and types of users
Participants and skill levels required
Assessment of difficulties and problems encountered
Perception of success and failure
Degree to which the methodology is altered by the users
according to the requirements of the situation
Differences between the theory and the practice of the
methodology
Methodology comparison: philosophy
Philosophy:
Paradigm:
SSM adopts systems paradigm (avoids reductionist
approach)
STRADIS, YSM, IE, SSADM, MERISE, RUP etc.
adopt the science paradigm
Objectives:
STRADIS, YSM, IE, SSADM, MERISE, RUP etc have
clear objectives to develop computerized information
systems
SSM aims at much more than developing an IT system
Methodology comparison: philosophy
Philosophy:
Domain:
IE, and SSM address general planning, organization, and
strategy of information and systems in the organization
(IE‟s first stage is information strategy planning)
STRADIS, YSM, SSADM, Merise and RUP are classified
as specific problem-solving methodologies
Target:
RUP: general-purpose, not very useful for small systems
STRADIS: general-purpose, DFDs not suitable for
management information systems or web-based systems
SSM: more applicable in human activity „messy‟ situations
XP: suitable for small and continuously evolving systems
most methodologies (not XP) designed for large systems
Methodology comp.: model and techniques
Model:
STRADIS uses primarily DFDs
DFDs are also used in YSM, SSADM, IE, SSM (but play a less
significant role than in STRADIS)
SSADM, IE, Merise, RUP integrate both processes and data
Techniques:
STRADIS is largely described in terms of its techniques
SSM does not heavily use techniques and tools
YSM, SSADM, RUP specify techniques and view them as
important for the methodology
IE explicitly suggests that the techniques are not a fundamental
part of the methodology
Methodology comparison: scope & product
Scope: (see figure 27.3 in Information Systems Development, by
Avison and Fidzgerald)
Product:
SSADM comes with a large set of manuals
SSM comes only with some academic papers
RUP has a range of books, and online specs
Some methodologies offer certification of competency for
developers
Methodology comp.: outputs & practice
Outputs:
Methodologies differ significantly in terms of
Kinds of deliverables
Degree of detail in which they are specified
How deliverables are used to measure progress and move
to the next stage
Practice:
STRADIS, YSM, IE, SSADM: commercial origin
Merise, SSM, RUP: academic origin
STRADIS, YSM, IE, SSADM, Merise, RUP: professional
technical developers
SSM: both business and technical people
Summary of lecture 10
1. Frameworks
Multiview
Strategic Options Development and Analysis (SODA)
Capability Maturity Model (CMM)
Euromethod
2. Methodology issues
Components of a methodology
Rationale for a methodology
Adopting a methodology in practice
Evolution of methodologies
3. Methodology comparisons
Criteria
Framework
Comparison