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

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Международный университет природы, общества и человека «Дубна» Филиал «Угреша»

РЕФЕРАТ

по дисциплине: «Технология программирования»

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

выполнил: студент группы М1-10 Садыхов И.Р.

проверил: преподаватель Кленина В.И.

Дзержинский 2014



Содержание

Введение

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

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

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

Список литературы



Введение

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

подготовительную работу;

проектирование и разработку;

выпуск документации;

сопровождение документации.

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

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

эксплуатационную документацию программного продукта - объекта и

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

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

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

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

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

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

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



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

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

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

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

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

достигнуть соглашения с заказчиком по определению наличия и содержания

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

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

понять ограничения, которые могут сопутствовать или препятствовать решению проблем документирования.

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

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

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

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

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

В процессе установления стратегии, стандартов и руководств по документированию конкретного проекта ПС необходимо осуществить:

выбор модели жизненного цикла ПС и состава его документов;

определение шаблонов, содержания и степени детализации каждого документа;

определение необходимого качества каждого документа;

определение форматов и системы обозначения документов;

установление процедур реализации шаблонов документов;

распределение ресурсов для документирования: персонала; технических средств; финансов, а также на планирование документирования.

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

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

основные функции и связи между подразделениями и отдельными должностными лицами, указанными на схеме документирования, и их подчиненность;

описание регламента работ документирующих подразделений;

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

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

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

стандартами и нормативными документами, определяющими все аспекты документирования программ и данных;

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

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

планами документирования как органической части всего жизненного цикла конкретного ПС;

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

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

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

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

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

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

команда разработчиков ПС, получает представление о сложности и размере создаваемого продукта и составе его документации;

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

- группа тестирования, планы тестирования, варианты испытаний и процедуры проверок;

специалисты по сопровождению и поддержке, получают представление о функциональности каждой составной части продукта;

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

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

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

- персонал, занимающийся юридической стороной проекта, проверит, соответствуют ли требования к продукту существующим законам и постановлениям.

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

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

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

- реализованные планы документирования и обобщенные перечни выполненных работ, реальные графики проведенных ранее оценок и разработок, различных ПС и документов;

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

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

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

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

разделы, подразделы и отдельные требования должны быть названы согласованно;

полезно использовать средства визуального выделения последовательно, иерархически и в разумных пределах;

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

нумеровать все рисунки и таблицы, ссылки на них, используя присвоенные номера.

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

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

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

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

При проектировании полезно последовательно уточнять требования к номенклатуре, каждому свойству и качеству документов ПС.

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

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

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

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

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

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

размер - масштаб, подлежащих разработке полностью новых программных компонентов и документов;

размер и относительная доля готовых программных компонентов и документов, которые могут быть заимствованы из предшествовавших проектов и повторно использованы в новом проекте ПС;

относительные затраты ресурсов на создание проекта с оцененным масштабом: труда специалистов, времени, бюджета на единицу размера (на строку текста программ) или полные затраты на разработку всего ПС и комплекса документов.

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

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

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

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

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

Менеджер проекта для оценок документации должен подготовить план

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

установление графиков и сроков своевременного решения задач документирования;

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

определение времени, необходимого для выполнения конкретных задач документирования;

распределение задач документирования по исполнителям;

определение обязанностей исполнителей по созданию содержания документов;

выделение критических ситуаций, связанных с задачами или самим процессом документирования;

установление критериев управления и обеспечение качества документов;

обеспечение внешних условий и определение инфраструктуры проекта системы для выполнения процесса документирования.

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

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

Планирование и управление разработкой ПС и документов проходят

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

привлекается для документирования все большее число специалистов в среднем меньшей квалификации для выполнения более частных и менее творческих работ и документов.

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

общую структуру комплекта документов;

номенклатуру и содержание (или ссылки на шаблоны) каждого документа;

требования к качеству, оформлению и обозначению документов;

регламент комплектования и хранения документов;

правила обращения, изменения и сопровождения документов;

графики подготовки, проверки, редактирования, согласования, утверждения распространения документов.

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

исходные данные (шаблоны), требующиеся для успешного выполнения данного этапа документирования проекта или компонента ПС;

контролируемые и документируемые данные о состоянии объекта и процесса разработки, регистрируемые после завершения этапа;

содержание процедур контроля состояния проекта и документов в процессе выполнения работ этапа;

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

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

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

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

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

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

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

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



Список литературы

1. Липаев В.В. Документирование сложных программных средств. - М.: СИНТЕГ, 2012. 124 С.

2. http://www.ergeal.ru/archive/cs/tp/ - Технология программирования,

конспект лекций ВМиК МГУ, кафедра системного программирования

3. http://www.aanet.ru/~web_k46/textbooks/std_pro/face.htm - Богданов Д.В.,

Путилов В.А., Фильчаков В.В. Стандартизация процессов обеспечения качества программного обеспечения. - Апатиты, КФ ПетрГУ, 1997.

Размещено на Allbest.ru

...