Вячеслав Мизгулин.

Системный инженер. Как начать карьеру в новом технологическом укладе



скачать книгу бесплатно

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

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

В системной инженерии принято называть систему по основной функции, которую она выполняет.

Как известно, система выполняет функции на стадии эксплуатации. Какую главную функцию выполняет умный дом?

Очень часто проекты называют беспредметно и абстрактно. Часто приходится слышать такие названия проектов как «Система управления сервисами платформы того-то» или «Сервис управления системами сего-то». Чаще всего целью проекта является разработка какого-нибудь маленького модуля, а в названии пишут чуть ли не «Разработка системы управления миром».

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

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

Я, как <стейкхолдер>, хочу <потребность>, потому что <проблема>.

Например, я, как владелец умного дома, хочу меньше платить за электричество, потому что сейчас приходится платить слишком много из-за неэффективно использующегося оборудования, например, ночью.

Коммерческий отдел или отдел маркетинга вряд ли будет формулировать потребность именно в такой форме. Ваша задача, как системного инженера, привести к одной форме все потребности. Однако надо учесть, что коммерсанты могут перевернуть вам представление о проекте в один счет.

На очередном совещании выясняется, что спрос на системы типа умного дома резко вырос у бизнес-центров. Этот рынок достаточно новый и большой. Вопрос заключается в том, есть ли принципиальная разница между умным домом для коттеджа и для бизнес-центра? Вероятно, потребности стейкхолдеров умного бизнес-центра будут значительно шире. Ценник будет отличаться, возможно, на порядок. Требования будут значительно жестче. Тем не менее, если бизнес-центр научится экономить ресурсы, оставив стоимость арендной платы на прежнем уровне, это позволит увеличить прибыль.

Обычно выявлением потребностей занимаются отдельные специалисты.

Системный инженер должен структурировать потребности относительно стейкхолдеров системы (простейшая форма дана выше), а затем для каждой потребности сформулировать набор требований. Требование формулируется относительно самой системы или ее элементов.

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

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

Я, как <стейкхолдер>, считаю, что система должна <требование>, чтобы <потребность>.

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

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

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

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


Таблица 4. Потребности стейкхолдеров системы с рабочим названием умный бизнес-центр


Для каждой потребности необходимо предложить сценарии использования системы, по которым можно будет судить об удовлетворении потребности, а также о степени удовлетворения, если необходимо. Именно сформулированные потребности помогают системному инженеру спланировать валидацию системы, например в рамках приемочных испытаний. На практике я часто встречался с ситуациями, когда проверочные и приемочные испытания представляли собой примерно одно и то же, поставленное в календарном плане друг за другом. Сейчас, когда вы формулируете потребности и требования, давайте зафиксируем:

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

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

Остановимся на потребности (П1) – меньше платить за электричество и водоснабжение. Важной способностью системного инженера должно быть сценарное (или алгоритмическое) мышление. Можно выделить несколько основных видов мышления по времени приложения: рассуждения о настоящем времени; рассуждения о прошедшем времени; рассуждения о будущем времени. Думаете, это все? Можно еще рассуждать о прошлом из прошлого, о прошлом из будущего, о будущем из прошлого и т. д. Успешный системный инженер должен думать во всех временах с одинаковой изворотливостью и быстротой.

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


Таблица 5. Требования владельца и пользователя системы (СХ1) для потребности (П1)


Вариантов требований может быть очень много. Можно вспомнить про парковки, про влажность воздуха, про авторегулирование освещения и многое другое. Требования всегда имеет смысл ранжировать. Уровень важности того или иного требования может оценить каждый стейкхолдер. При этом, каждый стейкхолдер может быть «по секрету» взвешен, на предмет собственной важности. Снимать требования в зависимости от их низкого ранга «просто так», конечно, нельзя. Но так легче понять, какие требования можно вынести на обсуждение со стейкхолдерами, как необязательные. А уже потом – убрать.

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

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

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

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

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

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


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


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

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

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

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

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

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

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


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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


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

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

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

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



скачать книгу бесплатно

страницы: 1 2 3