Набор серебряных пуль

Константин Константинович Берлинский, 2004

Войны ИТ-методологов не затихают. Каждые несколько лет нам преподносится совершенно новая, быстрая, легкая, простая, эффективная методика (или новая версия «старой»). И уж она наконец-то решит главную проблему – построение качественного ПО в срок… Я думаю, что правда о методологиях заключается в том, что их не существует… Есть лишь УПР – удачные проектные решения, – которые могут сработать (или нет) в конкретной ситуации и проекте. Цель этого справочника – собрать их вместе, дать им краткое описание и подвигнуть ИТ–сообщество к дальнейшему их поиску и классификации…

Методологии разработки ПО

RUP

Rational Unified Process — Рациональный Унифицированный процесс.

RUP был создан в 1996г. корпорацией Rational при участии Гради Буча, Айвара Якобсона и Джима Румбаха.

Это поистине фундаментальная работа по описанию успешных методик создания ПО. Жизненные циклы ПО, потоки работ, роли, деятельности, артефакты, продукты, поддерживающие большую часть этапов ЖЦ. Не зря эту методику называют «тяжеловесной». Поддержка языка UML. RUP в качестве самостоятельной базы знаний по объему и значению может сравниться разве что с MSDN.

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

Продукты, поддерживающие методику — в первую очередь, это продукты самой компании Rational. Основной продукт Rose (используется практически на всех этапах разработки), SoDA (автодокументирование), RequisitePro (управление требованиями), ClearQuest (запросы на изменения), ClearCase (версионность), Administrator (управление репозиторием проекта), WorkBrench (настройка корпоративных процессов), Quantify (тестирование скорости кода), Purify (определение утечек памяти), PureCoverage (тест охвата кода), Robot (автоматизированное тестирование), SiteLoad (нагрузочное тестирование), SiteCheck (проверка «мертвых» Web-ссылок). В настоящее время доступен RUP, интегрированный в среду разработки Microsoft.NET (под названием Rational XDE).

XP

Extreme Programming — Экстремальное программирование.

Рождением (а точнее датой «официальной» регистрации) можно считать 2001г., когда в США, штате Юта 17 сторонников «легковесных» процессов разработки выработали манифест с основными постулатами. Идеологами методики можно считать Кента Бека, Уорда Каннингема и Рона Джеффриса.

Основные принципы: тесная коммуникация, постоянное тестирование, минимум документации и максимум гибкости. Впрочем, лучше привести текст манифеста (см. книгу [4]):

«Мы открываем лучшие способы разработки ПО, создавая его сами и помогая другим. Благодаря этой работе мы стали ценить:

Индивидуумов и взаимодействия выше процессов и инструментов

Работающее ПО выше всеобъемлющей документации

Сотрудничество с заказчиками выше согласований условий договора

Реагирование на изменения выше соблюдения плана

Это означает, что, хотя элементы в правой части также имеют свою ценность, но больше мы ценим элементы, расположенные слева».

Довольно краткие и понятные формулировки, делающие доступными высказанные идеи самым широким массам. ХР впервые озвучила некоторые совершенно революционные принципы разработки. «Это вам не понадобится», «Ищите самое простое решение, которое может сработать», «Любые сидящие рядом два разработчика могут поменять всё что угодно в системе», «Заказчик в любой момент может изменить требования» и др.

Однако я уже высказывал свою критику по поводу ХР. Большая часть претензий к ХР снимается, вследствие более детального знакомства с ней. Можно считать, что последние проекты, в которых я участвовал, были «в духе ХР».

Осталась следующая критика:

1. Идея «нахождения представителя заказчика в одной комнате с программистами» по моему мнению, мягко говоря, является фантастическим пожеланием. Никто не спорит, что коммуникация с заказчиком жизненно необходима. Но решение проблемы скорее находится, во-первых, в сфере разработки стандартных форм документов по взаимодействию (ТЗ, ТП). Во-вторых, в более быстрых итерациях (нужно помочь заказчику сформулировать и откорректировать своё видение системы)

2. Отрицание этапа «большого предварительного проектирования» допустимо только при разработке тривиальных систем (несложные сайты с уклоном в сторону дизайна, а не программирования, простейшие однопользовательские программы с минимумом бизнес-логики и т.п.). Цитируя одного из авторов: «Я рассматриваю здесь решения, полезные при разработке сложных систем. Если приложение простое, зачем тратить на него своё время?». В сложном и интересном проекте, с «богатой» предметной областью было бы преступной халатностью не сформировать в самом начале каркас системы, основные принципы его функционирования. Конечно, «настоящие ХР-шники» стоически воспримут информацию в середине проекта о том, что обнаружился прецедент, заставляющий переделать большую часть кода (или ещё хуже выбросить его). Но я считаю это совершенно недопустимым.

3. Десятки userstory (бумажки с несколькими предложениями, характеризующими прецедент пользователя), оставшиеся после завершения проекта, не могут служить в качестве надежной документации. Получается, что ХР нацелена на быструю разработку ПО, но не на его сопровождение. Приведу цитату из книги [4] по поводу неудачи проекта 3C, выполненного посредством ХР (расчет зарплаты для Chrysler — могу подтвердить, что зарплата при своей внешней простоте одна из самых трудных областей бухгалтерии, в которой «утонула» не одна команда программистов). «Когда ушло достаточно много сотрудников, незаписанные сведения о проекте и групповая память были утрачены». Я думаю, что апологеты ХР переусердствовали с минимизацией документации. Что для студентов может выглядеть привлекательным, серьезных разработчиков должно насторожить.

Должен поделиться собственным ощущением от «работы в стиле ХР». В отличие от RUP (или любой другой методики с фиксированием результатов этапов, посредством тех. задания, тех. проекта и т.п.) ХР дает ощущение неуверенности и анархии в начале проекта. Бизнес-требования и архитектура меняются так быстро, что, просидев пару дней дома можно потом не узнать структуру базовых классов (даже если ты сам её придумал).

Сразу начинаешь понимать положение ХР о 40-часовой рабочей недели без переработок. Зачем до 22_00 трудиться в поте лица над модулем, который завтра может вообще не понадобиться?

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

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

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

SADT

Structured Analysis and Design Technique — Методология структурного анализа и проектирования.

Известна как разработка компании SofTech, либо как только функциональный вариант в правительственной версии (IDEF0). Её начали применять с 1973г. во многих областях, таких как бизнес, производство, оборона, связь и организация проектирования.

Диаграммы в стандарте IDEF0 имеют несомненное преимущество для функционального моделирования системы. Однако представление модулей системы в виде блоков с набором входов и выходов и набором управляющих воздействий на них хорошо раскрывает только высокоуровневые структурные особенности системы. В этом SADT успешно конкурирует с диаграммами деятельности языка UML.

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

SADT в полной мере реализует идею «большого предварительного проектирования в начале разработки» с целью уменьшить «просачивание» ошибок на более поздние этапы ЖЦ, где дороже их исправление (см. книгу [24]). Из-за жесткой декомпозиции процесса разработки методику можно считать «прародителем» RUP.

MSF & MOF

Microsoft Solutions Framework (Набор решений от MS) и Microsoft Operations Framework (Набор операций от MS).

По замыслу составителей методики, она объединяет лучшие принципы каскадной и спиральной моделей разработки ПО, так сказать «лучшее из двух миров» (см. сайт [23]). Естественно, для достижения успешного результата предлагаются решения и продукты непосредственно от Microsoft.

Однако нельзя не признать огромную заслугу компании Microsoft в сфере компьютерной индустрии. Стоит изучить MSF только из-за того, что «так делает лидер».

Конец ознакомительного фрагмента.