SDLC STANDARDS

QUALITY ASSURANCE GUIDELINES

Version 1.1            July 9, 2004

This page contains the published standards for the Ministry's approach to Quality Assurance Guidelines.

Table of Contents

VERSION CONTROL

1. INTRODUCTION
1.1    Purpose
1.2    Audience
1.3    Scope/Exclusions
1.4    Assumptions
1.5    Other Standards
 
2.      THE QUALITY ASSURANCE TEAM
2.1    General
2.2    Applications Architect (AA)
2.3    Application Manager (AM)
2.4    Business Analyst (BA)
2.5    Business Expert
2.6    Data Administration (DA)
2.7    Database Administrator (DBA)
2.8    End Users
2.9    Ministry Project Manager (PM)
2.10  Vendor  

3.     SYSTEM DEVELOPMENT LIFE-CYCLE OVERVIEW

5.     CONCLUSION

FIGURES

Figure 1:        SDLC Phases
Figure 2:        SDLC QA Matrix

APPENDICES

Appendix A:    QA Matrix - Detailed
Appendix B:    Bibliography

VERSION CONTROL

This section of the document records the various versions or releases of this document.

 

Version	Details/Description	Distribution	Date	Author	Organization
0.1	First Draft	Whole Document	June 28, 2001	Dawn Henry	IMB
0.2	Second Draft Deliverable Definitions Updated	Whole Document	Aug. 13, 2001	Dawn Henry	IMB
0.3	Third Draft Updated with changes from BA group	Whole Document	Dec.19, 2001	Dawn Henry	IMB
1.0	Published to the Web and Minor Changes	Whole Document	Dec.19, 2001	Dawn Henry	IMB
1.1	Edits based on Final Report	Whole Document	July 9, 2004	Chris Burd	Catchword Info. Design

 

Table 1: Version Control

[TOC] 1.      INTRODUCTION Project Quality Management is defined as the processes required to ensure that the project will satisfy the needs for which it was undertaken. This quality assurance (QA) processes document describes the processes for conducting quality assurance on the deliverables for application development and maintenance projects in the Ministry. This document does not replace the SDLC documentation but should be used in conjunction with it. 1.1      Purpose This document defines the activities performed to provide assurance that the application deliverables the Ministry receives conform to established Ministry standards. The QA guidelines also describe how the project will be quality assured to ensure that the policies, standards, practices, procedures, and processes applicable to the Ministry's System Development Life-Cycle (SDLC) are followed. 1.2      Audience This document is directed at those who will be producing deliverables as required for designing, developing and maintaining applications for the Ministry. This includes external vendors, consultants, and business partners, as well as Ministry employees. All vendors performing work for the Ministry are expected to follow the quality assurance processes as outlined in this document. This fact should be specified in the RFP and contract. 1.3      Scope/Exclusions These standards focus on corporate applications, but they can also be used for smaller applications, e.g., district or regional applications. In these instances the standards may be used as a guideline to the QA processes, but the QA processes as defined do not apply. The requirements for Government-wide applications are not included in this document. This document intends to ensure that vendors and staff have a clear understanding of the QA processes so they can be used in all Corporate application development and maintenance projects. This document includes detailed QA processes with required timelines and clear delineation of roles and responsibilities for Ministry staff and vendors. 1.4      Assumptions It is assumed that the audience is familiar with the Ministry's System Development Life Cycle (SDLC) Overview. 1.5      Other Standards Other related standards can be found on the Standards page.

[TOC] 2.    THE QUALITY ASSURANCE TEAM 2.1      General Overall coordination of quality assurance is the responsibility of the Ministry Project Manager for most deliverables, except during the Maintenance phase, where this responsibility lies with the Application Manager. All feedback and QA results should be delivered to the originator of the deliverable via this coordinator. The QA coordinator should communicate appropriately with all team members with respect to the QA of deliverables. There are several roles associated with the various QA tasks. Individuals may assume multiple roles during the project, and roles may rotate when appropriate. This section provides a general description of the roles and responsibilities. Please refer to the appropriate section for the specific QA. Several deliverables will require both a Business QA and a Technical QA. Note: The person performing the QA should not be the person who developed the deliverable. 2.2      Application Architect (AA) The Application Architecture Section provides advice on QA applications from a technical perspective. 2.3      Application Manager (AM) The Application Manager is the Ministry person responsible for the overall management of one or more applications. A key quality assurance role is to ensure the QA of an application by leading and conducting the User Acceptance Testing. Where the Application Manager is responsible for overall management of the QA, duties will include the following: •   overall coordination of quality assurance of the specified deliverable; •   ensuring the deliverable is quality assured by the relevant program area staff; •   ensuring that a copy of the deliverable is forwarded to the Information Management BA; •   delivering the QA results to the author via email, phone or meeting. 2.4      Business Analyst (BA) This description applies to the Information Management Branch Business Analyst (IMB BA). For most deliverables the IMB BA will be responsible for managing the technical QA. The QA duties will include the following: •   overall coordination of the technical QA for the deliverable; •   ensuring the deliverable is quality assured by the relevant technical staff (AA, DBA, DA, etc.); •   delivering the QA results to the Ministry Project Manager or Application Manager via email, phone or meeting. Note: For the purposes of this document, Information Management Business Analyst could refer to either the Information Business Analyst or the Information Business Systems Consultant, as assigned to the client or project. 2.5      Business Experts The Business Experts are responsible for the QA of deliverables from a business perspective. 2.6      Data Administration (DA) Data Administration group is responsible for QA of the UML Domain model, CASE Repository and the Logical Data Model. 2.7      Database Administrator (DBA) The Database Administrator is responsible for the QA application code, physical database, application delivery, scripts and process. 2.8 End Users The End User will assist in the QA of specific deliverables from the user's perspective. 2.9      Ministry Project Manager (PM) The Ministry Project Manager is responsible for overall coordination of the QA for all deliverables, except those in the maintenance phase, which are usually managed by the Application Manager. The duties are as follows: • overall coordination of the QA for the deliverable; • ensuring the deliverable is quality assured by the relevant program and staff (from the business perspective); • ensuring that a copy of the deliverable is forwarded to the IMB, BA (for the technical QA); • delivering the QA results to the originator via email, phone or meeting. 2.10     Vendor The contractor is often referred to as the Vendor. The Vendor is responsible for ensuring the deliverable meets the Ministry standards prior to submitting it to the Ministry Project Manager or Application Manager. The Vendor will also review QA results as performed by the Ministry staff and make changes to the deliverable where required.

[TOC] 3.    SYSTEM DEVELOPMENT LIFE CYCLE OVERVIEW The foundation for this QA guideline is the System Development Life Cycle (SDLC). The SDLC consists of seven distinct Phases as shown in Figure 1 below. For more information on these phases see the Systems Development Life Cycle Standard. Figure 1: SDLC Phases

Phase 1	Phase 2	Phase 3	Phase 4	Phase 5	Phase 6	Phase 7
Planning	Definition	Requirements	Design	Build	Implementation	Warehouse

 

Each Phase has one or more individual deliverables associated with it. These deliverables are described in other standards documents. The QA processes for each deliverable are summarized in table format at the beginning of each phase. The complete table is located in Appendix A.

[TOC]
4.      QA OF SYSTEMS DEVELOPMENT LIFE CYCLE DELIVERABLES This section details the QA processes for each deliverable. Project Plans must include the timelines, costs and resources for these processes. Note: Where a time frame of 1 day is indicated, this means that a walkthrough or meeting is to be held for the purpose of performing the QA on that deliverable. Where possible, the deliverable should be supplied in advance. 4.1     QA OF PLANNING PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Project Proposal Ministry Project Manager email, hardcopy Ministry standards, content, format 1 week email, meeting, phone RFP Ministry Project Manager email, hardcopy Ministry standards, technical standards, content, details, omissions 1 week (schedule in advance) email, meeting, phone ITQ Ministry Project Manager email, hardcopy Ministry standards, technical standards, content, details, omissions 2-3 days email, meeting, phone
Project Proposal
The Project Proposal is largely an internal document developed by Ministry staff prior to the enlistment of a vendor. In most cases it is developed by the Application Manager or the Ministry Project Manager. The Project Proposal should be developed ahead of the annual planning process or as needed throughout the year. For more details please refer to the Ministry developed standard for the Project Proposal.
Method of Delivery:	The Project Proposal is distributed via email or hardcopy to the Information Management Business Analyst, for the purpose of being quality assured. The QA results will be delivered to the author of the Project Proposal via email, phone or meeting.
Performing the QA:	The QA of the Project Proposal is performed by:
	—	relevant program area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The Project Proposal will be quality assured for:
	—	conformity to Ministry Standards;
	—	content;
	—	format.
Timeframe:	One week.
[TOC]
Request For Proposal
A Request for Proposal (RFP)is a request to suppliers to submit proposals on how (and at what price) they would provide goods and/or services. Details of the RFP process are in the Ministry RFP Guide and at the Purchasing Commission website.
Method of Delivery:	The RFP is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured. The QA results will be delivered to the author of the RFP via email, phone or meeting.
Performing the QA:	The QA of the RFP is performed by:
	—	relevant program area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The RFP will be quality assured for:
	—	conformity to Ministry Standards;
	—	technical standards;
	—	content;
	—	details;
	—	omissions.
Timeframe:	1 - 2 weeks.
[TOC]
Invitation To Quote
An Invitation to Quote (ITQ) is a written request made to prospective suppliers to quote on goods or services sought by the prospective purchaser. Details of the ITQ process are at the Purchasing Commission website.
Method of Delivery:	The ITQ is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured. The QA results will be delivered to the author of the ITQ via email, phone or meeting.
Performing the QA:	The QA of the ITQ is performed by:
	—	relevant program area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The ITQ will be quality assured for:
	—	conformity to Ministry Standards;
	—	technical standards;
	—	content;
	—	details;
	—	omissions.
Timeframe:	2 - 3 days.
[TOC]
4.2    QA OF THE DEFINITION PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Project Statement Ministry Project Manager email, hardcopy Ministry standards, technical standards, content, format 1-2 weeks email, meeting, phone Project Schedule Ministry Project Manager email, hardcopy deliverables and milestones - clearly defined, reasonableness, availability of resources as part of Project Statement email, meeting, phone Conceptual Design - High Level Ministry Project Manager meeting, walkthrough technical feasibility, fit with Ministry infrastructure, review of physical model 1 day meeting
Project Statement
The purpose of the Project Statement is to provide a "road-map" for the successful execution of a project. Refer to the Project Statement Standard documentation for a detailed description of this deliverable.
Method of Delivery:	The Project Statement is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured. The QA results will be delivered to the author of the Project Statement via email, phone or meeting.
Performing the QA:	The QA of the Project Statement is performed by:
	—	Ministry Project Manager;
	—	Application Manager;
	—	relevant program area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The Project Statement will be quality assured for:
	—	conformity to Ministry standards;
	—	technical standards;
	—	content;
	—	format.
Timeframe:	1 - 2 weeks.
[TOC]
Project Schedule
The Project Schedule is a plan of the project's tasks. It details the timelines and who is responsible for each task. It is part of the Project Statement but for the purpose of this documentation has been outlined as a separate deliverable. The Project Schedule, where possible, will be done in MS Project.
Method of Delivery:	The Project Schedule is distributed (as part of the Project Statement) via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the Project Schedule is performed by:
	—	Ministry Project Manager;
	—	Application Manager;
	—	relevant program area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The Project Schedule will be quality assured for:
	—	deliverables and milestones are clearly defined;
	—	reasonability;
	—	level of Ministry staff required (resources).
Timeframe:	The Project Schedule should be quality assured at the same time as the Project Statement and the QA results returned to the Ministry Project Manager within 1 - 2 weeks.
[TOC]
Conceptual Design - High Level
The Conceptual Design deliverable is a High Level document for the Definition Phase, a Checkpoint in the Requirements Phase, and the Mandatory in the Design Phase. The QA processes are the same for all three phases. The deliverables, however, change as they progress through the phases.
Method of Delivery:	The Conceptual Design is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the Conceptual Design is performed by:
	—	Application Manager;
	—	DA and AA for the technical QA;
	—	Information Management BA.
Scope of QA:	The Conceptual Design will be quality assured for:
	—	technical feasibility;
	—	fit with the Ministry infrastructure;
	—	review of physical model.
Timeframe:	One day.
[TOC]
4.3    QA OF THE ANALYSIS PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Software Requirement Specification Document Ministry Project Manager See Application Delivery Standards Ministry standards, content, technical language, model soundness, sharing potential 2 weeks (schedule in advance) meeting Data Architecture Standards Ministry Project Manager See Application Delivery Standards Ministry standards, business requirements, descriptions, completeness of repository, functional model soundness, data model soundness 2 weeks meeting Data Conversion Analysis Ministry Project Manager See Application Delivery Standards completeness, soundness of approach, content, data mapping, appropriate testing strategy 1 week meeting Conceptual Design -Checkpoint Ministry Project Manager meeting, walkthrough technical feasibility, fit with Ministry infrastructure, review of physical model 1 day meeting   A standard has been developed for the Requirements Phase of the System Development Life Cycle. All vendors engaged to perform system requirements are instructed to follow and conform to these standards when producing deliverables for this phase.
Software Requirements Specification Document
The Software Requirements Specification document will capture the analysis and documentation of the business and functional requirements of the application system, using data and process modeling techniques.
Method of Delivery:	The Software Requirements Specification Document is delivered as per Application Delivery Standards . The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the Software Requirements Specification Document is performed by:
	—	Ministry Project Manager;
	—	Application Manager;
	—	relevant program area staff;
	—	DA and AA for the technical QA;
	—	Information Management BA.
Scope of QA:	The Software Requirements Specification Document will be quality assured for:
	—	conformity to Ministry standards;
	—	content;
	—	technical language;
	—	model soundness;
	—	potential for sharing with other projects.
Timeframe:	Two weeks. Where possible, the QA of this deliverable should be scheduled in advance to ensure availability of resources.
[TOC]
Oracle Designer Repository
Oracle's Designer provides a central repository for the storage of information about an application throughout its entire life cycle. This repository enables consistent application design and development within the Ministry. Standards for these deliverable are located within the Data Architecture Standards plus the Oracle Repository Procedures documentation.
Method of Delivery:	The Oracle Designer Repository is delivered as per Application Delivery Standards . The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the Oracle Designer Repository is performed by:
	—	Ministry Project Manager for the business QA;
	—	Application Manager for the business QA;
	—	business representatives for the business QA;
	—	DA and AA for the technical QA;
	—	Information Management BA for the technical QA.
Scope of QA:	The Oracle Designer Repository will be quality assured for:
	—	conformity to Ministry standards;
	—	business requirements;
	—	descriptions;
	—	completeness of repository;
	—	functional model soundness;
	—	data model soundness.
Timeframe:	The QA result should be delivered to the vendor within two weeks via a meeting with the Ministry Project Manager. Note: This QA process will require three meetings: one for the technical QA, one for the business QA and a final meeting for the Ministry Project Manager to deliver the QA results to the vendor.
[TOC]
Data Conversion Analysis
The Data Conversion Analysis document captures the analysis and documentation of the current data and the requirements for importing it into the new application.
Method of Delivery:	The Data Conversion Analysis is delivered as per Application Delivery Standards . The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the Data Conversion Analysis is performed by:
	—	Ministry Project Manager;
	—	Application Manager;
	—	relevant Business Area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The Data Conversion Analysis will be quality assured for:
	—	completeness;
	—	soundness of approach;
	—	content;
	—	data mapping;
	—	appropriate testing strategy.
Timeframe:	One week.
[TOC]
Conceptual Design - Checkpoint
The Conceptual Design - Checkpoint is a review of the design, to ensure the application will meet the business needs and work within the Ministry's technical architecture. The QA processes for this deliverable are defined in Conceptual Design - High Level.
[TOC]
4.4    QA OF DESIGN PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Conceptual Design -Mandatory Ministry Project Manager meeting, walkthrough technical feasibility, fit with Ministry infrastructure, review of physical model 1 day meeting Detailed Software Design Description Ministry Project Manager See Application Delivery Standards Ministry standards, fit with Ministry infrastructure, meets business needs as described in Software Requirements Specification Document, model soundness, appropriate data mapping (where data conversion is required), content, appropriate testing strategy, technical feasibility, technical language 2 weeks (schedule in advance) meeting Data Architecture Standards Ministry Project Manager See Application Delivery Standards Ministry standards, business requirements, descriptions, completeness of repository, functional model soundness, data model soundness 2 weeks meeting Data Conversion Design Ministry Project Manager See Application Delivery Standards business needs, data mapping, error handling, corrupt data 1-2 weeks meeting
Conceptual Design - Mandatory
The Conceptual Design - Mandatory is a required deliverable. The QA processes for this deliverable are defined in Conceptual Design - High Level.
[TOC]
Detailed Software Design Description
The deliverable document from the Software Design Description process will include a set of technical specifications that will be used to generate (Build) and implement the new system or feature. The Detailed Software Design Description is quality assured via two walkthrough meetings - Business walkthrough and the Technical walkthrough. Each reviews the deliverable as noted below.
Method of Delivery:	The Detailed Software Design Description is delivered as per Application Delivery Standards. The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the Detailed Software Design Description is performed by:
	—	Ministry Project Manager for the business QA
	—	Application Manager for the business QA;
	—	relevant business area staff for the business QA;
	—	users for the business QA;
	—	DA and AA for the technical QA;
	—	Information Management BA for the technical QA.
Scope of QA:	The Detailed Software Design Description will be quality assured for:
	—	conformity to Ministry standards;
	—	fit with Ministry infrastructure;
	—	meets business needs as described in Software Requirements Specification Document;
	—	model soundness;
	—	appropriate data mapping (where data conversion is required);
	—	content;
	—	appropriate testing strategy;
	—	technical feasibility;
	—	technical language.
Timeframe:	Two weeks. Where possible, the QA of this deliverable should be scheduled in advance to ensure the availability of resources.
[TOC]
Data Architecture Standards - Design
The QA processes for this deliverable are defined in Data Architecture Standards in the Design Phase.
[TOC]
Data Conversion Design
Data Conversion Design documentation will include a set of technical specifications that will be used to convert existing data and import it into the new system. Note: This deliverable is distributed and quality assured via walkthrough/meeting. It is to be quality assured at the same time as the Detailed Software Design System and using the same processes.
[TOC]
4.5    QA OF BUILD PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Data Conversion Application Ministry Project Manager See Application Delivery Standards code structure conforms to Ministry standards, soundness, well commented, dead code, programming practices, delivery processes and environments 1 week email, meeting Product Release (Code Delivery) Ministry Project Manager See Application Delivery Standards code structure conforms to Ministry standards, soundness, well commented, dead code, programming practices, delivery processes and environments 2 weeks email, meeting
Data Conversion Application
The Data Conversion Application is the program and/or scripts that convert the format of existing data structures into the structure (as delivered by the Data Model) required by an application. This would include dealing with incompatibilities (i.e. missing attributes between the old and new data models).
Method of Delivery:	The Data Conversion Application is delivered as per Application Delivery Standards . The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the Data Conversion Application is performed by:
	—	relevant program area staff;
	—	end users;
	—	DBA and AA for the technical QA;
	—	Information Management BA.
Scope of QA:	The Data Conversion Application will be quality assured for:
	—	code structure conforms to Ministry standards;
	—	soundness;
	—	well commented;
	—	removal of dead code;
	—	programming practices;
	—	delivery process and environments.
Timeframe:	One week.
[TOC]
Product Release (Code Delivery)
Standards for the Product Release are detailed in the Application Delivery Standards document on the Intranet.
Method of Delivery:	The Product Release is delivered as per Application Delivery Standards . The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the Data Conversion Application is performed by:
	—	relevant program area staff;
	—	end users;
	—	DBA and AA for the technical QA;
	—	Information Management BA.
Scope of QA:	The Data Conversion Application will be quality assured for:
	—	code structure conforms to Ministry standards;
	—	soundness;
	—	well commented;
	—	dead code;
	—	programming practices;
	—	delivery process and environments.
Timeframe:	Two weeks.
[TOC]
4.6    QA OF IMPLEMENTATION PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned User Procedures Manual Ministry Project Manager email, hardcopy readability, clarity, content, format, 2 weeks email, meeting User Acceptance Test Plan Ministry Project Manager email, hardcopy Ministry standards, must include plans for testing of Data Conversion Application (where required), clear and comprehensive, completeness for testing all requirements as described in the Software Requirements Specification Document, completeness for covering all business scenarios and Exceptions 1 week email, meeting Transition Plan (Includes Training) Ministry Project Manager email, hardcopy communications plan, fall back plan, training plan, details, completeness, timing, reasonableness of time frames (e.g. system downtime), resources required 1 week email, meeting Technical Documentation Ministry Project Manager email, hardcopy Ministry standards, details, format, content, accuracy 1 week email, meeting
User Procedures Manual
The User Procedures Manual provides the information and support required for the End User. This document should be written using "user friendly" terminology. It serves as the End User training manual as well as the sole reference source for trained staff using the system.
Method of Delivery:	The User Procedures Manual is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the User Procedures Manual is performed by:
	—	Application Manager;
	—	relevant business area staff;
	—	end users;
	—	Information Management BA.
Scope of QA:	The User Procedures Manual will be quality assured for:
	—	readability;
	—	clarity;
	—	content;
	—	format.
Timeframe:	Two weeks.
[TOC]
User Acceptance Test Plan (UAT)
User Acceptance Testing is part of the Implementation Phase in the SDLC (the 6th Phase in the SDLC). Ministry standards for testing are defined in the User Acceptance Test Standard. Note: The UAT Plan should be written by someone who understands the business.
Method of Delivery:	The User Acceptance Test Plan (UAT) is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the UAT Plan is performed by:
	—	Application Manager;
	—	relevant program area staff;
	—	Information Management BA.
Scope of QA:	The UAT Plan will be quality assured for:
	—	conformity to Ministry standards;
	—	must include plans for testing of Data Conversion Application (where required);
	—	clarity and comprehension;
	—	completeness for testing all requirements as described in the Software Requirements Specification Document;
	—	completeness for covering all business scenarios and Exceptions.
Timeframe:	One week.
[TOC]
Transition Plan (Includes Training)
Transition Plan is a detailed plan for moving from the current application or manual procedures to the new application or upgraded version. It should include plans for user training.
Method of Delivery:	The Transition Plan is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the Transition Plan is performed by:
	—	Application Manager;
	—	relevant business area staff;
	—	relevant technical staff;
	—	Information Management BA.
Scope of QA:	The Transition Plan will be quality assured for:
	—	communications plan;
	—	fall back plan;
	—	training plan;
	—	details;
	—	completeness;
	—	timing;
	—	reasonability of time frames (e.g. system downtime);
	—	resources required.
Timeframe:	One week.
[TOC]
Technical Documentation
Technical Documentation includes the system detail and support documentation.
Method of Delivery:	The Technical Documentation is distributed via email or hardcopy to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the Technical Documentation is performed by:
	—	Ministry Project Manager;
	—	Application Manager;
	—	AA and DBA for the technical QA;
	—	Information Management BA.
Scope of QA:	The Technical Documentation will be quality assured for:
	—	conformity to Ministry standards;
	—	details;
	—	format;
	—	content;
	—	accuracy.
Timeframe:	One week.
[TOC]
4.7    QA OF WAREHOUSE PHASE DELIVERABLES Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Warehouse Deliverables The deliverables for this phase are as outlined in the Warehouse section of the Systems Development Lifecycle (SDLC) Overview document. The quality assurance processes for this phase are still to be defined and will be inserted at a later date. Applicable standards and information on this phase appear in the System Development Life Cycle (SDLC) Standard.
[TOC]
4.8    QA of Deliverables During Maintenance Activities required after an application is successfully delivered into production are considered to occur during Maintenance. This is not a phase as such, but an ongoing process of updating or modifying an application because of bugs, service requests or other required changes. Depending on the activities involved, it may require some or all of the deliverables noted in the table below. Each deliverable should be quality assured as noted. Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Project Proposal - Annual Application Manager email, hardcopy Ministry standards, content, format 1-2 weeks email, meeting Cost Estimates Application Manager email, hardcopy Ministry standards, completeness, content, format 1-2 weeks email, meeting Project Schedule - Annual Application Manager email, hardcopy deliverables and milestones - clearly defined, reasonableness, availability of resources as part of Project Statement status meeting CASE Repository Application Manager See Application Delivery Standards Ministry standards, content 2 weeks meeting Application Release Application Manager See Application Delivery Standards code structure conforms to Ministry standards, soundness, well commented, dead code, programming practices, delivery processes and environments 2 weeks email, meeting Updated System Documentation Application Manager email, hardcopy Ministry standards, details, format, content 1 weeks email, hardcopy Updated End User Documentation Application Manager email, hardcopy readability, clarity, content, format 2 weeks email, hardcopy
Project Proposal - Annual
The Project Proposal - Annual should be developed ahead of the annual planning process, or as needed throughout the year. For more details refer to the Ministry developed standard for the Project Proposal. The QA processes for this deliverable are as defined in the Project Proposal for the Planning Phase, but instead of being managed by the Ministry Project Manager they are usually managed by the Application Manager.
[TOC]
Cost Estimates
Cost Estimates are the process of estimating annual operational support costs for an application. The Intranet has Guidelines and a template to assist Application Managers with this process. New systems should incorporate these guidelines during the Feasibility phase of the project, to determine whether maintenance of the system is economically feasible, and during the Implementation phase, to confirm and adjust the estimated costs. For existing systems the guidelines should be used annually to re-evaluate support costs for the application, as these costs can change over the life of an application.
Method of Delivery:	The Cost Estimates are distributed via email to the Information Management Business Analyst for the purpose of being quality assured.
Performing the QA:	The QA of the Cost Estimates is performed by:
	—	Application Manager;
	—	relevant program area staff;
	—	business area specialist;
	—	relevant technical staff;
Scope of QA:	The Cost Estimates will be quality assured for:
	—	conformity to Ministry Standards;
	—	completeness;
	—	content;
	—	format.
Timeframe:	The QA results should be returned by the BA to Ministry Project Manager within 1 - 2 weeks.
[TOC]
Project Schedule - Annual
The QA processes for this deliverable are defined in the Project Schedule for the Planning Phase, but instead of being managed by the Ministry Project Manager they are usually managed by the Application Manager.
[TOC]
CASE Repository - Update
CASE (Computer-Assisted Software Engineering) Repository provides a central automated dictionary for storing and organizing all system information, including data definitions, diagrams, process specifications, and a variety of information related to planning project management, e.g., user access privileges and version control. A CASE repository also stores the relationships among the various information components, enabling sophisticated reports to be generated, e.g., the impact of design changes, or redundant data elements. The Ministry owns the CASE Repository and the Vendor must ensure the appropriate version is used.
Method of Delivery:	The CASE Repository is delivered as per Application Delivery Standards. The vendor must ensure the Ministry Project Manager or Application Manager receives notification of delivery.
Performing the QA:	The QA of the CASE Repository is performed by:
	—	Application Manager;
	—	DA for the technical QA.
Scope of QA:	The CASE Repository will be quality assured for:
	—	conformity to Ministry standards;
	—	content.
Timeframe:	Two weeks.
[TOC]
The Application Release
The QA processes for this deliverable are as defined in the Product Release for the Build Phase, but instead of being managed by the Ministry Project Manager they are usually managed by the Application Manager.
[TOC]
Updated System Documentation
The QA processes for this deliverable are as defined in the Technical Documentation for the Implementation Phase, but instead of being managed by the Ministry Project Manager they are usually managed by the Application Manager.
[TOC]
Updated End User Documentation
The QA processes for this deliverable are as defined in the User Procedures Manual for the Implementation Phase, but instead of being managed by the Ministry Project Manager they are usually managed by the Application Manager.
[TOC]

5.     CONCLUSION This guideline is intended to give Application Managers and developers an understanding of the Ministry's expectations and ensure a consistent approach to delivered products. [TOC]

 

APPENDIX A: QA MATRIX - DETAILED Quality Assurance - Summarized by Phase/Deliverable An Excel spreadsheet summarizing the information as captured in this document has been created and can be printed for quick reference. The summary table below allows the user to navigate quickly through the QA processes and standards for each deliverable. The standard (if available) can be accessed by clicking on the deliverable name in Figure 2, below. The detailed QA processes can be accessed by clicking the "QA" button below the deliverable name in Figure 2. Note: This checklist is meant to be a quick reference only. Details as noted in section 4 should be followed for each deliverable. Also, where the time frame of 1 day is indicated, it means that a walkthrough or meeting is to be held to perform the QA on the deliverable. Where possible, the deliverable should be supplied in advance. Figure 2: SDLC QA Matrix Deliverable Who Manages QA How Deliverable Received Scope of QA Time Frame of QA How Results Returned Phase 1 :    PLANNING Project Proposal Ministry Project Manager email, hardcopy Ministry standards, content, format 1 week email, meeting, phone RFP Ministry Project Manager email, hardcopy Ministry standards, technical standards, content, details, omissions 1 week (schedule in advance) email, meeting, phone ITQ Ministry Project Manager email, hardcopy Ministry standards, technical standards, content, details, omissions 2-3 days email, meeting, phone Phase 2 :    DEFINITION Project Statement Ministry Project Manager email, hardcopy Ministry standards, technical standards, content, format 1-2 weeks email, meeting, phone Project Schedule Ministry Project Manager email, hardcopy deliverables and milestones - clearly defined, reasonableness, availability of resources as part of Project Statement email, meeting, phone Conceptual Design - High Level Ministry Project Manager meeting, walkthrough technical feasibility, fit with Ministry infrastructure, review of physical model 1 day meeting Phase 3 :    ANALYSIS Software Requirements Specification Document Ministry Project Manager See Application Delivery Standards Ministry standards, content, technical language, model soundness, sharing potential 2 weeks (schedule in advance) meeting Data Architecture Standards Ministry Project Manager See Application Delivery Standards Ministry standards, business requirements, descriptions, completeness of repository, functional model soundness, data model soundness 2 weeks meeting Data Conversion Analysis Ministry Project Manager See Application Delivery Standards completeness, soundness of approach, content, data mapping, appropriate testing strategy 1 week meeting Conceptual Design -Checkpoint Ministry Project Manager meeting, walkthrough   technical feasibility, fit with Ministry infrastructure, review of physical model 1 day meeting Phase 4 :    DESIGN Conceptual Design -Mandatory Ministry Project Manager meeting, walkthrough   technical feasibility, fit with Ministry infrastructure, review of physical model 1 day meeting Detailed Software Design Description Ministry Project Manager See Application Delivery Standards Ministry standards, fit with Ministry infrastructure, meets business needs as described in Software Requirements Specification Document, model soundness, appropriate data mapping (where data conversion is required), content, appropriate testing strategy, technical feasibility, technical language 2 weeks (schedule in advance) meeting Data Architecture Standards Ministry Project Manager See Application Delivery Standards Ministry standards, business requirements, descriptions, completeness of repository, functional model soundness, data model soundness 2 weeks meeting Data Conversion Design Ministry Project Manager See Application Delivery Standards business needs, data mapping, error handling, corrupt data 1-2 weeks meeting Phase 5 :    BUILD Data Conversion Application Ministry Project Manager See Application Delivery Standards code structure conforms to Ministry standards, soundness, well commented, dead code, programming practices, delivery processes and environments 1 week email, meeting Product Release (Code Delivery) Ministry Project Manager See Application Delivery Standards code structure conforms to Ministry standards, soundness, well commented, dead code, programming practices, delivery processes and environments 2 weeks email, meeting Phase 6 :   IMPLEMENTATION User Procedures Manual Ministry Project Manager email, hardcopy readability, clarity, content, format, 2 weeks email, meeting User Acceptance Test Plan Ministry Project Manager email, hardcopy Ministry standards, must include plans for testing of Data Conversion Application (where required), clear and comprehensive, completeness for testing all requirements as described in the Software Requirements Specification Document, completeness for covering all business scenarios and Exceptions 1 week email, meeting   Transition Plan (Includes Training) Ministry Project Manager email, hardcopy communications plan, fall back plan, training plan, details, completeness, timing, reasonableness of time frames (e.g. system downtime), resources required 1 week email, meeting   Technical Documentation Ministry Project Manager email, hardcopy Ministry standards, details, format, content, accuracy 1 week email, meeting Phase 7:   WAREHOUSE Warehouse Deliverables The deliverables for this phase are as outlined in the Warehouse section of the Systems Development Lifecycle (SDLC) Overview document. The quality assurance processes for this phase are still to be defined and will be inserted at a later date. Applicable standards, information on this phase can be accessed by reviewing the information in the System Development Life Cycle (SDLC) Standard   MAINTENANCE Project Proposal - Annual Application Manager email, hardcopy Ministry standards, content, format 1-2 weeks email, meeting Cost Estimates Application Manager email, hardcopy Ministry standards, completeness, content, format 1-2 weeks email, meeting Project Schedule - Annual Application Manager email, hardcopy deliverables and milestones - clearly defined, reasonableness, availability of resources as part of Project Statement status meeting CASE Repository - Update Application Manager See Application Delivery Standards Ministry standards, content 2 weeks meeting Application Release Application Manager See Application Delivery Standards code structure conforms to Ministry standards, soundness, well commented, dead code, programming practices, delivery processes and environments 2 weeks email, meeting Updated System Documentation Application Manager email, hardcopy Ministry standards, details, format, content 1 weeks email, hardcopy Updated End User Documentation Application Manager email, hardcopy readability, clarity, content, format 2 weeks email, hardcopy

[TOC]

APPENDIX B: BIBLIOGRAPHY A Guide to the Project Management Body of Knowledge - Project Management Institute Information Technology Project Management - Kathy Schwalbe (ISBN 0-7600-1180-X)