Форма входа

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

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

Поиск

Наш опрос

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

Друзья сайта

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


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

    Я - Аналитик!

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

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

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

    Продукты работы аналитика

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

     

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

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

    На мой взгляд, это единственный документ, который должен быть утвержден на высшем уровне руководством заказчика и исполнителя. Грамотно составленный документ позволяет избежать множества проблем во взаимоотношениях между участниками проекта[2].

    • Видение

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

    Явно определяются заинтересованные лица и указываются их обязанности по отношению к проекту. Эффективное средство "управления" "неадекватными" заинтересованными лицами[3].

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

    • Модель прецедентов

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

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

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

    Известный гуру в области определения требований к системам Алистер Коберн обиделся на диаграммы прецедентов[4] за их нецелевое использование начинающими аналитиками и "выплеснул вместе с водой ребенка": моделирование на UML вообще.

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

    • Дополнительные спецификации

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

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

    • Спецификация требований к программному обеспечению

    В RUP это документ, который содержит все требования к системе, функциональные и нефункциональные.

    Собственно, разработчикам такой документ не нужен. Но некоторые заказчики требуют "ТЗ по ГОСТу". Никакой новой информации, по сравнению с перечисленными выше продуктами работы, этот документ  содержать не может. Если это так, то он, как и другие документы, может быть сгенерирован из моделей.

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

    Должен признаться, я никогда не пытался создать шаблон отчета для "ТЗ по ГОСТу". Но проблем здесь я не вижу!

    А должен ли аналитик моделировать бизнес[5]?

    Должен только в одном случае: если бизнес-модель должна быть включена в комплект поставки (мы говорим о бизнес-моделировании для определения требований к системе).

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

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

    Когда аналитик беседует с заинтересованными лицами, то даже самые "заинтересованные" из них часто забывают такие тонкости, как события в других частях бизнеса или изменения рабочего потока по условию. Это естественно: они об этом просто не задумываются, считают естественным, и думают, что компьютер поступит также. Увы!

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

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

    Бизнес-моделирование в RUP

    Бизнес-моделирование в RUP определяется через цели:

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

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

    Примечание: В бизнес-моделировании на основе RUP может подразумеваться, но явно не описывается компьютерная поддержка бизнес-процессов.

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

    Упрощенное моделирование существующего бизнеса

    Бизнес-моделирование в RUP следует принципам объектно-ориентированного подхода к моделированию бизнеса. И в задачах проектирования нового или реинженеринга существующего бизнеса этот подход имеет неоспоримые преимущества. Но в проектах разработки ПО для существующего бизнеса в разделении модели на "внешнюю" и "внутреннюю" нет необходимости. А почти удвоенные трудозатраты – слишком высокая цена за строгое следование принципам при равноценных результатах.

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

    Документ "Указания по бизнес-моделированию", который я рекомендую использовать для проектов ПО небольшого и среднего размера, можно скачать по адресу: Повышение производительности аналитика 02, Приложение

    Пример бизнес-моделирования[7]

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

    Пример, на мой взгляд, хорош тем, что, с одной стороны его предметная область – управление оказанием услуг, – достаточно общая, и модель, после адаптации, может быть применена на практике. С другой стороны, тема эта "не избита" в многочисленных примерах моделирования[8].

    Некоторые соображения:

    • Что такое бизнес-процесс?

    UML родился больше 15 лет назад, но до сих пор в многочисленных аудиториях многочисленные аналитики спорят, что есть прецедент (use case, вариант использования и т.д.), а что нет. В бизнес-моделировании ситуация та же. Но, т.к. бизнес-моделирование на UML распространено меньше, и споров меньше.

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

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

    Множество организаций выполняют один единственный основной бизнес-процесс[9]. В примере моделирования это бизнес-процесс "Оказание услуги".

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

    • Степень детализации бизнес-модели

    Я высказывал эту мысль выше: "Бизнес-модель нужна, прежде всего, аналитику как систематизированная информация для определения требований к системе".

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

    Излишняя детализация смысла не имеет.

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

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

    Скачивайте и смотрите веб-публикацию модели с помощью вашего браузера или модель непосредственно в RSA. И помните, что модель UML – это не только картинки.

     



    [1] Многие критики RUPа обращают внимание на большое количество ролей: "У нас и людей-то столько нет!"
    Я считаю большое количество ролей с непересекающимися обязанностями одним из преимуществ RUPа. Ведь роль – это не человек, и даже не должность. Человек, исполняющий роль, должен обладать определенным набором навыков. Универсалов, которые все могут делать одинаково хорошо, не так много. Поэтому, большое количество ролей позволяет руководителю оперативно управлять человеческими ресурсами при распределении работ, имея в голове или перед глазами матрицу "сотрудник – роль" с "галочкой" или даже цифрой, характеризующей оценку навыков, на пересечении столбца и строки.

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

    [4] Вообще-то всем нам крупно повезло, что это случилось. Иначе, он мог бы и не написать свою замечательную книгу "Современные методы описания функциональных требований к системам"!

    [5] Специалисты по-разному определяют термин "бизнес-моделирование". В этой статье используется определение и метод RUP, упрощенный для моделирования существующего бизнеса с целью поддержки определения требований к ПО.

    [6] В представленный пример бизнес-моделирования включен отчет SoDA "Спецификация бизнес-процесса …". Хотя документ в целом "обезличен", я сохранил лист изменений из оригинала. История такова: первая версия модели была разработана на основе беседы с заказчиком. Представленная версия – исправленная по результатам обсуждения первой. После нового обсуждения можно быть уверенным в "правильности" модели.

    [7] Материалы примера можно скачать в формате .rar на странице "Каталог файлов" по адресу:

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

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

    [8] Материалы этого проекта предполагается использовать в качестве примеров и в других статьях цикла.

    [9] Наиболее распространенная классификация бизнес-процессов – это "Основной бизнес", "Поддержка бизнеса" и "Управление бизнесом".

    Категория: Повышение производительности аналитика | Добавил: lnew (25.07.2011)
    Просмотров: 2070 | Комментарии: 8 | Рейтинг: 0.0/0
    Всего комментариев: 8
    5 EdwardG  
    Насколько я знаю и считаю UML, как UML появился максимум 15 лет назад. Составные его части, из которых он вырос, появились естественно куда раньше.

    6 lnew  
    Официальная версия 0.9 была издана в 1996 году.
    Книжки и инструменты появились в 95.
    Я где-то допустил неточность? Подскажите, пожалуйста! cry

    7 EdwardG  
    "UML родился больше 20 лет назад ..." далее Ваш ответ на мой комментарий.
    2011 - 1995 = 16 лет, но не как более 20 лет

    8 lnew  
    Спасибо.

    3 Павел  
    Леонид Борисович, возникли многочисленные вопросы по поводу документа "План управления требованиями": его назначение, структура, внешний вид. Очень бы хотелось увидеть "живой" пример. Спасибо!

    4 lnew  
    Обсуждение "Плана управления требованиями" (RUP) несколько отвлекает от главной темы (моделирование и документирование).
    Но, в качестве приза за отклик, я сделаю это в следующей статье выпуска.
    Спасибо.

    1 PavelZh  
    В chrome, ie9 у меня данная статья (с первой было всё ок) отображается с горизонтальной прокруткой. Не удается сделать так, чтобы весь текст был на экране.

    2 lnew  
    Спасибо. Исправил. Протестировал в IE/

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