Methodology and Methods

1
Methodology and Methods
2
Lecture Objectives

• Explain different types of method
• Explore some common methods
• Nature of iteration
• Testing and quality points

3
System Development LifeCycle

• All approaches to systems (software) design
  involve a System Development LifeCycle or SDLC
  that involves
• Analysis
• Design
• Implementation
• Maintenance
• All SDLCs involve feedback and testing

4
Waterfall Modele.g.,Structured Systems And
Design Method(SSADM)
5
Waterfall Methodseg., SSADM
Feasibility Study
Systems Integration
Systems Analysis
Systems Design
Implementation
Review and Maintenance
6
Waterfall Methodseg., SSADM

• Assumes that
• All requirements are identified at the start
• All the system is analysed
• All the system is designed
• All the system is written
• All the system is tested
• All the system is handed over to the client
• So there is only one run through the life cycle

7
Waterfall MethodsAdvantages

• Known requirements are all documented
• Analysis can cover all required areas
• Design can be optimised as all known requirements
  are included
• Coding and testing can be carried out efficiently
  as all areas to be covered are known.
• Project management is easier as tasks required
  are known timetables and staffing can be
  planned and controlled

8
Waterfall MethodsDisadvantages

• What if the client thinks of important
  requirements later in the project?
• What if the clients requirements change during
  the project?
• What if a step in the project takes longer than
  expected?
• What if the client does not like what the
  developers have produced?
• What if the system handed over to the client does
  the wrong thing?

9
Rational Unified Process(RUP)
10
Key Aspects of RUP

• Risk-driven process
• Risk management integrated into the development
  process
• Iterations are planned based on high priority
  risks
• Use-case driven development
• Use cases express requirements on the systems
  functionality and model the business as context
  for the system
• Use cases are defined for the intended system and
  are used as the basis of the entire development
  process

11
Key Aspects of RUP

• Risk-driven process
• Risk management integrated into the development
  process
• Iterations are planned based on high priority
  risks
• Use-case driven development
• Use cases express requirements on the systems
  functionality and model the business as context
  for the system
• Use cases are defined for the intended system and
  are used as the basis of the entire development
  process

12
Key Aspects of RUP

• Architecture-centric design
• Architecture is the primary artifact to
  conceptualize, construct, manage, and evolve the
  system
• Consists of multiple, coordinated views (or
  models) of the architecture

13
RUP 6 Best practices

• Develop Software Iteratively
• Driven by early risk identification and
  mitigation
• Each iteration results in an executable release
• Manage Requirements
• Requirements inherently dynamic across the
  systems life
• Use Component-Based Architecture
• Architectures that are resilient to change are
  essential

14
RUP 6 Best practices

• Visually Model Software
• Promotes consistency and unambiguous
  communication of development information
• Continuously Verify Software Quality
• Identify defects early, objective measure of
  project status
• Control Changes to Software
• Create and release a tested baseline at the end
  of each iteration

15
Process Overview
Core Workflows
Business Modeling
Requirements
Analysis Design
Implementation
Test Assessment
Deployment
Supporting Workflows
Change Management
Project Management
Environmental Analysis
Iteration(s)
16
The V Model
17
The V Model
Acceptance Test Design
Acceptance Test Design
Requirements Analysis
Systems Test Design
System Design
Systems Test Design
Integration Test Design
Architecture Design
Integration Test Design
Unit Test Design
Module Design
Unit Test Design
coding
18
The Spiral Model
19
The Spiral Model
Determine objectives, alternatives, constraints
Evaluate alternatives, identify, resolve risks
Risk analysis
Risk analysis
Risk analysis
Operational Prototype
Risk analysis
Review
Prototype 3
Prototype 2
Commitment Partition
Prototype1
Simulations, models, benchmarks
Softwarerequirements
Requirements plan Lifecycle plan
Softwareproductdesign
Detailed design
Conceptof operation
Developmentalplan
Code
Requirements validation
Unit test
Integrationand test plan
Integrationand test
Design validationand verification
Acceptancetest
Develop, verifynext level product
Plan next phases
Implementation
From Boehm B.W., A Spiral Model of Software
Development and Enhancement, Computer, May 1988,
pp. 61-72.
20
AGILE Method
21
AGILE Method
22
AGILE vs Waterfall

• The Agile Manifesto favours
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

From Sy, D (2007) Adapting Usability
Investigations for Agile User-centered Design.
JUS, Vol. 2, Issue 3, May 2007, pp. 112-132.
23
AGILE vs Waterfall

• In the waterfall model requirements gathering for
  all features in a release leads to a design
  phase, which is then followed by coding and
  quality assurance testing. The entire process for
  a release is measured in months, if not years.
• In contrast, the Agile development lifecycle is
  characterized as a series of incremental
  mini-releases. Each working version must be
  complete and stable, which makes it possible for
  the product release date to coincide with that of
  any working version. Working versions are created
  at regular intervals, called iteration cycles or
  sprints, which are generally two to four weeks
  long. Cycle end dates are fixed features that
  cannot be completed are moved to the next working
  version.

From Sy, D (2007) Adapting Usability
Investigations for Agile User-centered Design.
JUS, Vol. 2, Issue 3, May 2007, pp. 112-132.
24
AGILE vs Waterfall

• In the waterfall model there is formal
  demarcation between roles e.g., IT experts and
  users, and formal approaches to interaction
  between the roles. Typically there are infrequent
  and period (e.g., monthly), meetings with fixed
  agenda and minutes.
• In contrast, the Agile development encourages
  informal interactions between roles. In
  particular, ad-hoc or regular (daily of weekly)
  scrums between stakeholders that have no agenda,
  or a loose agenda, and which only key actions
  are recorded if there are any records at all.

From Sy, D (2007) Adapting Usability
Investigations for Agile User-centered Design.
JUS, Vol. 2, Issue 3, May 2007, pp. 112-132.
25
Soft System Methodology(SSM)
26
Soft Systems MethodologyWhat is it?

• In principle, an SSM covers
• examination of the problem situation
• analysis of the ingredients (using a rich picture
  method)
• coming to a root definition of significant facets
  of the system of interest
• conceptualisation and modelling
• comparison of concept/ideal to actual
• definition and selection of options
• design of action programme
• Implementation.

27
Soft Systems MethodologyProblem Expression

• Stating what the problem is requires situational
  and problem analysis - comprehending the problem
  domain of interest. What exactly the problem is
  will not be known until this analysis is done. A
  key feature of SSM is to
• Keep the project vague and wide for as long as
  possible - don't jump to conclusions nor assume
  or ignore the current situation e.g. by
  concentrating on idealised futures.
• The analysis may involve the use of many
  techniques such as checklists of things to look
  for, question sets, models and frameworks of
  examination. It is important not to become fixed
  on the use of one technique or analytical
  approach only. Typically brainstorming
  techniques, SWOT, STEEP analysis may be used.

28
Soft Systems MethodologyCATWOE

• Clients - (those who more or less directly
  benefit or suffer e.g. customers) from the
  machinations of the...
• Actors Stakeholders, the players (individuals,
  groups, institutions and agencies), who perform
  the scenes, read and interpret the script,
  regulate, push and improvise. Identify and
  examine the role of local and institutional
  actors .... who undertake the.....
• Transformations - what processes, movements,
  conversions of X take place? What is the nature
  of the production and service transformations?
  What is the content and processes involved from
  ingredients to a sandwich, from mixed, varied
  data to information, from an idea to a
  performance concept or marketable product etc?
  What are the transformations that generate a
  product or a service? How are they achieved? How
  well are they performing?

29
Soft Systems MethodologyCATWOE

• Weltanschauung or world-view - what is going on
  in the wider world that is influencing and
  shaping the "situation" and need for the system
  to adapt?
• Owners - the activity is ultimately "controlled"
  or paid for by owners or trustees. Who are they
  and what are their imperatives? How do they
  exercise their ownership power? Are their other
  stakeholders - who claim a stake and a right to
  be involved i.e. as legitimate quasi-owners.
  Ownership and the human activity occurs within an
  
• Environment - the trends, events and demands of
  the political, legal, economic, social,
  demographic, technological, ethical, competitive,
  natural environments provide the context for the
  situation and specific problem arena. We need to
  understand these.

30
Soft Systems Methodology Transformation

• Checkland offers the case of an aircraft landing
  system where
• (transformation) the incoming aircraft approaches
  from a height and a distance. The goal is safe
  landing on the runway.
• The actors are the pilots (human and auto), the
  clients - the passengers, crew, air traffic
  controllers, ground staff and people living under
  the runway.
• The owners include the airline owners and their
  agents (the managers)
• The environment air lanes, traffic conditions
  and geographic features, regulation of landing
  and take-off slots at the airport, competition
  from other airports.
• The weltanschauung may involve the rise in
  passenger traffic, competition between
  international airports, the airport-housing
  environment, high concern for safety and high
  technology operations.

31
Soft Systems Methodology Rich Picture
32
Soft Systems Methodology Rich Pictures

• Checkland encourages the problem researchers to
  illustrate the system of interest with diagrams
  or "rich pictures" (a diagram "without rules").
  Rich pictures show
• the people involved
• the purposes they state
• their desires and fears (use think balloons).
• symbols to express environmental detail
  (activities, similar and contentious processes,
  relationships (push-pull) and transactions
  across organisational boundaries).
• how and where interests agree or conflict.
• Rich pictures are cartoons - funny, sad,
  political, ... and all at once. The pictures of
  course are generated by the analysts and hence
  are selective, representative of their
  perceptions .... and questions.... and areas of
  uncertainty.

33
Soft Systems Methodology The Process View

• Using CATWOE in analysis discussions and drawing
  a rich picture encourages a process approach.
  Participants can test assertions, assumptions,
  positions and the integrity of data/information.
• SSM targets existing systems. The focus is on
  investigation and definition of the existing
  features of the organisational and how these
  interact externally and internally with the
  system as a whole (hence "holism") and
  sub-processes. Consider too the situational and
  organisational "climate" (efficient, tense, wet,
  cold, hot, neurotic, sloppy, democratic, sulky,
  joyous ...).

34
Soft Systems Methodology The Process View

• After problem examination and definition, SSM
  participants "should" be able to "see" the
  organisation
• differently and more fully .
• differentiate levels and sub-problems of the
  whole.
• They will have researched "facts
• positions and viewpoints at varying levels of
  detail.
• They will have articulated many "problem"
  statements, some major and some trivial.
• They will have debated the evaluated assumptions
  about the trivial and the major.

35
Soft Systems Methodology Root Definition

• A root definition for which there is a consensus
  - at a point in time - is an important outcome of
  the SSM process. The analyst-researchers now need
  to define the arena of concern more precisely i.e
  to synthesis the "root definition". They move
  towards a well- defined statement about the area
  of concern, its activities and components. This
  may represent a minimum that can be agreed in
  terms of the real activity domain. People should
  be able to see what they are agreeing to and what
  has been left out. It is for internal, creative
  use not public dissemination

36
Soft Systems Methodology Conceptual Modelling

• With a root definition and a CATWOE rich picture
  - the analysts can turn to an imagined, "ideal"
  system. Creativity and solution generation time
  is here folks .... exploring
• the wild and fanciful
• defining the musts and the desirables
• evaluating and choosing
• agreeing criteria for choosing deciding.
• A "best" model may be proposed and the criteria
  maybe implicit .... but be clear about what the
  criteria are and what has been systematically
  left out of the formula!

37
Soft Systems Methodology Five Es for Decision
Criteria

• efficacy (will it work at all?)
• efficiency (will it work with minimum resources?)
  
• effectiveness (does it contribute to the
  enterprise?)
• ethics (is it sound morally?)
• elegance (is it beautiful?)

38
Soft Systems Methodology Compare the Concept
with the Current

• The conceptual model should provide inspiration.
  Its purpose should not be seen as criticism or
  threatening (these however may arise in any human
  activity system) so ... simply compare the
  concept with the current system. The current
  system exists. It does something. The adage "if
  it works, don't change it" may string to mind
  but.... questions now arise
• why aren't we doing it the "ideal" way?
• what reasons explain our current practice and
  behaviour?
• how do we, at present, measure up to the ideal
  given the criteria of efficiency, effectiveness,
  ethics and elegance and group/political opinion?

39
Soft Systems Methodology Agree on Changes

• If the current system is imperfect (why we did
  the analysis) - then we have to agree on
  desirable changes. These presumably may move us
  towards the ideal.
• retrace our footsteps and go over our synthesis
• re-evaluate the insight gained from each stage
• examine how proposals may affect and be received
  by stakeholders.
• in what way will changes for which there is no
  consensus/agreement result in problems?
• The outcome is that there is some agreement -
  permission to move.

40
Soft Systems Methodology Action/Implementation

• Outcome may not be predictable. Implementation is
  a new human activity. It means new compromises.
  If the root definition and option analysis is
  still fuzzy and if there is no ownership by those
  who hold the reins of power (the decision-makers)
  then the SSM process could go into an infinite
  loop and start the whole thing over again - rue
  the day!
• The final outcome will not completely match the
  planned change. It will be interesting to see how
  close they are.
• Does an SSM project ever finish .... it doesn't
  need to as it embodies learning - the human
  learning and adaptation philosophy. There may be
  convergence. Issues debated early on may
  dissipate. Implementation discussions may focus
  more on participant confidence, ability and
  understanding of the enterprise.

41
Soft Systems Methodology Criticisms of SSM

• It is not a "how to build a system guidebook". It
  is heuristic not algorithmic.
• There is no real method. But then many other,
  more prescriptive "methodologies" don't work. SSM
  does encourage commitment and it provides a forum
  to bring diverse interests together.
• The open endedness makes it difficult to manage.
  An SSM project is unlikely to be a complete
  success or a failure but it should reflect a
  natural, evolutionary approach.

42
Soft Systems Methodology Criticisms of SSM

• SSM can too easily ignore environmental and
  structural determinants and questions of power.
  Organisational members do not have equal choice
  and it is naive to think that everyone can openly
  discuss problems, perceptions and needs. Yet
  open, willing and supported discussion is more
  likely to open up organisation culture -
  encouraging learning and joint problem solving.
• Openness and togetherness are implicit and
  explicit values of SSM .... not easy values in a
  confused, conflict and contradiction-oriented or
  power-centred organisation.

43
Lecture Objectives

• Explain different types of method
• Explore some common methods
• Nature of iteration
• Testing and quality points