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

×


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

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


Сообщения - Oleg Voronov

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13
181
У меня были следующие ситуации:
1. Собеседование было назначено на одно и тоже время для нескольких кандидатов. Нужно было ждать в порядке живой очереди.
2. После начала собеседования интервьювер сразу заявил что все что я знаю "полная фигня" и имеющиеся методологии никому не нужны. У них есть своя собственная система которая самая правильная и то что я знаю некоторые технологии и методологии это огромный минус.

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


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

183
Работа / Re: Условия работы :)
« : 17 Ноября 2009, 14:22:39 »
Как то слабо представляю себе работу аналитика вахтовым методом. Все проекты строго заточены на  <=28 дней или они ждут потом еще месяц пока аналитик отдыхает? :)

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

185
О чем спор. Вариант использования описывается с точки зрения пользователя - actora. При этом следует учитывать общий контекст использования (где мы находимся, что является системой).

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

Точка зрения системы (изнутри) отражается по-моему в реализации ВИ.
Примерно это я и хотел сказать.  :)

186
Это разные действия системы по инициативе пользователя. Система ответила на запрос; система проверила и приняла/отклонила на входные данные - в чём принципиальная разница?  ???
Тогда это другая ДВИ будет.
И какая система будет внешней? проектируеамая система будет внешней к проектируемой? Оригинально  :)
Принципиальная разницамежду чем?.
Могу привести пример: Авторизация клиента. Если есть несколько клиентов, то она может выглядеть по разному. Например один клиент вводит номер пригласительного, а другой нет и т.д.

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

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

187
А можно пример?
Я вот, если грубо, понимаю ДВИ так - пользователь запросил - система выполнила. Какие тут точки зрения в ДВИ?

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

188
Вот и программист - прочитает по-русски, а поймет "так". Потом "так" сделает.

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

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

Необходимо еще устанавливать причину этих запросов: являются ли они новыми требованиями заказчика, недовыявленными аналитиком требованиями или следствиями ошибок программистов.
1. По поводу неправильного понимания программистом. У нас существует практика проверки того что написал программист аналитиком ( то есть насколько написанный функционал соответствует изначально задуманному аналитиком).
2. Речь идет не о всех запросах на изменение, а о тех случаях когда запрос поражден некорректой работой разработанного функционала ( с точки зрения логики, а не реализации), либо когда разработаннный функционал не решает поставленной проблемы ( или решает ее некорректно). Опять же, если проблема изменилась после или в течении реализации, то это не считается ошибкой.
3. По поводу стрельбы из ружья, я бы не был так категоричен. Может быть это и не самый достоверный показатель, но лучьше чем ничего.


189
Огласите плз в какой бизнес-области работаете, делаете продукт или заказная разработка, методология разработки - используется ли agile-подходы, outsourcing или внутренняя разработка? Просто интересно в каком случае такой подход работает!!!!!!

Если применять подход дословно то это презумпция виновности аналитика))))

Я занимаюсь поддержкой и развитием внутреннего решения поддержки бизнеса ( CRM + ERP + шлюз для обмена с системами бухгалтерского и склодского учета). Работаем по системе "релизов" ( я к сожелению не знаю к каой методологии можно это отнести :( ) Из оутсорсинга есть несколько интернет проектов которые обмениваются данными с нашей системой.

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

191
У нас эффективность оценивается путем подсчета заявок на доработку того или иного функционала. То есть если аналитик отработал хорошо, то функционал практически не дорабатывается первые три четыре месяца. Если анализ был проведен неверно, то как правило возникает большое колличество доработок.

192
На мой взгляд, стоит обратить внимание на уровень детализации и точку зрения, с которой строится данная диаграмма. 

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13