Что такое качество документации ПС

12) Документирование — Технологии программирования

Любой проект должен сопровождаться хоть какой-то документацией (прим. редактора = например readme файл с иноформацией о том как именно использовать «таблетку» — это,так сказать , минимальная документация)

Цели документирования

Документация, создаваемая при разработке программных средств необходима для =

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

Классы документов

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

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

А именно =

ДОКУМЕНТАЦИЯ ПРОЕКТА =

1. Описание проекта
2. Планы
3. Задания исполнителям (задание распределённое между конкретными людьми или группами, участвующими в реализации проекта)
4. отчёт о ходе работ — создаются менеджерами для контролирующих органов
5. Протоколы встреч и обсуждений
6. Отчёты о результатах активности
7. Журналы

ДОКУМЕНТАЦИЯ ПРОДУКТА =

1. Технические требования
2. Технические спецификации
3. Сведения о выпуске (Release notes)
4. Руководства (напр — по эксплуатации и настройки)

——————————————

Документирование процесса разработки (process documentation)

Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС
Они обеспечивают связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами, управляющими разработкой

———————

Типы документов управления

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

Стандарты

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

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

Рабочие документы

Рабочие документы — это основные технические документы, обеспечивающие связь между разработчиками — актуальны в определённое время в рамках процесса разработки

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

Заметки и переписка

Заметки и переписка — Эти документы фиксируют различные детали взаимодействия между менеджерами («самой компании-разработчика» — со слов преподавателя) и разработчиками

—————————

Product documentation (ДОКУМЕНТАЦИЯ ПРОДУКТА)

Документы, входящие в состав ПС (product documentation), описывают ПС =

1. с точки зрения его применения пользователями,
2. с точки зрения его разработчиков и сопроводителей (в соответствии с назначением ПС)

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

Типы документов продукта

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

1. пользовательская документация ПС (П-документация),
2. документация по сопровождению ПС (С-документация)

Теперь подробнее =

Пользовательская документация

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС
К этому типу документации относятся документы, которыми руководствуется пользователь при:

1. при инсталляции ПС,
2. при применении ПС для решения своих задач,
3. при управлении ПС (например, когда данное ПС взаимодействует с другими системами)

.

Категории пользователей

Следует различать две категории пользователей ПС:

1. ординарных пользователей ПС (те , кто используют ПС для решения своих прикладных задач)
2. и администраторов ПС

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

Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ

Например, Администратор ПС может =

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

——————-

Состав документации

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

———————-

Режим использования документа

Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ

Обычно пользователю достаточно больших программных систем требуются =

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

Состав пользовательской документации =

1. Общее функциональное описание ПС с краткой характеристикой функциональных возможностей ПС.

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

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

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

4. Справочник по применению ПС.

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

5. Руководство по управлению ПС.

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

————-

Разработка пользовательской документации

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

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

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

Не всегда получается изложить мысли разработчика в форме понятной для пользователя — но надо стараться или же привлекать так называемых «технических писателей»

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

1. предписывается порядок разработки этой документации,
2. формулируются требования к каждому виду пользовательских документов,
3. определяются их структура и содержание

——————————-

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

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки

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

То есть тексты пишутся для разработчиков , подобных исполнителям (исполнители — это те, кто изначально создали ПС)

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

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

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

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

1. внешнее описание ПС (Requirements document — то есть описание , с точки зрения зависимости от параметров среды , в которой будут выполняться коды ПС — например — зависимость от операционной системы);
2. описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы;
3. для каждой программы ПС — описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

И ещё =

1. для каждого модуля — его спецификация и описание его строения (design description);
2. тексты модулей на выбранном языке программирования (program source code listings);
3. документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС

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

2) Документацию, помогающую вносить изменения в ПС = содержит Руководство по сопровождению ПС (system maintenance guide), которое описывает:

1. известные проблемы, связанные с ПС,
2. какие части системы являются аппаратно- и программно-зависимыми,
3. возможности дальнейшего развития ПС

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

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

———————————-

Автоматизация документирования

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

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

Генератор документации

Генератор документации — программа или пакет программ, позволяющая получать документацию, предназначенную для программистов (документация на API) и/или для конечных пользователей системы, по особым образом комментированному исходному коду и, в некоторых случаях, по исполняемым модулям, полученным на выходе компилятора

Принципы работы генератора документации

Генератор анализирует исходный код программы, выделяя синтаксические конструкции, соответствующие значимым объектам программы (типам, классам, процедурам/функциям и т. п.)

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

На основе всей собранной информации формируется готовая документация в одном из общепринятых форматов.

Источник: http://fkn.ktu10.com/?q=node/454

О стандартах документации

Документация – такая штука, к которой мало кто питает тёплые чувства: скучно, занудно, однообразно. И, тем не менее, иногда не возникает сомнений в её необходимости: ведь кому-то после вас этим пользоваться или, тем паче, модифицировать.

И тогда появляется вопрос: как сделать документацию правильно? Существует тьма статей на тему «как писать документацию», но если вы решили взяться за неё в первый раз, то в новой для вас области не сразу понятно, дело ли пишет автор, или отсебятину выдумывает.

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

Кто-то может сказать «а-а, стандарты! они ещё более адово скучные, чем сама документация!». Ну, не будем врать, есть немного Но если у вас документ в электронном формате – найти необходимое не составляет труда.

И кроме того, ну надо же размочить раздел стандарты уже, а то висит пустой, даже обидно.

Наши

Обратимся сначала к ГОСТ-ам. Они расстраивают датами разработки (впрочем, похоже, за эти годы в документировании не многе изменилось) и радуют бесплатностью.

ГОСТ Р ИСО 9127-94 «Документация пользователя и информация на упаковке для потребительских программных пакетов» – наиболее приглянувшийся мне стандарт из наших.

Довольно кратко (весь документ – около 20 страниц) указаны основные требования к составу и содержанию документации пользователя.

Официальная страница. Скачать PDF.

ГОСТ Р ИСО/МЭК 15910-2002 «Процесс создания документации пользователя программного средства» — стандарт больше отвечает не на вопрос «Что» должно быть в документе, а «Как» должен создаваться документ.

Дополнительно есть подробное описание стиля документа с примером – довольно удобная штука для создания шаблона: один раз запариваешься (и забиваешь в шаблон всё: от выравнивания до формата подписей рисунков), а потом клепаешь документы все одного вида, а не с заголовками разного шрифта.

Официальная страница. Скачать PDF.

ГОСТ-ы серии 19.хх – серия ЕСПД, страсть, какая древняя (в среднем, документы созданы в 78-м году), но зато такие же лаконичные, как в ГОСТ 9127, требования ко многим видам документов.

Ознакомиться.

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» — стандарт на ТЗ. Спасибо Jazzist.

Буржуйские

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

Хотят – могут и деньги брать за свою работу. К счастью, многие стандарты можно скачать по-привычному, по-пиратски.

IEEE Std 1063-2001 «IEEE Standard for Software User Documentation» — в документе обозначены требования к структуре, содержимому и формату инструкций пользователя.

Официальная страница.

IEEE Std 1016-1998 «IEEE Recommended Practice for Software Design Descriptions» — рекомендации к документам, описывающим архитектуру программного обеспечения, то бишь к техническому описанию.

Официальная страница. Особливо понравилась табличка-экстракт основного содержания документа (здесь вольный перевод):

ISO/IEC FDIS 18019:2004 «Guidelines for the design and preparation of user documentation for application software» — рекомендации по созданию документации пользователя. Так сказать, советы «хозяйке на заметку». Довольно приятное руководство с большим количеством примеров (имхо, больше подходит для чтения до или в самом начале создания документации, так как подходит к процессу основательно, от самого планирования). Также в приложениях есть чеклисты «что не забыть сделать в процессе разработки документации» и «что должно быть в документе»
Официальная страница.

ISO/IEC 26514:2008 «Requirements for designers and developers of user documentation» — довольно свежий и, судя по содержанию, полезный документ. Но, как раз, видимо, ввиду его свежести, этот стандарт нигде не найти бесплатно. По крайней мере, мне этого сделать не удалось.

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

UPD

Источник: https://habr.com/post/116825/

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

Когдапрограммист-разработчик получает в той или иной форме задание напрограммирование, перед ним, перед руководителем проекта и перед всей проектнойгруппой встают вопросы:

·   что должно быть сделано, кроме собственнопрограммы?

·   что и как должно быть оформлено в видедокументации?

·   что передавать пользователям, а что ?службе сопровождения?

·   как управлять всем этим процессом?

·   что должно входить в само задание на программирование?

Кроме упомянутых вопросовесть и другие.

На эти и массу другихвопросов когда-то отвечали государственные стандарты на программнуюдокументацию ? комплекс стандартов 19-й серии ГОСТ ЕСПД. Но уже тогда упрограммистов была масса претензий к этим стандартам.

Что-то требовалосьдублировать в документации много раз (как, казалось — неоправданно), а многоене было предусмотрено, как, например, отражение специфики документированияпрограмм, работающих с интегрированной базой данных.

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

2. Общая характеристика состояния

Основу отечественнойнормативной базы в области документирования ПС составляет комплекс стандартовЕдиной системы программной документации (ЕСПД).

Основная и большая частькомплекса ЕСПД была разработана в 70-е и 80-е годы.

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

Говоря о состоянии ЕСПД вцелом, можно констатировать, что большая часть стандартов ЕСПД моральноустарела.

К числу основных недостатковЕСПД можно отнести:

·   ориентацию на единственную, «каскадную»модель жизненного цикла (ЖЦ) ПС;

·   отсутствие четких рекомендаций подокументированию характеристик качества ПС;

·   отсутствие системной увязки с другимидействующими отечественными системами стандартов по ЖЦ и документированиюпродукции в целом, например, ЕСКД;

·   нечетко выраженный подход кдокументированию ПС как товарной продукции;

·   отсутствие рекомендаций посамодокументированию ПС, например, в виде экранных меню и средств оперативнойпомощи пользователю («хелпов»);

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

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

Международный стандарт ISO/IEC12207: 1995-08-01 на организацию ЖЦ продуктов программного обеспечения (ПО)- казалось бы весьма неконкретный, но вполне новый и отчасти «модный»стандарт.

2.1. Краткое представление стандартов ЕСПД

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

·                 стандартыЕСПД вносят элемент упорядочения в процесс документирования ПС;

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

·                 стандартыЕСПД позволяют вдобавок мобильно изменять структуры и содержание установленныхвидов ПД исходя из требований заказчика и пользователя.

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

Стандарты ЕСПД (как и другие ГОСТы) подразделяют на группы, приведенныев таблице:

Обозначение стандарта ЕСПД строят по классификационному признаку:

Обозначение стандарта ЕСПД должно состоять из:

·                 числа19 (присвоенных классу стандартов ЕСПД);

·                 однойцифры (после точки), обозначающей код классификационной группы стандартов,указанной таблице;

·                 двузначногочисла (после тире), указывающего год регистрации стандарта.

Перечень документов ЕСПД

1.             ГОСТ19.001-77 ЕСПД. Общие положения.

Источник: http://prepod-shmu.ucoz.ru/publ/lekcii/trpp/lekcija_5_quot_dokumentirovanie_programmnykh_sredstv_quot/14-1-0-7

Тема 2

Назначение аттестации программного средства.Испытания и оценка качества программного средства. Виды испытаний и методыоценки качества программного средства.

4.1.1. Назначение аттестации программного средства

Аттестация ПС — это авторитетное подтверждение качества ПС [14.1]. Обычно дляаттестации ПС создается представительная (аттестационная) комиссия изэкспертов, представителей заказчика и представителей разработчика.

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

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

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

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

4.1.2. Виды испытаний программного средства

Известны следующие виды испытаний ПС [14.2,14.3], проводимых с цельюаттестации ПС:

1.                 испытания компонент ПС;

2.                 системные испытания;

3.                 приемо-сдаточные испытания;

4.                 полевые испытания;

5.                 промышленные испытания.

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

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

Приемо-сдаточные испытания являются основным видом испытаний приаттестации ПС. Именно с этих испытаний начинает работу аттестационная комиссия.

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

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

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

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

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

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

4.1.3. Методы оценки качества программного средства

Оценка качества ПС по каждому из критериев сводится к оценке каждого изпримитивов, связанных с этим критерием качества ПС, в соответствии с ихконкретизацией, произведенной в спецификации качества этого ПС [12.4]. Методыоценки примитивов качества ПС можно разделить на четыре группы:

1.                 непосредственное измерение показателей примитива качества;

2.                 обработка программ и документации ПС специальными программнымиинструментами (процессорами);

3.                 тестирование программ ПС;

4.                 экспертная оценка на основании изучения программ и документации ПС.

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

, а также путем измерения времени работыразличных устройств и объема занятой памяти ЭВМ при выполнении контрольныхпримеров.

Например, некоторым показателем эффективности по памяти может бытьчисло строк программы на языке программирования, а некоторым показателемэффективности по времени может быть время ответа назапрос.

Использование каких-либо показателей для примитивов качества можетопределяться в спецификации качества ПС. Метод непосредственного измеренияпоказателей примитива качества может сочетаться с использованием тестированияпрограмм.

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

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

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

В ряде случаев для оценки отдельных примитивов качества ПСтестирование применяется в сочетании с другими методами. Так для оценки качествадокументации по применению ПС (П-документированности)тестирование применяется в сочетании с экспертной оценкой этой документации.

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

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

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

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

Для оценки большинства примитивов качества ПС в настоящее время можноприменять только метод экспертных оценок.

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

Литература к лекции

14.1. Г.Майерс. Надежность программногообеспечния. — М.: Мир, 1980. — С. 174-175.

14.2. В.В.Липаев. Тестирование программ. — М.:Радио и связь, 1986. — С. 231-245.

14.3. Д.Ван Тассел. Стиль, разработка,эффективность, отладка и испытание программ. — М.: Мир, 1985. — С. 281-283.

Источник: http://vit-prog.narod.ru/page/TRPP/section_4/subjec_4.1.htm