Bureaucrats, darkmatter, Administrators
1,459
edits
| Line 155: | Line 155: | ||
==Change processes and development== | ==Change processes and development== | ||
In the past, a development process referred to as "waterfall" was often used in software development. A long specification process was supposed to lead to a shorter, more informed development process. However, with specialists doing specification no one could understand, many projects went overtime and budget (or failed outright). | |||
Development process today has shifted more towards a process referred to as [wp:Agile software development]. Initially, basic examples and prototypes are used to describe the project, and multiple cycles of development, called "iterations," that ideally involved all involved persons, are used to make sure everyone sees the product, and has a chance to comment on it, before another revision cycle. This also allows constant revision of a product. | |||
CED literature describes similar processes based on Knowing, Doing and Reviewing (Torjman, 2007). | |||
Therefore, a preferred development cycle for a project may appear as follows: | Therefore, a preferred development cycle for a project may appear as follows: | ||
| Line 172: | Line 172: | ||
# iterate | # iterate | ||
It's important to contain each process. Keep timelines short and easy to measure. Avoid (like the plague) custom solutions, unless | It's important to contain each process. Keep timelines short and easy to measure. Avoid (like the plague) custom solutions, unless they are absolutely necessary (for example, where accessible software does not exist) - the uncertainty and cost create a lot of risk. | ||
Modern software practices also provide access to all team members to project tracking | Modern software practices also provide access to all team members to project tracking, and today Wiki based systems can be used to measure goals, tasks, timelines, responsible persons and even costs. | ||
=Technology as a solution= | =Technology as a solution= | ||