Systems Analysis & Design

Quality Control In SSADM In order understand how quality control operates in SSADM we must first define what we mean by quality: Quality - A measure applied to all SSADM products to show that they are fit for the required purpose. Every product is classified according to standard criteria, if the product meets these criteria, it may be accepted as part of the project documentation. Quality criteria - prescribed characteristics of a given product, these characteristics are specified before production begins. Quality is embedded in SSADM in what are known as quality products:
Q u a lity P r o d u c ts

P ro d u c t D e s c rip tio n s

In v i ta tio n s to q u a lity r e v ie w

Q u a li ty re v ie w re s u lts

T e c h n ic a l e x c e p ti o n s

P ro je c t Is s u e R e p o rt

O ff s p e c ifi c a tio n re p o rt

R equest fo r c h a n g e

Product Descriptions Each product should be described in the following terms: Title: A simple identifier, which is accessible to non-technical people as well as to technical specialists. Purpose: A brief statement of what the purpose of the product is, e.g. to communicate the analyst's understanding to the user, or to show the layout of a screen used in a dialogue. Composition: A list and description of all the component parts of the product. If it is a report, or form-based, a design for the form should be included, showing project header information, version numbers and release dates for Configuration Management purposes, and space for every item of information required. The SSADM Reference Manual (CCTA, 1990) provides suggested layouts for forms, but actual forms design is a matter for local standards. Derivation: A statement of where the information in the product was derived, e.g. from discussion with users, Current physical DFD etc. Quality: The specific quality criteria the product must match before it is acceptable. Before any activity begins, the team must know what level of quality it is to meet. This might be at the level of asking if every box on a form is completed, or of
qual.doc

CMSCS201

Systems Analysis & Design checking the accuracy of data flows on a DFD, or of specifying the cross-checks between two techniques or products. Again precise criteria are tailorable for each project; the important thing is that they are set before the activity which produces it, is started. Quality Assurance - is the system for setting standards and procedures for quality control and ensuring that these are applied. We can now define quality control. Quality Control - QC is the evaluation of software components against the predetermined QA criteria and used to identify software elements that have unacceptable quality. These may be carried out by testing, review or inspection. The purpose of these controls is to allow the identification of work units of unacceptable quality sufficiently early in the development process to take corrective action. There are two basic forms of quality control: formal and informal Informal checks have nothing to do with management and are not sufficient to achieve sign-off. They are valuable, however, in helping to ensure that the formal quality assurance (QA) reviews are productive and result in the acceptance of the product.

Formal Quality Assurance Reviews These follow a pattern with participants and procedures that should be standard. The participants are: Presenter - usually the person who has produced whatever is being reviewed. The presenter introduces the product, its scope and description, having distributed copies to all participants well beforehand. Chairperson - ensures that the review is conducted fairly and thoroughly. The Chair may note all the comments & criticisms of the item under review, or there may be a separate scribe to do that. One main responsibility is to see that the review identifies problems and errors, but does not attempt to resolve them. Reviewers - their purpose is to ensure that the items submitted for review are both accurate and complete, certainly up to the level laid down in the product description quality criteria. They will identify errors or weaknesses and accept ownership of them, thus ensuring corrections are made before the item is accepted. Each organisation will have different ways of conducting such reviews (sometimes known as walkthroughs, inspections or Fagan Inspections), and following up the action points, but most will follow the above structure. So what are the typical errors and weaknesses that we look for in reviews? CMSCS201 2

qual.doc

Systems Analysis & Design The quality criteria are supported by rigorous descriptions of both the application of the techniques involved and by the product descriptions of what is to be produced. However, these are aided by cross validation (cross referencing) performed between complementary techniques.

Cross Referencing in SSADM Firstly, we must remember that SSADM utilises three views of a system: User's View System View Effects of Time [DFDs] [Logical Data Structure] [Entity Life History]

The technique of cross-referencing is used to provide tests of completeness and accuracy. Data stores represented on data flows diagrams comprise part of an entity, a complete entity, a number of entities or several parts of complete entities. It is possible to cross-reference the data stores from a set of data flow diagrams with an entity model. If a current physical data store cannot be referenced to one or more entities then either the entity model is incomplete or the physical data is not required within the system. If an entity from the entity model is not cross referenced, then the entity may not be stored in the current system. Errors may have occurred during the construction of either model. The construction of a cross reference can highlight problem areas and serves as an early proof mechanism on the completeness and accuracy of the data flow diagrams and entity model. Dataflow diagrams can act as a check on the Logical Data to ensure that each data item is created & amended at some time. The LDS ensures that the data is present in the system, to allow the processes shown on the DFD to take place. The Entity Life History shows how events impact the data over time and again cross-referencing can be used to ensure that each entity has a complete life. Thus during a review we may discover: A data entity that is not used by any process A process that does not access any of the data entities we have discovered The other types of errors we may discover might be: Incorrect/incomplete/inaccurate use of techniques: e.g. dataflows missed or incorrectly labeled on a DFD, unidentified entities, missing relationships or incorrect relations on the LDS.

qual.doc

CMSCS201