Как составить описание системы

Федеральное управление

гражданской авиации

Министерства транспорта США

Руководство по разработке

и управлению требованиями

При создании авиационных бортовых

встраиваемых систем реального времени

Исходный текст, 2009 / Русский перевод, 2022

Оглавление

2.1 Создайте
«Общее описание системы»

2.1.1 Разработайте
«Общее описание системы»
на ранних этапах разработки требований

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

Этот документ должен включать в себя как минимум:

  • Краткое описание системы
  • Одно или несколько описаний контекста
  • Краткое описание каждого внешнего объекта на контекстных диаграммах
  • И набор целей, задач и ограничений системы высокого уровня

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

Примеры таких описаний приведены в 
приложении A.1 для инкубатора,
приложении B.1 для системы управления полётом,
приложении C.1 для подсистемы руководства полётом и 
приложении D.1 для AP.

Рекомендация 2.1.1

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

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

2.1.2 Предоставьте краткое текстовое описание системы (синопсис)

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

В ранней версии синопсиса в спецификации термостата инкубатора говорится:

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

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

Как и весь документ «Общее описание системы» этот текстовый обзор (синопсис) будет развиваться в процессе уточнения требований. Примеры полных системных обзоров приведены в начале приложения A.1 для инкубатора, приложения B.1 для системы управления полётом, приложения C.1 для подсистемы руководства полётом и приложения D.1 для автопилота.

Рекомендация 2.1.2

Предоставьте краткий текстовый обзор системы в качестве первой части общего описания системы. В кратком обзоре следует назвать систему, описать её назначение и кратко описать возможности системы.

2.1.3 Определите контексты, в которых работает система

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

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

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

Рекомендация 2.1.3

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

2.1.4 Используйте контекстные диаграммы

Для каждого контекста должны быть определены внешние объекты, с которыми взаимодействует система, и характер этих взаимодействий. Для этого удобно использовать контекстную диаграмму, которая графически изображает каждый внешний объект и его взаимодействие с системой. Пример контекстной диаграммы для инкубатора показан на рисунке A-1. Аналогичная контекстная диаграмма для FCS показана на рисунке B-1, для FGS — на рисунке C-1, а для AP — на рисунке D-1. Обратите внимание, что сама система показана на контекстной диаграмме в виде черного ящика без внутренней структуры. Также может быть полезно определить системы более высокого уровня, в которые встроена система (например, контекст Термостата включает в себя более крупное системное содержимое инкубатора).

Для удобства приведём здесь эти диаграммы:

Рисунок A-1 Контекстная диаграмма для инкубатора

Рисунок B-1 Контекстная диаграмма для системы управления полётом

Рисунок C-1 Контекстная диаграмма подсистемы руководства полётом

Рисунок D-1 Контекстная диаграмма подсистемы «‎Автопилот»‎

Рекомендация 2.1.4

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

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

2.1.5 Опишите внешние объекты
(внешние сущности)

Также должно быть предоставлено краткое описание каждого внешнего объекта, взаимодействующего с системой. Поскольку мы формулируем часть общего описания системы, текст должен быть кратким и простым (более подробная информация об объектах и их взаимодействиях будет предоставлена в последующих разделах спецификации). Примеры описаний внешних объектов и их взаимодействия с системой приведены в приложении A.1.1 для инкубатора, приложении B.1.1 для системы управления полётом, приложении C.1.1 для подсистемы руководства полётом и приложении D.1.1 для автопилота.

Приведём тут пример для термостата инкубатора.

Термостат напрямую взаимодействует с тремя объектами, входящими в состав инкубатора:

  • Датчик измерения температуры сообщает термостату текущую температуру воздуха в инкубаторе
  • Источник тепла нагревает воздух в инкубаторе. Он включается и выключается с помощью регулятора нагрева
  • Интерфейс пользователя предоставляет пользователю настройки термостата и получает обратную связь от термостата

Термостат также косвенно взаимодействует с другими объектами за пределами инкубатора:

  • Медсестра, которая использует пользовательский интерфейс для входа в настройки и просмотра обратной связи
  • Воздух в инкубаторе
  • Младенец, помещённый в инкубатор и согретый воздухом

Рекомендация 2.1.5

Для каждой контекстной диаграммы предоставьте краткое описание всех внешних объектов и их взаимодействие с системой.

2.1.6 Зафиксируйте предварительный набор целей системы

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

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

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

Рекомендация 2.1.6

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

2.1.7 Поддерживайте информацию
о целях системы

Цели часто помогают объяснить, почему существует то или иное конкретное требование или почему оно именно таким образом сформулировано.

Цели могут быть приведены в обосновании требования (см. раздел 2.11). Концепция эксплуатации (см. раздел 2.3) также можно соотнести с конкретным целям системы. Управление целями системы будет варьироваться в зависимости от размера, сложности и зрелости разрабатываемой системы. В небольших проектах цели могут быть хорошо поняты и, возможно, удастся перечислить их на одной странице, а всё управление ими может свестись к периодическому пересмотру и обновлению.

Это относится и к примеру с инкубатором, который изначально преследует только две простые цели:

  • G1 — Младенец должен находиться в безопасной и комфортной для него температуре

  • G2 — Стоимость изготовления термостата должна быть как можно ниже

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

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

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

  • Источник — Откуда взялась цель (клиент, физическое лицо, документ…)?
  • Дата возникновения — Когда была впервые определена цель?
  • Автор — Кто первым задокументировал цель?
  • Приоритет — Какова важность цели по сравнению с другими целями?
  • Стейкхолдеры (Заинтересованные стороны) — Какие клиенты или пользователи больше всего обеспокоены этой целью?
  • Cтабильность — Насколько вероятно, что эта цель изменится?
  • Запланированная дата — На какую дату планируется реализовать эту цель?

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

Рекомендация 2.1.7

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

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

Далее к разделу 2.2

«Теория систем и системный анализ»

И. Б. Родионов

Лекция 4: Функциональное описание и моделирование систем

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

Модель — описание системы, отражающее определенную группу ее свойств.

Описание системы целесообразно начинать с трех точек зрения: функциональной, морфологической и информационной.

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

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

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

Как нам уже известно, система может быть однофункциональной и многофункциональной.

Во многом оценка функций системы (в абсолютном смысле) зависит от точки зрения того, кто ее оценивает (или системы, ее оценивающей).

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

Функционал количественно или качественно описывающий деятельность системы называют функционалом эффективности.

Функциональная организация может быть описана:

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

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

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

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

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

Sf = {T, x, C, Q, y, φ, η},

где T — множество моментов времени, х — множество мгновенных значений входных воздействий, С = {c: T → x} — множество допустимых входных воздействий; Q — множество состояний; y — множество значений выходных величин; Y = {u: T → y} — множество выходных величин; φ = {T×T×T×c → Q} — переходная функция состояния; η:T×Q → y — выходное отображение; с — отрезок входного воздействия; u — отрезок выходной величины.

Такое описание системы охватывает широкий диапазон свойств.

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

Примем, что система S выполняет N функций ψ1, ψ2, …, ψs, …, ψN, зависящих от n процессов F1, F2, …, Fi, …, Fn. Эффективность выполнения s-й функции

Эs = Эss) = Э(F1, F2, …, Fi, …, Fn) = Эs({Fi}), i = 1…n, s = 1…N.

Общая эффективность системы есть вектор-функционал Э = {Эs}. Эффективность системы зависит от огромного количества внутренних и внешних факторов. Представить эту зависимость в явной форме чрезвычайно сложно, а практическая ценность такого представления незначительна из-за многомерности и многосвязности. Рациональный путь формирования функционального описания состоит в применении такой многоуровневой иерархии описаний, при которой описание более высокого уровня будет зависеть от обобщенных и факторизованных переменных низшего уровня.

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

Процессы {Fi(1)} можно обнаружить на выходе системы. Это процессы взаимодействия со средой. Будем называть их процессами первого уровня и полагать, что они определяются:

  1. параметрами системы первого уровня — Q1(1), Q2(1), …, Qj(1), …, Qm(1);
  2. активными противодействующими параметрами среды, непосредственно направленными против системы для снижения ее эффективности — b1, b2, …, bk, …, bK;
  3. нейтральными (случайными параметрами среды) c1, c2, …, cl, …, cL;
  4. благоприятными параметрами среды d1, d2, …, dp, …, dP.

Среда имеет непосредственный контакт с подсистемами низших уровней, воздействуя через них на подсистемы более высокого уровня иерархии, так что Fi* = Fi*({bk}, {cl}, {dp}). Путем построения иерархии (параметры β-го уровня — процессы (β-1)-го уровня — параметры (β-1)-го уровня) можно связать свойства среды с эффективностью системы.

Параметры системы {Qj} могут изменяться при изменении среды, они зависят от процессов в системе и записываются в виде функционалов состояния Qj1(t).

Собственным функциональным пространством системы W называется пространство, точками которого являются все возможные состояния системы, определяемое множеством параметров до уровня b:

Q = {Q(1), Q(2), … Q(β)}.

Состояние может сохраняться постоянным на некотором интервале времени Т.

Процессы {Fi(2)} не могут быть обнаружены на выходе системы. Это процессы второго уровня, которые зависят от параметров Q(2) подсистем системы (параметров второго уровня). И так далее.

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

Внешние характеристики системы определяются верхним уровнем иерархии, поэтому часто удается ограничиться описанием вида ({Эi},{ψS}, {Fi(1)}, {Qj(1)}, {bk}, {cl}, {dp}). Число уровней иерархии зависит от требуемой точности представления входных процессов.

Графические способы функционального описания систем

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

  • дерево функций системы,
  • стандарт функционального моделирования IDEF0.

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

  • целевая функция;
  • базисные функции системы;
  • дополнительные функции системы.

Целевая функция системы соответствует ее основному функциональному назначению, т.е. целевая (главная) функция — отражает назначение, сущность и смысл существования системы.

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

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

Описание объекта на языке функций представляется в виде графа.

Описание объекта на языке функций в виде графа

Рис. — Описание объекта на языке функций в виде графа

Формулировка функции внутри вершин должна включать 2 слова: глагол и существительное «Делать что».

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

Исходными данными для формирования дерева функций являются основные и дополнительные функции системы.

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

При этом каждая из функций конкретно взятого i-ого уровня может рассматриваться как макрофункция по отношению к реализующим ее функциям на (i+1)-го уровня, и как элементарная функция по отношению к соответствующей функции верхнего (i-1)-го уровня.

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

Краткое описание методологии IDEF0

Объектами моделирования являются системы.

Описание IDEF0 модели построено в виде иерархической пирамиды, в вершине которой представляется самое общее описание системы, а основание представляет собой множество более детальных описаний.

IDEF0 методология построена на следующих принципах:

  • Графическое описание моделируемых процессов. Графический язык Блоков и Дуг IDEF0 Диаграмм отображает операции или функции в виде Блоков, а взаимодействие между входами/выходами операций, входящими в Блок или выходящими из него, Дугами.
  • Лаконичность. За счет использования графического языка описания процессов достигается с одной стороны точность описания, а с другой — краткость.

Необходимость соблюдения правил и точность передачи информации. При IDEF0 моделировании необходимо придерживаться следующих правил:

  • На Диаграмме должно быть не менее 3-х и не более 6-и функциональных Блоков.
  • Диаграммы должны отображать информацию, не выходящую за рамки контекста, определенного целью и точкой зрения.
  • Диаграммы должны иметь связанный интерфейс, когда номера Блоков, Дуги и ICOM коды имеют единую структуру.
  • Уникальность имен функций Блоков и наименований Дуг.
  • Четкое определение роли данных и разделение входов и управлений.
  • Замечания для Дуг и имена функций Блоков должны быть краткими и лаконичными.
  • Для каждого функционального Блока необходима как минимум одна управляющая Дуга.
  • Модель всегда строится с определенной целью и с позиций конкретной точки зрения.

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

Контекст модели очерчивает границы моделируемой системы и описывает ее взаимосвязи с внешней средой.

Точка зрения определяет позицию автора, т.е. что будет рассматриваться и под каким углом зрения.

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

Цель отражает причину создания модели и определяет ее назначение. При этом, все взаимодействия в модели рассматриваются именно с точки зрения достижения поставленной цели.

В рамках методологии IDEF0 модель системы описывается при помощи Графических IDEF0 Диаграмм и уточняется за счет использования FEO, Текстовых и Диаграмм Глоссария. При этом модель включает в себя серию взаимосвязанных Диаграмм, разделяющих сложную систему на составные части. Диаграммы более высокого уровня (А-0, А0) — являются наиболее общим описанием системы, представленным в виде отдельных Блоков. Декомпозиция этих Блоков позволяет достигать требуемого уровня детализации описания системы.

Разработка IDEF0 Диаграмм начинается с построения самого верхнего уровня иерархии (А-0) — одного Блока и интерфейсных Дуг, описывающих внешние связи рассматриваемой системы. Имя функции, записываемое в Блоке 0, является целевой функцией системы с принятой точки зрения и цели построения модели.

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

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

Хотя вершиной модели является Диаграмма уровня А-0, настоящей «рабочей вершиной или структурой» является Диаграмма А0, поскольку она является уточненным выражением точки зрения модели. Ее содержание показывает, что будет рассматриваться в дальнейшем, ограничивая последующие уровни в рамках цели проекта. Нижние уровни уточняют содержание функциональных Блоков, детализируя их, но, не расширяя границ модели.

Описание синтаксиса языка моделирования

Основными элементами на IDEF0 Диаграммах являются Блоки и Дуги.

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

глагол + объект действия + [дополнение].

Например: обрабатывать деталь на станке, передать документы в отдел, разработать план-график проведения анализа, опубликовать материалы…

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

Место соединения дуги с блоком определяет тип интерфейса.

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

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

Типы дуг

Рис. — Типы дуг

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

За каждой Дугой закрепляется Замечание, которое отображает суть информации или объекта. Замечание формулируется в виде оборота существительного, отвечающего на вопрос: «Что?».

Дуги, как ограничивающие и уточняющие факторы Блока

Рис. — Дуги, как ограничивающие и уточняющие факторы Блока

Пример А0 диаграммы

Рис. — Пример А0 диаграммы

Функциональные Блоки на Диаграмме изображаются в виде прямоугольников, внутри которых записывается имя функции и номер Блок (в правом нижнем углу прямоугольника).

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

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

Очень важно помнить, что доминирование блоков на диаграмме не задаёт чёткой временной зависимости операций.

Стороны Блока также имеют определенное значение. К левой границе Блока присоединяются входные Дуги, к верхней — управляющие Дуги, к правой — выходные Дуги, а к нижней — Дуги механизмов.

Дуги на IDEF0 Диаграмме изображаются в виде стрелок.

При IDEF0 моделировании используются пять типов взаимосвязей между Блоками, для описания их отношений.

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

    Взаимосвязь по управлению

    Рис. — Взаимосвязь по управлению

  • Взаимосвязь по входу, — когда выход одного Блока является входом для другого.

    Взаимосвязь по входу

    Рис. — Взаимосвязь по входу

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

    Обратная связь по управлению

    Рис. — Обратная связь по управлению

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

    Обратная связь по входу

    Рис. — Обратная связь по входу

  • Взаимосвязь «выход-механизм», — когда выход одной функции является механизмом для другой. Иначе говоря, выходная Дуга одного Блока является Дугой механизма для другого. Такой тип связи встречается редко и относится чаще всего к подготовительным операциям.

    Взаимосвязь «выход-механизм»

    Рис. — Взаимосвязь «выход-механизм»

Поскольку содержание IDEF0 Диаграмм уточняется в ходе моделирования постепенно, Дуги на Диаграммах редко изображают один объект. Чаще всего они отображают определенный набор объектов и могут иметь множество начальных точек (источников) и определенное количество конечных точек (приемников). В ходе разработки графической Диаграммы для отражения этой особенности используют механизм разветвления/слияния Дуг. Это позволяет не только уточнить с использованием Замечаний содержание каждой ветви разветвленной Дуги (потока объектов), но и более точно описать из каких наборов объектов состоит входящая в функциональный Блок Дуга, если она получена путем слияния.

Пример

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

Диаграмма верхнего уровня А-0, отражающая целевую функцию системы

Рис. — Диаграмма верхнего уровня А-0, отражающая целевую функцию системы

Диаграмма А0, отражающая декомпозицию целевой функции на основные функции А1, А2, А3

Рис. — Диаграмма А0, отражающая декомпозицию целевой функции на основные функции А1, А2, А3

Декомпозиция блока А1

Рис. — Декомпозиция блока А1

Декомпозиция блока А2

Рис. — Декомпозиция блока А2

Декомпозиция блока А3

Рис. — Декомпозиция блока А3

Требования к структуре общего описания системы по ГОСТ 34 устанавливаются РД 50-34.698-90. В общем случае документ должен состоять из следующих разделов:

1 Назначение системы
1.1 Вид деятельности, для автоматизации которой предназначена система
1.2 Перечень объектов автоматизации, на которых используется система
1.3 Перечень функций, реализуемых системой
2 Описание системы
2.1 Структура системы и назначение ее частей
2.2 Сведения об АС в целом и ее частях, необходимые для обеспечения эксплуатации системы
2.3 Описание функционирования системы и ее частей
3 Описание взаимосвязей АС с другими системами
3.1 Перечень систем, с которыми связана данная АС
3.2 Описание связей между системами
3.3 Описание регламента связей
3.4 Описание взаимосвязей АС с подразделениями объекта автоматизации
4 Описание подсистем
4.1 Структура подсистем и назначение ее частей
4.2 Сведения о подсистемах и их частях, необходимые для обеспечения их функционирования
4.3 Описание функционирования подсистем и их частей

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

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

Примечание

Эти и другие требования к структуре и содержанию общего описания системы по ГОСТ 34 подробнее см. РД 50-34.698-90

Документ выполняют на формах, установленных соответствующими стандартами Единой системы конструкторской документации (ЕСКД).

Для размещения утверждающих и согласующих подписей к документу рекомендуется составлять титульный лист и (или) лист утверждения.

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

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

Примечание

Эти и другие требования по оформлению общего описания системы по ГОСТ 34 подробнее см. ГОСТ 2.105-95

Приступая
к изучению новой, неизвестной системы,
мы не знаем, с чем имеем дело. В этом
случае представление об объекте
исследования может дать некоторое
описание его свойств.

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

  • значимость
    системы в ее конкретной функции;

  • воздействие
    на внешнюю среду (связи с другими
    системами).

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

Морфологическое
описание дает ответ на вопрос о том, из
каких элементов состоит система?
Указанное описание определяет:

  • глубину
    описания (выбор элемента, внутрь
    которого описание не проникает);

  • композиционные
    свойства (способ объединения элементов
    в систему);

  • эффективность
    выполнения функции, на которую влияют
    искажения и непредусмотренные потери
    информации.

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

Информационное
описание дает представление об обмене
информацией между частями системы,
системой и внешней средой. Описание
позволяет судить об информационной
упорядоченности системы. При этом
обычно определяют:

  • меру
    неопределенности (энтропию) или
    упорядоченности (негэнтропию) системы;

  • информационный
    метаболизм (обмен информации со средой).

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

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

2.3. Суть системного подхода

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

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

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

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

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

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

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

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

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

Системность
заключатся в стремлении исследовать
объект с разных сторон.

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

  • единства
    (рассмотрение систем и как нечто целого
    и как совокупности частей);

  • развития
    (изменяемости системы по мере накопления
    информации, черпаемой из внешней
    среды);

  • целевой
    направленности (результирующий целевой
    вектор системы не всегда является
    совокупностью оптимальных целей его
    подсистем);

  • функциональности
    (структура системы следует за ее
    функциями, соответствует им);

  • децентрализации
    (как сочетание централизации и
    децентрализации);

  • иерархии
    (соподчинение и ранжирование систем);

  • неопределенности
    (вероятностного наступления событий);

  • организованности
    (степени выполнения решений).

Сущность
системного подхода в трактовке академика
В.Г. Афанасьева выглядит следующим
образом:

  1. морфологическое
    описание (из каких частей состоит
    система);

  2. функциональное
    описание (какие функции выполняет
    система);

  3. информационное
    описание системы (передача информации
    между частями системы, способ
    взаимодействия на основе связей между
    частями);

  4. коммуникационное
    описание (взаимосвязь системы с другими
    системами, как по вертикали, так и по
    горизонтали);

  5. интеграционное
    описание (изменение системы во времени
    и пространстве);

  6. описание
    истории системы (возникновение, развитие
    и ликвидация системы).

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

Схематично
системный поход выглядит как
последовательность определенных
процедур:

  1. Определение
    признаков системы (целостность и
    множество членений на элементы);

  2. Исследование
    свойств, отношений и связей системы;

  3. Установление
    структуры системы и ее иерархического
    строения;

  4. Фиксация
    взаимоотношений между системой и
    внешней средой;

  5. Описание
    поведения системы;

  6. Описание
    целей системы;

  7. Определение
    информации, необходимой для управления
    системой.

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

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

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

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

1Шевырев А.В. Технология творческого
решения проблем. Книга первая. – Мышление
и проблема. Психология творчества. –
Белгород: «Крестьянское дело», 1995 ,
С.42.

2Богданов А.А. Всеобщая организационная
наука (Тектология). Т. 1 – М.: Экономика,
1989, с.249

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

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

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

Одна и та же система должна быть описана всеми тремя основными способами, чтобы понять механизм её работы, из чего её делать и где её искать. Важно не путать эти описания. Вот ножницы, которые описываются с точки зрения их использования как ножевой блок и ручка (описание в момент использования этих ножниц, функциональное. Значок «=» перед названием части указывает на то, что речь идёт о ролевой, функциональной части). Если вы попытаетесь на один завод дать заказ на ножевой блок, а на другой завод заказ на ручку, то это будет невозможно сделать! Описание, удобное для изготовления — это описание половинок ножниц (винтик, их скрепляющий, не показан).

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

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

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

Новости по поводу книги/текста появляются в блоге автора, https://t.me/ailev_blog, предложения и замечания присылать автору по адресу ailev@asmp.msk.su.

Источник: книга А. Левенчука «Образование для образованных 2020».

Loading

Добавить комментарий