67255

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

Лекция

Информатика, кибернетика и программирование

Тексты и объектный код программ для ЭВМ могут стать программным продуктом только в совокупности с комплексом документов полностью соответствующих их содержанию и достаточных для его освоения применения и изменения. Посредством документов электронных или бумажных специалисты взаимодействуют...

Русский

2014-09-06

149.5 KB

56 чел.

PAGE  1

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

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

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

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

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

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

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

Процессы документирования программ и данных входят в весь жизненный цикл сложных систем и ПС. Поэтому организация и реализация работ по созданию документов должны распределяться между специалистами, ведущими непосредственное и преимущественное создание проектов комплексов программ и специалистами осуществляющими, в основном, разработку, контроль и издание документов. При создании особо сложных систем целесообразно выделение специального коллектива, обеспечивающего организацию и реализацию основных системных работ по документообороту ПС. Совокупные затраты на документирование крупных программных продуктов могут достигать 20 – 30%  от общей трудоемкости проекта и необходимого числа (десятки) специалистов в жизненном цикле проекта ПС.  В более простых случаях,  организация работ может быть упрощена, затраты на документирование снижаются приблизительно до 10%, однако всегда целесообразно выделять специалистов, непосредственно ответственных за создание, адекватность и контроль полноценного комплекта документов на программный продукт. Состав и общий объем документов широко варьируется в зависимости от класса и характеристик объекта разработки, а также в зависимости от используемой технологии. Наиболее сложному случаю разработки критических ПС реального времени высокого качества соответствует самая широкая номенклатура  документов. Такой перечень документов может быть использован как базовый для формирования на его основе состава и шаблонов документов в остальных более простых проектах.  

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

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

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

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

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

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

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

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

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

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

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

17.2. Формирование требований к документации                                        сложных программных средств

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

        Формированию требований к комплексу программ должно сопутствовать создание требований,  отражающих его документооборот, вследствие чего эти процессы во многом подобны.  От масштаба ПС непосредственно зависят затраты ресурсов для их документирования и не всегда целесообразно создавать и использовать  в реальных проектах весь комплекс документов, отраженных ниже в таблицах 17.1 17.7 . Масштаб проекта и спецификация требований к ПС, непосредственно отражаются на составе, содержании и объеме документации, необходимой различным участникам проекта. Каждый из разработчиков в той или иной степени должен привлекаться к управлению требованиями, как к проекту, так и его документации. Разработчикам необходимо выработать профессиональные приемы для понимания и изложения в документах потребностей заказчиков и  пользователей, управления масштабом проекта, построением системы и документации,   которые включают:

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

    Размер или масштаб комплексов программ в настоящее время приводится в публикациях в различных единицах, что может изменять их численные значения для одних и тех же программ в несколько раз (см. лекцию 5). Влияние единиц измерения размера программ на оценку рационального объема документации можно значительно изменяться, если учесть их принципиальные особенности и, прежде всего, выделить две группы единиц измерения масштаба проектов ПС:

  •  группу, характеризующую размер исходных текстов программ, которые разрабатываются и анализируются специалистами – человеком, отражающую, сложность, трудоемкость и длительность создания ПС, его компонентов и основных документов;
  •  группу, отражающую размер программ и данных, размещаемых в реализующей (объектной) ЭВМ, и характеризующую объем памяти и производительность ЭВМ, необходимые для рабочего функционирования и исполнения комплекса программ  в соответствие с его назначением.

      Эти две группы единиц отражают размер программ и документов, с разных  позиций, и должны использоваться в зависимости от целей анализа и применения значений масштаба проекта (рис. 17.1).  Для разработки набора документов после оценки масштаба комплекса программ, необходимо выполнить цикл поэтапного определения и формирования совокупности спецификаций требований к компонентам и документации проекта ПС. Первым этапом является создание Концепции проекта ПС и комплекса первичных требований спецификаций к иерархическому набору функций, на которые могут быть разбиты предполагаемые фактические компоненты ПС. В дальнейшем разбиение может структурироваться и детализироваться, формируя упрощенный или более точный уровень абстракции и взаимодействия компонентов. Цель документа – Концепция,  состоит в сборе, анализе и определении высокоуровневых потребностей пользователей, функций и документов программного продукта. Основное внимание должно уделяться возможностям и функциям документов, в которых нуждаются будущие разработчики и пользователи.

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

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

       Составлять спецификацию требований к документации ПС следует таким образом, чтобы все заинтересованные в проекте лица смогли в ней разобраться и применять:

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

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

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

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

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

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

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

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

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

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

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

      

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

     Общее руководство процессом документирования комплексов программ можно разделить на два уровня:

  •  адаптация состава и содержания документов к данной деловой, проблемно-ориентированной области, например,  авиационной, медицинской, военной, финансовой или административной;
  •  адаптация номенклатуры, структуры и содержания документов для  каждого специфического проекта, контракта или предприятия.

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

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

    Может представлять интерес оценка ориентировочного физического объема  документации (например, в стандартных страницах А4 или эквивалентных объемов файлов) для проектов комплексов программ. В качестве гипотетического примера выделим два масштаба проектов: малый – 50 тысяч строк и крупный – один миллион строк, и выделим оценки на технологическую и на эксплуатационную документацию. В эксплуатационной документации обычно не оформляются и не приводятся спецификации компонентов, тексты программ с комментариями, тесты и результаты тестирования, что резко сокращает номенклатуру документов до трех – семи  видов (см. таблицу 17.7).  Каждое описание, руководство или инструкция может содержать до 100 страниц текста, что в совокупности дает до тысячи страниц эксплуатационных  документов. Для крупного программного продукта несколько возрастает номенклатура документов, но главное, пропорционально увеличению сложности и масштаба комплекса программ до 10 6 строк,  объем эксплуатационной документации  может  увеличиться до 10 тысяч страниц.

     Номенклатура технологических документов в жизненном цикле             крупного ПС может доходить до 50 видов (см. таблицы 17.1 – 17.6) , среди которых наибольшее влияние на объем документации оказывают: спецификации программ и данных, тексты программ с комментариями, тестовые сценарии и результаты тестирования компонентов и модулей. Для отражения совокупности этих документов, в среднем на каждую строку текста программы может требоваться от 10%  до полной страницы документации. Остальные документы в основном являются интегральными для проекта и вряд ли займут более 10% общего объема от перечисленных категорий документов. Таким образом, технологическая документация для жизненного цикла ПС размером 10 6 строк может составить около ста тысяч страниц или ста томов по тысяче страниц.

      Вряд ли целесообразно изготавливать такой объем твердых копий документов на бумаге. Большая часть этих документов может оставаться в файлах (сотни мегабайт), однако каждый документ должен быть оформлен в  соответствии со стандартами и шаблонами, и скреплен подписями разработчиков и, где нужно, заказчика. Изменение этих документов должно санкционироваться, также как твердых копий. Для относительно малого проекта ПС (50 тысяч строк) с минимальной технологической документацией может потребоваться около 5 тысяч страниц или эквивалентных файлов.

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

      Менеджер проекта для оценок объема и содержания документации должен подготовить план выполнения документирования в жизненном цикле ПС (рис. 17.2). Этот план должен содержать описания соответствующих работ и задач и обозначения создаваемых программных продуктов и документов. Он должен охватывать следующие задачи:

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

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

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

В плане управления документированием каждого этапа жизненного цикла ПС целесообразно фиксировать и документально оформлять:

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

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

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

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

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

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

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

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

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

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

20915. Исследование двигателей постоянного тока 578.5 KB
  Оборудование измерительные приборы и инструменты: лабораторная установка источники постоянного тока вольтметр амперметр тахометр магазин сопротивлений. В настоящее время в качестве исполнительных двигателей наиболее часто используются: двухфазные асинхронные двигатели с повышенным сопротивлением ротора; двигатели постоянного тока с независимым возбуждением или постоянными магнитами; 3 синхронные – шаговые двигатели. В настоящей работе исследуется двигатель постоянного тока ДПТ.
20916. Исследование тахогенераторов постоянного и переменного тока 980.5 KB
  Оборудование измерительные приборы и инструменты: лабораторная установка источники постоянного и переменного тока вольтметры тахометр магазины сопротивлений и конденсаторов. По роду тока тахогенераторы делятся на ТГ постоянного тока и ТГ переменного тока. Допустимая амплитудная погрешность может составлять единицы процентов; минимум фазовой погрешности – минимум изменения фазы выходного напряжения при изменении скорости вращения для ТГ переменного тока; симметричность выходной характеристики – неизменность ее крутизны при изменении...
20917. Исследование электрических гиромоторов 327 KB
  Совокупность ротора электропривода роторных опор называемых главными опорами гироскопа и элементов крепящих двигатель на раме гироскопа представляет собой гиромотор гиродвигатель. Кинетический момент равен произведению момента инерции ротора J на угловую скорость его вращения 2: H=J2 . Для получения максимально возможного момента инерции ротора в заданных габаритах гиромоторы выполняются по обращенной схеме. В отличие от обычного двигателя статор гиромотора размещается внутри охватывающего его ротора.
20918. Классификаторы, коды и технология их применения 117 KB
  Контрольное число контрольная цифра разновидность контрольной суммы добавляется обычно в конец длинных номеров с целью первичной проверки их правильности. Контрольное число чаще всего это либо последняя цифра суммы всех чисел номера либо результат другой математической операции над цифрами. Вычисляется контрольное число A как остаток от деления контрольной суммы на 11 3. Если контрольное число A больше 9 то результирующее контрольное число A вычисляется как остаток от деления A на 10 4.
20919. Организационно-экономическая сущность задачи 2.16 MB
  Для этого рассмотрим: внешние и внутренние связи подразделения для которого создается АИС; информационная взаимосвязь входной и выходной информации; способы отправки и доставки информации. Информационная взаимосвязь подразделений данного экономического объекта позволяет определить состав взаимосвязанных подразделений объекта и место подразделения для функционирования которого необходимо решение данной задачи. Пример отражения информационной взаимосвязи подразделений супермаркета и выделение конкретного подразделения в частности отдела...
20920. ДОСЛІДЖЕННЯ СХЕМ ПОРІВНЯННЯ НАПРУГ 452 KB
  На панелі Джерела натиснути відповідні кнопки вибору сигналу постійного струму і включити стенд. На панелі U вх натиснути кнопку Джер. 1 панелі Джерела встановити напруга на вході 1 компаратора рівне U вх = 3 В. На панелі натиснути кнопку Джер.
20921. ДОСЛІДЖЕННЯ РОБОТИ МУЛЬТИВІБРАТОРА 64.5 KB
  2 із зображенням мультивібратора рис. Визначити за допомогою осцилографа амплітуду частоту і шпаруватість сигналу на виході мультивібратора. Часові діаграми роботи мультивібратора показані на рис.
20922. ДОСЛІДЖЕННЯ ІНТЕГРАТОРА 184 KB
  Експериментальне визначення перехідних характеристик інтегратора рис. Натисніть кнопку 20 сек панелі і кнопку С1 Інтегратор відлічуючи по секундоміру стенду час за допомогою U вих виконайте вимірювання зміни в часі вихідної напруги інтегратора. побудуйте перехідні характеристики інтегратора.
20923. ДОСЛІДЖЕННЯ ЕЛЕМЕНТІВ, ЩО ВИКОНУЮТЬ ЛОГІЧНІ ОПЕРАЦІЇ 105.5 KB
  Мета роботи: ознайомитися з принципом і режимом роботи логічних елементів. При виконанні роботи визначаються передавальні характеристики логічного елементу при різних опорах навантаження а також складаються таблиці станів для логічних елементів €œІ€ €œНІ€ €АБО€ €АБОНІ€ €ІНІ€. Визначення передавальних характеристик логічних елементів рис. Складання таблиць істинності логічних елементів.