Обратное проектирование

Да. Задача уже поставлена. Получается, что консультироваться с разработчиками придется постоянно. Модулей куча! Сейчас параллельно в работе три процесса: изучение основ ООП, Java и исходников. И беспокоит то, сколько разработчик будет отвечать на вопросы? Ведь чем глубже погружаешься в задачу, тем больше вопросов возникает. Возможно некоторые вопросы неоднократно.

Ответы не затягиваются, с этим все в порядке. Беспокоюсь, что рано или поздно может наступить предел( И скажут, что задачу нужно было выполнить вчера

Точно нужно настолько детальное описание программы, что необходимо погружаться в код на Java?

Разделы документа по ГОСТу:

• общие сведения;
• функциональное назначение;
• описание логической структуры;
• используемые технические средства;
• вызов и загрузка;
• входные данные;
• выходные данные.
  

Знание кода может потребоваться в одном пункте из 7 - "Описание логической структуры". А может и не потребоваться. Бывает достаточно написать, что программа состоит из таких-то модулей, каждый из которых отвечает за такую-то функциональность. Добавить схему взаимодействия этих модулей. Об этом должен иметь представление менеджер проекта или системный архитектор. И это можно рассказать, не зная языка, на котором эти модули реализованы.

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

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

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

У него появляется стимул начать разбираться. Самая большая проблема - "НАЧАТЬ", а далее человек втягивается, ему становится интересно и разбирается понемногу. Если не интересно, то профессия не его.

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

Автор темы уже заинтересован и вопрос был "с чего начать".


Правильно

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

По ГОСТ потом можно начинать оформлять.

Можно, но хотелось бы посмотреть как вы закроете тему ))

Угу. Ты мне так рассказываешь, как будто я документации для программистов не писала... Поэтому на "поверь" могу ответить своё "поверь", что на выходе качественного документа не выйдет, если технический писатель не в теме. Вряд ли он сможет на начальном этапе даже грамотно вопросы программисту задать. Поэтому обучаться программированию надо было в свободное время на тренингах до получения подобных задач. Моё мнение - сначала надо дорасти до определённого уровня, а потом уже браться за подобные задачи.
Если документация не имеет практического применения, то можно, конечно, писать как хочешь и что хочешь. Но абсолютно уверена, что бест практис для программистов может написать только гуру-программист.

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

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

В данном случае есть цель описать сущности, классы и архитектуру ПО. Для изучения инструментов, цель разбивается на подцели: что такое сущности, классы, объекты, методы, функции, вызовы, как они зависят друг от друга и влияют, изучается терминология Java в этом контексте и так далее. В идеале установить среду в которой разрабатывалось ПО (netbeans, eclipse и пр), взять исходники программы, найти зависимости, описать справочники, переменные, описать вызовы с примером кода вызова методов, процедур и пр. Собрать все это дело и описать по шагам этапы сборки, логирования, параметров для последующей инсталляции и так. далее.

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

 писал писал и ошибка сохранения...

В процессе. Постоянно обращаюсь к соответствующей литературе.

Можно подробнее? Или, если есть шаблоны какие то, стандарты или ГОСТы, можно их посмотреть?