Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

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

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

Информационная модель -- надо полагать как совокупность групп описаний, выполненных в общей объемлющей онтологии. Деонтические операторы -- это указания о долженствовании тех или иных фактов. О том, как информационная модель (факт-ориентированная) становится требованиями, рассказано тут: 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 и привычного вида почти бумажных документов на экране, то всегда из современных средств работы с требованиями можно выгрузить в "систему управления требованиями" архаичных поколений много-много информации, нет проблем. Фишка тут в том, что нужно думать, откуда берется загружаемая в эти традиционные "системы управления требованиями" информация, и что с ней потом можно делать, кроме как прикладывать в виде официальных приложений к контрактам. Но это уже по юридико-административной, а не по инженерной линии. На это всегда выдадут денег, не стоит на этом специально заморачиваться.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment