Сравнение RUP и других методологий разработки ПО

Но что реально даст такое сравнение? Как можно сравнивать по этим показателям современные методологии, которые, вообще говоря, не регламентируют строго ни то, ни другое, ни третье… И как измерять степень различия? В методологию А входит на три артефакта и на две задачи больше, чем в методологию B? И что? Какой вывод можно из этого сделать? Так что же является теми ключевыми характеристиками, которые позволили бы сказать, что методологии А и В близки между собой, а методология С, напротив, отличается от А очень сильно?

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

Итеративная разработка

Что представляют собой предложенные для сравнения характеристики?

Начнем с итеративной разработки ее отличия от каскадной ( «водопада»).

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

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

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

Уровень формализма

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

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

С чем сравнивать

С какими методологиями имеет смысл сравнивать RUP? Конечно, с теми, которые наиболее распространены или про которые хотя бы можно прочитать.

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

Структурные методологии, в частности, основанные на подходах Эдварда Йордона, диаграммах «сущность-отношение» и потоках данных, были первыми активно продвигаемыми в нашей стране методологиями. Хотя они нередко связывались (по крайней мере, у слушателей презентаций) с реализующими их CASE средствами, а не рассматривались как самостоятельные методологии, тем не менее, они оказались достаточно известными, хотя нельзя сказать, что широко используемыми. Тем не менее, сравнение с ними имеет определенный смысл. По крайней мере, оно должно показать, насколько RUP отличается от них.

Наибольший интерес в настоящее время, видимо, представляет сравнение с гибкими (Agile) методологиями (3), которые в последние годы активно развиваются и приобрели определенную популярность. Так называется группа относительно новых методов, развиваемых участниками Agile Manifest (4) — объединения в поддержку гибких методов. Общее число таких методологий достаточно велико. Но не все из них широко известны, и не по всем из них можно найти материалы на русском языке. Поэтому для сравнения были выбраны Экстремальное программирование (XP), Crystal Clear и FDD (Feature Driven Development).

Кроме методологий, описывающих что, как и в каком порядке надо делать, есть еще один тип документов, регламентирующих разработку ПО. Это международные и государственные стандарты и другие разработки, направленные на определение требований к процессам разработки. Среди стандартов наибольший интерес для отечественного производителя представляют, конечно, ГОСТы 19-ой и 34-ой серий и ГОСТ 12207 Р ИСО МЭК. А среди других регламентирующих документов наиболее известна модель зрелости процессов разработки ПО CMM, разработанная Software Engineering Institute (5).

Как получится…

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

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