Моделирование процесса инженерии требований на промышленном предприятии Батоврин В.К.1, Гайдамака К И.2 1 Московский Технологический Университет (МИРЭА), Москва, Россия vkbat@mail.ru 2 Московский Технологический Университет (МИРЭА), Москва, Россия k.gaydamaka@gmail.com Abstract. This paper presents some special aspects of requirements engineering process modeling for enterprises creating complex technical products. Аннотация. В докладе рассмотрены особенности моделирования процес- са инженерии требований в условиях предприятия, создающего сложную техническую продукцию. Ключевые слова: системная инженерия, инженерия требований, качество требований. 1 Введение Важнейшей составляющей деятельности по созданию сложных инженерных объектов является работа с требованиями. Практически все крупные компании, занятые созданием сложной техники, признают, что налаженная инженерия требований критически важна для успеха проектов и является одним из ключе- вых элементов повышения конкурентоспособности предприятий и их продук- ции на мировом рынке. Для установления на предприятии зрелого процесса инженерии требований, а также для его поддержки инструментальными средствами, требуется модель процесса инженерии требований. Общепризнанной модели процесса инженерии требований, пригодной к адаптации к условиям деятельности произвольного предприятия, сегодня не существует. Поэтому на каждом предприятии, созда- ющем сложные системы, приходится налаживать свой уникальный процесс инженерии требований, отвечающий особенностям предметной области и кон- кретного бизнеса. Процесс инженерии требований является комплексным и сложным, поэтому, возможны ситуации, когда предприятию приходится вы- страивать отдельный процесс инженерии требований, адаптированный для кон- кретного проекта, например, компания Airbus налаживала подобный процесс при реализации проекта по созданию самолета A 380 [4]. Цель работы – анализ существующих моделей процесса инженерии требований и выявление принци- 402 пов, которые могут быть положены в основу выполнения работ по моделирова- нию этого процесса на промышленном предприятии. 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], состоит в выделении отдельных процессов инженерии требова- ний в области проблем и в области решений, а также в тесной увязке процесса инженерии требований с процессом моделирования интересующей системы 403 посредством операций анализа и выработки вариантов проектного решения. Подобная модель позволяет получить наглядное представление о взаимосвязи между исходными и производными требованиями и облегчить формирование стратегии проверки соответствия. К. Поль, в свою очередь, предлагает при моделировании процесса инженерии требований использовать три точки зрения: процесс, уровни абстракции, типы артефактов [13]. При этом в качестве ключевых действий процесса инженерии требований выделяется выявление, документирование и согласование требова- ний с добавлением сквозных действий по валидации и управлению требования- ми. Модель также определяет типовые артефакты инженерии требований: Цели, Сценарии и Требования к решению (Solution-oriented requirements). В ряде отраслей промышленности, в частности в авиации, сформировались свои подходы к моделированию инженерии требований, см., например, [5, 6]. В основу подобных моделей положена практика организации производственных процессов, сложившаяся на зарубежных предприятиях в течение десятков лет, что затрудняет прямую адаптацию содержащихся в документах рекомендаций к условиям отечественного предприятия. Таким образом, адаптация имеющихся рекомендаций по моделированию процесса инженерии требований к условиям конкретной организации должна выполняться в два этапа: • Первый этап – адаптация рекомендаций международных стандартов для кон- кретной отрасли или предприятия, например, авиационной, атомной, меди- цинской, военной. На этом этапе главным образом определяются состав, цели и результаты процессов. • Второй этап – адаптация отраслевых или корпоративных стандартов для кон- кретного проекта или контракта. На этом этапе в основном определяются особенности и порядок реализации деятельности по инженерии требований на отдельном предприятии или в конкретном проекте. Выполненный нами применительно к авиационной отрасли анализ норматив- ных и методических документов, а также отраслевых стандартов показал, что сегодня необходимо сосредоточиться на первом этапе работ. Это обусловлено тем, что адаптация международных рекомендаций по инженерии требований повлечет за собой необходимость коренной перестройки традиционных инже- нерных и управленческих процессов на предприятии. Важнейшим результатом подобной работы должна стать контекстная диаграмма, учитывающая цели процесса инженерии требований и содержащая описание его состава, входов и выходов, а также факторов управления, имеющихся ресурсов и ограничений. 3 Инженерия требований и разработка архитектуры Общепризнанно, что существует глубокая и неразрывная связь между процес- сом инженерии требований и процессом определения архитектуры. При этом в литературе можно встретить утверждение, что создание системы начинается с 404 выяснения нужд и обоснования требований, на основе которых, в свою очередь, определяется архитектура. В действительности связь между требованиями и архитектурой намного сложнее. Основная особенность взаимосвязи между требованиями и архитектурой за- ключается в том, что даже на самых ранних этапах жизненного цикла у создате- лей системы всегда имеется унаследованное представление о ее архитектуре. Кроме того, в процессе разработки могут быть установлены требования, кото- рые не получены от заказчика или пользователей, а определяются именно архи- тектурными решениями [13]. Таким образом, вне зависимости от типа создава- емой системы отдать явное предпочтение определенной парадигме проектиро- вания: «требования-архитектура-требования» или «архитектура-требования- архитектура» – бывает затруднительно. Подобная ситуация характерна не толь- ко для автомобилестроения или авиакосмической техники, но и для других от- раслей, например, сферы телекоммуникаций, где рекомендованные решения относительно архитектуры часто содержатся в телекоммуникационных стандар- тах [17]. Причем, в тех случаях, когда в отрасли сложилось устоявшееся пред- ставление о типовой архитектуре целевой системы, оно начинает оказывать заметное влияние и на структуру предприятия и на структуру отрасли в целом, например, специализации поставщиков авиационных систем соответствуют элементам типовой архитектуры воздушных судов. В авиастроении сложившиеся представления об архитектуре нашли отраже- ние в таких стандартах как ATA 100 [2] и S1000D [14]. При этом попытка опти- мизации архитектуры изделия без учета типовой архитектуры (с чистого листа) приводит к необходимости решения множества организационных и техниче- ских трудностей, как это было в проекте Boeing 787 Dreamliner [11]. Описанное положение хорошо иллюстрируется «моделью двух вершин» (Рис. 1), из которой следует что разработка требований и архитектуры – два параллельных, неразрывно связанных между собой процесса [12]. Укрупненно Специфицирование Уровень детальности Требования Архитектура Детально Не зависит Зависит Зависимость от реализации Рис. 1. Модель двух вершин [11] 405 Анализ практики западных компаний, занятых созданием сложной техники показал, что в настоящее время при моделировании процесса инженерии требо- ваний за основу всегда берется типовая, признанная в отрасли иерархическая структура целевой системы [4], которую принято называть схемой разукруп- нения продукции (PBS, The Product Brakedown Structure), где за каждым уров- нем иерархии закрепляется свое название. Например, в Airbus принято исполь- зовать четырехуровневую схему: самолет, система самолета, подсистема, агре- гат [9]. Кроме того предполагается, что процесс инженерии требований приме- няется рекурсивно на каждом иерархическом уровне, а жесткие ограничения на сроки реализации программы заставляют широко использовать параллельное проектирование когда разработка ведется на всех уровнях декомпозиции изде- лия одновременно [1]. Отметим, что имеется отечественная практика использо- вания уровней разукрупнения инженерных объектов с учетом функциональной и конструктивной сложности [18]. Однако эта практика увязывается главным образом с проблемами документирования и стандартизации, а не с решением задачи обеспечения гарантированной взаимосвязи и прослеживаемости в тре- угольнике «требования-архитектура-объекты конфигурации». В качестве примера можно привести отечественное предприятие, разрабаты- вающее авиационную технику. Игнорирование типовой архитектуры в качестве основы для построения процесса инженерии требований привело к трудностям при организации прослеживания требований: требования к элементам структу- ры изделия второго уровня не были документированы, а обеспечить прослежи- ваемость требований между уровнем изделия (первый уровень) и уровнем под- систем (третий уровень) оказалось затруднительно ввиду чрезмерно большого количества связей. Отсутствие адаптации рекомендаций международных стан- дартов к особенностям отрасли, отсутствие гармонизации процессов инженерии требований с процессами управления конфигурациями (вариативность испол- нения изделия) и использование для работы с требованиями распространенного программного продукта, привело к необходимости перестройки процесса инже- нерии требований и значительной доработки программных средств по работе с требованиями на поздних стадиях авиационной программы. Таким образом, в основу модели процесса инженерии требований должно быть положено критически осознанное представление о взаимосвязи между процессами определения архитектуры и определения требований. В свою оче- редь, формирование адекватного представления об этой взаимосвязи невозмож- но без углубленного анализа сложившейся мировой практики и отраслевых стандартов, а также применения утвержденных в установленном порядке, обя- зательных для всех участников работ моделей иерархической структуры целе- вой системы. 4 Функциональный анализ и привязка требований Еще одним важным аспектом моделирования процесса инженерии требований представляется определение процедуры функционального анализа и привязки 406 требований (functional analysis and allocation). Важным ограничением здесь яв- ляется то, что русскоязычное нормативное и методическое обеспечение подоб- ной процедуры практически отсутствует. Кроме того, обзор русскоязычных публикаций, а также результаты консультаций со специалистами показали, что практика подобной деятельности на отечественных промышленных предприя- тиях не сложилась и ее придется формировать по существу с нуля. Дополни- тельно осложняет ситуацию необходимость автоматизации указанных процедур при создании сложных систем, поскольку консультанты и поставщики про- граммного обеспечения склонны к использованию типовых решений и их адап- тации за счет заказчика, что повышает вероятность ошибок. В основу функционального анализа и привязки требований может быть поло- жено итеративное применение процедур синтеза, анализа и оценки, как мы пред- лагали в [15, 16]. В рамках синтеза происходит преобразование практических целей в описание функций, подлежащих выполнению, в процессе анализа выпол- няется функциональная декомпозиция с привязкой функций к подсистемам на основании описания функциональных взаимодействий и формирование на этой основе представления о конфигурации системы, наконец, оценка предполагает валидацию решений с использованием базовых процедур валидации требований, описанных в литературе, см., например, [13]. Одним из важнейших результатов функционального анализа является получение исходных данных для прослежива- ния функциональных требований. Прослеживаемость функциональных требова- ний снизу-вверх дает, в частности, возможность получения объективных свиде- тельств того, что создаваемая система позволит удовлетворить нужды заинтере- сованных сторон. Прослеживаемость сверху-вниз помогает выделить объекты конфигурации, получить представление об их функционировании и заложить основы для налаживания процедуры управления конфигурацией. На начальном этапе при формировании практической процедуры функцио- нального анализа целесообразно взять в качестве прототипа зарубежные реко- мендации, например, Обобщенный метод инженерии требований корпорации Airbus (Method for Common Airbus Requirements Engineering, CARE) [4] Модели, описанные в подобных источниках, прошли апробацию в соответствующих отраслях, что снижает риски отечественных предприятий на первых этапах налаживания зрелого процесса инженерии требований. Среди базовых принципов, реализованных в CARE, можно выделить: • Использование типовой структуры деления изделия на части; • Использование определенной иерархической структуры требований, вклю- чающей указание типов требований; • Применение функционального анализа для обеспечения целостности и пол- ноты требований; • Документирование требований с использованием типовых спецификаций; • Ориентация на работу с данными, а не с документами; • Необходимость обеспечения прослеживаемости требований. 407 5 Заключение При моделировании процесса инженерии требований его необходимо рассмат- ривать в неразрывной связи с процессом описания архитектуры целевой систе- мы и процессом управления конфигурацией, причем, в зависимости от особен- ностей конкретного проекта в качестве исходного может служить любой из названных процессов. Среди важнейших принципов моделирования следует выделить: 1. Адаптацию рекомендаций международных стандартов системной инженерии и инженерии требований к условиям отечественного предприятия с акцентом на состав и контекст использования типовых процессов, что предполагает перестройку традиционных инженерных и управленческих процессов на предприятии, т.е. даже хорошая модель процесса инженерии требований ма- лоэффективна в отрыве от налаживания других ключевых процессов систем- ной инженерии. 2. Использование при моделировании в качестве основы критически осознанно- го представления о взаимосвязи между процессами определения архитектуры и определения требований, в частности, при наличии общепризнанной, типо- вой архитектуры моделировать процесс инженерии требований следует в привязке к этой архитектуре с выделением обязательной иерархической структуры целевой системы. 3. Формирование на предприятии типовой процедуры функционального анали- за и привязки требований, основанной на итеративном применении процедур синтеза, анализа и оценки с акцентом на обеспечении двусторонней просле- живаемости и использованием в качестве прототипа известных зарубежных отраслевых рекомендаций по определению функциональных требований. 4. Осторожность при выборе программных средств, реализующих функцио- нальные возможности по работе с требованиями, т.е. сначала предприятие должно определить свои процессы работы с требованиями, а потом выбрать средства автоматизации. 5. Необходимость обязательной гармонизации между собой моделей процессов инженерии требований и управления конфигурацией. Литература 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. 408 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 pro- cesses". 8. ISO/IEC/IEEE 29148:2011 Systems and software engineering. Life cycle processes. Re- quirements 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 In- ternational Conference on Product Focused Software Process Improvement, Oulu, Fin- land, 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. 15. Батоврин В.К. Современная системная инженерия и ее роль в управлении проектами (Часть 2)// Управление проектами и программами. 2015. № 4(44). С. 276-289. 16. Батоврин В.К., Гайдамака К.И. Инженерия требований – ключевой фактор успеха проектов // Управление проектами и программами. 2017. Т. 1. № 49. С. 6–20. 17. Халл Э. и др. Инженерия требований. – М.: ДМК Пресс, 2017. 18. ГОСТ Р 52003-2003 Уровни разукрупнения радиоэлектронных средств. Термины и определения. – М.: Стандартинформ. – 2003