Introduction to Methodologies and SSADM
- Introduction
- What is SSADM?
- Why is SSADM Used?
- How is SSADM Controlled?
- What are the Major Tools?
- How is SSADM Structured?
- Critique of SSADM and DSDM
- SSADM4+
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 :-
- limited user involvement;
- inadequate requirements elicitation;
- use of ad hoc analysis and design techniques;
- absence of CASE support for analysis and design;
- time consuming use of 3GL tools;
- inflexible file and 3rd generation database management systems.
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 :-
- a lack of ownership of and commitment to the system from users as a result of the low level of involvement;
- business requirements may have changed between inception and delivery;
- requirements may have been mis-understood;
- inadequate analysis and design tools and techniques may have been used;
- or more likely a combination of these problems.
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.
- Logical Data Modelling; This is the process of identifying, modelling and documenting the data requirements of a business information system. A Logical Data Model consists of a Logical Data Structure (LDS - The SSADM terminology for an Entity-Relationship Model) and the associated documentation. LDS s represent Entities (things about which a business needs to record information) andRelationships (necessary associations between entities). slide 7
- Data Flow Modelling; This is the process of identifying, modelling and documenting how data flows around a business information system. A Data Flow Model consists of a set of integrated Data Flow Diagrams supported by appropriate documentation. DFDs represent processes (activities which transform data from one form to another), data stores (holding areas for data), external entities (things which send data into a system or receive data from a system and finally data flows (routes by which data can flow). slide 8
- Entity Event Modelling; This is the process of identifying, modelling and documenting the business events which affect each entity and the sequence in which these events occur. An Entity/Event Model consists of a set of Entity Life Histories (one for each entity) and appropriate supporting documentation. slide 9
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
- Feasibility Study; Module 1 the feasibility study consists of a single stage (Stage 0 Feasibility),which involves conducting a high level analysis of a business area to determine whether a system can cost effectively support the business requirements. In stage 0 an overview DFD is produced together with a high level LDS. At this stage the DFD will represent the existing system warts and all and the LDS may be incomplete and contain unresolved M:M relationships. slide 12
- Requirements Analysis; Module 2 requirements analysis consists of 2 stages; Stage 1 Investigation of Current Environment and Stage 2 Business System Options (BSO). During stage 1 the systems requirements are identified and the current business environment is modelled in terms of the processes carried out and the data structures involved. During stage 1 DFDs and an LDS are used to produce detailed logical models of the current system During stage 2 up to 6 business system options are produced and presented. As a result one of these options (or indeed a hybrid solution) is adopted and refined. During stage 2 DFDs and LDS are produced to support each business system option and the final chosen option. The transition from stage 1 to stage 2 is a key part of SSADM, this is where we move from a logical model of the current system to a logical model of the required system, i.e. this is where the DFDs and LDS have to be refined to cater new/changed requirements.slide 13
- Requirements Specification; Module 3 Requirements Specification consists of a single stage (Stage 3 Definition of Requirements) which involves further developing the work carried out in module 2, detailed functional and non-functional requirements are identified and new techniques are introduced to define the required processing and data structures. In stage 3 the DFDs and LDS are refined and cross validated in the light of the chosen business system option. The LDS is enhanced using relational data analysis (normalisation). The DFDs and LDS are validated against the ELHs also produced during this stage. DFDs LDS and ELHs are used as input to the subsequent stages of SSADM. slide 14
- Logical System Specification; Module 4 Logical System Specification consists of 2 stages; Stage 4 Technical System Options and Stage 5 Logical Design. In stage 4 up to 6 technical options (specifying the development and implementation environments) are produced, one being selected. In stage 5 the logical design of update and enquiry processing and system dialogues (menus etc.) is carried out.slide 15
- Physical Design; Module 5 Physical Design consists of a single stage (Stage 6 Physical Design) in which the logical system specification and technical system specification are used to create a physical database design and a set of program specifications. slide 16
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 use of 4th Generation Tools (to enable quick delivery);
- an iterative model of systems development which allows backtracking in the light of changing requirements;
- the use of evolutionary prototypes (SSADM adopts the adage that a picture is worth a thousand words, RAD goes a step further and advocates that a working model is worth a thousand pictures);
- a very high level of user involvement in the development process to aid in communications and to encourage feelings of commitment and ownership;
- the empowerment of highly skilled, multi-disciplinary teams consisting of users, analysts and technical specialists.
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, techniques and tools and scope areas. The framework is also extended to enable comparison on the basis of the suitability of the methodologies for use within a Corporate Information Management Strategy.
Comparative Analysis
(Section Under Development)
Philosophy
<>
Models
<>
Techniques and Tools
<>
Scope
<>
Corporate Information Management Strategy
<>
Critique
Neither SSADM nor DSDM really address the fundamental importance of corporate data management. SSADM adopts a structured, rigorous, project led approach to the development of data structures and processes. DSDM adopts a dynamic, project led approach to both data structures and processes. Both approaches fail to recognise that data structures are largely stable and many processes dynamic.
SSADM can reduce the chances of initial requirements being mis-understood and of the systems functionality straying from the requirements through the use of inadequate analysis and design techniques. However, SSADM assumes that the requirements (in the form of an agreed requirements specification) will not change during the development of a project. Following each step of SSADM rigorously can be time consuming and there may be a considerable delay between inception and delivery (which is typically the first time the users see a working system). The longer the development time the more chance of the system meeting the requirements specification but not satisfying the business requirements at the time of delivery.
RAD has been used successfully in many organisations and is currently gaining more formal support under the auspices of the DSDM consortium. The RAD approach however is not without its pitfalls. DSDM advocates that RAD is only suitable for certain kinds of applications, i.e. those which are interactive, with clear functionality at the user interface, have a clearly defined user group, are not computationally complex and have requirements which are not too detailed and fixed. DSDM advocates that RAD is not suitable for real-time or safety-critical applications or for applications where functional requirements have to be fully specified before any programs are written. Thus RAD would only appear to address part of the applications backlog. Applications suitable for RAD and those not would appear to be at opposite ends of a scale. What about the large class of information systems in between, i.e. those which have;
- a mixture of interactive and non-interactive functionality,
- a core user group which is clear but an ill-defined group of ‘other’ users,
- some elements of computationally complex functionality,
- a range of requirements, from the detailed and fixed to the unclear and variable.
RAD depends on active user involvement in the development process. What happens if the right users are unavailable? It has been stated that the best users to be involved in RAD teams are those which business can’t afford to lose!
There is a common misconception that RAD is a ‘license to hack’, it isn’t, however the temptation is there. There may also be integration and data sharing problems when a number of RAD project teams are working concurrently on different systems. (It should be noted that integration problems are not peculiar to RAD projects, the possibility also exists within structured environments, however the use of consistent analysis and design techniques reduces the probability of this occuring.)
(Section Under Development)
No comments:
Post a Comment