This paper presents some special aspects of requirements engineering process modeling for enterprises creating complex technical products. Аннотация. В докладе рассмотрены особенности моделирования процесса инженерии требований в условиях предприятия, создающего сложную техническую продукцию.
Важнейшей составляющей деятельности по созданию сложных инженерных объектов является работа с требованиями. Практически все крупные компании, занятые созданием сложной техники, признают, что налаженная инженерия требований критически важна для успеха проектов и является одним из ключевых элементов повышения конкурентоспособности предприятий и их продукции на мировом рынке. Для установления на предприятии зрелого процесса инженерии требований, а также для его поддержки инструментальными средствами, требуется модель процесса инженерии требований. Общепризнанной модели процесса инженерии требований, пригодной к адаптации к условиям деятельности произвольного предприятия, сегодня не существует. Поэтому на каждом предприятии, создающем сложные системы, приходится налаживать свой уникальный процесс инженерии требований, отвечающий особенностям предметной области и конкретного бизнеса. Процесс инженерии требований является комплексным и сложным, поэтому, возможны ситуации, когда предприятию приходится выстраивать отдельный процесс инженерии требований, адаптированный для конкретного проекта, например, компания Airbus налаживала подобный процесс при реализации проекта по созданию самолета A 380 [4]. Цель работы -анализ существующих моделей процесса инженерии требований и выявление принци-пов, которые могут быть положены в основу выполнения работ по моделированию этого процесса на промышленном предприятии.
Существующие рекомендации и модели Кроме того, упомянутые стандарты включают описание процессов, тесным образом связанных с инженерией требований, но не предполагающих получение требований в качестве основного результата, в том числе:
• Процесс определения архитектуры (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]. В основу подобных моделей положена практика организации производственных процессов, сложившаяся на зарубежных предприятиях в течение десятков лет, что затрудняет прямую адаптацию содержащихся в документах рекомендаций к условиям отечественного предприятия.
Таким образом, адаптация имеющихся рекомендаций по моделированию процесса инженерии требований к условиям конкретной организации должна выполняться в два этапа:
• Первый этап -адаптация рекомендаций международных стандартов для конкретной отрасли или предприятия, например, авиационной, атомной, медицинской, военной. На этом этапе главным образом определяются состав, цели и результаты процессов.
Общепризнанно, что существует глубокая и неразрывная связь между процессом инженерии требований и процессом определения архитектуры. При этом в литературе можно встретить утверждение, что создание системы начинается с выяснения нужд и обоснования требований, на основе которых, в свою очередь, определяется архитектура. В действительности связь между требованиями и архитектурой намного сложнее. Основная особенность взаимосвязи между требованиями и архитектурой заключается в том, что даже на самых ранних этапах жизненного цикла у создателей системы всегда имеется унаследованное представление о ее архитектуре. Кроме того, в процессе разработки могут быть установлены требования, которые не получены от заказчика или пользователей, а определяются именно архитектурными решениями [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]. Однако эта практика увязывается главным образом с проблемами документирования и стандартизации, а не с решением задачи обеспечения гарантированной взаимосвязи и прослеживаемости в треугольнике «требования-архитектура-объекты конфигурации».
В качестве примера можно привести отечественное предприятие, разрабатывающее авиационную технику. Игнорирование типовой архитектуры в качестве основы для построения процесса инженерии требований привело к трудностям при организации прослеживания требований: требования к элементам структуры изделия второго уровня не были документированы, а обеспечить прослеживаемость требований между уровнем изделия (первый уровень) и уровнем подсистем (третий уровень) оказалось затруднительно ввиду чрезмерно большого количества связей. Отсутствие адаптации рекомендаций международных стандартов к особенностям отрасли, отсутствие гармонизации процессов инженерии требований с процессами управления конфигурациями (вариативность исполнения изделия) и использование для работы с требованиями распространенного программного продукта, привело к необходимости перестройки процесса инженерии требований и значительной доработки программных средств по работе с требованиями на поздних стадиях авиационной программы.
Таким образом, в основу модели процесса инженерии требований должно быть положено критически осознанное представление о взаимосвязи между процессами определения архитектуры и определения требований. В свою очередь, формирование адекватного представления об этой взаимосвязи невозможно без углубленного анализа сложившейся мировой практики и отраслевых стандартов, а также применения утвержденных в установленном порядке, обязательных для всех участников работ моделей иерархической структуры целевой системы.
Еще одним важным аспектом моделирования процесса инженерии требований представляется определение процедуры функционального анализа и привязки требований (functional analysis and allocation). Важным ограничением здесь является то, что русскоязычное нормативное и методическое обеспечение подобной процедуры практически отсутствует. Кроме того, обзор русскоязычных публикаций, а также результаты консультаций со специалистами показали, что практика подобной деятельности на отечественных промышленных предприятиях не сложилась и ее придется формировать по существу с нуля. Дополнительно осложняет ситуацию необходимость автоматизации указанных процедур при создании сложных систем, поскольку консультанты и поставщики программного обеспечения склонны к использованию типовых решений и их адаптации за счет заказчика, что повышает вероятность ошибок. В основу функционального анализа и привязки требований может быть положено итеративное применение процедур синтеза, анализа и оценки, как мы предлагали в [15,16]. В рамках синтеза происходит преобразование практических целей в описание функций, подлежащих выполнению, в процессе анализа выполняется функциональная декомпозиция с привязкой функций к подсистемам на основании описания функциональных взаимодействий и формирование на этой основе представления о конфигурации системы, наконец, оценка предполагает валидацию решений с использованием базовых процедур валидации требований, описанных в литературе, см., например, [13]. Одним из важнейших результатов функционального анализа является получение исходных данных для прослеживания функциональных требований. Прослеживаемость функциональных требований снизу-вверх дает, в частности, возможность получения объективных свидетельств того, что создаваемая система позволит удовлетворить нужды заинтересованных сторон. Прослеживаемость сверху-вниз помогает выделить объекты конфигурации, получить представление об их функционировании и заложить основы для налаживания процедуры управления конфигурацией.
На начальном этапе при формировании практической процедуры функционального анализа целесообразно взять в качестве прототипа зарубежные рекомендации, например, Обобщенный метод инженерии требований корпорации Airbus (Method for Common Airbus Requirements Engineering, CARE) [4] Модели, описанные в подобных источниках, прошли апробацию в соответствующих отраслях, что снижает риски отечественных предприятий на первых этапах налаживания зрелого процесса инженерии требований.
Среди базовых принципов, реализованных в CARE, можно выделить:
• Использование типовой структуры деления изделия на части;