В случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, что и команде первоначальных разработчиков, — с той лишь разницей, что документация для команды разработчиков-сопроводителей будет чужой (она создавалась другой командой). Команда разработчиков-сопроводителей должна будет изучать эту документацию и затем вносить в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС
Документация по сопровождению ПС можно разбить на две группы:
1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;
2. документацию, помогающую вносить изменения в ПС
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы:
· внешнее описание ПС (Requirements document);
· описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы;
Сопровождение и запуск новичка . Пошаговая инструкция.
· для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;
· для каждого модуля — его спецификация и описание его строения (design description);
· тексты модулей на выбранном языке программирования (program source code listings);
· документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС
Документы установления достоверности ПС включают прежде всего документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ
Документация второй группы содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает:
· известные проблемы, связанные с ПС,
· какие части системы являются аппаратно- и программно-зависимыми,
· возможности дальнейшего развития ПС
Документирование программного продукта. Пользовательская документация, ее назначение и состав.
Документы, входящие в состав ПС (product documentation), описывают ПС
1. с точки зрения его применения пользователями,
2. с точки зрения его разработчиков и сопроводителей (в соответствии с назначением ПС)
Эти документы используются не только на стадии эксплуатации ПС, но и на стадии разработки для управления процессом его разработки
Типы документов продукта
Эти документы образуют два комплекта с разным назначением:
1. пользовательская документация ПС (П-документация),
2. документация по сопровождению ПС (С-документация)
1. Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС
Пошаговая инструкция по сопровождению
К этому типу документации относятся документы, которыми руководствуется пользователь: при
· при применении ПС для решения своих задач,
· при управлении ПС (например, когда данное ПС взаимодействует с другими системами).
Следует различать две категории пользователей ПС:
· ординарных пользователей ПС
Ординарный пользователь ПС (end-user) использует ПС для решения задач в своей предметной области и может не знать многих деталей работы компьютера или принципов программирования
Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ
Например, он может
· регулировать права доступа к ПС между ординарными пользователями,
· поддерживать связь с поставщиками ПС,
· выполнять определенные действия для поддержания ПС в рабочем состоянии
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано данное ПС, и от режима использования документов. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории
Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ . Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника)
Состав пользовательской документации
· Общее функциональное описание ПС с краткой характеристикой функциональных возможностей ПС. Предназначено для пользователей, решающих, насколько необходимо им данное ПС.
· Руководство по инсталляции ПС, предназначенное для системных администраторов. Оно должно детально описывать действия по установке системы и определять требования к конфигурации аппаратуры.
· Инструкция по применению ПС. Предназначена для ординарных пользователей и содержит необходимую информацию по применению ПС , организованную в форме удобной для изучения
· Справочник по применению ПС. Предназначен для ординарных пользователей и содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска
· Руководство по управлению ПС. Предназначено для системных администраторов и должно описывать сообщения, генерируемые при взаимодействии ПС с другими системами, а также способы реагирования на эти сообщения . Если ПС использует системную аппаратуру, то этот документ может объяснять, как сопровождать эту аппаратуру
Разработка пользовательской документации
Разработка пользовательской документации начинается сразу после создания внешнего описания и ее качество может существенно определять успех ПС. Она должна быть достаточно проста и удобна для пользователя, поэтому к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели . Для обеспечения качества пользовательской документации разработан ряд стандартов , в которых
· предписывается порядок разработки этой документации,
· формулируются требования к каждому виду пользовательских документов,
Дата добавления: 2018-05-13 ; просмотров: 489 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Документация по сопровождению программных средств
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение — это продолжающаяся разработка.
Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, — с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;
2) документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
· Внешнее описание ПС (Requirements document).
· Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы (подсистемы).
· Для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
· Для каждого модуля — его спецификация и описание его строения (design description).
· Тексты модулей на выбранном языке программирования (program source code listings).
· Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ. Для обеспечения приемлемого качества этой документации полезно следовать общепринятым рекомендациям и стандартам.
Документация второй группы содержит:
· Руководство по сопровождению ПС (system maintenance guide), которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми.
Общая проблема сопровождения ПС — обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда ПС изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть отражены в руководстве по сопровождению, и зафиксированы в базе данных управления конфигурацией.
Кратко подводятся итоги занятия, при этом обращается внимание студентов на основные понятия стандартов и программирования.
Дать задание на самостоятельную работу (отводимое время 1 час):
ó с целью более глубокого освоения материала повторить и более подробно изучить материал. Литература: [1] с.47. 60, конспект лекций,
При необходимости ответить на возникшие вопросы.
Старший преподаватель кафедры АС и ПО И.Денисова
Источник: studopedia.su
Документация по сопровождению программных средств.
Документация по сопровождению ПС описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена, и модернизацию его программ. Сопровождение — это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей.
Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, — с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Команда разработчиков-сопроводителей должна будет изучать эту документацию, чтобы понять строение и процесс разработки модернизируемого ПС, и внести в эту документацию необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;
(2) документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
- Внешнее описание ПС.
- Описание архитектуры ПС, включая внешнюю спецификацию каждой ее программы.
- Для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля.
- Для каждого модуля — его спецификация и описание его строения.
- Тексты модулей на выбранном языке программирования.
- Документы установления достоверности ПС, описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.
- Руководство по сопровождению ПС, которое описывает известные проблемы вместе с ПС, описывает, какие части системы являются аппаратно- и программно-зависимыми, и как развитие ПС принято в расчет в его строении (конструкции).
Тема №9: Обеспечение функциональности, надежности и качества пс. Технологии оценки качества пс.
Обсудим обеспечение примитивов качества ПС, выражающих критерии функциональности и надежности ПС.
Обеспечение завершенности программного средства.
Завершенность ПС является общим примитивом качества ПС для выражения и функциональности и надежности ПС. Функциональность ПС определяется его функциональной спецификацией. Завершенность ПС как примитив его качества является мерой того, насколько эта спецификация реализована в данном ПС.
Обеспечение этого примитива в полном объеме означает реализацию каждой из функций, определенной в функциональной спецификации, со всеми указанными там деталями и особенностями. Однако в спецификации качества ПС могут быть определены несколько уровней реализации функциональности ПС: может быть определена некоторая упрощенная (начальная или стартовая) версия, которая должна быть реализована в первую очередь, могут быть также определены и несколько промежуточных версий.
В этом случае возникает дополнительная технологическая задача: организация наращивания функциональности ПС. Упрощенная версия требуемого ПС должна быть рассчитана на практически полезное применение любыми пользователями, для которых оно предназначено. Поэтому главный принцип обеспечении функциональности такого ПС заключается в том, чтобы с самого начала разрабатывать ПС таким образом, как будто требуется ПС в полном объеме, до тех пор, пока разработчики не будут иметь дело с теми частями или деталями ПС, реализацию которых можно отложить в соответствии со спецификацией его качества. Тем самым, и внешнее описание и описание архитектуры ПС должно быть разработано в полном объеме. Можно отложить лишь реализацию тех программных подсистем, определенных в архитектуре разрабатываемого ПС, функционирования которых не требуется в начальной версии этого ПС.
Источник: studfile.net