436

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 07 Марта 2014, 17:08:58 »

Леонид, видимо, Вам серьезно досталось. Сочувствую.

Благодарю за участие, но сочувствовать право не стоит. Рассматриваемый феномен обрел силу лишь последние лет 5, и лично мне повредить уже не может.

А вот относительно начинающих жаль. Кто-то искренне считает, что если в названии его должности есть слово "аналитик", то занимается он аналитикой. Или, глядя на особо креативное тестовое задание - что это он дурак (ведь составитель задания априори мудр и знает, что делает). Или терзается конкретным вопросом навроде "куда вставить последний сценарий в ТЗ по ГОСТ" слегка подозревая, что туда и первый вставлять не стоило. Сложно сегодня становиться аналитиком.

437

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 07 Марта 2014, 13:41:57 »

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

Действительно. Зачем нужно мнение аналитика с его бизнес-интересами? Ведь все, что знает, он уже написал. Пусть идет на следующий проект, там сценарии еще не написаны. Остальное - дело серьезных пацанов и технологических инноваций.

Правда, только сценариями же систему не опишешь.

Это мелочи. Остальное программисты сами придумают - они же Программисты, а не быдлокодеры. А в случае чего, ПМ отправит аналитика убеждать Заказчика, что это именно то, что тому надо. Ну, чтобы лишний раз административный ресурс не беспокоить.

438

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 07 Марта 2014, 12:54:56 »

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

1. Я в таких местах/проектах работал. Безусловно, от аналитика там требовалось еще что-то: оформить разработанные сценарии в виде определенного документа, консультировать по ним программистов, участвовать в тестировании, поддерживать коммуникации с заказчиками. Но все перечисленное - не аналитика. Аналитика оканчивалась разработкой сценариев. Попытки влезть с советами по поводу организации информационных объектов, проектирования интерфейсов, межсистемного взаимодействия бодро пресекались. Мол, это дело архитекторов и программистов.

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

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

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

По-моему, вы воюете с ветряными мельницами.

Разве я воюю?

439

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 07 Марта 2014, 11:09:41 »

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

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

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

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

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

440

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 19:20:17 »

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

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

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

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

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

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

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

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

441

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 15:15:22 »

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

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

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

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

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

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

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

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

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

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

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

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

442

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 12:11:51 »

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

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

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

443

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 12:04:40 »

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

444

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 06 Марта 2014, 11:35:44 »

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

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

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

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

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

445

Задачи студентов / Re: Перевод с UML

« : 05 Марта 2014, 22:09:57 »

осилил 5 пунктов не считая 5, все ли верно?

В такой ситуации не может быть деления на верно/неверно. Это своего рода вопрос личного вкуса, эстетики и привычек. Так что дальше - моя вкусовщина.

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

Я бы не сказал. Рыбке до Бабки вообще дела не было. Скорее, "Возврат участником Рыбка спонтанно образовавшейся задолженности участнику Дед посредством разрешения его запросов". Шутка, разумеется. С некоторой долей шутки.

3.   Рыбка – дед:

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

Бабка – дед:
Передача информации о желании.

А "подготовка агента к приему и передаче следующего желания"? (начинается со слов "Дурачина ты, простофиля!")

Дед – невод:
Закидывать.
Невод – рыбка:
Ловить.
Рыбка - невод:
Попадаться в объект невод.
Бабка – желание:
Придумывание и передача агенту дед.
Дед - желание:
Получение информации от пользователя бабка и передача участнику рыбка.
Рыбка – желание:
Получение от агента дед и исполнение.

Я бы отделил отношения участников от манипуляции объектами.
На упомянутой выше картинке, например, можно изобразить так:
"Дед" +  "->" + "Рыбка".
Стрелку подписать (например, сверху): "Передача информации о желании"
И подрисовать (например, внизу) объект "Желание".

Кстати, отношения Деда с Рыбкой я бы разделил и отрисовал двумя стрелками. Первая - "Установление доверительных отношений" - однократное, с применением объекта "Невод". Вторая - собственно, "Передача информации о желании", многократное, с применением объекта "Желание".

Бабка:
...
Приобретение статуса столбовая дворянка, статуса вольная царица.

Я бы сказал, "потребление результатов исполнения желаний". Будет более универсально.

Недовольство текущим статусом, положением и статусом объектов во владении.

Неплохой пример дуги, начинающейся и оканчивающейся на одном и том же участнике. Кольца, то есть.

---

Ну и подправить картинку. Объекты оттуда убрать, причинно-следственность починить (например, дед закидывал невод в море не потому, что бабка послала его за новым корытом).

446

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 05 Марта 2014, 21:40:08 »

Мы все поняли, чем плохи сценарии.

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

Правда, прецедент(он же вариант использования, он же способ применения) является не просто сценарием, а коллекцией (совокупностью) сценариев.

На практике я больше сталкивался с наборами разрозненных ВИ. И хорошо еще, если исключения в них были хоть как-то отработаны.

Но не очень понятна правильная альтернатива. Не могли бы Вы очертить, именно, этот подход?

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

447

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 05 Марта 2014, 21:33:10 »

Гриша, а на чем зиждется такое утверждение. Очень интересно.

Присоединяюсь.

448

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 05 Марта 2014, 21:31:23 »

... сформирует архитектуру и дизайн системы, закодирует, выполнит сборку, развернёт систему, протестирует, а потом ещё и поддержку осуществлять будет.

Считаете, это является частью работы аналитика?

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

Так и есть. Плюс/минут то, что он сам под себя загребет.

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

Вероятно. Какое отношение это имеет к тому, что я сказал?

В части проектов аналитику могут поручить только собрать, задокументировать требования и управлять изменениями требований, но не касаться преобразования (принятия решений) требований в модель анализа.

Лично Вы готовы заниматься этим до пенсии? Вы считаете, что эти занятия приведут Вас к вершинам профессии?

В случае если спецификации ВИ написаны качественно, то сценарии будут не разрозненными и неполными, а хорошо структурированными и полными.

Главное, ни в коем случае не добавлять туда новые сценарии.

Почему при мизерной добавленной стоимости работодатели согласны платить такие высокие зарплаты аналитикам?

Не следует ли спросить об этом работодателей? Хотя я бы не стал. Задумаются.
По моему опыту, работодатели сами слабо представляют, что такое аналитик и как его "готовить".

И есть ли у Вас данные о том, какое количество выпускников общеобразовательных школ обладают всеми необходимыми компетенциями для качественного сбора и документирования требований к ПО?

Нет. А Вы с какой целью интересуетесь?

Что по Вашему должно являться "вершиной аналитической мысли" вместо ВИ чтобы аналитики не "вредили себе"?

Написано в первом посте темы.

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

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

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

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

449

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 05 Марта 2014, 21:01:43 »

Мне кажется, что наличие сценариев не противоречит наличию решений.

Не противоречит.

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

Выводы и рекомендации могут быть даны в спеке, например, в виде макета экранной формы. Кто будет потребителем?

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

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

а их количество\полнота\качество не являются в итоге критерием качественно выполненной работы аналитика.

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

450

Системный Анализ и Требования / Re: Неубогий подход к труду аналитика

« : 04 Марта 2014, 23:31:50 »

Леонид, не могли бы развернуть свою мысль? Высказав концепцию правильного подхода к труду аналитика ИС, и чем плох мышления в категориях сценариев?

Спасибо

Конечно. Мысли свои, на абсолютную истину не претендующие.

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

В случае бизнес/системного анализа, информация в норме принимает форму требований к системе (например, ТЗ), а "выводы и рекомендации" - решений технорабочего проекта (или спецификаций). Важно, что именно решений, а не постановки. Это, на мой взгляд, наивысший возможный вклад аналитика в процесс.

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

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

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

Я не отказываю в праве на существование таким процессам. Иногда они целесообразны и оправданы. Но для хорошего аналитика, или желающего таковым стать, они губительны. ("В совершенстве владеете иностранным языком? Отлично, будете наклеивать марки на конверты!")
И да, я трудился некоторое время аналитиком-сценаристом. Опыт из первых рук.