Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 110
Текст из файла (страница 110)
21.6. Планирование следующей итерации После каждой итерации вы должны оценить выполнение проекта и пересмотреть план на следующую итерацию. Как соотносится длительность прошедшей итерации с запланированной? Правильно ли вы распределили задачи между разработчиками? Доволен ли клиент выполнением работ? Возникли ли какие-нибудь очевидные проблемы или задачи для следующей итерации? Получилась ли программа стабильной, или вам придется отвести больше времени на реорганизацию на следующей итерации? Конечно, если итерация оказалась успешной, выполнение плана можно продолжать. В противном случае не нужно бояться отбросить неправильные решения н внести необходимые коррективы.
Приложение получится расширяемым, обслуживаемым н жизнеспособным, только если у него есть надежная основа. Вы должны регулярно получать отзывы пользователей. Они особенно важны на ранних этапах, потому что вам нужно, чтобы пользователи впитали особенности вашего приложения и подумалц о его применении в повседневном бизнесе. Более того, пользователи могут помочь определить, когда работы отклонятся от заданного направления. 21.7. Моделирование и итерационная разработка 461 21.7.
Моделирование и итерационная разработка Моделирование естественным образом дополняет итерационную разработку. Одной из целей итерационной разработки является раннее обнаружение проблем в программном обеспечении. То же можно сказать и о моделировании. В работе 18ог1гочэЫ-01] автор выразительно охарактеризовал философию итерационной разработки словами «быстрый отказ».
Проблемы неизбежны, цо лучше их обнаружить на ранних этапах, чем на более поздних. Опытный разработчик может обнаружить некоторые проблемы еще в модели и тем самым сократить объем работ в одной итерации. В итоге разработка идет быстрее и проще. Итерационная разработка, разумеется, не оправдывает хакерских приемов и отказа от вдумчивого моделирования. Как показано на рис. 21.3, начинать следует с аккуратного люделировання приложения, что позволит выявить требования, после чего следует построить модель для первой итерации.
Затем можно снова вернуться к модели и провести следующую итерацию и так далее, чередуя моделирование с итерационной разработкой. Моделирование позволяет раньше обнаружить ошибки и дает ощущение направления и непрерывности последовательности итераций. Моделирование может и должно осуществляться быстро, чтобы не замедлять график проекта. Рис.
21.3. Моделирование и итерационная разработка В табл. 21.1 моделирование сравнивается с итерационной разработкой. Обе методики способствуют фиксации требований, но делают это по-разному. Моделирование помогает клиентам представить возможности программного обеспечения еще до его создания. Итерационная разработка помогает пм увидеть программу в процессе ее развития, чтобы они могли выступить с комментариями или изменить направление приложения усилий разработчиков. Ничто не может сравниться с моделированием по способности повысить качество приложения. В работе [Вгоокэ-87! утверждается, что «концептуальная цельность — важнейший критерий при проектировании системы».
Моделирование предназначено для облегчения понимания и усовершенствования сути приложения. Итерационная разработка подразумевает частое тестирование, а потому также способствует усовершенствованию, хотя и не столь эффективна сама по себе, как вместе с моделированием. Моделирование повышает производительность благодаря быстрому выявлению недостатков при мысленных экспериментах, позволяющих обойтись без отброшенного кода. Итерационная разработка также дает значительный вклад в производительность, потому что требует интеграции на ранних стадиях, что исключает создание несовместимых компонентов или неудачных редакций.
462 Глава 21 ° Итерационная разработка По определению моделирование не участвует в отслеживании проекта. Моделирование относится к ранней стадии разработки программного обеспечения, поэтому не может служить критерием оценки хода проекта как целого. Итерационная разработка гораздо лучше подходит для отслеживания проекта, потому что частый выпуск рабочего кода не оставляет места для споров о том, что сделано, а что нет. Вследствие этого график проекта становится более предсказуемым. 21.8. Идентификация рисков Самое важное в планировании итерации — минимизация рисков. Встречаться с опасностями нужно как можно раньше, а не откладывать их до конца проекта (что иногда случается).
Разновидностей возможных рисков сушествует довольно много. ° Технические риски. Предлагаемое техническое решение может оказаться неправильным или неприемлемым. Если вы займетесь техническими вопросами на раннем этапе, возможно, вы успеете найти другое решение до того, как будет слишком поздно, и прежде, чем на плохом фундаменте будет построена вся система. ° Технологические риски. Технология, на которую вы рассчитываете, может оказаться недоступной или несоответствуюшей требованиям.
Испытывайте технологии, задействованные в важнейших частях системы, как можно раньше. ° Риски приемлемости для пользователя. Пользователям может не понравиться интерфейс или функциональность системы. Итерационная разработка позволяет пользователям испытать часть системы в то время, когда стиль ее оформления еще может быть изменен достаточно легко. ° Риски планирования. Всегда сушествует шанс, что проект не завершится вовремя.
Итерационная разработка снижает этот шанс, поскольку предоставляет точные критерии выполнения. Если наблюдается отставание от графика, вы можете пожертвовать частью функциональности. Даже если проект завершится позже назначенного срока, у вас все равно будет работающая система, которую вы сможете предъявить в этот срок. Система с 90 Ж функциональности гораздо лучше, чем реализованная на 90%, но абсолютно неработоспособная система в водопадной модели. ° Риски персонала. Ключевые лица могут выйти из проекта в самый неудачный момент.
Итерационная разработка характеризуется частыми контрольными точками со стабильными выпусками системы. Модели гарантируют, что итерации тшательно продумываются и документируются. Потеря ключевых лиц не может остаться незамеченной, но, по крайней мере, у вас будет шанс подобрать им замену. ° Рыночные риски. Требования к приложению всегда могут измениться. Моделирование и итерационная разработка дают вам гибкость и быстроту реагирования на эти изменения. 21.9. Резюме 463 На каждой итерации вы должны идентифицировать риски, распределять их по приоритетам и в первую очередь заниматься рисками с наивысшими приоритетами.
Это позволит вам снизить первоочередные риски на ранних стадиях, когда у вас еще есть запас времени и вы можете перейти к альтернативным вариантам. Планы итераций далжяи учитывать возможность изменений. Сама рабочая обстановка должна быть ориентирована на изменения. 21.9. Резюме Разработке программного обеспечения присущи проблемы, связанные с недопониманием, неправильной оценкой и непредвиденными изменениями.
Моделирование делает ваше приложение гибким. Итерационная разработка делает гибким процесс создания этого приложения. Она предоставляет возможность регулярной проверки хода работ и раннего обнаружения недостатков. Итерационная разработка отличается от водопадного подхода. Водопадный подход предполагает идеальное предвидение и строгую последовательность разработки. Это неудачный подход, значение которого было сильно преувеличено в литературе. Итерационная разработка отличается и от быстрого прототипирования. В последнем, сложные вопросы решаются методом исследований при помощи написания кода, который в случае выбора неудачного решения отбрасывается.
Итерационная разработка подразумевает деление проекта на небольшие части, вероятность неудачи в рамках которых достаточно мала. Оба метода достаточно ценны. Количество и длительность итераций зависят от масштабов проекта. Если итерации слишком малы, они создают чрезмерные накладные расходы. Если итерации слишком велики, контрольных точек для оценки хода проекта становится слишком мало. Обычно разумная длина итерации составляет от нескольких недель до нескольких месяцев. Определять охват итерации следует методом ранжирования рисков по приоритетам. Начинайте с самых серьезных рисков и переоценивайте приоритеты по завершении каждой итерации.
Недопустимо затягивать график итерации, расширяя функциональность. Интегрируйте подсистемы в единое целое в ходе разработки, не откладывая это до конца. Если команды разработчиков предоставить самим себе, они неизбежно разойдутся в своих предположениях и в описаниях интерфейсов. При слишком поздней интеграции вам придется отслеживать изменения или устранять различия в коде. В конце итерации должен получаться исполняемый выпуск системы, который должен быть протестирован. Исполняемый код является лучшей мерой хода выполнения.
Моделирование — естественное дополнение итерационной разработки. Оба метода повышают качество, продуктивность и предсказуемость разработки программного обеспечения. Некоторым разработчикам кажется, что моделирование замедляет разработку и мешает работе.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
