Итеративный ЖЦ разработки

← →
Девушка © (2007-04-09 09:43) [0]

Цитата из Кватрани Т., “Rational Rose 2000 и UML. Визуальное моделирование”

В итеративном и инкрементальном жизненном цикле разработка осуществляется с помощью серии версий, которые развиваются в направлении конечной системы. Каждая версия состоит из одного или более компонентов процесса: построение бизнес-модели, определение требований к системе, анализ, проектирование, реализация, тестирование и внедрение. Разработчики допускают, что не все требования к системе известны в начале жизненного цикла. Корректировки возможны на любом этапе. Такой тип жизненного цикла позволяет уменьшить риск. Технические риски оцениваются и группируются по приоритетам на ранней стадии цикла и корректируются во время разработки каждой версии. Риски закреплены за каждой версией таким образом, что успешное завершение версии уменьшает риса, закрепленный за ней. Процесс планируется так, что бы наибольшие риски были рассмотрены в первую очередь. Построение системы подобным образом выявляет и уменьшает риски на раннем этапе жизненного цикла. Результат такой модели жизненного цикла - уменьшение риска и затрат.

Где можно поподробнее почитать про оценку рисков и вообще про итеративный ЖЦ разработки?

← →
db2admin (2007-04-09 10:02) [1]

http://delphimaster.net/view/15-1175977895/
в соседней ветке

← →
Иксик © (2007-04-09 12:32) [2]

Тут интересная статья на сходную тему. Плюс мнения МС от UML:
http://msdn2.microsoft.com/en-us/library/ms379623(vs.80).aspx

← →
Девушка © (2007-04-12 11:56) [3]

В соседней ветке была ссылка на книжку, которая, после скачивания, сказала "файл поврежден".
Где можно почитать про последовательность реализации версий? Где бы было более полно раскрыта фраза "Процесс планируется так, что бы наибольшие риски были рассмотрены в первую очередь."

> Девушка © (12.04.07 11:56) [3]
> Где бы было более полно раскрыта фраза "Процесс планируется
> так, что бы наибольшие риски были рассмотрены в первую очередь."

Риски имеют конкретные цифровые оценки. Вот и делаем в порядке уменьшения цифирь. но не наоборот :)

Упрощенно говоря: имеется 2 фичи продукта: без работающей в срок первой фичи заказчик за продукт деньги не заплатит вообще и разорвет контракт, а про вторую фичу - если не успеть ее сделать к сроку - можно поболтать с заказчиком, сдвинуть сроки ее реализации или несколько сократить функционал, доработав позже срока.
Соответственно реализацию обязательно начинаем с первой фичи, даже если она много сложнее и объемнее второй.

Итеративный ЖЦ разработки Найти похожие ветки