comparison of methodologies

Chapter 13

Comparison ofMethodologies

. – p.41/192

Picking a Methodology

You’ve got a team of 10-12 developers eagerly awaitingyour instructions.

Which methodology do you pick?

Usually one of the following things is done

Choice dictated by the methodologies usedpreviously by the developer’s bossUsing a new “hyped” methodology“Heard from a friend of my brother’s wife that it’sgood.”There was this lecturer at the College. . .

Comparing methodologies is like comparing apples tooranges

. – p.42/192

Comparing Apples to Oranges

Has been done before (using a Nicolet 740 FTIRspectrometer)

In Annals of improbable research (Scott A. Sandford)

Result: the two are very similar

. – p.43/192

Comparing Apples to Oranges(2)

Other people might have different opinions

Biologist points to taxonomy, describing similarities anddifferences

Nutrition expert has still another opinion...

Observation: depending on who you ask, you getdifferent answers

. – p.44/192

Comparing Methodologies

Same with methodologies:

Computer scientist: tries to develop general(theoretical) framework for comparing methodologiesDeveloper: tries to judge situation from priorexperiences and case studiesSenior management: tries to find out, if methodologywill give certain quality assurancesVendor: tries to sell own product (so you have toread between the lines)

. – p.45/192

Comparing Methodologies(2)

So, how can we compare methodologies?

1. Describe “ideal” methodology, then compare to othermethodologies

Who determines what’s ideal?If we find ideal methodology, why use othermethodologies?

2. Construct general comparison tool by selectingappropriate features

3. Develop a contingency framework to mapappropriate methodology to a particular environment

4. Develop a common frame of reference for viewingdifferent methodologies (provides a“meta-language”)

. – p.46/192

Comparing Methodologies(2)

We are going to look at:

Theoretical model for comparison (Song andOsterweil) (2.)Checklists (3.)/Frameworks (4.)Capability Maturity Model (CMM levels)

We are not going to look at:

Brochures of vendors

. – p.47/192

Theoretical Model

Song and Osterweil criticize that previous comparisonmethods have been very unscientific

Analysis and comparisons are activities common tomany scientific fields

E.g. comparing animals in biology in a systematic andobjective way:

Comparison of organs and inter-organ relationsUsually organs (e.g. eyes) are classified by theirfunctions (e.g. vision)Using this classification, organs having the same orsimilar functions can be identified and comparedOne compares structures (e.g. shape) and relationsto other organs (e.g. brain)

. – p.48/192

Theoretical Model(2)

Comparison of methodologies should be done similarly:

Comparisons of components and inter-componentrelationsComponents should be classified by their functions(what problems they address)Components should then be characterized by theirstructures

Problem: methodologies and their components areoften not rigorously defined

Methodologies and their components themselves needto be modeled

. – p.49/192

Overview

ModelingFormalismMethodology 1 Methodology 2

BaseFramework

BuildProcess Model

BuildProcess Model

ClassifyComponents

SelectComparison Topics

MakeComparison

SummarizeDifferences

DevelopProcess Code

DevelopProcess Code

Classification

Topics

Difference

Summary

Process Model Process Model

Process Code Process Code

Topics Topics

. – p.50/192

Step 1: Build Process Model

Develop a model, a more formalized description, ofeach of the two methodologies

After doing so, methodology can hopefully bedecomposed into components

Problem: many components (e.g. guidelines,rules-of-thumb) lack precise semantics

Model must be at higher abstraction level, yet becompact and clear

A number of Software Process Modeling Formalisms(SPMF) have been developed for this

. – p.51/192

Build Process Model(2)

SPM by Williams is a typical SPMF

Development process is described as a set of activities:

SPM = {activity}

An activity is described by a set of preconditions, anaction, a set of postconditions, and a set of messages:

activity = {{precond.}, action, {postcond.}, {msg}}

Activities may be composed of other activities and maybe performed in parallel

Messages provide a means of communication andsynchronization among various activities

. – p.52/192

Step 2: Classify Components

Having identified components, they are now classified

This is done within a comparison framework, identifyingcomponents that address similar issues

Typical issues are

How is problem modeled?How is solution modeled?How is design documented?

. – p.53/192

Describing Comparison Issues

Concept:

Understanding problems of IS developmentGeneral principles of coping with these problemsConcrete strategies that guide development

Artifact:

A description involved in the development process(e.g. code, diagrams)

. – p.54/192

Describing Comparison Issues(2)

Representation:

Means for representing artifacts (e.g. documenttemplates, design/modeling languages)

Action:

Physical and/or mental behaviors duringdevelopmentMay create or modify an artifact

. – p.55/192

Step 3: Select Comparison Topics

Topics should be selected based upon goals of aspecific comparison

Two general criteria can always be used:

Components should be comparableComparison between them should help in showingkey differences

. – p.56/192

Select Comparison Topics(2)

Classification may illustrate that two concepts addresssimilar issues

If so, one can select these two concepts for comparisonand trace

artifacts supporting the conceptsrepresentations representing the artifactsactions creating or modifying the artifacts

And eventually find the artifacts, representations, andactions that could be compared

. – p.57/192

Step 4a: Develop Process Code

Process model developed in step 1 may be too abstract

We have to identify detailed differences betweencompared components

This more detailed modeling is called process code (todistinguish it from process model)

This step is optional

. – p.58/192

Step 4b: Make Comparison

Typical criteria for comparing process code/model(again this depends on goal of comparison)

Inter-component dependencyDegree of human involvementDevelopment procedure/orderScope of issues that methodology addresses

. – p.59/192

Step 5: Summarize

Aims at providing readers with an overview and aconclusion

Should be organized around the comparison topics

Should help indicate the main differences betweencomponents

. – p.60/192

Summary of Theoretical Model

Tries to help compare methodologies moresystematically and objectively

Has limitations

It is almost impossible to capture all details of amethodology in a formal, rigorous modelModeling a methodology is a non-trivial task (rangingfrom hours to weeks)

Conclusion: is probably not going to be used bypractitioners, but helps understand findings of scientists

. – p.61/192

Checklists/Frameworks

Lots of checklists for choosing a methodology exist

Contain many questions of the following or similar form

How big is project? (small/medium/large)How much experience does project manager have(little/medium/much)What tool support is expected (no/partly/full)etc.

After evaluating answers according to a certainscheme, an answer is delivered

. – p.62/192

Checklists(2)

This approach has many drawbacks:

Methodologies (and their context) are much toocomplicated to be forced into simple recipesAnswer materializes in a “magic” way, no knowledgeabout the rationale of the checklist creator

. – p.63/192

Frameworks

Frameworks are a more systematic way for evaluatingmethodologies

Potential user (of a methodology) does not just checkboxes and waits for answer

Still somewhat subjective, will not satisfy everyone

Frameworks raise important questions that user has toanswer for him-/herself

We are looking at two frameworks:

NIMSAD: Normative Information Model-basedSystem Analysis and DesignFramework by Avison/Fitzgerald

. – p.64/192

NIMSAD

Aims:

Help understand the area of problem solving (ingeneral)Help evaluate methodologies, their structures, steps,form, nature, etc.Help in drawing conclusions

Before presenting actual comparison, we take a look athow IS development (or problem solving in general) isperceived under NIMSAD

. – p.65/192

Rationale

NIMSAD framework has four essential elements

Problem situation (methodology context)Intended problem solver (methodology user)Problem-solving process (methodology itself)Evaluation of the above

. – p.66/192

Problem Situation

Client

Organizations serve as context for information systems

This context is important for methodologies:

Effectiveness of IS can only be judged in this contextInteraction with organizational members duringdevelopmentInterpersonal relationships formed in this context

. – p.67/192

Problem Solver

ClientProblem Solver

However powerful, useful, and effective a methodologymay be, success often depends on personalcharacteristics of problem solver:

What does he/she select as relevant or dismisses asirrelevant?What are the implications of this selection?

. – p.68/192

Mental Constructs of Problem Solver

Perceptual process:

One of the most influential characteristicsActs as a filter to determine what is perceived assignificantEach person perceives reality differentlyProblematic if perception of problem solver does notmatch that of stakeholder

. – p.69/192

Mental Constructs of Problem Solver(2)

Values/Ethics:

Beliefs that we consider to be “good”Help pass judgment on situationsExample: participation

High economic values: participation is a waste oftimeHigh social values: highly effective

. – p.70/192


Motives/Prejudices

Personal needs that we try to satisfyOpinions that we form from our values andexperiencesBecoming conscious of these is helpful

. – p.71/192


Experience, knowledge, and skills

Acquired from education, training, and practical workHave to match requirements of the methodology tobe used

. – p.72/192


Reasoning ability/Structuring processes

Ability to abstract essential aspects and structurethem in a meaningful wayThinking in different ways helps to gain new insightsCommunicating those thoughts in a clear way helpsother people to understand reasons

. – p.73/192


Roles

In the development process, persons take ondifferent roles

AdvisorAnalystConsultantDesignerImplementer. . .

Conflicts between expected role behavior andnatural behavior of a person results in stress

. – p.74/192

Problem-solving Process

Methodology is a way of problem solving

Needs to help perform three essential phases:

Phase 1: Problem formulationPhase 2: Solution designPhase 3: Design implementation

. – p.75/192

Phase 1: Problem Formulation

Stage 1: Understanding the “situation of concern”

ClientProblem Solver

Mental construct

Mental construct can have several effects on graspingthe situation

. – p.76/192

Stage 1: Understanding situation

Deriving a boundary of concern

Client

Mental construct

Problem Solver

Boundary of concern

. – p.77/192

Boundary of Concern

If we do not subject mental constructs to self-criticalexamination, we may end up

accepting predefined boundaries of clientconstruct implicit boundaries (where there are none)not identifying relevant elements

A methodology should support this structuring ofproblem by supplying appropriate methods ofinvestigation

. – p.78/192

Boundary of Concern(2)

Why is boundary so important?

It excludes many elements from subsequent stepsIf causes for identified problems lie outside ofboundary,

it doesn’t matter how well content of boundary isredesignedactual problem will not be solved

. – p.79/192

Stage 2: Performing Diagnosis

Where are we now?

Stage 1 is more or less a description of situation

Diagnosis aims at understanding reasons for currentsituation

Helps identify gaps of knowledge or misunderstandings

Helps in communicating with clients in deriving agreedunderstandings

Two levels of expression:

Conceptual/logical levelPhysical level

. – p.80/192

Conceptual/Logical Level

Describes general and situation-specific information onan abstract level (“what” issues)

Details include information flows, people’s tasks, roles,functions, etc.

Expressed with the help of rich pictures, variance grids,data flow diagrams, actigrams/datagrams, bubblecharts, etc.

. – p.81/192

Physical Level

Describes physical characteristics of a situation (“who”or “how” issues)

Details include actual products, specific individuals,documents, computers (performance, memorycapacities, etc.)

Expressed in descriptive of tabular form

. – p.82/192

Stage 3: Defining Prognosis

Where do we want to be and why?

Client wants to change current state

Prognosis is expression of desired state

Focus is not to create content of future state (that is roleof design), but to understand rationale for change

Depending on outcome of this stage, project may not bestarted at all

. – p.83/192

Stage 4: Defining Problems

What is preventing realization of desired state?

Analyzing the gap between current and desired state

Identify and critically examine the absence and/orrelationships of elements

Results in identifying problem areas (written down inconcrete problem statements)

. – p.84/192

Stage 5: Deriving Notional Systems

Specifying requirements of a system

If such a system is built, we

eliminate the identified problemschange from current state to described state

. – p.85/192

Phase 2: Solution Design

Here we fill prognosis with content

Starting point is notional system

Consists of two stages:

Stage 6: Conceptual/logical designStage 7: Physical design

. – p.86/192

Stage 6: Conceptual/Logical Design

Design system on an abstract level (similar to the levelused for conceptual/logical analysis)

Most structured methodologies construct dataflows/processes and/or ER-diagrams ignoringroles/functions of individuals

. – p.87/192

Stage 7: Physical Design

Selection of ways and means to realize logical design

Usually a range of different realizations are possible

Additional criteria may play a role in selection:

EfficiencyReliabilityAccuracySecurity/SafetyAvailability

. – p.88/192

Phase 3: Implementation

This phase determines success of whole developmentprocess

Demonstrates validity of all previous steps

Consists of several tasks (that we are going to look at)

. – p.89/192

Tasks

Strategy and planning

Identify and adapt a strategy for sequencing allactivities

Management and control

Set up management and control functions to helpsupervise activities

. – p.90/192

Tasks(2)

Environment Preparation

Adjust surrounding for future system (e.g makechanges to buildings, cabling, train users)

System development

Identify activities and needed resources (e.g.recruitment of new personnel, acquisition ofhard-/software, coding of programs, testing)

Changeover

Integrate the new system (and introduce otherchanges) into the prepared environment

. – p.91/192

Evaluation

Methodology should not be a simple execution of steps

Should help bring about an efficient and effectivetransformation of situations

Role of (evaluation) framework is to questionmethodologies as to

what they attempt to transformwhy they try to transform ithow they help in undertaking the transformation

. – p.92/192

Evaluation(2)

Evaluation of the three elements problem situation,problem solver, problem-solving process

Before the project:

Initial assessment of the three elements

During the project:

Changes may alter the use of methodology

After the project:

Evaluate if problems were solved and howmethodology helped in doing so

. – p.93/192

Applying NIMSAD

MIMSAD is not a methodology itself (does not providecontent to different stages)

It is about finding out what elements in the framework amethodology addresses

in what orderand how

Methodology does not have to be an exact one-to-onemapping to framework

. – p.94/192

Applying NIMSAD(2)

NIMSAD provides important questions to check

Answers have to be found by potential users of amethodology∗

Questions for all elements of NIMSAD

More complete list in NIMSAD book, here just anexcerpt of most important ones

∗ The following might be disturbing for some students: lots of questionswithout answers

. – p.95/192

Problem Situation

Who are the clients?

How strong is their commitment?

Does methodology help in identifying clients and theirconcerns?

What’s the situation like? (well-structured, lesswell-structured, ill-structured)

For which situation is methodology suitable?

What does situation demand (identify problems, designsolutions for already identified problems, implement analready designed solution)?

. – p.96/192

Problem Solver

What level of abstract and technical thinking doesmethodology demand from user?

Do philosophical views advocated by methodologymatch user’s view?

What knowledge sets and skills does methodologyrequire from user?

Are mental constructs of user considered?

. – p.97/192

Problem-solving process

Stage 1: Understanding situation of concern

Does methodology offer assistance for boundaryconstruction?What is role of client (inclusion/participation orexternal)?Does methodology discuss particular methods ofinvestigation?

. – p.98/192

Problem-solving process(2)

Stage 2: Diagnosis

What techniques does methodology offer forexpressing situation characteristics?What level of expression is advocated(conceptual/logical and/or physical)What environmental (context) information iscaptured?What tools and techniques are available?

. – p.99/192


Stage 3: Prognosis

Is this stage supported at all?How does methodology offer help in definingprognosis?How are desired states established?

. – p.100/192


Stage 4: Defining Problems

What problems or problem types are of concern tothe methodology?How does it help in deriving problem statements?Are problem statements evaluated (or justaccepted)?

. – p.101/192


Stage 5: Deriving notional systems

Does methodology derive notional systems fromidentified problems?Does it offer help in formulating notional systems?

. – p.102/192


Design (Stage 6: Conceptual/Logical Design, Stage 7:Physical Design)

Does methodology accept client’s notional system asstarting point?Does it distinguish between logical and physicaldesign stages?Does it help in formulating design solutions?What aspects cannot be captured by methodology?Is a user on his/her own when trying to fill thesegaps?How experienced is user to be expected in thesolution domain?Who decides on which solution to take?

. – p.103/192


Stage 8: Implementation

What steps does methodology offer for developingthe IS?What does it offer in terms of tools and techniques?How does it help in handling major changes in thenotional system at this time?

. – p.104/192

Evaluation

Does methodology provide techniques for evaluatingitself and its outputs for

problem situation?problem solver?problem-solving process?

. – p.105/192

Evaluating Methodologies

We are going to look at two methodologies in theframework of NIMSAD:

SSADMSSM

. – p.106/192

SSADM: Problem Situation

Organizational context has higher priority than in otherstructured methodologies

Commitment of users is checked (partially) duringfeasibility study

Still SSADM is mainly concerned with formaldescriptions of data and processes via data flowdiagrams

Irregular and changing patterns often left out of domainof SSADM

. – p.107/192

SSADM: Problem Solver

SSADM does not alert its users to their mentalconstructs

E.g. two different (competent) SSADM users may arriveat two different sets of data flow diagrams

Most dominant knowledge and skills required are oftechnical nature

In practice, however, users also need social skills tomake methodology effective (not made explicit bymethodology)

. – p.108/192

SSADM: Problem-solving Process


Boundary construction is trial and error withinSSADMAssumes that data flow diagrams can help constructboundaryThis often establishes an implicit boundary (anythingthat cannot be captured in DFDs remains outside)

. – p.109/192

SSADM: Problem-solving Process(2)

Stage 2: Diagnosis

SSADM makes most useful contribution to this stageUse of DFDs provide clear ways of expressing flowsof formal dataStarts with physical data flows (describing how datais processed)Then tries to extract underlying meaning into alogical data model and logical data flow modelDoes so by removing physical elements ofelementary processes and thenreconstructing/regrouping transformed processes

. – p.110/192


Stage 2: Diagnosis

Logicalization may be problematic, as physicalconstraints may disappear

Example: agent updates customer record onlaptop, later this is synchronized with headquartersAfter logicalization there may only be onecustomer record file left. . .

Regular and frequent patterns get modeled, specialcases may be forgotten

. – p.111/192


Stage 3: Prognosis

Defining prognosis is not really possible in SSADMAlthough better than in other structured approaches,as clients get to choose among different BusinessSystems Options (BSO)Feasibility study also helps in deciding if benefitsoutweigh costsRationale of clients’ desired states may not becomeclear (it is assumed that clients know what they want)

. – p.112/192


Stage 4: Defining problems

There is an explicit problem definition phase duringfeasibility studyAt this point things are still vague, howeverAs there is no real prognosis, problems cannot bederived by looking at differences between diagnosisand prognosis

. – p.113/192



Strength of SSADM is in formalizing requirements ofclientAchieved by modeling the data flows of the requiredsystem with help of DFDsFunctions and user interfaces of the system can bespecifiedDeveloping specification prototype helps in gettingfeedback from clientAgain, assumes that client knows what he/she wants

. – p.114/192


Stages 6 and 7: Design

SSADM distinguishes between logical and physicaldesignWe are going to look at these in turn

. – p.115/192


Stages 6: Logical Design

Most useful and rigorous techniques offered bySSADM are DFDsDesigns are usually created by modifying logicaldiagnosis diagram using requirements and feasibilitystudy as guidelineSSADM also very useful for structuring dialoguesDoes not take any interest in how design decisionswill affect environment (BSO only looks atrequirements)

. – p.116/192


Stages 7: Physical Design

SSADM provide mainly generic guidelinesMany decisions depend on technical issues specificto chosen environmentEnvironment is chosen in Technical System Option(TSO) phase of SSADMIn TSO technical alternatives drawn up fromrequirements are presented to clients for decisionBetter than other structured approaches (wherethere is no TSO)Still problems for non-computerized areas of design

. – p.117/192


Stages 8: Implementation

Completely missing (one of the weakest points)

. – p.118/192

SSADM: Evaluation

Completely missing (the other of the weakest points)

. – p.119/192

SSADM: Summary

SSADM is/was popular methodology for formal designof IS

Better in “soft”, non-technical aspects than otherstructured approaches

However, still a technical methodology with weak pointsin “soft” aspects of IS development, the implementationphase, and self-evaluation

At least, does not claim to cover “soft” aspectsadequately

. – p.120/192

SSM: Problem Situation

SSM is one of the few methodologies that makescomments about problem situation

SSM is applicable to ill-structured situations

In contrast to structured methodologies (which seek a“single” truth), SSM considers many different views

Encourages its users to develop new perceptions oforganizations through systems thinking

SSM recognizes three roles: client (initiates study),problem owner (identifies relevant systems), problemsolver (uses SSM to resolve client’s concerns)

. – p.121/192

SSM: Problem Solver

SSM recognizes the need for reflection

Considers mental constructs of its users

Methodology user takes on role of debate facilitator andlearner

However, SSM relies on its users to have considerableconceptualization, abstraction, philosophical, andpolitical skills

. – p.122/192

SSM: Problem-solving Process


SSM provides insightful contributions to boundaryconstructionBoundaries, problem ownership, problem content,and context issues are all open to questionContext of a problem situation can be captured inrich pictures

. – p.123/192

SSM: Problem-solving Process(2)

Stage 2: Diagnosis

SSM does not prescribe particular form ofexpression to capture essential aspects of anorganizationAny technique may be used: graphs, text, animation,pictures, charts, tables, etc. (“rich pictures”)This is a strength and a weakness:

Gives users a lot of freedomBut also a lot of responsibility (user has to knowwhat he/she is doing)

SSM does not distinguish between logical andphysical diagnosis descriptions

. – p.124/192


Stage 3: Prognosis/Stage 4: Defining problems areskipped (details later)

Are handled a little differently in SSM

. – p.125/192



SSM does not derive notional systems fromidentified problems (see Stage 4)Attempts to develop many potentially relevantnotional systemsFormulates notional systems with root definitions(CATWOE)

. – p.126/192


Stage 6/7: Design

No distinction between logical and physical designUses root definitions as guide for design processDesign is not a strong point of SSMNot quite clear how to derive at an activity-baseddesign from system-based root definition

. – p.127/192


Stage 8: Implementation

Missing

. – p.128/192


Stage 3: Prognosis

SSM operates in environment where there aremultiple desired statesclients who are unsure of their desired states

SSM does not attempt to construct clear prognosisoutlineEach root definition implies a particular desired stateThere are many potentially relevant notional systems

. – p.129/192


Stage 4: Defining problems

As there is no clear prognosis, it is difficult to deriveproblem statements from mapping diagnosis toprognosisSSM maps design models against diagnosis todetermine relevanceDecision on relevance is carried out by conductingdebate with participantsPractically, Stage 4 is deferred until design is finished

. – p.130/192

SSM: Evaluation

SSM does not have an explicit step for evaluation

Nevertheless, it propagates learning

When evaluation is done, usually focus onproblem-solving process

Mostly done through SSM case studies (UK HealthService, Shell, IS planning)

. – p.131/192

SSM: Summary

SSM is a methodology for ill-structured problemsituations

Allows discussions on different viewpoints ofparticipants

Author of SSM also encourages debate anddiscussions about SSM

SSM is in constant process of refinement to meet validcriticism

. – p.132/192

Framework by Avison/Fitzgerald

Has seven basic elements:

PhilosophyModelTechniques and ToolsScopeOutputsPracticeProduct

. – p.133/192

Philosophy

The principle (or set of principles) that underlies amethodology

Several areas are distinguished

ParadigmObjectives/DomainTarget

. – p.134/192

Paradigm

Science paradigm vs. systems paradigm

Science paradigm explains world through reductionism,repeatability, refutation

Systems paradigm is concerned with whole picture,interrelationships between parts of the whole

Simplified this means

Science paradigm ≡ “hard” thinkingSystems paradigm ≡ “soft” thinking

. – p.135/192

Paradigm(2)

Debate has been extended to

Epistemology: study of knowledge, how we acquireknowledgeOntology: study of being (or what “is”)

Let’s make a short excursion into philosophy

. – p.136/192

Epistemology

The two extreme positions are positivism andinterpretivism

Positivism

There is an objective reality beyond the human mindIdeas and theories need to be tested against thisrealityThis is done via experiments, surveys, field studies,etc.

. – p.137/192

Epistemology(2)

Interpretivism

Knowledge of world is constructed through aperson’s lived experienceReality is constructed sociallyInterpretivists use case studies, hermeneutics,phenomenology, etc.

Hermeneutics: theory and practice ofinterpretation∗

Phenomenology: study of phenomena(appearance of things) from a first person point ofview

∗ Hermeneutic cycle is process by which we return to a text (or the world),and derive a new interpretation – perhaps a new one every time or a newone for every interpreter

. – p.138/192

Ontology

The two extreme positions here are realism andnominalism

Realism

There are universal entities and universal terms todescribe themE.g. many individual horse entities, but there is alsogeneral concept of an “ideal” horse

Nominalism

There are no universal entities, we can only refer toconcrete, individual entitiesE.g. many individual horse entities, speaking ofhorses in general is mere convenience for speakingof many things at once

. – p.139/192

Excursion into Philosophy

Usually extreme positions not encountered in pure form

A positivist confronted with a loaded gun will not startcalculating trajectories, possible areas of impact, he willexperience strong (subjective) emotions

An interpretivist paying £1000 into his bank account willnot accept the teller’s subjective point of view thatcrediting £800 is close enough

. – p.140/192

Paradigm(3)

Objectivistapproaches

Subjectivistapproaches

Realism Nominalism

OntologyPositivism

Interpretivism

Epistem

ology

. – p.141/192

Objectives/Domain

What is methodology trying to achieve within anorganization?

Development of a purely “computerized” IS?Does it take wider view including other tasks?Does it try to reengineer whole businessprocesses/change strategy of organization?

. – p.142/192

Target

For what

types of problems

environments

types or sizes of organizations

is methodology applicable?

. – p.143/192

Model

What constructs does methodology use to model thereal world?

VerbalAnalytic/mathematicalIconic/pictorial/schematicSimulation

. – p.144/192

Techniques and Tools

What techniques and tools are provided to support userof methodology?

. – p.145/192

Scope

Which phases of life cycle of IS development doesmethodology cover?

strategy, feasibility, analysis, logical design, physicaldesign, programming, testing, implementation,evaluation, maintenance

Problematic if methodology does not follow life cycle

. – p.146/192

Outputs

What is methodology producing in terms ofdeliverables?

This can range from feasibility studies, requirementsand analysis specifications up to workingimplementations of IS

When are these outputs generated?

. – p.147/192

Practice

What is the background of methodology (commercial oracademic)?

What is the user base (numbers and types of users)?

Who are the participants and what are their requiredskill levels (can users apply methodology themselves orare highly skilled consultants necessary)?

. – p.148/192

Product

What do you get for your money, i.e. when purchasingmethodology, what is included?

Software toolsWritten documentationTrainingHelp service

. – p.149/192

Applying Avison/Fitzgerald Framework

We are looking at SSADM and SSM in light ofAvison/Fitzgerald framework

Some arguments have already been presented inNIMSAD framework

Therefore, this is kept shorter

. – p.150/192

Philosophy

Paradigm

SSADMFollows science paradigmBelongs to objectivist approaches

SSMClearly follows systems paradigmBelongs to subjectivist approaches

. – p.151/192

Philosophy(2)

Objectives/Domain

SSADMHas objective of developing computerized ISNeglects organizational aspects

SSMTries to capture a broader view, includingorganizational context

. – p.152/192

Philosophy(3)

Target

SSADMData flow diagrams not applicable for all types ofproblems (decision support systems, webapplications)Targets large organizations (although there isslimmer version called MicroSSADM)

SSMApplicable in human activity situations withill-structured problems

. – p.153/192

Model

SSADM

Main modeling concept: data flow diagrams

SSM

Very flexible “rich pictures”

. – p.154/192

Techniques and Tools

SSADM

Main technique: structured approach to modelingand designTools like drawing tools, tools for projectmanagement, code generation seen as useful, butnot essential

SSM

Organizational techniquesDoes not advocate or mention specific tools

. – p.155/192

Scope

SSADM includes

(Strategy), feasibility, analysis, logical design,physical design

SSM includes

Strategy, (feasibility), analysis, (logical design)

. – p.156/192

Outputs

SSADM

Basically follows SDLC, so in each phase certaindocuments are produced (e.g. feasibility study,requirements specification, design documents)

SSM

Divided into seven stages, at the end of whichcertain documents are produced (e.g. rich pictures,root definitions)

. – p.157/192

Practice

SSADM

Commercial background“Traditional” participants: analysts, designers,(programmers)

SSM

Academic backgroundParticipants: much greater role of client and problemowner

. – p.158/192

Practice(2)

Difficult to evaluate user base, some numbers:

Fitzgerald 1999: 57% of organizations usemethodologies: 11% purely commercial ones, 30%adopted commercial ones, 59% unique onesRusso/Wynekoop 1995: of 132 organizations using amethodology, 77% used structured approach, 8%prototyping/iterative approach, 5% RAD approach

. – p.159/192

Product

SSADM

Large store of manuals, books, etc.Certificate of proficiency can be acquired

SSM

A set of academic papers and books

. – p.160/192

Capability Maturity Model (CMM)

Created by the Software Engineering Institute atCarnegie Mellon

Originally aimed at helping Department of Defenseassess capabilities of vendors and sub-contractors

Not so much about methodologies themselves, butabout how well an organization organizes its processes

Has five levels, level 5 being the best one

. – p.161/192

Overview

Initial

Repeatable

Defined

Managed

Optimizing

Disciplinedprocess

Standardprocess

Predictableprocess

Improvingprocess

. – p.162/192

Initial (Level 1)

Development is characterized as being ad hoc or evenchaotic

Processes are not defined

Everything depends on skilled individuals to get theiract together

Software is typically delivered late and over budget

Little effective management and control

Unfortunately, too many organizations are still at thislevel

. – p.163/192

Repeatable (Level 2)

Basic project management processes are established

Allows tracking of costs, schedules, functionality

Somme process discipline is in place

Earlier success on projects with similar applications canbe repeated

. – p.164/192

Defined (Level 3)

Management and engineering activities aredocumented, standardized, and integrated into astandard process

All projects use an approved, tailored version of theorganization’s process

Training programs are implemented to ensure that staffhas necessary skill

. – p.165/192

Managed (Level 4)

Detailed measures of the process and product qualityare collected and analyzed

Process and products are quantitatively understood andcontrolled

Risks in moving to new application domains are knownand carefully managed

. – p.166/192

Optimizing (Level 5)

Entire organization is focused on continuous processimprovement

Organization can identify weaknesses and preventpotential defects beforehand

Cost/benefit analyses of new technologies base on dataon effectiveness of current process

. – p.167/192

Summary

CMM is based on manufacturing and product-buildingview of systems development

This is not always appropriate as often IS developmentis more of a creative art than a science

CMM is mainly concerned with (technical) aspects ofsoftware development, not the wider area of ISdevelopment

High levels in CMM do not always lead to high qualitysoftware, just well-documented processes

. – p.168/192

Chapter Summary

Comparing methodologies is a very difficult task

Unfortunately, no silver bullet for doing so has beenfound yet

As many views as writers on the subject

. – p.169/192

comparison of methodologies

Technology