Суббота, 20 Апр 2024, 12:31
Uchi.ucoz.ru
Меню сайта
Форма входа

Категории раздела
Учителю физики [224]
Учителю химии [112]
Учителю биологии [744]
Учителю информатики [147]
Учителю математики [110]
Учителю русского языка [250]
Учителю астрономии [437]
Учителю иностранного языка [182]
Учителю истории (открытые уроки) [151]
Учителю обществознания [53]
Учителю истории [354]
Учителю труда [14]
Учителю ОБЖ [2]
Учителю искусствоведения [0]
Изо
Учителю белорусского языка и литературы [1]
Учителю допризывной и медицинской подготовки [0]
Учителю географии [9]
Учителю МХК [1]
Учителю музыки [3]
Учителю физкультуры [15]
Учителю черчения [0]
Новости
Чего не хватает сайту?
500
Статистика
Зарегистрировано на сайте:
Всего: 51635


Онлайн всего: 1
Гостей: 1
Пользователей: 0
Яндекс.Метрика
Рейтинг@Mail.ru

Каталог статей


Главная » Статьи » По предмету » Учителю информатики

ДОКУМЕНТИРОВАНИЕ ПРОГРАММНЫХ СРЕДСТВ
1. Документация, создаваемая и используемая в процессе разработки программных средств.
2. Пользовательская документация программных средств.
3. Документация по сопровождению программных средств.
4. Классификация стандартов на ЕСПД.


1. Документация, создаваемая и используемая в процессе разработки программных средств.
При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как:
- средство передачи информации между разработчиками ПС,
- средство управления разработкой ПС
- средство передачи пользователям информации, необходимой для применения и сопровожде-ния ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы:
• Документы управления разработкой ПС.
• Документы, входящие в состав ПС.
Документы управления разработкой ПС (software process documentation) управляют и протоко-лируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разра-ботчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers)  ли-цами, управляющими разработкой ПС. Эти документы могут быть следующих типов:
• Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС.
• Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.
• Стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС.
• Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.
• Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и со-проводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы бу-дут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровожде-ния), но и на стадии разработки для управления процессом разработки (вместе с рабочими доку-ментами)  во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:
• Пользовательская документация ПС (П-документация).
• Документация по сопровождению ПС (С-документация).

2. Пользовательская документация программных средств.
Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС. Она необходима, если ПС предпола-гает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при установке ПС с со-ответствующей настройкой на среду применения ПС), при применении ПС для решения своих за-дач и при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с други-ми системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ.
При создании пользовательской документации следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС.
Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих дета-лей работы компьютера или принципов программирования.
Администратор ПС (system administrator) управляет использованием ПС ординарными пользо-вателями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в ра-бочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом исполь-зуется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).
В соответствии со сказанным можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:
• Общее функциональное описание ПС. Дает краткую характеристику функциональных воз-можностей ПС. Предназначено для пользователей, которые должны решить, насколько необходи-мо им данное ПС. (ГОСТ 19.401-78. Единая система программной документации. Текст програм-мы, требования к содержанию и оформлению).
• Руководство по инсталяции ПС. Предназначено для администраторов ПС. Оно должно де-тально предписывать, как устанавливать системы в конкретной среде, в частности, должно содер-жать описание компьютерно-считываемого носителя, на котором поставляется ПС, файлы, пред-ставляющие ПС, и требования к минимальной конфигурации аппаратуры.
• Инструкция по применению ПС. Предназначена для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для ее изуче-ния.
• Справочник по применению ПС. Предназначен для ординарных пользователей. Содержит не-обходимую информацию по применению ПС, организованную в форме удобной для избиратель-ного поиска отдельных деталей.
• Руководство по управлению ПС. Предназначено для администраторов ПС. Оно должно опи-сывать сообщения, генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти сообщения. Кроме того, если ПС использует системную аппа-ратуру, этот документ может объяснять, как сопровождать эту аппаратуру.
Как уже говорилось ранее (см. лекцию 4), разработка пользовательской документации начинается сразу после создания внешнего описания. (ГОСТ 2.119-73. Единая система конструкторской доку-ментации. Эскизный проект. ГОСТ 2.120-73. Единая система конструкторской документации. Технический проект).
Качество этой документации может существенно определять успех ПС. Она должна быть достаточно проста и удобна для пользователя (в противном случае это ПС, вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создают-ся основными разработчиками ПС, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества пользователь-ской документации разработан ряд стандартов, в которых предписывается порядок разработки этой документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и содержание.

3. Документация по сопровождению программных средств.
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно уст-роена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение  это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС,  с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой).
Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документация по сопровождению ПС можно разбить на две группы:
(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;
(2) документацию, помогающую вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
• Внешнее описание ПС (Requirements document)
ГОСТ 19.202-78. Единая система программной документации. Спецификация, требования к со-держанию и оформлению.
• Описание архитектуры ПС (description of the system architecture), включая внешнюю специ-фикацию каждой ее программы (подсистемы).
ГОСТ 19.003-80 Схемы алгоритмов и программ. Обозначения условные графические
• Для каждой программы ПС  описание ее модульной структуры, включая внешнюю специ-фикацию каждого включенного в нее модуля.
• Для каждого модуля  его спецификация и описание его строения (design description).
• Тексты модулей на выбранном языке программирования (program source code listings)
ГОСТ 19.401-78. Единая система программной документации. Текст программы, требования к со-держанию и оформлению.
• Документы установления достоверности ПС (validation documents), описывающие, как уста-навливалась достоверность каждой программы ПС и как информация об установлении достовер-ности связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего, документацию по тести-рованию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ. Для обеспечения приемлемого качества этой документации полезно следовать общепринятым рекомендациям и стандартам.
Документация второй группы содержит
• Руководство по сопровождению ПС (system maintenance guide), которое описывает особенно-сти реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены воз-можности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми.
Общая проблема сопровождения ПС  обеспечить, чтобы все его представления шли в ногу (ос-тавались согласованными), когда ПС изменяется. Чтобы этому помочь, связи и зависимости меж-ду документами и их частями должны быть отражены в руководстве по сопровождению, и зафик-сированы в базе данных управления конфигурацией.

4. Классификация стандартов на ЕСПД
Стандарты ЕСПД подразделяют на группы, приведённые в таблице:
Код группы Наименование группы
0 Общие положения
1 Основополагающие стандарты
2 Правила выполнения документации разработки
3 Правила выполнения документации изготовления
4 Правила выполнения документации сопровождения
5 Правила выполнения эксплуатационной документации
6 Правила обращения программной документации
7 Резервные группы
8
9 Прочие стандарты
3.2. Обозначение стандарта ЕСПД строят по классификационному признаку.
Обозначение стандарта ЕСПД должно состоять из:
цифр 19, присвоенных классу стандартов ЕСПД;
одной цифры (после точки), обозначающей код классификационной группы стандартов, ука-занной в таблице;
двузначного числа (после тире), указывающего год регистрации стандарта.
Пример обозначения стандарта "Единая система программной документации. Общие положе-ния".
ГОСТ 19 . 0 01 -77
Год регистрации стандарта.

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

Классификационная группа стандартов

Класс (стандарты ЕСПД)

Категория стандарта (государственный стандарт)
Категория: Учителю информатики | Добавил: Wrecker (31 Июл 2012)
Просмотров: 785 | Рейтинг: 1.0/ 5 Оштрафовать | Жаловаться на материал
Похожие материалы
Всего комментариев: 0

Для блога (HTML)


Для форума (BB-Code)


Прямая ссылка

Профиль
Суббота
20 Апр 2024
12:31


Вы из группы: Гости
Вы уже дней на сайте
У вас: непрочитанных сообщений
Добавить статью
Прочитать сообщения
Регистрация
Вход
Улучшенный поиск
Поиск по сайту Поиск по всему интернету
Наши партнеры
Интересное
Популярное статьи
Портфолио ученика начальной школы
УХОД ЗА ВОЛОСАМИ ОЧЕНЬ ПРОСТ — ХОЧУ Я ЭТИМ ПОДЕЛИТ...
Диктанты 2 класс
Детство Л.Н. Толстого
Библиографический обзор литературы о музыке
Авторская программа элективного курса "Практи...
Контрольная работа по теме «Углеводороды»
Поиск
Главная страница
Используются технологии uCoz