What SQA Resource are you searching for?

Design Review

• Posted by author on December 31st, 2008 filed in SQA - Auditing
• Comment now »

ARCHITECTURE -PRELIMINARY DESIGN AUDIT The documents required are:
* Preliminary Design Document
* Requirements Document
* Change proposals
* User Manual
* Preliminary acceptance test plan
* Integration plan
* Standards
* Analysis
* Hierarchical decomposition of software
* Plans for manuals and documentation
* Preliminary Design Review Checklist
* Are computer languages defined?
* Is database (external database and internal tables) defined? Is it defined according to the standard?
* Is the functional role of each table described?
* Is the structure of each table clearly described?
* Does the description include pictorial representation?
* Does the description of each item in the table include field’s name, size, location, contents, level, and purpose?
* Is the scope of each table defined?
* Is there a list of modules that may change a table?
* Is there a list of modules that are using a table?
* Does every item have a source?
* Is the usage of every item unambiguous?
* Is the depth of the design appropriate?
* The depth of the design must be deeper than the decomposition depth of the requirements.
* Does each module description comply with the standard?
* A module description must include at least:
o NAME.
o FUNCTION.
o PARAMETER LIST (INPUT, OUTPUT, INPUT/OUTPUT).
o EXTERNAL EFFECT (such as printing, device handling).
o ERROR HANDLING.
o Has the decision criteria for the functioning of each module been given, whether system status, operational mode, or computes?
o Can the module be tested as designed?
o Are all conditions of system’s status that call for a module response described?
* Is binding among the modules according to good design practices:

The ’strength’ of the module must be maximized. That is the relationship among the sub-parts of the module must be such that they perform only one clearly defined function.

The ‘coupling’ of the modules should be minimized – the data relationships among the modules have to be by passing data as parameters and as elements of data and not as data structure.

The MYERS terminology for strength and coupling:

STRENGTH (weak to strong): Co-incidental, logical, classical (termination, initialization), procedural, communicational, functional. COUPLING (strong to weak): Content, common, external, control, stamp, data.
* Is the control structure well defined?
* Reactions to faults in equipment.
* Reactions to faulty input.
* Prevention of SYSTEM DEADLOCK.
* Exit from infinite loop and unexpected wait.
* Protection mechanism for table and resources.
* Memory load. Is there sufficient reserve?
* Other resources load. Is there sufficient reserve?

Observe: Two kinds of reserves must be allocated:

1. Reserve-1 needed to cope with erroneous design estimates and
2. Reserve-2 needed for possible addition of functions in future.

* Are any additional tools necessary?
* Were any additional constraints discovered?
* Were the mathematical algorithms checked?
* Check interface from both ends – the receiving unit and the sending unit for compatibility of definition.
* External interface.
* Interface among modules.
* Check definition of data items transferred: (units, range, format, scale, resolution, rate of transmission, most significant bit, defaults, meaning of discrete values, validity checks, accuracy, quantity)
* Is the communication code (ASCII, EBCIDIC) compatible?
* Is there notification of interface failure?
* Are there provisions for rerouting data in case of failure?
* Check timing requirements. Check volume of data.
* Have overload facilities been built in?
* Check data traffic on links for loading and timing.
* Are input/output rates and the speed of device adequate?
* Are devices suitably buffered?
* Has timing of recovery procedures been considered?
* Is there a requirement for additional processor time?
* What confidence is there in the timing data?

Check degradation and recovery procedures:

* How will system tolerate operator error?
* How will system prevent hardware or software errors to cause loss of data?
* Are there facilities for recording system’s state in the event of failure?
* Have acceptable degraded facilities been defined?
* Is ‘power up’ state considered?
* Is automatic reporting of failures adequately catered?
* Are there checkpoints (check sums) in software?
* Is software informing users that system has recovered?
* Is the operation sequence clearly defined?
* Check queuing scheduling and interrupts.
* Is interrupt handling compatible with the required operation sequence?
* Is scheduling algorithm dynamic? Are there facilities to alter the parameters?
* Do scheduling routines cater to degraded system?
* Can queuing be monitored (especially during system build up)?
* What was done to increase reliability?
* Were ready-made packages used? Was any check made to assure their compatibility?
* Check conformance of operating system to design.
* Is the operating system adequately documented?
* Does it provide all the services needed?
* Does it have features not required? Can they be removed to increase efficiency?
* Does it have task scheduling services, priority controls, I/O services?
* How much system overhead can be allowed?
* Were all changes incorporated in the design?
* Are planned manuals adequate?
* Are future extensions considered?
* Increase number of external lines.
* Build up of data flow greater than specified.
* Extended storage.
* Extended records.
* Extra processes acting on data.
* Is there a complete listing of symbols and definitions?

4.3 DETAILED DESIGN AUDIT top

(1) Necessary documents

* Detailed Design document
* Updated documents for
* Development Plan
* Test Plan
* Requirements
* Analysis

(2) Detailed Design Review Checklist The checklist of the Preliminary Design is also applicable to the Detailed Design. In addition check the following:

* Is the design compatible with the principle of ’structured programming’?
* Is the ‘Design Language Unit’ (a symbol of flowchart, a statement in PDL or UML) small enough to enable direct coding?
* Was there any consideration given to exception condition like – division by zero, difference between the value as expressed in binary form and the true exact value?
* Is methodology clear and utilized?
* Is design of sufficient detail to allow coding?
* Are there adequate margins for min/max data values?
* Are all referenced data items – declared?
* Are data items used only after they have received a value?
* Are all declared data items used?
* Is there un-executable code?
* Are there endless loops?
* Does module logic flow from top to bottom?
* Is indentation used correctly?
* Does this module determine the values of all inputs to modules it calls?
* Does this module use all outputs returned by the module it calls?

4.4 Implementation Review – INSPECTION top

4.4.1 DATA REFERENCE CHECKLIST

* Unset variables used?
* Subscripts within bounds?
* Noninteger subscripts legal?
* Dangling reference (reference to un-allocated storage)?
* Correct attribute when using alias?
* Record and structure attribute match?
* Structure definitions match across procedures?
* String limit exceeded?
* Off by one errors in indexing or subscripts?

4.4.2 DATA DECLARATIONS CHECKLIST

* All variables declared?
* Default attributes understood?
* Arrays and strings properly initialized?
* Correct length, types, and storage classes assigned?
* Initialization consistent with storage class?
* Any variables with similar names?

4.4.3 COMPUTATION CHECKLIST

* Computation on nonarithmetic variables?
* Computation on variables of different length?
* Illegal mixed mode arithmetic?
* Target size less than size of assigned value?
* Intermediate result overflow or underflow?
* Division by zero?
* Base-2 inaccuracies of floating value?
* Variable value outside of meaningful range?
* Operator precedence understood?
* Integer division correct?

4.4.4 COMPARISON CHECKLIST

* Comparison between inconsistent variables?
* Mixed mode comparison?
* Comparison relationship correct?
* Boolean expressions correct?
* Comparison of base-2 fractional values?
* Operator precedence understood?
* Compiler evaluation of boolean expressions understood?

4.4.5 CONTROL FLOW CHECKLIST

* Multiple branches (case range) exceeded?
* Endless loops?
* Will program terminate?
* Correct loop bypasses because of entry conditions?
* Loops fall-throughs correct?
* Off-by-one iteration errors?
* DO/END statements match?
* Any non-exhaustive decisions based upon assumptions concerning the possible values a variable may have?
* Misuse of nested IF statements?
* Undefined combinations of flags?

4.4.6 INTERFACE CHECKLIST

* Parameters and argument match as to:
* Number.
* Attributes.
* Units.
* Order.
* Any references to parameters not associated with current point of entry?
* Input-only arguments altered?
* Are global variable definitions consistent across modules?
* Constants passed as arguments?
* Returned error code checked?

4.4.7 INPUT/OUTPUT CHECKLIST

* File attributes correct?
* OPEN statements correct?
* Format specification match I/O statement?
* Buffer size matches record size?
* Files opened before use?
* End-of-file conditions handled?
* I/O errors handled?
* Any textual errors in output information?

4.4.8 OTHER CHECKS

* Is there a concept that can easily be expressed in plain language?
* Does the function in this part have a clear place in the overall function?
* Can the routine perform properly despite misuse?

FORM

* Is the style clean and clear?
* Is it meaningful to all class of readers?
* Are there repeated code segments?
* Are comments useful?
* Is the level of detail consistent?
* Are standard practices used?
* Is there proper initialization?
* Does the routine clean up after itself?

ECONOMY

* Unnecessary redundant operations?
* Is storage used consistently?
* How much will it cost to modify? (Consider the three most likely future modifications.)
* Is it simple?

4.5. FORMAL QUALIFICATION AUDIT top

A judge is a law student who marks his own examination papers. – H L Mencken

The FQA is used to approve the final product. It is therefore not necessary to review the product with respect to content, this is supposed to be done during the development by internal walk-through, and periodic reviews and testing.

The FQA is mainly a formal check of the contract implementation and other requirements.

* Do all representations of the software represent the same software: Does the object correspond to source, are the tape formats, labels and checksums correct? In short, there must be a physical configuration audit.
* Were all acceptance test executed and are results acceptable?
* Have walk-throughs been executed regularly?
* Is the identification complete and compliance with the configuration management plan?
* Is documentation of the appropriate quality?
* Have all deliverable items been delivered as required?