Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ProcessWhat To DoHow To Do It
1Initiate the Project
  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
2Identify Sponsor
  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.
3Submit Project Proposal
  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 refer to Vendor Implementation Checklistprepare a Third-Party System Review for each of the third-party systems being considered.
4Requirements Definition
  1. Once Project/Enhancement Proposal is approved, create
    1. Consider candidates for the various roles on the Project Team.
    2. Create the Project Charter for large high risk applications 
    3. Requirements Document
    4. If the project involves access to to sensitive, restricted, or personally identifiable information as defined in the OIT Data Definitions, then please contact the OIT Security Manager. Security reviews are best scheduled starting at the planning stages of a project and are required by the Requirements Definition phase of any high risk project.
  2. Schedule Requirements review and acceptance sign-off with functional and technical project teams.
    1. As an example of documentation that may be helpful in performing the review, it may be helpful to create a Development Environment Review Form.
  3. Is this a HIGH RISK project?
    1. Sections I - X of the Security Risk Assessment Questionnaire (SRAQ) completed so that the risk level is calculated.
    2. A HIGH RISK application typically includes any application that uses, stores, or transmits Password, SSN, home phone/address, credit card, bank account, California Driver's License or other credential, non-public student or employee data, FERPA blocked student data, patient information, or any data deemed sensitive, restricted, or personally identifiable as defined in the OIT Data Definitions. Encryption must be used in storage and transmission in all cases.
    3. If Restricted Information is stored or accessed, 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.
    4. Please contact the OIT Security Manager at the planning stages of high risk projects to review the SRAQ and Security Requirements of the project.
5Prepare a Project Plan
  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.
  2. The project leader should update the Project Sign-Off Sheet for Developed Applications or Project Sign-off Sheet for Vendor/ASP Solutions as appropriate and schedule additional tasks and dates for each of the sign-offs.
6Create System Specification
  1. Especially for more complex systems, as you design your specifications, please consider:
    • Architecture Review
    • Database Review
    • GUI Review and consistency
    • Please consider using Visio to create Data Flow Diagrams and System Architecture and System Design diagrams that show interaction between software components.
    • At minimum separate development and production environments must be specified. You may also need a test, training, or staging environment.
    • Consider creating 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 Threat Anaylsis based on technical details of design.
7Prepare a Test Plan
  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
8Develop Application
  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.
9Perform Quality Assurance

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:
10Conduct User Acceptance Testing and Approval for production release
  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.
11Production Rollout Planning
  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

12Launch Application
  1. Congratulate yourself on a job well done!
  2. Continue with change management and production support.
13Post-Implementation Review
  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.