Monthly Archives: July 2010

Вступил в INCOSE

Вступил в INCOSE (International Council on Systems Engineering).

Немного попарился с оплатой. Платить надо картой. У меня MasterCard Standard, с него оплата не проходит. ailev говорит, что есть два варианта: либо завести специальную карту для интернет-платежей, например MasterCard Virtual), либо связаться с центральным INCOSE и попросить провести платёж в ручном режиме.

С INCOSE Central я связаться не смог: на два моих e-mail’а ответа так и не пришло. Поэтому сделал MasterCard Virtual и оплатил ей. Видимо это самый простой вариант.

Стоимость года членства в INCOSE – 105 долларов. После вступления можно посещать заседания русского отделения INCOSE (http://incose.ru/), в т.ч. и удалённо. Также центральный INCOSE заверил меня, что «membership in INCOSE offers a tremendous number of benefits» и дал доступ к ресурсу INCOSE CONNECT, на котором предоставляются какие-то ништяки, пока не смотрел, какие именно.

 

Павел Сурменок

http://surmenok.ru/

User Requirements Notation

Краткий обзор языков и нотаций для моделеориентированной инженерии требований можно посмотреть у Левенчука.

Я посмотрел, по ссылочкам походил, почитал, и решил для начала попробовать URN. Потому что там есть акторы, есть цели.  

Как позже выяснил, посмотрев 22-е заседание русского чаптера INCOSE (24 февраля 2010), Левенчук тоже моделирует требования к своему чем-то-там-ядерному в URN. Значит велика вероятность, что я копаю в правильную сторону :)

 

Итак, что же такое URN… Это User Requirements Notation. Нотация пользовательских требований. Включает в себя:

·         GRLGoal-oriented Requirement Language – целеориентированный язык требований – для нефункциональных требований.

·         UCMUse Case Map scenario notation – нотация карт сценариев использования – для функциональных требований.

URN была стандартизирована ITU (International Telecommunication Union) как рекомендация Z.151 в ноябре 2008.

Подробней можно почитать у Левенчука http://ailev.livejournal.com/800769.html, а также тут http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/WebHome, далее по ссылкам.

GRL основан на подмножестве языка i*.

i* framework – conceptual modeling language for capturing the social characteristics of complex systems in terms of actors, their intentions, and their relationships. Actors are viewed as being intentional, i.e., they have goals, beliefs, abilities, and commitments, which must be discovered and properly documented.

О соотношении GRL с i* и о том, как дополнить GRL полезными штуками из i* (роли, агенты, позиции): http://jucmnav.softwareengineering.ca/ucm/pub/UCM/VirLibRIGiM09/RIGIM09-AmyotEtAl.pdf

Есть плагин для Eclipse, который позволяет рисовать модельки в этих нотациях. http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/WebHome

 

В связке GRL и UCM мне почему-то более интересен GRL. В нём определены акторы, цели, решения (Tasks, не знаю, как лучше перевести: решения/задачи/действия), обоснования. Также можно задавать стратегии.

Туториалы по GRL:

http://www.cs.toronto.edu/km/GRL/tutorial.html

http://jucmnav.softwareengineering.ca/ucm/pub/UCM/VirLibComNet03/ComNet03.pdf

 

Павел Сурменок

http://surmenok.ru/

 

Определение модели

При обсуждении каких-то сложных вещей сразу возникают проблемы с терминологией – стороны по-разному толкуют термины.

Вот и при обсуждении с коллегами моделеориентированной инженерии требований сразу возникло расхождение в том, что понимать моделью.

Наиболее распространено такое общее определение:

In the most general sense, a model is anything used in any way to represent anything else. Some models are physical objects, for instance, a toy model which may be assembled, and may even be made to work like the object it represents. However a conceptual model, may only be drawn on paper, described in words, or imagined in the mind. They are used to help us know and understand the subject matter they represent.

Т.е. обычно под моделью понимают нечто, что каким-то образом используется, чтобы представить что-то другое. Даже игрушечный самолётик можно считать моделью самолёта. В каком-то смысле (с чьей-то точки зрения) и кусок железа можно считать моделью самолёта.

В системной инженерии же под моделью понимается нечто иное. Вот, например, что пишут на подразделе MBSE сайта немецкого чаптера INCOSE:

A model is an approximation, representation, or idealization of selected aspects of the structure, behavior, operation, or other characteristics of a real-world process, concept, or system (IEEE 610.12-1990), i.e. an abstraction.

A model usually offers different views in order to serve different purposes. A view is a representation of a system from the perspective of related concerns or issues (IEEE 1471-2000).

Здесь уже говорится о том, что модель – это идеализация, абстракция чего-то из  реального мира.

Дальше смотрим пояснение сущности модели у Левенчука:

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

Далее эту идею можно развивать и преломлять (например, считать, что оперативная память — это не физическое представление, а что-то иное, и в зачёт идут только разные отображения — на экран, принтер, графопостроитель и т.д.). Но это уже детали.

Вот как-то так. Далее, понимая, что есть модель в MBSE, можно уже рассуждать о том, как модели соотносятся с документами, как понять, где уже моделеориентированная системная инженерия, а где еще олдскул и прочее, прочее.

 

Павел Сурменок

http://surmenok.ru/

 

Моделеориентированная инженерия требований

Инженерия требования, как и в целом системная инженерия, может быть документоориентированная (олдскул), может быть моделеориентированная (ньюскул).

Прошлое поколение – это когда вся информация о системе лежит в документах. Требования – тоже в каких-то документах, не важно, бумажных или электронных. Скажем, бумажка, в которой зафиксирован список требований.  А скорее не одна бумажка, а несколько разных, плюс к ним еще кучка документов с изменениями требований. И всё это в кучу, в целостную картинку сводится только в голове системного инженера.

Моделеориентированная системная инженерия– это когда есть модель, она в компьютере где-то лежит. В любой момент можно сделать представление этой модели на экране компьютера и  посмотреть состояние на текущий момент. Здесь же и конфликты какие-то видно сразу. Думать проще, когда модель есть. И коммуницировать проще – не надо махать руками, чтобы показать что-то, можно просто показать представление модели. Ну а если нужны документы  - их можно генерировать на основе модели. При этом модель будет первична, а документ лишь отображает какие-то части модели.

В моделеориентированной инженерии требований требование – это модель (или кусок модели или её элемент), с указанием на то, что система должна следовать этой модели. Требование состоит из 3 частей:

1.    Модель

2.    Деонтический оператор. Он предписывает: “должен”, “не должен”, “must”, “recommended”, “insist” и т.п.

3.    Стэйкхолдер, заинтересованная сторона. Это тот, чьё требование. При этом должно проверяться, имеет ли он право на то, чтобы говорить, что должно быть так.

 

Ох, запутанно как-то написал… Ну ничего, как поглубже вникну в эту связку документы vs модели – напишу понятней.

 

Павел Сурменок

http://surmenok.ru/

 

Высокотехнологический распил

Сейчас в России море бабла выделяют на развитие высоких технологий. Я даже верю, что где-то там на уровне принятия решений о выделении бабла у людей кроме цели личного обогащения есть еще и цель развития высоких технологий. Может даже эта цель для них важнее.

Я вижу, как в ВУЗах делают финансируемые государством лаборатории, закупают для них оборудования на десятки миллионов рублей, нанимают студентов и аспирантов. Темы разные, в т.ч. электроника, космос, авиация.

Еще много появилось каких-то программ, по которым выдают премии и гранты на разработку каких-то интересных проектов.

Всё вроде бы замечательно. Но механизм работает так, что толку от него получается не много. Бабло выделяют не на результат, а на процесс. У баблополучателей нет обратной связи, которую обычно даёт рынок. В итоге выходит, что баблополучатель вовсе забивает на интересы конечных пользователей его продукта, и концентрируется на процессе разработке и выбивании дополнительного финансирования.

Проект придумывается, финансирование выбивается. Идёт кодирование софта, паяние электроники. При этом проходит год, проходит второй год, уже и электроника по большей части работает, софт что-то делает. Но при этом до сих пор никто даже и не подумал – а кто же будут покупатели сего чудного продукта, кто за это будет платить, и что этим клиентам на самом деле нужно?

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

 

Павел Сурменок

http://surmenok.ru/

 

Системная инженерия онлайн

Всё, что пока есть в рунете по теме системной инженерии – это блоги Левенчука и еще нескольких энтузиастов. Все обсуждения по теме, похоже, проходят в этих блогах, в личной переписке и в оффлайне.

Не хватает какого-то общего онлайн-ресурса. Не столько для хранения там какой-то справочной информации, сколько для многосторонней коммуникации. Что-то типа форума.

Забавно, что даже у российских стриптизёрш есть  форум, где они обсуждают профессиональные моменты типа выбора музыки для танцев и методик правильного снятия деталей одежды :) А у системных инженеров нет.

Надо будет этим заняться.

 

Павел Сурменок

http://surmenok.ru/

Инженерия требований

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

Инженерия требований – это социотехническая дисциплина.

Инженер по требованиям – системный инженер, специализирующийся в инженерии требований.

Инженер по требованиям извлекает из людей или откуда-то еще требования заинтересованных сторон. Инженер по требованиям ответственен за то, чтобы:

1.    Обнаружить все заинтересованные стороны проекта (как внешние, так и внутренние – разработчики системы)

2.    Учесть требования заинтересованных сторон

3.    Т.к. требования зачастую противоречивы, разрешить конфликты путём нахождения архитектурных решений, снимающих эти противоречия, либо проведения переговоров между людьми, представляющими заинтересованные стороны

4.    Создать и поддерживать в актуальном состоянии специальное описание проекта, отражающее заинтересованные стороны и их интересы (модель требований). Также в этой модели по ходу принятия архитектурных решений отражаются эти решения и показатели достижения этими решениями целей заинтересованных сторон.

 

Павел Сурменок

http://surmenok.ru/