Information Systems 1
Download
Report
Transcript Information Systems 1
IMS5006 - Information Systems
Development Practices
Structured Systems
Analysis and Design Method
(SSADM);
Information Engineering
3.1
Structured Systems Analysis and
Design Method (SSADM)
A comprehensive and structured approach
to systems development
A “baseline” for comparison and
evaluation of other methodologies and for
themes in systems development
The true successor to the traditional SDLC
approach with new techniques and tools
developed since the 1970s
3.2
Structured Systems Analysis and
Design Method (SSADM)
assumptions about information systems:
relatively stable
routine processing, well-defined interaction
free-standing, developed from "scratch"
globally defined data, processes
complete and objectively definable
information is well-structured
3.3
Structured Systems Analysis and
Design Method (SSADM)
assumptions about information systems development:
essentially a linear process
users know their current and future needs
conceptual descriptions can be complete
in the early lifecycle stages, system structure is more
important than system behaviour
specification techniques should be simple and
graphical for users to understand easily
3.4
Structured Systems Analysis and
Design Method (SSADM)
assumptions about information systems, systems
development and the system developer’s roles:
system developer is the “expert” who has the technical
knowledge to provide a solution
system developer “owns” the methodology and
controls the development process
users have the business knowledge and must work
with/support system developers as necessary to
ensure requirements are met
users will own the system, must sign off
3.5
SSADM
developed by LBMS and Central Computing and
Telecommunications Agency (CCTA) in the UK
accepted by CCTA in January 1981 as the standard
approach within the UK civil service
requirements:
documentation
self-checking
tried and tested techniques
tailorable
teachable
3.6
SSADM
mature, widely used in UK in particular
typically medium to large projects
“data-driven” due to emphasis originally on data modelling
and database technology
later versions are more balanced:
role of users emphasised
importance of processes and functions
version 4 in 1990
earlier version has 6 stages (Downs, Clare and Coe 1988)
version 4 has 7 stages (Avison and Fitzgerald 2003)
3.7
SSADM
highly structured
facilitates project management
documentation “pervades” SSADM
e.g. completion of preprinted forms
stages and their activities are precisely defined as are
their associated deliverables
3.8
SSADM
prescriptive
reductionist
comprehensive
has evolved with use: versions, CASE tool
templates e.g. micro SSADM, maintenance
SSADM
SDLC phases: feasibility, systems analysis,
system design
focus on functional and technical aspects
3.9
SSADM phases
earlier version - Downs, Clare and Coe 1988: three phases
1.
feasibility study
examine the business and technical
feasibility of the project
2.
systems analysis
analyse the current system and problems,
identify new requirements and technical options
3.
systems design
logical data and process design, physical design
3.10
SSADM phases and stages
1. feasibility study
stage 01: problem definition
stage 02: project identification
2. systems analysis
stage 1: analysis of systems operations & current problems
stage 2: specification of requirements
stage 3: selection of technical options
3. systems design
stage 4: data design
stage 5: process design
3.11
stage 6: physical design
(Downs et al 1988)
SSADM
characteristics
Downs, Clare and Coe 1998
hierarchical structure:
phases, stages, steps, tasks, techniques
data driven design
cross-checking
separation of logical and physical
tailorable
user communication
quality assurance
documentation standards
3.12
SSADM techniques
Downs, Clare and Coe 1988
data flow diagrams
logical data structuring (LDST)
entity life histories
dialogue design
relational data analysis (RDA)
composite logical data design (CLDD)
process outlines
system flow charts
3.13
SSADM: other SDLC phases
construction and implementation:
output of physical design can interface with
1.
traditional programming (JSP)
2.
application generators
3.
application packages
prototyping can be used in design and construction
automated support tools are available
a project management methodology can be used
organisational IT/ IS planning:
use a planning methodology
e.g. LEAP developed by LBMS
3.14
SSADM: later versions
version 4 - Avison and Fitzgerald 2003: five phases, seven stages
feasibility study
0
Feasibility
requirements analysis
1
Investigation of current environment
2
Business system options
requirements specification
3
Definition of requirements
logical system specification
4
Technical system options
5
Logical design
physical design
6
Physical design
3.15
SSADM version 4:
Feasibility Study
ensure the project identified in planning phase is feasible
(= technically possible) and benefits > costs
prepare for the study (assess the scope)
define the problem (compare requirements with current
situation)
identify and select feasibility option (consider broad
alternatives in terms of business requirements and
technical options)
produce feasibility report
techniques: interviewing, document review etc., broad
DFDs and ER model
3.16
SSADM version 4:
Requirements Analysis
1 Investigation of current environment
detailed physical DFDs and ER model of current
processing and data,
logical DFDs, functional and non-functional
“requirements catalogue”,
scope and feasibility study results re-examined
2 Business system options
cost-justified requirements only, determine and agree on
functionality,
business options meeting minimum requirements: cost,
technical constraints, development schedule, benefits
and impact, training, etc.
3.17
SSADM version 4:
Requirements Specification
3 Definition of requirements
logical data model (ER) extended,
attribute collection and normalisation,
DFDs extended,
full documentation of all data, processes and
events,
entity life history diagrams,
prototyping can be used for important dialogues
and menu structures
3.18
SSADM version 4:
Logical System Specification
These stages occur in parallel:
4 Technical system options
environment in which system will operate - hardware,
software, contraints (e.g. performance, security, service
levels)
5 Logical design
design what the system is required to do
user involvement, refer to any prototypes, define
dialogues and menu structures for specific user roles,
ELHs used to define update and enquiry processing,
data validation rules etc.
3.19
SSADM version 4:
Physical Design
map the logical design onto a specific physical environment:
functional component implementation map (FCIM)
6
Physical design
roles of the technologists stressed
users and analysts verify final design satisfies user
requirements,
convert data model, specify programs, procedures etc.
specific activities depend on specific environment (system
type, size, technical platform etc.
SSADM ends: subsequent activities build, test and install the
system
3.20
SSADM
a structured approach: well-defined structure for
its use, for training, and for managing projects
supported by CASE tools
clearly defined deliverables and quality review
checkpoints
relies on availability of skilled personnel
systems development is about providing
technical solutions to business problems
3.21
Information Engineering
Martin and Finkelstein (1981), Martin (1989), several
versions
data oriented methodology
full lifecycle coverage
organisation-wide perspective on planning of information
technology and information systems
top-down analysis and development of organisation’s
applications
focus on data and activities
well-supported by CASE tools e.g. IEW, IEF
has evolved
widely used
3.22
Information Engineering
evolution
data base technology
data analysis and data management
strategic data models, procedure formation
4GLs and “productivity tools”, e.g. code generators
alignment of information systems planning with strategic
business planning
process modelling techniques
CASE technology, “encyclopedia”, knowledge
coordinator
RAD (Rapid Application Development)
object-oriented concepts
3.23
Information Engineering
data centred:
model data requirements first, processes later
(data is more stable)
applications will be integrated by a common data
framework
information engineering:
“an interlocking set of formal techniques in which
enterprise models, data models and process models are
built... and are used to create and maintain data
processing systems”
James Martin (1986)
use of diagrams as a communication and representation
3.24
tool
Major phases of Information
Engineering
information strategy planning
to build an information and technology architecture to
support business strategy and objectives
business area analysis
to identify data and function requirements of each
business area
individual systems planning
systems design
to complete logical specifications for a system and
convert these into physical design specifications
construction
to generate code, test, and install the system
cutover
3.25
Phase 1 - information strategy
planning:
corporate management and planners assess the
organisation:
business mission, objectives, CSFs, performance
measurements, organisation structure, current situation
construct corporate data model
determine major business functions
identify business areas, including goals and CSFs
determine:
information architecture (global entities and business areas)
information systems architecture (business sytems)
technical architecture (technology: hw/sw/comms)
information strategy plan (priorities)
3.26
Phase 2 - business area analysis:
identify and model in detail the fundamental data and
activities required to support a business area
ensure that requirements are independent of technology
ensure that requirements are independent of current
systems and procedures
ensure that requirements enable business area’s goals
and CSFs to be supported
ensure that requirements are independent of the current
organisational structure
a high-level executive sponsor is necessary
3.27
Business area analysis: steps
extract the relevant entity relationship model and businessfunction decomposition models
identify relevant departments, locations, business goals, CSFs
create a preliminary data model: identify events, entity life
cycles, initial attributes
create a preliminary process model: decompose the functions
into processes
model data and processes of existing systems for comparison
involve all affected end-users in iteratively building:
a detailed data model, a detailed process model, entity /
process matrices
3.28
identify and prioritise system development projects
Business area analysis:
techniques
data model
entity relationship modelling
attribute collection
normalisation
canonical synthesis
process model
process decomposition models
process dependency diagrams
data and activity interaction
entity lifecycles
process / entity matrix
3.29
Information engineering:
phases 3 and 4
Phase 3 - individual systems planning
use JRP for individual systems planning
Phase 4 - system design:
concerned with how selected processes in the business
are implemented in procedures and how these
procedures work
use the logical data and process models to design the
external representations of the system
direct end-user involvement is essential
identify reusable procedures
use prototyping
use JAD
3.30
System design techniques
prototyping
detailed process models: procedure design using
access path and volumes analysis, dialogue flows
and menu structures,
physical database design, file design,
screen displays
menu flows
report layouts
on-line procedures and software
batch procedures and software
design verification and testing
3.31
Information engineering:
phases 5 and 6
Phase 5 - construction:
technical design, create physical databases
create modules and programs, unit testing
system testing, documentation
Phase 6 - cutover:
conversion
final testing
conduct training
install the system, review implementation
3.32
Information Engineering
features:
organisation-wide perspective aligned with strategic
business planning
comprehensive
emphasis on user involvement e.g. JAD, JRP
evolves by incorporating new techniques, concepts,
technologies e.g. RAD, object-oriented concepts
evolves from practice e.g. shortened ISP phase
emphasis on automation e.g. 4GLs, I-CASE, prototypes
primarily for database transaction processing systems
little event or behaviour modelling
3.33
Information Engineering
features:
after ISP phase, activities can proceed in parallel
high level data and process model (co-ordinating
model) enables this by highlighting interfaces and
dependencies between systems etc.
flexible paths through the methodology
e.g. reverse engineering and re-engineering
3.34
References
Prescribed text:
Avison, D.E. & Fitzgerald, G. (2003).
Information Systems Development:
Methodologies, Techniques and Tools. (3rd ed),
McGraw-Hill, London.
Chapters 20.1, 20.3
3.35