Задача: Настройка процесса разработки для проекта
Данная задача заключается в адаптации процесса разработки под нужды конкретного проекта.
Дисциплины: Среда
Назначение

Цель этой задачи:

  • Масштабы процесса разработки должны соответствовать потребностям конкретного проекта.
  • Предоставьте членам проектной группы достаточно информации для того, чтобы они могли выполнять свою работу эффективно и с достаточно высоким качеством.
  • Обеспечьте для членов проектной группы удобный доступ к важной информации о проекте.
Взаимосвязи
РолиОсновной исполнитель: Дополнительные исполнители:
ВходыОбязательный:
    Необязательный:
      Выходы
        Использование процесса
        Основное описание

        Следующие задачи посвящены разработке ресурсов методов для конкретных проектов.   Эти задачи выполняются одновременно с шагами данной задачи, относящимися к разработке методов:

        При работе с вариантом разработки  задача Задача: Разработайте прецедент разработки выполняется скоординированно с этой задачей тонкой настройки.

        Шаги
        Проанализируйте проект
        Цель:  Получить представление о задаче, которую требуется решить, и объеме ресурсов, доступных для выполнения проекта.

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

        Определите объем адаптации
        Цель:  Определить, какие области процесса должны быть задействованы в конкретном проекте.

        Результаты анализа ресурсов проекта и опыт разработки аналогичных проектов в прошлом незаменимы при определении объема адаптации. В процесс, применяемый для реализации отдельно взятого проекта, не обязательно должны входить все возможные дисциплины и роли RUP. Помните о том, что RUP - это универсальный процесс, рассчитанный на широкий спектр проектов, и поэтому он слишком масштабен для любого конкретного проекта. Совокупность областей, которые будут применяться в процессе конкретного проекта, сильно зависит от совокупности навыков членов проектной группы и характера выполняемого проекта. Ниже приведены общие рекомендации по определению объема адаптации.

        • Области, в которых члены проектной группы уже сработались, и где не требуется вводить новые процессы и инструменты. Например, если члены проектной группы умеют проводить тестирование, быть может, не стоит вводить дисциплину тестирования RUP, чтобы сократить количество новых факторов. Вместо этого можно сфокусироваться на тех областях RUP, которые позволят устранить недоработки в существующем процессе.  Дополнительные сведения приведены в разделе Концепция: реализация процесса для проекта, пункт Оптимизация процесса и инструментов.  
        • Области (дисциплины), в которых требуется введение нового процесса и новых инструментов, поскольку эти области новые для организации. Иногда возникают ситуации, когда не подходит ни один из известных процессов и инструментов, и приходится вводить большинство компонентов RUP вместе с инструментами поддержки. Дополнительные сведения приведены в разделе Концепция: Реализация процесса в проекте, пункт Изменение всего.  
        • Недоработки в существующем процессе. Сконцентрируйтесь на улучшении областей, в которых у организации возникали сложности.
        • Какими инструментами пользоваться? Если проект рассчитан на определенные инструменты, процесс разработки обычно охватывает соответствующие области RUP.
        • Способность проекта изменяться. Довольно часто люди пытаются "починить" все сразу, особенно если одновременно возникает много сложностей. Как правило, это гибельный путь. Организации подобны людям в том отношении, что они могут осваивать только ограниченный объем изменений за ограниченное время. Если способность к изменению низка, имеет смысл сбавить темп и ввести только одну или две дисциплины RUP в первом проекте.
        • Области, в которых у членов проектной группы недостаточно квалификации или подготовки. Процесс разработки обязательно должен охватывать такие области. Убедитесь в том, что сотрудникам будет легко найти нужную информацию в RUP.

        Дополнительные сведения об определении рамок адаптации приведены в разделе Рекомендация: Тонкая настройка RUP

        Описание факторов, влияющих на настройку процесса для проекта, можно найти в разделе Рекомендации: Дискриминанты процесса.

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

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

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

        Разработайте специализированные компоненты процесса для проекта
        Цель:  Создать дополнительное "ноу-хау" в областях, где RUP в недостаточной степени охватывает потребности проекта.

        Методология RUP сформулирована в виде модели процесса, описанной в терминах метамодели UML. Методология RUP основана на метамодели UMA (Унифицированная архитектура методов). Основы UMA изложены в разделе  Концепция: Основные возможности Унифицированной архитектуры методов (UMA)

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

        В любом процессе, адаптированном под нужды конкретного проекта, должен быть набор адаптированных ресурсов, упрощающих создание артефактов проекта. Примерами таких ресурсов могут служить:

        • Общие рекомендации по созданию конкретных артефактов.
        • Шаблоны, оптимизированные для применения в конкретных проектах. Эти шаблоны будут частично заполнены информацией о проекте.
        • Примеры артефактов для конечных продуктов проекта и выбранной технологии.
        • Многоразовые ресурсы, например шаблоны проекта и библиотеки кода.

        В начале проекта руководитель проекта вместе с разработчиком процессов выбирает набор ресурсов и делает их доступными членам проектной группы в рамках процесса для конкретного проекта. Потребность в дополнительных ресурсах исследуется в начале каждой итерации.

        Настройте процесс
        Цель:  Привести масштабы процесса в соответствие с потребностями проекта.

        Для настройки процесса нужно выбрать наполнение методов (рабочие продукты, задачи, роли и т.п.), которые будут входить в процесс.  Рекомендации по выбору элементов методов для различных дисциплин приведены в разделе "важные решения <имя дисциплины>", которым сопровождаются все дисциплины RUP.  Выбор правильного наполнения методов для конкретного проекта - непростая задача. Для того чтобы процесс был эффективным, он должен быть сбалансированным, а его масштабы должны соответствовать размеру проекта (по объему ресурсов и продолжительности проекта), степени формальности, технологической платформе, предметной области и многим другим факторам.

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

        Создайте модель жизненного цикла для проекта
        Цель:  Создать модель жизненного цикла для проекта.  

        Важный компонент процедуры адаптации процесса для проекта заключается в выборе модели жизненного цикла, включая распределение жизненного цикла на этапы и итерации. На этом этапе от разработчика процессов требуется тесное взаимодействие с руководителем проекта, поскольку выбранная модель жизненного цикла закладывает базу для процесса планирования проекта. Некоторые проекты могут нуждаться в коррекции жизненного цикла RUP под их нужды. Например, при разработке продукта с чистого листа начальный этап требует больших усилий, чем при обслуживании готового продукта. Поэтому описание жизненного цикла должно соответствовать характеру проекта. Описание различных моделей жизненного цикла можно найти в разделе Концепция: Итерации.

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

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

        Сделайте процесс доступным членам проектной группы
        Цель:  Сделать процесс, адаптированный для конкретного проекта, доступным членам проектной группы

        После начальной адаптации нужно сделать процесс доступным в удобном формате членам проектной группы.

        Например, можно опубликовать процесс на сайте  или во внутренней сети организации, либо установить его на компьютерах всех членов проектной группы.  Если члены проектной группы почти всегда работают в сети, рекомендуется опубликовать процесс на Web-сервере, чтобы в дальнейшем обновление информации о процессе требовало минимума усилий.

        Поддерживайте процесс

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

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

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

        • Создайте процесс
        • Выполните работу в соответствии с процессом
        • Оцените результаты работы
        • Оптимизируйте процесс


        Иллюстрации
        Ключевые условия

        Независимо от масштабов адаптации, очень важно  сохранить информацию о результатах (и, вероятно, причинах)   ее проведения.   Кроме того, если адаптируемый процесс нужно будет адаптировать повторно  (например, если процесс сначала адаптируется для организации в целом, а затем будет дополнительно адаптироваться для каждого отдельно взятого проекта),  также важно разработать рекомендации по адаптации адаптированного процесса разработки. Решения и рекомендации по адаптации процесса можно сохранить в отдельном документе или сделать неотъемлемым компонентом процесса разработки.   Дополнительные сведения об уровнях адаптации приведены в разделе Концепция: Тонкая настройка RUP.

        План разработки программного обеспечения и организация разработки оказывают огромное влияние на процесс адаптации, и наоборот. Адаптация процесса должна проводиться скоординированно с разработкой плана проекта. Например, если набор этапов проекта будет отличаться от стандартного набора этапов RUP, эта особенность должна быть отражена в адаптированном процессе разработки.  Кроме того, после адаптации процесса разработки нужно создать на его основе практический план проекта. Дополнительные сведения о планировании процесса приведены в разделах Задача: Этапы и итерации плана и Задача: Разработка плана итерации.


        Не рекомендуется адаптировать сразу весь процесс.   Гораздо удобнее в каждый момент времени концентрироваться на каждой очередной дисциплине, которая будет задействована в проекте.   Дополнительные сведения об итерационном подходе к реализации процесса приведены в разделе Концепция: Реализация процесса в проекте.  

        Оценка организации, проводящей разработку позволяет установить, какие области организации, осуществляющей разработку программного обеспечения, требуют особого внимания. Необходимо принять продуманное решение о том, каким областям оптимизации будет уделяться внимание в рамках данного проекта. От этого решения напрямую зависит объем адаптации.

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

        Вариант разработки может применяться для  документирования решений, относящихся к адаптации (например, какие компоненты RUP было решено адаптировать, и почему), а также рекомендаций по дальнейшей адаптации.  В зависимости от масштабов адаптации, вариант разработки можно либо включить в процесс разработки,  либо воспользоваться им для планирования, осуществления и документирования собственно адаптации. Дополнительные сведения об уровнях адаптации приведены в разделе  Концепция: Тонкая настройка RUP.

        Альтернативы
        В RUP предусмотрено много уровней адаптации.   Дополнительные сведения приведены в разделе Концепция: Адаптация RUP.
        Дополнительные сведения
        Концепции
        Рекомендации
        Руководства по инструментам