3.2.2. Инкрементная модель жизненного цикла разработки программного обеспечения
Инкрементная разработка представляет собой процесс частичной реализации всей системы и постепенного наращивания функциональных возможностей. Этот подход позволяет уменьшить затраты, понесенные до момента достижения уровня исходной производительности. С помощью этой модели ускоряется процесс создания функционирующей системы. Этому способствует применяемый принцип компоновки из стандартных блоков, благодаря которому обеспечивается контроль над процессом разработки изменяющихся требований.
Инкрементная модель действует по принципу каскадной модели с перекрытиями, благодаря чему функциональные возможности продукта, пригодные к эксплуатации, формируется раньше. Для этого может понадобиться полный заранее сформированный набор требований, которые выполняются в виде последовательных, небольших по размеру проектов, либо выполнение проекта может начаться с формулирования общих целей, которые затем уточняются и реализуются группами разработчиков.
Подобное усовершенствование каскадной модели одинаково эффективно при использовании как в случае чрезвычайно больших, так и небольших проектов.
А теперь будет рассмотрен небольшой пример продукта, разработанного в результате выполнения трех инкрементных этапов. Здесь на инкременте 1 определяются базовые алгоритмы и выходные данные, на инкременте 2 добавляются некоторые ценные возможности производственного типа, такие как возможность занесения в файл и выборки результатов предыдущих прогонов программы, а на инкременте 3 добавляются различные полезные свойства к пользовательскому интерфейсу, а также к заранее определенным вычислительным свойствам системы.
Инкрементная модель описывает процесс, при выполнении которого первостепенное внимание уделяется системным требованиям, а затем их реализации в группах разработчиков. Как правило, со временем инкременты уменьшаются и реализуют каждый раз меньшее количество требований.
Каждая последующая версия системы добавляет к предыдущей определенные функциональные возможности до тех пор, пока не будут реализованы все запланированные возможности. В этом случае можно уменьшить затраты, контролировать влияние изменяющихся требований и ускорить создание функциональной системы благодаря использованию метода компоновки из стандартных блоков.
Рис. 2. Инкрементная модель
Предполагается, что на ранних этапах жизненного цикла (планирование, анализ и разработка проекта) выполняется конструирование системы в целом. На этих этапах определяются относящиеся к ним инкременты и функции.
Каждый инкремент затем проходит через остальные фазы жизненного цикла: кодирование, тестирование и поставку.
Сначала выполняется конструирование, тестирование и реализация набора функций, формирующих основу продукта, или требований первостепенной важности, играющих основную роль для успешного выполнения проекта либо снижающих степень риска.
Последующие итерации распространяются на ядро системы, постепенно улучшая ее функциональные возможности или рабочую характеристику. Добавление функций осуществляется с помощью выполнения существенных инкрементов с целью в комплексного удовлетворения потребностей пользователя. Каждая дополнительная функция аттестуется в соответствии с целым набором требований.
Применяя инкрементную модель при разработке проекта, для которого она подходит в достаточной мере, можно убедиться в следующих ее преимуществах:
не требуется заранее тратить средства, необходимые для разработки всего проекта (поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска);
в результате выполнения каждого инкремента получается функциональный продукт;
заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы;
правило по принципу "разделяй и властвуй" позволяет разбить возникшую проблему на управляемые части, благодаря чему предотвращается формирование громоздких перечней требований, выдвигаемых перед командой разработчиков;
существует возможность поддерживать постоянный прогресс в ходе выполнения проекта;
снижаются затраты на первоначальную поставку программного продукта;
ускоряется начальный график поставки (что позволяет соответствовать возросшим требованиям рынка);
снижается риск неудачи и изменения требований;
заказчики могут распознавать самые важные и полезные функциональные возможности продукта на более ранних этапах разработки;
риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки);
требования стабилизируются (посредством включения в процесс пользователей) на момент создания определенного инкремента, поскольку не являющиеся особо важными изменения отодвигаются на момент создания последующих инкрементов;
инкременты функциональных возможностей несут больше пользы и проще при тестировании, чем продукты промежуточного уровня при по-уровневой разработке по принципу "сверху-вниз"
улучшается понимание требований для более поздних инкрементов (что обеспечивается благодаря возможности пользователя получить представление о раннее полученных инкрементов на практическом уровне);
в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика;
использование последовательных инкрементов позволяет объединить полученный пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки;
в процессе разработки можно ограничить количество персонала таким образом, чтобы над поставкой каждого инкремента последовательно работала одна и та же команда и все задействованные в процессе разработки команды не прекращали работу над проектом (график распределения рабочей силы может выравниваться посредством распределения по времени объема работы над проектом);
возможность начать построение следующей версии проекта на переходном этапе предыдущей версии сглаживает изменения, вызванные сменой персонала;
в конце каждой инкрементной поставки существует возможность пересмотреть риски, связанные с затратами и соблюдением установленного графика;
потребности клиента лучше поддаются управлению, поскольку время разработки каждого инкремента очень незначительно;
поскольку переход из настоящего в будущее не происходит моментально, заказчик может привыкать к новой технологии постепенно;
ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика "давление" на управляемом уровне.
При использовании этой модели относительно проекта, для которого она подходит не в достаточной мере, проявляются следующие недостатки:
в модели не предусмотрены итерации в рамках каждого инкремента;
определение полной функциональной системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов;
формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;
заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены;
поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах;
использование на этапе анализа общих целей, вместо полностью сформулированных требований, может оказаться неудобным для руководства;
для модели необходимы хорошее планирование и проектирование: руководство должно заботиться о распределении работы, а технический персонал должен соблюдать субординацию в отношениях между сотрудниками.
может возникнуть тенденция к оттягиванию решений трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки;
Менеджер проекта может быть уверен в целесообразности применения модели, если для этого имеются следующие причины:
если большинство требований можно сформулировать заранее, но их появление ожидается через определенный период времени;
если рыночное окно слишком "узкое" и существует потребность быстро поставить на рынок продукт, имеющий функциональные базовые свойства;
для проектов, на выполнение которых предусмотрен большой период времени разработки, как правило, один год;
при равномерном распределении свойств различной степени важности;
когда при рассмотрении риска, финансирования, графика выполнения проекта, размера программы, ее сложности или необходимости в реализации на ранних фазах оказывается, что самым оптимальным вариантом является применение принципа по-фазовой разработки;
при разработке программ, связанных с низкой или средней степенью риска;
при выполнении проекта с применением новой технологии, что позволяет пользователю адаптироваться к системе путем выполнения более мелких инкрементных шагов, без резкого перехода к применению основного нового продукта;
когда однопроходная разработка системы связана с большой степенью риска;
когда результативные данные получаются через регулярные интервалы времени.
3.2.3 Итерационная модель
Общепринятая модель жизненного цикла не является идеальной уже потому, что только очень простые задачи проходят все этапы без каких-либо итераций — возвратов на предыдущие шаги производственного процесса.
При кодировании, например, может обнаружиться, что реализация некоторой функции очень громоздка, неэффективна и вступает в противоречие с требуемой от системы производительности. В этом случае необходимо перепроектирование, а может быть, и переделка спецификаций.
При разработке больших нетрадиционных систем итеративность возникает регулярно на любом этапе жизненного цикла как из-за допущенных на предыдущих шагах ошибок и неточностей, так и из-за изменений внешних требований к условиям эксплуатации системы.
Рис. 3. Итерационная модель.
Стрелки, идущие вверх, обозначают возвраты к предыдущим этапам, квалифицируемые как требование повторить этап для исправления обнаруженной ошибки. В связи c этим может показаться странным переход от этапа "Эксплуатация и сопровождение" к этапу "Тестирование и отладка". Дело в том, что рекламации, предъявляемые в ходе эксплуатации системы, часто даются в такой форме, что нуждаются в перепроверке. Чтобы понять, о каких ошибках идет речь в рекламации, разработчикам полезно предварительно воспроизвести пользовательскую ситуацию у себя, т.е. выполнить действия, которые обычно относят к тестированию.
Классическая итерационная модель абсолютизирует возможность возвратов на предыдущие этапы. Однако это обстоятельство отражает существенный недостаток программных разработок, проводимых в традиционном стиле: стремление заранее предвидеть все ситуации использования системы и невозможность в подавляющем большинстве случаев достичь этого.
Все подобные методологии программирования направлены лишь на то, чтобы минимизировать возвраты. Но суть от этого не меняется: при возврате всегда приходится повторять построение того, что уже считалось готовым.
Иначе обстоит дело с методологиями, которые реализуют поддержку итерационного развития проектов. В этом случае отказываются от завершенности фаз и этапов, вместо чего предлагается распределять наращивание функциональности и интерфейсных возможностей по итерациям. В результате можно ослабить требование переделки старого при возвратах.
По существу, классическая схема остается верной, но только в рамках одной итерации и с одной важной поправкой: все полезное, что было сделано ранее, сохраняется.
3.2.4 Спиральная модель (Бари Боэм, 1988.)
На практике, при решении достаточно большого количества задач, разработка ПО имеет циклический характер, когда после выполнения некоторых стадий приходится возвращаться на предыдущие. Можно указать две основные причины таких возвратов:
Ошибки разработчиков, допущенные на ранних стадиях и выявленные на поздних стадиях – ошибки анализа, проектирования, кодирования, выявляемые, как правило, на стадии тестирования.
Изменение требований в процессе разработки («ошибки» заказчиков). Это или неготовность заказчиков сформулировать требования («Сказать, что должна делать программа я смогу только после того, как увижу как она работает»), или изменения требований, вызванные изменениями ситуации в процессе разработки (изменения рынка, новые технологии, …).
Циклический характер разработки программного обеспечения отражен в спиральной модели ЖЦ, описанной Б. Боэмом в 1988 году. Спиральная модель была предложена как альтернатива каскадной модели, учитывающая повторяющийся характер разработки программного обеспечения. Основные принципы спиральной модели можно сформулировать следующим образом:
Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам
Создание прототипов программного обеспечения как средства общения с заказчиком для уточнения и выявления требований
Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту
Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок.
Использование каскадной модели как схемы разработки очередного варианта
Активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа программного обеспечения, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков.
Схема работы спиральной модели выглядит следующим образом. Разработка вариантов продукта представляется как набор циклов раскручивающейся спирали. Каждому циклу спирали соответствует такое же количество стадий, как и в модели каскадного процесса. При этом, начальные стадии, связанные с анализом и планированием представлены более подробно с добавлением новых элементов.
В каждом цикле спиральной модели выделяются четыре базовые фазы:
определение целей, альтернативных вариантов и ограничений.
оценка альтернативных вариантов, идентификация и разрешение рисков.
разработка продукта следующего уровня.
планирование следующей фазы.
Рис. 4. Циклы спиральной модели.
«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку программного обеспечения. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания.
Следующий цикл начинается с планирования требований и деталей жизненного цикла продукта для оценки затрат:
На фазе определения целей устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости их выполнения.
На фазе оценки устанавливаются риски вариантов требований.
На фазе разработки – спецификация требований (с указанием рисков и стоимости), готовится демо-версия программного обеспечения для анализа требований заказчиком.
Следующий цикл – разработка проекта – начинается с планирования разработки:
На фазе определения целей устанавливаются ограничения проекта (по срокам, объему финансирования, ресурсам,…), определяются альтернативы проектирования, связанные с альтернативами требований, применяемыми технологиями проектирования, привлечением субподрядчиков, …
На фазе оценки альтернатив устанавливаются риски вариантов и делается выбор варианта для дальнейшей реализации.
На фазе разработки выполняется проектирование и создается демо-версия, отражающая основные проектные решения.
Следующий цикл – реализация программного обеспечения – также начинается с планирования. Альтернативными вариантами реализации могут быть применяемые технологии реализации, привлекаемые ресурсы. Оценка альтернатив и связанных с ними рисков на этом цикле определяется степенью «отработанности» технологий и «качеством» имеющихся ресурсов. Фаза разработки выполняется по каскадной модели с выходом – действующим вариантном (прототипом) продукта.
Отметим некоторые особенности спиральной модели:
До начала разработки программного обеспечения есть несколько полных циклов анализа требований и проектирования.
Количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи
В модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.
Спиральная модель (по отношению к каскадной) имеет следующие очевидные преимущества:
Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.
Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика
Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.
Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.
Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.
Основные недостатки спиральной модели связаны с ее сложностью:
Сложность анализа и оценки рисков при выборе вариантов.
Сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий)
Сложность оценки точки перехода на следующий цикл
-
Бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки.
Спиральную модель целесообразно применять при следующих условиях:
Когда пользователи не уверены в своих потребностях или когда требования слишком сложны и могут меняться в процессе выполнения проекта и необходимо прототипирование для анализа и оценки требований.
Когда достижение успеха не гарантировано и необходима оценка рисков продолжения проекта.
Когда проект является сложным, дорогостоящим и обоснование его финансирования возможно только в процессе его выполнения
Когда речь идет о применении новых технологий, что связано с риском их освоения и достижения ожидаемого результата
При выполнении очень больших проектов, которые в силу ограниченности ресурсов можно делать только по частям.
3.2.5 V-модель жизненного цикла
V-образная модель жизненного цикла была создана с целью помочь работающей над проектом команде в планировании с обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается действиям, направленным на верификацию и аттестацию продукта. Она демонстрирует, что тестирование продукта обсуждается, проектируется и планируется на ранних этапах жизненного цикла разработки.
План испытания приемки заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы - на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели.
V-образная модель была разработана как разновидность каскадной модели, а значит, унаследовала от нее такую же последовательную структуру. Каждая последующая фаза начинается по завершению получения результативных данных предыдущей фазы.
Модель демонстрирует комплексный подход к определению фаз процесса разработки программного обеспечения. В ней подчеркнуты взаимосвязи, существующие между аналитическими фазами и фазами проектирования, которые предшествуют кодированию, после которого следуют фазы тестирования. Пунктирные линии означают, что эти фазы необходимо рассматривать параллельно.
Рис. 5. V-модель жизненного цикла.
Ниже дано краткое описание каждой фазы V-образной модели, начиная от планирования проекта и требований вплоть до приемочных испытаний:
планирование проекта и требований – определяются системные требования, а также то, каким образом будут распределены ресурсы организации с целью их соответствия поставленным требованиям. (в случае необходимости на этой фазе выполняется определение функций для аппаратного и программного обеспечения);
анализ требований к продукту и его спецификации – анализ существующей на данный момент проблемы с программного обеспечения, завершается полной спецификацией ожидаемой внешней линии поведения создаваемой программной системы;
архитектура или проектирование на высшем уровне – определяет, каким образом функции программного обеспечения должны применяться при реализации проекта;
детализированная разработка проекта – определяет и документально обосновывает алгоритмы для каждого компонента, который был определен на фазе построения архитектуры. Эти алгоритмы в последствии будут преобразованы в код;
разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое программного обеспечения;
модульное тестирование – выполняется проверка каждого закодированного модуля на наличие ошибок;
интеграция и тестирование – установка взаимосвязей между группами ранее поэлементно испытанных модулей с целью подтверждения того, что эти группы работают также хорошо, как и модули, испытанные независимо друг от друга на этапе поэлементного тестирования;
системное и приемочное тестирование – выполняется проверка функционирования программной системы в целом (полностью интегрированная система), после помещения в ее аппаратную среду в соответствии со спецификацией требований к ПО;
производство, эксплуатация и сопровождение – программное обеспечение запускается в производство. На этой фазе предусмотрены также модернизация и внесение поправок;
приемочные испытания (на рис. не показаны) – позволяет пользователю протестировать функциональные возможности системы на соответствие исходным требованиям. После окончательного тестирования программного обеспечения и окружающее его аппаратное обеспечение становятся рабочими. После этого обеспечивается сопровождение системы.
При использовании V-образной модели при разработке проекта, для которого она в достаточной мере подходит, обеспечивается несколько преимуществ:
в модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. Фаза модульного тестирования подтверждает правильность детализированного проектирования. Фазы интеграции и тестирования реализуют архитектурное проектирование или проектирование на высшем уровне. Фаза тестирования системы подтверждает правильность выполнения этапа требований к продукту и его спецификации;
в модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;
в V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование программного обеспечения — перед разработкой компонентов;
модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию;
благодаря модели менеджеры проекта может отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой;
модель проста в использовании (относительно проекта, для которого она является приемлемом).
При использовании V-образной модели в работе над проектом, для которого она не является в достаточной степени приемлемой, становятся очевидными ее недостатки:
с ее помощью непросто справиться с параллельными событиями;
в ней не учтены итерации между фазами;
в модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла;
тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта;
в модель не входят действия, направленные на анализ рисков.
Графически модель зачастую изображается (как показано на рис. 4) без указания интегральных задач. Этот вопрос достаточно легко решается, он здесь упоминается только для того, чтобы напомнить читателю о том, что интегральные задачи имеют место при использовании всех моделей жизненного цикла.
С целью преодоления этих недостатков V-образную модель можно модифицировать, включив в нее итерационные циклы, предназначенные для разрешения изменений в требованиях за рамками фазы анализа.
Подобно своей предшественнице, каскадной модели, V-образная модель лучше всего срабатывает тогда, когда вся информация о требованиях доступна заранее. Общераспространенная модификация V-образной модели, направленная на преодоление ее недостатков, включает в себя внесение итерационных циклов для разрешения изменения в требованиях за рамками фазы анализа.
Использование модели эффективно в том случае, когда доступными являются информация о методе реализации решения и технология, а персонал владеет необходимыми умениями и опытом в работе с данной технологией.
V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность, таких как прикладные программы для наблюдения за пациентами в клиниках, а также встроенное программного обеспечения для устройств управления аварийными подушками безопасности в автомобилях.
3.2.6 Модель быстрого прототипирования
Модель быстрого протитипирования предназначена для быстрого создания прототипов продукта с целью уточнения требований и поэтапного развития прототипов в конечный продукт. Скорость (высокая производительность) выполнения проекта обеспечивается планированием разработки прототипов и участием заказчика в процессе разработки.
Начало жизненного цикла разработки помещено в центре эллипса. Совместно с пользователем разрабатывается предварительный план проекта на основе предварительных требований. Результат начального планирования - документ, описывающий в общих чертах примерные графики и результативные данные.
Следующий уровень – создание исходного прототипа на основе быстрого анализа, проекта база данных, пользовательского интерфейса и некоторых функций. Затем начинается итерационный цикл быстрого прототипирования.
Разработчик проекта демонстрирует очередной прототип, пользователь оценивает его функционирование, совместно определяются проблемы и пути их преодоления для перехода к следующему прототипу. Этот процесс продолжается до тех пор, пока пользователь не согласится, что очередной прототип в точности отображает все требования.
Получив одобрение пользователя, быстрый прототип преобразуют детальный проект, и систему настраивают на производственное использование. Именно на этом этапе настройки ускоренный прототип становится полностью действующей системой.
При разработке производственной версии программы, может понадобиться более высокий уровень функциональных возможностей, различные системные ресурсы, необходимых для обеспечения полной рабочей нагрузки, или ограничения во времени.
После этого следуют тестирование в предельных режимах, определение квалификационных критериев и настройка, а затем, как обычно, функциональное сопровождение.
3.2.7 Agile методологии
3.2.7.1 Описание методологии
Эти адаптивные модели также носят название моделей "скоростного" жизненного цикла (Bullock 2003). В 2001 году группой, состоявшей из 17 представителей пользователей этой адаптивной модели жизненного цикла был выпущен "Манифест скоростной разработки программного обеспечения", и эта инициатива получила широкое развитие в отрасли информационных технологий.
Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование.
Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile методы делают упор на непосредственное общение лицом к лицу. Большинство agile команд расположены в одном офисе. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile методов является рабочий продукт. Отдавая предпочтение непосредственному общению agile методы уменьшают объем письменной документации по сравнению с другими методами, но не исключают их.
Если рассмотреть пары связей:
люди и взаимодействие - процессы и инструменты
работающий продукт - обширная документация
сотрудничество с заказчиком - детали контракта
готовность к изменениям - следование плану,
то можно сказать, что в agile методологиях мы, признавая, что правая часть тезисов важна, все-таки больше ценим их левую часть.
Существует более 15 agile методологий. Самые распространенные:
Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта. Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разработки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой характер, который позволяет менеджеру в большей мере сосредоточиться на руководстве командой, чем на управлении.
В результате отслеживание процесса не требует, к примеру, специальных документов о достигнутых результатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претендуют на инструментальность, и в таком ключе их рассматривать не имеет смысла.
Тем не менее, понятия контрольных точек и контрольных мероприятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным.
Жизненный цикл любой методологии быстрого развития можно описать следующим образом.
Начальная фаза. Она выделена, поскольку приходится выполнять работы, которые не являются характерными для основного процесса.
-
Серия максимально коротких итераций, состоящих из шагов:
выбор реализуемых требований (в экстремальном программировании — пользовательских историй);
реализация только отобранных требований;
передача результата для практического использования;
короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным мероприятием).
Фаза заключительной оценки разработки проекта.
Реальные быстрые методологии конкретизируют эту схему, дополняют ее теми или иными методиками.
До последнего времени быстрые процессы было не принято формализовать настолько, чтобы их можно было предлагать в качестве стандарта. И сегодня не приходится говорить, например, о сертификации команды как "правильно" работающей по быстрой методологии, подобном тому, что требует CMM. Тем не менее, вопрос о сертификации быстрого процесса приобретает актуальность — складывается своеобразная мода на гибкие методологии, отрицательно сказывающаяся на престиже подхода в целом.
Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасения, что в результате быстрые подходы станут формализованными до такой степени, что их нельзя уже будет называть гибкими. Эта проблема отмечалась во многих докладах на конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003.
Тем не менее в 2003 появилась компания, выполняющая проекты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000, свидетельствующий об определенных гарантиях качества организации проектной деятельности и получаемых результатов. Это произошло по прошествии примерно года с момента подачи заявки на сертификацию. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и поддерживаемыми стандартом. В остальном процедура сертификации не нарушила процессы производства программ в компании. Не потребовалось никакой настройки процесса, доведения его до требований стандарта. Не претерпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования, признана соответствующей требованиям качества и т.д.
3.2.7.2 Экстремальное программирование - Extreme Рrogramming (XP)
Экстремальное программирование (Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. (авторы Кент Бек, Уорд Каннингем, Мартин Фаулер и другие, 1996-1999)
Двенадцать основных практики экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
-
Короткий цикл обратной связи (Fine scale feedback)
Разработка через тестирование (Test driven development)
Игра в планирование (Planning game)
Заказчик всегда рядом (Whole team, Onsite customer)
Парное программирование (Pair programming)
-
Непрерывный, а не пакетный процесс
Непрерывная интеграция (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Частые небольшие релизы (Small Releases)
-
Понимание, разделяемое всеми
Простота (Simple design)
Метафора системы (System metaphor)
Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
Стандарт кодирования (Coding standard or Coding conventions)
-
Социальная защищенность программиста (Programmer welfare):
40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Ниже дано описание практик, которые активно используются и в других моделях для повышения качества продукта.
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.
При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды.
Коллективное владение означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.
Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если не рассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным.
Заказчик всегда рядом. «Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований.
Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости. Рефакторинг позволяет разрабатывать архитектуру программы постепенно, откладывая проектные решения до тех пор, пока не станет более ясной их необходимость.
Автоматическое юнит-тестирование позволяет убедиться, что рефакторинг не разрушил существующую функциональность. Иногда под рефакторингом неправильно подразумевают коррекцию кода с заранее оговоренными правилами отступа, перевода строк, внесения комментариев и прочими визуально значимыми изменениями, которые никак не отражаются на процессе компиляции, с целью обеспечения лучшей читаемости кода
Цель рефакторинга - сделать код программы более легким для понимания; без этого рефакторинг нельзя считать успешным. Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет ее работу.
Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу. С другой стороны, нужно отличать рефакторинг от реинжиниринга, который осуществляется для расширения функциональности программного обеспечения. Как правило, крупные рефакторинги предваряют реинжиниринг.
Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:
Необходимо добавить новую функцию, которая не достаточно укладывается в принятое архитектурное решение
Необходимо исправить ошибку, причины возникновения которой сразу не ясны
Когда сложно объяснить коллеге логику работы программы
Во многом, при рефакторинге лучше полагаться на интуицию, основанную на опыте. Но можно выделить наиболее очевидные причины, когда код нужно подвергнуть рефакторингу:
Дублирование кода
Длинный метод
Большой класс
Длинный список параметров
"Завистливые" функции - это метод, который чрезмерно обращается к данным другого объекта
Избыточные временные переменные
Классы данных
Не сгруппированные данные
Непрерывная интеграция (Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.
Требования к проекту:
Исходные коды и все, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями;
Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы
На выделенном сервере организуется служба, запускающая локальную сборку
по внешнему запросу,
по расписанию,
по факту обновления репозитория, и др.
В случае сборки по расписанию (daily build —ежедневная сборка) дополнительно вводится система нумерации сборок. Обычно каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой.
Исходные тексты и другие исходные данные при взятии их из репозитория системы контроля версий помечаются номером сборки. Благодаря этому точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.
|
