Design (Analysis & Conceptual Design) Construction Reception

Solution Development v1.
2 Consolidated process map

Process overview Core deliverables Support area deliverables Key player list
Procurement Group IT Support Services Group IT Testing
Data Architecture Group IT Service Management Group IT Architecture Event Impact Management
Project Management Programme Governance Compliance & BCP Group IT Security
Service Governance Group Solution Development process
Infrastructure
Implementation Services & Support
Solution Development
PG05
PG10
PG20
PG30
Investigation
Definition
Step1
Define project scope
Design (Analysis & conceptual design) Identif Deve y lop Step 3 Step 4 Step 5 Step 6 Step 2 goals over Build Plan Requirements and all featu by specification featur mod res featu es el list re
Detailed & prioritised features list
<<Steps repeated per increment>>

Desi Step gn 7 by featu re
Construction
Incre Step 9 ment integr ation Acce ptan Step 10 ce testi ng
Production hand-over documents Baseline code Finalised business documents
PG90
Step 8 Build
by featu re
Feasibility study and / or Business case Buy vs Build decision
Functional system specification (FSS) High-level analysis index Project Definition Document (PDD) Request for information (RFI)
Technical Update status Feature system in feature work queue specification work queue (TSS) Constructed code (Program logic)
Depl Stepoym 11 ent & warr anty

Production monitoring
Reception
Step 12
Project finalisation
Rollout
Lessons learned Completed PEP form Function point count (FPC) final Final service level agreement (SLA)
Request for proposal (RFP) Architecture models
Context model Business impact assessment document Information Revised protection service level definition agreement document (SLA)
Conceptual architecture models Information protection design document Project risk Information protection assessment construction (Hoskins) document
Physical architecture models
Project Project questionnaire questionnaire (Design) (Definition) Acceptance criteria

1st Strategy & architecture review sign-off EIM / BDS review 1st Business sign-off
Function Draft business Project point count questionnaire continuity plan (FPC) annexure (BCP) estimate (Construction)
BCP test report
Final business continuity plan annexure (BCP) Deployment Analyse test testing results
3rd Strategy & architecture review sign-off
Test planning (who, what, where, when & how) Automated Execute tests & Track Defects Test scripts Unit test, Integration test, Load test, Acceptance test 2nd Strategy & architecture review sign-off 2nd Business sign-off Deployment readiness review sign-off
Production support hand-over
3rd Business sign-off (UAT)
Period specified in PDD

Post implementation evaluation (PIE)
Final Deployment conformance verification review sign-off sign-off
PDD Business sign-off
Solution Development v1.2 process overview

Model for shape, list and plan, then iterate frequently and adjust accordingly
Definition
Step1
Contract between Sponsor and project team for delivery of solution
BACK

Construction
Incre Step 9 ment integr ation Acce ptan Step ce 10 testi ng Depl Stepoym 11 ent & warr anty
Reception
Step 12
Step 8 Build
by featu re
Each increment should not exceed 1 month

Business need defined Problem area understood Business requirements collected and documented Architecture design of the solution specified Architecture models produced Business Detailed features development identified, plan categorised, and prioritised Each release is Detailed design a separate specifications Construction documented stage
Build & test

Completed client-valued functions Functions integrated into system
Analysis
Conceptual Design
Acceptance criteria
User acceptance testing to verify that the solution is ready for deployment
Performance tuning to meet SLA requirements Sign-off by sponsor when SLA requirements met
Implement release
SLA requirements Sign-off Contract

1st Strategy & architecture review sign-off
PDD Business sign-off 1st Business sign-off
Warranty support to Hand-over achieve SLA to Production in LIVE Support environment
Sign-off functional requirements
Sign-off design and sequence of delivery

2nd Strategy & architecture review sign-off
2nd Business sign-off
Sign-off acceptance of all increments in this release
Sign-off LIVE
Governance checkpoints
Deployment readiness review sign-off 3rd Business sign-off (UAT)
Compare against Business Case

Post implementation evaluation (PIE) 2
STAGE: Definition
PG10
BACK
Definition
Step1
Project kick-off meeting (Architecture)

Construction
Reception
Step 12
Step 8 Build
by featu re
Definition stage project planning
Contract for delivery of solution

Project questionnaire (Definition) Impact/Risk Compliance / BCP checklist Compliance impact Information protection definition document
Account Manager (AM) assigned to project by Group IT Architecture
FSS (high-level analysis index)

Background
Conceptual Context model
Mandatory review if any branch systems, training, or communication affected Event Impact Management / BDS review
Business walkthrough
Acceptance criteria
Planning: WHAT Develop test cases (section 5) Define test phases Requirements change management
List of system goals Index to business functions
List of actors (initial) Common business rules (initial) Non-functional requirements (initial)
Iterate through PDD, attachments, and high level analysis index until complete
Project definition document (PDD)
Submit PG20 for approval of next stage
PDD and attachments constitute the complete contract

3
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Design stage project planning
FSS
List of actors (complete)
Conceptual architecture models

Physical Context model
Test Documentation
Planning: WHO Select test team (section 2) Planning: WHAT Develop test cases (section 5) Define test phases Requirements change management
Confirm Account Manager (AM) assigned to project by Group IT Architecture
System goals & features list (complete)
Feature model
Planning: WHERE Specify test environment (section 3)

Planning: WHEN Test schedule (MSP plan)
Project questionnaire (Design) Impact/Risk
Non-functional requirements (complete)
Revised service level agreement (SLA) Set up a workshop with IT Service Management to define the SLA
Planning: HOW Test tools (section 1) Test techniques MERCURY: Test planning procedure MERCURY: Test execution MERCURY: Defect management
Optional Compliance / BCP checklist Request for information (RFI)
Compliance impact
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
FSS
Common business rules User interface specifications

Feature Model (in progress)
Test Documentation
Use case specifications
Report layouts

Planning: WHEN Test schedule (MSP plan) Planning: HOW Test tools (section 1) Test techniques MERCURY: Test planning procedure MERCURY: Test execution MERCURY: Defect management
Optional
Deliverable from previous step

Request for information (RFI)
1st Business sign-off

5
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re

Information protection design document Feature model (in progress) Framework model
Test Documentation
Conceptual Software Layer model Conceptual Semantic data model Conceptual Walkthrough model Informal sequence diagrams
Conceptual Component model

Conceptual Execution model
Logical Data model & data dictionary
STAGE: Design
PG20
BACK
Definition
Step1
Optional Request for proposal (RFP) (initial)

Construction
Reception
Step 12
Step 8 Build
by featu re
FSS
Detailed & prioritised features List

List of feature owners
Test Documentation
Compliance & BCP Deliverable from previous step

Compliance / BCP checklist
System controls
Feature model (in progress) Conceptual Software Layer model (in progress) Conceptual Semantic data model (in progress) Conceptual Walkthrough model (in progress)
Framework model (in progress)

Conceptual Component model (in progress)

Conceptual Execution model (in progress) Logical Data model & data dictionary (in progress)
Compliance risk controls
Draft business continuity plan annexure (BCP)
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re

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
Check-in of project artifacts
FSS
Feature work queue
Test Documentation
Project risk assessment (Hoskins) Optional Function point count (FPC) estimate Optional Request for proposal (RFP) (complete)

Deliverables from previous steps

Project questionnaire (Design) Information protection design document Draft business continuity plan annexure (BCP) 2nd Strategy & architecture review sign-off 2nd Business sign-off Submit PG30 for approval of next stage
8
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Construction stage project planning Confirm Account Manager (AM) assigned to project by Group IT Architecture
TSS
User Interface Specification
Test Documentation
Produce automated test scripts

Physical Software Layer model (complete) Semantic data model (in progress) Component model (complete)
Report Layouts Review test plans (Who, What, Where, When, How)
Execution model (in progress)
Project Questionnaire (Construction) Impact/Risk
Conversion Considerations Program specifications Sequence diagrams Class diagrams Activity diagrams Contracts Batch scheduling & dependencies
Physical Data model & data dictionary Physical data structures Business data Reference data Configuration data
Walkthrough model (in progress)
Compliance / BCP checklist Compliance impact
Operator Instructions
List of class owners
Information Protection Construction Document
Physical data request sign-off (internal)
Follow remainder of Data Architecture, EDMC and ITIS process
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Physical architecture models Test Documentation

Review test plans (Who, What, Where, When, How) Constructed code (program logic) Semantic data model (complete) Physical Data model & data dictionary Execution model (in progress)
Execute tests Unit testing
Manage testing Track defects

Third party code review for package/turn key solutions
Unit test sign-off (internal)
Updated status in feature work queue
Code review and QA sign-off (internal)
10
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Test Documentation
Review test plans (Who, What, Where, When, How) Prepare system integration test environment

Execution model (complete) Physical Data model & data dictionary (complete)
Constructed code (program logic)
Execute tests Integration testing Stress testing
SIT environment sign-off (internal)
System integration test sign-off (internal)
Baseline test cases & scripts
Baseline code
11
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Finalised business documents

Training Delivery (design & delivery) Training manuals Actual training completed

Walkthrough model (complete)
Baseline code
Test Documentation
Review test plans (Who, What, Where, When, How) Prepare user acceptance test environment
IT Service Delivery Business support (help desk)
Banking Routines Group reference guide (GRG) Circulars, fan-outs, forms design
Readiness assessment List of impacted areas Conversion plan Implementation plan Back-out plan System rollout plan Finalised pro-active monitoring strategy
Production hand-over documents
Compliance & BCP

Execute tests User acceptance testing
UAT environment sign-off (internal)
Manage testing Track defects BCP test report

Risk register
Deployment readiness review sign-off

12
Internal Audit will conduct an independent assessment of all high risk projects, or as requested
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Incre Step 9 ment integr ation Acce ptan Step ce 10 testi ng Depl Step 11 oym ent & warr anty
Reception
Step 12
Step 8 Build
by featu re
Compliance & BCP

Baseline code Compliance /
The following models must be complete: BCP checklist Physical Context model Feature model Physical Software Layer model Physical Component model BCP test Physical Semantic data model report Physical Execution model Framework model Physical Walkthrough model Check-in of project Physical Data model & data dictionary artifacts Physical Data model & data dictionary
Test Documentation
Final business continuity plan annexure (BCP) Deployment testing Verify operation in live environment
Deliverables from previous steps

Project questionnaire (Construction) Information protection construction document
All critical project artifacts must be signed off prior to deployment of business solution
Operator instructions Callout instructions Activate monitoring
Deployment verification sign-off

13
STAGE: Construction
PG30
BACK
Definition
Step1
Design (Analysis & conceptual design) Deve Identif lop y Step 3 Step 4 Step 5 Step 6 Step 2 over goals Build Plan Requirements all and featu by mod specification featur res featu el es list re
Knowledge repository & patterns Information protection review

Construction
Reception
Step 12
Step 8 Build
by featu re
Lessons learned
Test Documentation
Analyse test results Lessons learnt PEP defect analysis New baseline regression test pack
Completed PEP form
Deliverables from previous steps Business case and/or feasibility study Project definition document (PDD) Functional system specification (FSS) Technical system specification (TSS)
Function point count (FPC) final Final service level agreement (SLA) Production support hand-over Final conformance review sign-off
Critical project documents

Set up a workshop with IT Service Management to define the SLA

Submit PG90 for project completion

14
STAGE: Definition
PG10
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
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 Criteria
Business Case and/or feasibility study signed off by business owner and Strategy & Architecture. Business process models may have been defined. Buy vs. Build decision has been taken.
Verification
Self assessment Analysis team Required
The team should review the list of primary actors to ensure completeness. The team should review the PDD and high-level analysis for completeness and correctness. Outstanding issues must be noted.
Tasks
Architecture assistance Project manager Required
Project manager must contact Group IT Architecture to have an Account Manager assigned to the project (assist with architectural issues). Cost billed to the project.
Form the analysis team Project management Required
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 be impacted by systems changes, communications, or training) PDD business sign-off (High-level analysis index, PDD and all attachments [Project questionnaire, Context model, Compliance & BCP checklist, Information protection definition document, and Acceptance criteria]) All preceding sign-off must be obtained first.
This team should consist of business experts from the relevant domain, a user representative, 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 proposed system. Actors can be customers, users, or external systems. The team starts by considering who the primary actors are in order to produce a preliminary list. The list can be refined when further input becomes available or as the various goals are identified.
Define high-level analysis index Analysis team Required
Deliverables
PDD FSS (high-level analysis index) Project questionnaire (Network communication requirements, etc) Compliance / BCP checklist Context Model (initial) and Actor list
The team documents the background, list of business goals (initial), list of actors, list of business functions, business walkthrough, common business rules, nonfunctional requirements (initial), and exclusions in the FSS. Together, these constitute the high-level analysis index.
Complete project questionnaire Analysis team Required
Techniques
A technique that may be useful here is to use index cards to represent the actors in a group session.
The team must document replies to the Network and related questionnaires. This is used to determine the extent of impact the project will have upon the existing network typology, information security, and continuity plans. Support areas will be involved in proportion to the perceived impact.
Tools
Preferred tool: Rational Rose Analyst Studio Visio may be used for the Context Model
15
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Define the business need and analyse the problem area. Finalise the system goals and translate into features.
Entry Criteria
Completion of process step 1. Initial context model and list of primary actors that will engage the system. Initial business goals from high-level analysis index.
Revise current SLA
Project manager
Required
This is facilitated by IT Service Management. Review and revise the existing SLA between business and IT to include the new system. Ensure that all service levels specified in the PDD have been included.
Tasks
Finalise Context Model Modelling team Required
Verification
Review trace ability Analysis 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 Required
The team should verify that each feature maps to at least one goal and that each goal maps to at least one actor.
Review prioritisation Project stakeholders Required
The team considers the goals (or business objectives) each actor has with respect to the system. Revise the list of actors if some system goals are found that do not belong to any of the actors identified.
Identify candidate features Analysis team Required
Project stakeholders, for example the sponsor and business owners, should review the prioritisation of features.
Exit Criteria
For each goal identified in the previous step, the team considers what features will fulfil the goal.
Initial prioritisation of features Analysis team Required
The team must deliver a list of prioritised goals and features. Goals must be finalised, but features may be reviewed in subsequent steps.
Deliverables
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 Required
Define an initial Feature Model. This will become the first cut for Use Case names.
Produce RFI Analysis team + Procurement Optional
Revised 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 by the business for acceptance for the solution)
Request for Information (RFI) should include a Context Model and list of system goals. It should refer to functional requirements only, not implementation specifics.
Techniques
For MoSCoW prioritisation of features, apply one of Must Have, Should Have, Could Have, or Would Have [BlueCore Toolkit]. Use can be made of the index cards used in Step 1: Define project scope. Write the goals on the backs of the cards.
Tools
Preferred tool: Rational Rose Analyst Studio Visio 16
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Collect and document all business requirements. Elaborate features (describing what is required, not how it must be done), deferring any design issues.
Entry Criteria
Completion of process step 2. List of system goals and features defining the business objectives of the system.
Tasks
Form feature sub-teams Project manager Optional
In order to maximise progress, the analysis team may be divided into sub-teams assigned to groups of use cases. The teams may be augmented by lead developers.
Document use cases Analysis (sub-)team Required
Test planning: WHAT Define 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 Piloting For each use case, the test team documents the test cases needed to fully test the use case (negative testing also). Test planning: WHERE The test manager identifies and documents the environments where the various phases 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: WHEN The test manager schedules testing as part of the overall MSP project plan. Key inputs are the test phases, test cases and test resources allocated.
Define use cases (who does what for what purpose or goal), providing the following: Name Characteristics (description, pre-condition, end-condition, actor/s, trigger event) Business rules Main success criteria Alternate scenario/s
Test planning Test manager Required
The test manager starts planning the testing that will be conducted to validate the solution: Test planning: WHO Select the teams who will complete the various testing phases. The following must be documented: Test team Support team (e.g. DBAs Network support) External team (e.g. Bankserve, MTN) Roles & responsibilities Skill levels Training requirements
17
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Collect and document all business requirements. Elaborate features (describing what is required, not how it must be done), deferring any design issues. Test planning: HOW The test manager identifies and documents the procedures that will be used during the 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
Tools
Rational Rose Analyst Studio
Document the user interface specifications and report layouts. Revise and expand the common business rules and exclusions. Role play all use cases to identify any missing or incomplete user interface/report requirements.
Log issues Analysis team Required
Record all issues in the Project Minutes, with due date, status, and responsibility.
Verification
Internal review Analysis team Required
The team should review all the requirements specifications for completeness and correctness. Outstanding issues must be noted.
Exit Criteria
1st business sign-off (FSS and initial test plan)
Deliverables
FSS (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 used by the business for acceptance for the solution)
Techniques
No specific techniques. Domain walkthroughs may aid understanding of the use cases. 18
STAGE: Design
PG20
BACK
Definition
Step1
Specify the architectural during domain modelling.
Depl Step 8 Stepoym 11 Step 12 Build by ent Project featu & finalisation re warr anty design of the business solution. Produce architecture models, which includes framework, layer, execution and data definitions. Apply design patterns Desi Step gn 7 by featu re Incre Step 9 ment integr ation
Construction
Acce ptan Step ce 10 testi ng
Reception
Entry Criteria
Completion of process step 3. Functional requirements of the system defined and signed-off. Test planning started. Features documented in Feature Model.
Develop domain model
Modelling team
Required
Tasks
Form 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 experienced design mentor, if available, should be included to counter inexperience.
Request assistance Project management Optional
For software, build class diagrams, informal sequence diagrams and component models using the available documents. The CRC technique may be useful here. The team may split up to tackle sub-domains and then consolidate the models. Architecture principles from the features sets should be resolved here and Patterns to be used should be identified. Initial execution models and network models may be designed 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
Group Architecture may assist team with design. Group IT Support Services may assist team to use ChangeManDS for source management and version control.
The team begins architecture definition by applying the architecture patterns defined in the BlueCore Toolkit and repository and reviewing architecture documentation for any existing frameworks.
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)
Verification
Model 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 Criteria
The team must produce all deliverables of this step, ensuring that any issues raised during the process are added to the issue log. 19
STAGE: Design
PG20
BACK
Definition
Step1
Specify the architectural during domain modelling.
Depl Step 8 Stepoym 11 Step 12 Build by ent Project featu & finalisation re warr anty design of the business solution. Produce architecture models, which includes framework, layer, execution and data definitions. Apply design patterns Desi Step gn 7 by featu re Incre Step 9 ment integr ation
Construction
Reception
Deliverables
Informal sequence diagrams for each distinct scenario of component interaction Project questionnaire (Network communication requirements, etc) Test documentation (updated test plan) Conceptual architecture models (in progress) Patterns & Principles
Techniques
CRC 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 Procurement CRC R [Bredenmeyer]
Tools
Rational Rose Analyst Studio Visio, until UML extension for Architecture description.
20
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
Produce a detailed list of atomic business features (fragment all composite features so that development effort will not exceed 2 weeks). Estimate development effort and identify inter-dependencies. Identify variable factors that could impact delivery. Project Sponsor must prioritise the relative business importance of all features.
Entry Criteria
Completion of process step 4. The modelling team has completed the Develop overall model process. All sign-offs have occurred.
Test planning
Test manager
Required
Tasks
Form 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
Verification
Self assessment Analysis 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
The team should review the list of features for completeness. The priorities of the features must be reviewed.
Exit Criteria
The team must produce the detailed list of prioritised features and services, subject to the approval of project stakeholders.
Deliverables
Using the priorities assigned to the features during process step 2 as the starting point, re-apply the MoSCoW prioritisation technique to the detailed list. Identify dependencies between features, and those features with a high latent planning impact (variable factors may have a considerable impact upon construction effort).
Define draft RFP Features list team + Procurement Optional
Detailed and prioritised features list Test documentation (updated test plan)
Techniques
Apply Identify Features. For MoSCoW prioritisation [Stapelton], apply one of Must Have Feature, Should Have Feature, Could Have Feature or Would Have Feature [BlueCore Toolkit].
This task only applies if a package solution is being considered for this project. The Request For Proposal should provide sufficient project and architectural documentation (including any imposed frameworks, networks, interfaces, or operational restrictions) for the vendor to respond with a detailed tender.
Tools
Rational Rose Analyst Studio Case Study research / reference MERCURY test tools 21
STAGE: Design
PG20
BACK
Definition
Step1

Construction
Incre Step 9 ment integr ation Acce ptan Step ce 10 testi ng
Step 8 Build
by featu re
Produce a detailed development plan, specifying the increments and order in which features will be delivered. number of increments and releases will depend on the channel.
Depl Stepoym 11 Step 12 ent Project & finalisation warr anty Each release must be a separate Construction stage. The
Reception
Entry Criteria
Step 5 must be completed (all features identified and the conceptual design for each completed). Features must have been prioritised by the business.
Verification
Assess plan Planning team Required
Tasks
Form planning team Project manager Required
The planning team should review the development schedule produced and involve any other project stakeholders as needed.
Define implementation training requirements Planning team Required
The planning team comprises the project manager, user representative, business expert, lead architect and lead developers.
Produce detailed construction plan 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.
The 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 unit without any dependence upon subsequent increments. Related increments are grouped into releases based upon the dependency of features. Each release is a separate Construction stage with a maximum duration of 7 months. A project may have more than one Construction stage, each delivering independent sections of the solution. The detailed construction plan must specify fixed end dates and resource responsibilities.
Appoint repository administrator Planning team Required (Software)
Exit Criteria
The planning team must produce a feature work queue and detailed project plan that has 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, project questionnaire, Compliance & BCP checklist) Preceding sign-off must be obtained first.
The team should appoint someone to act as the ChangeManDS team repository administrator who will be responsible for repository management.
Finalise RFP Features list team + Procurement Optional
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)
The Request For Proposal must define functional, architectural, security, and service level requirements in sufficient detail for vendors to respond to our request.
Techniques
Apply PlanningGame [BlueCore].
Tools
Rational Rose Analyst Studio MERCURY tool set 22
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
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 Criteria
Completion of process step 6. Plan by feature has been completed including business sign-off. Development environment must be in place. Team members must be available.
Finalise test cases
Test team
Required
The test team finalises the test cases for the current feature by the end of its design.
Verification
Design inspection Feature team Required
Tasks
Assemble feature team Feature owner Required
The feature owner identifies which classes are likely to be required for the implementation of the feature. The feature team is then drawn from the class owners. Domain experts may be necessary for detailed design of the feature and should be included in the team.
Study or review documentation Feature team Optional
The team must review the detailed design specifications for completeness and correctness. 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.
The team should review all information available relating to the feature under consideration.
Produce detailed design Feature team Required
Exit Criteria
Physical data model sign-off (internal by Data Architecture for creation of database tables)
Using the architecture models and functional requirements produced earlier as a starting point, the team creates detailed program specifications (4 different formats for all environments) for the feature and updates the user interface design/report layouts if necessary. The architecture models must be updated under the guidance of the lead architect. Physical database structures must be defined and submitted to Data Architecture for approval - comply with lead time requirements.
Produce automated test scripts Test manager Required
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) Project questionnaire (Network communication requirements, etc)
The test manager produces test scripts (automated wherever possible) for the tools used. Each test script has a pre-requisite state, test conditions, and expected results: MERCURY (Windows and web based functional testing tools)
Techniques
The CRC technique is also useful for detailed design [Ambler]. Modelling with archetypes [Coad]. Apply design patterns (see [GOF94] and [Buschman96]. 23
STAGE: Construction
PG30
BACK
Depl Step 8 Stepoym 11 Step 12 Step1 Build Define by ent Project project featu & finalisation scope re warr anty Implement design specifications (programs/classes/methods) for each feature. Perform unit test and code inspection to verify functional completeness and code quality. Desi Step gn 7 by featu re Incre Step 9 ment integr ation
Definition
Construction
Reception
Check-in code changes into ChangeManDS once they have been validated.
Entry Criteria
Completion of process step 7 for this increment. Detailed design for the feature/s has been completed.
Verification
Unit 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
Tasks
Prepare test environment Feature team Required
The test manager prepares and verifies the environment prior to commencement of unit testing. This includes hardware, software, networking, security, backup, and generation of test data. If a regression test pack is available, this would be used to verify that the baseline system functions before deploying any changes.
Check out classes Feature team Required (Software)
The team should inspect all detailed infrastructure designs and code for quality and adherence 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)
The team repository administrator must create an open edition of the project in ChangeManDS and check out any objects (programs, classes, etc) that will be modified during this increment.
Code unit tests Feature team Required
Only after verification tasks are completed should class owners check in new/changed classes into ChangeManDS. Update status in feature work queue.
Exit Criteria
Unit test environment sign-off (internal) Unit test sign-off (internal)
Class owners must create or extend the unit test suite for any classes they will create or modify. Wherever possible, build test scripts for an automated testing tool (e.g. Junit or Mercury suite). Each test script has a pre-requisite state, test conditions, and expected results.
Implement feature Feature team Required
Deliverables
Updated 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)
Each developer implements functionality in support of the feature and/or service as specified by the detailed design specifications.
Execute unit testing Feature team Required
Techniques
This task should be run by the developer concurrently with Implement feature. Running unit tests frequently measures the progress being made and determines completion.
Tools
Rational Rose Professional J MS Project MERCURY test tools ChangeManDS
Apply (refer to [BlueCore] and [Beck]): CodeUnitTestFirst YouArentGoingToNeedIt OnceAndOnlyOnce DoTheSimplestThingThatCouldPossiblyWork OneChangeAtaTime Apply language specific coding standards.
24
STAGE: Construction
PG30
BACK
Depl Step 8 Stepoym 11 Step 12 Step1 Build Define by ent Project project featu & finalisation scope re warr Complete integration testing and stress testing of all increment features to verify that the business solution is fully functional. On passing these anty the code is baselined in tests, Desi Step gn 7 by featu re Incre Step 9 ment integr ation
Definition
Construction
Reception
preparation 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)
Entry Criteria
Completion of process step 8 for this increment. All features that are part of the increment have been implemented, unit tested, reviewed (internal and/or external code review) and checked into ChangeManDS. All SIT, and stress test cases must be defined.
System integration test review
Test manager
Required
The system integration tests should be inspected to ascertain that sufficient code coverage was achieved. System integration testing and stress testing results should be independently verified.
Baseline code & test scripts Repository admin Required
Tasks
Prepare SIT environment Test manager Required
Once all the code has been fully tested and the accepted by the users, it must be baselined in ChangeManDS, along with the revised regression test suite.
The 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) and generation of test data. If a regression test pack is available, this would be used to verify that the baseline system functions before deploying any changes.
Execute SIT testing Test manager Required
Exit Criteria
System integration test environment sign-off (internal) System integration test sign-off (internal)
Deliverables
Integration testing must be performed to ensure that components (infrastructure or software) interoperate correctly. Integration test cases must be executed according to the test schedule. Regression testing must also be performed to ensure there is no loss of functionality. Review and expand test plans as necessary.
Execute stress testing Test manager Required
Execute stress test cases to confirm the solution meets the service levels specified in the PDD. The SIT environment must closely resemble production for meaningful results. Review and expand test plans as necessary.
Track defects Test manager Required
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
The test team report defects (where actual does not match expected results) and the test manager ensures that defects are fixed and re-tested. The test manager analyses defect data and produces defect reports to inform the team & management of new defects and progress of defect repair.
Techniques
Apply Automated Testing, Regression Test [BlueCore].
Verification
Manage testing Test manager Required
Tools
Rational Rose Professional MERCURY test tools Serena E-Changeman for baseline code. Visio for architecture updates 25
SIT and stress testing must be signed-off as complete. If testing is ended before all test cases have been successfully run, the test manager must indicate how much testing is left, and the risks of not completing. The test manager is responsible for when to stop testing, and should only do so when fully satisfied.
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re
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 is ready for operational use, and the security controls are suitable for business purposes. Acceptance Criteria test cases will be used.
Entry Criteria
Completion of process step 9 for this increment. SIT and stress test results must have been internally reviewed and accepted by business and IT. UAT test cases must be defined.
Verification
Manage testing Test manager Required
Tasks
Prepare UAT environment Test manager Required
UAT must be signed-off as complete. If testing is ended before all test cases have been successfully run, the test manager must indicate how much testing is left, and the 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 test manager prepares and verifies the environment (as similar as possible to the LIVE environment) prior to commencement of user acceptance testing. This includes hardware, software, networking, security, backup, and generation of test data. If a regression test pack is available, this would be used to verify that the baseline system functions before deploying any changes. Thereafter increment features are deployed.
Execute UAT Testing Test manager Required
The user acceptance tests should be inspected to ascertain that sufficient code coverage was achieved. Test results should be verified. Review all the test documentation for completeness and correctness. Testing normally stops when all tests are successfully run (i.e. actual results match expected results). If testing stops before all tests have been run, the outstanding testing & associated risk must be documented.
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 branch infrastructure. Test BCP recovery procedures, documenting findings in the BCP test report. Review and expand test plans as necessary.
Track Defects Test manager Required
Exit Criteria
Deployment readiness review sign-off (SCP results, implementation readiness assessment, production support hand-over documents, Internal Audit review) 3rd Business sign-off (UAT test results) Preceding sign-off must be obtained first.
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 reports to inform the team & management of new defects and progress of defect repair.
Prepare for deployment Project Manager Required
Deliverables
Produce production support hand-over documents for deployment of the system into 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)
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
Techniques
Techniques to be applied in testing are boundary analysis and equivalence partitioning.
Tools
Mecury Test Director
26
STAGE: Construction
PG30
BACK
Definition
Step1

Construction
Incre Step 9 ment integr ation Acce Step 10 ptan ceTe sting Depl Step 11 oym ent & warr anty
Reception
Step 12
Step 8 Build
by featu re
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 the LIVE environment for the specified warranty period. Performance tune as necessary to achieve the specified SLA requirements.
Entry Criteria
Completion of process step 10 for all increments in the is Construction stage. Implementation Plan reviewed and signed off by Production support. Channelspecific release criteria, standards and procedures reviewed.
Verification
Achieve service levels Project Management Required
The System must have executed in the LIVE environment according to the Warranty criteria stipulated in the PDD. All service levels must have been achieved as specified. All known defects must have been corrected or accepted by the project sponsor.
Tasks
Package the release Project Management Required
Exit Criteria
3rd Strategy & architecture review sign-off (all architecture models, BCP test report, 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-off must be obtained first.
Project Manager to communicate the channel-specific information to the team members and ensure that all standards and procedures have been applied. Release to be packaged as per the channel requirements. Production support must be involved in this exercise.
Notify production managers Project Manager Required
Communicate planned release and impact to all affected production areas. Comply with imposed freeze periods. Ensure the change control is loaded in AZIM with the correct lead time. Talk to the planned release at the daily production change meeting.
Verify deployment Project management Required
Deliverables
Callout instructions Operator instructions Business workarounds (where 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
Tools
MS Word Serena E-Changeman
Support the release (complete or portion of solution) in the production environment for the period stipulated in the PDD (Project Definition Document) until the specified service levels have been achieved to the satisfaction of the project sponsor. If the system does not operate as required, the team report defects and the project manager ensures that defects are fixed and re-tested. The project manager documents and communicates progress against plan. 27
STAGE: Construction
PG30
BACK
Definition
Step1
Design (Analysis & conceptual design) Deve Identif lop y Step 3 Step 4 Step 5 Step 6 Step 2 over goals Build Plan Requirements all and featu by mod specification featur res featu el es list re

Construction
Reception
Step 12
Step 8 Build
by featu re
Hand-over business solution to Production Support. Finalise all deliverables, ensuring that they properly reflect the status of the implemented business solution. Identify and document learning experiences and patterns that could be applied to future projects.
Entry Criteria
Deployment of all functionality for this release into the LIVE environment. Warranty period must have been completed, and system accepted by the project sponsor as delivering the service levels specified in the PDD.
Hand over to production support
Project management
Required
Hand over all supporting documentation to the production support team. Conduct a final communication session to close out on any outstanding actions related to the release.
Tasks
Document lessons learned Project management Optional
Verification
Publish deliverables Modelling team Required
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 the process. A pattern mining workshop can be run, facilitated by SigmaWorks if necessary, to identify patterns that can serve the rest of the enterprise in future projects.
Finalise project documentation Entire team Required
The team must collect, review and package all documentation produced throughout the project stages. Final documentation must to be checked into ChangeManDS and published on the Sigmaworks site within 1 week after closure of the project.
Exit Criteria
Final conformance review sign-off (all critical project documents, analysis of test results, lessons learnt, PEP form, final FPC, final SLA, finalised project documentation) Production support hand-over (production hand-over documents, all project documentation) Preceding sign-off must be obtained first.
All documentation produced during the course of the project must be completed and checked into a document management system (Changeman DS). It must provide an accurate reflection of the final implementation of the solution. This includes documentation to assist end users and facilitate integration of the new system into the business processes.
Finalise SLA Project manager Required
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
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 defects resolved. A summarised report is produced of the lessons learnt and recommendations for improvements. SIT and UAT defects must be recorded in the PEP form.
Tools
Rational Rose Analyst Studio MS Word MS Project 28
Requirements: Solution Development process

Solution Development process
BACK
Definition
Step1
Detailed & prioritised features list Feature work queue

Construction
Reception
Step 12
Step 8 Build
by featu re
Functional system specification (FSS)
Technical Update status system in feature specification work queue (TSS) User interface specifications
High-level List of actors Use case analysis index (final) specifications Background Business System goals Common walkthrough & features list business List of system (final) rules goals List of actors Index to business Non-functional User interface functions Common requirements specifications business rules
Report layouts
Translation from logical to physical views
Report layouts
Conversion considerations Operator instructions Program specifications Class diagram Sequence diagram Activity diagram Contract Batch scheduling & dependencies
29
Requirements: Group IT Architecture & Data Architecture

Group IT Architecture Data Architecture
BACK
Definition
Step1
Business impact assessment document Project kick-off meeting (Architecture)

Construction
Incre Step 9 ment integr ation Acce ptan Step 10 ce testi ng Depl Stepoym 11 ent & warr anty
Reception
Step 12
Step 8 Build
by featu re
Architecture models Context model Conceptual Context model Physical Context model

Informal sequence diagrams List of feature owners List of class owners
Feature model
Framework model Conceptual Software Layer model Conceptual Component model Conceptual Semantic data model Conceptual Execution model Conceptual Walkthrough model Logical Data model Data dictionary Physical Software Layer model Physical Component model Physical Semantic data model Physical Execution model
Physical Walkthrough model

Physical Data model Data dictionary
30
Requirements: Group IT Testing

Group IT Testing
BACK
Definition
Step1
Acceptance criteria

Construction
Reception
Step 12
Step 8 Build
by featu re
Test planning (who, what, where, when & how) Automated Execute tests & Track Defects Test scripts Unit test, Integration test, Load test, Acceptance test
Deployment Analyse test testing results Analyse test results (section 8)
Test scripts
Prepare SIT environment
Prepare UAT environment
Deployment testing
SIT UAT environment environment sign-off 4.1.2 sign-off 4.1.2 (internal) (internal) Execute tests Execute tests Execute tests (section 5) SIT UAT Unit test Stress test Track defects Track defects Track defects Section 6, 7 Section 6, 7 Section 6, 7 MERCURY MERCURY MERCURY

Unit test sign-off (internal)
System test sign-off (internal)
Baseline test cases
31
Requirements: Group Project Office

Programme Governance Project Management
BACK
Definition
Step1
Project planning DEFINITION Feasibility study and/ or Business case Project Definition Document (PDD)
Project planning DESIGN Project risk assessment (Hoskins)

Project planning CONSTRUCT
Construction
Reception
Step 12
Step 8 Build
by featu re
Lessons learned
Annexures
Compliance / BCP checklist Project team roles & responsibility Project questionnaire (Definition)
Function point count (FPC) estimate
Function point count (FPC) final
Collect PEP results throughout all stages of the project
Completed PEP form Submit PG90 for project completion
Submit PG10 Submit PG20 for approval for approval of next stage of next stage
Submit PG30 for approval of next stage
Sign-off completion

Final conformance review sign-off
32
Requirements: Group IT Security

Group IT Security
BACK
Definition
Step1
Business impact assessment document Information protection policies Information protection definition document
Information protection design document Information protection guidelines Information protection standards Information protection checklists

Information protection construction document
Construction
Reception
Step 12
Step 8 Build
by featu re
Information protection review
Security standards conformance issues (record in Project Minutes) Security action plan (record in Risk Register) Complete ONE of the following: Security controls checklist e-Commerce Threats & Controls security checklists Threats, vulnerabilities and controls assessment Information Protection Matrix Declaration of secrecy form (for third parties, vendors, consultant companies) Security Model (Conceptual --> Logical --> Physical)
3rd Final Strategy & architecture conformance review review sign-off sign-off
33
Requirements: Compliance & Business Continuity Planning

Compliance & BCP
BACK
Definition
Step1

Step 8 Build
by featu re
Incre Step 9 ment integr ation
Reception
Depl Step 11 oym ent & warr anty
Step 12
Review responses System controls

Compliance risk controls
BCP test report
Draft business continuity plan annexure (BCP)
Support areas to update their own BCP annexures
Final business continuity plan annexure (BCP)
34
Governance checkpoints: Business approval and sign-off

Definition
Step1
BACK

Construction
Reception
Step 12
Step 8 Build
by featu re
Functional system specification (FSS) High-level analysis index Project Definition Document (PDD) Acceptance criteria Revised service level agreement (SLA) Information protection definition document Context model Project questionnaire (Definition) 1st Strategy & architecture review sign-off EIM / BDS review Request for information (RFI)
Technical Feature system Expanded per increment until complete work queue specification (TSS) Request for proposal (RFP) Test planning (who, what, where, when & how) Automated Execute tests & Track Defects Test scripts Unit test, Integration test, Load test, Acceptance test Project risk assessment (Hoskins) Function point count (FPC) estimate
Deployment Analyse test testing results Final service level agreement (SLA) Function point count (FPC) final
Mandatory review if any branch systems, training, or communication affected Sign-off functional requirements
Sign-off Contract
Project sponsor to sign-off all stages
Sign-off design and sequence of delivery

Sign-off acceptance of all increments in this release

Sign-off LIVE
Sign-off completion
35
Governance checkpoints: Business approval and sign-off
Inspection process to be defined for business quality assurance and sign-off. All signatures will be recorded in the Compliance checklist once this document is available.
36
Project kick-off meeting (Architecture presentation)

PG10
BACK
Definition
Step1

Construction
Step 8 Build
by featu re
Project kick-off meeting (Architecture presentation) Group IT Architecture and domain architects must be present at this meeting. The purpose is to identify reusable processes, frameworks, data structures, components, etc that could apply to the project.
An Account Manager will be assigned to the project to assist the team with architectural issues. Note that the cost of the Account Manager will be billed against the project. The extent of involvement of support areas will be agreed. This includes Group IT Architecture, domain architects, Retail learning, Banking routines, Service delivery, Service Governance Group, and others. Lead times will be agreed with all support areas assisting with project deliverables (e.g. GRG, circulars)
Account Manager (AM) assigned to the project at the start of each stage by Group IT Architecture
Account Manager schedules kick-off meeting/s with all key players

More than one meeting may be required in order to meet with all key players
Depl Stepoym 11 Step 12 ent Project & finalisation warr anty Involve representatives from the following areas Group IT Architecture (your Account Manager) Group IT Strategy Information Security Data Architecture LAN Services Communications Network Services IT Compliance & BCP Group Compliance (your Business compliance officer)
Reception
Deliverables to be provided for kick-off meeting

Walkthrough of the business requirements and project objectives Business case and/or feasibility study Business process models Project questionnaire (Investigation stage) Business impact assessment (SPRINT) Conceptual Context model (first draft)
Project kick-off meeting (Architecture)
Output from kick-off meeting
List of candidate patterns and components Identification of enterprise components Frameworks and architectures List of candidate data structures Pro-active monitoring strategy (SGG)
Pro-active involvement of support areas to support project objectives
37
Governance checkpoint: 1st Strategy & architecture review sign-off

PG10
BACK
Definition
Step1

Construction
Step 8 Build
by featu re
Account Manager schedules review up to 3 weeks in advance
Reception
Deliverables to be provided for review

Presentation overview (10 minutes duration - use the ARM presentation template supplied) Project questionnaire (Definition stage) Information Protection document (Definition stage) Conceptual Context model Compliance/BCP checklist
Output from review

Feedback & assistance on design Re-usable components Issues that must be resolved 1st Strategy & architecture review sign-off (Definition stage)
Sign-off must be obtained prior to PDD business sign-off of Definition stage
38
Governance checkpoint: 2nd Strategy & architecture review sign-off

PG20
BACK
Definition
Step1

Construction
Step 8 Build
by featu re

Presentation overview (10 minutes duration - use the ARM presentation template supplied) Project questionnaire (Design stage) Information Protection document (Design stage) Physical Context model Conceptual Feature model Framework model Conceptual Software Layer model Conceptual Component model Conceptual Semantic data model Conceptual Execution model Conceptual Walkthrough model Logical data model & data dictionary Patterns (as identified) Compliance/BCP checklist Compliance controls Draft BCP annexure for this project
Reception
Feedback & assistance on design Issues that must be resolved 2nd Strategy & architecture review sign-off (Design stage)
Output from review
Sign-off must be obtained prior to 2nd business sign-off of Design stage
39
Governance checkpoint: 3rd Strategy & architecture review sign-off

PG30
BACK
Definition
Step1

Construction
Incre Step 9 ment integr ation Acce ptan Step ce 10 testi ng Depl Step 11 oym ent & warr anty
Reception
Step 12
Step 8 Build
by featu re

Presentation overview (10 minutes duration - use the ARM presentation template supplied) Project questionnaire (Construction stage) Information Protection document (Construction stage) Physical Context model Feature model Framework model Physical Software Layer model Physical Component model Physical Semantic data model Physical Execution model Physical Walkthrough model Logical data model & data dictionary Physical data model & data dictionary Patterns (as identified) Compliance/BCP checklist BCP test report Final BCP annexure for this project Updated BCP annexures for support areas
Involve representatives from the following areas Group IT Architecture (your Account Manager) Group IT Strategy Information Security Data Architecture LAN Services Communications Network Services IT Compliance & BCP Group Compliance (your Business compliance officer)
Feedback / issues 3rd Strategy & architecture review sign-off (Construction stage)
Output from review
Sign-off must be obtained prior to deploying solution into the LIVE environment
40
Advise Group IT Architecture that project has started (Abdul Baba or Sadiki Mbebe)
ARM Process Architecture Review Meeting

[At least 9 working days before ARM]
Project representatives present overview of project to AM
BACK
Account Manager (AM) assigned to the project by Group IT Architecture
[9 working days before ARM]

D-9Project manager provides completed architecture documentation to AM

Domain Architecture D-9 Forum reviews quality and compliance
Project requests review

Contact Group IT Architecture by Email to request ARM review (Abdul Baba or Sadiki Mbebe)
Accept (good quality)
Reject (incomplete documentation)

ARM minutes updated to record rejection and reasons
Reject (poor quality)
AM advises project manager of rejection and reasons. AM assists project team to resolve issues
Reject (unresolved issues) [3 working days before ARM]

DAFT decides on which Accept projects will get D-3 sign-off & which projects will be present
D-8 AM advises project manager of confirmed ARM date
Critical issues raised

Are any issues raised during the ARM?
[Wednesday ARM meeting]

ARM Project representatives present overview of project to ARM
[5 working days]
D-7 to D-3 Domain Architects review project documentation Group IT Architecture Group IT Strategy Information Security Data Architecture LAN Services Communications Network Services IT Compliance & BCP Group Compliance
Send note to PM, sponsor, Group IT Architecture (Sadiki Mbebe), and Group IT Strategy Architecture (Hilda Collis)
No critical Issues
ARM minutes updated to record approval of project
9 working days notice required

T F
D-8
M
D-7
T
D-6
W
D-5
T
D-4
F
D-3
M
D-2
T
D-1
W
ARM
Timeline
D-9
DAF meeting
DAF meeting
ARM meeting
41
Requirements: Procurement
Procurement
BACK
Definition
Step1
Available sources
Best value
Request for proposal (RFP) Request for information (RFI)

Construction
Reception
Step 12
Step 8 Build
by featu re
Buy vs Build decision
Checklists Screening criteria Supplier interviews
Checklists Evaluation criteria Package demonstration Reference site checks
Initial screening procedure
Detailed evaluation procedure
Short list of packages
Recommended package/s
Gartner market analysis Vendor market share Benchmark comparisons
Site visits Benchmark comparisons Gap assessment Investment analysis
Sign-off RFI
Sign-off RFP
At the RFI stage, the enterprise has the opportunity to canvass a broad mix of providers (e.g. small and large companies, product companies that have marketed their services capabilities to the enterprise and other nontraditional sources). RFI responses can be used to help formulate selection criteria that will carry forward to the successive RFP stage of the evaluation and selection process. Compare and contrast provider offerings and objectively cull the list of potential external service providers (ESPs) that demonstrate they could satisfy the enterprises requirements. This process will further the dialogue about important attributes and characteristics for ESP selection. The rationale for determining the short list of potential providers should be documented and used to develop the selection criteria used in the next stage. The tandem of RFI and RFP selection criteria forms a logical bridge between available sources (RFI) and the best value (RFP). 42
Requirements: Procurement (Initial screening procedure)

Procurement
BACK
PG20
Definition
Step1
Gartner market analysis Vendor market share Benchmark comparisons
Request for information (RFI)

Construction
Reception
Step 12
Step 8 Build
by featu re
Procurement
(allow 2 days for processing) Allocate reference number Produce covering letter
Vendors
(allow 3 weeks for response)
Annexure A only
Sign-off RFI
1st Business sign-off Evaluation criteria defined (optional) Send RFI to vendors
Vendor completes reply to RFI Simple selection process to determine short list (optional)
Short list of vendors and product/s
Completed RFI received and logged
Purpose Eliminate inappropriate external service providers and products as early as possible. Checks appropriateness to the environment and match to the business principles
43
Requirements: Procurement (Detailed evaluation procedure)

Procurement
BACK
PG20
Definition
Step1
Site visits Benchmark comparisons Gap assessment Investment analysis
Request for proposal (RFP)

Construction
Reception
Step 12
Step 8 Build
by featu re
Procurement
(allow 2 weeks for processing) Allocate reference number Produce covering letter
Vendors
(allow 6 weeks for response)
Annexure A, B, C mandatory Annexure D is optional
Sign-off RFP
2nd Business sign-off Detailed evaluation criteria defined Send RFP to vendors
Tender
Evaluation criteria applied to select best product/s Recommended product/s Industry benchmarks and market comparisons Completed RFP received and logged
Vendor completes reply to RFP Quote Rank own product/s Details of product/s
Purpose Map requirements of the business to the capabilities of the products offered. Eliminate products that do not meet the functional business needs or conflict with the Banks technical architecture. Identify the best value solution.
Notify vendors of decision Award contract
Advise unsuccessful bidders Placement of order
Findings from visits to reference sites
Negotiate SLA
44
Requirements: Implementation Services & Support

Implementation Services & Support
BACK
PG30
Definition
Step1

Construction
Reception
Step 12
Step 8 Build
by featu re

Retail learning (design & delivery) Training manuals Actual training completed
Guideline: Lead time Allow 6 weeks per training day for the design of training material. This excludes time necessary to collect the input information. Even more time could be needed if the traditional classroom training is not used (e.g. video tape).
IT Service Delivery Business support (help desk)
Guideline: Lead time To be defined
Banking Routines Group reference guide (GRG) Circulars, fan-outs, forms design
Guideline: Lead time Allow 2 weeks for publication and distribution of GRG and circulars to branches. This excludes time necessary to document, review, and approve the new content.

Risk register

45
Internal Audit will conduct an independent assessment of all high risk projects, or as requested
Requirements: Infrastructure
Infrastructure
BACK
Definition
Step1

Project questionnaire (Construction)
Construction
Reception
Step 12
Step 8 Build
by featu re
Project Project questionnaire questionnaire (Design) (Definition)
Includes
Compliance & BCP Internal Audit risk ranking Comms. Network Information Security SPRINT Service Governance Internet Services Capacity Management Event Impact Management ITIS
Includes
Compliance & BCP Internal Audit risk ranking Comms. Network Information Security Service Governance Internet Services Capacity Management Event Impact Management ITIS
Includes
Compliance & BCP Internal Audit risk ranking Comms. Network Information Security Service Governance Internet Services Capacity Management Event Impact Management ITIS
All questionnaires from various support areas are being rationalised and combined into one single questionnaire per Stage. These will be the minimum questions necessary to determine the impact of the project upon the architecture, infrastructure, networks, security, and business continuity.
Questions and answers will be stored in a database. Email messages will be automatically generated to advise all affected support areas. The answers to these questions will be used to produce a measure of the risk/impact of the project. Low risk/impact projects will follow a lightweight process, with reduced compliance requirements for architecture, security, etc.
46
Requirements: Service Governance Group

Service Governance Group
BACK
Definition
Step1

Construction
Reception
Depl Step 11 oym ent & warr anty
Step 8 Build
by featu re
Step 12
Operator instructions Batch scheduling & dependencies
Readiness assessment List of impacted areas Conversion plan Implementation plan
Operator instructions Callout instructions Activate monitoring
Service Governance deliverables are currently being defined. Templates will be provided once available. Please contact the Manager SGG in the interim for assistance.
Back-out plan System rollout plan Finalised pro-active monitoring strategy
Ready for Sign-off deployment completion

47
Solution Development v1.2 Core deliverables

PG05 PG10 PG20 PG30
Procurement Group IT Support Services Group IT Testing
Service Governance Group Solution Project Management Development process Group IT Architecture Data Architecture
BACK
Investigation
Definition
Step1
High-level analysis index
Detailed & prioritised features list

Construction
PG90
Step 8 Build
by featu re
Functional system specification (FSS)
Technical Update status Feature system in feature work queue specification work queue (TSS)

Reception
Step 12
Rollout
48
Feasibility study and / or Business case Buy vs Build decision
Project Definition Document (PDD) Request for information (RFI) Request for proposal (RFP) Architecture models Context model Acceptance criteria 1st Strategy & architecture review sign-off PDD Business sign-off 1st Business sign-off Conceptual architecture models Physical architecture models Constructed code (Program logic) Baseline code
Test planning (who, what, where, when & how) Automated Execute tests & Track Defects Test scripts Unit test, Integration test, Load test, Acceptance test 2nd Strategy & architecture review sign-off 2nd Business sign-off Deployment readiness review sign-off 3rd Business sign-off (UAT)
Deployment Analyse test testing results 3rd Strategy & architecture review sign-off Deployment verification sign-off
48
Solution Development v1.2 Support area deliverables

PG05 PG10 PG20 PG30
Programme Governance Compliance & BCP Group IT Security Event Impact Management
Project Management infrastructure Implementation Services & Support Group IT Service Management BACK
Investigation
Definition
Step1

Construction
PG90
Step 8 Build
by featu re
Feasibility study and / or Business case Business impact assessment document
Project Definition Document (PDD) Information protection definition document Project Project questionnaire questionnaire (Design) (Definition) Revised service level agreement (SLA) EIM / BDS review Information protection design document Project risk Information protection assessment construction (Hoskins) document Function Draft business Project point count questionnaire continuity plan (FPC) annexure (BCP) estimate (Construction)
Reception
Step 12
Rollout
Lessons learned Completed PEP form
BCP test report
Final business Function continuity plan point count annexure (BCP) (FPC) final Final service level agreement (SLA) Final conformance review sign-off

49

Design (Analysis & Conceptual Design) Construction Reception

Uploaded by

Copyright:

Available Formats

You might also like

Design (Analysis & Conceptual Design) Construction Reception

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Design (Analysis & Conceptual Design) Construction Reception

Uploaded by

Copyright:

Available Formats

Solution Development v1.

2 Consolidated process map

Procurement Group IT Support Services Group IT Testing

Project Management Programme Governance Compliance & BCP Group IT Security

Service Governance Group Solution Development process

<<Steps repeated per increment>>

Feasibility study and / or Business case Buy vs Build decision

Depl Stepoym 11 ent & warr anty

Request for proposal (RFP) Architecture models

Physical architecture models

Project Project questionnaire questionnaire (Design) (Definition) Acceptance criteria

BCP test report

Production support hand-over

3rd Business sign-off (UAT)

Period specified in PDD

Final Deployment conformance verification review sign-off sign-off

PDD Business sign-off

Solution Development v1.2 process overview

<<Steps repeated per increment>>

Each increment should not exceed 1 month

Build & test

SLA requirements Sign-off Contract

Warranty support to Hand-over achieve SLA to Production in LIVE Support environment

Sign-off functional requirements

Sign-off design and sequence of delivery

Sign-off acceptance of all increments in this release

Deployment readiness review sign-off 3rd Business sign-off (UAT)

Compare against Business Case

Final Deployment conformance verification review sign-off sign-off

<<Steps repeated per increment>>

Definition stage project planning

Contract for delivery of solution

Account Manager (AM) assigned to project by Group IT Architecture

1st Strategy & architecture review sign-off

FSS (high-level analysis index)

Conceptual Context model

List of system goals Index to business functions

Project definition document (PDD)

PDD Business sign-off

Submit PG20 for approval of next stage

PDD and attachments constitute the complete contract

<<Steps repeated per increment>>

Design stage project planning

Conceptual architecture models

Confirm Account Manager (AM) assigned to project by Group IT Architecture

System goals & features list (complete)

Planning: WHERE Specify test environment (section 3)

Project questionnaire (Design) Impact/Risk

Non-functional requirements (complete)

Optional Compliance / BCP checklist Request for information (RFI)

<<Steps repeated per increment>>

Conceptual architecture models

Use case specifications

Planning: WHERE Specify test environment (section 3)

Deliverable from previous step

1st Business sign-off

<<Steps repeated per increment>>