Форум Сообщества Аналитиков

×


Процесс обратной семантической трассировки(Прочитано 34634 раз)
Хочу привлечь к теме, которую Саша(BAS) уже анонсировал при отчете о конфернеции SEC(R).

И так результатом 6 летних усилий стало появление на свет так называемого каркаса P-моделирование (INTSPEI P-Modeling Framework). Скачать каркас можно с сайта института.

В основе лежит так называемое безмолвное моделирование (speechless modeling) и процесс обратной семантической трассировки

Вот что написано:
" Безмолвное Моделирование - мощный метод моделирования, который помогает увеличивать производительность проектировщиков и улучшать качество дизайна.

Сущность Безмолвного Моделирования - ограничение на использование в ходе взаимодействия непосредственного или косвенного применения естественного языка. Через этот метод, группа проектировщиков вынуждена использовать язык моделирования как единственный язык, доступный для связи в течение сеанса дизайна. Любая устная или письменная связь, вовлекающая естественные языки запрещается.

Группы, разрабатывая UML модели без использования правильных (regular) языков фактически превзошли по быстродействию "нормальные" группы, кто действительно использовал естественный язык. Критические причины для такого увеличения в работе лежат в следующем:

    * Ограничение на использование естественного языка стимулирует творческий потенциал проектировщиков, так же как вынуждает их оставаться сосредоточенными на их работе;
    * Работа в безмолвном режиме вынуждает проектировщиков явно раскрывать все основные предположения в очень ранних стадиях процесса дизайна;
    * UML больше не обработан как лишнее бремя, несоответствующее потребностям реальной жизни (как язык "только для прерывания") - вместо этого, проектировщики начинают демонстрировать большее беспокойство о качестве и удобочитаемости их моделей.

Было доказано, что Безмолвное Моделирование является очень эффективным временем и уменьшает время, потраченное на дизайн по сравнению с традиционными методами.

Кроме того, безмолвный сеанс - эффективная деятельность по построению групп: люди, которые никогда не видели друг друга прежде, демонстрируют способность работать в целом. Сеанс помогает выпускать творческий потенциал от новичков и доказан, чтобы показать лидеров в группе.
"


"Сеанс P-моделирования - комбинация Безмолвного Моделирования и Обратной Семантической Трассируемости в один случай. Безмолвный Сеанс - мощный метод моделирования, который позволяет группе выпускать истинный творческий потенциал архитекторов и разработчиков. Главная цель Безмолвного Сеанса состоит в том, чтобы создать дизайн высокого качества и иметь общее понимание архитектуры будущего проекта. В течение этого сеанса, использование любого естественного языка не разрешается; только графический язык моделирования (типа UML) позволяется. Рекомендуется, чтобы группа имела приблизительно 3 часа для тихого моделирования. После Безмолвного Сеанса, Обратная Семантическая Трассируемость выполняется, чтобы проверить правильность созданной архитектуры."

Никто не желает попробывать?



Эд,

Я разговаривал  с Владмиром Павловым, кот. является президетном INTSPEI. Разговаривали в частности о споносрстве программы "Статьи от студентов", и вродебы договрились, но это так отвлечение ...

По теме, Владимир, например, проводил множество семинаров/экспериметнов, по безмолвному моделированию. Суть заключалось в том, что он сажал несколько групп архитекторов и заствлял общаться только на ЮМЛ, без ест яз. Что приводило к двум вещам:
- более быстрое освоение ЮМЛ
- более четкие модели, причем в одном из экспер. группа, кот. общалась на ЮМЛ, дала лучшие результаты, чем группа - ест. яз.

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



Я разговаривал  с Владмиром Павловым, кот. является президетном INTSPEI.
Очень интересно. Значит инстутит наш? А что же нотации только на английском?

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



Очень интересно. Значит инстутит наш? А что же нотации только на английском?
Да, он наш, но штаб-квартира в америке и напрвлен инст на запад. Хотя основные разработки идут на Украине.

Да было бы интересно посмотреть саму методику в действии. А что она только на архитекторов направлена?
Вот тут вопрос большой. На мой вопрос прямо Владимир не ответил, а вопрос был: каким образом можно проверить правильно ли написал аналитик требовния со слов заказчика, ведь именно тут происходит наибольшая потеря.

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



каким образом можно проверить правильно ли написал аналитик требовния со слов заказчика, ведь именно тут происходит наибольшая потеря.
возможна ещё ситуация, когда аналитик записал требования правильно, но сам заказчик ошибается и выдал противоречивые или, как минимум, плохо согласованные требования.
И в первом и во втором случае меня в работе аналитика всегда сильно выручал метод построения  ЮМЛ-моделей для себя - и текстовых экскурсий по ним - для Заказчика.
Обычно это диаграмма классов для бизнес-сущностей и диаграммы состояний для них же.
Иногда сильно помогает активити со свим-лайнами в двух вариантах:
- детальный, с отображением передаваемых между активностями объектов[в состояниях].
- и упрощённый, где поток объектов скрыт полностью или почти полностью.


В модели для себя пытаюсь увязать всё, что записано со слов Заказчика,
а затем - по модели излагаю своё понимание и задаю вопросы в текстовом виде.

Самое мучительное - именно качественная модель.
Если она получилась - текстовое описание рождается как речевой поток у спортивного комментатора :-)

Дальше - уже всё просто: Заказчику отсылается текст с 1-м (главным) вопросом:
правильно ли я, аналитик, понял суть происходящего в предметной области?
И если ДА, то как быть с проблемами, изложенными далее в пачке остальных вопросов?


Всё это пространное описание я привожу с одной целью - 
указать, что вот оно, место для безмолвного моделирования:

бизнес-модель для согласования требований в умах аналитиков.

Даже если аналитик один, и в одном лице объединяет роли и автора и инспектора требований,
и даже, если Заказчик за такое моделирование не платит и падает в обморок при словах ЮМЛ и Диаграмма -
всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".



всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".

Очень интересно. Если у Вас есть такой хороший практический опыт, может быть Вы немного подробнее опишите  с приведением примеров? Мы постараемся развить идею и практику. В частности вот уже идет конкурс UML-сказок. Правда там не все так просто получается...



Gevorg,

Что-то подобное и рассказывал мне Владимир, но где гарантия того, что в фидбэке что-то не пропустит Заказчик?? Что он увидел - это правильно, но у него еще есть мысли, которые просто для него очевидны или следуют из чего-то написанного, и они пропадают. В том случае когда мы транслируем из одной бумажки бругую и потом наоборот, то первоначальную бумажку и конечную можно всегда строго проверить.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



но где гарантия того, что в фидбэке что-то не пропустит Заказчик?? Что он увидел - это правильно, но у него еще есть мысли, которые просто для него очевидны или следуют из чего-то написанного, и они пропадают. В том случае когда мы транслируем из одной бумажки бругую и потом наоборот, то первоначальную бумажку и конечную можно всегда строго проверить.
Саша, не нужно пытаться все решить сразу. Гибкая технология и говорит, что это если и возможно, то стоит больших денег и многого времени.

Идет итерационное приближение к пониманию заказчика, с одновременным изменением его мыслей и идей. В этом вся и соль.

Если же деалть это каскадно - тут ничего имхо не поможет, вернее совершенно иные средства, ресурсы и задачи. Однако даже критические системы типа атомных лодок Трайдент - проектировались итерационно. И ничего плавают



Мы о чем говрим??  О методах проверки или о методологиях, кот. снижают риск не понимания?
Сам Владимир говорил, что данный метод эффективен на больших проектах, где ошибка в начале может дорого стоить в конце
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Вот что написано:
" Безмолвное Моделирование - мощный метод моделирования, который помогает увеличивать производительность проектировщиков и улучшать качество дизайна.

Сущность Безмолвного Моделирования - ограничение на использование в ходе взаимодействия непосредственного или косвенного применения естественного языка. Через этот метод, группа проектировщиков вынуждена использовать язык моделирования как единственный язык, доступный для связи в течение сеанса дизайна. Любая устная или письменная связь, вовлекающая естественные языки запрещается.

УжОс. Первый вопрос, который приходит в голову - а каковы критерии "качества дизайна"?

Язык моделирования, как мне представляется, это РАСШИРЕНИЕ естественного языка, а не альтернатива ему. Не преставляю реальных задач, которые могут быть решены таким методом.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Гриша, надо провести семинар на эту тему и расставить все точки над и :)
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



УжОс. Первый вопрос, который приходит в голову - а каковы критерии "качества дизайна"?

Язык моделирования, как мне представляется, это РАСШИРЕНИЕ естественного языка, а не альтернатива ему. Не преставляю реальных задач, которые могут быть решены таким методом.
Гриша, успокойся. Не надо так нервничать, говорят нервные клетки не восстанавливаются или очень медленно. Вдохни-выдохни (повторить 10 раз). Лучше? Ну славу Богу.

Новое всегда так волнительно и главное так пугает.... :)

Ну, а если всерьез. Хотелось привлечь внимание к теме. Люди уже 6 лет этим занимаются и утверждают - эффект есть! Почему бы и не проанализировать, не попробывать в конце концов



Ну, а если всерьез. Хотелось привлечь внимание к теме. Люди уже 6 лет этим занимаются и утверждают - эффект есть! Почему бы и не проанализировать, не попробывать в конце концов

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

Но я, конечно, сознаю, что позволил себе высказать суждение о предемете, о котором ничего не знаю, на основе, возможно, только рекламной листовки. :) Поэтому меня легко будет переубедить.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



но где гарантия того, что в фидбэке что-то не пропустит Заказчик?? Что он увидел - это правильно, но у него еще есть мысли, которые просто для него очевидны или следуют из чего-то написанного, и они пропадают. В том случае когда мы транслируем из одной бумажки бругую и потом наоборот, то первоначальную бумажку и конечную можно всегда строго проверить.

Да нет особой гарантии, но есть опытное подтверждение того факта, что
записанное со слов Заказчика и переформулированное Аналитиком описание требований даёт одновременно и дополнительный и новый взгляд Заказчику на его требования.
Это даёт дополнительный шанс как-то "зацепить"эти коварные стеллс-требования, которые очевидны для Заказчика и полностью упущены Аналитиком.
Чаще всего это удаётся, когда Аналитик хотя бы малой частью СВОЕГО описания цепляет стеллс-требование и это малое описание оказывается НЕ совпадающим с представлениями Заказчика.
Вот тут нужно цепко хватать и разрабатывать эту золотую жилу.
 

Согласен, если по модели в точности восстанавливается её текстовое описание - тоже есть шанс, что стеллс-требования в скрытом виде будут присутствовать и в модели.
Но во-первых, - это далеко не факт, а во-вторых, они всё равно продолжают оставаться НЕзамеченными Аналитиком!


Другой вариант: стеллс-требование обнаруживается при построении модели, и далее, в текстовом описании проявляется, как отличие во фрагментах исходного и восстановленного документа.
Но здесь трудность в том, что для эффективности такого подхода два варианта текстового документа должны ПОЧТИ совпадать.

Я хотел обратить внимание, что ещё ДО проблем с наличием стеллс-требований, есть другие, не менее болезненные и коварные:
- неоднозначность понимания требований Заказчиком и Аналитиком,
- несогласованность требований "в недрах" самого Заказчика.

А вот тут метод формального преобразования требований туда-сюда совсем не даёт нужного результата:
В первом случае - текст просто будет совпадать,
Во втором - просто не получится построить даже модель, не говоря уже о текстовом описании на её основе.



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

может, всё-таки, не подвох, а жёсткая мера, аналогичная принципу проведения мозгового штурма (на время генерации идей - никакой критики)?

чтоб выжать из UML-а по-максимуму:
поставить архитекторов в безвыходное положение, а потом оценить, что из требований им удалось изобразить в диаграммах.

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19