Education K-12 Sector IM/IT Standards

1.1

BPP Standards Summary

This document provides a quick overview/summary of the Business Program Planning (BPP) of the Education K-12 Sector (Ministry of Education), which caters to the IM/IT standards of the Ministry and has also links to the Government standards. 

Project Manager/Project Teams are required to read and familiarize with this document.

The BPP has templates, standards and processes applicable to the development and maintenance of (changes to) Applications of various types such as: Custom-built, Commercial Off The Shelf (COTS), Open-Source, Software as a Service (SaaS) etc.

pdf

1.2 

Application  Deliverables Matrix (Master list)

This document lists and briefly describes the master list of the BPP deliverables and their formats. 

Projects are required to read and familiarize with this document. Projects may also request a quick walk through of the BPP if needed. 

pdf

2.1 

Data Architecture Standards

The purpose of this document is to provide consolidated Data Architecture standards and guidelines for the Ministry applications during application development, implementation and maintenance (application changes).  

Applicable to all application projects including application maintenance (application changes) regardless of project type/size, project budgets/costs and project schedules.

2.2

QCIL Review process (Team Review process) 

This document (pdf of the Visio diagram) describes the team review process (called “QCIL Process”) for conducting review and feedback on deliverables from the application projects including application maintenance (application changes).  

Applicable to all application projects including application maintenance (application changes) regardless of project type/size, project budgets/costs and project schedules.

2.3

Technical Architecture (TA) Standards

This document describes the Technical Architecture (hardware, Operating System (OS), Frameworks etc.) and also the core IT processes such as configuration management, release management etc.      

All application projects (Custom development/COTS/OpenSource/Application maintenance (application change) etc) need to comply with the Ministry Technical Architecture and its environments such as DEV, TEST, UAT, PROD, EFX, etc.

All new application developments/implementations, application changes and software (tools) deployment etc. need to run on the Ministry Technical Architecture without any adverse impacts (performance issues, security issues etc.) on the IT infrastructure and other co-existing applications.

3.1

Business Case

The purpose of this document template is to provide the decision makers with an analysis of the problem, solution options, cost benefit analysis and recommendations and to help in the next steps (Decision Note and Funding approvals etc.).

Business Case and Decision Note are mandatory for all projects regardless of project type/size, project budgets/costs and project schedules. 

doc

3.2

Feasibility Assessment and Options Analysis

This template may be used as a deliverable/work product during the Business Case development initiative of the overarching project/initiative. This template can also be used on its own as a standalone document for any exclusive Feasibility Assessment work/initiative.

Feasibility Assessment is an optional but recommended initiative for large projects (multi-year, big budget and high-risk projects) to help in early risk analysis and stakeholder buy-in for the large/high-risk project.

doc

3.3

Project Charter

This document template defines the project in terms of objectives, scope, stakeholders and major deliverables.  It is the main deliverable from the Project Initiation Phase.  Approval of this document allows Project Planning to begin.

Project Charter is mandatory for all projects regardless of project type/size, project budgets/costs and project schedules.  

doc

3.4

Master Project Plan (MPP) 

This document template is the major deliverable of the Project Planning Phase. It describes how the project will be managed.  It is based upon the Project Initiation Document produced in the earlier Project Initiation Phase.  The subsequent detailed MS Project Workplan will be a companion deliverable to the MPP.

Master Project Plan (MPP) is mandatory for all projects regardless of project type/size, project budgets/costs and project schedules.  For small/low-risk projects, there may be exceptions which may be clarified from the project sponsor.

doc

3.5

Business Requirements Document (BRD)

The purpose of this document template is to describe and document the business requirements of an Application completely, accurately and unambiguously in Technology-independent manner. 

Typically used in the Requirements Phase. Applicable to all projects including application maintenance (application changes) regardless of project type/size, project budgets/costs and project schedules.

doc

3.6

Data Architecture 

Data models in metadata format (such as Sparx"eap" file) and also in graphical formats (".pdf", "jpg", etc.) need to be submitted for QCIL Review.

Also, refer the "Data Architecture" section in the Application Architecture (AA) template. 

Typically used in the Data Architecture Phase.   Applicable to all projects including application maintenance (application changes) regardless of project type/size, project budgets/costs and project schedules. For COTS/Open Source projects please refer the item 2.2 Data Architecture Standards document.  

Sparx EA tool template 

3.7

Application Architecture (AA)

The purpose of this document template is to document the architecture and design of application components towards implementation of business functionality described in the Business requirements document.

Typically used in the Application Architecture Phase.   Applicable to all projects including application maintenance (application changes) regardless of project type/size, project budgets/costs and project schedules. Small projects (or low risk projects) may use the alternate template called Analysis, Design and Architecture (ADA) template. 

doc

3.8

Testing Strategy

The purpose of this document template is to help projects in the early identification and documentation of various types of testing, testing tasks, resources needed etc. for the testing of the application. Four types of testing at the least are mandatory for all application projects : unit testing, system testing, user acceptance testing and performance/ load/stress testing. 

Applicable to all projects including application maintenance (application changes) regardless of project type/size, project budgets/costs and project schedules.  Small projects (or low risk projects) may use the alternate template called Analysis, Design and Architecture (ADA) template.

doc

3.9

Data Conversion Strategy

The purpose of this document template is to help projects in the early identification and documentation of data conversion scope, tasks, data quality assurance, resources needed etc. for the conversion of data from the old system to the new system. 

Applicable to all application replacement projects regardless of project type/size, project budgets/costs and project schedules. Small projects (or low risk projects) may use the alternate template called Analysis, Design and Architecture (ADA) template.

doc

3.10

Implementation Plan

The purpose of this document template is to help projects in the early identification and documentation of all necessary tasks, dependencies, resources and timings for production roll out of the completed/tested application without any adverse impacts on the IT infrastructure or on other co-existing applications.

Applicable to all new development/new implementation projects regardless of project type/size, project budgets/costs and project schedules.  Small projects (or low risk projects) may use the alternate template called Analysis, Design and Architecture (ADA) template. Application maintenance projects (application changes) may create a new Implementation Plan document as needed.

doc

3.11

Operations Support Guide

The purpose of this document template is to help projects in the early identification and documentation of post-production support channels and support process for the implemented application such as first line support, second line support, support availability hours, etc. 

Applicable to all new development/new implementation projects regardless of project type/size, project budgets/costs and project schedules.  Small projects (or low risk projects) may use the alternate template called Analysis, Design and Architecture (ADA) template. Application maintenance projects (application changes) may update the existing Operations Support guide in case there are changes to the support information due to the application changes.

doc

3.12

Information Security Classification Form

This form is for Ministry internal use only. The purpose of this Form is to guide in establishing, classifying and labeling the Information Security Classification of Ministry Applications in line with OCIO - established Information Security Classification Standards. 

All Production applications (newly implemented as well as existing applications) are to go through the Information Security Classification process.

doc