| Process | What To Do | How To Do It |
|---|
| 1 | Initiate the Project | - 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.
- If you are not using a project management tool then use one of the following checklists as appropriate based on initial assumptions about the project:
- Project Sign-Off Sheet for Developed Applications
- Project Sign-Off Sheet for Third-Party Applications
|
| 2 | Identify Sponsor | - 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.
|
| 3 | Submit Project Proposal | - Prepare a Project Proposal request and submit the request as defined on the How to Submit a New Project page.
- To aid in determining what should be included in the Financial Impact section of the Project Proposal, download and use the Project Impact Analysis or High-Level Cost Benefit Analysis workbooks.
- If a third-party solution is an option to complete the project then prepare a Third-Party System Review for each of the third-party systems being considered.
- As soon as possible after submitting the project proposal to the Project Review Team, a new JIRA Project Request should be submitted.
- Prepare a wiki or Web page to publish information and updates about the project.
|
| 4 | Requirements Definition | - Consider candidates for the various roles on the Project Team. Assign as many of these as possible.
- Create the Project Charter for large, high risk applications.
- Prepare the Functional Requirements to document the basic functional requirements of the system.
- Use the results from the Third-Party System Reviews to help determine whether an application software solution should be developed internally or acquired from a third-party.
- 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 Third-Party System Review should be done for each one.
- Review the OIT Data Classifications to determine whether the project involves access to to sensitive, restricted, or personally identifiable information.
- If it does then contact the OIT Security Manager.
- 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.
- Determine the level of risk involved with the project.
- Complete Sections I - X of the Security Risk Assessment Questionnaire (SRAQ) to calculate the project's risk level.
- 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.
- If restricted information is stored or accessed:
- Encryption must be used in storage and transmission in all cases where such data occurs.
- 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.
- Contact the OIT Security Manager at the planning stages of high risk projects to review the SRAQ and security requirements of the project.
- Use the Audit Preparation Questionnaire to determine what information will be required if the project or system is audited.
- Schedule a requirements review and acceptance sign-off with functional and technical project teams to review the functional requirements.
- Prior to reviewing the requirements with the project team, it may be helpful to create a Development Environment Review Form.
|
| 5 | Prepare a Project Plan | - 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:
- Project Definition containing basic information about the project,
- Schedule showing project milestones and projected resource requirements and timeframes,
- Issues Log to keep track of potential and real problems encountered during the course of the project, and
- Organizational Information including key stakeholders, roles, and contact information.
|
| 6 | Create System Specification | - Especially for more complex systems, as you design your specifications, be sure to consider:
- Architecture Review
- Database Review
- GUI Review and consistency
- When creating diagrams (data flow, system architecture, system design, etc.) that show interaction between software components only use the tools defined in the Application Developer's Toolbox.
- At minimum separate development and production environments must be set up. You may also need a test, training, or staging environment.
- Create test data if any sensitive data will need to be tested.
- Schedule regular security reviews with the Security Team at the beginning of your project.
- System Architecture Diagrams in SRAQ Section XI should be completed and reviewed.
- Complete the Threat Anaylsis section of SRAQ based on technical details of design.
|
| 7 | Prepare a Test Plan | - 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 as outlined in the SRAQ.
- Parallel system test
- Test schedule
- User acceptance checklists
|
| 8 | Develop Application | - Application development is an iterative process with regularly scheduled review stages and quality controls.
- Contact your systems development director about the preferred development platform, tools, and methods.
- For more information about OIT software development practices, see Systems Development Practices & Guidelines.
- The Application Developer's Toolbox provides useful information about OIT-supported tools for the developer.
- During implementation, the Section XII (Controls) of the SRAQ must be completed. (OIT recommendations)
- Schedule Application and Code Review.
- The /wiki/spaces/adcom/pages/68028495 should be followed during implementation.
- High risk code, such as authentication and authorization, must be reviewed in the early stages of implementation.
- Schedule Code Reviews with peer software engineers from the beginning of development.
|
| 9 | Quality Assurance | - QA is an iterative set of activities during development of a project and is normally based on a documented process and standard practices. These include:
- Code analysis with automated tools and peer code reviews. Example: Java Code Review Checklist.
- Unit, Functional, and browser compatibility testing by programmer and end user.
- Security review in the form of verification of SRAQ Controls Section XII and OIT Application Security Checklist.
- Performance, load, and stress testing to simulate user load.
- Reporting and publishing of test results to determine progress and production readiness.
- See an example of Java Quality Assurance process.
- Reference links:
|
| 10 | User Acceptance Testing | - 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.
|
| 11 | Production Rollout Planning | - Production Rollout Planning includes:
- SRAQ completed fully with any left over action items completed.
- Successful quality assurance testing, application vulnerability scanning, and security sign-off.
- Completed Project Sign-Off Sheet (Third-Party or Developed Application version as appropriate for the project) with approvals and dates.
- For some OIT functional units, issue tracking and Change Control Management must be worked out with the appropriate OIT support units prior to moving the system to production.
- Scheduled database and code backups.
- Appropriate contingency plan or roll-back plans.
- Announcement of the application's availability date to end users via appropriate communication channels.
- 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.
|
| 12 | Launch Application | - Congratulate yourself on a job well done!
- Continue with change management and production support.
|
| 13 | Post-Implementation Review | - Perform project close-out including clean-up and lessons learned.
- Transition support from developers to OIT Help Desk.
- Prepare a Project Completion Report for review with end users.
- Meet with end users and project team to review Project Completion Report.
- Meet with Executive Sponsor to obtain sign-off of the Project Sign-Off Sheet.
- Email Project Sign-Off Sheet to the OIT Project Manager.
- Prepare system disposition plans.
- Monitor system to make sure it is performing as designed.
|