Загрузил boss.wot59

Лабораторна 1 Landscape Map

Реклама
Лабораторная работа № 1
Инструментальные средства управления функциональными требованиями
ЧАСТЬ 1
Статья. «Функциональные карты и диаграммы вариантов использования» [1]
Несколько слов о техниках работы бизнес-аналитика.
Уже пару десятков лет основной техникой моделирования функционала
информационных систем является разработка вариантов использования (use cases). Техника,
действительно, неплохая. Особенно если бизнес-аналитик прочитал книжку Алистера
Коберна «Современные методы моделирования функциональных требований» или посетил
учебный курс по разработке юзкейсов. Однако визуализация вариантов использования в виде
соответствующей UML диаграммы (рис.1) до сих пор вызывает сдержанную ухмылку у
разработчиков и легкое недоумение у функциональных заказчиков.
В настоящее время на уровне бизнес-архитектуры никто никаких юзкейсов не рисует.
Для отображения деятельности организации используется Business Capability Map – техника,
позволяющая отобразить все виды деятельности предприятия на одной картинке. Довольно
часто звучит и другой термин: функциональная карта. Что это такое и как использовать эту
карту в проектах изложено ниже в виде небольшой истории о вымышленном проекте
разработки системы управления инцидентами, рассказанной от лица ведущего бизнесаналитика этого проекта.
ПРИМЕР.
Вымышленный проект разработки системы управления инцидентами, рассказанной
от лица ведущего бизнес-аналитика этого проекта.
Как-то утром, когда завтрак уже давно кончился, а обед еще не думал начинаться, в
нашу комнату влетел руководитель службы бизнес-анализа. Сбивая на своем пути
зазевавшихся молоденьких сотрудниц и отчаянно жестикулируя, он подлетел к моему
рабочему столу и срывающимся голосом заорал: «Когда?… Почему! Где?! Где
функциональные требования?». Я тяжело вздохнул, пытаясь догадаться, о чем собственно
идет речь. Даже пару раз попытался перебить его, чтоб задать этот вопрос, но потом решил
дать руководителю немного остыть. Минут через десять руководитель службы немного
успокоился и сумел объяснить, что речь идет о системе управления инцидентами. Только что
он был на планерке у Директора по ИТ, который устроил всем грандиозный разнос за
отсутствие в нашей организации этой замечательной системы. Департамент эксплуатации ИТсистем, являющийся основным заказчиком такой системы, и Служба разработки ИТ-решений
перевели все стрелки на нас, заявив, что система управления инцидентами уже пару лет
остается абстрактной мечтой, потому что служба бизнес-анализа так и не удосужилась собрать
требования. Резонное возражение, что с такой задачей к нам никто не обращался,
естественно, не возымело действия, и уже через полчаса мы сидели в кабинете руководителя
департамента эксплуатации и выслушивали его рассказ о космических кораблях, бороздящих
просторы…
Из этого разговора я вынес совсем немного. Оказывается, наша служба поддержки
разделена на два уровня. На первом уровне работают начинающие специалисты, не способные
решить большинство поступающих проблем. Какие-то инциденты они решают, но их
1
основное занятие заключается в направлении запросов на ту или иную группу сотрудников
второго уровня. И вообще самое главное, чтоб пользователи самостоятельно подтверждали
закрытие инцидентов, потому что с ними подписан соответствующий SLA. Набросав в visio
простенькую UML диаграмму, остаток дня я посвятил строительству веселой фермы.
Без пяти девять утра следующего дня я уже стоял с красиво распечатанным рисунком у
кабинета руководителя департамента эксплуатации.
– Что это у тебя? – поинтересовался руководитель департамента, выходя из своего
кабинета.
– UML- диаграмма вариантов использования – отрапортовал я без малейшей запинки,
протягивая ему картинку.
Рис. 1 UML-диаграмма вариантов использования (use case).
Он нацепил очки, взял мой рисунок и на несколько секунд опустил на него взгляд.
Когда руководитель службы эксплуатации вновь поднял голову, я по косвенным признакам
сообразил, что картинка ему понравилась как-то не очень. Наверное, такое же выражение
лица, сочетающее сдерживаемый гнев и полную безнадежность, бывает у него от известия о
случившейся проблеме минус первого приоритета.
– Пойдем! – сдерживая гнев прошипел он и, размахивая картинкой, потащил меня в
кабинет директора по ИТ.
Директор, как назло, оказался в своем кабинете. Вместе с ним за столом сидели еще
двое и о чем-то оживленно беседовали. Одного из участников обсуждения я знал. Он работал
у нас в проектном офисе. Другой же человек, в строгом деловом костюме, был мне незнаком.
Прервав обсуждение, ни с кем не поздоровавшись, руководитель департамента
эксплуатации подошел к директору и, пробурчав: «Как Вы думаете, что это?», сунул ему мой
рисунок. Взглянув на рисунок, директор улыбнулся и добродушно ответил: «Пляшущие
человечки, я полагаю». Он небрежно передал мой рисунок другим собеседникам, которые тут
же принялись его заинтересованно разглядывать, а сам обратился к руководителю
департамента эксплуатации:
2
– Очень хорошо, что ты зашел. Присаживайся. Я решил оформить эти работы
отдельным проектом, и мы как раз обсуждаем систему управления инцидентами с будущим
менеджером проекта и внешним консультантом. Вот и еще один участник команды к нам
присоединился – отметил ИТ директор, бросив на меня недолгий, но пристальный взгляд, от
которого мне стало как-то не по себе. Я и руководитель службы эксплуатации сели за стол.
– Мы не будем больше рисовать такие картинки – безапелляционно заявил человек в
строгом деловом костюме, идентифицированный мною, как внешний консультант. Он достал
из своей папки другой рисунок и протянул его руководителю департамента эксплуатации. —
Это функциональная карта типового решения по управлению инцидентами. Отметьте
галочкой те функции, которые необходимы Вам в первую очередь.
Руководитель департамента эксплуатации достал авторучку и принялся
последовательно расставлять галки в каждом прямоугольнике, стараясь ничего не пропустить.
Некоторые он даже обвел кругом, а затем, вероятно, для пущей убедительности нарисовал
несколько стрелок и положил рисунок (рис.2) в центр стола, чтоб его могли видеть все
участники встречи.
Рис. 2 Нулевой вариант функциональной карты (Landscape Map)
типового решения по управлению инцидентами
– Отлично! – резюмировал консультант и передвинул листок менеджеру проекта. – Вот
наш scope. По этой карте мы будем отслеживать прогресс на всех фазах проекта, начиная с
уточнения требований и вплоть до ввода системы в эксплуатацию. Впрочем, и после запуска
системы функциональная карта нам еще пригодится.
Не понимая до конца, что следует делать с этим рисунком, но услышав слово
«требования» и проассоциировав их с бизнес-анализом, проектный менеджер передал рисунок
мне. На этом встреча закончилась. Я взял рисунок и вместе с участниками встречи покинул
кабинет директора. В приемной консультант остановил меня и сунул мне еще один рисунок
(рис. 3):
3
Рис. 3 Первый вариант Landscape Map
– Смотрите! – дружелюбно проговорил консультант – На следующей встрече нам надо
будет определить действующих лиц решения и сопоставить их с функциональной картой. Это
похоже на Вашу диаграмму, только без тощих человечков и эллипсов. Возьмите за основу
этот рисунок.
Вернувшись на свое рабочее место, абсолютно счастливый тем, что все так удачно
сложилось, я быстро отсканировал картинку и отправил её проектному менеджеру в качестве
сопроводительных материалов для следующей встречи, намереваясь посвятить остаток
рабочего дня обустройству веселой фермы. Однако после обеда раздался звонок. Менеджер
проекта управления инцидентами ехидно поинтересовался, как у меня дела, и спросил, не
желаю ли я вместе с ним поработать над границами проекта. Пришлось тащиться к нему и
выслушивать утомительные рассуждения о том, что запуститься следует всего через шесть
недель, и если не удастся сузить рамки проекта, то митигировать риски срыва сроков будет
решительно невозможно. В общем, он потребовал, чтоб к завтрашней встрече с
разработчиками я указал на функциональной карте стадии проекта и приоритеты требований.
К счастью, в нашей службе бизнес-анализа работало достаточное количество молодых
привлекательных сотрудниц, и одной из них я перепоручил эту мегаважную и необычайно
срочную задачу. Получилось у неё примерно следующее (рис.4):
4
Рис. 4 Второй вариант Landscape Map.
Добавлены стадии проекта и приоритеты требований
Слегка пожурив её за унылую цветовую гамму и излишне формальный подход,
следующим утром я вместе с менеджером проекта отправился на встречу с разработчиками.
Тем уже было известно про наше новое развлечение в виде системы управления инцидентами,
и встретили они нас во всеоружии. В ходе этой встречи мы узнали много нового, в частности,
то, что служба бизнес-анализа и проектный офис у нас полные идиоты, совершенно не
разбирающиеся в информационных системах (уверен, это замечание относилось не лично к
нам, а скорее к молодой сотруднице, готовившей картинку). Также мы узнали, что еще
полтора года назад компания закупила лицензии на программный продукт «Сервисменеджер», на котором и следует реализовывать проект. Кроме того разработчики осыпали
нас градом непонятных слов, из которых я сумел запомнить только малую часть. Чаще других
звучали айтил (ITIL), ЕэСБи (ESB) и еще какие-то трехбуквенные сокращения. В общем,
сплошной ТиСиПи-АйПи (TCP|IP). В какой-то момент они начали ругаться друг с другом,
обсуждая, следует ли дозакупить недостающие лицензии или «нафигачить экранную форму в
интранете». Затем позвали начальника отдела интранет-решений и повесили на него задачу
разработки формы для заведения и закрытия инцидентов. В конечном счете руководитель
службы разработки отобрал у меня исходную картинку, нарисованную консультантом и,
пообещав к завтрашнему утру самостоятельно нарисовать правильное решение, вместе с
проектным менеджером выгнал с совещания.
На следующее утро в почтовом ящике я обнаружил новый рисунок. Я удалил с него
несущественные технические детали: названия серверов, пиктограммы баз данных и прочую
муть и в таком виде (рис.5) отправил его консультанту:
5
Рис. 5 Третий вариант Landscape Map.
Добавлены возможности ИТ-инфраструктуры
Получил в ответ письмо благодарности за отличную работу и переслав его своему
непосредственному руководителю, я смог, наконец, забыть об этой суматошной задаче. Снова
задача напомнила о себе ближе к осени, когда на веселой ферме приближался сезон дождей.
Позвонил проектный менеджер и сказал, что завтра у него управляющий комитет с
докладом о статусе проекта. Что разработчики практически ничего не сделали, а тестирование
прошли два модуля из восьми. Впрочем, проблема понятна. Дело в том, что нам хронически
не хватает программистов на С++ и юзабилити дизайнеров для интранет-сайта. А еще,
оказывается, отправка смс сообщений с компьютера стоит денег. Мы должны что-то платить
алчному оператору связи, и чтоб рассчитать эту сумму, нужны нефункциональные
требования. Одним словом, в итоге во всем оказались виноваты бизнес-аналитики. Я понял,
что просто так мне не отвертеться, и позвонил консультанту, попросив его помочь в
подготовке к завтрашней встрече. Он оказался на удивление отзывчивым человеком и к утру
прислал следующую картинку (рис.6):
6
Рис. 6 Окончательный вариант Landscape Map.
Добавлены статусы работ и необходимые ресурсы
Видели бы вы, с каким апломбом проектный менеджер докладывал по этой картинке
статус проекта. Он рассказал и про цветовую легенду функциональной карты, отображающую
статус работ по конкретной задачи, и о пиктограммах, визуализирующих уже
протестированные модули, и про С++, и про важность эргономичного пользовательского
интерфейса, и даже поставил под сомнение целесообразность смс-уведомлений. В общем, все,
наконец, поняли, что во всем виноваты вовсе не аналитики. В отличие от разработчиков и
тестировщиков, нас с проектным офисом даже похвалили. А в конце квартала мне выписали
хорошую премию. И теперь я регулярно рассказываю о преимуществах функциональных карт
перед диаграммами вариантов использования. Все у нас стали описывать функциональность
именно так. Хотя порой мне немного жаль, что мы отказались от UML диаграмм. Ведь
функциональная карта — источник постоянных споров и разногласий в нашем дружном
коллективе. Разработчики, администраторы, проектные менеджеры и даже заказчики
постоянно что-то на них зачеркивают, обводят и исправляют. С UML диаграммами такого не
было. Потому что это стандарт! К тому же, диаграмма вариантов использования —
единственная картинка, которую в этом проекте я нарисовал сам.
7
ЧАСТЬ 2
Задание
Нарисуйте функциональную карту для рассмотренного в статье примера создания службы
Service Desk, используя два разных инструмента:


Jibility,
Archi,
Две из систем существуют в свободном доступе.
При использовании инструментов для выполнения задания надо ориентироваться на такие
ключевые слова, как





Capabilities,
Requirement,
Enterprise Architecture,
Business Capability,
Canvas.
На карте, по возможности, должны быть отображены:
•
•
•
•
•
•
•
•
глоссарий;
реестр требований;
функционал создаваемой системы;
стадии проекта;
приоритеты требований;
возможности инфраструктуры;
статусы работ;
необходимые ресурсы.
В качестве решения задания лабораторной работы должен быть представлен отчет со
скринами разработанных глоссария, реестра требований и диаграмм, а также таблица, в
которой необходимо указать достоинства и недостатки рассмотренных инструментов для
такого рода задач. Правила оформления отчета изложены ниже в части 3.
8
ЧАСТЬ 3
Оформление
Решение лабораторной работы нужно оформить в виде отчета в формате .doc.
Содержание отчета:





титульный лист (см. приложение 1);
краткая постановка задачи (не более ½ страницы);
скрины глоссария и реестра требований, созданных в указанных системах;
скрины диаграмм функциональных требований в виде Landscape Map,
нарисованных в системах:
o Jibility;
o Archi.
Скрины диаграмм должны быть размещены на листе в АЛЬБОМНОЙ
ориентации, крупно, без лишнего пустого пространства на листе. Скрин должен
отображать не только саму диаграмму, но и панель инструментов, с помощью
которых происходила разработка диаграммы (см. приложение 2);
таблицу анализа, в которой надо указать достоинства и недостатки
инструментов, а также действия, которые можно выполнять с требованиями
заказчика в этих инструментах (см. приложение 3).
Используемые источники.
1. М. Смирнов. Функциональные карты и диаграммы вариантов использования
https://mxsmirnov.com/2015/07/27/fmap/
2. Jibility Demo: Strategy Roadmaps Made Simple
https://www.youtube.com/watch?v=v07tc_0aEJ4
9
Приложение 1
Министерство сельского хозяйства Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Пермский государственный аграрно-технологический университет
имени академика Д.Н. Прянишникова»
Кафедра информационных технологий и программной инженерии
ЛАБОРАТОРНАЯ РАБОТА №1
Инструментальные средства управления функциональными требованиями
Выполнил:
группа ПИб-2
@@@@@@@@@@@
Проверил:
доцент каф. ИТиПИ,
Т.А. Казаченко
Пермь-2021 г
10
Приложение 2
11
Приложение 3
Таблица анализа инструментальных средств
№
п/п
Название
приложения
1
Jibility
2
Archi
Достоинства
инструмента
Недостатки
инструмента
1)
1)
2)
2)
1)
1)
2)
2)
Функциональные возможности
управления требованиями заказчика
12
Скачать