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

×


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

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


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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
166
Так же спорный вопрос № 8. Я не совсем согласен с тем что сценарий это все состояния Use Case

167
Какой то спорный тест. !

168
Примеры / Re: Курсовая работа -будильник
« : 19 Января 2010, 15:58:03 »
С вариантами использования все просто (там их немного).
А по поводу диаграм состояния я бы сначала определил все множество состояний будильника, затем определися с вариантами перехода между состояниями. Так же при этом необходимо определять в каком состоянии какой функционал будильника активен, а кокой нет. Например при режиме часы - часы - вкл, радио выкл, таймер выкл и так далее.

169
У нас сейчас тоже подобная задача стоит. В данный момент выбираем из 3х вариантов:
1. TrackStudio
http://www.trackstudio.ru/
2. Bugzilla
http://www.bugzilla.org
3. Request Tracker
http://www.bestpractical.com/rt/

170
kirillss
Тогда у нас действительно хорошо отлажена трассируемость. Хотя как показывает практика, баги всплывают довольно быстро ( в следующим или через 1 релизе). Плюс существует четкая привязка аналитика к тому или иному проекту.

171
kirillss

1. Средняя труоемкость порядка 4 - 6 человекомесяцев.
2. Конкретно аналитика характеризует определенная часть от заявок на доработку. Аналитик участвует в автоматизации разных бизнес-подразделений.
3.  Не совсем понимаю что значит 'Для такой методы оценки должна быть хорошо отлажена трассируемость требования-фича-релиз-баг'. Поясните плиз. :)
4. Последствия. Наверно как и везде. Изменение в показателях KPI и как следствие этого уменьшение или увелечение размера примиальных. Других прецедентов пока не было.

172
Наверно, можно оценить эффективность аналитика по количеству запросов на изменение, вот только анализ этих самых запросов должен быть очень качественным.
LastLegion86, а можно пару уточняющих вопросов - т.е. вы анализируете каждый запрос на изменение и типизируете (дифференцируете) его. Кто участвует в этом процессе (РП, нач. отдела аналитики, ведущий разработчик, архитектор или...).
Перевести "в числовые значения" (некие абсолютные показатели) не сложно. Проблематично провести детальный анализ запросов в условиях большого числа изменений вцелом по фирме.

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

У нас релизная схема работы. То есть все изменения вводятся поэтапно. То есть, если заказчик (тут имеется ввиду сотрудник нашей фирмы который инициирует доработку, например начальник отдела закупок) хочет что - либо доработать в ИС он пишет заявку. Заявка рассматривается на предмет критичности для бизнеса. И если она кретична (какой то явный баг мешающий функционоровать бизнесу) то она сразу берется в работу (такой хот фикс), если заявка некритична (например изменилось законодательство и бухгалтерия должна перейти на другую форму отчетности к 2011 году), то такие заявки собираются и раз в 2 месяца происходит их обсуждение, в котором принимают участие заявители, начальник отдела сис. анализа, тим лид програмеров, некотороые аналитики. Там каждая заявка рассматривается, оговариваются сроки реализации (то есть этот или следующий релиз, или вообще через 2 релиза и т.д.), назначаются ответственные лица ( у нас нет PM в явном виде, часть их фукнций берет на себя аналитик, а часть заявитель. Аналитик контролирует сроки и со всеми договаривается, заказчик занимается финансовыми вопросами. ) и решается ряд других вопросов. В результате подобного обсуждения становится понятно в чем причина заявки. Вобщем как-то так :).

173
По поводу запросов на изменение...
А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов, с мотивацией - у нас бизнес процесс единый и этот объект лучший. На все наши доводы, что дайте нам хотя бы сделать экспресс анализ нескольких объектов для получения сравнительной оценки только отмахнулся.
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение. Но аналитик не виноват...
Если уж судить работу аналитика по количеству запросов на изменение, то надо брать каждый (запрос) и анализировать его природу. Трудоемкая работа.

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

174
может такая ситуация еще и повторится в ближайшее время: кризис глубже не пойдет+демографический спад 90х.

Было бы хорошо! :)

175
Насколько я понял, парню нужна что-то обучающее, а не конкретно средсво. Поэтому я и посоветовал именно BPWin, так как там есть неплохая обучалка.

176
Заполнил анкету.
Ссылка на профиль:
http://o-voronov3.moikrug.ru/
Цели:
1. Общение с профессионалами.
2. Обсуждние возникающих проблем.
3. Знакомство с интересными материалами.
4. Возможно, написание статей.
P.S. Не совсем понятка процедуар регистрации в сообществе. Я вчера выполнил необходимые требования, о судя по всему где-то ошибся. Немогли бы поподробней обьяснить?

177
Если я правильно понял, причина сомнения многих коллег относительно эффективности этого способа оценки основывается на уверенности в том, что за 3 месяца у заказчика требования поменяются в любом случае, так как он более глубоко осознает задачу по мере наблюдения за разработкой. Я раньше придерживался такого же мнения, тем более, что эта точка зрения помогает аналитику снимать с себя ответственность за большое количество чейндж реквестов на функционал.
Но в последнее время мне кажется, что действительно профессиональный аналитик, умеющий докапываться до корневых проблем, разбирающийся в предметной области, и представляющий современные технологические и бизнес - тенденции должен предвидеть (хотя бы на 90%) такие изменение требований и заранее предлагать их заказчику.
 Другое дело, что когда появляется такой человек, то он за одну зарплату долго не работает ;)

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

178
Только продукт платный:)

В универе я думае есть "бесплатная" версия :). Когда я учился у нас была.

179
Если речь идет о IDEF0, то есть смысл использовать BPWin, в нем есть отличная обучалка как по продукту так и по нотации.

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

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

вот это типичная программерская логика: "а я думал, что это не то, а это..." Елы-палы, ну мало ли кто что думал - не можем же мы друг другу залезть в мозги и поправить там нужные шестеренки.
Остается только один инструмент взаимопонимания - язык. Если пользоваться им по назначению.

В предыдущем обсуждении я нигде не говорил о багах произведенных программистами. В моем понимании запрос на изменение это определенная доработка функционала не связанная с ошибками в реализации (изменения в логике работы). А ошибка реализации, это баг ИМХО. 

Причем тут программерская логика? Да и не писал я нигде о том что я что то там думал о способах мышления других.

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

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