Comparative Development Methodologies

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

mxiixm

Rectangle

mxiixm

Underline

mxiixm

Underline

mxiixm

Strikeout

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

mxiixm

Underline

mxiixm

Underline

mxiixm

Underline

mxiixm

Underline

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)

mxiixm

Underline

mxiixm

Underline

mxiixm

Underline

mxiixm

Underline

mxiixm

Underline

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)


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 …

mxiixm

Underline

mxiixm

Underline


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

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


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

Technology

Comparative Development Methodologies