Форма входа

Категории раздела

Повышение производительности аналитика [7]

Поиск

Наш опрос

Интересны ли Вам статьи цикла "Повышение производительности аналитика"?
Всего ответов: 25

Друзья сайта

  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Статистика


    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Понедельник, 10.12.2018, 22:47
    Приветствую Вас Гость
    Главная | Регистрация | Вход | RSS

    Я - Аналитик!

    Каталог статей

    Главная » Статьи » Опыт моделирования на UML » Повышение производительности аналитика

    Повышение производительности аналитика 03

    План управления требованиями

    Пожалуйста, посмотрите еще раз на рисунок, показывающий набор продуктов дисциплины "Требования" RUP.

     

    Большинство естественных и искусственных языков, в том числе графических, используют следующее правило чтения: "Слева направо, сверху вниз". Полагаю, что местоположение иконки "План управления требованиями" на рисунке выше явно указывает на то, какое значение придают этому документу авторы RUP.

    Управление требованиями в RUP

    "Управление требованиями – это систематический подход к обнаружению, документированию, организации и сопровождению изменяющихся требований к системе".

    Это формальное определение подразумевает наличие двух видов деятельности в рамках управления требованиями:

    • Определение, организация и документирование требований
    • Установление и выполнение правил управления изменением требований

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

    И вряд ли кто-нибудь будет возражать, что этот продукт совместной деятельности (требования к системе) изменяется в ходе выполнения проекта.

    Совместная деятельность требует управления; иначе – хаос. Правила этой деятельности должны быть согласованы (а лучше – утверждены) заказчиком и исполнителем на самом высоком уровне.

    План управления требованиями в RUP

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

    RUP содержит описание рабочего продукта "План управления требованиями", шаги создания этого рабочего продукта, советы и шаблон документа MS Word[1].

    RUP – это не стандарт, а рекомендации на основе обобщения опыта выполнения проектов. То же относится к шаблонам. Ниже описаны два примера документов, разработанных на основе базового шаблона для реальных проектов. По понятным причинам эти примеры обезличены.

    Пример 1. Заказной проект

    Контекст

    История проекта:

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

    По решению Губернатора СПб упомянутые подразделения были выведены из подчинения райадминистраций и переподчинены вновь созданному Главному управлению. Ознакомившись с ситуацией в сфере ИТ, руководство нового управления приняло решение о создании единой системы управления на базе наиболее удачного "районного" решения. Как, наверное, догадались читатели, за основу была выбрана система, о которой говорилось выше

    Ошибка руководства компании-исполнителя состояла в том, что анализ ситуации, согласование технических требований и подготовка договора были поручены специалистам продаж (без участия технических специалистов). Технические специалисты были привлечены для выполнения готового договора и утвержденных технических требований и графика поставок! Я был приглашен в проект в качестве системного аналитика.

    Заинтересованные стороны:

    • Заказчик

    Государственное учреждение. Заинтересовано в скорейшем появлении системы для управления районными филиалами при выполнении последними платных услуг населению. Финансовый спонсор проекта. Потенциальный пользователь части системы.

    • Пользователь

    Районный филиал – заказчик и пользователь предыдущей версии системы. Этот филиал был избран заказчиком в качестве полигона для тестирования и приемки новой системы. Заинтересован в пошаговой поставке системы и непрерывности поддержки бизнеса при переходе на новую версию.

    • Исполнитель

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

    Проблемы

    1. Технические требования были сформулированы на очень высоком уровне, соответствующем, по мнению исполнителя, задаче доработки существующей системы.
      Фактически, требовалось разработать новую систему, повторяющую функциональность старой, но имеющую совершенно другую архитектуру развертывания
      У
      твержденный календарный план не предусматривал разработки требований к системе.
    2. Календарный план поставок сформулирован на очень высоком уровне в терминах "водопадной" разработки, не обеспечивающей возможности пошаговой поставки.
    3. Не сохранилось никакой технической документации по предыдущей версии системы, ее разработчики уволились. Для разработки проекта была набрана временная команда
    4. Договорная документация была утверждена очень высоким руководством и, реально, не могла быть изменена.

    Решение

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

    Были приняты следующие решения:

    1. Использовать итерационный инкрементный цикл разработки
    2. Детализировать календарный план, сохранив названия и сроки этапов.
    3. Считать документ RUP "Видение" отчетным документом этапа "Эскизное проектирование", соответствующим образом изменив его название.
    4. Разработать модель прецедентов и модель анализа системы. Для каждого прецедента выпустить спецификацию, которая будет включать описание прецедента (требования) и описание реализации прецедента (анализ). Каждую спецификацию идентифицировать как приложение к документу "Эскизное проектирование. Общий отчет".
    5. Разработать и утвердить на уровне руководства заказчика, пользователя и исполнителя документ "План управления требованиями", правила которого обязательны для всех участников проекта.

    Пример 2. Внутренний проект

    Контекст

    Документ разрабатывался в рамках внутреннего проекта "Стандартный процесс разработки ПО" в департаменте разработки ИТ крупного банка[2].

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

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

    Продолжительность проекта – 8 месяцев. В этом проекте я выполнял роль наставника проекта[3].

    Проблема и решение

    Главная проблема – большое число связанных проектов и большое число участников. Ее следствием является сложность управления связанными требованиями и решениями многоразового использования.

    Для разрешения этой проблемы в регламенте:

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

    Инструменты управления требованиями

    Скорее всего, ни один из примеров плана управления требованиями не подойдет Вам, если Вы не используете инструмент для управления требованиями[4].

    На мой взгляд, хороший инструмент управления требованиями должен позволять:

    1. Создавать требования вручную или из модельных элементов и сохранять их в хранилище требований
    2. Определять типы требований с наборами атрибутов для управления требованиями
    3. Устанавливать иерархии требований одинакового типа
    4. Устанавливать трассируемости между требованиями одного или различных типов, в том числе между требованиями к различным проектам
    5. Идентифицировать требования, которые могут потребовать изменения вследствие изменения связанных (трассированных) требований
    6. Синхронизировать требования и описания связанных модельных элементов
    7. Сохранять историю изменения требований
    8. Генерировать рабочие и презентационные отчеты в требуемой форме

    Я использую IBM Rational RequisitePro, который допускает все эти возможности.



    [1] Шаблон документа на русском языке можно скачать с приложением к этой статье:
    Повышение производительности аналитика 03

    [2] Обратите внимание, что слово "план" в названии документа изменено на "регламент". Документ не требуется согласовывать с заказчиками, он утверждается руководством банка. В конкретном проекте как дополнение к регламенту может создаваться план, в основном, для персонификации участников.

    [3] В RUP консультант и наставник – это разные роли.

    • Консультант отвечает на конкретные вопросы и предлагает решения поставленных проблем. Он не является членом проектной команды и не несет ответственности за результаты своего консультирования.
    • Наставник – это член проектной команды, опытный эксперт широкого профиля. Стиль работы наставника: "Делай, как я!" Он проводит обучение, разрабатывает начальные версии документов, ищет проблемы и предлагает способы их разрешения. Иногда наставник обладает административными правами, делегированными ему руководителем проекта.

    [4] Может быть, только, если проект очень маленький, и требования можно пересчитать на пальцах.

    Категория: Повышение производительности аналитика | Добавил: lnew (30.07.2011)
    Просмотров: 2622 | Комментарии: 3 | Рейтинг: 0.0/0
    Всего комментариев: 3
    2 DimaV205  
    По ссылке [1] пишет, что страницы не существует sad

    0
    3 lnew  
    Извините! Я проверю, в чем дело.
    Чтобы посмотреть (скачать), переместитесь в раздел Каталог файлов и выберите название статьи, приложение к которой вы хотите увидеть.
    Спасибо!

    1 lnew  
    Простите, это кто? И за что?
    Л. Новиков

    Имя *:
    Email *:
    Код *: