Введение в программную инженерию

Федеральное государственное Автономное

образовательное учреждение

высшего образования

«Волгоградский государственный университет»







Институт Математики и информационных технологий

Кафедра «Информационных систем и компьютерного моделирования»







Курсовая работа

по дисциплине 

«Введение в программную инженерию»



«Документирование ПС»









ВЫПОЛНИЛ:

студент группыПРИ-161

Дон А.В.

ПРОВЕРИЛ:

доцент кафедры ИСКМ

Писарев А.В.







Волгоград

2017



ВВЕДЕНИЕ



































































































ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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









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



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.

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