Просмотр сообщений

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

Очень мало знаком. В последний раз копался и программировал в 1С в 2000 году. Но чутье подсказывает, что единичное приложение (т.е. exe-файл со своим "обвесом") из набора 1С имеет только одну архитектуру. Решение на нем - другое дело.

1. что такое ФЛК?

Форматно-логический контроль.

2. к какому из 7 перечисленных пунктов + само задание это относится? Как кто-то вне вашегго понимания задачи сумеет догадтся о ФЛК и потребности проверки?
Об этом следует догадаться. КАкие рассуждения должны привести студента к данному (думаю важному ) моментуХорошо, но сможет ли студент догадаться это учесть?

И остальное в ключе "не следует из постановки".

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

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

Логически можно вывести, но мне например в голову не пришло.

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

А в чем различие двух рисунков, я не заметил

Его нет. Закоммитил по криворукости два раза. Как убрать лишнюю - не знаю.

про этот формат мы можем догадаться из постановки, хотя есть и формат xlsx

Да и тот, наверное, не формат, а целое семейство форматов (хотя бы по версиям "офиса"). Но на уровне архитектуры это не важно. Важно, что формат данных как-то определен.

Почему именно три, как определить, что трех достаточно

Опыт (три года работы и руководства таким отделом). Для эффективного решения задач в "горячие дни" потребуется два человека при условии, что большая часть "посылок" пройдет автоматом. Третий сотрудник - страховка на случай больничных, отпусков, декрета. Ну и в помощь, разумеется.

Цитата: Курашов Юрий от 31 Марта 2014, 17:28:23

Какова его методологическая основа?

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

423

Вакансии / Re: Нужен Системный аналитик (Санкт-Петербург)

« : 31 Марта 2014, 18:30:43 »

Уважаемый Леонид,
Большое спасибо за проявленный интерес к нашей вакансии «Системный аналитик».
Готов буду детально обсудить ее с Вами по телефону. /8(812)313-93-80/

С наилучшими пожеланиями,
Курашов Юрий
Старший рекрутер

Юрий, я нахожусь в Москве и переезд в ближайшее время не планирую. Так что по прямому назначению эта вакансия не для меня.
Если же интересно обсуждение с точки зрения формулировок и поиска специалиста - можно прямо здесь. Думаю, население форума подключится и подскажет, как и где лучше искать нашего брата. Опять же, дискуссия может пригодиться и другим рекрутерам/соискателям.

424

Вакансии / Re: Нужен Системный аналитик (Санкт-Петербург)

« : 31 Марта 2014, 16:28:41 »

Ну, раз "будете рады" откликам, то вот...

- Ведение проектов в соответствии с методологией Управления Проектами;

Системному аналитику?

- Участие в проектировании, кодировании и тестировании систем;

Кодировании?

- Внедрение системных изменений для экономии работ по разработке и поддержке;

Даже боюсь себе представить...

- Обеспечение быстрого и эффективного устранения проблемных ситуаций.

Еще больше боюсь.

Пожелания к кандидату:

Да, типичный набор навыков аналитика.

Компания предлагает:
- Питание и спецодежда;
- Страхование жизни.

Совсем другое дело. Уже боюсь чуть меньше. А если спецодежда еще и веселенькая...

Рекрутер Екатерина (если я правильно перевел Ваше иностранное имя), кто ж у вас такие описания вакансий составляет?

P.S. Комплект из спецодежды, страхования жизни и "быстрого и эффективного устранения проблем" так и подталкивает поинтересоваться: со своим оружием приходить, или на месте выдадут?

425

Обучение / Re: Задания для проектирования архитектуры ИС

« : 31 Марта 2014, 12:11:29 »

Обыгрываются какие указанные материалы? Учебный кейс?

По первый ссылке на яндекс. Там, где куча презентаций.

Вы можете глянуть, если интересно из "первоисточника" http://yadi.sk/d/27r1YiWFGNgSr.

Глянул. Поплохело. Детей жалко.

Спасибо за пример. Интересно было бы посмотреть на ваше решение Хотя бы схематичное.

Я бы например решил задачу просто через google.docs, ну или, если имеется сайт, то можно наладить ftp сервис.
Если 5 % филиалов не имеет подключения, то они никак не могу передать отчетность. Если же у них есть телефон, то значит они могут отправить данные по модему.

Хорошо. Ниже.

Также, а что значит "действовать"?

Приступить к решению задачи.

Цитата: Galogen от 29 Марта 2014, 17:18:04

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

Если вести речь про архитектуру отдельного приложения - наверное, да. Хотя зачем ее вообще вести, если приложение уже есть (1С, например), непонятно. В этом случае ей надо просто правильно воспользоваться. Я же скорее говорю об архитектуре решения в целом.

Один из вариантов решения.

1. Для сбора отчетов будем использовать:
а) Корпоративный сайт (разработаем и встроим в него свои формы).
б) Электронную почту.
2. Все присылаемые отчеты будут проверяться на соответствие правилам ФЛК.
3. Отправитель будет уведомляться о результатах приемки отчета (когда получен, каковы результаты ФЛК, принят или нет):
а) если отчет подавался посредством сайта - то прямо на сайте и письмом в почту;
б) если отчет подавался по почте - ответным письмом в почту.
4. Для идентификации отправителей используем:
а) данные учетных записей на сайте;
б) адреса корпоративной почты.
5. Создадим механизм контроля, которая позволит показать на любой момент времени (включая текущий), кто и когда сдал (или не сдал) отчет за заданный период. Механизм потребуется для:
а) действий персонала по обеспечению собираемости отчетов;
б) контроля исполнения распоряжения первого лица компании "О предоставлении отчетности форм А, Б, Ц" от ....
6. Создам механизм статистической (нарастающим, по территориальному делению и т.п.) и аналитической (сравнение с АППГ, корреляция, экстраполяция и т.п.) обработки собранных отчетов.
7. Для обеспечения корректности расчетов и отображения исторических данных, создадим механизм ведения реестров филиалов (когда открыт, как назывался и переименовывался, кому подчинялся, когда был закрыт и т.п.).

Архитектура на рисунке. Зеленым - создаваемые компоненты решения.

Модуль Парсинга должен:
- Проверять указанную почту на предмет получения отчетов в формате xls.
- Принимать отчет с сайта в виде xls.
- Принимать отчет с сайта в виде xml (из формы, заполненной непосредственно на сайте).
- Управлять очередью обработки отчетов (отчеты, поданные через сайт, обрабатываются в режиме реального времени, почтовые - в остальное время).
- Проверять отчет на соответствие правилам ФЛК.
- Формировать и отправлять результаты обработки отчета:
а) в виде электронного письма по шаблону на адрес электронной почты, связанный с отчетом;
б) в xml для вывода на сайте.
- Сохранять принятый отчет в БД.

Модуль Парсинга взаимодействует с Формой ввода/загрузки отчета на корпоративном сайте.
Форма должна позволить пользователю:
1. Приложить и отправить отчет в виде xls-файла (идентификационные данные отправителя передаются в Парсер автоматически).
2. Заполнить отчет в онлайн форме и отправить его.
3. Получить ответ о результатах обработки в режиме реального времени.

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

Интерфейсом модуля Контроля является страница на корпоративном сайте.

Модуль ведения НСИ...
1. Ведение реестра филиалов.
...

Модуль статистики/аналитики...
...

5% неподключенных филиалов будут передавать отчеты:
- Посредством передачи файла с отчетом на отторгаемом носителе в ближайший филиал, который может его отправить одним из перечисленных выше способов .
- С применением домашнего подключения сотрудников к сети Интернет.
- Факсом.
- По телефону под диктовку.

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

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

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

426

Обучение / Re: Задания для проектирования архитектуры ИС

« : 29 Марта 2014, 18:53:21 »

...
Я же и обратился сюда за конкретной, а не теоретической помощью. Мне не только совет хотелось бы получить, мне бы хотелось получить исходные данные для решения задачи.
Здесь я разместил небольшие разработки http://yadi.sk/d/idePSkO0LPBw3.
...

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

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

Собрать несколько комплектов условий, приближенных к реальным и отправить студента "действовать".

Например:

---
Компании А требуется наладить сбор важной еженедельной отчетности установленных форм из своих филиалов в центральный офис в столице.
Сведения о компании:
1. У компании большой бюджет на создание решения, но на дальнейшее сопровождение он будет очень скромным.
2. Количество филиалов на текущий момент 315, в следующем году планируется открыть еще 112.
3. У компании есть избыточное количество лицензий на серверное ПО и СУБД от Майкрософт (закупленное для другого, провалившегося проекта).
4. Каналы связи у филиалов следующие: 50% - 1 гигабит и более, 25% - 512-256 килобит, 20% - 33,6 килобит, 5% - не имеют подключения.
5. ИТ-службы у компании есть только в 1/3 филиалов, в основном - в крупных городах.
6. У компании есть веб-сайт с форумом для своих сотрудников.
7. Отчетность в филиалах компании ведется в Excel.
Задание:
Предложите архитектуру информационной системы для решения задачи компании и обоснуйте его.
---

Цитата: Galogen от 29 Марта 2014, 17:18:04

1. все-таки разработка программной системы с нуля с использованием каких то универсальных языков разработки - это одно, а разработка приложений или ИС с использованием платформ и фреймверков типа 1C, Sap, Axapta и т.п. - это другое. Конечно есть общее, но имеющиеся в литературе и общем доступе методики все-таки ориентированы на разработку структуры классов, распределение ответственностей, т.е. по сути разработки архитектуры системы под создание ее средствами универсальных языков, а вот как при этом конструируются системы с использованием готовых компонентов, платформ - информации меньше и менее понятно как это все применять

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

427

Обучение / Re: Задания для проектирования архитектуры ИС

« : 29 Марта 2014, 15:23:02 »

Цитата: Galogen от 28 Марта 2014, 20:43:48

В закромах нарыл вот такие задания, у кого какое мнение?

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

А что от студента ожидается на выходе? В какой форме?

428

Обучение / Re: Задания для проектирования архитектуры ИС

« : 29 Марта 2014, 14:00:34 »

Цитата: Galogen от 28 Марта 2014, 20:33:58

Леонид, спасибо. Правда, если честно, не совсем понял всех нюансов Вашего уточнения.
1. О перспективах - да я понимаю, что можно (и нужно) включить определенные вводные, которые могут быть (или должны) отражены в соответствующем решение. Вы это имеете в виду?

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

а) "Не уместились в рамки проекта" - тут все просто. Например, хотелок у заказчика на 12 модулей, а времени и денег - только на 6. Но пока мы будем делать эти 6, заказчик подумывает раздобыть еще денег. Поэтому мы в архитектуре учитываем, что "дружить" между собой придется 12 модулей, а не 6, как сказано в ТЗ текущего контракта.

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

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

* не будем рассматривать случай, когда ИС создается по требованию "то же самое, но с зелеными кнопками".

Цитата: Galogen от 28 Марта 2014, 20:33:58

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

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

----
В целом, я не знаю, как довести эти идеи до студентов. И надо ли. Но на практике п.2 играл решающую роль наверное более чем в половине проектов, которые я наблюдал. А "хороший" архитектор отличался от "посредственного" тем, что учитывал п.1.

429

Обучение / Re: Задания для проектирования архитектуры ИС

« : 28 Марта 2014, 19:06:33 »

Цитата: Galogen от 28 Марта 2014, 17:11:26

на входе типично нужны Потребности заинтересованных лиц и Системные требований (по крайней мере по требований методики harmony и других), методика ADD (attribuite driven development) требует на входе списка функциональных требований, проектных ограничений и атрибутов качества.

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

430

Системный Анализ и Требования / Re: ТЗ на АС. 3.Характеристика объектов

« : 15 Марта 2014, 00:22:14 »

Цитата: Galogen от 14 Марта 2014, 20:41:39

Посмотрите пример здесь. Надеюсь, это поможет сделать правильный вывод

В примере есть ляпы. tanya, обратите внимание.

Конкретно в 3-м разделе:
1. Объект автоматизации путают с предметом (встречается сплошь и рядом).
2. Включать в перечень нормативно-правового обеспечения Конституцию - забавно, но совершенно бессмысленно. Бессмысленные положения ТЗ могут раздражать Заказчика.

Чуть выше, во 2-м:
1. Цель "Замещение существующей информационной системы" на грани фола. Балансирует между "целями" и "задачами". А прилагающиеся к ней "оправдания" в этом разделе неуместны.
2. "Ввод данных реестров" и "Редактирование данных реестров" - не задачи, которые будет решать бизнес, а функционал Системы. Вместо них было бы правильно указать "Ведение реестров".
3. Рассогласованность в перечислении задач "Ввод..." и "Интегрироваться..." подтверждает небрежное отношение авторов к документу (так что всецело полагаться на него не стоит).

431

Системный Анализ и Требования / Re: ТЗ на АС. 3.Характеристика объектов

« : 15 Марта 2014, 00:05:09 »

Цитата: tanya от 14 Марта 2014, 18:04:21

Могу ли я перечислить в разделе 3 (ТЗ) не только уже имеющиеся, но и разрабатываемые объекты (подсистемы)? Желательно ответ подтвердить стандартами.

Только в том случае, если разрабатываемые в данный момент объекты (подсистемы) не входят в рамки ваших (Исполнителя) работ. Т.е. разрабатываются кем-то еще, влияют на ваши работы, а потому вам в своих планах нужно это учесть.
Раздел 3 нужен для того, чтобы рассказать, в каких условиях придется "творить".
Подтверждение - сам стандарт (ГОСТ 34.602-89).

432

Бизнес-анализ и Целеполагание / Re: Выявить объект и предмет исследования.

« : 12 Марта 2014, 15:57:48 »

Уточню, что имеется еще. Архив на самом деле уже готов, так что время для написания введения выбрано верно.

Не Архив готов, а диплом. Но в целом - тут на вкус и цвет.

Система делалась для Белстата - Национального статистического комитета Республики Беларусь. Он может выступать в качестве объекта исследования?

Может. Но лучше уточнить, какое именно его подразделение (если, конечно, его не автоматизировали весь оптом).

В архиве каком? В старом (бумажном) или в новом, электронном?

Смотря что Вы "исследуете". В данном случае можно исследовать:
1. Процессы в старом архиве на предпроектном этапе.
2. Комплекс новых (разработанных) процессов на предмет их адекватности назначению, целям и задачам объекта автоматизации ("исследования"). Причем как теоретически, так и практически в период опытной эксплуатации.

Цитата: Dimonbek от 12 Марта 2014, 13:12:53

Делается диплом по технической специальности. В таком дипломе введение что ли не должно содержать данные пункты?

Я бы предложил согласовать этот момент с дипломным руководителем. Если предмет самого диплома не исследования, а вполне конкретная разработка - то может быть, так и стоит в нем писать? Будет заметно меньше неопределенности. Другое дело, что практика Вуза может требовать в дипломе именно таких формулировок. Не спросишь - не узнаешь.

433

Бизнес-анализ и Целеполагание / Re: Выявить объект и предмет исследования.

« : 12 Марта 2014, 14:44:18 »

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

Объект исследования - Архив. Может быть представлен в виде организационного подразделения госконторы (или совокупности подразделений). А можно без детализации, но вплоть до указания адреса: "Архив Управления архивов и фондов Госминтрестпрома, расположенный по адресу г.Какой-то, пр.Ленина, д.3".

Предмет исследования - процессы, которые происходят в Архиве.

Только почему "исследования"? Работы проходят как НИР/НИОКР?

Да, и один совет. "Введение" нужно писать в последнюю очередь. Когда станет понятно, что получилось.

434

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

« : 10 Марта 2014, 19:31:42 »

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

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

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

То есть, латентная методология жила себе и помогала жить другим в какой-то вполне определенной среде: культурной, традиционной, языковой, корпоративной, профессиональной, кадровой и т.д и т.п. Как-то во всем этом работала. Затем ее оттуда вынули, дистиллировали, формализовали и выдали на гора. В результате этого процесса она потеряла свои корни и питательную среду. И из пышно зеленеющего где-то древа превратилась в сухую универсальную теорию.

Они по сути так и называются - практики.

По моему глубокому убеждению, практики - они на реальном предприятии. Буквы внутри обложки - это теория и советы. Что бы при этом ни было написано на обложке.

Тот же RUP - это не теория - это практика.

В IBM - вполне возможно, не видел. Хотя в последние годы, судя по зверинцу и содержанию продуктов, у них не RUP правит бал, а маркетинговое "скупим всех". А как там эти "все" работают - кто ж их знает? (да и кому вообще это надо, работают - и ладно).

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

Вот. И так - практически везде. "Практически" говорю потому, что оставляю ничтожно малую вероятность, что кто-то все-таки умудрился выстроить у себя "настоящий" RUP, Agile или какой другой MSF (не исключено, что на свою беду).
Отсюда мои выводы.

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

Аминь. То, что они внедрили, и есть практика. А то, с чего внедряли - теория и рекомендации.

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

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

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

Не получается.

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

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

Скорее всего Вы имели в виде вовсе не это, но что тогда? Ваш личный опыт, Ваше личное наблюдение?

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

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

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

Может проблема масштаба?

Не понял вопроса. Можно пояснить?