Методологии разработки программного обеспечения

Я не являюсь приверженцем или фанатиком методологий Agile (XP, Lean, Scrum, FDD и др.) - равно как любой другой. Почему? Потому что, при agile-подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта».

Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта.

Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. Кроме того, считается, что работа в agile-команде мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов. А это уже диагноз.

Тут я попробую описать две методологии, которые я полагаю, применяемые совместно, приносят наибольшую пользу в управлении жизненным циклом проектирования, разработки и эксплуатации ПО.

Каскадная модель - (waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

В 1970 году в своей статье У.У. Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель» (в простонародье - "водопад"), и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели. В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:

Жизненный цикл каскадной модели.

Это самая первая методология, с которой я познакомился, начав заниматься программированием и построением автоматизированный систем.

Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.

Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит. Тем не менее, существуют модифицированные каскадные модели (включая модель самого Ройса), имеющие небольшие или даже значительные вариации описанного процесса.

Основные соображения для использования такой модели разработки вполне очевидны. Как известно, стоимость исправления ошибок, сделанных в ходе выполнения проекта зависит от того, насколько быстро эти ошибки обнаруживаются и исправляются. Ошибку в требованиях достаточно просто исправить на этапе разработки требований, но если о ней становится известно после завершения развертывания, последствия могут быть катастрофическими. Модель водопада стремится уменьшить, насколько это возможно, число таких долгоживущих ошибок. Для этого разработка дизайна не должна начинаться, пока требования не будут определены с достаточным качеством, кодирование не начинается до появления полного дизайна системы и т.д.

Насколько эффективным оказался такой подход? Он хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. В таких проектах модель водопада позволяет обеспечить заданный уровень качества (который может быть весьма высоким) и соблюдать бюджетные и временные ограничения.

Критика каскадной модели и гибридные методологические решения.

Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK (Project Management Body of Knowledge) 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов. Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом Проектного Менеджмента (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «водопада», так и достижения итеративных методологов.

Модель водопада является разумным выбором для типовых, стандартных проектов или при наличии жестких требований к качеству (например, при создании mission critical-систем). Тем не менее, ее недостатки весьма существенны, и для разработки коммерческого ПО, как правило, существуют значительно более эффективные альтернативы.

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

Основываясь на специфике проекта и требованиях заказчика, разработчики могут выбирать, что они хотят получить в результате очередной итерации:

Важно понимать, что все эти преимущества проявляются только при тщательном планировании итераций, в противном случае легко получить ухудшенный вариант модели водопада.

DSDM (Dynamic Systems Development Method) - метод разработки динамических систем, основанный, главным образом, на концепции быстрой разработки приложений (Rapid Application Development, RAD). В 2007 году DSDM стал основным подходом к управлению проектом и разработки приложений. DSDM - это итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.

Цель метода - сдать готовый проект вовремя и уложиться в бюджет, но в то же время регулируя изменения требований к проекту во время его разработки. DSDM входит в семейство гибкой методологии разработки программного обеспечения, а также разработок не входящих в сферу информационных технологий.

Как расширение концепции быстрой разработки приложений, DSDM фокусируется на проектах информационных систем, характеризующихся сжатыми сроками и бюджетами.В DSDM присутствуют указания на типичные ошибки проектов информационных систем, таких как превышение бюджета, опоздание со сроками сдачи (исполнения), недостаточное вовлечение пользователей и топ-менеджеров в работу над проектом. DSDM состоит из:

При некоторых условиях существует возможность включения в DSDM частей других методик, таких как Rational Unified Process (RUP), Экстремальное программирование, PRINCE2.

DSDM был разработан в Великобритании в 1990-х Консорциумом DSDM. Консорциум DSDM - это ассоциация разработчиков и экспертов в области программного обеспечения, созданная с целью "совместной разработки и продвижения независимого фреймворка RAD" комбинированием лучшего практического опыта участников ассоциации. Консорциумом DSDM - это некоммерческая организация независимых разработчиков, которые владеют и управляют фреймворком DSDM. Первая версия фреймворка была завершена в январе 1995 года и опубликована в феврале 1995 года. В июле 2006 года была представлена открытая версия DSDM 4.2, которая стала доступна частным лицам для просмотра и использования. Тем не менее, все, кто распространяет DSDM должны быть членами этого некоммерческого консорциума.

Принципы.

Чтобы успешно использовать DSDM, необходимо чтобы был выполнен ряд предпосылок. Во-первых, необходимо организовать взаимодействие между проектной командой, будущими пользователями и высшим руководством. Во-вторых, должна присутствовать возможность разбиения проекта на меньшие части, что позволит использовать итеративный подход.

Два примера проектов, для которых DSDM не очень подходит:

Жизненный цикл проекта.

Фреймворк DSDM состоит из трёх последовательных стадий, которые называются предпроектная стадия, стадия жизненного цикла проекта и постпроектная стадия. Стадия жизненного цикла проекта - самая продуманная и детально разработанная из всех остальных. Она состоит из пяти этапов, которые формируют итеративный, инкрементный подход к разработке информационных систем. Эти три фазы и соответствующие этапы будут более подробно описаны в последующих разделах. Для каждой стадии или этапа будут рассмотрены самые важные функции и будут представлены результаты.

Ниже на диаграмме представлен весь жизненный цикл проекта. Эта диаграмма описывает итеративную разработку DSDM. Описание каждого этапа будет представлено ниже.

Диаграмма жизненного цикла проекта

Четыре этапа стадии жизненного цикла проекта

Этап 1А: Исследование реализуемости

В течение этого этапа, проверяется реализуемость проекта в рамках DSDM. Предпосылки для использования DSDM проверяются ответом на вопросы: «Может ли данный проект удовлетворить необходимым экономическим требованиям?», «Проект подходит для использования метода DSDM?» и «Какие риски в этом проекте самые важные?». Наиболее важный метод на этом этапе - использование рабочих групп.

Итог данного этапа - отчёт о применимости и допустимый прототип, в которых рассмотрена реализуемость проекта, а также примерный глобальный план проекта и протокол возможных рисков, описывающий наиболее важные риски проекта.

Этап 1Б: Исследование экономической целесообразности.

Исследование экономической целесообразности расширяет и дополняет этап исследования реализуемости. После того как проект был признан реализуемым в рамках DSDM, на этой стадии проверяются бизнес-процессы, происходит вовлечение групп пользователей и анализ их требований и пожеланий. И опять же самым востребованным методом на данном этапе является использование рабочих групп. В рамках рабочих групп участники проекта собираются, чтобы обсудить планируемую систему. Информация полученная после данных мероприятий собирается в список требований. Важное свойство этого списка - распределение приоритетов среди требований. Эти требования распределены согласно методу MoSCoW. На основе полученной очерёдности создаётся план разработки, который будет ориентиром для всего проекта.

Для создания этого плана применяться очень важная для проекта методика - тайм-боксинг. Эта методика обязательна для достижения целей DSDM - уложится в сроки и в бюджет, и при этом сохранить необходимое качество продукта. Архитектура системы - ещё одно подспорье в управлении разработкой информационной системы. Итогом данного этапа является описание сферы коммерческой деятельности, в котором содержится context of the project within the company, описание архитектуры системы, предоставляющее первоначальную глобальную архитектуру информационной системы, находящейся в разработке, и план разработки, котором обозначены наиболее важные шаги в процессе разработки. В основе этих двух документов лежит список требований. Протокол возможных рисков дополняется данными, полученными на этом этапе.

Этап 2: Создание функциональной модели

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

Итогом данного этапа являются функциональная модель и функциональный прототип, которые вместе представляют функционал полученный на этой итерации, готовые для тестирования пользователями. Далее обновляется список требований - из него удаляются уже реализованные пункты и происходит повторное изменение очерёдности оставшихся пунктов. Протокол возможных рисков также обновляется, после анализа функционального прототипа.

Этап 3: Проектирование и разработка

Итог этапа - создание конструктивного прототипа для тестирования пользователями. Протестированная система переходит на следующий этап. На данном этапе внешний вид и функционал системы в общем готовы. Ещё один итог - создание пользовательской документации.

Этап 4: Реализация.

На этапе реализации протестированная система вместе с пользовательской документацией доставляется к будущим пользователям и происходит их обучение работы с системой. Система анализируется на соответствие требованиям, поставленных на ранних этапах проекта. Реализацию можно разделить на следующие подэтапы:

Итог этапа: законченная система, пригодная для использования конечными пользователями, контингент обученных пользователей и детальный документ анализа проекта.

Этап создания функциональной модели DSDM.

Модель мета-данных.

Связи между понятиями на этапе создания функциональной модели показаны на рисунке ниже.

Модель мета-данных.

Модель развития процесса.

Работа по определению функционального прототипа заключается в определении функционала, который будет присутствовать в прототипе на данной итерации. Аналитика и программирование закончено; прототипы собраны; и опыт полученный от них использован для улучшения моделей анализа (а также основывается на обновлённых списке требований и протоколе возможных рисков). Построенные прототипы не выбрасываются, а понемногу доводятся до необходимого качества, чтобы потом включить в готовую систему. Согласованный график работ необходим, чтобы определить когда и в какие сроки будет реализовано прототипирование; он расширяет расписание и план прототипирования. А тестирование, проводящееся в течение всего процесса, также является непременной частью этого этапа и включается в процесс анализа прототипа сразу после того, как прототип будет построен. Протокол испытания также будет использован для анализа прототипа и создания документа анализа. Ниже представлена диаграмма данного процесса.

Диаграмма создания функциональной модели.

Основные методики DSDM

MUST - требование ДОЛЖНО удовлетворять экономическим нуждам.

SHOULD - СЛЕДУЕТ ли выполнять это требование, если от него не зависит успех проекта.

COULD - НУЖНО ли оставить это требование, если оно не действует на деловую потребность проекта.

WOULD - МОЖНО ли отложить выполнение требования, если ещё есть время.

Итеративная и инкрементная природа DSDM

Кроме тайм-боксинга и распределения требований по приоритетам метод DSDM также использует итеративный и инкрементный подход к созданию информационных систем.

Этап создания функциональной модели, этап проектирования и разработки и этап реализации могут проходить по своим подстадиям много раз прежде, чем двигаться дальше к следующей стадии. На каждой итерации рассматриваются новые функции и каждая текущая итерация основывается на предыдущей. И если потребуется, каждую итерацию можно оставить недоделанной.

Например, если много новых и полезных функций было открыто во время разработки, но они не могут быть реализованы, то можно начать проект заново составлением новых требований на стадии исследования экономической целесообразности. Или, наоборот, некоторые функции могут быть опущены из-за ограниченности бюджета или времени. Проект может перейти в постпроектную стадию только, когда выполнены все поставленные требования.

Благодаря итеративной природе DSDM, наличествует должное управления требованиями и конфигурацией на протяжении всего проекта. Это обеспечивает реализацию всех требований, поставленных на ранних стадиях проекта.

Факторы, необходимые для успеха метода DSDM

В рамках DSDM существуют следующие факторы, которые влияют на успех проекта.

Сравнение с другими методами разработки информационных систем

Уже было разработано и применено в деле множество методов разработки информационных систем. Например, Structured Systems Analysis and Design Method (SSADM), методы быстрой разработки приложений RAD, методы ООП. Большинство этих методом похожи друг на друга и на DSDM. Метод экстремального программирования также использует итеративный подход к разработке информационных систем с привлечением пользователей.

Метод Rational Unified Process - самый похожий на DSDM, также является динамическим методом разработки информационных систем. И опять же в нём применяется итеративный подход в разработке.

Существуют и другие методы, которые могут показаться похожими на DSDM, но существует ряд отличий. Во-первых, он предоставляет необходимые инструменты и способы разработки. Это позволяет пользователям особым образом дополнить процесс разработки своими собственными методами и помочь в принятии решений. Ещё одна уникальная особенность - можно менять не время или средства разработки, а требования к проекту. Такой подход обеспечивает достижение основных целей DSDM - уложиться по времени и не выйти за рамки бюджета.

И последнее - взаимопонимание и общение между всеми участниками и их вовлечённость в проект.