Обсуждение

Я подписан на множество рассылок по Requirements Engineering, включая научные. Это просто ужас. Люди настолько оторваны от реальности, что просто диву даёшься.

Реальности бывают очень разные, смею заверить. И software requirements engineering (слово software они, конечно, не используют в названии) существено в некоторых местах отличается от таковой для systems engineering -- а большинство литературы сейчас выходит именно по software engineering. Там нет требований по мультифизике, например. Там редко нужно делать инженерные обоснования (которые потом подолгу проверяют специально обученные люди из надзорных органов). В системной инженерии тоже, конечно, бывает разное всякое, но я в докладе делаю особый упор на размежевание с теми вроде как "научными пионерскими разработками", которые "не взлетят" (например, использование логических языков типа OCL для записи требований никогда не выйдет в тренд -- хотя это и мечта для многих и многих университетских учёных).

А кто говорит про "software"? Оно, конечно, сейчас во все системы входит, но я видел и тех деятелей, которые требования для коллайдера писали. Хотя, конечно, среди чисто софтверных (особенно, вебовских людей) существует вера в Большую Кнопку.

О, коллайдер -- это совершенно особая история! А если взять ITER, то там история ещё особистей ))) Более того, для каждой подсистемы и подсистемы подсистемы в таких проектах обычно приняты разные практики инженерии требований, включая разные практики управления требованиями, разные наборы стандартов, опора на стандарты разных отраслей и инженерных специальностей и т.д. И я тут не об отдельных примерах (хотя у меня в докладе и отдельные примеры есть, как же без этого). И не о том, что средний уровень предприятий даже на Западе оказывается ниже плинтуса (а у Российских предприятий этого уровня на мировом рынке часто и вообще нет, даже если искать ниже плинтуса). Я об общих трендах, и именно в системной инженерии.

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

У меня другой взгляд на эти проблемы. Действительно, проблемы обычно в непротиворечивости сотен тысяч требований, но человек с орлиным взглядом обычно bottleneсk в больших системах: его всегда меньше, чем проблем для него. Плюс непротиворечивость неплохо бы проверять при каждом изменении системы и каждом изменении требований -- а человек с орлиным взором рутинно не способен одно и то же проверять по двадцать раз на дню, глаз замыливается. И требований много разных видов, в разых формах. Вот тут не помогают ни старые методы, ни ограниченное число (хотя кажется, что их много на всех уровнях) сверхумных хардверных инженеров, ни многие из новых методов. Тут и нужно понимать, где действенный фронтир. И на это тоже есть люди со своей чуйкой -- и эта чуйка у них побольше вашей и моей вместе взятых. А потом мы эти решения видим через много-много лет зафиксированными в стандартах, они становятся рутиной и чем-то обыденным. Но всегда будут лавки, в которых и обыденные стандарты это супер-пупер-дупер прогресс. Ну, и часто в стандартах фиксируется не реально помогающие методы, а их могучие упрощения (или наоборот, могучие навороты на реально работающие идеи). Недаром в каждом стандарте системной инженерии есть приписка, что без адаптации стандарта применять его нельзя -- то есть использование неизменённого для нужд конкретной организации стандарта есть наказуемый грех, non-complience.

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

У вас тут опять сверхобобщение и сверхупрощение. И я тут вообще не про "процессы". И не про консультантов. У вас в голове некоторая стандартная модель мира вокруг слова "требования", и вы её прикладываете более менее единообразно ко всем ситуациям и всем разговорам про инженерию требований. Но у меня про тренды в тех местах, где у вас модель мира не имеет соответствующих элементов. Вы хотя бы доклад посмотрели?!

У вас в голове некоторая стандартная модель мира вокруг слова "требования Такие заявления надо начинать со слов "мне кажется". Тем более, кажется не правильно. Доклад я его просмотрел. У меня все слайды перекошены, потому что шрифры другие и не виндусятная программа стоит. Да и читать английские слова русскими буквами не очень классно. Мы будем разбирать доклад по слайдам и мне по каждому пункту говорить, почему и как это в реальных условиях не будет работать? Причём, начиная сразу со второго слайда. А Donald Firesmith - это, вообще, какой-то собиратель. Как хомяк несёт в гнездо всё попавшееся. Совершенно не фильтрует.

Хочу в целом по посту прокомментировать. Я пробую отнестись к практике на предприятии после какой-то работы по ее внедрению как к решению (в смысле solution по Essence). Причем этот Solution собирается из кусков некоторой эталонной практики (дисциплины, описанной в стандартах и книжках; инструментов с рынка), изрядно подкрученной под потребности (needs, другие opportunities). Причем stakeholder needs относится к system definition как один к многим (то есть, для одной need может быть бесконечное число system definition). И вот если так смотреть, то у заинтересованных сторон в потребностях никогда не появится инженерия требований: этого не бывает в области проблем (я думаю, можно смотреть на customer area of concern как на область проблем). Зато в области решений под какую-то проблему может быть воткнута изрядно подкрученная инженерия требований. При этом понятно, что, возможно, кто-то наблюдал у заинтересованных сторон потребность, которую можно было бы закрыть подкрученной инженерией требований (пусть и не той, которая фронтирная). Я-то инженерию требований воспринимал в основном вместе с общением с заинтересованными сторонами (то есть - пойти зафиксировать потребности, переварить их в определение системы). Потребности для этого как раз я и не замечал. А всё, что касается аккуратного хранения уже зафиксированных требований (например, авиационных правил для авиации или каких-то других сводов сертификационных требований - которые существуют вне конкретного объекта), мне непонятно как закрыть инженерией требований с ходу. Я наблюдал потребность в хранении этих сводов не в виде документов, а в виде требований (то есть, решением было бы распарсить документ на требования, каждое требование было бы в какой-то базе уникальным и это требование крепилось бы к чему-то в настоящей системе). Но непонятно, что здесь от инженерии требований. То есть, это не та потребность, которую инженерией требований можно закрыть.

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

Интересный тезис о неполноте формальных моделей по сравнению с естественным языком, прям по Гёделю. Какая в таком случае видится роль у моделей? Дополнять, переводить текстовые описания или конкурировать с ними, если уж заменить не получится?

Модели позволяют: невидимое делать видимым, "вгрызаться" в содержание (ибо в них требуется подводить под типы метамодели, что требует дополнительных размышлений и привносит прошлое знание), проверять выражение, делать имитацию и т.д. -- то есть модели и тексты вполне себе будут сосуществовать. Конкурировать они будут лишь в том смысле, что будет сильно неохота иметь и представление в виде модели, и в виде текста. Хотя текстовые отчёты о движении курса, спортивных достижениях и т.д. из табличной сухой формы компьютерные программы в газетах делают прямо вот сейчас, так что тексты вполне конкурентоспособны оказываются -- уж не знаю почему (я бы таблички рассматривал, но есть и любители "читать новости"). Всё глубоко оказывается субъективно, правды одной на всех и для всех нет.

офф топ. вы прекрасно делаете презентации! можно про это в вашем блоге: http://www.slideshare.net/ailev?utm_campaign=profiletracking&utm_medium=sssite&utm_source=ssslideview

Про что "про это"?!