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

В стандарте ISO 9000 «Система менеджмента качества» сформулировано, что требование является документально изложенным критерием, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения.

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

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

• Требования определяют нужды (проблемы) заинтересованных сторон, или иначе, бизнес-требования.

• Требования определяют вариант создания продукта, т.е. процедуры, регламенты, системные требования.

• Требования определяют ограничения, связанные с решением или проектом по его реализации, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т. д.

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

Технический процесс системного проектирования начинается с функциональных требований. В интересах разработчика сохранить как можно большую свободу проектирования. Затем функциональные требования обычно декомпозируют. При этом задача декомпозиции вводит новые входные и выходные данные и среду для исполнителя. Нужно минимизировать объем информации, которую приходится передавать между подсистемами. Функциональные спецификации нижнего уровня являются основой для закупок услуг по проектированию. Они записываются в виде границ. Например, указано, что масса продукта должна быть меньше или равна 25 кг.

Успех любой создаваемой системы и ее эксплуатации зависит от следующих факторов:

1) готова ли рыночная среда к внедрению системы (когда потребности рынка обусловлены «окном возможностей»);

2) как обеспечено позитивное восприятие пользователем функциональности, пригодности и доступности системы;

3) способность системы выполнять эксплуатационные требования пользователя (эффективность системы);

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

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

К сожалению, плохо сформулированные требования являются главной причиной проблем на проекте. Требования определяют, что должно быть сделано, как хорошо и при каких ограничениях. Если разработчики получат неверные требования, проект и оборудование не будут работать. Требования являются причиной стоимости системы, бюджета проекта, графика работ, требуемых ресурсов, планов верификации, эксплуатационных процедур, т.е. всего в проекте!

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

В соответствии с иерархией структуры системы существует несколько уровней требований сверху вниз.

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

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

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

Для инициации процесса формирования требований используют следующую информацию.

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

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

3. Базовые стратегии поддержки для всех стадий ЖЦ (разработки, тестирования, производства, эксплуатации или утилизации конечного продукта).

4. Меры эффективности, т.е. соответствие результатов проекта критериям успеха (см. главу 3.8).

5. Другие данные. Например, для авиационных объектов все взаимодействия человека и системы, необходимые для эксплуатации, включая сборку, наземные операции, логистику, обслуживание в полете и на земле, эксплуатацию в полете и т. д.

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

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

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

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

• Учесть руководящие документы для создаваемого продукта или системы, ГОСТ, ISO, федеральные и отраслевые нормы, и др.

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

При выполнении анализа требования полезно классифицировать на основные типы:

A. Функциональные требования, отвечающие на вопрос «что система должна делать?». Например, обеспечить связь между землей и самолетом.

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

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

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

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

F. Требования к качеству (включая требования к безопасности).

G. Бизнес-требования (цена продукта, стоимость жизненного цикла, конкурентоспособность и др.).

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

Подробные требования к проекту могут содержать следующие пункты.

   1 Технические данные.   2 Планирование.   3 План управления системной инженерией (СИП).3.1 Процесс системного проектирования.3.2 Системный анализ и управление.3.3 Технологические вопросы (процессы, оборудование).3.4 Обеспечение технической интеграции.   4 Анализ эффективности.4.1 Технологический анализ производства.4.2 Анализ испытаний и верификации.4.3 Анализ опытного производства и испытательных установок.4.4 Эксплуатационный анализ сценариев расчетных и нештатных.4.5 Анализ поддержки в эксплуатации.4.6 Анализ обучения и соответствующего персонала.4.7 Анализ процесса утилизации.4.8 Анализ окружающей среды.4.9 Анализ стоимости жизненного цикла.4.10 Моделирование и цифровые двойники.   5 Детальный график системного проектирования.   6 Технические обзоры.6.1 Планирование цепи обзоров.6.2 Функциональные обзоры.6.3 Обзоры системы по времени работ.6.4 Организация сбора экспертных отзывов.   7 Структуру разбиения работ (СРР).   8 Требования к технической интеграции системы.8.1 Надежность и ремонтопригодность.8.2 Живучесть (где приложимо).8.3.Электромагнитная совместимость.8.4 Интеграция человеческих систем.8.5 Безопасность системы для здоровья и воздействие на окружающую среду.8.6 Безопасность системы от внешних воздействий.8.7 Обеспечение качества.8.8 Производство (технологические процессы, заготовки, инструменты, гибкие линии).8.9 Интегрированную логистическую поддержку.8.10 Испытания и оценки.   9 Прочие требования к разработке.9.1 Приобретаемые компоненты (ПКИ).9.2 Использование метрической системы.9.3 Контроль деталей, включая поставки от подрядчиков.9.4 Управление, связь и коммуникации.9.5 Прототипирование.   10 Проверку инженерного менеджмента у подрядчиков.

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

• Определить и документально зафиксировать требования. Заинтересованные лица (включая заказчиков, пользователей и др.) формируют набор требований верхнего уровня, зачастую эти требования входят в техническое задание контракта на разработку системы.

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

• Сформировать производные требования, вытекающие из заданных, для реализации детального проекта системы.

• Определить методы верификации требований.

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

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

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

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

Метод (https://clck.ru/3FNPmg) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуются в технические. Затем технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.

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

Одним из видов требований нижних уровней являются производные требования.

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

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

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

Схема процесса декомпозиции требований изображена на рис.7.

Рис. 7. Этапы декомпозиции требований

На рисунке процесс движется слева направо. На шаге 1 установлены возможности системы (выставленные исходные требования). На шаге 2 проводится декомпозиция требований верхнего уровня по функциям системы, формируются производные и «дочерние» требования. На шаге 3 требования к функциям привязывают к подсистемам и компонентам системы.

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

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

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

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

Примеры стандартных интерфейсов (механические и шины данных) показаны на рис. 8.

Рис. 8. Примеры интерфейсов

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

1. Интерфейсы возникают как между подсистемами, так и между подсистемами и системой.

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

3. Должен быть определен один владелец каждого интерфейса, даже если это очевидно.

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

5. Требования к интерфейсу включают логические и физические интерфейсы.

6. Функциональные и ресурсные распределения по подсистемам влияют на требования интерфейса. В качестве примера рассмотрим сжатие данных. Эта функция может быть выделена либо в радиолокационной подсистеме, подсистеме обработки данных или подсистеме связи.

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

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

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

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

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

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

a) определить интерфейс и его характеристики (физические, электрические, механические, человеческие и т.д.);

b) обеспечить совместимость интерфейса со всеми сопряженными интерфейсами, используя процесс, документированный и одобренный в проекте;

c) разработать документ управления интерфейсом;

d) определить монтажные чертежи или другую документацию, которая включает полную конфигурацию интегрируемого продукта, список деталей и инструкции по сборке;

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

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

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

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

• Документ управления интерфейсом (ICD) излагает детали интерфейса между двумя элементами системы: числа и типы разъемов, электрических параметров, механических свойств, а также экологических ограничений, определяет дизайнерское решение на требование интерфейса.

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

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