yesser overall sdlc process definition...yesser overall sdlc process definition version 0.6 - page 3...

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

Yesser Overall SDLCProcess Definition

e-Government Program (Yesser)

Yesser Overall SDLC Process Definition

Version 0.6 - Page 3 / 43

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)

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







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.

Please refer to the “Analysis and Design Process Definition” document for more details about this process key element.

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 about this process key element.

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.

Please refer to the “Quality Management Process Definition” document for more details about this process key element.

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?”

Please refer to the “Requirements Management Process Definition” document for more 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?”

Please refer to the “Analysis and Design Process Definition” document for more details 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.







Please refer to the “Build and Release Management Process Definition” document for 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?”

Please refer to the “Development Process Definition” document for more details about this 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.

Please refer to the “Development Process Definition” document for more details about this 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.

Please refer to the “Quality Management Process Definition” document for more details about this process key activity.







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”.

Please refer to the “Configuration and Change Management Process Definition” document 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”.

The outcome of this process key activity is considered an input for most project teams and 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

This process key activity is considered an umbrella activity that spans throughout the 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”.

The outcome of this process key activity is considered an input for most project teams and to provide a clear understanding of the expectations from each project team.

4.31. Key Activity 9010: Product Implementation Tracking, Monitoring & Control

This process key activity is considered an umbrella activity that spans throughout the 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)

11 Software Configuration Management (SCM) 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.

Please refer to the “Requirements Management Process Definition” document for more 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.

Please refer to the “Build and Release Management Process Definition” document for 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.








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.


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.

Please refer to the “Configuration and Change Management Process Definition” document 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.







Please refer to the “Configuration and Change Management Process Definition” document 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

1 All items and activities under the Yesser SDLC should be planned, reviewed and approved by the end of the planning phase (i.e. before execution).

2 Adequate recourses (material, people, and tools like EPM) need to be provided to carry out the SDLC activities.

3 The resources that will perform their assigned SDLC activities should be trained to carry out their designated activities.

4 Audits on the SDLC activities should be conducted to guarantee adherence with the defined SDLC process.

5 Tailoring guidelines should be defined for all process areas and they shall all be maintained in the organizational centralized repository

6 All project work products resulting from the SDLC should always be kept under a version control system.

7 Best practices and lessons learned should be captured, saved, and then used for future SDLC projects.

8 The documentation produced after each must be produced according to the templates defined within this document or as per the templates defined within each SDLC discipline process definition document.

9

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 deliverable/activity will be considered approved if no comment from the receiver was acknowledged within the defined timeframe.

10 For major RFCs, the approval of the Change Authorizing Board (CAB) will be required before initiating the development and implementation of that major RFC.

11 Refer to the policies section in “Requirements Management Process Definition 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”.

15 Refer to the policies section in “Change and Configuration Management Process Definition Document”.

16 Refer to the policies section in “Build and Release Management Process Definition 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


Providing the required assessment for SDLC-related RFCs to determine the 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


Providing the required assessment for SDLC-related RFCs to determine the 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


Providing the required assessment for SDLC-related RFCs to determine the 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


Providing the required assessment for SDLC-related RFCs to determine the 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.

Figure 3 - Measurements Lifecycle

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







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

Process

Sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, 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.

Procedure A fixed, step-by-step sequence of activities or course of action (with definite start and end points) that must be followed in the same order to correctly perform a task.

Guideline Recommended practice that allows maturity in its interpretation, implementation or use.

Policy A high-level overall plan embracing the general goals and procedures.

Standard Concept, norm, or principle established by agreement, authority, or custom, and used generally as an example or model to compare or measure the quality or performance of a practice or procedure.

Defect A differentiation between the expected and actual results founded in testing phase of project.

Non conformity A failure to comply with a defined process.

Configurable Item

The fundamental structural unit of a Configuration Management (CM) System, the CM system oversees the life of the CIs through a combination of process and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits.

Baselining The identification of significant states within the revision history of a Configuration Item (CI)

Measurement Measurement is the empirical objective assignment of numbers according to a rule derived from a model or theory to attributes of an object or event with the intent of describing them.