7

Обеспечьте максимально точное выполнение требований заказчиков

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

Сконцентрируйтесь на исполняемой программе

Главный результат, которого ждет от вас заказчик – работающая система. Поэтому никакие документы и модели не важны сами по себе. Они важны лишь настолько, насколько помогают создать работающую систему. И свой успех вы должны измерять именно этим.

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

Будьте готовы к изменениям с самого начала проекта

Изменения – это очень хорошо для проекта. Вряд ли вы везде и всегда сможете найти оптимальное решение с первой попытки. А изменения дают вам еще один шанс.

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

Закладывайте основу исполнимой архитектуры как можно раньше

Архитектура новой системы – один из основных источников риска в проекте. Наличие стабильной, тщательно протестированной архитектуры – хороший базис для быстрого и успешного завершения проекта.

Posted by admin

2четко определенный процесс

RUP создавался по методике, используемой при проектировании ПС. В частности, моделирование производилось с помощью Software Process Engineering Metamodel (SPEM) – стандарта моделирования процессов, основанного на UnifiedModeling Language (UML). У процесса есть два измерения:

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

Статическая структура. Вертикальное измерение представляет собой статическую структуру процесса. Оно описывает, как элементы процесса – задачи, дисциплины, артефакты и роли – логически группируются в дисциплины или рабочие процессы (workflows).

Динамическая структура RUP состоит из четырех фаз: Inception, Elaboration, Construction и Transition. Фазы могут подразделяться на итерации. Переход с фазы на фазу возможен только после выполнения задач фазы и представляет собой контрольную точку (milestone) процесса.

Статическая структура RUP состоит из дисциплин, в которые группируются работы, задачи, артефакты и роли. Для описания осмысленной последовательности выполнения работ и задач используются рабочие процессы. Они описывают кто, что, как и когда выполняет в процессе. В RUP входят 6 основных дисциплин:

  • Бизнес-моделирование (Business modeling);

  • Управление требованиями (Requirements);

  • Анализ и Проектирование (Analysis and Design);

  • Реализация (Implementation);

  • Тестирование (Test);

  • Развертывание (Deployment).

И три вспомогательные:

  • Управление проектом (Project management);

  • Управление изменениями (Change management);

  • Среда (Environment).

В отличие от каскадного подхода (<водопада>), в RUP все дисциплины выполняются практически во всех фазах жизненного цикла ПС. Однако, в зависимости от фазы, меняются текущие цели проекта и соотношение между объемами работ, соответствующих различным дисциплинам.

Так фаза Inception посвящена определению

Posted by admin