---

Quick Links

News | The Premier Online | Ministries & Organizations | Job Opportunities | Main Index

---

Contents

• B.C. Home
• Ministry of Environment
• Ministry of Agriculture and Lands
• CSD
  • IMB
    • Services
      • Database Services
      • Management Services
      • Application Services
      • Information Management Services
      • Technology Services
      • Web Services
        • File Transfer Service (SOFT)
      • Data Services
    • Organization
      • Business Plan
      • Corporate Information Architecture
      • Web Services
      • GIS and Access Support Services
      • Application Development Services
    • Standards
      • Alphabetical List of All Standards
      • Application & Architecture
      • Project Management
      • Standards for Standards
      • System Development Life Cycle (SDLC)
      • Technology
      • Web
    • Projects
      • Corporate Information Architecture
      • Web Services
      • Data Management Services
      • GIS and Access Support Services
      • Application Development Services
      • Land and Resource Data Warehouse
  • Reports and Publications
  • Branch Contacts

B.C. Home » Environment » CSD

SDLC STANDARDS

System Development Life Cycle (SDLC) Overview

SDLC OVERVIEW

Version 1.6     November 13, 2009

This page contains the published standards for the Ministry's approach to the System Development Life Cycle (SDLC) Overview.

Table of Contents

VERSION CONTROL

1. INTRODUCTION 1.1 Purpose 1.2 Audience 1.3 Assumptions 1.4 Other Standards 2. Project Organization 2.1 Executive Management 2.2 Project Sponsor 2.3 Business Champion 2.4 Project Manager 2.5 Application Administrator 2.6 Data Administrator 2.7 IMB Advisors 2.8 Development Team 2.9 User Team 2.10 IMB Quality Assurance 3. Business Planning 3.1 Business Planning 3.2 Application Planning 4. System Development Life-Cycle 4.1 Planning 4.2 Definition 4.3 Requirements 4.4 Design 4.5 Build 4.6 Implementation 5. WAREHOUSE 6. MAINTENANCE 7. CONCLUSION

 

FIGURES
	Figure 1: Typical Project Organization Figure 2: BUSINESS ARCHITECTURE Phases Figure 3: BUSINESS ARCHITECTURE Deliverables and Standards Figure 4: SDLC Phases Figure 5: SDLC Deliverables and Standards

Version Control

This section of the document records the various versions or releases of this document.

Table 1: Version Control

[TOC]

1.      INTRODUCTION

This Business Architecture and System Development Life-Cycle (SDLC) Overview document describes the process for conducting application development projects and assignments in the Ministry of Environment (ENV) and the Ministry of Agriculture and Lands (AL). This document first outlines a typical system development project team (project organization) and the roles and responsibilities associated with each project team member. Secondly, it describes a set of Business Planning guidelines for tasks that should be completed in conjunction with the Business Area prior to the identification of a new application project. Thirdly, it describes a set of guidelines for each of the Phases of the Ministry’s Business Architecture and SDLC approach to application development.

1.1     Purpose

The purpose of this document is to provide contractors and Ministry staff with an overview to the SDLC approach used by the Ministry.

1.2     Audience

This document is intended for the use of all Application Administrators, Project Managers, Project Leaders, Business Analysts, Database Designers and Developers involved in planning and delivering applications for the Ministry.

All contractors engaged to perform all or some of the SDLC Phases are instructed to follow and conform to the SDLC outlined in this document.
This fact must be specified in the RFP and the contract.

1.3     Assumptions

It is assumed that the reader of this document is familiar with the Ministry's typical System Development Life Cycle (SDLC).

1.4     Other Standards

Other related standards can be found on the IMB All Standards page.

[TOC]

2.     PROJECT ORGANIZATION

This section outlines the formation and organization of a typical systems development project. The terms and project roles identified here will be used throughout this document in the descriptions of each Phase of the SDLC.

A typical project organization is depicted below:

Figure 1: Typical Project Organization

The appropriate Names of the people fulfilling the project roles are to be inserted in the appropriate boxes of the project organization chart, when this is to be included in the Project Statement deliverable.

The Project Organization’s size and structure will vary depending on the nature of each specific project.

The Project Roles and Responsibilities of a typical project organization are outlined in the next section.

2.1     Executive Management

The role of Executive Management is filled by a Director, senior Ministry executive or a Steering Committee formed for an application development project. This role is responsible for:

• Accountability of the success of the Project;
• Resolving Requests for Decision;
• Resolving Project Resource Allocation Conflicts;
• Monitoring Project Plans/Schedules;
• Reporting to Director/Executive (if Steering Committee);
• Providing Strategic Direction and Plans;
• Ensuring integration between Business Units;
• Appropriate Reviews of Project Deliverables.

2.2     Project Sponsor

This role is responsible for:

• Reporting to Director/Executive or Steering Committee;
• Setting Project Priorities;
• Securing Project Funding;
• Allocating Project Resources;
• Final Approval of all Deliverables;
• Approving the Contracts.

2.3     Business Champion

This role is responsible for:

• Reporting to Project Sponsor;
• Providing Business Area Project Direction;
• Providing Business Direction;
• Coordinating Business Area Resources;
• Approving Project Budgets;
• Resolving Project Issues;
• Presentations to Steering Committee;
• Appropriate Review and Approval of Project Deliverables;
• Communicating to Regions and Districts. Communication.

2.4     Project Manager

The role of the Ministry's Project Manager is to take overall responsibility for the success of all aspects of the project. It is possible that this role will be filled by a contractor on behalf of the Ministry. This role is responsible for:

• Reporting to the Project Sponsor or Business Champion;
• Assuming the primary responsibility for comprehensive project management;
• Ensuring Adherence to all the SDLC Phases, Deliverables and Standards;
• Preparing Project Plans, Schedules and Budgets;
• Coordinating Project Resource Activity;
• Managing/Monitoring Contractors;
• Preparing/Presenting Project Status Reports (this status report refers to the whole project);
• Preparing/Monitoring Issues;
• Preparing/Monitoring Change Requests;
• Preparing/Monitoring Requests for Decision;
• Quality Assurance and Signing-off of all Deliverables;
• Conducting Final Acceptance Testing.

Note: Please refer to the Project Management Approach for more information.

2.5     Application Administrator

This role is responsible for:

• Being the main point of contact for Application in the Business Area.

2.6     Data Administrator

This role is responsible for:

• Providing Business Area Data Management and Administration;
• The responsibilities for this role are still to be completed.

2.7     IMB Advisors

The IMB Advisors are to be included as appropriate by the Project Manager to assist with particular technical, architectural, business and/or GIS requirements and direction. Representatives from the following groups within IMB are to be included in project meetings, when appropriate:

• Business Analysis;
• Application Architecture;
• Data Administration;
• Operations Planning and Support;
• Technical Support;
• Technical Service Center.

2.8     Development Team

The Development Team will usually draw upon resources from a consulting company, contracted to supplement the Ministry's project team.

Development Project Manager/Leader

• As for Project Manager above, but restricted to the scope and responsibility of the Development Team;
• Status Report preparing here will refer only to the project scope assigned to the Development Team;
• Main Ministry contact for the Development Team.

Business Analyst

• Major contribution to the Software Requirements Specification Deliverable;
• Understanding the Ministry's Business Requirements;
• Ensuring Business/Technical (IT) Integration;
• Coordinating User Testing;
• Major Contributing to the Deliverables of the Implementation Phase;
• Participating in all SDLC Phases.

Technical Analyst

• Major contribution to the Software Requirements Specification Deliverable;
• Major Contributing to the Software Design Description Deliverable;
• Assisting with Logical Data Model;
• Preparing the Physical Data Model;
• Coordinating System Testing.

Developers

• Major Contributing to the System Build Deliverable;
• Developing Functions, Screens and Reports;
• Conducting Unit Testing.

Quality Assurance on Development

• Conducting internal deliverable quality reviews prior to delivering to the Ministry;
• Reviewing and approving all Deliverables.

2.9     User Team

The User Team roles are defined depending on the requirements of the system and the business area being addressed. Typically there will be user representatives and/or experts from three segments of the Ministry representing the business users. These will be:

• Headquarters;
• Regions and/or Districts;
• Program area.

Each area will be responsible for its portion of the business and address the following responsibilities:

• Defining Business Requirements;
• Providing Business Direction;
• Appropriate Reviewing and Approving of Project Deliverables;
• Major contributing to User Documentation and Testing Plans;
• Participating in User and Acceptance testing.

2.10    IMB Quality Assurance

Quality Assurance (QA) is required for all Project Deliverables. Processes for QA of all project deliverables have been outlined in the Quality Assurance Guideline.

[TOC]

3.     BUSINESS ARCHITECTURE

The Business Architecture steps are intended to provide a set of guidelines for the successful completion of pre-application development projects. Business Architecture consists of two distinct Phases as shown in :Figure 2 below:

Figure 2: Business Architecture Phases

Each Phase contains one or more individual deliverables associated with the Phase. These deliverables are themselves described in separate standards documents.A summary of these deliverables, by SDLC Phase, as a checklist to Project Managers, Application Managers and anyone involved in system development projects, together with the appropriate standards, is shown in Figure 3 below.

Figure 3: Business Architecture Deliverables and Standards
Note:A listing of all available standards for the Ministry is detailed in the Alpha List of Existing Standards.

Phase (Click Phase Name for Purpose)	Deliverable	Contributes to Deliverable	Quality Assures Deliverable	Applicable Standard
Business Architecture
Phase 1: Business Planning	Conceptual Requirements	BE, BA, ITE	BE, BA, ITE, as appropriate	Conceptual Requirements Standard
Transformation Plan	BE, BA, ITE	BE, BA, ITE, as appropriate	Transformation Plan Standard
Phase 2: Application Planning	Software Needs Assessment	BE, BA, ITE	BE, BA, ITE, as appropriate	Software Needs Assessment Standard
Gap Analysis - TBD	BE, BA, ITE	BE, BA, ITE, as appropriate	Not applicable
Business Case	BE, BA, ITE	BE, BA, ITE, as appropriate	Business Case Standard

3.1     Business Planning

Purpose

This Phase of the Business Architecture is conducted to identify the current and future business processes that potentially will require the support of an automated system solution. This Phase will produce a Conceptual Requirements document that contains the AS IS and TO BE models of the business. From the TO BE process models, one or more application projects may be identified depending on the level at which the modelling is being performed, Division, Branch, Section or Unit.

Prerequisites:

Identified Business Need

Deliverables:

Conceptual Requirements
Transition Plan

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Deliverable Approval
Project Sponsor	--	Secondary Responsibility
Business Champion	--	Primary Responsibility
Project Manager	--	Assist as required
Development Team	--	None
Business Analyst	--	Assist as required
	--	Quality Assurance of deliverable
User Team	--	Requirement Input
IMB Quality Assurance	--	Standards QA

Milestone:

Project Approval.
 
A project must not proceed to the next Phase without the appropriate authorization and approval.

Commentary:

This is the first Phase in the Business Architecture. The Conceptual Requirements deliverable is the first major deliverable in identifying a potential project. It is normally produced by a hired contractor who works with the business area and IMB representatives to clearly identify the current and future business processes.
 
More details may be found in the Conceptual Requirements Template.
 
The second deliverable is optional depending on the depth at which the Conceptual Requirements is conducted. If it is at the Branch or Section level, a Transition Plan may be required to identify which of the processes will be addressed in future systems projects and what the short term, midterm and long term tasks are to implement the TO BE processes.
 
More details may be found in the Transition Plan Template.

Activity:

The Business Champion is responsible for producing the Conceptual Requirements. However, the Business Champion may delegate this activity for completion. Together with appropriate members of the User Team, the Business Champion will provide information for the completion of the Conceptual Requirements.
 
The Project Sponsor is responsible for reviewing and approving the Conceptual Requirements and securing the necessary funding for the next phase of the project.
 
The draft Conceptual Requirements must be submitted to the Information Management Branch (IMB) for Business Analyst review and QA against standards.
 
The completed Conceptual Requirements will be submitted to the Executive Management (Steering Committee) for approval and budget allocation authorization.
 
If required, the Transition Plan must be completed by the Business Champion and their Business Analyst to clearly document the short-term, midterm and long-term tasks required implementing the planned process. This document should identify which business processes will be further analysed in the next phase to identify a potential system solution.
 
The Project Sponsor is responsible for reviewing and approving the Transition Plan and securing the necessary funding for the next phase of the project.The draft Transition Plan must be submitted to the Information Management Branch (IMB) for Business Analyst review and QA against standards.
 
The completed Transition Plan will be submitted to the Executive Management (Steering Committee) for approval and budget allocation authorization.

Additional Activities:

Depending on the specific requirements of the project, certain activities may need to be performed, after the completion and approval of the Conceptual Requirements, but before the next Phase of the Business Architecture.
These are:

• Preparation and distribution of a Transition Plan;
• Preparation and distribution of an RFP for a Senior Business Analyst to assist in the next phase for the creation of the Software Needs Assessment;
• Review of proposal submissions;
• Selection of contract Analysis Team;
• Selection and appointment of a qualified Project Manager;
• Secured and allocated resources (funds, people, technology).

[TOC]

3.2     Application Planning

Purpose

This Phase of the Business Architecture is conducted to identify the high level business requirements of a selected business process from the Conceptual Requirements that could be replaced by an automated system solution. The Software Needs Assessment is the primary deliverable produced from this phase that will subsequently feed into the Gap Analysis and Business Case.

Prerequisites:

Completed Conceptual Requirements

Deliverables:

Software Needs Assessment
Gap Analysis
Business Case

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Deliverable Approval
Project Sponsor	--	Secondary Responsibility
Business Champion	--	Primary Responsibility
Project Manager	--	Assist as required
Development Team	--	None
Business Analyst	--	Assist as required
	--	Quality Assurance of deliverable
User Team	--	Requirement Input
IMB Quality Assurance	--	Standards QA

Milestone:

Project Approval.
 
A project must not proceed to the next Phase without the appropriate authorization and approval.

Commentary:

This is the second Phase in the Business Architecture. The Software Needs Assessment deliverable is the primary deliverable in identifying the base business requirements for which a systems solution may resolve the problem. It is normally produced by a hired contractor who works with the business area and IMB representatives to clearly identify the business requirements.
 
More details may be found in the Software Needs Assessment Template.  
A Gap Analysis may be conducted by itself or included in a Business Case that will support the funding request for capital to procure a CoTS or Custom Built solution.

Activity:

The Business Champion is responsible for producing the Software Needs Assessment. However, the Business Champion may delegate this activity for completion and hire a Senior Business Analyst to complete this with a working group of business area representatives. Together with appropriate members of the User Team, the Business Champion will provide information for the completion of the Conceptual Requirements.
 
The Project Sponsor is responsible for reviewing and approving the Software Needs Assessment and securing the necessary funding for the next phase of the project.
 
The draft Software Needs Assessment must be submitted to the Information Management Branch (IMB) for Business Analyst review and QA against standards.
 
The completed Software Needs Assessment will be submitted to the Executive Management (Steering Committee) for approval and budget allocation authorization.

Additional Activities:

Depending on the specific requirements of the project, certain activities may need to be performed, after the completion and approval of the Conceptual Requirements, but before the next Phase of the Business Architecture. These are:

• Preparation and distribution of a Business Case;
• Secured and allocated resources (funds, people, technology).

[TOC]

4.     SYSTEM DEVELOPMENT LIFE CYCLE

The System Development Life Cycle (SDLC) is intended to provide a set of guidelines for the successful completion of application development projects. The SDLC consists of six distinct Phases as shown in Figure 2 below:

Figure 2: SDLC Phases

Each Phase contains one or more individual deliverables associated with the Phase. These deliverables are themselves described in separate standards documents.A summary of these deliverables, by SDLC Phase, as a checklist to Project Managers, Application Managers and anyone involved in system development projects, together with the appropriate standards, is shown in Figure 3 below.

Figure 3: SDLC Deliverables and Standards
Note:A listing of all available standards for the Ministry is detailed in the Alpha List of Existing Standards.

Phase (Click Phase Name for Purpose)	Deliverable	Contributes to Deliverable	Quality Assures Deliverable	Applicable Standard
SDLC
Phase 1: Project Planning	Not Applicable	Quality Assurance is not actually a deliverable but a guide that must be followed for all deliverables	As appropriate	Quality Assurance
SDLC Rightsizing Matrix (329k pdf)	BE, BA, ITE	BE, BA, ITE, as appropriate	Not Applicable
Project Charter	BE, BA, ITE	BE, BA, ITE, as appropriate	Project Charter Standards Template (word doc)
SDLC Checklist (word doc)	BA	Not Applicable	Not Applicable
RFP Template - Contact your BA	BE, BA, ITE	BE, BA, ITE, as appropriate
Phase 2: Definition	Project Plan (word doc)	PM, BE, BA	PM, BE, BA, ITE, as appropriate	Project Plan Standard
Phase 3: Analysis	Software Requirements Specification(word doc)	BE, DT, ITE	BE, DBA, AA	Software Requirements Specification Standard
Data Conversion Analysis	BE, DT	BE, BA, ITE, as appropriate	Not Applicable
Phase 4: Design	Software Design Description(word doc)	BE, BA, DT, ITE	BE, AA, DA, BA	Software Design Description Standard
Logical Model   Physical Model	BE, BA, DT, ITE	DA	Data Architecture Standards
Data Conversion Design	BE, BA, DT, ITE	DA	Not Applicable
Phase 5: Build	Web Mapping Application Development Standards	BE, BA, GTE, DT	GTE	GEOBC Web Mapping Application Development Standards
Application Code	BE, DT, BA	AA	Java Standards Guidelines
Application Reports	BE	BE, AA	Oracle Reports Standards
Tested Application	DT	BE, BA	Vendor Test Plan
Data Conversion Application	DT	BE, AA	Not Applicable
Phase 6: Implementation	User Procedures	BE	BE, BA	Not Applicable
On-Line Help Text	BE	BE	Not Applicable
User Acceptance Test	BE, DT, BA	BE, BA	User Acceptance Plan
User Training Plan	BE	BE	Not Applicable
Implementation Plan	BE, BA	BA, ITE	Not Applicable
Application Delivery and Migration	DT, AA, BA	AA	Application Delivery Standards

 

4.1     PLANNING

Purpose

This Phase of the SDLC is required to determine the feasibility of a particular project proceeding, or not. This Phase will produce a high-level overview document of the proposed project. It will contain information relating to the project’s requirements and will enable the formalization and definition of the scope of the project.
 
Note: The deliverable of this Phase (The Project Charter) is largely an internal document, developed by Ministry staff prior to enlisting a contractor.

Prerequisites:

Identified Business Need

Deliverables:

Project Charter

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Deliverable Approval
Project Sponsor	--	Secondary Responsibility
Business Champion	--	Primary Responsibility
Project Manager	--	Assist as required
Development Team	--	None
Business Analyst	--	Assist as required
	--	Quality Assurance of deliverable
User Team	--	Requirement Input
IMB Quality Assurance	--	Standards QA

Milestone:

Project Approval.
 
A project must not proceed to the next Phase without the appropriate authorization and approval.

Commentary:

This is the first Phase in the SDLC. The Project Charter deliverable is the first major deliverable in the project. The Project Charter is to be produced prior to the commencement of a project. It is normally produced by Ministry Staff, such as the Application Administrator, and is usually completed and approved prior to hiring a contractor for the project.
 
Due to fiscal year budget allocations and fiscal contract restrictions the Project Charter will typically refer to project activity up to the end of the fiscal year in which the project starts. There may be exceptions and special circumstances when a Project Charter will span more than one fiscal year. In these cases, this should be specifically stated in the Project Charter document. Refer to the Project Charter Standards document for a more detailed description of the contents of this deliverable.
 
For projects spanning more than one fiscal year, an updated Project Charter will be required for each year that the project is undertaken, prior to the start of the fiscal year (normally done in March of each year).
 
The updated Project Charter for subsequent fiscal years will focus on identifying the scope and deliverables of the project for that particular fiscal year. The updated Project Charter will also include revisions (as appropriate) to project team, budget, schedule and project status.

Activity:

The Business Champion is responsible for producing the Project Charter. However, the Business Champion may delegate this activity for completion. Together with appropriate members of the User Team, the Business Champion will provide information for the completion of the Project Charter.
 
The Project Sponsor is responsible for reviewing and approving the Project Charter and securing the necessary funding for the project.
 
The draft Project Charter must be submitted to the Information Management Branch (IMB) for Business Analyst review and QA against standards.
 
The completed Project Charter will be submitted to the Executive Management (Steering Committee) for approval and budget allocation authorization.

Additional Activities:

Depending on the specific requirements of the system project, certain activities may need to be performed, after the completion and approval of the Project Charter, but before the next Phase of the SDLC. These are:

• Preparation and distribution of an RFP for the Development Team;
• Preparation and distribution of an RFP for a Project Manager;
• Review of proposal submissions;
• Selection of contract Development Team;
• Selection and appointment of a qualified Project Manager;
• Secured and allocated resources (funds, people, technology).

[TOC]

4.2     DEFINITION

Purpose

This Phase of the SDLC defines exactly what, who, when and how the project will be carried out. This Phase will take the deliverable from the previous Phase (Project Charter), expand on the high-level project outline and provide a specific and detailed project definition.
 
This Phase is the first activity of the project after obtaining approval and funding to proceed.
 
This description of this Phase assumes that the following associated activities have been completed:

• preparation and distribution of an RFP;
• selection of a contract development team; and
• appointment of a Project Manager.

This Phase effectively communicates to project stakeholders the project scope and schedule, as well as any related risks or constraints.

Prerequisites:

Project Charter -- Approved.
 
Budget Allocation.
 
RFP.
 
Contractor Selection.
 
Project Manager Appointment.

Deliverables:

Project Statement.

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Deliverable Approval
Project Sponsor	--	Deliverable Approval
Business Champion	--	Requirements Input
Project Manager	--	Primary Responsibility
Development Team	--	Estimating and Scheduling Information
Business Analyst	--	Secondary Responsibility
	--	Quality Assurance of deliverable
User Team	--	Requirement Input
IMB Quality Assurance	--	Standards QA

Milestone:

Project Statement -- Approval and Sign-off.
 
A project must not proceed to the next Phase without approval of the Project Statement.

Commentary:

This is the second Phase in the SDLC, but the first Phase of the project itself.
 
The Project Statement deliverable from this Phase must be completed and signed-off prior to commencing the next phase of the project. Refer to the Project Plan document for a detailed description of this deliverable.
 
Agreement to the Project Statement ensures that everyone involved in the project is clear on the project scope, objectives, goals and outcomes.

Activity:

The Project Manager is responsible for producing the Project Statement. However, the Project Manager may delegate this activity to the Development Team for completion.
 
The Business Champion, Business Analyst and appropriate members of the User Team will provide project information to help complete the Project Statement.
 
The draft Project Statement must be submitted to the Information Management Branch for Business Analyst review and QA against standards.
 
The completed Project Statement will be submitted to the Business Champion and Project Sponsor for approval and sign-off.

[TOC]

4.3     ANALYSIS

Purpose

This Phase of the SDLC is required to understand and document the users' needs for the system. This Phase will document, in significantly more detail than the Project Statement, the scope, business objectives and requirements of the current/proposed system.
 
The emphasis throughout this Phase is on what the system will do. During analysis and specification, the technical aspects and constraints should be considered, but should not be influenced by implementation characteristics. The technical aspects of the system are addressed in the Design Phase.
 
During this Phase the Data Conversion requirements, at a high level, will become apparent. This will start a parallel set of SDLC Phases for the Data Conversion associated with the system. Data Conversion will follow Phases 3 to 6 of the SDLC. Depending on the size and complexity of the total project (system and data conversion) the Data Conversion Application could be incorporated as a section or component of the main system Design deliverable, or become a separate Data Conversion deliverable of its own.
 
Data Warehousing requirements will also be identified during this Phase and a parallel set of Data Warehouse SDLC Phases should commence.

Prerequisites:

Project Statement -- Approved.

Deliverables:

Detailed Software Requirments Specification Analysis.
XMI export of High Level Domain Model.
IMB Data Administration QA Report.

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Monitor Progress
Project Sponsor	--	Support the Process
Business Champion	--	Direct, Approve Significant Contribution
Project Manager	--	Primary Responsibility
	--	Quality Assurance
Development Team	--	Secondary Responsibility
Business Analyst	--	Secondary Responsibility
	--	Major Contributor
User Team	--	Significant contribution
IMB Quality Assurance	--	Standards QA
	--	Analysis QA

Milestone:

Software Requirements Specification -- Approval and Sign-off
 
A project must not proceed to the next Phase without appropriate deliverable approval and Sign-off

Commentary:

The Software Requirements Specification is to be stated in language that reflects the background of the user base. Most requirements are written as plain language sentences supplemented with diagrams, graphics and tables of detailed information.
 
Refer to the System Analysis Standards for a more detailed description of the deliverables associated with this Phase.

Activity:

The Project Manager is responsible for producing the deliverables associated with the Software Requirements Specification. However, the Project Manager usually delegates this to the Business Analyst. This deliverable has significant input from the Business Champion and User Team. If some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to IMB for Quality Assurance.
 
The Project Manager will provide initial Quality Assurance of the deliverable prior to review by IMB QA, User Team and the Business Champion.
 
The draft Software Requirements Specification must be submitted to the Information Management Branch for Data Administration for QA against Data standards and to Technical Architecture for QA to application standards
 
The completed Software Requirements Specification will be submitted to the Business Champion and Project Sponsor for approval and Sign-off.

[TOC]

4.4     DESIGN

Purpose

This Phase of the SDLC continues from the Software Requirements Specification and describes how the proposed system will be built. The Design is specific to the technical environment that the system will operate in and the tools used in building the system. The results of this Phase significantly impact the Build and Implementation Phases of the system.

Prerequisites:

Detailed Software Requirements Specification -- Signed-off.

Deliverables:

Detailed Software Design Description.
 
Oracle Designer Repository.
 
XMI export of full UML Domain model.
 
Data Conversion Design.
 
IMB Database Administration QA Report.

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Monitor Progress
Project Sponsor	--	Support the Process
Business Champion	--	Review, Approve
Project Manager	--	Primary Responsibility
	--	Quality Assurance
Development Team	--	Secondary Responsibility
	--	Major Contributor
Business Analyst	--	Secondary Responsibility
User Team	--	Review
IMB Quality Assurance	--	Standards QA
	--	Database Design QA

Milestone:

Detailed Software Design Description -- Approval and Sign-off.
 
A project must not proceed to the next Phase without appropriate deliverable approval and Sign-off.

Commentary:

Refer to the Software Design Description Standards for a more complete description of the deliverables associated with this Phase.

Activity:

The Project Manager is responsible for producing the deliverables associated with the Detailed Software Design Description.
 
However, the Project Manager usually delegates responsibility for some or all of these deliverables to the Development Team. If some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to IMB for Quality Assurance
The Project Manager will provide initial Quality Assurance of the deliverables prior to review by IMB QA, User Team and the Business Champion.
 
The draft Software Design Description must be submitted to the Information Management Branch for Database Administration review and QA against standards.
 
The completed Software Design Description will be submitted to the Business Champion and Project Sponsor for approval and Sign-off.

[TOC]

4.5     BUILD

Purpose

This Phase of the SDLC deals with the development, unit testing and integration testing of the application modules, screens and reports. In addition, this Phase addresses the preparation and establishment of the technical environment for development, testing and training of user representatives.  
This Phase is usually carried out in parallel with the development of user procedures and user documentation from the Implementation Phase. Both of these will be required for module testing, upon the completion of the Build Phase. Coordination of the Build and Implementation Phase activities is a key responsibility of the Project Manager at this time.
 
Any special procedures for data conversion and/or data warehousing are also developed and tested. The process of developing and testing the data conversion and data warehousing modules is no different from that required for the system itself.

Prerequisites:

Detailed Software Design Description-- Signed-off.

Deliverables:

System Build.
 
Developer Guidelines.
 
Application Forms and Reports.
 
Data Conversion Application.
 
IMB Technical QA Report.

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Monitor Progress
Project Sponsor	--	Support the Process
Business Champion	--	Review, Approve
Project Manager	--	Primary Responsibility
	--	Quality Assurance
Development Team	--	Secondary Responsibility
	--	Major Contributor
Business Analyst	--	Secondary Responsibility
User Team	--	Review
IMB Quality Assurance	--	Standards QA
	--	Build QA

Milestone:

System Build -- Approval and Sign-off.
 
Some activities in this Phase may be conducted in parallel with activities of the Implementation Phase.

Commentary:

This is the fifth Phase in the SDLC. Refer to the System Build Standards and documentation for a more detailed description of the deliverables associated with this Phase.

Activity:

This is the fifth Phase in the SDLC. Refer to the System Build Standards and documentation for a more detailed description of the deliverables associated with this Phase.
 
The Project Manager will provide initial Quality Assurance of the deliverables prior to review by IMB QA, User Team and the Business Champion.
 
The draft System Build must be submitted to the Information Management Branch for technical review and QA against standards.
 
The completed System Build will be submitted to the Business Champion and Project Sponsor for approval and sign-off.

[TOC]

4.6     IMPLEMENTATION

Purpose

This Phase of the SDLC is to prepare for and carry out the implementation of the developed system through user and acceptance testing to a full production system.

Prerequisites:

System Build -- Sign-off.

Deliverables:

User Procedures (including Data Conversion).
 
On-Line Help Text.
 
Acceptance Test Plan.
 
Data Conversion Plan.
 
User Training Plan.
 
Application Migration Plan.
 
Implementation Plan.
 
Internet Deployment Plan (as appropriate).
 
Production Sign-off.

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Monitor Progress
Project Sponsor	--	Support the Process
Business Champion	--	Review, Approve
	--	Quality Assurance
Project Manager	--	Primary Responsibility
	--	Quality Assurance
Development Team	--	Secondary Responsibility
	--	Major Contributor
Business Analyst	--	Secondary Responsibility
	--	Major Contributor
User Team	--	Review, Approve
IMB Quality Assurance	--	Standards QA
	--	Production QA

Milestone:

Data Conversion -- Approval and Sign-off.
 
System Production -- Approval and Sign-off.
 
A project must not proceed to the next Phase without appropriate authorization and approval.

Commentary:

This is the sixth (and sometimes last) Phase in the SDLC. It is the last Phase only for those Business Systems that (for specific documented reasons) will not make their data available in the Data Warehouse.
 
This Phase will provide users with the documentation and training required to use the system effectively. Data Conversion will only occur once, but user documentation will also be required.
 
Individual system components that successfully completed unit and integration testing during the Build Phase are now subjected to a more rigorous system and acceptance testing, as defined by the testing plans. In addition, user and operation procedures are tested for the system.
 
Refer to the System Implementation standards and documentation for a more detailed description of the deliverables associated with this Phase.
 
As appropriate, the Data Conversion will be performed prior to the finalization of the system into Production. The detailed Data Conversion and Implementation Plans will define exactly how this will be accomplished.

Activity:

The Project Manager is responsible for producing the deliverables associated with the Implementation Phase. However, the Project Manager usually delegates responsibility for some or all of these deliverables to the Development Team. If some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to IMB for Quality Assurance.
 
The Project Manager will provide initial Quality Assurance of the deliverables prior to review by IMB QA, User Team and the Business Champion.
 
The draft deliverables must be submitted to the Information Management Branch for technical review and QA against standards.

[TOC]

5.0     WAREHOUSE

Purpose

Warehouse actually comprises, as appropriate, all the deliverables associated with SDLC Phases 1 [Planning] through 6 [Implementation] but may not require as much detail and effort. Data loading into the warehouse is the responsibility of resources at GEOBC and as such, their policies and standards must be followed.

Prerequisites:

Production -- Sign-off.

Deliverables:

Warehouse SDLC Deliverables, as appropriate, from Phases 2-6.

Responsibility:

The suggested responsibilities associated with this Phase are:

Executive Management	--	Monitor Progress
Project Sponsor	--	Support the Process
Business Champion	--	Review, Approve
	--	Major Contributor
Project Manager	--	Primary Responsibility
	--	Quality Assurance
Development Team	--	Secondary Responsibility
	--	Major Contributor
Business Analyst	--	Secondary Responsibility
	--	Major Contributor
User Team	--	Review, Approve
	--	Major Contributor
IMB Quality Assurance	--	Standards QA
	--	Warehouse QA

Milestone:

Data Warehouse Migration -- Approval and Sign-off

Activity:

The Project Manager is responsible for producing the deliverables associated with the Warehouse Phase. However, the Project Manager usually delegates responsibility for some or all of these deliverables to the Development Team. If some or all of the Phase's deliverables have been delegated, the Project Manager maintains overall responsibility for producing quality deliverables submitted to the Business Champion for review and sign-off, and to IMB for Quality Assurance.
 
The Project Manager will provide initial Quality Assurance of the deliverables prior to review by IMB QA, User Team and the Business Champion.
 
The draft deliverables must be submitted to the Information Management Branch for review and QA against standards.

[TOC]

6.     MAINTENANCE

The Maintenance activities are those activities that are required after an application has been successfully delivered into production. The guidelines required for these processes are not yet defined and will be added later. However, depending on the extent of the Maintenance required, the SDLC Phases and appropriate standards must be followed to ensure that application and data quality are maintained.

[TOC]

7.     CONCLUSION

This document provides an Overview to the System Development Life-Cycle (SDLC) Phases, their deliverables, the project team participants and their roles and responsibilities.
 It is intended to assist Application Administrators and developers of Ministry applications and to ensure a consistent approach to SDLC deliverables. It should clearly communicate the Ministry's expectations for each Phase of the SDLC.

[TOC]