Уровень формализма Что такое формализм в проекте
Разные методологии различаются не только названиями документов и моделей, которые разрабатываются в ходе проекта, но и тем, насколько формализовано ведется разработка. Что входит в это понятие? Во-первых, количество документов. Во-вторых, степень аккуратности их оформления и формальность процедур рецензирования, одобрения и передачи. Одно дело, скажем, методология XP2 , в соответствии с которой проект выполняется командой, сидящей в одной комнате, основная документация по проекту — это хорошо документированный код, а для планирования достаточно использовать карточки с краткими описаниями задач. И другое дело — распределенная разработка, при которой даже внутренние материалы проекта передаются от аналитиков к разработчикам и тестировщикам в виде предварительно отрецензированных и утвержденных бумажных документов.
Почему важна степень формализма
Почему так важна степень формализма как характеристика методологии? Дело в том, что она очень сильно влияет на скорость и трудоемкость разработки. Детальная документация, выполненная даже с использованием современных CASE-средств, требует много времени и сил. В то же время отсутствие или недостаточный уровень формализма при выполнении проекта может приводить к несогласованности решений, принимаемых участниками проекта, к непродуктивным затратам ресурсов на переработку кода (для согласования частей программного обеспечения, разрабатываемых разными участниками проекта) и на повторное решение типовых проблем. Кроме того, недостаток документации может значительно увеличивать стоимость последующего сопровождения продукта, поскольку внесение каких-либо изменений в него потребует очень больших усилий.
Что будем сравнивать
Теперь, когда определены критерии для сравнения методологий, можно переходить к выбору методологий для сравнения.
Поскольку автор является почитателем методологии RUP (Rational Unified Process)3, в качестве базовой методологии в следующей части статьи будет использоваться RUP. С какими методологиями имеет смысл сравнивать RUP? Конечно, с теми, которые наиболее распространены или про которые, как минимум, что-нибудь можно прочитать.
Методология «как получится». Видимо, самый распространенный «метод» — отсутствие какого-либо сознательно выбранного метода. И по сей день разработка ведется по сложившейся привычной схеме. И хотя в каждой команде существует собственный подход к разработке, в них все же можно выявить некоторые общие черты.
Структурные методологии, в частности основанные на подходах Эдварда Йордона, на диаграммах «сущность-отношение» и потоках данных, были первыми активно продвигаемыми в нашей стране методологиями. Зачастую они связывались (по крайней мере у слушателей презентаций) с реализующими их CASE-средствами и не рассматривались как самостоятельные методологии, но, тем не менее, они приобрели достаточную известность, хотя нельзя сказать, что стали широко используемыми. Так что сравнение с ними вполне оправданно. По крайней мере оно должно показать, насколько RUP отличается от них.
Наибольший интерес в настоящее время, видимо, представляет сравнение с гибкими (Agile) методологиями4, которые в последние годы активно развиваются и завоевали определенную популярность. Так называется группа относительно новых методов, развиваемых участниками Agile Manifest5 — объединения в поддержку гибких методов. Общее число подобных методологий достаточно велико, но не все из них широко известны и не по всем можно найти материалы на русском языке. Поэтому для сравнения были выбраны уже упоминавшееся выше экстремальное программирование (XP), Crystal Clear6 и Функционально ориентированная разработка7 (Feature Driven Development, FDD).
Помимо методологий, описывающих, что, как и в каком порядке следует делать, существует еще один тип документов, регламентирующих разработку ПО. Речь идет о международных и государственных стандартах и о других документах, определяющих требования к процессам разработки. Среди стандартов наибольший интерес для отечественного производителя, несомненно, представляют ГОСТы 19-й и 34-й серий и ГОСТ 12207 Р ИСО МЭК. А из других регламентирующих документов наиболее известна модель зрелости процессов разработки ПО CMM, разработанная Software Engineering Institute8.
Но обо всем этом мы поговорим в следующей части нашей статьи.
1 Пример использования этих показателей для сравнения методологий можно найти, например, в книге «RUP Made it easy» Пера Кролла и Филиппа Крачтена (Addison-Wesley, 2003) (есть русский перевод: Кролл П., Крачтен Ф. Rational Unified Process — это легко: Руководство по RUP для практиков. Кудиц, 2004). Однако эти авторы, естественно, ориентируются на методологии и стандарты, используемые западными разработчиками.
2 Довольно полный обзор методологии сделан в кн.: Бек К. Экстремальное программирование. СПб.: Питер, 2002.
3 Описание RUP можно найти, например, в упоминавшейся выше книге Кролла и Крачтена.
4 Agile иногда переводят как «быстрые методы», но автор поддерживает ту точку зрения, что перевод «быстрые методы» лучше использовать для RAD (Rapid Application Development) методологий.
5 См.: http://www.agilemanifesto.org.
6 Описание этой и других методологий из семейства Crystal можно найти в кн.: Коберн А. Быстрая разработка программного обеспечения. М.: Лори, 2002.
7 Детальное описание методологии можно найти в кн.: Пальмер С.Р., Фелсинг Д.Ф. Практическое руководство по функционально ориентированной разработке ПО. Вильямс, 2002.
8 http://www.sei.cmu.edu/about/about.html.