blue process

8/3/2019 Blue Process

1/49
http://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/POW%20Project%20Governance/Templates/Templates/Governance%20Cover%20Sheet.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/POW%20Project%20Governance/Templates/Templates/Governance%20Cover%20Sheet.dochttp://portal.sbic.co.za/documentation/Processes/POW%20Project%20Governance/Templates/Templates/Governance%20Cover%20Sheet.dochttp://portal.sbic.co.za/documentation/Processes/POW%20Project%20Governance/Templates/Templates/Governance%20Cover%20Sheet.dochttp://portal.sbic.co.za/documentation/Processes/POW%20Project%20Governance/Templates/Templates/Governance%20Cover%20Sheet.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/sites/eim/


2/49

BACK

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements

specificationProject

finalisation

Business need

defined

Problem area

understood

Business

requirements

collected and

documented

Architecturedesign of the

solutionspecified

Architecturemodels

produced

Business

features

identified,

categorised,

and prioritised

Detailed

development

plan

Each release is

a separate

Construction

stage

Hand-overto Production

Support

Performancetuning to meet SLA

requirements

Sign-off by sponsor wheSLA requirements met

SLA requirements

Each increment shouldnot exceed 1 month

Model for shape, list and plan, then iterate frequently and adjust accordingly

Governancecheckpoints

Analysis Conceptual Design

Build & test

Postimplementation

evaluation(PIE)

Compareagainst

BusinessCase

ReceptionDevelopoverallmod

el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

Implementrelease

Warrantysupport to

achieve SLAin LIVE

environment

Detailed design

specifications

documented

Completed

client-valued

functions

Functions

integrated into

system

Useracceptance

testing to

verify that

the solution

is ready for

deployment

Step1 Step 2 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11Step 3 Step 4 Step 12

Solution Development v1.2 process overview

Construction

Sign-off functionalrequirements

Sign-off design andsequence of delivery

Sign-off acceptance of allincrements in this release

Sign-offContract

Sign-offLIVE

Acceptance criteria

1stBusinesssign-off

Productionsupport

hand-over

Deploymentreadiness

reviewsign-off

2ndBusinesssign-off

PDDBusinesssign-off

3rdBusinesssign-off(UAT)

Deploymentverification

sign-off

Finalconformance

reviewsign-off

2nd

Strategy &architecture

reviewsign-off

1st


reviewsign-off

3rd


reviewsign-off

Design (Analysis & conceptual design)

Contract

between

Sponsor and

project team

for delivery of

solution

2


3/49

Contract for delivery of solution

FSS (high-level analysis index)

STAGE: Definition

Project kick-offmeeting

(Architecture)Project

questionnaire(Definition)

ConceptualContext model

Project definition

document (PDD)

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Acce

ptan

ce

testi

ng

Requirements


finalisation

Information

protectiondefinition

document

Submit PG20for approvalof next stage

Account Manager(AM) assigned to

project by GroupIT Architecture

PDDBusiness sign-off

1stStrategy& architecturereview sign-off

Background

Definition stage

project planning Compliance /BCP checklist

List of systemgoals

Common

business rules(initial)

Index to

businessfunctions

Business

walkthrough

PG10

3

Depl

oym

ent

&

warranty


el


Construction

Impact/Risk Compliance impact

Desig

n (Analysis & conceptual design)

Acceptance criteriaPlanning: WHAT

Develop test cases (section 5)

Define test phases

Requirements change management

PDD and attachments constitute the complete contract

Event ImpactManagement /

BDS review

Mandatory review if anybranch systems, training, orcommunication affected

List of actors(initial)

Iterate through PDD,attachments, and high

level analysis indexuntil complete

BACK

Non-functionalrequirements

(initial)
http://portal.sbic.co.za/sites/eim/http://portal.sbic.co.za/sites/eim/http://portal.sbic.co.za/sites/eim/http://portal.sbic.co.za/sites/eim/


4/49

Conceptualarchitecture models

FSS

STAGE: Design

System goals &features list(complete)

Non-functionalrequirements

(complete)

PhysicalContext model

Feature model

Request forinformation

(RFI)

Design stageproject planning

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements


finalisation

PG20

Revised service

level agreement(SLA)

4

ReceptionDeve

lopoverallmod

el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

List of actors(complete)


Construction

Optional

Account Manager

(AM) assigned toproject by GroupIT Architecture

Confirm

Projectquestionnaire

(Design)

Impact/Risk

Compliance /BCP checklist

Compliance impact


Test Documentation

Planning: WHO

Select test team (section 2)

Planning: WHAT


Define test phases


Planning: WHERE

Specify test environment (section 3)

Planning: WHEN

Test schedule (MSP plan)

Planning: HOW

Test tools (section 1)

Test techniques

MERCURY: Test planning procedure

MERCURY: Test execution

MERCURY: Defect management

Set up a workshop withIT Service Management

to define the SLA

BACK


5/49

Conceptual architecturemodels

FSS

Feature Model

(in progress)

Use casespecifications

Commonbusiness rules

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements


finalisation

STAGE: Design

1stBusiness sign-off

User interfacespecifications

Report layouts

5


el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

PG20


Construction

Deliverable from previousstep

Request for information (RFI)

Optional


Test Documentation

Planning: WHO


Planning: WHAT


Define test phases


Planning: WHERE


Planning: WHEN


Planning: HOW


Test techniques


MERCURY: Test execution MERCURY: Defect management

BACK


6/49

Conceptual architecture models

Feature model(in progress)

Logical

Data model & datadictionary

Conceptual

Execution model

Framework model

Conceptual

Walkthroughmodel

ConceptualSoftwareLayer model

ConceptualComponent model

Conceptual

Semantic datamodel

Informalsequence

diagrams

Test Documentation

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements

specification

Developoverallmod

el

Project

finalisation

STAGE: Design

Planning: WHO


Planning: WHAT


Define test phases


Planning: WHERE


Planning: WHEN


Planning: HOW


Test techniques



6

ReceptionAcceptan

ce

testi

ng

Depl

oym

ent

&

warranty

Informationprotection

design

document

PG20


Construction


BACK


7/49

Compliance & BCP

FSS

Detailed &prioritised

features List

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements


finalisation

STAGE: Design


Feature model(in progress)

LogicalData model & data

dictionary(in progress)

ConceptualExecution model

(in progress)

Framework model(in progress)

ConceptualWalkthrough

model(in progress)

Conceptual

Component model(in progress)

Conceptual

Semantic datamodel

(in progress)

Test Documentation

Planning: WHO


Planning: WHAT


Define test phases


Planning: WHERE


Planning: WHEN


Planning: HOW


Test techniques



Draft business

continuity planannexure

(BCP)

Compliance risk

controls

7


el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

System controls

ConceptualSoftware

Layer model

(in progress)

List of featureowners

PG20


Construction

Request forproposal (RFP)

(initial)

Optional

Deliverable from previousstep

Compliance / BCP checklist


BACK


8/49

FSS

Feature workqueue

Function pointcount (FPC)

estimate

Project riskassessment

(Hoskins)

Request forproposal (RFP)

(complete)

STAGE: Design

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements


finalisation

2ndBusiness sign-off

2ndStrategy& architecturereview sign-off

Test Documentation

Planning: WHO


Planning: WHAT


Define test phases


Planning: WHERE


Planning: WHEN


Planning: HOW


Test techniques



Submit PG30for approval

of next stage8


el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

PG20


Construction

Deliverables from previous steps Project questionnaire (Design) Information protection design document

Draft business continuity plan annexure (BCP)

Optional


The following models must be complete: Physical Context model Feature model Conceptual Software Layer model

Conceptual Component model Conceptual Semantic data model Conceptual Execution model Framework model Conceptual Walkthrough model Logical Data model & data dictionary

Optional


BACK

Check-in of project

artifacts

STAGE C i
http://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.doc


9/49

STAGE: Construction

TSS TestDocumentation

OperatorInstructions

Conversion

Considerations

User InterfaceSpecification

Report Layouts

InformationProtection

ConstructionDocument

Constructionstage project

planning

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Buildby

featu

re

Incre

ment

integr

ation

Requirements


finalisation

Physical architecture models

Physical


Execution model(in progress)

Walkthroughmodel

(in progress)

Semantic data

model(in progress)

Produceautomated test

scripts

Physical datastructures

Business dataReference dataConfiguration data

Physical datarequest sign-off

(internal)

Review test plans

(Who, What,Where, When,

How)

PG30

9


el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

Physical Software

Layer model(complete)

Program specificationsSequence diagrams

Class diagramsActivity diagramsContracts

Component model(complete)

List of classowners

ProjectQuestionnaire(Construction)

Step1 Step 2 Step 5 Step 6 Step 8 Step 9 Step 10 Step 11Step 3 Step 4 Step 12

Construction

Designby

featu

re

Step 7

Impact/Risk

Follow remainder ofData Architecture,

EDMC and ITISprocess

Account Manager(AM) assigned toproject by Group

IT Architecture

Confirm

Compliance /

BCP checklist

Compliance impact


BACK

Batch scheduling &dependencies

STAGE C t ti
http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/http://portal.sbic.co.za/sites/EDMC/standards/standards_and_procedures.htmhttp://portal.sbic.co.za/sites/EDMC/standards/standards_and_procedures.htmhttp://portal.sbic.co.za/sites/EDMC/standards/standards_and_procedures.htmhttp://itisnet.sbic.co.za/http://itisnet.sbic.co.za/http://itisnet.sbic.co.za/http://itisnet.sbic.co.za/http://itisnet.sbic.co.za/http://portal.sbic.co.za/sites/EDMC/standards/standards_and_procedures.htmhttp://portal.sbic.co.za/eiwweb/Enterprise%20Data%20Management%20Centre/Request%20Forms/


10/49

Constructedcode

(programlogic)

Updated status

in feature workqueue

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Incre

ment

integr

ation

Requirements


finalisation

STAGE: Construction

Test Documentation

Manage testing

Track defects


Physical


Execution model(in progress)

Walkthrough

model(in progress)

Semantic datamodel

(complete)

Execute tests

Unit testing

Unit test sign-off

(internal)

Codereview and QA

sign-off(internal)

Third party code review forpackage/turn key solutions

Review test plans(Who, What,

Where, When,

How)

10


el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

PG30


Construction

Buildby

featu

re

Step 8


BACK

STAGE C t ti
http://portal.sbic.co.za/documentation/standards/it%20standards/Program%20Code%20Inspection%20Standards.dochttp://portal.sbic.co.za/documentation/standards/it%20standards/Program%20Code%20Inspection%20Standards.dochttp://portal.sbic.co.za/documentation/standards/it%20standards/Program%20Code%20Inspection%20Standards.dochttp://portal.sbic.co.za/documentation/standards/it%20standards/Program%20Code%20Inspection%20Standards.dochttp://portal.sbic.co.za/documentation/standards/it%20standards/Program%20Code%20Inspection%20Standards.doc


11/49

Test Documentation

Baseline code

Definition

Defineproject

scope

Identify

goalsand

featur

es

Buildfeatures

list

Planby

featu

re

Designby

featu

re

Buildby

featu

re

Requirements


finalisation

Baseline test

cases & scripts

STAGE: Construction

Manage testing

Track defects

Execute testsIntegration testing

Stress testing

System integrationtest sign-off

(internal)


Execution model(complete)

Walkthrough

model(in progress)

Physical

Data model & datadictionary(complete)

Constructedcode

(program logic)

Prepare systemintegration testenvironment

SITenvironment sign-off

(internal)


Where, When,How)

11


el

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

PG30


Construction

Incre

ment

integr

ation

Step 9


BACK

STAGE C t ti


12/49

Compliance & BCP

Test Documentation

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

Productionhand-overdocuments

Readiness assessmentList of impacted areasConversion planImplementation planBack-out planSystem rollout plan

Finalised pro-activemonitoring strategy

STAGE: Construction

3rdBusiness sign-off

(UAT)

Deploymentreadiness review

sign-off

Physicalarchitecture models

Walkthroughmodel

(complete)

Manage testing

Track defects

Execute testsUser acceptancetesting

Prepare user

acceptance testenvironment

UATenvironment sign-off(internal)


BCP test

report


Where, When,

How)

Baseline code

12

Depl

oym

ent

&

warranty

ReceptionDevelopoverallmodel

PG30


Construction

Acce

ptan

ce

testi

ng

Step 10

Deliverable from previous step Risk register

Internal Audit will conduct an independentassessment of all high risk projects, or as requested

Finalised businessdocuments

Training Delivery(design & delivery)

Training manuals

Actual training completed

IT Service DeliveryBusiness support (helpdesk)

Banking RoutinesGroup reference guide(GRG)

Circulars, fan-outs, formsdesign


BACK

STAGE: Construction


13/49

Compliance & BCP

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Acce

ptan

ce

testi

ng

Depl

oym

ent &

warr

anty

Requirements


finalisation

STAGE: Construction

Test Documentation

Manage testingTrack defects

Deploymenttesting

Verify

operation in liveenvironment

Deploymentverification

sign-off

3rdStrategy& architecturereview sign-off

Final business

continuity planannexure

(BCP)

BCP testreport


13


Baseline code

PG30


Construction


The following models must be complete: Physical Context model Feature model Physical Software Layer model

Physical Component model Physical Semantic data model Physical Execution model Framework model Physical Walkthrough model Physical Data model & data dictionary Physical Data model & data dictionary

Deliverables from previous steps Project questionnaire (Construction) Information protection construction document

Check-in of projectartifacts

Productionmonitoring

Operator instructionsCallout instructionsActivate monitoring


BACK

All critical project artifacts must be signedoff prior to deployment of business solution

STAGE: Construction


14/49

Deliverables from previous steps Business case and/or feasibility study Project definition document (PDD) Functional system specification (FSS) Technical system specification (TSS)

TestDocumentation

Final servicelevel

agreement

(SLA)

Lessonslearned

CompletedPEP form

Function point

count (FPC)final

Analyse test resultsLessons learntPEP defect analysis

New baselineregression test pack

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integration

Requirements


finalisation

Knowledge

repository &patterns

STAGE: Construction

Productionsupport hand-over

Final conformancereview sign-off

Informationprotection

review

14


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

Submit PG90for projectcompletion

PG30


Construction


Deliverable from previous step Production monitoring

Critical projectdocuments

Set up a workshop with

IT Service Managementto define the SLA

BACK

STAGE: Definition
http://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.dochttp://../Documents%20and%20Settings/jbosch/Local%20Settings/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/8XUR0PYV/Templates/Checklists/Checklist%20-%20FPC%20pre-requisite.doc


15/49

Define the Contract (PDD, high-level analysis index, and attachments) between the Sponsor and the project team for the delivery of a business solution.

Entry CriteriaBusiness Case and/or feasibility study signed off by business owner and Strategy &Architecture. Business process models may have been defined. Buy vs. Builddecision has been taken.

TasksArchitecture assistance Project manager Required

Project manager must contact Group IT Architecture to have an Account Managerassigned to the project (assist with architectural issues). Cost billed to the project.

Form the analysis team Project management Required

This team should consist of business experts from the relevant domain, a userrepresentative, the lead architect and any other stakeholders. The team should

familiarise itself with the available documents and any process models, if present.

Define actors and scope Analysis team Required

The team identifies the actors & other systems that will interact with the proposedsystem. Actors can be customers, users, or external systems. The team starts byconsidering who the primary actors are in order to produce a preliminary list. The listcan be refined when further input becomes available or as the various goals areidentified.

Define high-level analysis index Analysis team Required

The team documents the background, list of business goals (initial), list of actors, list

of business functions, business walkthrough, common business rules, non-functional requirements (initial), and exclusions in the FSS. Together, these

constitute the high-level analysis index.

Complete project questionnaire Analysis team Required

The team must document replies to the Network and related questionnaires. This isused to determine the extent of impact the project will have upon the existingnetwork typology, information security, and continuity plans. Support areas will beinvolved in ro ortion to the erceived im act.

VerificationSelf assessment Analysis team Required

The team should review the list of primary actors to ensure completeness. The teamshould review the PDD and high-level analysis for completeness and correctness.

Outstanding issues must be noted.

Exit Criteria 1st Strategy & architecture review sign-off (context model, project questionnaire,Compliance & BCP checklist)

Event Impact Management / BDS review (mandatory if any branches will beimpacted by systems changes, communications, or training)

PDD business sign-off (High-level analysis index, PDD and all attachments [Projec

questionnaire, Context model, Compliance & BCP checklist, Information protectiondefinition document, and Acceptance criteria]) All preceding sign-off must be obtained

first.

DeliverablesPDD

FSS (high-level analysis index)

Project questionnaire (Network communication requirements, etc)

Compliance / BCP checklist Context Model (initial) and Actor list

TechniquesA technique that may be useful here is to use index cards to represent the actors in agroup session.

ToolsPreferred tool:Rational Rose Analyst Studio

Visio may be used for the Context Model

STAGE: Definition

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

PG10

15


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty


Construction


BACK

STAGE: Design


16/49

Define the business need and analyse the problem area. Finalise the system goals and translate into features.

Entry CriteriaCompletion of process step 1. Initial context model and list of primary actors that willengage the system. Initial business goals from high-level analysis index.

TasksFinalise Context Model Modelling team Required

Finalise the context model depicting the scope or boundary of the system required.All actors must be identified. All data flows must be identified and labelled.

Finalise system goals of actors Analysis team RequiredThe team considers the goals (or business objectives) each actor has with respectto the system. Revise the list of actors if some system goals are found that do notbelong to any of the actors identified.

Identify candidate features Analysis team Required

For each goal identified in the previous step, the team considers what features willfulfil the goal.

Initial prioritisation of features Analysis team Required

Begin by prioritising the goals which will then guide the prioritisation of the features.Use the MoSCoW prioritisation technique to aid in this task.

Define initial Feature Model Modelling team RequiredDefine an initial Feature Model. This will become the first cut for Use Case names.

Produce RFI Analysis team + Procurement Optional

Request for Information (RFI) should include a Context Model and list of systemgoals. It should refer to functional requirements only, not implementation specifics.

Complete project questionnaire Analysis team RequiredThe team must document replies to the Network and related questionnaires. This isused to determine the extent of impact the project will have upon the existingnetwork typology, information security, and continuity plans. Support areas will beinvolved in proportion to the perceived impact.

Revise current SLA Project manager Required

This is facilitated by IT Service Management. Review and revise the existing SLAbetween business and IT to include the new system. Ensure that all service levelsspecified in the PDD have been included.

VerificationReview trace ability Analysis team Required

The team should verify that each feature maps to at least one goal and that each goalmaps to at least one actor.

Review prioritisation Project stakeholders RequiredProject stakeholders, for example the sponsor and business owners, should review thprioritisation of features.

Exit CriteriaThe team must deliver a list of prioritised goals and features. Goals must be finalised, butfeatures may be reviewed in subsequent steps.

DeliverablesRevised SLA FSS (list of actors, goals and features, common non-functional requirements) Architecture Models document (Contect Model, initial Feature Model) RFI Test documentation (initial test plan) Acceptance criteria (high level test cases for business functions, and will be used bythe business for acceptance for the solution)

TechniquesFor MoSCoW prioritisation of features, apply one of Must Have, Should Have, CouldHave, or Would Have [BlueCore Toolkit].Use can be made of the index cards used in Step 1: Define project scope. Write thegoals on the backs of the cards.

ToolsPreferred tool:Rational Rose Analyst StudioVisio

STAGE: Design

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

PG20

16


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty


Construction


BACK

STAGE: Design


17/49

Collect and document all business requirements. Elaborate features (describing what is required, not how it must be done), deferring any design issues.

Entry CriteriaCompletion of process step 2. List of system goals and features defining thebusiness objectives of the system.

TasksForm feature sub-teams Project manager OptionalIn order to maximise progress, the analysis team may be divided into sub-teamsassigned to groups of use cases. The teams may be augmented by leaddevelopers.

Document use cases Analysis (sub-)team RequiredDefine use cases (who does what for what purpose or goal), providing the following:NameCharacteristics (description, pre-condition, end-condition, actor/s, trigger event)Business rulesMain success criteriaAlternate scenario/s

Test planning Test manager Required

The test manager starts planning the testing that will be conducted to validate the

solution:

Test planning: WHOSelect the teams who will complete the various testing phases. The following mustbe documented: Test team Support team (e.g. DBAs Network support) External team (e.g. Bankserve, MTN) Roles & responsibilities Skill levels Training requirements

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

STAGE: Design

17


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

Test planning: WHATDefine the testing phases for the project. The following are typical phases: Unit testing System integration testing (SIT) User acceptance testing (UAT) Performance monitoring External testing (e.g. Bankserve, MTN) Deployment verification PilotingFor each use case, the test team documents the test cases needed to fully test the us

case (negative testing also).

Test planning: WHEREThe test manager identifies and documents the environments where the variousphases of testing (identified above) will take place. The following must be documented Hardware requirements Software requirements Database requirements Disk space requirements Network requirements Security requirements Backup and recovery requirements Methods of creating test data Methods of checking results (e.g. reports to be printed, enquiries)

Set-up required (e.g. cards, accounts, pin numbers) Tools to be used Configuration management

Test planning: WHENThe test manager schedules testing as part of the overall MSP project plan. Key inputare the test phases, test cases and test resources allocated.

PG20


Construction


BACK

STAGE: Design


18/49

ToolsRational Rose Analyst Studio

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

STAGE: Design

18


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warranty

Test planning: HOWThe test manager identifies and documents the procedures that will be used duringthe various testing phases. The following procedures are available for Test Director: Requirements management procedure Test planning procedure Test execution procedure Defect management procedure

Define business requirements Analysis team Required

Document the user interface specifications and report layouts. Revise and expand

the common business rules and exclusions. Role play all use cases to identify anymissing or incomplete user interface/report requirements.

Log issues Analysis team Required

Record all issues in the Project Minutes, with due date, status, and responsibility.

VerificationInternal review Analysis team Required

The team should review all the requirements specifications for completeness andcorrectness. Outstanding issues must be noted.

Exit Criteria1st business sign-off (FSS and initial test plan)

DeliverablesFSS (Use case specifications, user interface specifications, report layouts,common business rules, exclusions) Feature Model (expanded) Test documentation (updated test plan) Acceptance criteria (high level test cases for business functions, and will be usedby the business for acceptance for the solution)

TechniquesNo specific techniques. Domain walkthroughs may aid understanding of the usecases.

PG20


Construction


Collect and document all business requirements. Elaborate features (describing what is required, not how it must be done), deferring any design issues.

BACK

STAGE: Design

BACK


19/49

Specify the architectural design of the business solution. Produce architecture models, which includes framework, layer, execution and data definitions. Apply design patternsduring domain modelling.

Entry CriteriaCompletion of process step 3. Functional requirements of the system defined andsigned-off. Test planning started. Features documented in Feature Model.

TasksForm modelling team Project manager Required

The modelling team should consist of the lead architect, user representative,

business expert and lead developers, or infrastructure engineers. An experienceddesign mentor, if available, should be included to counter inexperience.

Request assistance Project management Optional

Group Architecture may assist team with design. Group IT Support Services may

assist team to use ChangeManDS for source management and version control.


The test manager refines the plans for testing (see process step 3 for details) that

will be conducted to validate the solution:WHO (Select test team, roles & responsibilities, skill levels, training requirements)

WHAT (Develop test cases, define test phases, change management process)WHERE (Test environment/s, H/W, S/W, storage, network, security, backup, data)WHEN (Test schedule, MSP plan)

HOW (Test tools, test techniques, MERCURY tool set)

Develop domain model Modelling team Required

For software, build class diagrams, informal sequence diagrams and component

models using the available documents. The CRC technique may be useful here. Theteam may split up to tackle sub-domains and then consolidate the models.

Architecture principles from the features sets should be resolved here and Patterns tobe used should be identified. Initial execution models and network models may bedesigned for infrastructure projects.

Output design Modelling team Required

Design screen flows and layout, report layouts and initial file designs for batch.

Architectural models and standards Modelling team Required

The team begins architecture definition by applying the architecture patterns defined in

the BlueCore Toolkit and repository and reviewing architecture documentation for anyexisting frameworks.

VerificationModel validation Modelling team Required

The team can use techniques like scenario testing and walkthroughs to validate the

models produced.

Design review SigmaWorks Required

Group IT Architecture will facilitate internal review.

Exit CriteriaThe team must produce all deliverables of this step, ensuring that any issues raisedduring the process are added to the issue log.

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements

specification

Developoverallmodel

Project

finalisation

STAGE: Design

19

ReceptionAcceptan

ce

testi

ng

Depl

oym

ent

&

warranty

PG20


Construction


BACK

STAGE: Design

BACK


20/49

Deliverables Informal sequence diagrams for each distinct scenario

of component interaction


Test documentation (updated test plan)

Conceptual architecture models (in progress)

Patterns & Principles

TechniquesCRC Modelling [Ambler].

Modelling with archetypes [Coad].Apply architecture patterns [BlueCore], including Domain Independent Component

and Context Container.Scenario testing with CRC [Ambler].

Domain walkthroughs.TCO ProcurementCRC R [Bredenmeyer]

ToolsRational Rose Analyst Studio

Visio, until UML extension for Architecture description.

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements

specification

Developoverallmodel

Project

finalisation

STAGE: Design

20

ReceptionAcceptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

PG20


Construction


Specify the architectural design of the business solution. Produce architecture models, which includes framework, layer, execution and data definitions. Apply design patternsduring domain modelling.

BACK

STAGE: Design

BACK


21/49


The test manager refines the plans for testing (see process step 3 for details) that will conducted to validate the solution:WHO (Select test team, roles & responsibilities, skill levels, training requirements)WHAT (Develop test cases, define test phases, change management process)WHERE (Test environment/s, H/W, S/W, storage, network, security, backup, data)WHEN (Test schedule, MSP plan)HOW (Test tools, test techniques, MERCURY tool set)

VerificationSelf assessment Analysis team Required

The team should review the list of features for completeness. The priorities of thefeatures must be reviewed.

Exit CriteriaThe team must produce the detailed list of prioritised features and services, subject tothe approval of project stakeholders.

Deliverables Detailed and prioritised features list

Test documentation (updated test plan)

TechniquesApply Identify Features.For MoSCoW prioritisation [Stapelton], apply one of Must Have Feature, Should HaveFeature, Could Have Feature or Would Have Feature [BlueCore Toolkit].

ToolsRational Rose Analyst StudioCase Study research / referenceMERCURY test tools

Produce a detailed list of atomic business features (fragment all composite features so that development effort will not exceed 2 weeks). Estimate development effort andidentify inter-dependencies. Identify variable factors that could impact delivery. Project Sponsor must prioritise the relative business importance of all features.

Entry CriteriaCompletion of process step 4. The modelling team has completed the Develop

overall model process. All sign-offs have occurred.

TasksForm features list team Project manager Required

This team should consist of the project manager, lead architect, user representative,

business expert and lead developers.

Finalise features list Features list team Required

The informal list of features must be extended into a detailed list of features by

examining all available models. Features must be atomic whole business services,i.e. must deliver value to the end user, and must not exceed 2 weeks to construct.Name all features according to the convention, using business understandable

terminology. Features must be fully specified, i.e. owner, use case, user interface,contract (interface definition, pre & post conditions, state transformations, business

rules with all exception messages).

Prioritise features Features list team Required

Using the priorities assigned to the features during process step 2 as the startingpoint, re-apply the MoSCoW prioritisation technique to the detailed list. Identifydependencies between features, and those features with a high latent planningimpact (variable factors may have a considerable impact upon construction effort).

Define draft RFP Features list team + Procurement OptionalThis task only applies if a package solution is being considered for this project. TheRequest For Proposal should provide sufficient project and architecturaldocumentation (including any imposed frameworks, networks, interfaces, oroperational restrictions) for the vendor to respond with a detailed tender.

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

STAGE: Design

21


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

PG20


Construction


BACK

STAGE: Design

BACK


22/49

Produce a detailed development plan, specifying the increments and order in which features will be delivered. Each release must be a separate Construction stage. Thenumber of increments and releases will depend on the channel.

Entry CriteriaStep 5 must be completed (all features identified and the conceptual design foreach completed). Features must have been prioritised by the business.

TasksForm planning team Project manager RequiredThe planning team comprises the project manager, user representative, businessexpert, lead architect and lead developers.

Produce detailed construction plan Planning team RequiredThe planning team uses the detailed feature list, priorities, dependencies, estimated

effort, owners and resource availability to plan increments of 1-month duration.Each increment must deliver functionality that can be tested and approved as a unitwithout any dependence upon subsequent increments. Related increments aregrouped into releases based upon the dependency of features. Each release is aseparate Construction stage with a maximum duration of 7 months. A project mayhave more than one Construction stage, each delivering independent sections ofthe solution. The detailed construction plan must specify fixed end dates andresource responsibilities.

Appoint repository administrator Planning team Required (Software)The team should appoint someone to act as the ChangeManDS team repositoryadministrator who will be responsible for repository management.

Finalise RFP Features list team + Procurement OptionalThe Request For Proposal must define functional, architectural, security, andservice level requirements in sufficient detail for vendors to respond to our request.

Test planning Test manager RequiredThe test manager refines the plans for testing (see process step 3 for details) thatwill be conducted to validate the solution:WHO (Select test team, roles & responsibilities, skill levels, training requirements)WHAT (Develop test cases, define test phases, change management process)WHERE (Test environment/s, H/W, S/W, storage, network, security, backup, data)WHEN (Test schedule, MSP plan)HOW (Test tools, test techniques, MERCURY tool set)

VerificationAssess plan Planning team Required

The planning team should review the development schedule produced and involve an

other project stakeholders as needed.

Define implementation training requirements Planning team Required

The planning team should define the skills/competencies needed by the development

team. Training plans to be defined to address skills deficits.

Exit CriteriaThe planning team must produce a feature work queue and detailed project plan thathas the approval of the project stakeholders.

2nd business sign-off (RFP, development plan, final test plan)

2nd Strategy & architecture review sign-off (all architecture models, projectquestionnaire, Compliance & BCP checklist) Preceding sign-off must be obtained first

Deliverables Conceptual architecture models

Feature work queue

Final RFP ready for distribution to vendors

Function point count Project risk assessment

Test documentation (final test plan)

TechniquesApply PlanningGame [BlueCore].

ToolsRational Rose Analyst StudioMERCURY tool set

S G es g

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

22


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

PG20


Construction


BACK

STAGE: Construction

BACK


23/49

Produce detailed design specifications and refined/expanded architecture models for the feature/s (from feature work queue) designated for construction in this increment.Inspect detailed design specifications for completeness.

Entry CriteriaCompletion of process step 6. Plan by feature has been completed includingbusiness sign-off. Development environment must be in place. Team membersmust be available.

TasksAssemble feature team Feature owner Required

The feature owner identifies which classes are likely to be required for theimplementation of the feature. The feature team is then drawn from the class

owners. Domain experts may be necessary for detailed design of the feature andshould be included in the team.

Study or review documentation Feature team Optional

The team should review all information available relating to the feature underconsideration.

Produce detailed design Feature team RequiredUsing the architecture models and functional requirements produced earlier as astarting point, the team creates detailed program specifications (4 different formatsfor all environments) for the feature and updates the user interface design/reportlayouts if necessary. The architecture models must be updated under the guidanceof the lead architect. Physical database structures must be defined and submitted toData Architecture for approval - comply with lead time requirements.

Produce automated test scripts Test manager Required

The test manager produces test scripts (automated wherever possible) for the toolsused. Each test script has a pre-requisite state, test conditions, and expectedresults: MERCURY (Windows and web based functional testing tools)

Complete project questionnaire Analysis team RequiredThe team must document replies to the Network and related questionnaires. This isused to determine the extent of impact the project will have upon the existingnetwork typology, information security, and continuity plans. Support areas will beinvolved in proportion to the perceived impact.

Finalise test cases Test team Required

The test team finalises the test cases for the current feature by the end of its design.

VerificationDesign inspection Feature team Required

The team must review the detailed design specifications for completeness andcorrectness. Use external participants if necessary (including SigmaWorks).Outstanding issues must be noted.

Log issues Analysis team Required

Record all issues in the Project Minutes, with due date, status, and responsibility.

Exit CriteriaPhysical data model sign-off (internal by Data Architecture for creation of database

tables)

Deliverables TSS (user interface specifications, report layouts, conversion considerations,operator instructions, program specifications, batch scheduling, file design)

Architecture Models (all 9 models required - these will evolve with each increment

until complete) Test scripts (unit test, SIT test, stress test, UAT test)

Updated test documentation (test cases and test plan)


TechniquesThe CRC technique is also useful for detailed design [Ambler].

Modelling with archetypes [Coad].Apply design patterns (see [GOF94] and [Buschman96].

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

PG30

23


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty


Construction

Designby

feature

Step 7


C

STAGE: Construction

BACK


24/49

Implement design specifications (programs/classes/methods) for each feature. Perform unit test and code inspection to verify functional completeness and code quality.Check-in code changes into ChangeManDS once they have been validated.

Entry CriteriaCompletion of process step 7 for this increment. Detailed design for the feature/shas been completed.

TasksPrepare test environment Feature team Required

The test manager prepares and verifies the environment prior to commencement ofunit testing. This includes hardware, software, networking, security, backup, and

generation of test data. If a regression test pack is available, this would be used toverify that the baseline system functions before deploying any changes.

Check out classes Feature team Required (Software)

The team repository administrator must create an open edition of the project inChangeManDS and check out any objects (programs, classes, etc) that will bemodified during this increment.

Code unit tests Feature team Required

Class owners must create or extend the unit test suite for any classes they willcreate or modify. Wherever possible, build test scripts for an automated testing tool(e.g. Junit or Mercury suite). Each test scr ipt has a pre-requisite state, testconditions, and expected results.

Implement feature Feature team Required

Each developer implements functionality in support of the feature and/or service asspecified by the detailed design specifications.

Execute unit testing Feature team Required

This task should be run by the developer concurrently with Implement feature.Running unit tests frequently measures the progress being made and determinescompletion.

VerificationUnit test review Feature team Required

The unit test should be inspected to ascertain that sufficient coverage was achieved.

Unit test results should be verified.

Code inspection Feature team Required

The team should inspect all detailed infrastructure designs and code for quality andadherence to standards prior to check-in. The involvement of SigmaWorks may be

requested as part of the architectural services for construction.

Check in classes Feature team Required (Software)

Only after verification tasks are completed should class owners check in new/changed

classes into ChangeManDS. Update status in feature work queue.

Exit CriteriaUnit test environment sign-off (internal)

Unit test sign-off (internal)

DeliverablesUpdated status in the feature work queue

Constructed code (program logic) Expanded unit test scripts, reviewed/expanded test plans

Unit test results

Updated test documentation (test cases and test plan)

ToolsRational Rose Professional J

MS ProjectMERCURY test tools

ChangeManDS

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Incre

ment

integr

ation

Requirements


finalisation

24


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

TechniquesApply (refer to [BlueCore] and [Beck]):CodeUnitTestFirstYouArentGoingToNeedItOnceAndOnlyOnceDoTheSimplestThingThatCouldPossiblyWorkOneChangeAtaTimeApply language specific coding standards.

PG30


Construction

Buildby

feature

Step 8


STAGE: Construction

BACK


25/49

Entry CriteriaCompletion of process step 8 for this increment. All features that are part of theincrement have been implemented, unit tested, reviewed (internal and/or externalcode review) and checked into ChangeManDS. All SIT, and stress test cases mustbe defined.

TasksPrepare SIT environment Test manager RequiredThe test manager prepares and signs-off the environment prior to commencement

of increment integration testing. This includes the hardware, software, disk space,networking, security, backup& recovery, set-up (e.g. cards,accounts) andgeneration of test data. If a regression test pack is available, this would be used toverify that the baseline system functions before deploying any changes.

Execute SIT testing Test manager RequiredIntegration testing must be performed to ensure that components (infrastructure orsoftware) interoperate correctly. Integration test cases must be executed accordingto the test schedule. Regression testing must also be performed to ensure there isno loss of functionality. Review and expand test plans as necessary.

Execute stress testing Test manager RequiredExecute stress test cases to confirm the solution meets the service levels specifiedin the PDD. The SIT environment must closely resemble production for meaningfulresults. Review and expand test plans as necessary.

Track defects Test manager RequiredThe test team report defects (where actual does not match expected results) andthe test manager ensures that defects are fixed and re-tested. The test manageranalyses defect data and produces defect reports to inform the team &management of new defects and progress of defect repair.

VerificationManage testing Test manager RequiredSIT and stress testing must be signed-off as complete. If testing is ended before alltest cases have been successfully run, the test manager must indicate how muchtesting is left, and the risks of not completing. The test manager is responsible forwhen to stop testing, and should only do so when fully satisfied.

System integration test review Test manager RequiredThe system integration tests should be inspected to ascertain that sufficient codecoverage was achieved. System integration testing and stress testing results shouldbe independently verified.

Baseline code & test scripts Repository admin RequiredOnce all the code has been fully tested and the accepted by the users, it must bebaselined in ChangeManDS, along with the revised regression test suite.

Exit CriteriaSystem integration test environment sign-off (internal)System integration test sign-off (internal)

Deliverables Expanded SIT test scripts, reviewed/expanded test plans SIT test results:

Test cases - actual results (section 5 of test documentation) Defect reports (section 6 of test documentation) Test case matrix (section 7 of test documentation) Test coverage matrix (section 7 of test documentation) Defect status matrix (section 7 of test documentation) Open defect matrix (section 7 of test documentation)

Stress (performance) test approach and results (as above)

Baselined code Baselined test scripts

TechniquesApply Automated Testing, Regression Test [BlueCore].

ToolsRational Rose ProfessionalMERCURY test toolsSerena E-Changeman for baseline code.Visio for architecture updates

Complete integration testing and stress testing of all increment features to verify that the business solution is fully functional. On passing these tests, the code is baselined inpreparation for move into pre-production.Integration testing (execute all test cases to an acceptable success level to verify the functionality, integration, and security controls of the whole system)Stress testing (execute all test cases to an acceptable success level to verify the achievement of performance and service levels)

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Requirements


finalisation

25


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

PG30


Construction

Incre

ment

integr

ation

Step 9


STAGE: Construction

BACK


26/49

Complete user acceptance testing (UAT) of all increment features to demonstrate that that the agreed test cases have been executed to specification, the business solution isready for operational use, and the security controls are suitable for business purposes. Acceptance Criteria test cases will be used.

Entry CriteriaCompletion of process step 9 for this increment. SIT and stress test results musthave been internally reviewed and accepted by business and IT. UAT test casesmust be defined.

TasksPrepare UAT environment Test manager Required

The test manager prepares and verifies the environment (as similar as possible tothe LIVE environment) prior to commencement of user acceptance testing. This

includes hardware, software, networking, security, backup, and generation of testdata. If a regression test pack is available, this would be used to verify that thebaseline system functions before deploying any changes. Thereafter incrementfeatures are deployed.

Execute UAT Testing Test manager Required

The test team executes all UAT test cases - high priority test cases are run first.Execute SCP (Stress and Capacity Planning) tests for systems using the branchinfrastructure. Test BCP recovery procedures, documenting findings in the BCP testreport. Review and expand test plans as necessary.

Track Defects Test manager Required

The test team report defects and the test manager ensures that defects are fixed

and re-tested. The test manager analyses defect data and produces defect reportsto inform the team & management of new defects and progress of defect repair.

Prepare for deployment Project Manager Required

Produce production support hand-over documents for deployment of the systeminto the live environment: Readiness assessment List of impacted areas Data conversion plan Implementation plan and back-out plan System rollout plan (if system is to be piloted)

VerificationManage testing Test manager RequiredUAT must be signed-off as complete. If testing is ended before all test cases havebeen successfully run, the test manager must indicate how much testing is left, andthe risks of not completing. The test manager is responsible for when to stop testing,and should only do so when fully satisfied.

User acceptance test review Test manager Required

The user acceptance tests should be inspected to ascertain that sufficient codecoverage was achieved. Test results should be verified. Review all the test

documentation for completeness and correctness. Testing normally stops when alltests are successfully run (i.e. actual results match expected results). If testing stopsbefore all tests have been run, the outstanding testing & associated risk must bedocumented.

Exit CriteriaDeployment readiness review sign-off (SCP results, implementation readinessassessment, production support hand-over documents, Internal Audit review)

3rd Business sign-off (UAT test results) Preceding sign-off must be obtained first.

Deliverables

UAT test results (refer to process step 9 for details) BCP test report Expanded SIT test scripts, reviewed/expanded test plans Information Protection construction document Production hand-over documents

TechniquesTechniques to be applied in testing are boundary analysis and equivalencepartitioning.

ToolsMecury Test Director

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Requirements


finalisation

26

Depl

oym

ent

&

warr

anty


PG30


Construction

Acce

ptan

ce

testi

ng

Step 10


STAGE: Construction

BACK


27/49

Package all increments for this stage into a single release. Each channel must follow their own deployment procedures and standards. Support the business solution in theLIVE environment for the specified warranty period. Performance tune as necessary to achieve the specified SLA requirements.

Entry CriteriaCompletion of process step 10 for all increments in the is Construction stage.Implementation Plan reviewed and signed off by Production support. Channel-specific release criteria, standards and procedures reviewed.

TasksPackage the release Project Management Required

Project Manager to communicate the channel-specific information to the teammembers and ensure that all standards and procedures have been applied.Release to be packaged as per the channel requirements. Production support mustbe involved in this exercise.

Notify production managers Project Manager Required

Communicate planned release and impact to all affected production areas. Complywith imposed freeze periods. Ensure the change control is loaded in AZIM with thecorrect lead time. Talk to the planned release at the daily production changemeeting.

Verify deployment Project management Required

The project team must verify the operation of the increment in the live environment.

The deployment verification test cases are executed according to the test schedule.

Warranty support Project Manager Required

Support the release (complete or portion of solution) in the production environmentfor the period stipulated in the PDD (Project Definition Document) until the specifiedservice levels have been achieved to the satisfaction of the project sponsor. If thesystem does not operate as required, the team report defects and the projectmanager ensures that defects are fixed and re-tested. The project managerdocuments and communicates progress against plan.

VerificationAchieve service levels Project Management Required

The System must have executed in the LIVE environment according to the Warrantycriteria stipulated in the PDD. All service levels must have been achieved as specifiedAll known defects must have been corrected or accepted by the project sponsor.

Exit Criteria

3rd Strategy & architecture review sign-off (all architecture models, BCP testreport, BCP annexure/s, project questionnaire, Compliance & BCP checklist).

Deployment verification sign-off by business (post-implementation defects,operator instructions, callout instructions, business workarounds). Preceding sign-offmust be obtained first.

DeliverablesCallout instructions Operator instructions Business workarounds (where required)

ToolsMS WordSerena E-Changeman

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Acce

ptan

ceTe

sting

Depl

oym

ent &

warr

anty

Requirements


finalisation

27


PG30


Construction


STAGE: Construction

BACK


28/49

Hand-over business solution to Production Support. Finalise all deliverables, ensuring that they properly reflect the status of the implemented business solution. Identify anddocument learning experiences and patterns that could be applied to future projects.

Entry CriteriaDeployment of all functionality for this release into the LIVE environment. Warrantyperiod must have been completed, and system accepted by the project sponsor asdelivering the service levels specified in the PDD.

TasksDocument lessons learned Project management Optional

The project management team should produce a document detailing any lessons

learned over the course of the project that may serve to refine or improve theprocess. A pattern mining workshop can be run, facilitated by SigmaWorks ifnecessary, to identify patterns that can serve the rest of the enterprise in future

projects.

Finalise project documentation Entire team Required

All documentation produced during the course of the project must be completed and

checked into a document management system (Changeman DS). It must providean accurate reflection of the final implementation of the solution. This includesdocumentation to assist end users and facilitate integration of the new system into

the business processes.

Finalise SLA Project manager Required

This is facilitated by IT Service Management. Finalise draft SLA, applying changes

that are agreed by business and all affected IT support areas. Publish final SLA.

Analyse test results Test manager Required

The test manager reviews all tests executed, defects identified, and defectsresolved. A summarised report is produced of the lessons learnt and

recommendations for improvements. SIT and UAT defects must be recorded in thePEP form.

Hand over to production support Project management Required

Hand over all supporting documentation to the production support team. Conduct afinal communication session to close out on any outstanding actions related to the

release.

VerificationPublish deliverables Modelling team Required

The team must collect, review and package all documentation produced throughout

the project stages. Final documentation must to be checked into ChangeManDS andpublished on the Sigmaworks site within 1 week after closure of the project.

Exit CriteriaFinal conformance review sign-off (all critical project documents, analysis of test

results, lessons learnt, PEP form, final FPC, final SLA, finalised projectdocumentation)

Production support hand-over(production hand-over documents, all project

documentation) Preceding sign-off must be obtained first.

Deliverables

Finalised project documentation New baseline regression test pack Lessons learned, including review if Information Protection controls Completed PEP form (including Warranty period) Patterns Testing defect report

ToolsRational Rose Analyst StudioMS WordMS Project

Definition

Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integration

Requirements


finalisation

28


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

PG30


Construction


Requirements: Solution Development process

BACK
http://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.doc


29/49

DefinitionIncre

ment

integr

ation

Project

finalisation

User interfacespecifications

Reportlayouts

Conversionconsiderations

Operatorinstructions

Technicalsystem

specification(TSS)

Program specifications Class diagram Sequence diagram Activity diagram Contract

Batch scheduling &dependencies

Solution Developmentprocess

Functional system specification (FSS)

High-levelanalysis index

BackgroundBusinesswalkthroughList of systemgoalsList of actorsIndex to business

functions Commonbusiness rules

Use casespecifications

Commonbusiness

rules

User interface

specifications

Reportlayouts

System goals& features list

(final)

Non-functional

requirements

Detailed &prioritised

features list

Featurework

queue

Update status

in feature

work queue

29


Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

Step 9 Step 10 Step 11Step 4 Step 12

List of actors(final)

Construction

1stBusinesssign-off

2ndBusinesssign-off

3rdBusinesssign-off(UAT)


Translationfrom logical to

physical views

Defineprojectscope

Identify

goalsand

features

Designby

feature

Step1 Step 2 Step 7Requirements

specification

Step 3Buildfeatureslist

Planby

feature

Buildby

feature

Step 5 Step 6 Step 8

Requirements: Group IT Architecture & Data Architecture

BACK
http://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/TSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/TSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/TSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/TSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/FSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Feature%20work%20queue.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/FSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/TSS.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.doc


30/49

Definition

Project

finalisation

Architecture models

List of

feature

owners

List of

class

owners

Conceptual Execution model

Framework model

Conceptual Walkthrough model

Conceptual Software Layer model

Conceptual Semantic data model

Logical Data model Data dictionary

Physical Data model Data dictionary

Conceptual Component model

Group IT Architecture Data Architecture

30

Reception

Projectkick-offmeeting

(Architecture)

Businessimpact

assessmentdocument

Informal

sequence

diagrams

Step 12

Contextmodel

Conceptual architecture models Physical architecture models

Physical Software Layer model

Physical Component model

Physical Semantic data model

Physical Execution model

Physical Walkthrough model

Construction

Feature model

ConceptualContextmodel

PhysicalContextmodel

2nd


reviewsign-off

1st


reviewsign-off

3rd


reviewsign-off


Defineprojectscope

Identify

goalsand

features

Buildfeatureslist

Planby

feature

Designby

feature

Buildby

feature

Incre

ment

integr

ation

Acce

ptan

ce

testi

ng

Depl

oym

ent

&

warr

anty

Step1 Step 2 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Step 11Requirements

specification

Developoverallmodel

Step 3 Step 4

Requirements: Group IT Testing

BACK
http://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Architecture%20models.dochttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ExecutionModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_FrameworkModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_WalkthroughModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_LayerModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_LayerModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_SemanticDataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_DataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ComponentModel.pdfhttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Help/Contacts/Keyplayers%20contact%20list.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Architecture%20models.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Architecture%20models.dochttp://portal.sbic.co.za/documentation/Processes/Blue%20Process/Solution%20Development/Templates/Templates/Architecture%20models.dochttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_LayerModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ComponentModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_SemanticDataModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ExecutionModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_WalkthroughModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_FeatureModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ContextModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ContextModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ContextModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ContextModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ContextModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/ArchitectureWorksheets/ArchitectureWorksheets_ContextModel.pdfhttp://intranet.sbic.co.za/itssarch/SigmaWorks/Process/Archi