Structured Systems Analysis and Design Method

From Wikipedia, the free encyclopedia

This article may require cleanup to meet Wikipedia's quality standards.
Please discuss this issue on the talk page or replace this tag with a more specific message.
This article has been tagged since January 2007.

Structured Systems Analysis and Design Method (SSADM) is a systems approach to the analysis and design of information systems. SSADM was produced for the CCTA, a UK government office concerned with the use of technology in government, from 1980 onwards. The names "Structured Systems Analysis and Design Method" and "SSADM" are now Registered Trade Marks of the Office of Government Commerce (OGC), which is an Office of the United Kingdom's Treasury.

Introduction System design methods are a discipline within the software development industry which seek to provide a framework for activity and the capture, storage, transformation and dissemination of information so as to enable the economic development of computer systems that are fit for purpose.

SSADM is a waterfall method by which an Information System design can be arrived at; SSADM can be thought to represent a pinnacle of the rigorous document-led approach to system design, and contrasts with more contemporary Rapid Application Development methods such as DSDM.

SSADM is one particular implementation and builds on the work of different schools of development methods, some of the key members of which included:

Literature:

Contents

[edit] Stages

The SSADM method involves the application of a sequence of analysis, documentation and design tasks concerned with:

[edit] Analysis of the current system

Also known as: feasibility stage. Analyze the current situation at a high level. A DFD (Data Flow Diagram) is used to describe how the current system works and to visualize known problems.
The following steps are part of this stage:
  • Develop a Business Activity Model. A model of the business activity is built. Business events and business rules would also be investigated as an input to the specification of the new automated system.
  • Investigate and define requirements. The objective of this step is to identify the problems associated with the current environment that are to be resolved by the new system. It also aims to identify the additional services to be provided by the new system and users of the new system.
  • Investigate current processing. It investigates the information flow associated with the services currently provided, and describes them in the form of Data Flow Model. At this point, the Data Flow Model represents the current services with all their deficiencies. No attempt is made to incorporate required improvement, or new facilities.
  • Investigate current data. This step is to identify and describe the structure of the system data, independently of the way the data are currently held and organized. It produces a model of data that supports the current services.
  • Derive logical view of current services. The objective of this step is to develop a logical view of the current system that can be used to understand problems with the current system.

[edit] Outline business specification

Also known as: logical system specification stage. This stage consists of 2 parts. The first part is researching the existing environment. In this part, system requirements are identified and the current business environment is modelled. Modelling consists of creating a DFD and LDS (Logical Data Structure) for processes and data structures that are part of the system. In the second part, BSO (Business Systems Options), 6 business options are presented. One of the options is selected and built.
The following steps are part of this stage:
  • Define BSOs. This step is concerned with identifying a number of possible system solutions that meet the defined requirements from which the users can select.
  • Select BSO. This step is concerned with the presentation of the BSOs to users and the selection of the preferred option. The selected option defines the boundary of the system to be developed in the subsequent stages.

[edit] Detailed business specification

Also known as: requirements specification stage. To assist the management to make a sound choice, a number of business system options, each describing the scope and functionalities provided by a particular development/implementation approach, are prepared and presented to them. These options may be supported by technical documentation such as Work Practice Model, LDM (Logical Data Model) and DFD. They also require financial and risk assessments to be prepared, and need to be supported by outline implementation descriptions.
The following steps are part of this stage:
  • Define required system processing. This step is to amend the requirements to reflect the selected Business System Option, to describe the required system in terms of system data flows and to define the user roles within the new system.
  • Develop required data model. This step is undertaken in parallel with the above step. The LDM of the current environment is extended to support all the processing in the selected business system option.
  • Derive system functions. During the parallel definition of data and processing, additional events are identified, which cause existing functions to be updated, and new functions to be defined. Service level requirements for each function are also identified in this step.
  • Develop user job specifications. A Work Practice Model is developed to document the understanding of the user jobs in concern.
  • Enhance required data model. Its objective is to improve the quality of the required system LDM by the application of relational data analysis (also known as normalization).
  • Develop specification prototypes. It is used to describe selected parts of the required system in an animated form, for demonstration to the users. The purpose is to demonstrate that the requirements have been properly understood and to establish additional requirements concerning the style of the user interface.
  • Develop processing specification. This step is principally concerned with defining the detailed update and enquiry processing for the required system.
  • Confirm system objectives. During stage 1 and 3, the requirements will have been recorded, as they are identified, in the user requirements. This step represents the final review of the requirements before the completion of the Definition of Requirements Stage.

[edit] Logical data design

Also known as: logical system specification stage. In this stage, technically feasible options are chosen. The development/implementation environments are specified based on this choice.
The following steps are part of this stage:
  • Define BSOs (Business Systems Options). Its purpose is to identify and define the possible approaches to the physical implementation to meet the function definitions. It also validates the service level requirements for the proposed system in the light of the technical environment.
  • Select BSO. This step is concerned with the presentation of the BSOs to users and the selection of the preferred option.

[edit] Logical process design

Also known as: logical system specification stage. In this stage, logical designs and processes are updated. Additionally, the dialogs are specified as well.
The following steps are part of this stage:
  • Define user dialogue. This step defines the structure of each dialogue required to support the on-line functions and identifies the navigation requirements, both within the dialogue and between dialogues.
  • Define update processes. This is to complete the specification of the database updating required for each event and to define the error handling for each event.
  • Define enquiry processes. This is to complete the specification of the database enquiry processing and to define the error handling for each enquiry.

[edit] Physical design

The objective of this stage is to specify the physical data and process design, using the language and features of the chosen physical environment and incorporating installation standards.
The following activities are part of this stage:
  • Prepare for physical design.
  • learn the rules of the implementation environment;
  • review the precise requirements for logical to physical mapping; and
  • plan the approach.
  • Complete the specification of functions.
  • Incrementally and repeatedly develop the data and process designs.

[edit] Techniques

The 3 most important techniques that are used in SSADM are:

  • Logical Data Modelling. This is the process of identifying, modelling and documenting the data requirements of the system being designed. The data are separated into entities (things about which a business needs to record information) and relationships (the associations between the entities).
  • Data Flow Modelling. This is the process of identifying, modelling and documenting how data moves around an information system. Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for data), external entities (what sends data into a system or receives data from a system), and data flows (routes by which data can flow).
  • Entity Behaviour Modelling. This is the process of identifying, modelling and documenting the events that affect each entity and the sequence in which these events occur.

[edit] History

  • 1980 Central Computer and Telecommunications Agency (CCTA) evaluate analysis and design methods.
  • 1981 LBMS method chosen from shortlist of five.
  • 1983 SSADM made mandatory for all new information system developments
  • 1984 Version 2 of SSADM released
  • 1986 Version 3 of SSADM released, adopted by NCC
  • 1988 SSADM Certificate of Proficiency launched, SSADM promoted as ‘open’ standard
  • 1989 Moves towards Euromethod, launch of CASE products certification scheme
  • 1990 Version 4 launched
  • 1993 SSADM V4 Standard and Tools Conformance Scheme Launched
  • 1995 SSADM V4+ announced poon, V4.2 launched

[edit] References

  1. ^ W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.

[edit] See also

  • Kaur Methodology

[edit] External links

Retrieved from "http://en.wikipedia.org../../../s/t/r/Structured_Systems_Analysis_and_Design_Method_b6d6.html"
In other languages