На международной конференции по проблемам системной инженерии 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/

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

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

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

1.    Модель

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

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

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

–

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

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, утро