Форма входа

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

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

Поиск

Наш опрос

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

Друзья сайта

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


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

    Я - Аналитик!

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

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

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

    Еще раз о прецедентах

    Как я уже писал в предисловии к первому выпуску, я не составлял заранее плана статей. Темы для статей я нахожу на форуме UML2, где люди, работающие аналитиками, обсуждают свои профессиональные проблемы. Иногда я высказываю свое мнение непосредственно на форуме. Но, когда обсуждаются сложные явления, "форумный стиль" не позволяет выразить мнение достаточно аргументировано и полно.

    Тема прецедентов (вариантов использования, юзкесов) всплывает перманентно. Наиболее часто обсуждаемые вопросы:

    • Как правильно рисовать диаграмму прецедентов для проекта
    • Как правильно описывать прецедент

    Мое мнение по этим вопросам я постараюсь изложить в двух последовательных выпусках:

    • Эта (первая) часть статьи о прецедентах будет посвящена модели прецедентов в целом: структура модели, какие диаграммы я рисую и какие отчеты генерирую
    • Вторая часть (она почти написана) посвящена способу описания прецедента

    Откуда берутся прецеденты?

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

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

    Я не буду описывать эти приемы. Давайте лучше рассмотрим пример.

    В процессе интервьюирования заинтересованных лиц проекта "Система управления оказанием услуг" и изучения документов бизнеса параллельно разрабатывались документ "Видение" (см. предыдущую статью и приложения к ней) и модель бизнес-процесса (см. второй выпуск цикла и приложение).

    Каждое требование возможности из документа "Видение" должно детализироваться, по крайней мере, одним прецедентом[1].

    Модель бизнес-процесса дает существенно больше информации для идентификации прецедентов.

    Ниже представлена диаграмма деятельности бизнес-процесса "Оказание услуги".[2]


     

    (нажать для увеличения)

    Я использую модель бизнес-процесса следующим образом[3]:

    • Каждый бизнес-субъект и каждый бизнес-работник рассматривается как кандидат в системные субъекты. Если этот участник процесса будет пользователем разрабатываемой системы, он из кандидата становится системным субъектом
    • Каждое действие диаграммы деятельности, которое будет автоматизировано в разрабатываемой системе, рассматривается как кандидат в системные прецеденты
    • Класс, представляющий раздел на диаграмме деятельности, идентифицируется как первичный субъект[4] для всех прецедентов, образованных из действий, принадлежащих этому разделу.

    Рассмотрите следующую диаграмму прецедентов[5]. На ней представлены прецеденты, поддерживающие бизнес-процесс "Оказание услуги":

     

    (нажать для увеличения)

    Каждому автоматизируемому действию из бизнес-модели соответствует системный прецедент, имеющий то же название, что и действие. Исключение составляет действие исполнителя "Выполнение работы". Почему?

    Формально, бизнес-моделирование и моделирование прецедентов выполняют разные роли, а значит – могут выполнять разные люди.

    Бизнес-аналитик описывает полный бизнес. Он не должен разделять действия на выполняемые "вручную" ("в голове") или с использованием компьютера. В данном случае, бизнес-аналитик идентифицировал действия исполнителя как "Выполнение работы", и сделал описание:

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

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

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

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

    По завершении работ по наряду исполнитель передает продукты работы (пакет документов) и свою копию наряда руководителю для проверки.

    Если по заявке выполняются субподрядные работы, исполнитель контролирует количество и качество выполненных работ. (Работа по контролю субподрядных работ должна быть включена в наряд исполнителя.)

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

    Системный аналитик идентифицировал два прецедента с описаниями:

    ·        Прецедент "Заполнение основного наряда"

    Редактирование информации основного наряда в соответствии с выполненным объемом работ:

    - исключение из списка работ тех работ, которые исполнитель не выполнял или не будет выполнять

    - указание фактически выполненного объема работ и фактических затрат

    При первом открытии исполнителем наряд переходит в состояние "В работе".

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

    По завершении работ наряд передается на проверку. Наряд переходит в состояние "На проверке".

    ·        Прецедент "Заполнение дополнительного наряда"

    Создание и заполнение наряда на работы, не указанные в основном наряде, необходимость которых была выяснена в процессе выполнения основного наряда.

    После создания дополнительный наряд переходит в состояние "В работе".

    По завершении работ наряд передается на проверку. Наряд переходит в состояние "На проверке".

    Если обратиться к приведенным выше рекомендациям, налицо их нарушение: модель прецедентов не соответствует бизнес-модели. Как поступить?

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

    Еще одно, важное, на мой взгляд, замечание.

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

    Диаграммы становятся нечитабельными.

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

    Абстрактные прецеденты многоразового использования (включения) я помещаю в отдельный пакет "Абстрактные прецеденты".

    Иногда (редко) я создаю в корне модели прецедентов диаграмму "Главные прецеденты". Диаграмма имеет чисто демонстрационные цели.

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

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

    Я не помещаю эти прецеденты на диаграмму прецедентов функциональной области, чтобы не перегружать ее. Зато для каждого прецедента я создаю диаграмму "Контекст прецедента <Название>".

    Но об этом в следующей статье.

    Не забудьте скачать приложения!



    [1] Прецедент может поддерживать реализацию нескольких требований возможностей.

    [2] Те, кто знакомился с приложением ко второму выпуску, уже видели эту диаграмму и читали ее детальное описание в документе bps__Оказание услугиRpt.doc, на который ссылается бизнес-модель.

    [3] Нижеследующие рекомендации формально описаны в документе и реализованы в разработанном мной шаблоне преобразования бизнес-модели в модель прецедентов.

    [4] Напоминаю: С прецедентом могут взаимодействовать множество субъектов. Первичным является тот субъект, цель которого выполняет прецедент. Ассоциации прецедента с этим субъектом назначается ключевое слов "primary". Хорошая практика состоит в том, чтобы идентифицировать субъектов таким образом, чтобы каждый прецедент мог иметь только одного первичного субъекта.

    [5] Диаграмму в контексте можно увидеть в веб-публикации модели в приложении к этой статье.

    Категория: Повышение производительности аналитика | Добавил: lnew (19.08.2011)
    Просмотров: 5341 | Комментарии: 7 | Рейтинг: 0.0/0
    Всего комментариев: 3
    1 EdwardG  
    0
    Замечательная статья.

    Однако есть вопрос. Задача первой части статьи ответить на вопрос:
    "Как правильно рисовать диаграмму прецедентов для проекта?+
    Эта (первая) часть статьи о прецедентах будет посвящена модели прецедентов в целом: структура модели, какие диаграммы я рисую и какие отчеты генерирую"

    Мне кажется, Вы не до конца ответили на этот вопрос. Вы показали один из способов идентификации актеров и прецендентов. Показали, что во многих случаях UC=бизнес-деятельности, но не всегда, и объяснили почему. Но вот точно выраженных правил рисования диаграмм к сожалению нет. Есть, конечно, список рекомендаций:
    1. не отображать на одной диаграмме все известные прецеденты системы, со всеми включениями и расширениями
    2. разбивать все множество прецедентов на функциональные области, каждая из которых содержит прецеденты, поддерживающие один бизнес-процесс
    3. Абстрактные прецеденты многоразового использования (включения) помещать в отдельный пакет "Абстрактные прецеденты"
    4. Иногда (редко) создавать в корне модели прецедентов диаграмму "Главные прецеденты"
    5. для каждого прецедента создавать диаграмму "Контекст прецедента <Название>"

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

    Спасибо

    2 lnew  
    0
    Спасибо.
    Вы, конечно правы. Я пишу, как мне кажется, всем (специалистам) известные вещи.
    И пишу только потому, что для выполнения некоторых известных вещей я использую наработанные практикой приемы. Я о них и рассказываю.
    Если меня нанимают на проект внедрения, я работаю сначала как нормальный учитель (в зависимости от аудитории), попутно изучаю "местные" технологии и проблемы, затем участвую (в качестве наставника) в реальном проекте, в ходе которого параллельно разрабатываются документы стандартного (для организации) процесса.
    Примеры некоторых из них (представленные в приложениях) Вы видели: "Указания...", строительные блоки, шаблоны.
    Может быть, я не прав, но в этом цикле я не пытаюсь написать свой маленький плохой учебник. Их и так слишком много (особенно плохих).

    3 EdwardG  
    0
    Благодарю за ответ

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