Бесплатный фрагмент - Системный подход к управлению высокотехнологичными проектами

Почему эту книгу нужно прочесть

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

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

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

Данной теме посвящено значительное количество монографий, часть из которых приведена в перечне литературы в конце книги [1…13]. Обусловлено это тем, что на сегодня системно-инженерный менеджмент — единственная важная практическая дисциплина реализации инновационных проектов с подтвержденным положительным эффектом.

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

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

Системная инженерия оформилась на рубеже ХХ–ХХI веков на основе опыта и достижений технических и управленческих наук как организованный набор принципов, правил и процедур создания высокотехнологичных продуктов. Данные материалы были формализованы, реализованы в стандартах (включая ряд российских ГОСТов) и инструкциях. Воздействие методологии было многократно усилено внедрением информационных технологий. Международное сообщество системных инженеров INCOSE выдало 4-е издание справочника INCOSE Systems Engineering Handbook. Подробную информацию можно найти в последнем издании курса системной инженерии NASA (исходный справочник и два тома разъяснений к нему) [11, 12].

Автором ранее издано учебное пособие «Базовый курс системной инженерии» [13] на основе опыта работы и курса лекций, прочитанных в 2013–2016 гг. на междисциплинарной кафедре Высшей школы системной инженерии МФТИ, http://sehs.mipt.ru.

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

---

Книгу предваряет введение, где изложены сводные данные многолетнего практического применения данного подхода в РФ при непосредственном участии и под руководством автора.

Введение. Вопросы современной подготовки специалистов

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

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

Постановка задачи

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

• Необходимо увеличить объем материала для усвоения (т.е. тенденция «вечного студента»).

• Необходимо сократить сроки обучения специалистов для улучшения экономической отдачи.

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

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

---

• Предметная инженерия (специализацию дает ВУЗ — электроника, робототехника, автомобили, вертолеты, нефтехимия и т.д.).

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

• Управление проектом (во многом случайный процесс получения общих сведений из многочисленных пособий типа PMBoK и курсов для

• Системная инженерия (на сегодня минимально доступна в РФ, «клей» для объединения вышеперечисленного, универсальное дополнение к пропущенным важным элементам инженерной науки в части технической, управленческой и организационной, системный подход, предмет настоящей книги).

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

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

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

---

Системная инженерия является удобным и высокоэффективным средством обучения проектных команд и отдельных инженеров, неотъемлемой частью высокотехнологичных масштабных проектов. К сожалению, обучение системной инженерии с советских времен резко сократилось в вузах РФ. Образовательные новшества полезны для тех, кто освоил базовые знания и практические методологии эффективной работы.

Некоторые итоги применения системной инженерии в РФ

• Обучение системно-инженерному подходу приносит заметный практический эффект для 80–90% «обычных» инженеров (выпускников отечественных технических вузов) различных категорий.

• Освоение происходит в оперативном режиме, через 1–1,5 года сотрудники выходят на удовлетворительные темпы и качество работ, скачкообразно растет понимание системного подхода к задачам.

• Заметно снижаются потери рабочего времени в проекте.

• Возрастает качество работ и получаемых результатов.

• Рост производительности труда после периода обучения составляет от 20 до 100% и далее обеспечивает стабильный рост не менее 15–25% в год.

Немного истории системной инженерии

• С 90-х годов прошлого века все крупнейшие правительственные учреждения и ведущие мировые компании различных стран используют системно-инженерный подход для реализации своих высокотехнологических проектов. Применение стандартов системной инженерии обязательно для контрактов военных ведомств развитых стран и государственных заказчиков сложных систем (строительство атомных станций, мостов, транспортной инфраструктуры), таких как Министерство обороны США (DoD), Национальная аэрокосмическая ассоциация (NASA), компаний Boeing, Airbus, гигантов в сфере телекоммуникаций и информационных технологий (Siemens, IBM) и др.

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

Суть системной инженерии как дисциплины, которая для достижения своих целей ориентируется в рамках управления ЖЦ, состоит в комплексном решении задач управления и задач проектирования.

Данная методология дополняет (или как сказано выше, «склеивает») набор стандартных дисциплин высокотехнологичного проекта.

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

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

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

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

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

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

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

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

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

Раздел I.
Что такое системная инженерия

1.1. Кое-что из статистики

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

1-я индустриальная революция произошла при использовании энергии воды и пара для механизации производства;

2-я индустриальная революция наступила при применении электричества для серийного производства;

3-я индустриальная революция характеризовалась использованием электронных и информационных технологий для автоматизации производства.

Отличительными компонентами 4-й индустриальной революции являются (вариант):

• активизация науки о материалах;

• внедрение аддитивного производства;

• развитие нанотехнологий;

• эффективное хранение энергии;

• БАС (беспилотные авиационные системы);

• движение к полностью электрическому самолету;

• появление гиперзвуковых летательных аппаратов;

• широкое развитие робототехники;

• внедрение элементов искусственного интеллекта;

• развитие интернета вещей;

• использование квантовых компьютеров.

---

Посмотрим на экономические возможности Российской Федерации в настоящее время. Россия занимает в мире (на 2017 г.) следующие места:

1-е по запасам и экспорту природного газа (35% мировой добычи);

1-е по добыче нефти и 2-е по ее экспорту;

1-е по запасам каменного угля (23% мировых запасов) и 3-е по его экспорту;

1-е по запасам лесных ресурсов (23% мировых запасов);

1-е по запасам поваренной соли и 2-е по запасам калийной соли;

1-е по запасам питьевой воды;

1-е по экспорту пшеницы (3-е по ее урожаю);

1-е по запасам олова, цинка, титана, ниобия;

1-е по запасам и производству никеля;

1-е по запасам железных руд (около 28% мировых запасов);

1-е по экспорту стали и 3-е по экспорту металлопроката;

1-е по производству и экспорту первичного алюминия;

1-е по производству авиационного титана;

1-е по экспорту азотных удобрений, 2-е и 3-е места по фосфорным и калийным удобрениям;

1-е по запасам алмазов и 2-е по их добыче;

1-е по запасам серебра; 2-е в мире по запасам золота;

1-е по экспорту платины и 2-е по ее запасам;

1-е по протяженности электрифицированных железных дорог;

1-е по протяженности линий экологичного транспорта (троллейбусы, трамваи и метро);

1-е по количеству проданных на экспорт самолетов-истребителей;

1-е по поставкам на экспорт средств ПВО средней и малой дальности;

1-е по экспортным контрактам на сооружение атомных электростанций;

2-е место по количеству парка вертолетов;

2-е по поставкам вооружения всех видов;

2-е по величине подводного флота;

2-е по числу ежегодных запусков космических аппаратов;

3-е по запасам меди и свинца, вольфрама и молибдена, рения;

3-е по числу абонентов сотовой связи;

3-е по производству электроэнергии;

3-е по производству продуктов нефтехимии;

4-е место по количеству ежегодно печатаемых книг и 4-е по числу переводов с них (!);

5-е по добыче угля, синтетического каучука, калийных удобрений, производству стали;

9-е по производству зерна, черных и цветных металлов, целлюлозы, пиломатериалов.

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

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

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

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

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

---

1.2. Жизненный цикл системы и определение системной инженерии

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

Примеры систем (по возрастанию сложности):

• двигатель самолета по сравнению с набором деталей;

• самолет с двигателями и авионикой;

• самолет с внешними топливными баками;

• авиатранспортная система (АТС) с самолетами, пассажирами, грузами, тренажерами и др.;

• система систем: АТС + аэропорт + инфраструктуры обслуживания и наземного наблюдения.

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

У каждой системы имеется жизненный цикл (ЖЦ, life cycle): ЖЦ — это совокупность взаимоувязанных последовательных изменений состояния изделия (системы), связанных с реализацией установленных процессов от начала разработки до вывода из эксплуатации (утилизации).

Введем еще два определения из прикладного стандарта ГОСТ 56136—2014:

— этап жизненного цикла (life cycle milestone): часть ЖЦ, выделяемая по признакам моментов контроля (контрольных рубежей), в которых предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.

— контрольный рубеж (КР) этапа жизненного цикла (milestone/decision gate): момент завершения этапа ЖЦ, в котором предусматривается проверка характеристик проектных решений типовой конструкции и (или) физических характеристик экземпляров изделий.

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

Проект можно разбить на отдельные фазы, отделенные контрольными рубежами (воротами принятия решений). У NASA 7 фаз ЖЦ, в GE их 10, у Airbus в ЖЦ 14 последовательных этапов. Пример ЖЦ системы показан на рис. 1.2.

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

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

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

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

А. Инициация

Предварительный анализ изделия (КР 0)

Определение бизнес-возможности разрабатываемого продукта (КР 1)

Б. Формирование содержания программы

Концептуальное проектирование и оценка выполнимости (КР 2)

Определение облика изделия, эскизный проект (КР 3)

Представление ВС и процессов его создания (КР 4)

В. Фаза реализации программы

Утверждение («замораживание») конструкции (КР 5)

Изготовление опытных образцов (КР 6)

Летные испытания, сертификация (КР 7)

Начало поставок в эксплуатацию (КР 8)

Модернизация (КР 9)

Эксплуатация и завершение серийного производства (КР 10)

Г. Завершение программы

Вывод из эксплуатации и завершение программы (КР 11)

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

При разработке систем, продуктов или услуг необходимо найти ответы на несколько фундаментальных вопросов:

1. Что такое система?

2. Что входит в границы системы?

3. Какую роль играет система в организации пользователя?

4. Какие действия в эксплуатации выполняет система?

5. Какие ориентированные на результаты выходы дает система?

В истории человечества следы системно-инженерного подхода заметны при сооружении египетских пирамид, римских дорог, азиатских ирригационных каналов и других известных объектов, дошедших до наших дней. Так, «подушку» под римской дорогой для колесниц укладывали по правилам того времени до 5 метров толщиной из различных материалов. Спустя столетия эти дороги заасфальтированы и используются для современных автомобилей. Каменные мосты через реки в некоторых голландских городах используются без ремонта на протяжении 300–400 лет. Т.е. выполнено условие заботы о жизненном цикле продукта в целом — действия на каждой фазе ЖЦ системы были направлены на улучшение жизненного цикла на последующих этапах.

---

Великий российский инженер XIX–XX веков Владимир Шухов за годы работы реализовал со своими подрядными коллективами более 700 проектов. При этом уровень работ находился на вершине тогдашних инженерных знаний, оформлены патенты мирового уровня — горизонтальный и вертикальный паровые котлы, форсунка для мазута, нефтеналивная баржа, стальной цилиндрический резервуар, висячее сетчатое покрытие для зданий, арочное покрытие, нефтепровод, промышленная крекинг-установка, ажурная гиперболоидная башня (телецентр на Шаболовке в Москве), построено около 200 башен, около 500 мостов, зерновые элеваторы, доменные печи, плавучие ворота сухого дока, вращающаяся сцена МХАТ.

План ГОЭЛРО в послереволюционной России был утвержден в декабре 1921 г. и к 1930 г. перевыполнен, в результате Россия вышла на 3-е место в мире по производству электроэнергии.

Еще один первопроходец, американец Альберт Кан, реализовал в 1929–1932 гг. на объектах в СССР методику скоростной разработки архитектурно-строительной проектной документации. Проектирование гигантских заводов выполнялось не за 1,5–2 года, а в 10 раз быстрее — за 2–2,5 месяца. Применены быстрое создание из стандартных деталей универсального строительного объема, принципы модульности, идея стандартизации чертежей. Проектные решения для быстрой реализации увязывались с сортаментом конструкций и монтажно-техническими возможностями подрядных фирм. В США фирма штатом в 400 человек готовила рабочие чертежи за неделю, а корпуса промышленных предприятий возводила за пять месяцев. В СССР за 3 года построено 520 объектов, большинство из которых используется и сейчас.

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

1. Развитие затратных программ high-tech с учетом управления рисками и информационных технологий;

2. Активизация рыночного соревнования между странами и компаниями (развитие маркетинга);

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

4. Нарастание кадровых проблем для высокотехнологичных отраслей.

Как следствие, появились книги, справочники и стандарты по теме: H. Good, R. Machol, Системотехника. Введение в проектирование больших систем (1957 г.), справочник Военно-воздушных сил США по системной инженерии (1966 г.), MIL-STD 499 (первый стандарт СИ, 1969 г.). В СССР один из первых курсов СИ был издан в 1976 г.: В. Дружинин, Д. Конторов «Вопросы военной системотехники».

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

— Космическое агентство NASA, США — 2017.

— Европейское космическое агентство ESA — 2009.

— Некоммерческое общество системных инженеров INCOSE Handbook, изд. 4 — 2015.

— Администрация гражданской авиации США (FAA) — 2015.

— Компания-интегратор интеллектуальных транспортных систем ITS, изд. 3 — 2009.

— Министерство обороны США, DoD — 2006.

— Компания-интегратор авиационной техники Boeing — 2003.

— Компания-интегратор авиационной техники Airbus — 2004.

— Генеральный штаб ВВС США (USAF) — 2009.

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

Страны БРИКС совершили за два последних десятилетия резкое ускорение в развитии. Вследствие необходимости создания новых изделий и освоения высоких технологий им удалось стандартизовать подготовку творческих сотрудников на основе подходов СИ.

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

Данный процесс завершается интеграцией трех основных активностей:

• фаза разработки, которая контролирует процесс проектирования и обеспечивает базовые результаты, увязывающие проектные усилия;

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

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

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

Для реализации проектов и программ используются основные варианты декомпозиции в системной инженерии:

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

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

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

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

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

Системная инженерия демонстрирует эффективность разработанных подходов, является выгодным инструментом создания новых изделий, ведет к уменьшению затрат путем оптимизации процессов и исключения переделок (из-за увеличения глубины проработки и исправления ошибок на ранних стадиях проекта). Подход СИ снижает коэффициент экспоненты убытков на масштабе бюджета проекта, причем чем крупнее проект, тем выше эффект применения СИ. Статистика NASA показала, что можно снизить перерасход бюджета на 20–90% (от мелких до очень крупных проектов). При этом оптимальная доля затрат на деятельность системных инженеров составит от 5 до 35% соответственно.

Системная инженерия обеспечивает возможность реализации коллективных усилий по формированию и осуществлению набора процессов, необходимых для управления ЖЦ объекта, включая замысел, реализацию, эксплуатацию и утилизацию. Она позволяет эффективно организовать работу интегрированной команды проекта (integrated product team, IPT) и дает набор правил (мультидисциплинарный подход), когда все члены команды знают, что делать для успеха проекта. В системно-инженерном процессе эффективно используется множество типовых инженерных инструментов и методов.

В стандарте «Процессы жизненного цикла систем» ISO 15288:2015 (ГОСТ Р 57193—2016) сегодня перечислены 30 базовых процессов жизненного цикла систем (рис. 1.3).

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

При создании инновационных продуктов пункты вклада системной инженерии можно разложить по основным составляющим:

• технический менеджмент;

• организационные вопросы программ;

• технические инструменты и методы.

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

---

1.3. Вопросы управления жизненным циклом проекта

В начале процесса управления жизненным циклом объекта разработки необходимо сделать следующее:

• определить, что является базовой системой;

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

• связать фазы жизненного цикла проекта с частями V-диаграммы модели процесса системной инженерии;

• описать типичные цели разработки для каждой из фаз ЖЦ проекта.

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

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

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

1. Управление процессом проектирования и разработки ВС.

2. Управление процессом ТПП.

3. Управление процессом производства.

4. Управление процессами закупки ПКИ, материалов, заготовок, запчастей.

5. Управление процессом испытаний ВС (наземных, сертификационных, государственных, приемо-сдаточных).

6. Управление процессом ИЛП изделия.

7. Управление процессом ППО.

8. правление процессами подготовки летного состава и персонала ТОиР.

9. Обеспечение качества на всех этапах ЖЦ за счет процессов СМК, управления конфигурацией ВС, реализации процессов системной инженерии.

10. Обеспечение планируемого темпа производства ВС.

11. Достижение заданной трудоемкости разработки и изготовления ВС.

12. Управление процессом утилизации при списании ВС.

13. Управление информационной поддержкой всех процессов (с учетом циклов развития аппаратного и программного обеспечения).

Сегодня требования системной инженерии изложены в ряде стандартов ГОСТ РФ.

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

• ГОСТ Р ЕН 9100—2011. Системы менеджмента качества организаций авиационной, космической и оборонной промышленности, требования.

• ГОСТ 56136—2014. Управление жизненным циклом продукции военного назначения, Термины и определения.

• ГОСТ 56135—2014. Управление жизненным циклом продукции военного назначения, Общие положения.

• ГОСТ Р 58054—2018. Изделия авиационной техники. Управление конфигурацией. Общие положения.

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

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

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

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

Перемещение по звеньям процесса по мере разработки сопровождается верификацией каждого шага, возвратом к предыдущему результату для проверки прогресса работ. При формировании процессов используют особенности описания систем, изложенные в стандарте ГОСТ Р 57193—2016:

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

• иерархическое восприятие физической структуры системы;

• объект любого уровня иерархической структуры может рассматриваться как система;

• характерные свойства на границе системы возникают в результате взаимодействия между элементами системы;

• люди могут рассматриваться как внешние пользователи по отношению к системе (например, экипаж ВС) и как элементы в рамках системы (например, персонал завода-производителя ВС);

• система может рассматриваться как отдельный, изолированный от внешней среды объект.

Наиболее контролируемым параметром является стоимость жизненного цикла (LCC) — это общая стоимость программы или проекта за запланированный жизненный цикл от формулировки (исключая предварительную фазу A) до реализации.

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

Процесс разработки в системной инженерии можно представить в виде нескольких взаимосвязанных итерационных петель (рис. 1.5).

Выделим 12 последовательных этапов разработки для ЖЦ СИ, которые включают следующие задачи:

1. Комплексное техническое планирование (ITP) — формирование планов процессов СИ и продуктов.

2. Управление требованиями — определение и управление требованиями, которые описывают желаемые характеристики системы.

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

4. Маркетинговая оптимизация — информация по принятию решений на основе анализа и отбора наиболее сбалансированных решений по требованиям рынка.

5. Синтез — этап преобразования требований в физические решения верхнего уровня системы.

---

6. Управление интерфейсами — определение и управление взаимодействиями между сегментами в рамках системы или взаимодействиями с другими системами.

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

8. Целостный анализ — проверка, что выполненная интеграция системы обеспечила требуемый уровень точности и аккуратности.

9. Управление рисками и возможностями — определение, анализ и управление неопределенностями достижения требований программы путем разработки стратегий для снижения вероятности таких неопределенностей.

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

11. Проверка (верификация) и контроль (валидация).

— Верификация определяет, что требования к системе являются правильными.

— Валидация определяет, что реализованное решение отвечает утвержденным требованиям.

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

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

Поставки

1 — Поставка товаров

Приобретения

2 — Приобретение товаров

3 — Оценка производительности поставщика

Планирования

4 — Стратегии реализации процесса

5 — Определение технических усилий

6 — График и организация работ

7 — Технические планы

8 — Указания (директивы) для работы

Оценки

9 — Прогресс исполнения планов и графиков

10 — Оценка соответствия требованиям

11 — Технические обзоры проекта

Управления

12 — Результаты управления.

13 — Распространение информации.

Определения требований

14 — Требования Заказчика

15 — Требования других заинтересованных сторон

16 — Технические требования к системе

Определения проектных решений

17 — Представление логических решений

18 — Представление физических решений

19 — Указанные требования

Реализации

20 — Реализация проекта

Передачи Заказчику

21 — Ввод в эксплуатацию

Системный анализ

22 — Анализ эффективности

23 — Анализ рыночных альтернатив

24 — Анализ рисков

Проверки требований

25 — Проверка статуса требований

26 — Проверка требований Заказчика

27 — Проверка требований других заинтересованных сторон

28 — Проверка технических требований к системе

29 — Проверка представления логических решений

Проверки системы

30 — Проверка конструктивных решений

31 — Проверка конечного продукта

32 — Проверка готовности продукта к эксплуатации

Валидации конечного продукта

33 — Сертификация конечного продукта

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

В соответствии со стандартом ГОСТ Р 57193—2016 на контрольных рубежах ЖЦ должны быть выполнены главные задачи программы за предыдущую стадию:

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

• обеспечена приемлемость риска перехода на следующую стадию;

• продолжено стимулирование командной работы поставщика и заказчика.

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

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

— Приемлемо: переходить к следующей стадии проекта.

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

— Неприемлемо: не переходить; продолжать эту стадию и повторить пересмотр, когда будет готовность.

— Неприемлемо: вернуться на предыдущую стадию.

— Неприемлемо: заморозить мероприятия проекта.

— Невосстановимо: закрыть проект.

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

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

• определить цели исследования ниши на рынке;

• изучить имеющиеся материалы, включая конкурентную среду, ограничения и допущения;

• выбрать критерии оценки продукта или системы и их относительную значимость (они могут быть качественными и количественными);

• определить и выбрать вероятные альтернативы исполнения системы;

• оценить эффективность каждого варианта для каждого критерия;

• выполнить анализ чувствительности для избранных вариантов;

• сравнить результаты и выбрать предпочтительный вариант продукта;

• задокументировать процесс изучения рынка и его результаты;

Сформировать бизнес-план для обоснования развития будущего продукта или системы.

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

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

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

• были ли выполнены требования к системе и установленные ограничения;

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

• достаточны ли имеющиеся данные для утверждения предварительного выбора;

• достаточно ли независимы методы измерения, чтобы дать уверенность, что выполненный предварительный отбор лучше отброшенных альтернатив;

• если результаты нескольких альтернатив близки, необходим ли дальнейший анализ;

• были ли полностью учтены субъективные аспекты проблемы;

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

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

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

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

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

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

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

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

---

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

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

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

В тексте документа «Концепция эксплуатации» должны содержаться ответы на следующие вопросы:

1. Почему необходима система и предварительный обзор самой системы.

2. Описание полного жизненного цикла системы от развертывания до вывода из эксплуатации.

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

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

5. Указание условий, при которых система используется и обслуживается.

6. Определение границ системы, ее интерфейсов и связей с другими системами.

7. Уточнение, когда и как система будет использоваться, и при каких обстоятельствах, включая обслуживание.

8. Описание сценариев, иллюстрирующих конкретные эксплуатационные мероприятия, связанные с использованием системы.

Руководство по разработке ConOps удобно готовить в группе заинтересованных лиц программы (stakeholders). При этом:

• не следует указывать какие-либо особенности системы;

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

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

• желательно собрать всех участников группы в одном месте в одно и то же время по крайней мере дважды;

• модератор группы должен обладать навыками руководства группой и следить за ее работой;

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

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

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

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

Дадим основные определения понятия архитектуры системы.

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

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

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

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

Создание и развитие архитектуры — есть начало процесса проектирования системы. Здесь устанавливают связи между требованиями и проектом. Требования к системе являются ключевым компонентом процесса ее создания. Место процесса формирования требований в общем процессе СИ можно посмотреть на рис. 1.5.

Укажем формальные определения понятия «требование» из стандартов системы ISO.

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

ISO/IEC 29148 
«Разработка требований»

«Требование — это документально изложенный критерий, который должен быть выполнен, если требуется соответствие документу, и по которому не разрешены отклонения».

ISO 9000 
«Система менеджмента качества»

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

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

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

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

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

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

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

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

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

Вначале нужно сформулировать, зачем нужны требования:

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

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

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

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

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

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

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

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

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

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

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

Требования к системе обычно разделяют на основные типы:

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

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

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

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

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

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

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

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

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

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

Метод QFD (http://studme.org/1608040210904/ menedzhment/tehnologiya_ razvertyvaniya_ funktsii_kachestva) основан на экспертном построении фигурных матриц «домов качества», в которые заносится информация о качестве продукта и принимаемых решениях. Каждая часть «дома» содержит необходимые потребительские или технические характеристики. Процесс включает четыре последовательных этапа, на каждом из которых строится свой «дом качества». Потребительские характеристики преобразуются в технические. Технические характеристики преобразуются в характеристики компонентов, далее в характеристики процессов и в характеристики контроля продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошие требования к системе или продукту должны быть:

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

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

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

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

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

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

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

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

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

• рассуждений;

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

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

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

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

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

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

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

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

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

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

В документах на английском языке используют пометки типа TBA (to be agreed — необходимо согласовать), TBC (to be complete — необходимо завершить), TBD (to be decided — необходимо принять решение). Однако на определенном этапе разработки при «заморозке требований» весь набор пустых ячеек для требований должен быть заполнен.

---

Валидация требований входит в один из этапов ворот принятия решений.

Проверка требования включает четыре типовых вопроса:

1) Правильная ли сформулирована проблема?

2) Смогли ли указанные требования отразить проблему?

3) Являются ли эти требования верно сформулированными?

4) Соответствуют ли требования установленным границам системы и ограничениям?

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

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

• Самолет должен иметь три двигателя (исходное требование для DC-3). Позже выяснилось, что самолет должен отвечать требованиям эксплуатации при отказе одного двигателя.

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

• Космический аппарат должен максимизировать (?!) ресурс. Позднее уточнено, что космический аппарат должен иметь срок службы не менее трех лет.

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

• После проектирования системы пожаротушения в Таганском туннеле 3-го транспортного кольца Москвы было проведено ее опробование. Выяснено, что после срабатывания системы огонь ликвидирован, но восстановить движение по туннелю невозможно, так как пену нечем удалять (рис. 1.9 — видимо, предполагалось, что она будет сливаться в водостоки).

---

1.5. Организация интегрированной команды проекта

Наиболее эффективным инструментом системной инженерии является исполнение работ мультидисциплинарной командой, часто называемой интегрированной командой проекта (integrated project team, IPT). Существенным является принятие решений предварительно организованной командой проекта, что является одним из методов страхования рисков. Декомпозиция задач проекта по ролям команды, реализующей работы, показала эффективность системно-инженерного подхода, упрощает цели участников работ.

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

Затем изготовление сблизили с проектом, производственники должны интерпретировать чертежи, разработать план изготовления/оснастки, инструмента, конструкторские/заводские инструменты, фасонные детали, собрать самолет.

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

Основные задачи такого командно-образующего подхода:

• продемонстрировать решающую роль совместной работы при создании инженерных систем;

• описать принципы результативности успешных команд;

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

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

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

Пример: сквозная инженерная модернизация самолета F/A-18 на модель — E/F по контракту выполнялась ИКП, была завершена ранее графика, получена экономия бюджета 5 миллиардов долларов, а также получена конструкция на 400 кг легче расчетного веса.

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

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

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

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

1. стремление понять общую картину;

2. наблюдать изменение элементов в системе с течением времени, генерацию моделей и тенденций;

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

4. определять связную природу сложных причинно-следственных связей;

5. уточнить поверхности (границы системы) и допущения для испытаний;

6. рассматривать проблему в целом, сопротивляясь стремлению быстро прийти к выводу;

7. использовать понимание структуры системы для определения возможных рычагов воздействий;

8. рассматривать как краткосрочные, так и долгосрочные последствия действий;

9. находить, откуда возникают непреднамеренные последствия изменений;

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

Можно представить упрощенно пример состава команды продукта по признаку основных фаз жизненного цикла (проекта, производства, поддержки ППО):

Лидер команды проектирования

1. Планирование и контроль.

2. Системная инженерия.

3. Проектирование.

4. Прочность.

5. Надежность.

6. Обслуживаемость.

7. Инженерия систем ВС.

8. Материалы и технологии.

9. Вопросы обеспечения серийного выпуска.

10. Подготовка производства.

11. Проектирование оснастки.

12. Подготовка и проведение испытаний.

13. Обеспечение качества.

14. Электронный макет изделия (ЭМИ).

Лидер команды производства

1. Планирование и контроль.

2. Подготовка производства.

3. Проектирование оснастки.

4. Изготовление оснастки и инструмента.

5. Расстановка технологических линий.

6. Производственное планирование.

7. Производство.

8. Технологические и специальные процессы.

9. Контроль продукции.

10. Поддержка качества.

11. Лин, Канбан, Sixsigma.

12. Аддитивные технологии.

13. ЭМИ.

Лидер команды ТОиР

1. Планирование и контроль.

2. Планирование и управление интегрированной логистической поддержкой.

3. Системная инженерия.

4. Технические публикации.

5. Упаковка, хранение и транспортировка.

6. Модернизация и переоснащение.

7. Материально-техническое снабжение.

8. Обеспечение качества.

9. Работа с поставщиками.

10. Поддержка Заказчика.

11. Управление материалами и заготовками.

12. Анализ логистической поддержки.

13. ЭМИ.

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

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

2. Усиление командной составляющей, а не отдельных лиц.

3. Фокус управления на влияние результатов на людей в организации.

4. Интеграция модулей команд в организации для работы в скоординированной взаимозависимой системе.

5. Контроль работы сотрудников в части правил, политики и прямого надзора.

6. Толерантность к риску, когда сотрудникам предлагается быть агрессивными, инновационными и принимать решения, подверженные риску.

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

8. Конфликтная толерантность путем поощрения к открытым дискуссиям вплоть до конфликтов и критике на пользу работе.

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

10. Фокус на открытых системах, когда организация контролирует и реагирует на изменения во внешней среде для исполнения планов.

Важным конкурентным преимуществом РФ на рынке является наличие обширной территории в нескольких часовых поясах, где имеются значительные резервы талантливой молодежи. Наиболее простым и дешевым способом использовать ресурсы является развитие технологий удаленной работы (с организацией базовых коммуникационных узлов в различных географических точках). Так, под руководством автора в 2013–2017 гг. успешно функционировало объединенное конструкторское бюро ПАО «Технодинамика» в пяти городах РФ: Москве, Санкт-Петербурге, Уфе, Самаре и Кирове.

• Удаленные команды — это ключевое изменение рабочей силы, которое повлияет на процессы управления проектами.

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

• Работа за пределами географических границ позволяет предприятиям приобретать лучших талантов из гораздо большего круга кандидатов.

• В ряде случаев можно успешно использовать разницу в часовых поясах для создания дополнительной стоимости (использование лицензий ПО 24 часа и др.).

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

---

1.6. Принятие проектных решений

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

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

---

• Лучше продвигаться по проекту, имея несколько «сомнительных» решений, чем опоздать с решениями в поисках «совершенного» варианта. «Лучшее — враг хорошего».

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

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

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

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

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

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

1. Использовать модели для проектирования систем.

2. Использовать иерархический дизайн: сверху вниз.

3. Сначала выполняется работа с высокорисковыми компонентами.

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

5. Следует применять в альтернативах удовлетворительные конструкции.