Comparative Development Methodologies Lecture 9

1
Comparative Development MethodologiesLecture 9

• 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 8

• Overview of phases, disciplines and artifacts of
  the Unified Process
• UP an iterative object-oriented approach
• In a mini workshop we went through parts of the
  development of a Point-Of-Sale system, including
• requirements analysis (using use cases,
  supplementary specification, vision, glossary,
  contracts)
• analysis (using the domain model)
• design (using the design model - interaction and
  design class diagrams)
• implementation

3
Overview of lecture 9

• Rapid development methodologies
• Extreme Programming (XP) Kent Beck
• Organizational oriented methodologies
• Soft Systems Methodology (SSM) Peter Checkland

4
Rapid development methodologies

• Objective to speed up the development process
  in order to cope with rapidly changing business
  needs
• Business environment
• increasingly competitive
• customer-focused
• international
• and therefore continuously changing

5
Extreme Programming (XP)

• Particularly suitable for small and medium-sized
  applications (works best when the whole project
  requires 3-10 programmers)
• It is a series of principles for developing
  software rapidly
• XP is a lightweight methodology
• few rules and practices
• minor attention to documentation
• It stresses customer satisfaction it is designed
  to deliver the software the customer needs when
  it is needed
• It empowers developers to respond to changing
  customer requirements, even late in the life cycle

6
Main ideas in XP

• XP improves a software project in four essential
  ways communication, simplicity, feedback, and
  courage
• It stresses the role of teamwork with open and
  honest communication
• It requires the skill to develop simple programs
  at top speed
• It stresses the importance of concrete and rapid
  feedback (working with customers and doing
  continuous testing)
• It requires courage to throw code away and start
  again if necessary

7
XP phases

• Planning the project
• Designing the system
• Developing code
• Productionalizing (testing)

8
XP planning

• Write user stories
• Produce a release plan (plan for frequent small
  releases)
• Measure the project velocity
• Divide the project into iterations and start each
  one with iteration planning
• Have a stand-up meeting every day to communicate
  problems and solutions and promote team focus

9
XP designing

• Keep design simple always do the simplest thing
  that could work and never add functionality
  before it is scheduled
• Choose a suitable system of names for your
  objects that everyone can relate to
• Use Class, Responsibilities, and Collaboration
  (CRC) cards to design the system as a team.
• Create architectural spikes simple programs to
  explore the potential solution, i.e. programs
  that address only the problem under examination
  and ignore all other concerns
• Turn a blind eye towards future requirements and
  extra flexibility. Concentrate on what is
  scheduled for today only
• Re-factor obsolete designs that are hard to
  understand, maintain, or have unused functionality

10
XP coding

• The Customer continues to be available through in
  coding and testing (ask for experts not trainees)
• Code must be written to agreed standards
• Code the unit test first (before the actual code)
• Paired programming 2 people working at the same
  workstation
• Sequential code integration only one pair of
  programmers integrates code at a time
• Integrate code often in a common repository
• Collective code ownership is encouraged
• Avoid optimizing code
• Avoid working overtime or adding programmers

11
XP testing

• All code must have unit tests
• All code must pass all unit tests before it can
  be released
• When a bug is found more tests are created
• Acceptance tests (created from user stories in
  each iteration) are run and the score is
  published

12
Organizational-oriented methodologies

• In some organizational problem situations, it is
  not enough to break up a complex situation into
  its constituent parts in order to solve it
• The whole is greater than the sum of the parts
• An organization is an open system and it should
  be viewed in terms of the wider environment that
  it is part of
• A multidisciplinary team of analysts is needed to
  address organization-wide problems
• Human activity systems it is relatively easy to
  model data and processes (like in previous
  methodologies) but to understand the real world
  it is essential to include people in the model

13
Hard systems thinking

• In hard systems thinking
• a goal is assumed
• there is a well-defined problem to be solved
• the quality of result product is measurable
• technical factors are the most important
• one or a few acceptable technical solutions apply
• experiments of systems development are repeatable
• a scientific and formal approach to problem
  solving is suggested (e.g. divide-and-conquer)

14
Soft systems thinking

• In soft systems thinking
• organizational problems are poorly defined,
  rather a problem situation is detected where
  several problems arise
• the objectives of the system are more complex
  than a simple goal and are not always measurable
• stakeholders interpret problems differently
  (there is no objective reality)
• the human factor is very important
• creative, intuitive approach to problem solving
  is suggested
• outcomes are learning and better understanding
  rather than a solution

15
Soft systems methodology (SSM)

• SSM
• mode 1 developed by Checkland in 1981
• mode 2 revised by Checkland and Scholes in 1990
• SSM was developed through action research,
  whereby the systems ideas are tested out in
  client organizations.
• The analysts neither dictate the way the action
  develops nor step outside as observers they are
  participants in the action and results are
  unpredictable
• The central focus of the methodology is the
  search for a particular view (world view), which
  will form the basis for describing the systems
  requirements. What is the main purpose of the
  organization, its attitudes and personality?

16
SSM stages in mode 1

• The problem situation unstructured
• The problem situation expressed
• Root definitions of relevant systems
• Building conceptual models
• Comparing conceptual models with reality
• Assessing feasible and desirable changes
• Action to improve the problem situation
• Stages 1,2,5,6 and 7 are real-world activities
  involving people in the problem situation
• Backtracking and iteration are essential

17
SSM stage model (mode 1)
source Checkland Systems Thinking, Systems
Practice
18
SSM The problem situation unstructured

• Find out about the problem situation
• Get as many people (in the problem situation)
  involved as possible
• The views of the actors, owner and other
  stakeholders will often not coincide therefore
  the analysts can take different views regarding
  the system
• What is the structure of the problem situation?
• physical layout
• reporting structure
• formal and informal communication patterns
• This stage gathers the informal picture of the
  problem situation

19
SSM The problem situation expressed

• Attempt to express the problem situation in a
  more formal way
• For example, draw rich picture diagrams
• Rich picture diagrams can be used as a
  communication technique between the analysts and
  the users of the system
• Rich picture diagrams usually show
• the people involved
• problem areas
• controlling bodies
• sources of conflict
• Rich pictures are intended to help in problem
  identification, e.g.
• conflicts between departments
• absences of communication lines
• shortages of supply etc.

20
SSM The problem situation expressed
Where is my system?
My system is broken.
User Friday
User Monday
But I did that on Tuesday
No problem. Ill sort it!
LOG 1. 2. 3.
21
SSM Root definitions of relevant systems

• Root definitions are a technique for identifying
  the perspective (underlying belief) of each actor
  or stakeholder in the rich picture.
• Each stakeholder may have a different underlying
  perspective about why the organization does what
  it does, or what its priorities should be.
• A root definition is expressed in a short
  sentence. This gives the sentence a rich focus of
  expression.
• Checkland argues that it should contain a number
  of elements, to which he gives the mnemonic
  CATWOE.

22
SSM Root definitions of relevant systems

• CATWOE stands for
• C Customer the beneficiary of the business
  system.
• A Actor the people who perform the tasks in the
  system
• T Transformation the core activity of the
  system, or the primary change brought about
  as a result.
• W Weltanschauung (or worldview) the underlying
  belief about the system, whether it is the
  priority, the type of system or the
  objective of the system
• O Owner the person or body that has the power
  to approve/cancel the system
• E Environment the factors outside the system
  that might impose constraints on how it
  operates, e.g. legal or regulatory rulings,
  business environment, workload

23
SSM Root definitions of relevant systems
  USER IT SUPPORT C End users The
business A IT support staff IT support staff
T Look after my system Respond to calls W My
system must always We can correct any fault be
available quickly O IT manager IT
manager E My clients need me to Appraisal
criterial, relations provide immediate between
business and IT, information and response IT
workload - a very competitive marketplace
24
SSM Root definitions of relevant systems

• The CATWOE elements for a stakeholder can then be
  combined to form a simple one or two sentence
  statement.
• In the case of the user, it might read as
• IT support staff are responsible, under the
  direction and approval of the IT manager, for
  looking after the end-users computer systems,
  because I (and the other end-users) need the
  computer system to be available in order to do
  our job. This is a competitive environment, if I
  can not answer the queries swiftly, we will lose
  business.

25
SSM Building conceptual models

• A conceptual model is developed for each root
  definition
• The conceptual model is a diagram of the
  activities showing what the system, described by
  the root definition, will do
• Activity names start with verbs and they are
  connected with logical dependency arrows (showing
  order of occurrence)
• The root definitions of the previous stage
  represent an individuals perspective of what the
  business/system is trying to achieve. The
  conceptual model in this stage proposes an ideal
  view of the activities that should be followed in
  order to realize that perspective.
• At the initial drawing, there should not be too
  many activities shown, somewhere between five and
  10 is sufficient. Each activity could be
  decomposed in more detail later.

26
SSM Building conceptual models
Negotiate expected service with customer
Make a survey about customer needs
Agree formally on provided service
Consider new employee skills needed
Provide good and timely service
Train employees
27
SSM Compare conc. models with reality

• After the models (one per root definition) are
  completed, they are compared with the real world
  activities to see whether or not the perspectives
  are being met, and where there are discrepancies.
  
• This comparison can be carried out in many ways
  e.g. interviewing the appropriate actors,
  documenting the current practices, or
  benchmarking.
• Comparison and debate about changes leads to a
  set of recommendations regarding change in order
  to help the problem situation..

28
SSM Compare conc. models with reality
29
SSM Assess feasible and desir. changes

• Analyze the changes proposed in the previous
  stage
• Draw proposals for changes that are considered
  both feasible and desirable
• The activities will have information needs,
  particularly for monitoring their success.
• Here, the first moves are made towards the
  development of an information strategy.

30
SSM Action to improve the problem situat.

• Recommend action to help the problem situation
• The methodology does not describe methods for
  implementing solutions
• The methodology helps identifying and analyzing
  problem situations rather than providing concrete
  ways of solving them

31
SSM Discussion

• Tools and techniques of SSM rich pictures, root
  definitions and conceptual models
• SSM relies less on tools and techniques than
  other hard methodologies
• SSM provides all actors, including analysts,
  opportunities to understand and to deal with the
  problem situation
• Analysts are perceived as actors involved in the
  problem situation, not as outside onlookers
  providing objectivity
• The process is iterative
• It is difficult to know when a stage in the
  project has been satisfactorily completed

32
SSM Discussion (cont.)

• One possible way of using SSM is as a front end
  before proceeding to the hard aspects of system
  development
• SSM emphasizes analysis whereas harder
  methodologies emphasize design, development and
  implementation
• We just described Mode 1 version of SSM.
• In Mode 2 version, two stands of enquiry are
  followed
• logic-driven stream of enquiry
• cultural stream of enquiry

33
Summary of lecture 9

• We discussed two different kinds of
  methodologies
• rapid development methodologies and
• organizational-oriented methodologies
• We gave an 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.
• We gave an 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.