Tag Archives: MBRE

Ian Alexander

Искал, что же хорошего почитать об инженерии требований. И нашел.

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

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

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

–

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

http://surmenok.ru/

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

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

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

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

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

1. Модель

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

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

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

–

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

http://surmenok.ru/

Системная инженерия на практике

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

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

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

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

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

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

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

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

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

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

–

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

http://surmenok.ru/