3_Вимоги_1 / 09.17.12 / Второе поколение инженерии требований

Второе поколение инженерии требований

http://ailev.livejournal.com/754369.html

Опубликованы minutes к шестнадцатому заседанию INCOSE, на котором puln докладывал о системах управления требованиями (СУТ) в системной инженерии -- http://community.livejournal.com/incose_ru/9396.html. Там есть ссылка на два часа видео (в принципе, видео могло быть и больше, только при подключении флешки для демонстрации пары специально припасенных одним из участников обсуждения слайдов был выдернут шнур камеры для освобождения USB-разъема. В пылу дискуссии это не было замечено). Обсуждение споткнулось на понимании того, как СУТ обслуживают работу с требованиями на схеме V-диаграммы Это классическая схема из всех учебников по инженерии требований, но тут она дана не в разрезе инженерии требований в целом, а с точки зрения маленькой части: управление требований. Встал вопрос, как используется СУТ в части 1. обеспечения соглашений (включая практики инженерии требований и квалификации), и 2. обеспечения архитектурного проектирования, реализации, интеграции и испытаний. Работа СУТ в верхней части V (обеспечения соглашений) понятна -- можно обеспечивать "автоматизацию выдачи технических заданий и проверки их выполнения", а также "проверку соответствия требованиям технического регулирования"). Именно тут и появляется RIF, формат обмена требованиями, существенно отличающийся от формата обмена кусками информационной модели системы между подрядчиками. Работа в нижней части V (практики придумывания-изготовления) оказалась непонятна: природа этой работы сегодня стремительно меняется по мере появления нового поколения онтологических САПР и объединения всех видов информационных моделей по мере перехода к датацентрике, а вот что происходит при этом с "моделью требований" (эээ... содержимым базы данных системы управления требованиями) -- непонятно. Сами требования продолжают существовать не в виде семантических информационных моделей, как существует проект в сегодняшнем САПР, а в виде обрывков текста, требующих человеческой интерпретации. Такое впечатление, что все понятное машинам сегодня просто прекращают называть требованиями, а предпочитают называть как-нибудь иначе: business rules, информационная модель и т.д. А когда из понятного машинам это делается понятным юристам документом (юристы ведь появляются на запах контракта), то для обеспечения контрактации используют какие-то системы документооборота, только косвенно связанные с основными инженерными практиками. А разговор про инженерию требований к этому документообороту приклеивают только по историческим причинам: поезд ушел, а перрон-то остался! Моделирование самих требований еще не завоевало место под солнцем. Так, классики "текстовых требований" для систем типа DOORS пишут (http://download.boulder.ibm.com/ibmdl/pub/software/dw/ru/download/eBook_RU_Requirements_Engineering.pdf), что "Некоторые употребляют термин «моделирование требований». Это термин является неверным по сути. Моделируется реализация системы, а не требования к ней". У классиков СУТ старого поколения модели отдельно, а требования -- тоже отдельно. Тут я хотел бы еще раз отметить, что я совершенно не стесняюсь слова "модель", но не хочу произносить его всуе. "Описания требований" предыдущих поколений и "модель требований", в которой есть явная семантическая (встроенный формализм, позволяющий определить значение употребленных терминов) составляющая -- это, как говорят в Одессе, две большие разницы. Модель -- это семантическая модель. Описание же может быть как моделью, так и художественным описанием (совершенно непонятным компьютеру и хранящимся в виде текстовых строк в специализированных системах документооборота по поводу требований типа DOORS или IRqA). Как только мы начинаем разбираться с семантически представленными (а не "полнотекстовыми") требованиями, сразу выясняется, что "требования" отличаются от любых других фактов (или наборов фактов -- информационных моделей) просто деонтическим статусом, указанием на долженствование. Факт X становится требованием, когда записано "должен быть X" или "может быть X". Подробно об этом можно почитать в диссертации Andries Van Renssen, который подробно про это рассказывает для факто-ориентированного описания Gellish (http://repository.tudelft.nl/file/313741/306185). Абсолютно аналогична ситуация со всеми современными САПР (замечание в сторону: Gellish планируется на сегодня как ISO 15926-11, но выход этой части стандарта будет позже, чем в 2010 году. С другой стороны, ISO 15926-7 определяет фактоориентированное описание, в противовес атрибутному на EXPRESS и OWL. Так что все сказанное относится и к ISO 15926. Более того, все сказанное верно и для других концептуальных схем, используемых в современных САПР от Dassault Systemes, Intergraph, Bentley, AVEVA и т.д.). Приведем ссылку на статью еще одного геллишевца Leo van Ruijven -- Requirement management, traditional and a second generation scenario, 2006г.. В этой статье прямо говорится про второе поколение управления требованиями. Второе поколение инженерии требований исходит из того, что требования -- это какие-то факты из модели системы, выступающие в роли требований, и в этой роли имеющие связанные с ним какие-то другие специфические для предметной области инженерии требований факты. Итак, моделирование, появившись, съедает традиционную работу с огромными списками текстовых требований, требовавших специализированного документооборота. Заинтересованные стороны в model-driven requirement engineering честно при этом говорят (Software & Systems Requirements Engineering: In Practice, by Brian Berenbach, Daniel J. Paulish, Juergen Kazmeier, Arnold Rudorfer. ): "В зависимости от изощренности используемого инструмента моделирования, полная реализация URML может позволить организации проводить большинство мероприятий инженерии требований c URML [моделями], порождая по потребности без специальной о том заботы такие артефакты, как документы или спецификации требований" ("Depending on the sophistication of the modeling tools used, a full implementation of the URML would permit an organization to do most of its RE activities with a URML, generating artifacts such as documents or requirement specifications as needed on an ad hoc basis"). Это напоминает мне политкорректный вариант постоянно слышимого мной на посиделках специалистов по САПР: "единственный способ преодолеть сопротивление всей огромной производственно-юридической структуры старого поколения, это время от времени порождать им из текущего состояния информационной модели системы "проектную документацию" в их любимых форматах, и сразу же забывать об этом, как страшном сне. Процесс генерации этих залежей бумаги поручать студентам, ибо это тупая и простая работа -- главное, не считать эту "генерацию отчетов" частью основного инженерного процесса. Это налог, штука дорогая и ненужная, но легче отдаться и спать спокойно. А ошибки искать, проектировать и изготовлять, конечно, согласно живой модели". Я утверждаю, что при смене управления требованиями существенно поменяется и сама инженерия требований, управление требованиями в которой является важной (и даже определяющей) составной частью, но явно не единственной. Главные практики дисциплины инженерии требований (дисциплина = объединенный общей предметной/domain онтологией набор практик) по проекту ISO/IEC 29148 "Инженерия требований", это определение требований заинтересованных сторон, и анализ требований. Управление требований определяется (наряду с ) как "Управление требованиями объединяет те дела, которые записывают и сопровождают становящиеся требования и возникающие из [выполнения] мероприятий инженерии требований связанные исторические сведения и сведения о контексте. Управление требованиями таже устанавливает инструкции для определения, контроля и публикации базисов требований для всех уровней [структуры] целевой системы. Результативное управление требованиями происходит в контексте организационных и технических практик, как это определено в ISO/IEC 15288 и ISO/IEC 12207 (Requirements management encompasses those tasks that record and maintain the evolving requirements and associated context and historical information from the requirements engineering activities. Requirements management also establishes procedures for defining, controlling, and publishing the baseline requirements for all levels of the system-of-interest. Effective requirements management occurs within the context of an organization's project and technical processes as defined in ISO/IEC 15288 and ISO/IEC 12207). Когда мы меняем природу "требования", меняем природу "трассировки", переходим на управление конфигурацией в контексте всего жизненного цикла, а базис требований становится всего лишь частью общей информации модели, а не отдельной "базой данных требований", мы должны ожидать, что меняются и все остальные практики, связанные с требованиями. Так, сбор требований сразу может проходить в форме моделей, без предварительного текстового описания в виде полотен бумаги. Анализ требований -- тоже связан с моделированием. Конечно, все эти тонны бумаги текстовых распечаток полученных из моделей таблиц все равно будет производиться "для бухгалтерии и архива", как отчет о проведенной работе по сбору и анализу требований, но мы же тут про суть дела, а не юридико-бухгалтерские бантики -- заинтересованных сторон ведь много, они все хочут кушать, а некоторые даже искренне считают, что делают полезное дело, собирая макулатуру. Если не умеют взять в архив бэкап базиса модели, который сам по себе обычно уже не представляет интереса без сопутствующих изменений, то пусть уж берут распечатку). Тем не менее, книжки про requirements engineering еще исходят из старого онтологического понимания: требования -- это то, что записано на специальном бланке требований, и требования отдельны от моделей. Для заполнения этого бланка даже могут придумывать специальный язык, URML. В любом случае, получается отдельно модель требований, отдельно модель проекта, и для них наверняка будут использованы разные информационные системы. Потребуется мэппинг между этими информационными системами (ибо не факт, что они будут основаны на одной онтологии). Я думаю, что этот подход "электронной работы с ранее бумажными требованиями" прошлое поколение, хотя и с модными словами типа URML, Unified Requirement Modeling Language. В классификации Dassault Systemes -- это PDM, product data management. Есть данные, мы не интересуемся, какие они по сути (у них собственная схема данных, которая открыта, если они нам специально потребуются в другой информационной системе), и мы обеспечиваем их надлежащее хранение и выдачу по особым запросам. PDM -- это не про интеграцию данных, это про interoperability, когда легко обеспечить незначительным программированием взаимодействие двух каких-то указанных информационных систем. Например, системы требований и 3D-САПР. Системы требований, и P&ID САПР. Беда в том, что этих разнообразных САПР развелось очень много, со всеми систему управления требований не насвязываешь. Интеграции данных (произвольная выборка данных из разных хранилищ, обеспечиваемая внешней библиотекой справочных данных) при таком подходе прошлого поколения нет. Современные онтологические САПРы начинают работать с требованиями по-другому: обеспечивая необходимое моделирование того, что связано с собственно "требованием-как-долженствованием" (деонтической составляющей набора всех фактов модели), а не спецификой содержания фактов, помеченных как "требования" -- то есть управление требованиями -- это управление фактами о том, "о чем просил (собственно, факт модели), кто просил, когда просил, что с этим связано, кто и как проверил, насколько оно важно, кому нужно обязательно сообщить" и т.д. Само же содержание требования -- это кусочек обычного моделирования системы, определяется "концептуальной моделью данных" aka "схемой" (данных), представляет собой кусок общей семантической сетки, а не "текстовое поле". Впрочем, деонтическая информация, приписываемая к этому содержанию требования, тоже характеризуется (кодируется с семантической разметкой) в соответствии с той же "схемой". Это все не исключает инженерии требований как содержательной дисциплины: в любом случае, нужно выявлять и анализировать то, что нужно, кому нужно, когда нужно, зачем нужно, как эта потребность удовлетворяется, как проверяется соответствие этой потребности и т.д.. Для этого все равно нужно иметь специальный инструментарий, способный отобразить эту группу описаний -- "система управления требованиями", конечно, нужна, как нужна "система управления геометрией" ("геометрия" -- это 3D описания, к ним обычно привязываются и все остальные описания, т.е. P&ID, electrical etc.). В современных САПР есть много разных domain specific languages со своими редакторами, для группы описаний, затрагивающих аспект "долженствования" тоже может быть спец.редактор, связанный с 3D-описанием примерно так же, как P&ID. Его и назовем СУТ второго поколения, которая будет работать со специфической моделью данных "деонтики", связанной с фактами всей модели системы (а то еще и моделями обеспечивающих систем -- организационной моделью, например). Весь вопрос в том, как эти ранее stand-alone редакторы потихоньку сползаются в единую коллаборативную интерактивную среду, поддерживающую множество предметно-специфичных языков: 3D-описания, описания диаграмм P&ID, описания требований в их деонтической части и т.д.. Сначала полностью автономные системы, потом в рамках "семейств САПР" (Dassault Systemes V5, Intergraph SmartPlant Enterpise и т.д.) обмен файлами при "публикации" в "репозиторий-со-схемой", использующийся для многих уже по факту полуавтономных САПР -- это поддерживают сейчас практически все поставщики САПР. Позже -- непосредственная работа с общим репозиторием, пока из "больших" систем это реализовано только у Dassault Systemes. См. обсуждение технологий этого обеспечиваемого онтологическими технологиями слияния в http://ailev.livejournal.com/748188.html. Если поглядеть не только на сбор-анализ требований и проектирование-конструирование, но и на изготовление, то нужно обратить внимание тренд к унификации языка для представления цепочки "требования-->набор моделей-->программа для изготовления на станках", который обсуждается в подходе порождающего производства (Stephen Fox, Generative Production Systems for sustainable product creation, 2009, http://www.vtt.fi/inf/pdf/workingpapers/2009/W129.pdf). Аналогичные тренды по изменению работы с требованиями наблюдаются не только для САПР "железных" и "железобетонных" систем, но и в других классах информационных систем. Например, для явное выделение проблемы инженерии требований для организаций-систем проходит в другой терминологии (business rules, см.Манифест организационных норм http://ailev.livejournal.com/693597.html), но по сути представляет собой все то же самое: начав с заявления о том, что "к организации есть требования, и системы работы с этими требованиями должны быть семантическими, а не "полнотекстовыми", авторам пришлось признать, что "требовательная" часть занимает всего 15% от объема предлагаемого ими стандарта моделирования требований (OMG SBVR, Semantic Business Vocabulary and Rules, http://ailev.livejournal.com/692588.html), а все остальное посвятить описанию способа моделирования фактов об организации, который затем предполагается использовать во всех "частных" (аналогичных "частным" САПР в машиностроении) моделях. В принципе, этот ход приводит к новому пониманию архитектуры предприятия (Enterprise Architecture), где собственно архитектуру предприятия начинают, наконец, отклеивать от архитектуры IT-систем предприятия, и вставлять в более общий ряд моделей -- требования-архитектура-"модель для изготовления"-"модель as build с историческими данными". Старые архитектурные подходы (все эти TOGAF, "по Захману" и т.д.) трещат по всем швам, хотя и представляют собой такой же нынешний мейнстрим, как "управление требованиями с использованием DOORS и IRqA". Сюда нужно обязательно добавить упоминание про разбирательство с системами систем (ибо заинтересованные стороны, от которых начинается все это обсуждение инженерии требований, чаще всего предсталяют интересы каких-то своих целевых систем, с которыми нужно стыковаться. И нужно разобраться, как об этом говорить, то есть как это моделировать, и как удерживать распределенную инженерию требований и связанное с ним распределенное управление требованиями, поддерживаемое СУТ 2го поколения, какими бы они ни оказались). И только теперь нужно вернуться к вопросу о содержательной стороне инженерии требований: как проводить выявление требований заинтересованных сторон, как отличить их требования от требований к системе (определение системы = определение границ системы), как отличить их от архитектурных требований и являются ли архитектурные требования описанием архитектуры и т.д, и т.п. Так что задачей является создание методологии/дисциплины инженерии требований, соответствующей современной моделе-ориентированной системной инженерии (http://ailev.livejournal.com/728605.html). Для моделирования инженерии требований используем ситуационную инженерию методов -- http://ailev.livejournal.com/750878.html. И положим это все кирпичиком в PraxOS.

Инженерия требований в моделе-ориентированной системной инженерии

Итак, требования -- это информационная (онтологическая) модель системы и ее предполагаемого окружения, снабженная деонтическими операторами и указанием акторов, заинтересованных в тех или иных группах описаний этой модели и расставляющих свои деонтические операторы. Информационная модель -- надо полагать как совокупность групп описаний, выполненных в общей объемлющей онтологии. Деонтические операторы -- это указания о долженствовании тех или иных фактов. О том, как информационная модель (факт-ориентированная) становится требованиями, рассказано тут: http://sourceforge.net/apps/trac/gellish/wiki/Requirements%20Models (а требованиями стандартов -- http://sourceforge.net/apps/trac/gellish/wiki/Standard%20Specification%20Models). Этот подход (иногда называемый "моделированием требований") существенно отличается от подхода "управления требованиями", который воспринимается как простая запись, хранение и последующая маршрутизация обрывков текста (см. обсуждение в тексте "Второе поколение инженерии требований", http://ailev.livejournal.com/754369.html. Этот текст написан в развитие идей того постинга). В моделировании требований ярко выражены следующие направления: а) декларативные требования (несемантические, "текстовые строки", утверждающие что-то о системе). Тексты, в которых приведены таблички: кто что сказал о чем в системе. Поддерживаются двумя типами систем: -- репозитории текстовых обрывков знания о системе (DOORS, IRqA и т.д.) -- issue tracker (каждое требование порождает "запрос на изменение" и тем самым стартует работу по его выполнению, т.е. отработку предписанного workflow). Например, Requirements Central в Dassault Systemes V6 поддерживает эту работу (т.е. тесно связан с issue tracker и Engineering Central, через который проходит основной процесс инженерной работы, как процесс непрерывного внесения изменений в проект). б) онтологические модели (факт-ориентированные), удобны тем, что фиксируют практически любое знание. Неудобны тем, что крайне ненаглядны и неисполнимы: нотаций для них нет, вычислительных движков тоже -- и редакторы, и вычислители нужно цеплять снаружи. Репозитории современных PLM-систем (SmartPlant Foundation, ProjectWise, ENOVIA V6 и т.д.) в) симуляционные и структурные/процессные модели, без поддержки деонтики и указания заинтересованных сторон. Такая модель становится "требованием" после того, как те или заинтересованные стороны (заместители ролей акторов) настаивают на придание ей деонтического статуса "должного". Важно, что в этих моделях можно выполнять "расчет", или "оценку" выполнения требований при тех или иных выборах. Наглядны, в большинстве своем имеют графические нотации, приспособленные для показа диаграмм заинтересованным сторонам. Сюда относятся: -- в какой то мере -- OMG BMM (Business Motivation Model, это ведь тоже про цели=требования!). Не говорится, чьи требования -- фиксируется уже согласованный итог обсуждения всеми заинтересованными сторонами. -- OMG SBVR -- в той части, в которой rules содержат деонтическую составляющую, т.е. являются требованиями. Но не говорится, чьи это требования, хотя в стандарте есть "словарик про организацию" (http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules). -- SysML и прочие с целью дальнейшей трансформации/генерации (порождения) -- заход "требования как исполнимая спецификация". Чьи требования не говорится, важно содержание требований, а не откуда они пришли, и что с ними происходило до момента окончательного уторговывания. Сюда же отнесем огромное количество новых разработок аналогичного типа (совокупность нескольких типов диаграмм/языков, в том числе предназначенных для формулирования требований -- например, http://redseeds.iem.pw.edu.pl из относительно свежих). -- Modelica, и UML профиль для нее -- ModelicaML. Чьи требования, в этих симуляторах не говорится, зато хорошо выполнимая мультифизическая модель ( там и сям). Modelica интересна своей акаузальностью (acausal modeling), но в эту же нишу норовят (на мой взгляд, необоснованно) залезть куча других казуальных пакетов типа Matlab и Simulink (каузальность понижает возможность переиспользования моделей). -- мультимодельные среды (типа питерской http://www.xjtek.com/anylogic/approaches/). И сюда же примыкает системная динамика. Во всех этих моделях про собственно "требования" (т.е. -- чьи требования!) не говорится, зато хорошо выполнимая модель "факторов и обратных связей". В принципе, это все покрывается Modelica (в ней есть спец.библиотека для системной динамики и многих других подходов), но в отдельную строчку выделено по причине большого количества специальных инструментов типа iThink, PowerSim и уже упомянутого AnyLogic (http://www.systemswiki.org/index.php?title=Simulation_Software). -- URN, i* и т.д. из агентского подхода ((http://ailev.livejournal.com/800769.html). Говорится, чьи требования, но сама модель не "выполнима" -- зато оцениваются KPI. Тут нужно быть весьма осторожным, чтобы не спутать с очень близкими "типа SysML" (т.е. "требования как исполнимая спецификация"), а "оценивание" KPI не путать с "выполняемой моделью=спецификацией"). Идеал на сегодня недостижим. Будем считать, что софт PraxOS (если мы будем говорить об ориентации на инженерию требований, а не ситуационную инженерию методов), который будет реализовывать идеал, должен интегрировать: -- репозитарий с информационной моделью, достаточно богатой, чтобы включать не только модель продукта (например, PBS), но и сведения по KPI этого продукта, участвующим в проекте заинтересованным сторонам, и деонтические операторы. -- специализированные графические и текстовые языки представления требований именно как требований (т.е. специфических операций для работы с требованиями, а не операций моделирования, архитектурной работы, проектирования -- согласование требований, утверждение требований заинтересованными сторонами, трассировка требований и т.д.). -- движок по оценке "приемлемости требований" (assurance case, requirement case) -- движок (мультифизического, имитационного) моделирования -- движок workflow, совмещенный с управлением конфигурации модели (workflow прежде всего на изменение baseline модели системы/требований по мере принятия проектных решений) -- движок ситуационной инженерии методов: как минимум, справочник по методам работы со всем вышеперечисленным, порождение отдельных "проектов-project" и связанных с ними информационных моделей на основании "типовых методов, типовых моделей". Поэтому нужно думать о том, как подобраться к этому идеалу путем выбора и последующей интеграции существующих программных инструментов, реализующих поддержку тех или иных аспектов инженерии требований (и, соответственно, архитектурного проектирования -- ибо все эти модели в части, игнорирующей "заинтересованные стороны", прямиком относятся к архитектурному проектированию. Да и архитектурным проектированием дело не ограничивается -- нужно дальше пройтись по всем практикам системной инженерии, все они будут затронуты, см. обсуждение http://community.livejournal.com/incose_ru/12138.html). Это и будет инженерия требований в моделе-ориентированной системной инженерии. Не слишком похоже на "поставим требования под контроль конфигурации: купим DOORS", не так ли? Если кому-то очень хочется именно DOORS и привычного вида почти бумажных документов на экране, то всегда из современных средств работы с требованиями можно выгрузить в "систему управления требованиями" архаичных поколений много-много информации, нет проблем. Фишка тут в том, что нужно думать, откуда берется загружаемая в эти традиционные "системы управления требованиями" информация, и что с ней потом можно делать, кроме как прикладывать в виде официальных приложений к контрактам. Но это уже по юридико-административной, а не по инженерной линии. На это всегда выдадут денег, не стоит на этом специально заморачиваться.