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

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "á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.

Project Lifecycle Management (PLM)

Project Lifecycle Management (PLM) Project Lifecycle Management (PLM) Process or Tool? Why PLM? Project Definition Project Management NEW REQUEST/ INITIATIVES SUPPORT (Quick fixes) PROJECT (Start Finish) ONGOING WORK (Continuous) ENHANCEMENTS

More information

Appendix 2-A. Application and System Development Requirements

Appendix 2-A. Application and System Development Requirements Appendix 2-A. Application and System Development Requirements Introduction AHRQ has set up a Distributed Systems Engineering Lab (DSEL) to support all internal development efforts and provide a facility

More information

Time Monitoring Tool Software Development Plan. Version <1.1>

Time Monitoring Tool Software Development Plan. Version <1.1> Time Monitoring Tool Software Development Plan Version Revision History Date Version Description Author 10/01/01 1.0 First Draft Sabrina Laflamme 12/01/01 1.1 Completion of Document John Lemon Page

More information

Process Description Incident/Request. HUIT Process Description v6.docx February 12, 2013 Version 6

Process Description Incident/Request. HUIT Process Description v6.docx February 12, 2013 Version 6 Process Description Incident/Request HUIT Process Description v6.docx February 12, 2013 Version 6 Document Change Control Version # Date of Issue Author(s) Brief Description 1.0 1/21/2013 J.Worthington

More information

Release Management Policy Aspen Marketing Services Version 1.1

Release Management Policy Aspen Marketing Services Version 1.1 Release Management Policy Version 1.1 John Toso 5/10/2010 2 Contents Release Management Policy Overview:... 3 Critical Success Factors... 3 Service Level Management (SLM)... 4 Key Performance Indicators:...

More information

HP Service Manager. Software Version: 9.40 For the supported Windows and Linux operating systems. Processes and Best Practices Guide (Codeless Mode)

HP Service Manager. Software Version: 9.40 For the supported Windows and Linux operating systems. Processes and Best Practices Guide (Codeless Mode) HP Service Manager Software Version: 9.40 For the supported Windows and Linux operating systems Processes and Best Practices Guide (Codeless Mode) Document Release Date: December, 2014 Software Release

More information

Plan-Driven Methodologies

Plan-Driven Methodologies Plan-Driven Methodologies The traditional way to develop software Based on system engineering and quality disciplines (process improvement) Standards developed from DoD & industry to make process fit a

More information

VAIL-Plant Asset Integrity Management System. Software Development Process

VAIL-Plant Asset Integrity Management System. Software Development Process VAIL-Plant Asset Integrity Management System Software Development Process Document Number: VAIL/SDP/2008/008 Engineering For a Safer World P u b l i c Approved by : Ijaz Ul Karim Rao Revision: 0 Page:2-of-15

More information

Software Configuration Management Plan

Software Configuration Management Plan For Database Applications Document ID: Version: 2.0c Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 22 Copyright 2000-2005 Digital Publications LLC.

More information

Quality Assurance - Karthik

Quality Assurance - Karthik Prevention is better than cure Quality Assurance - Karthik This maxim perfectly explains the difference between quality assurance and quality control. Quality Assurance is a set of processes that needs

More information

PHASE 8: IMPLEMENTATION PHASE

PHASE 8: IMPLEMENTATION PHASE PHASE 8: IMPLEMENTATION PHASE The Implementation Phase has one key activity: deploying the new system in its target environment. Supporting actions include training end-users and preparing to turn the

More information

Essentials of the Quality Assurance Practice Principles of Testing Test Documentation Techniques. Target Audience: Prerequisites:

Essentials of the Quality Assurance Practice Principles of Testing Test Documentation Techniques. Target Audience: Prerequisites: Curriculum Certified Software Tester (CST) Common Body of Knowledge Control Procedures Problem Resolution Reports Requirements Test Builds Test Cases Test Execution Test Plans Test Planning Testing Concepts

More information

Integrating Project Management and Service Management

Integrating Project Management and Service Management Integrating Project and Integrating Project and By Reg Lo with contributions from Michael Robinson. 1 Introduction Project has become a well recognized management discipline within IT. is also becoming

More information

Software Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti

Software Engineering. Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti Software Engineering Session 3 Main Theme Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical

More information

Configuration management for test professionals CMMI Way!

Configuration management for test professionals CMMI Way! Configuration management for test professionals CMMI Way! Accenture, its logo, and Accenture High Performance Delivered are trademarks of Accenture. Agenda Objectives Configuration Management (CM) Concepts

More information

Department of Administration Portfolio Management System 1.3 June 30, 2010

Department of Administration Portfolio Management System 1.3 June 30, 2010 E 06/ 30/ 2010 EX AM PL 1. 3 06/ 28/ 2010 06/ 24/ 2010 06/ 23/ 2010 06/ 15/ 2010 06/ 18/ 2010 Portfolio System 1.3 June 30, 2010 Contents Section 1. Project Overview... 1 1.1 Project Description... 1 1.2

More information

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK IBM Software Group Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK Jean-Louis Maréchaux Software IT Specialist IBM Rational

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Document Purpose The purpose of this document is to provide guidance on the practice of Requirements Definition and to describe the practice overview, requirements, best practices, activities, and key

More information

Ellucian Implementation Methodology. Summary of Project Management and Solution Delivery Phases

Ellucian Implementation Methodology. Summary of Project Management and Solution Delivery Phases Ellucian Implementation Methodology Summary of Project Management and Solution Delivery Phases Rev. 5/10/2013 Table of Contents Overview 3 Project Management Initiation 4 Planning 5 Execution 6 Monitor

More information

Procedure for Assessment of System and Software

Procedure for Assessment of System and Software Doc. No: STQC IT/ Assessment/ 01, Version 1.0 Procedure for Assessment of System and Software May, 2014 STQC - IT Services STQC Directorate, Department of Electronics and Information Technology, Ministry

More information

System Development Life Cycle Guide

System Development Life Cycle Guide TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release

More information

Program Lifecycle Methodology Version 1.7

Program Lifecycle Methodology Version 1.7 Version 1.7 March 30, 2011 REVISION HISTORY VERSION NO. DATE DESCRIPTION AUTHOR 1.0 Initial Draft Hkelley 1.2 10/22/08 Updated with feedback Hkelley 1.3 1/7/2009 Copy edited Kevans 1.4 4/22/2010 Updated

More information

Yale University Change Management Process Guide

Yale University Change Management Process Guide Yale University Management Process Guide Yale University Management Process 1 of 29 Table of Contents Introduction... 3 Purpose... 3 Scope... 3 Management Overview... 3 Management Key Concepts... 4 Management

More information

CHAPTER 7 Software Configuration Management

CHAPTER 7 Software Configuration Management CHAPTER 7 Software Configuration Management ACRONYMS CCB CM FCA MTBF PCA SCCB SCI SCM SCMP SCR SCSA SEI/CMMI SQA SRS USNRC INTRODUCTION Configuration Control Board Configuration Management Functional Configuration

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

Requirements Management Database

Requirements Management Database Project Whitepaper Compliance with Pragmatic Marketing s That Work, LLC Project Whitepaper - Pragmatic Marketing's That Work Page 1 of 16 Introduction The Database has been designed for maximum flexibility

More information

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK

SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK Office of Safety and Mission Assurance NASA-GB-9503 SOFTWARE CONFIGURATION MANAGEMENT GUIDEBOOK AUGUST 1995 National Aeronautics and Space Administration Washington, D.C. 20546 PREFACE The growth in cost

More information

Service Catalog Management: A CA Service Management Process Map

Service Catalog Management: A CA Service Management Process Map TECHNOLOGY BRIEF: SERVICE CATALOG MANAGEMENT Catalog : A CA Process Map JULY 2009 Enrico Boverino SR PRINCIPAL CONSULTANT, TECHNICAL SALES ITIL SERVICE MANAGER ITAC CERTIFIED Table of Contents Executive

More information

Software Quality Assurance Plan

Software Quality Assurance Plan For Database Applications Document ID: Version: 2.1a Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 54 Copyright 2000-2006 Digital Publications LLC.

More information

Softjourn, Inc. s QA Testing Process

Softjourn, Inc. s QA Testing Process Softjourn, Inc. s QA Process Date of Last Update: June 05, 2007 Version: 2.0 Author: Softjourn, Inc. Headquarters 39270 Paseo Padre Pkwy #251 Fremont, CA 94536 USA p: +1.510.744.1528 f: +1. 815.301.2772

More information

PASTA Abstract. Process for Attack S imulation & Threat Assessment Abstract. VerSprite, LLC Copyright 2013

PASTA Abstract. Process for Attack S imulation & Threat Assessment Abstract. VerSprite, LLC Copyright 2013 2013 PASTA Abstract Process for Attack S imulation & Threat Assessment Abstract VerSprite, LLC Copyright 2013 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

More information

Custom Software Development Approach

Custom Software Development Approach Custom Software Development Approach Our approach to custom software development combines benefits from several standard development process models. We tend to have a well-defined, predictable and highly

More information

HKITPC Competency Definition

HKITPC Competency Definition HKITPC Competency Definition for the Certification copyright 2011 HKITPC HKITPC Competency Definition Document Number: HKCS-CD-L1L2 Version: 1.0 Date: June 2011 Prepared by Hong Kong IT Professional Certification

More information

RFP Attachment C Classifications

RFP Attachment C Classifications RFP 1. Applications IT Architect Analyzes and designs the architecture for software applications and enhancements, including the appropriate application of frameworks and design patterns and the interrelationships

More information

An Implementation Roadmap

An Implementation Roadmap An Implementation Roadmap The 2nd Abu Dhabi IT s Forum P J Corum, CSQA, CSTE, ITSM Managing Director Quality Assurance Institute Middle East and Africa Dubai, UAE Quality Assurance Institute Middle East

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

Project Implementation Process (PIP)

Project Implementation Process (PIP) Vanderbilt University Medical Center Project Implementation Process (PIP).......... Project Implementation Process OVERVIEW...4 PROJECT PLANNING PHASE...5 PHASE PURPOSE... 5 TASK: TRANSITION FROM PEP TO

More information

QA Roles and Responsibilities

QA Roles and Responsibilities QA Roles and Responsibilities There are various roles on projects, some people may play more than one role. You should always check with your organizations testing methodology on what your role(s) are.

More information

USGS EOS SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP)

USGS EOS SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP) Department of the Interior U.S. Geological Survey USGS EOS SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP) September 2013 Executive Summary This Systems Engineering Management Plan (SEMP) outlines the engineering

More information

MNLARS Project Audit Checklist

MNLARS Project Audit Checklist Audit Checklist The following provides a detailed checklist to assist the audit team in reviewing the health of a project. Relevance (at this time) How relevant is this attribute to this project or audit?

More information

PHASE 6: DEVELOPMENT PHASE

PHASE 6: DEVELOPMENT PHASE PHASE 6: DEVELOPMENT PHASE The Phase features a key step in the project: system construction. The previous phases lay the foundation for system development; the following phases ensure that the product

More information

COMMONWEALTH OF MASSACHUSETTS EXECUTIVE OFFICE OF HEALTH AND HUMAN SERVICES

COMMONWEALTH OF MASSACHUSETTS EXECUTIVE OFFICE OF HEALTH AND HUMAN SERVICES COMMONWEALTH OF MASSACHUSETTS EXECUTIVE OFFICE OF HEALTH AND HUMAN SERVICES The Office of Information Technology Project Methodology and Lifecycle Guide Version 4.4 Last Updated: November 15, 2011 CE M

More information

Software Development Life Cycle (SDLC)

Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) Supriyo Bhattacharjee MOF Capability Maturity Model (CMM) A bench-mark for measuring the maturity of an organization s software process CMM defines 5 levels of process

More information

D6.1: Service management tools implementation and maturity baseline assessment framework

D6.1: Service management tools implementation and maturity baseline assessment framework D6.1: Service management tools implementation and maturity baseline assessment framework Deliverable Document ID Status Version Author(s) Due FedSM- D6.1 Final 1.1 Tomasz Szepieniec, All M10 (31 June 2013)

More information

The Software Development Life Cycle (SDLC)

The Software Development Life Cycle (SDLC) Document ID: Version: 2.0 1 / 22 2 TABLE OF CONTENTS INTRODUCTION... 4 THE SDLC WATERFALL... 4 ALLOWED VARIATIONS... 5 OTHER SDLC MODELS... 6 REFERENCES... 7 GENERIC STAGE... 8 KICKOFF PROCESS... 8 INFORMAL

More information

IT PROCESSES BEST PRACTICES FOR. Version 1.0 Date: 04/06/2007

IT PROCESSES BEST PRACTICES FOR. Version 1.0 Date: 04/06/2007 BEST PRACTICES FOR IT PROCESSES Version 1.0 Date: 04/06/2007 The Saudi e-government Program (Yesser) has exerted its best effort to achieve the quality, reliability, and accuracy of the information contained

More information

ITIL by Test-king. Exam code: ITIL-F. Exam name: ITIL Foundation. Version 15.0

ITIL by Test-king. Exam code: ITIL-F. Exam name: ITIL Foundation. Version 15.0 ITIL by Test-king Number: ITIL-F Passing Score: 800 Time Limit: 120 min File Version: 15.0 Sections 1. Service Management as a practice 2. The Service Lifecycle 3. Generic concepts and definitions 4. Key

More information

Free ITIL v.3. Foundation. Exam Sample Paper 4. You have 1 hour to complete all 40 Questions. You must get 26 or more correct to pass

Free ITIL v.3. Foundation. Exam Sample Paper 4. You have 1 hour to complete all 40 Questions. You must get 26 or more correct to pass Free ITIL v.3. Foundation Exam Sample Paper 4 You have 1 hour to complete all 40 Questions You must get 26 or more correct to pass Compliments of Advance ITSM www.advanceitsm.com 1 A Service is not very

More information

Service Integration &

Service Integration & This is a DRAFT document, being published for review & comment The content is therefore subject to change & revision This document is part of the XGOV Strategic SIAM reference set Service Integration &

More information

Process Description Change Management

Process Description Change Management Process Description Change Management Version 4.1 April, 2013 Document Change Control Version # Date of Issue Author(s) Brief Description 1.0 3/8/13 J.Worthington Initial Draft 2.0 3/25/13 J.Worthington

More information

SECTION 4 TESTING & QUALITY CONTROL

SECTION 4 TESTING & QUALITY CONTROL Page 1 SECTION 4 TESTING & QUALITY CONTROL TESTING METHODOLOGY & THE TESTING LIFECYCLE The stages of the Testing Life Cycle are: Requirements Analysis, Planning, Test Case Development, Test Environment

More information

Example Software Development Process.

Example Software Development Process. Example Software Development Process. The example software development process is shown in Figure A. The boxes represent the software development process kernels. The Software Unit Testing, Software Component

More information

Requirements Definition and Management Processes

Requirements Definition and Management Processes Software Engineering G22.2440-001 Session 1 Sub-Topic 1 Requirements Definition & Management Processes and Tools Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute

More information

ITIL v3 Service Manager Bridge

ITIL v3 Service Manager Bridge ITIL v3 Service Manager Bridge Course Length: 5 Days Course Overview This 5 day hands on, certification training program enables ITIL Version 2 certified Service Managers to upgrade their Service Manager

More information

HP Service Manager. Software Version: 9.34 For the supported Windows and UNIX operating systems. Processes and Best Practices Guide

HP Service Manager. Software Version: 9.34 For the supported Windows and UNIX operating systems. Processes and Best Practices Guide HP Service Manager Software Version: 9.34 For the supported Windows and UNIX operating systems Processes and Best Practices Guide Document Release Date: July 2014 Software Release Date: July 2014 Legal

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

ITSM Process Description

ITSM Process Description ITSM Process Description Office of Information Technology Incident Management 1 Table of Contents Table of Contents 1. Introduction 2. Incident Management Goals, Objectives, CSFs and KPIs 3. Incident Management

More information

Requirements Analysis/Gathering. System Requirements Specification. Software/System Design. Design Specification. Coding. Source Code.

Requirements Analysis/Gathering. System Requirements Specification. Software/System Design. Design Specification. Coding. Source Code. Change Control and Configuration Management IVT 11 th Annual conference April 2010 DISCLAIMER Amgen is not responsible for the written or verbal bl content t of fthi this presentation tti Gisele Fahmi,

More information

MKS Integrity & CMMI. July, 2007

MKS Integrity & CMMI. July, 2007 & CMMI July, 2007 Why the drive for CMMI? Missed commitments Spiralling costs Late delivery to the market Last minute crunches Inadequate management visibility Too many surprises Quality problems Customer

More information

Surveying and evaluating tools for managing processes for software intensive systems

Surveying and evaluating tools for managing processes for software intensive systems Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB

More information

Automated Office Systems Support Quality Assurance Plan. A Model DRAFT. December 1996

Automated Office Systems Support Quality Assurance Plan. A Model DRAFT. December 1996 Quality Assurance Plan A Model DRAFT United States Department of Energy Office of Nonproliferation and National Security Title Page Document Name: Publication Date: Draft, ontract Number: Project Number:

More information

Chapter 3 The Integrated Requirements Management Framework (IREQM)

Chapter 3 The Integrated Requirements Management Framework (IREQM) Chapter 3 The Integrated Management Framework (IREQM) During the software requirements development process, customer and development team meet together for many times to obtain customer and product requirements

More information

Enterprise Test Management Standards

Enterprise Test Management Standards Enterprise Test Management Standards Version 4.0 09/28/2012 Document Number: FSA_TOADG_STDS_TEST.TMS_001 Document Version Control This section summarizes this document revision history. Each entry includes

More information

Independent Verification and Validation of SAPHIRE 8 Software Project Plan

Independent Verification and Validation of SAPHIRE 8 Software Project Plan INL/EXT-09-17022 Rev. 2 Independent Verification and Validation of SAPHIRE 8 Software Project Plan March 2010 The INL is a U.S. Department of Energy National Laboratory operated by Battelle Energy Alliance

More information

PHASE 9: OPERATIONS AND MAINTENANCE PHASE

PHASE 9: OPERATIONS AND MAINTENANCE PHASE PHASE 9: OPERATIONS AND MAINTENANCE PHASE During the Operations and Maintenance Phase, the information system s availability and performance in executing the work for which it was designed is maintained.

More information

A Guide To The Project Management Body of Knowledge (PMBOK) Significant Changes from the 3 rd edition to the 4 th edition

A Guide To The Project Management Body of Knowledge (PMBOK) Significant Changes from the 3 rd edition to the 4 th edition A Guide To The Project Body of Knowledge (PMBOK) Significant Changes from the 3 rd edition to the 4 th edition Major Changes The adoption of the verb-noun format for process names Amplification as to Enterprise

More information

ITIL v3 Service transition glossary

ITIL v3 Service transition glossary ITIL v3 Service transition glossary Term Assembly Assessment Asset management Asset register Attribute Audit Authority matrix Back out Best practice British Standards Institution (BSI) Build Build environment

More information

TEST METRICS AND KPI S

TEST METRICS AND KPI S WHITE PAPER TEST METRICS AND KPI S Abstract This document serves as a guideline for understanding metrics and the Key performance indicators for a testing project. Metrics are parameters or measures of

More information

REQUIREMENT DRIVEN TESTING. Test Plan for. Project name. Requirement Driven Testing [Pick the date]

REQUIREMENT DRIVEN TESTING. Test Plan for. Project name. Requirement Driven Testing [Pick the date] REQUIREMENT DRIVEN TESTING Test Plan for Project name Requirement Driven Testing [Pick the date] [Type the abstract of the document here. The abstract is typically a short summary of the contents of the

More information

Service Delivery Module

Service Delivery Module Service Delivery Module Software Development Methodology -India follows international industry standards and has adopted the standard methodology in our Software Development Life Cycle (SDLC). It is a

More information

Software Engineering Compiled By: Roshani Ghimire Page 1

Software Engineering Compiled By: Roshani Ghimire Page 1 Unit 7: Metric for Process and Product 7.1 Software Measurement Measurement is the process by which numbers or symbols are assigned to the attributes of entities in the real world in such a way as to define

More information

SA Tool Kit release life cycle

SA Tool Kit release life cycle Release management Release management process is a software engineering process intended to oversee the development, testing, deployment and support of software releases. A release is usually a named collection

More information

Business Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM

Business Analyst Work Plan. Presented by: Billie Johnson, CBAP CSM Business Analyst Work Plan Presented by: Billie Johnson, CBAP CSM Agenda Topic Introduction Overview of a Business Analysis Work Plan Initiating a Business Analysis Effort Components of the Business Analysis

More information

PHASE 5: DESIGN PHASE

PHASE 5: DESIGN PHASE PHASE 5: DESIGN PHASE During the Design Phase, the system is designed to satisfy the requirements identified in the previous phases. The requirements identified in the Requirements Analysis Phase are transformed

More information

Information Technology Services ServiceNow: Change Management Phase I Project Charter

Information Technology Services ServiceNow: Change Management Phase I Project Charter ServiceNow: Change Management Phase I Project Charter VERSION: 1.3 REVISION DATE: 9/28/2011 Approval of the Project Charter indicates an understanding of the purpose and content described in this deliverable.

More information

Request for Proposal for Application Development and Maintenance Services for XML Store platforms

Request for Proposal for Application Development and Maintenance Services for XML Store platforms Request for Proposal for Application Development and Maintenance s for ML Store platforms Annex 4: Application Development & Maintenance Requirements Description TABLE OF CONTENTS Page 1 1.0 s Overview...

More information

Test Plan (a Real Sample) SoftwareTestingHelp.com Live Project Training - OrangeHRM

Test Plan (a Real Sample) SoftwareTestingHelp.com Live Project Training - OrangeHRM www.softwaretestinghelp.com Test Plan (a Real Sample) SoftwareTestingHelp.com Live Project Training - OrangeHRM 2/1/2014 SoftwareTestingHelp.com Name of the tester Note: This is a sample test plan created

More information

Business Analysis Lifecycle

Business Analysis Lifecycle Business Analysis Lifecycle by Sergey Korban Aotea Studios Ltd November 2011 Contents Introduction... 3 Business Analysis Lifecycle... 4 Practical Application... 5 Start-Up Phase... 5 Initiation Phase...

More information

ITIL Roles Descriptions

ITIL Roles Descriptions ITIL Roles s Role Process Liaison Incident Analyst Operations Assurance Analyst Infrastructure Solution Architect Problem Manager Problem Owner Change Manager Change Owner CAB Member Release Analyst Test

More information

Appeals Case Management System Project. Scope Management Plan. November 20, 2014

Appeals Case Management System Project. Scope Management Plan. November 20, 2014 Appeals Case Management System Project Version 1.0 Health and Human Services Agency, Office of Systems Integration Template Revision History REVISION HISTORY REVISION # DATE OF RELEASE OWNER SUMMARY OF

More information

Product Build. ProPath. Office of Information and Technology

Product Build. ProPath. Office of Information and Technology Product Build ProPath Office of Information and Technology Table of Contents Product Build Process Maps... 1 Process: Product Build... 3 Product Build and Goals... 4... 4 Goals... 4 Product Build RACI

More information

Glendale Community College Microsoft Office SharePoint Server 2007 Initiative Vision/Scope Document. Version 1.0

Glendale Community College Microsoft Office SharePoint Server 2007 Initiative Vision/Scope Document. Version 1.0 ware Architects, Inc. Proposal to XXXXX Date Glendale Community College Microsoft Office SharePoint Server 2007 Initiative Vision/Scope Document Software Architects, Inc. Proposal to XXXXX Date Version

More information

7 Practical insights for IT Asset Management

7 Practical insights for IT Asset Management 7 Practical insights for IT Asset Management Tauneel McKay Director Swiss Reinsurance Company Ltd Subbarao Chaganty Principal Consultant Infosys Ltd RELATE MANAGE.. Context KNOW. Consolidate the IT Asset

More information

Blend Approach of IT Service Management and PMBOK for Application Support Project

Blend Approach of IT Service Management and PMBOK for Application Support Project Blend Approach of IT Service and PMBOK for Application Support Project Introduction: This paper addresses the process area, phases and documentation to be done for Support Project using Project and ITSM

More information

AUTHOR: REVISION BY: ADS Lead/Manager ESYS Windows OSA

AUTHOR: REVISION BY: ADS Lead/Manager ESYS Windows OSA INFORMATION RESOURCES APPLICATIONS AND DATA SERVICES PROCESS NAME: ADS Web Application Release Management ORIGINAL DOCUMENT DATE: 10/2/2014 AUTHOR: Jim Nelson PROCESS OWNERS: ADS Lead/Manager LAST REVISION:

More information

Wilhelmenia Ravenell IT Manager Eli Lilly and Company

Wilhelmenia Ravenell IT Manager Eli Lilly and Company Wilhelmenia Ravenell IT Manager Eli Lilly and Company Agenda Introductions The Service Management Framework Keys of a successful Service management transformation Why transform? ROI and the customer experience

More information

Release Management. ProPath. Office of Information and Technology

Release Management. ProPath. Office of Information and Technology Release Management ProPath Office of Information and Technology Table of Contents Release Management Process Maps... 1 Process: Release Management... 7 Release Management and Goals... 9... 9 Goals... 9

More information

LANDesk Professional Services

LANDesk Professional Services LANDesk Professional Services Service Description For G-Cloud Background Drawing upon 25 years of experience, LANDesk today is recognized as a leading provider of systems and endpoint security management,

More information

Independent Test and Evaluation

Independent Test and Evaluation Independent Test and Evaluation ProPath Office of Information and Technology Table of Contents Independent Test and Evaluation Process Maps... 1 Process: Independent Test and Evaluation... 3 Independent

More information

1. Introduction. Annex 7 Software Project Audit Process

1. Introduction. Annex 7 Software Project Audit Process Annex 7 Software Project Audit Process 1. Introduction 1.1 Purpose Purpose of this document is to describe the Software Project Audit Process which capable of capturing different different activities take

More information

BAL2-1 Professional Skills for the Business Analyst

BAL2-1 Professional Skills for the Business Analyst 1 BAL2-1 Professional Skills for the Business Analyst OVERVIEW This course trains participants to help business clients articulate their needs and wants, and to document them clearly, concisely, and completely.

More information

Vertex Information & Computer Consulting Services, Inc. Program and Project Management Approach

Vertex Information & Computer Consulting Services, Inc. Program and Project Management Approach Vertex Information & Computer Consulting Services, Inc. Program and Project Management Approach VICCS, Inc. 11821 Parklawn Drive, Suite 206 Rockville, MD 20852 TEL: 301-984-1355 FAX: 301-984-1360 Program

More information

White Paper August 2006. BMC Best Practice Process Flows for ITIL Change Management

White Paper August 2006. BMC Best Practice Process Flows for ITIL Change Management White Paper August 2006 BMC Best Practice Process Flows for ITIL Change Management Copyright 1991 2006 BMC Software, Inc. All rights reserved. BMC, the BMC logo, all other BMC product or service names,

More information

Skatteudvalget 2014-15 (2. samling) SAU Alm.del Bilag 48 Offentligt. Programme, Project & Service Management Analysis

Skatteudvalget 2014-15 (2. samling) SAU Alm.del Bilag 48 Offentligt. Programme, Project & Service Management Analysis Skatteudvalget 2014-15 (2. samling) SAU Alm.del Bilag 48 Offentligt Programme, Project & Service Management Analysis Table of Content 1 Executive Summary... 3 1.1 Scope of Work... 3 1.2 Methodology for

More information

Short Guides to IDA Quality Assurance Guidelines. Development and Validation Phase. Issue 2.0

Short Guides to IDA Quality Assurance Guidelines. Development and Validation Phase. Issue 2.0 Short Guides to IDA Quality Assurance Guidelines Development and Validation Phase Issue 2.0 Short Guide Development and Validation Phase Page ii TABLE OF CONTENTS 1 PREFACE...1 1.1 Purpose of this document...1

More information

The most suitable system methodology for the proposed system is drawn out.

The most suitable system methodology for the proposed system is drawn out. 3.0 Methodology 3.1 Introduction In this chapter, five software development life cycle models are compared and discussed briefly. The most suitable system methodology for the proposed system is drawn out.

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Purpose The purpose of this document is to provide guidance on the practice called Project Close-Out and to describe the practice overview, requirements, best practices, activities, and key terms related

More information

SOFTWARE PROJECT MANAGEMENT

SOFTWARE PROJECT MANAGEMENT SOFTWARE PROJECT MANAGEMENT http://www.tutorialspoint.com/software_engineering/software_project_management.htm Copyright tutorialspoint.com The job pattern of an IT company engaged in software development

More information

New York Health Benefit Exchange

New York Health Benefit Exchange Item Number New ork Health Benefit Exchange Detailed Design Review Summary for 9.0 Technology October 26, 2012 Topic 9.3.3 IV&V Reports, Quality Management section of the PMP Note: The Quality Management

More information