Petro123странно:
У Вас у аналитикиков есть какие-нибудь программные средства для:
- понимания их работы руководством (наглядность графиков/схем и т.д.)
- постановки задачь программистам и разговора с ними на одном языке (UML например) Аналитики у нас не занимаются дизайном. Они собирают требования и оформляют их в виде SRS и др.документов (концепция, иногда спецификация юз-кейсов, иногда описание бизнес-правил).
- документирования прошлой работы и проектов (если уволят Аналитика).[/quot]

У нас по каждому существенному проекту на доработку\разработку аналитик оформляет Концепцию и SRS (опционально спецификация юз-кейсов и документ с бизнес-правилами). Это обычные документы в Word'е. После закрытия проекта они помещаются в архив (шарепойнт).

Дизайном(UML) у нас аналитик не занимается.

Руководство может почитать концепцию, если его интересуют проект. А может и всё остальное, если проект его очень сильно интересует.

Ещё существует баг-трекер, где есть информация о мелких доработках.

Такая схема работы обуславливает проблемы , которые и хочется решить.

ПробегалМимо.составить документ "РУКОВОДСТВО РАЗРАБОТЧИКА" чтобы вновь пришедший в компанию разработчик смог приступить к проектированию прикладной системы использую данный конструктор.
Ищется НЕ руководство разработчика. Ищется способ для аналитика не пересобирать требования заново.


andbaryЯ поступаю следующим образом: Использую Sybase PowerDesigner и рисую все основные процессы (бизнес процессы) в этом средстве с комментариями в каких местах этот процесс применяется и формулы используемые для расчетов.

Подчеркну! Гарантировать истинность нарисованных схем, не сможет никто...
Возможно я ошибаюсь, но разработчик не сможет работать по схеме бизнес-процесса - другой уровень абстракции. В своё время пробовали- очень много чего остаётся в голове аналитика. Для разработчика нужно писать SRS. И наоборот, если в схему бизнес-процесса запихнуть требования уровня детализации SRS, то никто не будет читать такую схему - это будут макароны.
Собственно потому их(схем) истинность очень сложно гарантировать.

Я вижу свою задачу так - найти способ так организовывать SRS, Концепции, бизнес-правила, записи из баг-трекера, юз-кейсы, (при помощи ВолшебногоИнструмента???), чтобы минимизировать повторный сбор требований. Возможно, конечно, не правилен сам подход. Тогда ситуация серьёзней.

KGP модЯ отношу их к разработчикам. Т.е. им исходники в зубы и вперед - анализируйте. Жестко , а налитики работают у вас сразу в код? В вакансиях это часто называется аналитик-программист

Petro123Либо вместо аналитиков - секретари или бухгалтеры, которые не могут мыслить ООП (нарисовать схему в виде классов UML). А могут только бумажки собирать и в Word'e печатать.
Я не секретарь и не бухгалтер. Я аналитик. Есть определённая дисциплина управления требованиями к ПО. Этим занимаются аналитики. Насколько я знаю, это достаточно обычный подход.
Перекладывать управление требованиями на разработчиков - для нас это пройденный этап.

Petro123 кто занимается архитектурой проектов/разрабатываемой_системы?. Разработчики. Это их ответственность. У разработчиков свои методы документирования и свои проблемы. Имхо это оффтопик.

Petro123
IMHO видел где-то прогу, которая помогает аналитикам вместо Word'a вести документирование своего процесса и " трассировать требования " (это их термин).
Вы о Requisite Pro? Смотрели, имхо она подходит для сбора требований одному большому проекту (возможно я ошибаюсь). А тут ситуация в том, что есть много маленьких и средних проектов и надо раскопать и повторно использовать ранее собранные в д_р_у_г_о_м проекте требования.

Сейчас вырисовываются
либо какие-то околобиблиотечные темы : рубрикатор, поиск, ключевые слова

либо вики

либо МатьВсехSRS, которая обновляется после завершения каждого проекта и проектика

andbary bebopВозможно я ошибаюсь, но разработчик не сможет работать по схеме бизнес-процесса - другой уровень абстракции. Если у вас разработчики, а не кодеры, то должны! Разработчик должен уметь "ставить задачи", следовательно разбираться с БП. Чтобы не зависеть от конкретных людей, рассчитывать надо на кодеров :).

andbaryУ Sybase (и не только у этого ПО) есть вложенность, поэтому проблемы с данными макаронами (излишней детализацией) не вижу.

ОК, возможно это тоже вариант. Вы практически делали требования уровня SRS в PowerDesigner'е? Или всё-таки у вас несколько другой процесс разработки, с разработчиками-полуаналитиками?

А вообще интересная вырисовывается картина.

В одних местах
чистые бизнес аналитики сотрудничают с полуаналитиками-разработчиками (andbary)

в других местах
аналитики делают архитектуру и дизайн за разработчиков (petro123)

наша организация получается где-то посередине

мод KGPЖестко , аналитики работают у вас сразу в код?
Жестко - но таково требование времени - без посредников надежнее.
Во времена ассемблера было разделение труда - постановщики - кодеры. Во времена IDE кодирование превратилось в рутину, т.е. если все правильно спроектировано, то закодировать - последнее дело и отдавать это кодерам = похоронить проект. Более того - само проектирование лучше сразу делать в IDE.
Бывают и такие подходы. Я в курсе.
Лучше от этого бывает не всегда
И вообще, мы не можем сделать, как вы предлагаете. Начальство не поймёт.

мод grexhideИтого - аналитик - никому, как испорченный телефон - на самом деле не нужен, даже вреден.
Именно так и есть. Вообще само понятие появилось не так давно (интересно - откуда).
ps. У нас были постановщики - не программисты, но они изобретали чистые мат. методы.

Внесу 5 коп в тему. Аналитик вносит элемент НормальныхДоговорныхОтношений в процесс разработки. Заказчик не умеет читать ЮМЛ и АРИС. А если умеет, то в конфликтной ситуации скажет, что не умеет. Заказчик умеет читать договора. Спецификация - это договор между командой и заказчиком, понятный обеим.
Это общепринятая практика.

Пока разработки мало, всё так как утверждают уважаемые мод и grexhide. Когда пара проектов проваливается из-за того, что требования нигде не фиксировались, заказчик(внутренний) не понимает чего хочет и постоянно их меняет, а РазработчикиКоторыеЗнаютВсюСистему увольняются, то никаких вопросов про нужность аналитиков и спецификаций больше не возникает.
Мы не идиоты, для маленьких проектов мы пишем маленькие спецификации, а иногда обходимся итемом в багтрекере.
Всем сомневающимся читать SWEBOK и Standish Group Report.

Полностью согласен с andbary про важность квалификации аналитика.

А вообще мы сильно отклонились в оффтопик.
Пришёл аналитик, спросил как ему быть с определённой проблемой, а ему начинают объяснять, что аналитики в соответствии с новыми веяниями больше не нужны. Соответственно и проблем у них никаких быть не может