The use of SSADM (Structured Systems Analysis and Design Methodology) as a standard methodology on Information Systems Projects

Exposé Écrit pour un Séminaire / Cours , 2001 , 16 Pages , Note: 1 (A)

Informatique - L'informatique théorique

Table of Contents

1. Management Report

2. Introduction - History of SSADM

3. Discussion of SSADM
3.1 Size of potential systems
3.1.1 SSADM for large systems
3.1.1.1 Benefits of SSADM
3.1.1.2 Disadvantages of SSADM
3.1.2 SSADM for small and medium-sized systems
3.2 Proposed development methods
3.2.1 The Systems Development Life Cycle (SDLC)
3.2.2 Logical Data Modelling
3.2.3 Data Flow Modelling
3.2.4 Entity Event Modelling
3.3 Speed of development
3.3.1 SSADM within the traditional SDLC
3.3.2 The development stages of SSADM
3.3.3 Speed of alternative methods, e.g. Rapid Applications Development (RAD)
3.4 Appropriateness of SSADM to organisational cultures and structures
3.5 SSADM in context with the business situation

4. Conclusion

5. References

1. Management Report

The Structured Systems Analysis and Design Methodology (SSADM) has been developed and mainly used by government departments. This is why it is mainly designed for large-scale Information Systems with high volume business events. SSADM specifies exactly the flows and tasks of a development project and produces a detailed documentation of the project. SSADM sticks to the traditional waterfall model, which allows review of each stage but requires its accomplishment before the next one can begin. SSADM focuses on the Analysis and Design stages of the Systems Development Life Cycle (SDLC). SSADM combines three methods, complementing each other within a systems development cycle: Logical Data Modelling, Data Flow Modelling, Entity Event Modelling.

Its main benefits are: Improvement of quality, detailed documentation of the development stages, and reusability for similar projects that follow. But these points are not likely to be taken into consideration in practice. This is due to the danger of over-analysing, which can be very time and -cost consuming. Delays caused by SSADM can vary in range from months to years. Especially for small or medium-sized companies, huge delays can lead to serious financial and resource problems. So, it is highly advisable to investigate alternative methods, such as the Rapid Application Development (RAD) or to use an off-the-shelf product, which is much less expensive and less time-consuming and has already been tested by various other companies.

2. Introduction

In the late seventies, large-scale Information Systems (IS) became popular in order to manage large systems for billing, salaries, stock control and other applications requiring huge databases. Many organisations did not have an appropriate development method. First of all, analysis of the systems requirements was carried out on an ad hoc basis, so often the final product did not exactly meet the business requirements. Time consuming 3GL programming languages, such as Cobol, were used and the produced files and databases were inflexible.

To overcome these problems, the IS community decided to develop a methodology (e.g. “a system of ways of doing things especially regular and orderly procedures”) standardising the analysis and design stages of the IS development. It was especially designed for government departments and their external providers of software, where there was a great need for Information Systems and hope to improve their IS by using a disciplined engineering method. In fact, SSADM has to be used by all government departments along with the PRINCE project management method.¹ However, the standard is free for every company and may be altered for the specific requirements. The CCTA (Central Computing and Telecommunications Agency), which authorized the project, adopted the proposal of LBMS - Learmonth & Burchett Management Systems in order to develop a method. The launch of the final methodology, called Structured Systems Analysis and Design Methodology (SSADM) was in 1981. Further upgrades have been made since then and Version 4 of SSADM was inaugurated in 1990.²

3. Discussion of SSADM

As one can see, SSADM is a comparatively old system designed for large scale projects. So, one should consider carefully if it is suitable for the system that needs to be developed in respect of the systems size and purpose.

3.1 Size of potential systems

3.1.1 SSADM for large systems, benefits of SSADM

Companies, mainly, who have information systems to manage, i.e. “several high volume business events”³, that can benefit the most from SSADM. It is assumed that in general large companies need to produce large information Systems and small or medium-sized companies produce smaller information systems.

SSADM specifies exactly the flows and tasks of a development project and produces a detailed documentation of the project.⁴ The benefits that this prescribing methodology theoretically offers are mainly the following⁵:

3.1.1.1 Benefits of SSADM

Timelines: Theoretically, SSADM allows one to plan, manage and control a project well. These points are essential to deliver the product on time.

Usability: Within SSADM special emphasis is put on the analysis of user needs. Simultaneously, the systems model is developed and a comprehensive demand analysis is carried out. Both are tried to see if they are well suited to each other.⁶

Respond to changes in the business environment: As in SSADM documentation of the project’s progress is taken very seriously, issues like business objectives and business needs are considered while the project is being developed. This offers the possibility to tailor the planning of the project to the actual requirements of the business.

Effective use of skills: SSADM does not require very special skills and can easily be taught to the staff. Normally, common modelling and diagramming tools are used. Commercial CASE tools are also offered in order to be able to set up SSADM easily.

Better quality: SSADM reduces the error rate of IS by defining a certain quality level in the beginning and constantly checking the system.

Improvement of productivity: By encouraging on-time delivery, meeting business requirements, ensuring better quality, using human resources effectively as well as trying to avoid bureaucracy, SSADM improves the overall productivity of the specific project and the company.

Cuts costs: SSADM separates the logical and the physical systems design. So the system does not have to be implemented again with new hard -or software.⁷

3.1.1.2 Disadvantages of SSADM

But even for large companies, SSADM sometimes has some disadvantages:

SSADM puts special emphasis on the analysis of the system and its documentation. This causes the danger of over-analysing, which can be very time and cost consuming.⁸ Due to various types of description methods, checks of consistence cannot be carried out. Especially with large systems, the outline diagram can become very unclear, because all relevant data flows have to be included.⁹

However, large companies carrying out various projects, can profit from the fact that SSADM gives the possibility to reuse certain techniques and tools for other projects. This reduces cost and time spent enormously in the long run. So, the danger of spending too much money on analysis can be compensated by the reuse of the developed systems and experience gained.

3.1.2 SSADM for small and medium-sized systems

As we have seen, SSADM is mainly designed for large IS and companies. Small or medium sized companies are normally not involved in such high volume business projects. This is the main reason adopting SSADM as a standard methodology for the development of IS should be considered very carefully. The great advantage of smaller companies is, normally, that they are more flexible and less bureaucratic than large companies. Although SSADM sees its long term benefits in more flexibility and time saving (reuse of certain methods), there are still doubts about whether this could be a valuable method for medium sized companies.

At this point, though, one should consider that “it is the attributes of the development rather than the company that indicate the appropriateness of SSADM”¹⁰. If a system is being developed, for which standard methods and CASE tools can be used and it turns out that inhouse development is much more expensive and more time consuming, SSADM is a good solution. Another solution could be to produce cut-down versions of SSADM in order to make it suitable for another project, which is probably smaller. So, the company could benefit from the fact that the staff is already trained and experienced.

3.2 Proposed development methods

3.2.1 The Systems Development Life Cycle (SDLC)

SSADM is a waterfall model, embedded in the so called Systems Development Lifecycle (SDLC), similar to the model developed by Kendall & Kendall. But SSADM focuses mainly on the feasibility, analysis and design stage of the SDLC.¹¹ The specific stages of SSADM will be described in more detail within 3.3. SSADM combines three methods complementing each other to a systems development cycle: Logical Data Modelling, Data Flow Modelling, Entity Event Modelling.¹² SSADM specifies exactly the methods and techniques that have to be used during the single stages of development, even though it does not specify which software or tool has to be used.

3.2.2 Logical Data Modelling

Within this process the data requirements of an IS are investigated, identified, modelled and documented. The logical data structure (LDS) is formed. It gives information on the entities that need to be put down and on the relationships between these entities.¹³ Logical Data Modelling is mainly carried out in the first two stages of the SSADM development. So, for the feasibility stage, a higher Data Flow Diagram (DFD) and an Entity Relation Diagram are normally produced.

Data Flow Diagrams are used to describe the system in different levels of abstraction. They model functionality and show how input transforms into output. Entity Relation Diagrams represent objects and their relationships. They normally show the important entities and relations but no attributes.¹⁴ DFDs and ERDs are going to be used several times within the different levels of SSADM.

The following graphic shows the symbols that are used to produce a DFD.

Abbildung in dieser Leseprobe nicht enthalten

3.2.3 Data Flow Modelling

While Data Flow Modelling focuses on IS requirements, Data Flow Modelling deals with identifying, modelling and documenting how data flows around and within an IS. Again a comprehensive DFD is produced. This DFD shows the connection between various processes within the IS. The transformation of the processes, however, are more likely to be represented in a distinct description of processes. Furthermore, the DFD shows the data stores, which could be directories, folders, servers and the way they are accessed. A description of the external entities (persons or companies that do not belong to the systems but are relevant to it) should be included, too. Finally, data flows between processes, data stores and external entities are also represented.¹⁵

3.2.4 Entity Event Modelling

The process of Entity Event Modelling deals with the business events that have an impact on each entity and its surrounding. This information is put down in a so called Entity Life Histories¹⁶ file.

Finally, for each process, data flow, data store and external entity there is an entry in the so called data dictionary. This data dictionary is the central catalogue of data within an IS. It shows the structure, storage, connections, origin and use of data. The data dictionary aims to give the possibility of describing the elementary data in an appropriate verbal way.¹⁷

3.3 Speed of development

The development of an IS using SSADM is considered one of the most expensive ways. This is due to the fact that using SSADM means to develop a bespoke (in-house or outsourced) system. Although this system will meet its requirements perfectly and be of very good quality, the use of a formal structured methodology like SSADM is very time-consuming.¹⁸ The delays that are caused by the obligation to complete each stage before commencing the next and by the repetition of certain analysis and design stages, range between months or years. Especially for small or medium-sized companies such huge delays can lead to serious financial and resource problems, even to bankruptcy. The next paragraph will give an insight in the different stages of SSADM and when they have to be completed.

3.3.1 SSADM within the traditional SDLC

As the name reveals, SSADM puts emphasis on the analysis and design stages of the SDLC. Version 4 of SSADM consists of 3 phases split into 6 or 8 stages, which do not represent all of the SDLC stages, but fulfil the same tasks.¹⁹ The number of stages differs, because the feasibility stage is not imperative. Using SSADM, each stage is reviewed and has to be completed before commencing the next one. This is probably the most important reason, why SSADM is, on the one hand, very time-consuming, but, on the other hand, widely regarded as an improvement to the quality of a system.

3.3.2 The development stages of SSADM

Stage 0: Feasibility study

Investigation of economical and technical feasibility. The problems are defined and the project identified. The best business option is chosen out of up to 5 propositions. In SSADM the feasibility stage is not imperative.

Stage 1: Investigation of the current environment

Definition of broad requirements, investigation of current data and processing. The project is being identified and costs calculated. This stage is especially important as any omissions will have a bad effect on the whole project.¹

Stage 2: Business Systems Options

Formulation of business systems requirements. Evaluation of the implication and benefit of each proposed option.

Stage 3: Requirements specification

Identification of functional and non-functional require- ments in detail. Proposal of new methods and techniques in order to describe processing and data structures.¹

Produce a logical design of the proposed systems.

The entire waterfall model²⁰

Abbildung in dieser Leseprobe nicht enthalten

Stage 4: Technical systems options: Definition and selection Maintenance of specific technical options, such as different methods of implementation. and Review

Stage 5: Logical design: May be simultaneously to stage 4. User dialogues, update processes, enquiry processes are defined and selected.

Stage 6: Physical design: After producing a physical design, creating a function and data design, the SSADM cycle is completed and the applications are ready for delivery.

3.3.3 Speed of alternative methods, e.g. Rapid Applications Development (RAD)

Small and medium-sized companies, especially, will have to bear in mind that “time is money” because they do not have such large reserves or incomes from other parts of the company. SSADM, as we have seen, is very time consuming, they will have to look for alternative methods to SSADM.

There is mainly one method that focuses especially on fast, flexible and low resources development of IS. This method is called Rapid Applications Development (RAD). IT uses prototyping to involve users, so this definitely meets their requirements, and can help to develop IS faster.

RAD is mostly used in combination with the Dynamic Systems Development Methodology (DSDM). Its major principles are as follows:

ƒ- “Active user involvement is imperative.
ƒ- DSDM teams must be empowered to make decisions.
ƒ- The delivery of products is the most important factor.
ƒ- Fitness for business is the essential criterion for acceptance of deliverables.
ƒ- Iterative and incremental development is necessary to ahcieve an accurate business solution.
ƒ- All changes during development are reversible.
ƒ- Requirements are baselined at a high level.
- Testing is integrated throughout the life-cycle.
ƒ- A collaborative and co-operative approach between all stakeholders is essential.”²¹

3.4 Appropriateness of SSADM to organisational cultures and structures

The term organisational culture can be defined as “…a system of shared meaning held by members that distinguishes the organisation from other organisations.”²² This comprises unwritten rules, shared values and customs within an organisation. Each type of organisational culture normally appears alongside an “ideal” type of organisational structure, in this case a product/service-based design.

The parts of organisational culture, on which SSADM, if applied, has an effect, are control, direction, risk tolerance, and communication patterns.²³ Especially the extent of control, e.g. the number of rules, regulations, and supervision, are affected by using SSADM. So, an organisation with a structured and hierarchical culture, for example role or person culture, will have less problems adopting SSADM and getting its employees accustomed to it. Whereas organisations with power or task cultures, which allow the single employee to take more responsibility, and which in general tend to be less bureaucratic and more dynamic, will have difficulties alongside the Structured Systems Analysis and Design Methodology.

3.5 SSADM in context with the business situation

After discussing various aspects of SSADM, advantages as well as disadvantages have been identified. And these are closely related to the stability of the business situation of the organisation. It can only profit from the advantages that SSADM provides, such as better quality (due to the review of each stage) or meeting the requirements more exactly (due to emphasis on the requirements analysis stage), when the following criteria are met:

First of all the volume and the time that is at disposal must be large enough to undergo the whole development process. Secondly, the short term business situation is not supposed to change drastically, because SSADM does not intend to change the specifications that were made in advance after the review of the stage had been completed. This fact can lead to the problem that the end result deliver does not meet the business requirements at the point of time when it is delivered.²⁴

Considering the long-term situation, SSADM has shown that it increases the overall quality of Information Systems within an organisation. The fact that SSADM has become the imperative development methodology for government departments and their suppliers of IS proves this fact. However, it must be considered that SSADM was developed especially for these kinds of companies and that government projects, in general, have enough time, money and human resources to cope with the bureaucratic nature of SSADM.

4. Conclusion

“We will examine more realistic models later.”²⁵ This sentence can be found in Dave Chaffey’s book “Business Information Systems” in relation to the use of a traditional waterfall model. It reveals very well the overall problem that SSADM as the prime example of a waterfall model poses. It is said to be very bureaucratic, time and cost consuming. Only for large organisations, such as government departments does it make sense to adopt this structured methodology.

For medium-sized companies, developing a comparatively small information system, there are better solutions for developing an IS. If the aim is to develop a bespoke system, it is proposed to use the Rapid Application Development (RAD). Some discussion has been made about it in 3.4.3. But bearing in mind the limited resources of a medium-sized company, it should also consider using an off-the-shelf product, which is much less expensive and timeconsuming and has already been tested by various other companies.

5. References

Bocij, P., Chaffey, D., Greasley, A., Hickie, S., (1999) Business Information Systems, Prentice Hall, England

The Government of the Hong Kong special Region (1998) An introduction to Structured Systems Analysis & Design Methodology (SSADM) [S3a] Version 2.0 [Internet] Available from: <http://www.itsd.gov.hk/itsd/textmode/quality/download/s3a.pdf> [Accessed 20 December, 2001]

Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England

Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet] Pontypridd, University of Glamorgan. Available from: <http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html> [Accessed 20 December, 2001]

Krallmann, H., (1994) Systemanalyse im Unternehmen: Geschäftsprozessoptimierung, partizipative Vorgehensmodelle, objektorientierte Analyse, Oldenbourg Verlag, München

Robbins, S. P (1991) Organizational Behaviour: concepts, controversies and applications. 5/e. Prentice-Hall, England

Sandhill Consultants, (2001) SSADM Process Library [Internet]. Available from: <http://www.sandhill.co.uk/pware/ssadm.htm> [Accessed 20 December, 2001]

[...]

---

¹ Chaffey, D., et. al. (1999) Business Information Systems, Prentice Hall, England, p.262

² Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]

³ Sandhill Consultants, (2001) SSADM Process Library [Internet]

⁴ Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 489

⁵ The Government of the Hong Kong special Region (1998) An introduction to SSADM, Version 2.0 [Internet]

⁶ Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 491

⁷ The Government of the Hong Kong special Region (1998) An introduction to SSADM, Version 2.0 [Internet]

⁸ Sandhill Consultants, (2001) SSADM Process Library [Internet]

⁹ Krallmann, H., (1994) Systemanalyse im Unternehmen, Oldenbourg Verlag, München, p.73

¹⁰ Sandhill Consultants, (2001) SSADM Process Library [Internet]

¹¹ Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 489

¹² Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]

¹³ Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]

¹⁴ Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 491

¹⁵ Krallmann, H., (1994) Systemanalyse im Unternehmen, Oldenbourg Verlag, München, p.65

¹⁶ Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]

¹⁷ Krallmann, H., (1994) Systemanalyse im Unternehmen, Oldenbourg Verlag, München, p.68

¹⁸ Chaffey, D., et. al. (1999) Business Information Systems, Prentice Hall, England, p. 249

¹⁹ Hawryszkiewycz, Igor, T., (1995) Systemanalyse und -design, Prentice Hall, England, p. 489

²⁰ Chaffey, D., et. al. (1999) Business Information Systems, Prentice Hall, England, p.258

²¹ Chaffey, D., et. al. (1999) Business Information Systems, Prentice Hall, England, p. 273

²² Robbins, S. P (1991) Organizational Behaviour: concepts, controversies and applications. 5/e. Prentice-Hall

²³ Robbins, S. P (1991) Organizational Behaviour: concepts, controversies and applications. 5/e. Prentice-Hall

²⁴ Hutchings, T., (2001) Introduction to Methodologies and SSADM [Internet]

²⁵ Chaffey, D., et. al. (1999) Business Information Systems, Prentice Hall, England, p.253

• Note: 1 (A)
• Auteur: Marion Schumacher (Auteur)
• Année de publication: 2001
• Pages: 16
• N° de catalogue: V106034
• ISBN (ebook): 9783640043132
• Langue: anglais
• mots-clé: SSADM, Systems, Analysis, Design, Methodology), Information, Systems, Projects