ájoƒ ùdg á«hô dg áµلªÿg Yesser Overall SDLC Process Definition

Transcription

1 ájoƒ ùdg á«hô dg áµلªÿg Yesser Overall SDLC Process Definition

2 Version Page 3 / 43 Table of Contents 1. Process Introduction Process Scope Process Objectives and Benefits Process Interfaces with other Processes Process Entry & Exit Criteria Process Entry Criteria Process Exit Criteria Process Inputs & Output Process Inputs Process Outputs Process Key Elements RFC Assessment Requirements Development & Management Solution Architecture Solution Design Solution Development Solution Deployment Solution Verification (Quality Control) Software Configuration Management Quality Assurance Solution Tracking & Monitoring Process Flow Diagram Process Key Activities Key Activity 1000: Needs Requirements Definition? Key Activity 1010: Understand Solution Needs Key Activity 1020: Analyze Requirements Key Activity 1040: Create the System Requirements Definition Key Activity 1050: Get Approval on SRS Key Activity 2000: Needs Architecture Involvement? Key Activity 2030: Prepare Solution Architecture Key Activity 3000: Needs Design Involvement? Key Activity 3010: Prepare Solution Design Key Activity 3020: Prepare Deployment Manual Key Activity 3030: Prepare Release Notes Key Activity 4000: Needs Development Involvement? Key Activity 4010: Implement the Design of the Product Component Key Activity 5000: Release Planning Key Activity 5010: Deployment Sanity Check Key Activity 5020: Production Sanity Check Key Activity 5030: Production Release Planning Key Activity 6000: Needs Quality Involvement? Key Activity 6010: Test Planning Key Activity 6020: Test Analysis Key Activity 6035: Updating Test Cases Key Activity 6030: Test Execution Key Activity 6040: Proceed to UAT? Key Activity 6050: Conduct UAT Key Activity 6060: Proceed to Production? Key Activity 7000: Plan Configuration Management Activities Key Activity 7010: Review Configuration Management Activities Implementation Key Activity 8000: Plan Quality Assurance Activities Key Activity 8010: Review Process Implementation and Work Products... 26

3 Version Page 4 / Key Activity 9000: Plan Product Release Key Activity 9010: Product Implementation Tracking, Monitoring & Control Key Activity 9020: Product Closure & Announcement Key Activity 0010: Execute Deployment Key Activity 0020: Execute Production Deployment Process Guidelines The Approved Request For Change (RFC) The SDLC Disciplines Process Tailoring Guidelines Establishing Yesser Measurements Repository Establishing Yesser Process Assets Library Process Deliverables Software Requirements Specifications (SRS) Solution Architecture Solution Design Deployment Manual Solution Build Announcement Release Notes Test Plan Test Cases User Acceptance Testing (UAT) Report Software Configuration Management Plan (SCMP) SCM Nonconformities Report Quality Assurance Plan (QAP) Quality Assurance (QA) Review Findings Report Progress Status Report Process Policies Process RACI Matrix Process Roles & Responsibilities Business Analyst Role Solution Architect Role Software Designer Role Software Developer Role Release Management Officer Role Quality Control Team Role Configuration Management Officer Role Quality Assurance Officer Role Product Owner Role Operations Team Role Process Measurements Appendix A Acronyms Appendix B Glossary... 43

4 Version Page 5 / 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 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.

5 Version Page 6 / 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 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 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 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.

6 Version Page 7 / 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 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.

7 Version Page 8 / 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

8 Version Page 9 / 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 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 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 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.

9 Version Page 10 / 43 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 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 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.

10 Version Page 11 / 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 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 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.

11 Version Page 12 / 43 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 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.

12 Version Page 13 / Process Flow Diagram Figure 2 Overall SDLC Process Flow Diagram

13 Version Page 14 / 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 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 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.

14 Version Page 15 / 43 Please refer to the Requirements Management Process Definition document for more details about this process key activity 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. Please refer to the Requirements Management Process Definition document for more details about this process key activity 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 Please refer to the Requirements Management Process Definition document for more details about this process key activity.

15 Version Page 16 / 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. Please refer to the Requirements Management Process Definition document for more details about this process key activity 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 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

16 Version Page 17 / 43 Please refer to the Analysis and Design Process Definition document for more details about this process key activity 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? Please refer to the Analysis and Design Process Definition document for more details about this process key activity 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. Please refer to the Analysis and Design Process Definition document for more details about this process key activity.

17 Version Page 18 / 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. Please refer to the Analysis and Design Process Definition document for more details about this process key activity 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.

18 Version Page 19 / 43 Please refer to the Build and Release Management Process Definition document for more details about this process key activity 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 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.

19 4.14. Key Activity 5000: Release Planning e-government Program (Yesser) Version Page 20 / 43 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. Please refer to the Build and Release Management Process Definition document for more details about this process key activity 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. Please refer to the Build and Release Management Process Definition document for more details about this process key activity 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.

20 Version Page 21 / 43 Please refer to the Build and Release Management Process Definition document for more details about this process key activity 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. Please refer to the Build and Release Management Process Definition document for more details about this process key activity 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.

21 4.19. Key Activity 6010: Test Planning e-government Program (Yesser) Version Page 22 / 43 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. Please refer to the Quality Management Process Definition document for more details about this process key activity 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. Please refer to the Quality Management Process Definition document for more details about this process key activity 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. Please refer to the Quality Management Process Definition document for more details about this process key activity 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

22 Version Page 23 / 43 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 Please refer to the Quality Management Process Definition document for more details about this process key activity 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 Please refer to the Quality Management Process Definition document for more details about this process key activity 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:

23 Version Page 24 / 43 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. Please refer to the Quality Management Process Definition document for more details about this process key activity 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 golive 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. Please refer to the Quality Management Process Definition document for more details about this process key activity 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.

24 Version Page 25 / 43 Please refer to the Configuration and Change Management Process Definition document for more details about this process key activity 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 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. Please refer to the Quality Management Process Definition document for more details about this process key activity.

25 Version Page 26 / 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. Please refer to the Quality Management Process Definition document for more details about this process key activity 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 SDLCrelated 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 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.

26 Version Page 27 / 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 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. Please refer to the Build and Release Management Process Definition document for more details about this process key activity 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. Please refer to the Build and Release Management Process Definition document for more details about this process key activity.