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

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

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

–

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

http://surmenok.ru/

Немного попарился с оплатой. Платить надо картой. У меня 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/

Я посмотрел, по ссылочкам походил, почитал, и решил для начала попробовать 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/

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

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

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

–

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

http://surmenok.ru/

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

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

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

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

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

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

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

–

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

http://surmenok.ru/

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

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

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

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

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

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

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

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

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

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

–

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

http://surmenok.ru/

- Сбить еще одного лыжника и, возможно, завершить сноубордический сезон 2009/2010. Хотя весна еще не началась и, возможно, еще покатаюсь. Так я в этом сезоне толком по чёрным трассам и не покатался почему-то. Наверное потому что сложно было привыкнуть к новой карвинговой доске.

- Купить новый компьютер. Раньше у меня были только ноутбуки, которые обновлялись примерно раз в 3 года. Предыдущий ноут, купленный в 2007-м, уже не справляется с постоянно возрастающими задачами, и поэтому решено заменить.

На это раз взял десктоп. Всё равно с тех пор, как я купил 10-дюймовый одношпиндельный (какое старое, забытое слово, да?) маленький ноут Lenovo IdeaPad, большой 17-дюймовый ноут уже никуда не носил, так на столе и пылился.

На новом десктопе Core2Duo и 4 Gb RAM. Как обычно, выбирал, минимизируя цену при некоторых ограничениях характеристик. Так, памяти мне нужно было побольше и процессор помощнее, а вот видеокарта – абсолютно безразлична, т.к. графическими делами не занимаюсь.

На новый комп поставил Windows 7. Ничего так, приятно. Хотя кроме забавных новшеств в GUI ничего особо интересного не заметил. Ну только обновлённый калькулятор порадовал И еще монитор ресурсов – удобная штуковина.

- Начать переход на нормальный режим дня. Раньше редко поулчалось лечь спать раньше двух ночи. Ну и просыпался, соответственно, часов в 12-14 Теперь встаю в 7. Сейчас только 9 утра, а я уже сижу что-то в бложик пишу. Очень кстати забавные ощущения – когда успеваешь утром переделать кучу дел, смотришь на часы – а там всего часов эдак 9-10.

- Посмотреть сериал The Big Bang Theory. Очень рекомендую Забавный такой гиковский юмор. Английский я на нём изучаю� Чем больше слушаю, что они там по-англицки бормочут, тем лучше могу речь разобрать. Видимо мозг при просмотре фоном тренируется распознаванию иностранной речи, различает повторяющиеся паттерны, сопоставляет звук и субтитры.

- Начать изучение таких вещей как моделирование динамических систем, онтология, Semantic Web, моделеориентированная инженерия требований. А также заинтересовался всякими экзотическими парадигмами программирования, немэйнстримовыми языками вроде Smalltalk.

Читаю книги: “Handbook of Dynamic System Modeling”, “Handbook of Ontologies”, “Squeak by Example” и еще ряд публикаций об онтологиях, моделировании, Semantic Web, проектах BETA, OPEN Metis и др.

От обилия англоязычного чтения мне теперь уже сны на английском снятся

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

- Также практики системной инженерии пытаюсь применить при разработке проекта автоматизации проектирования космических аппаратов на ОАО «Информационные спутниковые системы» (бывший НПО ПМ, ведущий российский производитель спутников, город Железногорск – бывший Красноярск-26).

Вот такие примерно мои дела. Постараюсь в ближайшее время почаще писать в блоге.

–

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

Красноярск, 14 апреля 2010, утро

Вы хотите знать, КАК построить атомную станцию, уложившись в сроки и бюджет?

Вы хотите знать, КАК строятся такие огромные сооружения, как небоскрёбы, подводные лодки и авианосцы?

Вы хотите знать, КАК при строительстве завода спланировать не только расположение зданий, но и то, как будет подвозиться и заноситься оборудование, как будут проводиться плановые ремонты через 10, 20, 50 лет, как будут проводиться модернизации?

Вы хотите знать, почему советским инженерам приходилось по 7 раз ломать стены завода, чтобы занести внутрь оборудование?

Вы хотите знать, почему при строительстве АтомМаша пришлось после постройки зданий укреплять грунты и перестраивать подъездные пути, тем самым в несколько раз превысив бюджет и сроки проекта?

Смотрите лекцию Анатолия Левенчука “Введение в системную инженерию, часть 1″:

–

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

Красноярск, 7 ноября 2010, вечер