| |
This SSADM Version 4.2 Quality Control Guide, which is one of the four volumes of
SSADM V4.2 Practitioner Manuals, lists out the quality control requirements to be applied to all major
SSADM products.
This document provides hints to project teams, especially project managers and product
reviewers, to check SSADM deliverables for accuracy, consistency and relevance. It covers the SSADM
deliverables as described in the SSADM Version 4.2 Documentation Standards.
The document provides guidance as "how good the output should be" within SSADM.
For ease of reference, the Quality Control checklists of some major products are extracted
as below.
Entity Access Matrix
Check that :
There is at least one create event for each entity. All events have effects on at least one entity. All entities have been accessed by at least one event or enquiry The effects are C (Create), M (Modify), D (Delete), R (Read) or null. Other values should be explained
in detail. Consistency with other products
Event & Enquiry Catalogue
Check that :
All Event/Enquiry identifiers are unique. The description can describe the event/enquiry and explain the jargons, if any. Consistency with other products
Every data flow that is an input to a process that updates a system data store on the Data Flow Diagrams
(DFDs) should have at least one corresponding event in the Event and Enquiry Catalogue. Time triggered processes in the Required System DFDs should have a corresponding event in
the Event and Enquiry Catalogue. Each enquiry identified from Requirements Catalogue has an entry in the list. All events and enquiries should be referred in the Function Definition.
Required System Data Flow Diagrams
Check that :
The variant identifier is correctly stated as Required System. The DFDs are in appropriate level of details for identification of required functions. Every data flow is named unless it is too obvious as those to/from data stores. Only net data flow needs to be shown, i.e. output from elementary process to data store already implied
read operation. Every process has a unique identifier and a process name. Lowest level processes are marked with an asterisk at the right bottom corner. Update processes are included and the names should reflect the transformation of input data flows
to output data flows. Enquiry processes are excluded unless they are major activities of the system. The decomposition of external entities and data stores in lower level DFDs uses the correct naming
convention. Local data stores must be used only within the process that owns them. There is no manual data store which is named with prefix "M". There is no physical location marked in the process boxes. Every external entity has a unique name, replicas are marked with a
slash at top left hand corner. Every data store has a unique identifier and name, replicas are
marked with a double bar at left hand side. For each higher-level process each data flow connected to data stores, external entities and other
processes must be carried down into lower levels. All data stores must have incoming data flows. All processes must have outgoing data flows. Consistency with other products
All data stores have an entry in the Logical Data Store/Entity Cross Reference and mapped to
one or many entities in the LDS. For FS projects, each lowest level process on the Required System DFDs should have a corresponding
entry in the Function List. For SA&D projects, each lowest level process on the Required System DFDs should have a
corresponding entry in the Function Definition.
Required System Entity Description
Check that :
The variant identifier is correctly stated as Required System. The description in Part I can describe the entity and explain
the jargons, if any. All volumetric information are reasonable (e.g. a one-to-one optional detail relationship must
have the number of entity occurrence in master entity greater than that of the detail entity). For FS projects, the entity names in Part I and Part II are consistent. For SA&D projects,
the entity names in Part I, Part II and III are consistent All data items of an entity are defined in the Entity Description Part II. All entities have a primary key. Synonyms are identified (not treated as two different items). Each data item has a unique name which is a singular noun. Mandatory data items are identified. For SA&D projects, all foreign keys are identified and marked in the Entity Description Part III
(Entity Key Description). For SA&D projects, all entities are in Third Normal Form (3NF). Consistency with other products
Every entity in the LDS is described in the Required System Entity Description (both Part I & II). For SA&D projects, all the relationships among data entities defined in LDS are supported by
foreign keys in Entity Description Part III.
Required System Logical Data Structure
Check that :
Every entity has a unique name, which is a singular noun. For SA&D projects, many-to-many relationships are resolved using link entities, and link
entities have meaningful names. For SA&D projects, entities with one-to-one mandatory relationships should be combined. Stand-alone entities are examined carefully to make sure that they
are really required. Where two entities are linked by more than one relationship, all these relationships are named. Correct optionalities are identified using dotted lines and solid lines Correct degrees of relationships are marked. For SA&D projects, redundant relationships are retained only when different entity occurrences
of the detail entity are accessed by different access path. For SA&D projects, any double 'V' structures (two detail entities are having the same two master
entities) are resolved by either merging the two detail entities or inserting some missing entities. All relationships which are ended in the same group of exclusion have the same optionalities. Exclusive arcs are not marked at one single relationship lines, but for a group of two or more
relationshiplines. Exclusive arcs are given a unique identifier if there are more than one group of exclusion of the LDS. Consistency with other products
All entities should be mapped to a data store of the Required System DFD and documented in the
Required System Logical Data Store/Entity Cross Reference. All entities in the LDS are described in the Required System Entity Description. For SA&D projects, all relationships among data entities are supported by the foreign keys
defined in the Required System Entity Description Part III.
For further information, you are welcome to contact us through
email enquiry@ogcio.gov.hk .
|
|