Читать книгу: «Системный инженер. Как начать карьеру в новом технологическом укладе», страница 3

Глава 3. Функциональное моделирование

Сбор и анализ требований будет гораздо эффективнее, если кроме «послойного осаждения» в документации, они еще отразятся в функциональной модели системы.

Иногда о функциональной модели говорят: «Взгляд снаружи внутрь». То есть, в какой-то мере, функциональная модель представляет собой структуризацию и уточнение требований до той степени, когда не возникает вопросов, что именно должна делать целевая система. Давайте попробуем нарисовать функциональную модель системы умный бизнес-центр. Для этого нам необходимо назвать ее основную функцию. Мы снова вернулись к этому вопросу. Можно было бы нарисовать вот такую схему «на салфетке» (рис. 3).

Рис. 3. Контекстная функциональная модель системы управления потреблением электроэнергии и воды в бизнес-центре

Если мы напишем все функции системы через запятую в одном названии, то, фактически, мы словом «система» подменим, просто, некоторое объединение. На самом деле, мы будем проектировать в таком случае несколько разных систем, которые работают в некоторой связке: одна управляет электроэнергией, а другая – водоснабжением (может быть еще несколько аналогичных систем). Никакого системного эффекта здесь не просматривается. Можно было бы обобщить до понятия «ресурсы», но, опять таки, это обобщение не раскроет системного эффекта, возникающего при связанном функционировании перечисленных систем.

Еще одна неувязка заключается в том, что большинство требований относятся не столько к «коробочке с проводами», как мы охарактеризовали умный дом, сколько к некоторой инфраструктуре всего здания. То есть наших стейкхолдеров интересуют не сигналы управления на выходе, а конкретные действия по регулированию воды или электричества. Должен ли входить в нашу систему, например, кондиционер? И все-таки, кто же наши пользователи? Владельцы бизнес-центров, персонал, арендаторы или системные интеграторы, монтирующие «коробочку с проводами» в инфраструктуру здания? А может быть, мы должны проектировать всё здание «под ключ» вместе с умным бизнес-центром внутри?

Первый вариант, который мы рассмотрим, будет заключаться в укрупнении задачи. Давайте назовем функцией системы – поддержку комфорта в бизнес-центре (рис. 4). Таким ходом мы ставим себе задачу четкого определения термина «комфорт», вплоть до математической формулы. Для начала давайте декомпозируем комфорт, например, вот в такой кортеж:

Комфорт = <Температура воздуха, Влажность воздуха, Уровень автоматизации, Экономия>

Можно декомпозировать дальше:

Уровень автоматизации = <Включение и выключение эскалаторов, Автоматическая подача воды порциями и т.д.>

Когда мы знаем структуру, можно предложить различные математические критерии оценивания этого самого комфорта, например с помощью развесовки и суммирования. Каждый из субкритериев можно привести к нормализованному виду от 0 до 1, тогда задача оценки уровня комфорта не составит никакого труда. Но не будем углубляться в оценку – это предмет системного анализа, а не системной инженерии. Проблема в том, что поддержать тот или иной уровень комфорта система может только тогда, когда в неё входят приборы, взаимодействующие со средой, например, тот же кондиционер. Коробка с проводами сама по себе комфорт не обеспечивает – это не ее функция. Системный инженер должен обязательно обсудить с менеджерами такую проблему. Скорее всего, будет предложено не выходить за рамки идеи – коробки с проводами. Оборудовать здание кондиционерами, электроприборами и батареями – не совсем та задача, которую мы хотели решать сначала.

Рис. 4. Контекстная функциональная модель системы поддержки комфорта в бизнес-центре

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

Рис. 5. Контекстная функциональная модель системы минимизации денежных расходов на ресурсы в бизнес-центре в реальном времени

Интуитивно может показаться, что сейчас самое время начать функциональную декомпозицию системы, чтобы понять, как она должна работать, но это не так. Я настоятельно рекомендую выполнить обратное действие – давайте представим функцию нашей системы в составе функциональной декомпозиции использующей системы, то есть той системы, которая использует целевую систему. Чтобы это сделать, надо понять – что есть использующая система? В русскоязычной литературе часто встречается термин «надсистема», но он мне не нравится, поскольку не задает «потолок» рассуждениям о границах. Мы будем говорить именно о той системе, которая использует целевую систему «умный бизнес-центр», то есть «коробочку с проводами», то есть «систему минимизации денежных расходов бизнес-центра в реальном времени». Судя по всему, использующая система и есть бизнес-центр, но какая у него функция?

Мы уже вели рассуждения о комфорте. Если немного переформулировать функцию, связанную с комфортом, получим неплохую формулировку для использующей системы – система поддержки комфортных условий для ведения бизнеса. Вполне логично, что для комфортного ведения бизнеса нужна близкая к комнатной температура, продуманное управление потоками людей, наличие санузлов, электричества и многое другое. Немаловажно – чтобы все это укладывалось в реалистичный бюджет. Было бы неплохо весь список этих условий включить в новый кортеж, характеризующий уровень комфорта. Он будет похож на предыдущий, но более полный, потому что мы теперь правильно определили системные уровни для поставленной задачи.

Основной критерий правильного использования функциональной модели – резкое ускорение процесса проектирования. Если у вас возникают трудности в разработке, вернитесь к функциональной модели. При этом неважно, занимались вы функциональным моделированием «на бумаге» или нет. Все равно в вашей голове есть какая-то функциональная модель. Нарисуйте то, что у вас в голове, используя один из формализмов функционального моделирования.

Что вы делаете? Систему, которая обеспечивает комфорт или систему, которая экономит деньги? Это же два абсолютно разных проекта. Какой бюджет у модернизации бизнес-центра, а какой – у создания «коробочки с проводами»? Самые частые ошибки в инженерных проектах, которые я наблюдал на практике, были связаны с неверными представлениями о функции целевой системы. Когда в голове «комфорт», а проект про «коробочку с проводами», будут большие сложности с принятием решений.

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

Определяем входные потоки:

– внешние условия, включая погоду, механические воздействия, городской шум и другое;

– ресурсы, приходящие к нам через инженерные коммуникации: вода, электричество, газ или еще что-то;

– запросы на сервисы – в любом бизнес-центре нужны санузлы, уборщицы или что-то более специфичное типа эскалаторов (сервис транспорта), центров печати.

Определяем выходные потоки:

– мы ожидаем, что здание обеспечит нам внутренний комфортный климат, огородив от внешней среды;

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

Обращаю внимание, что рассуждение про потоки идет параллельно рассуждению о конструкции: здание, инженерные коммуникации, эскалаторы и т. д. То есть мы немного забегаем вперед, простраивая логическую архитектуру. Для системной инженерии это обычное дело, когда приходится перескакивать между разными точками зрения (частными методами описания), чтобы удержать в голове целостность системы. Для кого-то, возможно, было бы удобно нарисовать схему логической архитектуры уже сейчас в каком-то виде: показать стены, инженерные коммуникации, эскалаторы, санузлы и т. д. Я этого делать не буду. К логической архитектуре мы подойдем чуть позже. На данном этапе нам не столько важны варианты воплощения, сколько общая идея того, что происходит внутри использующей системы. Важно – использующая система пока существует без «коробочки с проводами».

Рис. 6. Функциональная диаграмма использующей системы без целевой системы (как есть)

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

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

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

Рис. 7. Функциональная диаграмма использующей системы с целевой системой

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

Например, «ПТ3. Внешние условия» может быть ассоциирован с потребностью обеспечивать комфортные условия в условиях пустыни. «ПТ1. Запросы на сервисы» может быть ассоциирован с потребностью в определенном количестве людей, которых должен обслуживать центр. «ПТ2. Результаты сервисов» может быть связан с потребностями ускорения процессов, повышения качества. Условия среды в (ПТ6) сами по себе являются важной потребностью, ведь если мы просто будем экономить на всём, в бизнес-центре может стать, например, душно и жарко. Потоки (ПТ8) и (ПТ9), с одной стороны внешние, а с другой – относятся к целевой системе. Эти потоки могут быть связаны с потребностями сервисного обслуживания, то есть дополнительно – (СХ6) техобслуживание.

Требования к целевой системе мы можем теперь разделить на 4 группы:

– требования к управлению сервисами (Т2, Т3);

– требования к управлению средой (Т1, Т4);

– требования к мониторингу среды;

– требования к мониторингу сервисов.

В скобках приведены идентификаторы тех требований, которые мы уже писали ранее. Как видно, мы интуитивно заметили только две группы требований. Требования к мониторингу сервисов могут быть связаны, например, с количеством сервисов, которыми система должна управлять, типами сервисов и их результатов; это могут быть расстояния, время, частота получения информации и многое другое. Мониторинг среды также имеет свои особенности, например: количество точек сбора информации, конкретные измеряемые характеристики, периодичность измерений и многое другое.

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

– идентификатор;

– короткое название;

– полное название;

– входные параеметры;

– выходные параметры;

– иные функциональные связи.

У начинающих системных аналитиков часто возникает вопрос: «А когда нужно прекращать декомпозировать? Сколько уровней должно быть?». Если спецификация функции занимает меньше A4, значит её уже не надо декомпозировать. Еще вариант – если по спецификации можно найти и купить соответствующий модуль.

Когда функциональное описание использующей системы вместе со встроенной целевой системой будет закончено, нужно вспомнить, что было на рисунке 1. У нас есть первый вариант плана. Самое время оценить осуществимость такого плана. На данном этапе, конечно, рано выполнять подсчет затрат на весь проект. Требования совсем «сырые». Однако, имеет смысл пересмотреть список стейкхолдеров. В частности, существуют стейкхолдеры, связанные с системами в операционном окружении, от которых очень сильно зависит успех проекта. Как видно из рисунка 7, целевая система взаимодействует с системами обеспечения комфортных внутренних условий (вентиляция, отопление, увлажнение и проч.) и системами обеспечения сервисов (санузлы, эскалаторы, центры печати и проч.). Наша «коробочка с проводами» начнет использоваться только тогда, когда будет подключена ко всем требуемым системам в операционном окружении. Если отталкиваться от того, что валидация должна выполняться на предмет удовлетворения потребностей стейкхолдеров, то становится не очень понятно, как это сделать, когда система еще не встроена в использующую систему, но уже произведена и должна быть продана, чтобы компенсировать затраты на производство. Валидация, с точки зрения системной инженерии, возможна лишь в условиях эксплуатации (или максимально приближенных) и должна проводиться с участием пользователя и заказчика.

Если вы проектируете «коробочку с проводами», а ваша компания не планирует выполнять монтажные работы, потому что это другой бизнес, то, выходит, вы не можете гарантировать удовлетворение потребностей в рамках текущего проекта.

Получается, что успешность нашей системы зависит от того, как сработают еще две группы стейкхолдеров, относящихся к системам обеспечения сервисов и к системам обеспечения комфортных внутренних условий (среды). Это огромное количество различных стейкхолдеров, занимающихся эскалаторами, принтерами, кондиционерами, инженерной инфраструктурой, проводкой и т. д. Их то мы и забыли включить в таблицу 3. Надо это обязательно сделать. Тем не менее проблема зависимости от этих стейкхолдеров в вопросе успеха «коробочки» остается нерешенной. Как выполнять валидацию? Валидация – это практика жизненного цикла системы. Может быть, сейчас правильнее задать вопрос – а какой у целевой системы жизненный цикл?

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