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: