February 20th, 2010

2021 год

WiFi в SIM-карте

Оно уже бывает: WiFi в крошечной симке -- http://www.engadget.com/2010/02/18/sagem-orga-shows-off-pricey-simfi-prototype-at-mwc/

Вот он, "интернет вещей". Умная пыль.

А оригинальная цель -- превратить буквально каждый телефон в точку доступа к мобильному интернету. Лежит у вас в кармане телефон, а ноутбук цепляется к интернету "от телефонного провайдера" по WiFi, совсем как дома. Всем выгодно.
2021 год

Редактор нотации пользовательских требований (user requirements notation)- jUCMNav

Нотация пользовательских требований (User Requirements Notation, URN) состоит из графического целеориентированного языка требований (Goal-oriented Requirements Language, GRL) для нефункциональных требований и карт сценариев использования (Use Case Maps) для функциональных требований. Подробности про языки -- http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/WebHome). Свободный Eclipse-плагин редактора для всего этого языкового требовательного разнообразия: http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome

Корни тут из агентских систем (см., например, Tropos -- известную методологию разработки агентского софта http://www.troposproject.org/ и там про requirements engineering -- http://www.troposproject.org/node/120).

URN была стандартизирована ITU (International Telecommunication Union) как рекомендация Z.151 в ноябре 2008 (из той же языковой семьи, что SDL, MSC, TTCN-3 и ASN.1), т.е. целевая область применения -- требования к телекоммуникационным системам и описание организационных (business) процессов.

GRL был стандартизирован как подмножество i* (http://istar.rwth-aachen.de/tiki-index.php) -- агентского языка моделирования социо-технических сложных систем в терминах акторов, их намерений и взаимоотношений. Этот заход с акторами крайне важен: моделируются заинтересованные стороны, включая их взаимоотношения и намерения, что часто опускается в "традиционном" анализе требований.

В http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/VirLibRIGiM09 (статья и презентация в аттачах) сказано про связь URN и i*. В частности, GRL имеет только акторов, а i* также определяет роли, агентов и позиции. Зато GRL имеет "стратегии". Суть статьи: GRL может иметь профили, созданные при использовании языка ограничений OCL, метаданных языка и связей (links) URN).

Это довольно широко распространенная школа работы с требованиями, в публикациях там больше 250 работ на эту тему: http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/UCMVirtualLibraryAllPubsPerYear

Странная аллюзия у меня -- это Flying Logic в ее именно логической части. Уж больно похоже с propagation влияния и "аргументационной поддержкой"! Но ведь все эти деревья Голдратта как раз и предназначены для выработки требований (и доказательству того, что требования являются правильными)!

Безусловно, это моделецентрическая работа с требованиями, хотя это совсем-совсем другие "модели", нежели выразимые в Modelica (да и в ModelicaML). Требования -- это просто модели, с деонтическим оператором к ним, но кроме этого в случае именно требований важно, чьи именно это требования. В "просто модели" этого нет, нужно менять определение: добавлять заинтересованные стороны, акторов.

Я рассматриваю эти все концептуализации как "моделирование" в противоположность "онтологизированию". В любом случае, это все потом можно (и даже нужно) будет осмыслить и затащить под ISO 15926. Помним про "программирование, моделирование, онтологизирование" (в http://ailev.livejournal.com/784347.html -- и там ссылка на любимого Конрада Бока http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119).


В любом случае, это не убогие таблички из DOORS или даже IRqA. Это работа с семантикой, что радует.
2021 год

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

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

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

Требования и законы (compliance).

Требования и законы -- близкие родственники. Но не более. Раскапывать можно начинать отсюда:

Статья: http://www.dit.unitn.it/~asiena/files/%20TR-0209-SMSP.pdf -- The Nomos framework: Modelling Requirements Compliant with Laws

Презентация: http://www.troposproject.org/files/SESeminar-090514.ppt -- Towards a Framework for Law-Compliant Software Requirements

Страничка Alberto Siena с кучей других ссылок: https://sites.google.com/site/albertosiena/

Смысл тут в том, что для моделирования законов применяется "язык прав" (которые не являются хотелками заинтересованных сторон. Это то, что заинтересованным сторонам вменяется, это не их цели! Более того, требования закона могут противоречить целям, а сам "закон" не является актором, чтобы быть учтенным в обычном порядке), "онтология закона" (предлагается вариант Hohfeld’s taxonomy of legal concepts, 1913). Для моделирования требований применяются "хотелки" из агентского подхода (онтологии) к требованиям i* (http://ailev.livejournal.com/800769.html). И далее эти две онтологии сливаются в едином порыве.

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

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

Дисклеймер: Это я только про техническое регулирование! Про право как таковое я пока не заикаюсь. Еще не время.