The OIT Systems Development Life Cycle (SDLC) is an important guideline to use when developing systems or implementing third-party solutions. In addition to helping implement more robust and secure systems for UCI, it also helps address future audits of IT systems 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 Waterfall 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. Table below provides some characteristics of both Waterfall and Scrum. Detailed Detailed information on each methodologies methodology tailored for OIT can be found in the following links.
Consider Agifall if:
...
When to Use Waterfall and When to Use Scrum
We recommend using Waterfall if:
- Customers know exactly what they want in advance and will not change their mind
- You know exactly what your customers want
- You know that users will have no concerns with your initial design
- Any feedback from users is either addressed in a subsequent project or not at allThe 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
- The project is very predictable or you’ve done similar projects many times before
- You’re working with fixed scope unchanging projects
- You anticipate only minor mistakes throughout the project
And you should use Consider Scrum if:
- Your customer does not know exactly what they want at first or could change their mind
- You don't always know exactly what your customers want or they're needs aren't always communicated perfectly
- Your users provide feedback on your design and you'd like to act on it
- You prefer to address user feedback during the project instead of after
- The final product isn’t clearly defined at first or the definition may change
- You anticipate there will be changes in scope, requirements, opinions, priority, environment, people, or technology during the project
- Some part of the project is different or is of moderate complexityProject 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)
...