Всего на сайте:
183 тыс. 477 статей

Главная | Финансы, Менеджмент

Практики определения системы – требования  Просмотрен 242

Тема 5. Практики определения системы – требования.

Стоимость ошибок. Основной принцип принятия решений. Организация графика работ. Онтология требований, виды требований. Структура инженерии требований. Работа инженера по требованиям. Поколения инженерии. Языки представления требований. Стандарты ISO 29148, ISO 15926. Связь инженерии требований с архитектурой.

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

 

Рассмотрим еще раз V-диаграмму жизненного цикла системы.

Напомним, что левая вертикальная линия называется system definition, правая – system realization, верхняя правая горизонтальная линия соответствует эксплуатации системы. Однако движение по линиям не поступательное, а, скорее, колебательное. Если эти колебания измерять в каких-то единицах, то получается hump-диаграмма.

 

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

 

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

 

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

 

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

 

Выявленная на стадии изготовления системы ошибка, например, в рабочих чертежах или выборе материала для детали, способна увеличить стоимость своего исправления в среднем в 12 раз. Если же ошибка «дожила» до проверки (система собрана, работает), то стоимость умножается на 40. Кстати, проверкой-наладкой также занимаются системные инженеры, охватывающие в мышлении систему в целом, и сохраняющие шанс спасти результат, поскольку увеличение стоимости в 40 раз – еще не катастрофа. Поэтому они имеют широкие права, в частности, потребовать переработки всей системы (например, атомной станции или самолета). После сдачи в эксплуатацию стоимость исправления ошибки возрастает уже в 250 раз. При этом в ряде видов систем это увеличение может быть на порядки выше (например, для космической станции, которая сдается в эксплуатацию на Земле, а эксплуатируется в космосе). Напомним, что при исправлении ошибки типичное решение менеджера – добавить финансирования и продлить сроки сдачи, решение системного инженера – модифицировать конструкцию.

 

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

Заметим, что недоработка требований чревата крахом системы. На практике около 80% провалов систем происходит из-за недоработки требований, упущений некоторых потребностей стейкхолдеров.

 

Предположим, что некоторый «проблемный» исполнитель может выполнить только 1 свою работу (MX) за 1 день («узкое место» проектов). Задача в том, как распределить имеющиеся проекты по 3-м дням. Упомянутый исполнитель не может выполнять три работы MX одновременно (верхний план на схеме). Для решения задачи условно представим исполнителя станком. Тогда можно задать ему последовательный режим выполнения работ (второй сверху план).

 

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

 

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

 

Для рассмотренного примера есть еще одно решение, предлагаемое школой системного менеджмента. Оно связано с наличием некоторого запаса (буфера) времени. Дело в том, что работа фактически занимает не 1 день. При оценке времени обычно применяется поправка (увеличение), поскольку на практике в конкретных проектах существует множество субъективных факторов. В среднем же работа может быть выполнена, например, за полдня. Тогда все поправки можно объединить в отдельном общем буфере проекта и использовать его в критических (по времени) ситуациях. Таким образом, задачи проектируются последовательными, но по времени вдвое короче, а общий буфер планируется на крайние случаи (см. нижний план). Заметим, что на этом плане каждая MX начинается не сразу за предыдущей MX, а чуть позже – зазор планируется из тех же соображений. Согласно теории вероятностей, вряд ли будет использован весь буфер. Поэтому все заказчики (включая третьего) получат результаты раньше. Даже на простом примере видно, что способов организации графика работ много, и они зависят от требований к системе.

 

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

 

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

 

Лишь упомянутые выше первые две группы требований относятся к инженерии требований.

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

 

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

 

Разобраться во всем многообразии требований помогает онтологический подход. Онтологически требования – это просто описание системы с приписанным к нему деонтическим оператором, модальностью («должно», «можно», «рекомендуется» и т.п.), непосредственно или в контексте, соответствующем модальности. Статус требования как такового определяется приписыванием деонтической модальности к обычному описанию системы. Если, например, есть архитектурное описание, то добавление к нему модальности («это есть baseline to be») превращает описание в требования к архитектуре. Убрав модальность, можно требования обратно превратить в описание. Модели существуют отдельно от их модальности. Далее разрабатывается рабочая документация, которая аналогично может быть превращена в требования рабочей документации.

 

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

 

 

Описываются практики работы с требованиями. Здесь показывается их место в процессе создания систем, перечисляются связанные с практиками международные стандарты, включая рассмотренный в 4-й лекции ISO 15288. Констатируется разнообразие практик в связи с природой систем (например, программно-емкая система, модель бизнеса и т.д.). Дается типовой набор практик требований. П. 2.4.3 – собственно разработка самих требований, причем, как видно из слайда, она занимает не так много места во всей инженерии требований. Показана необходимость обоснования выполнения требований (фактически их значимости), которое имеет собственные практики.

 

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

 

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

 

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

 

Двигаясь дальше, рассмотрим необходимые умения инженера по требованиям.

Инженер по требованиям – это системный инженер, специализирующийся в методах (поддисциплинах) инженерии требований. Он должен быть:

- лидером (работать с конкретными людьми, владеть психотехнологиями);

- социотехником (владеть социальными технологиями – работать с

безличными группами людей);

- инженером (владеть системным мышлением, разбираться в ситуационной

инженерии);

- грамотным человеком в смысле Alan Key (владеть компьютерным моделированием).

 

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

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

 

Кроме того, инженер по требованиям должен быть социотехником. Как социотехник, он ответственен за то, чтобы обнаружить и учесть все (обезличенные) заинтересованные стороны проекта (заказчиков, специалистов, нормативные акты, погоду и т.п.). Заметим, что сюда относятся и разработчики системы, которые являются заинтересованными сторонами по определению. Заинтересованные стороны ожидают, что система реализует их интересы (concerns), и требуют специализированных описаний для каждого из своих интересов. Они ожидают, что для них будут подготовлены экономические, эксплуатационные, инженерные, логистические и другие описания, из которых они поймут, что их интересы удовлетворяются. Можно сказать, что, в отличие от лидера, социотехник работает с «позициями». Это большая работа с людьми, но находящимися в позициях. Например, когда человек находится в позиции заинтересованной стороны, социотехник (инженер по требованиям) должен извлечь требования из этой позиции, заставив его правильно отвечать на правильные вопросы. Рассмотренная выше подробная структура инженерии требований в основном связана с работой именно социотехника.

 

Согласно Alan Key, грамотный человек должен уметь выражать свои мысли доступным ему способом. Способ социотехника – это инструмент формального описания требований, например, так называемые диаграммы целеполагания на компьютере. Инженер по требованиям создает специальное описание проекта (модель на языке диаграмм), в котором отражены заинтересованные стороны и их интересы (цели, намерения) в виде требований. Это описание передается системному архитектору. Поскольку требования заинтересованных сторон обычно противоречивы, ищутся архитектурные решения, снимающие противоречия (такие решения предоставляются архитектором), либо проводятся переговоры между заинтересованными сторонами (представляющими их людьми). В этой ситуации также участвуют лидеры, поскольку сами люди не стремятся участвовать в переговорах, тем более поддерживать на переговорах некую рациональную позицию. За то, чтобы было найдено устраивающее всех решение, и позже по жизненному циклу не возникло социального конфликта, отвечает социотехник. По мере принятия архитектурных (то есть «основных проектных») решений (как средств достижения целей заинтересованных сторон), на модели отражаются также эти решения. Отмечаются показатели, характеризующие достижение принятыми решениями целей заинтересованных сторон – ключевые показатели эффективности проекта.

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

 

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

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

 

В конце прошлого века был создан консорциум для разработки универсального средства описания всех процессов в инженерии. В результате его деятельности в 1997г. была зафиксирована модель данных EPISTLE (European Process Industries STEP Technical Liaison Executive), которая в дальнейшем легла в основу большинства современных PLM (product live cycle management – систем управления жизненным циклом). В стандарте STEP принято объектно-ориентированное моделирование данных. Подход сформулирован так: «что для одного проекта атрибут, то для другого проекта объект». Однако в результате модель распалась на несколько стандартов, каждый из которых описывает свою инженерную область. Каждую из областей описывает собственный Applications Protocol (AP). Разрабатывая протокол описания требований, ему присвоили номер 233, отсюда происходит наименование AP233 (прописано в стандарте ISO 10303). Он дает формат представления требований в компьютере, схему данных, но не содержит методов их обработки. Можно сказать, что AP233 – такой же язык описания архитектуры, как и SysML, только архитектура описывается в несколько других терминах. Из-за ограниченности этот язык не получил широкого распространения на практике.

 

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

выше). В нем, в частности, затруднительно хранить и обрабатывать числовые характеристики.

 

ISO 29148 – стандарт описания практик инженерии требований, который лишь мимоходом описывает собственно артефакты-требования и их группы. Например, он дает рекомендации по формулированию текстовых фраз, из которых состоят требования: «обязательность выражайте как shall, а will избегайте», «синтаксис требования – [условие] [предмет] [действие] [объект] [ограничение] или [условие] - [действие] - [значение]». Он также регламентирует агрегирование таких фраз в списки. Стандарт считает требование объектом и приводит примеры его атрибутов (но не жесткие их форматы). Согласно стандарту, набор требований необходимо сопровождать в ходе жизненного цикла вместе со связанными обоснованиями, решениями (decisions) и предположениями (assumptions). Требования также привязываются к базисам. В итоге можно сделать вывод, что ISO 29148 дает нестрогие рекомендации по организации работы с текстовыми требованиями. Моделирование требований осуществляется только для их валидации, а сами валидированные требования затем остаются в их исходной текстовой форме, модели далее не используются.

 

Группа языков GORE (goal-oriented requirements engineering – целеориентированная инженерия требований) представляет специфический подход к описанию функциональных требований и средств их реализации на основе конечных целей, мотивации, интересов. Он относится к «ранней» инженерии требований, соответствующей началу проекта. Здесь пересекаются 2 типа языков, описывающих 1) цели/намерения + заинтересованные стороны и 2) пользовательские сценарии. Основная идея целеориентированности в инженерии требований состоит в следующем. Требования возникают из-за того, что люди чего-то хотят, у них есть цели. Давайте обсудим цели в сочетании со средствами их достижения. Заодно запишем, чьи эти цели и тогда при разборе развилок в выборе средств будет появляться много традиционных требований. Сюда относится
URN – user requirements notation, в которой используются целеориентированный язык GRL – goal requirements language и UCM – use case maps. Для перехода от инженерии требований к архитектурному проектированию имеется язык ArchiMate. В нем требования к архитектуре задаются дополнением целеполагания (motivational) и полностью соответствуют подходу GORE.

Стандарт ISO 15926 описывает создание распределенного (через Интернет) хранилища любых данных. Он появился после возникновения технически непреодолимых препятствий моделирования жизненного цикла предприятий непрерывного производства группой разработчиков AP221 (ISO 10303). Ввиду выявленных проблем EPISTLE отказался от ограничений принятого в стандарте STEP объектно-ориентированного моделирования данных. Работа консорциума была продолжена, чтобы получить новый стандарт, свободный от недостатков STEP. Стандарт получил наименование ISO 15926. В его основе лежит факт-ориентированный подход, в котором, например, отношения могут служить предметом отношений. Часть 2 стандарта вышла в 2003 году, закрепив модель данных с 201 типом, в терминах которых принципиально можно было бы выразить данные любой предметной области. Наборы классов справочных данных, унаследованные от проекта STEP (то, что было раньше STEPLib) были переработаны и дополнены, и вышли в 2007г. в качестве части 4 ISO 15926. Стандарт предназначен не только для высокоуровневого, но и для полного обмена информацией между любыми вычислительными системами в ходе инжинирингового проекта по всему жизненному циклу – в том числе и обмену требованиями. Кроме того, данный стандарт по факту становится стандартом «семантического веба» (semantic web).

Основным препятствием в использовании стандарта ISO 15926 стало сопротивление ряда фирм-поставщиков программных средств PLM/CAD/CAM и средств инженерного моделирования. Стандарт работает хорошо и может быть использован не только для интеграции программных модулей в рамках продуктов одного поставщика (что фактически произошло с результатом работы EPISTLE), но и программных модулей разных поставщиков. Однако открытость собственных программных систем для включения чужих успешных продуктов не входит в планы ряда поставщиков.

Поэтому на словах они остаются приверженцами ISO 15926, но с технической стороны делают мало. Пользователи же программ PLM/CAD/CAM и средств инженерного моделирования наоборот крайне заинтересованы в появлении мощного стандарта интеграции данных жизненного цикла. И в последние годы они предприняли шаги по реальному использованию ISO 15926.

 

Ключевыми для использования стандарта ISO 15926 являются два обстоятельства: наличие справочных данных конкретной предметной области (особенно в случае российских ГОСТов) и наличие адаптеров конкретного программного обеспечения, данные из хранилища которого подлежат интеграции. Множество российских проектов создания справочных данных ISO 15926 и адаптеров к различному ПО находятся в стадии переговоров и экспериментов. Однако, очевидно, что ситуация с адаптерами и российскими справочными данными кардинально меняется.

 

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

 

Учитывая тесное взаимодействие инженерии требований с архитектурой, профессор Дитц предложил свою схему для демонстрации архитектуры и ее связи с другими компонентами системы. На ней using system construction – это система в операционном окружении, часть в которой занимает (или будет занимать) целевая система, выполняя свой сервис. Согласно этой схеме, исследуя технологию, применяя знания (онтологию), выполняют reverse engineering (обратную разработку) охватывающей системы, чтобы изучить ее и выяснить, какова должна быть функция целевой системы (object system function). Заметим, что терминология здесь немного другая, но ее суть прежняя. Object system function соответствует верхней части «гамбургера». Как принято в системной инженерии, мы начали рассмотрение системы с верхней части «гамбургера» (function design). Справа же – конструкция (construction design).

 

Когда поймут, что такое object system function, то в другой онтологии (справа) – конструкций (материалов, размеров и т.п.) находят решение, с помощью которого можно было бы создать сервис, предоставляемый объектом окружающей системе (слева). Другими словами, архитектура разрабатывается как набор основных принципов конструкции, определяющих функцию. Выполняя далее реализацию с применением соответствующих технологий, создают целевую систему (на схеме она обозначена как object system construction). Этот процесс назван engineering.

 

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

 

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

Предыдущая статья:Жизненный цикл Следующая статья:Практики определения системы – архитектура
page speed (0.1973 sec, direct)