Comparative Development Methodologies

Comparative Development Methodologies
Lecture 10
Niki Trigoni
Department of Computer Science
and Information Systems
Birkbeck College, University of London

Email: niki@dcs.bbk.ac.uk
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

5. Design technical
Technical requirements
aspects

4. Design human-
entity computer interface
model
entity
model computer tasks
role set
people tasks
primary
task
model 3. Analyze and
1. Analyze human 2. Analyze
activity information design socio-technical
function aspects
model

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.Human activity 1.
(Q1)
2.
2. Information 3..
(Q4) 4.
3. Socio-technical 5.
(Q2)

4. Human-computer
interface (Q3)

5. Technical
(Q5)

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 …

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

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

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

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
 “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)

 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 Approval of deliverables Approval of final
Tender response Approval of status deliverables
Supplier selection and plans Contract
Contract change control completion
Contract award

TENDERING PRODUCTION COMPLETION

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

1. Frameworks
 Multiview
 Euromethod
 Components of a methodology
 Rationale for a methodology
 Adopting a methodology in practice
 Evolution of methodologies

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

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

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

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

 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

 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

 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

 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)

 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

 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)

1. Frameworks
 Multiview
 Euromethod
 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?

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

 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
 Euromethod
 Criteria
 Framework
 Comparison

Comparative Development Methodologies

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Comparative Development Methodologies

Ähnlich wie Comparative Development Methodologies (20)

Mehr von guestc990b6

Mehr von guestc990b6 (11)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Comparative Development Methodologies