late 1960s and early 1970s

1
INFORMATION SYSTEMS DEVELOPMENT METHODOLOGIES
Why do we need them?
Why cant we develop systems using our instincts
and common sense?
What are the perceived problems in ISD?
late 1960s and early 1970s - The Software Crisis
2
First attempts to develop large and complex
systems were discouraging
The Software Crisis

• Late delivery of software
• Cost of software development often over budget
• Delivered software does not meet user
  requirements
• Software takes too long to build
• Application backlog
• Delivered system often unresponsive to changing
  user
• requirements
• Problems of maintenance ever increasing
• User confidence decreasing

3
First attempts to develop large and complex
systems were discouraging
The Software Crisis

• Late delivery of software
• Cost of software development often over budget
• Delivered software does not meet user
  requirements
• Software takes too long to build
• Application backlog
• Delivered system often unresponsive to changing
  user
• requirements
• Problems of maintenance ever increasing
• User confidence decreasing

4
Hiring more programmers and systems analysts
Exploitation of new markets (Big Bang) mergers
BUT is short termism

• No Army - just a well-trained well-supported
  hit-squad
• need higher pay
• needs to be tied in with training
• supply of suitable software development tools
  office space

5
Let users develop their own systems
This is the case with many other technologies
chauffeurs and phone operators not used by most
of us to interact with the car and the telephone!
increasingly common with informed school-leavers
and graduates entering business and having 4th
generation languages and PCs readily available
1999 IBM invoicing system global standard
introduced but each region quickly modified the
reporting structure.
6
Develop better programming languages
machine assembly procedural 4th generation
Have changed enormously can increase
productivity by x10 BUT programming is only
10-15 of development time ? gain is much less
substantial
4th generation eliminates input editing,
validation, report formatting, file handling
7
Attack the maintenance problem

• 50-75 of resources in many big organisations on
  maintaining OLD systems
• can they afford to throw them away?
• restructure them?
• reverse Engineering?
• carefully documenting where changes are made
  (50 of changes occur in only 5 of the code)

8
Use more disciplined engineering techniques
use structured programming, structured design and
analysis with software metrics and quality
assurance

• modest impact
• 10-20 improvement during development
• BUT much improved costs in maintenance
• and higher reliability - can be 10x less costly

9
Automate tools for systems development
CASE tools RAD reusable code Java beans
The Cobbler's children Conundrum building
automated systems is largely a manual job!
10
The Software Crisis

• Late delivery of software
• Cost of software development often over budget
• Delivered software does not meet user
  requirements
• Software takes too long to build
• Application backlog
• Delivered system often unresponsive to changing
  user
• requirements
• Problems of maintenance ever increasing
• User confidence decreasing

11
The Software Crisis
SOLUTIONS
Waterfall or Traditional Life Cycle Focus on
modularisation and structure NOT
hacking Sequential limited iteration
only Structured Methods (SSADM) Focus on data,
tasks, techniques and tools Aim to provide
increased rigour Seen as unwieldy, difficult to
understand and master
12
The Software Crisis
SOLUTIONS
RAD Rapid Applications Development Focus on
speed of development High user involvement and
use of prototyping Risk of quick and dirty
solution licence to hack Soft
Systems Focus on organisational and social
issues Limited attention to technical issues Not
generally provide full life cycle coverage
13
Stage 0
Feasibility Study
Feasibility
Stage 1
Requirements Analysis
Investigation of current environt
Modules and stages of SSADM
Stage 2
Business systems options
Stage 3
Requirements Specification
Definition of requirements
Structured Systems Analysis Design Methodology
Stage 4
Logical Systems Specification
Technical system options
Stage 5
Logical Design
Stage 6
Physical Design
Physical Design
14
SSADM
Unlike the Conventional Approach SSADM is data
driven

• Assumptions
• business methods change often
• IS processes will need to reflect changes
• underlying data in the system changes very
  little

Modelling the data is at the core of SSADM begins
very early in the development of the IS

• Representation of the data is checked against
• processing
• reporting requirements
• before being built into the systems architecture

15
Module Feasibility Study
Modules and stages of SSADM

• Stage 0 Feasibility
• Prepare for the feasibility study
• Define the problem
• Select feasibility options
• Create feasibility report

A feasibility study is usually NOT included if
there is an underlying assumption that the
project needs to go ahead
16
Module Requirements Analysis

• Stage 1 Investigation of
• Current Environment
• Establish analysis framework
• Investigate and define requirements
• Investigate current processing
• Investigate current data
• Derive logical view of current services
• Assemble investigate results
• Stage 2 Business system options
• Define business system options
• Select business system options
• Define requirements

Modules and stages of SSADM
17
Module Requirements Specification
Modules and stages of SSADM

• Stage 3 Definition of Requirements
• Define required system processing
• Develop required data model
• Derive system functions
• Enhance required data model
• Develop specification prototypes
• Develop processing specification
• Confirm system objectives
• Assemble requirements specification

18
Module Logical System Specification
Modules and stages of SSADM

• Stage 4 Technical system options
• Define technical system options
• Select technical system options
• Define physical design module
• Stage 5 Logical Design
• Define user dialogues
• Define update processes
• Define enquiry process
• Assemble logical design

19
Modules and stages of SSADM
Module Physical Design

• Stage 6 Physical design
• Prepare for physical design
• Create physical data design
• Create function component implementation map
• Optimise physical data design
• Complete function specification
• Consolidate process data interface
• Assemble physical design

20
Modules and stages of SSADM
Analysis is separated from design this aids
elimination of paralysis by analysis a wealth
of information on the current system can
overwhelm the systems analysis team which could
then influence design of the new system whereas
- user requirements should be paramount
21
Modules and stages of SSADM
Essentially the 6 modules of SSADM
cover Systems Investigation Systems
Analysis Systems Design of Conventional
Approach
22
Feasibility Study Systems Investigation Systems
Analysis Systems Design
Implementation and testing Review
Maintenance
23
Modules and stages of SSADM
Without a feasibility study there is increased
emphasis in
Investigate and define requirements sub-phase
of Stage 1 Investigation of Current
Environment Define requirements sub-phase of
Stage 2 Business System Options
in order to determine how the IS will be achieved
24

• The waterfall model
• The waterfall model of the software development
  process is within the paradigm used in the
  traditional life cycle
• The development process is seen as being made
  up of a series of distinct stages, or phases,
  each of which can be completed, and 'signed off'
• Typically, SSADM, the completion of a stage is
  marked by the submission of a set of defined
  deliverables

25

• Iteration within the Waterfall model
• A major problem with software design is the need
  for iteration - typically required for, and a
  result of, verification and validation (described
  in Boehm, 1981, quoted by Somerville)
• "Verification 'Are we building the product
  right?'
• Validation 'Are we building the right product?"

26
Iteration within the Waterfall model
Asking these questions at the end of each
development stage may result in a decision to
repeat (iterate) the stage and sometimes require
a reworking of a previous stage Iteration can be
included within the waterfall model, but tends to
reduce the manageability of a project. To deal
with this, a strategy is used whereby a stage is
'frozen' after a specified number of iterations.
27
Key benefits of SSADM

• Teachable
• Effective use of both experienced and
  inexperienced staff
• Great resilience against loss of key staff
• Improved involvement of end user over
  Conventional
• Approach
• Earlier/better validation of stages of analysis
  and design
• More complete and less ambiguous specifications
• More maintainable systems
• Improved management control of systems development

28
RAD philosophy

• Systems will not be developed and deployed
  rapidly
• if bureaucracy or political obstacles are in
  the way
• End-users need to act
• Management must be on-board to facilitate fast
• system building
• Fast development needs people with the right
  skills
• and talents

29
RAD philosophy

• In summary
• 4 essential aspects to fast development
• Tools
• Methodology
• People
• Management

30
RAD Rapid Applications Development
It cannot be denied that many core computer
applications in many corporations are obsolete
and fragile

• often created using third-generation languages
• without modern design techniques
• not designed for powerful desktop machines
• nor for connections to LAN or internet (WWW)

RAD
Focus on speed of developmenthigh user
involvement and use of prototyping
prioritisation essential use of CASE tools risk
of quick and dirty solutions "licence to hack"
POWER TOOLS
the Information Factory needs re-tooling
31
RAD
Return to an engineering-like approach to
information systems development
because
strategic
32
RAD
the key to RAD tools is INTEGRATION

• Tools
• 4th-generation languages
• non-procedural
• oriented to results rather than how to achieve it
• SQL (structured query language)
• User-friendly query languages
• Report generators
• Prototyping tools
• quick-build
• special prototype languages
• iterative development
• successive refinement

33
RAD

• CASE tools
• Computer-Aided Systems Engineering
• Graphically oriented ways of expressing
• plans
• models
• designs
• Code generators
• can generator COBOL from high level constructs
• Expert system shells
• ways of capturing functionality
• using rule-based language
• combine with object-oriented programming

34
RAD
CASE tools should perform the following
functions

• use diagrams for planning, analysis, design and
  code-generation
• solicit information about objects and their
  relationships so a complete set of information is
  built up
• store the meaning of diagrams, rather than just
  the symbols
• check for accuracy, integrity and completeness
  (AIC)
• allow multiple types of diagrams for
  representation of analysis and design
• enable users to draw program procedures that
  show conditions, loops, case-structures and other
  constructs
• enforce structured modelling that permits
  accuracy and consistency checks
• coordinate diagrams check for consistency so
  that together they have AIC
• allow all this information to be shared by other
  analysts and designers
• ensure consistency between developers working on
  various projects

35
Iteration - changing to the spiral model
RAD focuses on the development and implementation
of systems using a prototype. The concept of
iteration is further by discarding the waterfall
model and adopting the spiral model of
development
36
Cumulative cost
Progress through steps
Determine objectives, alternatives, constraints
Evaluate alternatives, identify, resolve risks
Risk analysis
Risk analysis
Risk analysis
Operational Prototype
Risk analy- sis
Prototype 3
Proto type1
Prototype 2
commitment partition
REVIEW
Simulations, models, benchmarks
Concept of operation
Requirements plan life-cycle plan
software require- ments
software product design
detailed design
requirements validation
develop- ment plan
code
unit test
integration and test plan
design validation and verification
integration and test
Develop, verify next-level product
Plan next phases
accept- ance test
Implem- entation
The Spiral Model