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

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

Понятие жизненного цикла  Просмотрен 234

Тема 3. Понятие жизненного цикла

Понятие жизненного цикла. Пошаговое выделение ресурсов (ICM). Управление жизненным циклом, особенности PLM-систем. Жизненный цикл с точки зрения системного инженера, проектного менеджера, инженера по специальности. Взаимосвязь системной инженерии и программной инженерии. Виды жизненных циклов: последовательный, инкрементальный, итерационный. Формализмы представления жизненного цикла. Типовость и разнообразие жизненных циклов, связь жизненнных циклов разных уровней структуры в составе системы.

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

 

Пусть у нас есть «нечто» – некоторая целевая система (system of interest). Для этого «нечто» существуют системы в операционном окружении. Это такие системы, которые непосредственно связаны с выполнением данной системой ее функции. Их взаимодействие осуществляется посредством интерфейсов. Оно может состоять в передаче информации (туда или обратно), вещества, энергии и т.д. Далее можно сказать, что все это вместе образует общую систему – более высокого уровня, и у нее есть свой стейкхолдер, интерфейсы вовне, функция по отношению к стейкхолдеру (он определяет назначение системы). А у исходной целевой системы есть свой стейкхолдер. Он смотрит на нее, и ему неведомо, что там дальше (выше), и о системе высшего уровня может лишь что-то предполагать. Целевая система, системы в операционном окружении, для него – это все функции. А для того, кто смотрит сверху, это все уже конструкция. Стейкхолдер нижнего уровня может занять так называемую рефлексивную позицию, и попытаться ответить на вопросы «кто я?», «что здесь делаю?». Рефлексивная позиция на схеме обозначается звездочкой. И поскольку он взял себя под контроль, то может вообразить себя на месте внешнего стейкхолдера и попытаться понять, что это за функция (его целевой системы), чему должна удовлетворять. В этой (рефлексивной) позиции важно, что он может найти и дополнительные системы в операционном окружении, которые не были ему видны, когда он рассматривал лишь свою целевую систему. Например, вначале был компьютер, который можно включить. А потом выясняется, что к нему нужен проектор, а потом неплохо бы получить и лектора. Нужен также шрифт, который на проекторе будет всем хорошо виден, и так далее. Это означает, что при рассмотрении некоторой целевой системы уровней рассмотрения может быть много. Для системного инженера важно «удерживать в голове» несколько уровней вверх. То есть у внешней системы в операционном окружении есть еще какие-то системы, и там есть еще граница и еще люди (стейкхолдеры), мыслящие о той системе. Например, парадокс, но ремонтопригодность – это функция не данной системы, а ее окружения. Не в любом окружении одна и та же система ремонтопригодна (например, автомобиль). На необитаемом острове практически любая система не ремонтопригодна. А в хорошей физической лаборатории – все иначе.

<1>

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

 

Классический пример сложной системы, который приводился в книжках по системной инженерии 1957, 1961гг. – радиолокатор. Для тех лет это, безусловно, сложная система. Там есть антенна, передатчик, отображающее устройство – индикатор, летящая наблюдаемая цель, есть расчетный блок, позволяющий вычислить расстояние, генератор, машина для передвижения, был моторчик, крутивший антенну, а еще человек-оператор. В стандарте ISO 15288 приводится пример более современной сложной системы – системы самолета. С ней рассматриваются не только фюзеляж и крыло, но еще и аэропорт, система обеспечения полетов, система, которая подвозит к самолету пассажиров (и эта система соизмерима с аэропортом – агентства, резервирование билетов, транспорт от гостиниц и т.д.). И там где-то есть теперь уже практически незаметный радиолокатор. Такова разница в масштабах мышления системного инженера 50-60 годов и настоящего времени, который легко доходит до понимания, как это все устроено, потому что он достаточно легко рассматривает уровни вверх. Это ключ – многоуровневость и первоначальный взгляд вверх (вместо заглядывания сразу вниз, что идет от интуитивного мышления).

 

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

 

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

Студенты для него – целевая система. Во время обучения она (целевая система) не эксплуатируется, а изготавливается (как на конвейере). А когда она будет эксплуатироваться? Тогда, когда закончится обучение, они устроятся на работу и будут выдавать сервис. Она и сейчас – система (в том же смысле, целевая), но у нее нет операционного окружения. Заметим, что здесь для иллюстрации был выбран один из возможных холонов в одной из возможных холархий. Вменены цели, стадия жизненного цикла, по которой систему продвинет преподаватель. Далее она поступает на следующую обработку, и в какой-то момент система будет готова и сможет приносить пользу. Обеспечивающей системой для деталей, изготовляемых на токарном станке, являются токарный станок, токарь, тот, кто принес заготовку, тот, кто унесет деталь. А что может относиться к операционному окружению? Некоторый винтик изготавливается, чтобы быть вкрученным в ракету, ракета улетит на Марс, далее на Марсе марсоход будет развернут. В этот момент начинает выполняться функция и, таким образом, появляется операционное окружение. А до этого момента и далее – идет процесс продвижения по жизненному циклу. Это продвижение осуществляет обеспечивающая система (enabling system), она создает возможность существования самой целевой системы.

 

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

 

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

 

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

 

Чем же различаются стадии жизненного цикла системы? Жизненный цикл – это период времени, и стадии – это периоды времени, т.е. у них одинаковый «онтологический статус». Хорошее определение стадии дано в стандарте ISO 24744, который, кроме прочего, посвящен жизненным циклам систем и методам их описания. Стадии отличаются тем, что называется cognitive framework («подход, который у тебя в голове»). Другими словами, на разных стадиях меняется представление о системе. Если система находится в разных состояниях, то, скорее всего, это разные стадии. Если операции, производимые с системой, различны (связаны с различным профессионализмом), то, как правило, и это разные стадии жизненного цикла. В «колбасках» часто рисуют когнитивные фреймворки следующего содержания: замысел, проектирование, изготовление, интеграция (реже), эксплуатация (выделенная стадия), вывод из эксплуатации. Отметим важный момент: поскольку стадия – это cognitive framework (а cognitive может относиться к разным «головам», то есть исполнителям), то некоторые стадии жизненного цикла могут существовать параллельно (например, эксплуатация + поддержка). В стадии эксплуатации могут работать операторы, занимающиеся обеспечением работоспособности системы (например, следить за параметрами – температура, влажность, пыль и т.п.). В стадии поддержки актуальны доставка топлива, запчастей. Параллельно могут осуществляться техобслуживание и ремонт. Сверху могут вклиниваться короткие стадии – модернизации. Кстати, и замысел системы как стадия может длиться почти на протяжении всего жизненного цикла.

<>

Существуют различные способы и нотации для изображения жизненного цикла системы и его стадий. Одна из них («вобла») используется фирмой «Инвестлаб» (автор – А.И. Левенчук). Если система изображается лишь в ее операционном окружении (как в начале лекции), то нет возможности изобразить и соответственно продумать то, как она будет изготавливаться. Можно будет лишь обсуждать, как она будет работать. Если систему требуется изготовить, то должно быть соответствующее обсуждение и изображение. Можно сказать, что в практической системной инженерии 99% обсуждений занимает процесс изготовления. Использование оси времени и изображение стадий вдоль нее позволяют такое осуществить. Количество изображаемых стадий может быть различным (выше были приведены стадии типового цикла).

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

Жизненный цикл и управление им – понятия не простые, как это может показаться на первый взгляд. Предположим, что мы работаем с системой (человеком), которая в конкретной темпоральной части (холоне) выполняет конкретную функцию (например, как специалист), и при этом проходит свой жизненный цикл. В других холархиях он может занимать другие холоны (семьянин и т.п.). Предположим, что он работает («крутит ручку»), но заболел. Приходит другой работник и начинает крутить ручку за него. Вопросы: это тот же работник? Та же система? Вспоминая предыдущую лекцию, можно сказать, что смотря для кого (или чего) он крутит ручку. Например, специалиста можно считать текущим модулем, установленным в данный слот. Тогда общая система – та же. Это непростые вопросы, потому что жизненный цикл – сложное понятие. Одно из первых, что делает системный инженер по отношению к целевой системе – создает систему управления жизненным циклом. Если им не управлять, то с системой никогда и ничего не произойдет. Однако данный аспект неоднозначен. Если жизненный цикл – отрезок времени, то как можно им управлять? Может быть, тогда нужно управлять системой? – Нет, ведь она пассивна как целевая система! Тогда, может быть, управлять обеспечивающей системой, которая ведет целевую систему по жизненному циклу? В результате поиска ответов на эти и ряд других вопросов, в системной инженерии было принято, что нужно все же управлять жизненным циклом целевой системы. Системы управления жизненным циклом мы рассмотрим позднее. Для них есть специальная аббревиатура – PLM (product live cycle management).

 

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

<>

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

 

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

 

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

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

 

Рассмотрим некоторые вопросы управления жизненным циклом. Вообще говоря, в системной инженерии основным методом такого управления является incremental commitment model (ICM). Бывают разные виды жизненных циклов, отличающиеся в основном процедурами и направлением передачи результатов прохождения стадий. Пусть, например, система идет на эксплуатацию (переходит в эту стадию), и есть baseline («as built»). Предположим, что этот конфигурационный базис показывает необходимость небольшой доработки. Она выполняется, и в чертежи вносятся необходимые изменения. Далее на стадию эксплуатации поступает система с измененными чертежами. Кстати, на практике может быть рассогласование – что-то физически изменили, а в чертежи изменения не внесли. Например, есть типовой проект Боинга, но нет даже двух идентичных самолетов. Управление конфигурацией и управление изменениями – это основное, что обычно осуществляется в системах управления жизненным циклом. Управление основано на базисах (baselines), которые представляют систему (в каком-то ее проектном виде) на разных стадиях жизненного цикла. Переход этого базиса с одной стадии на другую означает, что «жизнь изменилась». Если на какой-то стадии работа велась только с бумагами в офисе, САПРами и «воздушными замками», то на следующей стадии, возможно, будет работа с бетоном, в кирзовых сапогах, где-нибудь в условиях вечной мерзлоты. При этом «в голове» возникает другой «cognitive framework», и новые обсуждения проекта существенно отличаются от предыдущих. Например, на стадии замысла – это переговоры с инвесторами, работа над требованиями и т.д. Далее выдают соответствующий актуальный базис и переводят систему на следующую стадию. В результате появится инвестиционная декларация. Если меняется базис, то меняется окружение, включая документы, предметную область, методы. Иногда при этом меняются и руководители, т.к. на разных стадиях требуются различные навыки и методы управления. Часто меняют также и системных инженеров – требуется другой их тип. Например, один инженер хорошо знает САПР, другой хорошо интегрирует систему в железе. С другой стороны, все они продолжают совместную работу. Управление конфигурацией (учет, проверка, что все целостно) – это одно из направлений, из-за которых системных инженеров считают бюрократами. В отличие от них, инженеры по специальностям – «творческие люди», поскольку они что-то создают, а управление, контроль – это типично бюрократические функции.

 

На рисунке (автор А.И. Левенчук) изображены две системы, с их стадиями, названными по конечным продуктам этих стадий (согласно одной из распространенных концепций именования).

 

Здесь показано, что в компьютерной системе управления жизненным циклом (PLM-системе) имеются 3 вида моделей: enabling system – некоторое предприятие, создающее целевую систему; system of interest – целевая система, т.е. основная в данном рассмотрении; system in operation environment – система в операционном окружении, т.е. взаимодействующая с целевой системой в процессе ее эксплуатации. Наличие на диаграмме слова service подчеркивает дуализм систем и сервисов. Не следует путать термины процесс системы и жизненный цикл, несмотря на то, что каждый из этих терминов связан со временем. Если моделируется система, то имеются structure & behavior, а системный инженер работает с социо-техническими системами. Это означает, что в жизненном цикле системы учитывается роль людей. Когда люди не принимаются во внимание, говорят о физической системе. Важный момент: системный инженер всегда работает с людьми, а там невозможно адекватное применение физических моделей. Например, если вывести какую-то статистическую формулу, описывающую поведение людей и дать ознакомиться с ней большинству, то они статистически ее опровергнут. В этом основное отличие моделей физических процессов от моделей социо-технических систем.

 

Рассмотрим некоторые особенности работы PLM-систем. Пусть есть enabling system и в ней работают инженеры. Они обеспечивают issue (выпуск) некоторй трубы для некоторого резервуара. Предположим, выясняется, что для трубы принят допуск температуры (например, 100C), при котором она в эксплуатации расплавится от жидкости резервуара. Таким образом, возникает проблема, и невозможно определить, кто ответственен за ошибку. В таких случаях системный инженер выдает requirement change request (RCR, запрос о необходимости изменения), чтобы специалисты текущей стадии разобрались и устранили недостаток (с трубой либо жидкостью резервуара). Все это происходит в enabling system. Вообще резервуаров и труб много, например, на маленькой насосной станции или большом химическом заводе. О какой трубе и каком резервуаре может идти речь в рассматриваемой ситуации? Работа обеспечивающей системы всегда направлена на целевую систему. Есть агент (в enabling system), действие (action) и то, на что оно направлено (system of interest).

В каждой PLM-системе существуют 2 основных объекта. Первый – репозиторий, в котором хранятся все модели (system of interest – structure & behavior, systems of operating environment), все знания о проекте, включая baselines, изменения и прочее. Второй объект – модель обеспечивающей системы (workflow, в терминологии PLM – последовательность выполняемых действий) – агенты, совершающие некоторые действия. Разработаны специальные языки и диаграммы, описывающие действия агентов, есть память (хранилище данных), в которой это хранится. Модель enabling system в PLM-системе представляется в той же модели данных и базе данных, что и модель самой целевой системы. Чем же они отличаются? Тем, что интерпретатор (исполнитель, executer, «движок») выполняет модель enabling system как программу. Для system of interest часть structure используется как данные – показывается на экране. А все остальное (behavior и systems in operating environment) – моделируется (simulation). Таким образом, есть три вида выполнения, но компьютерная модель у них – общая. В структурной ее части она выглядит как первая схема (в начале лекции), в поведенческой, в том числе и для enabling system – как вторая схема (действия во времени). Проект пассивен, его выполнение – активно. В системе управления жизненным циклом осуществляется связка моделирования enabling system и моделирования system of interest.

На лекции 1 сопоставлялись две профессиональные области – системная инженерия и проектный менеджмент. Они соприкасаются, но имеют и существенные различия. При этом невозможно обсуждать работу системного инженера без обсуждения работы проектного менеджера. Одна из причин в том, что целевой системе всегда сопоставляется enabling system, с моделью которой непосредственно связан системный менеджер. Он хорошо ее знает, но не имеет представления, какие объекты существуют в модели ниже. В свою очередь, системный инженер хорошо знает нижнюю часть диаграммы (от system of interest), но понятия не имеет о многом из того, кто и что может сделать в enabling system. Следовательно, им необходимо работать вместе. Линия action и команды по ней осуществляются при участии обоих. Системный инженер, зная только модели целевой системы и ее окружения, ничего не смог бы сделать для их реализации. Поэтому он моделирует обеспечивающую систему. Системный менеджер не в состоянии отдавать команды (action), потому что у него нет аргументов (содержания) этих команд. Но он может обеспечить финансирование системы и другие ресурсы. У него другая картинка и стадии жизненного цикла.

 

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

 

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

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

 

Основываясь на такой тенденции, Richard J. Mayer (сотрудничавший ранее с Г.Бучем в развитии ООП) с соавторами создали новую дисциплину situational method engineering («ситуационная инженерия методов»). Она пытается построить методологию переноса методов из одних ситуаций (например, программирование) в другие ситуации (например, системная инженерия). Некоторый известный метод разбивается на мелкие части, называемые компонентами (виды рабочих продуктов, виды деятелей, виды стадий жизненного цикла и т.д.). Эти части вместе с компонентами других методов хранятся в «библиотеке». Рассматривая новую ситуацию, пытаются из компонент собрать новый метод (как из конструктора), который будет работать в этой ситуации. Сама системная инженерия во многих случаях работает как ситуативный метод. И данный метод в первую очередь определяет вид жизненного цикла, по которому пойдет система.

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

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