Управление сложностью с помощью моделей

Системная инженерия (Systems Engineering) (системотехника) — это научно-методологическая дисциплина, которая изучает вопросы проектирования, создания и эксплуатации структурно сложных, крупномасштабных, человеко-машинных и социотехнических систем.

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

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

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

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

Модели дают следующие преимущества:

• Они позволяют сконцентрироваться исключительно на значимой информации рассматриваемого вопроса, но при этом обеспечивают соблюдение целостности и логичности всего дизайна.

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

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

• Можно разрабатывать исполняемые модели, которые позволят провалидировать проект на соответствие предъявляемым требованиям еще до начала построения системы.

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

• Модели используются для управления процессом разработки.

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

• Модели предоставляют возможность обмена идеями и выработки критериев принятия решений, делая ваше взаимодействие и сотрудничество с командой разработчиков более эффективным.

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

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

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

Понимание контекста

Перед началом разработки набора требований для интеллектуального продукта или системы, необходимо уделить некоторое время обдумыванию проблем и задач, которые этот продукт или система будут решать. Например, если вы собираетесь создать автомобиль, важно понять, как именно он будет использоваться и кем. Станет ли он ездить по городу, магистралям или раллийным трассам? Кто является целевой аудиторией этого автомобиля на рынке — опытные водители, молодежь или их родители? Будет ли он эксплуатироваться в жестких условиях (например, в условиях севера), на посыпанных солью дорогах, в экстремально жарком климате, на пересеченной местности или на высокогорье?

Требования

Требования можно разбить на три категории (или класса):

• Исходные требования. Это такие требования, которые исходят от заказчиков или других заинтересованных сторон. Они могут быть пространными и общими, детализированными и специфическими, полными и фрагментированными, - в большинстве случаев, в них есть всего понемногу. Как принято говорить, “когда дело доходит до требований, заказчик не приемлет никаких правил – вы получаете то, что получаете”.

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

• Системные/подсистемные требования. Эти требования определяют то, что система должна иметь возможность делать. Они берут свое начало на высоком системном уровне, затем анализируются и декомпозируются, чтобы образовать требования для подсистем уровнем ниже. Они могут выражаться в простых формах (“система должна...”), либо изображаться в виде моделей и диаграмм.

На каждом уровне абстракции требования определяют, ЧТО система должна делать и насколько хорошо ей следует это делать, но никак не то, КАК это должно быть реализовано.

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

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

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

Моделирование – фактор кардинального снижения рисков и издержек проекта

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

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

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

Использование языков и техник, признанных отраслевыми стандартами моделирования (таких, как UML и BPMN) устраняют неточности и неоднозначности, помогают преодолеть барьеры в коллективах разработчиков, а также дают единственную исходную точку для определения статуса проекта и документирования. Улучшение взаимодействия и четкая и точная документация повышают продуктивность, сокращают время разработки, а самое главное — обеспечивают высокий уровень качества.

Интеграция и моделирование систем

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

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

В системной инженерии существуют два основных подхода для минимизации этого риска:

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

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

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

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

Второй способ — это внедрить в жизненный цикл разработки как можно больше последовательных интеграций и тестирований (итераций). Системные инженеры уже много десятков лет пользуются итеративным жизненным циклом разработки.

Моделирование и коммуникация

Примерно треть всех произведенных в мире устройств не соответствуют требованиям по функциональности или производительности, при этом 24% всех проектов закрываются с непоправимым отставанием от графика.

Чаще всего проблемы вызваны недостатком сведений, знаний или слабой коммуникацией.

Даже работникам одной компании отсутствие четкой организационной структуры может мешать нормальному общению, снижать производительность и способствовать перекладыванию проблем “с больной головы на здоровую”.

Недостаток информационного обмена может привести ко многим проблемам, среди которых:

• Отсутствие четких системных целей

• Множественные и различающиеся интерпретации системных требований

• Неполный список требований любого уровня

• Затраты времени на поиск и систематизацию информации «вручную» из многочисленных источников

• Работа команд с устаревшими документами

• Дублирование или нехватка ответственности исполнителей

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

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

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

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

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

Ключевые инструменты системной инженерии

• Управление требованиями и трассируемость. Сквозная динамическая трассировка, связывающая источник информации, целевое назначение системы и требования к системе / подсистеме

• Разработка систем на основе моделей. Моделирование требований, функциональности системы, вариантов реализации, исследование затрат, исполнение моделей, валидация

• Управление изменениями и конфигурациями. Управление взаимодействием, изменениями, общим репозиторием и конфигурацией

• Автоматическое создание документов. Создание документов, содержащих информацию о требованиях, моделях, дизайне, спецификациях

• Интегрированная системная и программная инженерия. Обеспечение интеграции между артефактами (сверху-вниз) – требованиями, моделями, разработкой встроенных приложений

Системная инженерия - основа эффективной разработки

• Устранение недостатков дизайна на ранних стадиях разработки

• Разработка гибких бизнес-моделей

• Контроль над сложным программным обеспечением

• Оптимизация управления требованиями

• Повторное использование кода для ускорения выпуска продукта

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

• Своевременная поставка на рынок сложных решений

• Использование интегрированной платформы разработки

• Раннее и частое тестирование

• Совместная работа с требованиями для повышения эффективности разработок