Есть самописная информационная система, одной торговой компании - ей (ИС) уже около 10 лет. Система достаточно велика, чтобы никто в отделе, не знал её полностью.

Сейчас описано и поддерживается в актуальном состоянии только назначение таблиц и полей в БД (процентов на 70-80).
Остальное описание системы предсталяет из себя разрозненные документы (описание отдельных бизнес-процессов, проектная документация по некоторым фичам, описание отдельных отчётов итд итп).
Много функционала вообще нигде не описано.

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

Интересно именно описание требований к системе, а не описание реализации. Т.е. по любой фиче в системе, любой разработчик, аналитик или тестер (а возможно и пользователь?) должен легко получить исчёрпывающую информацию о том для Чего и для Кого Это делалось и как Это должно себя вести.
Соответственно, когда делается новый проект любому было понятно, что в описании надо изменить, чтобы оно осталось актуальным.

Ещё одно ограничение: описание должно быть максимально постепенным, т.е. сразу всё описать по ресурсам не получится. Описание будет происходить несколько месяцев, практически в фоновом режиме.

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



* ARIS?
Сам я не специалист, но то что я видел разочаровало. Попытка писать в нём (не мной :) а специалистами) детальные требования к системе приводили к жутким макаронным диаграммам, где ничего не понятно.

* Написать ОченьБольшуюSRS
Возможно ещё ОченьБольшоеОписаниеВсехЮзКейсов ?
и Концепцию листов так на 80-100 ?

* Завести внутренний вики-ресурс ?
Опять таки вопрос,какая должна быть структура у этого ресурса

* Requisite Pro?

* Другие инструменты?

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

Вы не совсем о нашей ситуации говорите.

Постараюсь проиллюстрировать примером:
*Делаем Проект111 для бухгалтерии, одновременно хорошо описали несколько юз-кейсов и бизнес-правил о том как отдел закупки работает с таможней.

*Прошло полгода. Аналитик проекта111 уволился. Делаем проект222 для отдела закупок. Никому в голову не придёт искать что-то в проекте111. Всё требования начинаем писать с нуля.

*Прошёл год. Делаем проект111версия2. Тремя месяцами раньше в ходе реализации проекта 150 для фронт-офиса фичи по проекту111 подкорректировали. Информация об этом только в документации по проекту 150. Кроме этого по просьбе пользователей сделали 4 небольших доработки по проекту111. Информация об этом есть только в баг-трекере. Результат: собираем требования для проекта111версия2 практически с нуля.


Если конкретизировать, то основные потребители такой документации - аналитики.
Основная цель: повторное использование требований к ПО.
Ищется инструмент и\или методика.

Цели тотального отслеживания что на что влияет не стоит. Для этого есть методы уровня разработчиков.

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

Гликоген
Итак, я бы сделал в Access или другой подходящей среде быстрой разработки ИС для документирования ИС.
В виде нескольких сущностей, реляционно связанных между собой, и простеньких форм, обеспечивающих ввод/правку....
alex108
Есть "самописный" bug tracking, который тоже интегрируется с wiki.
Вообщем, пока очень даже устраивает...
Petro123
идти от "уборки мусора"... и ввести простейший Bug Tracker (напр. Mantis) .
Очень удобно слушать "мнения пользователей".
Баг трекер есть. Не помогает. Цель немного другая. (См. постом выше)

andbary Когда я сам, сталкнулся с подобной проблемой, быстро выяснилось, что:
1. Трудоемкость документирования сравнима с написанием новой системы.
2. Перед данным действом необходимо навести порядок, иначе придеться документировать "кучу мусора".
3. Проверить правильность документации не представляется возможным.
Я пошел по пути "уборки мусора"... До сих пор убираю
PS Документировать можно только основные процессы, все остальное в вашей ситуации не имеет смысла. alex108...
Пытаюсь использовать локальную wiki-документацию (pmWiki). Наполнение происходит постепенно и постоянно.
Документы привязаны к подсистемам и режимам с online-доступом. Документация пишется как для пользователя, так и для разработчика...
Alexey Kudinov...
У нас когда-то чем-то аналогичным занимался специально выделенный человек и это было одной из его должностных обязанностей.
При этом
- код изначально был отлично документирован.
- люди, которые "знают все" были доступны.
Как результат, был описан основной функционал и взаимосвязи в системе. Но далеко не все. Petro123... поддержание порядка "в голове" или "на бумаге" бОльшой системы зависит от качества характера и ... желания руководства.
Т.е. идти от "уборки мусора"...
Очень удобно слушать "мнения пользователей".Как вы думаете цель повторного использования ранее собранных требований реалистична? Возможно это утопия на любом инструментальном средстве?

модПроблема действительно серьезная. Лично я пришел к таким выводам:
1. Для конечного пользователя - демо реальной системы с кратким описанием не очевидных моментов ("Руководство пользователя").
2. Для разработчика - исходники с коментариями того, что также не очевидно.
Т.е. лучшее описание системы - это она сама.
У нас есть ещё один класс заинтересованных лиц - аналитики.

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 про важность квалификации аналитика.

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

Алексей Е.Прочитал всё, так и не услышал не одного рабочего варианта.
В чём всё-таки удобнее описать существующую систему? Что-бы потом можно было куда-то двигаться. У меня похожий вопрос сейчас стоит.
Вот то же самое. Понял что готовых, проверенных жизнью вариантов нет. У всех своё видение. Это видение очень сильно различается, думаю, из-за того, что процессы разработки в разных организациях очень по разному выстроены.

Алексей Е.Опять-же мне например интересно чтобы можно было делать разные уровни детализации. т.е. сначало видим большой "квадратик" - общий учет, раскрываем его, он делится на бух., управл., логист., ... Раскрываем, дальше например управл., видим то-то и то-то и так далее вплоть до классов/процедур кода, таблиц... Это видение с точки зрения разработчика. Оно не устроит других игроков. Например меня, как аналитика, основное время которого занимает разработка спецификаций.

Думаю у каждого: у заказчика, у специалиста по реинжинирингу бизнес-процессов, у проджект-менеджера, у специалиста по тестированию, у специалиста по развёртыванию, у специалиста по поддержке итп, будет своё видение. Многие из них не захотят видеть систему в единственном разрезе Бухгалтерский\Управленческий\Логистический учёт
И, думаю, каждый из этих специалистов считает, что их модели фундаментальны и всё остальное должны быть производными от них. Разработчик считает, что фундаментален код и модель должна синхронизироваться с кодом, специалист по БП, что фундаментальны БП и всё остально должно ссылаться на его схемы БП, специалист по инфраструктуре считает, что первичны приложения и сервисы и всё должно быть описано в их терминах итд итп

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