Виктор Юрьевич Николенко "Секреты успешных НИОКР"

Менеджеры, руководители проектов, инженеры различной квалификации, студенты найдут в этой книге изложение эффективных приемов управления и реализации НИОКР на основе системного подхода, с учетом успешного 50-летнего опыта работы автора в РФ и за рубежом. Представлены варианты применения инструментов ОКР, полезные при разработке изделий и систем городской инфраструктуры, здравоохранения, транспорта, ИТ-сектора, продукции госкорпораций «Ростех», «Роскосмос», «Газпром», «Росатом», и других.

date_range Год издания :

foundation Издательство :Издательские решения

person Автор :

workspaces ISBN :9785005999559

child_care Возрастное ограничение : 12

update Дата обновления : 15.06.2023


• ГОСТ Р ИСО 10007—2019. Менеджмент качества. Руководящие указания по менеджменту конфигурации.

• ГОСТ Р 59193—2020. Управление конфигурацией. Основные положения.

• ГОСТ Р 57100—2016 (ISO 42010:2011). Системная и программная инженерия. Описание архитектуры.

• ГОСТ Р ISO/МЭК 12207—2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.

• ГОСТ Р 57101—2016 (ISO/IEC/IEEE 16326:2009). Системная и программная инженерия. Процессы жизненного цикла. Управление проектом.

1.3 Формирование требований к системе

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

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

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

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

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

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

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

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

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

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

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

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

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

Необходимым стартовым компонентом для продвижения по этапам разработки является «Концепция эксплуатации» (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. Определить методы верификации требований.

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

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

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

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

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

Все книги на сайте предоставены для ознакомления и защищены авторским правом