(что нужно приобрести, разработать или повторно использовать)
Например, может понадобиться приобрести пакет вычисления налоговых платежей.
Создайте документ(Артефакт) План на следующую фазу и план разработки. Здесь описывается приблизительный план фазы развития, описание средств, челове ческих ресурсов, необходимых навыков и других ресурсов.
Фаза развития
На стадии развития уточняется видение системы на основе обратной связи от пользователей и разработчиков различных частей системы. При этом на нескольких итерациях разработки проводятся семинары по определению требований.
В процессе итеративной разработки требования все более проясняются и зано сятся в дополнительную спецификацию.
К моменту завершения фазы развития завершается и работа над описанием пре цедентов, составлением дополнительной спецификации и документа “Видение”, кото рые теперь отражают основные свойства и другие требования. Это не означает, что по завершении фазы развития дополнительную спецификацию и документ “Видение” нужно заморозить и не изменять в дальнейшем. Напомним, что основным “лейтмо тивом” итеративной разработки и UP является возможность постоянной адаптации системы.
Поясним эту мысль подробнее. По завершении фазы развития целесообразно со гласовать с заинтересованными лицами задачи следующего этапа проекта и разрабо тать соглашение (возможно, письменное) относительно требований и графика их реализации. В какой-то момент (в рамках UP — по завершении фазы развития) необ ходимо точно знать “что, когда и сколько”. В этом смысле формальное соглашение о требованиях к системе является нормальным и целесообразным. Необходимо также определить процесс управления изменениями (одна из лучших идей UP), предполага ющий формальное рассмотрение и одобрение вносимых изменений, а не хаотичную и бесконтрольную модификацию.
Поэтому приходим к следующим выводам.
В рамках итеративной разработки и UP в детально проработанную специфика цию требований могут вноситься незначительные изменения. Эти изменения могут затрагивать свойства системы, обеспечивающие ее конкурентоспособ ность или улучшающие функциональность.
В рамках итеративной разработки основное внимание уделяется получению обратной связи от заинтересованных лиц и реализации проекта в нужном на правлении. Благодаря этому заинтересованные лица не могут “умыть руки” и ожидать в стороне реализации “замороженного” набора требований в окон чательном программном продукте. При “замораживании” требований система вряд ли будет отражать реальные потребности заинтересованных лиц.
(что нужно приобрести, разработать или повторно использовать) Например, может понадобиться приобрести пакет вычисления налоговых платежей.
Создайте документ(Артефакт) План на следующую фазу и план разработки. Здесь описывается приблизительный план фазы развития, описание средств, челове ческих ресурсов, необходимых навыков и других ресурсов.
Фаза развития
На стадии развития уточняется видение системы на основе обратной связи от пользователей и разработчиков различных частей системы. При этом на нескольких итерациях разработки проводятся семинары по определению требований.
В процессе итеративной разработки требования все более проясняются и зано сятся в дополнительную спецификацию.
К моменту завершения фазы развития завершается и работа над описанием пре цедентов, составлением дополнительной спецификации и документа “Видение”, кото рые теперь отражают основные свойства и другие требования. Это не означает, что по завершении фазы развития дополнительную спецификацию и документ “Видение” нужно заморозить и не изменять в дальнейшем. Напомним, что основным “лейтмо тивом” итеративной разработки и UP является возможность постоянной адаптации системы.
Поясним эту мысль подробнее. По завершении фазы развития целесообразно со гласовать с заинтересованными лицами задачи следующего этапа проекта и разрабо тать соглашение (возможно, письменное) относительно требований и графика их реализации. В какой-то момент (в рамках UP — по завершении фазы развития) необ ходимо точно знать “что, когда и сколько”. В этом смысле формальное соглашение о требованиях к системе является нормальным и целесообразным. Необходимо также определить процесс управления изменениями (одна из лучших идей UP), предполага ющий формальное рассмотрение и одобрение вносимых изменений, а не хаотичную и бесконтрольную модификацию.
Поэтому приходим к следующим выводам.
В рамках итеративной разработки и UP в детально проработанную специфика цию требований могут вноситься незначительные изменения. Эти изменения могут затрагивать свойства системы, обеспечивающие ее конкурентоспособ ность или улучшающие функциональность.
В рамках итеративной разработки основное внимание уделяется получению обратной связи от заинтересованных лиц и реализации проекта в нужном на правлении. Благодаря этому заинтересованные лица не могут “умыть руки” и ожидать в стороне реализации “замороженного” набора требований в окон чательном программном продукте. При “замораживании” требований система вряд ли будет отражать реальные потребности заинтересованных лиц.