Моделирование процесса инженерии требований на промышленном предприятии

Abstract

This paper presents some special aspects of requirements engineering process modeling for enterprises creating complex technical products. Аннотация. В докладе рассмотрены особенности моделирования процесса инженерии требований в условиях предприятия, создающего сложную техническую продукцию. Ключевые слова: системная инженерия, инженерия требований, качество требований.

-

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

Для установления на предприятии зрелого процесса инженерии требований, а также для его поддержки инструментальными средствами, требуется модель процесса инженерии требований. Общепризнанной модели процесса инженерии требований, пригодной к адаптации к условиям деятельности произвольного предприятия, сегодня не существует. Поэтому на каждом предприятии, создающем сложные системы, приходится налаживать свой уникальный процесс инженерии требований, отвечающий особенностям предметной области и конкретного бизнеса. Процесс инженерии требований является комплексным и сложным, поэтому, возможны ситуации, когда предприятию приходится выстраивать отдельный процесс инженерии требований, адаптированный для конкретного проекта, например, компания Airbus налаживала подобный процесс при реализации проекта по созданию самолета A 380 [ 4 ]. Цель работы – анализ существующих моделей процесса инженерии требований и выявление принципов, которые могут быть положены в основу выполнения работ по моделированию этого процесса на промышленном предприятии. 2

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

При формировании модели состава процесса инженерии требований за основу могут быть взяты процессы, описанные в международных стандартах ISO/IEC 15288 «Системная и программная инженерия. Процессы жизненного цикла систем» [ 7 ] и ISO/IEC/IEEE 29148 «Системная и программная инженерия. Управление жизненным циклом. Инженерия требований» [ 8 ]. Эти стандарты не содержат описания модели процесса как таковой, однако предлагают набор процессов, которые пригодны для ее построения, а именно: • Процесс анализа хозяйственной деятельности или комплекса решаемых задач (Business or mission analysis process). • Процесс определения нужд и требований заинтересованных сторон (Stakeholder needs and requirements definition process); • Процесс определения требований к системе (System requirements definition process). Кроме того, упомянутые стандарты включают описание процессов, тесным образом связанных с инженерией требований, но не предполагающих получение требований в качестве основного результата, в том числе: • Процесс определения архитектуры (Architecture definition process). • Процесс определения проектно-конструкторских решений (Design definition process). • Процесс верификации (Verification process). • Процесс валидации (Validation process). Наконец, в указанных документах можно найти описание процессов, необходимых для управления требованиями, в частности: • Управление изменениями (Change management). • Измерения (Measurement for requirements). Примеры комплексных моделей процесса инженерии требований содержатся в ряде публикаций, например, [ 3, 10, 13, 17 ]. Ключевое отличие модели, предлагаемой в [17], состоит в выделении отдельных процессов инженерии требований в области проблем и в области решений, а также в тесной увязке процесса инженерии требований с процессом моделирования интересующей системы посредством операций анализа и выработки вариантов проектного решения. Подобная модель позволяет получить наглядное представление о взаимосвязи между исходными и производными требованиями и облегчить формирование стратегии проверки соответствия.

К. Поль, в свою очередь, предлагает при моделировании процесса инженерии требований использовать три точки зрения: процесс, уровни абстракции, типы артефактов [ 13 ]. При этом в качестве ключевых действий процесса инженерии требований выделяется выявление, документирование и согласование требований с добавлением сквозных действий по валидации и управлению требованиями. Модель также определяет типовые артефакты инженерии требований: Цели, Сценарии и Требования к решению (Solution-oriented requirements).

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

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

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

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

В авиастроении сложившиеся представления об архитектуре нашли отражение в таких стандартах как ATA 100 [ 2 ] и S1000D [ 14 ]. При этом попытка оптимизации архитектуры изделия без учета типовой архитектуры (с чистого листа) приводит к необходимости решения множества организационных и технических трудностей, как это было в проекте Boeing 787 Dreamliner [ 11 ].

Описанное положение хорошо иллюстрируется «моделью двух вершин» (Рис. 1), из которой следует что разработка требований и архитектуры – два параллельных, неразрывно связанных между собой процесса [ 12 ]. Укрупненно Уровень детальности Детально

Специфицирование Требования

Архитектура Не зависит

Зависит Зависимость от реализации Рис. 1. Модель двух вершин [ 11 ] Анализ практики западных компаний, занятых созданием сложной техники показал, что в настоящее время при моделировании процесса инженерии требований за основу всегда берется типовая, признанная в отрасли иерархическая структура целевой системы [ 4 ], которую принято называть схемой разукрупнения продукции (PBS, The Product Brakedown Structure), где за каждым уровнем иерархии закрепляется свое название. Например, в Airbus принято использовать четырехуровневую схему: самолет, система самолета, подсистема, агрегат [ 9 ]. Кроме того предполагается, что процесс инженерии требований применяется рекурсивно на каждом иерархическом уровне, а жесткие ограничения на сроки реализации программы заставляют широко использовать параллельное проектирование когда разработка ведется на всех уровнях декомпозиции изделия одновременно [ 1 ]. Отметим, что имеется отечественная практика использования уровней разукрупнения инженерных объектов с учетом функциональной и конструктивной сложности [18]. Однако эта практика увязывается главным образом с проблемами документирования и стандартизации, а не с решением задачи обеспечения гарантированной взаимосвязи и прослеживаемости в треугольнике «требования-архитектура-объекты конфигурации».

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

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

Функциональный анализ и привязка требований Еще одним важным аспектом моделирования процесса инженерии требований представляется определение процедуры функционального анализа и привязки требований (functional analysis and allocation). Важным ограничением здесь является то, что русскоязычное нормативное и методическое обеспечение подобной процедуры практически отсутствует. Кроме того, обзор русскоязычных публикаций, а также результаты консультаций со специалистами показали, что практика подобной деятельности на отечественных промышленных предприятиях не сложилась и ее придется формировать по существу с нуля. Дополнительно осложняет ситуацию необходимость автоматизации указанных процедур при создании сложных систем, поскольку консультанты и поставщики программного обеспечения склонны к использованию типовых решений и их адаптации за счет заказчика, что повышает вероятность ошибок.

В основу функционального анализа и привязки требований может быть положено итеративное применение процедур синтеза, анализа и оценки, как мы предлагали в [15, 16]. В рамках синтеза происходит преобразование практических целей в описание функций, подлежащих выполнению, в процессе анализа выполняется функциональная декомпозиция с привязкой функций к подсистемам на основании описания функциональных взаимодействий и формирование на этой основе представления о конфигурации системы, наконец, оценка предполагает валидацию решений с использованием базовых процедур валидации требований, описанных в литературе, см., например, [ 13 ]. Одним из важнейших результатов функционального анализа является получение исходных данных для прослеживания функциональных требований. Прослеживаемость функциональных требований снизу-вверх дает, в частности, возможность получения объективных свидетельств того, что создаваемая система позволит удовлетворить нужды заинтересованных сторон. Прослеживаемость сверху-вниз помогает выделить объекты конфигурации, получить представление об их функционировании и заложить основы для налаживания процедуры управления конфигурацией.

На начальном этапе при формировании практической процедуры функционального анализа целесообразно взять в качестве прототипа зарубежные рекомендации, например, Обобщенный метод инженерии требований корпорации Airbus (Method for Common Airbus Requirements Engineering, CARE) [ 4 ] Модели, описанные в подобных источниках, прошли апробацию в соответствующих отраслях, что снижает риски отечественных предприятий на первых этапах налаживания зрелого процесса инженерии требований.

Среди базовых принципов, реализованных в CARE, можно выделить: • Использование типовой структуры деления изделия на части; • Использование определенной иерархической структуры требований, включающей указание типов требований; • Применение функционального анализа для обеспечения целостности и полноты требований; • Документирование требований с использованием типовых спецификаций; • Ориентация на работу с данными, а не с документами; • Необходимость обеспечения прослеживаемости требований. При моделировании процесса инженерии требований его необходимо рассматривать в неразрывной связи с процессом описания архитектуры целевой системы и процессом управления конфигурацией, причем, в зависимости от особенностей конкретного проекта в качестве исходного может служить любой из названных процессов. Среди важнейших принципов моделирования следует выделить: 1. Адаптацию рекомендаций международных стандартов системной инженерии и инженерии требований к условиям отечественного предприятия с акцентом на состав и контекст использования типовых процессов, что предполагает перестройку традиционных инженерных и управленческих процессов на предприятии, т.е. даже хорошая модель процесса инженерии требований малоэффективна в отрыве от налаживания других ключевых процессов системной инженерии. 2. Использование при моделировании в качестве основы критически осознанного представления о взаимосвязи между процессами определения архитектуры и определения требований, в частности, при наличии общепризнанной, типовой архитектуры моделировать процесс инженерии требований следует в привязке к этой архитектуре с выделением обязательной иерархической структуры целевой системы. 3. Формирование на предприятии типовой процедуры функционального анализа и привязки требований, основанной на итеративном применении процедур синтеза, анализа и оценки с акцентом на обеспечении двусторонней прослеживаемости и использованием в качестве прототипа известных зарубежных отраслевых рекомендаций по определению функциональных требований. 4. Осторожность при выборе программных средств, реализующих функциональные возможности по работе с требованиями, т.е. сначала предприятие должно определить свои процессы работы с требованиями, а потом выбрать средства автоматизации. 5. Необходимость обязательной гармонизации между собой моделей процессов инженерии требований и управления конфигурацией. Литература

References

1. Altfeld , Hans-Henrich. Commercial aircraft projects: managing the development of highly complex products . - Ashagate , 2010 .

2. ATA Specification 100 - Specification for Manufacturers' Technical Data , Revision No. 37 , Air Transport Association of America, 1999 .

3. Batra M. A Comparative Study of Requirements Engineering Process Model // Int. J. Adv. Res. Comput. Sci . 2017 . Т. 8. № 3. С . 740 - 745 .

4. Boulanger J.-L. (Ed.) Formal Methods Applied to Industrial Complex Systems. - London: Wiley-ISTE. - 2014.

5. DOT/FAA/AR-08/32 Requirements Engineering Management Handbook 06/2009 URL: https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf

6. FAA Systems Engineering Manual. Version 1.1. September 2015 . - URL: https://sep.faa.gov/policy_and_guidance/main

7. ISO/IEC/IEEE 15288: 2015 "Systems and software engineering - System life cycle processes" .

8. ISO/IEC/IEEE 29148: 2011 Systems and software engineering. Life cycle processes . Requirements engineering . - URL: http://www.iso.org/iso/ru/catalogue_detail. htm?csnumber =45171

9. Lauzier C . -A., AIRBUS. Requirements management and MOD closure process study on the A330 WV80 project Master thesis report // 2014 .

10. Lehto , Jari, M. Pentti , Decision-based requirement engineering process , Proc. of the 6th International Conference on Product Focused Software Process Improvement , Oulu, Finland, 2005 .

11. Norris G. , Wagner M. BOEING 787 DREAMLINER . , 2009 . 160 с.

12. Nuseibeh B. Weaving Together Requirements and Architectures // Computer (Long. Beach. Calif). 2001 . Т. 34 . № 3. С. 115 - 117 .

13. Pohl К. Requirements Engineering . - Springer-Verlag Berlin Heidelberg 2010 .

14. S1000D , "International specification for technical publications using a common source database" . 2016 . Issue 4.2 . URL: http://public.s1000d.org.