Документообіг в життєвому циклі

Для реализации на практике приведенных выше концепций, требований и планов документирования в проектах программных средств необходимы организационные мероприятия, гарантирую­щие участникам проектов определенную культуру, дисциплину раз­работки и применения документов. Такая организационная система должна обеспечивать специалистам разной квалификации и роли в проекте, возможность взаимодействия при решении требуемых ком­плексных задач, для накопления, хранения и обмена упорядоченной информацией о состоянии и изменениях компонентов проекта. Формализованная в документах такая информация должна повысить от­ветственность специалистов за корректность её содержания, оперативность формирования и изменения, качество процессов трансфор­мации и реализации в жизненном цикле ПС.

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

Технической основой документооборота являются системы управления базами данных (СУБД), адекватные целям и функциям проектов, структурированные по целям, назначению и содержанию данных в выделенных подсистемах документооборота (рис. 1.6) Они должны обеспечивать возможность управления организацион­ной и проектной деятельностью коллективов специалистов подсис­тем документооборота, универсальное хранилище в них необходи­мых данных, с инструментами наполнения, корректировки, поиска и контроля информации, соответствующей их профессиональной деятельности.

Рис 1.6

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

Первоначально должен быть разработан проект архитектуры системы документооборота и руководство по её применению, настроена выбранная СУБД на управление шестью взаимодействующими подсистемами документооборота, с соответствующими комплектами шаблонов документов, с учетом класса и масштаба предполагаемого проекта ПС. По мере развития жизненного цикла проекта комплекса программ, шаблоны подсистем документооборо­та должны поэтапно заполняться реальными данными от заказчика и разработчиков соответствующих квалификаций, и контролироваться менеджерами проекта. При этом следует управлять динамикой процессов реализации процедур документооборота, регистрировать реальное использование ресурсов специалистов, текущее время выполнения процедур процессов проекта и оформления документов в подсистемах документооборота.

Эти данные в подсистемах документооборота должны быть защищены от случайных и преднамеренных искажений, путем организованного санкционирования, дублирования и контроля документов, истории их создания и изменения, в процессах жизненного цикла. Необходимо гарантировать сохранность версий документов, с учетом их важности для результатов всего проекта. Особенно защищенным от искажений следует сохранять архив документов базовых версий программных продуктов, прошедших успешные испытания, утвержденных заказчиком и скрепленных его электронной цифровой подписью. Для устранения дефектов, реализации корректировок и ошибок при развитии новых базовых версий целесообраз­но выделять рабочую копию предшествовавшей базовой версии и архив накопленных изменений, обеспечивающих возможность «отката» к предыдущей базовой версии в случае разрушительных некорректных изменений в процессе разработки новой базовой версии. Такая система документооборота (см. рис. 1.6) может быть структурирована в соответствии с адаптированной версией жизненного цикла ПС, представленной на рис. 1.2. Эта система поддержана комплексом около пятидесяти шаблонов технологических документов, детализированных в разделах 3.1 - 3.6 главы 3. Состав эксплуа­тационных документов (п. 3.7) достаточно консервативен и слабо связан с технологическими документами, поэтому он выделен. В соответствии с основными задачами шести групп специалистов, на рис. 1.6 представлены частные подсистемы документооборота, ори­ентированные на определенные процессы и компоненты комплексов программ. Для каждой подсистемы рекомендуется выделять доста­точно автономную базу данных компонентов ПС с ограниченным доступом только определенных категорий специалистов. Эти базы данных могут быть построены на стандартизированной основе СУБД проекта, взаимодействовать с аналогичными по структуре предшествующей и последующей базами данных. Они должны на­капливать и содержать основные компоненты и документы проекта ПС на соответствующем уровне жизненного цикла. Интерфейсы этого взаимодействия баз данных должны быть стандартизированы, по возможности ограничены по объему и доступности обменивае­мой текущей и отчетной информации для других категорий специа­листов (см. табл. 1.2). Каждая группа документов в главе 3 сопрово­ждается таблицей, в которой выделены рекомендуемые документы для крупномасштабных, средних и относительно простых ПС. Ряд отчетных документов базовых версий проекта по согласованию ме­жду заказчиком и разработчиками должны утверждаться электрон­ной подписью. Для каждого сложного проекта комплекса программ целесообразно оформлять и утверждать руководство и схему доку­ментооборота, а также категории ответственных лиц за их поэтап­ную реализацию и контроль.

На рис. 1.6 изображена упрощенная схема непрерывного, прогрессивного развития проекта с последовательным применением и взаимодействием подсистем документооборота. В реальных проек­тах ПС возможны отклонения от такой линейной схемы двух типов:

* прерывание процессов документооборота и прекращение всей разработки на промежуточных этапах системного, предварительного или детального проекта ПС (п. 3.1 и п. 3.2 в гл. 3), вследствие недостаточности ресурсов для его полной реализации или вследствие отказа заказчика продолжать данный проект при появлении. Альтернативного варианта; итерационный возврат на предшествующие подсистемы документооборота, а также на их компоненты и шаблоны для корректировки и уточнения, обусловленные изменениями, взаимосвязан­ных с ними компонентов проекта ПС (см. рис. 1.5).

При наличии прототипов проекта ПС и ряда детальных спецификаций требований, для создания новой базовой версии может отсутствовать необходимость её системного, предварительного или детального проектирования, а разработка и тестирование программных компонентов выполняться в процессе расширения предшествовавшей базовой версии (п. 3.3 и п. 3.4 в гл. 3). Тем самым процессы и руководства документооборота при развитии и совершенствова­нии версий ПС могут формализоваться, начиная с некоторых промежуточных этапов жизненного цикла комплекса программ.

Выше в ведении подчеркивалось, что проводимый в книге ана­лиз документирования программных средств ориентирован на жиз­ненный цикл наиболее сложных крупномасштабных проектов ком­плексов программ высокого качества [11, 16, 19]. Большинство про­ектов ПС являются более простым, и их документооборот может быть значительно сокращен. Для этого рекомендуется проводить адаптацию и формировать практическую рабочую версию Руководства документооборота жизненного цикла конкретного проекта ПС. Для этого реализуется методика последовательного сокращения подсистем и компонентов документооборота, которая начинается с определения масштаба и наличия предыстории проекта - рис. 1.7. Известные функции, потенциальные пользователи и концепции существующих версий ПС позволяют прогнозировать направления совершенствования и уменьшения документооборота для нового проекта, имеющего прототип. При этом, возможно, потребуется вы­бор новой СУБД и её адаптация для реализации совокупности ново­го сокращенного набора подсистем документооборота (см. рис. 1.7). Дальнейшая адаптация Руководства документооборота проекта ПС может включать отбор и уменьшение состава шаблонов документов, а также исключение некоторых требований и характеристик в них, для реализации конкретного проекта ПС в выделенных подсистемах документооборота. Таким образом, для каждого проекта комплекса программ в начале его реализации целесообразно подготовить адаптированную версию руководства документооборота, которая должна обеспечивать регламентирование работы специалистов при документировании нового проекта.

 

 

Рис. 1.7

 

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

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