|
 |
|
|
|
|
|||||||||||||
|
|
|
Please get in touch with any comments or reactions to my site. In the early days of large scale information systems development many organisations used the Cobol programming language
together with indexed sequential files to build systems for customer billing, payroll, stock control and a variety of other
business areas. Developments at this time were characterised by :- Frequently the results of this approach were systems which, on delivery, did not satisfy business requirements. This caused
extensive maintenance requirements and thus an increase in the applications backlog. A variety of problems may have caused
the mis-match between system functionality and business requirements :- The response from the information systems community to these problems was the development of structured methodologies
for ISE. The purpose of these methodologies seems to have been to (a) formalise the requirements elicitation process to reduce
the chances of mis-understanding the requirements and (b) to introduce best practice techniques to the analysis and design
process SSADM (in common with other structured methodologies) adopts a precriptive approach to information systems development
in that it specifies in advance the modules, stages and tasks which have to be carried out, the deliverables to be produced
and furthermore the techniques used to produce the deliverables. SSADM adopts the Waterfall model of systems development,
where each phase has to be completed and signed off before subsequent phases can begin. SSADM is one example of a structured
methodologies, a variety of others are widely used in ISE, including : STRADIS: (Structured Analysis, Design and Implementation of Information Systems) a methodology developed by Gane
and Sarson (1979). The methodology is based on the philosophy of top down functional decomposition and relies on the use of
Data Flow Diagrams. YSM: (Yourdon Systems Method,Yourdon, 1993). YSM is similar to STRADIS in its use of functional decomposition, however
a middle-out approach is dopted and slightly more emphasis is placed on the importance of data structures. MERISE: (Quang and Chartier-Kastler, 1991)The methodology is widely used in ISE in France, Spain and Switzerland.
MERISE consists of three ‘cycles’, the decision cycle, the life cycle and the abstraction cycle. The abstraction
cycle is the key, in this cycle both data and processes are viewed firstly at the conceptual level, then the logical or organisational
level and finally at the physical or operational level. EUROMETHOD: (CCTA, 1994) Euromethod could be described as a framework for the integration of existing european methodologies
rather than as a methodology in its own right. SSADM (Structured Systems Analysis and Design Methodology) is a methodology (Def. a system of ways of doing things especially
regular and orderly procedures), used in the analysis and design stages of systems development. SSADM does not cover SITP
issues or the construction, testing and implementation of software. "SSADM has been used by the government in computing since its launch in 1981. It was commissioned by the CCTA (Central
Computing and Telecommunications Agency) in a bid to standardise the many and varied IT projects being developed across government
departments. The CCTA investigated a number of approaches before accepting a tender from Learmonth & Burchett Management
Systems to develop a method." (Eva, SSADM Version 4 - A Users Guide) Since 1981 SSADM has been further refined and version 4 was launched in 1990. SSADM is an open standard, i.e. it is freely
available for use in industry and many companies offer support, training and Case tools for it. Within government departments SSADM has to be used. External contractors producing software for the government also have
to use SSADM. SSADM is used by other companies because they expect the use of a disciplined ‘engineering approach will
eventually improve the quality of the systems they produce. many companies have been willing to incur the considerable expense
of implementing SSADM (e.g. staff training) with this expectation in mind. How is SSADM Controlled in the UK? SSADM is managed by the CCTA, however the Design Authority Board (DAB) is responsible for maintaining and developing SSADM
and the NCC (National Computing Centre) produce and maintain the definitive SSADM documentation. What are the Major Tools of SSADM? SSADM revolves around the use of three key techniques, namely Logical Data Modelling, Data Flow Modelling and Entity/Event
Modelling. Three Interdependent Views The success of SSADM may lie in the fact that it does not rely on a single technique. Each of the three system models provides
a different viewpoint of the same system, each of which are required to form a complete model of the system. Within SSADM
each of the three techniques are cross reference against each other to ensure the completeness and accuracy of the complete
model. slide 10 SSADM consists of 5 main modules, which are in turn broken down into a complex hierarchy of stages, steps and tasks. slide 11 A more detailed description of the structure of SSADM appears in the recommended texts, e.g. SSADM Version 4 Models &
Methods chapter 12 and SSADM Version 4 A Users Guide chapters 1 - 7. More detailed descriptions of the usage of the major
tools will appear in the following chapters and are described in detail in the recommended texts, e.g. SSADM Version Models
& Methods chapters 3, 4 and 7 and SSADM Version 4 A Users Guide chapters 8, 9 and 12. Tutorial Sheet: Introduction to SSADM Objectives The objective is to encourage you to view SSADM not as a magic pill which can be swallowed whole or not at all, but as
an analysis & design framework or set of tools which can be adopted in whole or in part depending on requirements and
which can be modified, tweaked or manipulated by people with sufficient experience and expertise. Question 1 Of the three main tools of SSADM (LDS, DFD, ELH) which is the most important and why from the point of view of the analyst/designer?
Which would be the easiest to understand from the end-users point of view? Question 2 "When developing information systems the technical environment should be established as soon as possible to avoid any
nasty surprises in the later stages of development." Is this a valid statement? If so why within SSADM do technical system
options not get considered until the penultimate module. Question 3 With so many possible implementation environments is there any point having a general physical design module? Question 4 Why do you suppose ELHs are not used alongside the DFDs and LDS in the requirements analysis phase? Question 5 Would SSADM be feasible without the support of CASE tools? Avison and Fitzgerald (1995) summarise the problems of the applications backlog along with a number of other issues which
are potential weaknesses of ‘traditional’ approaches to information systems development. One of the responses
to these problems from the information systems community was the development of structured methodologies for Information Systems
Engineering. The purpose of these methodologies seems to have been to (a) formalise the requirements elicitation process to
reduce the chances of mis-understanding the requirements and (b) to introduce best practice techniques to the analysis and
design process. SSADM (Structured Systems Analysis and Design Method, NCC, 1995) is a typical example of a structured methodology. RAD (Rapid Application Development, Martin, 1991) approaches began to be adopted in the late 80’s and are based
on a number of fundamental premises, the most important being the acceptance that business processing requirements will inevitably
change during the development cycle of a system. In order to work with this fact of systems development life the RAD approach
mandates :- The RAD approach has been used successfully in many organisations and is currently gaining more formal support with
the advent of DSDM (Dynamic Systems Development Method, DSDM Consortium, 1995), a framework for RAD. Framework A brief explanation of a framework for comparing methodologies developed by Avison and Fitzgerald (1995) is followed by
its application to the SSADM and DSDM methodologies. The framework consists of 7 elements :- Philosophy: In their terms a philosophy is a principle or set of principles that underlie a methodology. In fact
they define a methodology as a set of techniques underpinned by a philosophy. Model: The model is the basis of the methodology’s view of the world, e.g. the Waterfall and Spiral models
of Information Systems Engineering. Techniques and Tools: Typically a methodology adopts a set of integrated techniques, such as Entity-Relationship
Modelling and Data Flow Modelling and may use CASE tools to support the techniques. Scope: The scope of a methodology defines its start and end points within the ISE lifecycle. Outputs: The outputs define the deliverables to be produced during the phases of the methodology. Practice: This element looks at the use of the methodology in terms of the differences between the theory and the
practice. Product: This element looks at the nature of the product itself, in terms of documentation, CASE tool support, training
courses etc. The forthcoming evaluation addresses each of these elements, however it concentrates on the philosophy, models,
The tight Boys are the leaders of the school |
