comparison of methodologies
DESCRIPTION
Comparison Of MethodologiesTRANSCRIPT
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
Mental Constructs of Problem Solver(3)
Motives/Prejudices
Personal needs that we try to satisfyOpinions that we form from our values andexperiencesBecoming conscious of these is helpful
. – p.71/192
Mental Constructs of Problem Solver(4)
Experience, knowledge, and skills
Acquired from education, training, and practical workHave to match requirements of the methodology tobe used
. – p.72/192
Mental Constructs of Problem Solver(5)
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
Mental Constructs of Problem Solver(6)
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
Problem-solving process(3)
Stage 3: Prognosis
Is this stage supported at all?How does methodology offer help in definingprognosis?How are desired states established?
. – p.100/192
Problem-solving process(4)
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
Problem-solving process(5)
Stage 5: Deriving notional systems
Does methodology derive notional systems fromidentified problems?Does it offer help in formulating notional systems?
. – p.102/192
Problem-solving process(6)
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
Problem-solving process(7)
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
Stage 1: Understanding situation of concern
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
SSADM: Problem-solving Process(3)
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
SSADM: Problem-solving Process(4)
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
SSADM: Problem-solving Process(5)
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
SSADM: Problem-solving Process(6)
Stage 5: Deriving notional systems
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
SSADM: Problem-solving Process(7)
Stages 6 and 7: Design
SSADM distinguishes between logical and physicaldesignWe are going to look at these in turn
. – p.115/192
SSADM: Problem-solving Process(8)
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
SSADM: Problem-solving Process(9)
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
SSADM: Problem-solving Process(10)
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
Stage 1: Understanding situation of concern
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
SSM: Problem-solving Process(3)
Stage 3: Prognosis/Stage 4: Defining problems areskipped (details later)
Are handled a little differently in SSM
. – p.125/192
SSM: Problem-solving Process(4)
Stage 5: Deriving notional systems
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
SSM: Problem-solving Process(5)
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
SSM: Problem-solving Process(6)
Stage 8: Implementation
Missing
. – p.128/192
SSM: Problem-solving Process(7)
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
SSM: Problem-solving Process(8)
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