Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Тема начата: po_lena от 17 Марта 2016, 16:35:20
-
Добрый день, коллеги!
в процессе своей недолгой работы аналитиком столкнулась с такой проблемой:
каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?
интересует, каким образом справляются с этой проблемой вообще и какие инструменты для этого используют.
А также буду рада услышать ваши предложения, как разрулить этот вопрос на проекте, где SRS ведется с помощью MS Word, а версионирование документа осуществляется в SVN.
буду благодарна,если поделитесь своим опытом :)
-
сообщение устарело
-
каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?
буду благодарна,если поделитесь своим опытом :)
Делюсь. Для этого самое главное - голова на плечах. Которая и определяет, нужно ли вносить изменения в прямо или косвенно или вообще ранее несвязанные требования. После того, как голова определила, провести изменения уже не проблема, подойдет любой формат. Свои изменения вносятся самолично, "чужие" доводятся до ответственного за них как положено, например письмом.
При этом куда технически нужно вносить изменения - в вордовый файлик, в систему управления требованиями и т.п., глубоко безразлично.
Если же голова не может определить масштаб и глубину влияния изменения, никакие "инструменты" не помогут. Скорее, даже навредят путем демонстрации простых, очевидных и в общем случае скомпрометированных взаимосвязей.
Если Вы в аналитике недавно, скорее всего, возможности вашей "головы" еще ограничены. Тут уж как повезет: старайтесь, и будет получаться все лучше. А потом требовать усилий все меньше. Это нормально. Если же решите положиться на "инструменты"... Ну, пеняйте на себя, как говорится. Скорее всего, быстро получите удовлетворительный результат, но перспектив развития почти не будет. Как у современных бухгалтеров, которые разбираются не в бухгалтерии, а в том, куда надо нажать в 1С конкретной версии.
-
Делюсь. Для этого самое главное - голова на плечах.
Спасибо за мнение :)
Согласна с Вами, но все же считаю, что полагаться только лишь на голову не даст 100% гарантии того, что что-то не будет упущено. Ведь человеческий фактор никто не отменят.
Тем более голова не всегда поможет, если на проекте аналитик работает не с самого начала, а перенимает работу у другого коллеги (сама с таким сталкивалась). Если проект уже шел довольно долго, и документации насобиралось прилично, то знания, где откуда и что поменять, у нового аналитика появятся далеко не сразу.
То, о чем Вы пишите - типичная задача трассировки требований.
Ее решают с помощью ведения требований и их связей в специализированных системах.
Мы, например, используем 3SL Cradle, поскольку в ней легче всего работать со связями.
Благодарю, особенно за линки )
-
сообщение устарело
-
Согласна с Вами, но все же считаю, что полагаться только лишь на голову не даст 100% гарантии того, что что-то не будет упущено. Ведь человеческий фактор никто не отменят.
"Полное спокойствие может дать человеку только страховой полис" (с)
Именно потому, что человеческий фактор никто не отменял, что-то упущено будет всегда, независимо от инструментария.
Тем более голова не всегда поможет, если на проекте аналитик работает не с самого начала, а перенимает работу у другого коллеги (сама с таким сталкивалась).
Голова поможет всегда. )
А вот некая проекция текущей ситуации непонятной актуальности нередко вводит в заблуждение и вызывает ложное чувство того, что "все сделал правильно".
Если проект уже шел довольно долго, и документации насобиралось прилично, то знания, где откуда и что поменять, у нового аналитика появятся далеко не сразу.
Этих знаний в полном объеме не будет ни в какой документации и ни в каком инструменте. Содержимое что первого, что второго есть лишь бледная и ущербная тень того образа системы, который формируется в голове аналитика.
Когда новый аналитик осознает, что этих знаний у него нет, он их ищет самостоятельно, в процессе раскапывая массу интересного и полезного. Но когда ему услужливо подсовывают бумажку, на которой якобы все есть... Ну, редко кто удержится от соблазна не париться.
В общем, смотрите, что ближе лично Вам.
-
каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?
интересует, каким образом справляются с этой проблемой вообще и какие инструменты для этого используют.
приходите 31-го марта вечером в Лабораторию Касперского, узнаете о том, как это делают в международной продуктовой компании:
https://laboratoriya-kasperskogo.timepad.ru/event/303252/
-
сообщение устарело
-
Вот, кстати, Humbert недавно проводил независимое сравнение 3SL Cradle и Sparx EA, о котором будут рассказывать в Касперском.
Было бы интересно, если у него нашлось время поделиться мнением, применительно к той задаче, которую описала в начале Елена.
На мой взгляд, Sparx здесь проигрывает, т.к. он все-таки больше направлен на моделирование, модуль работы с требованиями и их связями у него гораздо слабее.
Прошу прощения, но я бы сделал окончательные выводы именно после знакомства с технологиями Касперского на вышеуказанной конференции. Сравнение для себя я сделал, но все таки оно не вполне корректно - если 3SL Cradle в качестве демо дает целостные проекты , то вот с рабочими проектами EA я еще не сталкивался, а на демопроекте EA выглядит как UML - рисовалка. Как раз хотел глянуть и послушать Сурину, чтобы оценить технологию в целом.
-
сообщение устарело
-
1. Сурина не Сурина, а вовсе даже Сурова и более того — модератор это раздела форума.
2. Управление изменениями они скорей всего реализуют в TFS (а не в EA), как часть процесса УТ.
До мероприятия можно посмотреть старые выступления Ирины и почитать расшифровки:
https://vimeo.com/70325086 TFS + EA. Созданы друг для друга?
https://vimeo.com/96520606 Шаблоны трассировок бизнес-требований на кросс-проектных продуктах
https://vimeo.com/100633408 Управление изменениями требований
https://habrahabr.ru/company/sqalab/blog/221909/ Использование трассировок на практике
-
сообщение устарело
-
да, действительно, как я помню им приходится подтаскивать к EA вторую систему, в данном случае TFS, поскольку EA не поддерживает управление версиями, в отличие от Cradle, где есть встроенное управление версиями каждого отдельнго требования.
Управлять требованиями можно в узком смысле и в широком.
В узком смысле – это версии требований, трассировки и «статусы» требований. Аналитикам обычно понятна только эта часть «управления», но те «статусы», которые не относятся напрямую к разработке требований, – это для них только следы процессов, которые находятся вне зоны их контроля.
Управление требованиями в широком смысле – это процесс, пронизывающий всю разработку. Программирование, тестирование, документирование, испытания, внедрение – всё это должно быть привязано к требованиям, и результаты этих процессов порождают те самые «статусы». Отвечает за этот процесс управления требованиями обычно менеджер (проекта или продукта).
TFS – это инструмент командной работы. Его интеграция с инструментом разработки требований типа EA позволяет всем участникам процессов разработки получать требования в виде, пригодном для использования в их процессах, и автоматически фиксировать результаты их труда в тех самых «статусах».
-
сообщение устарело
-
Может им просто попробовать Cradle и станет легче? Хотя они столько уже вложили в свою интеграцию, что врядли смогут перестроиться.
Касперский компания не проектная, а продуктовая, отличается примерно как завод от стройки. Могу предположить, что репозиторий кода и управление его движением у них основное. Я Cradle изучил еще недостаточно, но насколько я понял репозитория у него нет, даже такого куцего, как у EA. Так же не заметил в Cradle следов для организации межпроектного взаимодействия (впрочем как и у ЕА).
Так что осмелюсь предположить, что основным двигателем прогресса у Касперского были разработчики, а EA они в качестве погремушки для аналитиков прикрутили. И он для этих целей опять же лучше подходит - можно легко регулировать уровень использования, открытая СУБД (с возможностью миграции на любую другую)
Так что с уровня моих знаний об этих продуктах выбор EA вполне обоснован.
-
Humbert,
обратите, пожалуйста, внимание, в контексте чего ведется обсуждение.
Исходный посыл po_lena
"каким образом, при изменении одного требования, не упустить необходимость изменить и связанные требования?
А также буду рада услышать ваши предложения, как разрулить этот вопрос на проекте, где SRS ведется с помощью MS Word, а версионирование документа осуществляется в SVN."
В соответствии с исходными положениями, есть:
Спецификация требований в MS Word плюс SVN для хранение версий этого документа.
и задача легко управлять трассировкой требований.
Я предлагаю:
Две системы (MS Word+SVN) заменить на одну - 3SL Cradle,
Это позволит:
1) Легко перейти от MS Word к Cradle, благодаря Cradle Document Loader, при этом Cradle поэлементно сохранит все связи с исходными документами (трассировку).
http://www.youtube.com/watch?v=QKu5LLCnkOY
2) Использовать мощные функции Cradle по работе с трассировкой требований (аналогичного инструмента по удобству работы с трассировкой текстовых требований и моделей просто нет).
3) Управлять версиями требований в Cradle (т.к. это встроенная возможность), что позволит отказаться от SVN для версионирования спецификации и автоматически вести историю изменений содержания и атрибутов КАЖДОГО ОТДЕЛЬНОГО требования, а не документа в целом.
4) Управлять атрибутами требований в Cradle (приоритетами, статусами и др.), т.е. получить новые возможности, т.к. ни Word, ни SVN не позволяют этого делать.
--------------------------
Коллеги предложили посмотреть на опыт Лаборатории Касперского. Посмотреть на чужой опыт всегда хорошо.
Давайте посмотрим, что применительно к данной ситуации получится в этом случае:
Две системы (MS Word+SVN) заменятся на две системы Sparx EA + TFS
1) Переход от MS Word к Sparx EA неоднозначен.
а) переносить требования из спецификации в модуль RM придется ручками?
б) Sparx EA - это все-таки инструмент для моделирования (Вы сами об этом написали). Переводить всю спецификацию в UML-модели? А надо ли это в данном случае. В исходном посыле не отражено.
2) Трассировка разных типов текстовых требований в Sparx есть, но она гораздо слабее и менее удобна чем в Cradle. В Sparx модуль RM вырос как надстройка над UML-моделированием и он слабо развит.
3) Управлять версиями требований в TFS, причем управлять именно пакетами версий, а не версией каждого отдельного требования, поскольку Sparx поддерживает версионность только на уровне целых пакетов. Это также плохо влияет на возможность быстрой оценки изменений сквозь несколько версий.
4) Управлять статусами и приоритетами требований в Sparx (без возможности отслеживания истории изменений)
В соответствии с исходными условиями задачи второе решение (Sparx EA +TFS) получается:
а) более затратным
б) менее продуктивным
в) менее эргономичным
Поэтому целесообразность сделанного предложения про EA+TFS в данном случае мне непонятна.
Более того, хочу отметить, что из участвующих в дискуссии, насколько мне известно, никто Enterprise Architect в реальной работе не использует.
Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html
------------------
На этом свою помощь топикстартеру считаю оказанной. Если те, кто реально используют Enterprise Architect, захотят обсудить его с теми, кто реально использует 3SL Cradle - welcome https://www.facebook.com/groups/sysdes/.
-
сообщение устарело
-
.
-
Коллеги предложили посмотреть на опыт Лаборатории Касперского. Посмотреть на чужой опыт всегда хорошо.
Поэтому целесообразность сделанного предложения про EA+TFS в данном случае мне непонятна…
Топикстартер просила поделиться своим опытом, а не только тем своим опытом, который точно подойдёт в её очень фрагментарно описанной ситуации:
буду благодарна,если поделитесь своим опытом :)
Я рассказываю, где об этом опыте можно быстро и дёшево узнать (ссылки на открытые материалы, бесплатная встреча через 10 дней).
Я так вообще не фанат никакого ПО (а скорее открытых систем как класса) и считаю, что самое полезное, что можно будет извлечь из рассказов Ирины и Романа — это методические вещи по организации работы.
-
Связка EA + TFS, как и любого другого набора инструментов разных производителей, сама по себе довольно дорога в разработке, сопровождении и развитии, поэтому естественно такое себе могут позволить только крупные компании с достаточным штатом.
-
[Удалено как не относящееся к дискуссии]
-
Коллеги, если вам не нравится Cradle – аргументируйте.
Если вы считаете необходимым продвигать другой продукт – продвигайте на здоровье.
-
Я считаю необходимым ограничивать навязчивую рекламу одного и того же продукта.
-
Сделайте в конце концов подраздел Cradle также, как это сделано для EA — и там сходите с ума.
-
Я считаю необходимым ограничивать навязчивую рекламу одного и того же продукта.
Все сообщения шли строго в рамках запрошенной темы. Все приведенные факты объективны и легко проверяются.
-
Сделайте в конце концов подраздел Cradle также, как это сделано для EA — и там сходите с ума.
Если любители продукта об этом попросят - сделаем. В данном случае дается ответ на вопрос топикстартера. Плюрализм мнений и предложений приветствуется. Наезды - нет.
-
.
-
Если любители продукта об этом попросят - сделаем.
Это относится только к Cradle или к любым продуктам, используемым аналитиком?
-
Я вижу, как неприветствуются наезды, судя по тому, что фраза:
"хотя причины этого эмоционального порыва всем участникам обсуждения хорошо известны"
осталась
Автор удалила эту часть комментария.
-
Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html
Начинающих аналитиков. У vimeo есть ограничение на длину названия записи, поэтому пришлось это слово убрать. Но на первом слайде презентации оно есть.
EA поддерживает массу нотаций, далеко не ограничиваясь UML. И да, мы его используем, но только как инструмент рисования диаграмм. Возможности трассировки требований, насколько мне известно, у него довольно богатые, но в наших условиях не востребованы.
Это вообще проблема многих подобных систем: они позволяют делают в базе данных практически что угодно, но остаются при этом инструментами аналитика. Других участников процесса в них загонять бессмысленно: у них свои погремушки. Поэтому и приходится интегрировать.
К тому же TFS, например, легко подключается мощный инструмент тестирования от Microsoft. Это "погремушка" тестировщиков, в которой они разрабатывают и выполняют тест-кейсы и планы тестирования. А благодаря интеграции с TFS эти тест-кейсы трассируются прямо на код. Так что если вы что-то поменяли в коде, система автоматически определит, какие тест-кейсы эти изменения затрагивают, и предложит их выполнить повторно.
В идеальном мире хотелось бы видеть такую же интеграцию с инструментами разработки требований. Насколько я слышал несколько лет назад, Microsoft планировала какие-то попытки в этом направлении (хотели интегрироваться с системами других разработчиков), но о результатах мне ничего не известно.
-
TFS – это инструмент командной работы. Его интеграция с инструментом разработки требований типа EA позволяет всем участникам процессов разработки получать требования в виде, пригодном для использования в их процессах, и автоматически фиксировать результаты их труда в тех самых «статусах».
Да, примерно так. К тому же далеко не все в ЛК используют для разработки требований EA, кому-то достаточно Notepad, а кто-то пишет их прямо в TFS. Но в конечном итоге под учет все ставится в TFS-е.
Речь о том, что коллеги из Лаборатории Касперского используют TFS для управления версиями требований/моделей, поскольку Sparx этого не позволяет. Т.е. это вынужденная интеграция.
Если бы Sparx позволял управлять версиями требований и моделей - им бы для этого [управления версиями требований и моделей] TFS не нужен был.
Нет, конечно же нет. TFS поддерживает весь цикл разработки - от привязки Change Request'ов и багов к коммитам в исходники, и до сборки билдов.
-
Humbert,
обратите, пожалуйста, внимание, в контексте чего ведется обсуждение.
Целиком и полностью согласен, что Cradle - это первый продукт, который следует рассмотреть для решения задачи топикстартера. Помимо всего прочего, Cradle предполагает предварительную фиксацию технологии по работе с требованиями, а тто уберегает от множества ошибок, по сравнению с рисовалками.
-
Коллеги, спасибо всем за мнения и опыт, которым делитесь
Я так вообще не фанат никакого ПО (а скорее открытых систем как класса)
Денис, а можете поподробнее рассказать, почему?
-
Всем привет!
Присоединяюсь к дискуссии.
Спасибо Леониду и Грише - полностью согласна с тем, что голова первичней, чем инструмент. Имея опытную голову и понимая свои потребности, в инструменте можно построить то, что нужно.
На встрече 31 марта мы будем рассказывать про инструменты в контекстах наших проектов (продуктовых, in-house, сервисных/инфраструктурных). Как уже сказал Дима DIV, далеко не все аналитики в ЛК используют EA, а вот TFS использует весь R&D, это был проект внедрения на весь департамент.
С удовольствием расскажу, как было на самом деле, чтоб не приходилось гадать, что там вынужденное, что к чему прикручивали и т.д.
Интересующие вопросы можно задать здесь, постараемся учесть при подготовке к встрече.
Humbert, если нужна какая-то дополнительная информация для сравнения, обращайтесь, буду рада помочь.
Сразу замечу, что на оба инструмента в связке на этой встрече рассказывать не планируем, так же как и про версионирование, так как это отдельные большие темы, обсудить которые мы не успеем за 1 встречу.
Рекламы инструментов не будет. Общий стиль: потребности - способ их удовлетворения - реализация в инструменте. Если при таких же потребностях используете выбранный способ удовлетворения в другом инструменте или подскажете подходящий другой способ удовлетворения тех же потребностей, будет здорово :)
С уважением,
Ирина Сурова
-
На встрече 31 марта мы будем рассказывать про инструменты в контекстах наших проектов (продуктовых, in-house, сервисных/инфраструктурных). Как уже сказал Дима DVI, далеко не все аналитики в ЛК используют EA, а вот TFS использует весь R&D, это был проект внедрения на весь департамент.
С удовольствием расскажу, как было на самом деле, чтоб не приходилось гадать, что там вынужденное, что к чему прикручивали и т.д.
Интересующие вопросы можно задать здесь, постараемся учесть при подготовке к встрече.
Надеюсь записи встречи будут, ведь аналитики не только в Москве водятся.
А тема действительно интересная
-
Надеюсь записи встречи будут, ведь аналитики не только в Москве водятся.
А тема действительно интересная
Не уверена, что запись будет, так как это решаю не я. Но если тема реально интересна, то мы можем поговорить об этом на ЛАФ. (http://conf.uml2.ru/)
-
Поскольку со стороны участников дискуссии имеются нарушения правил данного форума будет не лишним их повторить. Прочитайте их пожалуйста и сверьте свое поведение на форуме: Правила форума (http://www.uml2.ru/forum/index.php?topic=1901.msg19090#msg19090).
В частности прошу обратить внимание на следующее:
Запрещается:
- Публикация грубых, оскорбляющих и унижающих сообщений. Ненормативная лексика разрешена только в исключительных случаях, когда изъятие нецензурных слов из предложения полностью изменяет смысл сообщения. В случае употребления нецензурных слов, бОльшая часть слова должна быть замаскирована спецсимволами. Оскорбительные высказывания в адрес любой страны, государства, народа и отдельных личностей нежелательны, а в отношении Российской Федерации, ее исторических предшественников и исторических личностей запрещены.
- Публикация сообщений с использованием широкоизвестного приема демагогии под названием "Переход на личности".
Публикация сообщений рекламного характера
- Разрешается публикация рекламного характера, соответствующего тематике форума, в том числе и коммерческого плана, если это поможет автору вопросу.
- Разрешается рекламные публикации в первом посте только нашим партнерам.
- Остальные рекламные объявления в первом посте должны быть согласованы с Администрацией.
- Администрация оставляет за собой право удалять сообщения рекламного характера без объяснения причин, в случае, если они не соответствуют тематике форума и не несут пользы для читателей.
Хочу отметить, что публикации pmle не противоречат этим правилам.
Будьте вежливы и терпимы друг к другу. Ведите дискуссию в конструктивном русле.
-
Надеюсь записи встречи будут, ведь аналитики не только в Москве водятся.
А тема действительно интересная
присоединяюсь к пожеланию
-
По данной теме я встану на сторону Дениса. Не в том смысле, что не люблю инструменты, а в том, что сперва, нужно иметь хорошее представление об изменениях, а только потом надеяться на инструменты.
Из своего опыта могу сказать след.:
1. Качество проработки изменения напрямую зависит от ваших знаний о системе, в которую изменения вносятся. Если не знаете систему, то первой обязанностью является изучать её на высоком уровне, а только потом изменять. В реальной ситуации может не быть возможности достаточно глубоко погрузиться (особенно в начале проекта), но держать в голове приоритет изучения системы нужно всегда.
2. Если вы не достаточно хорошо знаете систему, то полагаться на документацию нужно с оглядкой на то, что она может не соответствовать коду, быть неполной и некачественной. Очень часто именно так и бывает. В первую очередь, изменения влияют на живое тело проекта, т.е. на его код. Иными словами, оперировать нужно по телу, а не по мед.карте, а вся ответственность за жизнь пациента на вас. Поэтому, при анализе влияния изменений нужно проявлять максимальную дотошность к текущему фактическому состоянию системы. Аналитик вообще её должен всегда проявлять. Кажется, что это окупается с лихвой.
(Немножко оффтоп) 2.1 Купер сравнивает изменения ПО с рубцом после операции. Большое количество рубцов приводит к потере гибкости и хрупкости организма. Хорошо проработанные изменения отличаются не только полным описанием влияния, но и тем, что они стремятся к уменьшению количества рубцов в перспективе. Я не могу сказать, что всегда получается этому следовать, но держать это в голове тоже стоит.
3. Изменения в больших системах подразумевает правку кода в куче мест сразу. Поэтому, на большие изменения можно писать отдельный документ. Может не всегда нужно это делать, но если не уверены в качестве анализа влияния, то можно подсунуть команде на ревью.
Я видел ситуации, когда даже сами разработчики затрудняются оценить последствия изменения для системы. Это вполне может встретиться на больших проектах. Я никогда не видел ситуации, чтобы команда ругала отдельный документ на большие изменения. Кажется, он всем нравится. В любом случае, документ - это выражение вашей осмысленной работы над изменением.
Есть другой вариант. Если все спецификации содержатся в одном большом документе, то в качестве документа об изменении можно использовать diff версий(например - tfs + share point.wiki). Если по проекту несколько спецификаций, то нужно обеспечит так, чтобы изменения во всех документах можно было просмотреть в одном месте. Не следует разработчикам заставлять лазить по куче разрозненных документов. Велика вероятность, что кто-нибудь что-нибудь да пропустит ...
Лично мне нравится для изменения дополнительно описывать причину, источник, и ещё пару параметров.
Ещё мне нравится CR(change request) из той же самой DOORS. Видео можно на youtube найти.
4. Для изменений на больших данных с большой динамикой изменения стоит продумывать пути отступления. Это может и не очень частая ситуация, но стоит держать в голове гипотетическую ситуацию неотката.
5. Нужно выбросить из головы идею о том, что какой-либо инструмент когда-нибудь защитит от "человеческого фактора на 100%" в плане анализа влияния изменений. Дело в том, что человеческий фактор начинается с момента внесения требований в это самый инструмент. Если внесены кривые, неполные и неактуальные требования, то инструмент не поможет в любом случае.
6. Иногда изменения затрагивают большое количество чужих подсистем. Для таких случаев полезно иметь актуальные dfd или деплоймент диаграммы или диаграммы компонентов или спеки по интеграции. В любом случае, если вы знаете что, с вашей системой / подсистемой связана другая чужая, то всегда следует проверить возможное влияние на ней.
Я умышленно ушел в сторону от вопроса инструментов. Считаю, что начинающий аналитик должен работать над содержанием и пониманием. Выработать свой стиль изложения и понять что хорошо, а что плохо. Для этого ворд подходит лучше. Он не создает рамок. Инструменты загоняют в рамки различных best practice. Само по себе это не плохо, но всему свое время. Надо научиться видеть картину сверху, чтобы потом суметь адаптировать свой подход к изменениям в любой команде и к любому инструменту. Кажется, это будет универсально.
Обещать не буду, но может поищу материалы, которые сойдут за гайдлайны по изменениям.
Простите если кого утомил. многобуков. Не сдержался :-\
-
Я умышленно ушел в сторону от вопроса инструментов. Считаю, что начинающий аналитик должен работать над содержанием и пониманием. Выработать свой стиль изложения и понять что хорошо, а что плохо. Для этого ворд подходит лучше.
А почему ворд? Давайте уж сразу - чернила и бумага . А лучше пергамент. Но не перебарщивать - заставлять новичков высекать диаграммы на скалах не будем. Но вменим в обязанность непременное изучение каллиграфии. Годам к 150 из них получатся отличные аналитики. Жаль только не каждый доживет до момента принесения практической пользы....
Он не создает рамок. Инструменты загоняют в рамки различных best practice.
Инструменты ориентированы на методологии. Чтобы обьяснить тот же IDEF0 при формировании функциональных требований достаточно один раз нарисовать процесс на бумаге - если попытаться применить эту технологию на практическом примере, аналитик тупо упрется в недостаток времени на разработку любых моделей кроме наивных.
-
По данной теме я встану на сторону Дениса. Не в том смысле, что не люблю инструменты, а в том, что сперва, нужно иметь хорошее представление об изменениях, а только потом надеяться на инструменты.
Антон, конечно, Вы можете иметь свое мнение от прочитанной Вами дискуссии. Только мне, например, совершенно непонятно откуда возник этот тезис о первичности инструмента или о том, что существует инструмент, который решает все ваши проблемы волшебным образом. Если такой инструмент появится, то и специалист в этой области не понадобиться. Будем надеяться, что этого не случиться. Хотя искусственный интеллект развивается :)
-
А почему ворд?
"дабы дурь каждого видна была" (c)
Давайте уж сразу - чернила и бумага.
И так бывает. Не сказать, чтобы редко. Общаться езжу обычно с блокнотиком или вообще налегке - лист бумаги и ручку найти не проблема где угодно.
А лучше пергамент.
А где взять?
Но не перебарщивать - заставлять новичков высекать диаграммы на скалах не будем.
Правильно. Ни к чему их под Административный Кодекс подводить.
Но вменим в обязанность непременное изучение каллиграфии.
Кстати, многие японцы, посвятившие жизнь боевым искусствам, параллельно ей занимаются. Ибо много общего.
Годам к 150 из них получатся отличные аналитики. Жаль только не каждый доживет до момента принесения практической пользы....
Другое дело какой-нибудь ЕА: скачал, поставил - и сразу же твори нетленку.
. . .
Извините, не смог пройти мимо без шутки. )
-
"дабы дурь каждого видна была" (c)
В модельках она еще лучше проявляется:)
И так бывает. Не сказать, чтобы редко. Общаться езжу обычно с блокнотиком или вообще налегке - лист бумаги и ручку найти не проблема где угодно.
Это ж интервьюирование - совсем другая тема. Тут любые средства хороши для получения информации - и блокнотик, и пассатижи...
Кстати, многие японцы, посвятившие жизнь боевым искусствам, параллельно ей занимаются. Ибо много общего.
И я про то. Если стоит задача организовать тоталитарную секту аналитиков, то только каллиграфия. Никаких компьютеров :)
Другое дело какой-нибудь ЕА: скачал, поставил - и сразу же твори нетленку.
Не вижу я ничего плохого в том, что bizagi не даст пустить поток сообщений внутри пула, Bpwin проверит декомпозицию, а EA не позволит соединить что-угодно с чем угодно. От каких то грубых ошибок инструмент убережет срозу, от ошибок потоньше уберегут шаблоны , примеры и модели коллег.
Другое дело, что наличие инструмента совершенно никак не влияет на необходимость собственно обучения . Причем у рабочего наставника. И с этой точки зрения лучше наставник с вордом, чем такой же новичек с EA.
-
В модельках она еще лучше проявляется:)
Мне текст больше нравится. Половина "аналитегов" по одной-две ошибки на предложение лепят. Ну а чо, и так же все понятно? Это не говоря уже об осмысленности написанного. А вот модельки не так очевидны. Спасибо инструментарию, который не дает сразу выстрелить себе в ногу.
Это ж интервьюирование - совсем другая тема. Тут любые средства хороши для получения информации - и блокнотик, и пассатижи...
Не, не интервьюирование. Не люблю я это длинное слово. Я пообщаться хожу. Поговорить за жизнь производственную и организационную, за проблемы в ней, за чаяния душевные. Попутно почеркать себе что-нибудь на память.
Не вижу я ничего плохого в том, что bizagi не даст пустить поток сообщений внутри пула...
Ну как сказать... Оно с одной стороны неплохо. С другой, оно способно продлить жизнедеятельность генетически неприспособленного к такой работе тела до такой стадии, когда тело придумает, как обойти глупые ограничения и проявить себя во всей красе. А чем позже, тем дороже как правило.
-
Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559
-
Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559
При просмотре не покидал вопрос: а так ли ценен документ как структура хранения требований, что за него нужно бороться?
Можно ли разрабатывать требования не ставя в качестве конечной цели получение документа?
-
При просмотре не покидал вопрос: а так ли ценен документ как структура хранения требований, что за него нужно бороться?
Можно ли разрабатывать требования не ставя в качестве конечной цели получение документа?
Я считаю, что можно и нужно разрабатывать требования, не ставя в качестве конечной цели получение документа. То, что документы для нас так важны - это наша специфика и вопрос привычки, а так же отсутствие удобных средств для всех нужных нам действий, с которыми справляется Word.
И не согласна с утверждением, что документ - структура хранения требований, для нас это структура визуализации, представления требований. Инструментом хранения для нас там, где используется, всегда является ЕА.
-
Я считаю...
Редкий случай, когда хочется полностью подписаться под сказанным.
А документ... Документ - это самое надежное, самое долговечное и самое неприхотливое средство визуализации информации о системе, которое только можно придумать. Особенно в бумажной форме. К тому же - довольно дешевое (речь про документы, подготовленные людьми для людей, про остальные случаи утверждать не берусь).
Бумажный документ не требует никаких технических средств для применения по назначению, ему безразличны форматы хранения данных, совместимость версий ПО для просмотра (и стоимость их приобретения), долговечность носителя и т.д., и т.п. Он "всегда готов".
Поэтому, на мой взгляд, документы еще долго будут в цене, не являясь по сути конечной целью.
-
Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559
Испытывал очень сильные душевные волнения во время просмотра. Три года назад пытался реализовать схожие подходы на ЕА. Тогда не хватило опыта, сил, ума и я думал, что это всё плод моих перфекционистских фантазий и на практике мало осуществимо, дорого и никому не нужно. Эти видео подтверждают, что я шел в правильном направлении. Спасибо команде касперского. Это очень ценно!
-
Я считаю, что можно и нужно разрабатывать требования, не ставя в качестве конечной цели получение документа. То, что документы для нас так важны - это наша специфика и вопрос привычки, а так же отсутствие удобных средств для всех нужных нам действий, с которыми справляется Word.
И не согласна с утверждением, что документ - структура хранения требований, для нас это структура визуализации, представления требований. Инструментом хранения для нас там, где используется, всегда является ЕА.
+1
А документ... Документ - это самое надежное, самое долговечное и самое неприхотливое средство визуализации информации о системе, которое только можно придумать. Особенно в бумажной форме. К тому же - довольно дешевое (речь про документы, подготовленные людьми для людей, про остальные случаи утверждать не берусь).
Бумажный документ не требует никаких технических средств для применения по назначению, ему безразличны форматы хранения данных, совместимость версий ПО для просмотра (и стоимость их приобретения), долговечность носителя и т.д., и т.п. Он "всегда готов".
Поэтому, на мой взгляд, документы еще долго будут в цене, не являясь по сути конечной целью.
+1
Я полагаю, что у формального документа требований основное предназначение это "поиск ошибок на ранней стадии" и "управление проектом". Для управления удобней представление в трекере (любом), для поиска ошибок... Кому как, но для меня бумажный вариант наиболее предпочтителен.
-
Поэтому, на мой взгляд, документы еще долго будут в цене, не являясь по сути конечной целью.
Возможно не так долго, как кажется.
У Юлии Мадорской есть отличное сравнение процесса перехода разработки требований в виде бумажки (пусть даже электронной) с ведением БАЗЫ требований в инструментарии с переходом от бумажного проектирования к autocad.
http://edu.reqcenter.pro/?p=4500
Теперь чертежи на бумаге практически не печатаются (ну разве уж совсем в экзотических организациях). Ясно, что никто не будет изучать автокад, для того чтобы узбекам на даче обьяснить, где ставить сарай, но не более чем. Даже любители и то скачивают какие-нибудь редакторы или пользуются облачными сервисами для отрисовки планировок.
И произошло это лет за 10, не больше. Так и с документами требований - в ближайшее время они займут свое место рядом c теплым ламповым звуком, тканями с натуральными красителями и прочим винтажом.
-
Появление CAD-систем действительно сопровождалось значительной скоростью перехода на них проектных организаций.
Я вижу причины в том, что 3-хмерные модели физических объектов действительно удобны в работе, т.к. в своих проекциях на экране дают наглядное представление о себе.
С другой стороны, у софта и ИС нет никакой истинной 3D-формы, которая была бы легко постижима человеком. Поэтому модель софта и ИС остаётся ментальной конструкцией, которую каждый участник строит в своей голове по проекциям — будь-то диаграммы процессов, структуры.
Документ (бумажный или электронный) по сути даёт 2,5D-модель, т.к. показывает, в каком порядке эту модель собирать в голове.
Так что для учёта и управления электронные таблицы конечно эффективнее, а вот для проектирования по крайней мере простых систем повода для стремительного замещения только специализированным софтом пока нет. Т.к. этот софт всё равно не может продемонстрировать целостный образ создаваемого софта/системы, а лишь помогает в техническом контроле совмещения проекций (диаграмм, реестров).
-
"Я так вообще не фанат никакого ПО (а скорее открытых систем как класса)"
Денис, а можете поподробнее рассказать, почему?
Потому что в большинстве случаев проблемы в качестве анализа возникают не из-за неприменения инструментов, а из-за невладения техниками работы с требованиями:
1. не учли всех ключевых заинтересованных лиц (как тут поможет ПО?)
2. записали хотелки заказчика как есть, не выяснив реальных проблем (как тут поможет ПО?)
3. не понаблюдали за реальной работой реальных пользователей (как тут поможет ПО?)
4. не обнаружили конфликта невысказанных интересов (как тут поможет ПО?)
5. навязали заказчику свои фичи или технологии (как тут поможет ПО?)
Т.е. у большинства аналитиков и сочувствующих нет работающей эффективной технологии выполнения аналитико-проектных работ и попытки обращаться к инструментам выглядят карго-культом.
-
Потому что в большинстве случаев проблемы в качестве анализа возникают не из-за неприменения инструментов, а из-за невладения техниками работы с требованиями:
1. не учли всех ключевых заинтересованных лиц (как тут поможет ПО?)
2. записали хотелки заказчика как есть, не выяснив реальных проблем (как тут поможет ПО?)
3. не понаблюдали за реальной работой реальных пользователей (как тут поможет ПО?)
4. не обнаружили конфликта невысказанных интересов (как тут поможет ПО?)
5. навязали заказчику свои фичи или технологии (как тут поможет ПО?)
Это задачи старшего (ведущего) аналитика, методолога, а вовсе не начинающего. И помочь решать эти вопросы ничего, кроме человека с опытом не поможет. А опыт этот в свою очередь - кладбище загубленных проектов или наоборот успешных.
К вопросу - инструментарий или word имеет самое косвенное отношение. Совершенно непонятно, почему вместо критерия , оценивающего практический опыт аналитика вводится критерий владения/не владения инструментарием.
Почему от этих ошибок должен уберечь опыт технического писательства?
-
Это задачи старшего (ведущего) аналитика, методолога, а вовсе не начинающего.
Это вообще были не задачи, а ситуации, связанные с реализацией рисков. И кто писал про начинающего?
И помочь решать эти вопросы ничего, кроме человека с опытом не поможет. А опыт этот в свою очередь - кладбище загубленных проектов или наоборот успешных.
Т.е. вы считаете, что этот опыт не может быть формализован ни в какие чеклисты, шаблоны, технологию? Я считаю — может.
К вопросу - инструментарий или word имеет самое косвенное отношение.
ничего не понял. word – тоже инструмент.
Совершенно непонятно, почему вместо критерия , оценивающего практический опыт аналитика вводится критерий владения/не владения инструментарием.
мне тоже непонятно, о чём вы тут пишете. Кем вводится? Куда вводится? Когда вводится? Где вводится?
Умение выражать знания с чётким выделением действующего лица — важнейший навык аналитика.
-
Почему от этих ошибок должен уберечь опыт технического писательства?
При чём тут техническое писательство?
Я о чём писал выше? Конкретные ситуации, связанные с реализацией рисков, могут быть превращены в инструкции и шаблоны по их предотвращению. Это будет набор правил, руководств к действию, никак не связанных с работой технического писателя.
-
Ещё раз — меня не интересует выбор 1) Word или 2) CASE-средства.
Я говорю о выборе аналитика, во что инвестировать своё время — А) в освоение новых инструментов или Б) в освоение технологий выполнения аналитических и проектных работ. Я считаю, что окупаемость от Б-варианта гораздо выше, чем А.
-
Это вообще были не задачи, а ситуации, связанные с реализацией рисков. И кто писал про начинающего?
Устранение этих рисков и есть задача старшего (ведущего) аналитика. Если начинающий аналитик работает с явной информацией, то задача старшего в группе - устранение неявных рисков. Именно в силу его опыта.
Т.е. вы считаете, что этот опыт не может быть формализован ни в какие чеклисты, шаблоны, технологию? Я считаю — может.
На 100% нет. Есть вещи, которые в технологию не транслируются. Чуйка, интуиция.
ничего не понял. word – тоже инструмент.
С некоторым допущением что-угодно можно считать чем угодно. И карандаш инструмент. И долото для наскальных рисунков тоже.
Чтобы избавить дискуссию от упражнений в схоластике предлагаю считать инструментом средство , которые требования сохраняет в структурированном виде в базе данных.
-
… в схоластике предлагаю считать инструментом средство , которые требования сохраняет в структурированном виде в базе данных.
уууу, это порождает другие проблемы. является ли XML базой данных? но не будем.
-
Я говорю о выборе аналитика, во что инвестировать своё время — А) в освоение новых инструментов или Б) в освоение технологий выполнения аналитических и проектных работ. Я считаю, что окупаемость от Б-варианта гораздо выше, чем А.
Вы уверены, что A и Б никак не взаимосвязаны? Что инструменты не создают предпосылки для новых технологий, а технологии не определяют необходимость в тех или иных инструментах?
-
Вы уверены, что A и Б никак не взаимосвязаны? Что инструменты не создают предпосылки для новых технологий, а технологии не определяют необходимость в тех или иных инструментах?
А где я говорил, что они не связаны? я о том, что окупаемость инвестиций в освоение практик в общем случае выше, чем от инвестиций в освоение кнопочек в инструментах.
-
уууу, это порождает другие проблемы. является ли XML базой данных? но не будем.
Предлагаю считать - xml однозначно конвертируется в реляционную СУБД и наоборот. Например bpm, bpmc, основанные на xml, поддерживает bizagi modeler (хотя bizagi suite работает с СУБД)
-
Предлагаю считать - xml однозначно конвертируется в реляционную СУБД и наоборот. Например bpm, bpmc, основанные на xml, поддерживает bizagi modeler (хотя bizagi suite работает с СУБД)
ну вооот. а теперь давайте посмотрим, в чём хранит документ Word
-
А где я говорил, что они не связаны? я о том, что окупаемость инвестиций в освоение практик в общем случае выше, чем от инвестиций в освоение кнопочек в инструментах.
Если они связаны, значит освоение практик надо дополнять освоением кнопочек. А освоение кнопочек изучением методик. Одно без другого не имеет смысла, а соотношение ингредиентов не так важно.
В чем смысл этого противопоставления?
-
В чем смысл этого противопоставления?
в том, что я регулярно вижу попытки людей искать там, где светло (инструменты), а не там, где потеряли (методики).
-
в том, что я регулярно вижу попытки людей искать там, где светло (инструменты), а не там, где потеряли (методики).
Нормальный процесс развития. Если не знаешь ни методик, ни инструмента, то неважно с чего начинать.
Сразу все не охватишь, начинаешь с того, что проще. Если что не так, то понимание приходит быстро по практическим результатам.
-
ну вооот. а теперь давайте посмотрим, в чём хранит документ Word
Docx - это упакованный xml.
https://habrahabr.ru/post/138666/ (https://habrahabr.ru/post/138666/)
Но свойства этого формата используются только для отражения форматирования текста.
Весь текст размещается в тэгах типа
<w:t>{TEXT}</w:t>
При этом конструкций, отражающие семантические связи, между тэгами нет.
А если брать тот же xpdl или bpel, то они вообще исполняемы с помощью интерпретатора.
Тем не менее в критерий инструмент/не инструмент надо внести уточнение. Речь нужно вести не просто о базе данных как о атрибуте СУТ, а именно о репозитарии.
-
Нормальный процесс развития.
Для анекдота.
Если не знаешь ни методик, ни инструмента, то неважно с чего начинать.
Обычно перед тем, как приступить к практике, изучают теорию. Как минимум - технику безопасности.
Но если учить некому, опыта обучения вообще чему бы то ни было нет, даже пословицы вроде "не зная броду..." неизвестны - тогда да, начинать можно откуда угодно. Выжившие, возможно, чему-нибудь научатся.
Сразу все не охватишь, начинаешь с того, что проще. Если что не так, то понимание приходит быстро по практическим результатам.
А искать проще там, где светло. То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора ("да лан, не подкалывай - это же синонимы!").
И практические результаты у них соответствующие. Но "инструментально" они на высоте, и этого им вполне достаточно (тем паче, что работодатель впечатлен и з/п платит изрядную).
-
А искать проще там, где светло. То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора
Я не хочу вступать в защиту аналитиков, которые не знают разницы между справочником и классификатором. Но я хочу сказать, что это не то, что приводит к наиболее серьезным и классическим проблемам на проекте.
А вот неумение нормально работать на этапе выявления зл / требований (elicitation по Вигерсу) приводит действительно к серьезным долгоиграющим проблемам на проекте или в продукте. Кажется, что аналитиков с высоким скилом выявления мне встречалось гораздо меньше тех, которые знают «разницу между справочником и классификатором».
С другой стороны, не встречал ситуаций, когда знание «разницы между справочником и классификатором» спасало бы проект, от фатальных ошибок на этапе «выявления».
2 Humbert
Этап выявления в проекте идет всегда вообще самым первым и базируется на большим количестве методик. Именно методики, а не инструменты рулят на этом этапе.
PS
Предположу (опираясь на то, что я видел и знаю об аналитике в заказной разработке в РФ), что основная проблема у нас в проявлении нигилизма к «выявлению».
С одной стороны, никто не хочет инвестировать в «выявление».
С другой, когда проект завален или «условно успешен», все проблемы объясняются «неадекватным заказчиком», «недостаточным бюджетом», «слабым менеджментом», но никто никогда не говорит что «мы мало времени уделили выявлению требований или у нас были проблемы в методиках выявления».
-
Но я хочу сказать, что это не то, что приводит к наиболее серьезным и классическим проблемам на проекте.
Это просто пример про "общую", а не "инструментальную" квалификацию.
Кстати, о практике. У меня на глазах из-за непонимания этой разницы на два дня уронили серьезную федеральную систему. Потом ручками подняли, и пару месяцев командой переделывали за свой счет. "Классическая" это проблема или нет, утверждать не возьмусь. Но однозначно проблема.
-
Кстати, о практике. У меня на глазах из-за непонимания этой разницы на два дня уронили серьезную федеральную систему. Потом ручками подняли, и пару месяцев командой переделывали за свой счет. "Классическая" это проблема или нет, утверждать не возьмусь. Но однозначно проблема.
Не "Платон" часом ?
-
Кстати, о практике. У меня на глазах из-за непонимания этой разницы на два дня уронили серьезную федеральную систему. Потом ручками подняли, и пару месяцев командой переделывали за свой счет. "Классическая" это проблема или нет, утверждать не возьмусь. Но однозначно проблема.
Ни как не могу себе представить, как должен должен выглядеть весь процесс разработки, чтоб «незнание разницы между классификатором и справочником» приводило к падению системы на 2 для + реворк на 2 месяца … Я не пытаюсь подвергнуть сомнению Ваши слова, но просто пытаюсь представить.
-
Не "Платон" часом ?
Нет, у гайцов лет 5 назад.
Ни как не могу себе представить, как должен должен выглядеть весь процесс разработки,
Да как везде. Просто имело место сочетание сразу нескольких факторов: сроки жали, часть проектирования поручили архитектору, а тот перепоручил программистам, квалифицированными кадрами проверить уже не успевали. В смысле, проверить бы еще успели (если бы удалось заставить программистов описать содеянное), а вот переделать - нет.
Ну ничего, как гласит известный афоризм, "Чтобы сделать работу как следует, времени всегда не хватает; но на то, чтобы ее переделать, время находится".
-
Просто имело место сочетание сразу нескольких факторов: сроки жали, часть проектирования поручили архитектору, а тот перепоручил программистам, квалифицированными кадрами проверить уже не успевали.
Ну, да. Программисты случайно техподдержке не перепоручили техподдержке потренироваться в кодинге? Ну чтобы совсем определиться с тем, насколько вредно знание инструментальных средств для начинающих аналитиков.
То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора ("да лан, не подкалывай - это же синонимы!").
А джира какое имеет отношение к инструментарию аналитика? Это багтрекер - инструмент техподдержки. Может даже инструмент управления требованиями, но уж никак не их разработки.
Не годятся примеры совсем. Был бы это пример аналитика, умеющего прекрасно строить IDEF0 в bpWin, но абсолютно не понимающего в анализе... Вот тогда бы я усомнился в том, что хороший уровень владения инструментарием может быть получен без хорошего уровня владения методологией.
Если человек серьезно подходит к изучению инструментария, то он и про теорию не забудет.
При этом хочу подчеркнуть, что не считаю инструментарий самоцелью. Просто пришло уже такое время, что без инструментария можно только совсем примитивными проектами заниматься. А на серьезных проектах сразу столько всего наваливается, что без хорошего инструментария ни по качеству, ни по срокам ничего путного сделать.
Это как учет на бумажке вести или в ERP. Причем если EA с точки зрения управления требованиями - это что-то типа 1С ранних версий, то тот же Cradle - это SAP.
Думаю в ближайшее время уровень СУТ может выйти вообще на принципиально новый уровень, так как именно СУТ является идеальной площадкой для применения искусственного интеллекта. Мне понравилась идея Юлии Мадорской рассматривать матрицу трассировки как онтологическую модель. Если посмотреть на Loader из состава Cradle, который обеспечивает бесшовную интеграцию между документальным представлением требований и их репозитарием в Cradle, то легко увидеть, что следующим шагом будет семантический разбор нормативной и документальной базы проекта, автоматическое формирование глоссариев и онтологий, автоматическая викификация загружаемых документов.
При таких тенденциях заниматься разработкой требований без серьезного инструментария будет невозможно - по сути разработка сведется к согласованию онтологий предметной области и разрабатываемой системы.
-
А на серьезных проектах сразу столько всего наваливается, что без хорошего инструментария ни по качеству, ни по срокам ничего путного сделать.
Да, вы расскажите пожалуйста, что именно на вас наваливается.
-
Да, вы расскажите пожалуйста, что именно на вас наваливается.
На данный момент меня интересуют механизмы быстрой формализации предметной области.
Достаточно заказчику в конкурсную документацию вставить ссылку на какой-либо нормативный документ, этот документ должен быть учтен. Зачастую этот документ может относится к совершенно неизвестной предметной области и при этом он может быть достаточно большим. С этим наверняка сталкивались те аналитики, которые работали по межведомственным госзаказам, а уж при межгосударственных проектах встает еще проблема языка и отличающегося национального законодательства. Понятно, что эта проблема решается привлечением предметников, субподрядчиками и пр. Но ведь даже чтобы выстроить грамотно кооперацию по проекту, все равно желательно выделить основные термы этой предметной области, понять их взаимосвязь - просто для того, чтобы начать кого-то искать и договариваться.
Других способов для решения этой проблемы кроме использования того же ИИ я не вижу.
-
На данный момент меня интересуют механизмы быстрой формализации предметной области.
Достаточно заказчику в конкурсную документацию вставить ссылку на какой-либо нормативный документ, этот документ должен быть учтен. Зачастую этот документ может относится к совершенно неизвестной предметной области и при этом он может быть достаточно большим. С этим наверняка сталкивались те аналитики, которые работали по межведомственным госзаказам, а уж при межгосударственных проектах встает еще проблема языка и отличающегося национального законодательства. Понятно, что эта проблема решается привлечением предметников, субподрядчиками и пр. Но ведь даже чтобы выстроить грамотно кооперацию по проекту, все равно желательно выделить основные термы этой предметной области, понять их взаимосвязь - просто для того, чтобы начать кого-то искать и договариваться.
Других способов для решения этой проблемы кроме использования того же ИИ я не вижу.
Согласен, что задача автоматизации разбора документов важная и нужная.
Напомню, что есть инструменты, которые уже много лет помогают в ручном разборе (например, избавляют от копипаста и помогают контролировать проход по документу), типа https://www.visual-paradigm.com/tutorials/textualanalysis.jsp
Я бы предложил не ждать милостей у природы, а самим взять их у неё.
В смысле, например, разработать плагин для Google Docs, который будет делать базовый разбор текста.
Найдётся у вас время для такой работы?
-
Напомню, что есть инструменты, которые уже много лет помогают в ручном разборе (например, избавляют от копипаста и помогают контролировать проход по документу), типа https://www.visual-paradigm.com/tutorials/textualanalysis.jsp
Спасибо за ссылку. Идея отличная, но не уверен, что она получила широкое практическое применение. Вообще не вижу перспектив за продуктами типа confluence и плагинов к нему. Это безусловно лучше, чем word, но все равно не заменит "тяжелой" технологической системы.
А такие мелкие сервисы типа вышеописанного очень капризны к качеству подготовки текста, установлению связей с другими такими текстами. Не очень понятно, как скажем при появлении второго документа заставить использовать элементы из репозитория?
Я бы предложил не ждать милостей у природы, а самим взять их у неё.
В смысле, например, разработать плагин для Google Docs, который будет делать базовый разбор текста.
Разбор текста для чего? Лексических и семантических анализаторов как собак нерезанных. Писать их в научном плане крайне приятно - лет двадцать тому назад так приятно было свои языки и компиляторы писать. Один из наиболее качественных анализаторов у ABBYY например. Поставляются они и в виде готовых решений, и библиотек. Так что средств, которые могут хапнуть кучу документов, расчитатать по ним семантические метрики, откластеризовать и построить разного вида представления, характеризующие семантические связи по этим документам как грязи. Вопрос в том, как это провязывать к технологической системе. Так что к проблеме надо заходить со стороны СУТ. Причем такой тяжелой и правильной типа Cradle.
Самое обидное, что тот же 3SL двинулся во вполне правильном направлении в Loader. Они word файлы распаковывают, а xml пишут в базу. То есть разобранный документ они из базы обратно легко восстанавливают в первоначальном виде (что кстати довольно прикольно - родной микрософтовский sharepoint хранит вордовые файли как бинарные обьекты и попыток не делает их распаковать и проанализировать, хотя я думаю можно было бы с этого разные сервисы приятные поиметь) . Но при этом лексической единицей у Loader остается абзац - по вордовому форматированию Loader устанавливает иерархию этих абзацев, а в итоге иеррархию требований.
Соответственно сравнивая абзацы новых вернсий документов Loader понимает изменение требований. Но например в случае, если это не просто новая версия документа, а другой документ из той же ПО, но по другому оформленный, понимаение изменений возможно только в ручном режиме.
А вот если иметь семантический граф или онтологию, то понимание изменений возможно даже на неоднородных источниках
-
Ну, да. Программисты случайно техподдержке не перепоручили техподдержке потренироваться в кодинге?
Вряд ли. На них "вертикаль власти" заканчивалась.
Ну чтобы совсем определиться с тем, насколько вредно знание инструментальных средств для начинающих аналитиков.
Я где-то утверждал, что знание инструментария вредно? Если нет - зачем Вы это пишете?
На всякий случае еще раз: вредно ставить изучение инструментария впереди собственно аналитической работы.
А джира какое имеет отношение к инструментарию аналитика? Это багтрекер - инструмент техподдержки. Может даже инструмент управления требованиями, но уж никак не их разработки.
Вы спросили, Вы ответили.
Не годятся примеры совсем. Был бы это пример аналитика, умеющего прекрасно строить IDEF0 в bpWin, но абсолютно не понимающего в анализе...
И такое встречалось. UMLки рисовал - заглядение, но вот смысл их был крайне мутным. Без доработки напильником обычно не обходилось. Зато прекрасно знал назначение каждой закорючки и штришка в языке. Куда лучше меня.
Просто пришло уже такое время, что без инструментария можно только совсем примитивными проектами заниматься.
Ну, значит я реликт. Со своим вордом, блокнотом и джирой(иногда). Проекты-то не сказать, чтобы примитивные.
Думаю в ближайшее время уровень СУТ может выйти вообще на принципиально новый уровень, так как именно СУТ является идеальной площадкой для применения искусственного интеллекта.
СУТ - это система управления требованиями? Так она же к инструментарию аналитика вообще и разработке требований в частности отношения не имеет? (с)
по сути разработка сведется к согласованию онтологий предметной области и разрабатываемой системы.
И все, аналитиков можно из проектных команд исключать.
Я примерно такие же слова уже лет 15 слышу в отношении автоматической генерации кода. С периодической демонстрацией какого-нибудь суперинструмента. Но пока все так, как есть.
Других способов для решения этой проблемы кроме использования того же ИИ я не вижу.
Ну... Некоторые чудаки все еще используют ЕИ. Естественный, в смысле.
-
Разбор текста для чего?
Для того, чтобы выявить объекты и субъекты, онтологию, контексты-условия применения, правила поведения (потенциальные функции системы) и связку.
Например, из строки «Индвидидуальные предприниматели, ведущие деятельность на основании патента, обязаны сдать отчётность в срок не позже 4 мая текущего года» можно вытащить автоматически в словари-таблицы:
1. Субъект с уточнением — "ИП, ведущий деятельность на основании патента"
2. Объект — "отчётность"
3. Правило поведения — "сдать"
4. Правило-ограничение поведения — "до 4 мая"
5. Связка = 1 + 2 + 3 + 4
Потом можете эти словари загрузить куда угодно, т.к. первичный разбор сделан.
-
Для того, чтобы выявить объекты и субъекты, онтологию, контексты-условия применения, правила поведения (потенциальные функции системы) и связку.
Например, из строки «Индивидуальные предприниматели, ведущие деятельность на основании патента, обязаны сдать отчётность в срок не позже 4 мая текущего года» можно вытащить автоматически в словари-таблицы:
1. Субъект с уточнением — "ИП, ведущий деятельность на основании патента"
2. Объект — "отчётность"
3. Правило поведения — "сдать"
4. Правило-ограничение поведения — "до 4 мая"
5. Связка = 1 + 2 + 3 + 4
Потом можете эти словари загрузить куда угодно, т.к. первичный разбор сделан.
Не готов дать экспертизу, но это сильно отличается от обычного применения анализаторов (по крайней мере то, что видел я). Судя по примеру, текст далеко не естественный, нам нужно уметь отличать эти самые уточнения, понимать, что это не просто какие-то буковки, а "правило-ограничения"....
Обычно результаты семантического анализа выглядят по другому. То есть анализаторы найдут и выделят текстах:
ИП,деятельность, основания ,патент,отчетность, май
выделят отношения
ИП-деятельность -> вести
ИП-отчетность -> сдавать
итд
А что если нам что-то типа круглого стола организовать с ИИшниками, чтоб нам спецы рассказали, что можно, а что нельзя ?
"Возможности применения семантического анализа для неструктурированных описаний и онтологического анализа для структурированных описаний требований"
-
Вряд ли. На них "вертикаль власти" заканчивалась.
Я где-то утверждал, что знание инструментария вредно? Если нет - зачем Вы это пишете?
Ну и я не утверждал, что главное - инструмент, пофигу методики.
На всякий случае еще раз: вредно ставить изучение инструментария впереди собственно аналитической работы.
Это абсолютно нормальная последовательность:
1) Изучение инструмента
2) Выполнение аналитической работы с помощью инструмента
Несоблюдение этого принципа в аналитической работе чревато тем же, чем и в любой другой. Чтоб не получилось как у токаря, который знает свой станок как все свои два пальца...
Но это совсем не значит , что я считаю, что на методики надо забить. Они точно такой же инструмент, технология его использования.
Ну, значит я реликт. Со своим вордом, блокнотом и джирой(иногда). Проекты-то не сказать, чтобы примитивные.
Леонид, мне кажется Вы кокетничаете. Понятно что с Вашим опытом и компетенцией Вам может и джира иногда не нужна. С большой вероятностью и место в команде у Вас соответствующее, вовсе и не требующее от вас ничего, кроме блокнотика. Но примите во внимание, что Вы как специалист в другое время складывались. Специалист, который сейчас захочет расти , используя только блокнотик, в профессии может и не остаться.
СУТ - это система управления требованиями? Так она же к инструментарию аналитика вообще и разработке требований в частности отношения не имеет? (с)
Ну вот....Восстанавливаем:
А джира какое имеет отношение к инструментарию аналитика?
Может даже инструмент управления требованиями, но уж никак не их разработки
Из этих утверждений не следует:
1) Что джира является СУТ (утверждается , только что джира может использоваться для управления требованиями, но не утверждается, она является системой управления требованиями. Так же как не является СУТ ваш блокнот, хотя используя его, Вы вполне можете разрабатывать и управлять требованиями)
2) Что в любой СУТ обязательно должен отсутствовать механизм разработки требований. И EA, и Cradle это наглядно опровергают - и там , и там есть механизмы как разработки требований, так и управления ими.
Так что если и (с), то не мое.
И все, аналитиков можно из проектных команд исключать.
Я примерно такие же слова уже лет 15 слышу в отношении автоматической генерации кода. С периодической демонстрацией какого-нибудь суперинструмента. Но пока все так, как есть.
Позвольте не согласится с Вашим argumentum ad antiquitatem. У программистов сейчас не так , как было 30,20,10 лет назад. Их производительность труда по сравнению с программированием на машинных кодах сильно выросла, а появление новых инструментов не привело к исчезновению их профессии, а просто повысила уровень требований к создаваемым ими системам. И с аналитиками и инструментарием для них тоже самое.
Ну... Некоторые чудаки все еще используют ЕИ. Естественный, в смысле.
Опять же ИИ не предназначен замены ЕИ, а предназначен прежде всего для его усиления, для решения тех задач , которые ЕИ решить может и не в состоянии.
Ой, чтота мне бухгалтера 80х вспомнились с арифмометрами и счетами...
-
2 Humbert
Этап выявления в проекте идет всегда вообще самым первым и базируется на большим количестве методик. Именно методики, а не инструменты рулят на этом этапе.
Вы первый этап какого процесса имеете в виду? Создания ИС или информационного обследования? Если создания ИС , так собственно инструменты аналитика в своем большинстве на первом этапе и используются. В BPMN строим процесс, выявляем требования назначения и делаем описание обьекта автоматизации, в IDEF0 выявляем и фиксируем функциональные и нефункциональные требования. Ну и без инструментов разве только выявление целей и задач инструментов особых не требует, а все остальное совершенно незачем рисовать на ватманах...
-
Ну и без инструментов разве только выявление целей и задач инструментов особых не требует, а все остальное совершенно незачем рисовать на ватманах...
И тут есть мозговой штурм, вские брейнрайтинги,дерево целей, морфологически ящики Цвикки, диаграммы Исикавы, приницпы Парето и всякие приемы типа CATWOE и Н-метода, опять же Гольдратт с его подходами. Или это не считается инструментом?
-
Ну и я не утверждал, что главное - инструмент, пофигу методики.
Это абсолютно нормальная последовательность:
1) Изучение инструмента
2) Выполнение аналитической работы с помощью инструмента
Тем не менее, в нормальной последовательности им (методикам) места не нашлось.
Но это совсем не значит , что я считаю, что на методики надо забить. Они точно такой же инструмент, технология его использования.
Нет, не такой же. Вести осмысленную аналитическую работу с методиками, но без крадла можно, а вот наоборот - нет.
Леонид, мне кажется Вы кокетничаете.
Какие же деликатные собеседники на форуме. Я бы по-другому сказал. )
Но примите во внимание, что Вы как специалист в другое время складывались. Специалист, который сейчас захочет расти , используя только блокнотик, в профессии может и не остаться.
Равно как и тот, который использует все известные инструменты сразу.
Из этих утверждений не следует:
1) Что джира является СУТ (утверждается , только что джира может использоваться для управления требованиями, но не утверждается, она является системой управления требованиями.
Хех... То, что может использоваться как СУТ и используется как СУТ, скорее всего СУТ и является (как минимум, в рамках проекта). Что там в других местах - какая разница?
Гаечный ключ молотком де юре не является, но при должном энтузиазме и при отсутствии под рукой молотков, де факто очень даже.
У программистов сейчас не так , как было 30,20,10 лет назад. Их производительность труда по сравнению с программированием на машинных кодах сильно выросла
Соглашусь. Сейчас практически любой программист может "печатать со скоростью 1000 знаков в минуту". Многие доказывают это на практике.
, а появление новых инструментов не привело к исчезновению их профессии, а просто повысила уровень требований к создаваемым ими системам.
Я бы сказал, что повышение уровня требований к системам привело к появлению новых инструментов. Правда, доля программистов, способных с помощью этих инструментов создать что-то пригодное к эксплуатации имеет тенденцию к уменьшению. Доля среди общего числа программистов, в смысле. Но это совсем другой печальный вопрос.
И с аналитиками и инструментарием для них тоже самое.
Работа аналитика сильно отличается от "механистической" работы программиста. В последнем случае влияние инструментария гораздо важнее (хотя и не всегда имеет решающее значение). Так что "то же самое" не получится.
Опять же ИИ не предназначен замены ЕИ, а предназначен прежде всего для его усиления, для решения тех задач , которые ЕИ решить может и не в состоянии.
Вот так звучит гораздо лучше, чем в посте, где "Других способов для решения этой проблемы кроме использования того же ИИ я не вижу."
Ой, чтота мне бухгалтера 80х вспомнились с арифмометрами и счетами...
Не зря вспомнились, кстати. Имеют прямое отношение к обсуждаемому вопросу. Те бухгалтера ан масс гораздо лучше понимали суть проводимых операций, чем сегодняшнее "поколение 1С". Хотя "поколение 1С" может нашлепать куда больше проводок за единицу времени даже не приходя в сознание. С точки зрения бизнеса это хорошо: нужные операции проводятся, а кнопкодавы стоят дешево и меняются легко и непринужденно. Но вот вырасти в главбуха у ортодоксального кнопкодава шансов никаких.
-
В какую неожиданную сторону развилась тема! :)
Про ИИ хочу добавить (не в рамках рекламы, а в качестве распространения информации от IEEE):
В рамках 24th IEEE International Requirements Engineering Conference Sept. 12–16, 2016, Beijing, China (http://www.re16.org/)
состоится
Monday, September 12th, 2016:
WS01. AIRE: 3rd Intl Workshop on Artificial Intelligence for Req. Eng.
http://re.cs.depaul.edu/aire16/
Вероятно, если покопаться, то можно найти материалы предыдущих workshop'ов. В принципе, в рамках RE предыдущих годов возникали доклады на эту тему, если реально будут желающие, могу попробовать найти.
-
WS01. AIRE: 3rd Intl Workshop on Artificial Intelligence for Req. Eng.
http://re.cs.depaul.edu/aire16/
Вероятно, если покопаться, то можно найти материалы предыдущих workshop'ов.
Увы,не удалось обнаружить докладов предыдущего workshop'а.
Вообще судя по темам есть ощущение, что пока дело до конкретных реализаций применения ИИ в RE не доходит.
В принципе, в рамках RE предыдущих годов возникали доклады на эту тему, если реально будут желающие, могу попробовать найти.
Было бы замечательно. Вообще спасибо за ссылкы - даже не подозревал о наличии такой организации.
-
в рамках RE предыдущих годов возникали доклады на эту тему
Да, очень интересно. Но текстов докладов тут вроде нет, только программы:
2015 (http://re.cs.depaul.edu/aire15/program.html)
2014 (http://re.cs.depaul.edu/ai4re/program.html)
-
Григорий вот даже выступал "Analyst Days 2015. Почему UML — плохой выбор для обучения аналитиков"
https://www.webursitet.ru/trainer/grigorii-pechenkin.html
(https://image.slidesharecdn.com/uml-150221014851-conversion-gate02/95/uml-14-1024.jpg?cb=1425112363)
В коллекцию диаграмм, чтоб "чисто поржать". На моей планете не принято в таких случаях нарушать презумпцию и делать выводы об авторе диаграммы, о курсе-тренинге, который он рекламирует такой диаграммой, о школе, с которой он сотрудничает, о директоре этой школы и т. д.. Давайте просто поржём над диаграммой.
Ошибка студенческая.
-
Само пошутило, само поржало. ;D
Небезызвестный Kirill Fakhroutdinov считает, что это " typical misconception", что я перевожу на язык тутошней планеты как "популярные грабли".
(http://www.uml-diagrams.org/use-case-diagrams/use-case-business-error.png)
Кто в этот раз напишет "+100500 к граблям"? Вопрос риторический.
-
(https://image.slidesharecdn.com/uml-150221014851-conversion-gate02/95/uml-14-1024.jpg?cb=1425112363)
В коллекцию диаграмм, чтоб "чисто поржать". На моей планете не принято в таких случаях нарушать презумпцию и делать выводы об авторе диаграммы, о курсе-тренинге, который он рекламирует такой диаграммой, о школе, с которой он сотрудничает, о директоре этой школы и т. д.. Давайте просто поржём над диаграммой.
Ошибка студенческая.
Действительно, использование диаграммы вариантов использования здесь довольно сомнительно, поскольку закрепляет ответственности действующих лиц, а не ответственности системы по отношению к действующим лицам. Вообще тут нет описания использования и взаимодействия, а только описание ответственностей класса.
Конечно, никто не запрещает использовать нотацию таким образом. но тогда нужно оговариваться, что это не совсем UML. А какое-то свое собственное изобретение.
В этом же сообщении указана ссылка на выступление Гришы на конференции. Гриша, похоже тебе стоит включить диаграмму в свою копилку :). В ней тараканов в 10 раз больше, чем в диаграмме вариантов использования из методички известного вуза в твоем выступлении, по которой и на мой взгляд делаешь серьезную ошибку, уличая автора в смертных грехах смешивания уровней ВИ.
А вот слайд из презентации корпоративного курса, который читается за деньги и уважаемым мною человеком, тоже стоит включить в презентацию, как образец исключительного заблуждения автора :)
-
Действительно, использование диаграммы вариантов использования здесь довольно сомнительно, поскольку закрепляет ответственности действующих лиц, а не ответственности системы по отношению к действующим лицам. Вообще тут нет описания использования и взаимодействия, а только описание ответственностей класса.
Конечно, никто не запрещает использовать нотацию таким образом. но тогда нужно оговариваться, что это не совсем UML. А какое-то свое собственное изобретение.
В этом же сообщении указана ссылка на выступление Гришы на конференции. Гриша, похоже тебе стоит включить диаграмму в свою копилку :). В ней тараканов в 10 раз больше, чем в диаграмме вариантов использования из методички известного вуза в твоем выступлении, по которой и на мой взгляд делаешь серьезную ошибку, уличая автора в смертных грехах смешивания уровней ВИ.
Это не UML и не диаграмма вариантов использования, но это прекрасная визуализация.
Я считаю очень большой проблемой то, что к схеме типа "люди и их интересы" намертво приклеен ярлык "диаграммы вариантов использования". Варианты использования - это всего лишь один из методов проектирования, применимый в сравнительно узкой области. А область применения этой визуализации намного шире.
Об этом я говорил на Analyst Days в этом году. Видео пока нет, выложена только презентация. http://analystdays.ru/ru/talk/45843 Слайд 31 иллюстрирует один из первых зафиксированных случаев использования этой диаграммы в истории.
Я вообще об этом, по-моему, на каждом углу твержу, но меня не понимают. Ну ничего, мы разрушим эту монополию. :)
Поэтому решительно предлагаю эту диаграмму переименовать, а выражение "диаграмма вариантов использования" забыть, как страшный сон.
http://visic.info/pictures/roles-n-goals/61/
-
Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".
А почему это не UML, если автор, это нарисовавший, считает, что рассказывает про UML?
-
Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".
В этой стандартной нотации для "ответственностей" всё прекрасно: и скобочки после ответственностей, и горизонтальные чёрточки, делящие прямоугольник на три части (а зачем посередине пустая, кстати?), а особенно прекрасны интуитивно понятные любому человеку правила написания: МолодойВоин, охотитьсяНаЗверя.
Нет, у тех, кто программировал на Java, никаких затруднений не возникнет, конечно. А вы что, не программировали? Ну, это ваши проблемы. Стандарты нужно знать. Но непременно с методиками, иначе вы обязательно что-то нарушите.
"Вот за это они нас и не любят." (c)
-
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
По части визуализации она, прямо скажем, не очень.
-
Это не UML и не диаграмма вариантов использования, но это прекрасная визуализация.
Такая визуализация должна просто сопровождаться легендой.
Овал - интерес
Человечек - тип субъекта в племени
Стрелка с полым треугольником - специализация
-
Такая визуализация должна просто сопровождаться легендой.
Овал - интерес
Человечек - тип субъекта в племени
Стрелка с полым треугольником - специализация
А без легенды непонятно? В специальных пояснениях нуждается только стрелка.
-
Недостатки онлайновой рисовалки коллеги по форуму нашли очень быстро. И принесли мне "граблей". Благодарю. Вопросов моих, таким образом, как бы не было. Узнаваемый стиль.
Скобочки можно опустить. Именовать так, как привычнее. "Лишнюю" среднюю палку убрать. Можно убрать и рамочки, заменив на охотников.
Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.
-
Скобочки можно опустить. Именовать так, как привычнее. "Лишнюю" среднюю палку убрать. Можно убрать и рамочки, заменив на охотников.
А нотация после таких издевательств точно останется стандартной?
Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.
Язык, который требует умения разбираться в подмножествах диаграмм и применять инструменты (желательно разбираясь, какие из них умеют) для доведения до адресата достаточно простой мысли - не лучший выбор. В этом контексте он есть плохой язык. Хотя во всем остальном, особенно в плане применения по назначению заранее подготовленными людьми в заранее подготовленных ситуациях, он может быть прекрасен, аки лебедь.
Так что мужикам - яйца, экспертам - язык.
-
Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.
Кто сказал, что язык негодный? UML - отличный язык! Для архитекторов и программистов.
-
Что же, потоком идёт прежняя "милота". "Стандартный" русский язык не включает в себя "строительное" и/или криминальное "арго". А раз так, то общение на нём со строителем -- не лучший выбор. В контексте стройки он -- плохой язык. И т. п. и т. д. И учить русский язык -- потеря времени. А любое произведение какого-либо русского писателя -- повод для "ржаки".
Я предлагаю изобрести ещё какой-нибудь язык для тутошней планеты-форума. Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них. Чем не устраивает диаграмма классов как основа "муже-яйцевых" аналитических схем? Тем, что она будет понятна помимо аналитиков ещё и архитекторам, и программистам, и, страшно подумать, каким-то прогам?
-
Я предлагаю изобрести ещё какой-нибудь язык для тутошней планеты-форума. Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них.
В смысле, в цитатах? Или был отредактирован какой-то ваш пост?
Спрашиваю, потому что я иногда по ошибке нажимаю кнопку "Редактировать" вместо "Цитировать", и мог непреднамеренно что-то удалить.
Чем не устраивает диаграмма классов как основа "муже-яйцевых" аналитических схем? Тем, что она будет понятна помимо аналитиков ещё и архитекторам, и программистам, и, страшно подумать, каким-то прогам?
Да всем устраивает, если с её помощью аналитики общаются с архитекторами и программистами и друг друга понимают.
Всё, что я здесь (и в других местах) говорю о неприменимости UML, касается общения аналитиков с заказчиками и простыми пользователями. Там тоже очень нужна визуализация, но использование UML не решает проблему недопонимания, а усугубляет её. То есть ваша метафора работает в другую сторону: с ними ведётся общение на строительном жаргоне вместо обычного русского языка.
-
А без легенды непонятно? В специальных пояснениях нуждается только стрелка.
Без легенды понятно, если эту диаграмму не относить к UML. Если же задача была образно что-то показать, то наверное лучше было бы картинками это сделать.
-
Кто сказал, что язык негодный? UML - отличный язык! Для архитекторов и программистов.
Я в своем опыте ограничен даже поболе - только архитекторами. Не было у меня программистов, готовых (реально, а не "говно вопрос!") работать по спецификациям в uml.
-
"Стандартный" русский язык не включает в себя "строительное" и/или криминальное "арго". А раз так, то общение на нём со строителем -- не лучший выбор. В контексте стройки он -- плохой язык. И т. п. и т. д.
Коллега, мы же общаемся "за стройку" не только со строителями. Но и с теми, кто эту самую стройку заказывает и бабло на нее отсчитывает. Чего Вы так рветесь поговорить с ними на строительном языке? Если бы они этого хотели, говорили бы напрямую, без нас.
Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них.
Цитирование оно такое - суровое и беспощадное.
-
Смешная диаграмма про воинов продолжает работать в рекламе курса.
Уважуха. ОО-анализ на языке, похожем на UML, отчего бы нет.
-
Смешная диаграмма про воинов продолжает работать в рекламе курса.
Уважуха. ОО-анализ на языке, похожем на UML, отчего бы нет.
А что за курс?
-
Григорий вешал рекламу недавно.
-
Григорий вешал рекламу недавно.
Не очень конструктивный ответ.
-
Да, надо признать. Но в русле, в котором шло обсуждение. Мне кажется.
-
Смешная диаграмма про воинов продолжает работать в рекламе курса.
Уважуха. ОО-анализ на языке, похожем на UML, отчего бы нет.
В новой версии видеоролика смешную диаграмму про воинов убрали. Вторую смешную диаграмму оставили. А что делать? Нельзя же рекламировать курс про "анализ на" так называемом "UML" совсем без диаграмм.
Что мы видим на единственной диаграмме?
(http://docplayer.ru/docs-images/50/25958549/images/17-0.png)
Крановщик с технологом могут войти в систему только вместе, взявшись за руки? "Ржака" -- если использовать предложенный нам термин. Но для анализа на языке, похожем на UML, сойдёт.
С неизменной уважухой,
НЛО
-
НЛО, а вот насколько все-таки Ваше утверждение справедливо. Определяет ли стандарт каким образом интерпретировать такие ситуации. Ведь ВИ - это набор сценариев, если в одном участвует один тип пользователя, в другом другой?
-
Вполне себе справедливо утверждение.
В стандарте 2.4.1 есть диаграмма:
(https://training-course-material.com/images/d/d4/OCUPUseCaseDiagram.png)
Давайте её истолкуем в предложенном ключе: либо клиент договаривается о кредите без супервайзора, либо супервайзор договаривается о кредите без клиента якобы в рамках разных сценариев одного ВИ. Выйдет ещё более смешной язык, похожий на UML. Косяк диаграммы пропатчат в оисании? Не, не думаю. Если б так, то описание вытесняет диаграмму UML. Давайте её из ролика "вытеснять".
-
Давайте её истолкуем в предложенном ключе: либо клиент договаривается о кредите без супервайзора, либо супервайзор договаривается о кредите без клиента якобы в рамках разных сценариев одного ВИ. Выйдет ещё более смешной язык, похожий на UML. Косяк диаграммы пропатчат в оисании? Не, не думаю. Если б так, то описание вытесняет диаграмму UML. Давайте её из ролика "вытеснять".
Первая часть абзаца весьма логична и не вижу способов опровергнуть такие выводы. Другая часть, по-моему, эмоциональная. Неужели, НЛО, Вам ведомы земные страсти и сарказм?
Но. Возьмем таких авторитетов UML как Арлоу и Нейшдат (в своей книге uml2 и UP) в разделе 5.2 описывают как возникает обобщение (кстати ни в руководстве по UML2, ни в книге Рамбо и Блаха, почти ничего об этом не пишется).
(http://www.uml2.ru/forum/index.php?action=dlattach;topic=6519.0;attach=5621)
Хотя правильнее бы сказать, что продавец и покупатель взаимодействуют в рамках одного экземпляра варианта использования. А не исполняют одну и ту же функциональность, как авторы это определяют. Авторы заблуждаются? Или просто неряшливо используют UML?
-
Следует ли ожидать появления различных конфессий и сект, претендующих на единственное толкование "истинного UML" , и обкладывающих друг друга анафемами? ;)
-
Все-таки в спецификации UML отсутствует однозначное и прямое толкование обсуждаемой нами темы. Беглый просмотр книг и учебников от авторов UML тоже не проясняет ситуацию, но предполагает, что интерпретация (реализация взаимодействия) определяется другими средствами при дальнейшей декомпозиции, т.е. сама диаграмма не может ответить в таком случае на вопрос как должно быть в точности и подразумевается множество возможных ответов:
Технолог и Крановщик используют общую функциональность с индивидуальными особенностями или без, если с индивидуальными возможна декомпозиция с обобщениями или включениями
технолог и Крановщик могут зайти в систему только "держась за руки"
-
Первая часть абзаца весьма логична и не вижу способов опровергнуть такие выводы. Другая часть, по-моему, эмоциональная. Неужели, НЛО, Вам ведомы земные страсти и сарказм?
Это с кем поведёшься (про страсти и сарказм). Если возможно, то обсуждению моей персоны и того, что мне ведомо, прошу посвятить отдельную тему.
Но. Возьмем таких авторитетов UML как Арлоу и Нейшдат (в своей книге uml2 и UP) в разделе 5.2 описывают как возникает обобщение (кстати ни в руководстве по UML2, ни в книге Рамбо и Блаха, почти ничего об этом не пишется).
Книга Арлоу и Нейштадта не про RUP.
Книга Арлоу и Нейштадта не является спецификацией UML.
Книга Арлоу и Нейштадта написана в 2006 году, а стандарты OMG 2.5 и ISO 19505-1 и -2 много позже.
Да, Рамбо почти ничего не пишет по ВИ. Потому что их придумал Якобсон. Можно сходить на его сайт, найти там презентуху "USE-CASE 2.0" и на одной из первых страниц увидеть проиллюстированное примером видение изобретателя термина ВИ.
Можно мысленно проделать трансформацию по методу Арлоу и Нейштадта примера из 2.4.1, породив обобщающее действующее лицо от Customer и Supervisor, и убедиться, что обобщение действующих лиц не является способом борьбы с "пересекающимися линиями". Разумная трактовка их манипуляций заключается в том, что эскизная диаграмма с ошибкой при помощи трансформации, исправляющей ошибку приводится к верной модели.
Думаю, что утверждение про то, что по стандарту нельзя однозначное и прямое толкование найти, следует обосновать. Сделайте это, а потом я прилечу и с ведомым мне сарказмом проверю Ваше обоснование на прочность.
-
Тем, кто составляет список сект, могу предложить две: секта тех, кто читал стандарт; секта тех, кто не читал.
А теперь внимание. Анафему в студию! Или недостатки модели сами транзитивно переползают на автора модели?
С крепнущей уважухой,
НЛО
-
Видение такого известного популяризатора стандарта UML как Kirill Fakhroutdinov проиллюстрировано примером на его сайте:
http://www.uml-diagrams.org/bank-atm-uml-use-case-diagram-example.html
На минуту представим себя на планете, где банкоматы выдают деньги в обход банка. Или силами, почерпнутыми у Арлоу и Нейштадта на минуту обобщим Customer и Bank и "исправим" диаграмму. По-моему, неплохая выходит планета. Уже лечу к ней.
-
Думаю, что утверждение про то, что по стандарту нельзя однозначное и прямое толкование найти, следует обосновать. Сделайте это, а потом я прилечу и с ведомым мне сарказмом проверю Ваше обоснование на прочность.
Я верю, что в Вашей Вселенной живые существа обладают уникальными способностями, мы-то даже возможно и на Луне в реальности не бывали. Да и вообще очень невнимательные и крайне несовершенные существа. Лично я буду очень признателен, если вы укажете точные ссылки на спецификацию, которые определяют правила чтения и использования диаграмм такого типа.
-
Видение такого известного популяризатора стандарта UML как Kirill Fakhroutdinov проиллюстрировано примером на его сайте:
http://www.uml-diagrams.org/bank-atm-uml-use-case-diagram-example.html
На минуту представим себя на планете, где банкоматы выдают деньги в обход банка. Или силами, почерпнутыми у Арлоу и Нейштадта на минуту обобщим Customer и Bank и "исправим" диаграмму. По-моему, неплохая выходит планета. Уже лечу к ней.
Приводя Арлоу и Нейштадта я лишь показал, что рассуждения для чтения или изменения исходной диаграммы должны во многом основываться на контексте и предметной области. И что дальнейшее уточнение диаграммы может идти разными путями, или это будет обощение, или абстрагирование (выделение каких-то абстрактных ВИ) или предполагание, что два актора тут присутствуют неслучайно. При этом ясно, что Банк тут не инициатор ВИ, а лишь его участник, раньше (в розе) для этого предлагалась рисовать стрелку или указывать стереотип "инициирует".
-
Если бы имена элементов модели были бы важнее типов элементов и связей между ними, то для лучшего моделирования нужно было бы стереть человечков, овальчики, стрелочки. И заменить их на слова. Но напала блажь -- высказываться невербально, на графическом (и в том числе программно читаемом) языке. Представим себя программами-чеккерами. С такой точки зрения имена элементов модели -- лишь строчки. Смысл модели в наборе элементов, их свойствах, их связях. И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.
[Про остальное написало в личку.]
-
И тут везде одно и то же: один ВИ и два связанных с ним ДЛ. В каждом случае чеккер прочтёт модель с одинаковым смыслом.
Именно, как только мы начинаем производить автоматическую трансформацию с целью получения исполняемого кода или другого интерпретируемого продукта.
Мне неизвестны случая (это конечно не означает, что их нет), когда на основе чтения ДВИ можно получить больше чем просто описание модели.
Но даже в спецификации написано для чего применяется диаграмма ВИ и описание закладываемого в ВИ поведения определяется другими средствами: диаграммой деятельности, машиной состояния, последовательности.
-
Другая диаграмма и/или связанное описание может пояснять то, что не отражено на первой. Но не может менять смысл, зафиксированный первой. Поэтому, обсуждая этот смысл, привлекать другие диаграммы означает отвлекаться от главного в пользу второстепенного.
В Agile Modeling, к слову, допускается противоречивость. Накосячили в одном месте (где неважно), исправили в другом (где важно).
Чеккер выдаёт перечень ошибок. Поскольку речь об поиске "ржак" на диаграммах, точка зрения чеккера уместнее.
-
Другая диаграмма и/или связанное описание может пояснять то, что не отражено на первой. Но не может менять смысл, зафиксированный первой. Поэтому, обсуждая этот смысл, привлекать другие диаграммы означает отвлекаться от главного в пользу второстепенного.
Ну да, Вы правы. Я вспомнил такое правило. У каждого ВИ есть только одно основное действующее лицо (первичное), то, которое инициирует ВИ, остальные могут быть только вспомогательными.
-
Вижу в ленте провод для некропоста. Приклею это и ненадолго отлечу.
(https://www.webursitet.ru/kcfinder/upload/images/%206%20-%2005.png)
В сопроводительном тексте утверждается, что якобы "картинка, которая в UML называется диаграммой вариантов использования".
-
Вижу в ленте провод для некропоста. Приклею это и ненадолго отлечу.
(https://www.webursitet.ru/kcfinder/upload/images/%206%20-%2005.png)
В сопроводительном тексте утверждается, что якобы "картинка, которая в UML называется диаграммой вариантов использования".
Это что за ужас инопланетный тут представлен? У меня такое даже двоечники стесняются рисовать.
-
Это что за ужас инопланетный тут представлен?
А что тут такого ужасного?
Все вроде бы правильно.
-
А что тут такого ужасного?
Все вроде бы правильно.
Для начала не плохо бы начать с соответствия спецификации (стандарту) UML.
-
Для начала не плохо бы начать с соответствия спецификации (стандарту) UML.
А что на этой схеме не соответствует UML?
-
А что на этой схеме не соответствует UML?
В марсианских стандартах требуется, чтобы актор-треножник был на трёх ногах, а не на двух. ::)
Затруднительно отвечать на заданный вопрос, сохраняя серьёзность.
-
Затруднительно отвечать на заданный вопрос, сохраняя серьёзность.
А вы попробуйте.
Я серьезно не вижу никаких нарушений стандарта UML в этой схеме.
Может быть я плохо знаю стандарт или не внимателен.
Было бы хорошо, если бы без лишних слов Вы просто объясните, чем схема не соответствует стандарту.
-
Может быть я плохо знаю стандарт или не внимателен.
Ну тогда может Вы для начала узнаете его немного лучше? Тогда ответ будет вполне очевиден.
-
Было бы хорошо, если бы без лишних Вы просто объясните, чем схема не соответствует стандарту.
Зачем же лишать Вас удовольствия?
-
Ну тогда может Вы для начала узнаете его немного лучше? Тогда ответ будет вполне очевиден.
Я перед тем как написать свое первое сообщение по этому вопросу, открыл стандарт и посмотрел в нем схемы.
Никаких принципиальных отличий от выложенной здесь схемы я не увидел.
А вам видимо доставляет удовольствие говорить загадками на протяжении уже нескольких дней.
Очень продуктивный способ вести обсуждение.
-
Я перед тем как написать свое первое сообщение по этому вопросу, открыл стандарт и посмотрел в нем схемы.
Никаких принципиальных отличий от выложенной здесь схемы я не увидел.
В этом случае никакие мои слова ни в чем Вас не убедят.
А вам видимо доставляет удовольствие говорить загадками на протяжении уже нескольких дней.
Почему загадками. У меня своя точка зрения, у Вас своя. Для меня очевидным является факт, что это диаграмма не корректна с позиции именно нотации UML.
Вы же утверждаете, что она ни чем не противоречит. Мне как раз Ваша точка зрения не понятна.
Очень продуктивный способ вести обсуждение.
Называется маевтика :)
https://www.uml-diagrams.org/use-case-actor-association.html
https://www.uml-diagrams.org/use-case-extend.html
https://www.uml-diagrams.org/use-case-include.html
-
Было бы хорошо, если бы без лишних слов Вы просто объясните, чем схема не соответствует стандарту.
На Марсе в футбол играют в одни ворота. Слышало, что на Земле используют больше чем одни ворота в этой игре. Уважая традиции Вашей планеты, обращаюсь к Вам с симметричной просьбой обосновать свою точку зрения.
Открываем по Вашей просьбе стандарт OMG UML v2.5.1
В параграфе 18.1.4 на странице 642 сказано: An Extend relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the extending UseCase towards the extended UseCase. The arrow is labeled with the keyword «extend»... An Include relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the base UseCase to the included UseCase. The arrow is labeled with the keyword «include»...
Стало быть, стандартная нотация нарушена при изображении связи включения от Usecase2 к Usecase3 (проведена пунктирная линия, а не предписываемая стандартом пунктирная стрелка). Стало быть, стандартная нотация нарушена при изображении связи расширения от Usecase4 к Usecase2 (также отсутствует стрелка).
Сплошной линией в стандартном UML изображается ассоциация. Проводить ассоциацию между двумя вариантами использования стандарт разрешает только тогда, когда они находятся внутри разных subject-ов (внутри рамкок двух разных систем). Для этого в параграфе 18.2.5.6 на стр. 650 заведено ограничение:
no_association_to_use_case
UseCases cannot have Associations to UseCases specifying the same subject.
context UseCase inv: Association.allInstances()->forAll(a | a.memberEnd.type->includes(self) implies (
let usecases: Set(UseCase) = a.memberEnd.type->select(oclIsKindOf(UseCase))->collect(oclAsType(UseCase))->asSet() in
usecases->size() > 1 implies usecases->collect(subject)->size() > 1))
Выше в параграфе 8.1.3 на стр. 640 также сказано: Two UseCases specifying the same subject cannot be associated...
Значит, рисовать сплошную линию между двумя вариантами использования внутри одной рамки стандартом запрещено.
Теперь пройдёмте к Вашим воротам.
-
Называется маевтика :)
Жаль, что Вас "маевтика" больше интересует, чем UML.
-
Открываем по Вашей просьбе стандарт OMG UML v2.5.1 ...
Стало быть, стандартная нотация нарушена при изображении связи включения от Usecase2 к Usecase3 (проведена пунктирная линия, а не предписываемая стандартом пунктирная стрелка).
Стало быть, стандартная нотация нарушена при изображении связи расширения от Usecase4 к Usecase2 (также отсутствует стрелка).
...
Сплошной линией в стандартном UML изображается ассоциация.
Проводить ассоциацию между двумя вариантами использования стандарт разрешает только тогда, когда они находятся внутри разных subject-ов (внутри рамкок двух разных систем).
Для этого в параграфе 18.2.5.6 на стр. 650 заведено ограничение:
Выше в параграфе 8.1.3 на стр. 640 также сказано: Значит, рисовать сплошную линию между двумя вариантами использования внутри одной рамки стандартом запрещено.
Спасибо!
Так как два авторитетных аналитка сказали о некорректности схемы, я в этом не сомневался.
Просто хотелось точнее определить в чем заключается эта некорректность.
Теперь я еще раз перечитаю стандарт, уделяя особое внимание указанным "тонкостям".
-
Так что мужикам - яйца, экспертам - язык.
некротрединга псто:
Предлагаю желающим определить, чья нотация на следующих картинках: мужицкая или экспертная?
(https://www.ibm.com/developerworks/rational/library/06/0214_donatelli/figure16.gif)
Подпись к 1й картинке: Юзвери, юзвериные цели, экземпляры юзверей
(https://www.ibm.com/developerworks/rational/library/06/0214_donatelli/figure17.gif)
Подпись ко 2й картинке: Связи между вариантами использования, юзвериными целями, деловыми целями
Эксперты по "прекрасным визуализациям" могут попытаться здесь рассмотреть, что цель юзверя и вариант использования (даже если это вариант использования с уровнем "моря") -- это разные вещи. Их нельзя отождествлять.
-
... если это вариант использования с уровнем "моря" ...
Что такое "с уровнем моря"?
-
Что такое "с уровнем моря"?
С подачи Алистера Кобёрна считается, что у варианта использования есть т. н. "уровень цели" -- той цели [действующего лица], которая может быть достигнута в ходе взаимодействий, описываемых сценариями этого ВИ. Т. к. Кобёрн связывал ВИ-1---1-Цель [действующего лица] (1994й год, на минуточку), то из-за этого он упрощённо называл "уровень цели" ВИ просто "уровнем ВИ". Кобёрн придумал 5 "уровней цели" = 5 "уровней ВИ":
"уровень облака"
"уровень воздушного змея"
"уровень моря"
"уровень рыбы"
"уровень моллюска"
Цели пользователя (user goal) находятся на "уровне моря". Отсюда закрепилось "вариант использования уровня моря" или "вариант использования уровня цели пользователя".
Тут можно найти поводы для неразберихи:
-- соблазнительно отождествить цель действующего лица с целью пользователя;
-- собразнительно отождествить цель действующего лица и вариант использования;
-- собразнительно отождествить цель пользователя и вариант использования;
-- соблазнительно выродить набор из 5ти уровней цели в один единственный "уровень моря";
-- соблазнительно вещать о том, что на одной диаграмме ВИ должны быть ВИ одного и того же уровня.
Выше можно видеть, что Кобёрна уточнили, что в общем случае ВИ-*---*-Цель [действующего лица]. Нужно учитывать, что ВИ может быть связан с несколькими действующими лицами, у каждого из которых, вообще говоря, есть своя собственная цель по отношению к системе (у клиента банкомата -- получить налик, у банковского сервера -- получить от банкомата вменяемую пачку данных, чтобы можно было разобрать, отбить запрос или удовлетворить). Тогда выходит, что "уровень цели" ВИ по Кобёрну = "уровень цели" основного действующего лица этого ВИ. Глядя на ВИ с позиций разных действующих лиц, связанных с ним, мы можем видеть уровни цели этих лиц, и уровни эти не обязаны совпадать. Для точного и полного описания ВИ следовало бы у каждого ВИ указывать перечень целей всех причастных действующих лиц.
Но это марсианские реалии. Любое совпадение с реалиями тутошней планеты случайно.
-
... считается, что у варианта использования есть т. н. "уровень цели" -- той цели [действующего лица], которая может быть достигнута в ходе взаимодействий, описываемых сценариями этого ВИ ...
Еще раз спасибо! Коберна читал когда-то очень давно.
Хороший повод для самообразования. Надо будет перечитать все что связано с целями ВИ и их уровнями.
Можете порекомендовать что почитать кроме Коберна?
Но это марсианские реалии. Любое совпадение с реалиями тутошней планеты случайно.
У меня всегда есть стремление глубже разобраться и сделать что-то как можно "правльнее".
Не важно где я нахожусь: на марсе или на тутошней планете.
Поэтому в первую очередь интересует "истина", которая всегда "дороже".
-
Еще раз спасибо!
Благодарю Вас. Есть какие-то вещи, которые крутятся в голове, а повода оформить их в текст не находится. Общение на форуме такие поводы иногда даёт. Спасибо.
-
Можно дополнить, что саму моделируемую систему Кобёрн относил к действующим лицам. В этом можно усмотреть повод к тому, чтобы в рамках варианта использования посмотреть на всё глазами этого действующего лица, а именно признать, что система тоже имеет цели по отношению к действующим лицам, причастным к этому ВИ. Фиксация целей этого действующего лица и соответственно обязанностей, возлагаемых им на других причастных действующих лиц, может пригодиться для некоторых нефункциональных требований.
-
(у клиента банкомата -- получить налик, у банковского сервера -- получить от банкомата вменяемую пачку данных, чтобы можно было разобрать, отбить запрос или удовлетворить).
Коберн говорит о том, что в каждом шаге ВИ должен защищаться чей-то интерес. И он приводит довольно сложную классификацию ДЛ.
Но ВИ все-таки стремится обеспечить цель основного ДЛ, попутно удовлетворяя интересы других участников.
Причем БС - это второстепенное ДЛ (т.е. используемое). Но понятно что с точки зрения правления банка, оно хочет, чтобы транзакции осуществлялись корректно.
Т.е. множественность целей - это отличное наблюдение, но все-таки одна из них всегда в фокусе, и это цель ОДЛ.
-
Можете порекомендовать что почитать кроме Коберна?
Если интересно разобраться именно с use case modeling, я бы рекомендовал книгу: https://yadi.sk/d/j20Pd2DUftGuv
-
Я не такой хейтер Коберна как RUP-евангелистка Терри Кватрани. Я лишь обозначило возможное развитие его идей, с учётом приведённых выше IBM-овских диаграмм.
Могу продолжить болтать в том же ключе. Например, о том, что в большинстве случаев ВИ рассматривается как непротиворечивое взаимодействие действующих лиц и системы. Гитотетически можно предположить ВИ, в рамках которого несколько действующих лиц являются антагонистами со взаимно исключающими целями. Такой "лебедеракощучный" ВИ. В таком гипотетическом случае, считая основным лебедя и выделяя только его цель, забывая про то, что "рак пятится назад, а Щука тянет в воду", мы получим перекошенное описание. И не соблюдём завет классика: "Кто виноват из них, кто прав, — судить не нам...".