mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
82 lines
2.4 KiB
Markdown
82 lines
2.4 KiB
Markdown
---
|
|
title: Systems development lifecycle (SDLC)
|
|
draft: true
|
|
sr-due: 2022-04-13
|
|
sr-interval: 28
|
|
sr-ease: 270
|
|
aliases: SDLC
|
|
---
|
|
|
|
tags: #review
|
|
#### Review Questions
|
|
|
|
1. How can business process re-engineering be used in the analysis phase and what benefits can it provide?
|
|
bpr can be used in the analysis phase to simplify the processes relevant to the project. The benefits it provides include: SImpler requirements, better understanding of domain
|
|
|
|
|
|
---
|
|
|
|
# SDLC
|
|
Provides overall framework for managing the systems
|
|
There are many methodologies to help guide us through this cycle
|
|
Each methodology sits on the [Predictive adaptive spectrum](out/notes/predictive-adaptive-spectrum.md)
|
|
A very common methodology at the moment is [Agile Development](out/notes/agile-development.md)
|
|
|
|
## Phases
|
|
### Analysis
|
|
^2d7976
|
|
- Lots of communication with [Stakeholders](out/notes/stakeholders.md)
|
|
- Gather detailed information
|
|
- define system requirements
|
|
- prioritise requirements (what is risky, what brings value to business) -> increase proability of success
|
|
- develop UI dialogs ([Prototyping](out/notes/prototyping.md) where the user can interact with the system)
|
|
- evaluate requirments
|
|
- review reccomendations with management
|
|
|
|
## Business process re-engineering
|
|
method of organising company
|
|
- streamline processes to be efficient and efffective
|
|
- question basic assumptions
|
|
|
|
use ICT to help with BPR
|
|
|
|
sys analyst may find opportunites to improve processes
|
|
- any project can include components of BPR
|
|
|
|
simpler business processes -> simpler requirements -> simpler system
|
|
|
|
## Requirements
|
|
- [Requirements](out/notes/requirements.md)
|
|
- [Requirements elicitation](out/notes/requirements-elicitation.md)
|
|
- Something the system should do
|
|
- Some constraint the system should have
|
|
- Can be functional or non functional
|
|
- Good requirements prevent failure
|
|
|
|
## SDLC Variations
|
|
- different terminology
|
|
- change focus on people
|
|
- change speed of development
|
|
- [Prototyping](out/notes/prototyping.md)
|
|
- Rapid application development (RAD)
|
|
|
|
## Failure
|
|
main goal: Avoid project failure
|
|
- complete fail implies nothing delivered
|
|
- Types of fail
|
|
- cost overruns
|
|
- sw quality issues
|
|
- missed deadlines
|
|
- unhappy [stakeholders](out/notes/stakeholders.md)
|
|
|
|
Suprisingly very common with large projects
|
|
|
|
reasons for fail:
|
|
|
|
|
|
|
|
|
|
**coding rarely causes problems**
|
|
|
|
|