NRS SDLC Requirements, Design, Build, Deploy

This phase includes activities to produce the product such as requirements, design, build, test and deployment. Quality management along with other monitoring and control is essential during this phase. The natural resource sector (NRS) system development life cycle (SDLC) does not mandate a specific methodology for this phase.

The mandatory deliverables are the minimum required for a project. Additional deliverables will be decided on with the project management office (PMO).

A Project Kickoff meeting is held to allow for all team members to be informed of the scope and vision of the project.

As a means of accelerating and improving the planning, scheduling, and team-building efforts of the project, a formal project kickoff meeting/workshop must be held for all projects, regardless of their size or complexity.

The project kickoff meeting represents an opportunity to establish a shared vision of the project, shared commitment, and a common understanding of project issues, constraints, accountabilities, and goals across all levels of the project team, and to accelerate and improve the planning and scheduling efforts of the project.

Documented using the Project Kick-off meeting checklist and the minutes of the meeting, the following points are typically covered:

  • background and introductions
  • key concerns and open issues
  • key project interfaces
  • work breakdown structure
  • deliverable responsibilities
  • project master schedule
  • project monitoring and control procedures

Standards/Guidelines

The standard is to use the Project Kick-off Meeting Checklist below.

Templates

Deliverable Requisite

A project kickoff meeting is mandatory for all project complexity levels.

Samples

There is no sample currently available

The project manager (PM) makes sure the project team is aware of the appropriate standards for the project.  If there is any concern, the PM is responsible to follow-up with the appropriate project management office or the Standards Committee.

IRS is the inventory management tool used by Information Management Branch to keep track of applications, servers, and related infrastructure information.

The responsibility for maintaining IRS is primarily assigned to Business Portfolio Managers, Application Deliveries, Infrastructure and Middle Tier, Technical Architecture, Database Administrators, and Data Architecture. 

The IRS Roles and Responsibilities (DOCX) provides details for the upkeep of IRS (B.C. Government access only).

On the initiation of a new project and subsequent information system, steps must be taken to determine what the impact will be to the stakeholders of this business area in terms of the changes required to business process, skills required and steps required for success.

The purpose of conducting change impact assessment is determine which stakeholders may be impacted and what is required to mitigate the changes.

Standards/Guidelines

A Change Impact Tracker and a Stakeholder Engagement and Assessment must be completed for any new system or major enhancement.

Templates

Deliverable Requisite

An assessment is mandatory for each project complexity level.

Samples

There are no samples currently available.

 

Privacy and Security

A PIA is created to ensure compliance with the Freedom of Information and Protection of Privacy Act when collecting, using or disclosing personal information.

A privacy impact assessment must be completed for any new or changes to applications.  The initial assessment must be completed for all initiatives to determine whether personal information is involved.

A draft Privacy Impact Assessment (PIA) is required during the Initiation Phase to identify potential risks and impacts of collecting, using, and disclosing personal information.  It is also a requirement to move to the Test environment through the Change Management process. A final PIA is required in the Design phase and is a requirement to move to the Production environment through the Change Management process.

Standards/Guidelines

BC Government Privacy Impact Assessment Process:

Templates

Deliverable Requisite

A Privacy Impact Assessment is mandatory for all project complexity levels.

Samples

There is no sample currently available.

A STRA must be conducted when developing, implementing major changes to, or acquiring an information system.

The Security Threat and Risk Assessment is a component of overall Risk Management. The STRA pertains to information, whereas the Risk Assessment covers all aspects of a project including equipment, funding, resources, etc.

STRAs are mandated by the Office of the Chief Information Officer (OCIO), and are mandatory as per the government’s Information Security Policy (ISP).

BC Government ISP policy 8.1.1 a) states:

Information Owners must conduct a Security Threat and Risk Assessment during the requirements phase when developing, implementing major changes to, or acquiring an information system, to:

  • Identify the security requirements necessary to protect the information system; and,
  • Assign a security classification to the information and information system.

For new or significant/major development a STRA must be substantially completed in the Requirements phase. This deliverable would be a completed STRA with as much information as available at that point with a specific focus identifying the security requirements and the security classification.

Once the STRA is approved, Security can issue a new scorecard populated with the approved data to allow for the continuation of the STRA development through the design and build phases.

This is the STRA workflow:

  • Initiation Phase: STRA initiated
  • Requirements Phase: STRA substantially completed and submitted (Focus: Security requirements and security classification). Upon acceptance scorecard reissued with existing data
  • Design Phase: STRA refined
  • Build Phase: STRA completion and sign-off

Managers make informed decisions about information security risks that are directly or indirectly under their control as part of their responsibilities. Within the context of risk management, STRAs suggest where to avoid, reduce and accept risk, as well as how to diminish the impact of threatening events, pertaining to information.

Standards/Guidelines

Other Office of the Chief Information Officer (OCIO) IM/IT Standards that should be considered:

The assessment tool used for all STRAs across government is the Information Security Management and Risk Tool – iSMART.

Completed STRAs reside in a central repository. Collectively, they contribute to our ability to assess our information security posture in order to highlight control areas that need strengthening, as well as the OCIO’s ability to assess the overall information security posture of all of government.

Templates

The deliverable for a STRA is a Risk Scorecard (B.C. Government access only), and within the scorecard is a checklist pertaining to security controls. The minimum checklist to be used is based on the ISO 27001 standard, with questions related to 17 control areas (PDF) (B.C. Government access only).

Deliverable Requisite

An STRA is mandatory for all project complexity levels.

Samples

There is no sample currently available.

A Financial Risk and Control Review must be conducted for any system that records financial transactions.

If the application will contain financial transactions, a Financial Risk and Controls Review must be conducted which requires involvement of Ministry of Finance resources and verifies that Chapter 13 of core policy is being followed.

Standards / Guidelines

Templates

There is no template currently available.

Deliverable Requisite

The Deliverable is optional for all project complexities unless the system contains financial transactions.

Samples

There is no sample currently available.

A Records Impact Analysis (RIA) provides a structured manner of identifying the records that are used as inputs to the system and records and reports generated from the system.

The RIA will identify the records, their appropriate classification and retention along with the Officer of Primary Responsibility (OPR) and media format. The Records Impact Analysis is drafted during the Initiation phase and is finalized in the Build phase.

The draft Records Impact Assessment must be completed for all initiatives to fully identify the classifications and resulting retention periods for the records related to the application.

The RIA will also identify if there is a need for the development of additional classifications using an Information System Overview (ISO) analysis.

Standards/Guidelines

Government wide standards for the records management are included in Chapter 12 of the Policy and Procedures Manual and addressed in detail in the Recorded Information Management Manual.

The standard is to use the template below to complete a Records Impact Assessment document, and if requirement, an Information Systems Overview.

Templates

Deliverable Requisite

A Records Impact Assessment is mandatory for all project complexity levels.

Samples

There is no sample currently available

 

Procurement

Refer to your ministry procurement procedures for guidance.

Requirements

 

Requirements Quality Assurance (Mandatory)

Requirements review is reviewing the requirements and making sure the appropriate stakeholders are in agreement to proceed based on the requirements.

The project manager is responsible for making sure stakeholders have had an opportunity to review the requirements and have agreed the project can continue.

This is the stage gate review meeting, where a group of stakeholders meet when a stage gate is reached and assess the readiness of the project to move into next phase.

Participants include:

  • Project sponsor (or delegate)
  • Project manager 
  • Business area
  • Strategic Planning & Project Management Office
  • Representation from Architecture
  • Client Business Solutions

The group will make one of three decisions about next steps for the project:

  1. Proceed as planned: Project has met its stage gate criteria and project can proceed to next phase 
  2. Proceed with remedial action: Project has met certain stage gate criteria and can proceed to next phase provided unaddressed needs are addressed immediately
  3. Rework required: Project has not met its stage gate criteria and project cannot proceed to next phase unless criteria is met
 

Gate 2.x Project Review/PMO Gate

The gating process ensures that projects are examined at key decision points and provides assurance that projects can progress successfully to the next stage. 

This gate is to ensure a common understanding and agreement with the project requirements, design, build/test and/or deployment.  During this gate the project should be maintaining focus on goals, objectives, approach, scope, schedule, and budget and making required adjustments to the project in order to best ensure success.

There are three primary roles for the stage gate:
1. Presenter, likely the project manager
2. Facilitator, likely the PMO
3. Chair, a decision making role

Depending on the project, the individuals in the roles may be different.  This will be discussed during the project initiation meet with the PMO.

 

Design

Whiteboard sessions are scheduled at various stages of the project to ensure that the direction being taken is following Natural Resource Sector IM/IT standards.

The purpose of a whiteboard session is to bring together the necessary business and technical resources to determine the best approach and best practices to:

  • Address a business need using information technology;
  • Address a technology issue relating to an application or service provided by the Information Management Branch (IMB); or
  • Achieve decisions that will allow the work to go forward.

There are different types of whiteboards carried out at different times within a project as identified in Usage Within the SDLC.

  • Feasibility Whiteboard – is used to define the business problem and identify potential system solutions that may be viable within the Ministry standard deployments.
  • Technical Whiteboard – is used to confirm the design solution identified by the vendor will fit within the Ministry standard deployment patterns and confirms the technology and servers to be used.
  • Warehouse Whiteboard – is used to get agreement from both DataBC and the operational resources on what and how data will be replicated to the data warehouse.

Standards/Guidelines

Standard booking procedures are available at:

Templates

A whiteboard checklist is available to assist in asking the right questions and documenting the results of the whiteboard sessions:

Deliverable Requisite

A whiteboard session is mandatory for all project complexity levels.

It is expected NRS Projects continue using Whiteboards and Technical Advisory Group (TAG) and Architecture Review Board (ARB) is not intended to replace either Whiteboards or TAGs. If at a Whiteboard or TAG, a solution is recommended that does not conform to NRS architecture, the project must proceed with an ARB Submission and receive exemption before advancing with that solution.

Samples

There is no sample currently available.

The Request for Change (RFC) identifies the components being included in an application release that will impact one of the Natural Resource Sector technical environments.

An RFC should be initiated as early as possible via the JIRA tool.  RFCs are reviewed every Thursday, and must be submitted at least three (3) business days in advance.  RFCs must be updated and resubmitted for each target environment (Integration, Test, and Production).  An emergency RFC may be handled outside of this policy on an exception basis.
 
Deployment constraints:
  • Integration environment – Daily
  • Test environment – Monthly (third Wednesday of each month)
  • Production environment – Monthly (third Tuesday of each month)

Standards / Guidelines

  • The standard is to complete the RFC form in JIRA and submit the form to the Release Manager for review and approval.

Templates

  • The template is only available as a JIRA form.

Deliverable Requisite

The Deliverable is mandatory for all projects.

Samples

  • Samples are not available at this time

Quality assurance is a way of preventing mistakes or defects and avoiding problems when delivering solutions or services. It must address both the management and the product of the project, and should be planned into the project and product, and define and set the appropriate standards and identify how these standards are to be met.

Quality should focus on:

  • Fitness for use
  • Fitness for purpose
  • Conformance to requirements
  • Customer satisfaction

For additional information:

For a project, specialized workstations, hardware or software may be required.  These must be ordered using the NRS Business Service Desk request forms.

Standards / Guidelines

The standard is to submit your request using the form linked below.

Templates

The NRS Business Service Desk website (BC Government Access Only) contains the forms required for each of these requests.

Use the “Workstation Requests” form for workstation requests, use the “Hardware & Software Requests” for any non-workstation IT hardware requests or workstation software requests. 

Complete the forms with as much detail as possible (for example needs, source (website), vendor, model number, quantity, etc.).  If there are any questions, someone will follow up with you to clarify your request.

Deliverable Requisite

Workstation Hardware Request forms are optional for all project complexities unless there is a need for equipment.

Samples

There are no samples available.

This is the stage gate review meeting, where a group of stakeholders meet when a stage gate is reached and assess the readiness of the project to move into next phase.

Participants include:

  • Project sponsor (or delegate)
  • Project manager 
  • Business area
  • Strategic Planning & Project Management Office
  • Representation from Architecture
  • Client Business Solutions

The group will make one of three decisions about next steps for the project:

  1. Proceed as planned: Project has met its stage gate criteria and project can proceed to next phase 
  2. Proceed with remedial action: Project has met certain stage gate criteria and can proceed to next phase provided unaddressed needs are addressed immediately
  3. Rework required: Project has not met its stage gate criteria and project cannot proceed to next phase unless criteria is met
 

Gate 2.x Project Review/PMO Gate

The gating process ensures that projects are examined at key decision points and provides assurance that projects can progress successfully to the next stage. 

This gate is to ensure a common understanding and agreement with the project requirements, design, build/test and/or deployment.  During this gate the project should be maintaining focus on goals, objectives, approach, scope, schedule, and budget and making required adjustments to the project in order to best ensure success.

There are three primary roles for the stage gate:
1. Presenter, likely the project manager
2. Facilitator, likely the PMO
3. Chair, a decision making role

Depending on the project, the individuals in the roles may be different.  This will be discussed during the project initiation meet with the PMO.

 

Build/Test

Project teams generate DDL scripts from a variety of tools, which may also require some minimal manual clean up prior to use. Scripts should match the target environment database.

This report will be available in a future NRS EA Template release.

 

Standards/Guidelines

The development of solutions includes the specification and execution of unit tests, integration tests and user acceptance tests. Test cases must be constructed for each project. These tests should be structured to provided adequate coverage of both system and business functionality. Wherever possible, automated testing should be implemented in order to reduce the burden that manual testing imposes on developers and business staff.

1.1          Test Plan

The Test Plan is a document that is used to review and sign off testing activities. The Test Plan is a mandatory deliverable for development projects.

1.2          Unit Testing

Unit tests should be created for all classes and significant methods identified in the design. The JUnit tool will be used to create unit tests. However, not all classes require a unit test. The number of unit tests should reflect a useful coverage of major functionality for each class or component.

1.3          Integration Testing

To assist testers conducting integration testing, documentation of expected results should include expected results at the completion of significant points in the test steps. The design of integration tests should be informed by messages that are conveyed between component elements or objects as depicted in the system design.

1.4          User Acceptance Testing

Acceptance Testing (UAT) is based upon scenario tests to be executed by business staff. To assist business users conducting acceptance tests, documentation of expected results should be included for each step in the test. The NRS provides a template to be used as a guide to help create UAT document.

Templates

Deliverable Requisite

A test plan is mandatory for development projects.

Samples

There are no samples available.

Standards/Guidelines

The deployment plan documents the detailed steps and sequencing of activities and tasks needed to deliver the project into an operational production environment or state. For IM/IT projects delivering to the Natural Resource Sector Integrated Systems and Service Strategy (ISSS) environment, this would include the integration, test, and production environments.

The NRS Technical Change and Release Committee (TCRMC) is in place to support the authorization of technical changes and to assist change management in the assessment and prioritization of changes. TCRMC reviews and approves technical releases being deployed into all environments. A request for change (RFC) process guides the deployment process and activities.

The project manager or business portfolio manager is responsible for obtaining agreement about the deployments from the business area and stakeholders, engaging with the required technical teams at appropriate times, and to complete required documentation including requests for change and deployment.

Templates

No template is available at this time.

Deliverable Requisite

The requirement for this deliverable will be determined with the project management office.

Samples

There are no samples available.

Standards/Guidelines

The User Acceptance Test Summary Report is a mandatory deliverable that summarizes the test activities and overall final results. It is prepared after user testing is completed.

Templates

No template is available at this time.

Deliverable Requisite

A UAT report is mandatory for development projects.

Samples

There are no samples available.

Standards/Guidelines

Vulnerability scans (finds vulnerabilities in your web application dynamically):

  • Required by policy (Information Security Policy) and standards (Security Standards for Web Development and Deployment)
  • Scans are to happen anytime there is significant change (OCIO defines significant as “requires a contractor/skilled employee to develop the change”)
  • Scans should happen annually even if no changes have been done
  • Remediation timelines for found vulnerabilities should be  based off of risk (higher risk should equate to faster remediation)
  • Recommend vulnerabilities be ranked based off of CVSS score (Common Vulnerability Scoring System)
  • Consideration of risk should include other applications if in a shared environment (i.e. your application is low sensitivity, but you share the environment with a highly sensitive application)
  • CVSS scores of 9 to 10 (critical) are expected to be remediated immediately

 

Penetration test (someone tries to hack your system and documents how they did it):

  • Should be considered based off of risk (public facing/high value/high profile/shared environment)
  • From a financial side, these tests are known to be quite expensive (tens of thousands)
  • Remediation timelines should be risk based (higher risk, faster remediation)

This is the stage gate review meeting, where a group of stakeholders meet when a stage gate is reached and assess the readiness of the project to move into next phase.

Participants include:

  • Project sponsor (or delegate)
  • Project manager 
  • Business area
  • Strategic Planning & Project Management Office
  • Representation from Architecture
  • Client Business Solutions

The group will make one of three decisions about next steps for the project:

  1. Proceed as planned: Project has met its stage gate criteria and project can proceed to next phase 
  2. Proceed with remedial action: Project has met certain stage gate criteria and can proceed to next phase provided unaddressed needs are addressed immediately
  3. Rework required: Project has not met its stage gate criteria and project cannot proceed to next phase unless criteria is met
 

Gate 2.x Project Review/PMO Gate

The gating process ensures that projects are examined at key decision points and provides assurance that projects can progress successfully to the next stage. 

This gate is to ensure a common understanding and agreement with the project requirements, design, build/test and/or deployment.  During this gate the project should be maintaining focus on goals, objectives, approach, scope, schedule, and budget and making required adjustments to the project in order to best ensure success.

There are three primary roles for the stage gate:
1. Presenter, likely the project manager
2. Facilitator, likely the PMO
3. Chair, a decision making role

Depending on the project, the individuals in the roles may be different.  This will be discussed during the project initiation meet with the PMO.

 

Deployment

The project turnover document should contain or reference all the material to move from project to operations. This will include such items as:

  • Roles and responsabilities to accomplish turnover
  • Schedule of activities to be accomplished turnover
  • Communications plan and materials
  • Training plan and material for users, help desk, technical support, etc. 
  • Design materials and as-built materials
  • Operational instructions for the system administrator
  • Instructions for regularly monitor, performance tuning and maintenance of the product

Standards/Guidelines

Training needs are assessed early in the project and a training plan is prepared during the Initiation and Planning phase. Training to users, administrators, and support teams on the product may occur at different times throughout the project. During implementation and deployment, users will require training, documentation and support to use the system effectively. Training is often a sign-off requirement at handover and may be in scope for post implementation review.

Project managers, business portfolio managers, and the business areas are all responsible for aspects of training.

This is the stage gate review meeting, where a group of stakeholders meet when a stage gate is reached and assess the readiness of the project to move into next phase.

Participants include:

  • Project sponsor (or delegate)
  • Project manager 
  • Business area
  • Strategic Planning & Project Management Office
  • Representation from Architecture
  • Client Business Solutions

The group will make one of three decisions about next steps for the project:

  1. Proceed as planned: Project has met its stage gate criteria and project can proceed to next phase 
  2. Proceed with remedial action: Project has met certain stage gate criteria and can proceed to next phase provided unaddressed needs are addressed immediately
  3. Rework required: Project has not met its stage gate criteria and project cannot proceed to next phase unless criteria is met
 

Gate 2.x Project Review/PMO Gate (Mandatory)

The gating process ensures that projects are examined at key decision points and provides assurance that projects can progress successfully to the next stage. 

This gate is to ensure a common understanding and agreement with the project requirements, design, build/test and/or deployment.  During this gate the project should be maintaining focus on goals, objectives, approach, scope, schedule, and budget and making required adjustments to the project in order to best ensure success.

There are three primary roles for the stage gate:
1. Presenter, likely the project manager
2. Facilitator, likely the PMO
3. Chair, a decision making role

Depending on the project, the individuals in the roles may be different.  This will be discussed during the project initiation meet with the PMO.

 

Deploy refers to the processes required to deliver code and install/configure the software into an operational environment.

Projects need to ensure they engage with the applicable CSNR IMB technical teams.

 

Project Execution Completion

This is the stage gate review meeting, where a group of stakeholders meet when a stage gate is reached and assess the readiness of the project to move into next phase.

Participants include:

  • Project sponsor (or delegate)
  • Project manager 
  • Business area
  • Strategic Planning & Project Management Office
  • Representation from Architecture
  • Client Business Solutions

The group will make one of three decisions about next steps for the project:

  1. Proceed as planned: Project has met its stage gate criteria and project can proceed to next phase 
  2. Proceed with remedial action: Project has met certain stage gate criteria and can proceed to next phase provided unaddressed needs are addressed immediately
  3. Rework required: Project has not met its stage gate criteria and project cannot proceed to next phase unless criteria is met

The gating process ensures that projects are examined at key decision points and provides assurance that projects can progress successfully to the next stage. 

This gate is to ensure a common understanding and agreement with the project requirements, design, build/test and/or deployment.  During this gate the project should be maintaining focus on goals, objectives, approach, scope, schedule, and budget and making required adjustments to the project in order to best ensure success.

There are three primary roles for the stage gate:
1. Presenter, likely the project manager
2. Facilitator, likely the PMO
3. Chair, a decision making role

Depending on the project, the individuals in the roles may be different.  This will be discussed during the project initiation meet with the PMO.