Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 158 Next »

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.

Waterfall vs Scrum

Both Waterfall 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 Waterfall if: When to Use Waterfall and When to Use Scrum

  • The team has done similar projects before and full 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
  • Any feedback from users is either addressed in a subsequent project or not at all
  • You’re working with fixed-price / fixed-bid contracts
  • The team has done similar projects before and has a well-defined path to delivery 
  • You’re working with fixed scope unchanging projects
  • You anticipate only minor mistakes throughout the project

Consider Scrum if:

  • Project has a high degree of complexity and uniqueness (high risk)
  • Business users involvement is recommended at daily scrum and has early opportunity 
  • Priority shifts can occur during mid-sprint
  • The final product may not be fully defined and the details can unfold iteratively over multiple sprints.
  • Some part of the project is different or is of moderate complexity
  • You want the option of closing a project early once sufficient value is created (avoiding "everything but the kitchen sink" pitfall)
  • No labels