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

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

Классическая (монументальная) методология применяется, если:

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

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

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

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

Адаптивная (agile - гибкая или lightweight - легкая) методология применяется, если:

Не ясны или изменяются требования к системе.

Заказчик представляет себе разрабатываемое ПО только в общих чертах и предполагает вносить изменения в функциональность или дизайн разрабатываемой программы во время разработки ("не понравилось - поменяйте").

Необходимо как можно быстрее получить первые версии работающей программы.

Решаемая программой задача трудно поддается документированию.

На реализацию всех требований есть достаточный запас времени.

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

В независимости от используемой методологии, рабочий процесс, подчиняется следующим простым, но важным правилам:

Используется система контроля версий.

Оформление кода стандартизировано.

Первоочередное исправления ошибок перед внесением любых других изменений.

Выполняется регулярное резервное копирование всех проектных данных.

Используются инструментальные средства автоматизации документирования исходного кода и ведения списков ошибок.

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

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

Потребность в альтернативе классическим (монументальным) методологиям, которые в основном основаны на документации, привела к тому, что в 2001 году был проведен семинар, куда были приглашены представители различных адаптивных (гибких) методологий. Результатом работы стал манифест гибкой разработки ПО (Manifest for Agile Software Development) (см. Приложение 1).

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

Методология SCRUM.

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

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

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

Отличительной чертой SCRUM является проведение ежедневных 15-30 минутных совещаний, которые так и называются scrum (потасовка). В ходе этих совещаний лидер команды задает каждому следующие вопросы:

Что удалось сделать из выбранных для данной итерации функций за прошедший день?

Были ли какие-либо проблемы с реализацией?

Что планируется сделать за сегодняшний день?

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

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

Экстремальное программирование (eXtreme Programming или XP)

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

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

Семейство методологий Crystal.

Crystal - это не просто методология, это целое семейство методологий, разработанное Алистером Коберном.

Коберн рассматривает процесс создания ПО как конечную целенаправленную игру и утверждает, что у этой игры есть всего две цели: главная и вспомогательная. Главная цель заключается в том, чтобы успешно закончить проект, то есть создать работающий продукт. Второстепенная цель - подготовиться к следующей игре. Для достижения этой цели может понадобиться документация, качественное написание кода, то есть все, что облегчает дальнейшее развитие и поддержку продукта.

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

Коберн классифицирует проекты по двум параметрам: критичность и величина команды. Под критичностью понимается величина ущерба, нанесенного в результате использования продукта. Например, ошибка в ПО для космического корабля или для аппарата искусственного дыхания несравнима с ошибкой в ПО для форума на сайте. Жизненно важные проекты имеют категорию L, а те, ошибка в которых обозначает потерю удобств, категорию С.

Степень важности нарастает по вертикальной оси. Величина команды нарастает по горизонтальной оси. В результате получается семейство методологий. Чем ниже критичность и чем меньше команда, тем более "легкую" методологию нужно использовать. Самой легкой из всего семейства является методология Crystal Clear. Главные принципы данной методологии:

Вся команда разработчиков (до 6 человек) находится в одном помещении. Это позволяет сократить временные затраты на коммуникацию.

Частые поставки продукта позволяют выработать "ритм" проекта. Ничто так не вдохновляет команду, как поставленный вовремя продукт.

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

Средства контроля версий кода обеспечивают коллективное владение кодом.

Семейство методологий Crystal построено на итеративной разработке. Продолжительность итерации может изменяться в предела от 1 до 4 месяцев. Чем меньше итерация, тем лучше.

Важной особенностью Crystal является непрерывная настройка методологии. Это позволяет постепенно адаптировать ее для конкретной команды и конкретного проекта. Пожалуй, ни в одной другой методологии настройке не уделяется такого внимания.

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

Открытый исходный код (Open Source).

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

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

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

Адаптивная методология (Adaptive Software Development или ASD).

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

ASD базируется на принципе непрерывной адаптации, благодаря которой возникает другой жизненный цикл проекта. Постоянные изменения в проекте становятся нормой.

В ASD обычный статический жизненный цикл "Планирование - Проектирование - Конструирование" заменен на динамический "Обдумывание - Взаимодействие - Обучение".

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

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

Функционально-ориентированная разработка (Feature Driven Development или FDD).

Ключевую роль играет понятие функции или свойства (feature) системы. Функция должна реализовываться не более чем за две недели. То есть, если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько, относительно независимых, функций.

FDD включает пять процессов, последние два из которых повторяются для каждой функции:

разработка общей модели;

составление списка необходимых функций системы;

планирование работы над каждой функцией;

проектирование функции;

конструирование функции.

Разработчики в FDD делятся на "хозяев классов" и "главных программистов". Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в ХР нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки.

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

Метод разработки динамических систем (Dynamic System Development Method или DSDM).

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

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

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

DSDM неприменима если:

проект не сводится к итеративному приложению, где функциональность становится очевидна заказчику через пользовательский интерфейс;

не определена группа пользователей;

проект зависит от сложных внутренних вычислений.

Основные принципы DSDM:

Активное вмешательство пользователя (в идеале, пользователи и разработчики разделяют рабочее пространство, поэтому решения могут приниматься на месте).

Команда должна иметь возможность принимать решения без ожидания подтверждения вышестоящими уровнями (команда состоит как из разработчиков, так и из заказчиков).

Требования заказчика - прежде всего.

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

Разработка итеративная, управляемая пользовательским откликом. Итерации свойственны всей разработке ПО (разработчики постоянно улучшают систему посредством итераций, что дает им возможность извлекать пользу от вовлечения пользователей).

Все изменения обратимы (возвращение - основная черта DSDM).

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