Требовательный инжиниринг
Начал отвечать на коммент (http://ailev.livejournal.com/667768.html?thread=5692024#t5692024) и решил вынести отдельным постом. В комменте vit_r приводит фрагмент картинки из реальной requirement diagram, выполненной по современной моде системной инженерии, в SysML:
vit_r пишет: "это элементарный случай дюжина на дюжину. У меня во многих случаях идёт сто на сто. Так что графическое решение многих задач красиво только на элементарных (рекламных) примерах".
ППКС! Полностью согласен с приведенным примером. Хотя из этого не следует, что язык можно сразу выкинуть: можно сохранить его онтологию и семантику, но поменять нотацию. Так, схемами IDEF0 (даже в более расширенном их варианте, так называемом eIDEF0) в графическом виде пользоваться нельзя, но их великолепно подшивать к отчетам по договору: очень умно выглядят и занимают много-много листов бумаги. А вот пользоваться ими удобно только в виде их табличного представления. Хорошенькая такая табличка, с парой дюжиной полей и мнооооожеством строчек, готовится в Exel (например, программой ОргМастер), свободно читается топ-менеджерами без айтишного образования...
Я не приверженец графических языков. Я еще застал те времена, когда было модно обсуждать "блок-схемы программ" как обязательный документ перед написанием текста программы. И помню, чем закончилась эта битва обязательных блок-схем с "просто текстом" программ. Графические картинки алгоритмов и структур данных хорошо использовать в коротких презентациях: показываешь слайд, и много и долго затем что-то по нему рассказываешь. А вот если нужно этот рассказ иметь в письменном виде, то лучше это делать не картинками, а текстом -- и понятней, и быстрей, и компактней, удобней набирать/читать, легче организовать поиск.
UML я не доверяю в том числе и по этой причине: графическое его представление довлеет над текстовым, текстовые нотации для UML практически не используются (чем еще и гордятся). SysML в этом плане ничем не лучше. Десять квадратиков на двадцать линий -- и кончилось как понимание, так и площадь экрана.
Я думаю, наш самый большой вклад в INCOSE может быть в том, что мы будем усомневать SysML в качестве единственного языка системной инженерии. Мне кажется, что будущее тут не за "один язык для всех и обо всем", а за набором DSL для разных групп описаний. Ход на стыковку Modelica с SysML мне не представляется самым удачным (хотя Modelica и имеет текстовое и графическое представление одновременно. Кто знает, вдруг редакторы для Modelica станут средством массового применения SysML для больших систем?).
Если вернуться от общего обсуждения недостатков графических языков для описания больших систем к представлению требований, то
а) с онтологией требований все пока очень плохо:
-- понятие "трассировка" совершенно неоперационально (протрассируйте-ка требования ilities! Как раз про это assurance case, и нужно как-то требования привязывать к claims и далее к тестированию и обоснованиям, что в системах управления требованиями не слишком-то поддерживается, равно как в системах оценки: нет того места, где claims сопоставлялись бы с требованиями, или генерировались из них);
-- верификацию от валидации отличить зачастую затруднительно. Тут вся эта дискуссия про intents, различие "духа" требований и их "буквы", что очень трудно отразить в языке. Различение превращается в игру слов и выпячивание должностей участвующих;
-- иерархичность требований непонятно по каким типам отношений проходит -- понятно только что по разным (в мереологии обсуждается, что иерархии требований-подтребований могут строиться по разным основаниям);
-- разница между функциональными/черного ящика и конструкторскими/белого ящика требованиями размыта;
-- привязка требований к стейкхолдерам, и далее различные view и viewpoints для их выражения отнюдь не способствует единообразному их представлению. Требование "чтобы 2*2 было =4" лучше представлять в формате выражения, а вот требование "на самом видном месте должен быть налеплен логотип" даже не сразу понятно, в каком формате представлять, кроме текстового (хотя я верю, что "самое видное место" вполне можно формализовать и затем проверять выполнение этого требования приборно -- распознаванием сцен).
Этот список можно продолжать и продолжать. Сведение всего этого списка к "требование -- это текстовая строка, не более" сводит системы управления требованиями к простому блокноту, т.е. явно не дает особого выигрыша по сравнению с любой неспециализированной базой данных "текстовых строк". А как только мы пытаемся выскочить за пределы такого упрощения, тут же получаем все непонятки с требованительной онтологией.
б) с DSL (domain specific language) требований тоже плохо: язык должен выражать какую-то определенную онтологию, нотация должна быть компактна для этой онтологии. Ежели у нас нет онтологии, то мы не можем представить компактный язык для ее описания. Так, сначала можно поверить в SysML как адекватный язык представления требований, затем предложить альтернативную нотацию. Но вот что-то не кажется, что язык (его семантика) адекватен. Далее см. пункт 1 -- нелепо переходить к оптимизации нотации без уверенности в выразительной силе подлежащей семантики.
vit_r пишет: "это элементарный случай дюжина на дюжину. У меня во многих случаях идёт сто на сто. Так что графическое решение многих задач красиво только на элементарных (рекламных) примерах".
ППКС! Полностью согласен с приведенным примером. Хотя из этого не следует, что язык можно сразу выкинуть: можно сохранить его онтологию и семантику, но поменять нотацию. Так, схемами IDEF0 (даже в более расширенном их варианте, так называемом eIDEF0) в графическом виде пользоваться нельзя, но их великолепно подшивать к отчетам по договору: очень умно выглядят и занимают много-много листов бумаги. А вот пользоваться ими удобно только в виде их табличного представления. Хорошенькая такая табличка, с парой дюжиной полей и мнооооожеством строчек, готовится в Exel (например, программой ОргМастер), свободно читается топ-менеджерами без айтишного образования...
Я не приверженец графических языков. Я еще застал те времена, когда было модно обсуждать "блок-схемы программ" как обязательный документ перед написанием текста программы. И помню, чем закончилась эта битва обязательных блок-схем с "просто текстом" программ. Графические картинки алгоритмов и структур данных хорошо использовать в коротких презентациях: показываешь слайд, и много и долго затем что-то по нему рассказываешь. А вот если нужно этот рассказ иметь в письменном виде, то лучше это делать не картинками, а текстом -- и понятней, и быстрей, и компактней, удобней набирать/читать, легче организовать поиск.
UML я не доверяю в том числе и по этой причине: графическое его представление довлеет над текстовым, текстовые нотации для UML практически не используются (чем еще и гордятся). SysML в этом плане ничем не лучше. Десять квадратиков на двадцать линий -- и кончилось как понимание, так и площадь экрана.
Я думаю, наш самый большой вклад в INCOSE может быть в том, что мы будем усомневать SysML в качестве единственного языка системной инженерии. Мне кажется, что будущее тут не за "один язык для всех и обо всем", а за набором DSL для разных групп описаний. Ход на стыковку Modelica с SysML мне не представляется самым удачным (хотя Modelica и имеет текстовое и графическое представление одновременно. Кто знает, вдруг редакторы для Modelica станут средством массового применения SysML для больших систем?).
Если вернуться от общего обсуждения недостатков графических языков для описания больших систем к представлению требований, то
а) с онтологией требований все пока очень плохо:
-- понятие "трассировка" совершенно неоперационально (протрассируйте-ка требования ilities! Как раз про это assurance case, и нужно как-то требования привязывать к claims и далее к тестированию и обоснованиям, что в системах управления требованиями не слишком-то поддерживается, равно как в системах оценки: нет того места, где claims сопоставлялись бы с требованиями, или генерировались из них);
-- верификацию от валидации отличить зачастую затруднительно. Тут вся эта дискуссия про intents, различие "духа" требований и их "буквы", что очень трудно отразить в языке. Различение превращается в игру слов и выпячивание должностей участвующих;
-- иерархичность требований непонятно по каким типам отношений проходит -- понятно только что по разным (в мереологии обсуждается, что иерархии требований-подтребований могут строиться по разным основаниям);
-- разница между функциональными/черного ящика и конструкторскими/белого ящика требованиями размыта;
-- привязка требований к стейкхолдерам, и далее различные view и viewpoints для их выражения отнюдь не способствует единообразному их представлению. Требование "чтобы 2*2 было =4" лучше представлять в формате выражения, а вот требование "на самом видном месте должен быть налеплен логотип" даже не сразу понятно, в каком формате представлять, кроме текстового (хотя я верю, что "самое видное место" вполне можно формализовать и затем проверять выполнение этого требования приборно -- распознаванием сцен).
Этот список можно продолжать и продолжать. Сведение всего этого списка к "требование -- это текстовая строка, не более" сводит системы управления требованиями к простому блокноту, т.е. явно не дает особого выигрыша по сравнению с любой неспециализированной базой данных "текстовых строк". А как только мы пытаемся выскочить за пределы такого упрощения, тут же получаем все непонятки с требованительной онтологией.
б) с DSL (domain specific language) требований тоже плохо: язык должен выражать какую-то определенную онтологию, нотация должна быть компактна для этой онтологии. Ежели у нас нет онтологии, то мы не можем представить компактный язык для ее описания. Так, сначала можно поверить в SysML как адекватный язык представления требований, затем предложить альтернативную нотацию. Но вот что-то не кажется, что язык (его семантика) адекватен. Далее см. пункт 1 -- нелепо переходить к оптимизации нотации без уверенности в выразительной силе подлежащей семантики.