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

Да, это плохо. Если кто-то из них попал под трамвай, разобраться в исходных текстах бывает проблематично.

PG81Кто как ведет разработку АИС? (любопытен опыт реально работающего сопровождения)
Имет ли вообще смысл вести системную документацию или может вообще разработку программ нужно вести определенным образом?

Если планируется длительное сопровождение АИС с возможностью выпуска новых версий ПО и сопровождение выполняется не самим разработчиками (так и должно быть), а специально выделенными специалистами, то должна быть подготовлена документация сопровождения.
Требования к процессу сопровождения изложены, например, в ГОСТ РВ 0019-001 -2006, документ "План передачи программного обеспечения".

PG81Как ведется документирование проектов? (хотябы на системном уровне для разработчиков )

Это должно делаться соответствующими специалистами (разработчиками документации, "техническими писателями"),
потому что кредо программистов: "Читать документацию является признаком плохого тона, а писать её - тем более".

PG81Как поддерживается эта документация в актуальном состоянии?
Может пользуетесь какими-то специальными для этого приложениями?

Полагаться на сознательность разработчиков, которые будут уведомлять об изменениях - наивно.
Необходимо использовать специальные программные средства.
Например, "Система управления рекламациями и изменениями ПО".
Все внесенные изменения в ПО фиксируются в ней.
Подписчики (пользователи, любые заинтересованные лица, в том числе, и разработчики документации) получают уведомления об изменениях с комментариями внесенных изменений.

PG81Может свои внутренние разработки? Какие их основные принципы?


Да, обязательно должны использоваться корпоративные стандарты, например, на оформление исходных текстов,
правила именования объектов БД и т. п.

PG81Используется ли как-то самодокументирование? (например, особые комментарии, которые потом попадают в документаццию)
Каким аспектам документирования уделяется особое внимание? (имеет смысл наверное описывать только самое важное, хотябы на первом этапе)


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

PG81Отвечает ли за это специальные люди или отдел или разработчики самостоятельно поддерживают актуальность?


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

PG81Передавать ПО на сопровождение никому не планируется. Поэтому тут никакие стандарты учитывать нет необходимости, от ни нужно взятьтолько самое полезное.

Стандарт содержит общие рекомендации по организации процесса сопровождения.
Требования нужно брать, естественно, с учетом свой специфики.
Но есть и обшие, например,
1 Ресурсы сопровождения
2 ПО, используемое в процессе сопровождения (типа контроль учета изменений) и инструкции работы с ним
3 Документация, используемая при сопровождении (перечислить все из написанного и пригодного)
4 Предполагаемые (планируемые) области изменений и др.

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

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

PG81действительно разработчиков сложно заставить ее постоянно заполнять. Особенно когда зменения незанчительные.

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

Повторяю еще раз: необходимость во всех этих работах полностью зависит от того, как долго планируется использовать АИС и как часто необходимо вносить в неё изменения.
А это все индивидуально.