Методологические основы

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

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

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

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

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

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