Читать книгу Секреты успешных НИОКР - Виктор Юрьевич Николенко - Страница 5

Напомним основные понятия системы и их роли.

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

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

• Жизненный цикл: определяет, как система будет построена или произведена, ее испытания, продажи, финансирование, эксплуатацию, обслуживание и утилизацию по завершению эксплуатации.

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

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

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

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

• Компонент это элемент построения системы. Физические компоненты представляют оборудование для построения системы. Электрические и компьютерные компоненты программного обеспечения контролируют и регулируют ее работу. Человеческие компоненты взаимодействия людей с аппаратным и программным обеспечением необходимы для выполнения системных функций.

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

• Базовая версия системы. Это задокументированная точка отсчета для оценки результатов системного проектирования. На определенных этапах проектирования системы предыдущая базовая версия сменяется на более проработанную или зрелую.

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

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

Необходимым стартовым компонентом для продвижения по этапам разработки является «Концепция эксплуатации» (concept of operation). Это документ, описывающий ожидаемые характеристики разрабатываемой системы с точки зрения пользователя (не путать со спецификацией, где изложен весь набор требований заинтересованных сторон к системе, подсистемам и элементам). В стандартах РФ такой документ не фигурирует. Его задачей является наглядное описание целей создания системы («что» она должна делать, а не «как»). Концепция эксплуатации является базовым источником для остальных действий по реализации системы. Последующие действия по разработке преобразуют вопросы эксплуатации системы и функций поддержки ЖЦ в реальную систему.

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

• Что требуется от системы с функциональной точки зрения?

• Какие основные и второстепенные функции должна выполнять система?

• Что ограничивает ее возможности?

• Что пользователи ценят в ожидаемом продукте?

• Когда необходимо построить и поставить систему?

• Как будет поддерживаться запланированный жизненный цикл системы после продажи?

• Какова предполагаемая стоимость жизненного цикла системы?

• Где предполагается использовать систему?

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

Документирование «Концепции эксплуатации» системы должно завершиться до формирования требований. Она является связующим звеном между желаниями и требованиями для создания и тестирования решения.

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

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

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

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

Процесс разработки верхнего уровня архитектуры системы показан на рис. 1.4. Процесс движется из верхнего левого угла по часовой стрелке. Этапы на схеме пронумерованы.

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

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

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

• Физическая архитектура, в которой представлены физические ресурсы и их взаимосвязи.

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

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

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

Рекомендуется ознакомиться с ГОСТ Р 57100—2016 (ISO/IEC/IEEE 42010:2011) «Системная и программная инженерия. Описание архитектуры».

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

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

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

Формирование проектных требований начинается с уточнения внешних требований верхнего уровня, поступающих от заказчиков. Затем эти требования верхнего уровня группируют по конкретным направлениям.

1. Требования к системе, где собраны требования к продукции, и ее характеристикам.

2. Промышленные, производственные и испытательные требования.

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

Требования являются ключом к успеху проекта. Для хороших требований к системе или продукту важно наличие следующих свойств.

• Специфичность, чтобы отражать только один аспект конструкции или характеристик системы. Требования также должны быть выражены в терминах потребности (что и как хорошо), а не вариантов решений (как).

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

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

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

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

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

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

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

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

5. Политика и публичные законы вносят ограничения по безопасности, экологии и шуму. Следует учесть угрозы, налагаемые известными возможностями потенциального конкурента, что также ограничивает диапазон практических вариантов проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Сформировать производные требования.

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

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

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

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

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

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

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

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

• хаоса, необходимо сконцентрироваться на самом важном, требование не должно быть похоже на роман;

• лазеек, выражений типа «если это необходимо», поскольку они делают требование бесполезным;

• помещать больше одного требования в один параграф, это можно определить по наличию предлогов «и»;

• неконкретных рассуждений;

• нечетких слов, таких как «обычно», «в основном», «часто», «нормально», «типично»;

• использования неопределенных терминов («удобный в использовании», «универсальный», «гибкий»);

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

При написании детальных требований к системе используют, в частности, функцию развертывания качества (quality function deployment, QFD). Она переводит потребительские качества, желаемые пользователем, в технические функции и средства для их реализации и развертывания доступных ресурсов при создании продукта или услуги [2]. Метод QFD основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Сначала потребительские характеристики преобразуют в технические. Технические характеристики преобразуют в характеристики компонентов, далее в характеристики процессов и, в завершение, в характеристики контроля продукта. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве.

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

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

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

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

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

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

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

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

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

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

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

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

В результате процесса разработки формируется набор требований, который должен быть выполнен при создании продукта или системы. Этот завершающий комплект требований содержится в документах контракта, спецификациях или технических заданиях на выполнение работ (statement of work, SOW). Характеристики этого набора будут идентичны вышеописанным пунктам отдельных требований и удовлетворяют двум условиям. Набор должен быть полным, то есть не нуждается в дополнительных пунктах требований. Входящие в него требования должны быть согласованными, то есть не содержат противоречий, дублирований, и др. Далее на всех этапах разработки системы выполняется процесс управления требованиями (см. раздел 2.2).

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