Information & Technology Management Standards

Application Development, Project and Quality Management Standards

Standards and guidelines documents are accessible for download from this page.

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 and must include:
  • User interface style, including sample screen mock-ups,
  • Design strategy for functions of the application,
  • Classification of the components by types,
  • A mapping of the components to the technical architecture,
  • Use of patterns and use of meta data,
  • Design deliverables list,
  • Performance issues,
  • Configuration Management for meta data and components or packages.
Application Deliverables Matrix (PDF, 134KB)
Application Maintenance Phase Standards and Deliverables (PDF, 613KB)
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 (PDF, 528KB).
If use case approach is used to develop the Business Requirements Document, the Actor Profile Specification template (DOC, 254KB) should be used to document the actor profiles. Alternately, if the number of actors is small, then the actor profile information may be provided in a table in the Business Requirements Document itself.
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 (DOC, 264KB). Alternately, if there are fewer than 15 use cases, then use the tabular format in the Business Requirements Document itself to describe the essential use case specifications.
Database Change Request Form (DOC, 48KB). See an example DCR (DOC, 44KB).
Database Development Guidelines (DOC, 43KB).
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:
  • Transient data can be reproduced from the source data in a reasonable amount of time.
  • Transient data is not backed up as the data can be reproduced from others sources if needed.
  • Transient data should not have a shelf life greater then one year.
Examples of transient data would include:
  • Static reports.
  • A phone list that is generated from another source
The Implementation Plan should conform to the Ministry template.
Legacy Application Maintenance Standards (PDF, 124KB)
Middle Tier Service Request (DOC 54KB). See an example MTSR for a java application (DOC 67KB). See an example MTSR for a forms application (DOC, 74KB).
The Operations Support Guide should conform to the Ministry template.
Oracle Development Guide (DOC, 138KB)
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.
Requirements Modeling and Specification Guidelines and Standards (PDF, 528KB).
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 (PDF, 427KB)
Technical Architecture (PDF, 252KB)
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.
Web Applications User Interface Guidelines (PDF, 106KB)

Iterative Development Standards

The basic idea behind iterative approach is to develop a software system iteratively and incrementally, allowing the developers and users to take advantage of lessons learnt during the development of earlier iterations of the system development. In the iterative development approach, the whole process of system development typically iterates through all the phases of the System Development Life cycle (SDLC), starting from gathering requirements to delivering functionality of a working release.

The purpose of this standards document is to define and describe standards for Iterative development approach for the Ministry applications. These standards are to be used in conjunction with the existing Ministry ADE standards.

Iterative Development Standards (PDF, 203KB)

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 (PDF, 196KB)
Domain Class Diagram Modeling Standards & Guidelines (PDF, 261KB)
Essential Use Case Modeling Standards & Guidelines (PDF, 262KB)
Model Driven Development and Model Driven Architecture Issues (PDF, 114KB)
System Use Case Modeling Standards & Guidelines (PDF, 260KB)
UML Diagram Interchange Issues (PDF, 119KB)

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 (PDF, 160KB)
XML Data Validation Standards (PDF, 148KB)
XML Namespace Standards (PDF, 140KB)

 

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 (PDF, 141KB).
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 (PDF, 42KB).
Workplan Management Standards and Guidelines (PDF, 77KB).
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 Issue Management Process (PDF, 40KB).
Project Change Management Process (PDF, 42KB).
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 (DOC, 33KB).
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 (PDF, 141KB).
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 (PDF, 101KB).
System Testing Process (PDF, 92KB).
User Acceptance Testing Process (PDF, 124KB).
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.
Load Testing Process (PDF, 88KB).
All system and application deliverables will be signed off prior to migration to production.