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

Берлинский Константин

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

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

 

Идея «нахождения представителя заказчика в одной комнате с программистами» по моему мнению, мягко говоря, является фантастическим пожеланием. Никто не спорит, что коммуникация с заказчиком жизненно необходима. Но решение проблемы скорее находится, во-первых, в сфере разработки стандартных форм

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

 

Отрицание этапа «большого предварительного проектирования» допустимо только при разработке тривиальных систем (несложные сайты с уклоном в сторону дизайна, а не программирования, простейшие однопользовательские программы с минимумом бизнес-логики и т.п.). Цитируя одного из авторов: «Я рассматриваю здесь решения, полезные при разработке

сложных

систем. Если приложение простое, зачем тратить на него своё время?». В сложном и интересном проекте, с «богатой» предметной областью было бы преступной халатностью не сформировать

в самом начале

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

 

Десятки 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 только из-за того, что «так делает лидер».

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