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

Содержание

Введение

1. Анализ стандартов программной документации

2. Документирование программных изделий

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

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

Заключение

Список использованных источников

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

Введение

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

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

Объектом данной работы являются программные средства.

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

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

Задачи решаемые в данной работе:

1. проанализировать стандарты создания программной документации;

2. изучить документирование программных изделий;

3. описать пользовательскую документацию программных средств;

4. описать документацию по сопровождению программных средств.

1. Анализ стандартов программной документации

Регламентация проектной деятельности основывается на стандартах и методологиях, среди которых в настоящее время наиболее популярны как стандарты ГОСТ 34-й и 19-й серий, определяющие требования к разрабатываемой документации, так и новые стандарты ГОСТ Р ИСО/МЭК 12207-99 и ГОСТ Р ИСО/МЭК 14764-2002, определяющие процессы жизненного цикла программных средств. Одной из наиболее развитых и популярных методологий, описывающих процессы жизненного цикла (ЖЦ) программного средства (ПС), является Rational Unified Process (RUP), разработанный компанией Rational Software и соответствующий ГОСТ Р ИСО/МЭК 12207-99. При этом необходимо отметить, что RUP ориентирован прежде всего на разработку ПС и без предварительной адаптации не может использоваться для задач процесса сопровождения [8].

Сейчас складывается ситуация, когда многие коллективы, разрабатывающие программные средства, переходят на использование технологий, основанных на методологии RUP. В то же время, большинство Заказчиков, как внешних, так и внутренних, продолжают использовать стандарты серии ГОСТ 19 и 34 как основные при приемке программных средств от разработчика. Таким образом, возникает необходимость поддерживать двойную технологию, ориентируясь при разработке на методологию RUP, а при сдаче результатов - на стандарты ГОСТ 19 и 34 [8].

Сравнительный анализ зарубежного и российского стандартов приведены в таблице 1.

Таблица 1

Сравнительный анализ стадий RUP и ГОСТ

Стадии RUP	Стадии ГОСТ 34.601-90
Обследование (Inception)	Формирование требований Разработка концепции Техническое задание
Технический проект (Elaboration)	Эскизный проект Технический проект
Рабочий проект (Construction)	Рабочая документация
Передача в эксплуатацию (Transition)	Ввод в действие Сопровождение[8]

2. Документирование программных изделий

При разработке программных средств (ПС) создается и?используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС, и?как средство передачи пользователям информации, необходимой для применения и?сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС [3].

Эту документацию можно разбить на две группы:

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

?документы, входящие в?состав ПС [5].

Документы управления разработкой ПС (software process documentation) управляют и?протоколируют процессы разработки и?сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и?между коллективом разработчиков и?менеджерами ПС (software managers) - лицами, управляющими разработкой ПС [9]. Эти документы могут быть следующих типов:

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

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

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

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

?заметки и?переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и?разработчиками [4].

Документы, входящие в?состав ПС (software product documentation), описывают программы ПС как с?точки зрения их применения пользователями, так и с?точки зрения их разработчиков и?сопроводителей (в соответствии с?назначением ПС). Следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и?сопровождения), но и?на стадии разработки для управления процессом разработки (вместе с?рабочими документами). Во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС [6].

Эти документы образуют два комплекта с?разным назначением:

?пользовательская документация ПС (П-документация).

?документация по сопровождению ПС (С-документация) [2].

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

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с?пользователями. К?такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при установке ПС с?соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и?при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с?другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с?модификацией программ [9].

В связи с?этим следует различать две категории пользователей ПС: ординарных пользователей ПС и?администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Он может не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и?осуществляет сопровождение ПС, не связанное с?модификацией программ. Например, он может регулировать права доступа к?ПС между ординарными пользователями, поддерживать связь с?поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в?рабочем состоянии, если оно включено как часть в?другую систему [8].

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

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

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

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

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

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

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

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

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

Документация по сопровождению ПС (system documentation) описывает ПС с?точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроено (сконструировано), и?модернизацию его программ. Сопровождение - это продолжающаяся разработка. Поэтому в?случае необходимости модернизации ПС к?этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде приходиться иметь дело с?такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, с?той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и?процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а?затем внести в?нее необходимые изменения, повторяя в?значительной степени технологические процессы, с?помощью которых создавалось первоначальное ПС [6].

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

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

?документацию, помогающую вносить изменения в?ПС [5].

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

?внешнее описание ПС (Requirements document);

?описание архитектуры ПС (description of the system architectture), включая внешнюю спецификацию каждой ее программы (подсистемы).

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

?для каждого модуля спецификацию и?описание его строения (design description);

?тексты модулей на выбранном языке программирования (program source code listings);

?документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС, и?как информация об установлении достоверности связывалась с?требованиями к?ПС [7].

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

Документация второй группы содержит руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и?как учтены возможности развития ПС в?его строении (конструкции). В?нем также фиксируются, какие части ПС являются аппаратно- и?программно-зависимыми [1].

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

Создание и?использование пакета прикладных программ (ППП) от формирования концепции и?требований к?первой версии до изъятия его из эксплуатации сопровождается документированием объектов и?процессов жизненного цикла ППП [4].

По своему назначению документацию ППП можно классифицировать как:

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

?эксплуатационную (пользовательскую) документацию программного продукта, создаваемую для конечных пользователей пакета и?позволяющую им осваивать и?квалифицированно применять его для решения конкретных прикладных задач [8].

Технологическая документация включает:

?проектную документацию;

?документацию тестирования компонентов и?комплексов программ;

?документацию испытаний ППП;

?документацию сопровождения и?управления конфигурацией ППП [10].

В состав проектной документации входят:

?отчет по обследованию предметной области, для которой предназначен разрабатываемый ППП, с?описанием комплекса задач;

?описание концепции проектирования;

?техническое задание на проектирование;

?план-график работ;

?спецификации эскизного и?технического проекта;

?документация на разработанные программные модули пакета;

?общее описание программного обеспечения, используемого при разработке и?функционировании пакета (описание выбранной технологии автоматизированного проектирования ППП, операционной системы, других программных средств) [5].

В состав документации тестирования входят:

?исходные данные для проведения тестирования (методы тестирования, тестовые наборы, эталонные значения, реальные ресурсы тестирования - временные, аппаратно-программные, людские, критерии полноты и?качества тестирования);

?программа (сценарии) тестирования;

?журнал тестирования;

?итоговый отчет о?результатах тестирования [7].

В состав документации испытаний входят:

?программа испытаний;

?описание методов и?методик испытаний;

?протоколы испытаний;

?акт завершения работ;

?акт приемки ППП в?эксплуатацию [3].

В состав документации сопровождения управления конфигурацией входят:

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

?журнал выявленных дефектов и?предложений по совершенствованию и?развитию версии ППП;

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

?отчет о?результатах эксплуатации снятой с?сопровождения версии пакета;

?журнал тиражирования и?характеристик базовых версий, поддерживаемых сопровождением [2].

Пользовательская документация включает в?себя:

?паспорт на программное средство, где содержатся общие сведения о?ППП, его основные характеристики, комплектность, акт о?приемке, гарантии изготовителя (поставщика);

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

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

?руководства оперативных пользователей с?требованиями к?уровню подготовки пользователя, описание функций. Описан порядок подготовки ППП к?работе и?действия пользователя в?аварийных ситуациях, приведены рекомендации по освоению пакета, включая описание контрольного примера, правила его запуска и?выполнения [8].

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

В процессе сопровождения в?программы вносятся различные изменения:

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

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

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

Выход коммерческого программного продукта на рынок программных средств связан с?организацией продаж массовому пользователю. Как правило, для каждого программного продукта существует своя форма кривой продаж, которая отражает на рисунке 1 спрос V во времени t [6].

Вначале продажа программного продукта идет вверх - возрастающий участок кривой. Затем наступает стабилизация. Далее происходит падение объема продаж, что является сигналом к?изменению маркетинговой политики фирмы в?отношении данного программного продукта, требуется модификация продукта, изменение цены или снятие с?продажи [3].

Эксплуатация программного продукта идет параллельно с?его сопровождением, при этом эксплуатация программ может начинаться и?в?случае отсутствия сопровождения, или продолжаться в?случае завершения сопровождения еще какое-то время. После снятия программного продукта с?продажи его сопровождение может выполняться определенное время [10].

Рисунок 1 Кривая продаж программного продукта

Сопровождение коммерческого программного продукта производится в?форме устранения обнаруженных ошибок путем выпуска программных «заплаток» - патчей. Эти программы выкладываются на Web-сайте разработчика и?предлагаются пользователям. Обновление обычно происходит в?автоматическом режиме при загрузке патча. Кроме этого, ведется и?модернизация программ. В?процессе эксплуатации фирма-разработчик предлагает пользователям приобрести новые версии программного продукта. Сопровождение также осуществляется специализированными фирмами-распространителями программного продукта (дистрибьюторами) [9].

Снятие программного продукта с?продажи и?отказ от сопровождения происходят, как правило, в?случае изменения технической политики фирмы-разработчика, неэффективности работы программного продукта, наличия в?нем неустранимых ошибок, отсутствия спроса [4].

Длительность жизненного цикла для различных программных продуктов неодинакова. Для большинства современных программных продуктов длительность жизненного цикла измеряется двумя-тремя годами. Хотя достаточно часто встречаются и?давно снятые с?производства программные продукты [7].

Существуют другие варианты легального распространения программного продукта, кроме коммерческого, которые появились с?использованием глобальных или региональных сетей: freeware - бесплатно распространяемые и?поддерживаемые самим пользователем программы; shareware - условно-бесплатные программы. Ими можно пользоваться бесплатно некоторое время, а?при условиях регулярного использования требуется внести определенную сумму разработчику программы; demo-версии (демонстрационная и?пробная программы). Это версии коммерческих программ, специально подготовленные разработчиком для бесплатного распространения в?рекламных целях. Демонстрационная версия, как правило, рассчитана на неограниченное время пользования, но представляет собой урезанный вариант платной программы, то есть в?ней реализованы не все функции. Пробная версия обычно полнофункциональна, но остается работоспособной лишь в?течение небольшого промежутка времени, достаточного для ознакомления с?ней (несколько дней или недель, либо определенное количество запусков). После этого работоспособность программы блокируется или же она превращается в?демонстрационную версию; ad ware - программа, показывающая рекламу. Бесплатная программа такого типа, как правило, сохраняет все функции коммерческой версии и?остается работоспособной в?течение неограниченного времени, однако она постоянно показывает пользователю рекламные окна - баннеры. Чтобы «отключить» назойливую рекламу, необходимо оплатить коммерческую версию; OEM (Original Equipment Manufacturer) - программы, поставляемые с?купленной компьютерной техникой по OEM-контракту между фирмой-разработчиком и?продавцом ПК (или другого hardware). Их стоимость меньше, чем стоимость retail-программ, поставляемых в?розницу в?«коробочном» исполнении [5].

Заключение

В результате исследования были решены все поставленные задачи. Цель достигнута. Что позволяет сделать следующие выводы:

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

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

3. Анализ пользовательской документации программных средств показал, что она необходима, если предполагается какое-либо взаимодействие программного средства с?пользователями;

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

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

Список использованных источников

1. Вельдер С.Э., Лукин М.А., Шалыто А.А., Яминов Б.Р. Верификация автоматных программ. [Текст] СПб: Наука, 2011. 242 с.

2. Камаев В.А., Костерин В.В. технологии программирования - новый учебник [Текст] // Современные проблемы науки и образования. 2005. № 2. URL: www.science-education.ru/39-1486 (дата обращения: 19.03.2014).

3. Касихин В. В. Как стать создателем компьютерных игр. Краткое руководство [Текст] Издательство: Вильямс Год: 2006.

4. Ковалевская Е.В. МЕТОДЫ ПРОГРАММИРОВАНИЯ [Текст]: учебно-методический комплекс / Е.В. Ковалевская, Н.В. Комлева. М. : Изд. центр ЕАОИ, 2010. 320 с.

5. Лупин С. А., Посыпкин М. А. Технологии параллельного программирования [Текст] Издательство: Форум, Инфра-М 2011 ISBN: 978-5-8199-0336-0, 978-5-16-003155-2.

6. Монографии [Электронный ресурс] Режим доступа: http://www.rae.ru/monographs/141-4630.

7. Ричард Гербер, Арт Бик, Кевин Смит, Ксинмин Тиан Оптимизация ПО. Сборник рецептов [Текст] Издательство: Питер, Год: 2010 ISBN: 978-5-388-00131-3, 0976483211.

8. Роберт Мартин Чистый код. Создание, анализ и рефакторинг [Текст] Издательство: Питер Год: 2010.

9. Эрик Эванс Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем [Текст] Издательство: Вильямс Год: 2011.

10. Энди Орам, Грег Уилсон Идеальный код [Текст] Издательство: Питер Год: 2011.

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