Comparative Development Methodologies Lecture 10

1
Comparative Development MethodologiesLecture 10

• Niki Trigoni
• Department of Computer Science
• and Information Systems
• Birkbeck College, University of London
• Email niki_at_dcs.bbk.ac.uk
• Office Hours Wednesdays, 6 - 7 pm
• Web Page http//www.dcs.bbk.ac.uk/niki

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

3
Overview of lecture 10

• Frameworks
• Methodology issues
• Methodology comparisons

4
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

5
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

6
Frameworks Multiview stages
5. Design Technical aspects
technical requirements
4. Design human- computer interface
entity model
entity model
computer tasks role set people tasks
primary task model
3. Analyze and design socio-technical aspects
1. Analyze human activity
2. Analyze information
function model
7
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)

8
Frameworks Multiview framework
1.

• Human activity
• (Q1)

2.
3..
2. Information (Q4)
4.
3. Socio-technical (Q2)
5.
4. Human-computer interface (Q3)
5. Technical (Q5)
9
Frameworks Multiview framework

• Stage 1 Analysis of human activity
• Based on SSM (Mode 1)
• Central focus Search for a particular world view
• Form rich pictures of the problem situation
• Let rich pictures stimulate discussion between
  the problem solver and the problem owner
• Extract problem themes from rich pictures
• Form root definition
• Construct a conceptual model
• Compare the completed conceptual model to the
  representation of the real world in the rich
  picture
• Debate possible changes to improve the problem
  situation

10
Frameworks Multiview framework

• Stage 2 Analysis of information
• Takes as input the root definition/conceptual
  model from stage 1
• Two main phases
• the development of a functional model
• identify the main function
• decompose functions successively (4-5 levels)
• provide hierarchical model and DFDs as input into
  stage 3
• the development of an entity model
• Extract and name entities from the area of
  concern
• Establish relationships between entities
• Construct an entity model and provide it as input
  to stages 4 and 5

11
Frameworks Multiview framework

• Stage 3 Analysis and design of the
  socio-technical aspects
• Philosophy people should be allowed to
  participate in the analysis and design of the
  systems that they will be using
• Human considerations job satisfaction, task
  definition, morale
• Consider both social and technical objectives
• Specify both social and technical alternatives
• Match socio-technical alternatives
• Rank in terms of meeting socio/technical
  objectives
• Consider costs/resources/constraints and rank
  accordingly
• Select best socio-technical solution
• Define computer task, role set, and people tasks
  for solution

12
Frameworks Multiview framework

• Stage 4 Design of the human-computer interface
• Takes as input the entity model from stage 2, and
  the computer tasks, role-set, and people tasks
  from stage 3
• Philosophy the ways in which users will interact
  with the computer will have an important
  influence on whether the users will accept the
  system
• Works on the technical design of the
  human-computer interface
• batch vs. online facilities
• conversations and interactions with particular
  types of user
• necessary inputs and outputs, error checking,
  minimization of number of keystrokes

13
Frameworks Multiview framework

• Stage 5 Design of the technical aspects
• Takes as input the entity model from stage 2 and
  the technical requirements from stage 4
• Takes a technical view towards an efficient
  design of the system
• Final outputs are
• application subsystem (impl. functions in the
  function chart)
• information retrieval subsystem (responds to data
  enquiries)
• database (and db maintenance subsystem)
• control subsystem (alerts for user/program/operato
  r errors)
• recovery subsystem (repairs system after error
  detection)
• monitoring subsystem (records all system
  activities)

14
Frameworks SODA

• Strategic Options Development and Analysis (SODA)
• SODA is an approach designed to provide
  consultants with a set of skills, a framework for
  designing problem solving situations and a set of
  techniques and tools to help their clients work
  with messy problems Eden and Ackerman, 2001
• Four perspectives
• individual (tries to make sense of the
  organization)
• nature of organizations (political and power
  aspects play an important role in decision
  making role negotiation)
• consulting practice (role of negotiation in
  effective problem solving, managing consensus and
  commitment)
• technology and techniques (used to bring together
  the first three elements)

15
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
• Initial level (heroic level)
• adhoc (and chaotic) development
• success/failure depends on the individuals
  involved
• not sustainable
• late and over-budget software delivery
• Repeatable level
• identifiable policies for managing software
  development
• realistic plans based on performance of previous
  projects
• cost estimates, schedules, project standards

16
Frameworks CMM (cont.)

• Continuing enumeration of maturity levels
• 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
• 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

17
Frameworks CMM (cont.)

• Continuing enumeration of maturity levels
• 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

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

19
Frameworks Euromethod

• Euromethod applies to any information systems
  adaptation development or modification of an
  information system providing that the initial (or
  current) state and the required final state can
  be defined.
• Euromethod focuses on the understanding, planning
  and management of the contractual relationships
  between customers and suppliers of information
  systems adaptations.
• Types of transactions in an IS adaptation

Call for tender Tender response Supplier
selection Contract award
Approval of deliverables Approval of status and
plans Contract change control
Approval of final deliverables Contract completio
n
TENDERING PRODUCTION
COMPLETION
20
Frameworks Euromethod

• Euromethod includes elements relating to
  procurement rather than development of
  information systems
• Its concept is to bridge different methodologies
  by following three models the transaction model,
  the deliverable model and the strategy model
• The transaction model helps manage
  customer/supplier interactions across
  organizational boundaries
• The deliverable model defines the target domain
  (data, functions, architecture) for an
  information systems adaptation, incl. the goals,
  the key roles and responsibilities of the
  customer and the supplier
• The strategy model assesses the problem situation
  and selects a strategy with well defined decision
  points to get successfully to the final state of
  the adaptation.

21
Overview of lecture 10

• Frameworks
• Multiview
• Strategic Options Development and Analysis (SODA)
• Capability Maturity Model (CMM)
• Euromethod
• Methodology issues
• Components of a methodology
• Rationale for a methodology
• Adopting a methodology in practice
• Evolution of methodologies
• Methodology comparisons

22
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

23
Issues rationale for a methodology

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

24
Issues rationale for a methodology

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

25
Issues rationale for a methodology

• 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 gt
  reduction of cost
• A standardized process
• Staff can change between projects without
  retraining
• Common experience and knowledge can be
  accumulated
• Easy system maintenance
• Better systems integration

26
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

27
Issues adopting a methodology in practice

• Methodology adopters should be aware of these
  variations and of their particular needs in order
  to make an educated decision of using a
  methodology
• Methodology-related costs
• initial purchase
• training of personnel
• required hardware and software
• ongoing consultancy
• Involve users, analysts and managers in the
  decision of selecting a methodology (it should
  not be purely an IT department decision)
• Are we guaranteed successful information systems
  as a result of using a methodology?

28
Issues adopting a methodology in practice

• Developers may interpret the demands of the
  methodology differently and thus end up with
  different results
• Flexibility in how specified tasks are performed
  is another source of uncertainty about the
  expected results
• Despite variations, multiple uses of a
  methodology should yield roughly the same
  results. Of course, this also depends on the
  methodology itself
• The adoption of a methodology can be viewed as an
  attempt to reduce the degrees of freedom, by
  embodying a good practice for developing an
  information system
• Main criteria for selecting a methodology
• Whether it fits with the organizations 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

29
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

30
Issues evolution of methodologies

• Early-methodology era from early 1970s to early
  1980s
• Focused on identification of phases and stages to
  control and manage systems development
• Waterfall model feasibility study, systems
  investigation, analysis, design, development,
  implementation, maintenance
• Well-defined set of deliverables upon the
  completion of a stage
• Trained users and developers
• Documentation standards

31
Issues evolution of methodologies

• Methodology era from mid 1980s to mid/late 1990s
• Methodologies emerging both from theory and from
  practice
• The methodology, rather than consultancy about
  the methodology, became the product, resulting
  in
• Write-up of the methodology
• Consistency and comprehensiveness
• Marketability and maintainability
• Evolution into training packages
• Provide with supporting software
• Whilst creating methodology products
• Many gaps were filled
• The scope of methodologies was expanded (to more
  stages and higher organizational levels)
• Strategic and planning aspects were introduced
  (to gain competitive advantage

32
Issues evolution of methodologies

• Era of methodology reassessment from late 1990s
  onward
• Reappraisal of methodologies (change or abandon
  of specific methodologies)
• Criticisms of methodologies
• Productivity time consuming and resource
  intensive
• Complexity designed for large projects
• Encouraging the creation of wish lists by users
• Skills training is required for their use
• Tools shift focus to documentation rather than
  analysis/design, complex to use
• Not contingent upon the type of project or its
  size
• One-dimensional approach narrow solution
• Inflexible not allowing changes to requirements
• Invalid or impractical assumptions (e.g. coherent
  business strategy)

33
Issues evolution of methodologies

• Era of methodology reassessment from late 1990s
  onward
• Criticisms of methodologies (cont.)
• Goal displacement focus on the procedures to the
  exclusion of the real needs of the project
• Problems of building understanding into methods
  it is not enough to understand methods in order
  to understand the problem situation
• Insufficient focus on social and contextual
  issues overemphasis on the narrow technical
  development
• Difficulties in adopting a methodology
  resistance from developers and users
• No improvements not only it did not help, but it
  also hindered development

34
Issues evolution of methodologies

• Era of methodology reassessment from late 1990s
  onward
• New directions
• Ad hoc development rely on the experiences of
  developers
• Further developments in the methodology arena
  evolution of existing methodologies or
  development of new ones (object-oriented, RAD,
  prototyping, CRM approaches seem to be gaining
  ground)
• Contingency use the methodology as a general
  structure, and pick tools and techniques
  depending on the situation
• External development use of packages and
  outsourcing is effective for organizations with
  well-defined requirements, Enterprise Resource
  Packages (ERPs)

35
Overview of lecture 10

• Frameworks
• Multiview
• Strategic Options Development and Analysis (SODA)
• Capability Maturity Model (CMM)
• Euromethod
• Methodology issues
• Components of a methodology
• Rationale for a methodology
• Adopting a methodology in practice
• Evolution of methodologies
• Methodology comparisons
• Criteria
• Framework
• Comparison

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

37
Methodology comparison criteria

• What situations and types of application is it
  suited to?
• Does it aim to be scientific/systemic/behavioral?
• Is a computer solution assumed? What other
  assumptions are made?
• Who plays what role? Does it assume professional
  developers, require a methodology facilitator,
  involve users and managers, and if so, to what
  degree?
• What particular skills are required of the
  participants?
• How are conflicting views and findings handled?
• What control features does it provide and how is
  success evaluated?
• What claim does it make as to its benefits? How
  are these claims substantiated?
• What are the philosophical assumptions of the
  methodology?

38
Methodology comparison criteria

• Other criteria you would consider
• Rules and standardization
• Coverage

39
Methodology comparison framework

• Philosophy
• Paradigm
• Objectives
• Domain
• Target
• Model
• Techniques and tools
• Scope
• Outputs
• Practice
• Background
• User base
• Participants
• Product

40
Method. comp. framework philosophy

• Philosophy
• Set of principles that underlie a methodology
• Four distinguishing factors
• 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)
• Objectives, e.g.
• to develop a computerized information system?
• to discover if there is a need for a computerized
  system?

41
Method. comp. framework philosophy

• Philosophy (cont.)
• Four distinguishing factors (cont.)
• Domain situations that methodologies address
• narrow problem vs. wider organization-level
  problems
• individual problems vs. many interrelated
  problems viewed as a whole
• Target applicability of the methodology
• general-purpose vs. application/organization
  specific

42
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

43
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

44
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

45
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
• ...

46
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

47
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

48
Methodology comparison philosophy

• Philosophy
• Domain
• IE, and SSM address general planning,
  organization, and strategy of information and
  systems in the organization (IEs 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

49
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

50
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

51
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

52
Summary of lecture 10

• Frameworks
• Multiview
• Strategic Options Development and Analysis (SODA)
• Capability Maturity Model (CMM)
• Euromethod
• Methodology issues
• Components of a methodology
• Rationale for a methodology
• Adopting a methodology in practice
• Evolution of methodologies
• Methodology comparisons
• Criteria
• Framework
• Comparison