скачать книгу бесплатно
10. Управление конфигурацией – установление описания и поддержка базовой версии системы, управление изменениями функциональных и физических свойств.
11. Проверка (верификация) и сертификация (валидация) системы. Верификация определяет, что требования к системе являются правильными. Валидация определяет, что реализованное решение отвечает утвержденным требованиям.
12. Инженерия жизненного цикла – включает управление разработкой продукта, передачу работ в производство, интегрированную поддержку логистики, технологическую производственную часть и вывод из эксплуатации. Используется стандартизация для постоянного улучшения эффективности процессов и инструментов СИ, включая документирование и изучение уроков проектов.
Процесс разработки СИ включает несколько итерационных (повторяющихся) циклов: цикл требований, цикл проектирования, цикл верификации (проверки), цикл управления.
1. Цикл требований помогает уточнить определение требований путем распределения функций по подсистемам и компонентам на различных уровнях.
2. Цикл проектирования включает итерационные приложения результатов функционального анализа и распределения для проектирования продукта, чтобы система в целом могла работать в соответствии со всеми заданными требованиями.
3. Цикл верификации включает проведение испытаний спроектированного продукта, его подсистем и компонентов для контроля того, что все требования выполняются на всех уровнях.
4. Цикл управления обеспечивает рассмотрение и анализ вопросов в нужное время, и принятие правильных решений. Контур управления обеспечивает обмен информацией со всем персоналом, участвующим в программе разработки продукта.
Один из вариантов представления процесса разработки в системной инженерии в виде взаимосвязанных итерационных петель обратной связи показан на рис. 4.
Циклы повторяются для изменения архитектуры и конфигурации продукта, чтобы достичь сбалансированного дизайна продукта (т.е. удовлетворительно отвечающего всему набору требований с компромиссными решениями между различными конструктивными соображениями).
В ходе разработки системы должны быть спланированы действия на последующих этапах жизненного цикла. Планируются этапы производства или строительства готовой продукции, эксплуатации и послепродажной поддержки, а также вывода из эксплуатации и утилизации. Это важно для скорейшей передачи системы потребителям и организации процесса возврата инвестиций.
Детальное описание особенностей реализации процесса разработки систем можно найти в представленном в конце книги рекомендательном списке литературы [2,3,8,9]. Далее будут представлены некоторые особенности этапов разработки системы.
1.4 Формирование требований к системе
Выявление свойств и характеристик будущей системы начинается с задачи маркетингового исследования рынка. Типовая постановка задачи маркетинга описывает потребности клиента, заявляет цели проекта, очерчивает предмет проблемы, определяет концепцию эксплуатации. Необходимо оценить требования заинтересованных сторон, характеристики системы, стоимость, примерный график выхода на рынок, потребное вспомогательное оборудование, технологические риски, структуру декомпозиции работ, вплоть до наличия исходных запчастей и готовности к ремонту.
Рыночная привлекательность продукта определяется набором его преимуществ. Например, для системы гражданского самолета это дальность, грузоподъемность, стоимость пассажиро-километра, вес, надежность, наличие послепродажного обслуживания, стоимость владения, и др. Критерии принятия решений на рынке могут быть назначены на основе качественных мер эффективности, которые учитывают голос клиента, и количественных показателей эффективности, которые оценивают голос инженеров.
У новой системы могут быть также нематериальные преимущества, которые нелегко измерить. К ним относятся улучшение экологичности, повышение лояльности клиентов, лучшее качество, лучшее обслуживание, большее удовлетворение работой сотрудников, и так далее. Эти факторы могут влиять на экономическую осуществимость системы.
Ожидаемые результаты маркетинговых исследований включают выбор концепции эксплуатации системы, архитектуры системы, производные требования (альтернативы функций, распределение требований). На их основе формируют верхний уровень требований к системе.
Требование – это утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (стандарт ISO/IEC 29148 «Разработка требований»).
Есть несколько причин, зачем нужны требования:
• Требования определяют цель программы, например, чтобы предложить хороший продукт на рынок и получить прибыль от реализации проекта.
• Требования определяют, что система должна делать, и управляют ее развитием.
• Требования определяют ограничения, связанные с реализацией проекта, а именно сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства, и т. д.
Требования не являются спецификациями. Они определяют функции, характеристики системы, и задачи в части окружающей среды. Распространенной ошибкой является чрезмерное ограничение проектирования путем указания ненужных барьеров, ограничивающих творчество архитекторов и инженеров при выполнении проекта.
Посредством требований уточняются формулировки или характеристики продукта или системы, которые разработчик хочет или должен получить. В системных требованиях учитывают запросы заинтересованных сторон – производителей, поставщиков, операторов и других лиц. Сюда входят корпоративные клиенты, заинтересованные в рынке системы, низких эксплуатационных и капитальных затратах. Операторы системы, заинтересованные в ее производительности, долговечности, надежности, наличии запасных частей, и т. д. Пользователи, которые заботятся о комфорте, безопасности и удобстве использования. Эти стороны, в конечном счете, будут использовать систему, извлекать из нее выгоду, управлять, поддерживать в рабочем состоянии, влиять на нее или подвергаться ее воздействию.
Необходимым стартовым компонентом для продвижения по этапам разработки является документ «Концепция эксплуатации». В стандартах РФ документ не фигурирует, однако полезен для разработчиков, а также при разрешении последующих возможных конфликтов исполнителя с заказчиком. В нем количественно и качественно описывают ожидаемые характеристики разрабатываемой системы с точки зрения пользователя. По мере разработки и проверки концепции потребности заинтересованных сторон преобразуются в эксплуатационные требования. Задачей концепции является наглядное описание целей создания системы, «что» она должна делать, а не «как». Это не техническое задание, где изложен детальный набор требований к системе, подсистемам и элементам.
Концепция эксплуатации должна ответить на ряд вопросов пользователя.
• Что требуется от системы с функциональной точки зрения?
• Какие основные и второстепенные функции должна выполнять система?
• Что ограничивает ее возможности?
• Что пользователи ценят в ожидаемом продукте?
• Когда необходимо построить и поставить систему?
• Каков запланированный жизненный цикл системы?
• Какова предполагаемая стоимость жизненного цикла системы?
• Где предполагается использовать систему?
Наличие четко определенной концепции эксплуатации является ключевым исходным основанием для успеха системы. Нельзя начинать работу с ожиданиями, что можно спроектировать что-то сейчас, а исправить позже.
Далее начинается процесс формирования из системных требований верхнего уровня набора требований к системе в терминах, понятных разработчикам. Следует изложить, что должна делать новая система, и насколько хорошо она должна это делать. Заявленные требования предоставляются заказчиками систем, например, через часто используемые запросы контрактных предложений (RFP) и рабочие задания (SOW). Эти требования обычно формулируются на языке заказчика, зачастую в виде пожеланий. Требования заказчика недостаточны для проектирования системы. Обычно они неполные, нечетко сформулированные, а иногда и противоречивы по своему характеру. Системные требования должны быть собраны, отфильтрованы, уточнены, декомпозированы и задокументированы. Для этапа разработки необходим полный, технически обоснованный и точный набор системных требований, которые необходимо реализовать.
Требования являются ключом к успеху проекта. Хорошие требования к системе или продукту должны быть:
• Специфичны, должны отражать только один аспект конструкции или характеристик системы. Кроме того, должны быть выражены в терминах потребности (что и как хорошо), а не решений (как).
• Измеримы, характеристика выражается объективно и количественно, может быть проверена при испытании.
• Достижимы, технически реализуемы при доступных затратах, параметры элементов должны соответствовать законам физики и современным технологиям.
• Прослеживаемы, требования нижнего дочернего уровня должны четко вытекать из требований более высокого родительского уровня. Требования, не имеющие «родителей», должны быть оценены для необходимости включения на данный уровень.
Чтобы сформировать хорошие требования к системе, сначала нужно обратиться к заинтересованным сторонам. Это пользователи системы, операторы и специалисты по обслуживанию системы. Кроме того, это люди, которые косвенно влияют на пользователей системы, администраторы, вспомогательный персонал и разработчики системы. В обсуждениях с заинтересованными сторонами определяются потребности, которые должна удовлетворять система. Далее на основе этих запросов формируют системные требования, которые определяют, что будет делать система.
Для сбора потенциальных требований можно использовать разные источники.
1. Интервью с пользователями для уточнения дизайна продукта и улучшения качества.
2. Опрос и анкетирование, которые широко используются в социальных исследованиях и анализе рынка.
3. Наблюдение, которое включает фиксацию выполнения определенных функций и задач.
4. Изучение документов для сбора информации о том, как системы использовались, что необходимо добавить или улучшить в следующей версии системы.
5. Изучение аналогичных систем. Для этого можно использовать интервью с пользователями, исследование критических инцидентов, вопросов работоспособности, ремонтопригодности и удобства использования.
При сборе и анализе системные требования удобно классифицировать по типам:
– Функциональные требования, отвечающие на вопрос «что система должна делать?»
– Требования к рабочим характеристикам, отвечающие на вопрос «как хорошо система исполняет нужные функции?»
– Экологические, нефункциональные требования и сценарии использования, отвечающие на вопрос «при каких условиях экологии, надежности и доступности система должна работать для удовлетворения данного требования?»
– Ограничения системы. Они могут зависеть от предлагаемых решений. Необходимо учитывать внешние интерфейсы, налагаемые другими системами, например, габариты входной двери на объекте, условия хранения, транспортировки, эксплуатации, и др. Сюда же отнесены известные возможности потенциального конкурента, что ограничивает диапазон практических решений проекта.
– Политика и публичные законы, которые вносят ограничения по безопасности, экологии и шуму.
– Требования к качеству, включая требования к безопасности.
– Бизнес-требования, в том числе цена продукта, стоимость жизненного цикла, конкурентоспособность, и так далее.
– Требования к процессам жизненного цикла продукта, включающие скорость выхода на рынок, послепродажное обслуживание, и др.
Функциональные (эксплуатационные) требования к системе должны решать следующие основные проблемы.
• Сформулировать общую цель создания системы и перечислить основные функции, которые должна выполнять система. Для этого удобно определить набор эксплуатационных сценариев.
• Определить рабочие характеристики предполагаемых функций системы.
• Определить требования к жизненному циклу и использованию системы, включая предполагаемый срок службы системы. Задать режим использования системы, например, часы в день, дни в неделю, месяцы в году.
• Определить факторы эффективности системы, то есть стоимость жизненного цикла, доступность системы, средние интервалы времени между обслуживанием, логистическую поддержку, уровень квалификации обслуживающего персонала, и так далее.
• Определить факторы воздействия окружающей среды на работу и обслуживание системы, включая физические условия, климатическую зону, температуру, влажность, экологичность влияния системы на окружающую среду.
Написание хороших требований требует инженерных знаний системы, навыков общения с людьми и, прежде всего, способности мыслить критически и творчески. Сначала требование выражают в качественной форме. Например, «Автомобиль должен иметь возможность двигаться в прямом направлении и задним ходом, а направление движения должно выбираться водителем». Далее добавляют количественные оценки. Например, «Автомобиль должен проезжать в среднем 150 км с заправкой десяти литров топлива при следующих условиях: X, Y и Z» или «Уровень шума внутри автомобиля не должен превышать 55 децибел на скорости ниже 120 км в час, при движении по стандартному асфальтовому покрытию». Качественные и количественные требования заносят в документ, называемый техническим заданием (ТЗ). Выполнение требований, указанных в ТЗ, является обязательным для результата проекта.
После выявления требований проводят их анализ. Необходимо понять, что действительно нужно пользователям, и получить полную картину, как система будет использоваться, когда она будет построена. Типовыми инструментами здесь являются сценарии использования, или описания применения системы пользователями. По ним можно представить действия пользователя и функции системы, изучить и обсудить потенциальные проблемы с предполагаемым использованием системы. Одним из важных аспектов этого этапа анализа является преобразование требований пользователей в количественные технические показатели эффективности. В процессе, который называют развертыванием функции качества (QFD), выполняют преобразование голоса потребителя (требований и ожиданий) в технические характеристики продукции и рабочие инструкции. Потребности клиентов могут быть сформулированы расплывчатыми и качественными терминами, их нелегко измерить. QFD переводит эти требования с языка заказчиков на язык инженеров, перед которыми стоит задача разработки решений. Термин «развертывание» относится к распределению требований от верхнего уровня системы на подсистемы, модули, компоненты, программное обеспечение и материалы, а также на процессы их изготовления и сборки в производстве.
Концептуальное проектирование является первым, и наиболее важным шагом в процессе проектирования системной инженерии. На предыдущем этапе фиксируют системные потребности и эксплуатационные требования, которые собирают в один всеобъемлющий документ. На основе требований к системе изучаются концепции проектирования в сочетании с анализом осуществимости системы. На этой стадии рассматривают наиболее широкий спектр потенциально возможных решений, которые могут дать значительные преимущества для будущего продукта.
Чтобы проект был реализован, он должен быть выполнимым. Анализ осуществимости дает ответы на вопросы «Выгодно ли проектировать систему?» и «Сможем ли мы это сделать?» Чтобы объективно оценить возможность успеха реализации проекта, изучают потенциальный рынок и группы клиентов, учитывают факторы окружающей среды, доступ к необходимым ресурсам, готовность персонала, и текущие или разрабатываемые технологии. Критериями при оценке осуществимости проекта системы выбирают стоимость проекта и ценности для организации, полученные при проектировании.
Рассматривают три взаимосвязанных компонента осуществимости, технический, эксплуатационный и экономический. Техническая осуществимость оценивает доступность технических ресурсов, готовность и зрелость существующих и новых технологий. Также при разработке системы следует учесть законы, нормативные акты, стандарты и кодексы, которым должна удовлетворять новая разработка, включая стандарты безопасности и характеристик. В них указаны требования по охране труда, управлению качеством, экологии, и т. д.
Эксплуатационная осуществимость показывает, насколько хорошо предлагаемая система удовлетворяет заданным требованиям. Для анализа этого фактора разработчикам необходимо ответить на ряд вопросов. Хорошо ли эта система работает с существующей средой? Как система удовлетворяет потребности клиентов? Есть ли у разработчиков необходимые резервы для разработки такой системы, включая возможности организации, готовность ресурсов, навыков и обучения персонала? По ответам оценивают потенциальные плюсы и минусы эксплуатационной эффективности системы.
Экономическая осуществимость, также называемая анализом затрат и выгод, измеряется рентабельностью предлагаемой системы в течение проектного срока службы. Нужно оценить, в какие сроки окупятся затраты на разработку, так как конечной целью организации, инициирующей выпуск нового продукта, является получение прибыли.
На стадии концептуального проектирования основные действия по проектированию включают:
• определение пользователей и потребностей системы;
• формирование эксплуатационных требований к системе, включая функции системы, а также концепции обслуживания и поддержки системы;
• проведение анализа технических, социальных и экономических проблем, связанных с проектированием системы, и разработку плана действий для ее создания;
• проведение функционального анализа на системном уровне для определения иерархической структуры функций системы и рабочих отношений между ними;
• документирование исходной функциональной базовой версии системы;
• проведение обзора концептуального дизайна.
После уточнения концепции эксплуатации переходят к определяющему действию системной инженерии – к разработке архитектуры новой системы (не путать с архитектурой зданий).
Архитектура системы – это структура компонентов, их отношений, а также принципов и руководств, регулирующих их проектирование и развитие во времени (определение компании Boeing).
Системная архитектура отражает утвержденные системные требования. Она содержит наиболее важные стратегические реализационные решения, изобретения, инженерные компромиссы. В процессе разработки архитектуры формируется набор представлений, как система будет удовлетворять системным требованиям, все основные логические, физические, статические и динамические структуры, альтернативные решения, допущения и обоснования. Архитектура может включать функции системы, характеристики, технологию, оценку стоимости, риски, ограничения, границы системы и так далее. Перечень функций затрагивает используемые в эксплуатации входные и выходные данные, сценарии использования, циклические процессы, функциональные требования, приоритеты. Поведение компонентов является частью архитектурного описания.
Архитектура не является единой структурой. Она определяет основные части системы и то, как эти части будут взаимодействовать друг с другом, чтобы удовлетворить общие системные требования. Определения архитектуры не уточняют, что представляют собой компоненты. При формировании архитектуры можно использовать диаграммы, наброски, рисунки, таблицы, и другие наглядные материалы для выражения пожеланий будущих пользователей. Например, в одном из стандартов имеется более 50 разделов по типам описаний архитектуры.
Процесс функционального проектирования заключается в определении элементов и разработке функциональной архитектуры. Идентификация функциональных элементов осуществляется путем анализа технических требований. Затем требования к характеристикам системы должны быть распределены по функциям. Нужно установить и оценить несколько вариантов функциональных архитектур, и выбрать одну. Оценка различных альтернативных архитектур в сравнении по нескольким параметрам (качество, стоимость, время, производительность, риски, и т.д.) приводит к выбору компромиссного решения для дальнейшей разработки. В ряде случаев этот шаг подменяют традиционным решением из «запасников».
После определения функциональной архитектуры системы целью процесса физического проектирования является разработка различных архитектур для поддержки этих функций. Разработка физической архитектуры включает логические модели физического решения. Эти представления могут состоять из концептуальных проектных чертежей и блок-схем, которые определяют форму и расположение компонентов системы, и связанных интерфейсов. Основные действия, выполняемые при разработке физической архитектуры и дизайна, включают анализ и синтез вариантов, идентификацию и определение физических интерфейсов и компонентов, критических атрибутов, включая проектный бюджет (например, вес, надежность), анализ ограничительных требований. Усилия на этом этапе сосредоточены на определении классов компонентов, установлении параметров и выборе критериев для присвоения элементов функциональной архитектуры физическим компонентам. Проводится сравнение нескольких возможных физических архитектур, чтобы оценить их осуществимость. Далее остается выбрать финальную архитектуру, определить окончательное проектное решение, проверить и обосновать его. Разработка физической архитектуры является итеративным процессом. Он завершается, когда система декомпозирована до самого нижнего уровня системных элементов или элементов конфигурации. Рекомендуется ознакомиться с ГОСТ Р 57100—2016 «Системная и программная инженерия. Описание архитектуры».
Процесс разработки верхнего уровня архитектуры системы показан на рис. 5. Процесс движется из верхнего левого угла по часовой стрелке. Этапы на схеме пронумерованы.
В этом процессе важно идентифицировать производные требования и гарантировать, что они отслеживаются и являются частью общего набора требований. Рассматривают существующие технологии для удовлетворения требований пользователей.
Примерами рассматриваемых и фиксируемых целей в терминах стандарта архитектуры являются функциональность, выполнимость, применимость, предназначение и характеристики системы, известные ограничения, структура, поведение, функционирование, надежность, безопасность, информационное обеспечение, сложность, открытость, автономность, стоимость, график, динамичность, модульность. Архитектура определяет управление, изменение состояния, интеграцию подсистем, доступность данных, соответствие требованиям регуляторов, гарантии, деловые цели и стратегии, опыт заказчика, сопровождаемость, и утилизируемость системы.
После того, как архитектура системы сформирована, выполняют декомпозицию структуры системы или изделия. Структура системы связана с пятью другими ключевыми структурами:
1. структура требований к системе;
2. функциональная структура конструкций, технологических систем и компонентов;
3. геометрическая структура (например, в каком отсеке изделия, на каком уровне находится оборудование);
4. структура разбиения работ проекта (см. раздел 2.2);
5. организационная структура задействованных при реализации предприятий.
Далее необходимо дополнить и распределить требования верхнего уровня на всю структуру системы для каждого компонента. Формирование проектных требований начинается с уточнения внешних требований верхнего уровня, поступающих от заказчиков. Затем эти требования верхнего уровня группируют по конкретным направлениям:
• Требования к системе, где собраны требования к продукции, и ее характеристикам.
• Промышленные, производственные и испытательные требования.
• Требования к обеспечивающим процессам, включая применяемые процессы, управление проектом, качество и требования к закупкам.
Затем инженерные группы передают документы требований верхнего уровня исполнителям рабочих пакетов и поставщикам, для декомпозиции по компонентам и подсистемам. На основе архитектурных связей формулируются производные требования, необходимые для выполнения требований верхнего уровня.
Требования декомпозируют тремя способами: по потоку, распределением и ответвлениями. Декомпозиция требований вниз по потоку представляет прямую передачу их в подсистемы, для обеспечения характеристик системы в целом. Распределение включает количественный пропорциональный дележ требований верхнего уровня на компоненты нижнего уровня. Ответвление требований создает пропорциональную характеристику, зависящую от специфической реализации.
Одним из видов требований нижних уровней системы являются производные требования. Производными называют требования, которые прямо не указаны в наборе требований заинтересованных сторон, но они должны быть сформулированы, чтобы сделать базовые требования достижимыми при разработке элементов системы.
Прослеживаемость (трассировка) требований также является важной частью управления требованиями. После декомпозиции требований верхнего уровня на нижние уровни свойство прослеживаемости идентифицирует отношения и связи между требованиями разных уровней и их источниками, для возможности проверки их происхождения и правильности формулировки.
