Липаев В.В. Программная инженерия

Лекция 17. Документирование программных средств

работ и для использования на следующем этапе или при завершении проек­ та ПС.

Менедлсер программного проекта должен отвечать за проведение оценок программных продуктов, документов и планов: на соответствие принципам, методологии и технологии управления проектом и докумен­ тированием; в части удовлетворения их установленным требованиям до­ говора с заказчиком. Необходимыми компонентами успешной реализации программных проектов являются периодические анализы и оценки хода выполнения и завершения этапов и заданий на документирование.

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

—процессы создания документов, отражающих качество программ­ ного продукта;

—обязанности и ответственность специалистов за качество конкрет­ ных документов;

—используемые ресурсы, обеспечивающие создание документов вы­ сокого качества;

—требования к качеству конкретных документов и способы его кон­

троля.

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

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

Адаптация номенклатуры и содержания документов ПС к осо­ бенностям системы и пользователей может базироваться на выборе

570

17.3. Планирование документирования проектов сложных программных средств

ПОДХОДЯЩИХ шаблонов из набора документов. В процессе адаптации со­ става и содержания документов должны быть учтены особенности пользо­ вателей, поддерживающего персонала, руководителей контракта, потен­ циальных покупателей. Процессы, работы, шаблоны и задачи ЖЦ должны селектироваться и включать в себя перечень документов, которые обяза­

тельно нужно разработать, и информацию о персональной ответственности за них. Выбранные процессы, работы и задачи, не обеспечи­ ваемые конкретными документами, следует оговаривать в самом контрак­ те и утвержденном ЖЦ ПС. При адаптации документирования ПС необходимо также учитывать особенности проекта: стоимость, планиро­ вание, производительность специалистов, размеры проекта и интерфейс с человеком-пользователем. Все исходные данные и решения по адаптации номенклатуры, структуры и содержания документов должны быть доку­ ментированы и утверждены руководством проекта вместе с обоснованием их целесообразности.

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

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

571

Лекция 17. Документирование программных средств

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

Первоначально должен быть разработан проект архитектуры сис­ темы документооборота и руководство по ее применению, настроена выбранная СУБД на управление взаимодействующими подсистемами до­ кументооборота, с соответствующими комплектами выбранных шаблонов документов, с учетом класса и масштаба предполагаемого ЖЦ ПС (см. лекцию 16, п. 16.3). Шаблоны подсистем документооборота должны по­ этапно заполняться реальными данными проекта от заказчика и разра­ ботчиков соответствующих квалификаций и контролироваться менедже­ рами проекта. При этом следует управлять динамикой процессов реализа­ ции процедур документооборота, регистрировать реальное использование ресурсов специалистов, текущее время выполнения процедур процессов ЖЦ ПС и оформления документов в подсистемах. В реальных проектах ПС возможны отклонения от такой линейной схемы двух типов:

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

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

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

572

17.3. Планирование документирования проектов сложных программных средств

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

В состав базовых версий программного продукта входит седьмая

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

На базе стандартов, представленных в Приложении 1, с учетом ряда публикаций и нормативных документов, созданы и представлены ниже семь таблиц, отражающих состав комплекта технологических и эксплу­

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

Представленный в таблицах 17.1—17.7 перечень документов в ре­ альных проектах может варьироваться в зависимости от класса, масштаба

573

Лекция 17. Документирование программных средств

и характеристик ЖЦ программного средства. Наиболее сложному случаю разработки крупномасштабных критических ПС реального времени высо­ кого качества соответствует номенклатура и детализация всего комплекта представленных документов. Для каждого этапа жизненного цикла выде­ лены три уровня сложности проектов ПС: особо сложные (свыше 200 тысяч строк — крупные), средние по масштабу (свыше 50 тысяч строк — средние) и небольшие проекты программных средств (малые). Рекомендуй емые для таких проектов документы в таблицах отмечены знаком +. Некоторые документы целесообразно применять факультативно, или с со­ кращением и упрощением содержания, что отмечено знаками + -. Выде­ ленные три перечня документов целесообразно использовать как типовые, базовые, при адаптации и формировании состава и содержания докумен­ тов в конкретных проектах, с учетом их особенностей, масштаба и харак­ теристик.

Таблица 17.1

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

574

17.3. Планирование документирования проектов сложных программных средств

Таблица 17.2

Документы проектирования и выбора характеристик качества программного средства

575

Лекция 17. Документирование программных средств

Таблица 17.3

Документы процессов разработки и программирования компонентов программных средств

4.1Состав базовых документов, регламен­

4.2Исходные данные для верификации

4.4Исходные данные для тестирования

576

17.3. Планирование документирования проектов сложных программных средств

Окончание табл. 17.4

4.9Методика комплексирования фунцио-

4.10Оценка реализации комплексирования

Таблица 17.5

Документы квалификационного тестирования, испытаний

и оценивания качества программных продуктов

577

Лекция 17. Документирование программных средств

Таблица 17.6

6.1Описание среды жизненного цикла и конфи­

6.2План сопровождения версий

6.3План управления конфигурацией программно­

6.4Программа управления конфигурацией про­

6.5Отчеты пользователей о выявленных дефектах и предложениях по корректировке комплекса

6.8Извещение пользователям о выпуске новой версии программного продукта и/или о пре­

578

17.3. Планирование документирования проектов сложных программных средств

Таблица 17.7

Документы процессов эксплуатации программных продуктов