Iso 15288 процессы жизненного цикла систем

Iso 15288 процессы жизненного цикла систем thumbnail

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

Совершенно случайно, читая материалы по ISO 15288, я увидел схему «System interaction with Typical Enabling Systems» (оригинальный вид схемы намеренно приведен только в конце статьи), в которой достаточно наглядно изображены:

  1. виды систем, задействованных в создании и обеспечении работы целевой системы
  2. связи этих систем с целевой системой.

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

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

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

Я адаптировал идею жизненного цикла применительно к рассматриваемой предметной области бизнес-систем:

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

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

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

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

  1. Производственная система – это тоже система, которая проходит через свои стадии жизненного цикла.
  2. Стрелкой показана связь между системами, а именно: Производственная система на стадия «Функционирование» обеспечивает Продукту стадию жизненного цикла «Производство». Или, если говорить проще: на схеме отражен факт, что Производственная система производит Продукт.
  3. Производственная система частично обеспечивает Продукту стадия «Разработка». Объяснение какой смысл в это вкладывается, будет дан ниже.

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

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

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

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

Важные факты, которые отражены в данной схеме:

1) Во-первых, на этой схеме уже стали видны границы типовой бизнес-системы, которую в данном случае можно назвать системноинженерным термином «система систем» (SoS):
«По сути дела, всякий раз, когда ряд независимых и пригодных к работе систем объединяется для приобретения возможностей, выходящих за пределы суммы возможностей отдельных систем, мы получаем систему систем. Разумеется, уровень комплексирования может существенно различаться. На одном конце спектра находится SoS, полностью интегрированные на самых ранних стадиях разработки, когда отдельные системы, хотя и способные функционировать независимо, проектировались чуть ли не исключительно для SoS. На другом конце мы встречаем системы, слабо связанные для временного решения локальной задачи без каких-либо формальных оснований, кроме согласия своих владельцев», [А.Косяков «Системная инженерия», с.119].

Я думаю, и такие, и такие типы SoS встречаются в бизнес-системах. К этому хотелось бы добавить, что бизнес на верхнем уровне представления- это не «жесткая» иерархическая система, как принято считать, а именно система систем, т.к.:

а) системы в ней находятся в достаточно специфичных связях, а не в связях «Часть-Целое»:

  • Система развития замышляет, проектирует и разрабатывает Производственную и Обслуживающую систему;
  • Обслуживающая система занимается «ремонтом» Производственной системы.

В данном случае можно также вспомнить теорию деятельности (например, СМД-методологию Г.П. Щедровицкого) и сказать, что системы является объектами и средствами в некоторых деятельностях. При этом их роли могут меняться. Например, в деятельности по созданию Производственной системы, Производственная система является объектом, а Система развития – средством деятельности. Когда Производственная система построена, то она становится средством в деятельности по производству Продукта (или по производству денег в виде прибыли, если смотреть в суть дела)

Читайте также:  Жизненный цикл распределительного трансформатора

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

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

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

Факты, которые не отражены в этой схеме:

  1. На практике Система развития в цикле развития неоднократно выполняет стадии «Замысел-Проектирование» для Продукта, Производственной и Обслуживающей систем, а также «Производство» для Производственной и Обслуживающей систем.

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

  2. Кто занимается стадиями «Замысел-Разработка-Производство» для Системы развития?

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

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

  3. Не отражено как происходит списание Производственной и Обслуживающих систем, т.к. на практике это бывает достаточно редко.

Вариант для бизнеса, который занимается услугами/предоставлением сервиса приведен ниже (Рис.7):

В данном случае можно говорить о том, что:

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

Дополнительно можно рассмотреть расширение приведенной на Рис.6 схемы бизнес-системы для двух случаев.
Первый случай, когда есть необходимость сервисного обслуживания Продукта. В этом случае в должна быть создана еще и Сервисная система для Продукта:

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

Очевидно, что при необходимости обеспечить стадию «Списание» Продукта необходимо построить еще и Утилизационную систему. Примером продукта, когда это необходимо, является в настоящее время автомобиль.

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

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

Заключение

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

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

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

Приложение. Оригинальная схема из ISO 15288

Именно этот вариант изображения схемы взят из документа ISO/IEC TR 24748-1 «TECHNICAL
REPORT. Systems and software engineering — Lifecycle management. Part 1» В практически таком же виде он фигурировал в ISO/IEC 15288:2002, хотя из последней редакции 2015 года эта схема была вынесена в руководство ISO/IEC TR 24748.

Читайте также:  Виды жизненных циклов примеры

Дмитрий Пинаев, ГК «Современные технологии управления»

Источник

Обозначение: ГОСТ Р ИСО/МЭК 15288-2005Обозначение англ: GOST R ISO/IEC 15288-2005Статус:замененНазвание рус.:Информационная технология. Системная инженерия. Процессы жизненного цикла системНазвание англ.:Information technology. System engineering. System life cycle processesДата добавления в базу:01.09.2013Дата актуализации:01.01.2021Дата введения:01.01.2007Дата окончания срока действия:01.11.2017Область применения:Стандарт устанавливает общие основы для описания жизненного цикла систем, созданным людьми, определяет детально структурированные процессы и соответствующие терминологию.Оглавление:1 Область применения
   1.1 Назначение
   1.2 Область распространения
   1.3 Ограничения
2 Соответствие
   2.1 Предполагаемое использование
   2.2 Полное соответствие
  2.3 Адаптированное соответствие
3 Нормативные ссылки
4 Термины и определения
5 Процессы жизненного цикла системы
   5.1 Введение
   5.2 Процессы соглашения
      5.2.1 Введение
      5.2.2 Процесс приобретения
      5.2.3 Процесс поставки
   5.3 Процессы предприятия
      5.3.1 Введение
      5.3.2 Процесс управления средой предприятия
      5.3.3 Процесс управления инвестициями
      5.3.4 Процесс управления процессами жизненного цикла системы
      5.3.5 Процесс управления ресурсами
      5.3.6 Процесс управления качеством
   5.4 Процессы проекта
      5.4.1 Введение
      5.4.2 Процесс планирования проекта
      5.4.3 Процесс оценки проекта
      5.4.4 Процесс контроля проекта
      5.4.5 Процесс принятия решений
      5.4.6 Процесс управления рисками
      5.4.7 Процесс управления конфигурацией
      5.4.8 Процесс управления информацией
   5.5 Технические процессы
      5.5.1 Введение
      5.5.2 Процесс определения требований правообладателей
      5.5.3 Процесс анализа требований
      5.5.4 Процесс проектирования архитектуры
      5.5.5 Процесс реализации элементов системы
      5.5.6 Процесс комплексирования
      5.5.7 Процесс верификации
      5.5.8 Процесс передачи
      5.5.9 Процесс валидации
      5.5.10 Процесс функционирования
      5.5.11 Процесс обслуживания
      5.5.12 Процесс изъятия и списания
6 Стадии жизненного цикла системы
   6.1 Введение
   6.2 Модели жизненного цикла
   6.3 Стадии жизненного цикла
Приложение А (обязательное) Процесс адаптации
Приложение В (справочное) Стадии жизненного цикла
Приложение С (справочное) Взаимосвязь между ИСО/МЭК 15288 и Изменением № 1 к ИСО/МЭК 12207
Приложение D (справочное) Концепции
БиблиографияРазработан: МИРЭА
Подкомитет Системная и программная инженерия ТК 22 Информационные технологии
3 ЦНИИ Минобороны России
Российская академия ракетных и артиллерийских наук
Международный центр по информатике и электронике
ЦНИИ РТКУтверждён:29.12.2005 Федеральное агентство по техническому регулированию и метрологии (476-ст)Издан: Стандартинформ (2006 г. )Расположен в: Техническая документация
Электроэнергия

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ

Программное обеспечение

Экология

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ

Программное обеспечение

Строительство

Стандарты

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

Информационные технологии. Машины конторские
Нормативные ссылки:

  • ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»
  • ГОСТ Р 1.5-2004 «Стандартизация в Российской Федерации. Стандарты национальные Российской Федерации. Правила построения, изложения, оформления и обозначения»
  • ТК 22 «Типовая технологическая карта на выполнение работ по герметизации швов металлических и железобетонных конструкций зданий и сооружений с применением композиции “УТК-М-3″»

Источник

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

Система — это набор взаимодействующих частей, у которых есть цель. В системе явно вводится наблюдатель, с точки зрения которого выделяется интересующая-система (system-of-interest) и жесткое определение границ системы. Сервис — это тоже система (или сервис производится системой). Обеспечивающая (enabling) система — это система, которая пропихивает system-of-interest по этапам жизненного цикла (производственная система, ремонтная система для систем-продуктов и т.д.). Элементы системы могут быть описаны отдельно как системы, поэтому их можно заказать по контракту.

Все не так просто: этот заход существенно отличается от захода системной инженерии” стандарта ISO 26702, который описывает разработку системы, а не ее жизненный цикл. Впрочем, отличия описаны в самом тексте стандарта ISO 15288 (в приложении F).

Жизненный цикл — эволюция системы, продукта, сервиса, проекта или другой сущности, порожденной людьми, от концепта до отхода ее от дел (life cycle — the evolution of a system, product, service, project or other human-made entity from conception through retirement. [ISO/IEC 12207:2007 and ISO/IEC 15288:2007] ).

Модель жизненного цикла — относящийся к жизненному циклу фреймворк процессов и действий (которые могут быть организованы по стадиям), который также действует как общая рекомендация для общения и понимания. (life cycle model — a framework of processes and activities (which may be organized into stages) concerned with the life cycle, which also acts as a common reference for communication and understanding. [ISO/IEC 12207:2007 and ISO/IEC 15288:2007] )

“Каждая система, независимо от сорта или размера, следует какой-то модели жизненного цикла от ее начальной концептуализации до конечного отхода от дел. Проход системы в любой последовательности и любым способом через части модели, называется жизненным циклом. Модель жизненного цикла, тем самым, это концептуальное сегментирование определения нужды в системе, ее создания как продукта или сервиса, и ее использования, эволюции и выкидывания. Модель жизненного цикла системы обычно сегментирована на стадии, чтобы помочь планированию, обеспечению, функционированию и поддержке интересующей-системы. Эти сегменты обеспечивают упорядоченное продвижение системы через установленные барьеры принятия решений с целью уменьшить риск и убедиться в достаточности прогресса. Нужда принять решение согласно специфическому критерию перед тем как система сможет перейти на следующую стадию — это наиболее важный довод для использования модели жизненного цикла” — из проекта ISO TR 24748. Эти тексты невозможно адекватно перевести на русский язык!

Читайте также:  Редукция гаметофита в жизненном цикле голосеменных

Оттуда же (ISO TR 24748) — апдейт процессного подхода. Процессы имеют собственника (ответственного за их выполнение), модульны (т.е. каждый процесс посвящен одной и только одной функции, а число интерфейсов между процессами держится минимальным. Функция процесса описывается как его специфическая цель, продукты/outcomes и набор действий). Процесс по ходу жизненного цикла может использовать другой процесс для специализированной функции. Каждый процесс вызывается из организационного фреймворка. Если процесс A вызывается процессом B, и только процессом B, то A принадлежит B. Если функция вызывается более чем одним процессом, то эта функция сама становится процессом. Должно быть возможным верифицировать любую функцию в модели жизненного цикла. Каждый процесс должен иметь внутреннюю структуру, достаточно определенную, чтобы быть выполнимым. Процесс должен быть описан так, чтобы к нему можно было применить стандарт проверки его выполнения ISO 15504.

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

Контрактации:
— приобретения
— поставки
Организационные, обеспечивающие проектность:
— управления моделью жизненного цикла
— управления инфраструктурой
— управления портфелем проектов
— управления человеческими ресурсами
— управления качеством
Проектные (не-инжиниринговые):
— Управления проектами
   — Планирования проекта
   — Оценки проекта и контроля
— Поддержки проектов
   — управления решениями (управленческими!)
   — управления рисками
   — управления конфигурацией
   — управления информацией
   — измерений (ISO 15937)
Технические (собственно работа, а не ее организация):
   — Определения требований заинтересованных лиц
   — Анализа требований
   — Архитектурного проектирования
   — изготовления
   — Интеграции
   — Верификации
   — Перехода
   — Валидации
   — Функционирования
   — Обслуживания
   — устранения

Это не стадии жизненного цикла, это именно процессы. А стадии могут быть любыми, например:
Для системы (ISO 15288):
— концепт
— разработка
— производство
— эксплуатация
— поддержка
— вывод из эксплуатации
Для софта (ISO 12207):
— концепт
— разработка
— сопровождение
— вывод из эксплуатации
Для хардвера:
— концепт
— проектирование
— изготовление
— функционирование и обслуживание
— вывод из эксплуатации
Для людей (ISO 18529):
— определение скиллов
— покупка
— тренинг
— использование скилов и приобретение опыта
— увольнение
Для зданий:
— эскиз
— проектирование
— получение разрешения
— строительство
— функционирование и обслуживание
— вывод из эксплуатации
Для процессов:
— определение продукта (output)
— рисование прямоугольников и стрелочек (flowcharting)
— оформление
— пилотное использование
— использование и улучшение
— вывод из эксплуатации
Для естественных сущностей (вода, минералы и т.д.):
— приобретение
— разработка
— эксплуатация
— вывод из эксплуатации

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

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

Такая жесткая бюрократия наводится на все творчество криэйторов — которые, конечно, взвывают от этого, но зато построенные ими мосты имеют много меньшую вероятность обвалиться, а весь цикл разработки занимает много меньше времени — если учесть всю экономию от более простого внесения изменений в проект. Все эти требования стандарта просто отражают современную практику, и вряд ли могут быть реализованы без информационной модели целевой системы (system-of-interest).

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

Особое внимание нужно уделить нормативному закреплению в современных стандартах тренда на перетягивание методологий создания софта в методологии создания любых рукотворных продуктов и сервисов. Так, разработанная для софтовых проектов проверка выполнения процессов рутинно рекомендуется для проверки выполнения процессов на любом производстве — и так далее по всему списку. Конечно, разница пока признается (например, отдельно есть “общий” ISO 15288 и отдельно — софтовый ISO 12207), но далее действует замечание, что “все сложные системы стремительно становятся с существенной софтовой компонентой” — и замышлять, проектировать, разрабатывать, эксплуатировать и выкидывать их нужно так же, как софт. “К чему бы ни прикоснулся компьютер, то само становится компьютером”.

Источник