WikiCED manual: Difference between revisions

Line 155: Line 155:
==Change processes and development==
==Change processes and development==


CED literature describes a  
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).


In the past, a development process called "waterfall" was 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.


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 absolutely necessary (for example, where accessible software does not exist) - the uncertainty and cost create a lot of risk.
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, using system such as [http://trac.edgewall.com Trac], and today Wiki based systems can be used to measure goals, tasks, timelines, responsible persons and even costs.
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=
1,459

edits