Information & Technology Management Standards
Application Development, Project and Quality Management Standards
Standards and guidelines documents are accessible for download from this page.
- Application Development Standards and Guidelines
- New/Emerging Standards
- Project Management Standards and Guidelines
- Quality Management Standards and Guidelines
Click the document title to download the standards document. See the description of each of the "Core Deliverables" to see how these standards apply to project deliverables.
Application Development Standards and Guidelines
| The Analysis, Design & Architecture Document should conform to the Ministry template. Each section in this document is mandatory. The section outlining data access and data usage are particularly important to enable an assessment of the applications impact from an enterprise perspective. Two submission/acceptance points are associated with the delivery of this document. The first submission occurs at the end of the design phase and the final "as built" revision occurs towards the end of the project. | |
The Application Architecture Document should conform to the Ministry template
|
|
| Application Code Minimum Standards | |
| Application Code SQL Minimum Standards | |
| Application Code PL/SQL Minimum Standards | |
| Application Code Standards | |
| Application Code SQL Standards | |
| Application Code PL/SQL Standards | |
| Application Code SQL Guidelines | |
| Application Code PL/SQL Guidelines | |
| Application Deliverables Matrix |
|
| Application Maintenance Phase Standards and Deliverables |
|
| The Business Requirements Document should conform to the ministry's template. All sections of the document are mandatory. | |
| If the Designer approach is used to develop the Business Requirements Document, requirements models should conform to Requirements Modeling and Specification Guidelines and Standards |
|
| If use case approach is used to develop the Business Requirements Document, the Actor Profile Specification template |
|
| If use case approach is used to develop the Business Requirements Document, attach the Essential Use Case Specifications Document to the Business Requirements Document using the Essential Use Case Specifications Document template |
|
| Database Change Request Form |
|
| Database Development Guidelines |
|
| The Data Conversion Strategy should conform to the Ministry template. | |
Guidelines for the Location of Transient Data. Transient data will be located in its own data area on the middle tier. This data area will not be backed up. For the purpose of this guideline, transient data is defined as follows:
|
|
| The Implementation Plan should conform to the Ministry template. | |
| Legacy Application Maintenance Standards |
|
| Logical Database Design Minimum Standards | |
| Logical Database Design Standards | |
| Logical Database Design Guidelines | |
| Middle Tier Service Request |
|
| Module Functional Documentation Minimum Standards | |
| Module Functional Documentation Standards | |
| Module Functional Documentation Guidelines | |
| Module Technical Documentation Minimum Standards | |
| Module Technical Documentation Standards | |
| Module Technical Documentation Guidelines | |
| The Operations Support Guide should conform to the Ministry template. | |
| Oracle Development Guide |
|
| Physical Database Design Minimum Standards | |
| Physical Database Design Standards | |
| Under section 69 of Freedom of Information and Protection of Privacy Act, ministries are required to conduct a Privacy Impact Assessment (PIA) to determine if a new enactment, system, project or program meets the Privacy Protection requirements in the Freedom of Information and Protection of Privacy Act. The PIA is designed to be used for all programs, legislation, systems or initiatives. See Privacy Impact Assessments in the Core Policy Manual. | |
| Production Database DDL Minimum Standards | |
| Production Database DDL Standards | |
| Requirements Modeling and Specification Guidelines and Standards |
|
| A risk and controls review must be performed and documented for a new financial system, and whenever there are significant modifications to an existing financial system. Qualified, independent and objective parties must carry out the review. See Financial Systems and Controls in the Core Policy Manual. | |
| Software Configuration Management Standards |
|
| Standards and Guidelines for Development/Delivery of J2EE Applications. (Revised standards are in development). | |
The Technical Architecture Document should conform to the Ministry template, with the following sections completed:
|
|
| Defining a test strategy should be scheduled in the Analysis & Design phase. This strategy will include the development of test scenarios, test cases and a detailed test plan. | |
| The Testing Strategy should conform to the Ministry template. | |
| Five levels of project testing should take place: unit, integration, system, system integration, and user acceptance. At the end of system integration testing the system should be ready for user acceptance testing. | |
| In the case of remote development, ITMB highly recommends that application code is migrated to the Ministry database and middle tier servers early in the development cycle to execute unit testing. The expectation is to mitigate technical issues arising later in the development process due to differences in server configuration, software versions and/or operating systems. | |
| An acceptance test task should be included in the workplan to enable the business area to test the final product in a production-like environment prior to implementation. The initial requirements for this acceptance test should be documented during the business design. | |
| The Training and Support Strategy should conform to the Ministry template. | |
| The User Acceptance Test Plan is the responsibility of Ministry resources unless otherwise specified. | |
| User Interface Style Definition Minimum Standards | |
| User Interface Style Definition Standards | |
| Web Applications User Interface Guidelines |
UML Analysis Level Standards
The standards and deliverables pertain to the "high level requirements definition phase" of the ADE and will help to define and document requirements in a technology independent manner and in a standard notation (UML).
Currently there is no enforcement of any specific tool sets to produce the UML artifacts. However, if the artifacts are to be used in further phases of the systems development lifecycle, use of metadata driven tools rather than graphical tools is recommended.
| Activity Diagram Standards & Guidelines |
|
| Domain Class Diagram Modeling Standards & Guidelines |
|
| Essential Use Case Modeling Standards & Guidelines |
|
| Model Driven Development and Model Driven Architecture Issues |
|
| System Use Case Modeling Standards & Guidelines |
|
| UML Diagram Interchange Issues |
XML Standards
XML technologies span a wide variety of areas and standards. The ministry ADE process has identified nine areas of XML where standards could be built and evolved. Standards for each area will be covered in separate documents.
| XML Core Standards |
|
| XML Data Validation Standards |
|
| XML Namespace Standards |
Project Management Standards and Guidelines
| All projects must be initiated with the submission, review and approval of a Project / Initiative Overview Document. The PIO process must be followed if a proposed initiative will result in the implementation of new, enhanced or extended systems or infrastructure. The PIO process is part of the Standard Project Lifecycle. | |
| PIO Process Description | |
| PIO Checklist |
|
| Project Delivery Office document templates must be used as the basis for all project management documents. Changes to an approved document must be handled through a change management process. | |
| A project's Level of Project Management (LOPM) must be calculated and recorded in the Project Charter and the Master Project Plan. | |
| The Project Management Requirements indicated by the rating from the Level of Project Management tool must be adhered to. | |
| Every project must document the project requirements using the format of the Project Charter, Master Project Plan (light), Master Project Plan (Web) or full Master Project Plan, as agreed upon by the stakeholders at the start of the project. | |
| A full MPP is required for all projects with a Level of Project Management Score of 50 or more. | |
| All projects must have a completed Project Workplan filed with the Project Delivery Office. | |
| Workplan Creation, Tracking and Reporting Procedures |
|
| Workplan Management Standards and Guidelines |
|
| Every Project Planning phase document must follow a review and approval process. | |
| Under section 69 of Freedom of Information and Protection of Privacy Act, ministries are required to conduct a Privacy Impact Assessment (PIA) to determine if a new enactment, system, project or program meets the Privacy Protection requirements in the Freedom of Information and Protection of Privacy Act. The PIA is designed to be used for all programs, legislation, systems or initiatives. | |
| Project Managers report status to the Project Delivery Office using the standard template by the end of day on the second and fourth Thursday of every month. | |
| Project Issue Management Process |
|
| Project Change Management Process |
|
| All Application Development projects must ensure that APMS Data is updated adequately with Application information. Please click on the hyperlink to view APMS Data Update Checklist |
|
| All deliverables must be approved and formal acceptance of the final product must be obtained from the project sponsor. | |
| All projects should hold a post project evaluation either formal or informal. When deemed desirable by management, client or project manager the project evaluation should be formally documented in the Project Evaluation Document and accepted as part of the official project documentation. Lessons Learned from projects should be recorded and included in the Project Evaluation Document. | |
| All outstanding issues must be addressed and as necessary transferred to the appropriate party, project or function. | |
| All project files are classified and filed according to Administrative Records Classification System (ARCS). | |
| All project files are classified and filed according to Administrative Records Classification System (ARCS). | |
| All projects must complete a Project Completion Checklist Form at the end of the Closing phase. |
Quality Management Standards and Guidelines
| All deliveries should be made to the Project Delivery Office to be logged and distributed for review and acceptance. | |
All project deliverables will be subject to a review and approval process and will be signed off by the project sponsor and stakeholders with a vested interest in the particular deliverable. Click on the hyperlink to view the Guidelines on QA turnaround timelines for ADE deliverables |
|
| Peer reviews will be held for business design and technical design documents, and code-walkthroughs for non-generated code. | |
| Defining a test strategy has been scheduled in the Business Design phase. This strategy will include the development of test scenarios, test cases and a detailed test plan. | |
| Five levels of project testing will take place: unit, integration, system, system integration, and user acceptance. At the end of system integration testing the system should be ready for user acceptance testing. | |
| Unit Testing Process |
|
| System Testing Process |
|
| User Acceptance Testing Process |
|
| An acceptance test task is included in the workplan to enable the business area to test the final product in a production-like environment prior to implementation. The initial requirements for this acceptance test will be documented during the business design. | |
| All system and application deliverables will be signed off prior to migration to production. |

