SSWG Analysis of MyInfoVault 200-45 02-18-2010 Submission

NOTE: This document is a DRAFT until it has been reviewed.

NOTE: The SSWG 200-45 rubric was not provided to the MIV group in advance of the 200-45 submission under review, so there is no expectation that the submission should address any of the points in the rubric. That so many of the rubric points are addressed in the submission is a clear indication that the MIV group is strategically leveraging infrastructure and working towards standards. 

Platform: MIV uses Java and the Spring Framework, which meets the SSWG recommendations for the scope of the MIV application (campus-wide). MIV also leverages campus middleware wherever possible.

Development Methodology: The specific development methodology is not specified in the 200-45 submission, but the roadmap indicates a 1-month release cycle for incremental upgrades. End-users are integrated into the development process, though one area of concern is that the process for joining the representative user group is not clearly specified. The project website does reference specific bug- and feature request-tracking ticket numbers, but it does not appear that end-users have direct access to the tracking system.

Recommendation: The project should consider opening the bug/feature reporting and tracking system to end users to ensure that the user community is fully engaged in the development process. 

Coding Practices: Coding practices are not clearly specified in the 200-45 submission. However, the submission does mention the use of automated vulnerability scanning, use of common frameworks that support good coding practices, and a modular design.

Recommendation: The project should address coding practices, particularly with regard to code review and testing methodology, and should consider opening source code to the campus community both for review purposes and for potential collaboration in fixing bugs and adding features. 

Data Management and Access: The submission indicates that MIV uses MySQL as a database back-end, so it would easily possible to allow direct access to data from other applications. The intention to interact with other systems, including faculty recruitment and research administration, is clearly stated. However, the submission and the project website do not indicate that a process has been defined for obtaining access to the data for legitimate business uses. Moreover, the data model is not publicly available to assist in analyzing the available data set for other uses or to assess the granularity of access restrictions.

Recommendation: The project should define a process for obtaining access to data in accordance with the campus Data Management policy (PPM 320-40) and for accepting potential data feeds from external sources. The project should consider publishing the application data model to allow for external evaluation of the value of the data for other purposes. The project should assess the security requirements for the data on a granular level to ensure that appropriate data (e.g., faculty CV information) can be shared with other applications while protecting confidential data (e.g., external review letters).

Application Security: The submission states that the application is compliant with campus CyberSafety standards (PPM 310-70), however only automated vulnerability scanning is specifically mentioned as the means of assessment. The submission states that the Academic Senate has been consulted with regard to privacy requirements for data.

Recommendation: The project should address the methods used to ensure application security and data privacy. The project should consider a wider vetting of data privacy requirements to verify that current controls are neither too lax nor too restrictive.

Usability: That MIV uses the Spring framework indicates that the user interface is sufficiently separated from other aspects of the application to support usability assessment and enhancements. No usability testing methodology or process is specified in the submission or on the project website. While the application does significantly leverage campus middleware, it does not use UI middleware such as KNS.

Recommendation: The project should consider adopting a formal usability assessment and improvement process, particularly given the data-entry intensive nature of the application. As the campus moves toward the common KNS UI framework, the project should consider migrating to that framework to reduce user training requirements and ensure a common UI for campus business applications.

Accessibility: The submission indicates that the application is compliant with campus usability standards and that a QA/QC process is in place for testing accessibility compliance.

Recommendation: The project should specify the QA process for external evaluation.

Campus Core Middleware Services Integration: The submission indicates that the application leverages campus middleware for authentication, authorization, workflow, and various data sources wherever possible.

Documentation and Training for Users: The submission does not address documentation and training, however the project website indicates that facilitated training is available and offers some documentation. The process for creating and updating training resources is not specified. 

Recommendation: The documentation on the project website should be reorganized to consolidate available training resources. The project should consider offering online, self-paced training in addition to facilitated training. The project should specify the process for creating and updating training resources to ensure that sufficient resources are allocated for this task.

Project Management and Personnel: The submission outlines the project management organizational structure for the application and clearly identifies the executive sponsors, stakeholders, project manager, developers, oversight groups, and end users. The alignment of the needs of the executive sponsors with the end users is not clear. Allocation of financial resources for appropriate personnel is clearly indicated in the budget spreadsheet.

Recommendation: The project should consider deeper integration of end users into the project management process to ensure that end user needs are addressed.

Business Process Analysis: The submission does not indicate that a formal workload analysis has been completed, though it does note that the process MIV is created to automate is extremely cumbersome. The submission notes that the business process is "highly regarded" by stakeholders, but does not indicate that the process has been formally analyzed and streamlined.

Recommendation: The project should consider a formal workload analysis of the previous (paper) and new (electronic) processes to evaluate the workload impact of MIV for all application users. The project should consider a formal business process analysis of academic merits and promotions to find ways to further streamline the process.

Sustainability: The submission does not directly address sustainability, though it does indicate that the application significantly reduces the need for printed documents and travel. Further, the application architecture allows for easy virtualization on shared hardware, reducing energy requirements and carbon footprint.

Recommendation: The project should directly address sustainability, including an assessment of energy/carbon/waste reductions afforded by the application and a process for monitoring and continually improving the long-term sustainability of the application.

Risk Management: The submission does not specifically address backup or disaster recover plans, though it does indicate that the application and its data are of critical importance to University operations. That the application will be migrated to a virtualized environment on a robust service (IET-Data Center virtual hosting) that provides for disaster recovery is noted. 

Recommendation: The project should consider formalizing and publishing backup and disaster recovery plans.