GovHK | Search | Site Map | Contact Us | Home | Content | What's New
Professional Development > Software Development > SSADM V4.2 Quality Control Guide
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 :
o There is at least one create event for each entity.
o All events have effects on at least one entity.
o All entities have been accessed by at least one event or enquiry
o The effects are C (Create), M (Modify), D (Delete), R (Read) or null. Other values should be explained in detail.
o Consistency with other products
o All events and enquiries identified in the Event and Enquiry Catalogue are included.
o All entities identified in the Required System Logical Data Structure are included.
Event & Enquiry Catalogue
Check that :
o All Event/Enquiry identifiers are unique.
o The description can describe the event/enquiry and explain the jargons, if any.
o Consistency with other products
o 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.
o Time triggered processes in the Required System DFDs should have a corresponding event in the Event and Enquiry Catalogue.
o Each enquiry identified from Requirements Catalogue has an entry in the list.
o All events and enquiries should be referred in the Function Definition.
Required System Data Flow Diagrams
Check that :
o The variant identifier is correctly stated as Required System.
o The DFDs are in appropriate level of details for identification of required functions.
o Every data flow is named unless it is too obvious as those to/from data stores.
o Only net data flow needs to be shown, i.e. output from elementary process to data store already implied read operation.
o Every process has a unique identifier and a process name.
o Lowest level processes are marked with an asterisk at the right bottom corner.
o Update processes are included and the names should reflect the transformation of input data flows to output data flows.
o Enquiry processes are excluded unless they are major activities of the system.
o The decomposition of external entities and data stores in lower level DFDs uses the correct naming convention.
o Local data stores must be used only within the process that owns them.
o There is no manual data store which is named with prefix "M".
o There is no physical location marked in the process boxes.
o Every external entity has a unique name, replicas are marked with a slash at top left hand corner.
o Every data store has a unique identifier and name, replicas are marked with a double bar at left hand side.
o For each higher-level process each data flow connected to data stores, external entities and other processes must be carried down into lower levels.
o All data stores must have incoming data flows.
o All processes must have outgoing data flows.
o Consistency with other products
o All data stores have an entry in the Logical Data Store/Entity Cross Reference and mapped to one or many entities in the LDS.
o For FS projects, each lowest level process on the Required System DFDs should have a corresponding entry in the Function List.
o 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 :
o The variant identifier is correctly stated as Required System.
o The description in Part I can describe the entity and explain the jargons, if any.
o 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).
o 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
o All data items of an entity are defined in the Entity Description Part II.
o All entities have a primary key.
o Synonyms are identified (not treated as two different items).
o Each data item has a unique name which is a singular noun.
o Mandatory data items are identified.
o For SA&D projects, all foreign keys are identified and marked in the Entity Description Part III (Entity Key Description).
o For SA&D projects, all entities are in Third Normal Form (3NF).
o Consistency with other products
o Every entity in the LDS is described in the Required System Entity Description (both Part I & II).
o 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 :
o Every entity has a unique name, which is a singular noun.
o For SA&D projects, many-to-many relationships are resolved using link entities, and link entities have meaningful names.
o For SA&D projects, entities with one-to-one mandatory relationships should be combined.
o Stand-alone entities are examined carefully to make sure that they are really required.
o Where two entities are linked by more than one relationship, all these relationships are named.
o Correct optionalities are identified using dotted lines and solid lines
o Correct degrees of relationships are marked.
o For SA&D projects, redundant relationships are retained only when different entity occurrences of the detail entity are accessed by different access path.
o 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.
o All relationships which are ended in the same group of exclusion have the same optionalities.
o Exclusive arcs are not marked at one single relationship lines, but for a group of two or more relationshiplines.
o Exclusive arcs are given a unique identifier if there are more than one group of exclusion of the LDS.
o Consistency with other products
o 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.
o All entities in the LDS are described in the Required System Entity Description.
o 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.
2003 © | Important notices | Privacy Policy | Last review date : 30 September 2009
End of page