OSHERA M-Code Peer Review Checklist v0.5 (DRAFT)

Transcription

1 OSHERA M-Code Peer Review Checklist v0.5 (DRAFT) Date Submitted: 18 October 2011 Prepared for: Department Of Veterans Affairs Prepared by:

2 Document Version Control Revision Editor Date Changes Open Source Electronic Health Record Agent (OSEHRA) Software Quality Certification M-Code Primary Developer s Checklist v0.5 (DRAFT) Copyright OSEHRA, distributed under Creative Commons by Attribution License 3.0 Page i

3 Table of Contents Section Page Overview...3 Checklist...4 Notes...7 Open Source Electronic Health Record Agent (OSEHRA) Software Quality Certification M-Code Primary Developer s Checklist v0.5 (DRAFT) Copyright OSEHRA, distributed under Creative Commons by Attribution License 3.0 Page ii

4 Overview This document describes the set of checks that a Peer Developer should perform as part of the process of reviewing a code contribution posted by a Primary Developer, with the aim of including it in the OSEHRA code base. Primary developer is the developer who is addressing an issue or a feature request that has been reported in the OSEHRA JIRA issue tracker. The Peer Reviewer is another developer who is also knowledgeable on the VistA/MUMPS code base and its quality control system. This current OSEHRA document is and adaptation of the M-Code Secondary Developer Review Checklist used by the Product Development team at the Department of Veterans Affairs. Changes are very minor and are mostly intended to adapt to the software tools and procedures that have been setup for OSEHRA. Peer Reviewers are expected to perform the verifications listed in this checklist, as they study code submission, and to fill-up the entries in the checklist accordingly. The processed checklist must be included in a read-only format (for example a PDF document) as part of the review submission. Once processed, this document must be uploaded in the JIRA ticket that originated the action of the Primary Developer. Completed forms should be saved with the Save As option and uploaded to JIRA. Page 3 of 8

5 Checklist This document describes the set of specific checks that a peer developer must perform as part of the process of reviewing a patch that has been submitted for integration into the OSEHRA code base. It is the reviewer s responsibility to complete the checklist and assure that it is uploaded to the JIRA ticket that initiated the action of the Primary Developer. This is a requirement for approving a patch in the Gerrit code review system. JIRA Ticket Number: Review Completed by: Test Version: Date: Item Product Build Checklist Question Review Outcome # Peer Review consists of items Yes No N/A 1 Do all components follow the System Design Document? 2 Do all components satisfy the requests of the Requirements Specification Document? 3 Are the Use Case Specifications documented? 4 Is the Interface Control Document complete and current? 5 Are the components required for the build identified? 6 Do all components follow Product Development Standards? 7 Is Product Component Testing (aka Unit Testing) complete for each component of the build? 8 Are the results of the Product Component Testing documented? 9 Did Product Component Testing follow Product Development Standards? 10 Have the Test Scripts been completed? 11 Do the Test Scripts conform to Product Development Standards? Page 4 of 8

6 Item Product Build Checklist Question Review Outcome # Peer Review consists of items Yes No N/A 12 Is the Master Test Plan completed according to the Test Preparation process? 13 Is Product Documentation available for the build? 14 Has the sequence of integration of the Product Components been identified (see Test Preparation Process)? And Documented? Secondary Developer Review Checklist Pass/Fail Fail & NA Require Comment Before Patch Installation Duplicate the original defect as described in the Remedy ticket(s) listed in the patch. Confirm the analysis of the defect(s) is accurate; the solution is acceptable and appropriate, and appears to be the most effective way to resolve the defect(s) without introducing new defects. Review all Remedy tickets and check that the patch description clearly describes all issues and solutions. Capture the before routine checksums included in the patch before installing the patch to verify against the before checksums listed in OSEHRA Patch Module Repository, if applicable. Capture the before portions of the Data Dictionaries (DDs) affected the patch for comparison to after install, if applicable. Run XINDEX on the patch build checking for warnings or errors. Print more than compiled errors and warnings, and accept the defaults. Ensure there are no issues reported. Forward the patch from the OSEHRA Patch Module Repository (OPMR) to the test account. Installation and Post Installation Page 5 of 8

7 Secondary Developer Review Checklist Pass/Fail Fail & NA Require Comment Install the patch using the installation instructions included in the patch description or Installation Guide, as applicable, confirming the instructions are correct. Verify the before patch checksums match what is documented in the patch description in the (OPMR), if applicable. Capture the after routine checksums after installing the patch. Verify the after patch checksums match what is documented in the patch description in the OPMR. Run XINDEX on the build after installing the patch checking for warnings or errors. Print more than compiled errors and warnings, and accept the defaults. You may answer No to the Print routines option. Capture and verify the after portions of the DDs to ensure the changes were made appropriately. Review affected data, cross-references, and outputs, if applicable. Confirm the patch installed correctly. Review the code ensuring its accuracy and meets the current Standards and Conventions (SAC) standards. Confirm that Integration Control Registrations (ICRs) supported by the package have been updated if the code has changed and the subscribing packages have been informed of the changes, if applicable. Capture and perform unit testing to verify that the code changes work and provide the unit testing results to SQA. Verify the original issue(s) is fixed and options, menus, security keys, protocols, etc. are in the patch as noted in the patch description. Verify that the patch does not break existing functionality. Page 6 of 8

8 Notes OSEHRA Patch Module Repository (OPMR): code.osehra.org/files/patches OSEHRA Technical Journal: OSEHRA Git Repository: OSEHRA Gerrit Code Review: Page 7 of 8