RUP и другие методологии разработки ПО
Часть 1. Принципы сравнения методологий разработки ПО
Итеративная или каскадная разработка
Почему важна степень формализма
В наше время руководителю проекта разработки программного обеспечения (ПО) нет необходимости с нуля выдумывать собственную методологию разработки программного обеспечения. Он может выбирать из достаточно широкого набора готовых методологий, предлагаемых различными авторами. Но как выбрать методологию «по размеру» и все ли они пригодны для любого проекта?
Настоящая статья адресована всем, кто собирается внедрять методологию RUP. Она посвящена сравнению RUP с другими популярными методологиями. В первой части статьи обсуждаются принципы сравнения различных методологий. Вторая часть будет посвящена собственно сравнению этих методологий. В третьей части будут даны рекомендации по выбору и настройке методологий под конкретные проекты.
Как «измерить» методологию
Разрабатывать ПО можно при помощи различных методологий. Как всегда, когда существует возможность выбора, неизбежно возникает ответственность за его результат. Неверно выбранная методология может привести к перерасходу ресурсов, к затягиванию сроков выполнения проекта и даже к его полному провалу.
Как выбрать подходящую методологию? Чем вообще они различаются? Перед покупкой, например, первой цифровой камеры обычно приходится долго выяснять, по каким показателям их сравнивать. А по каким показателям сравнивать методологии? Казалось бы, очень простой вопрос: по работам и задачам, из которых состоит разработка ПО; по стадиям разработки, в которые эти работы группируются; по составу каждой стадии; по разрабатываемым документам и моделям.
Но что реально даст нам такое сравнение? Как можно сравнивать по этим показателям современные методологии, которые, строго говоря, не регламентируют жестко ни то, ни другое, ни третье? Методология А, скажем, предполагает оформление требований в форме сценариев использования (use case), методология Б — в форме историй, а методология В — в форме технического задания (ТЗ). И как в этом случае можно сравнить их между собой? Тем более что автору приходилось, например, включать в ТЗ сценарии использования. Так что название документов — явно не самая принципиальная характеристика методологии. Каковы же те ключевые принципы, которые позволили бы сказать, что методологии А и Б близки, а методология В, напротив, существенно отличается от А?
Видимо, в настоящее время такими ключевыми принципами следует считать прежде всего отношение методологии к итеративной разработке и степень формальности в оформлении рабочих материалов в проведении разработки как таковой1.
Итеративная или каскадная разработка
Что представляют собой предложенные для сравнения принципы?
Начнем с каскадной разработки («водопада») и с того, чем она отличается от итеративной.
Каскадный подход
Если не углубляться в детали, то каскадные методологии разработки ПО подразумевают, что разработка ПО делится на фазы, каждая из которых характеризуется своим набором работ. Сначала происходит выявление всех требований к проекту и их анализ. Затем проектная группа приступает к проектированию системы (чаще всего сверху вниз, разбив создаваемую систему на подсистемы и далее детализируя их до уровня программных процедур и функций). После этого начинаются разработка кода и модульное тестирование. Затем наступает очередь сборки и системного тестирования. И так далее — вплоть до передачи системы заказчику.
Преимуществами каскадного подхода считаются: минимальный объем переработок написанного кода, возможность тщательно спроектировать архитектуру системы и однократное тестирование системы.
Итеративный подход
В отличие от каскадного, при итеративном подходе разработка разбивается на несколько итераций, и в ходе каждой из них выполняются практически все типы работ, а в результате создается реально работающая система с постоянно совершенствующимися функциональными возможностями. Практически во всех итерациях выполняется и анализ требований, и проектирование, и тестирование. Так, в самой первой итерации, еще до выявления всех требований, может начаться разработка прототипа, на котором проверяются основные архитектурные решения. По мере детализации требований на отдельные подсистемы или компоненты на последующих итерациях начинаются их проектирование и кодирование. Разработанные начерно подсистемы и компоненты собираются в единую систему (не дожидаясь завершения разработки всех подсистем), и немедленно начинается их системное тестирование (тестирование этих модулей повторяется в ходе последующих итераций).
Перечислим преимущества подобного подхода. В процессе разработки всегда появляются дополнительные требования заказчика или изменяются сформулированные им ранее требования. Также появляются новые ограничения, связанные с принятыми техническими решениями, или, наоборот, новые возможности у используемых в разработке операционных систем, баз данных и другого готового ПО. В наиболее полной мере их удается учесть именно в итерационной разработке, поскольку при таком подходе руководство проекта в полной мере готово к изменениям.
Почему это важно
Почему различия между итерационным и каскадным подходами столь важны для характеристики методологии? Дело в том, что они самым принципиальным образом влияют на весь процесс. Для тех, кто привык к каскадной разработке, наиболее существенным, на мой взгляд, отличием являются постоянный состав команды и заранее планируемые повторные работы.
Состав команды
При каскадном подходе в проекте от начала и до конца принимает участие разве что менеджер проекта. Аналитики, зафиксировав требования, уступают место разработчикам, а те, в свою очередь, — специалистам по тестированию. Конечно, ведущий аналитик обычно продолжает присматривать за проектом, давая необходимые пояснения архитектору и программистам, а те, в свою очередь, исправляют обнаруженные тестировщиками дефекты. Но это уже, как правило, неполная занятость. Да и занимаются этим не все участвовавшие в проекте на предыдущей фазе.
При итерационной разработке команда проекта оказывается значительно более стабильной. Она может сохраняться в течение нескольких итераций, активно изменяясь лишь в самом начале и в самом конце проекта.
Повторные работы
При итерационной разработке нужно быть готовым к тому, что в ходе различных итераций будут выполняться одни и те же (по крайней мере по названию) работы. Так, в ходе первых итераций обычно выявляются все наиболее существенные требования к системе. Однако уровень их проработки может весьма различаться, и те требования, которые будут реализовываться в последующих итерациях, должны быть уточнены и детализированы в ходе последующих работ. Модули, разработанные и протестированные на первых итерациях, будут подвергаться системному тестированию в ходе всех последующих итераций. И так далее.
Уровень формализма
Что такое формализм в проекте
Разные методологии различаются не только названиями документов и моделей, которые разрабатываются в ходе проекта, но и тем, насколько формализовано ведется разработка. Что входит в это понятие? Во-первых, количество документов. Во-вторых, степень аккуратности их оформления и формальность процедур рецензирования, одобрения и передачи. Одно дело, скажем, методология 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.
 |
|
