This document provides the default structure for SSADM4+ Full Studies (version 4.3).

The SSADM process has been captured in Process Continuum, the process improvement tool from CA, and is in a format which can be :

• tailored to the circumstances of specific organisational standards and projects;
• used by project managers in planning and controlling SSADM4+ projects.

Structured Systems Analysis and Design Method (SSADM) is an analysis and design method that ensures an information systems specification is correctly defined and monitored. It provides a complete framework for capturing and analysing requirements and specifying a system design. SSADM is a flexible and adaptable method with a set of product specifications and the associated procedures for undertaking the development of IT systems to support business needs. The method is integrated with a series of supporting guidelines for customising the method to reflect different development environments.

SSADM has been used by the UK Government in computing since its launch in 1981, when it was originally developed by LBMS for the CCTA. Since its first appearance the method has undergone many changes and is now used widely throughout industry as well as by the government and public sector organisations.

The current release of SSADM is version 4.3, which was launched in 1996 and is targetted at the development of applications with graphical user interfaces.

"SSADM" and "Structured Systems Analysis and Design" are registered trademarks of the Government Centre for Information Systems (CCTA). The CCTA is responsible for the development of SSADM.

• Introduction

This icon highlights issues which need to be considered by project managers when planning and controlling SSADM projects.

For a successful SSADM project, YOU MUST TAILOR SSADM TO YOUR PROJECT'S CIRCUMSTANCES. If the Method is used without tailoring, the required system will - at best - take longer and cost more to deliver than is necessary. At worst, the project will be terminated and your career in project management curtailed.

• Key Components

Whatever tailoring decisions are taken on individual projects, there are two critical products which the Project Manager must ensure are produced to a high quality. They are:

• Required System Logical Data Model
• Function Definitions.

The Logical Data Model is probably the key component of the entire SSADM development process. It not only drives the design of the eventual database but all processing is specified with reference to it. A data model produced to poor quality standards will undermine the specification, design and construction of the entire system.

Function Definitions identify the system processing which must be implemented and how this processing should be packaged to provide effective support for Users. Depending on the tailoring decisions taken, Function Definitions do not have to be specified in as much detail as recommended by SSADM. However the Functions are specified, the key point is that they must be specified in sufficient detail to enable the Users to verify the processing requirements of the proposed system and to confirm that the scope of each function is consistent with Users' job responsibilities.

• GUI Systems

Project Managers must decide:

• the point at which the GUI is designed
• the extent to which the GUI design is documented.

SSADM's default structural model has GUI design as part of Stage 3 (Definition of Requirements), the intention being that GUI Design can help in identifying and confirming user requirements. However, an equally valid apporach is to leave GUI Design until either Stages 5 (Logical Design) or 6 (Physical Design).

By including GUI Design in Stage 3, there is a serious risk of overloading this stage in terms of:

• long timescales
• the size of team required
• the amount of user resource required. (Effective GUI development requires very high levels of interaction with end-users.)

If there are no significant advantages FOR YOUR PROJECT in designing the GUI during Stage 3, it is recommended that this activity be postponed to later stages.

The extent to which the GUI design is documented will vary depending on the particular components of the GUI. In some cases, it may be that a hand-drawn sketch of a window proves an adequate design specification. However, more complex windows will require an actual bitmap of the proposed window with a detailed specification of the processing inherent in the window.

Project Managers must produce a detailed plan (including quality plan) for GUI Design to ensure that each component of the GUI is documented to an appropriate level of detail. Appropriate documentation will ensure that each GUI component can subsequently be built and maintained in a controlled manner. Otherwise, the risk is that the designers will actually build the GUI without an adequate design which will undoubtedly lead to problems during system integration, testing and maintenance.

• Client/Server Applications

For client/server developments, Stage 6 (Physical Design) provides no practical advice on mapping logical design components to the physical components which must be implemented on the clients and servers. Project Managers need to consider the default activities in Stage 6 to ensure that that they result in a physical design which will satisfy all functional and non-functional requirements.

Deciding the mapping between logical design and physical design components should begin once it has been decided which logical design components are to be specified. For a new development environment, Project Managers should consider building a limited, throwaway prototype system with the sole purpose of validating the proposed mapping between the logical and physical design components. To postpone all physical design decisions until Stage 6 introduces a significant element of risk to the project.

• Relational Database Management Systems

For systems being implemented using a Relational Database Management System, SSADM update and enquiry process models provide a very poor specification for programmers. The concepts underlying the structure of the process models are not directly relevant to implementation of SQL-like statements to access and maintain relational databases. Consequently, programmers have to "unravel" the standard SSADM process models in order to identify the database tables to be accessed, the data to be accessed and the conditions governing the accesses. For RDBMS developments, Project Managers should consider the use of design specifications which can be more readily understood and implemented by programmers, eg textual pseudo code.

• User Involvement

SSADM does not result in products which User Representatives can readily understand and review. The different models which result from the Method may be meaningful and appropriate for the analysts, designers and programmers on a team, but they will not be viewed so favourably by User Representatives.

Project Managers must implement appropriate review procedures to ensure effective User participation and commitment. Merely sending SSADM models to Users and asking for their comments will prove very ineffective. At all times, the emphasis should be on presentations by the project team to ensure that the User Representatives are aware of the issues which must be validated and agreed by them.

For planning purposes, Project Managers must recognise that review points add significantly to the overall development timescales. The time allowed for reviews must be sufficient to enable:

• those concerned to review the products in question;
• a meeting/procedure for agreeing changes to the products;
• the authors of the products to make the necessary changes;
• confirmation that the necessary changes have been made.

• Planning for Implementation

The structural model for SSADM contains no specific activities relating to implementation of the system. This can result in all implementation issues being ignored until very late in the development process, with the result that system implementation is largely unplanned, poorly coordinated and badly managed. Project Managers should ensure that implementation issues are addressed as early as possible - the default structural model leaves all mention of implementation activities until Stage 6 (Physical Design). Consideration of implementation issues can start once the Requirements Specification has been agreed and can parallel the SSADM Design Stages. Particular issues which need to be addressed include:

• Acceptance Test Planning:
  • Define Acceptance Criteria
  • Produce an Acceptance Test Plan
  • Produce Acceptance Test Scripts

• Implementation Planning:
  • Produce an Implementation Plan
  • Produce a Data Conversion Plan
  • Produce a Service Level Agreement
  • Produce an Application User Guide

• Training Planning:
  • Produce a Training Plan
  • Develop Training Materials

• Overworking the Models

At all stages in the Method, the Project Manager should ensure that the team is making real progress and not merely refining the SSADM models to achieve some mistaken aesthetic or "text book" perfection. Such situations can arise with inexperienced SSADM analysts/designers who fail to recognise when a Model has achieved its purpose and that it is more productive to move on. The Project Manager should remind the team at all stages that once a Model is in a relatively stable state and provides a sound platform for the next activity, it has served its purpose and it is time to start on the next activity.

The SSADM process has been captured in Process Engineer by Sandhill Consultants Ltd.

The SSADM structural model has been derived from the default model for SSADM4+ and amended as follows:

• to reflect the GUI activities as outlined in the publication "SSADM and GUI Design: A Project Manager's Guide", ISE Library, HMSO, 1994. ISBN 011 330650.
• to include the planning step from SSADM Version 4, namely Step 110 (Establish Analysis Framework).

The tailoring advice provided is based on extensive, practical experience of working on, managing and advising SSADM projects in a whole range of environments. If you would like more detailed advice on specific issues or have comments to make on this template, please contact Walter Acuti at:

Sandhill Consultants Ltd
St John's Court
Brewery Hill
Grantham
Lincolnshire
NG31 6DW

Tel No: +44 (0) 1476 568708
Fax No: +44 (0) 1476 568620
Email: walter.acuti@sandhill.co.uk

Web site: www.sandhill.co.uk