FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Document Title: SDLC REPORT
Document Reference: COM/MGT/REP/4168
CP/CWO Reference: NIA
Abstract: Explanation of the Software Delivery Life Cycle used for Horizon
Applications.
Document Status: APPROVED
Author & Dept: Fujitsu
External Distribution: Restricted. See section titled Information Distribution.
Information See section 0.8
Classification:
Approval Authorities:
Name
Fujitsu Horizon Audit Team (POA) See Dimensions for record
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS PageNo: 1 of 72
FUJ00232715
FUJ00232715
oe SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Table of Contents
0 DOCUMENT CONTROL.
0.1 Document History.
0.2 Review Details.
0.3. Associated Documents (Internal & External,
0.4 Abbreviations.
0.5 Glossary..
0.6 Changes Expected.
0.7 = Accuracy.....
0.8 Information Classification
1 EXECUTIVE SUMMARY.
PURPOSE & SCOPE.
SDLC....
Overview of Process.....
4.1.1 HNGxDBM Product Descriptions. 1
4.2 Define Solution.......
4.2.1 Process Aims & Objectives.
4.2.2 Process Inputs...
4.2.3 Process Flow: Defini
2
3 BACKGROUND & INTRODUCTION.
4
4.
4.2.4 Process Outputs and Product Descriptions. 15
4.3 Design Solution... 17
4.3.1 Process Aims & Objectives. 17
4.3.2 Process Inputs... 17
4.3.3 Process Flow: Desig 18
4.3.4 Process Outputs and Product Descriptions. 22
4.4 Code, Build and Component Test....
4.4.1 Process Aims & Objectives.
4.4.2 Process Inputs............0 25
44.3 Process Flow: Code, Build and Component Test 26
4.4.4 — Process Outputs and Product Descriptions. 38
4.5 Integration (Application Package)...
4.5.1 Process Aims & Objectives.
4.5.2 Process Flow.
46 Testing & QA....
4.7 Accept and Deploy.
4.7.1 Process Overview.
4.7.2 Process Flow.
4.7.3 Process Steps.
FORMAL AUDIT REPORTS..
CONCLUSIONS.
N DO
RECOMMENDATIONG...........00000008
8 INFORMATION DISTRIBUTION
APPENDIX A —- HNGXDBM ROLE DESCRIPTIONS... 68
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 2 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
A.1 - Managemert.....
A.2 - Requirements & Architecture
A.3 - Technical & Engineering, including Test
A4 - Integration & Release.....
APPENDIX B —- TOOLING
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
PageNo: 3 of 72
FUJ00232715
FUJ00232715
SDLC REPORT
fee)
FUJITSU FUJITSU CONFIDENTIAL
0 Document Control
0.1 Document History
Version No. Date Summary of Changes and Reason for Issue Associated Change
CWO, CP, CCN or
Peak Reference
1.0 29/01/2021 Approved for release N/A
0.2 Review Details
Mandatory Review
Role Name
Horizon Audit Team Fujitsu
0.3 Associated Documents (Internal & External)
Reference Version Date Title Source
COM/MGT/REP/4163 I Latest Latest Expanded Table of Contents for the Dimensions
SDLC Report
COM/MGT/REP/4166 I Latest Latest Testing & QA Report Dimensions
0.4 Abbreviations
ADBM Applications Design and Build Method
AIS Application Interface Specification
BAU Business As Usual
BRAO1 Fujitsu Office in Bracknell where the Fujitsu POA project team are based
BRS Business Requirements Specification
CAB Change Advisory Board
ccD Contract Controlled Document
CIT Component Integration Test (Development Pre-Integration Test Environment)
CMDB Configuration Management Database
COTS Commercial Off The Shelf software products e.g. MS Office
cP Change Proposal (internal to Fujitsu)
cR Change Request (See RTQ below) (External POL)
csP Customer Solution Proposal
cT Component Test
CTP/CITP Component (Integration) Test Plan
CTR/CITR Component (Integration) Test Report
cwo Change Work Order — Contractual agreement to implement a work package under
BAU Change
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS PageNo: 4 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT ~
FUJITSU FUJITSU CONFIDENTIAL
DLL Dynamic Link Library
DPVB Deployable Product Version Baseline
EBMS European Business Management System
ECCB Engineering Change Control Board
EDS Enterprise Data Server — part of IBM Tivoli provisioning solution
EPM Enterprise Provisioning Manager — part of IBM Tivoli provisioning solution
FSR Feasibility Study Report
GDC Networks Fujitsu Network Team in India
HBA Fibre optic card that connects SAN storage to a server
HLD High level Design
HNG-x Horizon Next Generation ‘Plan X’
HNGxDBM HNG-x Design and Build Method
IDBM Infrastructure Design and Build Method
IFS System Interface Specification
IPR Intellectual Property Rights
Iso International Standards Organisation
KB Knowledge Base (article)
LLD Low Level Design
LST Live System Test (Pre-Production Test Environment)
LUN Disk. Logical Unit Number disk, units of which are used to create a SAN
NIC Network Interface Card
os Operating System
PCI Payment Card Industry
PCI DSS Payment Card Industry Data Security Standard — proprietary information security
standard
PHIL Platform Hardware Instance List — spreadsheet showing Platforms on a Rig
POA Post Office Account
POL Post Office Limited
PPD Physical Platform Design
PSD Project Solution Design
PSPID Platform Set Platform Instance Definition
PVB Product Version Baseline
ac Hewlett Packard Quality Centre (Test Management Tool)
Rig Defined network and server environment i.e. Integration, Test, Live
RM Release Management Team
ROM Rough Order of Magnitude estimate
SAN Storage Storage Area Network — configurable network storage
scm Software Configuration Management Team
SRR Service Readiness Review
TEM Tivoli Enterprise Manager
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
PageNo: 5 of 72
Ee)
FUJITSU
FUJ00232715
FUJ00232715
SDLC REPORT
FUJITSU CONFIDENTIAL
TIs Technical Interface Specification
TPM Tivoli Provisioning Manager
UAT User Acceptance Testing
UML Unified Modelling Language
VLAN Virtual Local Area Network
WWN World Wide Number assigned to connection in HBA
XML eXtensible Markup Language
0.5 Glossary
Term Det nm
Baseline A distinct version of a software deliverable or configuration item — as recorded in
Dimensions
Build Doc Computer file containing list of DPVBs
Central CM control
Configuration Management controlled centrally using Dimensions
Cron job
Linux command used for scheduling tasks to be executed sometime in the future
Dimensions
Software and document database
Discrete Platform
Server built on a single piece of hardware
Hosted Platform
1 of many servers built on Bladeframe hardware
Integration Platform List
Document that contains the list of Servers on the Integration Rig
Interim Baseline
An Interim Baseline is a version of a document which is stable and complete
enough to enable the use of it for a specific purpose — e.g. a design which is
missing sections describing Service elements, may still be stable/complete to
enable the first stage of implementation, or for Testing to derive Test Cases.
Local CM control
Configuration Management control exercised at the local level. May be via VSS or
cvs
Peak Fujitsu Incident and Release management system
PEN Testing PENetration Testing
Platform Server — there may be more than 1 instance of a server
Release A set of software changes that are to be deployed
Requirements
Documented and agreed requirements that describe what is to be provided
Storage Definition
Spreadsheet that defines the Storage disks for each platform
Sysware
Record in Dimensions that references Fujitsu and/or COTS software lodged on a
fileshare
0.6 Changes Expected
0.7 Accuracy
Fujitsu endeavours to ensure that the information contained in this report is accurate but, while every effort is made
to ensure the accuracy of such information, it accepts no liability for any loss (however caused) sustained as a
result of any error or omission herein.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 6 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
0.8 Information Classification
The author has assessed the information in this document for risk of disclosure and has assigned an information
classification of FUJITSU CONFIDENTIAL. This report is also subject to the Information Distribution statements in
Section 8.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
PageNo: 7 of 72
FUJ00232715
FUJ00232715
oe SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
1. Executive Summary
The purpose and scope of this report is to explain the current Fujitsu Software Delivery Life Cycle used
for Horizon Applications. It provides POL with information to understand how Fujitsu delivers this
element of the contracted services.
On 20 August 2020, POL requested an audit of Horizon by sending a letter to Fujitsu titled “Horizon
Audit’. Following a number of discussions between POL and Fujitsu, it was agreed by POL that Fujitsu
would prepare a set of reports on key topic areas identified by POL.
The spirit of the discussions between POL and Fujitsu was to share content that would allow both
organisations to confirm the efficiency of the current ways of working together, and to identify ways to
make meaningful improvements. Fujitsu believe in collaboration and welcome constructive suggestions
from POL.
This report explains the Software Delivery Life Cycle used for Horizon Applications (“SDLC Report”). It
follows the “Expanded Table of Contents for the SDLC Report” (COM/MGT/REP/4163) which was
shared with POL on 01 December 2020.
The SDLC Report covers the lifecycle from Requirements to Release excluding “Test” activities which
are subject to a separate report entitled “Testing & QA Report” (COM/MGT/REP/4166).
Fujitsu's Software Delivery Life Cycle for the Horizon application is based on widely recognised industry
standard approaches and has been refined to meet the needs of POL and the current Horizon Contract.
This Report explains how the SDLC is operated for POA and shows the many points of engagement with
POL and the joint processes throughout.
Fujitsu has endeavoured to ensure that the content of this report is correct as at the date of issue. Fujitsu
reserve the right to make changes to the way we work in the ordinary course of its operations and
business without obligation to update this report. POL should verify the position with Fujitsu before
relying upon any information or content from this report, as well as bearing in mind the requirements set
out in “Information Distribution” at Section 8 below.
The author has assessed the information in this report for risk of disclosure and has assigned an
information classification of FUJITSU CONFIDENTIAL. This report is also subject to further Information
Distribution statements at Section 8 in this report.
POL is invited to comment on this report to seek any additional clarifications it needs. Fujitsu will
endeavour to respond to any comments or clarifications requested and may, if it deems necessary,
provide an updated version of this report.
Fujitsu welcome the opportunity to provide this report.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 8 of 72
FUJ00232715
FUJ00232715
oe SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
2 Purpose & Scope
The purpose and scope of this report is to explain the current Fujitsu Software Delivery Life Cycle used
for Horizon Applications. It provides POL with information to understand how Fujitsu delivers this
element of the contracted services.
POL is invited to comment on this report to seek any additional clarifications it needs. Fujitsu will
endeavour to respond to any comments or clarifications requested and may, if it deems necessary,
provide an updated version of this report.
Fujitsu welcome the opportunity to provide this report and looks forward to a constructive dialogue with
POL.
3. Background & Introduction
On 20 August 2020, POL requested an audit of Horizon by sending a letter to Fujitsu titled “Horizon
Audit’. Following a number of discussions between POL and Fujitsu, it was agreed by POL that Fujitsu
would prepare a set of reports on key topic areas identified by POL.
The spirit of the discussions between POL and Fujitsu was to share content that would allow both
organisations to confirm the efficiency of the current ways of working together, and to identify ways to
make meaningful improvements that would enhance the working relationships and hopefully ensure a
better experience for the POL branches and their postmasters. Fujitsu believe in collaboration and
welcome constructive suggestions from POL.
This report explains the Software Delivery Life Cycle used for Horizon Applications (“SDLC Report’). It
follows the “Expanded Table of Contents for the SDLC Report” (COM/MGT/REP/4163) which was
shared with POL on 01 December 2020.
The SDLC Report covers the lifecycle from Requirements to Release excluding “Test” activities which
are subject to a separate “Testing & QA Report” (COM/MGT/REP/4166).
As a general comment, it is important to note that Fujitsu is only one supplier involved in the overall
delivery of end-to-end services to POL in relation to Horizon. The Horizon application also relies on the
working partnership between POL and its chosen partners — such as Verizon, Computacenter and Atos —
as well as external service providers such as banks and affiliated organisations. This applies to both the
IT systems and the operational processes in Horizon.
Although every effort has been made to avoid confusing jargon in this report, the very nature of this
aspect of the service delivered to POL necessitates the use of many acronyms and phrases that may
need expanding upon to ensure the correct understanding. Fujitsu accepts that further explanation may
be necessary and encourages POL to seek these clarifications.
Fujitsu has endeavoured to ensure that the content of this report is correct as at the date of issue. This
report has been prepared with the input of numerous Fujitsu individuals and attribution of any statements
made in this report should be made to Fujitsu only. In preparing this report, the authors have collectively
characterised and summarised many internal Fujitsu documents. They have also described processes
and procedures which have been established over many years and may not be in written form. Many of
the documents, processes and procedures described in this report are continuously updated and Fujitsu
reserve the right to make changes to the way it works in the ordinary course of its operations and
business without obligation to update this document. POL should verify the position with Fujitsu before
relying upon any information or content from this document in the future as well as bearing in mind the
requirements set out in “Information Distribution” at Section 8 below.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
PageNo: 9 of 72
FUJ00232715
FUJ00232715
oe SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
4 SDLC
4.1 Overview of Process
This section presents an overview of the HNG-x Project, including its engineering lifecycle, the roles of
the Fujitsu team that operate within the lifecycle and the products generated by it through the BAU
Change Process.
It is important to note that if a programme of work operates and is managed separately from HNG-x, it
may do so under a different set of processes, and may have differing roles and products. For example,
the current Belfast Exit (Pivot to Cloud) Programme, which is being directed by POL, has different roles
and processes from the HNG-x Project.
Previous versions of the HNG-x engineering lifecycle were historically based on the Fujitsu corporate
processes which, at the inception of the HNG-x Project, pertained to: the Fujitsu corporate Applications
Design and Build Method (ADBM), the Infrastructure (IDBM), the Test and Validation (T&V) equivalents,
and the Fujitsu standards for engineering and testing. In agreement with the POL (then Royal Mail
Group, now Post Office Ltd), the original HNG-x Development Strategy (now deprecated) expanded on
this and identified that the nature of the HNG-x Project required elements of ADBM, IDBM and T&V to
be combined to form a single new engineering lifecycle methodology (Design and Build Method): The
HNGxDBM.
Fujitsu are required to operate a generic Development Lifecycle methodology designed to deliver the
required Development Services as set out in Schedule B1.1 of the Horizon Contract, and specifically
Clause 3 of Schedule B1.1. The generic Development Lifecycle methodology is HNGxDBM.
The processes have been refined over time to follow changes to general working practises, including to
align with changes to Fujitsu's own processes where appropriate, as described in the Fujitsu Europe
Business Management System (EBMS) (Fujitsu Internal).
This document also describes the key roles of the Fujitsu team referenced in the HNGxDBM processes.
These roles are detailed in Appendix A - HNGxDBM Role Descriptions.
The diagram below shows key inputs and outputs to the lifecycle process.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 10 of 72
FUJ00232715
FUJ00232715
(oe) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
I
L
The process diagram above is explained in the next sections of this document.
4.1.1 HNGxDBM Product Descriptions
Product Descriptions provide details of each artefact potentially generated by the HNGxDBM
engineering lifecycle. Product Descriptions assist in giving the team member to whom the product is
allocated a clear understanding of what is required. It also forms the criteria/benchmark that the
completed product is evaluated against when it is submitted for review.
Where possible HNGxDBM Product Descriptions will conform to the overall structure and layout set out
in the HNG-x document template.
Some artefacts may be supplied by POL or a third party for a particular BAU Change programme and as
such, whilst being deposited in Dimensions, will not conform to the required HNG-x document templates.
In other instances, an artefact may be produced from a tool, in which case strict compliance with the
HNG-x document template may not be possible. Where such an exception exists, it will be noted in the
Composition element of the Product Description.
4.2 Define Solution
This section describes the initial phase of the SDLC: defining the solution.
4.2.1. Process Aims & Objectives
To clarify POL’s and HNG-x Project staffs understanding of the Stakeholder Requirements and the
scope of the agreed solution design.
Communication links will have been established with POL and other stakeholders for each group of
changes that are to be delivered in a Release. Details of such links can be found in the associated
Project Management documentation for that Release.
In other cases, details of POL or other stakeholders can be found in the associated Change Request
(RTQ) or Change Work Order (CWO) documents.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR _ Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 11 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
4.2.2 Process Inputs
* Change Request (RTQ) from POL containing statements / artefacts defining the required or
potential functionality or service change.
e Change Work Order (CWO) signed by POL containing statements / artefacts defining the agreed
scope of functionality or service change.
e Current HNG-x system including architecture, design artefacts and code.
e Outline Project Plan for the relevant Release (Project Management)
e POL and contractual constraints and obligations (see Service Descriptions, Contract Controlled
Documents, HNG-x Contract).
e Existing Business and System information - Use Cases, Solution and Technical Architectures,
related High Level Designs.
4.2.3 Process Flow: Define
This is an optional stage that is followed when Fujitsu believes the POL Requirements require further
clarification. An overview of the process is shown and each numbered box is explained in the table that
follows.
I Stage 1 — Requirements Gathering and Confirmation
(Step 1.1) I (Step 1.2) (Step 1.3) (Step 1.4)
i Receive Signed {4 Elicit I_I Reviewand I »I_ Identify Fujitsu
Study CWO I Stakeholder Verify Service
H Requirements Requirements Requirements
a (BRS)
(Step 1.7) (Step 1.6) (Step 1.5)
Review and Verify (*— Establish Requirements }*—} Generate Design
Design Proposal Traceability Proposal
(CSP/FSR) (CSP/FSR)
(Step 1.8) (Step 1.9)
Baseline Design ry Issue Design
Proposal (CSP/FSR) Proposal (CSP/FSR)
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 12 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
14 POL have identified I Receive Signed Study CWO POL 1.2
a potential need for I The POL Change Request (RTQ) has Fujitsu Change
a Business Change. I previously been processed, and the signed Management
Stakeholder associated CWO is now processed.
Requirements are
not wholly clear or a
definite preferred
solution has not yet
been identified or
agreed. Internal
POL governance
has authorised
spend and a Change
Work Order (CWO)
has been signed,
issued and received
by Fujitsu to
commence Design
or Feasibility Study
work,
1.2 Stakeholder Elicit Stakeholder Requirements POL 1.3
Requirements are The value of the CWO signed will contain Fujitsu Solution
not wholly clear or @ I sufficient time to workshop either Owner
lefinite preferres Requirements or design options with
solution has not yet I stoneholders ign oP Fujitsu Business
been agreed. nalys!
1.3 Signed CWO and Review and Verify Stakeholder POL 14
RTQ Requirements Fujitsu Solution
(optional) prior ROM I The established Stakeholder Requirements Owner
Response / are reviewed to verify that: Fujitsu Business
understood 3" Party I, The Requirements are clear, Analyst
involvement! unambiguous, well-formed and
requirements/ consistent
obligations .
«The scope of the change is clear taking
account of any prior agreements (e.g.
previous ROM process, third Party
involvement/ requirements/ obligations)
«The impact on existing HNG-x solution
and service obligations and capabilities
can be determined
«Any requirement for PEN Testing is
identified and recorded
* Any revisions are agreed with POL and
updates applied to the BRS
«¢ Optionally, and with POL’s involvement
and agreement, requirements can be
recorded in a separate requirements
catalogue (BRS) document if that is more
appropriate. This is required to be
reviewed by POL at least once, and a
Baseline produced which addresses the
output of that review.
14 Signed CWO and _I Identify Fujitsu Service Requirements Fujitsu Service 15
RTQ «Analyse the Business Requirements Owner
(optional) prior ROM I e — Discuss with the Fujitsu Solution Owner I Fujitsu Solution
Response / . Owner
* Fujitsu Service prepare any required
a
understood 3° Party Fujitsu Service Requirements
involvement/
requirements/
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 13 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
obligations / BRS.
1.5
Signed CWO and
RTQ
(optional) prior ROM
Response /
understood 3” Party
involvement/
requirements/
obligations / BRS /
Service
Requirements
Generate Design Proposal (Customer
Solution Proposal / Feasibility Study
Report
Note that the format of the output can be
either a Customer Solution Proposal (CSP)
or, where there are either multiple design
options or a potential design is evaluated, a
Feasibility Study Report (FSR).
Analyse the Business Requirements and
prepare a Design Proposal using the
appropriate Design Proposal Template:
This will comprise a summarised description
of the proposed solution which will:
« — Support the Change Proposal impacting
process
e — Identify to POL and CS Operations
stakeholders how their Requirements will
be met
Identify the primary areas of business
change in the context of the existing HNG-I
x Solution and Services
* Identify any impact on the existing HNG-
x Architecture and core Solution Designs
Identify the primary functional and non-
functional changes and the HNG-x
Solution components that will be
impacted
Identify the nature of any security
solution changes
* Identify the nature of any impact on
existing contractual or standards
compliance obligations or measures
Fujitsu Solution 16
Owner
1.6
CSP/FSR from 1.5
Establish Ret
The generated Design Proposal seeks to
address all previously identified Requirements
and show traceability within the document to
particular document sections, or to other
documents/collateral where Requirements are
addressed. If a formal and separate BRS is
being produced this is also referenced.
Note: ‘Addressing’ a requirement might
include requesting a HNG-x Concession (as
per the contract) where the requirement
cannot be fulfilled, or can only be partially
fulfilled.
irements Traceabi
Fujitsu Solution 17
Owner
1.7
CSP/FSR from 1.5
Optional BRS from
1.3
Review and Verify Design Proposal (FSR
or CSP) and (optional) BRS_
The proposed design output which will be for
POL consumption, and which may be passed
onto third parties must be as a minimum
formally and internally peer reviewed. A
Design walkthrough may be required either/or
both internally and with POL to assist
understanding of what will be issued.
Fujitsu Solution 1.8
Owner
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR _ Date
Page No:
STORED OUTSIDE DIMENSIONS
29-Jan-2021
14 of 72
SDLC REPORT
FUJITSU CONFIDENTIAL
Ee)
FUJITSU
FUJ00232715
FUJ00232715
1.8 CSP/FSR from 1.5 Baseline Design Proposal (FSR or CSP)
Optional BRS from and (optional) BRS
1.3 The proposed design output and (optional)
formal requirements catalogue (BRS) once
verified and reviewed is Baselined.
Fujitsu Solution
Owner
1.9 CSP/FSR from 1.5 I Issue FSR/CSP and (optional) BRS Fujitsu Solution
Optional BRS from I The verified and reviewed Design output Owner
13 (CSP/FSR and optional BRS) is delivered
formally via Fujitsu Document Management
to POL
End
4.2.4 Process Outputs and Product Descriptions
Some of the process outputs are shown below and described in the following sections:
e Business Requirements Specifications (BRS/CWO) (covering both functional and non-functional
requirements) from POL
e Feasibility Study Report
e Customer Solution Proposal
4.2.4.1
Business Requirements Specification
Document Type
BRS (and/or CWO): Business Requirements Specification.
Status
Purpose
Composition
Format and presentation
Responsibility
Quality Criteria
Quality method
Current: This product applies to BAU Change.
The BRS is a requirements catalogue that defines the business functionality that the
solution has to provide. The BRS may be produced by the Customer, or on behalf of the
Customer by Fujitsu or another third party.
A catalogue or enumeration of Business Requirements and Acceptance Criteria to be
delivered/managed for the BAU Project. This may be simply from the CWO document, or
presented as a separate catalogue ideally referred to in the CWO.
The Business Requirements Specification is owned by the Customer, and there is therefore
no HNG-x document template. If the Requirements are few, they may be managed from the
CWO documentation, and not documented separately
See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
The Business Requirement Specification is progressed as per the HNGXDBM
Requirements and Solution Design Process (Fujitsu internal document), and as such will be
subject to the standard quality controls and checkpoints defined for it.
Group review as defined in HNG-x Document Management and Control Process (Fujitsu
internal document). Approved and Baselined by the Customer.
Comments
‘Shared document. POL will have examples in their own document stores.
4.2.4.2
Feasibility Study Report
Document Type
FSR: Feasibilty Study Report
Status
Purpose
Composition
Current: This product applies to BAU Change.
Provides a detailed overview of the feasibility of a potential solution or range of solutions to
the Customer, as required designed to satisfy the Business Requirements (BRS), and may
compare options, risks, design and considerations and (v)ROM costs for each
The Customer Solution Proposal is required to present to the customer how the stated
Business Requirements will be addressed, and will cover:
* Scope
« Requirements
* Security and Data Protection (GDPR) considerations
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
Version:
Date:
Page No:
COM/MGT/REP/4168
UNCONTROLLED WHEN PRINTED OR
STORED OUTSIDE DIMENSIONS
1.0
29-Jan-2021
15 of 72
Ee)
FUJITSU
FUJ00232715
FUJ00232715
SDLC REPORT
FUJITSU CONFIDENTIAL
Format and presentation
Responsibility
Quality Criteria
Quality method
* Solution Description and potential solution options
* Risks, technical or other considerations
+ Potential (comparative) costs and timelines
(Fujitsu internal document),
‘See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
The Feasibility Study Report is progressed as per the HNGxDBM Requirements and
Solution Design Process (Fujitsu internal document), and as such will be subject to the
standard quality controls and checkpoints defined for it
Group review as defined in HNG-x Document Management and Control Process (Fujitsu
internal document). Approved by the Customer.
Comments I Details of implementation, especially where any Fujitsu Intellectual Property might be
exposed or IPR compromised, will not be contained within the FSR (as a customer facing
document) but rather documented later in the architecture and design phase in a PSD
(Fujitsu internal document).
Shared document. POL will have examples in their own document stores.
4.2.4.3 Customer Solution Proposal
Document Type I CSP: Customer Solution Proposal
Status I Current: This product applies to BAU Change.
Purpose I Provides a detailed overview of the proposed solution or solutions to the Customer, as
required designed to satisfy the Business Requirements (BRS).
Composition I The Customer Solution Proposal is required to present to the Customer how the stated
Format and presentation
Responsibility
Quality Criteria
Quality method
Business Requirements will be addressed, and will cover:
* Scope
+ Requirements (and traceability within the document)
* Solution Description and potential solution options
* Security and Data Protection (GDPR) considerations
+ Testing strategy
* Service Introduction strategy
(Fujitsu internal document)
‘See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document)
The Customer Solution Proposal is progressed as per the HNGXDBM Requirements and
Solution Design Process (Fujitsu internal document), and as such will be subject to the
standard quality controls and checkpoints defined for it
Group review as defined in HNG-x Document Management and Control Process (Fujitsu
internal document). Approved and Baselined by the Customer.
Comments
Details of implementation, especially where any Fujitsu Intellectual Property might be
exposed or IPR compromised, will not be contained within the CSP (as a customer facing
document) but rather documented in the PSD (as an internal document).
Shared document. POL will have examples in their own document stores.
4.3 Design Solution
This section describes the process of designing the solution.
4.3.1
Process Aims & Objectives
To clarify HNG-x Project staff's understanding of the Stakeholder Requirements and the scope
of the agreed solution design.
To balance re-use and creativity in approaching the solution and seek to ensure that the solution
is technically sound, fulfils all Requirements, can be produced with minimum risk and within
predictable time and budget constraints.
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 16 of 72
FUJ00232715
FUJ00232715
SDLC REPORT
fee)
FUJITSU FUJITSU CONFIDENTIAL
To provide an approved audit trail for each stage progression through the Requirements and
Design Phase.
To document products as defined and agreed by all stakeholders.
To provide the collateral required for Release acceptance and authorisation.
Process Inputs
IT and Compliance standards and Policies
Change Request (RTQ) from POL containing statements / artefacts defining the required or
potential functionality or service change
Change Work Order (CWO) signed by POL containing statements / artefacts defining the agreed
scope of functionality or service change
Business Requirements Specification
(optional) FSR documentation
Additional functional or service requirements contained within Fujitsu Design collateral
associated with the change (CSP/PSD)
Current HNG-x system including architecture, design artefacts and code
Outline Project Plan for the relevant Release (Project Management)
Customer and contractual constraints and obligations (See Service Descriptions, Contract
Controlled Documents, HNG-x Contract)
Existing Business and System information - Use Cases, Solution and Technical Architectures,
related High Level Designs
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 17 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
4.3.3
Process Flow: Design
An overview of the process is shown and each numbered box is explained in the table that follows.
I Stage 2 — Design Solution I
I I
a
I H (Step 2.1) H Step 2.2 Step 2.3 Step 2.4
i Receive Signed Generate Solution ‘Component Generate/Assure
I I Implementation I Design [—*) Integration and > Interface
i cwo i Work Breakdown Specifications
i i (PSD) structure in PSD (alsiTis)
Step 2.7 Step 2.6 Step 2.5
I Review and Verify Review and Revise CCDs, Baseline Interface
Internal Design (PSD) I «I Solution and Topic Specifications
gn (PSD) Architectures (FSIAISITIS)
I (if required)
Step 2.8 Step 2.9 Step 2.10 Step 2.11
Support of Release Issue and
I Baseline Design (PSD) Development and Acceptance / Approve
I (Interim Baseline) I Test Authorisation Acceptance
(RAMIRAB) Report
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR _ Date 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 18 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
24 POL have identified I Receive Signed Implementation CWO POL 2.2
a definite need fora I The POL Change Request (RTQ) has previously I POL Change
Business Change. _I een processed, and the signed associated CWO I Management
Stakeholder is now ready for work to be planned and
Requirements are I commenced.
understood and
defined, and a
solution is defined or
preferred. Internal
POL governance
has authorised
spend and a Change
Work Order (CWO)
is signed, issued
and received by
Fujitsu to
commence
implementation
work.
2.2 POL have identified I Generate Project Solution Design (PSD) Fujitsu Solution 2.2
a definite need fora I Analyse the Business Requirements (BRS) and I Owner
Business Change. I prepare an internal facing Design, expanding Infrastructure &
Stakeholder upon any existing design proposal Application
Requirements are I (CSP/FSR/CWO attachments) using the Architect(s)
understood and appropriate Design Proposal Template.
lefined, and a .
Solution is defined or This will comprise a summarised description of
preferred. Internal 1 proposed solution which wi
POL governance e Describe the business and service outcomes
has authorised that this solution must deliver
spend and a Change I « Provide a high level description of the
Work Order (CWO) proposed technical and operational solution,
is signed, issued sufficient to enable the production of High
and received by Level Design (HLD) by implementers
jitsu to
commence * Support dialogue with the Business and
implementation Service Requirements stakeholders in order
work. to demonstrate compliance to their
” Requirements
« — Identify the primary technologies that will be
used to deliver the solution
« Elaborate on the areas of business change
and their impact on the HNG-x Solution and
Services
e Identify internal and external interface
specifications which are expected/required to
change
Identify any impact on the existing HNG-x
Architecture and core Solution Designs
(liaise with Fujitsu Chief Technology Officer
and Applications / Infrastructure Architects to
agree impacts and / or dependencies arising
from solution)
« — Identify how the Functional and Non-
Functional Requirements will be met
* Identify the nature of any Security solution
changes
« — Identify the nature of any impact on existing
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 19 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
* contractual obligations or measures
Identify how the solution might be most
efficiently and effectively tested, including
interfacing with customer UAT, and third
party testing Requirements.
« — Identify how the solution will be delivered into
live service and the manner by which on-
going service operation will be achieved
2.3
PSD from 2.2
Component Integration and work breakdown Fujitsu Solution
structure Owner
The PSD will describe and plan the solution Fujitsu Architecture
changes required to realise Requirements to the
software component level. The PSD will then
describe packages of solution change functionally
(work breakdown structure) across components,
where applicable, to realise Requirements. This
will enable:
Implementation and Project Planning based
upon inter team or component dependencies
Identify how the solution might be most
efficiently and effectively tested, including
interfacing with customer UAT, and third
party testing Requirements
«The ability to understand the effect of
emerging or additional Requirements
«The ability to separate individual
Requirements if necessary from the overall
solution, if the project is re-scoped, or
individual Requirements are de-scoped
24
2.4
PSD from 2.3
Generate / Verify Interface Specifications Fujitsu Solution
Owner
The PSD will have identified any application,
technical or internal interface changes Infrastructure &
expected/required. Verify the status of any third I Application
party interface Architect(s)
25
2.5
Interface
Specifications from
24
Baseline Interface Specifications Fujitsu Solution
Once verified and reviewed all interface Owner
specifications are Baselined. Internal interfaces, if I Infrastructure &
there is the potential for change, should be as a_I Application
minimum given a status of Interim Baseline — Architect(s)
which enables implementation to start POL
Officially, external interfaces or changes to them
which are required to be met by the solution, are
owned by a third party and brokered via the
customer via their own documentation
management. In practice, Fujitsu is often asked
to author the third party interface documentation
‘on behalf of POL.
It is a distinct contractual requirement to meet
these interfaces as part of the solution, and
therefore such an interface must be clearly and
correctly versioned, and APPROVED (fully
Baselined) by all stakeholders prior to
implementation.
26
2.6
PSD from 2.3
Interface
Specifications from
25
Review and Revise CCDs, Solution and Topic I Infrastructure &
Architectures (if required) Application
Architect(s)
Update Contract Controlled Documents (CCDs)
or other Architecture documents as required, and
27
‘© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
Version:
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS Page No:
COM/MGT/REP/4168
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
as identified in the PSD.
2.7
PSD from 2.3
Review and Verify Internal Design (PSD)
The design output which will be for Project
execution, must be, as a minimum, formally
reviewed by those Teams expected to implement
the solution. A Design walkthrough may be
required to assist with understanding and
assurance of what has been designed
Fujitsu Solution
Owner
Fujitsu Architecture
28
2.8
PSD from 2.7
Baseline Design (PSD) and other Architecture
Design artefacts (Interim Baseline:
Once verified and reviewed all Architecture
Design artefacts, including the PSD are
Baselined. The PSD is a document which acts as
a specification and design roadmap for
implementation, and will very probably change to
reflect any design issues which arise throughout
the component design and implementation stage
Additionally many project plans can make a start
in areas where design is stable, but where it is
obvious that other areas require further definition.
The PSD, and any other Architecture Design
artefacts which have the potential for change
should be as a minimum given a status of
Interim Baseline — which enables
implementation to start
29
2.9
Architecture and
Design are
baselined for
implementation to
proceed
Support of Development and Test
Support design queries that emanate from
development, support teams or from Test.
«Any significant design clarifications are
written up in the PSD and/or relevant
Architecture Design artefacts, verified and
issued back to implementers. (Steps 2.2 / 2.4
12.7)
«Any change to Requirements must be
managed through Fujitsu Change
Management, and not accepted into the
scope of the project until commercial and
contractual considerations have been
addressed
* Functional Test planning will require input
from Architecture, and testable Requirements
must be fed into appropriate Test tooling (e.g
ac)
* Deployment / Migration Test planning will
require input from Architecture
« Release Management planning will require
input from Architecture
Fujitsu Solution
Owner
Infrastructure &
Application
Architect(s)
2.10
2.10
Functional Test
Release Acceptance / Authorisation
RAM/RAB.
Towards the conclusion of Live System Testing
(LST) the testable functional Requirements will
hopefully have been proven, reported upon and
any defects or inability to fulfil Requirements will
be understood, communicated to the Customer
and any resolution planning agreed.
SRR, Release acceptance and authorisation can
be prepared.
Fujitsu Solution
Owner
POL & Fujitsu
Infrastructure &
Application
Architect(s)
POL & Fujitsu
Business Analysts
POL & Fujitsu
Project Managers
2.11
‘© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS
COM/MGT/REP/4168
Version: 1.0
29-Jan-2021
Page No: 21 of 72
FUJ00232715
FUJ00232715
oe SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
To deploy software change to a Live, production I POL & Fujitsu
environment, Release authorisation is required Service Managers
This may take the form, for simple change, of POL & Fujitsu
TFSNow/Change Management records only. Requirements
Where change is more complex, multiple Managers
components and multiple requirements, Release
authorisation will require a Fujitsu presentation to
customer stakeholders.
Where there are distinct customer owned
requirements which must be proven and
evidenced a formal Release acceptance process
must precede Release authorisation.
Both Fujitsu and POL require SRR to be
assessed also prior to Release.
Once Live System Test is complete the SRR,
RAM and RAB meetings can take place to gain
explicit customer acceptance and approval or the
Release prior to migration of changes to Live.
211 Output from 2.10 Issue and Approve Acceptance Report (ACS) I Fujitsu Business End
Where the RAM/RAB process has been followed I Analyst
formally, at the point where Release authorisation I POL and Fujitsu
is given by the Customer, a summary of the Requirements
presentations and Customer authorisations is Managers
captured in the Acceptance Report, then issued
for Fujitsu and Customer stakeholder approval
4.3.4 Process Outputs and Product Descriptions
Some of the process outputs are shown below and described in the following sections:
e Project Solution Design (PSD) Interim Baseline (to enable implementation) if required
e Project Solution Design (PSD) Final Baseline (to record implementation) if required
e Interface Specifications — Various interface specifications (which represent contractual
obligations/requirements to implement) covering Technical (TIS), Applications (AIS) and Internal
(IFS)
4.3.4.1 Project Solution Design
Document Type I PSD : Project Solution Design
Status I Current: This product applies to BAU Change.
Purpose I Provides a detailed design description of the Customer approved solution relating to a
distinct BAU change, to the internal implementation teams, to enable implementation and to
satisfy the Business Requirements (BRS)
Composition I The Project Solution Design is required to present to internal implementers how the stated
Business Requirements will be addressed, and will cover:
* Scope
+ Requirements (and traceability within the document)
* Solution Description
* Security and Data Protection (GDPR) considerations
+ Testing strategy
* Service Introduction strategy
* Communications development activities and their related applications
Format and presentation I (Fujitsu internal document)
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document)
Quality Criteria I The Project Solution Design is progressed as per the HNGxDBM Requirements and
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 22 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Solution Design Process (Fujitsu internal document), and as such will be subject to the
‘standard quality controls and checkpoints defined for it.
Quality method I Group review as defined in HNG-x Document Management and Control Process (Fujitsu
internal document).
Comments I Fujitsu internal document.
4.3.4.2 Application Interface Specification
Document Type I AIS : Application Interface Specification
Status I Current: This product applies to BAU Change.
Purpose I An Application Interface Specification is a document that defines an application interface in
terms of data format and content. It defines an interface between HNG-x and an external
application
Composition I There will be an Application Interface Specification for each interface between HNG-x and
an external application
Each Application Interface Specification will cover:
* Scope
* Application Processes
* Message Types
Format and presentation I Most AIS documents are owned by POL or other third party so the format and presentation
will vary.
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Application Interface Specification is progressed as per the HNGxDBM Requirements
and Solution Design Process (Fujitsu internal document), and as such will be subject to the
‘standard quality controls and checkpoints defined for it.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
(Fujitsu internal document).
Comments I An AIS APPROVED prior to or under a related and signed CWO, is a contractual obligation
to implement.
Shared document. POL will have examples in their own document stores.
4.3.4.3 Technical Interface Specification
Document Type I TIS : Technical interface Specification
Status I Current: This product applies to BAU Change.
Purpose I The Technical Interface Specification covers the physical connectivity between HNG-x and
other parties from a host and network perspective
Composition I Typical topics include:
* Environment
« Medium of Transfer (Layers)
* Operational Considerations
* Security Considerations
« Recovery / Resilience
* Migration
«Testing
Format and presentation
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Technical Interface Specification is progressed as per the HNGxDBM Requirements
and Solution Design Process (Fujitsu internal document), and as such will be subject to the
‘standard quality controls and checkpoints defined for it.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS PageNo: 23 of 72
Ee)
FUJITSU
FUJ00232715
FUJ00232715
SDLC REPORT
FUJITSU CONFIDENTIAL
(Fujitsu internal document).
‘Comments
‘Shared document. POL will have examples in their own document stores.
4.3.4.4
Internal Interface Specification
Document Type
IFS : Internal interface Specification
Status
Purpose
Composition
Format and presentation
Responsibility
Quality Criteria
Quality method
Current: This product applies to BAU Change.
Internal or File Interface Specification: Usually specifies the interfaces between applications
within the HNG-x domain, although some IFS documents are owned by the Customer and
describe file formats deliverable to third-party systems.
Details the nature of an interface and the data exchanged across it.
The composition of an IFS will vary according to whether it is describing a file format, an
application interface, or a database specification. Commonly the document will prescribe
data formats, (field names, lengths and types) acceptable to an interface.
The IFS has no formal Template reference, and is not uniform in presentation.
‘See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document)
The Internal Interface Specification is progressed as per the HNGxDBM Requirements and
Solution Design Process (Fujitsu internal document), and as such will be subject to the
standard quality controls and checkpoints defined for it
Review by Circulation as defined in HNG-x Document Management and Control Process
(Fujitsu internal document),
Comments
Note that for some legacy interfaces the interface description may be present in the relevant
HLD.
‘Some of these are shared document. POL will have examples in their own document stores.
Some are Fujitsu internal documents.
4.4 Code, Build and Component Test
This section describes the process to build the solution components.
4.4.1. Process Aims & Objectives
The Code, Build and Component Test process defines the activities required for POA to build solution
components, based on an understanding of agreed Requirements, test them as individual components,
and integrate those components with others developed internally or by third parties and then Conduct
Component Integration Testing. The outputs from this process are placed under configuration
management control for use in the later System Validation and Integration Test process.
4.4.2 Process Inputs
e Customer Solution Proposal/Project Solution Design
e Application and Technical Interface Specifications
e Coding Standards
« Configuration Management Databases and records
e Entry and Exit Criteria for CIT stages
e Requirement definitions functional/non-functional (Requirements / traceability from CSP/ HLD)
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 24 of 72
FUJ00232715
FUJ00232715
SDLC REPORT
FUJITSU CONFIDENTIAL
Ee)
FUJITSU
4.4.3. Process Flow: Code, Build and Component Test
An overview of the process is shown and each numbered box is further explained below.
Design Build and Component Test Flow
Please note the following points:-
1. Although represented in a linear form it is not intended that there should be an absolute finish-start relationship
between deliverables and activities.
2. Component Integration Testing is an optional testing stage and only carried out when required. It is not a formal test
rig and does not cover all applications or platforms.
3. LLD’s are not applicable for all applications where the HLD is sufficiently detailed
STAGE 2
STAGE 4 Low level
Design — High revel Design &
Customer 9 Component I [—
Solution Test
Planning
Low Level Code Review
Design (where [4 Output
applicable)
Component
Coding (staces 2) Integration
Standards (es a }— Test Plan
rset
‘Component
Integration
CIT Entry & Test Report
Potential rework cycle Exit Criteria (stases
‘Component
Integration
Testing ‘Component
Reviewed Component Integrated and
Code H (4 Test Report Potential rework cycle Tested Code
/giasea)I Component —
Testing Tested Code . =
Direct if no
CIT for
. Component Dien
Component Potential rework cycle
TestPlan
STAGE 6
Product Support
Documentation Y
Note that although Component (& Integration) Test planning is identified in this Stage it may not actually generate a
plan before the code is cut and reviewed.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS PageNo: 25 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
An overview of the process is shown and each numbered box is explained in the table that follows.
Stage 1 : Design Customer Solution
Updated
Architecture
Documents,
Baselined
Business
and Service
nts
STEP 14
Generate or
update High
Level Design(s)
(HUD)
‘STEP
Generate or update
where appicable
‘STEP 42
Draft High oar ign I
Levelp Approve HLO Lege
£ 'g
i i
© ©
STEP 4.4 (
Draft Review & Ph
PawsioR Approve PPD PlatfSim
Design Desigh
P P
D D
) )
11
Project Solution
Design from
HNGxDBM
Requirements
Specify High Level Design (HLD) specifications~ I Lead Developer
these define the physical aspects of each
subsystem as defined in the Solution
Architecture.
Good practice is to have an architect on the team
who can manage the integration between the
different subsystems.
Ideally, the PSD will be at approved status.
However, under exceptional circumstances work
on the HLD may proceed against an interim
(document) baseline PSD after explicit
authorisation from the relevant Programme /
Project Manager.
Output - Draft High Level Design
1.2
Draft High Level
Designs
Review and Approve High Level Design See
The iterative nature of design-code-build-test may I Reviewer/Approver
result in coding starting before a final approved —_I Role Matrix (Fujitsu
version of the HLD is available. This is a risk internal document)
position that must be assessed by the Lead
Developer before coding starts.
The review checks the HLD against criteria of
correctness, completeness and consistency, to
1.3
‘© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
Version:
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS Page No:
COM/MGT/REP/4168
1.0
29-Jan-2021
26 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
enable a sensible implementation.
If, during this activity, errors are found in the
associated PSD they are handled through the
task management system and a software
fault/issue raised for subsequent action. Changes
to the solution need to be managed under change
control.
Output — Approved High Level Design
1.3 High Level Designs I Physical Platform Designs (PPD) are developed I Designer 14
or updated to describe the design details
pertaining to all products existing on the specified
type of platform including the list of products and
the number of instances of the platform in the
operational solution. The design details include
the interfaces / characteristics that the
products present / require with the storage;
network; processor; operating system; security;
resilience and sub-systems.
Output — Draft Physical Platform Design
1.4 Draft Physical Review and Approve Physical Platform Design _I See
Platform Design using Email Reviews Reviewer/Approver
Output - Approved Physical Platform Design I Role Matrix (Fujitsu
internal document)
An overview of the process is shown and each numbered box is explained in the table that follows.
Stage 2 : Low Level Design & Component Test Plan
Note: LLD’s are only used where the HLD does not contain sufficiently detail to complete development
st st st ey Low
I =P eP a ae le
Decifire cbt aa Lo
te a ite Aigo, af
.
. 5
Generate Rey
Plesorngu Apple PI
ration Plaidigu Coatigu
: ratign etait in
; t ° Dimensichs
i a
:
st
= I EB ‘comp
Le} pegs Ep ae (is 96tton
Ce nen Gondiite Pass Tela
Ce eron Tre ecqP ore)
required) c cre)
5
Whilst the Compdhent (& Integration) Test planning is identified here the plan may not be generated or completed until
,
)
code is completed and reviewed.
241 High Level Design Deconstruct HLD and identify components to be Lead Developer 2.2
developed. The component level may be at or
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 27 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
above the code module level and will often be at
the DLL or executable level. 25
Identify where components must be integrated and
tested as part of this phase.
22 Deconstructed High I Generate LLD for Applications and Infrastructure Lead Developer 23
Level Design elements if applicable for the product application, I Developer
otherwise continue to use HLD if sufficiently
detailed.
2.2 [I/F] I Physical Platform Generate Platform Configuration Details Platform Owner 23
Designs Architect / Lead
Developer
2.3 Low Level Design - Provide traceability by cross referencing LLDs to Architect / Lead 24
Traceability HLD and ensuring that the HLD refers to all Developer
constituent LLDs
2.4 Low Level Design — Quality Review LLD. Lead Developer 3.41
ee ONa' at apoicable for If the LLD can be brought to final approved status Developer
GHappheations ghereite I before coding begins then that option is taken Sign-off
HLDis sufcienty detaied) I However, the iterative nature of design-code-build- I <0
test may result in coding starting before a final R im
approved version of the LLD is available. This is a Role Mat revit
risk position that must be assessed by the Lead ole Matrix (Fuji Su
Developer before coding starts. internal document)
The review checks the LLD against criteria of
correctness, completeness and consistency, to
enable a sensible implementation.
If, during this activity, errors are found in the
associated HLD(s) they are handled through the
task management system and a software
fault/issue raised for subsequent action. Changes
to the HLD are made under the cover of the blanket
CP raised for that purpose.
Output - LLD Review Output
Output - Signed off LLD
2.4 [VF] I Platform Quality Review Platform Configuration details Platform Owner
Sree details I The objectives of this activity are much the same _I Lead Developer
vale i as the Quality review for the LLD i
Dimensions (CMDB) 2 Sign-off :
See
Reviewer/Approver
Role Matrix (Fujitsu
internal document)
25 High Level Designs I Plan component level testing and, if identified in Lead Developer 26
Step 1.1 earlier, where components require Developer
integration for testing.
May also involve :
This activity will often take place in parallel to the I Torn;
development of the LLD and a degree of iteration is I 'St Design
to be expected
2.6 Component Test Generate Component/Unit Test Plan (CTP/UTP) Lead Developer 27
Plans Where identified generate Component Integration I Developer
Test Plan (CITP)
Note: The production of the physical Test Plan may
not take place until during or even after the coding
has taken place.
27 CTP/CITP Review CTP (and CITP) See 44
Reviewer/Approver_ I cTp
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 28 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
The iterative nature of design-code-build-test may
result in coding starting before a final approved
version of the CTP is available. This is a risk
position that must be assessed by the Lead
Developer before coding starts.
The review checks the plans against criteria of
compliance to HLD/LLD, completeness of testing
‘scope and consistency of testing across related
components.
The review of the CITP also considers the
consistency of the integrated testing to be
conducted with the testing already undertaken at
individual component level
Output - CTP Review Output
Role Matrix (Fujitsu
internal document) I 5 4
CITP.
An overview of the process is shown and each numbered box is explained in the table that follows.
Stage 3 : Code and Inspect
y
Pp
)
STEP.
Infrastr 320
Con
pred Infate
oder
Product
vightow st 5 x a
Loel Rev EP. =z EP -—
HLOFELO sedate Revd & adw
i) jor
3 P
Componen Component
1 Testi [4 Appl or Unit Test
m seb Plan
Sard __ mn
co
31 HLD/LLD complete Review HLD/LLD and CTP/UTP prior to coding Lead Developer 3.2
and signed off (see 2.6) Developer 32
(V/F]
Note: The production of CTP may not take place
until during or even after the coding has taken
place.
3.2 Coding Standards Generate code, applying relevant and applicable I Developer 3.3
available standards and using tools identified for
development activities (see examples in
Appendix B)
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 29 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
During this activity the Lead Developer monitors
progress at a level commensurate with the
Developer's skill and experience
3a
FI
COTS Product
available
Configure Infrastructure COTS product
Developer
3.3
3.3
CTP/CITP
Review CTP/UTP during coding/configuration
activity and discuss inconsistencies and
potential changes with Lead Developer.
Update CTP (and CITP) if required
Output — Updated CTP (and CITP)
Developer
Lead Developer
3.4
3.4
Undertake code review using Crucible (see
screenshot below) or HNGx Generic Code
Review Template (Fujitsu internal document) to
generate comments / defects
Commit code to Source Code Control System.
Currently using a variety of systems but
standardising on Fujitsu approved COTS
Subversion (SVN).
Output - Code Review Output
Output - Reviewed Code
Lead Developer
Developer
44
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS
COM/MGT/REP/4168
Version: 1.0
29-Jan-2021
Page No: 30 of 72
FUJ00232715
FUJ00232715
(oe) SDLC REPORT .
FUJITSU FUJITSU CONFIDENTIAL
Sample Crucible code review screenshot (with redactions as necessary):
® Poa-R-s634 =o
Sm «0 eens 4
(CBB.4850: InstalPINPadBLO (migration)
a:
An overview of the process is shown and each numbered box is explained in the table that
follows.
Stage 4 : Component / Unit Testing
somponen ymponen Componen
Baty trea ‘ret
casi tates —
®
)
st
EP
~ CT Bit oon Soe —
Componen fo
rate snebest
T
Pp
)
Note: The production of the physical Test Plan may not take place until during or even after the coding has taken
place. C/T Plans/Report maybe one single document depending on the size and nature of the project.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR
Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 31 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT ~
FUJITSU FUJITSU CONFIDENTIAL
44 CT Entry Criteria Generate CT environment including any Developer 42
Reviewed Code harnesses, emulators and tools (see examples
CIP in Appendix B)
Conduct component tests using CTP/UTP.
Correct code where found to be defective.
Repeat this cycle until CTP/UTP tests have all
been executed successfully
Commit code for CIT to Local CM control.
Output — Individual tested components
4.2 CT Exit Criteria Review test outcomes against CT Exit Criteria Lead Developer 4.1 if
and repeat/rework if not met N
Output — Have Exit Criteria been met? 4.3 if
Y
4.3. I Component Tested I Generate CTR. This may be a free-standing Developer 44
Code report or additional sections at the end of the
CTP providing the results of the tests passed or
failed. In this case the document should be
identified as a combined Plan and Report
44 Component Test Quality Review CTR See 5.1 if
(Plan and) Report The review checks the Report against criteria of I Reviewer/Approver I CIT to
completeness of planned tests and the Role Matrix (Fujitsu I take
correction of all defects identified. internal document) I place
The HLD/LLD is also checked to make sure that
it remains consistent with the resultant code.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 32 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
An overview of the process is shown and each numbered box is explained in the table that follows.
Stage 5 : Component Integration Testing (CIT)
Note: Depending on the size and nature of the project CIT plans and reports for different deliverables may be combined into one.
STEPS integrated &
Component Unit CIT Entry i Tested
Tested Code CIT Et Cite
Contoured I STEBS1 - STER55 STEPSS
s Cond Review outcome
emponents Integration tests itera
Not
Component Component
Integration Test Defect and Test Integcation Test
porters ea, Progress Data Repo
y
‘STEP S7
Build and
Delivery
5A Component Tested Integrate components to become ‘target of Build Technician 5.2
Code (internal) testing’ Developer
Component Tested Output — Integrated components ‘Target of I I cad Developer
Code (third party) Testing’
Infrastructure COTS
Product
5.2 CIT Entry Criteria Generate CIT environment as required Developer 5.3
‘Target of Testing’ Conduct component integration tests using Lead Developer
cITP CIT.
Repeat this cycle until CIT tests have all been
executed successfully
Commit CIT code to CCM control
Output - Integrated and tested components
5.3 Testing complete Incident Management. Developer 54
Upon discovery of defects the tester raises an _I Lead Developer
issue using the POA Peak Defect database /
Jira. The role of the Lead Developer is to verify
the nature and severity of the incident before it
is committed to Peak
Whether a component can be subjected to
another type of testing will depend upon whether
it satisfied the exit criteria or if any failure
conditions were fatal.
5.4 CIT Exit Criteria Review test outcomes against CIT Exit Criteria I Lead Developer 5.2 if
and repeat/rework if not met N
5.5 if
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 33 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Output — Have Exit Criteria been met?
55 Component Generate CITR. This may be a free-standing Developer 56
Integration Tested report or additional sections at the end of the Lead Developer
Code CITP providing the results of the tests passed or
failed. In this case the document should be
identified as a combined Plan and Report
5.6 Component Review CITR Developer 5.7
Integration Test (Plan I The review checks the Report against criteria of I Lead Developer
and) Report completeness of planned tests and the
correction of all defects identified.
The HLD/LLD is also checked to make sure that
it remains consistent with the resultant code.
Output - CITR
5.7 Build and Delivery Once the code components have been Build Engineer End
successfully tested and no more defects are Developer
raised out of CIT then the developer can take it
out of the source control system and upload it to
Dimensions (CMDB) in to the appropriate
product area. The SCM Web tool is then used to
produce and deliver the baselines (PVB) along
with the handover note to the Integration Team
who will then package it in to a (DPVB).
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
PageNo: 34 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT ~
FUJITSU FUJITSU CONFIDENTIAL
An overview of the process is shown and each numbered box is explained in the table that follows.
Stage 6 : Produce Support Documentation
‘System
Requireme -—
nts
—Speciicati—
on
STEP 6.1 STEP 6.2 STEP 6.3 STEP 6.4
Systom & Understand Understand I Generate I Review and
‘Architect System Documentation Support ‘Approve
Functionality Standards Guide(s) SPG(s)
High /
Low r— ‘Support
Level Guide
— besigns —
Various
Interface —_
Specification
eisai
Step Current Situation / Activities Accountability Next
Inp Step
6.1 Requirements, Review the systems requirements specification, I Designer 62
Architectures, solution architecture, HLDs and various Interface I Developer
Customer Solution Specifications to understand the system from a
Proposals, High / user's perspective.
Low Level Designs —_I Understand the following:
and Interface oar
Specifications at a « The system functionality
formally reviewed * How the users interface with it
draft as minimum © What interfaces there are to other systems
6.2 System Functionality I Investigate current examples of user Designer 63
understood documentation. Understand documentation Developer
standards to be followed.
6.3 Documentation Identify information to be included in the Support I Architect 64
standards Guide (SPG) Designer
understood Subjects to include: Developer
* Outline of the purpose of the product
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 35 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
- — function
- the way in which it performs the function
- outline of the code standards used, and
the language used
Documentation
- List all relevant product documents.
(titles and references) i.e.
Requirements, HLD, LLD etc
Code Source Repository
- Location of code within repository —
required by SSC
Code paths
- — which procedures call which other
procedures
- what parameters are passed, and what
the procedures do
- what is output from each procedure
Platforms
- identify platforms (servers /
workstations) that support will require
access to, in order to support the
product
Errors
- what errors the software can produce
- which procedures produce them
- what events/activities cause them to be
produced
- what to do about them when they are
produced.
- _ list of known deficiencies in the product
- expected clearance dates for known
deficiencies
- workarounds in place to overcome
known deficiencies
- _ identify location of all relevant log files
Events / KBs
- where the application produces
harvestable Events then those need to
be enumerated / detailed for
consumption through Netcool / SMC.
- Associated KBs need to be used /
detailed where;
a) solutions to known errors have
been deferred
b) detail in the KB will significantly aid
support.
Messages
- where a product uses an internal
message format then details of the
message format and examples of
decoding these
Public API - Either in the support guide or as
a separate document (AIS)
- details of all of the functions that can be
called
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref:
Version:
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS Page No:
COM/MGT/REP/4168
1.0
29-Jan-2021
36 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
- what they do
- what parameters can be passed to them
- what the parameters mean
- what options/defaults for each
parameter
- what is output from these functions
© — Support route
- How to contact support
- what hours they work
- what level of service is offered
« Expected clearance timescales for problems
of different severity
Document information in draft Support Guide
(SPG)
6.4 Draft SPG(s) Review Support Guide (SPG) with all internal I See HNG-x End
available authorities Approver /
Output - approved SPG(s) Reviewers Role
Matrix (Fujitsu
internal document)
4.4.4 Process Outputs and Product Descriptions
Some of the process outputs are shown below and described in the following sections:
e High Level Design (HLD) documents derived from the related Customer Solution Proposal
(CSP) / PSD
e Physical Platform Design (PPD, where applicable)
e Low Level Design (LLD, where applicable) documents derived from the related High Level
Design (HLD)
« Component Test / Unit Tests Plans (CTP)
e Component Integration Test Plans (CITP) for those components to be integrated and tested in
this phase
« Component Test Reports (CTR) that may be addenda to the relevant CTP
« Component Integration Test Reports (CITR) for those components to be integrated and tested in
this phase
4.4.4.1 High Level Design
Document Type
HLD : High Level Design
Status
Purpose
Composition
Current: This product applies to BAU Change.
‘A High Level Design is a document that describes the design for a new application, or for
changes to an existing application.
There may be one or more High Level Design documents for each new or changed
capability.
The High Level Design creation or update is derived from Project Solution Design (PSD) or
equivalent design documentation, and will cover:
* Scope
* Underlying system design
* Work Package/TaskiRequirements Traceability from BRS/PSD or other key
design collateral as appropriate
+ Application development activities for applications
+ Infrastructure development activities and their related applications
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 37 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
+ Systems management, supportability or other non-functional Requirement
development activities and their related applications
The High Level Design informs potential Low Level Design and Development activities
Format and presentation I see template for Applications (Fujitsu internal document) or both, or
See template for Infrastructure (Fujitsu internal document).
Where HLDs (such as historically in the Web Services and Counter areas) are substantially
model based and may not conform fully to the identified templates.
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document),
Quality Criteria I The High Level Design is progressed as per the HNGxDBM Requirements and Solution
Design Process (Fujitsu internal document), and as such will be subject to the standard
quality controls and checkpoints defined for it
Quality method I Group review as defined in HNG-x Document Management and Control Process (Fujitsu
internal document),
Comments I (Fujitsu internal document)
4.4.4.2 Physical Platform Design
Document Type I PPD : Physical Platform Design
Status I Current: This product applies to BAU Change.
Purpose I To capture in a single artefact all relevant design details pertaining to all products existing
cn the specified type of platform including the list of products and interfaces/characteristics
that the products present/require with the: storage; network; processor; operating system;
security; resilience etc. sub-systems, This information is used in instantiating the solution
Composition I The PPD cover the following areas
+ Existence of the platform in Live and Test environments
+ Geographical Data Centre Locations
+ Aspects of Hardware / memory specification etc
+ Software Product Stack
* Operating Systems
+ Common software products
+ HNG-x Baselines to be applied
Format and presentation I See Live PPD Template (Fujitsu internal document)
Responsibility I Platform Owner, i. a Solution Architect or Designer
Quality Criteria I The Platform Physical Description is progressed as per the HNGxDBM Requirements and
Solution Design Process (Fujitsu internal document), and as such will be subject to the
standard quality controls and checkpoints defined for i.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
(Fujitsu internal document),
Comments I (Fujitsu internal document).
4.4.4.3 Low Level Design (it’s are not applicable for all applications where the HLD is sufficiently detailed)
Document Type I LLD : Low Level Design
Status I Current: This product applies to BAU Change.
Purpose I To capture the lowest level of design for a given component. This provides linkage between
the High Level Design and the code produced which supports the requirements for the
given component.
Composition I There may be one or more Low Level Design documents for each new or changed
capability
The Low Level Design is derived from the High Level Design and will cover:
* Scope
* Underlying component design at function and class level
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR _ Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 38 of 72
FUJ00232715
FUJ00232715
(ce) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
«Error handling
+ Logging and other non-functional requirements
Format and presentation I (F yjtsu intemal document)
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Low Level Design is progressed as per the HNGxDBM Code, Build and Component
Test Process (Fujitsu internal document), and as such will be subject to the standard
quality controls and checkpoints defined for it.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
(Fujitsu internal document).
Comments I (Fujitsu internal document).
4.4.4.4 Component Test Plan
Document Type I CTP : Component (Development Unit) Test Plan
Status I Current: This product applies to BAU Change.
Purpose I This product details the requirements and actions needed to perform the set of tests
required to confirm the successful implementation of a given component in accordance with
the design. Completion of the CT Plan should prove that an attribute of the ‘test object!
‘satisfies the agreed requirements. Correct completion of each CT Plan contributes towards.
the delivery of a quality solution.
Composition I For non-Java code the CTP will describe the tests required and run to demonstrate the
satisfactory development of the component
For Java code this may be a document or be made up of a Java program executing the
tests.
Format and presentation I Although uniform in presentation, the CTP currently has no formal Template reference.
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Component Test Plan is progressed as per the HNGxDBM Code, Build and
Component Test Process (Fujitsu internal document), and as such will be subject to the
‘standard quality controls and checkpoints defined for it.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
(Fujitsu internal document).
Comments I Where the BAU change is relatively small the CTP will combine the CTR into an
amalgamated documented - see CTR.
(Fujitsu internal document).
4.4.4.5 Component Integration Test Plan
Document Type I CITP: Component integration Test Plan.
Status I Current: This product applies to BAU Change.
Purpose I This product details the requirements and actions needed to perform the set of tests
required to confirm the successful integration of a set of related components, or functional
tests to be performed in an integrated Test environment, in accordance with the design.
Correct completion of each CIT Plan contributes towards the delivery of a quality solution,
Composition I For non-Java code the CITP will describe the tests required and run to demonstrate the
satisfactory development of the component
For Java code this may be a document or made up of a Java program executing the tests.
Format and presentation I Although uniform in presentation, the CITP currently has no formal Template reference.
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Component Integration Test Plan is progressed as per the HNGxDBM Code, Build and
Component Test Process (Fujitsu internal document), and as such will be subject to the
standard quality controls and checkpoints defined for i.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 39 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
(Fujitsu internal document).
Comments I Where the BAU change is relatively small the CITP will combine the CITR into an
amalgamated documented — see CITR
(Fujitsu internal document)
4.4.4.6 Component Test Report
Document Type I CTR: Component Test Report.
Status I Current: This product applies to BAU Change.
Purpose I This product is used to provide summarised information about the testing activity for the
Component Test. It seeks to enable members of the management team to assess the
progress of testing and highlight issues that require intervention. It also provides an audit
trail for the Build & Test phase.
Note that this document may manifest itself as an update to the Component Test Plan in
which case the Plan and Report become a single document.
Composition I Tests conducted and success/failure status
List of incidents (optional as can be produced from Peak)
Test metrics
The CTR may be generated as an addendum to the CTP in which case the section
headings identified in the CTR template is copied over to the CTP for updating. CTRs may
also be generated separately.
Format and presentation I Although uniform in presentation, the CTR currently has no formal Template reference.
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Component Test Report is progressed as per the HNGxDBM Code, Build and
Component Test Process (Fujitsu internal document), and as such will be subject to the
‘standard quality controls and checkpoints defined for it.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control
Process(Fujitsu internal document).
Comments I (Fujitsu internal document)
4.4.4.7 Component Integration Test Report
Document Type I CITR : Component Integration Test Report
Status I Current: This product applies to BAU Change.
Purpose I This product is used to provide summarised information about the testing activity for the
Component integration Test. It seeks to enable members of the management team to
assess the progress of testing and highlight issues that require intervention. It also
provides an audit trail for the Build & Test phase.
Note that this document may manifest itself as an update to the Component Integration Test
Plan in which case the Plan and Report become a single document.
Composition I Tests conducted and success/failure status
List of incidents (optional as can be produced from Peak)
Test metrics
The CITR may be generated as an addendum to the CITP in which case the section
headings identified in the CITR template is copied over to the CITP for updating. CITRs
may also be generated separately.
Format and presentation I (Fujitsu internal document)
Responsibility I See HNG-x Reviewer & Approver Role Matrix (Fujitsu internal document).
Quality Criteria I The Component Integration Test Report is progressed as per the HNGxDBM Code, Build
and Component Test Process (Fujitsu internal document), and as such will be subject to
the standard quality controls and checkpoints defined for it.
Quality method I Review by Circulation as defined in HNG-x Document Management and Control Process
(Fujitsu internal document).
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 40 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Comments I Where the BAU change is relatively small the CITP will combine features of the CITR into
an amalgamated documented,
(Fujitsu internal document)
4.5 Integration (Application Package)
This section describes the build and maintenance of the OS and application software.
4.5.1. Process Aims & Objectives
To collect and prepare system components that are to be released into the test or live environment.
Integration is the first place in the process where hardware and software that is representative of the Live
Rig is built using the same deployment methods and tools
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 41 of 72
FUJ00232715
FUJ00232715
(oe) SDLC REPORT .
FUJITSU FUJITSU CONFIDENTIAL
4.5.2 Process Flow
An overview of the process is shown and each numbered box is explained in the table that follows.
Integration (Application Package)
STAGE 1 STAGE 2 STAGE 7 Test I Functional /
Build Integration > I Build Integration I IS!» Regression
Infrastructure Piatforms Test DPVBs Testing
ry
Initial
STAGE 6 Build
STAGE 3 Maintain i
> I Create PVB Integration >
and DPVB Provisioning
Environment TEM/
TPM Test Fail
STAGE 4
Maintain
Code Build and
Component test > I Batiorm / ”
Spreadsheets} I I»! Dimensions I
\ \ STAGE 8
v Create Build
Lists for
STAGE 5 Platforms and
> I Maintain Incremental
Product Tags Updates
STAGE 9
Update
Security
Patches
the SDLC
Note: Stage 9 is included as part of the overall Integration Application Packaging process but it is not strictly part of
Stage 1 : Build Integration Rig Infrastructure
is set up.
This section describes the activities required to build the underlying hardware infrastructure and
virtualisation software to support the deployment of a platform or platforms on the Integration Rig. The
steps are to check that the hardware and software resources and the Physical Platform Design (PPD) is in
the correct state. The PPD is used at this stage to determine the basic configuration, such as the OS, disk
and memory requirements. The network is configured for the platform and any required network storage
ation /
Step Current S
Input
Accountability Next
Step
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR _ Date 29-Jan-2021
STORED OUTSIDE DIMENSIONS PageNo: 42 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
44 CP requesting new I Determine if hardware available within Integration I Integration Team I 1.2
platform/platforms I). May depend if new platform is discrete or
hosted on current Bladeframes
Output - Request for new hardware if required
1.2 PPD(s) for new Review PPDs (See “sample PPD screenshot” Integration Team I 1.3.
Platform(s) below) Platform Owners
Output - Approved PPDs
1.3 Relevant PPDs Set up hardware Integration Team 14
* Allocate physical space for Discrete Servers
* Create physical or virtual blades with
required resources documented in PPDs
« Update internal Integration Platform List in
PowerPoint.
Output — Platforms/Processor Resource
available
Output - Updated Integration Platform List
1.4 Relevant PPDs Connect platforms to network Integration Team 15
Network Definition « On discrete platforms connect defined GDC Networks
Network Interfaces to available switch ports
* Configure switch ports as required for correct
VLANS etc. May need GDC networks
* Configure NICs in pserver definitions for
platforms hosted on Bladeframes
Output — Platforms network enabled
15 Relevant PPDs Configure storage for platforms. For platforms on I Integration Team
Storage Definition BladeFrames or discrete servers, requiring
additional SAN storage, the storage must be
configured in the Eternus Storage and in the SAN
switches.
« For Bladeframe platforms add HBAs as
appropriate to the pserver definition for the
platform.
«Inthe Eternus Storage a LUN group must be
created containing LUNs appropriate to the
disks defined for the platform in the PPD. A
host group is then created for the platform
configuring the WWNs of the HBAs defined
in the pserver for Blafeframe platforms or the
WWNs of the physical HBAs for discrete
platforms.
« — Zoning must then be configured in the SAN
switches to link the HBAs of the pservers to
the appropriate ports on the SAN storage.
« Update the disk storage array, internal
Storage_DX80 and Storage_DX200
spreadsheets in PowerPoint with the
additional information.
Output - Platforms configured with storage
ready for provisioning with OS
Output - Updated storage spreadsheets.
Sample PPD screenshot (with redactions as necessary)
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date:
29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 43 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
~ z ElArangeall Hide -
Preview Selection bE! Freeze Panes > ie Windows ~ ¥:
B c D i F G H 1
4 A i
6 I J
66
The Windows server platform foundations provide default drive eters for certain file
Isystems. Please use this section if this platform does not use the standard drive letters.
letter
69 0S Boot Disc
70 [DVD drive
71 (0S Page File
2
Bl
741.7 Product Stack
This section indicates which “Common Products” are to be Installed on the specific platform
75 1.7.1 Common Products type. Other “Shared Products” should be listed individually in section 1.7.2.
EE Common Product Groups Available on OS? _ Required in this platform? Comment
The available Common Product Groups are listed below. Please note the following:
(1) The precise set of products varies according to the platform foundation and not al common product groups are available on every platform foundation.
TT _{2) These Common Product Groups are not mandatory, the use of each Common Product Group should be considered individually for each platform type.
Please indicacte which common product groups are Required in this
78 needed for this platform type in this section below. Win Serv platform?
79 [Remote Access Available Y¥
80 SupportTools ‘Available Y
81 [Software Distribution ‘Available Y
82 [Event Monitoring & Fillenng: ‘Available: Y
83 [Enterprise Monitoring Available Y
84 [Time Synchronisation Available Y
85 [TWS Scheduling ‘Available W
86 [Secure Logon. WA Y Not available on this OS
87 (Antivirus: ‘Available Y
88 Performance Monitoring Available: Y
89 (Back ‘Available Y
90 I S
coal
This section indicates the specific “Products” that are to be installed on the specific platform
type, in addition to the “Common Products” listed in section 1.7.1.
Product Product COTSPackageNamei COTS COTS
Phase" Sequence applicable (or sysware) Version Supplier Product Owner
‘Windows 2003 R2 Enterprise Edition 32-bit
94 I(w2k3120032) 1 1
96 Windows Server 2003 SP2 T 1 2 -
> Version Control I PPD I ValidPlatformtypes I ValidserversoS .. @ I I
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 44 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
Stage 2: Build Platforms (Including OS)
This stage describes the steps required to provision the platform instances on the hardware configured in
Stage 1. The computer.xml containing the platform information and the PSPID (Platform Set Platform
Instance Definition) that contains the software products and ordering is uploaded in to the deployment
servers TEM and TPM. The software is then despatched (deployed) on to the Integration rig, which
creates the Platforms, deploys the OSs and the software products. Checks are then performed to test that
the platforms are running and visible to the network and that the software products have deployed.
Step Current Situation Activ’ Accountability Next
Input Step
241 Approved Platform Create computer.xml for import into TPM Integration Team 2.2
Hardware Instance I ¢ — Computer.xml created on the TPM server __I (BRA Builds)
List (PHIL), Physical and then imported into TPM through the
(ep) ter TPM GUI to create server definition in TPM
Design/Architect with Output — Server definition created in TPM
Platform attributes
2.2 Product Stack Generate Platform Set Platform Instance Integration Team 2.3
Spreadsheet in Definition
Dimensions « — Software stack generated in TPM/TEM
(List of products which consists of an ordered list of DPVBs
required by platform (packages which will be installed on the
based on PPD) platform.
Output - Software stack for platform
generated in TPM/TEM
2.3 Server Definition on Dispatch PSPIDs and Software Integration Team 24
TPM * Computer XML loaded into TPM to allow
Software stack deployment and build of the Physical
Computer XML for Platform
deployment to (Tivoli I « — PSPID loaded into TPM/TEM to allow
Provisioning deployment and build of the Physical
Manager) TPM Platform
Updated Product Output - Test TPM attributes of the Physical
Tags used to define Platform match the Specification in the PHIL
the Psychical and PPD
Platform
Updated PSPID used
to define the
Psychical Platform
24 TPM updated and Provision Platform Instances Integration Team 25
ready to build i isionit
Physical Platform Trigger O/S provisioning from TPM
* Software package installation triggered
from TPM/TEM
Output - Fully commissioned environment
Output — Integration Environment Hardware
Commissioned
2.5 Installed and Execute Tests Integration Test End
Configured Platform I, — platform provisioned with O/S and currently I Team
available Baselines.
* Platform is ready to receive subsequent
deliveries of baselines from
development/integration for installation and
testing
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date:
29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 45 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
Stage 3: Create Product Version Baselines and Deployable Product
Version Baselines
PVBs are created by the Development teams and consist of the compiled code (executables and
supporting components e.g. .exe, .DLL), run time scripts and installation instructions. Integration also act
as the Development team for certain product deliveries, such as OS updates and OS security patches.
These individual components are uploaded in to a PVB in Dimensions.
Integration extract the PVB (components) from Dimensions (see “Sample Dimensions screenshot Showing
PVBs and DPVBs” below) and then create the installable scripts based on the instructions in the handover
note. These scripts are tested to check the scripts work as expected. The components and scripts are
then bundled in to an installable file and uploaded in to a DPVB in Dimensions.
Step Current Accountability
Situation /
Input
3.1 I Generate CP I Create a CP or Peak (see "Sample screenshot Showing I Platform Owner I 3.2
or Peak used I Peak below") or Development
to initiate 1 . Integration check the status of all required document I Team
new PVB updates and use this data for the steps that follow
Output — New CP or Peak
3.2 I NewCPor I Review CP or Peak and create new PVB Platform Owner I 3.3.
Peak * Assess the information provided in the CP or Peak or Development
and check that that the Platform Product Stacks are I Team
up to date and include the PVB Design part
* Create the files that comprise the new PVB, this must
include a handover.doc and any other relevant files or
references to Sysware items
Output - Updated handover.doc and any supporting
files or items
3.3 I Updated Load PVB into Dimensions Development 34
handover.do /, Using the SCM-Web tool create a new PVB item inI Team
cand any Dimensions and set the PVB to READY_FOR_BUILD
supporting status
Hes or tems Output — PVB available in Dimensions
3.4 I PVBsetto I Process PVB Integration Team I 3.5
READY_FO I, — Review the PVB Handover.doc and any associated
R_BUILD files, use the handover instructions to prepare the
status in DPVB
Dimensions
mens! Output - Set PVB to IN_BUILD status
Output — Draft DPVB
3.5 I PVBto Create DPVB Integration Team I 3-6
IN_BUILD The Draft DPVB is tested on a test platform to
status and mitigate syntax errors and checks that the package is
draft DPVB adhering to the instructions listed in the handover.doc
* Create DPVB script package, this package can be in
any of the following formats (.SPB, .BFA, .RPM,
.PKG and manual).
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 46 of 72
Fe}
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
Output - DPVB package
3.6 Tested
DPVB
package
Load DPVB into Dimensions
Dimensions and set the DPVB to
READY_FOR_BRA_SYSTEMTEST status
« Using the SCM-Web tool create a new DPVB item in
Integration Team I End
Sample Dimensions screenshot Showing PVBs and DPVBs (with redactions as necessary)
D [diem 12b] Dimensions CM - [Baselines(Find Results) ) ~ a x
[ File Eat” View Rem’ Requst”Bavelne” Releve “roe Sueam Report Tote Window Help A Fossa
[ Dinew = "Boven ~ Z}rna - IB __ eM
Nycomed raed vax En
s6Lo8aL G saseinestina Resa ware
‘Folders and tems ‘eoceines EI of y + ems Be hr vel -
Pats and heme = [Sosa fiowaly —[smned =IAevee [Seopa
Bere: (Sim HOOK nT post Suto 202 oote0018 {ein 2020 161837 POEM
Gren WONT POST_SUL0_209_VOTEOIE Touny2070 561305 ALLS
BB Bescines ‘Weva_seane_COnra, 282 Do06 DNS 14 Sp 2261725 31 POOR
Buen 1m E ELIT
» Bh Requests
@, Reviews ba *
GBreme 5 Wi Peeve [paeasaicams Baveines “Races
B easetines <Unseeced> Reques ob + vel -
ree [v1 Ga\tae Sim (Singe Acton Ot
8S WoncAreas
» © Deployment Aces
L © e J a Dishow retated « >
Feri press = HREM = once mremcoustoonig $6 ne pote)
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR _ Date 29-Jan-2021
STORED OUTSIDE DIMENSIONS PageNo: 47 of 72
FUJ00232715
FUJ00232715
(oe) SDLC REPORT .
FUJITSU FUJITSU CONFIDENTIAL
Sample screenshot Showing Peak (with redactions as necessary)
ee ee ee
CO @ sectetynsucdmvcabiciibctaisipiCainalcpcb29taes * O26
Peak Incident Management System - PC0291468
iene a See se expats jetsis
FReiene—_—FReponed in ENGSCDOST TopRef LOBES YSLOGNG CFG. 2081_DIISDOOIE
{call Type Prociy
Keon E [Sie [etch SW Fc Avec Call onaer [Rowse Posts]
flempact_ POR) IRA
ae EY x ©
lispeyess rsa Apply 5¥5v2-P0139_608_e15t-etack (SYSLOG SEAVER_CF,208%_D9E2-D611 R_NCO_PROEESYSLOQI, CFS 2061 DOAS-0082
2tpaya root # cat SLO, SEAVERCF, 208. o33-V0H Lop
0 User-Oimensions automated Wee
155008 Veer imemsions automated Wer
: ce
[ste ot Resear)
rok 0201468 handled by Laegration aute hander
ve folloving baselines attached to this peak have te targeting flags eat
FRoot Come : 723 Response]
[Subrect Product JING-X Pasbmas ~ Saog Sever SYS) Sp]
[asseaee Gore] BeSpen I
names [fsa 22112000 DO Mas Dae [eons Te]
Bowe
Stage 4: Maintain Platform Product Spreadsheets
This describes the steps required to maintain the spreadsheets that define the order of installation of the
DPVBs. When a new software product is required, the Development team or Platform owner update the
PPD with the new product. This will show where in the install order this product should be in relation to
other products, after its dependencies and before anything that depends on it. For example, MySQL
would need to be installed before the create table product is installed. The Integration team use the
information in the PPD to insert the product name in to the ScmProductStack_*.xls (see “Sample
screenshot Showing ScmProductStack_BALv2.xIs” below). SCM is notified, so that they can update the
product as a valid product in Dimensions.
Step Current Accountability Next
Situation / Step
Input
4.1 I Generate CP I Create a CP or Peak Platform Owner I 4.2
or Peak used I , integration check the status of all required document _I of Development
‘0 initiate a updates and use this data for the steps that follow Team
Output - New CP or Peak
4.2 New CP or Update PPD to reflect new Product. Platform Owner 43
Peak © Update the relevant PPD to reflect the new Software I of Development
Product Team
Output - Updated PPD committed to Dimensions
4.3 I Updated Review CP\Peak and PPD Integration Team I 4.4
PPD > Assess the information provided in the CP\Peak
and PPD to check that that the Platform Product
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 48 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
» Stacks are up to date and include the new Product
* Check-out SemProductStack_*.xls from Dimensions
and update the document with the new Product
Output - Updated ScmProductStack_*.xls
4.4 I Updated Check ScmProductStack_*.xis into Dimensions Integration Team I 4.5
ScmProduct I, Check ScmProductStack_*.xls into Dimensions and
Stack_*.xls check that the status is set to complete
Output - ScmProductStack_*.xIs in Dimensions
marked as complete
45 ScemProduct I Notify SCM of ScmProductStack_*.xls update Integration Team I 4.6
Stack “xls I. Email sent to SCM team to inform them that a
set to ScmProductStack_*.xls has been update
Complete "
status in Output — SCM team review update
Dimensions
4.6 I ScmProduct I SCM team create an updated valid products xml SCM Team 47
Stack_*xls_ I. SCM team run their script to create an updated valid
review products xml to check that the new Product can be
complete deployed to the target Platform
Output - Updated valid products xml
4.7 I Updated Create PVBs and DPVBs Integration Team I End
valid © See process to “Create PVBs and DPVBs”
products xml
Output - New PVB and DPVB
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version 1.0
UNCONTROLLED WHEN PRINTED OR Date:
29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 49 of 72
FUJ00232715
FUJ00232715
SDLC REPORT .
FUJITSU CONFIDENTIAL
Ee)
FUJITSU
Sample screenshot Showing ScmProductStack_BALv2.xls (with redactions as necessary)
eas)
a 8 c A . F 6 H
‘contol PLATFORW_TYPE 'SOFTWARE_PRODUCT 'SOFTWARE_PHASE SOFTWARE_ORDER Platioom Product Name Notes
(Dimensions 1D -f not known use ‘Short
2 ‘AL_SERVER V2 SOBA — Crypt Kaye Sub CA Pubs Tet On (Linu)
3 BAL_SERVER-V2 20 BALs2 Cyn Keys Sub CA ble Le Ony una
+ ‘BAL_SERVERLV2 Sopasa
5 BAL_SERVERLV2 40 6au2
5 [BAL_SERVER V2 So Baa
1 BBAL_SERVER V2 0 Bau st ony
‘ BAL_SERVER.V? To Base UST AND SV&I ONLY
3I BAL_SERVER V2 20 BALe
10/60
i
2
4
6
€
Ea -
Proauetstack
Stage 5: Maintain Product Tags
Product Tags are a set of values maintained in a spreadsheet that are used by the installation scripts
(DPVBs) depending on the context of where the script is run. The script will require a certain value on the
LST (Live System Test) rig, but on the Live rig would require a different value.
Step Current Activities Accountability Next
Situation / Step
Input
51 Generate CP I Create a CP or Peak Platform Owner I 5.2
or Peak used I, Integration check the status of all required document _I Of Development
to initiate a updates and use this data for the steps that follow Team
Output - New CP or Peak
5.2 New Review CP\Peak Integration 5.3
Peak\CP * Assess the information provided in the CP\Peak to Team
check that all the details have been provided to create
or update a Product Tag
Output - Reviewed Peak\CP
5.3 I Reviewed Update product tags Integration 54
Peak\CP Output — Updated Product tags and new PVB and Team
DPVB created
5.4 New PVB New Product tag PVB and DPVBs are created Integration 5.5
and DPVB I Output — Integration team review update Team
created in
Dimensions
Stage 6: Maintain Integration Provisioning Environment
The software provisioning servers, TPM (see “Sample screenshot showing TPM deployment” below) and
TEM (see “Sample screenshot showing TEM deployment” below) need to be uploaded with the software
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 50 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
components extracted from Dimensions that make up the Integration rig. They are then used to provision
new Platforms and update existing ones with new or updated software DPVBs.
Step Current Situation / Activities Accountability Next
Input Step
61 Server Definition Adding new Platform Instances Integration Team nla
(PPD) * Establish hardware/storage/network
Platform Set in requirements. From PPD and assign in host
Dimensions environment (Bladeframe/ESXi/VM)
List of Authorised * Create Computer XML on TPM and
Packaged Software provision OS
* Create Product and stack XML using auto
PSPID scripts and upload to TPM or TEM.
DPVBs are automatically copied to
TPM/TEM.
Upload XML into TEM (auto for TPM)
* Provision software onto platform using full
product stack, plus any manual processes
specified.
Output — Product Stacks in TPM or TEM
Output - Built instance in Integration Rig
6.2 Support request Platform Troubleshooting Integration Team na
* Check Platform status, connection status,
Tivoli Common Agent (for TPM managed),
BigFix Agent status (for TEM managed)
* Check space or resource issues
* Check hosting issues, BladeFrame, ESXi,
ete.
6.3 Regular task TPM and TEM Housekeeping Integration Team nla
* Check space and any resource issues on
EPM and EDS for TPM. Similar for TEM.
Remove redundant tasks and items on TEM
* Backup TPM3 EPM & EDS on ESXi
Output - None
6.4 I Support request TPM and TEM Troubleshooting Integration Team nla
Check cron jobs running, scripts and
processes running. Check end-to-end
PSPID process.
* Check space and any resource issues on
EPM and EDS for TPM. Similar for TEM
Check hosting issues, BladeFrame, ESXi,
ete.
* Check TPM accessible across network, GUI
login works and TPM logs OK.
Output -None
Sample screenshot showing TPM deployment
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 51 of 72
FUJ00232715
FUJ00232715
oo SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Qrevsicnna wanes BK.
nn seine hate ie
Sample screenshot showing TEM deployment
Stage 7: Integration Test of Deployable Product Version Baselines
The DPVB is uploaded into the deployment server, TPM or TEM. The DPVB is then pushed from the
deployment server to the target Platform or Platforms on the Integration rig. The install logs are checked
for error and that the expected software components have been updated. The DPVB is then regressed
from the Platform using the regress script or instructions, and the checks repeated to verify that the DPVB
has been regressed correctly. The DPVB is then re-installed from the deployment server. The status of
the DPVB is changed to indicate that it is ready for the Test teams and the Test teams notified that the
DPVB works successfully on the Integration rig and the DPVB is available to be deployed to the Test rigs.
If at any stage the install or regress fails, the DPVB status is updated to show this, a ticket in respect of the
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR _ Date 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 52 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
fault (Peak) is raised and sent to the Integration packager to be repacked as a new DPVB.
Step Current Situation / A Accountability Next
Input Step
71 DPVBs in Prepare Baseline for Integration Test Integration Team 7.2
Dimensions * Update Dimensions status of DPVB to
“Approved for Bracknell System Test”
* Create Product and stack XML using auto
PSPID scripts (also copies to TPM or TEM)
* Upload XML into TEM (automatic for TPM)
Output — Baseline ready for Integration
testing
7.2 I Baseline available in I Test baseline on Integration rig Integration Team I 7.30n
Integration TPM or I, Apply to a target Platform instance. Check Success
TEM logs, install items, etc. 7.40n
* — Un-install, check logs, regress of items, Fail
etc.
Re-install, re-check logs, install items, etc.
* If successful, apply to other instances.
Move DPVB to next Dimensions status.
Send “Ready for Test” email.
e — If unsuccessful, raise a Peak, set status to
Withdrawn, pass back to Dev or Packager
depending on error. Un-install on
Integration rig.
Output — Install-tested DPVB in Dimensions
made ready for system test
Output - “Ready for Test” email
Output — Peak for failed baseline
7.3 Successful Move DPVB on to system test. Integration Team
Integration test * Move DPVB to next Dimensions status.
« Send “Ready for Test” email
* Apply DPVB to other platform instances
Output - Install-tested DPVB in Dimensions
made ready for system test
Output - “Ready for Test” email
74 Failed Integration Return Baseline for fix. Pass back to Developer I Integration Team
test or Packager depending on error.
* Raise a Peak
* Set Dimensions status to Withdrawn
* — Un-install on Integration rig
Output — Peak for failed baseline
Stage 8: Create Build Lists for Platforms and Incremental Updates
This describes the steps to create a list of DPVBs required for a release to be uploaded in to the
deployment servers, TPM and TEM. DPVBs can be deployed individually, but for a larger release or a
full platform build, it is better to deploy DPVBs as a group.
Step Current Next
Inp Step
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 53 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
8.1 Request from RM Create Build Lists for new Platforms Integration Team nla
Design Part List for I On receipt of a request, Integration team
Platform generates the list of DPVBS using
List of DPVBs to be Dimensions reports
omitted (optional) * Check for any anomalies such as
Target Release and inappropriate for target rig, and remove any
Rig requested exceptions.
* Create Dimensions Build Doc for Release.
Output - Dimensions Build document
containing the full list of DPVBs as related
objects
Output - Email to RM with Build Doc
reference, Release number, comments and
any Special Instructions.
8.2 Request from RM Create Incremental Build Lists for new Integration Team
Requested
Incremental
Baselines
List of DPVBs to be
omitted (optional)
Target Release and
Rig
Baselines across one or more platforms
* — Onreceipt of a request, Integration team
generates the list of DPVBS using
Dimensions reports
* Check for any anomalies such as
inappropriate for target rig, and remove any
requested exceptions.
* Create Dimensions Build Doc for Release.
Output — Dimensions Build document
containing the full list of DPVBs as related
objects
Output - Email to RM with Build Doc
reference, Release number, comments and
any Special Instructions.
Stage 9: Update Security Patches
This describes the steps required to maintain the monthly security patches. When the patches have been
assessed and agreed the Integrator creates them in Dimensions as a new PVB and DPVB and they are
deployed and tested using the same processes as other DPVBs.
This stage is part of the overall Integration process but not directly part of the SDLC.
Step Current Situation Aci Accountal Next
Input Step
o4 Monthly Security Define Requirement SecOps 9.2
Updates * Requirement based on information Integration Team
PCI Compliant available from various Security enforcement
Platforms agencies, Security Bulletin boards and
Master Spreadsheet Operating System vendors
92 Security enforcement I Update Master Spreadsheet Integration Team 93
agencies * Security patches are updated in a managed I Development
Security Bulletin and controlled document with all
boards information necessary to allow assessment
Operating System of the obtained patches.
Vendors. Output — Master Spreadsheet
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date:
STORED OUTSIDE DIMENSIONS
29-Jan-2021
PageNo: 54 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
9.3
Master control
Spreadsheet
Stakeholder Panel Assessment
* Patch Assessment Board meet to consider
relevance of assessed Patches and degree
of criticality. A decision is made and
security patches are selected based on
impact criteria.
Output — Peak call raised to deliver required
components.
SecOps and
Customer
9.4
94
Security Patches in
the form of COTS
products from
various OS Vendors
Register Sysware
« Register Sysware in Dimensions
Output — Software stored in package share
repository
Integration Team
95
95
Patches / Hotfixes
from OS Vendors
Create Product Version Baselines
« A Product Version Baseline is created and
items placed in Dimensions. PVB is develop
tested to check for automated delivery.
Output — PVBs in Dimensions
Integration Team
96
96
PVBs in Dimensions
Create Deployable Product Version
Baselines
* Package patches using appropriate
methods and tools
Output - DPVBs in Dimensions
Integration Team
97
97
DPVBs in
Dimensions
Test and Release DPVBs
* Packages are installed in integration test
environment to check for no package
errors.
« DPVBs propagated to next level for System
test and LIVE environments.
Output — Move Peak to LST
Integration Team
4.6 Testing & QA
See Testing & QA Report COM/MGT/REP/4166.
4.7 Accept and Deploy
4.7.1
Process Overview
A release is a delivery of:
Bug fixes; and/or
Security updates.
Change to functionality; and/or
Once the content is defined, Development complete the work and this will be followed by any Integration
packaging required for the deployment tooling to the rigs.
Release Management work with the Delivery and Operational teams to write an agreed deployment plan.
The focus is on how this release will be deployed into Live Service. Deployment into Test will follow/be a
dry run for Live following the same ordering and post implementation checks. Change Control (TfSNow)
will be used to deploy the release into Test and will record any changes/redeliveries due to findings
during testing. Any changes made during Test Phases are fed back into the Live deployment plan. A
walkthrough of the amended plan is held with the Delivery, Test and Operational teams to produce an
agreed deployment plan ready for Live deployment.
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL, Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 55 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Change Control for Live (including RDT) follows the POL Change Management Process using TfSNow
and any agreed checkpoints with POL. POL define which of the following checkpoints are applicable to
each release:
e Service Readiness Review (SRR)
e Release Authorisation Meeting/Board (RAM/RAB)
e Change Advisory Board (CAB)
Post Implementation Reviews are held and if any issues are found then these follow the POL Change
Management Process.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 56 of 72
FUJ00232715
FUJ00232715
(oe) SDLC REPORT .
FUJITSU FUJITSU CONFIDENTIAL
4.7.2, Process Flow
An overview of the process is shown and each numbered box is explained in the table that follows.
Release
Raised Received
fi Pr Rel De aT
Phun Release Identified renee Reine Ready ey 8 Test
T z
CAB Approval
Not Release are
Applicable to ROT
Change Request
Deployment Plan
Initialised
‘Stage 4
Prepare Release
forRDT
(Release Note(s)
Change Approval
Plan Available
‘Stage 5
Ready
‘Stage 6
AllTeams
Release Note(s),
Release to RDT
Stage7
Prepare Release
for Live
LF
Ready
Stage 8
Close Release:
Release to Live
_{” Tech Bridgeas ,
rt wired
Failure Resolution \._ Resuied
as Required 1? <
If” Customer
\\ Communication 7
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL,
UNCONTROLLED WHEN PRINTED OR
STORED OUTSIDE DIMENSIONS
Ref: COM/MGT/REP/4168
Version: 1.0
Date: 29-Jan-2021
Page No: 57 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT ~
FUJITSU FUJITSU CONFIDENTIAL
4.7.3 Process Steps
Release Trigger I The Requirement for the I e BIF (Business I Dimensions I ¢ Approved
Release: Impacting Peak requirement.
Forum). Held « Release ID
* CP (Change weekly. created.
Proposal) raised to I, Btr (Peak
cover new internal Targeting
or external
functionality esky but
changes: may be held
° Peak (Fault . at any time if
identified from Live emergency fix
or internally during
test activities). required
Stage 1 Activities to plan RP (Release Excel © FSC (Forward
Plan release: Planning) held SharePoint Schedule of
weekly to define Change
Release * Out of Development I test window. updated with
date proposed date if
* Test window Programme
* Projected Live delivery.
date(s) * Development
code produced.
Release Activities to define Dimensions I Release Note(s)
Content release content: content (Baselines)
Identified , Excel (plan) I defined.
«Baselines within
Release identified.
Change «Test Change TISNow Change Request
Request Raised Request raised and Approval. (see
distributed for “Sample screenshot
internal showing TFSNow
assessment. Change Request”
below)
Deployment ° Draft plan created Meeting(s) with Excel Draft Deployment
Plan initialised Development and Plan (see “Sample
Deployment screenshot showing
NB; When Test plan unit(s) held as Deployment Plan”
created it is generated required. below)
from a Live perspective
and Test is then planned
accordingly.
Stage 2 « RM (Release N/A Peak Processed Release
Process Management) Dimensions I Note (see “Sample
Release activity to create screenshot Showing
(Test) release note(s) to Release Note”
carry baseline(s). below
« Release Note Peak
related to Fault
Peak.
« SCM (Software
Configuration
Management)
package baseline(s)
and delivery
software to
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No: 58 of 72
Fe}
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
* repository.
Release Note(s) Release Note(s) Meeting(s) with Excel ‘Approved
Ready with RM Development Deployment Plan.
¢ Individual Child Deployment
Task(s) raised for I unit(s) and test
each Release held as required.
Note(s). (see
“Sample screenshot
showing TFSNow
CTask” below)
* Plan updated with
Release Note
References.
Change Confirmation checked TISNow ‘Approval to proceed
Advisory prior to release to Test deployment.
Received deployment
Plan Available e Approved plan TfSNow Approval to proceed
attached to Change Excel to Test deployment.
Request.
«Approved plan
distributed to key
stakeholders.
¢ Individual Child
Task(s) assigned to
Test (for onward
assignment to
deployment Unit(s)
* Release Note(s)
assigned to Test.
Stage 3 The activities that covers « RDT
deployment and Testing Deployment
Deploy & complated
Test
Release Failure
Resolution as
Required
Release ¢ Individual Child TISNow ° Test
Deployed Task(s) assigned to Peak Deployment
back to Test by completed.
Deployment Unit(s) * Release signed
with successful off by Test.
annotation. «= Failure
« — Individual Child Resolution as
Task(s) assigned to Required.
back to Test by
Deployment Unit(s)
with failure
annotation.
Release Meeting(s) with TfSNow Failure Resolution
Rejected Development as Required.
Deployment Peak
unit(s), test and
Release
Management held
as required to
discuss resolution.
Failure Activities to cover * Suspend
Resolution as failure. Release.
Required «© Fix Forward &
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL, Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No:
59 of 72
FUJ00232715
FUJ00232715
oo SDLC REPORT .
FUJITSU FUJITSU CONFIDENTIAL
« — Re-test.
« = Regress
software from
Test.
Release Signed
off by Test
Individual Child
Task(s) assigned
back to Release
Management.
« Release Note(s)
assigned back to
Release
Management.
* Test Sign Off
and Caveats.
* Release Notes
returned to RM.
Stage 4
Prepare
Release
for RDT
* RM (Release
Management)
activity to clone
release note(s) to
carry baseline(s)
¢ SCM (Software
Configuration
Management)
package baseline(s)
and delivery
software to
repository.
N/A
Peak
Dimensions
Processed RDT
Release Note(s)
version(s).
Release Note(s)
Ready
Release Note(s)
with RM.
* Release Note Peak
related to Fault
Peak.
¢ Individual Child
Task(s) raised for
each Release
Note(s).
Plan updated with
Release Note
References.
Meeting(s) with
Development
Deployment
unit(s) and test
held as required.
Excel
Approved
Deployment Plan.
‘Change
Request Raised
* RDT Change
Request raised and
distributed for
internal
assessment.
TfSNow
Change Request
Approval.
Deployment
Plan Initialised
« — Draft plan created.
Meeting(s) with
Development and
Deployment
unit(s) held as
required
Excel
Draft Deployment
Plan.
Change
Advisory
Received
Confirmation checked
prior to release
deployment
TfSNow
‘Approval to proceed
to RDT deployment.
Plan Available
‘Approved plan
attached to Change
Request.
¢ Approved plan
distributed to key
stakeholders.
© Individual Child
Task(s) assigned to
deployment Unit(s).
TISNow
Excel
Approval to proceed
to RDT deployment.
Stage 5
The activities that covers
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL,
UNCONTROLLED WHEN PRINTED OR
STORED OUTSIDE DIMENSIONS
Ref:
Version:
Date:
Page No:
COM/MGT/REP/4168
1.0
29-Jan-2021
60 of 72
FUJ00232715
FUJ00232715
oo SDLC REPORT .
FUJITSU FUJITSU CONFIDENTIAL
Release ‘deployment to RDT.
to RDT
Release © Individual Child TISNow « RDT
Deployed Task(s) assigned to Peak Deployment
back to Release completed.
Management by ° Failure
Deployment Unit(s) Resolution as
with successful Required.
annotation.
© Individual Child
Task(s) assigned to
back to Release
Management by
Deployment Unit(s)
with failure
annotation.
Failure Activities to cover «Fix Forward &
Resolution as failure. continue
Required * Regress
software from
RDT
Stage 6 Release Note(s) signed
Prepare off by Test cloned for
Release Live.
for Live
NB: Results in same
Release Note Peak.
Change « — Live Change * — Technical TfSNow « — Approval to go
Request Raised Request raised and CAB (Change Excel to Business
distributed for Advisory CAB (Change
internal Board). SharePoint Advisory
assessment. * FSC (Forward Board).
Schedule of «Customer
Change). request to re-
time change.
Deployment * Draft plan updated I Meeting(s) with Excel Draft Deployment
Plan Updated Development and Plan.
Deployment
unit(s) held as
required.
Release Note(s) Ie Release Note(s) Meeting(s) with Excel ‘Approved
Ready with RM Development Deployment Plan.
¢ Individual Child Deployment
Task(s) raised for unit(s) and test
each Release held as required.
Note(s).
«Plan updated with
Release Note
References.
Change Confirmation TISNow Approval to proceed
Approval checked prior to Live deployment.
Received to release
deployment.
CAB Approval I Change presented I CAB Business. Change Request
to CAB (Change Approval.
Advisory Board).
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 61 of 72
Fe}
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
NB: Changes selected
for presentation
depending on Business
impact. Approval may
be given directly in
TfSNow.
RAM/RAB * RAM (Release RAM/RAB RAM/RAB Approval.
Approval Authorisation meetings held as
Meeting). required and
* RAB (Release dependent on type
Authorisation of Release e.g
Board). generally
programme
releases.
SRR Approval I* SRR (Service RAM/RAB SRR Approval.
Readiness Review). I meetings held as
required and
dependent on type
of Release e.g.
generally
programme
releases.
Plan Available Ie Approved plan TfSNow ‘Approval to proceed
attached to Change Excel to Live deployment.
Request.
¢ Approved plan
distributed to key
stakeholders.
¢ — Individual Child
Task(s) assigned to
deployment Unit(s).
Stage 7 The activities that covers «Live
Release deployment to Live. Deployment
to Live completed.
«= Failure
Resolution as
Required.
Failure Activities to cover «Fix forward &
Resolution as failure. continue.
Required * Regress
software from
Live.
Release « — Individual Child TfSNow «Live
Deployed Task(s) assigned to Peak Deployment
back to Release completed.
Management by ° Failure
Deployment Unit(s) Resolution as
with successful Required.
annotation.
© Individual Child
Task(s) assigned to
back to Release
Management by
Deployment Unit(s)
with failure
annotation.
Tech Bridge as_I Deployment Manger ‘Agreed Resolution
Required contacts Duty Manager
to advise failure.
Customer Duty Manager contacts ‘Agreed Resolution
Communication I Customer Duty Manager
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS
Page No:
62 of 72
Ee)
FUJITSU
SDLC REPORT
FUJITSU CONFIDENTIAL
FUJ00232715
FUJ00232715
as required
Stage 8 I Stage 8 The activities that covers TISNow Release Closed.
Close I Close Release _I Release closure Peak
Release Individual Task(s) SharePoint
closed (all
environments)
« Change Request
Close (all
environments)
* Close Release
Notes (all
environments).
« Peak returned to
call logger for
closure.
Customer Customer notified via TfSNow Release Closed.
Communication I TfSNow closure
process.
Sample screenshot showing TFSNow Change Request (with redactions as necessary)
shaping aman why
Sarde Pte Fe
<< Be oungeteqet cress
Oe
songs
ee vo [
yd oes ‘
‘avers tect eh
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL, Ref:
Version:
Date:
Page No:
UNCONTROLLED WHEN PRINTED OR
STORED OUTSIDE DIMENSIONS 63 of 72
COM/MGT/REP/4168
1.0
29-Jan-2021
SDLC
FUJITSU
FUJ00232715
FUJ00232715
REPORT
FUJITSU CONFIDENTIAL
Sample screenshot showing Deployment Plan
f
1 x L
4 i
t rv Takers Cone
itt : Jancntrstowoee.o4 : z : =I, fz
i Network changes cones ovex
Pre-Reauisite- 1,14 Reference Data Chanaes. pases ve
par besioy erence Stoo Une tel hela for HSDPRS [ONAOTLAR I WWHTRED I —WAVGIDI “HE Wow nartion @ WOE
picsPase e107
rane Deny Reena re cenRNaT DONOR oan pe I wvebas I Twa I Beaded vos
e107
‘oa __[Pre-Upgrase -Acmin
oe [coi Gna peo ae ma eopare wer
os Cen else ks frm sired of BST Tart [onsite @
os Eeatereete Oo er ene
ne leaner oO
sor rae re I Tarmne aes I RIATAaRO Tama I Ua Wit acco
lewriees 80
[25> [Release R20.92 Payment Pilot Phase 2 - Dependent Release R20.28
Upgrade Activites - S8N
at pn BS SC and CORT HEA BT TE TRS TES) Re PRTTT
isos orosenon” I_I aon soe Pe ooo beack fauna ammaemies I ramiaemieisI wr frsars
pms eca cnr om 300s & onsets @ 07
* ova rest couvte sv, 088,207)
"Tre Toe Tsssnaes 1 Toop ss tas, oon ola frase I 7eoes I avaROTTs I aT EW
+ I Deployment Pan I" eatveRegrssion rn. crit I omads I 202 S0.careas I ecoeouee I. @ 1
Sample screenshot showing Release Note (with
(a
‘TEMI#430_LT-R2092-LST-
redactions as necessary)
BRAD
ist
Lae ‘SOMDsiner To REN
= ‘ComprerAd fo Paton Xo
te SCM tncloe XM Na
Ye Redinersofvemctclines No
‘TEMIG450.L1 -R0090- LST -DC¥i2- Mana Delivery of Ant Bele
aon aor Ongiauee 2 fro)
‘Applied 24/1120 Acuon Complete
Coonact
‘COMPLETION, by 2020-11-24 07:29:57 Acton Complete
‘COMMENT, by 2020-11-24 07:37:35 n-Progress
COMMENT, by Rs 2020152607 5:58
Release Note: TEMI8AS0_LT
PLATFORM:
DDEBIT_CARD MANAGEMENT SERVER. V2
Software and XL delivered to the DXT into /repositry/efles/SCMINIREL_TEML0430_LT
‘The XML Fes are called Addsoftwareproduct.xml and Addsotwarestack xml
‘The stack name is OC¥V2-P0143_0000_0364 stack
Baselines delivered to Irland are:
© Copyright Fujitsu 2021
FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 64 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Sample screenshot showing TFSNow CTask (with redactions as necessary)
aeeooenecsier ‘ aoe
< ong ek-crstionin Pe me felon + Undue Se Te oumein I meres Tine I Topgeropascpe I
Service Portal My Company sigur sem . I
ae gi ay aa rec 20 pt weed
eed ets Wotes I
veined toe snes
5 Formal Audit Reports
POL has commissioned an ISAE3402 audit as well as quarterly PCI Prioritised Approach audits on POA.
Both audits examined some of the topics discussed in this report. Furthermore, POA are periodically
requested to contribute to internal Fujitsu corporate audits to support Fujitsu UK in attaining and
maintaining a variety of certifications - such as 15027001, ISO9001 and IISO22301.
6 Conclusions
Fujitsu’s Software Delivery Life Cycle for the Horizon application is based on widely recognised industry
standard approaches and has been refined to meet the needs of POL and the current Horizon Contract.
This Report explains how the SDLC is operated for POA and shows the many points of engagement with
POL and the joint processes throughout.
7 Recommendations
None recorded in this version of the report.
8 Information Distribution
This report and any enclosed materials (the “Audit Materials”) are being provided to Post Office Limited (
“POL”) pursuant to POL’s request for an audit of Horizon (the “Audit”). The Audit Materials comprise
work product prepared by Fujitsu pursuant to requests from POL. Fujitsu has confined this report to the
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 65 of 72
FUJ00232715
FUJ00232715
oe SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
specific requests from POL and accepts no responsibility for any other matters. The Audit Materials
relate to the current HNG-x platform.
The Audit Materials are confidential and provided to POL for the sole purpose of the Audit. The Audit
Materials may only be shared by POL with KPMG, the external auditors appointed by POL in connection
with the Audit. POL shall take all necessary precautions to ensure that any Audit Materials are: (i) not
used for any purpose other than the Audit and; (ii) not disclosed to any third party (apart from KPMG),
without Fujitsu's express consent in writing. In particular, it should be noted that:
(i) the Audit Materials may contain highly confidential and sensitive information which, if disclosed,
is likely to significantly increase the risk of cyber and engineering attacks on the Horizon system;
(ii) the Audit Materials may contain personal data within the meaning of the General Data Protection
Regulation (“GDPR”); and
(iii) any system architectural content may be subject to copyright and/or other intellectual property
rights and cannot be shared or disseminated.
Prior to making any permitted disclosure of the Audit Materials (or any part thereof), POL shall provide
Fujitsu with reasonable advance notice of such intended disclosure and shall permit Fujitsu the
opportunity to redact information including but not limited to any privileged information, personal data
and/or other commercially sensitive or proprietary content.
This report refers to various documents that are confidential and internal to Fujitsu. Such confidential
documents are proprietary to Fujitsu and are not intended for sharing outside of Fujitsu. Fujitsu in no way
waives or intends to waive confidentiality in these documents by describing, referring to, reproducing
extracts of, or in any way referencing these documents in this report. Where extracts of such documents
are reproduced in this report, redactions have been applied to protect personal and sensitive information.
The Audit Materials, or any part thereof, may not be altered or amended without Fujitsu’s express
consent in writing. Under no circumstances shall any Fujitsu personnel be named or identified in any
reports or other documents created by POL based on information from the Audit Materials (or any part
thereof). Attribution of any Audit Materials shall be to Fujitsu only.
Unless agreed specifically in writing to the contrary Fujitsu does not accept any duty of care or any other
legal responsibility whatsoever to any person or entity in relation to this Report, any related enquiries,
advice or other work. Any person who receives a draft or copy of this Report (or any part of it) or
discusses it (or any part of it) or any related matter with Fujitsu, does so on the basis that he or she
acknowledges and accepts that he or she may not rely on this Report or any related information given by
Fujitsu for any other purpose.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 66 of 72
FUJ00232715
FUJ00232715
o SDLC REPORT -
FUJITSU FUJITSU CONFIDENTIAL
Appendix A —- HNGxDBM Role Descriptions
This document describes the key roles of the Fujitsu team referenced in the HNGxDBM processes.
These role descriptions are based on the underpinning ADBM roles supplemented where necessary with
detail or new roles specific to HNGxDBM.
Note that these are roles, not people. One person may fulfil more than one role in a particular project.
A.1 — Management
Role Description
Programme I The HNG-x BAU Programme Manager is responsible for the detailed, day-by-day conduct of the HNG-x
Manager Project, based on the planning of BAU Change projects. The plans constitute a notional contract, in that:
The Project Board supplies the direction and resources
In return, the Programme Manager:
* Delivers the Products
© Meets the Quality Criteria (for the products)
+ Verifies compliance with agreed Quality processes
. within the Budget
. by the Target Date for completion
. within any defined Tolerances
The Programme Manager is also responsible for preparing the plans for approval by the Project Board.
Head of Tasked with overall responsibilty for the resourcing and engineering process across the development to.
Application _I release phases.
Lifecycle
Development I Tasked with overall responsibilty for the success of the code, build and component test effort, providing
Manager Management oversight including :
* Quality and development best practice advocacy, resource planning and management, and
resolution of issues that impede the development and test effort.
* Reviewing and approving relevant documents
* Reviewing effectiveness of development.
Business Tasked with overall responsibilty for the success of the requirements gathering, understanding and
Requirements I providing Management oversight. Including
Manager
© Quality and requirements management best practice advocacy, resource planning and
management, and resolution of issues that impede the requirement effort.
* Release Acceptance and Authorisation (RAM/RAB) with Customer representatives
© Reviewing and approving relevant documents
* Reviewing effectiveness of requirements gathering and comprehension
Test Manager I Tasked with overall responsibility for the success of the independent test effort, providing Management
oversight. Including
* Quality and test best practice advocacy, resource planning and management, and resolution of
issues that impede the test effort.
* Reviewing and approving relevant documents
* Reviewing effectiveness of testing
Release and Tasked with overall responsibility for the success of the Integration and Release Management functions,
Integration _I providing Management oversight. Including :
Manager * Resource planning and management, and resolution of issues that impede team effort.
© Reviewing and approving relevant documents
* Reviewing effectiveness of resources and processes.
Responsible for planning and overseeing the successful rollout of releases, with close liaison to
Configuration and Change Management to agree the exact content and rollout/regression planning.
Makes available all necessary evidence to the Release authorisation team.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR _ Date 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 67 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Team ‘A Team Manager's responsibility is to achieve the completion of the Product(s) or Work Packages
Manager allocated to the team, using whichever quality processes have been agreed for the project and meeting
the product's Quality Criteria.
Within the context of HNGxDBM there are Solution Architecture, various Development Teams, SV&I and
LST Test Team Managers.
A.2 — Requirements & Architecture
Role Description
Business Business Analysts engage with the Customer (external and internal) to understand and define their real
Analyst Tequirements, and contribute to solution definitions. The Business Analyst seeks to ensure that
requirements are achievable, traceable and can be supported by test or other evidence to facilitate
acceptance.
The BA will prepare and deliver the materials required for Release acceptance and authorisation with the
Customer.
Solution This is a technical role and a crucial project role. The Solution Owner is responsible for all aspects of the
Owner design, requirements realisation, integration, implementation and performance of the project solution,
‘Additionally, Data Protection and Security implications are considered and acted upon by the Solution
Owner. Clearly there may be many Architects involved in the project, covering several technical
disciplines. There is only one Solution Owner; a senior person who works closely with the Project
Manager seeks to ensure that all the technical aspects of the plans are secure.
Platform This is a custodial role, where a first point of contact for general queries on a ‘platform’.
Owner A’platform’ is a functional sub-system component, composed of hardware specifications and application
in software layers — starting from an Operating System base and software and applications to provide
basic “functions” (e.g. printer functionality libraries), system management, network management, backup
utilities, and solution specific applications/functions (e.g. transaction receipt generation).
The Platform Owner is not required to have a detailed and intimate knowledge of the software on the
system/Platform — but rather seeks to efficiently direct enquiries concerning the system/platform.
The Platform Owner is the owner of the relevant PPD document which relates to the platform, and guides
changes made to the PPD.
Domain / Domain / Solution or Application Architects are responsible for the delivery of those aspects of the
Solution or Architecture allocated to them by the Solution Owner.
Application
Architect
Lead The Lead Infrastructure Architect is responsible for all aspects of the design, integration, implementation
Infrastructure I and performance of the infrastructure aspects of the project.
Architect
Infrastructure Infrastructure Architects are responsible for the delivery of those aspects of the Infrastructure
Architect Architecture allocated to them by the Lead Infrastructure Architect.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 68 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
A.3 — Technical & Engineering, including Test
Role Description
ECCB Lead The Engineering Change Control Board Lead will facilitate the timely and thorough estimation of the
impact of change and consolidate data gathered from ECCB contributors. Team Managers/Leads or
Members may contribute to the assessment of the technical feasibility or cost of proposed BAU Change
through the ECCB forum.
Team Leader I There will be a number of Team Leaders operating in different areas of the engineering lifecycle. They are
responsible for aspects of the work allocated to their team, including best practice advocacy, resource
management within their team and managing plan exceptions where these occur.
Team The Team Members within a project are responsible for delivering the ‘technical’ products.
Member Teams may be cross-functional (.e. composed of people from different parts of the participating
organisation(s) and brought together temporarily for the specific purposes of the project) or functional (i.e.
drawn from a specialist function which is acting as a supplier to the project).
Within the context of HNGxDBM these are Business Analysts, Lead Developers, Developers and
Testers
Lead Acts as a Developer (see below) ~ also Responsible for the high level design of specific elements of the
Developer solution, and may take responsibility for elements of quality control e.g. Code Review / liaison with
Architecture, CIT/Test Teams etc.
Developer Responsible for the detailed design, coding, component and component integration testing of software
modules.
CIT Test Responsible for identifying and detailing the required test scenarios, conditions (steps, data and expected
Engineer results), hardware and software including required regression testing requirements; monitoring detailed
testing progress and results in each test cycle; evaluating the overall coverage and quality as a result of
testing activities; implementation of the tests; logging and evaluating the outcomes of that testing and
reporting defects.
A.4 - Integration & Release
Role Description
Integration Dedicated full time Integration or team member or members of a development team performing the
Team Integration function.
Member
Release Team I Dedicated full ime Release Management team member or members of a development team performing
Member the Release Management function.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version: 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 69 of 72
FUJ00232715
FUJ00232715
ee) SDLC REPORT
FUJITSU FUJITSU CONFIDENTIAL
Appendix B — Tooling
A list of the main tools used in the SDLC process.
Tool Used b: Description
Bamboo Engineering A Continuous Integration server providing build telemetry to help
identify and highlight trends, pattems, and linkages across builds.
CBA Test Tool Engineering I Test tool to test Counter Business Application.
Checkstyle Engineering I A development tool to help programmers write Java code that adheres
to a coding standard. It automates the process of checking Java code
Clover Engineering I A powerful and highly configurable code coverage analysis tool used
for improving test quality, test productivity and seamless project
integration
Confluence Collaboration I An enterprise wiki software for sharing and editing content, online
collaboration, knowledge management, document management, file
sharing, and more.
Crucible Support A peer code review tool to review code changes, make comments, and
record outcomes in an efficient, distributed, and process-neutral way.
Crypto J Lib Engineering Crypto Library for Counter development.
Dimensions Engineering I Software Baselines/Documents.
Eclipse Engineering I An open development platform comprised of extensible frameworks,
tools and runtimes for building, deploying and managing software
across the lifecycle.
Enterprise Architect I Engineering _I Combines the power of the latest UML 2.1 specification with a high
performance, intuitive interface, to bring advanced modelling to the
desktop
ESXi Engineering VMWare ESX for managing virtualised servers.
FishEye Support A source code repository insight tool that opens up your repository to
help you better understand your changing source.
FSC Management I Forward Schedule of Change — Calendar with project Live Deployment
Dates.
Installshield Engineering I Build and Install package Software.
JIRA Management I A browser-based bug, issue, task and defect tracking system and
project management software solution.
JUnit Engineering I A unit testing framework for the Java programming language.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
VersionI 1.0
UNCONTROLLED WHEN PRINTED OR Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 70 of 72
FUJ00232715
FUJ00232715
oO SDLC REPORT ~
FUJITSU FUJITSU CONFIDENTIAL
Management Management I Provides an enhanced set of reports within the Apt Task Management
Reporting tool that help project managers to track the effort and schedule
performance of their teams.
Maven Engineering I Maven is a software project management and comprehension tool.
Based on the concept of a project object model (POM), Maven can
manage a project's build, reporting and documentation from a central
piece of information.
Microsoft Project Management I Project management software program designed to assist project
managers in developing plans, assigning resources to tasks, tracking
progress, managing budgets and analyzing workload.
Mylyn Engineering I A Task-Focused Interface for Eclipse that reduces information
overload and makes multi-tasking easy.
Peak Engineering I Bug and Release Note Database Tool.
PMD Engineering I A solution that scans source code and looks for potential problems:
possible bugs, unused and suboptimal code, over-complicated
expressions and duplicate code.
Release Note Management Record in Peak of software deployment.
Database
SCM Web Tool Engineering Used to create Product Version Baselines in Dimensions.
SharePoint Management I Service library.
SoapU! Engineering Unit and Cl Testing.
Subversion Support An open-source revision control system.
TEM Engineering _I Tivoli Endpoint Manager — deploy software products to servers.
TFSNow Management I Change Request System.
TortoiseSVN Support An easy to use Subversion client for Microsoft Windows, implemented
as a Windows shell extension, integrating seamlessly into the
Windows explorer.
TPM Engineering _I Tivoli Provisioning Manager — deploy software OS and products to
servers.
Visual Source Safe Support Source Repository.
© Copyright Fujitsu 2021 FUJITSU CONFIDENTIAL Ref: COM/MGT/REP/4168
Version 1.0
UNCONTROLLED WHEN PRINTEDOR _Date: 29-Jan-2021
STORED OUTSIDE DIMENSIONS Page No: 71 of 72