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

Это называется "ЖОПА".
Нормальная состояние системы, которая развивалась "сама по себе".
Тут надо посчитать, что дешевле.
Дальше обкладывать систему "костылями" и "хаками".
Или "взять и переписать".

А так. Я бы советовал бы следующую последовательность
1) Описать что (НЕ КАК) должна сделать система (чем подробнее, тем лучше)
2) Описать, как минимум, типичные сценарии работы с системой со стороны "клиента" (Клиентом может быть, как и пользователь, так и другая система)
3) Написать для этих сценариев интеграционные тесты (сделали то-то, в ответ получили то-то)
...
4) PROFIT