Номенклатура показателей качества 11 страница

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

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

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

Методическая достоверность приемо-сдаточных испытаний и оценивания характеристик качества ПС определяется следующими факторами:

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

· достоверностью и точностью эталонных значений характеристик, с которыми сравниваются результаты тестирования испытываемой программы;

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

· точностью и корректностью регистрации и обработки результатов тестирования, сравнения полученных характеристик с требованиями ТЗ.

5.4.3. Альфа– и Бета–тестирование

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

Для таких коммерческих ППП принято проводить оценивание (испытания) в два последовательных этапа:

· Альфа–тестирование;

· Бета–тестирование.

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

При Альфа–тестировании привлекаются наиболее компетентные конечные пользователи, работающие обычно в той же компании, но не участвующие непосредственно в разработке ППП.

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

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

5.4.4. Программная генерация тестов

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

Программ имитации внешней среды на ЭВМ позволяет:

· проводить длительное непрерывное генерирование имитируемых данных для оценивания характеристик функционирования ПС в широком диапазоне изменения условий и параметров;

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

· создавать тестовые данные, соответствующие критическим или опасным ситуациям функционирования объектов внешней среды, которые невозможно или рискованно реализовать при натурных экспериментах;

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

При использовании программных моделей на ЭВМ достоверность генерации тестов определяется следующими факторами:

· адекватностью имитатора моделируемому объекту или источнику информации;

· инструментальной точностью средств, реализующих имитатор внешней среды;

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

· точностью дискретизации имитаторами реальных непрерывных процессов в моделируемых объектах.

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

5.4.5. Обработка результатов испытаний

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

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

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

· данные, отражающие исходную тестовую информацию и выходные результаты испытаний;

· маршруты исполнения программных компонентов и их операторов при некоторых фиксированных тестовых данных;

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

· характеристики использования различных ресурсов ЭВМ.

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

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

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

· данные об отказах, дефектах и ошибках, условиях их проявления и характеристиках обнаруживающих тестов, а также предложения на изменение программ, подлежащие анализу и выделению тех из них, для которых будут разрабатываться корректировки программ;

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

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

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

Вопросы по теме

1. Какие факторы учитываются в технологических затратах в жизненном цикле программных средств?

2. Назначение методологии CMM/CMMI?

3. Охарактеризуйте уровни зрелости процессов согласно методологии CMM/CMMI.

4. Какие отличия и общности имеют стандарты и модели зрелости процессов?

5. Каким образом производится оценивание жизненного цикла программных средств по стандарту ISO 15504?

6. Каким образом производится оценивание жизненного цикла программных средств по стандарту ISO 14598?

7. С какой целью применяется модель внешней среды при оценивании качества программных средств?

8. Как производится испытания программных средств? Что такое программа испытаний, из каких разделов она состоит?

9. Охарактеризуйте Альфа- и Бета-тестирование программных средств.

10. С какой целью производится программная генерация тестов и имитация внешней среды на ЭВМ?

11. Как обрабатываются и фиксируются результаты испытаний?

6. единая система программной документации

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

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

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

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

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

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

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

6.1. Общая характеристика ЕСПД

Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Но уже тогда у программистов была масса претензий к этим стандартам. Что-то требовалось дублировать в документации много раз (как, казалось – неоправданно), а многое не было предусмотрено, как, например, отражение специфики документирования программ, работающих с интегрированной базой данных. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории РБ на основе межгосударственного соглашения по стандартизации.

Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ серии 19) носят рекомендательный характер. Впрочем, это относится и ко всем другим стандартам в области ПС (ГОСТ серии 34, Международному стандарту ISO/IEC и др.). Эти стандарты становятся обязательными на контрактной основе – то есть при ссылке на них в договоре на разработку (поставку) ПС.

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

· ориентацию на единственную каскадную модель ЖЦ ПС;

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

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

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

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

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

ЕСПД нуждается в полном пересмотре на основе стандарта ISO/IEC 12207 на процессы ЖЦ ПС.

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

Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем – обобщенные, но воспринимаемые как весьма жесткие по структуре ЖЦ и проектной документации. Но эти стандарты многими считаются бюрократическими до вредности и консервативными до устарелости.

6.2. Структура ЕСПД

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

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

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

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

При этом стиль применения стандартов может соответствовать современному общему стилю адаптации стандартов к специфике проекта:

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

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

· привязывают создание этих документов к той схеме ЖЦ, которая используется в проекте.

Группы стандартов ЕСПД представлены в табл.6.1.

Таблица 6.1

Группы стандартов ЕСПД

Kод группы	Наименование группы
	Общие положения
	Основополагающие стандарты
	Правила выполнения документации разработки
	Правила выполнения документации изготовления
	Правила выполнения документации сопровождения
	Правила выполнения эксплуатационной документации
	Правила обращения программной документации
7, 8	Резервные группы
	Прочие стандарты

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

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

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

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

В ЕСПД существуют следующие стандарты:

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

· ГОСТ 19.101–77 ЕСПД. Виды программ и программных документов.

· ГОСТ 19.102–77 ЕСПД. Стадии разработки.

· ГОСТ 19.103–77 ЕСПД. Обозначение программ и программных документов.

· ГОСТ 19.104–78 ЕСПД. Основные надписи.

· ГОСТ 19.105–78 ЕСПД. Общие требования к программным документам.

· ГОСТ 19.106–78 ЕСПД. Требования к программным документам, выполненным печатным способом.

· ГОСТ 19.201–78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.

· ГОСТ 19.202–78 ЕСПД. Спецификация. Требования к содержанию и оформлению.

· ГОСТ 19.301–2000 ЕСПД. Программа и методика испытаний.

· ГОСТ 19.401–78 ЕСПД. Текст программы. Требования к содержанию и оформлению.

· ГОСТ 19.402–78 ЕСПД. Описание программы.

· ГОСТ 19.404–79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.

· ГОСТ 19.501–78 ЕСПД. Формуляр. Требования к содержанию и оформлению.

· ГОСТ 19.502–78 ЕСПД. Описание применения. Требования к содержанию и оформлению.

· ГОСТ 19.503–79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.

· ГОСТ 19.504–79 ЕСПД. Руководство программиста.

· ГОСТ 19.505–79 ЕСПД. Руководство оператора.

· ГОСТ 19.506–79 ЕСПД. Описание языка.

· ГОСТ 19.508–79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.

· ГОСТ 19.604–78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.

· ГОСТ 19.701–90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

· ГОСТ 19.781–90. Обеспечение систем обработки информации программное.

6.3. ГОСТ 19.101. Виды программ и программных документов

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

Программу (по ГОСТ 19781) допускается идентифицировать и применять самостоятельно и/или в составе других программ. Их подразделяют на следующие виды:

· компонент – программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса;

· комплекс – программа, состоящая из двух или более компонентов и /или комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.

К программным документам относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. Виды программных документов и их содержание приведены в табл.6.2.

Таблица 6.2

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

Вид программного документа	Содержание программного документа
Спецификация	Состав программы и документации на нее
Ведомость держателей подлинников	Перечень предприятий, на которых хранят подлинники программных документов
Текст программы	Запись программы с необходимыми комментариями
Описание программы	Сведения о логической структуре и функционировании программы
Программа и методика испытаний	Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля
Техническое задание	Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний
Пояснительная записка	Схема алгоритма, общее описание алгоритма и/или функционирования программы, а также обоснование принятых технических и технико-экономических решений
Эксплуатационные документы	Сведения для обеспечения функционирования и эксплуатации программы

Виды эксплуатационных документов и их содержание приведены табл.6.3.

Таблица 6.3

Виды эксплутационных документов

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

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

Виды программных документов, разрабатываемых на разных стадиях разработки ПС, и их коды приведены в табл.6.4.

Стандартом допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в ТЗ. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.

Таблица 6.4

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

Код вида документа	Вид документа	Стадии разработки
Эскизный проект	Технический проект	Рабочий проект
компонент	комплекс
–	Спецификация	–	–	Ä	Å
	Ведомость держателей подлинников	–	–	–	à
	Текст программы	–	–	Å	à
	Описание программы	–	–	à	à
	Ведомость эксплуатационных документов	–	–	à	à
	Формуляр	–	–	à	à
	Описание применения	–	–	à	à
	Руководство системного программиста	–	–	à	à
	Руководство программиста	–	–	à	à
	Руководство оператора	–	–	à	à
	Описание языка	–	–	à	à
	Руководство по техническому обслуживанию	–	–	à	à
	Программа и методика испытаний	–	–	à	à
	Пояснительная записка	à	à	–	–
90–99	Прочие документы	à	à	à	à

Условные обозначения:

Å – документ обязательный;

Ä – документ обязательный для компонентов, имеющих самостоятельное применение;

à – необходимость составления документа определяется на этапе разработки и утверждения технического задания;

– – документ не составляют.

6.4. ГОСТ 19.102. Стадии разработки

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

Таблица 6.5

Стадии разработки программ и программной документации

Стадия разработки	Этапы работ	Содержание работ
1. Техническое задание	Обоснование необходимости разработки программы	· Постановка задачи. · Сбор исходных материалов. · Выбор и обоснование критериев эффективности и качества разрабатываемой программы. · Обоснование необходимости проведения научно-исследовательских работ.
Научно-исследовательские работы	· Определение структуры входных и выходных данных. · Предварительный выбор методов решения задач. · Обоснование целесообразности применения ранее разработанных программ. · Определение требований к техническим средствам. · Обоснование принципиальной возможности решения поставленной задачи.
Разработка и утверждение технического задания	· Определение требований к программе. · Разработка технико-экономического обоснования разработки программы. · Определение стадий, этапов и сроков разработки программы и документации на нее. · Выбор языков программирования. · Определение необходимости проведения научно-исследовательских работ на последующих стадиях. · Согласование и утверждение технического задания.
2. Эскизный проект	Разработка эскизного проекта	· Предварительная разработка структуры входных и выходных данных. · Уточнение методов решения задачи. · Разработка общего описания алгоритма решения задачи · Разработка технико-экономического обоснования.
Утверждение эскизного проекта	· Разработка пояснительной записки. · Согласование и утверждение эскизного проекта.
3. Технический проект	Разработка технического проекта	· Уточнение структуры входных и выходных данных. · Разработка алгоритма решения задачи. · Определение формы представления входных и выходных данных. · Определение семантики и синтаксиса языка. · Разработка структуры программы. · Окончательное определение конфигурации технических средств.
Утверждение технического проекта	· Разработка плана мероприятий по разработке и внедрению программ. · Разработка пояснительной записки. · Согласование и утверждение технического проекта.
4. Рабочий проект	Разработка программы	· Программирование и отладка программы.
Разработка программной документации	· Разработка программных документов в соответствии с требованиями ГОСТ 19.101–77.
Испытания программы	· Разработка, согласование и утверждение порядка и методики испытаний. · Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. · Корректировка программы и программной документации по результатам испытаний.
5. Внедрение	Подготовка и передача программы	· Подготовка и передача программы и программной документации для сопровождения и/или изготовления. · Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. · Передача программы в фонд алгоритмов и программ.