Page Comparison

1. If you are using a workflow-based project management tool (e.g., JIRA) then set up a document template to track approvals and completion of tasks.
2. If you are not using a project management tool then use one of the following as appropriate based on initial assumptions about the project:
   
   1. Project Sign-Off Sheet for Developed Applications
   2. Project Sign-Off Sheet for Third-Party Solutions

1. Identify a person who will take ownership of the project and:
   
   • is in a position where he or she can organize resources from the functional side.
   • has the skills and time to manage or help manage the project, including requirements analysis, tracking progress, setting up meetings, and organize user testing
   • has the time and interest to develop the skills required to assist requirements analysis.

1. Prepare a Project Proposal request and submit the request as defined on the How to Request a New Project or Enhancement page.
2. If a vendor solution is an option to complete the project then prepare a Third-Party System Review for each of the third-party systems being considered.

1. Consider candidates for the various roles on the Project Team. Assign as many of these as possible.
2. Create the Project Charter for large, high risk applications. 
3. Prepare the Functional Requirements to document the basic functional requirements of the system.
4. Prepare a Build vs. Buy Analysis for the project to help determine whether an application software solution should be developed internally or acquired from a third-party.
   
   1. The general guideline is that if a third-party solution providing at least 85% of the features and capabilities outlined in the Functional Requirements can be located, and it satisfies the technical criteria defined by OIT with respect to architecture, security, etc., then the third-party solution should be used. If multiple third-party solutions are being considered, a Build vs. Buy Analysis should be done for each one.
5. Review the OIT Data Classifications to determine whether the project involves access to to sensitive, restricted, or personally identifiable information.
   
   1. If it does then contact the OIT Security Manager.
   2. Security reviews are best scheduled starting at the planning stages of a project and are required during the requirements definition process of any high risk project.
6. Determine the level of risk involved with the project.
   
   1. Complete Sections I - X of the Security Risk Assessment Questionnaire (SRAQ) to calculate the project's risk level.
   2. A HIGH RISK application includes any application that uses, stores, or transmits:
   
   
   • • Password
     • Social Security Number
     • Home phone or address
     • Credit card numbers
     • Bank account numbers
     • Driver license or other credential
     • Nonpublic student or employee data
     • FERPA-protected student data
     • Patient information
     • Or any other data deemed sensitive, restricted, or personally identifiable as defined in the OIT data classifications.
   
   
   1. If restricted information is stored or accessed:
      
      1. Encryption must be used in storage and transmission in all cases where such data occurs.
      2. The project is categorized as HIGH RISK and the UCI CIO and UCI Security Officer must be notified in writing or acknowledged email before any work effort begins.
   2. Contact the OIT Security Manager at the planning stages of high risk projects to review the SRAQ and security requirements of the project.
7. Schedule a requirements review and acceptance sign-off with functional and technical project teams to review the functional requirements.
   
   1. Prior to reviewing the requirements with the project team, it may be helpful to create a Development Environment Review Form.

1. A Project Plan contains enough information about the project that all stakeholders can understand what will be done and have an idea when the work will be completed. This includes:
   
   1. Project Definition containing basic information about the project,
   2. Schedule showing project milestones and projected resource requirements and timeframes,
   3. Issues Log to keep track of potential and real problems encountered during the course of the project, and
   4. Organizational Information including key stakeholders, roles, and contact information.

1. Especially for more complex systems, as you design your specifications, be sure to consider:
   
   1. Architecture Review
   2. Database Review
   3. GUI Review and consistency
   4. When creating diagrams (data flow, system architecture, system design, etc.) that show interaction between software components only use the tools defined in the Application Toolbox.
   5. At minimum separate development and production environments must be specified. You may also need a test, training, or staging environment.
   6. Consider creating Create test data if any sensitive data will need to be tested.Schedule Security Design Review
      
      • Schedule reviews with Josh Drummond, Security Architect at the beginning of your project.
      • System Architecture Diagrams in SRAQ Section XI should be completed and reviewed.
      • Revisit Complete the Threat Anaylsis based on technical details of design.

1. A Test plan consists of:

• • Automated code testing in your development environment
  • Cross-browser application certification using VMWare
  • Steps to test major areas of functionality. Include screen shots for regression testing.
  • Security tests, per Security Risk Assessment Questionnaire
  • Parallel system test
  • Test schedule
  • User acceptance checklists
    
    • Example:Parking Permits Test Plan

1. This is an iterative process, with regularly scheduled review stages and quality controls.
2. Please speak to your systems development director about the preferred development platform.
3. For more informaton about OIT software development practices, see Systems Development Practices & Guidelines.
4. The Application Development Toolbox may provide useful information for the developer as well.
5. Schedule Application and Code Review.
   1. During implementation, the Controls Section XII of the SRAQ must be completed. (OIT recommendations)
   2. The OIT Application Security Checklist should be followed during implementation.
   3. High risk code, such as authentication and authorization, need to be reviewed in early stages of implementation.
   4. Schedule Code Reviews with your senior software engineers from the beginning of development. Please contact the OIT Security Manager if you need any help.

This is an iterative set of activities during development of a project, normally based on a documented process and standard practices which include:

1. Code analysis with automated tools and peer code reviews. Example: Java Code Review Checklist
2. Unit, Functional, and browser compatibility testing by programmer and end user
3. Security review in the form of verification of SRAQ Controls Section XII and OIT Application Security Checklist.
4. Performance, load, and stress testing to simulate user load
5. Reporting and publishing of test results to determine progress and production readiness
6. See an example of Java Quality Assurance process 
7. Reference links:

• • Windows Web Test Lab
  • OIT Windows Web Test Lab
  • Mac OS Testing Environment
  • For OIT staff that would like help, please Create or Modify a QA Request (JIRA login required)

1. User Acceptance Test and Acceptance Sign-off is usually coordinated by a Functional Lead and indicates that users have:

• • tested functionality,
  • approved that an application meets original requirements, and
  • determined that it is ready to go into production from the business perspective.

1. Production rollout readiness includes

• • Final Security Risk Assessment Questionnaire completed fully with any left over action items completed.  
  • Successful quality assurance testing, application vulnerability scanning, and security sign-off.  Please use the Project Sign-off / QualityControl Sheet for Developed Applications or Project Sign-off Sheet for Vendor/ASP Solutions as appropriate and schedule dates for the review sign-off.
  • For some OIT departmental units, issue tracking (JIRA suggested) and change control management (login required) as part of production support and maintenance. Prioritization of issues and change requests, where stakeholders are involved in the decision making process, are essential and a best practice.
  • Scheduled database and code backups
  • Marketing; announce application availability date to campus either via Zotmail or e-mail
  • User Training
  • Help desk training
  • Cross-train backup support
  • Adding the application into Help Desk Service Request Tracking System
  • Adding application to campus portals, if applicable
    
    

1. Congratulate yourself on a job well done!
2. Continue with change management and production support.

1. Perform project close-out including clean-up and lessons learned.
2. Transition support from developers to OIT Help Desk.
3. Sign and e-mail the Project Sign-Off Sheet to the OIT Project Manager.
4. Prepare system disposition plans.
5. Monitor system to make sure it is performing as designed.