|#||Assigned||Description||Date Identified||Due Date||Date Completed||Status|
|Mayo/Jason||We have run into multiple issues where the performance on the DEV tier has be a problem due to Mayo not being able to replicate the slow points due to the drastic difference in DEV resources. We discuss this with the systems team and they requested us to put in a DRT ticket that provides the specs to match the Mayo DEV server.||08/30/13||The server resources have been expanded with an addition vCPU and an additional 2GB memory. Initial tests have shown better performance but the testing is ongoing.|
|Area of Interest||Details|
|LexEVS 6.1||Still working on the completing the deployment of URI resolver to the DEV Tier. It was decided that we would proceed with the deployment of the core LexEVS 6.1 to not slow down progress on the deployment of the browsers and API.|
|LexEVS 6.0 and 5.1|
The systems team applied a JDK patch and the subsequent appscan passed with no high or medium vulnerabilities. The QA team is working on finalizing the test report and requesting a deployment to the stage tier.
|Term Browser 2.3 Release|
The AppScan came back with 2 high level vulnerabilities. One was to update the JDK, similar to what we did for LexEVS 5.1 above. The other was a cross scripting vulnerability introduced through a third party widget that check for the flash version of the user and re-directs them to the adobe site if they do not have it. We are removing the re-direct and making the it a manual process to go to the adobe site with just a message with a URL where to go. The re-scan is being performed now.
|Meta Download Validation App||Waiting for the final decision on whether to use the EVS or CBIIT interface. A meeting was held and the discussion items are being put together and are supposed to be distributed. Still waiting for the final decision. Development is on hold until then. QA team also said they will be sending out the performance test results to the group.|
|Term Suggestion Form||QA team has the tag to start testing but has not had time to do anything with it yet.|
|NCIm Browser||NCIm browser has passed appscan and has been tested. It will be ready to deploy to stage once the 6.1 API is deployed there.|
Performed trouble shooting on a single question-mark character (‘?’) test string failure case reported by the QA team. This issue is likely related to the handling of special characters by Lucene indexing implemented in the search extension. Informed Mayo of the observation.
Analyzed value set search response times and potential bottlenecks.
Implemented caching of resolved value set coding scheme versions at initialization.
|GF#32816||Migrate to LexEVS API 6.1.||6/28/2013||1 Developer||We are still reviewing the new deployment of LexEVS 6.1 on DEV. This date is dependent on the value sets issues describe previously.|
|Moving up Development Time||7/17/2013||We are pushing to get the coding done for a July 17th review by the EVS users. This will give the users a chance to provide input on the implementation before we completely freeze the code.|
|Pushing back the start of the user evaluation||7/22/2013||Having an issue with the exact match search. Working with mayo to get it resolved but need it fixed before user can review.|
|Delay starting QA testing for Term Browser and NCIm Browser||7/13/2013||We had to delay the start of the QA testing since a fully functioning API has not been established on the QA tier.|
|Delays with the final release candidate of LexEVS 6.1 API on QA||9/6/2013||The LexEVS 6.1 release has been extended to mid to late October. Sense the browsers are dependent on the API we will need to extend the release date to late October/early November.||Deployment by 9/30 is at risk|
|Delays with LexEVS 6.1 API due to deployment setup/AppScan||11/8/2013||There has been issues with getting all the components of LexEVS 6.1 setup on the DEV tiers. We have also received vulnerabilities from the AppScan on the QA tier that were not found on the DEV tier. These vulnerabilities require software patches to both the infrastructure and browser software requiring a new tag.|
|Area of Interest||Details|
|Term Browser 2.3 Release||Provide any updates based on the user review/testing.|
|Term Browser 2.3 Release||Make any required fixes from QA testing.|
|Term Suggestion Application Release||Make any required fixes from QA testing.|
|NCIm Browser||Make any required fixes from QA testing.|
Risks, Issues, Dependencies
|#||Opened Date||Due Date||Description||Likelihood (H, M, L)||Impact||Assigned||Status||Mitigation Strategy|
|6/19/13||9/30/13||Term Browser 2.3 and LexEVS 6.1 are in parallel development with the Term Browser having a dependency on LexEVS release. Both have a hard deployment date of 9/30/2013. Anticipating some QA resource limitations with both schedules being in parallel.||M||Jason||Monitoring both schedules and will provide status to QA to make sure resources are available.|
|7/17/2013||Removal of JAVA 1.6 from desktops. The Term Browser deployments using AntHillPro require JAVA 1.6. Putting in a request for a waiver until we can upgrade.||This would affect the deployments and production environment for the EVS tools. It sounds like this is going to be a future issue but we should have time to upgrade before it is part of the CBIIT tech stack.||Provided a level of effort for migrating all of the EVS applications to Java 1.7 to the Technical Project Manager and government sponsor.|
|7/31/2013||We currently have an issue where the browsers are ready to move to the QA tier for testing but due to the dependency of LexEVS 6.1 cannot start the QA testing process. LexEVS 6.1 does not currently have all the pre-QA qualification to proceed with the deployment to the QA tier.||With a hard deadline of Sept. 30 for both the browsers and LexEVS API 6.1 there is concern that there will be time to finish all the testing and deployments on time.||Received approval to proceed to QA tier with LexEVS 6.1.|
|Term Browser 2.3 release dependent on the LexEVS 6.1 release. See the Issue listed for 7/31/2013 for details on the status.|