Характеристики различных представлений жизненного цикла системы и его контрольные ворота



В одной из статей о Системном Инжиниринге [1] мы дали понятие о концепции жизненного цикла (ЖЦ) системы и эта статья может стать ее продолжением.

Нужно понимать, что выбор того или иного представления, или модели, ЖЦ зависит от многих параметров системы или проекта. Часто, особенно в сложных системах, могут применяться разные модели на разных этапах развития системы или для разных подсистем одной большой системы. Для того, что стало более понятно, как и в каких случаях использовать ту или иную модель можно свести все данные в одну таблицу. Это будет полезно как для практических целей в повседневном использовании системными инженерами, так и целей обучения. В таблице 1 применены следующие краткие обозначения для указания на модель ЖЦ: В — модель «водопад», И — инкрементальная модель, Э — эволюционная модель, С — спиральная модель. Символом «V» обозначаем применимость данной модели для данной характеристики системы. Отсутствие «V» не означает что данную модель вовсе нельзя применять, но для этого случая она менее удобна.

Таблица 1

Выбор модели ЖЦ по заданным критериям

Характеристики	Критерии	В	И	Э	С
Изменения в существующих системах или для полевых условий	Малые и средние изменения	V			V
	Крупные изменения		V	V
Частота ожидаемых изменений	Низкая	V	V	V	V
	Средняя		V	V	V
	Высокая			V
Ожидаемые величины требуемых изменений	Низкая	V	V	V	V
	Средняя		V	V	V
	Высокая			V
Применение технологий	Существующие технологии	V	V	V	V
	Новые технологии		V	V	V
	Будущие технологии (внутри ЖЦ)		V	V
Предполагаемый объем требуемых изменений (широта)	Малый	V	V	V	V
	Средний	V	V	V	V
	Большой		V	V
Возможность смягчить риск в рамках модели	Низкая	V			V
	Средняя	V	V		V
	Высокая		V	V
Степень готовности требований (насколько полно сформированы требования)	Высокая	V	V	V	V
	Средняя		V	V	V
	Низкая		V	V

Развитие любой системы прогрессирует от абстрактных необходимостей до готового продукта с функциями и формами. Каждая модель ЖЦ характеризуется фазами и определенными мероприятиями [1]. И для должной отработки выбранной модели или моделей нам нужны определенные «контрольные ворота» (в том смысле, что «ворота» могут или не могут пропустить развитие системы далее), по которым мы можем судить о завершении того или иного этапа или фазы ЖЦ. Такими контрольными воротами могут быть акты анализа и решающие точки «готов/не готов».

– Акты анализа изучает поставляемые промежуточные продукты и определяет готова ли система перейти к следующей фазе;

– Точка «готов/не готов» определяет необходимость решения о продолжении работы над системой на основании заданных критериев.

Причем управляющие точки «готов/не готов» могут быть включены в частные акты анализа.

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

Итогом самого первого этапа развития системы — определении концепции, может стать Анализ Системных требований (АСТ), по которым можно судить все ли требования системы определены и определены ли они правильно. Достоверность АСТ во многих случаях субъективна и зависит от компетенции специалистов его составивших. Далее, на стадии разработки могут потребоваться частные Анализы Сегментных Требований для уточнения требований подсистем. Во время разработки дизайна системы может быть потребован Анализ Предварительного Дизайна (АПД), а по окончании этого этапа рационально утвердить Критический Анализ Дизайна с точками «готов/не готов» по заданным критериям. После разработки компонентов системы может быть необходимо утвердить Анализ Готовности к Тестам (АГТ). По окончании стадии Интеграции и Верификации необходимо подготовить Анализ Готовности к Поставке. И перед стадией Инсталляции и Валидации возможно опять потребуется АГТ под текущие условия. Во время разворачивания системы будет полезно организовать Анализ Перехода к Эксплуатации (АПЭ), где необходимо определить готовность системы к реальной работе и здесь же необходимо включить управляющие точки «готов/не готов» по заранее определенным критериям. И, наконец перед вводом системы в эксплуатацию необходимо провести целый ряд процедур — провести промежуточный Анализ Статуса Инсталляционных работ, провести Анализ Готовности к Эксплуатации (АГЭ) и организовать приемку системы по критериям Формальной Квалификации.

В общем случае состав и объем актов анализа, промежуточных и окончательных критериев «готов/не готов» зависит от размеров системы/программы, ее сложности и объемов работ.

Для более подробного описания необходимых или полезных мероприятий по анализу сведем все в таблицу 2.

Таблица 2

Необходимые мероприятия как ключевые точки на разных стадиях ЖЦ

		Когда необходимо	Цель проведения	Документальные данные
Первоначальный технический анализ	ПТА	Раннее уточнение концепта	– Установка и уточнение общей технической линии. – Оценка первоначальных финансовых расчетов программы.	– Документ по анализу затрат. – Доклад по оценке технических и ценовых рисков
Анализ альтернатив системы	ААС	Позднее уточнение концепта	– Оценка требований по отношению к нуждам заказчиков. – Оценка готовности предпочтительных альтернатив.	– Изучение компромиссов. – Предварительная спецификация системы. – Инженерный план системы. – Задания для дизайна системы. – Входные данные для разработки технологий.
Анализ Системных требований	АСТ	Ранняя интеграция систем	– Оценка требований к функционалу системы	– Предварительная спецификация критериев эффективности. – Предв. документы по планированию. – Анализ БДФП, НДР
Анализ Функциональных требований	АФТ	Ранняя интеграция систем	– Оценка дизайна системы. – Валидация спецификации системы. – Определение общей линии функционального дизайна.	– Спецификация характеристик эффективности. – Документ по общему дизайну. – НДР, ЛВШ
Анализ спецификаций программного обеспечения (ПО)	АПС	Интеграция системы на среднем этапе	– Оценка требований по эффективности ПО. – Валидация спецификации ПО. – Установление общей линии спецификации ПО.	– Спецификация ПО. – CТПО & СИПО. – Концепция эксплуатации.
Предварительный Анализ Дизайна	ПАД	Поздняя Системная интеграция или ранняя демонстрация системы	– Валидация спецификаций – Определение общей линии конструкций и машин. – Оценка предварительного дизайна конструкций, машин и ПО	– Спецификации конструкций – План тестирования – Инженерные чертежи – Предварительные ОДПО — ОИПО
Критический Анализ дизайна	КАД	Ранняя демонстрация системы	– Анализ дизайна CI – Определение готовности для производства	– Предварительная спецификация материалов, процессов, комплектующих. – Детальный документ по дизайну включая ОДПО, ОИПО
Анализ готовности к тестам	АГТ	Средний и поздний этап демонстрации системы	– Утверждение процедур тестирования ПО. – Определение готовности к формальным тестам.	– Процедуры тестирования ПО. – Неформальные результаты тестов.
Аудит Функциональной конфигурации	АФК	Поздний этап демонстрации системы или раннее P&D	– Проверка CI соответствие реальных показателей эффективности …SRS & IRS	– Планы и описание тестов – Отчет о тестировании ПО
Формальный квалификационный анализ	ФКА	Позднее LRIP	– Проверка показателей CI в системном окружении.	– Отчеты по тестам – Спецификации – Документы по эксплуатации и поддержке
Анализ готовности к производству или эксплуатации	АГП АГЭ	Поэтапная Системная демонстрация	– Оценка рисков для продолжения производства или эксплуатации	– Документы по планированию производства
Аудит физической конфигурации	АФИК	LRIP и раннее FRP	– Экзаменация текущей конструкции	– Финальная спецификация комплектующих – Списки – Чертежи уровня 2 и 3
Анализ работающей системы		Система в эксплуатации	– Оценка работы системы в нормальном окружении – Оценка поддержки и обслуживания системы	– Оценка рисков и опасностей работающей системы – Оценка готовности эксплуатации – Отчет о несоответствиях

*Где БДФП- блок-диаграмма функциональных потоков (FFBD) [2], НДР — надежность доступность ремонтопригодность (RAS) [2], ЛВШ — лист временной шкалы (TLS) [2], СТПО — спецификация требований ПО (SRS) [2], СИПО — спецификация интерфейсов ПО (IRS) [2], ОДПО — описание дизайна ПО (SDD) [2], ОИПО — описание интерфейсов ПО (IDD) [2].

В зависимости от выбранной модели ЖЦ могут потребоваться дополнительные стадии. Например, это может быть стадия системной интеграции, когда выполняется процесс соединения программного обеспечения, конструкций, машин и людей в единую систему. Эта стадия должна проводиться инкрементально, по шагам, так чтобы каждая подсистема была интегрирована поочерёдно, а не все сразу. Это комплексная и долгая стадия. Часто именно здесь возникают проблемы из-за нежелательного и непредсказуемого взаимодействия подсистем.

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

– недооценки характеристик окружения;

– сопротивления людей;

– сосуществования других систем;

– проблем с физическим монтажом системы.

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

– физические проблемы или несовместимость;

– проблемы преобразования данных;

– возрастающие ошибки операторов системы из-за неудачных интерфейсов.

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

Литература:

1. Сычев В. А. Этапы развития системы в системном инжиниринге // Молодой ученый. — 2018. — № 35. — С. 7–13. — URL https://moluch.ru/archive/221/52455/ (дата обращения: 17.09.2018).
2. Defense Acquisition Guidebook. URL https://www.dau.mil/tools/dag/Pages/DAG-Page-Viewer.aspx?source=https://www.dau.mil/guidebooks/Shared %20Documents %20HTML/Chapter %203 %20Systems %20Engineering.aspx Originally from Defense Acquisition University. (дата обращения 17.09.2018).