Плохо обратное проектирование документированная Java из исходных кодов

Я системный инженер, недавний выпускник колледжа, и мне только что дали проект, который исключительно устрашающий.

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

Он использует собственный сценарий сборки Perl, для работы требуется тысяча модулей из CPAN, а я не знаю Perl. Обратный инжиниринг в UML потерпел неудачу, за исключением Doxygen, который ограничивается только диаграммами наследования и графами вызовов.

Я получил массивную классную доску и медленно просматриваю код, моделируя пакеты, а затем вложенные пакеты внутри.

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

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

Есть ли какие-нибудь книги, которые могут мне помочь, и подхожу ли я к этому с правильной точки зрения? Следует ли мне нанять подрядчика, который знает Perl и JMX, чтобы помочь мне?