Форум Сообщества Аналитиков
Общий раздел => Нововведения => Тема начата: Galogen от 05 Ноября 2007, 20:52:35
-
Хочу привлечь к теме, которую Саша(BAS) уже анонсировал при отчете о конфернеции SEC(R).
И так результатом 6 летних усилий стало появление на свет так называемого каркаса P-моделирование (INTSPEI P-Modeling Framework). Скачать каркас можно с сайта института.
В основе лежит так называемое безмолвное моделирование (speechless modeling) и процесс обратной семантической трассировки
Вот что написано:
" Безмолвное Моделирование - мощный метод моделирования, который помогает увеличивать производительность проектировщиков и улучшать качество дизайна.
Сущность Безмолвного Моделирования - ограничение на использование в ходе взаимодействия непосредственного или косвенного применения естественного языка. Через этот метод, группа проектировщиков вынуждена использовать язык моделирования как единственный язык, доступный для связи в течение сеанса дизайна. Любая устная или письменная связь, вовлекающая естественные языки запрещается.
Группы, разрабатывая UML модели без использования правильных (regular) языков фактически превзошли по быстродействию "нормальные" группы, кто действительно использовал естественный язык. Критические причины для такого увеличения в работе лежат в следующем:
* Ограничение на использование естественного языка стимулирует творческий потенциал проектировщиков, так же как вынуждает их оставаться сосредоточенными на их работе;
* Работа в безмолвном режиме вынуждает проектировщиков явно раскрывать все основные предположения в очень ранних стадиях процесса дизайна;
* UML больше не обработан как лишнее бремя, несоответствующее потребностям реальной жизни (как язык "только для прерывания") - вместо этого, проектировщики начинают демонстрировать большее беспокойство о качестве и удобочитаемости их моделей.
Было доказано, что Безмолвное Моделирование является очень эффективным временем и уменьшает время, потраченное на дизайн по сравнению с традиционными методами.
Кроме того, безмолвный сеанс - эффективная деятельность по построению групп: люди, которые никогда не видели друг друга прежде, демонстрируют способность работать в целом. Сеанс помогает выпускать творческий потенциал от новичков и доказан, чтобы показать лидеров в группе."
"Сеанс P-моделирования - комбинация Безмолвного Моделирования и Обратной Семантической Трассируемости в один случай. Безмолвный Сеанс - мощный метод моделирования, который позволяет группе выпускать истинный творческий потенциал архитекторов и разработчиков. Главная цель Безмолвного Сеанса состоит в том, чтобы создать дизайн высокого качества и иметь общее понимание архитектуры будущего проекта. В течение этого сеанса, использование любого естественного языка не разрешается; только графический язык моделирования (типа UML) позволяется. Рекомендуется, чтобы группа имела приблизительно 3 часа для тихого моделирования. После Безмолвного Сеанса, Обратная Семантическая Трассируемость выполняется, чтобы проверить правильность созданной архитектуры."
Никто не желает попробывать?
-
Эд,
Я разговаривал с Владмиром Павловым, кот. является президетном INTSPEI. Разговаривали в частности о споносрстве программы "Статьи от студентов", и вродебы договрились, но это так отвлечение ...
По теме, Владимир, например, проводил множество семинаров/экспериметнов, по безмолвному моделированию. Суть заключалось в том, что он сажал несколько групп архитекторов и заствлял общаться только на ЮМЛ, без ест яз. Что приводило к двум вещам:
- более быстрое освоение ЮМЛ
- более четкие модели, причем в одном из экспер. группа, кот. общалась на ЮМЛ, дала лучшие результаты, чем группа - ест. яз.
Кстати, можно провести и такой семинар в рамках нашего ресурса, даже я думаю можно пригласить или Владимира или кого-то из его инста.
-
Я разговаривал с Владмиром Павловым, кот. является президетном INTSPEI.
Очень интересно. Значит инстутит наш? А что же нотации только на английском?
Кстати, можно провести и такой семинар в рамках нашего ресурса, даже я думаю можно пригласить или Владимира или кого-то из его инста.
Да было бы интересно посмотреть саму методику в действии. А что она только на архитекторов направлена?
А интересно, у них как-то можно пройти повышение квалификации?
-
Очень интересно. Значит инстутит наш? А что же нотации только на английском?
Да, он наш, но штаб-квартира в америке и напрвлен инст на запад. Хотя основные разработки идут на Украине.
Да было бы интересно посмотреть саму методику в действии. А что она только на архитекторов направлена?
Вот тут вопрос большой. На мой вопрос прямо Владимир не ответил, а вопрос был: каким образом можно проверить правильно ли написал аналитик требовния со слов заказчика, ведь именно тут происходит наибольшая потеря.
А интересно, у них как-то можно пройти повышение квалификации?
Что ты имеешь в виду? Инст частный, поэтому банального обмена или повышение квалификации за бесплатно не получится, я думаю, хотя всегда можно поговорить с Владимиром. Так же они проводят тренинги и курсы, но это уже платно и думаб не за дешево.
-
каким образом можно проверить правильно ли написал аналитик требовния со слов заказчика, ведь именно тут происходит наибольшая потеря.
возможна ещё ситуация, когда аналитик записал требования правильно, но сам заказчик ошибается и выдал противоречивые или, как минимум, плохо согласованные требования.
И в первом и во втором случае меня в работе аналитика всегда сильно выручал метод построения ЮМЛ-моделей для себя - и текстовых экскурсий по ним - для Заказчика.
Обычно это диаграмма классов для бизнес-сущностей и диаграммы состояний для них же.
Иногда сильно помогает активити со свим-лайнами в двух вариантах:
- детальный, с отображением передаваемых между активностями объектов[в состояниях].
- и упрощённый, где поток объектов скрыт полностью или почти полностью.
В модели для себя пытаюсь увязать всё, что записано со слов Заказчика,
а затем - по модели излагаю своё понимание и задаю вопросы в текстовом виде.
Самое мучительное - именно качественная модель.
Если она получилась - текстовое описание рождается как речевой поток у спортивного комментатора :-)
Дальше - уже всё просто: Заказчику отсылается текст с 1-м (главным) вопросом:
правильно ли я, аналитик, понял суть происходящего в предметной области?
И если ДА, то как быть с проблемами, изложенными далее в пачке остальных вопросов?
Всё это пространное описание я привожу с одной целью -
указать, что вот оно, место для безмолвного моделирования:
бизнес-модель для согласования требований в умах аналитиков.
Даже если аналитик один, и в одном лице объединяет роли и автора и инспектора требований,
и даже, если Заказчик за такое моделирование не платит и падает в обморок при словах ЮМЛ и Диаграмма -
всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".
-
всё равно стОит таким заниматься, чтобы уменьшить эту злобную "наибольшую потерю".
Очень интересно. Если у Вас есть такой хороший практический опыт, может быть Вы немного подробнее опишите с приведением примеров? Мы постараемся развить идею и практику. В частности вот уже идет конкурс UML-сказок. Правда там не все так просто получается...
-
Gevorg,
Что-то подобное и рассказывал мне Владимир, но где гарантия того, что в фидбэке что-то не пропустит Заказчик?? Что он увидел - это правильно, но у него еще есть мысли, которые просто для него очевидны или следуют из чего-то написанного, и они пропадают. В том случае когда мы транслируем из одной бумажки бругую и потом наоборот, то первоначальную бумажку и конечную можно всегда строго проверить.
-
но где гарантия того, что в фидбэке что-то не пропустит Заказчик?? Что он увидел - это правильно, но у него еще есть мысли, которые просто для него очевидны или следуют из чего-то написанного, и они пропадают. В том случае когда мы транслируем из одной бумажки бругую и потом наоборот, то первоначальную бумажку и конечную можно всегда строго проверить.
Саша, не нужно пытаться все решить сразу. Гибкая технология и говорит, что это если и возможно, то стоит больших денег и многого времени.
Идет итерационное приближение к пониманию заказчика, с одновременным изменением его мыслей и идей. В этом вся и соль.
Если же деалть это каскадно - тут ничего имхо не поможет, вернее совершенно иные средства, ресурсы и задачи. Однако даже критические системы типа атомных лодок Трайдент - проектировались итерационно. И ничего плавают
-
Мы о чем говрим?? О методах проверки или о методологиях, кот. снижают риск не понимания?
Сам Владимир говорил, что данный метод эффективен на больших проектах, где ошибка в начале может дорого стоить в конце
-
Вот что написано:
" Безмолвное Моделирование - мощный метод моделирования, который помогает увеличивать производительность проектировщиков и улучшать качество дизайна.
Сущность Безмолвного Моделирования - ограничение на использование в ходе взаимодействия непосредственного или косвенного применения естественного языка. Через этот метод, группа проектировщиков вынуждена использовать язык моделирования как единственный язык, доступный для связи в течение сеанса дизайна. Любая устная или письменная связь, вовлекающая естественные языки запрещается.
УжОс. Первый вопрос, который приходит в голову - а каковы критерии "качества дизайна"?
Язык моделирования, как мне представляется, это РАСШИРЕНИЕ естественного языка, а не альтернатива ему. Не преставляю реальных задач, которые могут быть решены таким методом.
-
Гриша, надо провести семинар на эту тему и расставить все точки над и :)
-
УжОс. Первый вопрос, который приходит в голову - а каковы критерии "качества дизайна"?
Язык моделирования, как мне представляется, это РАСШИРЕНИЕ естественного языка, а не альтернатива ему. Не преставляю реальных задач, которые могут быть решены таким методом.
Гриша, успокойся. Не надо так нервничать, говорят нервные клетки не восстанавливаются или очень медленно. Вдохни-выдохни (повторить 10 раз). Лучше? Ну славу Богу.
Новое всегда так волнительно и главное так пугает.... :)
Ну, а если всерьез. Хотелось привлечь внимание к теме. Люди уже 6 лет этим занимаются и утверждают - эффект есть! Почему бы и не проанализировать, не попробывать в конце концов
-
Ну, а если всерьез. Хотелось привлечь внимание к теме. Люди уже 6 лет этим занимаются и утверждают - эффект есть! Почему бы и не проанализировать, не попробывать в конце концов
Там какой-то подвох. Либо архитекторы так глубоко знают UML, что он им окончательно заменил естественный язык ;) , либо круг задач ограничен так, что все базовые решения по архитектуре уже приняты (или тривиальны).
Но я, конечно, сознаю, что позволил себе высказать суждение о предемете, о котором ничего не знаю, на основе, возможно, только рекламной листовки. :) Поэтому меня легко будет переубедить.
-
но где гарантия того, что в фидбэке что-то не пропустит Заказчик?? Что он увидел - это правильно, но у него еще есть мысли, которые просто для него очевидны или следуют из чего-то написанного, и они пропадают. В том случае когда мы транслируем из одной бумажки бругую и потом наоборот, то первоначальную бумажку и конечную можно всегда строго проверить.
Да нет особой гарантии, но есть опытное подтверждение того факта, что
записанное со слов Заказчика и переформулированное Аналитиком описание требований даёт одновременно и дополнительный и новый взгляд Заказчику на его требования.
Это даёт дополнительный шанс как-то "зацепить"эти коварные стеллс-требования, которые очевидны для Заказчика и полностью упущены Аналитиком.
Чаще всего это удаётся, когда Аналитик хотя бы малой частью СВОЕГО описания цепляет стеллс-требование и это малое описание оказывается НЕ совпадающим с представлениями Заказчика.
Вот тут нужно цепко хватать и разрабатывать эту золотую жилу.
Согласен, если по модели в точности восстанавливается её текстовое описание - тоже есть шанс, что стеллс-требования в скрытом виде будут присутствовать и в модели.
Но во-первых, - это далеко не факт, а во-вторых, они всё равно продолжают оставаться НЕзамеченными Аналитиком!
Другой вариант: стеллс-требование обнаруживается при построении модели, и далее, в текстовом описании проявляется, как отличие во фрагментах исходного и восстановленного документа.
Но здесь трудность в том, что для эффективности такого подхода два варианта текстового документа должны ПОЧТИ совпадать.
Я хотел обратить внимание, что ещё ДО проблем с наличием стеллс-требований, есть другие, не менее болезненные и коварные:
- неоднозначность понимания требований Заказчиком и Аналитиком,
- несогласованность требований "в недрах" самого Заказчика.
А вот тут метод формального преобразования требований туда-сюда совсем не даёт нужного результата:
В первом случае - текст просто будет совпадать,
Во втором - просто не получится построить даже модель, не говоря уже о текстовом описании на её основе.
-
Там какой-то подвох. Либо архитекторы так глубоко знают UML, что он им окончательно заменил естественный язык ;) ,
либо круг задач ограничен так, что все базовые решения по архитектуре уже приняты (или тривиальны).
может, всё-таки, не подвох, а жёсткая мера, аналогичная принципу проведения мозгового штурма (на время генерации идей - никакой критики)?
чтоб выжать из UML-а по-максимуму:
поставить архитекторов в безвыходное положение, а потом оценить, что из требований им удалось изобразить в диаграммах.
а по поводу базовых решений и ограниченности круга задач - так тут уместно вспомнить про шаблоны проектирования (Design Patterns),
без использования которых уже трудно представить современную профессиональную команду архитекторов.
-
Но я, конечно, сознаю, что позволил себе высказать суждение о предемете, о котором ничего не знаю, на основе, возможно, только рекламной листовки. :) Поэтому меня легко будет переубедить.
Да я и сам не прочь убедиться :)
Единственно, что цепляет. Так вот UML, IDEF и прочие штучки, даже самое ООП, не везде вообщем-то приживается, порой просто отторгается, не принимается.
Причина вполне понятна - и так работаем, и вроде получается, и даже зарабатываем. А освоение нового, да еще не понятного, только со слов кого-то действенное - настораживает. Понятно, что для освоения нужно: раз, два, три, четыре - да ну ее в болото...
Пример из жизни. В начале года на предмете Web-технологии возглашаю:
"Милостливые студенты! Мы будем с вами изучать PHP. Мы будем изучать его в стиле ООП. За ООП разработку на языке РНР - бонус."
Есть достаточно богатый разработанный пример для ООП - целый струмент с фронтэндом, админкой. На нем построен курс практики. Сначал все скурпулезно объясняется почему так, а как иначе. Предлагается усе повторить, а затем добавить свои фичи (задания отображаются синеньким цветом).
Для проверки знаний устраиваю контрольные. Алгоритмы простенькие. Задачки беру из методички 1 курса по паскалю. Естественно прошу реализовать на РНР, и не просто реализовать а постараться показать свою профпригодность. Куда-там! сплошной линейный код с кучей условий и циклов, в лучшем случае кто-то сруппирует это по функциям и то совершенно не корректно: каждой функции свое действие. Про использование объектов - вообще молчу. Хотя мой выстраданный пример - бери и пользуйся. Сложно мыслить объектно!
Т.е. для перехода на что-то новое должна быть какая-то нетривиальная проблема, которая просто заставит потратить силы на изменение.
Конечно есть еще волшебное слово пиар. Возможно UML - это пиар? И все что с ним связано? Может нужно чтобы прошло лет 10-20, чтобы UML воспринимался так же как обычные блок-схемы?
-
По поводу UML вместо естественного языка:
- наверное, это возможно - все ведь помнят мат. анализ с его интернациональным формальным языком (хотя, как выясняется, у каждого математика - свой диалект этого языка);
- это расходится с agile методологиями, в которых, как известно, главный носитель знаний - не документ, а человек;
- созданная модель будет понятна только архитекторам (хотя бы "по совместительству"); как объяснять новому участнику команды, о чём вообще эта модель без слов - не представляю; а ведь модель как раз и нужна, чтобы её ВСЕ использовали в виде справочника.
-
<...>Для проверки знаний устраиваю контрольные. Алгоритмы простенькие. Задачки беру из методички 1 курса по паскалю. Естественно прошу реализовать на РНР, и не просто реализовать а постараться показать свою профпригодность. Куда-там! сплошной линейный код с кучей условий и циклов, в лучшем случае кто-то сруппирует это по функциям и то совершенно не корректно: каждой функции свое действие. Про использование объектов - вообще молчу. Хотя мой выстраданный пример - бери и пользуйся. Сложно мыслить объектно!
<...>
Всё правильно. Студенты - умные и ленивые, алгоритмы простые, ресурсы (особенно временнЫе) у них на контрольной ограничены. Вот они и идут более естественным способом. Вот если бы Вы разделили их на команды и дали каждой команде огромный курсовик (есть у них бух. учёт? ИС бух. учёта) - могли бы увидеть как минимум структурное программирование и правильную разбивку по функциям.
-
Всё правильно. Студенты - умные и ленивые, алгоритмы простые, ресурсы (особенно временнЫе) у них на контрольной ограничены. Вот они и идут более естественным способом.
Согласен. Золотые слова - они идут естественным способом. Что значит естественным, кто сказал, что линейный код естественный? Это для 5 курса естественный код? :)
Вот Вам и реперная точка, вот и критерий для проверки профпригодности.
Да они сразу должны мылсить объектно, структурно как минимум. Почему не получается? Потому как такова система образования (по крайней мере на нашей кафедре). Что очень жаль.
Потому для них структурный код или ОО код - неестественный :(
А ведь стоит учесть еще и тот факт, что это 5 курс после сдачи квалификационной работы на бакалавра!!!
Вот если бы Вы разделили их на команды и дали каждой команде огромный курсовик (есть у них бух. учёт? ИС бух. учёта) - могли бы увидеть как минимум структурное программирование и правильную разбивку по функциям.
Alex, давайте не будем путать божий дар с яичницей. Все-таки курс у меня другой, задача подобная бух учету решается на 3 курсе в рамках соотвествующих дисциплин - смотрите мои опыты преподавания в разделе Обучения.
Прадва бухучета у них нет как предмета, что конечно сильно жаль.
-
ИМХО попытка ограничиться использованием исключительно UML пока преждевременна. Очевидно, что это сильно сужает выразительные средства участников создания системы (как со стороны Заказчика, так и со стороны разработчиков). А цель? Ускорение (удешевление) разработки? Более точный учет требований в коде? Более точное соответствие формулировки требований реальному смыслу, который в них вкладывает Заказчик?
Скорее аскетизм выразительных средств UML позволяет средствами UML искусственно загрубить конткекст обсуждения участников создания системы, чтобы более рельефно выявить самые важные, глубинные контуры структуры и функционала системы. При этом поясняющие детали, в том числе на "естественном языке" могут добавляться по необходимости. И отбирать у участников разработки такую возможность скорее контрпродуктивно.
Представляется заманчивым разработать язык моделирования, который позволял бы более компактно описывать действия как на этапе анализа, так и разработки, аналогично тому как векторная и матричная алгебра позволяет более компактно описывать многие физические модели, по сравнению с координатной формой представления. Более того, порождаются собственные формализмы, позволяющие быстро и наглядно решать многие задачи. При этом, при необходимости всегда можно строго и однозначно перейти от векторных и матричных представлений к координатным. В практике использования UML попытку генерации кода из диаграмм можно рассматривать как попытку движения в этом направлении. Но перспектив дальнейшего развития UML как "векторно-матричного" инструмента анализа и разработки, к сожалению не просматривается. Эта задача явно еще ждет своих Кирилла и Мефодия.
Пока же попытка отлучить участников создания системы от естественного языка в любой форме больше напоминает опыты биологов:
Известно, что шимпанзе способны выучить язык глухонемых и формулировать простейшие просьбы и утверждения. Возникло предположение, что если их погрузить более интенсивно в языковую среду, можно было бы добиться больших успехов как в их обучении языку, так и, возможно, уровня разумности. С этой целью одна семья американиских биологов воспитывала своего ребенка вместе с детенышем шимпанзе и учила их общаться на языке глухонемых. Результат был печальным: шимпанзе через пять лет остановился в развитии, при этом замедлилось развитие и ребенка человека. Получилось, что возможности обезьяны затормозили развитие человека, не ограничит ли "монопольное использование" UML в противовес "традиционным языковым средствам" развитие ИТ-практик?
Ведь несмотря на то, что диаграммы очевидно помогают разработке, создатели UML не ставили перед собой революционных задач - основная цель была прекратить "войну нотаций" и привести их к некоему общему знаменателю
-
Посмотрел несколько докладов Владимира Павлова (http://www.vlpavlov.com/). очень интересный авторский подход. Описана методика проведения экспериментов по безмолвному моделированию и обратной семантической трассировке. Результаты впечатляют, по крайне мере,что касается анализа требований.
Правда презентации не дают возможности понять как же все это реально работает. При этом возникает вопросы:
1. Что значит отличное знание UML и ООП?
2. Как достичь у студентов этого знания, что нужно предпринять для этого? Хотя ответ дан в виде повторяющихся слов Практика, но вопрос как ее грамотно обеспечить? Т.е. что и как надо организовать в процессе обучения
Радует хотя бы то, что Владимир готов выезжать в вузы и проводить семинары и тренинги бесплатно!
Интересно, можно ли у него пройти курсы повышения квалификации.
-
Правда презентации не дают возможности понять как же все это реально работает.
Вот это большой вопрос. Мне кажется работает это не очень. Во всяком случе где примеры реального внедрения применения?
Радует хотя бы то, что Владимир готов выезжать в вузы и проводить семинары и тренинги бесплатно!
Опана?! Это где написано. Может пригласим кого-то из их инста на семинар??
-
Вот это большой вопрос. Мне кажется работает это не очень. Во всяком случе где примеры реального внедрения применения?
Понимаешь пока это скорее исследовательское направление. Как я понял данная методика хорошо прочищает мозги студентам и дает им живое понимание полезности и нужности UML. Ведь не секрет, что несмотря на многие разговоры про UML, он используется довольно слабо
Опана?! Это где написано. Может пригласим кого-то из их инста на семинар??
это написано в презентациях, которые я скачивал, может это и не актуально уже. По крайней мере, там было написано, что для вузов тренинги бесплатные. Правда нужно оплатить дорогу и проживание тренера. Вообще интересно было бы посмотреть что это такое.
В презентации вообще описана методика проведения семинара, однако она требует хорошей подготовки самих студентов- раз, супер подготовки тренера - два.
Тут как раз с первым и есть проблема: как хорошо подготовить студентов. Вроде в презентациях дается некий ответ: обучение UML и OO в пантомимах, но что это есть не совсем понял.
В любом случае везде приводится метафора Вавилонской башни, а также тренинговая игра в Крокодила. Т.е. задается слово типа мелиорация и нужно противоположной команде изобразить жестами, а команда должна угадать слово.