Yesser SDLC - Overall SDLC

ájOƒ©°ùdG á«Hô©dG áµ∏ªŸG
Yesser Overall SDLC

Process Definition
e-Government Program (Yesser)
Yesser Overall SDLC Process Definition
Version 0.6 - Page 3 / 43
Table of Contents
1. Process Introduction ........................................................................................................ 5

1.1. Process Scope ............................................................................................................. 5
1.2. Process Objectives and Benefits .................................................................................. 5
1.3. Process Interfaces with other Processes ...................................................................... 6
1.4. Process Entry & Exit Criteria ........................................................................................ 6
1.4.1. Process Entry Criteria ......................................................................................................................... 6
1.4.2. Process Exit Criteria ............................................................................................................................ 6
1.5. Process Inputs & Output .............................................................................................. 6
1.5.1. Process Inputs..................................................................................................................................... 7
1.5.2. Process Outputs .................................................................................................................................. 7
2. Process Key Elements ...................................................................................................... 8
2.1. RFC Assessment ......................................................................................................... 9
2.2. Requirements Development & Management ................................................................ 9
2.3. Solution Architecture .................................................................................................... 9
2.4. Solution Design ............................................................................................................ 9
2.5. Solution Development ................................................................................................ 10
2.6. Solution Deployment .................................................................................................. 10
2.7. Solution Verification (Quality Control) ......................................................................... 11
2.8. Software Configuration Management ......................................................................... 11
2.9. Quality Assurance ...................................................................................................... 11
2.10. Solution Tracking & Monitoring ................................................................................... 12
3. Process Flow Diagram .................................................................................................... 13
4. Process Key Activities .................................................................................................... 14
4.1. Key Activity 1000: Needs Requirements Definition? ................................................... 14
4.2. Key Activity 1010: Understand Solution Needs........................................................... 14
4.3. Key Activity 1020: Analyze Requirements .................................................................. 15
4.4. Key Activity 1040: Create the System Requirements Definition .................................. 15
4.5. Key Activity 1050: Get Approval on SRS .................................................................... 16
4.6. Key Activity 2000: Needs Architecture Involvement? .................................................. 16
4.7. Key Activity 2030: Prepare Solution Architecture........................................................ 16
4.8. Key Activity 3000: Needs Design Involvement?.......................................................... 17
4.9. Key Activity 3010: Prepare Solution Design ............................................................... 17
4.10. Key Activity 3020: Prepare Deployment Manual ......................................................... 18
4.11. Key Activity 3030: Prepare Release Notes ................................................................. 18
4.12. Key Activity 4000: Needs Development Involvement? ................................................ 19
4.13. Key Activity 4010: Implement the Design of the Product Component ......................... 19
4.14. Key Activity 5000: Release Planning .......................................................................... 20
4.15. Key Activity 5010: Deployment Sanity Check ............................................................. 20
4.16. Key Activity 5020: Production Sanity Check ............................................................... 20
4.17. Key Activity 5030: Production Release Planning ........................................................ 21
4.18. Key Activity 6000: Needs Quality Involvement?.......................................................... 21
4.19. Key Activity 6010: Test Planning ................................................................................ 22
4.20. Key Activity 6020: Test Analysis ................................................................................. 22
4.21. Key Activity 6035: Updating Test Cases ..................................................................... 22
4.22. Key Activity 6030: Test Execution .............................................................................. 22
4.23. Key Activity 6040: Proceed to UAT?........................................................................... 23
4.24. Key Activity 6050: Conduct UAT................................................................................. 23
4.25. Key Activity 6060: Proceed to Production? ................................................................. 24
4.26. Key Activity 7000: Plan Configuration Management Activities .................................... 24
4.27. Key Activity 7010: Review Configuration Management Activities Implementation ....... 25
4.28. Key Activity 8000: Plan Quality Assurance Activities .................................................. 25
4.29. Key Activity 8010: Review Process Implementation and Work Products .................... 26
Confidential e-Government Program (Yesser)
This document (either in whole or in part) cannot be modified or

reproduced without the prior written permission of the e-Government Program (Yesser)
4.30. Key Activity 9000: Plan Product Release.................................................................... 26

4.31. Key Activity 9010: Product Implementation Tracking, Monitoring & Control ................ 26
4.32. Key Activity 9020: Product Closure & Announcement ................................................ 27
4.33. Key Activity 0010: Execute Deployment ..................................................................... 27
4.34. Key Activity 0020: Execute Production Deployment ................................................... 27
5. Process Guidelines ......................................................................................................... 28
5.1. The Approved Request For Change (RFC) ................................................................ 28
5.2. The SDLC Disciplines ................................................................................................ 28
5.3. Process Tailoring Guidelines ...................................................................................... 28
5.4. Establishing Yesser Measurements Repository.......................................................... 29
5.5. Establishing Yesser Process Assets Library ............................................................... 30
6. Process Deliverables ...................................................................................................... 31
6.1. Software Requirements Specifications (SRS)............................................................. 31
6.2. Solution Architecture .................................................................................................. 31
6.3. Solution Design .......................................................................................................... 32
6.4. Deployment Manual ................................................................................................... 32
6.5. Solution Build Announcement .................................................................................... 32
6.6. Release Notes............................................................................................................ 33
6.7. Test Plan .................................................................................................................... 33
6.8. Test Cases ................................................................................................................. 33
6.9. User Acceptance Testing (UAT) Report ..................................................................... 34
6.10. Software Configuration Management Plan (SCMP) .................................................... 34
6.11. SCM Nonconformities Report ..................................................................................... 34
6.12. Quality Assurance Plan (QAP) ................................................................................... 35
6.13. Quality Assurance (QA) Review Findings Report ....................................................... 35
6.14. Progress Status Report .............................................................................................. 35
7. Process Policies .............................................................................................................. 36
8. Process RACI Matrix ....................................................................................................... 37
9. Process Roles & Responsibilities .................................................................................. 38
9.1. Business Analyst Role................................................................................................ 38
9.2. Solution Architect Role ............................................................................................... 38
9.3. Software Designer Role ............................................................................................. 38
9.4. Software Developer Role ........................................................................................... 39
9.5. Release Management Officer Role............................................................................. 39
9.6. Quality Control Team Role ......................................................................................... 39
9.7. Configuration Management Officer Role..................................................................... 39
9.8. Quality Assurance Officer Role .................................................................................. 40
9.9. Product Owner Role ................................................................................................... 40
9.10. Operations Team Role ............................................................................................... 40
10. Process Measurements .................................................................................................. 41
11. Appendix A – Acronyms ................................................................................................. 42
12. Appendix B – Glossary ................................................................................................... 43

1. Process Introduction
Yesser is rapidly expanding its IT services and infrastructure in support of its national e-
government agenda of building a centralized integration platform. As part of delivering the
best services, Yesser define and implement the SDLC practices across Yesser software
related projects/products within Yesser.
This process definition document was prepared to illustrate the overall Yesser high-level
SDLC processes, procedures, guidelines and policies.
1.1. Process Scope

This process aims to detail the overall SDLC practices within Yesser that will govern the
software team work on Yesser software products/projects under the following disciplines:
 Requirements Management
 Analysis and Design
 Development
 Quality Management
 Configuration and Change Management
 Build and Release Management
1.2. Process Objectives and Benefits

Implementing this definition document within Yesser will allow:
 Assuring predictability of work activities achieving approximately the same
deliverables with the same resources and same quality each time the process is
followed.
 Enabling workers to better plan their workday because of the predictability
resulting from work processes.
 Establishing a basic set of work tasks that can be improved continuously.
 Increasing Yesser software development productivity.
 Better understanding of the overall Yesser SDLC by all involved Yesser teams.
 Increasing the probability that the deliverables produced will be the desired
deliverables.
 Putting workers in charge of their own destiny because they know the standards
by which their work products will be evaluated.
 Improving schedule and budget predictability.
 Increasing quality and customers’ satisfaction.

1.3. Process Interfaces with other Processes

Yesser overall SDLC touches many aspects and disciplines for Yesser software
development projects, some of these aspects relates to the following IT governance
processes:
 ITSM Change Management Process
 Incident Management Process
 GSB On-boarding Process – Consumer
 GSB Provider On-Boarding Process
Other interfaces relate to specific disciplines that touches directly the software
development and delivery processes:
 Requirements Management
 Analysis and Design
 Development
 Quality Management
 Configuration and Change Management
 Build and Release Management
1.4. Process Entry & Exit Criteria

This section describes the conditions required to trigger activities within the Yesser SDLC
and the conditions required to consider ending the SDLC process.
1.4.1. Process Entry Criteria

Since most SDLC related activities will have change-effect on Yesser environment; then,
the sole trigger to initiate SDLC is an approved RFC resulting from the Yesser ITSM
Change Management Process. As part of this approved RFC should come the high-level
business requirements, these requirements will be gathered and included in the Business
Requirement Document (BRD) which is included within the RFC.
1.4.2. Process Exit Criteria

The SDLC process will end with the successful implementation and deployment of the
software solution. Along this successful implementation and deployment, should come the
signoff of the related stakeholders, Yesser product owner and business owners.
1.5. Process Inputs & Output

This section describes the inputs required from the non-SDLC activities prior to the
initiation of the SDLC process as well as the expected outputs for the SDLC process.

1.5.1. Process Inputs

 The key input for the SDLC process is the approved RFC that comes from Yesser
ITSM Change Management Process; this RFC will have undergone all the Yesser
pre-defined change management activities as illustrated in the “ITSM Change
Management Process” document maintained by Yesser IT Governance.
 A very important input for the initiation of the Yesser SDLC process is also the
impact analysis results that were conducted by the CAB that include the effect of
this RFC on solution architecture, requirements, design and quality related
activities.
 Another very important (but not mandatory) input for the Yesser SDLC process is
the high-level business requirements which are gathered prior to the approval of
the RFC by the Business Analyst (BA). For many cases, these high-level
requirements are considered important as they are used to control the scope of the
submitted RFC, these requirements will be gathered and included in the Business
Requirement Document (BRD) which is included within the RFC. This BRD should
be approved by Business Owner, Application Engineering Directory and
Architecture prior to the approval of the RFC by the Change Authorizing Board.
 Since Yesser SDLC process tackles changes on Yesser main software solutions
(Saudi National Portal, Saudi Governmental Service Bus – GSB, Yesser Internet
Portal, Yesser Intranet Portal or any other similar solution), all previously created
architecture documentation, design documentation, software code, requirements
documentation and quality documentation are considered important for the SDLC
process.
1.5.2. Process Outputs

Yesser SDLC output will produce the following main outputs:
 An updated version of the solution documentations that can include architecture
documentation, design documentation, requirements documentation and quality
documentation in addition to the updated deployment manual that allows
successful deployment of the software solution.
 An updated source code of the Yesser software solutions stored on Yesser source
code version control repository.
 An updated deployed version of Yesser software solutions (Saudi National Portal,
Saudi Governmental Service Bus – GSB, Yesser Internet Portal, Yesser Intranet
Portal or any other similar solution) modified either to include the updated/new
requirements or to include and expose of the governmental service for other Saudi
agencies.
 Status updates to the BMC Remedy RFC to indicate the status of the
implementation and deployment of approved RFC.
 A Release Announcement after the closure of the implementation of a certain
RFC.
 Updates to Yesser historical data repository that includes any information that will
help Yesser in their effort for continuous process improvement.

2. Process Key Elements

The Yesser SDLC process key elements can be thought of as high level grouping for one
or more activity within the process that achieve a common goal or objective. Below is a list
of the Yesser SDLC process key elements:
 RFC Assessment
 Requirements Gathering & Development
 Solution Architecture
 Solution Design
 Solution Development
 Solution Verification (Quality Control)
 Solution Deployment
 Configuration Management
 Quality Assurance
 Solution Tracking & Monitoring
Figure 1 - SDLC Key Element Flow Chart

2.1. RFC Assessment

The trigger to initiate all SDLC activities within Yesser is the approved RFC. This RFC is
maintained by Yesser change management IT governance process. During the early
lifecycle stages of the RFC, a preliminary impact analysis is conducted by the Yesser
CAB, this impact analysis results would decide on the Go/No-Go of the implementation of
the RFC and would decide whether the SDLC need to be triggered for this purpose since
not all RFCs interact with the SDLC.
During the RFC assessment, each of the Yesser teams involved in the SDLC would
determine their involvement in the implementation of this RFC and would decide on the
impact of this RFC on their work products. As a result, all teams would know early enough
whether they are part of the implementation of a specific RFC thus help in better planning
for this RFC.
2.2. Requirements Development & Management

After realizing the RFC assessment results, the Yesser Business Analysis (BA) role would
understand their involvement in the implementation of a certain RFC; this would be based
on the understanding of whether a change is required for the solution requirements or not.
The BA role would then commence the effort to understand the solution needs to produce
the “Software Requirements Specifications (SRS)” document for the rest of the teams (i.e.
Software Designers and Quality Control teams) as an input to continue their work.
Please refer to the “Requirements Management Process Definition” document for more
details about this process key element.
2.3. Solution Architecture

After determining the involvement of the Yesser Solution Architecture role in the
implementation of a certain RFC; the Solution Architecture will focus on gathering all the
required technical details for them to prepare the “Solution Architecture” document. This
would be a main input for the rest of the teams (i.e. Software Designers, Release
Management and Operations teams) to continue their work.
Please refer to the “Analysis and Design Process Definition” document for more details
about this process key element.
2.4. Solution Design

After determining the involvement of the Yesser Design role in the implementation of a
certain RFC, the Software Designer will focus his effort to come up with the “Solution
Design” document which will include all the details required to start the actual
implementation of the RFC by the Yesser Software Developers. His work outcome will
also be required as a base for the Operations and Release Management teams to
continue their work.

Also, during this process key element, the solution “Deployment Manual” is prepared to
document the steps needed to successfully copy the changes to production.
2.5. Solution Development

After determining the involvement of the Yesser Development role in the implementation
of a certain RFC, the Developers will focus their effort to come up with the “Solution Build”
which will include the actual implementation of the solution as per the prepared design.
A certain “Solution Build” can include partial or full implementation of the prepared design;
this depends on the plan for the gradual incremental development approach that is agreed
upon within the project teams. A “Solution Build” will be the main input for the Operations
and Release Management teams to continue their work. For each certain “Solution Build”,
a “Solution Build Announcement” is prepared to inform all the related parties about the
scope of certain build.
Please refer to the “Development Process Definition” document for more details about this
process key element.
2.6. Solution Deployment

The solution deployment process key element main focus is to deploy a certain “Solution
Build” on a certain environment based on the prepared “Deployment Manual” document
which acts as a checklist procedure to repeat the deployment on any of these
environments.
For each deployed “Solution Build” which is not on the Production, the Quality Control
team will use it along with the “Solution Build Announcement” as an input to continue their
testing work.
Once a deployment is ready for production, the Operations team will execute the build on
the production and the Software Designer will prepare the “Release Notes” document
which will contain the overall scope of this software release for future reference.
Please refer to the “Build and Release Management Process Definition” document for
more details about this process key element.

2.7. Solution Verification (Quality Control)

After determining the involvement of the Yesser Quality Control role in the implementation
of a certain RFC, the Quality Control team will focus their effort to come up with the “Test
Plan” document which will include all the required details and descriptions about the
quality control activities to be carried out through the implementation of the RFC.
Another activity by the Yesser Quality Control role is to prepare the “Test Cases” which
will act as the test analysis guidelines and procedures, these “Test Cases” will later be
used during the test execution and the Quality Control team will determine the result of
their execution.
It is worthy to mention that part of the test results produced during the test execution
would be the defects; each defect will describe an issue currently existing in a certain
“Solution Build”, their priorities/severities amongst other attributes will help understand the
fixing priority for the reported issues. These defects will be managed with the defect
management process and workflow and will be tracked to closure accordingly.
Please refer to the “Quality Management Process Definition” document for more details
2.8. Software Configuration Management

Software configuration management (SCM) will be an umbrella process key element
which will govern the identification of the SDLC Configurable Items (CIs) to defining and
identifying how to systematically control changes to the identified CIs for the purpose of
maintaining their integrity and traceability throughout the SDLC, thus ensuring
completeness, consistency, and correctness of CIs. All these rules, guidelines and
procedures will be document by the Configuration Management Officer within the
“Configuration Management Plan” document.
Throughout the SDLC, reviews for the configuration management activities will take place
to identify nonconformities; these nonconformities will later be logged and tracked for
closure.
Please refer to the “Configuration Management Process Definition” document for more
details about this process key element.
2.9. Quality Assurance

Quality assurance will also be an umbrella process key element which provides the
framework necessary to ensure a consistent approach to software quality assurance
throughout the SDLC. The systematic monitoring of execution of SDLC disciplines, and
work products will be evaluated to ensure that they meet requirements and comply with
Yesser processes, policies, standards and procedures.

In order to provide an objective insight into the maturity and quality of the software, the
Quality Assurance Officer will document the goals, processes, and responsibilities
required to implement effective quality assurance within the “Quality Assurance Plan”
document. Similarly, regular reviews will be carried out and findings will be logged and
tracked for closure.
2.10. Solution Tracking & Monitoring

The solution tracking and monitoring key element main focus will be the planning,
motoring and control of the activities of building, testing and deployment of the approved
RFC till the closure of its activities within SDLC overall process.
It involves different activities that focus on preparing the conditions for the execution
phase. This usually involves developing the overall plan (and sub plans) and getting the
commitment on all these plans from the different teams.
Also, this area shall involve the activities of ensuring and monitoring the progress in order
to identify variances from the overall plan so that corrective active actions can be taken
when necessary to meet the desired objectives.
When actual status deviates significantly from the expected values, corrective actions
shall be taken as appropriate. These actions may require re-planning, which may include
revising the original plans, establishing new agreements, or including additional mitigation
activities within the current plans.
Moreover, this key element is concerned with Risk Management for identifying potential
problems before they occur so that risk-handling activities can be planned and invoked as
needed across the SDLC implementation to mitigate possible impacts that would affect
achieving the desired objectives.

3. Process Flow Diagram
Figure 2 – Overall SDLC Process Flow Diagram

4. Process Key Activities

This section includes the descriptions and procedures required to carry out all the process
key activities illustrated in the Overall SDLC Process Flow Diagram.
4.1. Key Activity 1000: Needs Requirements Definition?

The SDLC is initiated by having a Request For Change (RFC) approved by the Change
Authorizing Board (CAB). This aim of this task is for the Business Analyst (BA) to analyze
the approved Request For Change (RFC) and identify areas for new requirements or
updates for existing requirements in order to trigger the requirements management
process.
The result of the assessment of this RFC will determine whether to start the requirements
management process or not. If the BA involvement was found to be necessary by this
process key check activity, then the BA will start the “Key Activity 1010: Understand
Solution Needs” process key activity:
If the involvement of the BA was determined as not-required (such as the fixing of a bug
from the Incident Management), then this will end the requirements management process
and initiate another assessment effort by the Solution Architects with “Key Activity 2000:
Needs Architecture Involvement?”
details about this process key activity.
4.2. Key Activity 1010: Understand Solution Needs

Once the involvement of the BA was determined within the work for a certain RFC, the BA
will start the effort to understand the stakeholders of the RFC requirements, collect the
RFC requirements that the solution should fulfill and prioritize these requirements. The BA
can use several techniques for this purpose including but not limited to:
 Conducting interviews to understand the solution needs with the different RFC
stakeholders.
 Questionnaires to be filled by the RFC stakeholders.
 Creating a prototype to allow better and more opened communication channels
with the business oriented stakeholders.
 Creating storyboards.
The outcomes from this key activity will be gathered by the BA to be used later on when
executing the “Key Activity 1020: Analyze Requirements”.

4.3. Key Activity 1020: Analyze Requirements

Once the BA formulates the full understanding of the solution needs, the BA will start the
effort to translate these business needs into system requirements. This task is to model
the business processes for the RFC requirements.
During this key activity, the BA will start analyzing the stakeholder needs gather
previously, the result of this analysis effort can produce both functional requirements
(mostly represented using the Use-Case Models) and the nonfunctional requirements
(including performance requirements, security, availability, etc).
The outcomes from this key activity will be gathered by the BA to be used later on when
executing the “Key Activity 1040: Create the System Requirements Definition”.
4.4. Key Activity 1040: Create the System Requirements

Definition
During this process key activity, the BA will work on create the system requirements
definition and document it in the “Software Requirements Specification (SRS) Document”.
This deliverable document will contain the consolidation of all the BA findings in the form
of system functional requirements (mostly represented using the Use-Case Models) and
the system nonfunctional requirements.
After this process key activity, the BA will work with the Product Owner to get his approval
on the prepared “Software Requirements Specification (SRS) Document” along with other
teams commitment on it.
Before the approval of the Product Owner, the BA will work with the rest of the SDLC
teams to get their commitment on the SRS each in his domain. For example, the Quality
Control team can commit that the requirement included in the SRS are testable and clear,
the Software Designer can commit that the requirements mentioned in the SRS are
implementation and also clear

4.5. Key Activity 1050: Get Approval on SRS

During this process key activity, the BA will work with the Product Owner to get his
approval on the prepared “Software Requirements Specification (SRS) Document”; this
approval is required as it sets the expectations between what BA will communicate to the
rest of the SDLC teams and the Product Owner requirements.
Two roles can start their respective process key activities after this step:
 Solution Architects with “Key Activity 2000: Needs Architecture Involvement?”
 Quality Control Team with “Key Activity 6010: Test Planning”.
4.6. Key Activity 2000: Needs Architecture Involvement?

This process key check activity will determine whether the Solution Architecture
involvement is required or not to finish working on the assigned RFC. The Solution
Architecture involvement in the implementation of a certain RFC has several aspects, for
example:
 Deciding on the technology required to implement a specific RFC
 Deciding whether the introduction of additional infrastructural components will be
required to implement a certain RFC.
 Deciding on whether more technical details are required prior the start of the
implementation of a certain RFC (e.g. Integration Specifications).
If the Solution Architecture involvement was found to be necessary for a specific RFC and
a change on the current architecture is required, then the Solution Architecture will
execute the “Key Activity 2030: Prepare Solution Architecture”. However, if the
involvement of the Solution Architecture was determined as not-required, then this will
initiate another assessment effort by the Software Designer with “Key Activity 3000:
Needs Design Involvement?”
about this process key activity.
4.7. Key Activity 2030: Prepare Solution Architecture

Based on the gathered RFC requirements and if implementing the RFC will require
updating the solution architecture, the Solution Architecture will prepare the “Solution
Architecture Document”.
After this process key activity, the Software Designer will use this deliverable document to
execute the “Key Activity 3010: Prepare Solution Design”

4.8. Key Activity 3000: Needs Design Involvement?

This process key check activity will determine whether the Software Designer involvement
is required or not to finish working on the assigned RFC. The Software Designer
involvement in the implementation of a certain RFC has several aspects, for example:
 Deciding on whether the development of new software component is required.
 Deciding on the integration sequence between the solution different components.
If the Software Designer involvement was found to be necessary for a specific RFC, then
the Software Designer will execute the “Key Activity 3010: Prepare Solution Design”.
However, if the involvement of the Software Designer was determined as not-required,
then this will initiate another assessment effort by the Software Developer with “Key
Activity 4000: Needs Development Involvement?”
4.9. Key Activity 3010: Prepare Solution Design

This process key activity will initiate the effort to come up with the “Solution Design
Document” which is the base for the Software Developers to start with the actual effort to
implement the RFC without continuously referring back to the Software Designer for
clarification.
The Software Designer will rely on several main inputs to come up with the “Solution
Design Document”:
 The Software Requirements Specifications (SRS) Document.
 The Solution Architecture Document.
 Other inputs that can be required based on the RFC nature.
After this process key activity, two roles can start their respective process key activities:
 Software Developer with “Key Activity 4010: Implement the Design of the Product
Components”.
 Software Designer with “Key Activity 3020: Prepare Deployment Manual”.

4.10. Key Activity 3020: Prepare Deployment Manual

This process key activity will initiate the effort to come up with the “Deployment Manual
Document” which is the base for the Operations Team when conducting/executing a
software deployment on any of Yesser environments. It will make sure that the
deployment process is documented, tested and verified before conducting it on the
production environment.
The Software Designer will rely on several main inputs to come up with the “Deployment
Manual Document”:
 The Solution Design Document.
 The Solution Architecture Document.
 Other inputs that can be required based on the RFC nature.
It is worthy to mention that as part of this process key activity, the Software Designer will
also ensure the validity of the previously prepared “Deployment Manual Documents” by
providing the necessary maintenance for these documents and update them to
accommodate for the changes introduced within either the “Solution Design Document”
and/or the “Solution Architecture Document”.
After this activity, the Release Management Officer will get one of the inputs required to
get him started with his process key activity “Key Activity 5000: Release Planning”.
4.11. Key Activity 3030: Prepare Release Notes

This is the process key activity that is initiated after the getting the signal from the Quality
Team after conducting the UAT that the RFC implementation is ready to go-live on
production. With this process key activity, the Software Designer will consolidate all the
changes implemented for the received RFC and produce the “Release Notes”.
The “Release Notes” document includes many detail, below are some example for these
details:
 The “What is new?” section – this lists the new changes introduced by the
implementation of a certain RFC from a business prospective.
 Features Added – this can list from a technical or semi-technical point of view the
new features implemented for a cetain RFC.
 Known issues/bugs – this can list a list of known issues for the released
implemented RFC.
The outcome of the execution of this process key activity will be communicated to the
RFC related stakeholders using the “Release Notes” document.

more details about this process key activity.
4.12. Key Activity 4000: Needs Development Involvement?

This process key check activity will determine whether the Software Developer
involvement is required or not to finish working on the assigned RFC. The Software
Developer involvement in the implementation of a certain RFC has several aspects, for
example (“development of one or more software component” or “development of a DB
stored procedure”).
If the Software Developer involvement was found to be necessary for a specific RFC, then
the Software Developer will execute the “Key Activity 4010: Implement the Design of the
Product Component”. However, if the involvement of the Software Developer was
determined as not-required, then this will initiate another assessment effort by the Quality
Control Team with “Key Activity 6000: Needs Quality Involvement?”
process key activity.
4.13. Key Activity 4010: Implement the Design of the Product

Component
Based on the prepared solution design, the Software Developer will start the actual
implementation of all the related product components as defined by the Software
Designers in the “Solution Design” document.
This effort will involve modifying on the source code of the solution using the development
IDE specific for each technology. The result of this development effort will be the “Solution
Build” which will be sent for deployment on a test environment by the Operations Team to
be tested by the Quality Control Team.
As part of the Software Developer deliverables in addition to the “Solution Build” is the
“Solution Build Announcement” which is prepared to inform all the related parties about
the scope of certain build. After this process key activity, the Release Management Officer
will execute the “Key Activity 5000: Release Planning” based on the prepared
“Deployment Manual” document and other imputs.
process key activity.

4.14. Key Activity 5000: Release Planning

This process key activity will initiate the effort to discuss and agree on the scope of the
next planned “Solution Build” by the Release Management Officer for non-production
deployments. It relies on inputs from several teams including:
 The “Solution Design” document prepared by the Software Designer.
 The “Solution Architecture” document prepared by the Solution Architect.
 The “Deployment Manual” document prepared by the Software Designer.
An example for the activities that are carried out during this process key acitivity includes
the coordination of Release Management Officer with the rest of the teams for any
downtime for the environment for deployment purposes.
4.15. Key Activity 5010: Deployment Sanity Check

This process key activity will initiate the effort of the Release Management Officer to
conduct a check after each non-production deployments to verify that the correct
deployment was carried out. Below are some examples of the items checked by this
process key activity:
 Correct “Solution Build” was deployed on the targeted environment.
 The successful preparation and communication of the “Solution Build
Announcement” to the related parties.
 Correct version of the “Deployment Manual” document was used to carry out the
deployment.
4.16. Key Activity 5020: Production Sanity Check

This process key activity will initiate the effort of the Release Management Officer to
conduct a check only after each production deployments to verify that the correct
deployment was carried out. The Release Management Officer will check against the
same Sanity Checklist used by “Key Activity 5010: Deployment Sanity Check”, for
example:
 Correct “Solution Build” was deployed on the targeted environment.
 The successful preparation and communication of the “Solution Build
Announcement” to the related parties.
 Correct version of the “Deployment Manual” document was used to carry out the
deployment.

4.17. Key Activity 5030: Production Release Planning

Similar to “Key Activity 5000: Release Planning”, this process key activity will initiate the
effort to discuss and agree on the scope of the planned “Solution Build” by the Release
Management Officer for production deployments. It relies on inputs from several teams
including:
 The “Solution Design” document prepared by the Software Designer.
 The “Solution Architecture” document prepared by the Solution Architect.
 The “Deployment Manual” document prepared by the Software Designer.
 The “Release Notes” document prepared by the Software Designer.
 The “Testing Result” for the testing conducted by the Quality Control Team.
 The “UAT Report” that includes the pass-results of conducting the User
Acceptance Testing (UAT) between the Quality Control Team and the Product
Owner.
An example for the activities that are carried out during this process key acitivity includes
the coordination of Release Management Officer with the rest of the stackholders for any
downtime for the environment for deployment purposes.
4.18. Key Activity 6000: Needs Quality Involvement?

This process key check activity will determine whether the Quality Control Team
involvement is required or not to finish working on the assigned RFC. The Quality Control
Team involvement in the implementation of a certain RFC has several aspects, for
example:
 Verifying the successful implementation of the functionality implemented as part of
the RFC implementation.
 Verifying the implementation of the RFC meets a certain performance KPI.
If the Quality Control Team involvement was found to be necessary for a specific RFC,
then the Quality Control Team will execute the “Key Activity 6010: Test Planning”.
However, if the involvement of the Quality Control Team was determined as not-required,
then this will end the SDLC process.

4.19. Key Activity 6010: Test Planning

This process key activity will initiate the effort to come up with the “Test Plan Document”
which is the base for the Quality Control Team to scope their testing and verification
activities throughout the implementation of an RFC.
The Quality Control Team will rely mainly on the “Software Requirements Specifications
(SRS) Document” to come up with the “Test Plan Document”.
4.20. Key Activity 6020: Test Analysis

This process key activity will initiate the effort to come up with the “Test Cases
Documents” which are the base for the Quality Control Team when conducting/executing
their testing and verification activities on a certain “Solution Build” as part of the
implementation of an RFC.
The “Test Cases Documents” will include the identification of the testing procedures,
steps, solution expected results and conditions which will be the base to be used by the
Quality Control Team when executing the “Key Activity 6030: Test Execution”.
4.21. Key Activity 6035: Updating Test Cases

This process key activity will initiate the effort to update the test cases prepared by the
previous the “Key Activity 6020: Test Analysis”. This update can be necessary since the
test cases were prepared before the implementation of the RFC, and therefore, there is a
slight chance that they would require updates to reflect minor changes on the System
Under Test (SUT)
An example for the changes that can occur and might require the Quality Control Team to
update their test cases accordingly, are field label changes, field specifications, mandatory
vs. optional fields, page/form layouts …etc.
4.22. Key Activity 6030: Test Execution

This process key activity will initiate the execution of the actual testing effort on the
deployed “Solution Build” as per the prepared “Test Plan Document” and “Test Cases

Documents”. It is initiated after the completion of the following previous process key
activities:
 Key Activity 5010: Deployment Sanity Check
 Key Activity 6020: Test Analysis
The Quality Control Team will rely on the “Solution Build Announcement” as an input to
understand the scope of changes/enhancement/fixes that were introduced as part of each
deployed “Solution Build”.
The outcomes from this process key activity will be the documented “Test Results” which
can include many deliverables, for example:
 The PASS/FAIL results from the executed test cases, failed results are
documented as “Defects” which are communicate to the remainder of the project
teams to decide on the corrective actions accordingly.
 Testing progress status updates
 Suggested enhancements for the system under test
4.23. Key Activity 6040: Proceed to UAT?

This process key check activity will determine based on the defined Quality Control
acceptance and/or exit criteria whether to sign-off testing on a certain “Solution Build” or
not. The Quality Control Team will accordingly recommend either one of the following:
 Conduct another cycle to close the identified pending issues and go back to the
execution of the “Key Activity 4010: Implement the Design of the Product
Components”.
 Provide the sign-off for the deployed and tested “Solution Build” for it to undergo
acceptance testing with the Product Owner by the execution of the “Key Activity
6050: Conduct UAT”
4.24. Key Activity 6050: Conduct UAT

This process key activity will initiate the execution of the acceptance testing with the
Product Owner to validate with him that all the requirements requested by the RFC are
implemented and are functioning correctly.
During the UAT session, the person conduction this session will gather all the comments
and feedback of the Product Owner to classify them into the following categories:

 Test results from User Acceptance Testing (UAT) may reveal defects that were not
identifies during the Quality Control testing of the RFC, these defects will be
logged and tracked back to closure.
 Test results from User Acceptance Testing (UAT) may ay introduce certain
changes in the original requirements/specifications or new requirements that are
out of Scope-of-Work of the RFC, these changes or new requirements must be
raised as new RFC in order to track them through the SDLC and to verify their
closure.
4.25. Key Activity 6060: Proceed to Production?

This process key check activity will allow the Quality Control team to recommend based
on the comments and feedback of the Product Owner during the User Acceptance Testing
(UAT) whether that the “Solution Build” that was validated during the UAT is ready to go-
live onto the Production environment or not.
Several criteria can control the Quality Control team recommendation to go-live, for
example:
 The severity of the identified new issues/defects that were revealed during the
UAT.
 The priority of the new changes that were identified during the UAT based on the
business impact that is owned by the Product Owner.
4.26. Key Activity 7000: Plan Configuration Management

Activities
This process key activity will initiate the effort to come up with the “Software Configuration
Management Plan (SCMP) Document” which is the base for the Configuration
Management Officer to document and inform project stakeholders about the Software
Configuration Management (SCM) activities within the implementation of a certain RFC. It
can be initiated after or during the RFC assessment by the different project teams.
The Configuration Management Officer will rely mainly on the “Data Management Plan” to
come up with the “Software Configuration Management Plan (SCMP) Document”.
The outcome of this process key activity is considered an input for most project teams and
any senior leader whose support is needed to carry out the tasks mentioned in this SCMP.

Please refer to the “Configuration and Change Management Process Definition” document
for more details about this process key activity.
4.27. Key Activity 7010: Review Configuration Management

Activities Implementation
This process key activity is considered an umbrella activity that spans throughout the
different SDLC stages. It will include conducting reviews for implementation of the
configuration management activities within the implementation of a certain RFC.
This will promote the successful implementation of a certain RFC by ensuring that work
products and documentation changes involved during the implementation of the RFC
establish and maintain configuration control. All identified discrepancies will be collected,
documented and tracked for closure within the “Configuration Management
Nonconformities Report”.
for more details about this process key activity.
4.28. Key Activity 8000: Plan Quality Assurance Activities

This process key activity will initiate the effort to come up with the “Quality Assurance Plan
(QAP) Document” which is the base for the Quality Assurance Officer to define the
approach that will be used to monitor and assess software development processes and
work products to provide an objective insight into the maturity and quality of the activities
carried out during the implementation of a certain RFC. It can be initiated after or during
the RFC assessment by the different project teams.
The Quality Assurance Officer will rely on the “Project Management Plan” to come up with
the “Quality Assurance Plan (QAP) Document”.
to carry out their tasks to ensure that they meet their requirements and comply with
Yesser policies, standards and procedures as well as the selected/chosen delivery model.

4.29. Key Activity 8010: Review Process Implementation and

Work Products
different SDLC stages. It will include conducting reviews for the implemented software
development processes and work products to provide insight about the maturity and
quality of the activities carried out during the implementation of a certain RFC.
This will promote adherence to the defined processes as well as providing the necessary
feedback to carry on with Yesser continuous process improvement. All identified findings
will be collected, documented and tracked for closure within the “Quality Assurance
Review Findings Report”.
4.30. Key Activity 9000: Plan Product Release

This process key activity will initiate the effort to come up with the “Product Release Plan
Document” which serves as the master plan that describes the high-level activities to be
conducted by each of the teams involved to ensure the success of the implementation of a
certain RFC. This process key activity can be initiated after or during the RFC assessment
by the different project teams.
The Product Owner will rely on the information included along with the approved SDLC-
related RFC to come up with the “Product Release Plan Document”.
to provide a clear understanding of the expectations from each project team.
4.31. Key Activity 9010: Product Implementation Tracking,

Monitoring & Control
different SDLC stages. It will include several activities to be conducted by the Product
Owner to:
 Track and monitor of the current activities of the involved project teams.
 Identify variances from the plan so that corrective active action can be taken when
necessary to meet desired objectives.
 Report status of implementation of a certain RFC to stakeholders by frequent
preparing and submission of the “Progress Status Report”.
 Ensure the closure of the implementation of a certain RFC for the product.

4.32. Key Activity 9020: Product Closure & Announcement

This process key activity can be considered as the final step to be executed as part of
Yesser SDLC process. The Product Owner will reply on the input received from the
different project teams to decide on the closure of the implementation of a certain RFC for
a specific product. It can be thought of as the final announcement for the successful
implementation of a certain RFC for the related stakeholders and will depend on the
RFC’s acceptance criteria.
4.33. Key Activity 0010: Execute Deployment

This process key activity will initiate the execution of the deployment procedures for a
certain “Solution Build” on a non-production environment; the Operations Team will use
the “Deployment Manual” document prepared by the Software Designer as the checklist to
execute the deployment steps.
This process key activity will result with a deployed solution build on its targeted
environment and the Release Management Officer can proceed with the initiation of the
execution of “Key Activity 5010: Deployment Sanity Check”.
4.34. Key Activity 0020: Execute Production Deployment

This process key activity will initiate the execution of the deployment procedures for the
“Solution Build” that was validated during the UAT on the production environment; the
Operations Team will use the “Deployment Manual” document prepared by the Software
Designer as the checklist to execute the deployment steps.
This process key activity will result with a deployed solution build on the Production
environment and the Release Management Officer can proceed with the initiation of the
execution of “Key Activity 5020: Production Sanity Check”.

5. Process Guidelines
This section depicts the list of guidelines that govern the execution of the Yesser SDLC
process activities.
5.1. The Approved Request For Change (RFC)

1) The initiator for the Yesser SDLC is an approved RFC requiring any of the SDLC
activities.
2) RFCs are work items maintained using the defined Yesser ITSM Change
Management Process including their approval process.
3) RFC work item life cycle is maintained using the change management process
implemented on the BMC Remedy tool.
5.2. The SDLC Disciplines

1) All the activities defined in the Yesser SDLC process will follow the specific
process guidelines defined within the following process definition documents:
a) The Requirements Management Process Definition Document.
b) The Analysis and Design Process Definition Document.
c) The Development Process Definition Document.
d) The Quality Management Process Definition Document.
e) The Change and Configuration Management Process Definition Document.
f) The Build and Release Management Process Definition Document.
2) For each of the approval activities within the SDLC (e.g. the approval of SRS with
the Product Owner), there need to be defined a certain timeframe for the specific
SDLC deliverable/activity in which this specific SDLC deliverable/activity will be
considered approved if no comment from the receiver was acknowledged within
the defined timeframe. For Example, if the timeframe to commit to the SRS by the
Development Team is three working day, then the BA can consider the SRS as
commited if no reply was received from them during the defined three working
days.
3) For major RFCs, the approval of the Change Authorizing Board (CAB) will be
required before initiating the development and implementation of that major RFC.
5.3. Process Tailoring Guidelines

1) Tailoring guidelines should cater for each current and future SDLC related Yesser
track (examples: National Portal, GSB, Yesser Internal Portal or Yesser Internet
Portal).
2) Tailoring guidelines should cater for each project based on business needs and
project constraints.

5.4. Establishing Yesser Measurements Repository

1) Measurement repository should contain both product and process measures.
2) Defined measurement should provide a way to assess the status of your program
to determine if it is in trouble or in need of corrective action and process
improvement.
3) The assessment of the measures collected must be based on up-to-date data that
reflect current program status, both in relation to the program plan and to models
of expected performance drawn from historical data of similar programs.
4) Metrics are computed from measures. They are quantifiable indices used to
compare software products, processes, or projects or to predict their outcomes.
5) Yesser defined metrics should consider the following categories of metrics:
a) Schedule metrics – they are used to determine whether the estimation
techniques for the tasks to be carried out during the system’s
implementation produces near-life values similar to the actual efforts spent.
b) Technical metrics – they are used to determine whether the code is well-
structured, that documentation is complete, correct, and up-to-date.
Technical metrics also describe the external characteristics of the system’s
implementation. These metrics can also include size and complexity.
c) Quality metrics – they are used to determine that the system does not
erroneously process data, does not abnormally terminate, and does not do
the many other things associated with the failure of a software-intensive
system.
6) Rules for selecting metrics:
a) Metrics must be understandable to be useful.
b) Metrics must be economical and do not require a lot of time from the
project resources to collect the metric required data.
c) Make sure proposed metrics have been successfully used on other
programs or make sure they are prototyped before accepting them.
d) Look for data about the SDLC process that permit management to make
significant improvements. Metrics that show tiny deviations should not be
considered.
e) Metrics must give drive for process improvement within Yesser. However,
they should be used very carefully; metrics should be not used to judge
teams or individuals performance.

5.5. Establishing Yesser Process Assets Library

1) Make sure to establish a process assets library to create a reference for the
different teams involved in the SDLC process to carry out their tasks without
diversions from the defined processes, guidelines, policies and templates.
2) The process asset library should contain all the assets required for the different
teams, for example, the assets library can contain the following:
a) Organizational policies.
b) Defined process descriptions.
c) All documentation templates excluding some real examples demonstrating
the use of these templates.
d) Training materials.
e) Process aids (e.g. checklists).
f) Lessons-learned reports.

6. Process Deliverables
This section includes the main deliverables that will be produced within the Yesser SDLC
process. This list is not the complete set of deliverables as other deliverables will be
defined and listed within each of the SDLC disciplines.
The table below lists the main deliverables that are part of the Yesser SDLC process:
# Template Name Template File
1 Software Requirements Specifications (SRS)
2 Solution Architecture
3 Solution Design
4 Deployment Manual
5 Solution Build Announcement
6 Release Notes
7 Test Plan
8 Test Cases
9 User Acceptance Testing (UAT) Report
10 Software Configuration Management Plan (SCMP)
Software Configuration Management (SCM)
11
Nonconformities Report
12 Quality Assurance Plan (QAP)
13 Quality Assurance (QA) Review Findings Report
14 Progress Status Report
6.1. Software Requirements Specifications (SRS)

The purpose of the Software Requirements Specifications (SRS) document is to include
and elaborate on the system requirements (functional and non-functional requirements);
the functional requirements capture how the system should behave, while the non-
functional requirements represent other non-behavioral requirements.
details.
6.2. Solution Architecture

The purpose of the Solution Architecture Document is to provide a comprehensive
architectural overview of the system, using a number of different architectural views to
portray different aspects of the system. It is intended to capture and convey the significant

architectural decisions which have been made on the system. The document can also
include alternative architectural solutions discussed and how all alternatives were
compared based on well-defined selection criteria.
Please refer to the “Analysis & Design Process Definition” document for more details.
6.3. Solution Design

The purpose of the Solution Design Document is to provide detailed design and
comprehensive architectural views (such as portfolio, hierarchy, exposure, dependencies,
compositions and flow, non-functional requirements, messages, decisions, decisions
realizations, etc.) of the system to be implemented. The software developers will use this
document in order to proceed with the system implementation. This document should be
comprehensive enough so that developers will not need to refer back to the designer
frequently for clarification and at the same time to help the maintenance team provide all
their work with minimal interaction with the designers.
The document can also include alternative design solutions discussed and how all
alternatives were compared based on well-defined selection criteria.
Please refer to the “Analysis & Design Process Definition” document for more details.
6.4. Deployment Manual

The purpose of the Deployment Manual Document is to capture and detail all deployment
steps that are needed to deploy and configure a software application in the Yesser
environments. This document can be used to replicate a software application into a new
environment. It should be detailed enough to help Yesser Operations team to execute the
same steps in the production environment with no technical difficulties.
Another main purpose of this document is to describe the roll-back procedures and plan in
case a certain software/solution build was not to be considered for deployment on any of
Yesser environments.
more details.
6.5. Solution Build Announcement

The purpose of the Solution Build Announcement is to capture the areas that were
impacted for a specific software/solution build during the implementation phase (such as
listing the defects that were fixed and the postponed one and listing of the solution known
issues). This announcement acts as in input for the Quality Control Team to determine the
scope of the specific build under-test.

more details.
6.6. Release Notes

The purpose of the Release Notes Document is to detail the areas that were impacted for
a specific software/solution release after finishing the implementation and testing prior
releasing the software/solution to production. This document can include details such as
the list of change requests that were implemented as part of this software release or the
list of known defects for the release.
This document is similar in many aspects to the “Solution Build Announcement”; however,
this document is intended for production purposes and is sent to the business owners to
understand the scope for the newly released software/solution.
more details.
6.7. Test Plan

The purpose of the Test Plan Document is to describe the strategy and approach used to
plan, organize, and manage the project’s Quality Control (QC) and Testing activities
including the definition of the scope of the testing activities, testing types (functional and
non-functional), define the resources and skills needed to execute the tests, and the tools
to be used for testing. This document can be considered the primary plan for the Quality
Control Team.
This document ensures that the QC processes and methodologies will be carried out by
the Quality Control Team. It is also considered a critical artifact that communicates to the
stakeholders and to the Development Team the level of testing for acceptance and the
strategy to execute these tests.
Please refer to the “Quality Management Process Definition” document for more details.
6.8. Test Cases

The purpose of the Test Cases Document is to describe the set of scenarios to be
executed against the developed system to make sure that these scenarios have been
carried out before experiencing them on production. It includes the set of inputs, execution
steps, and expected results for each identified scenario. The expected behavior of the
system is to be controlled by the system requirements/use cases.

6.9. User Acceptance Testing (UAT) Report

The purpose of the User Acceptance Testing (UAT) Report Document is to document the
results of executing the UAT testing that was conducted between the Quality Control
Team and the Product Owner. The report is include the test cases that were carried out
during the UAT test along with the results of the execution of these test cases.
The Product Owner need to provide a document sign-off on this report as this report is
consider the base for later stages to approve the production deployment of the
implementation of a certain RFC.
6.10. Software Configuration Management Plan (SCMP)

The purpose of the Software Configuration Management Plan (SCMP) Document is to
document and inform project stakeholders about the Software Configuration Management
(SCM) activities within the project, what SCM tools will be used, and how they will be
applied to establish and maintain configuration control of the products and documentation
of the project to promote the success of this project by:
 Defining and identifying of the methods and procedures that shall be used to
identify the software configuration at discrete points in time.
 Defining and identifying how to systematically control changes to the identified
software configuration for the purpose of maintaining software integrity and
traceability throughout the software lifecycle.
 Defining the baselining criteria of the software-related configurable items (CI’s).
 Reporting and recording status of the software-related CI’s by any requested
modification.
 Ensuring completeness, consistency, and correctness of the software-related CI’s.
This document is considered an input for most project teams (such as the Project
Manager, Quality Control, Development, project sponsor) and any senior leader whose
support is needed to carry out the tasks mentioned in this SCMP.
for more details.
6.11. SCM Nonconformities Report

The purpose of the Software Configuration Management (SCM) Nonconformities Report is
to list all nonconformities identified as a result of SCM audits for all/any of the project
teams. This report will ensure that all identified SCM nonconformities are logged and
tracked for closure.

for more details.
6.12. Quality Assurance Plan (QAP)

The purpose of the Quality Assurance Plan (QAP) Document is to establish the goals,
processes and responsibilities required to implement effective quality assurance functions
for the SDLC projects.
The QAP provides the framework necessary to ensure a consistent approach to software
quality assurance throughout the project life cycle. It defines the approach that will be
used by the Quality Assurance Officer to monitor and assess software development
processes and products to provide objective insight into the maturity and quality of the
software.
The systematic monitoring of the execution of the SDLC processes and the resulted work
products will be evaluated to ensure that they meet their requirements and comply with
Yesser policies, standards and procedures as well as the selected/chosen delivery model.
6.13. Quality Assurance (QA) Review Findings Report

The purpose of the Quality Assurance (QA) Review Findings Report is to list all findings
identified as a result of the QA audits for all/any of the project teams. This report will
ensure that all identified QA review findings are logged and tracked for closure.
6.14. Progress Status Report

Collecting performance information for status reports, measuring progress & forecasting
will lead to Progress Status Report which will be provided the Product Owner whom is
accountable of the delivery of the SDLC RFC to demonstrate the actual status of the
activities assigned for each of the project teams. This report is consolidated from the
micro-statuses of each of the project team member from within each team and then
having each team head reporting his individual status to the Product Owner.
This report is essential for determining the status of a certain SDLC RFC implementation
and would act as a great support for the management to create better and more realistic
decisions affecting the course of the SDLC activities.

7. Process Policies
This section lists the policies that will help establish a consistent set of management
practices and terms to conduct systems development within Yesser environment. These
policies allow establishing a standardized process for conducting projects within Yesser.
Below are the policies that will be governing activities for Yesser SDLC process:
# Policy Description
All items and activities under the Yesser SDLC should be planned, reviewed and
1
approved by the end of the planning phase (i.e. before execution).
Adequate recourses (material, people, and tools like EPM) need to be provided to carry
2
out the SDLC activities.
The resources that will perform their assigned SDLC activities should be trained to carry
3
out their designated activities.
Audits on the SDLC activities should be conducted to guarantee adherence with the
4
defined SDLC process.
Tailoring guidelines should be defined for all process areas and they shall all be
5
maintained in the organizational centralized repository
All project work products resulting from the SDLC should always be kept under a version
6
control system.
Best practices and lessons learned should be captured, saved, and then used for future
7
SDLC projects.
The documentation produced after each must be produced according to the templates
8 defined within this document or as per the templates defined within each SDLC discipline
process definition document.
For each of the approval activities within the SDLC, there need to be defined a certain
timeframe for the specific SDLC deliverable/activity in which this specific SDLC
9
deliverable/activity will be considered approved if no comment from the receiver was
acknowledged within the defined timeframe.
For major RFCs, the approval of the Change Authorizing Board (CAB) will be required
10
before initiating the development and implementation of that major RFC.
Refer to the policies section in “Requirements Management Process Definition
11
Document”.
12 Refer to the policies section in “Analysis and Design Process Definition Document”.
13 Refer to the policies section in “Development Process Definition Document”.
14 Refer to the policies section in “Quality Management Process Definition Document”.
Refer to the policies section in “Change and Configuration Management Process
15
Definition Document”.
Refer to the policies section in “Build and Release Management Process Definition
16
Document”.

8. Process RACI Matrix

This section includes the Yesser SDLC process tasks and activities with roles and
responsibilities for each possible role. Roles associated with Yesser SDLC process are
defined in the context of service management and are not intended to correspond with
organizational job titles. In some cases, many persons might share a single role; and in
other cases, a single person may assume many roles, or at least more than one role.
The complete RACI matrix is included in a separate document; please refer to the
following document for complete details about the RACI matrix.
Yesser Overall SDLC

RACI Matrix

9. Process Roles & Responsibilities

This section depicts the roles and responsibilities for all parties involved in the defined
SDLC process.
9.1. Business Analyst Role

The role represents the person(s) responsible for the following:
 Providing the required assessment for SDLC-related RFCs to determine the
impact on the existing requirements definition for Yesser related solutions.
 Understanding the stakeholder needs for a certain SDLC-related RFC.
 Analyzing the stakeholder needs for a certain SDLC-related RFC and provide their
representation as use-cases that include the main flow of the identified
functionalities as well as any alternative flow.
 Creating, documenting and updating of the requirements definition for Yesser
solutions.
9.2. Solution Architect Role

impact on the existing architecture for Yesser related solutions.
 Gathering and understanding of the technical requirements for a certain SDLC-
related RFC.
 Creating, documenting and updating of the architecture for Yesser solutions.
 Acting as a reference for the Software Designer for architecture related inquiries.
 Handling defects fixing that requires architectural changes.
9.3. Software Designer Role

impact on the existing design for Yesser related solutions.
 Creating, documenting and updating of the software design for Yesser solutions.
 Acting as a reference for the Development and Quality Control Teams for design
related inquiries.
 Handling defects fixing that requires software design changes.

9.4. Software Developer Role

impact on the existing product components for Yesser related solutions.
 Creating, maintaining and updating of the source code for Yesser solutions.
 Handling defects fixing that requires development involvement.
 Conducting of developers unit testing.
 Creating of the solution builds.
9.5. Release Management Officer Role

 Conducting release planning activities to decide on the readiness of all non-
production deployments within Yesser SDLC.
 Coordinating the execution of the Sanity Checkings after all non-production
deployments
 Conducting release planning activities to decide on the readiness of all production
deployments within Yesser SDLC.
 Coordinating the execution of the Sanity Checkings after all production
deployments.
9.6. Quality Control Team Role

testing needs for Yesser related solutions.
 Creating, maintaining and updating of the test plans for Yesser solutions.
 Creating, maintaining and updating of the test cases for Yesser solutions.
 Conducting of system black-box testing, gray-box testing, load testing, stress
testing, SOA functional & performance testing, usability testing and regression
testing.
 Reporting and tracking defects.
 Decide on the readiness of a solution build to be a production release.
9.7. Configuration Management Officer Role

 Creating, maintaining and updating of the Configuration Management Plans for
SDLC-related RFCs for Yesser solutions projects.
 Defining the criteria for Configurable Items (CIs) identifications.

 Defining the baselining criteria of the software-related CIs for SDLC-related RFCs.
 Defining and identifying how to control changes to the identified software
configuration for the purpose of maintaining software integrity and traceability
throughout the software lifecycle.
 Conducting reviews for implementation of the configuration management activities
within the implementation of a certain RFC.
 Collecting and documenting the identified nonconformities within the
“Configuration Management Nonconformities Report”.
 Tracking the closure of the identified nonconformities.
9.8. Quality Assurance Officer Role

 Creating, maintaining and updating of the Quality Assurance Plans for SDLC-
related RFCs for Yesser solutions projects.
 Conducting reviews to monitor and assess software development processes and
products within the implementation of a certain RFC.
 Collecting and documenting the identified QA review findings within the “Quality
Assurance (QA) Review Findings Report”.
 Tracking the closure of the identified QA review findings.
9.9. Product Owner Role

 Accepting the Release Plans for SDLC-related RFCs for RFCs for the product he
owns.
 Monitoring and reporting the status of the implementation of SDLC-related RFCs
for the product he owns.
 Ensuring the closure of the implementation of SDLC-related RFCs for the product
he owns by acting as the holder of the related Yesser specific product.
 Deciding on the roadmap for the product he owns.
 Providing approvals for the prepared Software Requirements Specifications (SRS)
documents for the product he owns.
 Attending the RFC User Acceptance Testing (UAT) acting as a client for the
product he owns.
9.10. Operations Team Role

 Conducting of deployment activities on all Yesser non-production environments.
 Conducting of deployment activities on all Yesser production environments.
 Maintaining all Yesser environments.

10. Process Measurements

Rather than defining a metric in terms of the operations we can perform (i.e. the things we
can count) to compute it, it would be preferable to think about the question we want
answered first, the nature of the information (the attributes) that could answer that
question and then define measures that can address those attributes in that context.
To evaluate a proposed metric, including one that this document proposes, it would be
useful to ask the following questions:
 What is the purpose of this measure? Examples of purposes include (facilitating
private self-assessment and improvement, or evaluating project status to facilitate
management of the project or related projects).
 What is the scope of this measure? Examples of scope include (one project done
by one workgroup, or a year's work from that workgroup).
 What is the natural scale of the attribute we are trying to measure? What type of
scale makes sense for programmer skill, or thoroughness of testing, or size?
 What measuring instrument do we use to perform the measurement? For the
attribute “length” we can use a ruler (the instrument) and read the number from it.
Examples of instruments include (Counting, Matching, Comparing and Timing).
 What are the natural and foreseeable side effects of using this measurement? If
we change our circumstances or behavior in order to improve the measured result,
what impact we are going to have on the attribute. For some cases, the measured
result looked better while the underlying performance that was allegedly being
measured was actually worse.
Since the SDLC is the result of its underlying disciplines, process measurement of the
overall SDLC will rely on each of the SDLC disciplines measurement procedures and
guidelines, please refer to each SDLC discipline process definition document for more
details.
Define measurement
objectives (business
objectives)
Specifying measurement (KPIs)
to address the defined objectives
Specify measurement collection

instruments & store procedures Specify measurement analysis &
validation procedures
Collect & analyze

measurement data
Communicate measurement
results
Figure 3 - Measurements Lifecycle

11. Appendix A – Acronyms

This appendix contains a list of acronyms used within this document along with their
explanation per each term.
Acronyms Explanation
SDLC Software Development Life Cycle
GSB Governmental Service Bus
RFC Request For Change
CAB Change Authorizing Board
BA Business Analysis
SRS Software Requirements Specifications
SCM Software Configuration Management
CI Configurable Item
IDE Integration Development Environment
KPI Key Performance Indicator
SCMP Software Configuration Management Plan
QAP Quality Assurance Plan
QA Quality Assurance
QC Quality Control
QoS Quality of Service
RACI Matrix (Responsible, Accountable, Consulted, Informed) Matrix
SOA Service Oriented Architecture

12. Appendix B – Glossary

This appendix contains a list of terms used within this document along with a brief
explanation for each term.
Term Description
Sequence of interdependent and linked procedures which, at every
stage, consume one or more resources (employee time, energy,
Process machines, money) to convert inputs (data, material, parts, etc.) into
outputs. These outputs then serve as inputs for the next stage until a
known goal or end result is reached.
A fixed, step-by-step sequence of activities or course of action (with
Procedure definite start and end points) that must be followed in the same order to
correctly perform a task.
Recommended practice that allows maturity in its interpretation,
Guideline
implementation or use.
Policy A high-level overall plan embracing the general goals and procedures.
Concept, norm, or principle established by agreement, authority, or
Standard custom, and used generally as an example or model to compare or
measure the quality or performance of a practice or procedure.
A differentiation between the expected and actual results founded in
Defect
testing phase of project.
Non conformity A failure to comply with a defined process.
The fundamental structural unit of a Configuration Management (CM)
System, the CM system oversees the life of the CIs through a
Configurable Item combination of process and tools by implementing and enabling the
fundamental elements of identification, change management, status
accounting, and audits.
The identification of significant states within the revision history of a
Baselining
Configuration Item (CI)
Measurement is the empirical objective assignment of numbers according
Measurement to a rule derived from a model or theory to attributes of an object or event
with the intent of describing them.


Yesser SDLC - Overall SDLC

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Yesser SDLC - Overall SDLC

Uploaded by

Copyright:

Available Formats

ájOƒ©°ùdG á«Hô©dG áµ∏ªŸG

Yesser Overall SDLC

1. Process Introduction ........................................................................................................ 5

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

4.30. Key Activity 9000: Plan Product Release.................................................................... 26

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

1.1. Process Scope

1.2. Process Objectives and Benefits

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

1.3. Process Interfaces with other Processes

1.4. Process Entry & Exit Criteria

1.4.1. Process Entry Criteria

1.4.2. Process Exit Criteria

1.5. Process Inputs & Output

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

1.5.1. Process Inputs

1.5.2. Process Outputs

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

2. Process Key Elements

Figure 1 - SDLC Key Element Flow Chart

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

2.1. RFC Assessment

2.2. Requirements Development & Management

2.3. Solution Architecture

2.4. Solution Design

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

2.5. Solution Development

2.6. Solution Deployment

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

2.7. Solution Verification (Quality Control)

2.8. Software Configuration Management

2.9. Quality Assurance

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

2.10. Solution Tracking & Monitoring

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

3. Process Flow Diagram

Figure 2 – Overall SDLC Process Flow Diagram

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

4. Process Key Activities

4.1. Key Activity 1000: Needs Requirements Definition?

4.2. Key Activity 1010: Understand Solution Needs

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

4.3. Key Activity 1020: Analyze Requirements

4.4. Key Activity 1040: Create the System Requirements

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

4.5. Key Activity 1050: Get Approval on SRS

4.6. Key Activity 2000: Needs Architecture Involvement?

4.7. Key Activity 2030: Prepare Solution Architecture

Confidential e-Government Program (Yesser)

This document (either in whole or in part) cannot be modified or

4.8. Key Activity 3000: Needs Design Involvement?