|
Определение требований проекта к рекомендациям
|
Цель:
|
Выявление рекомендаций, необходимых для проекта.
|
Учитывая создаваемые рабочие продукты и требуемые уровни формальности, определите набор рекомендаций, необходимых для
проекта. Рекомендации подготавливаются в ходе настройки процесса проекта; инженер процесса совместно с
руководителем проекта принимают решение относительно типов рекомендаций, которые будут предоставлены группам.
Ниже перечислены основные цели рекомендаций по проекту:
-
Предоставление инструкций и указаний по разработке конкретных рабочих продуктов.
-
Обеспечение согласованной разработки рабочих продуктов и соответствия установленным соглашениям и стилям.
-
Описание стандартов, необходимых для выполнения требований проекта.
-
Назначение сотрудника, контролирующего качество и завершенность рабочих продуктов.
В следующей таблице описаны наиболее распространенные рекомендации для проектов программного обеспечения. В состав RUP
входят примеры рекомендаций, на основе которых можно создать собственные.
|
Тип рекомендации
|
Связанные роли
|
|
Создатели
|
Потребители
|
Рекомендации по бизнес-моделированию
Описаны особенности моделирования вариантов использования бизнес-процесса, участников бизнес-процесса и
бизнес-элементы. Эти рекомендации рассматриваются, если проект предусматривает формальное моделирование
бизнес-процесса для построения новой системы. Степень подробности рекомендаций зависит от объема повторного
проектирования или сложности бизнес-процесса.
|
Аналитик бизнес-процессов
|
Аналитик бизнес-процессов, проектировщик бизнес-процессов, технические проверяющие
|
Рекомендации по моделированию вариантов использования
Варианты использования должны играть важную роль в моделировании поведения системы. В рекомендациях
следует указать соглашения по моделированию, такие как применяемые взаимосвязи, а также стили текстовых
описаний.
|
Аналитик
|
Системный аналитик, ответственный за спецификацию требований, проектировщик
|
|
Рекомендации по проектировке
Создаются на основе определения архитектуры. Рекомендации по проектировке, разработке архитектуры и
реализации.
|
Разработчик архитектуры
|
Проектировщик, конструктор, технические проверяющие
|
|
Рекомендации по программированию
Относятся к конкретным языкам программирования и библиотекам классов. В рекомендациях следует описать
формат исходного кода и комментариев, соглашения об именах и поддержку национальных языков. Кроме того,
должны быть упомянуты меры предосторожности, касающиеся различных функций языков
программирования.
|
Архитектор программного обеспечения (с участием ответственных за реализацию)
|
Ответственные за реализацию, тестеры
|
Рекомендации по пользовательскому интерфейсу
Правила и рекомендации, касающиеся разработки пользовательского интерфейса проекта. Как правило,
рекомендации содержат ссылки на внешние публикации, такие как The Windows Interface Guidelines for Software
Design (Microsoft® Corporation).
|
Проектировщик интерфейса
|
Проектировщик пользовательского интерфейса, проектировщик, ответственный за
реализацию
|
|
Рекомендации по инструментам
Оптимальные методики применения выбранного набора инструментов. Для каждого инструмента можно указать
одну рекомендацию, которая обычно содержит следующую информацию:
-
Сведения об установке, такие как версия, конфигурация, параметры.
-
Ограничения функциональности, а также функции, недоступные в рамках проекта.
-
Действия по обходу неполадок
-
Интеграция с прочими инструментами, в том числе применяемые процедуры, программное
обеспечение и принципы.
|
Специалист по инструментам
|
Специалист по инструментам, тестер, системный администратор, пользователи
инструментов
|
Рекомендации по тестированию
Применяются для отражения изменений (часто тактических) способа тестирования в рамках конкретного проекта,
а также описания эффективных методик, обнаруженных в ходе текущего тестирования. В качестве примеров
рекомендаций по тестированию можно привести критерии завершения тестирования и рекомендации по управлению
дефектами.
|
Разработчик тестов
|
Разработчик тестов, тестер, аналитик тестов
|
Примечание: Решение относительно полного набора рекомендаций не обязательно принимать единовременно. Как правило,
необходимость в рекомендациях и примерах возникает во время подготовки среды к итерации.
|
Подготовка рекомендаций для проекта
|
Цель:
|
Представление рекомендаций участникам проекта.
|
В ходе анализа конечного набора рекомендаций вам потребуется принять одно важное решение о покупке или разработке.
Несмотря на то, что рекомендации можно получить бесплатно, всегда рекомендуется рассматривать стоимость
преобразования этого набора в полезные рекомендации в контексте проекта по сравнению со стоимостью разработки
рекомендации для конкретной цели или даже отказа от этих рекомендаций.
Подразделы:
Инженер процесса, отвечающий за процессы проекта, постоянно ищет рекомендации и примеры, с помощью которых участники
проекта смогут с большей эффективностью разрабатывать высококачественное программное обеспечение. Отдельные
рекомендации можно найти в хранилище ресурсов компании (как правило, они представляют собой компиляцию "методик
организации"). Кроме того, рекомендации можно найти в литературе или в сети Internet (они подпадают под категорию
"общие стандарты").
Изначально большинство рекомендации создается в качестве рабочих продуктов проекта (например, документация по
отдельному незначительному процессу проекта). Затем оценивается их ценность за пределами проекта и ставится вопрос о
возможности повторного применения.
Во время принятия решения относительно создания в проекте новой рекомендации убедитесь, что ей уделяется достаточное
внимание и она рассматривается как внутренний рабочий продукт проекта. Следует выделить ресурсы для ее создания и
проверки и добавить рекомендацию в соответствующие планы итераций.
В первом экземпляре настоятельно рекомендуется разрабатывать рекомендацию для конкретного контекста проекта. Опыт
показывает, что неудачи многих проектов были связаны с приоритетным обобщением рабочих продуктов для последующего
повторного использования вместо разработки с учетом конкретных потребностей. Однако для повышения эффективности
процессов организации при создании рекомендаций следует уделять внимание возможности их применения в последующих
проектах. В случае создания первого экземпляра рекомендаций или других рабочих продуктов работы по их преобразованию в
многоразовые ресурсы можно не включать в бюджет проекта.
Новые рекомендации можно разрабатывать на любом этапе жизненного цикла проекта. В большинстве случае они
разрабатываются по мере необходимости, либо в качестве задач, описывающих эффективные методики создания других рабочих
продуктов.
Рекомендации и примеры должны соответствовать контексту проекта, поскольку в противном случае они не будут
использоваться. Уточнение рекомендаций входит в обязанности инженера процесса и отдельных представителей со стороны
заказчиков. Особое внимание следует уделить уточнению рекомендаций, заимствованных из других проектов, поскольку они
могли разрабатываться в рамках других контекстов.
Рекомендуется вести протокол всех уточнений, поскольку эта информация может облегчить применение рекомендации в
последующих проектах.
Доступность подготовленных рекомендаций имеет не меньшее значение, чем их уточнение. Заинтересованным лицам необходимо
предоставить точную информацию о расположении рекомендаций и примеров, а также контактные данные для отправки отзывов.
Рекомендации можно опубликовать на Web-сайте с помощью технологии модулей RUP, связав их с рабочими продуктами и
задачами. Дополнительная информация приведена в разделе Концепция: Адаптация
RUP.
|
Обслуживание рекомендаций
|
Цель:
|
Повышение эффективности рекомендаций в соответствии с отзывами пользователей.
|
В организациях, направляющих значительную часть усилий на обеспечение повторного использования, критически важное
значение для усовершенствование процесса имеют отзывы по работе с ресурсами проектов. Обратите внимание, что
наиболее эффективные методики разрабатывались в течение продолжительного времени.
В процессе поиска ошибок и возможных улучшений рекомендаций доступны два варианта действий: исправить рекомендацию
или отправить запрос изменения для обработки за пределами проекта. Выбор варианта зависит от формальности процесса
в организации и сложности вопроса. В каждой итерации руководитель проекта может выделить время для проверки и
уточнения рекомендаций. Можно создать конференцию, в которой участники группы смогли бы обмениваться идеями по
улучшению.
|
|
