Форум Сообщества Аналитиков

×


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

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Юрий Булуй

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
316
У вас в вашей диаграмме показано как плодяться параллельные процессы ... это так и должно быть? Неужели одновременно идет "передача параметров запроса" и "прием параметров запроса" и еще третий в добавок???
В первом распараллеливании, не понятно что происходит после "Действия администратора" с этой веткой ... она заканчивается? Система при этом изменяет свое состояние???
А что обозначает стрелка идущая от "Установка флага запроса Е в 1" в стрелку "соединение отсутствует"????

Вывод - помимо синтаксических проблем, похоже есть еще и семантическая ...

317
Вопрос (опрос) адресован персонально аналитикам, а не работодателям. Думаю, что вопрос можно было бы сформулировать следующим образом - Какие из навыков вы считаете наиболее востребованными в работе аналитика (в процентном отношении):
1. Коммуникативные навыки (эффективное межличностное общение с заказчиком и разработчиками);
2. Знание предметной области
3. "Системный подход"
4. Навыки документирования

Надо бы только пояснить что есть системный подход ....

318
Денис, не ты один работал фрилансером :-). Я бы не стал называть рынком ситуацию, когда заказчики приходят через знакомых ... это не MLM все-таки ... А в рост рынка нужно инвестировать - есть очередь из желающих? Я собственно вопрошаю о тех самых преимуществах, которые заказчик может получить от "проектного подряда аналитика" ... хотел бы ознакомиться с "аргументами для инвестора".

319

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

Строго говоря - ТП это СТАДИЯ по ГОСТ 34.601, а не документ ... т.к. на этой стадии создается целый ряд документов. Более корректно вести речь о "документации ТП".

320
>>> Заказчики по-видимому должны быть очень серьезными, учитывая стоимость инструмента
К сожалению, как это часто бывает, интерес заказчиков значительно угас после завершения процесса внедрения SA. Под проект средства выделяются, а вот под поддержку и развитие... И временами интерес лишь появляется перед аудиторскими проверками, когда хочется нажав одну кнопку узнать, а что же у нас есть? Ведь у нас есть SA и там все должно быть. Не понимают лишь того, что если в SA не внести инфу, то это только и останется - скелет, пусть и прочный, но лишь скелет. И в очередной раз повторяется - какая неуклюжая и бесполезная система :)
К сожалению не помогают в достаточной степени и регламентирующие документы и "посылы" к ITIL, что так "НАДО ДЕЛАТЬ" и так делает весь цивилизованый мир. Уффф... :) Эмоции, короче.
Юрий, а что такое Archimate? Не сталкивался ранее с подобным термином, а переводить в гугле некогда. В двух словах можете обрисовать?

1. SA - это всего лишь инструмент. Если нет рядом людей и процесса, обеспечивающих актуальность моделей (а соответственно и целей, для чего нужно обеспечивать актуальность моделей), то он так и останется просто инструментом и ни чем более... У вас в организации нет людей, ответственных за EA и процессы в области ИТ? Если есть - то это их задача, чтобы были соответствующие их целям модели ... и они должны наполнять контентом репозитории инструментария.
2. www.archimate.org ... если совсем коротко - то это  UML-based язык для моделирования EA.

321
Полностью согласен. К тому же, есть ещё принцип KISS. Переусложнённые процессы и инструменты, а также сложные люди :) , обычно хуже работают и чаще ломаются.

TSA в большей степени относиться к EA, а не к чисто разработке софта ... этот факт следует учесть. А сложность и "подробность" модели EA должна быть адекватна задачам, которые организация собирается решать при помощи EA. Очевидно, что незачем городить огород с EA, если используется 1С и MS Office ...

322
Сходил в interface.ru на семинар по этому продукту. Доклад делал  представитель телелоджика Тупчиенко Сергей.
Действительно мощный продукт, но графики ему не хватает. Очень неудобно и некрасиво. Если сравнивать с продуктами Microsoft по красоте интерфейса, то это мягко говоря-уродство :(


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

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

1. С каким именно продуктом MS идет сравнение? Если речь о Visio, то это в большей степени рисовалка, а всю логику приходится все равно выносить в Excel (матрицы связей и т.п.). IMHO сравнение не вполне корректноктное на мой взгляд. System Architect более мощный инструмент и предназначен несколько для иного, чем Visio.
2. К GUI привыкаешь к любому ... и через месяц активного использования он уже не кажется таким уж неудобным. Более корректно на мой взгляд говорить об соотношение В КОНКРЕТНОМ СЛУЧАЕ м/у стоимостью инструментария и пользу, которую он может принести ...
3. Пример, который привел Сергей - этот лишь частный случай пользы, которую может принести EA (Enterprise Architecture) как таковая. А System Architect - это в первую очередь инструмент для создания и поддержки модели EA, хотя конечно его можно использовать и в других целях.
4. Компаний, в которых ИТ подразделения до конца не знают всего набора используемого софта и его связи м/у собой и степень пользы, который он приносит бизнес-подразделениям, а уж тем более планирующих развитие ИТ синфазно с развитием бизнеса - ооооочень много ... А крупных контор, в которых используется большое кол-во разнообразного ПО в России немало - от Газпрома и его дочек, до банков ...  так что не одним РЖД :-).

Вот чего действительно не хватает TSA - так это поддержки Archimate ... или уже есть?

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

324
Еще один стартап. На самом деле есть определенные сомнения по поводу поиска именно аналитиков через такие ресурсы. Т.к. крупные заказчики вряд ли так будут работать, а мелкие редко понимают зачем нужен аналитик, которому еще и деньги платить нужно ...
Деньги на ком ресурс будет зарабатывать?

325
"Пара бывших прапорщиков угробит любой ISO, внедренный на предприятии" (с) byur :-) ... Саша - можешь меня в статье цитировать!

326
И все-таки он Якобсон, а не Джекобсон ... и Ивар, а не Айвар :-) ... это все американцы на свой манер хотят скандинавов называть :-). Так же как и Крухтен, а не Кратчен :-) ....

327
Если в 2х словах - заказчик еще сам не знает до конца все свои хотелки; нужен аналитик, который выяснит до конца желания заказчика.

Аналитик должен выяснить реальные ПОТРЕБНОСТИ заказчика ... а желания заказчика могут иметь поистине фантастический размах :-)

328
Эд, невзирая на то что я тебя поздравил по телефону, тем не менее позволь и тут пожелать тебе всего самого наилучшего!

329
Обычно кого назвали архитектором, тот и есть. То есть у всех по своему.

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

Один комментарий ... Архитектура - это собственно структура и связи. А их описание - это architecture description.

330
<
Набор букв, а не пост. Первая половина вообще не понятна, но если ты разобрался, то опустим ...

Про CASE средства:Эти критерии вообще к CASE средствам не относятся. Это критерии средств управления проектом.
ClearCase- это средство версионного контроля как CVS или SVN.
ClearQuest - это средство управления запросами на исправление ошибок (bug\issue tracker), как BugZilla или Jira

Более правильно позиционировать CQ как средство управления изменениями вообще, а не только как defect management

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »