2.1

The traditional SDLC

and

structured approaches: Structured Analysis

IMS3230 - Information Systems Development Practices

2.2

The traditional SDLC

Traditional SDLC: basis for many systems development approaches since the 1970s

e.g. NCC in the UK proposed a methodology based on the SDLC in the late 1960s

A linear “waterfall” model:Feasibility study

System investigation

Systems analysis

Systems design

Implementation

Review and maintenance

See Avison & Fitzgerald (2003) chap 3

2.3

The traditional SDLC

Methodologies based on the SDLC have: A series of phases, subphases, activities etc., defined

deliverables Techniques used in particular phases Standards for techniques, documentation etc. Software tools to assist developers e.g. project

management, data dictionary, report generators, CASE tools

Training schemes A philosophy – implied but not stated

2.4

The traditional SDLC

Techniques:

Early: flow charts, organisation charts, grid charts etc.

Later: data flow diagramming, ER modelling, normalisation, etc.

Concepts and philosophy of the traditional SDLC approaches influenced and/or evolved into the later approaches such as Structured Analysis, SSADM, Information Engineering, Object-oriented development approaches etc.

2.5

Strengths of the SDLC: well-tried and tested provides a base guideline for systems development which

can be modified to suit specific requirements emphasis on project control, documentation, standards,

and quality control useful for building large transaction processing systems

and management information systems where requirements are highly structured and well-defined

building complex systems which need rigorous and formal requirements analysis, predefined specifications, and tight control of the system development process

Traditional SDLC

2.6

Limitations of the SDLC: is resource intensive

a large amount of time spent gathering information and preparing detailed specifications and sign-off documents

could take years to develop a system .. requirements change before the system is operational

is inflexible and inhibits change output-driven: the time and cost required to repeat activities

encourages freezing of specifications early in the development and locks users into something that may no longer be appropriate

top-down, step-by-step approach discourages iteration and evolution of understanding and ideas

Traditional SDLC

2.7

Limitations:

hard to visualize final system users sign off specification documents without fully understanding

their contents or implications

management and strategic needs ignored decision-making is often unstructured, there are no well-defined

models or procedures routine, low-level processing instead of meeting strategic and

corporate objectives

Traditional SDLC

2.8

Limitations: not well suited to most of the small desktop systems that are

common does not encourage user participation models based on processes are unstable focus on technical aspects of problem situations

BUT SDLC is still being used successfully Alternative methodologies/approaches do not solve all of these

problems Many systems developed use no methodology (the implications of this????)

Traditional SDLC

2.9

Structured Analysis

De Marco (1978): Structured Analysis and System Specification

Gane and Sarson (1979): Structured Systems Analysis: Tools and Techniques

STRADIS (Structured Analysis, Design and Implementation of Information Systems)

(see Avison and Fitzgerald (2003) Chap 19.1)

Yourdon (1989): Modern Structured Analysis

YSM (Yourdon Systems Method)

(see Avison and Fitzgerald (2003) Chap 19.2)

2.10

apply the concepts of structured design to systems analysis process-oriented functional decomposition to structure the system definition data flow diagrams (DFDs) to represent system

requirements individual, routine, operational level applications influential, widely practised has evolved emphasis on communication with the users

Structured Analysis

2.11

The Structured lifecycle

See DeMarco (1979) for his version

The STRADIS lifecycle:1. initial study

overview DFD of existing system, estimates of time, costs and benefits, report to determine if proceed to next stage

2. detailed studydetailed investigation of existing system, current logical DFDs, statement of costs/benefits, impact on staff/procedures

2.12

The STRADIS lifecycle continued:3. defining and designing alternative solutions

system objectives, new logical DFDs, alternative design options

4. physical designtransform/transaction analysis, normalisation, physical file/DB design,design details of error handling, report and screen formats etc.

implementation not specifically addressed

The Structured lifecycle

2.13

Structured Analysis the “structured specification” (DeMarco):

- a set of fully levelled data flow diagrams

- data dictionary

- transform descriptions (mini-specs) characteristics

- graphic

- non-redundant

- maintainable

- partitioned

- separation of logical and physical

- the viewpoint of the data emphasis on the importance of systems analysis

2.14

Structured Analysis the system is a network of processes with data flowing into and out of

the processes levelling of the system's processes: a static view of the system's

functional decomposition top down modelling postpone consideration of physical implementation details:

- man / machine boundary

- error routines

- initialisation and termination procedures

- design of major inputs and outputs

- performance targets transition to design

2.15

DeMarco (1979): “classic” structured analysis

four stage modelling process:

build a set of current system physical data flow diagrams: (current physical model)

derive a logical equivalent: (current logical model) incorporate new system requirements identified in the

feasibility report: (new logical model) add physical implementation details to reflect the selected

implementation option (new physical model)

Structured Analysis

2.16

See subphases of structured analysis - DeMarco (1979) current physical model:

a detailed investigation of the current system's operations

- determine scope and users affected

- interview users

- collect sample data types, forms, files, transactions

- produce levelled, physical DFDs of current system and data dictionary

- user walkthroughs to verify DFDs

- publish documentation for user acceptance

“classic” Structured Analysis

2.17

current logical model

- “logicalise” the physical DFDs by removing current implementation details

- user walkthroughs to verify the model

new logical model

- use the “charter for change” and current logical model

- identify the domain of change on bottom-level DFDs

- repartition the domain of change

- walkthrough with users to verify

“classic” Structured Analysis

2.18

new physical model:

- establish different options for the man/machine boundary

- prepare cost / benefit statements for each

- users select their preferred option

- convert the new logical model into a physical model which reflects the selected implementation option

transition to system design phase where structured design techniques are used

“classic” Structured Analysis

2.19

emphasis on detailed modelling of the existing system:

- “analysis paralysis”

- inhibits creative redesign

limited data modelling

no modelling of system behaviour

level of individual applications

for routine, highly structured systems

“classic” Structured Analysis

2.20

Evolution of structured analysis Ward and Mellor (1985): Structured Development

for Real-Time Systems

Yourdon (1986): “Whatever happened to structured analysis?”

Yourdon (1989): Modern Structured Analysis model the “essential” system:

- logical model of the new system

- no modelling of the current system model stored data: entity relationship models model system behaviour:

- control flows and control processes

- state transition diagrams

2.21

Modern structured analysisthe essential model

1. the environmental model:

- context diagram

- statement of system's purpose

- event list

2. the behavioural model:

- event-driven, “middle out” partitioning of processes

- entity relationship model

- state transitions diagrams (for real time systems)

- balance all models

- data dictionary (with mini-specs)

2.22

3. the user implementation model

bridge the gap between specification and system design:

- document on DFDs the computerisation boundary

- allocate subsystems and processes to particular software and hardware environments

- design key human/computer interfaces and key error

processing routines

- consider key physical data design decisions e.g. DBMS

- design critical manual procedures

transition into systems design

Modern structured analysis

2.23

References

Prescribed text:

Avison, D.E. & Fitzgerald, G. (2003). Information Systems Development: Methodologies, Techniques and Tools. (3rd ed), McGraw-Hill, London.

Chapters 3, 19

Refer to additional references in the readings at the unit web page and in the prescribed text