Welcome to Systems Development Life Cycle Portal (SDLC)

Determine the release size as well as technical and business risk levels.

Start SDLC Wizard

1. Summary

1.1 Executive Summary

This handbook has been developed with the aim to present a process model for systems development activities, including activities performed under “projects” and activities performed under “business as usual” or “support/maintenance” work.

The development of this process model is part of the response to the recommendations made by Deloitte to the Department of Education and Training (DET) in relation to the OneSchool incident and the need to take a risk-based approach in the development of systems and software in the agency.

At a high level, this handbook endeavours to present a model for “work” under systems development activities and provide a governance model to cover all stages throughout the lifetime of a system in DET’s environment. It highlights and explains all the related processes, controls and artefacts required throughout systems development activities.

If implemented and followed thoroughly, this process model will enable DET to

Strengthen ability to apply different levels of rigor and control based on the risk profile of a release for IT/ICT solutions developed internally;
Strengthened consistency, traceability, transparency and robustness within systems development activities;
Improve confidence in the quality of in-house developed solutions, ensuring industry and government standards are being met; and
Achieve a higher level of engagement with the business in all stages of systems development life cycle, especially during needs determination, concept development, and testing.

Multiple sources have been used to develop this process model including IEEE/ISO standards, journal papers, articles and books as well as the support and feedback from a community of practice formed by Queensland Government Chief Information Office (QGCIO) while the customisations and localizations have been performed in accordance to our local stakeholders’ needs and requirements.

This process model has been developed with the aim to conform to ISO 15288:2015 (Systems and Software Engineering - System Life Cycle Processes) [1] while its supporting artefacts are developed to conform to a number of different IEEE/ISO standards.

It’s highly recommended for the agency to ensure this process model and its supporting artefact templates are reviewed periodically in order to stay relevant in future. As part of “Organizational Project-Enabling Processes” in ISO 15288:2015, Life Cycle Model Management Processes should be well documented, easily available and finally, supported and owned by a team to ensure consistency, transparency and quality are achieved throughout the systems development activities.

1.2 Developer’s Summary

As a systems development team member, the following steps can show you how to follow DET’s SDLC process model effectively:

Make sure you familiarize yourself with “SDLC Principles”, “SDLC Conceptual Model” and the definition of an SDLC Track, which is a “trip” between SDLC stages. For each release size, a different SDLC track may be applicable with certain SDLC stages.
At the beginning of a systems development activity (i.e. when developing a new system that did not existed before or when developing a new release of an existing system after going through the “Release Planning and Size Determination Process”), the “SDLC Track Processes” should be performed:
1. If applicable, perform the “Life Cycle Model Management Process” to ensure the teams become aware of the organizational principles, processes and procedures around SDLC.
2. Determine the release size according to the “Release Planning and Size Determination Process” in section ‎11.5.2. Depending on the size of the release, different SDLC tracks and stages may be applicable. This process shows the SDLC stages that should be included in the development activity.
3. When developing new features and/or when data models and/or data schemas are being modified, perform the “Preliminary Information Classification Process” according to section ‎3.2.
4. If applicable, for releases including cloud-based components, perform the “Preliminary Cloud Assessment Process” according to section ‎3.3.
5. Perform the “Risk Assessment Process” to determine the risk associated with the release according to section ‎3.4. Depending on the risk, different levels of rigor and controls may be applicable.
Depending on the release size and the applicable SDLC track, follow the guidelines and perform the processes related to the SDLC stages involved in the SDLC track.
You can refer to “Appendix B – Alignment of Systems Development Method” for a quick guide on how to align mainstream systems development methods with DET’s SDLC process model.
It would be an anti-pattern to bundle releases of different risk profiles together since the highest risk level of the smallest piece will be applicable to the whole bundle resulting in extra overhead. The granularity at which an independent release unit is defined is left to the development teams to find the optimum balance, however, it would be sensible to isolate a single high-risk release and manage its development and artefacts separately for better traceability and transparency.
This process model defines the absolute minimums in terms of governance and artefacts. The development teams are free to apply extra rigor and use DET’s ICT Project Management Life Cycle and method based on their own discretion to cover “any” release types while managing and delivering them under “projects”.

2. Overview

2.1 Background

The Department of Education (DET) has been using a systems development life cycle for its internal systems development activities. Recent changes in the landscape and the recommendations made by Deloitte after the OneSchool incident have become the drivers to review and refresh the systems development life cycle of the department to ensure all development activities in DET follow consistent documented processes that comply with industry standards. To address the recommendations, this new systems development life cycle has been developed to be used throughout the department.

2.2 Purpose

The purpose of this handbook is to describe a process model with the minimum required stages and considerations for developing and/or implementing systems and software at the Queensland Department of Education and Training.

2.3 Limitations

This handbook covers the minimum processes and artefacts related to systems development activities and it could be tailored and adapted to different project sizes and types, however, there are a number of areas for which this handbook will not be prescriptive, as follows:

2.3.1 Systems Development Methods

This handbook has been developed with the mindset that the systems development teams will choose their systems development method and to accommodate that, this handbook supports both traditional waterfall and a number of modern agile systems development methods, as explained in “Appendix B – Alignment of Systems Development Method”.

2.3.2 Cloud-Based vs. On-Premises Development

This handbook has been developed to support systems development activities for both cloud-based and on-premises systems, however, the choice between the two is left to be made by the systems development teams and/or project owners through DET’s cloud decision making processes.

2.4 Applicability

By definition, a system is a set of man-made components that may be configured with one or more of the following system elements: hardware, software, data, humans, processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities [1].

It is envisaged that this handbook and the processes it covers should be applied to all the systems development activities addressing all release sizes, irrespective of the risk, complexity, size and frequency involved in the development activity, and/or the hosting environment.

The applicability domain of this process model is not limited to the development of in-house software only; it could also be used with the customizations and integrations performed on Commercial off-the-shelf products and solutions which are performed internally by the agency.

2.5 Conformance to Standards

This handbook endeavours to represent a systems development life cycle process model that is conformant to ISO 15288:2015 (Systems and software engineering - System life cycle processes) [1].

It would be worth highlighting that ISO 15288:2015 does not prescribe any particular life cycle models. Instead, it defines a set of processes, termed “life cycle processes”, which can be used in the definition of the system's life cycle. Also, ISO 15288:2015 does not prescribe any particular sequence of processes within the life cycle model [1].

Moreover, ISO 15288:2015 has recognized that particular projects or organizations may not need to use all of the processes provided. Therefore, implementation of this International Standard typically involves selecting and declaring a set of processes suitable to the organization or project. Accordingly, claiming “full conformance to outcomes” asserts that all of the required outcomes of the declared set of processes are achieved [1], which is what DET’s SDLC process model aims to deliver.

Figure 1 illustrates the processes that have been chosen from ISO 15288:2015 for implementation in DET’s SDLC model.

Figure 1 – Selected ISO 15288:2015 processes for implementation in DET SDLC Model (highlighted boxes)

2.6 Governance, Rigor and Quality

While one of the goals of this handbook is to clarify and define repeatable processes, it also acknowledges and appreciates the fact that the only true measure of progress on a software development project is the regular delivery of “working” software [2].

To avoid anti-patterns (e.g. the “more process is better” mindset, documentation inundation etc…), this handbook endeavours to leave the teams with as much flexibility as possible to tailor their activities as long as the outcomes highlighted in this handbook are achieved. Instead of forcing the use of documents, this handbook encourages the use of tools that can help achieve the required outcomes, controls and traceability discussed in this handbook.

Notwithstanding the fact that sign-offs at executive level can promote rigor and support governance, it’s worth highlighting that the 3^rd important dimension, “quality”, is mostly achieved at a technical level through reviews and quality assurance protocols the implementation of which can impact resourcing, planning and delivery timing; which in return, will require support and attention from executive and management levels.

2.7 Artefact-Level Sign-Offs

In this handbook, it is assumed that there are four levels of interactions with an artefact as follows:

Table 1 - Artefact interactions
Colour	Applicability Scope
Contribution	Providing and producing contents. This is usually performed at Subject Matter Expert level.
Endorsement	Supporting the maturity of the contents and affirming the approval readiness and maturity. This is usually performed at manager level. In cases where application/solution governance boards exist for the application/solution and they own sub-committees, endorsements are performed at such sub-committees to provide assurance for board approvals.
Approval	Confirming the maturity of the artefact contents. This is usually performed at director level or if applicable, at application/solution governance board level.
Noting	Being informed about the finalization, maturity and approval of an artefact. It is usually performed at an executive level.

There are cases where the risk associated with a release requires extra attention and therefore, endorsements and approvals made by individuals (as opposed to boards) may be shifted one level higher to be performed by directors and executive directors accordingly.

At the discretion of an individual approver, extra peer endorsements may also be acquired in certain circumstances.

It is necessary to version the documents according to the system release versions (please refer to “Release Versioning Conventions” for more details). For each version, a row should be added to the version history table of the artefacts with the right details in them.

Figure 2 shows a conceptual model for interactions with artefacts. An artefact can have multiple contributions from the same contributor in a single release each with separate comments. For each system/solution release, an artefact can have a unique endorsement and approval from the same endorser and approver accordingly.

Figure 2 – A conceptual model for artefact interactions

The following tables illustrate examples of how the conceptual model behind artefact interactions can be implemented in the artefacts.

Table 2 - Sample table for artefact contribution history log
System Release Version Number	Contributed by	Contribution Date	Comment	Modified Sections
e.g. 1.2
e.g. 1.2
e.g. 1.3

Table 3 - Sample table for artefact endorsement history log
System Release Version Number	Endorsed by	Endorsement Date	Comment
e.g. 1.2
e.g. 1.2
e.g. 1.3

Table 4 - Sample table for artefact approval history log
System Release Version Number	Approved by	Approval Date	Comment
e.g. 1.2
e.g. 1.2
e.g. 1.3

Table 5 - Sample table for artefact noting history log
System Release Version Number	Noted by	Noting Date	Comment
e.g. 1.2
e.g. 1.2
e.g. 1.3

2.8 Process Description

Throughout this document, all processes have been described based on the guidelines presented in ISO/IEC 24774:2010 [3].

Figure 3 illustrates a conceptual model for process description used in this handbook.

Figure 3 - Conceptual model for process description [3].

Throughout this handbook, the term “Artefact” or “Deliverable” has been used instead of “Information Item”, as seen in Figure 3.

Figure 4 - process inputs, outputs, controls and enabling mechanisms [4]

Throughout this document, a consistent colouring scheme has been used to describe stages, processes and activities as follows:

Figure 5 - Stage, process, activity colouring conventions

As will be discussed in “Process Viewpoints”, different category of releases (cloud-based vs on-prem and low risk vs. high risk scenarios), may require different steps and controls.

Activities and steps required for releases with a high level of risk have been highlighted in red for easier access.

2.9 Periodic Reviews

It is necessary to periodically review and refresh this handbook and its associated artefacts to ensure it stays relevant and up-to-date. This requires a unit dedicated to support and take ownership of all SDLC-related processes in the organization to ensure for all development activities, a consistent, valid and documented approach is taken.

The processes around the maintenance and management of systems development life cycle (including this handbook and all related artefacts) are all discussed in section 6.2.1 of ISO 15288:2015 [1] under “Life cycle model management process” and claiming full conformance to the standard requires the delivery of all outcomes involved in such a process.

3. Terms and definitions

Term	Definition
Application/Solution Governance Board	A board with members from the business and the technical development teams that provide governance over an application or solution. Such boards may include technical and non-technical sub-committees and may include members related to enabling or dependent systems/applications.
Architecting	Process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle [5].
Architecture	Fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution [5].
Architecture Description (AD)	A work product used to express an architecture [5].
Architecture Description Language (ADL)	Any form of expression for use in architecture descriptions, for example the Unified Modelling Language (UML) or ArchiMate [5].
Architecture Framework	Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders (e.g. The Open Group Architecture Framework (TOGAF), Generalised Enterprise Reference Architecture and Methodologies (GERAM), Kruchten’s 4+1 view model) [5].
Architecture View	A work product expressing the architecture of a system from the perspective of specific system concerns. A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns [5].
Architecture Viewpoint	A work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns. In other words, a viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views [5].
Business	An organizational unit that owns a solution, system or application and usually sponsors its development, maintenance and support and is as one of its important stakeholders.
Concern	Interest in a system relevant to one or more of its stakeholders [5].
Enterprise Architecture	There are two definitions for enterprise architecture: 1. The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. [Source: MIT Centre for Information Systems research] 2. A conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives [6]. This level of architecture is associated with the highest level of abstraction and lowest level of details, as opposed to Solutions Architecture and Software Architecture.
Enterprise Architecture Board	A cross-organization board to oversee the implementation of the enterprise architecture. This body should be representative of all the key stakeholders in the architecture, and will typically comprise a group of executives responsible for the review and maintenance of the overall enterprise architecture [6].
Development Activity	A set of activities with a goal to develop and deliver a ‘single’ release of a system or solution in its production environment.
Life cycle	Evolution of a system, product, service, project or other human-made entity from conception through retirement [7].
Life cycle model	Framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding [7]. The life cycle processes are based on principles of ownership (a process is associated with a responsibility) and modularity. That is, the processes are: a) Strongly cohesive, meaning that all the parts of a process are strongly related; b) Loosely coupled, meaning that the number of interfaces among the processes is kept to a minimum [4]. In a way, this SDLC handbook tries to describe DET’s systems life cycle model.
Model Kind	Conventions for a type of modelling. Examples of model kinds include data flow diagrams, class diagrams, Petri nets, balance sheets, organization charts and state transition models [5].
Pre-Verification Environment	An environment used for Business Acceptance Testing. Majority of the business units know this environment as Zone 2. Some areas of the organization call it Quality Assurance (QA) or User Acceptance Test (UAT) environment.
Process	A set of interrelated or interacting activities which transforms inputs into outputs [7].
Process outcome	An observable result of the successful achievement of the process purpose [7].
Process purpose	A high level objective of performing the process and the likely outcomes of effective implementation of the process [7].
Process View	A representation of a set of processes in a life cycle (or process model) to provide visibility to a significant concept or thread that cuts across the processes of the life cycle. Unlike a process, the description of a process view does not include activities and tasks. Instead, the description includes guidance explaining how the outcomes can be achieved by employing the activities and tasks of the various processes in an existing process model or models [3].
Process Viewpoint	What a process view conforms to. A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines how to construct and use a view (by means of an appropriate schema or template). It could be viewed as binoculars from which a process can be viewed and what is seen through it forms the view [3].
Project	An endeavour with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements [7].
Quality assurance	All the planned and systematic activities implemented within the quality system, and demonstrated as needed, to provide adequate confidence that an entity will fulfil requirements for quality [7].
Release	A particular version of a configuration item, system or application that is made available for a specific purpose (for example, test release) [7].
Release Unit	A release unit describes the portion of a service or IT infrastructure that is normally released together according to the organisation’s release policy [8].
SDLC Track	An SDLC Track is a path or trip taken between the stages within the SDLC. For each release size, a different track may be taken throughout the SDLC.
SDLC Track Processes	The processes that are specific to SDLC tracks and have to performed at the beginning of each development activity irrespective of the size of the release.
Software Architecture	The high level structure of a software system, the discipline of creating such structures, and the documentation of these structures. This level of architecture is associated with the highest level of implementation-related details and is concerned with the software architectural design patterns and paradigms (e.g. the SOLID principles).
Solution Architecture	A description of a discrete and focused business operation or activity and how IS/IT supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks [6]. Alternatively, solution architecture (SA) is an architectural description of a specific solution. SAs combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture (ESA) [Gartner (2013)]. Alternatively, defined as the architecture of a solution, where a solution is a system that offers a coherent set of functionalities to its environment. As such, it concerns those properties of a solution that are necessary and sufficient to meet its essential requirements [Greefhorst].
Stage	A period within the life cycle of an entity that relates to the state of its description or realization [7].
Stakeholder	Individual or organization having a right, share, claim or interest in a system or in its possession of characteristics that meet their needs and expectations [7].
System	A collection of components that are man-made and may be configured with one or more of the following: hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities [1].
Systems Development Technical Risk	The technical risk in systems development activities is the degree of uncertainty on the magnitude of difference between the actual and optimal design solutions. In this definition, the magnitude of difference is measured either by internal metrics of software quality or time or cost of design. From this standpoint, addressing technical risk management means to identify the magnitude of difference between optimal and current solutions, and minimize that difference as much as possible. Some example factors include multiple wishes in one requirement, inappropriate representation of requirements, untraceable requirements, notes and assumptions in requirements, unfeasible, unclear or untestable requirements, changes in requirements, adding requirements in late phases, inadequate architectural solutions, simple design mistakes, unrealistic time and cost estimates, over-flexible design which may make the solution difficult to maintain, dependence on external supplied components, dependency on other tasks, real-time performance shortfalls, error-prone, unmaintainable or unmanageable code, insufficient or ineffective testing, low number of builds on the integration branch, underestimating the delivery, mismanaging software variants, underestimation of defect turnaround time, and missing key-specialist in development [9].
Systems Development Business Risk	Systems Development Business Risk is the effect (either positive or negative) of uncertainty on business objectives caused due to the use of an IT/ICT system or solution which is under development. Business Risk management is the coordination of activities that direct and control the department with regard to risks (AS/NZS ISO 31000:2009 Risk management).
User	An individual or group that benefits from a system during its utilization [7].
Validation	Validation in a life cycle context is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals and objectives [7]. The Validation process determines that the right product is built [1].
Verification	Verification in a life cycle context is a set of activities that compares a product of the life cycle against the required characteristics for that product. This may include, but is not limited to, specified requirements, design description and the system itself [7]. The Verification process determines that the product is built right [1].

4. Process Viewpoints

In order to demonstrate how certain goals for certain scenarios (e.g. developing high-risk systems) are achieved through the use of this SDLC process model, the process model can be viewed from different viewpoints. This chapter describes a number of such viewpoints from which different concerns related to systems development activities are addressed. The view seen out of the SDLC process model from each viewpoint will demonstrate how those goals are achieved in such scenarios.

These definitions and their properties have been aligned to ISO 24774:2010 [3].

4.1 Release Size

4.1.1 Overview

As a property of a release (or the development activity that delivers the release), size is defined to the amount of work that is involved in the development activity. In order to cover all sizes, certain “tracks” in the life cycle model can be gone through covering certain stages for each release size.

For release size categorization, it is recommended for the Information and Technologies Branch (ITB) to partially use the definitions in ITIL [8], as follows, however, other areas of the agency may still use their existing labels, which is why a size mapping table will be presented later in this handbook to avoid confusion.

Major releases and hardware upgrades, normally containing large areas of new functionality, some of which may make intervening fixes to problems redundant. A major upgrade or release usually supersedes all preceding minor upgrades, releases and maintenance fixes.
Minor releases and hardware upgrades, normally containing small enhancements and fixes, some of which may have already been issued as maintenance fixes. A minor upgrade or release usually supersedes all preceding maintenance fixes.
Maintenance[1] releases, normally containing the corrections to a small number of known problems.

4.1.2 Process Viewpoint Stakeholders

SDLC users (program managers, project managers, systems and software developers, database administrators, solutions architects etc…)
Department of Education

4.1.3 Process Viewpoint Concerns

As a process model, the SDLC should be agile enough to allow the development teams perform their routines in a timely fashion with the minimum but most effective level of governance.
The SDLC should be able to cover all types of systems development activities, especially business as usual and maintenance-related activities, not just projectized activities.
The SDLC should provide controls, rigor, governance and accountability for any releases deployed in the production environment.

4.1.4 Release Sizes and Size Mappings

In order to keep the SDLC generic and help it be applicable in different areas of the organization and due to existing release type labels for some areas and to avoid confusion, a generic set of labels (type 1, type 2 and type 3) will be used in this handbook that could be mapped to existing labels in each area, as Table 6 illustrates.

SDLC Release Size Label	Information and Technologies Branch Release Type Label	Finance Branch Release Type Label	Human Resources Branch Release Type Label
Type 1	Major	Project	Major
Type 2	Minor	Major, Significant	Major
Type 3	Maintenance/Bug Fix	Minor, Emergency, Adhoc	Maintenance/Bug Fix

Table 6 - release sizes and size mappings for different areas of the organization

Despite these definitions being subjective, there are a number of criteria that can help the development teams determine which category of release they should choose as it affects the governance model and supporting artefacts applicable.

One distinguishing difference between Type 3 releases as opposed to Type 2 is the fact that for Type 3 releases, the requirements do not change. Consequently, in scenarios where requirements are being changed or there are new requirements, the choices will be limited to either Type 1 or Type 2 releases.

NOTE: The first release of a system that has never existed before is considered a Type 1 release irrespective of its actual size.

You can refer to section “‎7.11.5.2” which explains the release planning and size determination process in details.

4.1.5 Release Versioning Conventions

It is highly recommended to follow a unified versioning convention that is aligned with the release types discussed in this handbook.

Due to a 3-level categorization scheme, it is recommended to use 3 numbers for each release that could match the Major[.Minor][.Maintenance] convention (e.g. 3 for a Type 1 release, or 3.1 for a Type 2 release or 3.1.2 for a Type 3 release).

4.1.6 Release Units

A release unit describes the portion of a service or IT infrastructure that is normally released together according to the organisation’s release policy. The unit may vary, depending on the type(s) or item(s) of service asset or service component such as software and hardware.

The general aim is to decide the most appropriate release unit level for each service asset or component, however, as a general principle, it is highly necessary to avoid bundling releases with high risk profiles with low-risk releases as this will turn the bundle into a high-risk bundle.

4.2 Risk

4.2.1 Overview

Risk is a characteristic of a release under development and how the SDLC addresses different levels of it is viewed through this viewpoint.

Risk of a release can be defined against a number of criteria in two aspects (business risks as opposed to technical risks) as highlighted in DET Enterprise Risk Management Framework Risk Assessment Criteria , including

How high-profile a system is in terms of popularity and media influence (reputational aspects).
How critical the system is in providing key business outcomes (e.g. the delivery of lessons at school or the processing of payroll for staff)
Whether or not the system deals with protected or highly-protected data the compromise of which could be severely costly for the public or the department.
Whether or not the system is integrated with and/or sends/receives protected, highly-protected data or financial data to/from external systems from other agencies and organizations.

From the risk perspective, irrespective of other perspectives like size, the SDLC should apply different levels of control and rigor on pre-production readiness definitions, criteria and examinations.

This viewpoint is another dimension over the SDLC besides others (like size) and ensures any change, irrespective of size, covering a system, or a module, with high Risk, will go through extra steps while mandating extra artefacts before production readiness is achieved.

4.2.2 Process Viewpoint Stakeholders

SDLC users (program managers, project managers, systems and software developers, database administrators, solutions architects etc…)
Department of Education

4.2.3 Process Viewpoint Concerns

The SDLC should remain agile enough for business as usual activities.
The SDLC should not create extra red tapes in daily business operations.
The SDLC should provide a consistent set of definitions and artefacts for each Risk level.
The SDLC should cover all types of systems development activities, especially business as usual and maintenance-related activities, not just projectized activities.
The SDLC should provide the optimum and effective level of rigor before a release is deployed in the production environment, especially for systems where there’s a very low levels of tolerance for risk.

4.3 Hosting/Deployment Environment

4.3.1 Overview

Hosting/deployment environment is another property of a release under development and how the SDLC addresses different environments is viewed through this perspective.

4.3.2 Process Viewpoint Stakeholders

SDLC users (program managers, project managers, systems and software developers, database administrators, solutions architects etc…)
Department of Education

4.3.3 Process Viewpoint Concerns

The SDLC should address and cover the different paths needed to be taken for cloud-based development.
Since majority of platform-as-a-service environments keep changing frequently without DET’s control, it’s vital that the SDLC remains agile and provides the chance for the development teams to catch up with the demand of an ever-green hosting environment.
The SDLC should ensure that all procedures around development for the cloud remain consistent, clear and documented.

5. SDLC Conceptual Model

Throughout this handbook, a set of concepts have been used based on a conceptual model depicted in Figure 6. It is highly recommended to fully understand this model as it will be the foundation behind all the rules and definitions in this handbook.

Figure 6 - SDLC Conceptual Model

As can be seen in Figure 6, a system-of-interest can be conceptualized as a number of releases, each of which can be categorized in size, risk and hosting environment “dimensions”.

Each release is delivered by one development activity (in which one or more teams or individuals could be involved) and each development activity is carried out through traversing between SDLC stages, each trip to be called an SDLC Track.

An SDLC Track is a path or trip taken between the stages within the SDLC and as will be discussed in section “‎7.1”, for each release size, a different track may be taken throughout the SDLC.

Each SDLC track owns a number of SDLC-track-specific processes that should be carried out irrespective of the size of the release (i.e. Life cycle model management process, information classification, business risk assessment, and cloud suitability assessment). Depending on the size of the release (major, minor, maintenance), different types of SDLC tracks may be applicable which will accordingly mandate different artefacts to be delivered with the release.

At the end, each SDLC track contains a number of SDLC stages, each of which owns its processes, controls and artefacts. It is assumed that leaving one stage and traversing to another stage requires the controls of the current stage to be fulfilled and the artefacts to be updated or produced.

Apart from “size”, releases are also categorized from the perspective of “risk” which then alters the level of rigor and controls applicable at each SDLC stage. Different colouring schemes have been used to highlight specific controls that may be applicable with certain risk profiles as explained in “Process Description”.

6. SDLC Principles

In support of the SDLC conceptual model, there are a number of principles the SDLC is built upon, as follows:

6.1 SDLC Stage Controls

Statement:

Before moving to the next SDLC stage, the controls of the current stage should be fulfilled.

Rationale:

Having the controls at the end of each SDLC stage is what makes a stage different from just a bundle of processes since it underlines a specific period throughout the lifetime of a system (or a release) in DET’s environment. These check points support transparency and encourage consistency and traceability throughout the development activities. Depending on the risk of the release, different controls may be applicable.

Implications:

The development teams and the governing bodies may require extra time and resources to ensure stage controls are applied and fulfilled.

6.2 Freedom in Tailoring the SDLC Artefacts

Statement:

As long as the outcomes of each SDLC process are achieved, the development teams are free to define their own artefact templates or use the tools that support achieving the outcomes without physical documentation.

Rationale:

As discussed in “Conformance to Standards”, DET SDLC Process Model claims conformance to ISO 15288:2015 [1] at outcomes level which requires the process outcomes to be achieved in full.

Implications:

The achievement of the process outcomes is a mandatory requirement and the ultimate true/false detector. A good balance between agility and governance can be achieved but not at the cost of lack of governance or documentation. The development teams should be aware that the process outcomes also provide the traceability that could be of great value, should the need arises.

6.3 Artefact and Document Versioning

Statement:

All SDLC artefacts and documents must be versioned in accordance to system/solution release version numbers for clarity, transparency and traceability purposes while each release can have its own independent documents based on the discretion of the development teams.

Rationale:

Release managers, change managers and other governance bodies may use such commonality as a criterion that illustrates the artefacts have been updated as required. It also helps establish traceability for forensic purposes.

Implications:

In case tools are used instead of documents, limitations may be faced depending on whether or not such tools can provide such identification/versioning mechanisms.

6.4 Risk Level in Release Bundles

Statement:

The highest risk level included in a release bundle applies to the whole release bundle.

Rationale:

The risk level is a factor that defines the rigor and changes many of the SDLC workflows. It is acknowledged that bundling releases for different purposes (e.g. calendar restrictions and timing alignment) is a common practice and the SDLC does not discourage release bundling, however, such bundling should be performed for releases that have the same level of risk. It would be sensible to manage an individual high-risk release on its own without being bundled with other high-risk releases for consistency, transparency and traceability purposes.

Implications:

Extra time or resources may be required to support the isolation between releases of different risk levels.

6.5 Risk Level in Iterative Development

Statement:

The risk level can change in iterative development where changes are introduced incrementally and such changes have to be managed.

Rationale:

The risk level is a factor that defines the rigor and changes many of the SDLC workflows. Even though “Risk Assessment Process” should be performed at the beginning of a development activity, however, such risks must be re-assessed in each iteration to ensure minor incremental changes and their impacts are managed properly.

Implications:

The rigor being applied to the documentation may change during iterative development work as a consequence of the risk level getting changed which may require extra time or resources. Project managers and owners should be aware of such implications and update their schedules accordingly or alternatively, leave such changes for future releases.

6.6 Information Classification Changes in Iterative Development

Statement:

The information classification of data entities involved in iterative development may change and has to be re-assessed where changes are introduced incrementally.

Rationale:

Even though “Preliminary Information Classification Process” should be performed at the beginning of a development activity, however, such classifications must be re-assessed in each iteration, if the data models are changed, to ensure minor incremental changes and their impacts are managed properly.

Implications:

The project managers and owners should be aware that if information classification re-assessment becomes necessary, it may require extra time or resources and this can affect project delivery and schedules.

7. SDLC Overview

Figure 7 illustrates an overview of the systems development life cycle stages and its links to ICT change/release process model and ICT project life cycle. The stages explained in this handbook are partially aligned with the definitions and examples mentioned in ISO/IEC 24748-1:2010 (Systems and software engineering - Life cycle management - Part 1 - Guide for life cycle management) [4].

Figure 7 - SDLC Overview

7.1 SDLC Tracks

As can be seen in “Figure 6 - SDLC Conceptual Model” and “Figure 7 - SDLC Overview”, an SDLC Track is a path taken between the stages within the SDLC. Such a traversal of stages results in a single release which could be of Type 1, Type 2 or Type 3. For each release size, a different track may be taken throughout the SDLC starting from and ending at different stages. For each SDLC track, specific processes may be required apart from the process included in the relevant SDLC track stages. Such SDLC track processes are performed at the beginning of each development activity.

NOTE: Each release track represents a view of the whole SDLC addressing the work required for a specific release size. In this sense, each release track could be considered as a process view, as explained in [3].

7.1.1 Type 1 Release Track

This SDLC track covers Type 1 releases which depending on the business area could cover specific release sizes and labels (i.e. in Information and Technologies and Human Resources Branches, it is mapped to Major releases and in Finance Branch, it is mapped to Projects as “Table 6 - release sizes and size mappings for different areas of the organization” illustrates).

This track starts from the Needs stage and ends at the Deployment stage and accordingly, such releases will require the artefacts and controls highlighted in all the included stages.

NOTE: For Type 1 releases, it’s mandatory to go through the Transition Process and the Validation Process in the Deployment stage to ensure the benefits of the solution are fully realized.

Figure 8 – SDLC Stages in a Type 1 Release Track

7.1.2 Type 2 Release Track

This SDLC track covers Type 2 releases which depending on the business area could cover specific release sizes and labels (i.e. in Information and Technologies and Human Resources Branches, it is mapped to Minor releases and in Finance Branch, it is mapped to Major/Significant releases as “Table 6 - release sizes and size mappings for different areas of the organization” illustrates).

This track starts from the Requirements stage and ends at the Deployment stage and accordingly, such releases will require the artefacts and controls highlighted in all the included stages.

Figure 9 – SDLC Stages in a Type 2 Release Track

7.1.3 Type 3 Release Track

This SDLC track covers Type 3 releases which depending on the business area could cover specific release sizes and labels (i.e. in Information and Technologies and Human Resources Branches, it is mapped to Maintenance/Big Fix releases and in Finance Branch, it is mapped to Minor, Emergency, Adhoc releases as “Table 6 - release sizes and size mappings for different areas of the organization” illustrates).

This track starts from the Analysis and Design Stage and ends at the Deployment stage and accordingly, such releases will require the artefacts and controls highlighted in all the included stages.

NOTE: The important aspect of Type 3 releases is that with them, the requirements do not change. The goal of such releases is to fix issues and problems and ensure the requirements are fulfilled properly, rather than implementing new requirements.

NOTE: In majority of cases, practically, the work to fix bugs and/or do maintenance work starts from the Implementation stage, however, there are also cases where in order to fix a persistence issue, the design should be changed accordingly. That’s why a more inclusive scenario has been selected for this release type. Obviously, if the design is not changed, then some of the processes in this stage can be skipped even though processes like “System Analysis Process” and “Iteration Planning Process” may still be applicable.

Figure 10 – SDLC Stages in a Type 3 Release Track

7.2 Environments Used Throughout the SDLC

Throughout the SDLC, different controlled environments are used by systems developers to build, distribute, install, configure, test, and execute systems that move through the SDLC stages. Each environment has specific purposes that make them suitable for certain stages of the SDLC, as follows:

Environment	Description
Zone 1 (Development)	Developers use this environment to develop and test their codes and scripts and ensure their health and correctness. This is the environment in which the “Alpha” version of a release is deployed in.
Zone 2 (User Acceptance Testing, Quality Assurance)	Business representatives and stakeholders use this environment to test the solutions against their original business requirements. This environment is mostly used in throughout the Test stage. This is the environment in which the “Beta” version of a release is deployed into.
MPE (Mirrored Production Environment, Staging)	This environment is used by those performing the deployment to ensure the health of the deployment package before deployment into production. Ideally, this environment should act as a staging environment and be a complete identical copy. This is the environment in which the “Candidate” version of a release is deployed into.
Production	This is the environment where solutions finally are deployed to, for final use by their intended end users.
Training	This environment is used by the business stakeholders and support staff or developers for training purposes.
Disaster Recovery	This environment is used for disaster recovery purposes.

Table 7 – Environments used throughout the SDLC

7.3 SDLC Track Processes

As illustrated in the SDLC conceptual model (Figure 6), depending on the size of the development activity and/or release, different stages of the SDLC are traversed and therefore, different types of artefacts and controls will be applicable. However, there are processes that should be performed irrespective of the size of development activity and/or release. These processes are those that are carried out per development activity and are described as follows.

Life Cycle Model Management Process

7.3.1.1 Purpose

The purpose of the Life Cycle Model Management process is to assure availability of policies, life cycle processes, life cycle models, and procedures for use by the development teams. This process provides life cycle policies, processes, models, and procedures that are consistent with the organization's objectives, that are defined, adapted, improved and maintained to support individual project needs within the context of the organization, and that are capable of being applied using effective, proven methods and tools.

This process is aligned with “Life Cycle Model Management Process” of ISO 15288:2015 [1].

NOTE: If the presence of the release has been established in SDLC tools and all members are aware of the organizational policies and procedures they should follow, this process can be skipped. The team leaders should assure all team members are aware of the organizational procedures and routines.

NOTE: As part of the Life Cycle Model Management Process and team members’ induction, it’s important to be aware of the limitations and preferences around the use of open-source libraries in the agency. Further details can be found in section XXX.

7.3.1.2 Outcomes

The outcomes of the Life cycle model management process are as follows:

Organizational policies and procedures for the management and deployment of life cycle models and processes are accessed and introduced to the development teams.
Responsibility, accountability, and authority within teams are clarified.
Prioritized process, model, and procedure improvements are implemented.
Development teams establish the presence of the release they are planning to deliver in the corresponding SDLC systems.

7.3.1.3 Work Breakdown Structure

Figure 11 illustrates the work breakdown structure of the Life Cycle Model Management Process.

Figure 11- The work breakdown structure of the Life Cycle Model Management Process

7.3.1.4 Workflow

Figure 12 illustrates the workflow of the Life Cycle Model Management Process.

Figure 12 - The workflow of the Life Cycle Model Management Process

7.3.1.5 Open-Source Libraries and License Types

DET follows the Open-Source Policy developed by the Queensland Government Chief Information Office . Aligned with that, it is possible to make use of open-source libraries while developing systems and software provided that the terms of conditions of the relevant licences are followed, which in majority of cases include the need to ship a copy of the original licence and to mention the copyright owner’s name. Such details could be included in a specific page or screen to contain legal information related to the system or release.

There are different sources available to know about different licence types and their limitations including the one at http://choosealicense.com/appendix/ . It is highly recommended for team leaders to ensure their teams are exposed to these details prior to making a decision on using or not using open-source libraries, which will be reviewed as part of the “Design Review Process” and “Code Review Process”, however, early decisions should be made with enough insight.

NOTE: As part of the terms and conditions related to some license types like all GNU General Public (GPL) Licenses, Mozilla Public License 2.0, Open Software License 3.0, Microsoft Reciprocal License, LaTeX Project Public License v1.3c, European Union Public License 1.1, and Eclipse Public License 1.0, if any libraries published under such licenses are used to build a system, it becomes mandatory to make the whole codebase public for such systems, if the system is “distributed”.

A mobile app being physically installed on a device certainly constitutes “distribution”, however, there’s still debate around whether or not deploying code or binaries on web servers for web-based solutions can constitute “distribution”. There are specific license types like Affero General Public License v3.0 (AGPL), European Union Public License 1.1 and Open Software License 3.0 that consider a “network use” as “distribution” and therefore should be “avoided” by default, unless the agency is prepared to consider making the codebase of solutions using such libraries public, even when they are used in web-based solutions deployed only on web servers, not on end users’ devices.

There are cases where GNU Lesser General Public License (LGPL) libraries in dynamically-linked compiled setups (e.g. dynamically-linked libraries (DLLs), or JARs) can be used to build distributed solutions without needing to make the whole codebase public, as the requirements for statically vs dynamically linked modules highlight. Either way, the LGPL license mandates the possibility for end users to be able to modify the LGPL library, compile it and re-link the entire binaries to build the final solution and that’s why dynamic linking can make things a lot easier in this instance.

NOTE: Apart from the details provided in this manual (obviously to be considered as a guide only with no ‘assurance’), further legal consultation may be required to ensure all the terms and conditions involved with the use of open-source libraries have been fully followed and fulfilled, especially around the use of restrictive licenses like GPL. As an easier alternative, it would be recommended to avoid such libraries and instead use more permissive options like MIT, BSD, and Apache-licensed libraries.

Preliminary Information Classification Process

7.3.2.1 Purpose

The purpose of the Preliminary Information Classification Process is to identify high-level data entities involved with the system-to-be or release and identify the classification level applicable to them. The outcomes of this classification practice is used as a criterion to determine the risk related to the system-to-be or release which consequently affects the rigor and governance around system or release.

NOTE: The Preliminary Information Classification Process is owned and performed by Information Management Authority in DET and is performed according to DET’s information management policy and procedures.

NOTE: The Preliminary Information Classification Process is categorized under SDLC Track processes to be performed at the beginning of each development activity, however, during iterative development, the need to re-asses classifications is determined by the development teams through the “System Analysis Process” in the “Analysis and Design Stage” to ensure the right decision-making criteria are used throughout the development activity.

This process is aligned with Decision Management Process in ISO 15288:2015 [1].

7.3.2.2 Outcomes

The outcomes of the Preliminary Information Classification Process are as follows:

High-level data entities of the system-to-be or the release are identified.
High-level data types are identified.
Classification applicable to each data entity or field (entity property) is determined.
The location of certain data is determined.
Possible access levels are identified.
Data protection levels and legislative concerns and limitations are identified.
The outcomes of the classification process will support the generation of an information classification report to guide the “Risk Assessment Process”.

7.3.2.3 Work Breakdown Structure

Figure 13 illustrates the work breakdown structure of the Preliminary Information Classification Process.

Figure 13 - The work breakdown structure of the Preliminary Information Classification Process

7.3.2.4 Workflow

Figure 14 illustrates the workflow of the Preliminary Information Classification Process.

Figure 14 - The workflow of the Preliminary Information Classification Process

7.3.2.4.1 Artefacts

Table 8 lists the artefacts of the Preliminary Information Classification Process.

Artefact	Description
Information Classification Report	An artefact to include the decision outcomes and rationale of the information classification process.

Table 8 - Preliminary Information Classification Process Artefacts

Preliminary Cloud Assessment Process

7.3.3.1 Purpose

The purpose of the Preliminary Cloud Assessment Process is to support structured and documented decision making in regards to assessing the suitability and feasibility of using cloud services or cloud hosting for a release.

NOTE: The Preliminary Cloud Assessment Process is owned and performed by Cloud Assessment Authority in DET and is performed according to DET’s cloud suitability assessment policy and procedures.

NOTE: This process only applies to releases that are supposed to utilize cloud services and/or hosting for the first time, or alternatively, to releases in which existing cloud services and/or hosting arrangements are being changed in such a way that the new services and/or hosting arrangements may pose new risks, or in any case where a decision to utilize a particular cloud service or hosting arrangement should be documented and justified. For example, this process may be applicable to development activities involving existing on-premise systems whose new releases may include cloud-based components.

This process is aligned with the Decision Management Process of ISO 15288:2015 [1].

7.3.3.2 Outcomes

The outcomes of the Preliminary Cloud Assessment Process are as follows:

The suitability of cloud services and/or cloud hosting for the system-to-be or related releases is determined and compiled into a report.
The decision making process and the rationale behind decisions to use cloud-based services for a solution or a release is documented.
The traceability to the decision making criteria and logic is established, should forensic investigation be required in case of cloud-related incidents.

7.3.3.3 Work Breakdown Structure

Figure 15 illustrates the work breakdown structure of the Preliminary Cloud Assessment Process.

Figure 15 - The work breakdown structure of the Preliminary Cloud Assessment Process

7.3.3.4 Workflow

Figure 16 illustrates the workflow of the Preliminary Cloud Assessment Process.

Figure 16 - The workflow of the Preliminary Cloud Assessment Process

7.3.3.4.1 Artefacts

Table 9 lists the artefacts of the Preliminary Cloud Assessment Process.

Artefact	Description
Cloud Assessment Report	An artefact to include the decision outcomes and rationale of the cloud assessment process.
Cloud-Based Development General Briefing Note	An artefact aimed for noting by senior business executives to highlight the aspects of a cloud-based development.

Table 9 - Preliminary Cloud Assessment Process Artefacts

Risk Assessment Process

7.3.4.1 Purpose

The purpose of the Risk Assessment Process is to assess and determine the risk associated with the system-to-be or the release for effective decision making and employing different levels of rigor and controls accordingly.

The generic term “risk” in the context of systems development has two aspects: Technical Risk and Business Impact Risk.

As defined thoroughly in “Terms and definitions”, technical risk in systems development activities is the degree of uncertainty on the magnitude of difference between the actual and optimal design solutions [9]. On the other hand, business risk is the effect (either positive or negative) of uncertainty on business objectives caused due to the use of an IT/ICT system or solution which is under development. The nature of these risks is different but the SDLC views both categories at the same level of importance.

NOTE: Business Impact Risk Determination is owned and performed by the business with the support from development teams and must be performed at the beginning of each development activity, irrespective of all other types or categories of the release. Obviously, the business owning the system or module are the best to answer the questions that determine the risk profile of a release related to that system or module. Development teams should avoid making assumptions and should ensure that the Release Risks/Issue Register is approved and signed off by the business.

NOTE: The Risk Assessment Process is categorized under SDLC Track processes to be performed at the beginning of each development activity, however, during iterative development, the risk is re-assessed through the “System Analysis Process” in the “Analysis and Design Stage” to ensure the right decision-making criteria are used throughout the development activity and that the real risks resulted by incremental changes are managed properly.

NOTE: As discussed under “SDLC Principles”, the highest risk level within a release bundle applies to the whole bundle.

NOTE: It is recommended to isolate high-risk releases and manage them independently from other releases for transparency and traceability purposes.

NOTE: As per enterprise policies, it is necessary to use the Enterprise Risk Management Framework to determine the business impact risk levels throughout systems development activities.

NOTE: More information about Enterprise Risk Management Framework can be found on “Risk Assessment Criteria” , “Risk Matrix” , and “Enterprise Risk Management Framework” documents.

NOTE: Notwithstanding the fact that traditionally risk exposure (i.e. the product of probability or likelihood times potential loss or consequence for a risk factor) is used as a determinant for the real quantifiable risk, it is understood that in many cases, it must be attempted to avoid the occurrence of consequences resulted by IT/ICT systems failure even once, which leads us to using the “consequence” as a quantifiable risk determinant irrespective of the likelihood (in the context of systems development).

This process is aligned with the Decision Management Process and Risk Management Process in ISO 15288:2015 [1].

7.3.4.2 Outcome

As the outcomes of the successful implementation of the Risk Assessment Process, the risk level associated with the release is determined and a report is compiled accordingly.

7.3.4.3 Technical Risk Level Determination Matrix

Table 10 illustrates a list of risk factor categories and a description of scenarios where risks related to these categories are significant.

Technical Risk Factor Category â	Significant Risk	Insignificant Risk
Requirements	When any of the followings happen: · multiple wishes in one requirement · inappropriate representation of requirements · untraceable requirements · notes and assumptions in requirements · unfeasible, unclear or untestable requirements · changes in requirements · adding requirements in late phases	Any other case.
Design	When any of the followings happen: · inadequate architectural solutions · simple design mistakes · error-prone unmaintainable or unmanageable code · insufficient or ineffective testing · real-time performance shortfalls · low number of builds on the integration branch · mismanaging software variants · There are portions and modules of the release or system that are very complex to implement.	Any other case.
Time and budget	When any of the followings happen: · unrealistic time and cost estimates · over-flexible design which may make the solution difficult to maintain · dependence on external supplied components · dependency on other tasks · underestimating the delivery · underestimation of defect turnaround time · missing key-specialist in development	Any other case.

Table 10 – Technical Risk Levels Matrix

7.3.4.4 Combined (Technical and Business) Risk Determination Matrix

Table 11 illustrates the combined overall risk levels associated with a release based on the Business Risk Consequence Level which is determined using “Risk Assessment Criteria ” and the technical risk which is determined using “Table 10”.

Business Risk Consequence Levelà (Determined thru “Risk Assessment Criteria ”) Technical Risk Level â (Determined thru Table 10)	Insignificant	Minor	Moderate	Major	Critical
Insignificant	Low	High	High	High	High
Significant	Low	High	High	High	High

Table 11 – Combined (Technical and Business) Risk Determination Matrix

Values in Table 11 should be used in order to determine the combined risk associated with a release throughout different stages of the development activity.

7.3.4.5 Work Breakdown Structure

Figure 17 illustrates the work breakdown structure of the Risk Assessment Process.

Figure 17- The work breakdown structure of the Risk Determination Process

7.3.4.6 Workflow

Figure 18 illustrates the workflow of the Risk Determination Process.

Figure 18 - The workflow of the Risk Determination Process

7.3.4.6.1 Artefacts

Table 12 lists the artefacts of the Risk Determination Process.

Artefact	Description
Release Risks/Issue Register	An artefact to include a list of risks and issues pertaining to the release.

Table 12 - Risk Determination Process Artefacts

7.4 Needs Stage

7.4.1 Overview

During this stage, an idea or a need for a new or improved system is identified and determined. This stage begins when management determines that it is necessary to enhance a business process through the application of information technology. A top-level idea definition artefact is developed, along with a review of such items as the cost, criticality, and feasibility of the intended system.

NOTE: The traceability back to the idea definition which should be supported and approved by the business is an important by-product of going through this stage. It is highly recommended to development teams to go through this stage as part of a “Type 1 Release Track” when it’s sensed that such traceability may add value, irrespective of development activity or release size.

7.4.2 Purpose

The Needs Stage is executed to assess new business opportunities and to develop preliminary high-level requirements of the system-to-be.

7.4.3 Artefacts

Table 13 lists the artefacts of the “Needs” stage.

Artefact	Description	Template Trim Reference
Idea Definition Document	An artefact to contain an overview of the business opportunity, high-level solution idea, options available, as well as stakeholders identified.	TBD

Table 13 - Needs Stage Artefacts

7.4.4 Controls

Table 14 lists the controls required for the “Needs” stage to be fulfilled.

Control
The Idea Definition Document must be approved by all relevant parties before this stage could be considered fulfilled.
The custodians of enabling or related systems/solutions should provide their support of the idea.
The initial feasibility study to demonstrate whether or not the idea is implementable as part of an improvement or new module for an existing solution should be performed at a Solution Architecture level, pertaining to the solution.
The alignment of the proposed implementation of the need/idea to enterprise architecture and the evaluation of where the idea could be implemented (i.e. in which existing solution, if applicable) should be verified by the Enterprise Architecture Board.
For development activities pertaining to releases with a high level of Risk, Idea Definition Document must be signed off by a representative from all different stakeholder groups (e.g. external agencies, if applicable).
For development activities covering releases with a high level of Risk, Idea Definition Document must be signed off at executive level.

Table 14 - Needs Stage Controls

7.4.5 Stage Processes

High-Level Idea Definition Process

7.4.5.1.1 Purpose

The purpose of the High-Level Idea Definition Process is to define the business or mission problem or opportunity, characterize the solution space, and determine potential solution class(es) that could address a problem or take advantage of an opportunity.

This process is aligned with the Business or Mission Analysis Process in ISO 15288:2015 [1].

NOTE: Part of this process involves the identification of stakeholders. Stakeholders include, but are not limited to, users, operators, supporters, developers, producers, trainers, maintainers, disposers, external organizations who have interests or concerns in the system, parties responsible for external interfacing entities, regulatory bodies and members of society. Where direct communication is not practicable, e.g., for consumer products and services, representatives or designated proxy stakeholders are selected [1].

It is highly recommended to note that stakeholders include internal users are not limited to them only and in all cases, external agencies who have interests or concerns over an internal system may well be among the stakeholders whose initial approval and support of an idea needs to be well established.

7.4.5.1.2 Outcomes

The outcomes of the High-Level Idea Definition Process are as follows:

Stakeholders of the system-to-be and their classes are identified.
The problem or opportunity space is defined.
The solution space is characterized.
Preliminary operational concepts and other concepts in the life cycle stages are defined.
Candidate alternative solution classes are identified and analyzed.
The preferred candidate alternative solution class(es) are selected.
Any enabling systems or services needed for business or mission analysis are available.
Traceability of business or mission problems and opportunities and the preferred alternative solution classes is established.

7.4.5.1.3 Work Breakdown Structure

Figure 19 illustrates the work breakdown structure for the High-Level Idea Definition Process.

Figure 19 - Work breakdown structure for the High-Level Idea Definition Process

7.4.5.1.4 Workflow

Figure 20 illustrates the workflow for the High-Level Idea Definition Process.

Figure 20 - High-level idea definition process workflow

7.4.5.1.5 Artefacts

Table 13 lists the artefacts of the high-level idea definition process.

Artefact	Description
Idea Definition Document	An artefact to contain an overview of the business opportunity, high-level solution idea, options available, as well as stakeholders identified.

Table 15 - High-level idea definition process artefacts

7.5 Concept Stage

7.5.1 Overview

The Concept Stage begins with initial recognition of a need or a requirement for a new system-of-interest or for the modification to an existing system-of-interest. This is an initial exploration, fact finding, and planning period during which the need or idea is framed into a project or work package.

7.5.2 Purpose

The purpose of this stage is to transition a need or an idea into a project or a work package after the required checks and controls are applied.

7.5.3 Artefacts

Table 16 lists the artefacts of the “Concept” stage.

Artefact	Description	Template Trim Reference
Product Vision/Roadmap	An optional artefact to contain a high-level roadmap for the solution. For solutions with a long life in DET’s environment (e.g. OneSchool), this artefact may already exist and is kept alive once modules or components are added to the solution.	TBD
Terms of Reference Document	An artefact to describe the purpose and structure of a project and highlight the responsibilities and commitments of the sponsors and the development teams.	TBD
Project Brief Document	An artefact to contain the results of a projectization effort.	TBD
Preliminary Business Requirements Specification	An artefact to contain preliminary business requirements.	TBD

Table 16 - Concept Stage Artefacts

7.5.4 Controls

Table 17 lists the controls required for the “Concept” stage.

Control
All artefacts must be approved by all relevant parties before this stage could be considered fulfilled.
For development activities covering releases with a high level of Risk, the project brief document must be signed off at executive level.

Table 17 - Concept Stage Controls

7.5.5 Stage Processes

Preliminary Business Requirements Specification Process

7.5.5.1.1 Purpose

The purpose of the Preliminary Business Requirements Specification Process is to define the requirements for a system/solution that can provide the services needed by users and other stakeholders in a defined environment. It analyzes and transforms these into a common set of stakeholder requirements that express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational service is validated in order to confirm that the system fulfils the needs.

This process is aligned with the Stakeholder Needs and Requirements Definition Process in ISO 15288:2015 [1].

7.5.5.1.2 Outcomes

The outcomes of the Preliminary Business Requirements Specification Process are as follows:

Required characteristics and context of use of capabilities and concepts in the life cycle stages, including operational concepts, are defined.
Constraints on a system are identified.
Stakeholder needs are defined.
Stakeholder needs are prioritized and transformed into clearly defined stakeholder requirements.
Critical performance measures are defined.
Stakeholder agreement that their needs and expectations are reflected adequately in the requirements is achieved.
Traceability of stakeholder requirements to stakeholders and their needs is established.

7.5.5.1.3 Work Breakdown Structure

Figure 21 illustrates the work breakdown structure of the Preliminary Business Requirements Specification Process.

Figure 21 - Work breakdown structure of the Preliminary Business Requirements Specification Process

7.5.5.1.4 Workflow

Figure 22 illustrates the workflow of the Preliminary Business Requirements Specification Process.

Figure 22 - Preliminary Business Requirements Specification Process workflow

7.5.5.1.5 Artefacts

Table 18 lists the artefacts of the Preliminary Business Requirements Specification Process.

Artefact	Description
Preliminary Business Requirements Specification	An artefact to contain preliminary business requirements.

Table 18 - Preliminary Business Requirements Specification Process Artefacts

Projectization and Planning Process

7.5.5.2.1 Purpose

The purpose of the Projectization and Planning Process is to scope the work into a project or work package and produce and coordinate effective and workable plans. This process determines the scope of the project management and technical activities, identifies process outputs, tasks and artefacts, establishes schedules for task conduct, including achievement criteria, and required resources to accomplish tasks.

NOTE: This could be an on-going process that continues throughout a project, with regular revisions to plans, especially for iterative development. The “Iteration Planning Process” in the “Analysis and Design Stage” includes steps to ensure planning remains a continued practice for non-projectized activities for type 2 and type 3 releases as well as iterative development.

This process is aligned with the Project Planning Process in ISO 15288:2015 [1].

7.5.5.2.2 Outcomes

The outcomes of the Projectization and Planning Process are as follows:

Scope of work is identified.
Objectives and plans are defined.
Roles, responsibilities, accountabilities, authorities are defined.
Resources and services necessary to achieve the objectives are formally requested and committed.
Plans for the execution of the project are activated.

7.5.5.2.3 Work Breakdown Structure

Figure 23 illustrates the work breakdown structure of the Projectization and Planning Process.

Figure 23 - Work breakdown structure of the Projectization and Planning Process

7.5.5.2.4 Workflow

Figure 24 illustrates the workflow of the Projectization and Planning Process.

Figure 24 - Projectization and Planning Process workflow

7.5.5.2.5 Artefacts

Table 19 lists the artefacts of the Projectization and Planning Process.

Artefact	Description
Product Vision/Roadmap	An optional artefact to contain a high-level roadmap for the solution (for solutions with a long life in DET’s environment (e.g. OneSchool), this artefact may already exist and is kept alive once modules or components are added to the solution).
Terms of Reference Document	An artefact to describe the purpose and structure of a project and highlight the responsibilities and commitments of the sponsors and the development teams.
Project Brief Document	An artefact to contain the results of a projectization effort.

Table 19 - Projectization and Planning Process Artefacts

7.6 Requirements Stage

7.6.1 Overview

During the Requirements stage, actions are performed to reach the requirements maturity milestone either during an iteration which will be the basis for the design of the solution or release as well as the basis for the changes that may apply to the design of the solution or release.

7.6.2 Purpose

The purpose of this stage is to specify the detailed formal requirements for a release to address the problem or opportunity identified by the business.

7.6.3 Artefacts

Table 20 lists the artefacts of the “Requirements” stage.

Artefact	Description	Template Trim Reference
System Requirements Specification Document	An artefact to include system requirements.	TBA

Table 20 - Requirements Stage Artefacts

7.6.4 Controls

Table 21 illustrates the controls required for the “Requirements” stage.

Control
All artefacts must be updated and signed off by the relevant parties.
For development activities covering releases with a high level of Risk, System Requirements Specifications must be signed off by a representative from different stakeholder groups (e.g. external agencies, if applicable) at an executive level.

Table 21 - Requirements Stage Controls

7.6.5 Stage Processes

System Requirements Definition Process

7.6.5.1.1 Purpose

The purpose of the System Requirements Definition process is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user. This process creates a set of measurable system requirements that specify, from the development team’s perspective, what characteristics, attributes, and functional and performance requirements the system/release is to possess, in order to satisfy stakeholder requirements.

This process is aligned with “System Requirements Definition Process” in ISO 15288:2015 [1].

NOTE: The focus on the requirements stage is on whats and the focus of the design stage is on hows. This simple principle can sometimes put everything back to where they should be and help avoid going into too much details at early stages. As far as constraints permit, the requirements should not imply any specific implementation.

NOTE: Defining requirements begins with stakeholder intentions (referred to as needs, goals, or objectives), that evolve into a more formal statement before maturing as valid stakeholder requirements. Initial stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis and possibly consistency and feasibility. Using the Concept of Operations to aid the understanding of the stakeholder intentions at the organizational level and the System Operational Concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements [10].

NOTE: A well-formed requirement is a statement that

can be verified,
has to be met or possessed by a system to solve a stakeholder problem or to achieve a stakeholder objective,
is qualified by measurable conditions and bounded by constraints, and
defines the performance of the system when used by a specific stakeholder or the corresponding capability of the system, but not a capability of the user, operator, or other stakeholders.

This description provides a means for distinguishing between requirements and the attributes of those requirements (conditions, assumptions, design decisions and constraints) [10].

7.6.5.1.2 Outcomes

The outcomes of the “System Requirements Definition Process” are as follows:

The system description, including system interfaces, functions and boundaries, for a system solution is defined.
System requirements (functional, performance, process, non-functional, and interface) and design constraints are defined.
Critical performance measures are defined.
The system requirements are analyzed.
Any enabling systems or services needed for system requirements definition become available.
Traceability of system requirements to stakeholder requirements is established.

7.6.5.1.3 Work Breakdown Structure

Figure 25 illustrates the work breakdown structure for the System Requirements Definition Process.

Figure 25 - Work breakdown structure for the System Requirements Definition Process

7.6.5.1.4 Workflow

Figure 26 illustrates the workflow for the System Requirements Definition Process.

Figure 26 - System requirements definition process workflow

7.6.5.1.5 Artefacts

Table 22 lists the artefacts of the System Requirements Definition Process.

Artefact	Description
System Requirements Specification Document	An artefact to include system requirements.

Table 22 - System Requirements Definition Process Artefacts

Demonstration and Evaluation Process

7.6.5.2.1 Purpose

The purpose of the Demonstration and Evaluation Process is to further define system characteristics, concepts, and solutions through systems engineering, development of preliminary equipment and prototypes, and testing and evaluation through active engagement with the business.

NOTE: The development teams are free to choose to go through the Demonstration and Evaluation Process at their own discretion, however, in some of the areas in the agency, it’s a very common practice to refine the requirements and obtain the final sign-offs on the Business Requirements Specifications through this process which may involve prototyping and/or designing wireframes, sketches and user interface screen layouts.

This process is aligned with “System Requirements Definition Process” in ISO 15288:2015 [1].

7.6.5.2.2 Outcomes

The outcomes of the Demonstration and Evaluation Process are as follows:

The business is engaged and involved in the refinement of system characteristics and requirements.
System characteristics, concepts, and solutions are refined and defined with more clarity and depth.
The business achieves confidence in the fact that their concerns and requirements are being captured and addressed.
Business Requirements Specifications are finalized and signed off.

7.6.5.2.3 Work Breakdown Structure

Figure 27 illustrates the work breakdown structure for the Demonstration and Evaluation Process.

Figure 27 - The work breakdown structure of the Demonstration and Evaluation Process

7.6.5.2.4 Workflow

Figure 28 illustrates the workflow of the Demonstration and Evaluation Process.

Figure 28 - The workflow of the Demonstration and Evaluation Process

7.6.5.2.5 Artefacts

Table 23 lists the artefacts of the Demonstration and Evaluation Process.

Artefact	Description
System Requirements Specification Document	An artefact to include system requirements; refined and finalized.

Table 23 - Demonstration and Evaluation Process Artefacts

Infrastructure Provisioning Process

7.6.5.3.1 Purpose

The purpose of the Infrastructure Provisioning Process is to provide the infrastructure and services to projects, solutions, systems and releases, and to support organization and project objectives throughout the life cycle. This process defines, provides and maintains the facilities, tools, and information and communications technology assets needed for the solution or release.

This process is aligned with “Infrastructure Management Process” in ISO 15288:2015 [1].

7.6.5.3.2 Outcomes

The outcomes of the Infrastructure Provisioning Process are as follows:

The requirements for infrastructure needed for the release/solution are defined.
The infrastructure elements are identified and specified.
Infrastructure elements are developed or acquired.
The infrastructure is provisioned and becomes available.

7.6.5.3.3 Work Breakdown Structure

Figure 29 illustrates the work breakdown structure for the Infrastructure Provisioning Process.

Figure 29 - The work breakdown structure of the Infrastructure Provisioning Process

7.6.5.3.4 Workflow

Figure 30 illustrates the workflow of the Infrastructure Provisioning Process.

Figure 30 - The workflow of the Infrastructure Provisioning Process

7.7 Analysis and Design Stage

7.7.1 Overview

During the Analysis and Design Stage, a transition from requirements into system design is achieved and once the design maturity milestone is reached, the desired features and operations of the solution/release are captured and framed into the design artefacts in details and finally accepted and confirmed by the business.

7.7.2 Purpose

The purpose of the Analysis and Design Stage is to compile and develop detailed system design from the requirements and achieve the support and acceptance of the design from the business.

7.7.3 Artefacts

Table 24 lists the artefacts of the “Analysis and Design” stage.

Artefact	Description	Template Trim Reference
Logical Solution Architecture	An artefact to contain technology-agnostic models from different architecture viewpoints.	TBD
Physical Solution Architecture	An artefact to contain implementation-related models from different architecture viewpoints.	TBD
Design Review Report	An artefact to confirm the alignment of the design to DET’s architecture principles and standards.	TBD

Table 24 – Analysis and Design Stage Artefacts

7.7.4 Controls

Table 25 illustrates the controls required for the “Analysis and Design” stage.

Control
All artefacts must be updated and signed off by the relevant parties.
For development activities pertaining to releases with a high level of Risk, The Design Review Report must be signed off by a representative from different stakeholder groups (e.g. external agencies, if applicable) at an executive level.

Table 25 - Analysis and Design Stage Controls

7.7.5 Stage Processes

System Analysis Process

7.7.5.1.1 Purpose

The purpose of the System Analysis process is to provide a rigorous basis of data and information for technical understanding to aid decision-making across the life cycle.

The System Analysis process applies to the development of inputs needed for any technical assessment. It can provide confidence in the utility and integrity of system requirements, architecture, and design. System analysis covers a wide range of differing analytic functions, levels of complexity, and levels of rigor. It includes mathematical analysis, modeling, simulation, experimentation, and other techniques to analyze technical performance, system behavior, feasibility, affordability, critical quality characteristics, technical risks, life cycle costs, and to perform sensitivity analysis of the potential range of values for parameters across all life cycle stages. It is used for a wide range of analytical needs concerning operational concepts, determination of requirement values, and resolution of requirements conflicts, assessment of alternative architectures or system elements, and evaluation of engineering strategies (integration, verification, validation, and maintenance).

This process is aligned with “System Analysis Process” in ISO 15288:2015 [1].

NOTE: In iterative development, it is vital to re-assess the risk level and the need for information re-classification whenever a change is made to the data models involved with the solution/release. The analysis process includes steps to ensure this is done.

7.7.5.1.2 Outcomes

The outcomes of the System Analysis Process are as follows:

System analysis assumptions and results are validated.
System analysis results are provided for decisions.
Traceability of the system analysis results is established.
risk is re-assessed.
Information classification is carried out again, if applicable.

7.7.5.1.3 Work Breakdown Structure

Figure 31 illustrates the work breakdown structure of the System Analysis Process.

Figure 31 - The work breakdown structure of the System Analysis Process

7.7.5.1.4 Workflow

Figure 32 illustrates the workflow of the System Analysis Process.

Figure 32 - The workflow of the System Analysis Process

7.7.5.1.5 Artefacts

Table 24 lists the artefacts of the “System Analysis Process” stage.

Artefact	Description
Updated Release Risks/Issue Register	An artefact to include a list of risks and issues pertaining to the release.
Updated Information Classification Report	An artefact to include the decision outcomes and rationale of the information classification process.

Table 26 – System Analysis Process artefacts

Iteration Planning Process

7.7.5.2.1 Purpose

The purpose of the Iteration Planning Process is to produce and coordinate effective and workable plans for the current iteration. This process determines the scope of the activities, identifies outputs, tasks and artefacts, establishes schedules for task conduct, including achievement criteria, and required resources to accomplish tasks throughout a single iteration.

NOTE: After the initial analysis is performed at the beginning of the Analysis and Design Stage, this process helps work out which requirements or enhancements are added to the development pipeline and/or product, sprint or iteration backlogs.

Note: This process handles planning activities involved in a single iteration. Project-wide planning happens at the “Projectization and Planning Process”.

This process is aligned with “Project Planning Process” in ISO 15288:2015 [1].

7.7.5.2.2 Outcomes

The outcomes of the Iteration Planning Process are as follows:

Objectives and plans of the current iteration are defined.
Roles, responsibilities, accountabilities, authorities are defined, if applicable.
Resources and services necessary to achieve the objectives are formally requested and committed.
Plans for the execution of the iteration are activated.
Work breakdown structures, tasks and items in the development pipeline or product/iteration backlog are identified.

7.7.5.2.3 Work Breakdown Structure

Figure 33 illustrates the work breakdown structure for the Iteration Planning Process.

Figure 33 - Work breakdown structure for the Iteration Planning Process

7.7.5.2.4 Workflow

Figure 34 illustrates the workflow for the Iteration Planning Process.

Figure 34 – Iteration Planning Process Workflow

Logical Architecture Definition Process

7.7.5.3.1 Purpose

The purpose of the Logical Architecture Definition process is to generate system architecture alternatives, to select one or more alternative(s) that frame stakeholder concerns and meet system requirements, and to generate implementation-agnostic design, and to express it in a set of consistent views.

NOTE: As the definition of Architecture implies, system architecture deals with fundamental principles, concepts, properties, and characteristics and their incorporation into the system-of-interest. Architecture definition has more uses than as merely a driver (or part of) design.

NOTE: As one of the artefacts of the Design stage, the logical solution architecture should be technology and implementation agnostic while the physical solution architecture, should be technology and implementation dependent.

NOTE: Stakeholders are initially identified in the Stakeholder Needs and Requirements process. Additional stakeholders are usually identified during the Architecture Definition process. Stakeholder concerns related to architecture are expectations or constraints associated with the system life cycle stages such as utilization (e.g., availability, security, effectiveness, usability), support (e.g., reparability, obsolescence management), evolutionary development of the system and of the environment (e.g., adaptability, scalability, survivability), production (e.g., producibility, testability) [1].

NOTE: In scenarios where a commercial-off-the-shelf (COTS) product is being customized or integrated internally, the internal workings of the product may not be known or available and are not necessary to be included in architecture description documentations, however, through the selection of the right architectural views, such customizations and integration details can still be described using the same principles used with in-house developed solutions.

NOTE: As part of the improvements made to business engagement and ownership, it would be the art of the development teams to describe the architecture of the solution through the right views and modeling languages so that the business can also understand, confirm and approve the design. Another missing piece is the decision-support aspect of architecture design. Some possible architecture alternatives can be expressed in the architecture description and the decision to choose one can be made by the business according to their needs, provided that there’s alignment with enterprise architecture.

This process is aligned with the Architecture Definition Process in ISO 15288:2015 [1].

7.7.5.3.2 Outcomes

The outcomes of the Logical Architecture Definition Process are as follows:

Identified stakeholder concerns are addressed by the architecture.
Architecture viewpoints are developed.
Context, boundaries, and external interfaces of the system are defined.
Architecture views and models of the system are developed.
Concepts, properties, characteristics, behaviors, functions, or constraints that are significant to architecture decisions of the system are allocated to architectural entities.
System elements and their interfaces are identified.
Architecture candidates are assessed.
An architectural basis for processes throughout the life cycle is achieved.
Alignment of the architecture with requirements and design characteristics is achieved.
Any enabling systems or services needed for architecture definition are available.
Traceability of architecture elements to stakeholder and system requirements is developed.

7.7.5.3.3 Work Breakdown Structure

Figure 35 illustrates the work breakdown structure for the Logical Architecture Definition Process.

Figure 35 - Work breakdown structure for the Logical Architecture Definition Process

7.7.5.3.4 Workflow

Figure 36 illustrates the workflow for the Logical Architecture Definition Process.

Figure 36 – Logical architecture definition process workflow

7.7.5.3.5 Artefacts

Table 27 lists the artefacts of the Logical Architecture Definition Process.

Artefact	Description
Logical Solution Architecture	An artefact to contain technology-agnostic models from different architecture viewpoints.

Table 27 - Logical Architecture Definition Process Artefacts

7.7.5.3.6 Development of Architectural Viewpoints and Views

The artefact templates related to architecture have been modified and aligned with the definitions in ISO 42010:2011 with the goal to be able to establish a strong link between stakeholder concerns and architectural decisions and concepts. The stakeholder-concern-view-viewpoint axis in the new architecture description model will ensure that business stakeholders will have visibility on architectural decisions more proactively and can provide acceptance on areas that were deemed too technical in the past. This will promote a higher level of business ownership and reduce the technical gap between the development teams and business stakeholders.

As explained in “Terms and definitions”, an architecture view is defined as a work product expressing the architecture of a system from the perspective of specific system concerns while an architecture viewpoint is the perspective from which a system is expressed [5].

An architecture viewpoint can be defined as a work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns. In other words, a viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views [5].

From another perspective, “a view is to a viewpoint as a program is to a programming language.”

NOTE: Despite the fact that it’s vital to fully understand all the concepts used to describe architectures (as depicted in Figure 37), it must be remembered that the goal of this activity is to be able to “describe” a system from different perspectives that are derived from stakeholder concerns. Ultimately, the architecture description artefact should suffice in describing the system at different levels.

NOTE: For development activities focused on the delivery of systems with no in-house development components (e.g. network upgrades and/or installation of Commercial-Off-The-Shelf products with no customizations), no view or viewpoints related to the internal workings of such products is necessary. Instead, the Logical Design Process should focus on making it easy for the business with the right decision making criteria to choose one or more architecture alternatives.

Figure 37 illustrates the conceptual model behind architecture description.

Figure 37 – The Conceptual model of architecture description [5]

There are a set of pre-defined viewpoints that could be used to ease the development of an architecture description artefact as follows:

Source	Viewpoints
Kruchten, “The ‘4+1’ view model of architecture”	Logical, Development, Process and Physical views. The resulting views are integrated via Scenarios.
Rozansky and Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives.	Functional, Information, Concurrency, Development, Deployment and Operational viewpoints and perspectives, Security, Performance and Scalability, Availability and Resilience, and Evolution perspectives for software-intensive systems.
Clements, et al., Documenting Software Architectures: views and beyond	Provides extensive resources for defining 3 categories of viewpoints. These categories, called viewtypes (see A.4), are Module, Component and Connector and Allocation viewtypes. Within each viewtype, a number of styles are defined.
Eeles and Cripps, The Process of Software Architecting	Requirements, Functional, Deployment, Validation, Application, Infrastructure, Systems Management, Availability, Performance, Security; and the “work products” (i.e., model kinds) for each.

Table 28 – Common architecture viewpoints

Physical Design Definition Process

7.7.5.4.1 Purpose

The purpose of the Physical Design Definition Process is to provide sufficient detailed data and information about the system and its elements to enable the implementation consistent with architectural entities as defined in models and views of the logical system architecture.

NOTE: Architecture focuses on suitability, viability, and desirability, whereas design focuses on compatibility with technologies and other design elements and feasibility of construction and integration. An effective logical architecture is as design-agnostic as possible to allow for maximum flexibility in the design trade space.

NOTE: Physical Design Definition considers any applicable technologies and their contribution to the system solution. Design provides the ‘implement-to’ level of the definition, such as drawings and detailed design descriptions.

This process is aligned with the Design Definition Process in ISO 15288:2015 [1].

7.7.5.4.2 Outcomes

The outcomes of the Physical Design Definition Process are as follows:

Design characteristics of each system element are defined.
System requirements are allocated to system elements.
Design enablers necessary for design definition are selected or defined.
Interfaces between system elements composing the system are defined or refined.
Design alternatives for system elements are assessed.
Design artefacts are developed.
Any enabling systems or services needed for design definition are available.
Traceability of the design characteristics to the architectural entities of the system architecture is established.

7.7.5.4.3 Work Breakdown Structure

Figure 38 illustrates the work breakdown structure for the Physical Design Definition Process.

Figure 38 - Work breakdown structure for the Physical Design Definition Process

7.7.5.4.4 Workflow

Figure 39 illustrates the workflow for the Physical Design Definition Process.

Figure 39 – Physical design definition process workflow

7.7.5.4.5 Artefacts

Table 27 lists the artefacts of the Physical Design Definition Process.

Artefact	Description
Physical Solution Architecture	An artefact to contain implementation-related models from different architecture viewpoints.

Table 29 - Physical Design Definition Process Artefacts

Design Review Process

7.7.5.5.1 Purpose

The purpose of the Design Review Process is to ensure the design maturity milestone has been reached while ensuring that the design is aligned with DET’s architectural principles and standards. Later through the review process, the business has the chance to confirm and support the design.

This process enables the development teams to produce, collect, and validate evidence that forms the basis for a justified statement of confidence that the release/solution/product conforms to its established requirements all gathered through a documented process, preferably performed by parties that are independent from the teams involved in the development/project [1].

This process is aligned with the Quality Assurance Process in ISO 15288:2015 [1].

The related artefacts of this process are aligned with IEEE Standard 730™-2014 IEEE Standard for Software Quality Assurance Processes [11].

7.7.5.5.2 Outcomes

The outcomes of the Design Review Process are as follows:

Evaluations of the design are performed and are consistent with DET’s architectural principles and standards.
Results of evaluations are recorded and provided to relevant stakeholders.
Incidents are recorded and resolved.
Problems are treated.
The business approves and supports the design.

7.7.5.5.3 Work Breakdown Structure

Figure 40 illustrates the work breakdown structure of the Design Review Process.

Figure 40 - The work breakdown structure of the Architecture Review Process

7.7.5.5.4 Workflow

Figure 41 illustrates the workflow of the Design Review Process.

Figure 41 - The workflow of the Design Review Process

7.7.5.5.5 Artefacts

Table 30 lists the artefacts of the Design Review Process.

Artefact	Description
Design Review Report	An artefact to confirm alignment of the design to DET’s architecture principles and standards.

Table 30 - Design Review Process Artefacts

7.8 Implementation Stage

7.8.1 Overview

During the implementation stage, the design is materialized and realized into physical code, artefacts and elements. During this stage, a transition from design maturity to build maturity occurs.

7.8.2 Purpose

The purpose of the implementation stage is to materialize and realize system elements based on the detailed design.

7.8.3 Artefacts

Table 31 lists the artefacts of the “Implementation” stage.

Artefact	Description	Template Trim Reference
All codes and scripts fully finalized and checked into DET’s selected source control environment.	All codes and scripts required to build the solution or release.	N/A
Unit Test Reports	An artefact to contain a summary of the unit tests and their results.	TBD
Code Review Report	An artefact to contain details about code review results.	TBD
Deployment Plan	An artefact to contain the instructions and details on how to deploy the release/solution.	TBD
EIP Engagement	An artefact to contain adetails on the integration between the release/solution and other enabling or dependent systems.	TBD
Accessibility Review Report	An artefact to contain details about accessibility review results.	TBD

Table 31 – Implementation Stage Artefacts

7.8.4 Controls

Table 25 illustrates the controls required for the “Implementation” stage.

Control
All artefacts must be updated and signed off by the relevant parties.

Table 32 - Implementation Stage Controls

7.8.5 Stage Processes

Implementation Process

7.8.5.1.1 Purpose

The purpose of the Implementation Process is to realize specified system elements. This process transforms requirements, architecture, and design, including interfaces, into actions that create system elements according to the practices of the selected implementation technology, using appropriate technical specialties or disciplines. This process results in system elements that satisfy specified system requirements (including allocated and derived requirements), architecture, and design.

This process is aligned with the Implementation Process in ISO 15288:2015 [1].

NOTE: Performing unit testing is a part of the implementation process. The basic principle is that proper unit testing is a pre-requisite for user acceptance testing (verification) and without it, user acceptance testing should not commence. It is part of the responsibilities of the development teams to ensure that unit testing becomes a routine activity.

NOTE: It is a developer’s responsibility to make sure that the code they produce integrates with the rest and works as expected as an end-to-end product. Unit testing is a mechanism to establish evidence for the fact that the code performs as expected.

NOTE: During the implementation process, some business units may use the services of professional testers to perform System Functional Testing whose goal is to test the implementation against the specifications by feeding inputs and examining outputs. Either way, it is mandatory to perform functional testing to ensure the implementation matches the specifications.

NOTE: For releases with a high level of risk, it is mandatory to reach 100% code coverage for unit testing. This is aligned with a more rigorous regression testing regime for high-risk releases to ensure changes do not destabilize existing code.

NOTE: The use of test automation tools can support unit testing practices and ease the process. It is highly recommended for development teams to make that a practice.

NOTE: It is highly recommended to make automated regression testing part of the build process to ensure that the integrity and health of the whole codebase is maintained when introducing change.

NOTE: It is highly recommended for development teams to make it a priority to develop testable codes which might require stepping away from the traditional development mindsets. It would be sensible to ensure that if possible, the business logic is not implemented at the database level and that the performance costs of such a shift are handled by employing other design pattern and paradigms. DET’s newest application development framework has been developed to support this goal.

7.8.5.1.2 Outcomes

The outcomes of the Implementation Process are as follows:

Implementation constraints that influence the requirements, architecture, or design are identified.
System elements are realized.
System elements are packaged or stored.
Any enabling systems or services needed for implementation become available.
Traceability is established to requirements and stakeholder concerns.

7.8.5.1.3 Work Breakdown Structure

Figure 42 illustrates the work breakdown structure of the Implementation Process.

Figure 42 - The work breakdown structure of the Implementation Process

7.8.5.1.4 Workflow

Figure 43 illustrates the workflow of the Implementation Process.

Figure 43 - The workflow of the Implementation Process

7.8.5.1.5 Artefacts

Table 33 lists the artefacts of the Implementation Process.

Artefact	Description
All codes and scripts fully finalized and checked into DET’s selected source control environment.	All codes and scripts required to build the solution or release.
Unit Test Reports	An artefact to contain a summary of the unit tests and their results.
Deployment Plan	An artefact to contain the instructions and details on how to deploy the release/solution.

Table 33 - Implementation Process Artefacts

Integration Process

7.8.5.2.1 Purpose

The purpose of the Integration Process is to synthesize a set of system/release elements into a realized system (product or service) that satisfies system requirements, architecture, and design. This process assembles the implemented system elements. Interfaces are identified and activated to enable interoperation of the system/release elements as intended. This process integrates the enabling systems with the system-of-interest to facilitate interoperation.

This process is aligned with the Integration Process in ISO 15288:2015 [1].

NOTE: Apart from system-to-system integration, element-to-element integration in the same system is also covered by integration. The ultimate goal is to ensure that all elements (possibly developed by different parties) integrate and function well, as an end-to-end unit.

NOTE: As per DET’s standards and principles, all system-to-system data transfers and interfaces, irrespective of underlying technology or being internal or external, are managed and controlled by the Enterprise Integration Platform (EIP) unit.

7.8.5.2.2 Outcomes

The outcomes of the Integration Process are as follows:

Integration constraints that influence system/release requirements, architecture, or design, including interfaces are identified.
Approach and checkpoints for the correct operation of the assembled interfaces and system/release functions are defined.
Access to any enabling systems or services needed for integration becomes available.
A system composed of implemented system/release elements is integrated.
The interfaces between the implemented system/release elements that compose the system are checked.
The interfaces between the system/release and the external environment are checked.
Integration results and anomalies are identified.
Traceability of the integrated system/release elements is established.

7.8.5.2.3 Work Breakdown Structure

Figure 44 illustrates the work breakdown structure of the Integration Process.

Figure 44 - The work breakdown structure of the Integration Process

7.8.5.2.4 Workflow

Figure 45 illustrates the workflow of the Integration Process.

Figure 45 - The workflow of the Integration Process

7.8.5.2.5 Artefacts

Table 34 lists the artefacts of the Integration Process.

Artefact	Description
EIP Engagement	An artefact to contain details on the integration between the release/solution and other enabling or dependent systems.

Table 34 - Integration Process Artefacts

Code Review Process

7.8.5.3.1 Purpose

The purpose of the Code Review Process is to ensure the implementation maturity milestone has been reached while confirming that the implementation is a fit to the design and is aligned with DET’s architectural principles and standards.

This process enables the development teams gather evidence to justify that the software product conforms to DET’s standards, all gathered through a documented process, preferably performed by parties that are independent from the teams involved in the development/project.

This process is aligned with the Quality Assurance Process in ISO 15288:2015 [1].

NOTE: The code review process is applicable to releases that include the generation of code or scripts. Releases that only include configuration modifications on commercial off-the-shelf solutions and do not include in-house developed codes or scripts may skip this process.

NOTE: The code review process should be an enabler for quality not a burden or a step to only check for statistical or apparent characteristics of the code at the final last moment. As well as ensuring the basics have been followed (e.g. the SOLID principles), a properly-performed code review also ensures alignment of the implementation with the design in architectural aspects. It also helps achieve a longer lifespan for the system under development and saving maintenance and changing costs through promoting high cohesion, loose coupling and higher levels of maintainability.

7.8.5.3.2 Outcomes

The outcomes of the Code Review Process are as follows:

Ensuring evaluations of the implementation are performed and that the implementation is conformant to DET’s architectural principles and standards.
Results of evaluations are recorded and provided to relevant stakeholders.
Incidents are recorded and resolved.

7.8.5.3.3 Work Breakdown Structure

Figure 46 illustrates the work breakdown structure of the Code Review Process.

Figure 46 - The work breakdown structure of the Code Review Process

7.8.5.3.4 Workflow

Figure 47 illustrates the workflow of the Code Review Process.

Figure 47 - The workflow of the Code Review Process

7.8.5.3.5 Artefacts

Table 35 lists the artefacts of the Code Review Process.

Artefact	Description
Code Review Report	An artefact to contain details about code review results.

Table 35 - Code Review Process Artefacts

Accessibility Review Process

7.8.5.4.1 Purpose

The purpose of the Accessibility Review Process is to ensure the user interface of the release or system is aligned with DET’s accessibility and user interface design principles and standards.

This process is part of the processes that enable the development teams gather evidence to justify that the product conforms to DET’s accessibility principles and standards.

This process is aligned with the Quality Assurance Process in ISO 15288:2015 [1].

NOTE: The accessibility review process is only applicable to development activities that include in-house built solutions that come with a user interface.

7.8.5.4.2 Outcomes

The outcomes of the Accessibility Review Process are as follows:

Ensuring evaluations on the user interface of the solutions are performed and that they are conformant to DET’s accessibility principles and standards.
Results of evaluations are recorded and provided to relevant stakeholders.
Incidents are recorded and resolved.

7.8.5.4.3 Work Breakdown Structure

Figure 48 illustrates the work breakdown structure of the Accessibility Review Process.

Figure 48 - The work breakdown structure of the Accessibility Review Process

7.8.5.4.4 Workflow

Figure 49 illustrates the workflow of the Accessibility Review Process.

Figure 49 - The workflow of the Accessibility Review Process

7.8.5.4.5 Artefacts

Table 36 lists the artefacts of the Accessibility Review Process.

Artefact	Description
Accessibility Review Report	An artefact to contain details about accessibility review results.

Table 36 - Accessibility Review Process Artefacts

7.9 Test Stage

7.9.1 Overview

During the test stage, the stakeholders test and verify the release or system and ensure it fulfills the requirements as expected by the specs.

7.9.2 Purpose

The purpose of the test stage is to transition from build maturity milestone into production maturity milestone.

7.9.3 Artefacts

Table 37 lists the artefacts of the “Test” stage.

Artefact	Description	Template Trim Reference
User Acceptance Test Report	An artefact to include user acceptance test results.	TBD
Secondary User Acceptance Test Report (for releases with high levels of risk)	An artefact to include secondary user acceptance test results for releases/solutions with a high level of risk.	TBD
Quality assurance certificate (all releases)	An artefact to include a checklist demonstrating that the release/solution has gone through its due quality checkpoints.	TBD
Production Readiness Certificate (Type 1 releases)	An artefact to include a checklist demonstrating that the Type 1 release has gone through its due quality checkpoints and is ready for its first release in the production environment.	TBD
Operational Support Plan	An artefact to include details on arrangements required to keep the solution/release running and supported. A pre-requisite for production readiness and maturity.	TBD

Table 37 – Test Stage Artefacts

7.9.4 Controls

Table 38 illustrates the controls required for the “Implementation” stage.

Control
All artefacts must be updated and signed off by the relevant parties.
For releases with a high level of risk level, a secondary user acceptance test report must be presented.
For Type 1 releases, a production readiness certificate must be available.
For all releases, a quality assurance certificate must be available.

Table 38 - Implementation Stage Controls

7.9.5 Stage Processes

Pre-Verification Deployment Process

7.9.5.1.1 Purpose

The purpose of the Pre-Verification Deployment Process is to deploy the release into the User Acceptable environment so that the relevant stakeholders can test and verify the release/solution.

7.9.5.1.2 Outcomes

The outcomes of the Pre-Verification Deployment Process are as follows:

Ensure that the release becomes available in the user acceptance/quality assurance environment to be verified by stakeholders.
Ensure that the deployment plan is up-to-date and relevant.
Ensure that each release package consists of a set of related assets and service components that are compatible with each other.
Ensure that integrity of a release package and its constituent components is maintained.
Ensure that all release/deployment packages can be tracked, installed, tested, verified, and/or uninstalled or backed out, if appropriate.
Record and manage deviations, risks, issues related to the new or changed service, and take necessary corrective action.

7.9.5.1.3 Work Breakdown Structure

Figure 50 illustrates the work breakdown structure of the Pre-Verification Deployment Process.

Figure 50 - The work breakdown structure of the Pre-Verification Deployment Process

7.9.5.1.4 Workflow

Figure 51 illustrates the workflow of the Pre-Verification Deployment Process.

Figure 51 - The workflow of the Pre-Verification Deployment Process

Verification Process

7.9.5.2.1 Purpose

The purpose of the Verification Process is to provide objective evidence that a release or a system fulfils its specified requirements and characteristics. The Verification Process identifies the anomalies (errors, defects, or faults) in the implemented release or system. This process provides the necessary information to determine resolution of identified anomalies.

This process is aligned with the Verification Process in ISO 15288:2015 [1].

NOTE: The Verification process determines that the "product is built right". The Validation process determines that the "right product is built".

7.9.5.2.2 Outcomes

The outcomes of the Verification Process are as follows:

Constraints of verification that influence the requirements, architecture, or design are identified.
Any enabling systems or services needed for verification become available.
The release, system or system element is verified.
Data providing information for corrective actions is reported.
Evidence that the realized system fulfils the requirements, architecture and design is provided.
Verification results and anomalies are identified.
Traceability of the verified system elements is established.

7.9.5.2.3 Work Breakdown Structure

Figure 52 illustrates the work breakdown structure of the Verification Process.

Figure 52 - The work breakdown structure of the Verification Process

7.9.5.2.4 Workflow

Figure 53 illustrates the workflow of the Verification Process.

Figure 53 - The workflow of the Verification Process

7.9.5.2.5 Artefacts

Table 39 lists the artefacts of the Verification Process.

Artefact	Description
User Acceptance Test Report	An artefact to include user acceptance test results.
Secondary User Acceptance Test Report (for releases with high levels of risk)	An artefact to include secondary user acceptance test results for releases/solutions with a high level of risk.
Penetration and performance Test Report	Applicable for first-time cloud-based releases; an artefact to include the outcomes of penetration and performance tests.

Table 39 - Verification Process Artefacts

Pre-Production Quality Assurance Process

7.9.5.3.1 Purpose

The purpose of the Pre-Production Quality Assurance Process is to ensure the pre-production maturity milestone has been reached while ensuring that the release/system is ready for deployment into the production environment.

This process enables the development teams gather evidence to justify that the software product conforms to its established requirements, all gathered through a documented process.

This process is aligned with the Quality Assurance Process discussed in ISO 15288:2015 [1].

NOTE: The pre-production quality assurance process should be an enabler for quality not a burden or a blockage for project and development teams, however, it should provide the assurance that the system or release has gone through enough check points before being considered ready for production.

NOTE: Depending on the release size, different types of production readiness checklists are compiled. For Type 1 releases, production readiness certificate is to be compiled while for all release types, a production quality assurance checklist is compiled which is a compressed and efficient form of a production readiness certificate.

7.9.5.3.2 Outcomes

The outcomes of the Pre-Production Quality Assurance Process are as follows:

Ensuring that all the necessary requirements for production support are in place for the release/system.
Ensuring that the relevant support teams accept responsibility for the system in production.
Ensuring evaluations of the production maturity are performed.
Results of evaluations are recorded and provided to relevant stakeholders.
Incidents are recorded and resolved.

7.9.5.3.3 Work Breakdown Structure

Figure 54 illustrates the work breakdown structure of the Pre-Production Quality Assurance Process.

Figure 54 - The work breakdown structure of the Pre-Production Quality Assurance Process

7.9.5.3.4 Workflow

Figure 55 illustrates the workflow of the Pre-Production Quality Assurance Process.

Figure 55 - The workflow of the Pre-Production Quality Assurance Process

7.9.5.3.5 Artefacts

Table 40 lists the artefacts of the Pre-Production Quality Assurance Process.

Artefact	Description
Quality assurance certificate (all releases)	An artefact to include a checklist demonstrating that the release/solution has gone through its due quality checkpoints.
Production Readiness Certificate (Type 1 releases)	An artefact to include a checklist demonstrating that the Type 1 release has gone through its due quality checkpoints as a project/work package and is ready for its first release in the production environment.
Operational Support Plan	An artefact to include details on arrangements required to keep the solution/release running and supported. A pre-requisite for production readiness and maturity.

Table 40 - Pre-Production Quality Assurance Process Artefacts

7.10 Deployment Stage

7.10.1 Overview

During this stage, the release or solution is deployed into the production environment.

7.10.2 Purpose

The purpose of this stage is to transition from the production readiness milestone into the delivery milestone. For type 2 and type 3 releases, this would be the ultimate goal of the delivery, however, for type 1 releases, the delivery can be considered fulfilled after the Transition stage is also finalized and the benefits and goals of the solution are realized.

ArtefactsTable 41 lists the artefacts of the “Deployment” stage.

Artefact	Description	Template Trim Reference
Performance and Penetration Test Report	An artefact to include the results of running a performance and penetration test, only applicable to cases defined under “Performance and Penetration Testing Applicability Criteria”.	TBD
Release Completion Report	An artefact to highlight the outcomes of the deployment stage.	TBD
Business Benefits Realization Report	An artefact to highlight the key performance indicators of success in reaching business goals achieved by the solution.	TBD
Post-Transition Report	An artefact to highlight outcomes of the transition process.	TBD

Table 41 –Deployment Stage Artefacts

7.10.3 Controls

Table 42 lists the controls of the “Deployment” stage.

Control
The Release Completion Report must be developed and signed by all relevant parties.

Table 42 –Deployment Stage Controls

7.10.4 Stage Processes

Staging (Mirrored) Production Environment Deployment Process

7.10.4.1.1 Purpose

The purpose of the Staging (Mirrored) Production Environment Deployment Process is to ensure that the release or solution is working as expected in the staging (mirrored) production environment with its interfaces established and tested before it is deployed in the production environment.

NOTE: It is mandatory to ensure that the staging environment is truly a mirrored version of the production environment; an environment that in a true sense could be used to provide the same services to the end users as the production environment would. There might be times that instead of imposing downtimes, the traffic could be redirected to the “true” staging environment while the real production environment is being updated.

Unlike what it’s assumed, this environment is not just used for pre-production “practice” deployment. In fact, the success in the deployment in this environment is part of the pre-production maturity growth for the release or solution.

To achieve this goal, a mirrored instance of all services and systems should truly exist in the mirrored production environment and they should be kept up-to-date.

NOTE: It is assumed that with the implementation of this new life cycle model, as part of the deployment stage, all systems in the mirrored production environment will automatically remain synchronized with the production environment provided that both environments are synchronized shortly before the implementation of this life cycle model commences.

7.10.4.1.2 Outcomes

The outcomes of the Staging (Mirrored) Production Environment Deployment Process are as follows:

The deployment authorities will have a chance to ensure that all aspects of the deployment plans are up-to-date and the release or solution can truly be deployed based on them in the production environment.
To perform initial health checks before the final go-live in the production environment.

7.10.4.1.3 Work Breakdown Structure

Figure 56 illustrates the work breakdown structure of the Staging (Mirrored) Production Environment Deployment Process.

Figure 56 - The work breakdown structure of the Staging (Mirrored) Production Environment Deployment Process

7.10.4.1.4 Workflow

Figure 57 illustrates the workflow of the Staging (Mirrored) Production Environment Deployment Process.

Figure 57 - The workflow of the Staging (Mirrored) Production Environment Deployment Process

7.10.4.1.5 Artefacts

Table 43 lists the artefacts of the Staging (Mirrored) Production Environment Deployment Process.

Artefact	Description
Performance and penetration test report	An artefact to include the results of running a performance and penetration test, only applicable to cases defined under “Performance and Penetration Testing Applicability Criteria”.

Table 43 - Staging (Mirrored) Production Environment Deployment Process Artefacts

7.10.4.1.6 Performance and Penetration Testing Applicability Criteria

Even though it’s rational to perform performance and penetration test for all releases but since it is currently carried out through the engagement of external vendors which impose some costs on the agency, it been attempted to define the criteria to determine if it is mandatory to perform such tests or not, as Table 44 illustrates.

Criteria	Question	Yes?	No?
Data persistence backend for public-facing solutions	Is this release the first release of a public-facing solution (either on-premises or cloud-based) with data persistence backend of any sort (e.g. SQL databases)?	Mandatory	Not Mandatory
Data classification changes	Has the data classification changed in this release from a permissive level to a more restrictive level (e.g. from public to protected)?	Mandatory	Not Mandatory
Cloud/on-premises nature	Is this release the first release of a cloud-based solution (either public-facing or totally-internal)?	Mandatory	Not Mandatory

Table 44 - Performance and Penetration Testing Applicability Criteria

Production Environment Deployment Process

7.10.4.2.1 Purpose

The purpose of the Production Environment Deployment Process is to deploy the release or solution in the production environment and take the first steps to operationalize the new release or solution for the stakeholders.

NOTE: As a pre-requisite for the Production Environment Deployment Process, it is mandatory to ensure of the success in the Staging (Mirrored) Environment Deployment Process and to ensure the health checks have been performed properly and that the release/solution is working as expected in the staging environment.

7.10.4.2.2 Outcomes

The outcomes of the Production Environment Deployment Process are as follows:

The deployment authorities will deploy the well-tested release or solution in the production environment while ensuring that the integrity of the live environment is protected and that the correct components are released.
Issues found are recorded and resolved.
Steps are taken to perform a rollback, should the need arise.

7.10.4.2.3 Work Breakdown Structure

Figure 58 illustrates the work breakdown structure of the Production Environment Deployment Process.

Figure 58 - The work breakdown structure of the Production Environment Deployment Process

7.10.4.2.4 Workflow

Figure 59 illustrates the workflow of the Production Environment Deployment Process.

Figure 59 - The workflow of the Production Environment Deployment Process

Early Life Support Process

7.10.4.3.1 Purpose

The purpose of the Early Life Support Process is to resolve operational issues quickly during an initial period after the production deployment, and to remove any remaining errors or deficiencies that may be faced.

7.10.4.3.2 Outcomes

The outcomes of the Early Life Support Process are as follows:

Extra attention and/or resources are allocated to the release/solution that has been just deployed in the production environment.
The release/solution is monitored for abnormalities and possible issues.
Errors, issues and problems that may be faced shortly after deployment are recorded, identified and classified.
Problems are analyzed and assessed to identify acceptable solutions.
Problem resolution is implemented;
Problems are tracked to closure; and
The status of all problems reported is logged.

7.10.4.3.3 Work Breakdown Structure

Figure 60 illustrates the work breakdown structure of the Early Life Support Process.

Figure 60 - The work breakdown structure of the Early Life Support Process

7.10.4.3.4 Workflow

Figure 61 illustrates the workflow of the Early Life Support Process.

Figure 61 - The workflow of the Early Life Support Process

7.10.4.3.5 Artefacts

Table 45 lists the artefacts of the Early Life Support Process.

Artefact	Description
Release Completion Report	An artefact to highlight the outcomes of the deployment stage.

Table 45 – Early Life Support Process Artefacts

Transition Process

7.10.4.4.1 Purpose

The purpose of the Transition process is to establish a capability for a system to provide services specified by stakeholder requirements in the operational environment. This process moves the system in an orderly, planned manner into the operational status, such that the system is functional, operable and compatible with other operational systems. It installs a verified system, together with relevant enabling systems, e.g., planning system, support system, operator training system, user training system. This process includes preparing applicable storage, handling, and shipping enabling systems.

This process is aligned with the Transition Process in ISO 15288:2015 [1].

NOTE: Transition process is only applicable to Type 1 releases.

7.10.4.4.2 Outcomes

The outcomes of the Transition Process are as follows:

Ensure the system installed in its operational location is capable of delivering its specified functions.
Operators, users and other stakeholders necessary to the system utilization and support are trained.
Transition results and anomalies are identified.
The installed system is activated and ready for operation.
Traceability of the transitioned elements is established.

7.10.4.4.3 Work Breakdown Structure

Figure 62 illustrates the work breakdown structure of the Transition Process.

Figure 62 - The work breakdown structure of the Transition Process

7.10.4.4.4 Workflow

Figure 63 illustrates the workflow of the Transition Process.

Figure 63 - The workflow of the Transition Process

7.10.4.4.5 Artefacts

Table 46 lists the artefacts of the Transition Process.

Artefact	Description
Post-Transition Report	An artefact to highlight outcomes of the transition process.

Table 46 - Transition Process Artefacts

Validation Process

7.10.4.5.1 Purpose

The purpose of the Validation Process is to provide objective evidence that the system, when in use, fulfills its business or mission objectives achieving its intended use in its intended operational environment while fulfilling the benefits foreseen and expected.

The objective of validating a system or system element is to acquire confidence in its ability to achieve its intended mission and business benefits, or use, under specific operational conditions. Validation is ratified by stakeholders.

NOTE: As highlighted in section ‎7.9.5.2.1, the verification process determines that the "product is built right" while the validation process determines that the "right product is built".

NOTE: Validation process is only applicable to Type 1 releases.

7.10.4.5.2 Outcomes

The outcomes of the Validation Process are as follows:

Validation criteria for stakeholder requirements are defined.
Constraints of validation that influence the requirements, architecture, or design are identified.
The system or system element is validated.
Validation results and anomalies are identified.
Objective evidence that the realized system or system element satisfies expected business benefits is developed.

7.10.4.5.3 Work Breakdown Structure

Figure 64 illustrates the work breakdown structure of the Validation Process.

Figure 64 - The work breakdown structure of the Validation Process

7.10.4.5.4 Workflow

Figure 65 illustrates the workflow of the Validation Process.

Figure 65 - The workflow of the Validation Process

7.10.4.5.5 Artefacts

Table 47 lists the artefacts of the Validation Process.

Artefact	Description
Business Benefits Realization Report	An artefact to highlight the key performance indicators of success in reaching business goals achieved by the solution.

Table 47 - Validation Process Artefacts

7.11 Maintenance Stage

7.11.1 Overview

The Maintenance Stage begins with the provision of maintenance, logistics and other support for the system-of-interest's operation and use. The Maintenance Stage is completed with the retirement of the system-of-interest and termination of support services.

This stage includes those processes related to providing services that support utilization of the system-of-interest. This stage also includes processes to use and monitor the support system itself and its services, including the identification, classification, and reporting of anomalies, deficiencies, and failures of the support system and services.

During this stage, the system can evolve under different versions or configurations.

7.11.2 Purpose

The Maintenance Stage is executed to provide logistics, maintenance, and support services that enable continuing the operation of the system-of-interest.

7.11.3 Artefacts

Table 48 lists the artefacts of the “Maintenance” stage.

Artefact	Description	Template Trim Reference
System Release Schedule	An artefact to describe and list the bug fixes, changes, modifications, or new features that are planned to be included in a release.	TBD

Table 48 – Transition Stage Artefacts

7.11.4 Controls

Table 49 lists the controls of the “Maintenance” stage.

Control
All issues reported during the support process must be recorded in a traceable manner with enough details on how to replicate the issue.

Table 49 – Transition Stage Controls

7.11.5 Stage Processes

Support Process

7.11.5.1.1 Purpose

The purpose of the Support Process is to sustain the capability of the system to provide a service. This process monitors the system’s capability to deliver services, records incidents for analysis, takes corrective, adaptive, perfective and preventive actions and confirms restored capability.

This process is aligned with the Maintenance Process of ISO 15288:2015 [1].

7.11.5.1.2 Outcomes

The outcomes of the Support Process are as follows:

Maintenance constraints that influence system requirements, architecture, or design are identified.
Replacement, repaired, or revised system elements are made available.
The need for changes to address corrective, perfective, or adaptive maintenance is reported.
Failure and lifetime data, including associated costs, is determined.

7.11.5.1.3 Work Breakdown Structure

Figure 66 illustrates the work breakdown structure of the Support Process.

Create a new support request thru support ticketing systems (e.g. Service Now or Team Foundation Service) and provide further details (e.g. how to replicate an issue, if applicable).
Analyze the reported request or problem and categorize the request in different dimensions like
(a) Type; for example, corrective, improvement, preventive, or adaptive to new environment;
(b) Scope; for example, size of modification, cost involved, time to modify;
(c) Criticality; for example, impact on performance, safety, or security.
Action the request for inclusion in next releases thru the “Release Planning and Size Determination Process”.

Figure 66 - The work breakdown structure of the Support Process

7.11.5.1.4 Workflow

Figure 67 illustrates the workflow of the Support Process.

Figure 67 - The workflow of the Support Process

7.11.5.2 Release Planning and Size Determination Process

7.11.5.2.1 Purpose

The purpose of the Release Planning and Size Determination Process is to be able to bundle support and change requests and plan a new build (i.e. release) of the system and categorize the release (and the development activity covering the release) from the “size” prospective.

NOTE: The first release of a system that has never existed before is considered a Type 1 release irrespective of its actual size.

NOTE: It would be worth highlighting that the artefacts required for Type 1 releases can establish traceability back to the idea which may originate from the business and therefore, if new requirements are supposed to change existing business processes, especially the ones that involve external agencies, irrespective of size, it is highly recommended to categorize such releases as a Type 1 to be able to establish such a link back to the idea, however, the decision is left to the development teams to be made.

This process is aligned with Decision Management Processes as well as Project Planning Processes of ISO 15288:2015 [1].

7.11.5.2.2 Outcomes

The outcomes of the Release Planning and Size Determination Process are as follows:

Releases and their scope and objectives are identified.
Roles, responsibilities, accountabilities, authorities are defined.
Resources and services necessary to deliver the release are formally requested and committed.
Plans for the delivery of the release are developed.
Size classification applicable to a release (and the development activity delivering the release) is determined.
The outcomes of the Release Planning and Size Determination Process will determine what SDLC stages should be traversed during the development activity and what artefacts should accompany the release.

7.11.5.2.3 Work Breakdown Structure

Figure 68 illustrates the work breakdown structure of the Release Planning and Size Determination Process.

Figure 68 - The work breakdown structure of the Release Planning and Size Determination Process

7.11.5.2.4 Workflow

Figure 69 illustrates the workflow of the Release Planning and Size Determination Process.

Figure 69 - The workflow of the Release Planning and Size Determination Process

7.12 Retirement Stage

7.12.1 Overview

During this stage, the system is retired from normal services. It includes archiving the retiring system and providing limited support to its users for a given period.

7.12.2 Purpose

The purpose of this stage is to ensure that the disposal of a system is carried out properly with the right provisions and a smooth transition to a new state in which the system won’t be operational.

7.12.3 Artefacts

Table 50 lists the artefacts of the “Retirement” stage.

Artefact	Description	Template Trim Reference
Retirement Report	An artefact to include details about the outcomes of the disposal process.	TBD

Table 50 – Retirement Stage Artefacts

7.12.4 Stage Processes

Disposal Process

The purpose of the Disposal Process is to end the existence of a system element or system for a specified intended use, appropriately handle replaced or retired elements, and to properly attend to identified critical disposal needs (e.g., per organizational policy, or for environmental, legal, safety, security aspects).

This process is aligned with the Disposal Process in ISO 15288:2015 [1].

NOTE: The Disposal process may also be applicable throughout the other stages of the life cycle, including disposing prototypes during the early SDLC stages, and decommissioning elements from modifications during the later SDLC stages.

7.12.4.1.1 Outcomes

The outcomes of the Disposal Process are as follows:

Disposal constraints are provided as inputs to requirements, architecture, design, and implementation.
Any enabling systems or services needed for disposal become available.
The system elements or waste products are destroyed, stored, reclaimed or recycled in accordance with safety and security requirements.
The environment is returned to its original or an agreed state.
Records of disposal actions and analysis are saved.

7.12.4.1.2 Work Breakdown Structure

Figure 70 illustrates the work breakdown structure of the Disposal Process.

Figure 70 - The work breakdown structure of the Disposal Process

7.12.4.1.3 Workflow

Figure 71 illustrates the workflow of the Disposal Process.

Figure 71 - The workflow of the Disposal Process

7.12.4.1.4 Artefacts

Table 51 lists the artefacts of the Disposal Process.

Artefact	Description
Retirement Report	An artefact to include details about the outcomes of the disposal process.

Table 51 - Disposal Process Artefacts

7.13 SDLC Iterations

It is acknowledged that development teams may need to employ iterative incremental systems development methods and the possibility to support them is an important requirement. The following iterations are being discussed just as examples and the real combinations may include but are not limited to the followings.

The “variation” pathway in the SDLC provides the possibility for the development teams to fully utilize incremental iterative methods with a low-weight governance layer.

NOTE: It’s increasingly important to make sure that re-assessing the risk, re-performing information classification are carried out at the beginning of the Analysis and Design stage to ensure that the consistency of the processes are preserved during iterative work.

NOTE: Irrespective of being in an iteration or not, no design or development work should commence without the requirements having been approval by the business.

7.13.1 Product Development Iterations

Major solutions with a long life in DET’s environment (e.g. OneSchool) go through a number of product development iterations periodically throughout which a constant stream of new features and enhancements are prioritised and added to the development pipeline.

Figure 72 - Product Development Iteration

Defining which features are to be implemented and added to the solution, defining the feature set and roadmap of the solution, prioritising the workload and allocating the resources accordingly can be named as the main focus areas of such iterations.

Considering the fact that majority of such development activities cover Type 1 releases, application governance boards like the OneSchool board and its internal committees (if applicable) can review, endorse and approve the artefacts of the Needs and Concept stages as well as the artefacts of the Test stage.

For example, the OneSchool board internal committees include the Prioritization Committee whose focus is to prioritise the feature sets and the roadmap of the solution and tune the allocation of resources to high-priority features based on the availability of budget or legislative restrictions, and the Technical Committee, whose focus is to review the artefacts from a technical viewpoint, ensure feasibility of ideas for inclusion in OneSchool and provide the technical assurance to the OneSchool board in terms of the approvals and sign-offs[2].

The same model can be utilized by other similar application governance boards.

Figure 73 illustrates an example of how OneSchool Board Approval Model works from the Needs stage to the Maintenance stage in one Product Development Iteration.

Figure 73 - OneSchool Board Approval Model from Needs to Maintenance Stages in one Product Development Iteration

7.13.2 Product Stabilization Iterations

The focus of such iterations is to stabilize the release by moving back to the Analysis and Design stage to fix issues and make sure the release is verified by the business and ticks all the boxes.

Figure 74 - Product Stabilization Iteration

As can be seen in “Figure 7 - SDLC Overview”, this iteration may be used for all types of releases.

7.13.3 Requirements Stabilization Iterations

The focus of such iterations is to stabilize the requirements by moving back to the Requirements stage to address the fact that in many occasions, the requirements are re-written and changed after the product is first built and is sent to be verified by the business.

Figure 75 - Requirements Stabilization Iteration

Despite the fact that the SDLC provides a number of chances in the Concept stage and in the Requirements stage (through the “Demonstration and Evaluation Process”) to refine and validate the requirements, however, in practice, it may be likely that after the first build is released, the business may require some of the requirements to change. Such iterations may be helpful in such scenarios.

As can be seen in “Figure 7 - SDLC Overview”, this iteration may be used for Type 1 and 2 releases.

7.13.4 Requirements Refinement Iterations

The focus of such iterations is to provide a chance for the development teams and the business to refine their requirements by moving back to the Requirements stage from the Analysis and Design.

Figure 76 - Requirements Refinement Iteration

This is an acknowledgement of the fact that with more analysis on the requirements, sometimes, the need to re-define requirements becomes more vivid.

In practice, once the development teams get into the “hows” in the Analysis and Design stage, it is realized that the “whats” may be affected to improve the design or to address a gap or to reach a deadline or to reach a certain goal or to make the solution easier to build by tweaking the “whats”. In such cases, Requirements Refinement Iterations could help the development teams reach their goals by refining the requirements.

As can be seen in “Figure 7 - SDLC Overview”, this iteration may be used for Type 1 and 2 releases.

7.14 SDLC Milestones

Milestones are specific points of time throughout the life cycle at which certain goals are achieved and even though they have been aligned with the end of SDLC stages but in fact they are the points at which checks and controls are usually applied.

7.14.1 Pre-Projectization Milestone

This is a point of time during the life cycle at which a need or an idea for a new solution or for an improvement or enhancement in an existing solution is framed into an idea definition to receive the initial approvals.

7.14.2 Projectization Milestone

This is a point of time during the life cycle at which the approved need or idea is framed into a project definition and is shaped to become a project or work package after the approvals. High-level business requirements should be prepared by this milestone.

7.14.3 Requirements Maturity Milestone

This is a point of time during the life cycle at which the requirements are finalized and become mature enough for the analysis and build process to begin in the current iteration.

7.14.4 Design Maturity Milestone

This is a point of time during the life cycle at which the design of the solution or release reaches the maturity for the implementation to commence in the current iteration.

7.14.5 Build Maturity Milestone

This is a point of time during the life cycle at which the solution or release becomes mature enough for verification and testing to commence in the current iteration.

7.14.6 Production Maturity Milestone

This is a point of time during the life cycle at which the solution or release becomes mature enough for final delivery and deployment into the production environment.

7.14.7 Delivery & Benefits Realisation Milestone

This is a point of time during the life cycle at which the solution or release has been deployed into the production environment and has become available for the end users and stakeholders to use. At this point, the solution has become operationalized with its benefits, goals and business values being realized by its users and stakeholders

7.14.8 End of Use Milestone

This is a point of time during the life cycle at which the system/solution is decommissioned while the support for the system/solution is ceased and its users stop using it for the retirement stage to begin.

7.14.9 End of Life Milestone

This is a point of time during the life cycle at which the solution has been totally disposed of.

7.15 Links to the Change/Release Management

As can be seen in “Figure 7 - SDLC Overview”, for all release sizes, Change/Release Management protocols will be used throughout life cycle, as follows:

During the “Implementation Stage”, Zone 1 may be used by the development teams to help develop deployment scripts.
During the “Test Stage”, User Acceptance Testing/Quality Assurance/Zone 2 will be used by the development teams and business representatives to perform the “Verification Process”.
During the “Deployment Stage”, Staging/Mirrored Production Environment will be used to perform the “Staging (Mirrored) Production Environment Deployment Process” and the Production Environment will be used in the “Production Environment Deployment Process”. Some systems/solutions/applications may also use the Disaster Recovery and the Training Environments throughout this stage.

7.16 Release Life Cycle

DET’s Systems Development Life Cycle accommodates a traditional Alpha/Beta/Release Candidate model for release life cycle management.

As illustrated in “Figure 7 - SDLC Overview”, the following stages throughout the life of a release are supported and linked to the SDLC at different points:

7.16.1 Alpha Release

This is the first instance of a release deployed in a developer’s environment (zone 1) which is tested by the team members involved in the development of the release.

7.16.2 Beta Release

This is the second instance of a release deployed in the user acceptance testing environment (zone 2) which is tested by the business stakeholders or team members outside of the development teams.

7.16.3 Release Candidate

This is the 3rd instance of a release deployed in the staging environment (Mirrored Production Environment) which is mature enough to be considered a candidate for the final production release.

7.16.4 Final Production Release

This is the 4th instance of a release deployed in the production environment which is fully mature as the final production release.

7.17 Links to ICT Project Management Life Cycle

As can be seen in “Figure 7 - SDLC Overview”, the life cycle of Type 1 releases fairly matches the life cycle of an ICT Project.

Enterprise-wide project management protocols and methods are defined and managed outside of the systems development life cycle process model and have to be followed thoroughly if the minimum projectization thresholds and criteria are met for a release.

Project sponsors and/or development teams may also elect to run the delivery of their smaller releases as “projects” by following the ICT Project Life Cycle that may require extra artefacts and steps in addition to the minimums the SDLC defines and mandates.

8. Appendix A – SDLC Processes Glossary

7.3.1 Life Cycle Model Management Process............................................................................................. 39

7.3.2 Preliminary Information Classification Process........................................................................... 41

7.3.3 Preliminary Cloud Assessment Process........................................................................................... 43

7.3.4 Risk Assessment Process................................................................................................................... 45

7.4.5.1 High-Level Idea Definition Process................................................................................................ 50

7.5.5.1 Preliminary Business Requirements Specification Process........................................................ 54

7.5.5.2 Projectization and Planning Process.......................................................................................... 57

7.6.5.1 System Requirements Definition Process.................................................................................... 60

7.6.5.2 Demonstration and Evaluation Process.................................................................................... 63

7.6.5.3 Infrastructure Provisioning Process........................................................................................ 65

7.7.5.1 System Analysis Process............................................................................................................... 67

7.7.5.2 Iteration Planning Process......................................................................................................... 70

7.7.5.3 Logical Architecture Definition Process..................................................................................... 72

7.7.5.4 Physical Design Definition Process............................................................................................... 78

7.7.5.5 Design Review Process.................................................................................................................. 80

7.8.5.1 Implementation Process.............................................................................................................. 83

7.8.5.2 Integration Process..................................................................................................................... 86

7.8.5.3 Code Review Process..................................................................................................................... 89

7.8.5.4 Accessibility Review Process......................................................................................................... 91

7.9.5.1 Pre-Verification Deployment Process.......................................................................................... 94

7.9.5.2 Verification Process.................................................................................................................... 95

7.9.5.3 Pre-Production Quality Assurance Process................................................................................ 98

7.10.4.1 Staging (Mirrored) Production Environment Deployment Process......................................... 102

7.10.4.2 Production Environment Deployment Process......................................................................... 106

7.10.4.3 Early Life Support Process.......................................................................................................... 108

7.10.4.4 Transition Process..................................................................................................................... 110

7.10.4.5 Validation Process..................................................................................................................... 112

7.11.5.1 Support Process.......................................................................................................................... 114

7.12.4.1 Disposal Process......................................................................................................................... 119

9. Appendix B – Alignment of Systems Development Methods

This chapter explains how the SDLC process model can be used in conjunction with mainstream software development methods.

9.1 Waterfall-Based Methods

The methods that are based on the waterfall model (e.g. Structured Systems Analysis and Design Method (SSADM)) are very easy fit the SDLC process model in single-iteration scenarios due to their sequential structure that starts with the requirements stage and ends with the verification (testing) stage.

DET’s SDLC process model is release/risk centric and that’s why the maintenance stage has been distributed in the overall life cycle through returning to the previous stages. The way DET’s SDLC has been formulated is aligned with making sure there is a singular governance model over the lifetime of the whole solution, including the maintenance/support period which includes the later releases of the solution/system and that’s why the maintenance stage does not include a micro life cycle model in relation to maintenance and minor releases.

Figure 77 illustrates the alignment of the waterfall model with DET’s SDLC process model in a single-iteration setup.

Figure 77 - The alignment the waterfall model with the SDLC process model

9.2 The Unified Process

In a sense, DET’s SDLC process model could be viewed as a core Unified Process model surrounded by sequential Idea Projectization and Deployment/Maintenance milestones with a stronger emphasis on checkpoints and governance.

The Deployment discipline of the Unified Process could be interpreted as equivalent to the “Pre-Verification Deployment Process” (section ‎7.9.5.1) in DET SDLC process model and therefore, early iterations in DET SDLC process model could be mapped to the iterations of the Inception phase in the Unified Process while the later iterations could be mapped to iterations of the transition phase of the Unified Process, as illustrated in Figure 78.

In a way, the “phases” in the Unified Process (i.e. Inception, Elaboration, Construction and Transition) could be considered as “titles” given to “periods of time” with different levels of focus and emphasis on different development “disciplines”. In DET SDLC process model, however, the checkpoints and milestones within each iteration have been given a higher weight for governance purposes.

Figure 78 - The alignment the Unified Process with the SDLC process model

9.3 Scrum

Scrum has been traditionally a popular systems development method in DET and it can well fit within the new SDLC process model.

Traditionally, the product backlog is compiled once the requirements become known and during early analysis, through “Requirements Refinement Iterations”, the backlog grows until the development starts for the first time. During each sprint, a number of items are planned and chosen for implementation via the “Iteration Planning Process”. Once the product reaches a level of maturity and the business has the chance to perform tests, the product backlog may be updated with new requirements through “Requirements Stabilization Iterations”. And finally, through “Product Stabilization Iterations”, issues and bugs may be added to the Sprint and/or Product Backlog, as illustrated in Figure 79.

Figure 79 - The alignment the Scrum Process with the SDLC process model

9.4 Spiral Model

In DET’s SDLC process model, similar steps like the 2^nd step in the Spiral Model (Identity and Resolve Risks) is carried out through the “SDLC Track Processes” as well as “System Analysis Process”. In DET’s SDLC process model, similar steps like the 3^rd step in the Spiral Model (Development and Test) are carried out through different iterations as illustrated in Figure 80.

Obviously, planning the next iteration and determining objectives are the practices that team leaders and/or project managers go through in the “Analysis and Design Stage” through the “Iteration Planning Process”.

Figure 80 - The alignment the Spiral Process with the SDLC process model

10. Appendix C – SDLC Artefact Glossary

Artefact	Required for Type 1 Release	Required for Type 2 Release	Required for Type 3 Release
SDLC Track Artefacts
Information Classification Report		*	*
Cloud Assessment Report	**	**	**
Cloud-Based Development General Briefing Note	**	**	**
Release Risks/Issue Register
Needs Stage Artefacts
Idea Definition Document
Concept Stage Artefacts
Product Vision/Roadmap	***
Terms of Reference Document
Project Brief Document
Preliminary Business Requirements Specification
Requirements Stage Artefacts
System Requirements Specification Document
Analysis And Design Stage Artefacts
Logical Solution Architecture	#	#	#
Physical Solution Architecture
Design Review Report
Implementation Stage Artefacts
All codes and scripts fully finalized and checked into DET’s selected source control environment.
Unit Test Reports
Code Review Report
Deployment Plan
EIP Engagement	^	^	^
Accessibility Review Report	^^	^^	^^
Test Stage Artefacts
User Acceptance Test Report
Secondary User Acceptance Test Report (for releases with high levels of risk)	****
Penetration and Performance Test Report	^^^	^^^	^^^
Quality assurance certificate
Production Readiness Certificate
Operational Support Plan
Deployment Stage Artefacts
Performance and Penetration Test Report	##	##	##
Release Completion Report
Post-Transition Report
Business Benefits Realization Report
Maintenance Stage Artefacts
System Release Schedule
Retirement Stage Artefacts
Retirement Report

* Optional depending on whether or not data models have changed during the development of the release.

** Only applicable to releases with cloud-based components

*** Optional.

**** Only applicable to releases with a high level of risk.

^ Only applicable to solutions with system-to-system integration.

^^ Only applicable to solutions/releases with a user interface.

^^^ Only applicable to releases that are being deployed in the cloud for the first time.

# For delivery activities that do not include in-house development (e.g. network upgrades, COTS solution deployment etc…), viewpoints and views related to the internal workings of such products are not necessary.

## Only applicable to cases defined under “Performance and Penetration Testing Applicability Criteria”.

References

[1]	“ISO IEC IEEE 15288:2015 Systems and software engineering. System life cycle processes,” 15 May 2015. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63711. [Accessed 11 Jan 2016].
[2]	“Best practices for lean development governance, Part II: Processes and measures,” IBM, 15 July 2007. [Online]. Available: http://www.ibm.com/developerworks/rational/library/jul07/kroll_ambler/. [Accessed 5 Mar 2016].
[3]	“ISO/IEC TR 24774:2010 Systems and software engineering — Life cycle management — Guidelines for process description,” 15 Sep 2010. [Online]. Available: http://www.iso.org/iso/catalogue_detail.htm?csnumber=53815.
[4]	“ISO IEC 24748-1:2010 Systems and software engineering - Life cycle management -Part 1 - Guide for life cycle management,” 1 Oct 2010. [Online]. Available: http://www.iso.org/iso/catalogue_detail.htm?csnumber=50502. [Accessed 11 Jan 2016].
[5]	“ISO IEC 42010:2011 Systems and software engineering. Architecture description,” 01 Dec 2011. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=50508. [Accessed 11 Jan 2016].
[6]	V. Haren, TOGAF Version 9.1, Van Haren Publishing, 2011.
[7]	“ISO/IEC 12207:2008 Systems and software engineering — Software life cycle processes,” 1st of Feb 2008. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43447.
[8]	C. Agutter, ITIL Lifecycle Essentials: Your Essential Guide for the ITIL Foundation Exam and Beyond, It Governance Ltd, 2013.
[9]	M. S. W. M. Yard Antinyan, “Defining Technical Risks in Software Development,” in IEEE International Conference on Software Process and Product Measurement , 2014.
[10]	“ISO/IEC/IEEE 29148:2011 - Systems and software engineering — Life cycle processes — Requirements engineering,” 01 Dec 2011. [Online]. Available: http://www.iso.org/iso/catalogue_detail.htm?csnumber=45171. [Accessed 11 Jan 2016].
[11]	“IEEE Std 730™-2014 IEEE Standard for Software Quality Assurance Processes,” 27 March 2014. [Online]. [Accessed 11 Jan 2016].
[12]	R. Fairley, “Software Risk Management,” IEEE Software, 2005.

[1] The original title for the 3^rd release type in ITIL is “Emergency” but internal stakeholders in DET agreed upon eliminating the urgency dimension in the title and use “Maintenance” instead. Obviously, urgency may affect priority and timings but it does not affect the size or governance model around releases since maintaining the health of the production environment has the highest priority of all.

[2] For more details, please refer to the new Terms of Reference for OneSchool board and its committees.