EXTERNAL (EXT)
START OF
INITIATION
START OF
SYSTEM
REQUIREMENTS
6.2.3 Estimate for
System
Requirements
Development
Reqmts. Estimate
START OF
SYSTEM
ANALYSIS &
DESIGN
6.2.9 Develop
System
Analysis & Design Estimate
Requirements &
Estimate Design
START OF
DEVELOPMENT
6.3.1 Develop
System Design & System Development Estimate
Data Architecture
AND Estimate
Development
Effort
.
Reqmts.
Estimate
User - System
Interface
Design
.
6.2.5 Evaluate
System Reqmts.
Development
Estimate
6.2.15
Review/Sign-off
Requirements
6.2.17 Evaluate
Analysis &
Design Estimates
/ Development Design
Priority
Decision
Decision
Program RFC
RFC
Form
Requirements
Sign-off
Reqmts.
Decision
Programming /
DB Objects Test
Results
6.3.2
Review/Sign-off
"User-System
Interface" Design
6.3.9 Evaluate
System
Development
Estimates /
Development
Priority
User Procedures
Connector ID:
UP1 (User
Procedures)
6.4.2 QA User
Procedures /
User Acceptance
Test Plan
Development
Decision
Development
Decision
6.1.3 Review
Request
Evaluation
Recommendation
External RFP / ITQ
6.1.4 Create RFC
6.2.6 Assist with
Evaluating
Reqmts.
Development
Estimate
Internal / External
?
RFC
Decision
Internal
Request
Estimate
Solicitation
6.1.10 Reject
RFC
Reject / Hold /
Implement RFC
Implement
RFC
External Reqmt.
Request
On-hold
Project
6.2.10 Develop /
Review System
Requirements
6.2.16 QA /
APPROVE
System
Requirements
Internal/ External
Reqmt.
Internal Development?
Reqmt.
Request
6.2.18 Assist with
Evaluating
Analysis &
Design Estimates
/ Development
Priority
6.3.3 Review
"User-System
Interface" Design
Internal /
External?
User Test
Results / UAT
Sign-off
6.3.11 Place
Project ON HOLD
6.5.4 Assist
Designated PA(s)
with Integration
Testing
6.8.1 Sign-off
System
Acceptance
Training
Complete
Advice
System
Acceptance
Sign-off
User
Test
Plan
6.6.2 Participate
In User
Acceptance Test /
APPROVE
Production
Implementation
Screens /
Reports Review
.
Implementation
Completed?
UAT Approval
YES
.
Internal
Design
Request
Requirements
Approval
System
Requirements
Reqmts.
Develop- ment
Estimate
6.2.4 Estimate
For System
Requirements
Development
6.7.1 Conduct /
Participate In
User Training
Connector ID:
UP1 (User
Procedures)
6.6.1 Conduct
User Acceptance
Test / Signoff
System
Acceptance
YES
NO
On-hold
Project
Screens / Reports
Review
Implementation
Approval
Estimates
Evaluation
NO
6.2.2 Prepare
Requirements
Estimate Request
Rejected
RFC
User
Procedures
Screens /
Reports
Review
External
Design
Request
Estimates
Evaluation
6.2.7 Place
Project ON HOLD
RFC
Proceed with
Project?
NO
NO
Comments /
Recommendations
BUSINESS ANALYST (BA)
6.5.3 Validate
Screens / Reports
During
Integration
Testing
6.4.8 Perform
Manual Data
Conversion
Proceed With
Design?
YES
PRODUCTION
(PROD)
Requirements /
Procedures
YES
Proceed with
Project?
START OF
SYSTEM
IMPLEMENT
-ATION
.
Integration
Test Results
.
6.1.2 Create RFC
via Web Interface
RFC
START OF
USER
ACCEPTANCE
TESTING
6.5.2 Perform
Integrated System
Test
System
Objects
Screens /
Reports
Review
User System
Interface
Sign-off
Design
Decision
6.5.1 Move
Development
Objects Into ISB
Delivery
Environment
Developed
Database /
System
Design
QA
Review
Advice
PROGRAM ADMINISTRATOR (PA)
6.1.1 Evaluate
Request / Defect /
Enhancement
START OF
INTEGRATION
SYSTEM
TESTING
6.4.1 Develop
Database /
System & Unit
Test Functions
.
System Reqmts.
6.2.19 Place
Project ON HOLD
Reqmts.
Development
Estimate
Reqmts.
Completed?
YES
6.3.10 Assist with
Evaluating
System
Development
Estimates /
Development
Priority
On-hold
Project
6.5.8 APPROVE
Integration
System Test
RFC
ON-HOLD
6.7.2 Conduct /
Assist With User
Training /
Approve
Implementation
Integration
Test Approval
6.1.9 Place RFC
ON - HOLD
Minor Project
Major/Minor
Project?
Release
Implementation
Report
Procedures /
QA Results
Major Project
.
Minor
Project
.
Internal Analysis
NO
Estimate?
Connector ID:
SA1 (Systems
Analysis
Connector)
6.8.2 Conduct
Post
Implementation
Review
END OF
PROJECT
6.4.3 QA User
Procedures /
User Acceptance
Test Plan
User Procedures
YES Analysis
Estimate
Request
6.1.5
Promote to
System
Requirements State
6.2.20
Promote To
System
Analysis &
Design State
6.2.1 Determine
Project
Magnitude
BA State
Promotion
Magnitude
Decision
6.3.13 Place
Project on
TEMPORARY
HOLD
.
YES
.
O/S
Projects
User Test
Completed?
.
.
.
Systems Analysis
State Promotion
DATA ADMINISTRATOR (DA)
.
6.2.11 Review
Data
Requirements
Data
Architecture
Approval
6.3.4 Develop OR
QA / APPROVE
Data Architecture
.
Data Reqmt.
Recommendations
Data Reqmts.
Comment
6.1.6 Review Data
Reqmts.
6.2.12 Estimate
Data Architecture
Development
6.3.5 Plan /
Design Data
Architecture For
Data Conversion
Data
Conversion
Estimate
Data Architecture
Estimate
PROGRAMMER
System Reqmts.
Comment
System
Implementation
Advice
NO Retest
.
6.1.7 Review
System Reqmts.
6.2.13 Estimate
Systems Analysis
/ Design
6.3.6 Develop
System Design /
Estimate
Development
Effort OR QA /
APPROVE
System Design
Systems Analysis &
Design Estimate
6.4.4 Develop /
Unit Test System
Functions OR QA
/ APPROVE
System Unit Test
System
Development
Estimate
User - System
Interface
Design
6.7.3 Implement
(Deploy) System
Integration Test
Completed?
Developed and
Unit Tested
Components
System Design
Approval
YES
.
Data
Conversion
Results
6.4.5 Develop &
Implement Data
Conversion
Functions
6.5.5 Move
System Objects
Into ISB Delivery
Environment
System /
Oracle
Objects
.
DATABASE ADMINISTRATOR (DBA)
DB Impact
Comment
6.5.6 Perform /
QA/APPROVE
Integrated System
Test
6.5.9 Set-up UAT
System
Environment
6.7.4 Assist With
Data Conversion
Into Production
6.5.10 Set-up UAT
Oracle
Environment
6.7.5 Implement
Database in
Production
Integration Test / QA
Results / Approval
Database
Implementation
Advice
Database QA
Review
6.1.8 Review
Database Impact
6.2.14 Estimate
Database Design
6.3.7 Develop
Database Design
/ Estimate
Development
Effort OR
QA/APPROVE
Design
Database Design
Estimates
6.4.6 Develop OR
QA / APPROVE
Server Model /
Database
DB Design
Approval
6.5.7
QA/APPROVE
Integration
System Test
Integration Test / QA
Results / APPROVAL
Developed and Unit
Test Objects
Database Development
Estimate
Data Conversion
Completion Advice
Data Conversion
Comments
6.3.8 Assist With
Data Conversion
Planning / Design
6.4.7 Develop
Temporary Data
Conversion
Database
6.7.6 Perform
Data Conversion
Into Production
Database
Data Conversion
Environment
CHANGE MANAGEMENT BOARD (CMB)
6.3.12 Review
Project Scope /
Requirements
and Schedule
Development
Temp HOLD
Decision
External
Development
Request
YES
On Temporary
HOLD?
Internal /
External?
.
.
Internal Development Request
NO
HARVEST - SYSTEM ADMIN- ISTRATOR
UAT State Promotion
6.2.8 Set-up
Release
Package
Group
Major Project Package Group
Minor Project Package Group
Connector ID:
SA1 (Systems
Analysis
Connector)
6.3.14
Promote To
Development State
6.4.9 Assign
Release
Number
Development
State Promotion
Unspecified
Title :SCM Methodology - 2004/04/30
Dev / Unit Test
Completed?
YES
Release
Number
6.4.10
Promote to
Integration
System Test
Integration
System Test
State Promotion
6.5.11
Promote To
User
Acceptance
Test (UAT)
State
6.6.3
Promote to
Implementation State
6.7.7
Promote To
Production
State
Systems Configuration Management (SCM) Methodology
Guide
Ministry of Community Services
Ministry of Tourism, Sport and the Arts / ActNow BC
September 27, 2007
(MCS/TSA)
Copyright © 2004, Province of British Columbia
All rights reserved
This material is owned by the Government of British Columbia and protected by copyright law. It
may not be reproduced or redistributed without the prior written permission of the Province of
British Columbia.
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.1
Table of Contents
1. VERSION CONTROL ............................................................................................................................... 1
2. INTRODUCTION....................................................................................................................................... 1
2.1. Audience ...........................................................................................................................1
2.2. Purpose.............................................................................................................................1
3. SYSTEMS CONFIGURATION MANAGEMENT (SCM)........................................................................... 1
3.1. Systems Configuration Management - Definition .........................................................1
3.2. Baseline Criteria For Harvest Candidates .....................................................................2
4. PROPOSED SCM HARVEST REPOSITORY STRUCTURE .................................................................. 2
5. DEFINITION OF TERMS .......................................................................................................................... 3
5.1 Systems Configuration Management (SCM) Acronyms/Terms ....................................3
5.2 Harvest Terms ...................................................................................................................5
6. SCM METHODOLOGY – Major/Minor Software Development/Enhancements ................................. 6
6.0 Process Notes / General Harvest Procedures................................................................6
6.0.1 Primary SCM Methodology Process Participant ......................................................................... 6
6.0.2 Hyperlink Access to Detailed Harvest Function Procedures....................................................... 6
6.0.3 Harvest Workbench Logon / Logoff Procedures ......................................................................... 6
6.1 INITIATE PHASE................................................................................................................7
6.1.1 Evaluate Request / Defect / Enhancement (Program Administrator (PA)) ................................ 8
6.1.2 Create RFC via Web Interface (Program Administrator (PA)) ................................................... 9
6.1.3 Review Request (ISB Business Analyst (BA)) ........................................................................... 9
6.1.4 Create RFC (ISB Business Analyst (BA)) ................................................................................ 10
6.1.5 Promote to System Requirements State (ISB Business Analyst (BA)).................................... 11
6.1.6 Review Data Requirements (ISB Data Administrator (DA))..................................................... 11
6.1.7 Review System Requirements (ISB Programmer)................................................................... 12
6.1.8 Review Database Impact (ISB Database Administrator (DBA)) .............................................. 12
6.1.9 Place RFC “ON - HOLD” (ISB Business Analyst (BA)) ............................................................ 13
6.1.10 Reject RFC (ISB Business Analyst (BA))............................................................................... 13
6.2 SYSTEM REQUIREMENTS PHASE ................................................................................14
6.2.1 Determine Project Magnitude (ISB Business Analyst (BA))..................................................... 15
6.2.2 Prepare Requirements Estimate Request (ISB Business Analyst (BA)) ................................. 16
6.2.3 Estimate for System Requirements Development (External System Developer) .................... 17
6.2.4 Estimate for System Requirements Development (ISB Business Analyst (BA)) ..................... 17
6.2.5 Evaluate System Requirements Development Estimate (Program Administrator (PA)).......... 18
6.2.6 Assist with Evaluating Requirements Development Estimate (ISB Business Analyst (BA)).... 18
6.2.7 Place Project “ON HOLD” (ISB Business Analyst (BA)) .......................................................... 19
6.2.8 Set-up Release Package Group (ISB Harvest System Administrator) .................................... 20
6.2.9 Develop System Requirements & Estimate Design (External System Developer).................. 20
6.2.10 Develop / Review System Requirements (ISB Business Analyst (BA))................................. 21
6.2.11 Review Data Requirements (ISB Data Administrator (DA))................................................... 22
6.2.12 Estimate Data Architecture Development (ISB Data Administrator (DA)) ............................. 23
6.2.13 Estimate Systems Analysis / Design (ISB Programmer) ....................................................... 24
6.2.14 Estimate Database Design (ISB Database Administrator (DBA)).......................................... 24
6.2.15 Review/Sign-off Requirements (Program Administrator (PA))............................................... 25
6.2.16 QA/Approve System Requirements (ISB Business Analyst (BA)) ......................................... 25
i
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.1
6.2.17 Evaluate Analysis & Design Estimates / Development Priority (Program Administrator (PA))
............................................................................................................................................................ 26
6.2.18 Assist with Evaluating Analysis & Design Estimates/Development Priority (ISB Business
Analyst (BA)) ...................................................................................................................................... 27
6.2.19 Place Project on HOLD (ISB Business Analyst (BA)) ............................................................ 27
6.2.20 Promote to System Analysis & Design State (ISB Business Analyst (BA)) ........................... 28
6.3 SYSTEM ANALYSIS & DESIGN PHASE ........................................................................29
6.3.1 Develop System Design & Data Architecture AND Estimate Development Effort (External
System Developer) ............................................................................................................................. 31
6.3.2 Review/Sign-off “User-System Interface” Design (Program Administrator (PA))..................... 33
6.3.3 Review “User-System Interface” Design (ISB Business Analyst (BA)) .................................... 33
6.3.4 Develop OR QA/Approve Data Architecture (ISB Data Administrator (DA)) ........................... 34
6.3.5 Plan / Design Data Architecture For Data Conversion (ISB Data Administrator (DA)) ............ 36
6.3.6 Develop System Design / Estimate Development Effort OR QA/Approve System Design (ISB
Programmer) ...................................................................................................................................... 37
6.3.7 Develop Database Design / Estimate Development Effort OR QA/Approve Design (ISB
Database Administrator (DBA)).......................................................................................................... 38
6.3.8 Assist With Data Conversion Planning / Design (ISB Database Administrator (DBA)) ........... 40
6.3.9 Evaluate System Development Estimates / Development Priority (Program Administrator
(PA)) ................................................................................................................................................... 40
6.3.10 Assist with Evaluating System Development Estimates/ Development Priority (ISB Business
Analyst (BA)) ...................................................................................................................................... 41
6.3.11 Place Project on HOLD (ISB Business Analyst (BA)) ............................................................ 41
6.3.12 Review Project Scope/Requirements and Schedule Development (Change Management
Board (CMB)) ..................................................................................................................................... 42
6.3.13 Place Project on Temporary HOLD (ISB Business Analyst (BA)).......................................... 43
6.3.14 Promote to Development State (ISB Harvest System Administrator) .................................... 43
6.4 DEVELOPMENT PHASE .................................................................................................44
6.4.1 Develop Database / System & Unit Test Functions (External System Developer).................. 45
6.4.2 QA User Procedures / User Acceptance Test Plan (Program Administrator (PA)) ................. 47
6.4.3 QA User Procedures / User Acceptance Test Plan (ISB Business Analyst (BA)) ................... 48
6.4.4 Develop / Unit Test System Functions OR QA / Approve System Unit Test (ISB Programmer)
............................................................................................................................................................ 48
6.4.5 Develop & Implement Data Conversion Functions (ISB Programmer) .................................... 50
6.4.6 Develop OR QA/Approve Server Model / Database (ISB Database Administrator (DBA)) ..... 50
6.4.7 Develop Temporary Data Conversion Database (ISB Database Administrator (DBA)) .......... 51
6.4.8 Perform Manual Data Conversion (Designated Program Area Personnel) .............................. 52
6.4.9 Assign Release Number (ISB Harvest System Administrator) ................................................ 52
6.4.10 Promote to Integration System Test (ISB Harvest System Administrator) ............................ 53
6.5 INTEGRATION SYSTEM TESTING (IST) PHASE...........................................................53
6.5.1 Move Development Objects into ISB Delivery Environment (External System Developer)..... 54
6.5.2 Perform Integrated System Test (IST) (External System Developer) ...................................... 55
6.5.3 Validate Screens/Reports During Integration Testing (Program Administrator (PA)) .............. 56
6.5.4 Assist Designated PA(s) With Integration Testing (ISB Business Analyst (BA)) ..................... 56
6.5.5 Move System Objects into ISB Delivery Environment (ISB Programmer) ............................... 57
6.5.6 Perform / QA/Approve Integrated System Test (IST) (ISB Programmer) ................................ 57
6.5.7 QA/Approve Integration System Testing (IST) (ISB Database Administrator (DBA)).............. 58
6.5.8 Approve Integration System Test (IST) (ISB Business Analyst (BA))...................................... 59
6.5.9 Set-up UAT System Environment (ISB Programmer) .............................................................. 59
6.5.10 Set-up UAT Oracle Environment (ISB Database Administrator (DBA))................................. 59
6.5.11 Promote to User Acceptance Test (UAT) State (User Acceptance Testing Phase) .............. 60
6.6 USER ACCEPTANCE TESTING (UAT) PHASE .............................................................60
6.6.1 Conduct User Acceptance Test / Signoff System Acceptance (Program Administrator (PA)) 61
ii
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.1
6.6.2 Participate In User Acceptance Test / APPROVE Production Implementation (ISB Business
Analyst (BA)) ...................................................................................................................................... 61
6.6.3 Promote to Implementation State (ISB Harvest System Administrator)................................... 62
6.7 IMPLEMENTATION PHASE ............................................................................................63
6.7.1
6.7.2
6.7.3
6.7.4
6.7.5
6.7.6
6.7.7
Conduct / Participate In User Training (Program Administrator (PA)) ..................................... 63
Conduct / Assist With User Training / Approve Implementation (ISB Business Analyst (BA)) 64
Implement (Deploy) System (ISB Programmer)....................................................................... 64
Assist With Data Conversion Into Production (ISB Programmer) ............................................ 65
Implement Database In Production (ISB Database Administrator (DBA))............................... 65
Perform Data Conversion Into Production Database (ISB Database Administrator (DBA)) .... 66
Promote to Production State (ISB Harvest System Administrator) .......................................... 67
6.8 PRODUCTION PHASE.....................................................................................................67
6.8.1 Sign-off System Acceptance (Program Administrator (PA)) ..................................................... 67
6.8.2 Conduct Post Implementation Review (ISB Business Analyst (BA)) ........................................ 68
APPENDIX A .............................................................................................................................................. 69
A – 1 SCM Methodology Harvest Processes ......................................................................69
A-1.1 Approve Package ..................................................................................................................... 69
A-1.2 Check In.................................................................................................................................... 70
A-1.2a Check In (Package Level) .................................................................................................. 70
A-1.2b Check In (State Level)........................................................................................................ 71
A-1.3 Check Out For Browse ............................................................................................................. 75
A-1.4 Check Out For Update.............................................................................................................. 77
A-1.5 Create Deficiency Package ...................................................................................................... 79
A-1.6 Create Designer Package – removed from SCM Methodology on June 17, 2005 .................. 80
A-1.7 Create Document Package....................................................................................................... 80
A-1.8 Create RFC (Harvest Workbench) ........................................................................................... 81
A-1.9 Create RFC (Web).................................................................................................................... 82
A-1.10 Demote ................................................................................................................................... 84
A-1.11 Hold Package ......................................................................................................................... 85
A-1.12 Logon ...................................................................................................................................... 85
A-1.13 Logoff ...................................................................................................................................... 88
A-1.14 Move Package ........................................................................................................................ 88
A-1.15 Promote .................................................................................................................................. 89
A-1.16 Reject Package....................................................................................................................... 89
A-1.17 Take Snapshot........................................................................................................................ 90
A - 2 Other Harvest Processes.............................................................................................92
A-2.1 List Differences Between Views ............................................................................................... 92
A-2.2 List Version ...............................................................................................................................95
A - 3 Standards......................................................................................................................97
A - 2.1 Releases ................................................................................................................................. 97
A - 2.2 Package Naming Standards ................................................................................................... 97
A – 2.2.1 RFC Package (Request For Change) Naming Standards ............................................. 97
A – 2.2.2 Deficiency Package Naming Standards ......................................................................... 97
A – 2.2.3 Oracle Designer Package Naming Standards................................................................ 97
A – 2.2.4 Package Group Naming Standards................................................................................ 98
iii
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
1. VERSION CONTROL
Document
Version
1.0
1.1
Harvest
Version
1.1.1
6
1.2.0
7
Description
Initial Publication
Development Phase
Enhancements
Removal of Designer
Package Creation.
Added notifications for BA
Dev Phase
Enhancements
Changed Ministry Names
Date
Author
Organization
April 30, 2004
June 30, 2004
Ted Dixon
Ted Dixon
MCAWS
MCAWS
June 16, 2005
K Warnes
MCAWS
Sept 27, 2007
Kwarnes
MCS
2. INTRODUCTION
2.1. Audience
The intended audience for this document includes:
¾ Program Administrators
¾ ISB Managers
¾ Business Analysts
¾ Systems Configuration Management - Software Administrators
¾ Data Administrators
¾ Database Administrators
¾ ISB Programmers
¾ External System Developers
¾ Designated Program Area Participants
2.2. Purpose
The purpose of this document is to describe the Systems Configuration Management (SCM)
methodology and the related processes which support the System Configuration Management Process
Diagram. This includes the detailed instructions of how to use AllFusion Harvest software to support
the methodology activities.
3. SYSTEMS CONFIGURATION MANAGEMENT (SCM)
3.1. Systems Configuration Management - Definition
Systems Configuration Management is a process for controlling the development and implementation
of software tools within the Ministry to support its business functions. It covers all activities of the
systems development life cycle; from identifying a need to solve a business requirement and
developing a business case for the proposed solution, to the implementation of the software solution.
The Methodology describes major software development/enhancements projects or minor software
changes/enhancements (Section 6 – SCM Methodology - Major/Minor Software
Development/Enhancements).
-1-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
3.2. Baseline Criteria For Harvest Candidates
The baseline criteria for an application to be a candidate for inclusion in the Harvest environment
should be:
1. Source code for the release of the application in Production.
2. All application related documentation deliverables, which are deemed important and up-todate (if possible).
3. For Oracle based applications, a stable database metadata in Designer 10g repository
created according to our Designer 10g SCM guidelines and baselined in the
WA_PRODUCTION workarea. This has to be manually QA'ed and verified against the
actual database components that are implemented in Production.
4. PROPOSED SCM HARVEST REPOSITORY STRUCTURE
The following table illustrates the Harvest Repository Structure for storing systems development
lifecycle deliverables. NOTE: This is to be reviewed on a periodic basis as new needs arise.
Project: CCOF
Package Group: R03.21.16
RFC_022456 Package
This represents an application.
This represents an application “Release”
Contents examples
- Request Description
- Requirements Statement
- Business Case (if applicable)
- Managed Programming Code (RFC
Dependent)
Contents examples
- Request Description
- Requirements Statement
- Business Case (if applicable)
- RFC Estimates (Optional)
- Managed Programming Code (RFC
Dependent)
Contents examples
- Requirements Documentation
- User Procedures
- System Design Documentation
- Business Case (if applicable)
- Test Plans
- Release Project Plan
- Unmanaged Programming Code
Contents examples
- Unit Test QA Review
- Integration Test QA Review
- User Acceptance Test Deficiencies
RFC_022466 Package
DOC_000345 Package
DEF_022466 Package
-2-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
CCOF_R03-21-16 Package
(For Designer Objects
NOTE: the 4 character Application
acronym prefix)
Contents examples
- Designer 10g Configuration
R03.21.16
- Designer 10g Diagrams
- Designer 10g DDL
5. DEFINITION OF TERMS
5.1 Systems Configuration Management (SCM) Acronyms/Terms
SCM Acronym/
Term
BA
DA
DBA
Designer Package
DOC Package
External System
Developers
IST
MCS
MTSA
PA
Program Area
Acronym/ Term Description
An acronym for the Ministry’s ISB Business Analyst
An acronym for the Ministry’s ISB Data Administrator
An acronym for the Ministry’s ISB Database Administrator
A special package created during the Implementation Phase for storing
Oracle objects applicable to a System Release. NOTE: This applies
only to Releases in Oracle objects were either created and/or updated.
This would not apply to Releases with only programming changes or
when the changes are to non-Oracle databases.
This special package is created when the Release Package Group is
set-up in the early stages of the System Requirements Phase. It
contains documentation related to the entire Release rather than to a
specific RFC Package. As an example, a copy of the new/updated
Integration System Testing (IST) Plan and the relative IST results
targeted to the specific Release.
This term describes all of the participating team members at an external
company that are on contract to develop a new system or to enhance a
system. The latter could be anything from additional functionality to a
minor change such as the pitch of a report heading.
An acronym for Integration System Testing.
An acronym for Ministry of Community Services.
An acronym for Ministry of Tourism, Sport and the Arts
An acronym for Program Administrator
This refers to designated or all members of a Ministry Business Unit. As
an example, the group responsible for Child Care Subsidy program
which includes the PA for the area.
-3-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
SCM Acronym/
Term
RFC
SCM
SDLC
SUT
SYSTEM DEFECT
(Harvest Deficiency
(DEF) Package)
Acronym/ Term Description
An acronym for Request For Change (i.e. a system change request).
NOTE: A Request For Change (RFC) is defined as:
“Requests for a new system, a system enhancement or an emergency
system fix to correct a system malfunction of a system that has been
in implemented into production. It also applies to system
requirements that have not been stated in the System Requirements and
therefore not specified in system terms in the System Design”. Some
examples of the latter case are:
¾ a hoped for screen navigation that was not identified until
the system had been developed and was in the testing
state
¾ a required report field that was not discovered until the
system testing stage.
An acronym for System Configuration Management
An acronym for System Development Life Cycle. This is the standard
System Development methodology that describes the proven techniques
of developing quality-based systems. Extensions of this methodology
include Information Engineering (IE) and Zachman Enterprise
Framework.
An acronym for System Unit Test
NOTE: A Deficiency is defined as:
“A recorded event where a system process does not function as stated
in the System Requirements and specified in system terms in the
System Design”. Some examples are:
¾ the screen navigation is not according to the specifications in
the System Requirements and System Design
¾ a report field does not contain the expected values as
specified in the System Requirements and System Design
¾ during testing, a program crashes or a system process
malfunctions.
In every case, the system process did not behave as defined in the
System Requirements and subsequently specified in the System Design.
UAT
System Deficiencies would be recorded in Harvest “Deficiency” (DEF)
packages created by the ISB BA on behalf of the User Testers during
the User Acceptance Testing (UAT).
An acronym for User Acceptance Test.
-4-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
SCM Acronym/
Term
User System
Requirements
Acronym/ Term Description
This Industry Standard term refers to a description of a minor System
Change, System Enhancement or a new System in terms of satisfying
Business Function Information needs. This is not the same as System
Analysis & Design in which the system is described in terms of detailed
system functionality (e.g. Logical Data Architecture, Screens, Reports,
Detailed System Function Specifications, Test Plans).
This differs from Business Analysis, which is targeted toward the
Mission Statement, Goals and Objectives and the relative Processes of
an Enterprise or a Business Function (Unit). Other deliverables from a
“Business Analysis” (Study) initiative could also be a “Business Process
Re-engineering” (i.e. BPR) or a “Business Process Improvement” (i.e.
BPI) report with the supporting “Enhanced Business Process” and
possibly “Personnel Organization Chart(s)” and supporting “Position Job
Description” documentation.
5.2 Harvest Terms
Harvest Term
Change Item
Harvest Form
Life Cycle
Package
Package Group
Project
Harvest Term Description
An electronic file (e.g. source code, executable code, MS Word document)
that is under the change Management of Harvest.
This pertains to a specific Harvest Function screen (e.g. “Create RFC
(Web)” form, “Approve Package” form).
This is a set of Systems Development Life Cycle (SDLC) Phases of a
project to develop or change computer system software. The Phases
consist of INITIATE, SYSTEM REQUIREMENTS, SYSTEM ANALYSIS &
DESIGN, DEVELOPMENT (system functions/programs and manual
procedures as required), INTEGRATION TESTING (i.e. System Integration
Testing), USER ACCEPTANCE TESTING, IMPLEMENTATION (i.e. total
system implementation which includes training and implementation of
manual procedures as well as system functions and database),
PRODUCTION (where the project is reviewed by all parties to learn what to
do or avoid in the future when developing / enhancing systems).
In Harvest, this is a basic unit of work that moves through the system life
cycle. Refer to Section #4 above for the proposed contents of a package
and how it is grouped into a software release.
A Package Group provides a means of grouping related “Packages” so that
one is able to perform Harvest Process at a higher level that would apply to
all of the associated individual Packages. As an example, by Promoting a
Package Group to the next Harvest State, all of the Packages within the
Group are automatically Promoted as well. A particular Package may
belong to one group, several groups, or no groups at all. Refer to Section #4
above for the proposed contents of a Package Group and how one or more
packages would be grouped into a software release.
In the Information Technology (IT) industry this is known as an application.
Some examples in this Ministry are LGIS, CCOF, STVS, etc.
-5-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Harvest Term
Repository
Harvest Term Description
In Harvest, this is the database that contains a hierarchical collection of
versioned of RFC related items. These could consist of the original request
and the business case document, Requirements and Design documents,
system development estimates, system related correspondence, program
code, database design and code, User Procedures and other related system
“objects”.
6. SCM METHODOLOGY – Major/Minor Software
Development/Enhancements
6.0 Process Notes / General Harvest Procedures
6.0.1 Primary SCM Methodology Process Participant
In the following SCM Methodology Process descriptions, the Primary Participant is indicated by BoldItalic font (e.g. ISB Business Analyst (BA)). This corresponds to the SCM Methodology Process
Diagram “Swim Lane” participant name.
6.0.2 Hyperlink Access to Detailed Harvest Function Procedures
The detailed description of how to use Harvest Workbench processes to perform the required
procedure (e.g. Check In) is contained in the APPENDIX. The description may be accessed by
clicking on the Harvest “Hyperlink” link included in a SCM Methodology Process (e.g. Check In ).
To return to the SCM Methodology Process from the APPENDIX, use the “Back” Arrow
Word/Web Toolbar.
on the
6.0.3 Harvest Workbench Logon / Logoff Procedures
Purpose
This section contains the links to detailed descriptions of “Logging Into” or “Logging Off” Harvest.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
All “Licenced” Harvest Users
HARVEST Process
Logon
Logoff
-6-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.1 INITIATE PHASE
Purpose
In this phase a request for system change (which could range from a bug fix to a new system) is
received, evaluated and if deemed feasible, the relative Request For Change (RFC) is created in
Harvest. If it’s a major change, the System Requirements Phase is initiated.
Deliverables
Deliverable
Request For Change (RFC)
The User “Change Request” is initiated by
entering it into the Harvest Repository
(database) using the Harvest “Create RFC”
process.
Detailed Description of Requirements
This consists of a separate document in
addition to a brief requirements description in
the relative RFC Package folder. The
document content may range from a brief
description of a new system or a major system
enhancement to support the business
information needs for large projects to a basic
description for a minor change (e.g. correct the
identified “system bug” in the Child Care
Subsidy – Claims screen as indicated by the
system error message). In the latter instance,
captured screen images should be included for
information purposes.
Business Case Report
This could be a Cost / Benefits Analysis report
which identifies direct and indirect costs and
benefits.
Responsibility
PA
ISB BA
M = Mandatory
PD = Project
Dependent
M
PD
PA, ISB BA
PD
PA, ISB BA
PD
-7-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Deliverable
Formal Project Request Estimate
Request(s)
This could be:
¾ an Informal Quote for System
Requirements Development
¾ an “Invitation To Quote” (ITQ) for
System Requirements and possibly for
a “guesstimate” of the total
system/system enhancement
¾ a “Request For Proposal” (RFP) for a
total system solution.
Responsibility
ISB BA, PA
M = Mandatory
PD = Project
Dependent
PD
6.1.1 Evaluate Request / Defect / Enhancement (Program Administrator (PA))
Purpose
The Program Administrator (PA) receives a request for a system change or for a new system. The
request is evaluated based on need, business case, and the Program Area’s system requirements
priorities.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
S
S
Participant
Participant Role
Program Administrator (PA)
Requester of the system or system
change
Program Area Management (as
required)
ISB Business Analyst (BA)
Responsible for Process Activities and
Deliverables
Initiates Change Request
Approves Change Request
Consultant to PA
Methodology Process Activities
1. A PA receives a change request, evaluates the requirement and feasibility with the Program
Area person who initiated the request.
2. If the request is rejected, the PA notifies all involved parties of the rejection and the
reason(s) for the decision.
3. If the request is accepted, the PA would perform the 6.1.2 Create RFC via Web Interface
process.
-8-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. If it’s a major request then:
¾ the PA would discuss the RFC with the BA, and if technical advice is required, the
BA would contact the appropriate ISB technical personnel (e.g. DA, DBA,
Programmer)
¾ through meetings or other communication means with Program Area Management
and any other interested user community members, the PA would obtain a
consensus for approval to proceed to the next set of phases or reject the request.
6.1.2 Create RFC via Web Interface (Program Administrator (PA))
Purpose
This process describes RFC creation using the Harvest Create RFC (Web) process using the Web
Interface.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Program Administrator (PA)
Other Users Acting in the PA Role
Primary User in Creating RFCs remotely
Secondary Users that are able to Create
RFCs on an “as required” basis
Methodology Process Activities
1. The PA creates a RFC using the Create RFC (Web) process with (NOTIFICATIONS: ISB
BA). If supporting documentation is required (e.g. screen shots to illustrate a system bug), it is
included as an attachment to the RFC on the Web form. In the initial implementation, a
maximum of 5 attachments may be included during the RFC creation.
6.1.3 Review Request (ISB Business Analyst (BA))
Purpose
This process highlights the Business Analyst’s role in assisting the Program Area in evaluating a
change request.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Provides system related request consulting
services to the PA
Reviews a system related request before
approval
Provides data related consulting services as
identified
ISB Business Analyst (BA)
S
Program Administrator (PA)
S
ISB Data Administrator (DA)
-9-
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participant
Type
P = Primary
S = Supporting
S
S
Participant
Participant Role
ISB Database Administrator (DBA)
ISB Programmer
Provides database related consulting
services as identified
Provides programming related consulting
services as identified
Methodology Process Activities
1. The BA is notified when a PA creates a RFC. The ISB BA reviews it for completeness and
ensures that the PA has attached any required supporting documentation.
2. If the RFC is for a minor change or to report a system malfunction, the BA may obtain advice
from ISB technical personnel (i.e. ISB Data Administrator (DA), ISB Database Administrator
(DBA), ISB Programmer) before proceeding with the 6.1.5 Promote to System Requirements
State process.
3. If the RFC is for a major change, the BA assists the PA with the change request evaluation and
provides suggestions/recommendations regarding the request. This may include obtaining
advice from ISB technical personnel (i.e. ISB Data Administrator (DA), ISB Database
Administrator (DBA), ISB Programmer).
4. After the initial evaluation process, the BA would:
¾ perform the 6.1.10 Reject RFC process if the decision is to Reject the RFC
¾ perform the 6.1.9 Place RFC ON – HOLD process if the decision is to place the
request On Hold until some future date
¾ perform the 6.1.5 Promote to System Requirements State process if the decision
is to proceed to the next phase(s) with the RFC.
6.1.4 Create RFC (ISB Business Analyst (BA))
Purpose
This process describes how an ISB BA would create a RFC in Harvest, which formally initiates the
change request.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Creates a RFC when/as required
ISB Business Analyst (BA)
Methodology Process Activities
1. The BA creates a RFC using Harvest Create RFC (Harvest Workbench) process with
(NOTIFICATIONS: ISB BA). To include additional supporting documentation, the BA would
attach it by selecting the “attach” feature (Icon) located on any Harvest screen.
2. If any supporting documents are to be updated, they must be checked against the Harvest DOC
Package using Harvest Check In process.
- 10 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.1.5 Promote to System Requirements State (ISB Business Analyst (BA))
Purpose
The purpose of this process is to highlight the promotion of the RFC from the Initiate State to the
System Requirements state. This implies that the PA and ISB BA have “APPROVED” the RFC.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Promotes an approved RFC to the next
Phase
ISB Business Analyst (BA)
Methodology Process Activities
1. The ISB BA is notified when a RFC has been created in Harvest and approved by the PA.
2. The BA reviews the prepared RFC for completeness.
3. The BA would then promote the RFC to the System Requirements Phase using Harvest
Promote process.
6.1.6 Review Data Requirements (ISB Data Administrator (DA))
Purpose
NOTE: This process is to be performed on an “as identified” basis when there are data implications.
The purpose is to advise the BA and Program Area on possible data impact to support the RFC
requirements.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Data Administrator (DA)
Provides data related consulting to assist
RFC evaluation
Obtains RFC data impact used in evaluating
the requested system change
ISB Business Analyst (BA)
Methodology Process Activities
1. Provide the BA with information on the potential data requirements based on the change
request. This would assist the BA with evaluating the potential magnitude and/or feasibility of
implementing the change.
- 11 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.1.7 Review System Requirements (ISB Programmer)
Purpose
NOTE: This process is to be performed on an “as identified” basis when there are major system
function implications. The purpose is to advise the BA and Program Area on possible programming
impact to support the RFC requirements.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Provides programming related consulting to
assist RFC evaluation
Obtains RFC data impact used in evaluating
the requested system change
ISB Programmer
ISB Business Analyst (BA)
Methodology Process Activities
1. Provide the BA with information on the potential system function(s) requirements based on the
change request. This would assist the BA with evaluating the potential magnitude and/or
feasibility of implementing the change.
6.1.8 Review Database Impact (ISB Database Administrator (DBA))
Purpose
NOTE: This process is to be performed on an “as identified” basis when there are database
implications. The purpose is to advise the BA and Program Area on possible impact to support the
RFC requirements.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Database Administrator (DBA)
ISB Business Analyst (BA)
Provides database related consulting to
assist RFC evaluation
Obtains RFC database impact used in
evaluating the requested system change
Methodology Process Activities
1. Provide the BA with information on the potential database requirements based on the change
request. This would assist the BA with evaluating the potential magnitude and/or feasibility of
implementing the change.
- 12 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.1.9 Place RFC “ON - HOLD” (ISB Business Analyst (BA))
Purpose
In this process a RFC is placed on HOLD until a decision is made to either proceed with the
development effort or permanently close the RFC (i.e. Reject it). The reason for placing a RFC on
HOLD may be that either the time and/or the cost estimate is prohibitive at evaluation time.
NOTE: The RFCs in this state are to be reviewed periodically by the BA and the PA, and a
determination made if the RFC should remain in the HOLD state, be re-activated or be placed into the
REJECT state (i.e. CLOSE the project).
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Based on the program area decision, the BA
would place a RFC in a HOLD State,
REJECT State or Promote a RFC On HOLD
to the next phase
Is responsible for advising the ISB BA on
the course of action regarding a new RFC or
those in a HOLD state
ISB Business Analyst (BA)
Program Administrator (PA)
Methodology Process Activities
1. If the System Requirements are not being developed, the BA would place the RFC package(s)
and any supporting documentation into a HOLD State using Harvest Hold Package process
with appropriate notation on the RFC form.
2. The BA reviews RFC packages in the HOLD State on a periodic basis, and in consultation with
the PA determine if any of them are to:
¾ remain in the HOLD state
¾ be re-activated by promoting the RFC Package(s) to the System Requirements Phase
using the Promote process.
¾ be placed into a REJECT state (i.e. CLOSE the project) using Harvest Reject Package
process.
6.1.10 Reject RFC (ISB Business Analyst (BA))
Purpose
The process highlights a rejection of a new RFC based on a preliminary review by the programmer
area with the BA’s assistance.
- 13 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Reject a RFC
ISB Business Analyst (BA)
Methodology Process Activities
1. Based on the joint decision by the PA and ISB BA, the BA would close the respective RFC(s) by
placing them into a Reject State using Harvest Reject Package process.
6.2 SYSTEM REQUIREMENTS PHASE
NOTE: The detailed phase activities are to be done if the BA determines that it is a major change
request or that the change requires additional System Requirements.
Purpose
In this phase, the User System Requirements are developed for a new system or major
enhancements to an existing system. These Requirements must support the business information
needs through manual procedures and automated processes (e.g. data capture, data processing
and information reporting). If the Systems Analysis and Design deliverables are to be developed by
External Developers under a separate contract, then the time / cost estimates should also be a
deliverable in this phase.
Deliverables
Deliverable
System Requirements Development
Estimate
System Requirements Development
Decision Document
System Requirements Documentation
Data Requirements Review Report
Estimate For System Analysis & Design /
Design Effort
This would be done only if the magnitude of
the project warranted it.
Responsibility
BA / External
System
Developer
Program
Administrator
External System
Developer or
ISB BA
ISB DA
External System
Developer or
ISB DA, DBA,
ISB
Programmer
- 14 -
M = Mandatory
PD = Project
Dependent
PD
PD
PD
PD
PD
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Deliverable
Project Charter
This is a Mandatory Deliverable for major
projects such as major system enhancements
or for a new system.
Next Phase Decision
This consists of “written” communication from
the PA to the ISB BA, which states whether or
not the project is to proceed to the next phase.
External Vendor Contract
The contract may be for only the
Requirements Phase or for the entire project.
Responsibility
Program
Administrator,
ISB BA
M = Mandatory
PD = Project
Dependent
PD
Program
Administrator
M
Program Area
Management,
ISB BA, Ministry
Contract
Management
Group
PD
6.2.1 Determine Project Magnitude (ISB Business Analyst (BA))
Purpose
If the change is greater than a minor report or screen change (e.g. change the wording of a screen field
title, move a report field to a different location or simple report or screen display) or an emergency
system malfunction, then there could be a varying degree of Requirements and Design development.
In this instance, the ISB BA:
¾ determines the scope of a RFC or a related group of RFCs
¾ decides if major Requirements Development is needed before proceeding with the Analysis
/ Design Phase.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Determines project scope based on all
available information
ISB Business Analyst (BA)
Methodology Process Activities
1. The BA performs the following:
¾ reviews the RFC documentation stored in Harvest and determines the degree of
“Requirements” and “Design” effort required to implement the system change
¾ requests ISB Harvest System Administrator to set-up up the project in Harvest (6.2.8
Set-up Project Package Group process)
2. If it’s a minor change, then the BA performs the 6.2.20 Promote To Systems Analysis State
process after the ISB Harvest System Administrator has created the RFC PACKAGE GROUP.
3. If it’s a major change and System Requirements development is required, then the BA would
perform the 6.2.2 Prepare Requirements Estimate Request process.
- 15 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.2.2 Prepare Requirements Estimate Request (ISB Business Analyst (BA))
Purpose
If it’s a major system change/enhancement, then the ISB BA would;
¾ develop or assist the PA with the development of a Project Charter and check it against the
Harvest DOC Package. NOTE: The complexity of the charter is dependent on the
scope/size of the development project.
¾ if an external vendor will be contracted to develop the requirements, then ISB BA in
consultation with the Program Area would develop a formal request such as an Invitation To
Quote (ITQ) or for large systems; a Request For Proposal (RFP).
¾ if the requirements will be developed by an Internal BA or an internal BA under contract, an
informal Requirements Development Estimate would suffice.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for Requirements Estimate
Request preparation
Responsible for Project Charter preparation
and assists ISB BA with Requirements
Estimate Request
ISB Business Analyst (BA)
Program Administrator (PA)
Methodology Process Activities
1. The BA jointly with the PA decides if External Vendors or internal BA(s) will develop the
Requirements development.
2. The ISB BA develops or assists the PA with the development of a Project Charter and checks
it against the Harvest DOC Package using Harvest Check In process. NOTE: The complexity
of the charter is dependent on the scope/size of the development project.
3. If the System Requirements are being developed internally, the BA would determine the
estimate in time and cost through meetings with internal personnel (Ministry employees or
Business Analysts on contract to the Ministry) and record this in the RFC package.
4. If the System Requirements are being developed by an external vendor, then ISB BA in
consultation with the Program Administrator would:
¾ develop a formal request such as an Invitation To Quote (ITQ); or for large systems, a
Request For Proposal (RFP)
¾ check-in the formal request against the Harvest DOC Package using Harvest Check In
process.
¾ forward the request to potential external vendors for evaluation and formal estimates.
NOTE: The Project Charter would be an integral component of the formal request.
- 16 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.2.3 Estimate for System Requirements Development (External System
Developer)
Purpose
An external company provides an estimate for System Requirements development based on an
Invitation-To-Quote (ITQ) for a minor to medium sized projects or Request-For-Proposal (RFP) for
major projects. The ITQ or RFP may include a request for a “ball-park” or “fixed price” estimates to
complete the Systems Analysis, System Development, Integration System Testing and Implementation
phase activities.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for providing requested
estimates
Provides Estimates Consultation (as
required)
External System Developer
ISB Business Analyst (BA)
Methodology Process Activities
1. The BA would liaise with External System Developer as required by providing information
regarding the System Requirements.
2. The external company would forward the estimate(s) to the BA for review.
3. The BA checks-in the “Estimates Report” against the RFC Harvest DOC Package using Harvest
Check In process.
6.2.4 Estimate for System Requirements Development (ISB Business Analyst
(BA))
Purpose
Ministry or contracted Business Analysts estimate in-house System Requirements development.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Business Analyst (BA)
Responsible for estimating Requirements
development effort by internal BA(s)
Methodology Process Activities
1. Based on the RFC and any supporting documentation, the BA would estimate the amount of
time (and cost if a contractor were to be hired) that would be required to develop the System
Requirements in-house.
2. The BA records the estimate in the relative RFC Package using a Harvest RFC Package
function.
- 17 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.2.5 Evaluate System Requirements Development Estimate (Program
Administrator (PA))
Purpose
The Program Administrator (with ISB BA assistance) reviews the time & cost estimates and decides
whether or not to proceed with the Requirements Development and who would develop the System
Requirements (i.e. an ISB BA or an External System Developer).
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for deciding on whether or not
to proceed with the System Requirements
development
In a consulting capacity
Program Administrator (PA)
ISB Business Analyst (BA)
Methodology Process Activities
1. The PA would checkout the External Vendor estimates using Harvest Check Out For
Browse process.
2. The PA reviews the time & cost estimates and with BA assistance decides whether to proceed
with the Requirements Development or defer the RFC to some future date.
3. If development is to proceed, then the BA and PA decide who will develop the System
Requirements, internal ISB BA or a BA on contract; or an External Vendor.
4. The PA prepares a decision communication and forwards it to the assigned BA for the record.
5. The BA attaches the communication to the RFC Package using the Harvest “Document
Attachment” function.
6.2.6 Assist with Evaluating Requirements Development Estimate (ISB Business
Analyst (BA))
Purpose
The BA assists the Program Administrator with the estimate evaluation and the decision whether or not
to proceed with the Requirements Development.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
In a consulting capacity to the PA
ISB Business Analyst (BA)
- 18 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. The BA would check out the estimates using Harvest Check Out For Browse process and
assist the PA with the decision regarding Systems Requirements development.
2. The BA receives the decision communication and attaches the communication to the relative
RFC Package using the “Document Attachment” function.
3. If the RFC is to proceed with System Requirements development, the BA requests ISB Harvest
System Administrator to set up the project in Harvest (i.e. 6.2.8 Set-up Project Package Group
process).
4. If development is being deferred to some future date, then the BA performs the 6.2.7 Place
RFC ON - HOLD process.
5. If development is to be done in-house with the assistance of contract help, the ISB BA arranges
for a Contract BA.
6. If the development is to be done by an external company, the BA participates in the preparation
of the contract by interested parties and check-in the soft copy against the Harvest DOC
Package using the Check In process.
6.2.7 Place Project “ON HOLD” (ISB Business Analyst (BA))
Purpose
The BA places a project on HOLD until a decision is made to proceed with the development effort or
permanently close the project. The reason for this decision may be that either the time and/or the cost
estimate is prohibitive at evaluation time.
NOTE: The RFCs in this state are to be reviewed periodically by the BA and the PA, and a
determination made if the RFC should remain in the HOLD state, be re-activated or be placed into the
REJECT state (i.e. CLOSE the project).
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for placing a RFC On HOLD /
Re-activating a RFC On HOLD / placing a
RFC in the REJECT state (i.e. closing the
RFC)
Provides direction regarding RFCs On
HOLD
ISB Business Analyst (BA)
Program Administrator (PA)
Methodology Process Activities
1. If System Requirements are not being developed, the BA would place the RFC package(s) and
any supporting documentation into a HOLD State using Harvest Hold Package process with
appropriate notation on the RFC form.
- 19 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
2. The BA reviews RFC packages in the HOLD State on a periodic basis, and in consultation with
the PA determine if any of them are to:
¾ remain in the HOLD state
¾ be re-activated by promoting the RFC Package(s) to the System Requirements Phase
using the Promote process.
¾ be placed into a REJECT state (i.e. CLOSE the project) using Harvest Reject Package
process.
6.2.8 Set-up Release Package Group (ISB Harvest System Administrator)
Purpose
The ISB Harvest System Administrator sets-up the Release Package Group (e.g. RFC Package(s),
Release DOC Package) in Harvest; which is the start of a Development Release. The Package Group
is assigned a temporary Name. It is re-named with the Release Number prior to being promoted into
the Integration System Testing Phase.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Harvest System Administrator
ISB Business Analyst (BA)
Sets-up the Release Package Group
Requests Release Package Group
Methodology Process Activities
1. The BA requests the ISB Harvest System Administrator to set up a System Release within
Harvest.
2. The ISB Harvest System Administrator performs the following:
¾ creates the Documents Package using Harvest Create Document Package
process
¾ creates a Harvest Package Group identified by a temporary “Release Name”
¾ adds the relative RFC and Document Packages to the Package Group using Harvest
“Package Assignment” functionality
¾ advises the ISB BA that a Package Group has been created. This notification would
include the assigned Package Group name.
6.2.9 Develop System Requirements & Estimate Design (External System
Developer)
Purpose
This process describes the activities performed by an External System Developer developing the
System Requirements and estimating the effort and cost for specified subsequent phases.
- 20 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for developing System
Requirements & Subsequent Phases
Estimates
Responsible for providing System
Requirements Information
Participates in System Requirements
development
Participates in System Requirements
development by providing data related
consulting
External System Developer
P
Program Area Representatives
S
ISB Business Analyst (BA)
S
ISB Data Administrator (DA)
Methodology Process Activities
1. If the change request is an enhancement, the ISB BA would forward the developed System
Requirements documentation to the External Developer for enhancement.
2. Based on information obtained through initial RFC documentation, Joint Application Design
(JAD) sessions, meetings and consultation with the Program Area Representatives, ISB BA and
DA, develop the System Requirements to support the identified Business Function needs.
3. When the System Requirements have been completed, they are forwarded to the ISB BA for
sign-off.
4. If requested, the subsequent phases estimate(s) are completed by the External Developers and
forwarded to the ISB BA for review with the PA.
6.2.10 Develop / Review System Requirements (ISB Business Analyst (BA))
Purpose
This process describes the activities to either:
¾ develop/enhance and QA System Requirements developed by Internal BA(s) and estimate
the effort for the System Analysis & Design phase
¾ participate (in a consultative capacity) in system development/enhancement and QA
System Requirements developed by External System Developers.
Participants
Participant
Type
P = Primary
S = Supporting
P
P
Participant
Participant Role
Responsible for System Requirements
Development
Responsible for providing System
Requirements Information
ISB Business Analyst (BA)
Program Area Representatives
- 21 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participant
Type
P = Primary
S = Supporting
S
Participant
Participant Role
ISB Data Administrator (DA)
Participates in System Requirements
development by providing data related
consulting
Methodology Process Activities
1. If it’s a minor change, then
¾ check the RFC and any supporting documentation to ensure that the Requirements
specifications are complete
¾ if additional details are required, in discussion with the user community, the BA would
complete the Systems Requirements specifications and check the Requirements against
the Harvest DOC Package using the Check In process.
2. If it’s a major change then:
¾ if the change request is an enhancement, the BA would check-out any previous System
Requirements documentation using the Check Out For Update process
¾ based on information obtained through initial RFC documentation, Joint Application
Design (JAD) sessions, meetings with the Program Area Representatives and
consultation with the ISB DA, develop the System Requirements to support the identified
Business Function needs
3. When the System Requirements have been completed, check-in the System Requirements
against the Harvest DOC Package using the Check In process.
4. If the System Analysis & Design phase is to be done in-house, the ISB BA would request
estimates from the ISB System Analysis and Design team and forward them to the PA for
evaluation.
6.2.11 Review Data Requirements (ISB Data Administrator (DA))
Purpose
This process highlights the importance of Data Administrator participation in the initial phases of an
enhancement or new system. By having the DA provide data related consultation at the Requirements
phase, the risk of not having the data and/or the appropriate data architecture to support current and
potential future business information needs is greatly reduced.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for providing data related
consultation
Responsible for System Requirements (if
Requirements are being developed
externally)
ISB Data Administrator (DA)
External System Developer
- 22 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participant
Type
P = Primary
S = Supporting
S
Participant
Participant Role
ISB Business Analyst (BA)
Responsible for System Requirements (if
Requirements are being developed
internally)
Methodology Process Activities
1. Participate in Joint Application Design (JAD) and meetings to ensure that the data and/or the
appropriate data architecture to support current and potential future business information needs
is met. This includes assurance of data integrity and effective data acquisition by the
envisioned System Processes.
2. If the change is to replace an existing system, identify requirements for Data Conversion.
3. Using the Requirements documentation provided by the BA or obtaining a copy of the
documentation using the Check Out For Browse process, ensure that all data related
information; including the associated Business Rules regarding the data are included in the
System Requirements documentation. This provides the basis for the next phase in the
methodology.
4. Prepare a Data Requirements Review Report documenting observations/ comments/
recommendations regarding the data related requirements to support the System Requirements
prepared by External System Developers or by Internal BA(s)
5. Attach the Data Requirements Review Report to the Harvest DOC Package using the Harvest
“Documentation Attach” function.
6.2.12 Estimate Data Architecture Development (ISB Data Administrator (DA))
Purpose
The ISB DA is to provide an estimate of the time required to develop Logical Data Architecture.
NOTE: This process applies to System Requirements that have been developed by an ISB BA.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Provides an estimate for Logical Data
Architecture development
ISB Data Administrator (DA)
Methodology Process Activities
1. Obtain a copy of the System Requirements documentation using the Check Out For
Browse process.
2. Estimate the effort for creating Logical Data Architecture and forward the estimate to the ISB
BA for evaluation.
- 23 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.2.13 Estimate Systems Analysis / Design (ISB Programmer)
Purpose
The ISB Programmer prepares an estimate of the time required to develop a System Functions Design
which includes function code specifications, screens / reports layouts.
NOTE: This process applies to System Requirements that have been developed by an ISB BA.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Programmer
Provides an estimate for system functions
specification and screen/report design
development
Methodology Process Activities
1. Obtain a copy of the System Requirements documentation using the Check Out For Browse
process.
2. Estimate System Functions Specifications and screens / reports layout design.
3. Forward the estimates to the ISB BA for evaluation.
6.2.14 Estimate Database Design (ISB Database Administrator (DBA))
Purpose
The ISB Database Administrator (DBA) prepares an estimate of the time required to develop any
special/unusual database requirements design (e.g. temporary data conversion databases) specific
to the System Requirements. In normal circumstances, the database design estimate is dependent on
the Logical Data Architecture development.
NOTE: This process applies to System Requirements that have been developed by an ISB BA.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Database Administrator (DBA)
Provides an estimate for Physical Database
Objects design
Consultant on Data Architecture Impact on
Database Design
Consultant on Database Design impact on
Programming effort
S
ISB Data Administrator (DA)
S
ISB Programmer
- 24 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. Obtain a copy of the System Requirements documentation using the Check Out For
Browse process.
2. Determine (in consultation with the ISB DA and Programmer) if there are any unusual data
requirements that will require additional database design objects not specified in the Logical
Data Architecture that need to be developed in the next phase. An example would be the
design of a Temporary Database to accommodate Data Conversion.
3. If there were any special design requirements, the DBA would estimate the additional effort
and forward the estimate to the ISB BA.
6.2.15 Review/Sign-off Requirements (Program Administrator (PA))
Purpose
The Program Area Users review the requirements through working sessions/JADs with the participants
involved in developing the User System Requirements. After the reviews have been completed and the
requirements have been determined to meet the User needs, the Program Area project sponsor signsoff the requirements. This officially sets the scope and deliverables for the project.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Program Administrator (PA)
Designated System Requirements
Development Participants
Responsible for formally accepting the
System Requirements
Act in a consulting capacity
Methodology Process Activities
1. If the PA has Harvest access, obtain a copy of the System Requirements documentation using
the Check Out For Browse process.
2. If the PA does not have Harvest access, obtain a copy of the System Requirements
documentation from the ISB BA.
3. Review the User System Requirements with designated System Requirements development
participants.
4. Any last minute changes are made to the Requirements documentation.
5. Steps 1 – 4 are repeated until the Users are satisfied with the User System Requirements.
6. When the Users are satisfied with the System Requirements, then:
¾ the Program Area project sponsor and designated parties sign-off the System
Requirements
¾ the ISB BA is provided with a signed-off copy and a soft copy of the System Requirements.
This officially sets the scope and deliverables of the Release.
6.2.16 QA/Approve System Requirements (ISB Business Analyst (BA))
Purpose
The ISB BA assists the PA in assuring requirements completeness so that the project sponsor is in a
position to sign-off the System Requirements.
- 25 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
QA System Requirements and checks the
accepted System Requirements
documentation into Harvest
ISB Business Analyst (BA)
Methodology Process Activities
1. The ISB BA checks-out the Requirements and any System Analysis & Design development
estimates using Harvest Check Out For Browse process.
2. The BA provides consultative services to the PA by:
¾ reviewing the System Requirements to ensure completeness
¾ approving the System Requirements for sign-off by the project sponsor.
3. When the BA receives the signed-off System Requirements, the BA, would:
¾ record in the relative RFC package who signed off the Requirements and the sign-off
date
¾ if System Requirements have been previously checked into Harvest, check out the latest
version of the System Requirements documentation in Harvest using the Check Out
For Update process
¾ check in the approved System Requirements documentation into Harvest using the
Check In process
¾ approve the System Requirements using Harvest Approve Package process to
formally record the acceptance of the System Requirements.
6.2.17 Evaluate Analysis & Design Estimates / Development Priority (Program
Administrator (PA))
Purpose
The purpose of this process is for the PA to be able to:
¾ evaluate the estimate(s) for the development of the System Analysis and Design deliverables
¾ assess further development activities within context of the branch priorities
¾ arrive at a decision of either proceeding with the project or deferring development until some
future date.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Decides on project continuation
Assists the PA with the project continuation
decision
Program Administrator (PA)
ISB Business Analyst (BA)
- 26 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. The PA reviews the development estimate(s) for the System Analysis and Design deliverables
development in context of the branch priorities with assistance of the BA.
2. When the evaluation is complete, the PA prepares a decision and forwards it to the BA for
action.
6.2.18 Assist with Evaluating Analysis & Design Estimates/Development Priority
(ISB Business Analyst (BA))
Purpose
The ISB BA assists the PA with the decision regarding the next phase of the project within branch
priorities.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Assists the PA with the project continuation
decision
ISB Business Analyst (BA)
Methodology Process Activities
1. The BA provides consultative services to the PA in making the decision on whether to proceed
with the next phase or place the project ON HOLD until some future date.
2. When the BA receives the project decision from the PA, the BA would record the decision in the
relative RFC package using the Harvest Package Update function
3. If the decision were to put the project on HOLD, the BA would perform 6.2.19 Place Project ON
HOLD process.
6.2.19 Place Project on HOLD (ISB Business Analyst (BA))
Purpose
A project is placed in the On HOLD state until a decision is made to proceed with the development
effort or permanently close the project. The reason for this decision may be that either the time and/or
the cost estimate is prohibitive at evaluation time.
NOTE: The RFCs in this state are to be reviewed periodically by the BA and the PA, and a
determination made if the RFC should remain in the HOLD state, be re-activated or be placed into the
REJECT state (i.e. CLOSE the project).
- 27 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for placing a RFC On HOLD /
Re-activating a RFC On HOLD / placing a
RFC in the REJECT state (i.e. closing the
RFC)
Provides decisions regarding Projects On
Hold.
ISB Business Analyst (BA)
Program Administrator (PA)
Methodology Process Activities
1. If the System Requirements are not being developed, the BA would place the RFC package(s)
and any supporting documentation into a HOLD State using Harvest Hold Package process
with appropriate notation on the RFC form.
2. The BA reviews RFC packages in the HOLD State on a periodic basis, and in consultation with
the PA determine if any of them are to:
¾ remain in the HOLD state
¾ be re-activated by promoting the RFC Package(s) to the SYSTEM REQUIREMENTS
state using the Move Package process
¾ be placed into a REJECT state (i.e. CLOSE the project) using Harvest Reject Package
process.
3. If RFC Package(s) is/are to proceed to the next phase, the BA would determine if the System
Analysis & Design development is to be re-estimated, before proceeding to the next phase.
4. If a new estimate is required, then the BA would:
¾ move the package(s) into the SYSTEM REQUIREMENTS state using the Move
Package process
¾ when a new estimate is received and the decision is to proceed with the project, the BA
would perform 6.2.20 Promote to System Analysis & Design process.
5. If the original Analysis / Design estimate is still valid, the BA would perform 6.2.20 Promote to
System Analysis & Design process.
6.2.20 Promote to System Analysis & Design State (ISB Business Analyst (BA))
Purpose
The RFC is promoted from the System Requirements State to the System Analysis & Design state.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Promotes packages from System
Requirements to Systems Analysis state
ISB Business Analyst (BA)
- 28 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. If the decision by the Program Area is to proceed with the next phase of the project, the BA would
promote the RFC Package(s) to the SYSTEM ANALYSIS state using Harvest Promote function
with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer).
6.3 SYSTEM ANALYSIS & DESIGN PHASE
Purpose
In this phase, the logical data architecture and any cross-references for screen/report development
or data conversion are developed and detailed system functions are designed. The system design
is based on the System Requirements and provides system developers with a detailed system
programming “blueprint”. This includes:
¾ screen and report prototypes or layout designs which could include screen print-outs. NOTE:
There is no programming code at this stage of the SDLC. This occurs in the System
Development Phase.
¾ a cross-reference between the screen / report fields and the data architecture entity attributes
which are the data source to support display screens and reports or data repository for data
entry screens. This very important deliverable proves availability of data to support the
business information needs.
¾ if data conversion is required, a cross-reference between the existing database and the new
data architecture. In addition of identifying any missing data, this would also indicate the
method of synchronizing the two data environments during the conversion process.
Deliverables
Deliverable
Responsibility
New/Enhanced Logical Data Architecture
For Oracle based application, new/enhanced
logical data architecture in designated Oracle
Designer Work Area. For applications that
have not been converted to Oracle Designer,
then a logical architecture in whatever format
that is appropriate that could be stored in the
Harvest Repository.
New/Enhanced Screen Prototypes / Design
or Oracle based application, new/enhanced
Oracle Forms screen prototype(s) in the
Oracle Repository. For non-Oracle based
applications, new/enhanced screen
prototype(s) / layouts in the appropriate tool
that can be stored in the Harvest Repository.
External System
Developer or
ISB DA
External System
Developer or
ISB
PROGRAMMER
- 29 -
M = Mandatory
PD = Project
Dependent
PD
PD
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Deliverable
Responsibility
New/Enhanced Report Prototype(s) /
Design
For Oracle based application, new/enhanced
Oracle Forms report prototype(s) in the Oracle
Repository. For non-Oracle based
applications, new/enhanced report
prototype(s) / layouts in the appropriate tool
that can be stored in the Harvest Repository.
New/Enhanced “Data Architecture –
Screen/Report” Cross Reference
This maps new/enhanced data architecture to
the screen / report fields.
New/Enhanced Database Specifications/
Requirements
Specifies any new/special database related
requirements.
New/Enhanced System Program
Modules/Functions Design/Specifications
Specifies / describes the algorithms and
processes that capture/process data and/or
produce defined information
Data Conversion Cross Reference
This maps the existing data structure to the
new/enhanced data architecture.
Data Conversion Strategy
Based on the Data Conversion Cross
Reference and any relative meetings/JAD
sessions, this describes the data conversion
requirements and methods of converting
existing data into the new/enhanced data
architecture.
Temporary “Data Conversion” Database
Architecture
This architecture is developed in the case
where a temporary architecture is required to
capture additional data to support the
new/enhanced data architecture.
Intermediate Data Conversion Cross
Reference-Specification
This maps the existing data structure to the
Temporary “Data Conversion” Database
Architecture and identifies what additional data
would be required to complete the temporary
database structure.
External System
Developer or
ISB Programmer
M = Mandatory
PD = Project
Dependent
PD
External System
Developer or
ISB DA
PD
External System
Developer or
ISB DBA
PD
External System
Developer or
ISB
PROGRAMMER
M
External System
Developer or
ISB DA
External System
Developer or
ISB DA
PD
External System
Developer or
ISB DA
PD
External System
Developer or
ISB DA
PD
- 30 -
PD
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Deliverable
Responsibility
Development Time / Cost Estimate
The estimates are for development of the
program code and if required the physical
database
Data Architecture QA Form
This is a communication tool used to
communicate Data Architecture QA Review
results to other Internal Data Architects or
External System Developers
¾ Special Database Tables Requirements
¾ Special Database Performance
Requirements
¾ Special Database Access Requirements
(including Security Matrix if applicable)
Any or all components are to be developed as
required.
System Development Decision
External System
Developer, or
ISB DBA, ISB
Programmer
M = Mandatory
PD = Project
Dependent
PD
ISB DA
PD
External System
Developer, or
ISB DBA
PD
PA
PD
6.3.1 Develop System Design & Data Architecture AND Estimate Development
Effort (External System Developer)
Purpose
The External System Developers analyze/ design/ develop system components (e.g. logical data
architecture, prototype screens/reports, screens/reports – data architecture cross reference, system
function design) and prepare a System Development estimate if required.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
External System Developers
P
Designated Program Area
Representatives
S
S
ISB Business Analyst (BA)
ISB Data Administrator (DA)
Responsible for performing the Analysis &
Design
Responsible for providing “Person –
Machine” Interface requirements to the
design team
Provide consultation in the design effort
Provide consultation regarding data
architecture components
- 31 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
NOTE:
1. Refer to the following documents for the Ministry’s Oracle Design/Development
Standards/Guidelines:
¾ Oracle Designer 10g Standards and Guidelines
¾ Designer Repository Management Guide
2. In the case of Oracle based systems, the External System Developers would develop
the data architecture and/or any Oracle Objects in an Oracle Designer environment.
Methodology Process Activities
1. The External System Developers would check out the System Requirements documentation
using Harvest Check Out For Browse process.
2. If the RFC was for a system enhancement / modification, any available non-Oracle system
design components would be checked-out using the Check Out For Update process.
3. Based on the System Requirements, JAD sessions (as required) with Designated Program Area
Representatives, ISB BA and ISB DA and the scope of the project, the External System
Developers would develop/enhance all or some of the following deliverables:
¾ new/enhanced logical data architecture
¾ new/enhanced screen prototype(s) / layouts
¾ new/enhanced report prototype(s) / layouts
¾ new/enhanced “Data Architecture – Screen/Report” Cross Reference
¾ new/enhanced Database specifications/requirements
¾ new/enhanced system program modules/functions design/specifications.
NOTE: For Oracle based deliverable(s) the external design team would perform the design in
the ISB Designer repository.
4. When the design has been completed, the External System Developers would check-in the
design documentation against the Harvest DOC Package using the Check In process with
(NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External System
Developer).
5. When notified of a QA Report Check-in, the external design team would:
¾ check out using Harvest Check Out For Update process
¾ perform the design/design updates and/or responses to ISB QA “Queries/ Comments”
documents
¾ check in the update components against the Harvest Doc Package using the Check In
process with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer,
External System Developer).
6. Step #5 would be repeated until the designed component(s) is/are approved.
7. When the ISB QA Reviews are complete, if requested, the External System developers would
prepare an estimate for developing the designed components and forward the estimates to the
ISB BA for evaluation.
- 32 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.3.2 Review/Sign-off “User-System Interface” Design (Program Administrator
(PA))
Purpose
The Program Area Users review the User-System Interface design (e.g. screens, reports) through
working sessions/JADs with the System analysis & Design participants. When the reviews have been
completed and the design approved by the designated Program Area Participants, the Program Area
project sponsor and other designated parties sign-off the design documents. This officially sets the
system development scope of the project.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for obtaining System Design
Acceptance
Assists the PA in obtaining System Design
Acceptance
Assists the PA in obtaining System Design
Acceptance
Program Administrator (PA)
S
ISB Business Analyst (BA)
S
ISB Programmer
Methodology Process Activities
NOTE: Oracle objects such as ERDs, Data Dictionary and Function/Data usage matrices should be
included in the Appendix of the design document.
1. Obtain a copy of the System Design documentation using the Check Out For Browse
process.
2. With user, ISB BA and ISB Programmer participation, review the System Design.
3. When the Users are satisfied with the User-System Interface Design, the Program Area project
sponsor and other designated parties sign-off the design that officially sets the system
development scope of the project.
6.3.3 Review “User-System Interface” Design (ISB Business Analyst (BA))
Purpose
The purpose of this process is to describe the ISB BA’s participation in reviewing the System Design
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Participates in the development and review
of the “User – System Interface” design
ISB Business Analyst (BA)
- 33 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
NOTE: Oracle objects such as ERDs, Data Dictionary and Function/Data usage matrices should be
included in the Appendix of the User-System Interface Design document.
1. If the PA has Harvest access, obtain a copy of the System Requirements documentation using
the Check Out For Browse process.
2. If the PA does not have Harvest access, obtain a copy of the System Requirements
documentation from the ISB BA.
3. With user participation review the System Design through sessions/JADs with either the
respective ISB Technical Team or the External System Developers (if it is to be developed by an
External vendor).
4. When the Users are satisfied with the System Design and the Program Area project sponsor
signs-off the System Design, the BA approves the User-System Interface Design using Harvest
Approve Package process with (NOTIFICATIONS: ISB Harvest Administrator, BA).
6.3.4 Develop OR QA/Approve Data Architecture (ISB Data Administrator (DA))
NOTE:
1. This process would not be performed if there were no data implications.
2. If there were data implications, then during either the QA Review or internal
development process, the DA would perform the functions in consultation with the
ISB DBA.
Purpose
This process identifies the development or QA review by the ISB DA of:
¾ a new/enhanced data architecture
¾ a new/enhanced “Data Architecture – Screen/Report” Cross Reference
¾ a new/enhanced Data Conversion Cross Reference and Data Conversion Strategy
¾ estimate for Physical Data Architecture Development
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Data Administrator (DA)
ISB Database Administrator (DBA)
External System Developers
Develops / Reviews Logical Data
Architectures
Assists the DA in a consulting capacity
Methodology Process Activities
Data Architecture to be done by an External Vendor
1. Based on notification by the External System Developers, the ISB DA would:
¾ perform a QA review of the new/enhanced logical data architecture in either Oracle
Designer, a non-Oracle based relational architecture or any other data structure
provided by the External System Developer(s)
¾ perform a QA review of the new/enhanced “Data Architecture/Database –
Screen/Report” Cross Reference(s)
- 34 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
2.
3.
4.
5.
¾ perform a QA review of the relative data conversion Data Conversion Cross Reference
and Data Conversion Strategy.
If there were questions, comments or modification requests based on the review the ISB DA
would:
¾ prepare a Data Architecture QA Form
¾ record the Data Architecture QA Form ID number and date in the Data Analysis text field
in the Systems Analysis tab in the relative RFC Package form in Harvest
¾ check in the new/updated Data Architecture QA Form against the Harvest DOC Package
using Harvest Check In process with (NOTIFICATIONS: ISB DA, ISB DBA,
designated ISB Programmer, External System Developer).
If the identified modifications require system requirements enhancements, the ISB DA would
Demote the Release Package(s) to the Systems Requirements state using Harvest Demote
process with (NOTIFICATIONS: ISB BA).
If there were additional questions, comments or modification requests based on the review the
ISB DA would:
¾ check-out updated QA Review Form using Harvest Check Out For Update process
¾ perform a follow-up review and update the Data Architecture QA form
¾ check-in the update form against the Harvest DOC Package using the Check In
process with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer,
External System Developer).
Step #4 would be repeated until the ISB DA is satisfied with the designed architecture. When
this stage is reached, the DA would approve the RFC package(s) using Harvest Approve
Package process with (NOTIFICATIONS: ISB Harvest Administrator, BA).
Data Architecture to be done by ISB DA
1. If the analysis and design is to be done by the ISB DA, depending on the scope of the project,
the DA would:
¾ develop a new/enhanced logical data architecture in either Oracle Designer, a nonOracle based relational architecture or any other data structure appropriate for the
application
¾ if the new/enhanced “Data Architecture/Database – Screen/Report” Cross Reference(s)
is to be developed by an ISB PROGRAMMER, then the ISB DA would review the Cross
Reference. If for some reason the ISB PROGRAMMER is unable to develop the
new/enhanced “Data Architecture/Database – Screen/Report” Cross Reference(s), then
the ISB DA would perform this activity.
¾ if required, develop a relative data conversion Data Conversion Cross Reference and
Data Conversion Strategy
¾ with ISB DBA assistance, prepare an estimate for developing the Physical “Server” Data
Architecture
¾ check the non-Oracle components into Harvest using Harvest Check In process with
(NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External
System Developer).
¾ approve the RFC package(s) using Harvest Approve Package process with
(NOTIFICATIONS: ISB Harvest Administrator, BA).
- 35 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.3.5 Plan / Design Data Architecture For Data Conversion (ISB Data
Administrator (DA))
Purpose
If an application’s data architecture is being redeveloped because the application is being re-written,
then system implementation would normally include data conversion. To perform data conversion, a
data conversion strategy and possibly temporary data architecture may be required to complete the
missing data before it can be loaded into the new database.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Data Administrator (DA)
S
ISB Business Analyst (BA)
S
ISB Database Administrator (DBA)
P
External System Developers
Review / Develop Temporary Data
Conversion Architecture
Provides data conversion consulting from a
business perspective
Provides data conversion consulting from a
database perspective
If data conversion is to be done by External
System Developers, they would develop
Temporary Data Conversion Architecture
Methodology Process Activities
Data Conversion Planning to be done by External System Developers
1. Based on Harvest notification, the ISB DA reviews the Data Conversion strategy, design and
any cross references to ensure that existing data and any additional enhancements can be
converted into the new data architecture.
2. If there were any questions, comments or modification requests then the ISB DA would:
¾ prepare a Data Architecture QA Form
¾ record the Data Architecture QA Form ID number and date in the System Analysis &
Design tab in the relative RFC Package form in Harvest
¾ check the Data Architecture QA Form against the Harvest DOC Package using Harvest
Check In process with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB
Programmer, External System Developer).
3. If there were additional questions, comments or modification requests based on the review the
ISB DA would:
¾ check-out updated QA Review Form using Harvest Check Out For Update process
¾ perform a follow-up review and update the Data Architecture QA form
¾ check-in the update form against the Harvest Doc Package using the Check In process
with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External
System Developer).
4. Steps #3 would be repeated until the ISB DA is satisfied with the designed architecture. When
this stage is reached, the DA would approve the RFC package using Harvest Approve
Package process with (NOTIFICATIONS: ISB Harvest Administrator, BA).
- 36 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Data Conversion Planning to be done by ISB DA
1. The ISB DA prepares Data Conversion Cross Reference and the relative Data Conversion
Strategy and checks in the components using Harvest Check In process with
(NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External System
Developer).
2. If the Data Conversion Strategy indicates that conversion of old data and additional new data
requires a separate temporary database, the DA would:
¾ develop a Temporary “Data Conversion” Database Architecture, an Intermediate Data
Conversion Cross Reference-Specification which includes the Data Load Method
¾ check in the appropriate components (i.e. those that are not Oracle Designer based) into
Harvest using Harvest Check In process with (NOTIFICATIONS: ISB DA, ISB DBA,
designated ISB Programmer, External System Developer).
3. When all of the required components have been developed, the DA would approve the RFC
package using Harvest Approve Package process with (NOTIFICATIONS: ISB Harvest
Administrator, BA).
6.3.6 Develop System Design / Estimate Development Effort OR QA/Approve
System Design (ISB Programmer)
Purpose
The ISB Programmer designs program/system function(s) and prepares an estimate for the system
functions/programs development effort; or performs a QA review of the External Systems Developers
System Design.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Programmer
P
Designated Program Area
Representatives
S
S
ISB Business Analyst (BA)
ISB Data Administrator (DA)
S
S
ISB Database Administrator (DBA)
External System Developer
If Internal Design, responsible for
performing the Analysis & Design OR
if External System Development Design,
responsible for Design QA
Responsible for providing “Person –
Machine” Interface requirements to the
design team
Provide consultation in the design effort
Provide consultation regarding data
architecture components
As a Database Consultant
Methodology Process Activities
System Design to be done by External System Developer
1. Based on Harvest notification, the ISB Programmer would review the system design
documentation.
- 37 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
2. If the identified modifications require system requirements enhancements, the ISB Programmer
would Demote the Release Package(s) to the Systems Requirements state using Harvest
Demote process with (NOTIFICATIONS: ISB BA).
3. If there were any questions, comments or modification requests that were specific to the
deliverable submitted by the External System Developer, then the ISB PROGRAMMER would
notify the External System Developers of deficiencies in the design.
4. Steps #1 - #3 would be repeated until the designed components pass the review. When the QA
review is passed, the ISB PROGRAMMER would make any comments in the RFC package and
approve it using Harvest Approve Package process with (NOTIFICATIONS: ISB Harvest
Administrator, BA).
System Design to be done by ISB PROGRAMMER
1. If the application is being enhanced, the ISB Programmer would check-out the appropriate
documents out of Harvest using Harvest Check Out For Update process.
2. Based on the System Requirements, JAD sessions (as required) with Designated Program Area
Representatives, ISB BA and ISB DA and the scope of the project, the ISB Programmer would
develop/enhance all or some of the following deliverables:
¾ New/Enhanced Screen prototypes / design
¾ New/Enhanced Report prototype(s) / design
¾ New/enhanced “Data Architecture – Screen/Report” Cross Reference
¾ New/enhanced system program modules/functions design/specifications.
NOTE: For Oracle based deliverable(s) the ISB Programmer would perform the design in the
ISB Designer repository.
3. When the design has been completed, the ISB Programmer would check in the non-Oracle
components against the Harvest DOC Package using the Check In process with
(NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External System
Developer).
4. If required, the Programmer prepares a System Functions/Programs Development Estimate.
5. The Programmer approves the RFC package(s) using Harvest Approve Package process
with (NOTIFICATIONS: ISB Harvest Administrator, BA).
6.3.7 Develop Database Design / Estimate Development Effort OR QA/Approve
Design (ISB Database Administrator (DBA))
Purpose
This process describes any special database design requirements and identifies the need for
estimating the database development effort.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Database Administrator (DBA)
If internal development, responsible for
Database design or if Database design is by
External System Developers, then
responsible for QA/Approval of physical
database design
- 38 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
External System Developers
If database design is being done under
contract
Methodology Process Activities
Database Design to be done by External System Developers
1. Depending on requirements and project scope, the External System Developer prepares some
or all of the following design documentation depending on system requirements:
¾ Special Database Tables Requirements
¾ Special Database Performance Requirements
¾ Special Database Access Requirements (e.g. Oracle Database Roles)
2. The External System Developer checks in the deliverables using Harvest Check In process
with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External System
Developer).
3. The ISB DBA checks-out the documentation using Harvest Check Out For Browse process
and reviews the documentation.
4. If the identified modifications require system requirements enhancements, the ISB DBA would
Demote the Release Package(s) to the Systems Requirements state using Harvest Demote
process with (NOTIFICATIONS: ISB BA).
5. If there were any questions, comments or modification requests that were specific to the
deliverable submitted by the External System Developer, then:
¾ ISB DBA notifies the External System Developers of the required changes
¾ the External Developer checks out the affected deliverable(s) using Harvest Check Out
For Update process and makes the appropriate modifications
6. Steps #2 - #5 would be repeated until the requirements pass the review. When the QA review
is passed, the ISB DBA would approve the package using Harvest Approve Package process
with (NOTIFICATIONS: ISB Harvest Administrator, BA).
Database Design to be done by ISB DBA
1. Depending on requirements and project scope, the ISB DBA prepares some or all of the
following design documentation depending on system requirements:
¾ Special Database Tables Requirements
¾ Special Database Performance Requirements
¾ Special Database Access Requirements (e.g. Oracle Database Roles).
2. The ISB DBA then:
¾ prepares a Database Development Estimate (if required)
¾ checks-in the non-Oracle components into Harvest using Harvest Check In process
with (NOTIFICATIONS: ISB DA, ISB DBA, designated ISB Programmer, External
System Developer)
¾ approves the package using Harvest Approve Package process with
(NOTIFICATIONS: ISB Harvest Administrator, BA).
- 39 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.3.8 Assist With Data Conversion Planning / Design (ISB Database
Administrator (DBA))
Purpose
The ISB DBA assists with the Data Conversion Planning and Design.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Database Administrator (DBA)
Acts as consultant to the Data Conversion
Planning/Design team
Methodology Process Activities
1. If any pertinent design documentation has been checked into the Harvest repository, the ISB
DBA checks-out the documentation for perusal using Harvest Check Out For Browse
process.
2. The ISB DBA participates in data conversion meetings/sessions as a database consultant.
6.3.9 Evaluate System Development Estimates / Development Priority (Program
Administrator (PA))
NOTE: This process applies to new systems or major enhancements to a system.
Purpose
The Program Administrator with the Program Management and in consultation with the ISB BA review
the estimate(s) and decide if the project is to proceed to development and implementation or be placed
On HOLD.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for obtaining a System “Go /
No-Go” decision from Program Area
Management
Responsible for deciding on viability of
proceeding with system development
Assists the decision making process in a
consulting capacity
Program Administrator (PA)
P
Program Area Management
S
ISB Business Analyst (BA)
- 40 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. The PA checks-out the relative System Development Estimate documentation using Harvest
Check Out For Browse process and reviews it in consultation with the Program
management and ISB BA.
2. Based on the review, the PA prepares a decision document and forwards it to the ISB BA for
action.
6.3.10 Assist with Evaluating System Development Estimates/ Development
Priority (ISB Business Analyst (BA))
Purpose
The ISB BA receives system development estimates from either the External System Developers or
internal development team (i.e. ISB Programmers, ISB DBA) and assists the program area with the
estimate(s) review. Based on the program area decision, the ISB BA either promotes the project into
the Development State or places it on HOLD until a future decision is made whether to proceed with the
project or to permanently REJECT it.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Business Analyst (BA)
Responsible for acting in a consulting
capacity
Provides the ISB BA with direction regarding
project approval / rejection
Program Administrator (PA)
Methodology Process Activities
1. The ISB BA reviews the System Development estimates with the Program Management and the
PA.
2. If the project is to continue, the ISB BA arranges a meeting with the Change Management
Board to set development priorities and schedule development (i.e. perform 6.3.12 Review
Project Scope / Requirements and Schedule Development process).
3. If development is being deferred, the BA performs 6.3.11 Place Project ON HOLD process.
6.3.11 Place Project on HOLD (ISB Business Analyst (BA))
Purpose
A project is placed in the On HOLD state until a decision is made to proceed with the development
effort or permanently close the project. The reason for this decision may be that either the time and/or
the cost estimate is prohibitive at evaluation time.
NOTE: The RFCs in this state are to be reviewed periodically by the BA and the PA, and a
determination made if the RFC should remain in the HOLD state, be re-activated or be placed into the
REJECT state (i.e. CLOSE the project).
- 41 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for placing a RFC On HOLD /
Re-activating a RFC On HOLD / placing a
RFC in the REJECT state (i.e. closing the
RFC)
Provides decisions regarding Projects On
Hold.
ISB Business Analyst (BA)
Program Administrator (PA)
Methodology Process Activities
1. If the System is not being developed, the BA would place the RFC package(s) and any
supporting documentation into a HOLD State using Harvest Hold Package process with
appropriate notation on the RFC form.
2. The BA reviews RFC packages in the HOLD State on a periodic basis, and in consultation with
the PA determine if any of them are to:
¾ remain in the HOLD state
¾ be re-activated by promoting the RFC Package(s) to the SYSTEM REQUIREMENTS
state using the Move Package process
¾ be placed into a REJECT state (i.e. CLOSE the project) using Harvest Reject Package
process.
6.3.12 Review Project Scope/Requirements and Schedule Development (Change
Management Board (CMB))
The Change Management Board reviews all projects destined for development and based on the
availability of the development personnel decide whether to proceed with development or delay the
project until the required personnel are available for the Development Phase. If the project is to be
temporarily delayed, the BA would be requested to place it on “temporary” hold until it can be
rescheduled for development.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Change Management Board (CMB)
May consist of ISB Management, DBA,
Programmer(s), BA, and any other
interested parties. The Board is responsible
for scheduling development based on the
availability of technical personnel.
- 42 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. The CMB reviews all of the projects that require development and decides on the development
priority.
2. Based on the priority and development personnel availability, a combination of projects is then
either scheduled for development or a decision is to place the project into a “temporary” hold
state by the BA until the next review (i.e. 6.3.13 Place Project on TEMPORARY HOLD
process).
3. If the System Development is to proceed, the BA forwards the following notifications:
¾ notifies the ISB Harvest System Administrator to promote the project to the Development
state
¾ notifies the respective system development team members to proceed with System
Development.
6.3.13 Place Project on Temporary HOLD (ISB Business Analyst (BA))
Purpose
The BA places identified RFCs into a Temporary Hold Package State until the next meeting by the
Change Management Board.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Business Analyst (BA)
Responsible for placing projects into a
“Temporary Hold” state and re-activating
projects in “Temporary Hold”.
Methodology Process Activities
1. The BA would place the RFC package(s) and any supporting documentation into a HOLD State
using Harvest Hold Package process with appropriate notation on the RFC Package form and
notifies the PA of the CMB decision.
2. The BA reviews RFC packages in the temporary hold state on a frequent basis (including prior
to any CMB projects development review meeting), and in consultation with the CMB members
determine which packages are to:
¾ remain in the “Temporary” HOLD state
¾ proceed with development.
3. If RFC Package(s) is/are to proceed to the next phase, the BA would:
¾ advise the ISB Harvest System Administrator to promote the RFC(s) to the System
Development State (i.e. perform the 6.3.14 Promote to Development State process)
¾ advise the developers (External System Developers or Internal Development Team
depending on the decision on who would perform the development)
¾ notifies the PA that development of a project “On Temporary Hold” has been reactivated.
6.3.14 Promote to Development State (ISB Harvest System Administrator)
Purpose
The RFC is promoted from the System Analysis & Design State to the Development state.
- 43 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Harvest System Administrator
Responsible for promoting RFCs to the
Development Phase.
Methodology Process Activities
1. If the decision by the Change Control Board is to proceed with the next phase of the project and
all of the approvals have been made (ISB BA, ISB DA, ISB DBA and ISB Programmer) the ISB
Harvest System Administrator would promote the RFC Package Group to the Development
state using Harvest Promote process with (NOTIFICATIONS: ISB BA, designated ISB
Programmer, External System Developer).
6.4 DEVELOPMENT PHASE
Purpose
In this phase, the database, manual procedures, system functions (programs) and test plans are
developed. The system functions are also Unit Tested in this Phase. The Unit Test Plans are
based on the Detailed System Functions design. If data conversion is required from an existing
database, the temporary database and any supporting conversion programs are developed and the
temporary database is loaded with available data. If additional data is required, or data
discrepancies need to be corrected and there are no automated means that would satisfy business
requirements, then the Program Area would be responsible for the manual data entry process to
correct the deficiencies.
Deliverables
Deliverable
Oracle Server Model
Oracle Database
Temporary Data Conversion Database
System Functions (Programming Objects)
Responsibility
External System
Developer or
ISB DBA
External System
Developer or
ISB DBA
External System
Developer or
ISB DBA
External System
Developer or
ISB Programmer
- 44 -
M = Mandatory
PD = Project
Dependent
PD
PD
PD
M
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Deliverable
System Function Unit Test Plan (new /
enhancement)
System Function Unit Test Results
System Installation Guide
Temporary Data Conversion Functions
(Programming Objects)
This code is generally used once to convert
the data into a new data architecture.
Integration System Testing Plan (new /
enhancement
User Acceptance Test Plan (new /
enhancement)
Temporary Data Conversion System
Functions
User Procedures (new / enhancement)
Responsibility
External System
Developer or
ISB Programmer
External System
Developer or
ISB Programmer
External System
Developer or
ISB Programmer
External System
Developer or
ISB Programmer
M = Mandatory
PD = Project
Dependent
M
M
M
PD
External System
Developer or
ISB Programmer
PD
External System
Developer or
Program
Administrator
(PA) or ISB BA
External System
Developer or
ISB Programmer
External System
Developer or
Program
Administrator
(PA)
PD
PD
PD
6.4.1 Develop Database / System & Unit Test Functions (External System
Developer)
Purpose
This highlights the system development effort being performed by External System Developers.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
External System Developer
Responsible for developing/providing the
Database, System Functions, Unit and
Integrated System Test Plans and Unit Test
Results.
- 45 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
NOTE: Refer to the following documents for the Ministry’s Oracle Design/Development
Standards/Guidelines:
¾ Oracle Designer 10g Standards and Guidelines
¾ Designer Repository Management Guide
Methodology Process Activities
RFC System Development and System Unit Testing (SUT)
1. The Developers would check out the System Design documentation using Harvest Check Out
For Browse process.
2. If the development involves Oracle deliverables, the Developers would either “Export” the
required objects for development into their environment or arrange to perform development in
the designated Ministry’s Oracle Development work area.
3. If the project is an enhancement to an existing system the Developers would check out the
existing code, Unit and Integration System Testing Plans using Harvest Check Out For
Browse process.
4. If Unit Test Deficiencies have been identified, the Developers would check out the existing code
from the respective RFC using Harvest Check Out For Update process.
5. Based on the System Design, the Developers would:
¾ if required, regenerate the database (using the Server Model if it’s an Oracle based
development)
¾ if required, develop/update Unit Test plans and check them against the Harvest DOC
Package using the Check In process.
6. For each RFC, the Developer would:
¾ develop/update program functions/code
¾ Unit Test the functions, record the Unit Test Results and attach the Unit Test Results to
the respective RFCs using the Harvest “Attach” function
¾ check in the code pertaining to the respective RFC under development using the Check
In process.
7. Steps #4 - #6 would be repeated until the System Unit Tests have been approved which
completes the SUT QA Reviews.
8. The Developer creates a new or updates an existing Integration System Testing Plan and
checks it against the Harvest DOC Package using the Check In process.
9. The Developer creates new or updates existing System Installation Guide and checks it against
the Harvest DOC Package using the Check In process.
10. Perform 6.5.1 Move Development Objects into ISB Delivery Environment and 6.5.2
Perform Integrated System Test (IST) processes.
Integration System Testing (IST) And User Acceptance Testing (UAT) - System Development
and System Unit Testing (SUT)
1. If applicable, when notified by Harvest, the Developers would access the relative Deficiency
(DEF) Package(s) created in Harvest by UAT testers using Harvest Check Out For Browse
process.
2. Based on either Deficiency packages created during the UAT or Deficiency notifications
received by other communication methods, the External Developer would:
¾ ROLLBACK testing environment
¾ check out the existing code from the respective RFC using Harvest Check Out For
Update process.
3. For each RFC, the Developer would:
¾ develop/update program functions/code
- 46 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
¾ Unit Test the functions, record the Unit Test Results and attach the Unit Test Results to
the respective RFCs using the Harvest “Attach” function
¾ check in the code pertaining to the respective RFC under development using the Check
In process.
4. Respond to the comments/observation in the DEF Package(s) / deficiency notifications.
5. Perform 6.5.1 Move Development Objects into ISB Delivery Environment and 6.5.2
Perform Integrated System Test (IST) processes.
6. Steps #1 - #5 would be repeated until the IST and UAT have been approved.
6.4.2 QA User Procedures / User Acceptance Test Plan (Program Administrator
(PA))
Purpose
This process highlights the development or enhancement of detailed User Procedures and the User
Acceptance Test Plan.
Both of these deliverables are based on the System Requirements. The User Procedures may extend
beyond the requirements specification if the decision is to include manual procedures that extend
beyond those that are directly related to the automated processes. The Program Administrator has the
primary responsibility for the activities in this process.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for User Acceptance Test Plan
and User Procedures development.
Responsible for User Acceptance Test Plan
and User Procedures development (if being
developed externally)
Acts in a consulting capacity for User
Acceptance Test Plan and User Procedures
development.
Responsible for providing direction for User
Procedures development
Program Administrator (PA)
S
External System Developer
S
ISB Business Analyst (BA)
S
System User Community
Methodology Process Activities
1. With the assistance of the User Community and the ISB BA, review and approve the new or
enhanced User Procedures (developed by program personnel or External Procedure writers
under contract) and the User Acceptance Test Plan based on new or enhanced System
Requirements.
2. Submit the User Acceptance Test Plan to the ISB BA for inclusion in the Harvest repository.
This will be used for reference during the User Acceptance Test.
- 47 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.4.3 QA User Procedures / User Acceptance Test Plan (ISB Business Analyst
(BA))
Purpose
The ISB BA participates as a consultant in performing a QA review of the User Procedures and
especially the developed User Acceptance Test Plan.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Business Analyst (BA)
In a consulting capacity, assists with User
Procedures and UAT plan review.
Methodology Process Activities
1. If this is an enhancement to an existing system, the ISB BA would checkout existing User
Acceptance Test Plan documentation using Harvest Check Out For Update process and
forward it to the designated “User Acceptance Test Plan Developer” for update.
2. Participate in the review of the User Procedures and the User Acceptance Test Plan review.
3. Check against the Harvest DOC Package the new/updated User Acceptance Test Plan using
the Check In process.
6.4.4 Develop / Unit Test System Functions OR QA / Approve System Unit Test
(ISB Programmer)
Purpose
The ISB Programmer may be responsible for developing a new system / application enhancement or
perform basic Quality Assurance review of development done by External Systems Developers.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Programmer
Responsible for either system development
or system QA review depending on whether
the development is being done internally or
by External System Developers.
Methodology Process Activities
System Development to be done by External System Developers
1. Check Out the System Unit Test Results using Harvest Check Out For Browse process and
review the test results.
2. Check Out the System Installation Guide using Harvest Check Out For Browse process and
review the guide for completeness.
3. If the identified modifications require systems analysis and design enhancements, the ISB
Programmer would Demote the Release Package Group to the System Analysis & Design state
using Harvest Demote process with (NOTIFICATIONS: ISB BA, ISB DA, ISB DBA,
designated ISB Programmer, External System Developer).
- 48 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. If any other Deficiencies are noted, notify the External System Developers of the observed
errors.
5. Steps #1 - #3 are repeated until the no deficiencies are observed. The ISB Programmer would
then approve the RFC package using Harvest Approve Package process with
(NOTIFICATIONS: ISB Harvest Administrator, ISB DBA).
System Development to be done by ISB Programmer(s)
RFC System Development and System Unit Testing (SUT)
1. The Programmers would check out the System Design documentation using Harvest Check
Out For Browse process.
2. If the project is an enhancement to an existing system the Programmer would check out the
existing code, Unit and Integration System Testing Plans using Harvest Check Out For
Browse process.
3. Based on the System Design, the Programmer would:
¾ if required, regenerate the database (using the Server Model if it’s an Oracle based
development)
¾ if required, develop/update Unit Test plans and check them against the Harvest DOC
Package using the Check In process.
4. For each RFC, the Programmer would:
¾ develop/update program functions/code
¾ Unit Test the functions, record the Unit Test Results and attach the Unit Test Results to
the respective RFCs using the Harvest “Attach” function
¾ check in the code pertaining to the respective RFC under development using the Check
In process.
5. The Programmer creates a new or updates an existing Integration System Testing Plan and
checks it against the Harvest DOC Package using the Check In process.
6. The Programmer creates new or updates existing System Installation Guide and checks it
against the Harvest DOC Package using the Check In process.
7. Perform 6.5.5 Move System Objects into ISB Delivery Environment and 6.5.6 Perform / QA
/ Approve Integrated System Test processes.
Integration System Testing (IST) And User Acceptance Testing (UAT) - System Development
and System Unit Testing (SUT)
1. If applicable, when notified by Harvest, the Programmer would access the relative Deficiency
(DEF) Package(s) created in Harvest by UAT testers using Harvest Check Out For Browse
process.
2. Based on deficiencies identified during the IST or Deficiency packages created during the UAT,
the Programmer would:
¾ ROLLBACK testing environment
¾ check out the existing code from the respective RFC using Harvest Check Out For
Update process.
3. For each RFC, the Programmer would:
¾ develop/update program functions/code
¾ Unit Test the functions, record the Unit Test Results and attach the Unit Test Results to
the respective RFCs using the Harvest “Attach” function
¾ check in the code pertaining to the respective RFC under development using the Check
In process.
4. Respond to the comments/observation in the DEF Package(s).
- 49 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
5. Perform 6.5.5 Move System Objects into ISB Delivery Environment and 6.5.6 Perform / QA
/ Approve Integrated System Test processes.
6. Steps #1 - #5 would be repeated until the IST and UAT have been approved.
6.4.5 Develop & Implement Data Conversion Functions (ISB Programmer)
NOTE: This process is performed only if there is a need for automated processes to convert
existing data into new data architecture.
Purpose
This process describes the activities in designing and developing “One-time” system functions to
convert existing data into a new database structure.
Participants
Participant
Type
P = Primary
S = Supporting
P
P
Participant
Participant Role
If conversion development is to be done by
Ministry personnel.
If conversion development is to be done by
an External vendor and reviewed by ISB
Programmer
ISB Programmer
External System Developer
Methodology Process Activities
Data Conversion Development to be done by External System Developers
1. The External Developers perform the following:
¾ check-out the data conversion documentation using Harvest Check Out For Browse
process.
¾ develop and unit test the conversion functions
¾ for non-Oracle components, check them into Harvest using Harvest Check In process
¾ for Oracle components, the Developers perform the coding and Unit Testing in either the
vendor’s environment or the designated Ministry Oracle Development Work Area.
2. The ISB Programmer reviews the conversion process design and test results to ensure that the
functionality satisfies the conversion process based on available data.
Data Conversion Development to be done by ISB Programmer(s)
1. The Programmer(s) perform the following:
¾ check-out the data conversion documentation using Harvest Check Out For Browse
process.
¾ develop and unit test the conversion functions
¾ for non-Oracle components, check them into Harvest using Harvest Check In process
¾ for Oracle components, the coding and Unit Testing is performed in the designated
Ministry Oracle Development Work Area.
6.4.6 Develop OR QA/Approve Server Model / Database (ISB Database
Administrator (DBA))
NOTE: This process is performed only if there are data implications.
- 50 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Purpose
If the database is to be developed by External System Developers, then the DBA would QA the
database. If the database is being developed in-house, the DBA would be responsible for developing
the database on a supported platform. At the time of writing, this would be on an Oracle platform.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Database Administrator (DBA)
Responsible for database development or
QA review if database developed by
External System Developers.
Methodology Process Activities
Database Development to be done by External System Developers
1. After the database has been generated by the External Developers, the DBA would perform a
QA review of the constructed database to ensure that it can support the business information
needs as defined in the logical data architecture and highlighted in the System Requirements.
2. If the identified modifications require systems analysis and design enhancements, the ISB DBA
would Demote the Release Package Group to the System Analysis & Design state using
Harvest Demote process with (NOTIFICATIONS: ISB BA, ISB DA, ISB DBA, designated
ISB Programmer, External System Developer).
3. If the database does not pass the review, the DBA notifies the External System Developers of
any deficiencies.
4. Steps #1 - #3 would be performed until the database passes the QA review. When the review
is complete, the DBA would approve RFC package(s) using Harvest Approve Package
process with (NOTIFICATIONS: ISB Harvest Administrator, ISB DBA).
Database Development to be done by ISB DBA
1. Using the logical data architecture in Designer, the DBA would build the Server Model and
generate the physical database.
2. When the DBA is satisfied the database would support the data for the business information
needs, the DBA would approve the RFC Package(s) using Harvest Approve Package
process with (NOTIFICATIONS: ISB Harvest Administrator, ISB DBA).
6.4.7 Develop Temporary Data Conversion Database (ISB Database
Administrator (DBA))
NOTE: This process would be performed only if there was a need for a temporary database to
support data conversion in an Oracle environment.
Purpose
If the Conversion database is being developed internally, the ISB DBA creates a temporary database to
support data conversion.
- 51 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Database Administrator (DBA)
Responsible or creating a temporary data
conversion database.
Methodology Process Activities
1. Based on the logical data conversion architecture in Designer, the ISB DBA would forward
engineer the temporary data conversion database in the appropriate Oracle Work Area.
2. Record that the activity has been completed in the relative RFC Package by using a Harvest
function for this purpose.
6.4.8 Perform Manual Data Conversion (Designated Program Area Personnel)
NOTE: This process is to be performed only if there is a requirement for converting existing
data into a new database and there is no automated method of obtaining all of the required data
to support the new data architecture.
Purpose
This process highlights the requirement for manual data input to populate a new database with
incomplete existing data or to clean-up corrupted data in an existing data structure.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for manual data conversion
and/or data clean up.
Program Administrator (PA)
Methodology Process Activities
1. The PA would checkout the Data Conversion Design documentation using Harvest Check Out
For Browse process.
2. Based on the specifications defined in the Data Conversion Design and using whatever tools
are available for the process, the designated data entry personnel would enter / correct data in a
temporary data structure for loading into the production database.
6.4.9 Assign Release Number (ISB Harvest System Administrator)
Purpose
The ISB Harvest System Administrator assigns a Release Number to the “Release Package Group”
before promoting it to the Integration Test state.
- 52 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Harvest System Administrator
Responsible for assigning a Release
Number to the Release Package Group
Methodology Process Activities
1. When all of the approvals have been received and there are no other outstanding issues (e.g.
Temporary Data Conversion Database Development), the ISB Harvest System Administrator
would assign the next Release Number to the Release Package Group by changing its’ name
with the Release Number. This is done using a Harvest Administration function.
6.4.10 Promote to Integration System Test (ISB Harvest System Administrator)
Purpose
The ISB Harvest System Administrator promotes the RFC from the Development State to the
Integration Test state.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Harvest System Administrator
Responsible for promoting the Release
Package Group from the Development state
to the Integration Test state.
Methodology Process Activities
1. When all of the approvals have been received and there are no other outstanding issues (e.g.
Temporary Data Conversion Database Development), the ISB Harvest System Administrator
promotes the Release Package Group to the Integration System Testing state using Harvest
Promote process with (NOTIFICATIONS: ISB BA, ISB DBA, designated ISB Programmer,
External System Developer).
6.5 INTEGRATION SYSTEM TESTING (IST) PHASE
Purpose
In this phase, the individual system components are assembled into a total system and placed into
a specified ISB “Delivery Environment”. The reasons for this phase are:
¾ to ensure that if there are any missing components, this would be identified before User
Acceptance Testing
- 53 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
¾ the system functionality is tested according to an Integration System Testing test plan
based on the system design. This step ensures that system deficiencies are corrected
before the User Acceptance Test phase. This test could include a cursory test of the
human-machine interfaces (e.g. screen content and control features, screen navigation,
reports) by a designated Program Area representative.
Deliverables
Deliverable
Responsibility
Release Note
Some document topics would be:
¾ instructions for executing DB
Scripts / code
¾ what functions and database tables
are involved (i.e. System Functions
– Database Xref Matrix)
System Code
External System
Developer
Database Objects
User Defined Set (UDS)
This applies to Oracle Database Objects
Integrated System Test (IST) Results
Deficiency Notification
External System
Developer or
ISB Programmer
ISB DBA,
External System
Developer or
ISB Programmer
External System
Developer or
ISB Programmer
External System
Developer or
ISB Programmer
ISB DBA, BA,
Programmer
M = Mandatory
PD = Project
Dependent
PD
M
PD
PD
M
PD
6.5.1 Move Development Objects into ISB Delivery Environment (External
System Developer)
Purpose
The External System Developers move all the system components (including any Oracle Objects) into
specified ISB Delivery Environments.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for performing this process
External System Developer
- 54 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participant
Type
P = Primary
S = Supporting
S
Participant
Participant Role
ISB Database Administrator (DBA)
Assists the External System Developer as
required
Assists the External System Developer as
required
NOTE: Refer to the following documents for the Ministry’s Oracle Design/Development
Standards/Guidelines:
¾ Oracle Designer 10g Standards and Guidelines
¾ Designer Repository Management Guide
S
ISB Programmer
Methodology Process Activities
1. Obtain instructions and location from the ISB Programmer and/or ISB DBA into which “Delivery
Environment” the system deliverables are to be placed for Integration Testing.
2. Move the system components into the designated “Delivery” Environments.
3. If the system is Oracle based, the External Developer would create a User Defined Set (UDS).
4. Set-up the IST environment.
6.5.2 Perform Integrated System Test (IST) (External System Developer)
Purpose
If the system is totally developed by External System Developers, they would perform the Integrated
System Test based on a developed Test Plan and report the Test Results to the ISB Programmer and
ISB DBA if applicable.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
S
Participant
Participant Role
External System Developer
ISB Programmer
ISB Database Administrator (DBA) (if
required)
Performs the IST
Reviews IST Results
Reviews IST Results
Methodology Process Activities
1. The External System Developers would:
¾ check out the latest version of the IST Plan using Harvest Check Out For Browse
process
¾ perform the Integrated System Test
¾ record the test results and forward them to the ISB Programmer for review.
2. On notification of any deficiencies by either the ISB Programmer or the ISB BA (for Person –
System Interface Testing), the External System Developers would perform 6.4.1 Develop
Database / System & Unit Test Functions process.
3. Steps #1 - 2 are repeated until all IST deficiencies have been corrected.
- 55 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.5.3 Validate Screens/Reports During Integration Testing (Program
Administrator (PA))
NOTE: This process would be performed on an “as required” basis. It would be more critical in
the case of a major new system implementation.
Purpose
A designated Program Area tester may be assigned to perform an initial User – System Interface test to
ensure that the functions work according to the System Requirements. This initial pass is to reduce or
hopefully eliminate any User - System interface deficiencies before User Acceptance Testing.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Program Administrator (PA)
Primary Tester
In a consultative capacity to the PA
ISB Business Analyst (BA)
Methodology Process Activities
1. Based on the User-System Interface Design provided by the ISB BA, the Program Area Tester
would perform a cursory test of the Interface components (e.g. screens, reports).
2. Any deficiencies would be noted and forwarded to the ISB BA for action.
3. Steps #1 - #2 would be performed until the Tester is satisfied with the test results.
6.5.4 Assist Designated PA(s) With Integration Testing (ISB Business Analyst
(BA))
NOTE: This process would be performed on an “as required” basis. It would be more critical in
the case of a major new system implementation.
Purpose
This process highlights ISB BA participation in performance of the initial User – System Interface test
with a designated Program Area tester.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
In a consultative capacity
ISB Business Analyst (BA)
Methodology Process Activities
1. The ISB BA checks out the User-System Interface Design document using Harvest Check Out
For Browse process and provides a copy to the Program Area Tester for a cursory test of the
Interface components (e.g. screens, reports).
- 56 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
2. If the ISB BA receives identified deficiencies, the BA would notify the ISB Programmer and/or
External System Developers for system correction.
3. Steps #1 - #2 would be performed until the Tester is satisfied with the test results.
6.5.5 Move System Objects into ISB Delivery Environment (ISB Programmer)
Purpose
The Internal System Developers move all the system components into designated ISB Delivery
Environments.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Programmer
ISB Database Administrator (DBA)
Responsible for performing this process
Assists the ISB Programmer as required
Methodology Process Activities
1. The ISB Programmer(s) would move the system components (including any Oracle Objects)
into the designated ISB “Delivery Environment”.
2. If the system were Oracle based, the Programmer would create a User Defined Set (UDS).
3. Set-up the IST environment.
6.5.6 Perform / QA/Approve Integrated System Test (IST) (ISB Programmer)
Purpose
If External System Developers test the system, then the ISB Programmer would perform a QA Review
of the Integrated System Test Results. If the system were developed in-house, a designated
Programmer would perform the Integrated System Test and place the Test Results in the Harvest
repository by attaching them to the DOC Package.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for reviewing IST Results
Receives Deficiency notification if the IST is
performed by an external vendor
ISB Programmer
External System Developer
Methodology Process Activities
Integrated System Test to be done by External System Developers
1. Receive the IST Results from the External System Developers and attach them to the Release
DOC Package using the Harvest Attach function.
2. The programmer notifies the External Developers of any Deficiencies.
- 57 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
3. Steps #1 - #2 are repeated until all deficiencies have been corrected. The ISB Programmer
would then approve the Release Package Group using Harvest Approve Package process
with (NOTIFICATIONS: ISB Harvest Administrator, BA).
Integrated System Test to be done by ISB Programmer(s)
1. The Programmer(s) would checkout the Integration System Testing Plan using Harvest Check
Out For Browse process.
2. Based on the System Design, the Programmer(s) would:
¾ if the system is Oracle based, the Programmer would create a User Defined Set (UDS)
¾ set-up the IST environment
¾ a designated Programmer would perform the IST, attach the test results to the Release
DOC Package using the Harvest Attach function and notify the developer of any
deficiencies.
3. When testing has been completed, the Programmer approves the Release Package Group
using Harvest Approve Package process with (NOTIFICATIONS: ISB Harvest
Administrator, BA).
6.5.7 QA/Approve Integration System Testing (IST) (ISB Database Administrator
(DBA))
NOTE: This process is performed only if there are data implications.
Purpose
If External System Developers test the system, then the DBA would perform a QA Review of the
Integrated System Test Results to ensure that the database is functioning as designed. If the system
were developed in-house, the DBA (in a consultative capacity) would assist the ISB Programmer(s)
with the Integrated System Test.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
S
Participant
Participant Role
Performs IST QA
Performs IST if an internal developed
system
Performs IST of an external developed
system
ISB DBA
ISB Programmer
External System Developer
Methodology Process Activities
Integrated System Test to be done by External System Developers
1. Receive the IST Results from the External System Developers and attach them to the Release
DOC Package using the Harvest Attach function.
2. The DBA notifies the External Developers of any Deficiencies.
3. Steps #1 - #2 are repeated until all deficiencies have been corrected.
4. The ISB DBA approves the Release Package Group using Harvest Approve Package
process with (NOTIFICATIONS: ISB Harvest Administrator, BA).
- 58 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Integrated System Test to be done by ISB Programmer(s)
1. The ISB DBA assists the ISB Programmer(s) with correcting any deficiencies observed in the
database functionality during the Integrated System Testing.
2. Step #1 is repeated until all deficiencies have been corrected. The ISB DBA would then
approve the Release Package Group using Harvest Approve Package process with
(NOTIFICATIONS: ISB Harvest Administrator, BA).
6.5.8 Approve Integration System Test (IST) (ISB Business Analyst (BA))
Purpose
The approval indicates that from a business point of view, the system is ready for the full User
Acceptance Testing.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Approves the Release Package Group
ISB Business Analyst (BA)
Methodology Process Activities
1. The ISB BA approves the RFC package(s) through notification to the ISB Harvest
Administrator.
6.5.9 Set-up UAT System Environment (ISB Programmer)
Purpose
The ISB Programmer moves the system components into the User Acceptance Test Environment.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for setting-up system code in
the UAT environment.
ISB Programmer
Methodology Process Activities
1. The ISB Programmer prepares system components for User Acceptance Test and advises the
ISB Harvest System Administrator that the UAT Set-up activity has been completed.
6.5.10 Set-up UAT Oracle Environment (ISB Database Administrator (DBA))
NOTE: this process is performed only if there are data implications.
Purpose
The ISB DBA sets-up the Oracle User Acceptance Test Environment.
- 59 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Database Administrator (DBA)
Responsible for performing this process
Methodology Process Activities
1. Using the User Defined Set (UDS) created by External Developers or Internal Programmers, the
ISB DBA creates the relative Oracle System Configuration and moves it into the UAT
Environment.
2. Advises the ISB Harvest System Administrator that the Oracle UAT Set-up activity has been
completed.
6.5.11 Promote to User Acceptance Test (UAT) State (User Acceptance Testing
Phase)
Purpose
The ISB Harvest System Administrator promotes the Release Package Group from the Integrated
System Test (IST) State to the User Acceptance Test (UAT) state.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Harvest System Administrator
Responsible for the Promotion function
Methodology Process Activities
1. When all the approvals have been received as well as notifications regarding the UAT
Environments set-up, the ISB Harvest System Administrator would then promote the RFC
packages to the UAT state using Harvest Promote process with (NOTIFICATIONS: ISB DBA,
BA, Programmer, External System Developer).
6.6 USER ACCEPTANCE TESTING (UAT) PHASE
Purpose
In this phase, the system functionality is tested according to a User Acceptance Testing (UAT) test
plan based on the System Requirements. Designated Program Area representatives and possibly
the BA would perform the test. Any errors or deficiencies would be recorded in the Harvest
Deficiency (DEF) Packages. The system would be “rolled back” to an appropriate point in the
System Development Life Cycle and the developers would make the necessary changes to correct
the identified deficiencies. After the changes are made, the system would be re-tested until no
deficiencies are detected. If the test should identify a change, this would be recorded as a new
RFC for the next system release.
- 60 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Deliverables
Deliverable
Responsibility
User Testers,
ISB BA
User Testers,
ISB BA
Deficiency Package
RFC
M = Mandatory
PD = Project
Dependent
PD
PD
6.6.1 Conduct User Acceptance Test / Signoff System Acceptance (Program
Administrator (PA))
NOTE: This process would be performed on an “as required” basis. It would be more critical in
the case of a major new system implementation.
Purpose
Designated Program Area testers may be assigned to perform the User Acceptance Test to ensure that
the functions work according to the System Requirements.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Program Administrator (PA)
P
Designated Program Area Tester
S
ISB Business Analyst (BA)
Responsible for ensuring User Acceptance
Testing is done.
Responsible for performing User
Acceptance Test
In a consultative capacity
Methodology Process Activities
1. Based on the User Acceptance Test Plan provided by the ISB BA and the developed User
Procedures, the Program Area Testers would perform the User Acceptance Test of the system
functions and the procedures.
2. Any system deficiencies and/or new requirements would be noted and forwarded to the ISB BA
for recording in Harvest.
3. Steps #1 - #2 would be performed until no deficiencies are observed.
6.6.2 Participate In User Acceptance Test / APPROVE Production Implementation
(ISB Business Analyst (BA))
NOTE: This process would be performed on an “as required” basis. It would be more critical in
the case of a major new system implementation.
Purpose
The ISB BA would assist designated Program Area testers to perform the User Acceptance Testing to
ensure that the functions work according to the System Requirements.
- 61 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
In a consultative capacity
ISB Business Analyst (BA)
Methodology Process Activities
1. The ISB BA would check out the User Acceptance Test Plan using Harvest Check Out For
Browse process and provide it to the Program Area Testers who would perform User
Acceptance Test.
2. If any deficiencies are identified by the Program Area Tester, the ISB BA would:
¾ create Deficiency Packages in Development state using Harvest Create Deficiency
Package process with (NOTIFICATIONS: ISB Programmer, ISB DBA, ISB BA,
External System Developer)
¾ demote the Release Package Group to the Development state using Harvest Demote
process with (NOTIFICATIONS: ISB Programmer, ISB DBA, ISB BA, External
System Developer).
3. If any RFCs are raised, the ISB BA would perform 6.1.4 Create RFC process.
4. Steps #2 - #3 would be performed until the Testers are satisfied with the test results.
5. When the UAT is complete, the BA would approve the Release Package Group using Harvest
Approve Package process with (NOTIFICATIONS: ISB Harvest Administrator).
6.6.3 Promote to Implementation State (ISB Harvest System Administrator)
Purpose
The Release Package Group is promoted from the Integration Testing State to the Implementation
state.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Harvest System Administrator
Responsible for promoting Release
Package Group to the Implementation State
Methodology Process Activities
1. When all of the approvals have been received and there are no other outstanding issues (e.g.
Temporary Data Conversion Database Development), the ISB Harvest System Administrator
would then promote the Release Package Group to the Implementation state using Harvest
Promote process with (NOTIFICATIONS: ISB BA, ISB DBA, designated ISB Programmer).
- 62 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.7 IMPLEMENTATION PHASE
Purpose
In this phase, the system is placed into production.
Deliverables
Deliverable
Implemented System Components
(e.g. Program Code)
Generated / Updated Database objects
(i.e. Oracle System Configuration)
Harvest “Designer Package”
This applies only if there are Oracle Designer
Converted Data
Harvest - System Release Snapshot
This is deliverable is contained in the Harvest
Repository.
User Training
Responsibility
ISB Programmer
M = Mandatory
PD = Project
Dependent
M
ISB DBA
PD
ISB DBA
PD
ISB
Programmer,
DBA
ISB Harvest
System
Administrator
PD
Program
Administrator
(PA)
PD
M
6.7.1 Conduct / Participate In User Training (Program Administrator (PA))
NOTE: This process is to be performed on an “as required” basis.
Purpose
The need for user training in using system functions (especially if it is a new system or major
enhancements have been done to an existing system) is a critical for a successful system
implementation. This is the reason that this process is being highlighted as it is often overlooked or not
given the necessary resources for it’s’ completion.
NOTE: This process is performed only if there is a major system enhancement or an implementation of
a new system.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
P
Program Area System Users
Responsible for ensuring training is
provided to the system users.
Responsible for participating in the training
S
ISB BA
If required in a consultative capacity
Program Administrator (PA)
- 63 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Methodology Process Activities
1. Based on the User Procedures, the Program Administrator arranges for system educators to
train system users in the use of the system functions.
2. When the training has been completed to the satisfaction of the User area, the Program
Administrator advises the ISB BA that the system may be implemented into Production.
6.7.2 Conduct / Assist With User Training / Approve Implementation (ISB
Business Analyst (BA))
NOTE: This process is to be performed on an “as required” basis.
Purpose
The ISB BA may conduct / assist with the training activity on a project basis and approve system
implementation into production when advised by the users that they are ready for the new/enhanced
system.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Acts as a consultant to the System User
community and approves system
implementation into production.
ISB BA
Methodology Process Activities
1. The ISB BA may conduct or assist with the system training activity depending on the scope and
type of project.
2. When the ISB BA receives confirmation from the Program Administrator that the Program Area
is ready for the system, the BA would approve the Release Package Group using Harvest
Approve Package process with (NOTIFICATIONS: ISB Harvest Administrator).
6.7.3 Implement (Deploy) System (ISB Programmer)
Purpose
In this process, the ISB Programmer moves the tested system into the production.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
Responsible for deploying internally or
externally developed system code into the
Production Environment
ISB Programmer
- 64 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participant
Type
P = Primary
S = Supporting
S
Participant
Participant Role
External System Developers
If applicable, responsible for performing
system code deployment into the Production
Environment
Methodology Process Activities
1. If system developed by internal Programmer(s), the Programmer moves system components
into the production environment.
2. If system developed by External System Developers, the Programmer ensures that the system
components are moved into the appropriate production environment.
3. The Programmer approves the relative system release using Harvest Approve Package
process with (NOTIFICATIONS: ISB Harvest Administrator).
6.7.4 Assist With Data Conversion Into Production (ISB Programmer)
NOTE: This process is performed on an “as needed” basis.
Purpose
The ISB Programmer loads the database with converted date.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for loading converted data into
the Production Database
If applicable, may perform the converted
data load into the Production Database
ISB Programmer
External System Developers
Methodology Process Activities
1. Execute the developed software to load the new database with converted data.
2. Notify the ISB BA and ISB Harvest System Administrator that the data conversion has been
completed.
6.7.5 Implement Database In Production (ISB Database Administrator (DBA))
NOTE: This process would be performed only if there are any Oracle database implications.
Purpose
In this process, the ISB DBA moves the tested Oracle Objects into the production.
- 65 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
ISB Database Administrator (DBA)
Responsible for setting-up the database in
Production environment
If applicable, may set-up the database in the
Production environment
External System Developers
Methodology Process Activities
1. The Oracle Objects (including Configuration) are moved into the production environment.
6.7.6 Perform Data Conversion Into Production Database (ISB Database
Administrator (DBA))
NOTE: This process would be performed only if existing data is to be converted into the new
data architecture.
Purpose
If data conversion were required, the ISB DBA would perform the activities to complete this
implementation process.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
S
Participant
Participant Role
ISB Database Administrator (DBA)
ISB Programmer
External System Developers
Responsible for executing data conversion
functions
Assists the ISB DBA as required
Assists the ISB DBA as required
Methodology Process Activities
1. The DBA executes database functions and/or specific program code to convert existing data
into the new data architecture. Since this is a one-time process, the program functionality would
be discarded after a successful conversion.
- 66 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
6.7.7 Promote to Production State (ISB Harvest System Administrator)
Purpose
This purpose of this process is to highlight the promotion of the System Release Package Group from
the Implementation State to the Production state.
Participants
Participant
Type
P = Primary
S = Supporting
P
Participant
Participant Role
ISB Harvest System Administrator
Promotes the Release Package Group into
the Production State.
Methodology Process Activities
1. When all approvals and any required notifications have been received, the ISB Harvest System
Administrator would then promote the Release Package Group into the Production state using
Harvest Promote process with (NOTIFICATIONS: ISB BA, ISB DBA).
2. Take a System Release Snapshot using Harvest Take Snapshot process.
6.8 PRODUCTION PHASE
Purpose
This is a very important phase because this is where project history is recorded. It provides
valuable information such as what to repeat, what to avoid and where something could be improved
when developing or enhancing applications in the future. Too often this phase is bypassed and all
the valuable experience is lost.
Deliverables
Deliverable
User System Acceptance Signoff
Post Implementation Review Report
Responsibility
PA
BA
M = Mandatory
PD = Project
Dependent
M
PD
6.8.1 Sign-off System Acceptance (Program Administrator (PA))
Purpose
This is a major milestone in the Post System Implementation Phase as it states that the Program Area
has officially accepted delivery of the new System Release.
- 67 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Participants
Participant
Type
P = Primary
S = Supporting
P
S
S
Participant
Participant Role
Responsible for obtaining System Signoff
Provides System Signoff
Provides System Signoff (as required)
Program Administrator (PA)
Project Sponsor
Program Area Management
Methodology Process Activities
1. The authorized Program Area management sign-off on the System Release, which is an official
acceptance of the system.
2. The Program Administrator provides the ISB BA with a sign-off form, which advises the ISB that
the User area has formally accepted the system.
6.8.2 Conduct Post Implementation Review (ISB Business Analyst (BA))
NOTE: This process to be performed for major system enhancements or new systems.
Purpose
This process is initiated by the ISB BA to review the project and record events that were helpful or
detrimental during the project. This history is extremely valuable to ensure greater success with future
projects.
Participants
Participant
Type
P = Primary
S = Supporting
P
S
Participant
Participant Role
Responsible for conducting Post
Implementation Review and recording the
review results
Participate in Post Implementation Review
ISB Business Analyst (BA)
All Project Participants
Methodology Process Activities
1. Conduct a post implementation review meeting.
2. Document the findings and attach them to the “Release” Documents Package in Harvest.
- 68 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
APPENDIX A
A – 1 SCM Methodology Harvest Processes
A-1.1 Approve Package
Approve Package
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Expand the State node and then the Packages node to display all the packages
currently in that state.
3. Right-click on the Package you wish to approve and choose Processes | Approve
Package from the shortcut menu. The Approve Package dialog will appear.
4. Select Approve.
5. Click OK.
- 69 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A-1.2 Check In
Check In
A-1.2a Check In (Package Level)
NOTE - Use this Check In process if:
¾ You are on a PC and you want to check in new or previously checked out files against a
package; OR
¾ You are in VO and you want to check in a new file.
This Check In method is not recommended if you are checking in a file that you checked out
while in the VO environment.
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Expand the State node and then the Packages node to display all the packages
currently in that State.
3. Right-click on the package you want to check items in against. Choose Processes |
Check In from the shortcut menu.
a. If you are checking in a new file:
i. You will see the following dialog box. Go to Section XXX Check In (State Level)
and follow steps 5 to 14.
- 70 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
b. If you currently have files checked out against the package
i. Files will be listed in the Files list box because they were associated with the
package when you checked them out. The following dialog box will appear:
ii. Choose Update and Release from the Mode drop-down list. The Update and
Release option creates a new version on the trunk and removes the lock from the
version so it can be checked out again later.
iii. Click OK.
4. Check the Harvest output log to confirm that the file(s) have been checked in. You can
also do this confirmation by expanding the Package node, clicking on the Versions node
(see diagram below) and checking that the files are there. NOTE: Each package has a
versions node, which will display all the files associated with that package.
A-1.2b Check In (State Level)
NOTE: - Use this Check In process if:
¾ You are on a PC or if you are in Virtual Office (VO) and you want to check new
versions of files into Harvest; OR
¾ You are in VO and you want to check in a file that was checked out while in the
VO environment
1. Make sure you are logged into the Harvest Workbench and you have set your Default
Context including the Project and State you wish to work in and your Context View Path
and Context Client Path.
2. Right-click on the State and choose Processes | Check In from the shortcut menu.
- 71 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
3. Confirm that the Mode is set to Update and Release. This will check the item or
version into the repository and, if the item was reserved by a package during a previous
check out, the reserved tag (red “r”) is removed from the item. The permission on the
client file is automatically set to read-only so that changes cannot be made to it until it is
checked out again.
Other available modes are:
a. Update and Keep—The item in the view is updated (or created) and the current
package keeps it reserved, and the file permissions unchanged, so that more
updates can be made.
b. Release Only—No check in is performed and the item is not updated, but the item is
no longer marked as reserved for the current package. The permission on the client
file is automatically set to read-only so that the file cannot be changed until it is
checked out again. Check In for Release Only does not require the local file system
file to exist. If the file does not exist on the local file system, you need to right-click
the reserved version and then choose the check in process.
4. Any updates made to an item are associated with the package selected in the Package
field. Select the Package you want to check in against by clicking the
button next to
the Package field (see screen shot below Step 2). This opens the Select a Package
dialog, which allows you to locate and select the package.
- 72 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
5. The From field lets you set where the client files are coming from. To use the client
directory path you set in your Default Context, check the “Use Context Client Path”
option. The file path will populate this field. If you want to change the path, leave the
option unchecked and click the
button next to the From field. This opens a Select a
Directory Path dialog that allows you to set the desired path.
6. The To field specifies the location in the destination view for the files being checked in.
To use the default view path you set in your Default Context, check the “Use Context
View Path” option. If you want to change the path, leave the option unchecked and click
the
button next to the To field. This opens the Select a Repository Item Path dialog
that allows you to set the desired path.
7. The Options field provides a variety of ways to check in files and filter the files being
checked in. Select one of the following:
a. Preserve Directory Structure checks in the selected files to repository view paths
with names that correspond to their client directory location, if these view paths
currently exist.
b. Preserve and Create Path Structure (default) checks in selected files to paths with
names that correspond to their client directory location, and creates any view paths
that do not currently exist.
c. All Files to Same View Path checks in all selected files to the same path in the
destination view, ignoring the client directory structure.
8. Verify the Filter field is set to New or Existing Items. This will allow check in of all
selected files, if they are reserved by the package or did not previously exist.
9. To select the items, click on the
button next to the Files section (see screen shot
below Step 2). This will display the following Find File window:
- 73 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
10. Click the
icon beside the Look in field and browse to the location of the file(s) you
want to check in.
11. Check the “Include subfolders” option if you want to browse directories below the one
you’re looking in.
12. Click Find Now to get a list of files. Select the file(s) you want to check in.
13. Click OK. You will be brought back to the previous screen where you can verify all the
items you are checking in and their respective locations in the repository.
14. Click OK.
15. Check the Harvest output log to confirm that the file(s) have been checked in. You can
also do this confirmation by expanding the Package node, clicking on the Versions node
(see diagram below) and checking that the files are there. NOTE: Each package has a
versions node which will display all the files associated with that package.
- 74 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A-1.3 Check Out For Browse
Check Out For Browse
1. Make sure you are logged into the Harvest Workbench and you have selected the Project and
State you wish to work in.
2. Expand the State node.
3. Expand the Data View node and navigate to the location of the items you want to check out.
4. Select the item(s) you want to check out. Right-click on the selected item(s) and choose
Processes | Checkout for Browse.
- 75 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
5. You will see the Check Out for Browse dialog. Confirm the Mode is set to Browse.
6. Verify the Option field is set to be Preserve and Create Directory Structure. This will
create a mirror image of the directory structure where the item resides within the repository on
your local file system.
- 76 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
7. The From field is already set for you since you started the Check Out from the Data View
node.
8. The To field lets you set the file system path you want to check items out to. If you wish to
use the file path you set in your Default Context when you first logged in, click the check box
beside Use Context Client Path. If you want to check out to a different location, click on the
folder icon beside the To field and browse to the desired location.
9. Click OK.
A-1.4 Check Out For Update
Check Out For Update
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Expand the Packages node to display all the packages currently in that state.
3. All changes to items must be associated with a package. As a package moves through
the lifecycle it brings the associated changes with it. Right-click on the desired package
and choose Processes | Check Out for Update. You will see the screen below.
- 77 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. Confirm that the Mode is set to Update.
5. Verify the Option field is set to be Preserve and Create Directory Structure. This will
create a mirror image of the directory structure where the item resides within the
repository on your local file system.
6. Ensure that the package you are working on is shown in the Package field. If it is not,
click the button next to the field to locate and select it.
7. The From field lets you set the repository path you want to check items from within
Harvest. If you want to use the view path you set in your Default Context when you first
logged in, click the check box beside Use Context View Path. If you wish to check out
from a different repository location, click on the folder icon beside the From field and set
to the desired location.
8. The To field lets you set the file system path you want to check items out to. If you wish
to use the file path you set in your Default Context when you first logged in, click the
check box beside Use Context Client Path. If you wish to check out to a different
location, click on the folder icon beside the To field and set to the desired location.
9. You now need to select the items you want to check out. Click on the
icon (see
screen shot above step 4) to the right of the Versions section of the dialog. This will
launch the Select Version window as shown below.
- 78 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
10. From this Window be sure to select the Recursive check box, then click the Find button.
This will display all the items in the View Path. By default all the items on the list will be
selected – to deselect the ones you don’t want to check out simply hold the control key
and click on the item.
11. Click the OK button. This will bring you back to the Check Out for Update dialog box.
Verify these are the files you want to check out and then click OK.
12. On the data tree, expand the Package you are working on (by clicking on the
beside
the package) then click on Versions. Here you can see the items you have checked
out. Notice the red “r” tag – this indicates that the items are now reserved in Harvest
and you need to check them in or release them before anyone else can check them out.
A-1.5 Create Deficiency Package
Create Deficiency Package
If deficiencies are noted with respect to a particular RFC, these deficiencies are recorded and tracked
through a Deficiency (DEF) package.
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project you wish to work in.
2. Select the User Acceptance Testing state. (Note: This is the only state in which you can
create the Deficiency package.)
3. Right-click on the state and choose Processes | Create Deficiency Package from the
shortcut menu. This will open the Create Deficiency Package dialog.
- 79 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. The DEF package name is generated automatically so you don’t need to type in a name.
5. Click OK and the DEF package will be created.
6. Fill out the Details tab of the associated Deficiency form.
A-1.6 Create Designer Package – removed from SCM Methodology on June 17, 2005
A-1.7 Create Document Package
Create Document Package
The Create Document Package process is used to create a package that contains all documents
pertaining to a Release. Since a release can made up of one or more individual packages, this allows
any documentation pertaining to the entire release to be tracked against a single package. The DOC
package is created by the CM Administrator at the same time the Release package group is created.
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project you wish to work in.
2. Select the System Requirements state. (Note: This is the only state in which you can
create the Document package.)
3. Right-click on the state and choose Processes | Create Document Package from the
shortcut menu. This will open the Create Document Package dialog.
- 80 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. The DOC package name is generated automatically so you don’t need to type in a
name.
5. Click OK and the DOC package will be created.
A-1.8 Create RFC (Harvest Workbench)
Create RFC (Harvest Workbench)
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project you wish to work in.
2. Select the Initiate State. (Note: You can only create regular RFC Packages in the
Initiate State.)
3. Right-click on the state and choose Processes | Create RFC (Harvest Workbench)
from the shortcut menu. This will open the Create RFC (Harvest Workbench) dialog.
4. The RFC name is generated automatically so you don’t need to type in a name.
- 81 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
5. Click OK.
6. The new RFC package is created and you will be left at the Details tab of the RFC form.
7. Fill in the fields on the Details tab of the form. If there is supporting documentation you
wish to attach to the form, please see Attachments below.
8. To save your changes, click OK.
Attachments:
Attachments should only include information that does not need to be versioned. If
versioning is required, please use the “Check In” process instead.
1. Click on the RFC to view its associated form.
2. Click on the
icon in the bottom left hand corner of the pane. The Form Attachments
dialog will be displayed.
3. To add a File:
a. Click on Add Files… You will see the Add Files as Form Attachments dialog.
b. Use the Look In field to browse to the location of the file(s) you wish to attach. Click
Find Now.
c. Select the file(s) you want to attach and click OK.
4. To add a URL:
a. Click on Add URL… You will see Add URL Reference dialog.
b. Type in the URL.
c. Click OK.
5. Verify the file(s) and/or URL(s) you have selected.
6. Click OK.
A-1.9 Create RFC (Web)
Create RFC (Web)
This method of raising an RFC is available to “non-Harvest” users such as Program
Administrators. This method is available through the following URL:
http://icw.harvestweb.cserv.gov.bc.ca
- 82 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
1. Enter your IDIR Userid, Password and Domain. The following screen will appear:
2. Fill in Sections 1 and 2 on the web form.
3. If you want to attach supporting documentation, use Section 3 on the web form - Add
Attachments. Click on the Browse button next to the Attachment 1 field to locate and
- 83 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
select a file. (Note: You can only attach one file at a time.) Repeat using the other
Attachment fields provided to add up to 5 attachments.
4. Once you are finished entering your data click on the Submit RFC button at the bottom
of the page.
5. You will see a confirmation screen indicating that your request has been successfully
submitted.
6. You can print this screen as a record of your request or note the RFC number as a
reference.
A-1.10 Demote
Demote
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Expand the State node and then the Packages node to display all the packages
currently in that state.
3. Right-click on the package you wish to demote and choose Processes | Demote from
the shortcuts menu. The Demote dialog will appear.
4. Click OK to confirm that you want to demote the package. Notice that the package no
longer exists in the current state.
- 84 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A-1.11 Hold Package
Hold Package
The Hold Package process is essentially a promote process to the Hold State.
1. Make sure you are logged into the Harvest Workbench and you have
selected the Project and State you wish to work in.
2. Expand the State node and then the Packages node to display all the
packages currently in that state.
3. Right-click on the package you wish to put on hold and choose Processes |
Hold Package from the shortcut menu. The Hold Package dialog will
appear.
4. Click OK to confirm that you want to put this package into a Hold state.
Notice that the package no longer exists in the current state.
A-1.12 Logon
Logon
From a PC:
1. Go to the Start menu. Go to Programs | Computer Associates | AllFusion | Harvest
CM | Workbench.
- 85 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
2. Enter the Username and password that you were given by the Administrator. Note:
User ID and Password are case-sensitive.
3. In the Broker field, enter the name of the machine where the Harvest broker is running
(nike) (Note: The broker name is case-sensitive.)
4. Enabling the Save Password check box will cause the password you entered to be
retained for your next Harvest session.
5. Click OK.
From Virtual Office (VO): - no longer applicable
1. Go to the CAWS folder on your VO desktop. Double-click the Harvest Workbench
icon.
2. Enter the Username and password you were given by the Administrator. Note: User ID
and Password are case-sensitive.
3. In the Broker field, enter the name of the machine where the Harvest broker is running
(BOGGLE). (Note: The broker name is case-sensitive.)
4. Enabling the Save Password check box will cause the password you entered to be
retained for your next Harvest session.
5. Click OK.
6. You may receive the message below where the remote agent shown is the name of the
last VO server you were logged onto.
7. Click No.
(Note: Each time you log onto VO it will connect you to the least busy server. Harvest
remembers the last server you were using. This message is its attempt to reconnect you
to the remote agent there.)
HARVEST CONTEXT
Once in the Workbench window, you can enter any Harvest project to which you have
access. However, first, you must establish the context of your activity, i.e. the project and
state where you plan to operate. Once a project is selected, you can select a specific state
in that project. Remember, Harvest is hierarchical. The top level is Harvest, then comes the
Project, then States in that project and Processes within the State.
- 86 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
1. Select the Project you are to work on.
2. Select the State you want to work on.
3. If you are going to perform a Check Out or a Check In process it is strongly
recommended you set the View Path and the Client Folder you will Check Out to or
Check In from. (Note: If you do not have an access to the particular state that you
selected, the View Path Icon will not be enabled.)
4. Click OK - You will see the following window (next page):
- 87 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A-1.13 Logoff
Logoff
To log off from your Harvest session, on the Harvest menu bar, click File | Exit.
A-1.14 Move Package
Move Package
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project you wish to work in.
2. Select the Hold state. (Note: This is the only state in which you can do a package
Move.)
3. Expand the Hold state node and the Packages node to display the packages currently in
that state.
4. Right-click on the Package you wish to remove from Hold and choose Processes |
Move to System Requirements from the shortcut menu. The Move to System
Requirements dialog will appear.
5. Confirm the package you want to remove from the Hold state.
6. Click OK.
- 88 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A-1.15 Promote
Promote
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Expand the State node and then the Packages node to display all the packages
currently in that state.
3. Right-click on the package you wish to promote and choose Processes | Promote from
the shortcut menu. The Promote dialog will appear.
4. Click OK to confirm that you want to promote the package. Notice that the package no
longer exists in the current state.
A-1.16 Reject Package
Reject Package
The Reject Package process is essentially a promote process to the Reject State.
1. Make sure you are logged into the Harvest Workbench and you have
selected the Project and State you wish to work in.
2. Expand the State node and then the Packages node to display all the
packages currently in that state.
3. Right-click on the package you wish to reject and choose Processes | Reject
Package from the shortcut menu. The Reject Package dialog will appear.
- 89 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. Click OK to confirm that you want to Reject the package. Notice that the
package no longer exists in the current state.
A-1.17 Take Snapshot
Take Snapshot
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Right-click on the State and choose Take Snapshot from the shortcut menu.
- 90 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
3. Enter a name for the snapshot in the View Name field. The name should be entered
according to the standards identified.
4. Select Type as required:
a. Latest Versions in Current Working View: captures the latest versions in the
current working view;
b. As of Modified Version Date: captures versions in the current working view during
a specified timeframe;
c. Snapshot View Plus Package(s): captures versions in a specified snapshot view
plus listed packages
5. To create a partial snapshot of the repository go to the Advanced tab, select Partial
Repository and select which parts of the repository you want to include.
6. Click OK.
7. Verify the snapshot by expanding the View Snapshot state, expanding the Data Views
node and you will see the snapshot you created.
- 91 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A - 2 Other Harvest Processes
A-2.1 List Differences Between Views
The compare views process generates a report showing the differences between any two
views, either snapshot or working, which exist in any project. You can select any or all of the
following options to generate the report:
¾
¾
¾
¾
Items that exist only in the first view
Items that exist only in the second view
Items that exist in both views but have different contents
Items that exist in both views but have identical contents
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project you wish to work in.
2. You can invoke the List Differences between Views process from a State node or from
a folder within a Data View:
a. Right-click on a State node; OR
b. Expand a State node, then expand the Data View node and the Working View.
Right-click on the desired folder in the working view.
The List Differences between Views dialog will be displayed and, depending on where
you started the process, will appear similar to the screen below.
- 92 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
3. The Project fields will be populated by your current project name.
4. The View fields initially contain the view contexts when the dialog was invoked. Clicking
the buttons next to the View fields, opens the Select a View dialog, which can be used to
select a view.
5. The Path fields initially contain the repository paths when the dialog was invoked.
Clicking the buttons next to the Path fields, opens the Select a Repository Item Path
dialog, which can be used to select a repository path.
6. The Show options allows you to specify the items you want to show in the Compare
View list. You can select one or more of the options:
¾ Items only in View1—This check box indicates that all items in View1 should be
listed.
¾ Items only in View2—This check box indicates that all items in View2 should be
listed.
¾ Common Items/Different Contents—This check box indicates that all items that
are common to View1 and View2 but have different contents should be listed.
¾ Common Items/Identical Contents—This check box indicates that all items that are
common to View1 and View2 and have identical contents should be listed.
¾ Recursive—The Recursive option works in conjunction with the Show options.
Normally, only items in the path specified in the View and Path fields and specified
by the Show criteria are displayed in the dialog list. When Recursive search is
chosen, Harvest searches all paths beneath the current path and displays the item
versions matching the other filtering criteria being used on the dialog.
- 93 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
7. Once View1 and/or View2 are selected and you have specified your item selection, click
the Compare View button to show a list of items meeting your criteria. The list of items
shows item descriptions shown in columns.
Note: Tagged versions (reserved, merged, removed) are listed as Changed (C) versions
in the scroll list, but they cannot be used with the detailed report or the Visual Difference
dialog. An error message is generated in the detailed report for each tagged item.
8. Selecting an item in the list enables the Visual Diff and Report buttons, allowing you to
execute a visual difference or generate a summary report. The Full Path field becomes
populated with the path of the item you selected. Select one of the following three
reports:
Compare View—Click the Compare View button to display the items that are unique to
one view or which have changes between the views.
Visual Diff—The Visual Diff button is enabled only if an item that is marked as modified
in the differences list box is selected. Choosing this button invokes the Visual Difference
window, which displays the two versions of the item side-by-side for easy comparison.
(See “Visual Difference” below for more detail.)
Report—Click the Report button to generate a summary Compare Views report, which
is sent to the output log. From the output log, it can be printed, copied, or saved.
9. Click Close when done.
Visual Difference
The Visual Difference dialog is invoked by clicking the Visual Diff button on the List
Differences between Views dialog and displays detailed, line-by-line differences between
two files. When the dialog is invoked, the versions being compared are displayed with
common blocks (lines the same in both versions) and conflict blocks. Because the List
Differences between Views process is read-only, changes cannot be made to the files.
Note: Only text files are viewable in this method.
The Visual Difference dialog has two panes: the Left pane and the Right pane. The title
bar displays the version names and their contexts.
¾ Left Pane—The Left pane contains the current project and view context when the
List Differences between Views dialog was invoked.
¾ Right Pane—The Right pane contains the comparison view that was selected by the
List Differences between Views process.
The panes are synchronized to ensure that the panes are displaying the same conflict
lines. Text characters beside lines and color codes indicate the status of the text.
¾
¾
¾
¾
¾
u indicates unchanged text. The color code is navy blue.
a indicates added text. The color code is yellow.
c indicates changed (conflict) text. The color code is green.
d indicates deleted text. The color code is gray.
If the imaginary symbol option is enabled, a circle indicates the lines that have been
added to align the synchronicity of the panes.
- 94 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
Status Bar—The status bar at the bottom of the dialog contains a Conflict meter. The
Conflict meter shows your current conflict location and the total number of conflicts. A
yellow horizontal bar indicates your location in the sequence of conflicts. The line
number of the current conflict is also displayed in the status bar.
Conflicting blocks are displayed side-by-side, and the portions of the item that are the
same for each version are displayed across the width of the dialog. The Conflicts menu
and a toolbar provide you with different options to navigate through the conflicts. The
navigation options found in the Conflicts menu are the same as those found on the
toolbar. The toolbar can be undocked and relocated on the dialog. The scroll bar on the
right side of the dialog can be used to move
up and down in the file.
You have the following options:
¾ First Conflict moves you to the first conflict.
¾ Previous Conflict moves you to the previous conflict.
¾ Next Conflict moves you to the next conflict.
¾ Last Conflict moves you to the last conflict.
The View menu lets you customize the dialog to show or hide the Visual Difference
Toolbar, Toolbar, Status Bar and Imaginary Symbols. You can double-click on the
pane's title bar to hide the title bar and increase your visible text space. Double-clicking
again on the top border of the pane restores the title bar.
A-2.2 List Version
The list version process allows you to generate reports about the changes made to items in
the current project. This process is useful for viewing changes made to an item to create
new versions on the trunk. The List Version report is automatically written to the output log,
from which it can be copied to the clipboard or saved to a text file.
1. Make sure you are logged into the Harvest Workbench and you have selected the
Project and State you wish to work in.
2. Navigate to the Data Views Node and drill down to the location where you want to invoke
the List Version Process.
3. Right-click on the item you want to view changes on. Select Processes | List Versions.
- 95 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
4. You will see the List Versions dialog. The “Report On” section will display the file you
selected. If you want to add a version to the list, click on the “Add…” button to open the
Find Version dialog. If you want to remove a version from this list, click the “Remove”
button.
- 96 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
5. Set Options as required:
(a) Show change description causes the change description provided during check in,
to be displayed.
(b) Show actual change causes the actual line-by-line changes between one version
and the next to be displayed.
The differences are displayed in your output window as instructions that can be used to
change the first version and make it the same as the second. These instructions contain
either: add a, delete d, or change c commands. A line number follows each command. A
less than sign (<) precedes lines from the first version. A greater than symbol (>) precedes
lines from the second version. A pair of line numbers separated by a comma represents a
range of lines; a single line number is used to represent a single line. Refer to the Computer
Associates’ AllFusion Harvest Change Manager User Guide for detailed examples.
A - 3 Standards
An Enterprise Lifecycle cannot be successful if its implementation is not accompanied by, the
implementation of development standards. These standards must include directory and file naming
standards, package naming standards as well as coding standards. Directory and file naming standards
are imperative to ensure that development of common components can be accomplished with minimum
confusion and effort.
A - 2.1 Releases
A release is the grouping of RFC’s. The Release moves as a whole through the lifecycle. The
Designer 10g Release Naming standards apply to SCM Releases (e.g. R01-01-01).
A - 2.2 Package Naming Standards
A – 2.2.1 RFC Package (Request For Change) Naming Standards
When a new package is created in Harvest in the Initiate State the name will be automatically created
with the following input mask: RFC-%N('FM099999') (e.g. RFC-000041). The numbers will
automatically increment.
A – 2.2.2 Deficiency Package Naming Standards
When a new package is created in Harvest in the Test State the name will be automatically created
with the following input mask: DEF-%N('FM099999') (e.g. DEF-000023). The numbers will
automatically increment. This package type is used to report deficiencies.
A – 2.2.3 Oracle Designer Package Naming Standards
This Package Type is created in Harvest in the Implementation State. This package is created to store
Oracle Designer Objects for each system release. The naming standard is based on the Oracle
Repository standard:
<APPLICATION SHORT NAME>_R<Release Number>
A package name example would be LGIS_R01.00.00.
- 97 -
Ministry of Community Services and Ministry of Tourism, Sport and the Arts
SCM Methodology Guide
Version 1.2
A – 2.2.4 Package Group Naming Standards
Package groups are used to manage Releases. When a release is initiated, the Harvest Administrator
will assign a temporary name. When the release has progressed to the end of the “Development”
state, the Package Group is assigned a permanent name based on a Release Number. The naming
standard is R00.00.00, where the 1st two digits are for major release, the 2nd two digits are for minor
release, and the 3rd two digits are for a patch release.
- 98 -