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

разработку

ПО, но не на его

сопровождение

. Приведу цитату из книги [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 только из-за того, что «так делает лидер».

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