When discussing computer system
s, this refers to the process
- Deciding what to do (see User Requirements)
- Working out the details (See System Proposal)
- Working out how to do it (See Analysis and Design)
- look at what's currently in use by the parties suffering the problem
- decide whether it can be used - or modified - to fix the problem
- if not, look for other existing systems that could be used - or modified - to fix the problem
- if you fail, look for existing systems that fix some of the problem
- work out what needs to be modified or created to fix the whole problem
- write down how to prove the problem has been fixed
- knock up a quick schedule of works and get tenders
- discuss the costs with the parties involved and confirm the problem is worth fixing
- Build the system
- This is generally considered the easy bit
- Making sure it does what it's meant to do (See "v model".)
- Sending it off out into the big wide world
- This may be considered passe... but even the
Linux kernel has releases.
Get to step 6 before step 1 has time to become wrong
Never forget to go back to the top and repeat the process as often as you can.
"Parties involved" will tend to grow over time and must include the people who'll be using the system and the people who'll be supporting the system, otherwise you're going to be hated by one or other (or probably both) groups.
Little and often is a good motto - people get used to continuous improvement and start looking for things to make their lives better. This keeps you in work and them happy.
But some people
think it means coding