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

×


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

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


Сообщения - davvol

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 »
166
А сейчас какой софт используется?

Для описания бизнес-процессов я бы порекомендовал нотацию BPMN и Bizagi Process Modeler как инструмент работы с ней, т.к. он удобный и бесплатный.

Или обязателен именно UML?

167
На мой взгляд - просто караул.
......

Ну или я такой мамонт.
Все как в реальности:)))
Выпустится студент и кто знает в какую контору и команду он попадет? Будет готов:)


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

Наблюдал такое частенько. У нас забороли это через тестирование. Т.е. тестировщик не просто проверяет некий абстрактный функционал на работоспособность, а в первую очередь на соответствие его ТЗ и требованиям заказчика.

По теме:

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

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

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

ЗЫ: В данном случае на мой взгляд поведение заказчика совершенно естественно и оправданно.

168
Видимо улучшение по всем трем составляющим, как писали ранее

ИМХО на стороне проекта, а у проекта есть 3 составляющие: качество, сроки, бюджет.

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

169
В данном контексте "сторона" - это набор потребностей, интересов и ограничений конкретного участника проекта.

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

171
Для всех / Re: Шаблон требований
« : 01 Марта 2013, 13:14:26 »
Для каждого документа свой.

Если речь идет об опроснике, то минимальный, тот который будет понятен заказчику. Т.е. бизнес-требования, нефункциональные требования и набор вариантов использования (или истории пользователей).
Это то что ляжет в основу ТЗ.

Если речь идет о ТЗ, то уже детальные требования, которые сделаны на основании опросника и бесед с заказчиком/пользователями заказчика. И уже их вы и будете согласовывать с заказчиком.


172
Для всех / Re: Шаблон требований
« : 01 Марта 2013, 12:54:13 »
Нет, вы меня неправильно поняли. Никаких тетрадок и надежд.
Все должно быть последовательно, записано в документы и согласовано.
Сначала видение продукта. Это отдельный документ, в котором описывается что и зачем мы вообще затеваем.
Потом аналитик делает сбор требований. В том числе и с помощью обсуждаемого шаблона.
Затем аналитик выявляет требования из того что собрал от заказчика, из его "хочу/не хочу, это не это и т.д."
Аналитик готовит ТЗ в котором указывает все требования к разрабатываемой системе.
Если ТЗ согласовано с заказчиком - за дело берутся разработчики, которые решают какая архитектура удовлетворит требованиям (а не наоборот), какие реализации сделать, и т.д.

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

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


Еще раз кратко что я хотел сказать прошлым постом: Такой шаблон - лишь малая часть работы аналитика. Весь процесс сбора требований им не заменишь.

173
Для всех / Re: Шаблон требований
« : 01 Марта 2013, 12:17:11 »
Чем больше всего разного - тем выше энтропия. Чем глубже кинетесь в детали - тем больше шанс упустить действительно важное.
То что вы даете заказчику, должно быть целиком и полностью ему понятно. И написано ему простым человеческим языком.
Зачем ему документ где он не сможет ответить на 80% вопросов?
За вас заказчик ТЗ не напишет:)

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

Если же нужно "стандартизировать и формализовать процесс сбора требований", то одним шаблоном весь процесс не заменишь. Как ни крути, придется и лично общаться с заказчиком тоже.
А вот как часть процесса - такой шаблон вполне.

174
Для всех / Re: Шаблон требований
« : 01 Марта 2013, 11:46:31 »
Добрый день!
Мне кажется вы в этом документе спихнули в одну кучу вообще все документы с которыми только может работать аналитик.
В такой каше клиент точно не разберется, и выявить требования у клиента с ним не выйдет.

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


175

Аналитик не занимается нефункционалом, он пишет Биз треб - "Система должна открываться за 2 сек макс, в 50 городах страны, 24/7 ", а Архитектор с Тимлидом и ПМ решают на какой СУБД, каким железом и есть ли канал 10 мбит на Камчатке.
По моему, то что вы перечислили - это и есть нефункциональные требования, которыми по вашему аналитик НЕ должен заниматься. Т.е. требования к надежности, производительности, обслуживанию и доступности системы.
Или вы под "нефункциональными требованиями" подразумеваете что-то другое?

Цитировать
И аллерт кстати пишет тим лид, потому что Аналитику побарабату на Шарепоинте или на Е-бизнессьюте будет документооборот писаться, это решают на концептуальном уровне основываясь на инфу аналитика.
А откуда инфа у аналитика, если ему "побарабану" в каком окружении у клиента будет использоваться продукт?
Откуда тимлиду вообще узнать где и какие алерты должны быть? Непонятно:)


176
Как должно быть:
Аналитик - Описывает как хочет работать Заказчик....

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

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

Заказчик может много о чем не попросить и умолчать, потому что сам считает:
1. Ну это же само собой разумеющееся! Все это знают!
2. Ну вы же умные, вам виднее.

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

177
Смущают ВИ "Получить книгу" и "Вернуть книгу" у Клиента. Ведь при этом он не взаимодействует с системой.

178
UML SysML и пр. / Re: В каких случаях UML вреден?
« : 20 Февраля 2013, 09:36:18 »
Очень интересно. Каким образом вам удаётся сделать это с помощью UML?
Я один раз столкнулся с ситуацией когда одна ДВИ нарисованная за час в Rational Rose совершила прорыв в переговорах, находившихся в тупике уже несколько недель. Она предельно наглядно выявила точки непонимания между заказчиком и подрядчиком и буквально за пару дней все вопросы были решены и дальше дело пошло хорошо и без UML.

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

179
UML SysML и пр. / Re: В каких случаях UML вреден?
« : 19 Февраля 2013, 17:03:17 »
Лично мое мнение такое. UML очень полезен когда надо развеять "туман войны" над разрабатываемым продуктом. Когда при минимуме затрат нужно максимально охватить структуру и реальную желаемую пользу от разработки, показать заказчику что мы понимаем, какой продукт ему нужен и что мы сделаем то что надо.

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

180
UML SysML и пр. / Re: Почему вам не нравится UML?
« : 19 Февраля 2013, 10:31:33 »
Сама постановка вопроса мне кажется странной.
То же самое что и "Почему вам не нравится гаечный ключ?"
Не нравится ключ, бери отвертку.  Аналогично с UML.

Может дело в применении? Что если не пихать UML куда надо и не надо, то и не тупик совсем?:)


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