The OIT Systems Development Life Cycle (SDLC) is an important guideline to use when developing systems or implementing vendor third-party solutions. In addition to helping implement more robust and secure systems for UCI, it it also helps address future possible audits of IT systems .
...
- 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 as appropriate based on initial assumptions about the project:
...
- 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.
...
- Prepare a Project Proposal request and submit the request as defined on the How to Request a New Project or Enhancement page.
- 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.
...
- Consider candidates for the various roles on the Project Team.
- Create the Project Charter for large, high risk applications.
- Prepare the Functional Requirements to document the basic functional requirements of the system.
- If the project involves access to to sensitive, restricted, or personally identifiable information as defined in the OIT Data Definitions, 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.
- Schedule a requirements review and acceptance sign-off with functional and technical project teams.
- As an example of documentation that may be helpful when reviewing the project with others, it may be helpful to create a Development Environment Review Form.
- Is this a HIGH RISK project?
- Sections I - X of the Security Risk Assessment Questionnaire (SRAQ) completed so that the risk level is calculated.
- 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.
- 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.
- Please contact the OIT Security Manager at the planning stages of high risk projects to review the SRAQ and Security Requirements of the project.
...
- 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.
- 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.
...
- 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.
...
- 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
...
- This is an iterative process, with regularly scheduled review stages and quality controls.
- Please speak to your systems development director about the preferred development platform.
- For more informaton about OIT software development practices, see Systems Development Practices & Guidelines.
- The Application Development Toolbox may provide useful information for the developer as well.
- Schedule Application and Code Review.
- During implementation, the Controls Section XII of the SRAQ must be completed. (OIT recommendations)
- The OIT Application Security Checklist should be followed during implementation.
- High risk code, such as authentication and authorization, need to be reviewed in early stages of implementation.
- 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:
- 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:
- 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)
...
- 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.
...
- Production rollout readiness includes
...
- Congratulate yourself on a job well done!
- Continue with change management and production support.
...
by providing the procedures and documentation required to meet the expectations of the auditors.
The SDLC described here is meant to provide a flexible set of guidelines that can be adapted to any project by tailoring the steps, processes, and procedures to meet specific needs of a project. For more information, see Tailoring the SDLC. An overview diagram of the entire process can be downloaded in PDF or Microsoft Visio 2010 format.
| Child pages (Children Display) |
|---|
Agifall vs Scrum
Both Agifall and Scrum are widely used methodologies for different reasons. Although most projects adopt one methodology over the other, the non-traditional hybrid method of using parts of each methodology can also be effective in arriving at the desired project outcome. Detailed information on each methodology tailored for OIT can be found in the following links.
Consider Agifall if:
- The team has done similar projects before and scope of work is known in advance
- Except for reviews, approvals, status meetings, etc., a business user presence is not strictly required after the requirements phase. Meetings can still occur on an "as needed" basis.
- Priority shifts can still occur and change impact is acceptable in terms of scope/budget/timeline.
- You’re working with fixed-price / fixed-bid contracts
Consider Scrum if:
- Project has a high degree of uniqueness (high risk) or requires considerable R&D. The final product may not be fully defined and the details can unfold iteratively over multiple sprints
- Business users involvement is recommended at the daily scrum and user has early opportunity to see delivery.
- Priority shifts can occur during mid-sprint and change impact is acceptable in terms of scope/budget/timeline.
- You’re working with time/material contracts.
- You want the option of closing a project early once sufficient value is created (avoiding "everything but the kitchen sink" pitfall)