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

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

Практики воплощения системы  Просмотрен 256

 

Тема 8. Практики воплощения системы.

«Вынос в реальность». Планирование и изготовление системы. Системная интеграция и ее роль. Способы реализации. Верификация и валидация, V-диаграмма. Целеориентированная инженерия и инженерные обоснования. Стандарт ISO 15026. Выбор вида жизненного цикла. Ошибки взаимодействия менеджеров и инженеров. Метод ICM, его обоснование, особенности и преимущества. Проблема интеграции данных жизненного цикла и стандарт ISO 15926.

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

 

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

 

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

Планирование систем осуществляется следующим образом.

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

 

В реализации систем можно наблюдать 2 противоположных процесса. Первый – это создание производства (завода) на месте сборки (additive manufacturing), то есть там, где в дальнейшем система будет эксплуатироваться. Например, робот, укладывающий трубы, может загнуть и приварить трубу сразу на месте укладки. Данный способ позволяет экономить на доставке материалов. Вторая тенденция – противоположная. Она состоит в стремлении как можно больше компонентов системы изготовить в стационарном производстве, а на месте эксплуатации ее только собрать (например, дом из крупных запчастей, а не кирпича). Это модульное производство, оно экономит на процессе сборки, который в данном случае осуществляется быстро и не требует большого числа рабочих и другого соответствующего обеспечения. Оба способа предварительно требуют соответствующего тщательного определения системы. Additive manufacturing осуществляется таким образом: предварительно печатается несколько моделей, чтобы убедиться, каким будет результат. Второй способ требует большего моделирования. Примером может служить строительство олимпийских объектов в Китае (стадион-гнездо, бассейн). При модульной сборке бассейн настолько прочен, что даже если его поставить на бок, он все равно будет стоять.

 

Современная инженерия такова, что основная работа осуществляется на стадии определения системы (system definition), после чего реализация системы (system realization) становится делом техники (причем, высоко автоматизированной). Современная системная инженерия – это «семь раз отмерь, один – отрежь», в ней сначала думают, а потом без проблем делают.

 

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

 

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

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

 

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

 

Один из важных видов артефактов, с которым работают системные инженеры – это обоснования. Они тесно связаны с целеориентированной инженерией требований (см. также Лекцию 5). Все требования должны быть обоснованы.

 

 

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

 

Assurance case (можно перевести как «обоснование») – имеет собственные нотации (GSN, CAE). Эти нотации имеют мало отличий от архитектурных нотаций (Archimate, BMM). Некоторые отличия состоят в следующем. Когда речь шла о требованиях, говорилось, что имеются цели и средства. Средства – это нечто из конструкции, а цели – это функции, которых необходимо достичь. В доказательствах многое аналогично, однако цели часто называются claims (заявления, декларации), средства – evidence (основания, доказательства). Основное отличие в том, что добавлен третий элемент – аргументы. С помощью этих элементов могут быть представлены различные доказательства – от противного, методом исключенного третьего, экспертными оценками, вероятностно, статистически, аргументацией и т.д.

 

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

 

Необходимость разработки обоснований закреплена стандартом ISO 15026. В ходе работы над этим стандартом было проанализировано 15–20 типов доказательств. Как итог – признано, что данный стандарт является одним из основных в системной инженерии. Рекомендации стандарта таковы. Case – это в переводе «дело». Начиная работать над проектом (левая ветка V-диаграммы, см. выше), необходимо создавать это дело, то есть все обосновывать. Переходя на правую ветку (от теоретической части к физической), нужно все тестировать, проводить многократные испытания –подтверждать на практике обоснования, которые ранее были доказаны теоретически.

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

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

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

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

По-видимому, истина где-то посередине. На практике одним из перспективных подходов к организации жизненного цикла оказывается ICM (incremental commitment model) – модель пошагового выделения ресурсов. Стандарт ISO 15288 обязывает разработчиков в самом начале проекта определиться с типом жизненного цикла (объявить, записав этот факт), однако никак не регламентирует данный выбор. Определить жизненный цикл – это значит определить дисциплины (практики) и для них определить стадии. Вспомним, например, «горбатую диаграмму».

 

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

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

 

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

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

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

 

Далее – о самом методе ICM. Его пытались создать как нечто более гибкое, чем «водопад», но все же со строгой организацией.

 

 

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

 

 

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

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

 

Рекомендации по выбору типа жизненного цикла таковы. Целесообразно планировать «водопад» в стандартных разработках, которые выполнялись неоднократно и соответственно содержат немного рисков. При этом достаточно оставить минимальный набор decision gates. Если же проект выполняется не в первый раз, но возникают какие-то новшества (например, сменился подрядчик), то рекомендуется добавить decision gates. Другими словами, при повышении рисков необходимо чаще собирать и проверять конфигурации. Если же рассматривается новый проект (например, исследовательский), то следует добавить (или увеличить) стадию моделирования. Кроме того, полезно ввести стадию создания прототипа (или «претендотипа» – макета) и пересмотры к ней. Как показывает практика, в процессе испытания прототипа могут появиться дополнительные требования к системе (например, изменятся размеры). Проводя параллель с программной инженерией, можно заметить, что программисты нередко начинают работу с создания «пустого» интерфейса пользователя, который после его обсуждения с самим пользователем может привести к пересмотрам функциональности программы.

 

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

 

Рассмотрим еще раз картинку (ниже), которую ранее обсуждали в Лекции 7 (о корпоративной архитектуре). Она актуальна для любой другой архитектуры в системной инженерии, и не только архитектуры, а и, например, для рабочих чертежей, станков с ЧПУ, то есть в специальной инженерии. Она демонстрирует сложность интеграции различных составляющих в системе, в том числе людей в разных позициях. В настоящий момент речь пойдет о современном подходе к интеграции различных данных, появляющихся на протяжении всего жизненного цикла. Жизненный цикл при этом понимается так, как изображено на предыдущей таблице. Данные могут появляться в любой точке таблицы, то есть на любой стадии и в любой практике. Разработчики мыслят разными категориями, отражают эти мысли в программном обеспечении, и в результате появляются данные, несовместимые между собой. При этом проект остается общим, а за его интеграцию несет ответственность системный инженер.

 

Выход состоит в разработке компьютерной онтологии, охватывающей семантику всех данных. Этой проблеме, ее постановке и решению, посвящен стандарт ISO 15926. Подобная проблема уже рассматривалась в Лекции 5, а сегодня обсудим еще некоторые вопросы в данном направлении, а именно – интеграцию данных на примере жизненного цикла.

На диаграмме показаны различные стадии жизненного цикла, порождаемые данные и их типы (включая БД производителей, каталоги комплектующих для системы), а также необходимые связи между данными. Кроме классов (типов), на схеме можно увидеть их представителей с конкретными серийными номерами. Это означает, что на схеме учтены сделанные закупки, возможно, оплаченные. С другой стороны, сохранены ссылки на каталоги, что позволяет при необходимости заменить любой экземпляр. Такая форма записи достаточно формальна, чтобы ее можно было ввести в компьютер для обработки. Фактически это некоторый аналог схемы базы данных, который позволяет описать весь проект в их терминах. Особенность в том, что все эти данные исходно расположены в различных местах. Более того, они соответствуют разным стадиям, поэтому могут быть разнесены во времени. Однако их и не нужно хранить вместе. Представленный подход позволяет описать схему всех данных жизненного цикла и их связи, отношения (например, части с целым), независимо от времени появления (вспомним 4D extensionalism – Лекция 2). Это необходимо для управления информацией в рамках целой системы. Подход используется в современных проектах различного масштаба. Ниже представлен еще один пример.

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

Предыдущая статья:Системы систем. Организационная инженерия Следующая статья:Системная инженерия ПО
page speed (0.0278 sec, direct)