Лабораторная работа № 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