Unified software development process

Перелистываю фундаментальную книжку «троих друзей» (Jacobson, Booch, Rumbaugh) об унифицированном процессе разработки ПО 1999 года выпуска (перевод на русский в 2002) и с сожалением осознаю, что наиболее ценные идеи RUP и UML не нашли своего воплощения в корпоративной среде. Сплошь и рядом игнорируются три основные свойства унифицированного процесса:

  • управляемый вариантами использования;
  • ориентированный на архитектуру;
  • итеративный и инкрементный.

Процесс развития корпоративной информационной управляется deadline-ами (К кому-то на Новый год приходит Дед Мороз, а к кому-то – дед лайн). В лучшем случае, под такую интерацию подкладываются требования в виде списка фич. Причем, элементы такого списка могут описывать структуры данных, элементы поведения, нефункциональные требования и вообще все что угодно. Что означает доступность сервиса 99,9% редко кого волнует. А ведь большинство современных сервисов включают множество вариантов использования: подключение(подписка), предоставление, настройка, разрешение проблем и пр. Какой из этих сценариев должен успешно завершаться в 999 случаях из тысячи и что такое успешное завершение – решительно не понятно. Далее, в отличие от требований, варианты использования четко описывают, для какой группы пользователей предоставляет требуемый функционал и, что даже более важно, зачем он им предоставляется. В требованиях никогда такого не было. Обычная формулировка требования: у объекта X должно быть свойство Y. На вопросы, кто и в какой момент задает значение этого свойства, кто и когда использует это значение, кому разрешено данное значение переопределить, требования не дают ответов. Унифицированный процесс предлагает построить все активности вокруг сценариев: определение состава проекта(итерации), проектирование, разработку и тестирование, развертывание компонент, планирование capacity и т.д.

Сделать это правда, можно только с использованием архитектуры. Основная идея ИТ архитектуры заключается в том, что для получения качественного решения следует рассматривать продукт с нескольких точек зрения. Недостаточно определить структуры данных и операции. Декомпозиция решения на модули позволяет четко определить зоны ответственности различных команд. Описание взаимодействий – собирает отдельные модули в единую работающую систему. Варианты использования привязывают цели пользователей к взаимодействиям между системами и компонентами, что позволяет планировать характеристики продукта (емкость, доступность, время отклика). Планирование развертывания, с одной стороны, дает возможность независимо от процесса разработки готовить инфраструктуру, а с другой стороны помогает не запутаться при согласовании настроек различных сред и приложений.

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

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s