На международной конференции по проблемам системной инженерии RuSEC 2010 в Москве присутствовал Ian Alexander, уже не один десяток лет занимающийся проблемами инженерии требований. Жаль, что я не смог поприсутствовать на конференции, потому что судя по слайдам, доклад был замечательный.

На сайте Яна можно найти его публикации.

А еще он автор трёх книг о требованиях: Writing Better Requirements (2002),  Scenarios, Stories, Use Cases (2004),  Discovering Requirements (2009). Их можно без проблем найти в интернете. Я сейчас читаю последнюю, надо сказать, очень полезно и практично.

–

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

http://surmenok.ru/

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

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

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

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

·         UCM – Use 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/

PDF’ов ). Еще конечно очень полезны видеозаписи заседаний русского INCOSE и лекций Левенчука (первая лекция тут: http://ailev.livejournal.com/757223.html , там же ссылки на вторую-шестую).

Мой предпринимательский опыт однако давно заставил меня понять, что теории мало, нужна и практика

Дальше начинаются проблемы. Вроде бы в целом всё ясно. Есть стандарты, в них практик описаны. Есть определенные виды жизненного цикла. А что конкретно делать-то? Непонятно.

Еще проблема с объектом, на котором практики системной инженерии применять. Хорошо конечно когда затевается большой проект типа проектирования новой АЭС, и можно влезть туда порулить процессом. Однако найти более-менее серьезный проект, где захотят внедрять системную инженерию, и тем более поставят меня оной порулить – это крайне сложно

Пробовал в некоторые небольшие проекты внедриться, объяснял отцам-командирам, что такое системная инженерия, что они с этого могут поиметь, как всё это выглядит. Понимания нет. В одном месте (софтовый проект) сказали «Да, всё круто, так и будем делать. Я передал то, что ты говорил, нашему системному аналитику, он напишет ТЗ на систему». Ага, супер Из моих рассказов об инженерии требований было понято, что надо написать ТЗ на систему, причём даже без сбора требований стэйкхолдеров

Еще в одном проекте (проектирование беспилотного ЛА + софта бортового и наземного) сказали, что всё это круто, но лучшее – враг хорошего, и они на коленке продолжат делать. При этом там даже нет и не планируется требований к софту и описания архитектуры софта – ни в виде моделей ни в виде документов.

В общем, есть большая проблема непонимания менеджментом необходимости системной инженерии.

Из известных мне предприятий радует разве что ОАО «Информационные спутниковые системы» (лидер российского спутникостроения, спутники связи и спутники ГЛОНАСС делает). Там 2 года назад внедрили Dassault (CATIA, ENOVIA), некоторые этапы жизненного цикла проходятся уже на этой платформе. Переходят на полностью электронный документооборот, включая обмен моделями с поставщиками. Осенью будем пытаться там делать автоматизацию общего проектирования. Тут и инженерия требований во всей красе (стэйкхолдеров с требованиями к системе автоматизации проектирования много насчитывается), и  даже порождающее проектирование (будем порождать общий дизайн космического аппарата на основе требований к оному и базе знаний с знаниями, добытыми из проектантов, и набором предыдущих дизайнов).

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

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

–

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

http://surmenok.ru/