Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 109
Текст из файла (страница 109)
Быстрое прототипирование обладает схожими с итерационной разработкой преимуществами. Отличие состоит в том, что в первом подходе часто приходится отбрасывать имеющийся код, тогда как во втором подходе код аккумулируется. Рис. 21.2. Быстрое прототипирование 458 Глава 21 ° Итерационная разработка Прототипирование представляет собой проверку концепций, при которой часто приходится отбрасывать частично готовые варианты программы. Итерационная разработка тоже допускает исключение части кода при изменениях, но такое исключение не является намеренным.
Быстрое прототипирование ориентировано на взаимодействие с заказчиком и помогает быстро определять его требования. Оно может быть полезно для демонстрации технической возможности реализации в тех случаях, когда речь идет о технологии, которая может вызвать затруднения. Недостаток состоит в том, что отказаться от написанного кода может быть сложно. Заказчики часто путают успешный прототип с готовым продуктом и не понимают, что прототип предназначен только для демонстрации и может быть лишен устойчивой инфраструктурыы.
Некоторые клиенты рассматривают отбрасывание кода как выбрасывание денег на ветер. Им трудно понять, что истинная ценность прототипов состоит в том опыте, который приобретается с их помощью. Итерационная разработка позволяет сохранить те же преимушества, при условии, что итерации делаются достаточно короткими, а промежуточные версии демонстрируются клиенту. Оба метода дают заказчику возможность регулярно контролировать успешность выполнения проекта. Они также помогают разработчикам устранять возможные проблемы на ранних стадиях.
21Я. Масштаб итераций Итерационная разработка состоит из последовательности итераций. Количество итераций и их длительность зависят от масштабов проекта. В коротком проекте длительностью не более шести месяцев длина итерации может составлять две — четыре недели. В большом проекте длительностью в несколько лет итерации могут продолжаться три — четыре месяца. Слишком короткие итерации создают избыточные накладные расходы. Слишком длинные итерации не позволяют получить достаточного количества контрольных точек для оценки выполнения проекта и выполнения промежуточных корректировок.
Вы должны стремиться к тому, чтобы все итерации были одинаковыми, но в некоторых случаях может возникнуть потребность удлинить итерацию, например, при проработке глубокой инфраструктуры или сложных составляющих. Определите масштаб итераций. В качестве цели удобно выбрать минимальный объем работы, который дает на выходе ощутимый материальный результат. Важные для приложения составляющие нужно создавать как можно раньше.
Это относится и к ключевым участкам кода, которые часто выполняются приложением. Следите за тем, чтобы функциональность внутри системы была сбалансирована. Разработчики могут иметь любимые методики и предпочитать работать с разными аспектами, но план в целом должен быть сбалансирован и нацелен на максимально быструю реализацию законченных самостоятельных частей приложения.
Каждая итерация должна обеспечивать как минимум что-то одно из нижеследующего: экономическую отдачу, расширение функциональности, улучшение взаимо- 21.5. Выполнение итерации 459 действия с пользователем, повышение эффективности, повышение надежное~и или укрепление инфраструктуры (последнее необходимо для обслуживания и для последующих итераций). Хороший базис для оценки задают варианты использования. В рамках одной итерации можно сосредоточиться на нескольких вариантах использования. Конечно, не обязательно, чтобы итерация реализовывала вариант использования целиком. Вы можете реализовать основную функциональность на первой итерации, расширенную функциональность на следующей, а обработку ошибок добавить на третьей итерации. Однако не следует разбивать вариант использования по слишком большому количеству итераций.
Помимо вариантов использования, вы должны разделить по итерациям внутренние сервисы — механизмы и службы, предоставляющие инфраструктуру или обеспечивающие поддержку для реализации более высокоуровневых операций. Эти сервисы идентифицируются на этапах планирования архитектуры и проектирования классов. Если приоритет какой-либо из составляющих необходимо повысить, приоритет другой составляющей должен быть понижен.
Это позволит избежать синдрома одинаковой важности всех частей. Никогда не бывает так, чтобы все было одинаково важно, просто менеджеры и разработчики боятся делать сложный выбор или признавать, что времени на все не хватает. Отслеживая длительность итераций и корректируя их содержимое, вы вынуждены смотреть на вещи трезво и представлять ход выполнения плана. Не обязательно предоставлять клиенту результаты каждой итерации.
С точки зрения разработчика, самое главное — не останавливаться, оставаться в рамках графика и следить за тем, чтобы части приложения подходили друг к другу. С точки зрения клиента установка промежуточных продуктов после каждой итерации может потребовать слишком больших расходов. Для упрощения логистики можно объединить несколько промежуточных версий перед передачей их заказчику.
21.5. Выполнение итерации Каждая итерация должна начинаться с единой для всех разработчиков базовой версии и заканчиваться новой базовой версией. В конце итерации разработчики должны интегрировать все версии артефактов системы и проверить их. Это позволит всем работать с одинаковым набором предположений и не отставать от изменений системы. Выполнение этого правила — обязательное условие успеха проекта.
Некоторым разработчикам такое правило может показаться неудобным. Кажется, что эффективнее продолжать разрабатывать подсистему, не тратя время на ее интеграцию с остальными частями системы. Действительно, если команда делится на мелкие группы, которым приходится часто взаимодействовать друг с другом, это не так удобно. Но это жизненно важно для успеха проекта в целом.
Если группы слишком долго работают сами по себе, они расходятся в своих прел- положениях, интерфейсах и по другим параметрам. Осуществление интеграции может оказаться сложным и дорогостоящим. Но часто оказывается, что предположения, заложенные в разные подсистемы, просто несовместимы друг с другом. 460 Глава 21 ° Итерационная разработка Тогда приходится отслеживать изменения или идти на программистские ухищрения, чтобы решить возникшие проблемы.
Чтобы закончить итерацию, сдать ее результаты, протестировать и интегрировать ее в систему, команда должна структурировать свою деятельность. Это требует затрат на планирование, которые, впрочем, окупаются в долгосрочной перспективе в масштабах всей системы. Второе правило гласит, что на выходе каждой итерации должна получаться исполняемая версия программы.
Недостаточно написать код, который нельзя выполнить. Чтобы протестировать код, его необходимо запустить. После этого можно проверить интеграцию подсистем, обнаружить и устранить несовместимости на ранних этапах. Более того, именно исполняемый код является лучшей мерой успешного выполнения проекта. Очень легко обмануть себя и других, если исполняемого кода нет. Так можно пропустить серьезные недочеты или недооценить сложность отлалки и интеграции подсистем. В каждой итерации должно быть отведено достаточно времени на все этапы разработки. Внутри итерации программа пишется по уменьшенной водопадной модели.
Вы переходите от анализа к проектированию, реализации, тестированию и интеграции. Волопадный подход вполне эффективен в небольших масштабах, где он обеспечивает систематическую разработку функциональности. Проблемы возникают только в том случае, если принимаемые решения нельзя изменить на более поздних этапах. В итерационном подходе неправильные решения можно изменить на последующих итерациях, поэтому они не угрожают проекту в целом. Отведите в своем плане достаточно времени для тестирования. Очень важно проводить тестирование по ходу работы и не откладывать его на поздние итерации. Вся суть итерационной разработки в том, чтобы строить надежные системы маленькими шагами.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
