Разрабатывать систему из компонентов

Главное внимание — исполняемой программе

Разрабатывать именно то, что нужно заказчику

Атаковать риски как можно раньше

The Spirit of RUP

Для характеристики RUP введено понятие «Дух RUP» (The Spirit of RUP), который заключен в 8 принципах:

• атаковать риски как можно раньше, пока они сами не перешли в атаку;
• разрабатывать именно то, что нужно заказчику;
• главное внимание - исполняемой программе;
• приспосабливаться к изменениям с самого начала проекта;
• создавать архитектурный каркас как можно раньше;
• разрабатывать систему из компонентов;
• работать как одна команда;
• сделать качество стилем жизни.

Риск — это все то, что может привести к возникновению проблем в ходе разработки.

Информационные системы разрабатываются для заказчиков и покупателей, и надо максимально точно выполнять все их пожелания. Формулирование требований в форме примеров использования и формирование тестов на основе этих прецедентов позволят быстрее понять пожелания заказчика и точнее их выполнить. А заказчику они помогут с самого начала понять, что вы собираетесь разрабатывать, и при необходимости откорректировать ваши планы.

Главный результат, которого ждет заказчик, — работающая система. Никакие документы и модели сами по себе не важны. Они важны лишь настолько, насколько помогают создать и поддерживать работающую систему. Срок жизни программ в наши дни часто не превышает пары лет. Затем они нередко заменяются совершенно другими программами, часто выполненными в другой технологии и реализующими другие бизнес-правила. Всегда ли нужна ли в такой ситуации детальная тщательно проработанная проектная документация? Или ее разработка приведет только к неоправданному завышению стоимости разработки? Конечно, вопрос этот в каждом конкретном случае требует серьезного анализа. Но важно понять, что простой рецепт «документации всегда должно быть много» не является безоговорочно верным.

Использование компонентов, соединяющих данные и методы для их обработки, — это наиболее эффективный способ декомпозиции системы. Если разбивать систему на подсистемы по функциональному принципу, возникает множество связей через данные. Если же данные и методы для работы с ними объединены в компоненте, все изменения в такой системе ограничиваются одним компонентом. Доступ к компоненту осуществляется только через хорошо определенный интерфейс. Еще одно достоинство компонента состоит в том, что его можно использовать повторно или заменить другим компонентом; достаточно проверить, что сохранен старый интерфейс.