Ministry of Agriculture & Lands

[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)

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.

2.4      Business Analyst (BA)

This description applies to the Information Management Branch Business Analyst (IMB BA).

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

2.6      Data Administration (DA)

2.7      Database Administrator (DBA)

2.8 End Users

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:

2.10     Vendor

 [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

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.

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 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.

[TOC]

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.

[TOC]

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.

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.

[TOC]

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.

[TOC]

[TOC]

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.

[TOC]

[TOC]

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.

[TOC]

[TOC]

[TOC]

[TOC]

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.

[TOC]

[TOC]

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.

[TOC]

[TOC]

[TOC]

[TOC]

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.

[TOC]

[TOC]

[TOC]

[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.

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]

[TOC]

[TOC]

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.

[TOC]

[TOC]

[TOC]

[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)