System Development Life Cycle Processes For the Natural

Corporate Services for the Natural Resource Sector

Information Management Branch

System Development Life Cycle Processes For the Natural Resource Sector

Last Updated: March 19, 2012

Version: 1.0.0

Document: NRS_IMIT_SDLC_Processes.docx

CSNR SDLC Processes Information Management Branch

i

Contents 1 Business Architecture ............................................................................................................................................................................................... 1‐1

1.1 Phase 1: Business Planning............................................................................................................................................................................... 1‐1

1.2 Phase 2: Application Planning .......................................................................................................................................................................... 1‐4

2 Systems Development Life Cycle – New Development ............................................................................................................................................ 2‐1

2.1 Phase 1: Initiation ............................................................................................................................................................................................. 2‐1

2.2 Phase 2: Analysis .............................................................................................................................................................................................. 2‐7

2.3 Phase 3: Design .............................................................................................................................................................................................. 2‐14

2.4 Phase 4: Build ................................................................................................................................................................................................. 2‐19

2.5 Phase 5: Implementation ............................................................................................................................................................................... 2‐27

3 Systems Development Life Cycle – Maintenance ..................................................................................................................................................... 3‐1


3.2 Phase 2: Analysis & Design ............................................................................................................................................................................... 3‐5

3.3 Phase 3: Build ................................................................................................................................................................................................... 3‐9

3.4 Phase 4: Implementation ............................................................................................................................................................................... 3‐12

4 Systems Development Life Cycle – Lightweight Development Framework ............................................................................................................. 4‐1


4.2 Phase 2: Analysis & Design ............................................................................................................................................................................... 4‐2

4.3 Phase 3: Build ................................................................................................................................................................................................... 4‐2

4.4 Phase 4: Implementation ................................................................................................................................................................................. 4‐3

5 Project Management Monitoring and Control Deliverables .................................................................................................................................... 5‐1


ii

Version History

Version Date Responsible Notes

1.0.0 2012‐03‐20 Standards Review Committee First Published Release.

Purpose

The intent of this document is to identify the tasks required for the various systems development processes within the CSNR Information Management Branch. This document was created in collaboration with members of the Standards Review Committee and a core group of Senior Business Portfolio Managers. It will be used to create the new SDLC web pages, their content, and the new single SDLC checklists based on a rightsizing calculator to be created.

Requirement • M = Mandatory

• R = Recommended

• O = Optional


1‐1

1 Business Architecture Allows for the identification of the business processes that a business area is or will be implementing and may require systems to support.

Phase Task Responsibility1 Artifact Requirement Comments

1.1 Phase 1: Business Planning • Meet with the Business Area to identify the

project BPM / Business Area Project Assessment

Document M

• Conduct Procurement / Establish Contract BPM / Business Area Procurement document / Contract

O Required if in‐house resources are not available

• Develop Conceptual Requirements BPM / Business Area / Vendor

Conceptual Requirements

O Required if business area has not conducted a process review in the past 3 years or is undergoing business process change.

• Review Conceptual Requirements BPM / Business Area / Technical Architect

Review Results

• Conceptual Requirements Signoff BPM /Business Area / Vendor

1 Technical Advisory Committee consists of the assigned resources by service area for Client Business Solutions, Infrastructure and Middleware, Architecture, Data Administration, Database Administration, Workstation Services, Application Delivery, and NRS Servicedesk. This will link to the new Project Roles and Responsibilities document (once consolidated).

http://www.for.gov.bc.ca/his/sdlc/ProjectAssessmentDocument.pdf



1‐2



• Final Conceptual Requirements ‐ Sign off – the original signed copy of the artifact should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM Signed Conceptual Requirements

M ***link to filing procedures ***

• Conduct Feasibility Whiteboard session with Technical Advisory Committee. If there is a possibility of spatial or warehouse components, contact the Geomatics Sr. BPM to determine additional resources to attend.

BPM / Technical Architect / Business Area

Feasibility Whiteboard Checklist Minutes

M CSNR R SLK Whiteboard Sessions CSD:EX

Use CSNR IMB Whiteboard distribution list

Whiteboard Calendar

• Determine the change control process that will be used. (There are currently two processes. One for highly integrated application suites or applications that have many external dependencies and one for more autonomous applications.)

BPM / Application Delivery

M

http://www.for.gov.bc.ca/his/sdlc/whiteboard_checklist.docx


http://www.for.gov.bc.ca/his/sdlc/Whiteboard%20Calendar%20Process.pdf


1‐3



• Transformation Plan BPM /Business Area / Vendor

Transformation Plan O Required if area of requirements is larger than one application and changes will take more than 1 year to implement. Allows for phased implementation.

• Transformation Plan review BPM / Business Area / Technical Architect

QA Results

• Transformation Plan Signoff BPM /Business Area /Vendor

• Transformation Plan ‐ Sign off – the original signed copy of the artifact should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM Signed Transformation Plan



1‐4



1.2 Phase 2: Application Planning • Develop Software Needs Assessment BPM / Business Area /

Vendor Software Needs Assessment

M

• Review Software Needs Assessment BPM / Business Area / Vendor Technical Architect

Review Results

• Software Needs Assessment Signoff BPM /Business Area /Vendor

• Software Needs Assessment ‐ Sign off – the original signed copy of the artifact should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM Signed Software Needs Assessment


• Develop Gap Analysis or Business Solution Options

BPM / Business Area / Vendor

Gap Analysis Document or

Business Solution Options

O Required if there are similar existing software applications available in the sector, in government or as COTS solutions.


1‐5



• Review Gap Analysis or Business Solution Options

BPM / Business Area / Vendor Technical Architect

Review Results

• Gap Analysis or Business Solution Options Signoff

BPM /Business Area /Vendor

• Create Business Case BPM /Business Area / Vendor

Business Case O Required if capital funding will be necessary to build the solution. Business Case processes have not been finalized and should not be restricted to Capital funding only.

• Review Business Case BPM / Business Area / Technical Architect

Review Results O

• Business Case Signoff BPM /Business Area /Vendor

• Initiate Project Charter(s) BPM/ Business Project Charter O

• Identify Project Resources Business Area/ BPM Project Team Charter, Skills matrix, Responsibility Assignment Matrix, Steering Committee, technical advisors

O


2‐1

2 Systems Development Life Cycle – New Development2 Allows for the creation of a new application system to support a business need. New application systems are assets and must use capital funding to be built. It is preferred but not required that components of the Business Architecture process be completed prior to the identification of a new development project.

Phase Task Responsibility Artifact Requirement S M C3 Comments

2.1 Phase 1: Initiation • Meet with the Business Area to identify the

project BPM / Business Area Project Assessment

Document M M M

• Initiate Project Charter (if not already created)

BPM / Business Lead Project Charter M M M

• Identify Project Resources (if not already done)

BPM / Business Lead Project Team Charter, Skills matrix, Responsibility Assignment Matrix, Steering Committee, technical advisors

M M M

• Conduct Feasibility Whiteboard session with Technical Advisory Committee. If there is a possibility of spatial or warehouse components, contact the Geomatics Sr. BPM to determine additional resources to attend.

BPM / Technical Advisory Committee / Business Area

Feasibility Whiteboard Checklist Minutes

M M M CSNR R SLK Whiteboard Sessions CSD:EX


Whiteboard Calendar

2 New Development covers both Custom Development and COTS/MOTS implementations. 3 Mandatory indicators based on project size – Simple, Moderate, or Complex.







2‐2



• Review Project Charter BPM/ Business Area / Technical Advisory Committee

Review Results M M M

• Initiate Impact Analysis BPM / Business Lead / Development Team / Technical Lead / Systems Technical Analyst / Data Analyst / Data Custodian / Application Custodian / Development Team Lead / DBA / Data Standards Manager / Data Resource Manager

Impact Analysis O O O Required when multiple business areas may be impacted by the new application.

Will need to include new Business Calendar Committee

• Document Management per Records Management practice.

BPM M M M


2‐3



• Final Project Charter – Signoff ‐ the original signed copy of the Project Charter should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM Signed Project Charter M M M ***link to filing procedures ***

• Create Project Identification Form BPM / Business Area Project Identification Form

M M M NOTE: this deliverable is intended for ISP/ SIP committee (non‐existent) – details need to be confirmed on scope

• Create Business Case BPM / Business Area Business Case M M M Required if requesting Capital funding and not previously completed. The process for Business Cases has not been finalized. Should not be only for capital.


2‐4



• Review Business Case BPM / Business Area / Technical Lead

Review Results

• Business Case Signoff BPM / Business Area Need to confirm sign‐off of business cases for a variety of funding sources

• Initiate IM/IT Capital Funding Request process (if required)

BPM/Business Lead/ PMO

M M M The TB Submission process will be superseded for IM/IT Capital projects by this new process coordinated/ facilitated by PMO.

• Complete right‐sizing calculator and appropriate checklist

BPM / Business Area Right‐sizing calculator and checklist

M M M *** new tool will be developed

• Enter new application (acronym, name, description, known participants) in the Application Inventory application (IRS?)

BPM / Application Deliveries

M M M ** Application to be determined as we have multiple at this time.


2‐5





M M M This will identify which delivery and migration approval method will be used

• Initiate STRA with Security Analyst (iSmart)

Business Area / BPM / MISO

STRA M M M

• Conduct Procurement Process BPM Procurement Documents / Contract

M M M Refer to Procurement Process Document

• Initiate Retirement / Archive Plan BPM / Business Area / Technical Lead

Retirement/Archive Plan

M M M

• Initiate PIA with Security Analyst BPM / Business Area / MISO / KIS

PIA M M M

• Initiate Records Impact Assessment BPM / Business Area / Technical Lead / Records Management

Records Impact Assessment

M M M *** talk to Jeff Barber about when this happens ***

• Schedule Project Kick‐off Meeting BPM M M M

• Initiate Master Project Plan / Work Breakdown Structure

BPM / Vendor MPP and WBS O M M


2‐6



• Finalize MOU / SLA eLicensing Manager / eLicencing Team / Ministry team

MOU/SLA M M M Required if a new business area is coming on board to eLicencing.

May also apply in other business areas where there is a need for cross‐sector agreement on use of application.

• Supply Vendor with applicable Standards BPM M M M

• Initiate Application Delivery Checklist BPM Application Delivery Checklist

O M M Application Delivery Checklist

• Conduct Project Kick Off Meeting BPM / Business Area / Vendor / Technology Advisory Committee / MISO

Publish Minutes M M M

http://csdgww.bcgov/imb/bas/app_arch/standards/application_delivery_checklist.html



2‐7



Final Master Project Plan Document ‐ Sign off – the original signed copy of the Master Project Plan should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM ***link to filing procedures ***

2.2 Phase 2: Analysis • Initiate Communication Plan BPM/ Business Area Communications Plan

Communications Log

O M M

• Initiate Risk Mgmt Plan BPM/ Business Area Risk Mgmt Plan

Risk Register

O M M

• Initiate Budget and Cost mgmt Plan BPM/ Business Budget Mgmt Plan

Expense tracking

O M M


2‐8



• Initiate Quality Mgmt Plan BPM/ Business Area Quality Mgmt Plan O O M *** management processes required to ensure the project will satisfy the needs for which it was undertaken. Quality management must address both the management of the project and the product of the project i.e. process and product. Includes: overall quality planning, project performance, ensuring product quality

• Initiate Issue Mgmt Plan BPM/ Business Issue Mgmt Plan

Issue Log/register

O M M

• Initiate Change Control BPM/ Business Change Log

Change Request

M M M

• Gather User Requirements (incorporate into Software Requirements Specifications)

Business Area / BPM / Vendor

M M M


2‐9



• Conduct “Technical Whiteboard Session” with vendor

Business Area / BPM / Vendor / Technical Advisory Committee

Technical Whiteboard Checklist Minutes

M M M CSNR R SLK Whiteboard Sessions CSD:EX


Whiteboard Calendar

• Create Process Model Business Area / BPM / Vendor / Technical Lead / Development Team Lead

Process Model O O O May have been completed as part of Conceptual Requirements in Business Architecture Phase 1

• Create Requirements Storyboards Vendor / BPM / Business Lead / Business SME

Requirements Storyboards

O O O Required if eLicencing application. Similar to flat prototype.

• Conduct Financial Risk and Controls Review (verifies that Chapter 13 of core policy is being followed)

Financial Business Analyst / BPM / Business Lead / Business SME / Vendor Team

Financial Risk and Controls Review

O O O Required if application will contain financial transactions.

Requires involvement of Ministry of Finance resources and costs $$.




http://gwwt.elicensing.gov.bc.ca/docs/storyboards_v1.doc


2‐10



• Create Logical Data Model, create/confirm Data codes

Vendor Logical Data Model M M M ** Have included note about Data Codes….. the integrated dbase utilizes common codes

• Review Logical Data Model DA / BPM / Vendor Review Results M M M

• Create Security Actions and Roles Definition (security matrix)

BPM / Business Lead / Business SME

Security Actions and Roles Definitions

O M M

• Develop draft Software Requirements Specification (SRS)

Vendor Software Requirements Specification

M M M

• Identify Data Conversion Requirements Business Area / BPM / Vendor

Data Conversion Requirements (if not included in SRS)

O O O Required if new system will replace an existing one for which the business area wishes to retain historical data.

• Review Domain Model DA Review Results O O O

• Review Draft Software Requirements Specification (SRS) Ensure Ministry Standards are being met.

Business Area / BPM / Technical Advisory Committee


• Incorporate changes to SRS Vendor Software Requirement Specification

M M M


2‐11



• Confirm SRS changes are per QA responses

BPM M M M

• Ensure SRS is signed off by Project Champion and copy filed per records management policy.

BPM

Final Software Requirements Specification – Sign off – the original signed copy of the SRS should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM *** link to filing procedures ***


2‐12



• Develop Business Solutions Options BPM / Business Lead / Technical Lead

Business Solutions Options

O O O If a Gap Analysis was conducted for this project, this is not required.

Required if there are similar existing software applications available in the sector, in government, or as COTS solutions. Need to justify the technical implementation of the solution now that requirements have been defined.

• Review Business Solutions Options BPM / Technical Advisory Committee

Review Results O O O

• Develop Business Prototype Development Team Lead / BPM / Development Team / Business Lead / Technical Lead / User Group

Business Prototype O M M May have been included as part of the SRS


2‐13



• Draft Implementation Plan Business Area / BPM / Technical Lead / Development Team Lead

Implementation Plan O M M

• Draft Training Plan Business Area/ BPM Training Plan O O M

• Draft User Acceptance Test Plan BPM / Business Lead / Technical Lead / Development Team / User Group / User Test Team / Systems Technical Analyst

User Acceptance Test Plan

O M M

• Create Data Management Plan BPM / Business Lead / User Group / Data Custodian / Data Standards Manager / Data Resource Manager

Data Management Plan

O M M

• Refine PIA BPM / Business Lead / Data Custodian / MISO

PIA M M M

• Refine STRA BPM / Business Area / MISO

STRA M M M


2‐14



• Create Capacity Plan Development Team Lead / BPM / Technical Lead / Development Team

Capacity Plan O M M

• Revise Impact Analysis BPM / Business Lead / Development Team / Technical Lead / Data Custodian / Application Custodian / Development Team Lead / Technical Advisory Committee

Impact Analysis O O O Required when multiple business areas may be impacted by the new application.

Will need to include new Business Calendar Committee

• Training Team Kick‐off Meeting BPM/ Business Lead/ Business Area/ User Group

O O M

2.3 Phase 3: Design • Draft Software Design Description

(SDD)/Design Specification Document (DSD)

Vendor Software Design Description

M M M Vendor must include list of standards they are using for the application.


2‐15



• User Interface Specification BPM / Development Team / Business Lead / Development Team Lead / User Group / Systems Technical Analyst / Development Team Quality Reviewer

User Interface Specification

O O O May have been included in the SDD

• Reporting Specification BPM / Development Team / Business Lead / Development Team Lead / User Group / Systems Technical Analyst / Development Team Quality Reviewer

Reporting Specification

O O O May have been included in the SDD

• Submit Infrastructure Request Form BPM / Systems Technical Analyst / Development Team Lead / Web Analyst / Application Deployment

Infrastructure Request Form

O O O Required if new equipment will be necessary to implement the solution


2‐16



• Prepare Vendor Test Plan Vendor M M M

• Confirm Vendor Test Plan BPM / Business Lead M M M

• Create Physical Data Model Vendor Physical Data Model M M M

• Review Physical Data Model DBA / DA / Vendor / BPM


• Draft Data Conversion Design Vendor Data Conversion Design

O O O Required if data will be retained from previous application.

• Design Warehouse replication procedures (if warehousing is required, a “Warehousing Whiteboard” is required)

Vendor / Warehouse BPM / DA / Business Area / BPM / DBA

Warehouse Replication

O O O Required if data will be replicated to the BCGW

• Develop and complete data security profile (operational)

Business Area / BPM Data Security Profile M M M

• Complete Metadata Definition Business Area / BPM Metadata Definition O O O Required if warehousing the data

• Develop and complete warehouse data security profile

Business Area / BPM Warehouse Data Security Profile

O O O Required if warehousing data

• Complete PIA BPM / Business Lead / Data Custodian / MISO

Signed PIA M M M Must be filed with OCIO KM


2‐17



• Draft QA Test Plan BPM/ Business Lead / Vendor

QA Test Plan O M M ** plan to test out technical scenarios and conditions which the business users may not be even aware of. It will include integration testing of the application. As well, it will ensure that the system complies with ministry standards. **

• Technical Prototype BPM / Development Team / Business Lead / Development Team Lead / User Group / Systems Technical Analyst / Development Team Quality Reviewer

Technical Prototype O O O May have been included in the SDD

• Review draft Software Design Description /Design Specification Document

BPM / Technical Advisory Committee

Review Results O O O

• Incorporate changes to SDD Vendor Software Design Description

M M M


2‐18



• Confirm SDD changes are per QA responses

BPM M M M

• Ensure SDD is signed off by Project Champion and copy filed per records management policy.

BPM

Final Software Design Description– Sign off – the original signed copy of the SDD should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should also be created and filed in the project folder for future reference.

BPM *** link to filing procedures ***


2‐19



2.4 Phase 4: Build • Develop Application Development Team

Lead / Development Team / Technical Lead / Systems Technical Lead / BPM / Business Lead / Development Team Quality Reviewer

Application code M M M If new vendor, conduct first module code review.

• Prepare Infrastructure Request Form Technical Lead / BPM / Systems Technical Analyst / Development Team Lead / Web Analyst / Application Deployment / Capacity Planning

Infrastructure Request Form

O O O Required if new equipment will be necessary and not previously requested to implement the solution.


2‐20



• Develop Online Help Development Team Lead / Development Team / Technical Lead / Systems Technical Lead / BPM / Business Lead / Development Team Quality Reviewer

Online Help Files O M M Determined at technical whiteboard if online help or paper file.

Must have one or other.

• Develop User Materials Development Team Lead / Development Team / Technical Lead / Systems Technical Lead / BPM / Business Lead / Development Team Quality Reviewer

User Materials O M M Determined at technical whiteboard if online help or paper file.

Must have one or other.

• Security Matrix Updates BPM / Vendor Team / Business Lead / Business Area

Security Matrix M M M Required if roles have changed since the original security requirements were determined


2‐21



• Develop Data Conversion Development Team Lead / Development Team / Technical Lead / Systems Technical Lead / BPM / Business Lead / Development Team Quality Reviewer

Data Conversion Module

O O O Required if business area wants historical data loaded into the new database.

• Prepare User Acceptance Test Plan (UAT) – including data conversion

Business Area / BPM assists


M M M

• Conduct Vendor Testing Vendor M M M

• Review Developer Test Results BPM / Business Lead M M M

• Conduct on‐site review at Vendor location Business Area / Vendor / BPM

O M M

• Initiate application migration process (QA, Delivery, Test, Production, Train)

BPM M M M This will be dependent on the outcome of the Change Control Processes/ Application Scrutiny

• Build Migration package Vendor M M M


2‐22



• Conduct Application review where appropriate

Application Delivery Specialist / Technical Advisory Committee

Review Feedback M M M

• Revise code, migration package based on QA Feedback

Vendor M M M

• Refine STRA (iSmart) BPM / Business Area / MISO

STRA M M M

• Refine Implementation Plan BPM / Development Team Lead / Business Lead / Technical Lead

Implementation Plan O M M

• Create Data Conversion Implementation Plan

Technical Lead / BPM / Development Team / Business Lead / Development Team Lead / User Group / Systems Technical Analyst / Data Administrator / Database Administrator

Data Conversion Plan O O O If data from previous application or data sources is required to be populated in the new/revised application.


2‐23



• Finalize Records Impact Assessment BPM / Business Lead / Technical Lead / Records Management

Records Impact Assessment

M M M

• Draft QA Test Scripts Technical Lead / Development Team Lead / Development Team / BPM / Systems Technical Analyst / Business Lead

O M M *** need confirmation on what this is ***

NT –test scenarios which will be followed to perform QA testing. All test conditions and expected results are document. During testing actual results are documented and a Pass/Fail status is given. QA Test Scripts may also include actual ddl scripts which may be run to perform integrity tests on the data.

• Prepare User Procedures Manual Business Lead / BPM / Development Team Lead / User Group / Development Team

User Procedures Manual

M M M


2‐24



• Draft Operations Manual Development Team Lead / BPM / Development Team / Business Lead / Technical Lead / User Group / Systems Technical Analyst

Operations Manual M M M

• Prepare Training Plan Business Lead / BPM / Technical Lead / Development Team / User Group / User Test Team / Systems Technical Analyst / NRS Servicedesk

Training Plan O M M

• Conduct Training Team Kick‐off Meeting Business Lead / User Group / BPM

O M M


2‐25



• Prepare User Training Materials Business Lead / BPM / Development Team Lead / Technical Lead / User Group / User Test Team / NRS Servicedesk / Systems Technical Analyst

Training Materials O M M

• Prepare Maintenance Plan BPM / Business Lead / Technical Lead / Development Team Lead / Application Custodian / Data Custodian

Maintenance Plan M M M *** includes deployment diagram ***

• Implement in Delivery environment Vendor / Application Delivery Specialist

Application in Delivery O O O Mandatory if a delivery instance exists for this business area.

• Conduct Data Conversion into Delivery environment

Application Delivery Specialist / DBA

O O O Required if business area wants historical data loaded

• Conduct testing in Delivery Environment BPM / Business Lead / Vendor

O O O Required if delivery environment available to this application


2‐26



• Log Testing Issues BPM / Business Lead Issue Log M M M

• Resolve testing issues Vendor M M M

• Repackage and Redeliver Vendor Application Code M M M

• Retest in Delivery BPM / Business Lead / Vendor

M M M

• Complete STRA (iSmart)

• Review results with Information Owner / Data Custodian

BPM / Business Area / MISO

STRA M M M

• Obtain Approval to migrate to Test environment

Business Lead / BPM/ Application Delivery (VMAD)

Or

Application Scrutiny Committee

M M M This approval will depend on the final application migration processes to be used. Currently uses two processes – BPM/ Business Lead/ Application Delivery or Application Scrutiny Committee (former MFR CMC)


2‐27



2.5 Phase 5: Implementation • Migrate into test environment Application Delivery

Specialist / DBA Application in Test M M M

• Conduct Data Conversion into Test environment


O O O Required if business area wants historical data loaded

• Execute QA Test Scripts BPM QA Test Results O M M Need to ensure separation of responsibility to prevent conflict of interest

• Conduct UAT in Test Environment (including Data Conversion Testing)

Business Lead / User Test Team / BPM / Vendor

UAT Test Results M M M

• Log Testing Issues BPM / Business Lead Issue Log M M M

• Prioritize Issues and get vendor to resolve BPM / Business Lead M M M

• Resolve priority issues Vendor M M M

• Repackage release and redeliver Vendor Application Code M M M

• Retest Business Lead / BPM / User Test Team

M M M


2‐28



• Refine Operations Manual BPM / Development Team / Business Lead / Technical Lead / User Group / Systems Technical Analyst

Operations Manual O M M Required if changes made in deployment since document started.

• Update Software Design Document Vendor Software Design Document

O O O Required if modifications were made to the code based that does not align to the SDD.

• Present application to the NRS Servicedesk if they will be supporting it.

BPM / NRS Servicedesk Lead(s)

M M M

• Approve migration to Production environment

Business Lead / BPM M M M Dependent on change control processes


2‐29



• Obtain Approval to migrate to PROD environment


Or


M M M This approval will depend on the final application migration processes to be used. Currently uses two processes – BPM/ Business Lead or Application Scrutiny Committee (former MFR CMC)

• Conduct Data Conversion in Production environment


O O O Required if business area wants historical data loaded into the database.

• Conduct Production Confirmation Business Lead M M M

• Conduct Data Conversion Confirmation Business Lead O O O Required if conversion included.

• Migrate to Training environment Application Delivery Specialist / DBA

O O O Required if a training environment has been requested by the business area.


2‐30



• Conduct Data Conversion in Training environment


O O O Required if business area wants historical data loaded into the database.

• Update/Confirm User Training Materials Business Lead/ BPM Up‐to‐date User Training materials

O O O

• Conduct User Training Sessions Business Lead / User Group / BPM

O M M

• Review/ Confirm User Manuals Business Lead/ User Group/ BPM

O O O

• Review/ Confirm Maintenance Plan BPM/ Vendor Updated Maintenance Plan

O O O

• Review/ Confirm Handover Plan BPM/ Vendor/ Business Lead/ NRS Servicedesk

Updated Handover Plan

O O O

• Complete Project Evaluation/ Post Project Review

BPM/Business/ PMO Project Evaluation

Or

PIR

M M M

• Review and ensure project documentation appropriately filed

BPM M M M ARCS x‐reference available from PMO


2‐31



• Next Steps documented BPM/ Business Next Steps M M M

• Post Training Survey BPM Survey results O O O


3‐1

3 Systems Development Life Cycle – Maintenance Modifications to existing functionality of an application that is paid for from operational budget. Does not include major enhancements which are the addition of new functionality but may include technology upgrades which may result in a major release versus bug fixes which are a minor or patch release. Version numbering of M.m.p where M = Major release number; m = minor release number; p = patch release number.

Phase Task Responsibility Artifact Requirement Comments

3.1 Phase 1: Initiation • Procurement BPM O Required once original

RFP for build is complete and renewal options on existing RFPs have been fully utilized or it has been determined that the current support vendor is not delivering to Ministry satisfaction.

• Contract BPM O Required if procurement proceeds

• Right size work BPM Rightsizing calculator and checklist

R Rightsizing work will confirm the level of work that will be required to complete the work. Not all deliverables will be required for all projects

• Initiate Project Charter BPM/ Business Area M


3‐2



• Identify Project Resources BPM/ Business Lead Project Team Charter, Skills Matrix, Responsibility Assignment matrix, Steering Committee, technical advisors

O



M

• Initiate Project Plan/ Work Breakdown Structure

BPM / Vendor Project Plan and WBS O

• Schedule Project Kick‐off Meeting BPM M

• Finalize Project Charter BPM


3‐3



• Final Project Charter – Signoff ‐ the original signed copy of the Project Charter should be placed in the appropriate records management location by the Business Portfolio Manager. Hard copy to file (ARCS and ORCS). A copy may also be retained by the Business Area. A scanned copy of the signed document should be kept in the project folder.

BPM Signed Project Charter *** link to filing procedures ***

• Supply Vendor with Standards BPM M

• Initiate Application Delivery Checklist BPM M Application Delivery Checklist

• Conduct Kick off Meeting BPM / Business Area / Vendor / Technology Advisory Committee / MISO

Publish Minutes M

• Review / Create Maintenance Plan BPM / Business Lead / Technical Lead / Development Team Lead / Application Custodian / Data Custodian

Maintenance Plan M Review plan if created in previous New Development process.

Create if it does not exist.




3‐4



• Review/ Create Retirement Archive Plan BPM / Business Area / CRO / DA

Retirement Archive Plan

M Evaluate if application can now be retired.

• Review/ Initiate PIA BPM/ Business Area/ MISO

PIA M

• Review/ Initiate STRA BPM/ Business Area/ MISO

STRA M

• Review/ Initiate RIA BPM/ Business Area/ CRO

RIA M

• Review/ Initiate Impact Analysis BPM/ Business Lead/ Development Team, Technical Advisory Committee

Impact Analysis M Include: integrated environments/ applications, data warehouses, ESF (not exclusive list)

• Identify Issues Application Administrator / BPM / Vendor

Issue Log M Gathering issues from all sources i.e. NRS Servicedesk, business issues, technology issues, SSBC


3‐5



3.2 Phase 2: Analysis & Design • Review/ Update Communications Plan as

required

BPM/ Business Lead Updated Communications Plan

O Depending on work to be completed, existing communications plan may not meet current need

• Review Update Risk Mgmt Plan BPM/ Business Lead Updated Risk Mgmt Plan

O Depending on work to be completed, existing risk mgmt plan may not meet current need

• Initiate Budget tracking BPM Budget Tracking tool O Existing tool may meet needs and simply appended to or start tracking for this migration

• Review/ Update Quality Mgmt Plan BPM Updated QM Plan and QA Test Plan

O Depending on work to be completed, existing QM Plan may not meet current need


3‐6



• Review/ Update Issue Mgmt Plan and log BPM Updated Issue Mgmt Plan and Issue log

O Depending on work to be completed, existing Issue Mgmt Plan may not meet current need

• Review/ Update Change Control BPM Change Log M Depending on work to be completed, existing Change log may be all that is required or a new log may be required for this migration

• Construct CSCR or CR (depending on final process) for issues selected by Application Administrator

BPM / Application Administrator

M

• Prioritize Items for Estimation Application Administrator / BPM / User Group

M

• Get Detailed Estimates for CSCR/CR Vendor M

• Review and approve CSCR/CR BPM/ Business Area/ Expense Authority

M


3‐7



• Define Release Content and timing Application Administrator / BPM / User Group

M

• Conduct “Technical Whiteboard Session” with vendor

Business Area / BPM / Vendor / Technical Advisory Committee

Technical Whiteboard Checklist Minutes



Whiteboard Calendar

• Submit Infrastructure Request BPM / Application Administrator

O Required if additional equipment is required to implement this release

• Create Addendums to Software Requirements Specification

Vendor SRS Addendums M

• Create Addendums to Software Design Document

Vendor SDD Addendums M




3‐8



• Revise Logical Model Vendor Logical Model O Required if adjustments to the logical model are required to support the items being implemented in this release

• Review logical model DA / Vendor / BPM Review Results O Required if logical model updated for this release

• Revise Physical Data Model Vendor Physical Model O Required if adjustments to the physical model are required to support the items being implemented in this release

• Review physical model DBA / DA / Vendor / BPMReview Results O Required if physical model updated for this release

• Review/ confirm Data Conversion Implementation Plan

Technical Lead/ BPM/ O


3‐9



• Review Addendums Application Administrator / BPM / User Group / Technical Advisory Committee

Review Results M

• Adjust User Acceptance Test Plan Application Administrator / BPM


O Required if additional features are being implemented in the release

• Adjust Training Plan Application Administrator / BPM

Training Plan O Required if additional features are being implemented in the release

3.3 Phase 3: Build • Review/ confirm QA Test Scripts Technical Lead/

Development Team Lead/ BPM

Updated QA Test Scripts

O Whatever change is being made, may require changes to existing or additional scripts

• Application Adjustments Vendor M


3‐10



• Conduct on‐site review at Vendor Site Application Administrator / BPM / User Group / Vendor

O

• Initiate application migration process (QA, Delivery, Test, Production, Train)

BPM O This will be dependent on the outcome of the Change Control Processes/ Application Scrutiny

• Package Release for QA and Delivery Vendor M

• Review and Confirm Implementation Plan BPM/ Business Lead/ Technical Lead/ Development Team Lead

O

• Conduct Application QA where appropriate

Application Delivery Specialist / Technical Advisory Committee

QA Results M

• Revise package and code as required Vendor M

• Migrate release into delivery (if available) Vendor / Application Delivery Specialist

O


3‐11



• Conduct Data Conversion into Delivery environment


O Required if new table structures created that need to be populated from historical data.

• Conduct testing in Delivery environment Vendor / Application Administrator / BPM

O

• Resolve testing issues Vendor O

• Repackage and Redeliver Vendor O

• Retest in Delivery BPM / Application Administrator / Vendor

O


3‐12



• Obtain Approval to migrate to Test environment

Business Lead / BPM / Application Delivery (VMAD)

or


M This approval will depend on the final application migration processes to be used. Currently uses two processes – BPM/ Business Lead/ Application Delivery or Application Scrutiny Committee (former MFR CMC)

3.4 Phase 4: Implementation • Migrate into test environment Application Delivery

Specialist / DBA Code Package M

• Conduct Data Conversion into Test environment



• Execute QA Test Scripts BPM QA Test Results O


3‐13



• Conduct UAT in Test Environment (including Data Conversion Testing)

Business Lead / User Test Team / BPM / Vendor

M

• Log Testing Issues BPM / Business Lead M

• Prioritize Issues and get vendor to resolve BPM / Business Lead M

• Resolve priority issues Vendor M

• Repackage release and redeliver Vendor M

• Retest Business Lead / BPM / User Test Team

M

• Refine Operations Manual BPM / Development Team / Business Lead / Technical Lead / User Group / Systems Technical Analyst

O Required if new features or obvious changes added in this release

• Present application to the NRS Servicedesk if they will be supporting it

BPM/ NRS Servicedesk Lead(s)

M


3‐14



• Obtain Approval to migrate to PROD environment


Or


M This approval will depend on the final application migration processes to be used. Currently uses two processes – BPM/ Business Lead/ Application Delivery or Application Scrutiny Committee (former MFR CMC)

• Migrate to Production environment Application Delivery Specialist / DBA

M

• Conduct Data Conversion in Production environment (if required)



• Conduct Production Confirmation Business Lead M

• Conduct Data Conversion Confirmation (if required)

Business Lead O Required if new table structures created that need to be populated from historical data.


3‐15



• Migrate to Training environment (if available)


O

• Conduct Data Conversion in Training environment



• Conduct User Training Sessions Business Lead / User Group / BPM

O Required if new features added to application in this release.

• Review/ Confirm User Manuals Business Lead/ User Group/ BPM

O

• Review/ Confirm Maintenance Plan BPM/ Vendor M

• Review/ Confirm Handover Plan BPM/ Vendor/ Business Lead/ NRS Servicedesk

O


4‐1

4 Systems Development Life Cycle – Lightweight Development Framework4


4.1 Phase 1: Initiation • Meet with the Business Area to identify the

project BPM / Business Area M

• Conduct Feasibility Whiteboard session with Technical Advisory Committee.

BPM / Technical Architect / Business Area

Feasibility Whiteboard Checklist



Whiteboard Calendar

• Conduct Feasibility Assessment BPM / Technical Architect / Business Lead

Lightweight Feasibility Agreement

M

• Sign off on Lightweight Development Business Lead M

• Initiate Change Management Plan BPM/ Business Lead O Template available to provide business area with consistent considerations to implementation and ongoing maintenance

• Add Application to Application Inventory (IRS)

BPM M

4 Lightweight Development includes: Desktop tools like Infopath, MS Access




http://www.for.gov.bc.ca/his/sdlc/lightweight_feasibility_agreement.docx

http://www.for.gov.bc.ca/his/sdlc/lightweight_feasibility_agreement.docx


4‐2



4.2 Phase 2: Analysis & Design • Initiate Security, Threat, Risk Assessment

(STRA) Business Lead / BPM / ISO

M

• Initiate Privacy Impact Assessment Business Lead / BPM / ISO

M

• Initiate Records Impact assessment Business Lead/ BPM/ CRO

M

• Complete Software Requirements Specification

BPM / Business Lead O Required if there is potential that this lightweight solution may grow into a corporate solution

• Complete Software Design Document BPM / Business Lead O Required if there is potential that this lightweight solution may grow into a corporate solution

4.3 Phase 3: Build • Application Development Business Area M

• Create User Acceptance Test Plan Business Area / BPM M


4‐3



• User Materials Development Business Area O Required if the user group extends beyond those working in the same location as the Business Lead

• Refine STRA Business Lead / BPM / ISO

M

• Conduct User Acceptance Testing Business Lead / User Group / BPM

M

• Revise application based on test results Business Area M

• Retest application Business Area M

4.4 Phase 4: Implementation • Complete/ signoff STRA Business Lead / BPM /

ISO M

• Complete/ signoff PIA Business Lead / BPM / ISO

M

• Complete/ signoff RIA Business Lead/ BPM/ CRO

M

• Implement application in a test environment

Business Lead / BPM O

• Test application Business Area O

• Resolve testing issues Business Area O

• RE‐test in test environment Business Area O


4‐4



• Implement application in a production environment

Business Lead/ BPM M

• Confirm application deployment Business Area M

• Update documentation as required Business Area M

• Conduct Post Project Review BPM / Business Lead / Technical Architect

M


5‐1

5 Project Management Monitoring and Control Deliverables Deliverables that are initiated at the beginning of work – potentially as early on as the Business Architecture Phase ‐ and are reviewed and updated throughout the life of the work.

Phase Artifact Responsibility Comments

• Status Reporting BPM

• Issue Logs BPM

• Meeting Minutes BPM

• Risk Assessment/ Risk Mgmt Plan BPM/ Business lead

• Project Decision Request BPM

• Change Request BPM

• Change Log BPM

• Budget/Cost mgmt BPM

• Contract mgmt – contract admin BPM

• Project Repository BPM

• Team Charter BPM Reviewed and updated during project

• Lessons Learned Inventory BPM

• Communications Plan BPM

• Project Plan/ Project schedule BPM

• Implementation Plan BPM

• Training Plan BPM

• Quality Management Plan/ Quality Assurance BPM