Не так. Не сценарии плохи (они верно служат в качестве сырья для формирования требований или же в роли наглядного примера). Плоха подмена ими результатов работы аналитика.

Сценарии ВИ это не сырье для формирования требований к разрабатываемой программной системе, а наоборот продукт процесса разработки требований, один из способов представления функциональных требований.

Потому что появились довольно широкие классы ПО, в которых взаимодействие пользователя с системой неудобно описывать сценариями. Попробуй описать в виде сценариев работу с Excel, например. Получится очень ограниченный набор требований, который не покроет большей части функциональности. Слишком много путей, все предусмотреть невозможно. То же относится к большинству программ для ПК: текстовые, фото, видеоредакторы - сценариями можно описать какие-то отдельные кусочки взаимодействия, которые всё равно не складываются в мозаику.

Для веб-сайтов сценарный подход тоже оказался неприменим.

По большей части, согласен с Григорием. Я на тренинге тоже рассказываю об ограничениях ВИ (в нотации Коберна).

ВИ очень удобны для учетных систем (склад, фильмотека, форум, социальная сеть). Т.е. для сайтов с функционалом они более чем применимы.

Случаи, когда они не очень удобны:
* Проекты по настройке систем.  Для разработки багтрекера ВИ прекрасно подходят, а для проекта по настройке багтрекера лучше использовать более высокоуровневые нотации [EPC|State|Data Flow|...] + [табличное описание объектов |XML|...] + ...
* Протоколы интеграции. Примитивный форум сейчас интегрируется с кучей систем. Т эту интеграцию лучше описывать другими нотациями.
* Игромеханика. С помощью ВИ сложно описать шахматы...

Сейчас все чаще настраивают готовые системы, чем пишут с нуля. Ситуация за последние 20 лет изменилась достаточно существенно.
Сейчас все больше интеграций. 20 лет назад системы были более изолированы.

Так что, да: ВИ все еще занимают важную нищу, но ее размер сокращается.

Сейчас все чаще настраивают готовые системы, чем пишут с нуля. Ситуация за последние 20 лет изменилась достаточно существенно.
Сейчас все больше интеграций. 20 лет назад системы были более изолированы.

Да, Сергей, спасибо. Интересное наблюдение.

Леонид, спасибо. Можно, хотя бы кратко, весь цикл инфоработы и его результат?

Кратко я привел его в первом посте темы:

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

Можно чуть более формализовано:
1. Сбор данных.
2. Систематизация данных.
3. Обработка данных.
4. Получение информации.
5. Выработка решений, выводов, рекомендаций.

Правомерность разделения пунктов 3 и 4 под вопросом. По сути - это две стороны одной медали.

Я имел ввиду другое. Степень вклада аналитика (глубина проработки) в разных проектах разная. Поэтому я считаю некорректным устанавливать границу, на которой находится "наивысший возможный вклад аналитика".

Вот колокольня. Ее наивысший возможный вклад (практически, смысл существования) - обеспечить нужную высоту источнику звукового сигнала для его максимального распространения. А вот конкретный проект по разгону облаков, который предполагает другую глубину и степень ее использования. Разгон облаков - штука нужная и полезная. Но колокольню строили для другого.

Не совсем понятно о каких решениях вы говорите. Насколько глубоко, по вашему, аналитик должен про прорабатывать решение.

Решения, подвластные аналитику, могут лежать в области применяемых алгоритмов, наличия отдельных функций,  функциональной архитектуры, интерфейсов, политики учета объектов, очередности реализации функционала и т.д, и т.п. Глубина должна быть такой, чтобы его решениями могли пользоваться те, для кого они предназначены.

По моему опыту степень специализации аналитика, как и других членов команды, зависит от размера и сложности проекта. В крупных проектах высокая специализация более уместна. Вершин можно достичь развиваясь как вширь, так и вглубь.

Конечно зависит. И да - можно всю жизнь совершенствоваться, например, в написании сценариев. И помереть непревзойденным мастером сценариев. Разве я против? Только аналитиком его называть неправильно.

Чем это грозит?

Тем, что очередной частный случай развалит всю полноту и непротиворечивость.

Вы говорите про мизерность добавленной стоимости и примитивности навыков. Хотелось бы понять на основе чего Вы делаете такие выводы?

На основании места выдаваемого "продукта" в цепочке создания ценности. Чем ближе к началу - тем ниже добавленная стоимость и тем меньше навыков требуется для ее создания. Аналог - ситуация, в которой некая страна продает сырые углеводороды, а не продукты их переработки.

В большое количество активностей RUP роль аналитика тоже попала по недоразумению?

Я не являюсь знатоком RUP и истории его развития. Ответить не могу.

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

Я и не призываю.

В моем представлении как раз наоборот. ВИ нужны для того чтобы согласовать общее понимание неопределенного окружения.

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

Сценарии ВИ это ... один из способов представления функциональных требований.

Известный подход, в Библии широко применяется. В смысле, когда эксперта спрашивают "как надо?", а тот отвечает притчей. Со всеми вытекающими.

Сценарии могут содержать в себе требования (а также латентные требования, ограничения, рекомендации, исключения, предостережения, приколы и т.п.).
Сценарии не являются требованиями.

Вот колокольня. Ее наивысший возможный вклад (практически, смысл существования) - обеспечить нужную высоту источнику звукового сигнала для его максимального распространения. А вот конкретный проект по разгону облаков, который предполагает другую глубину и степень ее использования. Разгон облаков - штука нужная и полезная. Но колокольню строили для другого.

Предназначение колокольни сложно оспорить. К сожалению в нашей профессиональной области нет такого единства в понимании предназначения аналитика.

Решения, подвластные аналитику, могут лежать в области применяемых алгоритмов, наличия отдельных функций,  функциональной архитектуры, интерфейсов, политики учета объектов, очередности реализации функционала и т.д, и т.п. Глубина должна быть такой, чтобы его решениями могли пользоваться те, для кого они предназначены.

Конечно зависит. И да - можно всю жизнь совершенствоваться, например, в написании сценариев. И помереть непревзойденным мастером сценариев. Разве я против? Только аналитиком его называть неправильно.

Потребители и производители "аналитического" продукта в разных проектах могут обладать разными компетенциями. Архитектуру могут "навесить" на аналитика, а в другом случае архитектурой будет заниматься главный разработчик или архитектор. Интерфейсы может разрабатывать как аналитик, так и дизайнер. Зависит от процесса разработки, используемого в проекте, и от компетенций членов команды. Почему специалиста с не самой широкой специализацией нельзя назвать аналитиком? И чем вы руководствуетесь при выделении списка решений, подвластных аналитику? Только собственным опытом или какими-то авторитетными источниками?

Тем, что очередной частный случай развалит всю полноту и непротиворечивость.

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

На основании места выдаваемого "продукта" в цепочке создания ценности. Чем ближе к началу - тем ниже добавленная стоимость и тем меньше навыков требуется для ее создания. Аналог - ситуация, в которой некая страна продает сырые углеводороды, а не продукты их переработки.

По моему некорректное сравнение. Если следовать Вашей логике, то на примере производства автомобилей тот кто прикручивает колёса на конвейере будет более квалифицированным, чем тот, кто проектировал двигатель. А в проекции на производство ПО получается что технический писатель, который готовит инструкцию пользователя, будет гораздо более квалифицированным чем разработчик (кодировщик) или архитектор.

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

Если я имею представление далёкое от широко распространённого в профессиональной среде, тогда прошу дать мне ссылку на авторитетный источник, который указывал бы, что в ситуациях высокой определённости окружения (требований) использование ВИ более целесообразно чем в други условиях. Буду рад если избавлюсь от своего заблуждения.

Известный подход, в Библии широко применяется. В смысле, когда эксперта спрашивают "как надо?", а тот отвечает притчей. Со всеми вытекающими.

Сценарии могут содержать в себе требования (а также латентные требования, ограничения, рекомендации, исключения, предостережения, приколы и т.п.).
Сценарии не являются требованиями.

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

К сожалению в нашей профессиональной области нет такого единства в понимании предназначения аналитика.

Не готов ручаться за область. Лично у меня это понимание есть.

Потребители и производители "аналитического" продукта в разных проектах могут обладать разными компетенциями. Архитектуру могут "навесить" на аналитика, а в другом случае архитектурой будет заниматься главный разработчик или архитектор. Интерфейсы может разрабатывать как аналитик, так и дизайнер. Зависит от процесса разработки, используемого в проекте, и от компетенций членов команды. Почему специалиста с не самой широкой специализацией нельзя назвать аналитиком?

Разве я говорил, что нельзя? Аналитикой (то есть, информационной работой) могут заниматься все поголовно. В том числе, на благо конкретного проекта. Это никоим образом не меняет назначения колокольни.

И чем вы руководствуетесь при выделении списка решений, подвластных аналитику? Только собственным опытом или какими-то авторитетными источниками?

Собственным опытом и опытом коллег.

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

Сработают в любом случае. Остается лишь небольшой вопрос цены разрешения противоречия. Что нам стоит провести рефакторинг-другой?

По моему некорректное сравнение. Если следовать Вашей логике, то на примере производства автомобилей тот кто прикручивает колёса на конвейере будет более квалифицированным, чем тот, кто проектировал двигатель. А в проекции на производство ПО получается что технический писатель, который готовит инструкцию пользователя, будет гораздо более квалифицированным чем разработчик (кодировщик) или архитектор.

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

Если я имею представление далёкое от широко распространённого в профессиональной среде, тогда прошу дать мне ссылку на авторитетный источник, который указывал бы, что в ситуациях высокой определённости окружения (требований) использование ВИ более целесообразно чем в други условиях. Буду рад если избавлюсь от своего заблуждения.

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

Разве я говорил, что нельзя? Аналитикой (то есть, информационной работой) могут заниматься все поголовно. В том числе, на благо конкретного проекта. Это никоим образом не меняет назначения колокольни.

Собственным опытом и опытом коллег.

Назначения колокольни не меняет, а вот Ваше мнение про назначение аналитика пока остаётся только Вашим субъективным мнением. Я уважаю это мнение, но к сожалению оно пока не подкреплено мнением значительного количества коллег.

Сработают в любом случае. Остается лишь небольшой вопрос цены разрешения противоречия. Что нам стоит провести рефакторинг-другой?

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

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

"Определённая деятельность определённого специалиста" складывается из "совокупности разных работ". Вы говорили про место выдаваемого "продукта" в цепочке создания ценности, сравнивали с местом других продуктов в цепочке создания ценности и добавленную стоимость разных продуктов. То есть мы говорили об одном и том же. О совокупности разных работ разных специалистов на разных участках.

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

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

а вот Ваше мнение про назначение аналитика пока остаётся только Вашим субъективным мнением.

Да, я обозначил это в первых строках первого поста. Правда, насчет "только" я не был столь категоричен.

Я уважаю это мнение, но к сожалению оно пока не подкреплено мнением значительного количества коллег.

Если в стане коллег разброд и шатание - ну, тем хуже коллегам. Печально, когда ты сам не определился, кто ты и зачем ты. Но мне кажется, что Вы несколько сгущаете краски. Не все так плохо у коллег.

"Определённая деятельность определённого специалиста" складывается из "совокупности разных работ". Вы говорили про место выдаваемого "продукта" в цепочке создания ценности, сравнивали с местом других продуктов в цепочке создания ценности и добавленную стоимость разных продуктов. То есть мы говорили об одном и том же. О совокупности разных работ разных специалистов на разных участках.

Еще раз: Вы последовали не туда. Если мне не удается это быстро и доходчиво объяснить - видимо, я неважно объясняю. Если вопросы все еще остаются, вернитесь пожалуйста к "истокам". Я там достаточно просто обозначил связь между стадией информационной работы и необходимыми для ее выполнения навыками. Другими словами: чем дальше от начала "цепочки" заходит процесс, тем бОльшими навыками и опытом должен располагать исполнитель.

Я очень рад если Вам удаётся абсолютно не знакомясь с имеющимся опытом "старших" коллег...

Обратите пожалуйста внимание на слова "...В качестве обобщенного личного опыта отдельных людей, у которых в определенной ситуации неплохо работает то-то и то-то - довольно интересно. Местами изящный "расклад по полочкам" или эффектный ход вызывают желание снять шляпу...". Это относится к трудам как известных западных "старших" коллег, так и куда менее известных, но от этого не менее грамотных, коллег отечественных.

Дискуссия пошла в какой-то этап взаимных упреков.

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

Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.

Да, я обозначил это в первых строках первого поста. Правда, насчет "только" я не был столь категоричен.

Хотелось бы услышать мнение других участников форума.

Если в стане коллег разброд и шатание - ну, тем хуже коллегам. Печально, когда ты сам не определился, кто ты и зачем ты. Но мне кажется, что Вы несколько сгущаете краски. Не все так плохо у коллег.

Я говорил про то, что пока не слышал убедительного подтверждения Вашему мнению. Отсутствие у меня такого информации о таком подтверждении не значит что везде разброд и шатание.

Еще раз: Вы последовали не туда. Если мне не удается это быстро и доходчиво объяснить - видимо, я неважно объясняю. Если вопросы все еще остаются, вернитесь пожалуйста к "истокам". Я там достаточно просто обозначил связь между стадией информационной работы и необходимыми для ее выполнения навыками. Другими словами: чем дальше от начала "цепочки" заходит процесс, тем бОльшими навыками и опытом должен располагать исполнитель.

Я прекрасно Вас понял. Такая логика не работает во многих случаях. К примеру написание инструкции пользователя обычно заканчивается после разработки, то есть дальше от начала "цепочки". Действительно ли по этой логике технический писатель должен располагать большими навыками и опытом чем кодировщик?

Дискуссия пошла в какой-то этап взаимных упреков.

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

Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.

Я пытался сохранять максимальное самообладание и уж точно у меня не было цели кого-то упрекать. У меня есть желание более глубоко разобраться в мнении Леонида. На текущий момент у меня уже не осталось вопросов, хотя во многом я остался не согласен с высказанными идеями.

Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.

Что Вы понимаете под "технологией сценариев"?

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

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

Пример про "стоимость".
На собеседованиях я спрашиваю кандидата о его вкладе в проекты, которыми он занимался. Как правило, человек начинает рассказывать про проведенные обследования, написанные ТЗ, нарисованные схемы. Выслушав, я стараюсь вывести его на несколько иной уровень: а придумал-то ты чего? Что "твоего" в решении, которое сейчас где-то работает и, предположительно, приносит пользу? Если кандидат переходит на истории о том, какую замечательную классификацию учета он разработал, какое придумал решение для разруливания противоречия между требованиями нормативки и реалий, как он предложил и убедил заказчика включить в состав решения новую подсистему, потому что работа без нее означала большие проблемы в ближайшем будущем, как он развел потоки данных так, что заказчик ажно дар речи от счастья потерял - вот это аналитик, который стоит хороших денег (и неважно, что "слегка преувеличил").
Ну а если кандидат продолжает рассказывать о том, что в его ТЗ нормоконтролер носа не подточит, его сценарии строго следуют заветам Вигерса и у него три сертификата по UML - это не совсем аналитик. Это ремесленник с явным превосходством формы над содержанием (что не означает его бесполезности, разумеется).