QA Plan

Release Information

Project:	EGADSS
Internal Release Number:	$Revision: 1.9 $
Release Audience:	Developer release
Attached Worksheets:
Related Documents:	SRS Design

Introduction

"Quality" refers to all the good things that we would like to see in the EGADSS product. In particular, we adopt the standardized quality factor description according to ISO 9126, in which quality is defined in regard to the following factors:

    1.     Functionality - suitability, accuracy, interoperability, security, compliance, completeness
    2.     Reliability - maturity, fault tolerance, recoverability compliance
    3.     Usability - understandability, learnability, operability, attractiveness, compliance
    4.     Efficiency - time behavior, resource utilization, compliance
    5.     Maintainability - analyzability, changeability, stability, testability, compliance
    6.     Portability - adaptability, installability, co-existence, replaceability, compliance

The above terminology is used throughout this document and determines its structure. The EGADSS project plan schedules five mile stone releases. Each of these releases will include different, respectively revised versions of work products that must comply with different quality goals. An overview on the scheduled release plan, the work products to be produced and the quality goals to be achieved are given below. The next sections will define mechanisms used to assure the quality goals. Detailed description of the planned functionality for the construction and deployment phases can be found in the Construction Planning document.

Project phase	Schedule	Deliverables / Quality objectives
Elaboration	Jan 1- March 31, 2005	"Paperchild" release Specification Requirements Should be functionally complete, suitabile, easy to understand and should cover the security aspect Design Should give an accurate structural and behavioural description of the component-level architecture including all interfaces Should specify what implementation platforms should be used and why Implementation Rapid prototype implementation of all major components for a particular test case (tetanus immunization)
Construction I	April 1- June 31, 2005	"Strawman" release Specification Requirements Should be revised for accuracy Should be compliant to ISO/IEEE documentation standards Design Specification of ARDEN compiler rules Implementation Functionality see construction planning document Maintainability: Testability, understandability
Construction II	July 1- September 30, 2005	"Woodwoman" release Specification Design Should give an accurate structural and behavioural description of the component-level and class-level architecture Design should comply to ISO/IEEE documentation standards Mission-critical parts of the specification should be formal Implementation Functionality see construction planning document Maintainability: Knowledge-base configuration management implemented Efficiency Measurements, STP annotations in UML, design refactoring for performance optimization
Construction III	October 1 - December 31, 2005	"Ironcat" release Specification All parts of the specification should comply to ISO/IEEE documentation standards Compliance with implementation Implementation Reliability: correctness, fault tolerance, recoverable, maturity Implementation of additional Preventive care guidelines Preliminary integration with TAPAS
Deployment	January 1 - March 31, 2006	"Diamonddog" release Specification User documentation Should be complete and understandable Implementation integration with TAPAS\|ems and documentation of integration process to work with other EMRs, deployability

Quality assurance for strawman release

Quality goal	Assurance techniques
Requirements spec should be functionally complete, suitabile, easy to understand and should cover the security aspect Design spec Should give an accurate structural and behavioural description of the component-level architecture including all interfaces Should specify what implementation platforms should be used and why	Multiple rounds of requirements review cycles involving all team members. Prototypical implementation of skeleton architecture to test interface design with a sample scenario (immunization guideline in preventive care) Formal decision and evaluation matrix for pivotal platform decisions
Design spec Should give an accurate structural and behavioural description of the component-level architecture	Comparison against component interface implementation and execution traces Design review by entire team
Implementation Rapid prototype implementation of all major components for a particular test case (tetanus immunization)	Sample scenario with fictitious patient and tetanus immunization guideline. System must produce the right recommendation.

Quality goal

Assurance techniques

Requirements spec should be functionally complete, suitabile, easy to understand and should cover the security aspect

Design spec

Should give an accurate structural and behavioural description
of the component-level architecture including all interfaces
Should specify what implementation platforms should be used and why

Multiple rounds of requirements review cycles involving all team members.

Prototypical implementation of skeleton architecture to test interface design with a sample scenario (immunization guideline in preventive care)
Formal decision and evaluation matrix for pivotal platform decisions

Design spec

Should give an accurate structural and behavioural description of the component-level architecture

Comparison against component interface implementation and execution traces
Design review by entire team

Implementation

Rapid prototype implementation of all major components for a particular test case (tetanus immunization)

Sample scenario with fictitious patient and tetanus immunization guideline. System must produce the right recommendation.

Quality assurance for woodwoman release

Quality goal	Assurance techniques
Specification Should be revised for accuracy Should be compliant to ISO/IEEE documentation standards Specification of ARDEN compiler rules	Test whether all use cases can be traced to implementation functions Accuracy with class-level implementation tested by reverse engineering of reference model Comparison to ISO/IEEE documentation standards and best practices as documented in software engineeting literature Use of formal reasoning techniques to prove critical properties (such as TLA+) Specification of ARDEN compiler rules formalized and tested in PROGRES
Implementation Functionality Automatic generation of Expert-System Schema (COOL) based on W3C Document schema Automatic population of Expert-System Schema based on incoming CDA document (DocImpEx) Automatic generation of recommendation document based on resulting facts (DocImpEx) (Limited) ARDEN compiler Full auditing system Implementation of additional Immunization test guidelines Maintainability: Testability, understandability	Use core data set and recommendation document W3C schemas to test COOL schema generation Use core data set documents to test COOL schema population Implement three example guidelines in CLIPS to test recommendation document generation Test ARDEN compiler with three Immunization guidelines Formal code and design review meetings Unit test harnesses with representative test cases for all components (JUnit) Use of "Design-by-contract" paradigm of specifying pre-conditions, post-conditions and class invariants for all implementation classes, using Java assertions. For implementation of invariants, each class will have a method "invariant_check", in each pre- and post-condition of each method.

Quality goal

Assurance techniques

Specification

Should be revised for accuracy
Should be compliant to ISO/IEEE documentation standards

Specification of ARDEN compiler rules

Test whether all use cases can be traced to implementation functions
Accuracy with class-level implementation tested by reverse engineering of reference model
Comparison to ISO/IEEE documentation standards and best practices as documented in software engineeting literature
Use of formal reasoning techniques to prove critical properties (such as TLA+)
Specification of ARDEN compiler rules formalized and tested in PROGRES

Implementation

Functionality

Automatic generation of Expert-System Schema (COOL) based on W3C Document schema

Automatic population of Expert-System Schema based on incoming CDA document (DocImpEx)

Automatic generation of recommendation document based on resulting facts (DocImpEx)
(Limited) ARDEN compiler
Full auditing system
Implementation of additional Immunization test guidelines

Maintainability:

Testability, understandability

Use core data set and recommendation document W3C schemas to test COOL schema generation
Use core data set documents to test COOL schema population
Implement three example guidelines in CLIPS to test recommendation document generation
Test ARDEN compiler with three Immunization guidelines
Formal code and design review meetings
Unit test harnesses with representative test cases for all components (JUnit)
Use of "Design-by-contract" paradigm of specifying pre-conditions, post-conditions and class invariants for all implementation classes, using Java assertions. For implementation of invariants, each class will have a method "invariant_check", in each pre- and post-condition of each method.

Quality assurance for ironcat release

Quality goal	Assurance techniques
Specification All parts of the specification should comply to ISO/IEEE documentation standards Compliance with implementation	Accuracy with class-level implementation tested by reverse engineering of reference model Comparison to ISO/IEEE documentation standards and best practices as documented in software engineeting literature Documentation audit by ISO/IEEE expert
Implementation Reliability: correctness, fault tolerance, recoverable, maturity	Development and application of systematic reliability test plan Use of "Design-by-contract" paradigm of specifying pre-conditions, post-conditions and class invariants for all implementation classes, using Java assertions. For implementation of invariants, each class will have a method "invariant_check", in each pre- and post-condition of each method. We will monitor the behavior of servers to automatically detect service outages or performance degradation. We have policies and procedures in place for failure notification, escalation, and correction.

Quality goal

Assurance techniques

Specification

All parts of the specification should comply to ISO/IEEE documentation standards
Compliance with implementation

Accuracy with class-level implementation tested by reverse engineering of reference model
Comparison to ISO/IEEE documentation standards and best practices as documented in software engineeting literature
Documentation audit by ISO/IEEE expert

Implementation

Reliability: correctness, fault tolerance, recoverable, maturity

Development and application of systematic reliability test plan
Use of "Design-by-contract" paradigm of specifying pre-conditions, post-conditions and class invariants for all implementation classes, using Java assertions. For implementation of invariants, each class will have a method "invariant_check", in each pre- and post-condition of each method.
We will monitor the behavior of servers to automatically detect service outages or performance degradation. We have policies and procedures in place for failure notification, escalation, and correction.

Quality assurance for diamondog release

Quality goal	Assurance techniques
Specification User documentation Should be complete and understandable	Reference implementation of EMR agnostic adapter
Implementation Usability, deployability	We want to understand each post-deployment system failure and actively take steps to correct the defect. The system has built-in capabilities for gathering detailed information from each system failure (e.g., error message, stack traceback, operating system version). This information will be transmitted back to us so that we may analyze it and act on it.