RCR Technology Software Development Live Cycle: SDLC Processes and Phases, Study notes of Software Development

Download RCR Technology Software Development Live Cycle: SDLC Processes and Phases and more Study notes Software Development in PDF only on Docsity! TECHNOLOGY CORP Software Development Life Cycle Process (SDLC) Overview Version 2.0-2016  RCR Technology Software Development Live Cycle Document Page 2 of 23 Document Information Document Source The following provides an overview of the Application Services (AS) Software Development Life Cycle (SDLC). Revision History Version No. Date Summary of Changes Name Revision Marks RCR Technology Software Development Live Cycle Document Page 5 of 23 d. Listing of Resources and Available Work Hours e. Key Project Assumptions f. Listing of the Project Stakeholders g. Designated Xxxxx Sponsor h. MR Program Timeline 1.1.3 Key Tasks / Activities The following are the key tasks / activities used to complete the ‘Project Definition’ phase: a. Review Xxxxx-identified priorities provided via the Change Review Board (CRB), Subject Matters Experts (SMEs), lawsuit activities, etc., as well as timelines for recent and pending policy changes and identify activities that are time sensitive relative to general MR timelines. b. Review ClearQuest (CQ) for a prioritized list of potential enhancements and defects; and the Change Management Log (posted in Sharepoint) for a listing of the approved Change Requests. c. Develop Level of Effort estimates to be used in conjunction with the output of (a) and (b) above to provide the basis for determining the preliminary scope for the MR. d. Create a preliminary MR Scope document. e. Review the preliminary MR Scope document with the Stakeholders. f. Finalize the MR Scope document and incorporate into the formal Project Charter document. g. Draft the Project Charter document, with input from the Stakeholders, for review by the Xxxxx. h. Obtain approval and signature for the Project Charter from the designated Xxxxx representative. i. Distribute Project Charter to key stakeholder(s). j. Develop a preliminary Project Schedule that includes a work breakdown structure and initial resource assignments. - Schedule will identify dependencies on Xxxxx policy changes, other systems, such as ICES, and other affected organizations, such as training. k. Update the MR Program Timeline with estimated dates. RCR Technology Software Development Live Cycle Document Page 6 of 23 l. Notify Business Analysts (BAs), Developers and Testers of work assignments and MR timeline. m. Initiate weekly MR status meetings with the Xxxxx to review progress, defects, schedule, risks, etc. A red/green/yellow indicator is used to indicate the current status of the project. The Xxxxx is also provided a budget status including a review of actual versus budgeted hours expended to date and an estimate of hours to complete. These status meetings are conducted weekly throughout the MR project by the project manager assigned to the MR. n. Post deliverables and supporting work product documentation to Sharepoint. 1.1.4 Outputs / Deliverables The following are outputs and deliverables resulting from the ‘Project Definition’ phase: a. Signed Project Charter b. Updated MR Program Timeline c. MR Scope Document, including Level of Effort estimates d. Project Schedule, MS Project Plan with work breakdown structure and initial resource assignments e. Enhancement and Defect CQs updated with Business Analyst, Developer and Tester assignments 1.2 Requirements Definition and Analysis (Requirements Modeling) 1.2.1 Description This phase includes developing a complete understanding of the business needs to be addressed and working with the appropriate Stakeholders to analyze, develop and document the business and functional requirements necessary to complete the technical design for the solution. 1.2.2 Inputs The following are inputs for the ‘Requirements Definition and Analysis’ phase: a. Signed Project Charter b. Updated MR Program Timeline c. MR Scope Document, including initial estimates RCR Technology Software Development Live Cycle Document Page 7 of 23 d. Enhancement and Defect CQs e. Change Request documentation f. Change Analysis documentation g. Existing Requirements documentation h. Other Related documentation, as available 1.2.3 Key Tasks / Activities The following are the key tasks / activities used to complete the ‘Requirements Definition and Analysis’ phase: a. Review supporting documentation to gain an understanding of the business needs being addressed. b. Complete requirements analysis and elicitation resulting in the documentation of the requirements, forms specifications and user interface specifications for the enhancements and/or defects. c. Develop and/or update business use cases, process flow, and other requirements documentation. d. Review requirements and scope with Stakeholders. e. Obtain sign-off approval from the Xxxxx on any deliverables. f. Conduct Requirements walkthrough, including deliverables and supporting work product documentation, with Developers and Testers. g. Conduct a “Joint Test Planning” meeting with Partner SMEs, UAT testers, and the appropriate Application Services BAs, SIT testers and developers to gain a better understanding of the requirements and test scenarios necessary to better facilitate the ‘Technical Definition and Analysis’, ‘Construction’ and ‘SIT’ phases of the MR. h. Notify the MR Manager of any changes to the MR scope and/or estimates. i. Post deliverables and supporting work product documentation to Sharepoint. 1.2.4 Outputs / Deliverables The following are outputs and deliverables resulting from the ‘Requirements Definition and Analysis’ phase: a. Updated MR Program Timeline b. Updated MR Scope Document, with revised estimates RCR Technology Software Development Live Cycle Document Page 10 of 23 The following are inputs for the ‘Construction’ phase: a. Enhancement and Defect CQs b. Requirement Document(s) c. Forms Specification(s) d. User Interface Specification(s) e. Business Use Case(s) f. Technical Design Document(s) g. Architectural Specification(s) h. Development (DEV) Environment 1.4.3 Key Tasks / Activities The following are the key tasks / activities used to complete the ‘Construction’ phase: a. Conduct meetings to confirm requirements, technical design and architectural specifications to create specific Developer work assignments. b. Conduct design change reviews with Business Analysts, Partners and Xxxxx. c. Complete software development and check-in the updated code into ClearCase. d. Implement database changes and check-in the database scripts into ClearCase. e. Conduct code reviews. f. Complete unit testing of software changes. g. Conduct performance testing, as appropriate. h. Execute “Build” process to incorporate Service Center, Document Center, IVR and Interface code updates; and update and distribute Release Notes. i. Deploy modified code to the DEV environment and distribute Release Notes. j. Post deliverables and supporting work product documentation to Sharepoint. 1.4.4 Outputs / Deliverables The following are outputs and deliverables resulting from the ‘Construction’ phase: a. Updated code checked into ClearCase b. Functioning and Unit Tested System, including Service Center, Document Center, IVR and Interface code updates RCR Technology Software Development Live Cycle Document Page 11 of 23 c. Updated Database Schema d. Database Scripts to facilitate updating the database in subsequent environments e. Release Notes 1.5 System Integration Test 1.5.1 Description The purpose of this phase is to conduct the System Integration Testing (SIT) for the software including the integration of the software changes with the system components and the end-to-end testing of the overall system. The emphasis of this testing is on the functional changes to the system. Testing occurs in a separate environment from code development and subsequent User Acceptance Testing. Testing is conducted by Application Services staff and includes manual testing of specific functions, automated testing using scripts that execute selected processes and regression testing that includes a specific set of functions that are tested for every release. The SIT process is an iterative process wherein testers ensure that new functionality performs as specified in the requirements documents. This test stage also validates that existing functionality was not affected by enhancements and defect fixes incorporated into the code. As defects are identified in the updated code, they are documented in ClearQuest (CQ) and fixed by the developers. New versions of the code are released periodically for continued SIT. The testing is conducted by using scenarios or test scripts that detail what information is expected in the system to conduct the test, what steps the tester should take to execute the test scenario, and what the expected results should be. The SIT tester compares both the steps planned to be taken and the actual steps executed in the system as well as the planned outcome versus the actual outcome to determine if the test passes or not. The output of this phase is a fully tested system that is ready for User Acceptance Testing (UAT). Defects identified during SIT will be documented in ClearQuest (CQ) and resolved, unless agreement is reached with the Stakeholders to move forward without a resolution to the defect. 1.5.2 Inputs The following are inputs for the ‘System Integration Test’ phase: a. Project Charter RCR Technology Software Development Live Cycle Document Page 12 of 23 b. Requirement Document(s) c. Forms Specification(s) d. User Interface Specification(s) e. Business Use Case(s) f. Process Flow Document(s) g. SIT Environment, with latest version of software h. Release Notes 1.5.3 Key Tasks / Activities The following are the key tasks / activities used to complete the ‘System Integration Test’ phase: a. Review the requirements documentation, business use cases and functional specifications of the solution. b. Meet with Business Analysts, Developers, Xxxxx SMEs and Partners to clarify requirements and the solution. c. Develop Test Plan for SIT. d. Create test data for SIT. e. Create test scripts for manual tests in Rational Manual Tester. f. Update automated test scripts in Rational Functional Tester. g. Deploy updated code to the selected SIT environment. h. Execute the Test Plan for SIT, including regression testing. i. Document test results. j. Consolidate test results and distribute daily SIT Status Reports. k. Identify and document in ClearQuest (CQ) any defects experienced during the testing. l. Triage the defects to identify severity and address accordingly through code builds. m. Assign and resolve defects identified during the testing. n. Deploy code on a daily basis to address identified defects to the SIT environment. Deployments will be accompanied by Release Notes identifying defects addressed in the modified code. RCR Technology Software Development Live Cycle Document Page 15 of 23 d. Meet with Business Analysts and SIT testers, as needed, to clarify the requirements and solution. e. Develop Test Plan for UAT. f. Create test data for UAT. g. Deploy updated code to the selected UAT environment. h. Execute the Test Plan for UAT. i. Document test results. j. Consolidate test results and distribute daily UAT Status Reports. k. Identify and document in ClearQuest (CQ) defects identified during testing. l. Triage the defects to identify severity and address accordingly through code builds. m. Assign and resolve defects identified during testing. n. Conduct daily “UAT Defect Review” meetings. o. Deploy code on a daily basis to address identified defects to the UAT environment. Deployments will be accompanied by Release Notes identifying defects addressed in the modified code. p. Re-test system components to confirm defects were resolved and did not create additional system issues. Code updates to address defects will be deployed by the AS team and tested. q. Conduct stress testing of the modified system with data that is comparable in characteristics, variability and volume to Production. r. Conduct “Go/No Go” meeting to obtain concurrence to move forward with the implementation. s. Create Implementation Readiness Document. t. Review Implementation Readiness Document and secure written approval of “Go Live” decision from the designated Xxxxx representative. u. Post deliverables and supporting work product documentation to Sharepoint. 1.6.4 Outputs / Deliverables The following are outputs and deliverables resulting from the ‘User Acceptance Test’ phase: a. Documented UAT Test Cases RCR Technology Software Development Live Cycle Document Page 16 of 23 b. Executed Test Plan for UAT with 100% of planned tests executed and in a known status; and with all Severity 1 and 2 defects fixed c. Updated Requirements Document(s), as necessary d. Updated Forms Specification(s), as necessary e. Updated User Interface Specification(s), as necessary f. Updated Business Use Case(s), as necessary g. Updated Process Flow Document(s), as necessary h. “Go Live” Decision for implementation from UAT Team i. Implementation Readiness Document, signed by the designated Xxxxx representative j. Fully Tested System, ready for Production environment 1.7 Implementation 1.7.1 Description The purpose of this phase is to cutover the fully tested system to the Production (PROD) environment. This phase includes all the planning, preparation and documentation required to support the cutover. 1.7.2 Inputs The following are inputs for the ‘Implementation’ phase: a. Project Charter b. MR Project Schedule (i.e. MS Project Plan) k. Executed Test Plan for UAT with 100% of planned tests executed and in a known status; and with all Severity 1 and 2 defects fixed c. “Go” Decision for implementation from UAT Team d. Implementation Readiness Document, signed by the designated Xxxxx representative e. Fully Tested System, ready for PROD environment 1.7.3 Key Tasks / Activities RCR Technology Software Development Live Cycle Document Page 17 of 23 The following are the key tasks / activities used to complete the ‘Implementation’ phase: a. Create the Maintenance Release Plan. b. Conduct “Coming Attractions” meeting with AS staff to review changes in functionality that will be deployed in the pending Release. c. Create and submit Netfor ticket to schedule cutover to PROD environment. d. Identify “Smoke Testers” to confirm that the new functionality and core system are operating as planned in the PROD environment during the Release. e. Identify a “SWAT Team” of AS team members to provide technical support and respond to any defects identified by the “Smoke Testers” during the Release. f. Execute the Maintenance Release Plan to upgrade system in the PROD environment. g. Perform “Smoke Test” and collect results. h. Communicate Maintenance Release status to the Stakeholders. i. Post deliverables and supporting work product documentation to Sharepoint. 1.7.4 Outputs / Deliverables The following are outputs and deliverables resulting from the ‘Implementation’ phase: a. Maintenance Release Plan b. Updated MR Project Schedule (i.e. MS Project Plan) c. Documented “Smoke Test” Results d. Operational PROD environment 1.8 Post-Implementation Support (Production Support) 1.8.1 Description The purpose of this phase is to monitor the Production (PROD) environment following cutover and to develop a resolution plan for identified defects. This phase also includes the closeout of the project, including the updating and posting of all final deliverables and supporting work product documentation in Sharepoint. RCR Technology Software Development Live Cycle Document Page 20 of 23 f. After the high level prioritization has been completed, the software defects are then discussed in a weekly Internal AS Defect Review meeting to make a further assessment of the scope, impact, and possible workarounds; and also to confirm that the identified problems are software defects. g. Following the Internal AS Defect Review meeting, the AS team completes an analysis to determine the root cause of the defect. (Depending on the complexity of the defect, this analysis could take multiple days or even weeks to complete.) h. After the analysis has been completed, the CQ records are updated to indicate that the software defects are ready for review and prioritization with the Xxxxx and the Partner SMEs in the weekly Partner Defect Review meeting; and also updated with additional notes to provide a description of the nature and cause of the defect. i. An updated Partner Defect Prioritization Report is generated for review in the weekly Partner Defect Review meeting. j. The weekly Partner Defect Review meeting is held with the Xxxxx and Partner SMEs to: 1) assign a severity and priority to the software defects, 2) identify any defects that should be re-categorized as possible enhancements (i.e. Change Request candidates), 3) identify any defects that should be re- categorized as Perfective Maintenance enhancements, and 4) close out any defects that require no further action. k. Following the Partner Defect Review meeting, the CQ records are updated to reflect the determinations made in the prior task. l. The prioritized software defects are then periodically reviewed and assigned by the MR Project Manager for implementation as part of an MR or as a Non- MR implementation. 1.9.4 Outputs / Deliverables The following are outputs and deliverables resulting from the ‘Defect Management’ phase: a. Defect records created in CQ b. Defect CQs updated with a description of the nature and cause of the defect, as well as an assigned severity and priority, or closed out with the justification noted c. Defects to be implemented within an MR d. Defects to be implemented outside an MR (Non-MR implementation) e. Perfective Maintenance CQs RCR Technology Software Development Live Cycle Document Page 21 of 23 f. Change Request (candidates) 1.10 Change Management 1.10.1 Description The purpose of this phase is to define the process used by Application Services to identify, analyze and implement Program Enhancements, including Change Requests. Consideration is given based on whether these Enhancements or Change Requests result from Federal policy or program change; as an enhancement or program change requested by the Xxxxx, Partner Community or Application Services; or as an AS identified internal perfective maintenance change. 1.10.2 Inputs The following are inputs for the ‘Change Management’ phase: a. Federal Policy or Program Change b. Xxxxx Requested Program Change c. Partner Requested Program Change d. Application Services Requested Program Change e. Approved ICES Change f. Perfective Maintenance CQ 1.10.3 Key Tasks / Activities The following are the key tasks / activities used to complete the ‘Change Management’ phase: a. New Change Requests (CRs) are created to identify enhancements or changes resulting from a Federal policy or program change; or an enhancement or program change requested by the Xxxxx, a Partner, or by Application Services. Planned ICES changes are also reviewed for possible impact on WFMS/FACTS; and as necessary, a new CR is created. b. New CRs are submitted to the client’s Steering Committee (SC) for review and prioritization. The SC meets on a bi-weekly basis. For each CR, the SC generates a prioritized weighting and a recommendation to: 1) Submit to CRB, 2) Implement without CRB consideration, or 3) take No Further Action. RCR Technology Software Development Live Cycle Document Page 22 of 23 CRs may also be returned to the submitter for additional information before formal consideration by the FSC. c. CRs with a recommendation to ‘Submit to CRB’ are considered by the CRB which meets on a bi-weekly basis. The CRB will review and discuss the new CRs and determine if they should be approved for: a. Further analysis (i.e. Change Analysis); b. Implementation with no further analysis (typically requiring detailed business requirements to be generated); c. Deferral until further notice; or d. Withdrawn. d. CRs approved by the CRB for ‘further analysis’ are assigned a Change Analysis owner and a due date is established for completing the analysis. The due date is established based on the agreed to ‘Processing Priority’ for the CR. e. For approved CRs assigned to AS, AS assigns a Change Analysis owner. The CA Owner completes the Change Analysis and associated Estimating Worksheet (for AS internal planning purposes) and submits the completed Change Analysis to the CRB for review and approval. Prior to submitting the Change Analysis to CRB, the Change Analysis is reviewed and discussed with the Xxxxx and Partner SMEs in the AS Partner CR Impact meeting. f. CRs that fall into the following categories are assigned and the implementation is monitored through existing change processes. a. CRs approved by the SC to be ‘Implemented without CRB consideration’ b. CRs approved by the CRB to be ‘Implemented with no further analysis’ g. An implementation plan is established for each of the CRs approved by the SC and CRB, including whether the Change will be implemented within an MR or outside an MR (Non-MR Implementation). h. For additional details for each of the Change Management tasks/activities described above, please refer to the ‘Application Services – Change Management Process Overview & Instruction Guide’. i. Perfective Maintenance CQs are reviewed and prioritized in the weekly AS Change Control Board (CCB) meeting. j. Prioritized Perfective Maintenance CQs are periodically reviewed by the MR Project Manager for possible inclusion in an MR or the Perfective Maintenance change is assigned for a non-MR implementation. 1.10.4 Outputs / Deliverables