SocioTechnical Perspectives on Methodologies '

1
Socio-Technical Perspectives on Methodologies .

• Look ahead to rest of module
• Trends in hard methods
• Examples of softer methods
• Pressures for new approaches to ISD
• Methods are contentious
• Slogans

2
Trends in hard methods

• Trends in hard methods
• Early approaches
• Structured approaches
• Data-driven approaches
• Object-Oriented approaches

Trend is towards compatibility with, or
accommodation of, softer approaches
3
Trends in hard methods

• Early years
• 1940s scientific problem solving computers were
  tools for the scientists that built them no
  need for any method to support development.
• 1950s early business data processing, grew
  rapidly in 1960s. Problems included
• Carry over of culture from 1940s, but developers
  were less expert and not as continually engaged
  in programs they developed the need for clearly
  written, understandable programs rather than
  obscure, complex programs emerged.
• Need for some broad principles of programming and
  higher level programming languages. The latter
  made feasible by improvements in storage
  technology.
• No formal training of ISDers. Need for academic
  courses.
• By early 1960s programming problems dominated ISD
  and the phrase software crisis was coined.
  (Budgets, deadlines exceeded, no workable
  outcomes of projects).

4
Trends in hard methods

• Early Systems Analysis methods
• Early focus on software crisis soon developed
  into realisation that systems analysis and design
  phases of ISD were also of critical importance.
• Early methods were lifted from industrial
  engineering and used modified flow charts.
• More advanced methods were developed by e.g. NCR
  and IBM. These included ideas like
• separating Analysis and Design phases completely
  from programming
• defining required information outputs first then
  working out what minimum data input was required.
  From this the requirements for a database could
  be worked out.
• Defining overall organisational information needs

5
Trends in hard methods

• The Systems Development Life-Cycle
• Idea of a systematic, reductionist approach
  evolved though 1960s into the waterfall SDLC
  (Royce,1970)
• Stage-limited commitment
• Discrete stages
• Signoff of interim end-products

Planning
Analysis
Design
Implementation
6
Trends in hard methods

• The Structured Approach
• Developed out of waterfall life-cycle
• probably the most widely-known and widely-used
  approach.
• this top-down approach evolved bottom-up from
  structured programming.
• structured programming.
• Programmers should be constrained to 3
  constructs
• sequence, selection, iteration
• Unrestricted branching should not be allowed
• GOTO

7
Trends in hard methods

• The Structured Approach
• structured design
• Cleaning up programming with structured
  programming didnt solve the software crisis, it
  just revealed pollution upstream.
• Top-down, functional decomposition into modules.
• Cohesion and coupling of modules
• Maximise (internal) cohesion
• Minimise (minimise) coupling
• Information hiding by modules (need to know
  analogy)

8
Trends in hard methods

• The Structured Approach
• structured analysis
• More pollution upstream revealed.
• Data flow diagrams
• Entity relationship diagrams
• Data Dictionary

9
Trends in hard methods

• The Structured Approach
• The technical elements could be coupled with
  management elements such as
• Walk-throughs
• Team reviews
• Sign-offs
• Phased-deliveries
• It could be sold in form of training courses and
  books.
• It was seen as a silver bullet for a time.

10
Trends in hard methods

• The Structured Approach
• Criticisms and weaknesses
• Transition from analysis to design is poorly
  defined.
• Attempts to solve this by distinct
  logical/physical modelling didnt work.
• Complete set of structured approaches tend not
  to be used - practitioners select what works for
  their circumstances. (But approach is not
  designed to be used like that).
• It disregards problems posed by differing
  interests and power. (Bansler and Bodker)
• Essentially process-driven, didnt address the
  structure of data (it did later).
• One of key originators, Ed Yourdon, described it
  as irrelevant and obsolete given modern
  development environment.

11
Trends in hard methods

• The Structured Approach
• Legacy
• Modules
• Interior of modules clearer and more maintainable
• Exterior of modules clearer and more maintainable
• Large programs composed of modules more
  comprehensible.
• Design more visible due to graphical
  representation of system structure.

12
Trends in hard methods

• Data Driven approach
• Couldnt really emerge until disk-storage had
  developed
• Data structures seen as more stable than
  processes
• Evidence showed that good solutions often used
  processing structures that mirrored data
  structures.
• Recognition that data (information, knowledge) is
  an important organisational resource and should
  be managed accordingly.
• Example SSADM despite its name
• Data-driven but incorporates
• Structured programming
• Event modelling

13
Trends in hard methods

• Object-Oriented Approach
• Object-orientated approach dates back to at least
  1960s (Simula programming language).
• Process and data are encapsulated in a single
  entity.
• Advantages of O-O approach
• Maps to real world objects well
• Natural modelling technique (UML)
• Single representation used throughout life cycle
• Facilitates re-use.
• Claimed to facilitate communication between users
  and developers.
• Examples of current methodologies
• Rational Unified Process (www.rational.com)
• Unified Software Development Process (see Bennett
  et al.)
• Extent of take-up in business domain is unclear.

14
Examples of softer methods

• Examples of softer methods
• Participative approach
• ETHICS
• DSDM
• SSM

15
Examples of softer methods

• Participative Approach
• See first lecture Scandinavian Approach

16
Examples of softer methods
Effective Technical and Human Implementation of
Computer-based Systems. (ETHICS) is a
technique and also a philosophy that future users
of new technical systems should be able to
participate in the design process and help create
systems that are humanistic and friendly as well
as efficient and effective (Enid Mumford, Comm.
Of ACM, July 1993, p.82)

• Arguments for participation
• Ethics. People have a basic right to control
  their own destinies, and this applies in the work
  situation as elsewhere.
• Expediency If people do not have a say in the
  decisions of others, they may repeal or subvert
  the decisions as soon as those others leave the
  scene.
• Expert Knowledge People who are the experts on
  topics such as task design are the people who do
  the jobs.
• Motivating Force Participation is a motivator and
  will increase the productivity and efficiency of
  the eventual system.

17
Examples of softer methods.
ETHICS

• Socio-Technical Satisfaction
• knowledge fit
• knowledge being developed to make staff
  increasingly competent
• psychological fit
• job matches employees status, advancement and
  work interest
• efficiency fit
• effort-reward bargain
• work controls matching employees expectations
• supervisory controls
• task-structure fit
• degree to which tasks are demanding or fulfilling
• ethical fit
• match between employee values and organisational
  values

18
Examples of softer methods
ETHICS

• Levels of Participation
• Consultative. Leaves most design decisions to
  computer specialists, with system objectives and
  the eventual form of the system being greatly
  influenced by the users.
• Representative. Design group is formed involving
  users to design the new work to fit in with the
  technology.
• Consensus Users are involved continuously
  throughout the design process.

19
Examples of softer methods
ETHICS

• ETHICS Diagnostic and Design Tools
• A framework to help identify mission, key tasks,
  important constraints and factors critical to
  effective operation.
• A tool to help identify systemic and operational
  problem areas.
• A framework to help identify what is likely to
  change in the internal and external environment.
• A set of guidelines for individual and group work
  design,

20
Examples of softer methods

• Dynamic Systems Development Method (DSDM)

Influences
Participatory Design
Feasibility Business Study
Risk-Driven Development Process (Spiral Model)
Functional Model Iteration
Implementation
Rapid Application Development
Design and Build Iteration
Evolutionary and incremental development
21
Examples of softer methods

• Soft Systems Methodology (SSM)
• Involves
• Appreciating the situation
• Representing the situation
• Rich pictures
• Imagining possible relevant systems
• Building models of human activity
• Conceptual models
• Comparison
• of understanding of real situation
• with conceptual models
• Recommendations for change
• Taking action

Influences
Systems Theory
Action Theory (learning from reflection on
practice)
Worldviews, including that of developer
Stakeholder participation
22
Pressures for new approaches to ISD

• Pressures for new approaches to ISD

23
Pressures for new approaches to ISD

• (Reminder) Information systems are developed for
  a specific situation in a specific company at a
  specific point in its history.
• In todays context
• The software for many IS is not built from
  scratch but is tailored from some more
  general-purpose package
• e.g. Enterprise Resource Planning (ERP) systems
  Oracle, SAP
• Some ISD deploys off-the-shelf packages
• Configuration development integration of package
  software to incorporate local conditions
• Yet even when as IS includes off-the-shelf
  software, ISD activities are still necessary to
  determine requirements and to fit the
  technological product with the situation in which
  it is used.

24
Pressures for new approaches to ISD

• IS are not only conceptually parts of larger
  systems, but their technological components often
  interact with components of other systems.
• Most ISD these days is not green field
  development, but takes within an existing
  interconnected IS environment with on-going
  complex work practices and skill sets.
• This systemic aspect leads to a development
  process where knowledge about the context becomes
  increasingly important.(Fitzgerald et al.)
• The success of a new development is now more
  obviously judged by
• how well it contributes to the larger system of
  which it is a part,
• Rather than how well it performs in isolation.

25
Pressures for new approaches to ISD

• Changing nature of business environment means
  short-term needs dominate given faster
  metabolism of business these days.
• Altered profile of ISD environment leads to
  replacement of large-scale monolithic approaches
  with approaches based on a good enough and
  frequent tangible results philosophy.

26
Methods are contentious

• Methods are contentious

27
Methods are contentious

• The use of methods for ISD has been the focus of
  much research over a long period of time. The
  main point of contention has been whether the
  methods actually do help in the development
  process (Fitzgerald et al.. 2002,. p3)
• Those who earn their living by developing
  methods, writing about them or researching them
  claim that
• practitioners dont understand the need and
  benefits of using them.
• Practitioners claim that
• available methods dont fit the complexity of the
  development situation and that researchers dont
  understand this.

28
References and Further Reading

• Avison, D.E. Fitzgerald, G. (2003) Where now
  for development methodologies.  Communications of
  the ACM,  46, 1.
• Bansler, J. Bodker.K (1993) A reappraisal of
  structured analysis design in an organisational
  context., ACM Transactions on Information
  Systems. 11, 2, 165-193.
• Bennet, S. et al. (2002) Object-Oriented Systems
  Analysis and Design. (2nd Ed). McGraw-Hill Ch. 3,
  21 and 22
• Fitzgerald, B, Russo,N.L. and Stolterman (2002)
  Information Systems Development Methods in
  Action. McGraw-Hill.