136

Обучение / Re: CBAP или как стать суперменом в Бизнес-аналитике

« : 23 Марта 2016, 12:16:07 »

хочется заниматься больше в сфере управления требованиями.

Что это за сфера такая? Какая от нее польза?

По поводу сертификации задумываюсь сейчас, потому что знаю, что необходимо 3500 и 7500ч практики в конкретных сферах, определенных IIBA.

Зачем Вам сертификат?

Поэтому я сейчас стараюсь получить как можно опыта во всех предметных областях БА и уже потом выбирать узкую специализацию для себя.

Можете перечислить хотя бы часть упомянутых предметных областей БА?

137

Для всех / Re: Разработки

« : 22 Марта 2016, 11:05:40 »

Это почему это не надо? Очень даже надо!

Кому надо? Заказчику или исполнителю? Если второму то, как известно, проблемы индейцев...

Неужели никто из коллег не хлебнул лиха от неграмотного, но очень самоуверенного заказчика?

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

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

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

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

Годами работаю по госконтрактам. Ни разу такого не видел.

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

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

138

Для всех / Re: Объект обследования

« : 21 Марта 2016, 17:28:59 »

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

Спросите любого сейла!

139

Для всех / Re: Объект обследования

« : 21 Марта 2016, 17:25:46 »

Помогите, пожалуйста, с его решением.

Вопрос звучит следующим образом: что такое объект обследования?

Запросто. Объект обследования - это то, что вы собрались обследовать. Организация, ангар в промзоне, редкая бабочка.

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

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

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

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

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

140

Для всех / Re: Разработки

« : 21 Марта 2016, 12:58:36 »

Да каких же продвинутых ?

Продвинутых в сторону аналитики.

Блок-схемам любых айтишнегов годов с 60х...

Так не всем же айтишниками быть. Есть и нормальные люди.

Потом UML стали учить. Но все равно любой айтишнег не спутает описание процесса с описанием структуры.

А название - запросто может. Ну, примерно как спутать справочник с классификатором.

То есть топикстартер не шарит ни в UML, ни  в том, что было до UML.

Она позиционировала себя как заказчик. Заказчику и не надо.

Так какие основания у топикстартера столь высокомерно относится к конечным пользователям

Она позиционировала себя как заказчик.

всех призывает с ней брататься, как с некоторым светочем KPMG в темном царстве госзаказчиков...

Она позиционировала себя как заказчик.

Пусть матчасть поучит...

(вздыхает) ...

141

ПО Аналитика / Re: Управление изменениями требований

« : 18 Марта 2016, 17:38:46 »

Согласна с Вами, но все же считаю, что полагаться только лишь на голову не даст 100% гарантии того, что что-то не будет упущено. Ведь человеческий фактор никто не отменят.

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

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

Голова поможет всегда. )
А вот некая проекция текущей ситуации непонятной актуальности нередко вводит в заблуждение и вызывает ложное чувство того, что "все сделал правильно".

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

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

В общем, смотрите, что ближе лично Вам.

142

Для всех / Re: Разработки

« : 18 Марта 2016, 15:51:15 »

Или Вы блок-схемой любые схемы с блоками (кубиками) называете?

Как и большинство людей, кстати. Схема есть, блоки есть. Как их еще называть?

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

143

Для всех / Re: Разработки

« : 18 Марта 2016, 11:28:09 »

Похоже, жизнь Вам дает всё без препятствий. 

Я люблю её, жизнь. И надеюсь, что это взаимно.

Вас никак не должно волновать, кому будет тяжело.

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

144

ПО Аналитика / Re: Управление изменениями требований

« : 18 Марта 2016, 11:19:06 »

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

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

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

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

Если Вы в аналитике недавно, скорее всего, возможности вашей "головы" еще ограничены. Тут уж как повезет: старайтесь, и будет получаться все лучше. А потом требовать усилий все меньше. Это нормально. Если же решите положиться на "инструменты"... Ну, пеняйте на себя, как говорится. Скорее всего, быстро получите удовлетворительный результат, но перспектив развития почти не будет. Как у современных бухгалтеров, которые разбираются не в бухгалтерии, а в том, куда надо нажать в 1С конкретной версии.

145

Для всех / Re: Разработки

« : 15 Марта 2016, 20:32:55 »

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

Эм... Шурочка, Вы только не обижайтесь. Но по прочтении приходит в голову народная мудрость "работа дурака любит". Не знают они, ага. И как работали все эти годы?

Показала своему руководству, но в итоге он лишь украл мои идеи...

Тяжело Вам будет.

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

Похоже, тяжело будет не только Вам.

Друзья! Уверена, что существуют разработки, которые позволяют считывать информацию с печатей штампов при сканировании. У кого есть такие наработки? Сколько они стоят?

Есть такая компания Элар. По крайней мере, лет 5 назад была. Всякое сканирование и прочий перевод в электронный вид "госмакулатуры" было их коньком. Поинтересуйтесь. И вообще, сейчас чуть ли не каждый первый крупный интегратор готов за нескромную сумму этим заниматься (ну, или купить для этого кого-то вроде Элара).

Давайте дружить и продвигать знания и прогресс в Госдепартаменты!

Да только "за". Дружить - дело полезное.

146

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 04 Марта 2016, 13:41:48 »

Потому что вы писали "Артефакты же ГОСТа перпендикулярны вигерсовским, поскольку ГОСТ иначе смотрит на ".

Ну вот я и говорю, какой именно ГОСТ соотносить.

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

147

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 04 Марта 2016, 13:19:23 »

Можно попунктно сравнить состав ГОСТ 19.201-78, IEEE 830-1998 и SRS Вигерса чтобы увидеть, что разница между ними чисто эволюционная, а не "перпендикулярная", что бы это ни значило.

Было бы неплохо. Только почему 19-й, когда мы про 34-й?

148

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 04 Марта 2016, 12:33:50 »

Артефакты ГОСТ 34 соотносятся с артефактами Вигерса приблизительно так же, как соотносятся АС и ПО.

Пожалуй, не соглашусь. АС включает в себя ПО как элемент системы, добавляя связи между ним и другими элементами АС для получения нужной синергии. Артефакты же ГОСТа перпендикулярны вигерсовским, поскольку ГОСТ иначе смотрит на предстоящие работы, применяет другую классификацию и, как следствие,  рекомендует иную расстановку акцентов.

Дисклеймер: вывод о вигерсовом подходе сделан на основании предоставленный выше ссылки и может не соответствовать фактическому положению вещей.

149

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 04 Марта 2016, 12:18:09 »

Правильно делают, что не читают. Вместе с тем 200+ элементов - это фактически учебная задача. ...
 
Больших слонов едят по частям - сделать что-то полезное с таким количеством элементов и их связей человек с нормальной психикой просто не в состоянии.

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

Поэтому у аналитика и есть инструментарий с репозитарием , который позволяет работать не со всей моделей на ватмане, а с отдельной проекцией, помещая в фокус именно ту часть модели, которая необходима для принятия решения.

 

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

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

Ничего не имею против осознанности. А вот попа все-таки нужна. Без попы нет усидчивости, а без усидчивости никакая осознанность не поможет съесть кусок слона на 200+ элементов.

150

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 04 Марта 2016, 12:11:54 »

Коротко она пересказывается, например, здесь: http://foranalysts.blogspot.ru/2011/08/blog-post_17.html
Картинка в статье - из книги Вигерса "Разработка требований к программному обеспечению".

Значит, будем плясать от этой ссылки.

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

а) Предпроектная документация (отчеты об обследовании*, ТЗ) может содержать все виды требований, от "зачем это надо вообще" до "тут нужно кодить исключительно на турбопаскале, потому что у заказчика лицензий к нему немеряно и люди натасканы".

* Отчеты обычно не содержат требующих формулировок, но являются источником требований. Это когда их делают, что бывает относительно нечасто.

Что касается ТЗ, то хоть п.1.4 ГОСТ 34.602 провозглашает "Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений", но как правило, искать решения нужно в отведенных границах. Или вокруг неких констант, забитых гвоздями низкоуровневых требований. Например, если одна из основных задач создаваемой системы - служить источников данных для другой системы, которая умеет переваривать только csv-файлы, то самые замечательные и современные xml-технологии будут неактуальны.

В целом, в предпроектной документации акцент смещен в сторону высокоуровневых требований.

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

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

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