| | Введение
В современном мире качеству уделяется все больше и больше внимания. Не удивительно, что в процессе разработки, внедрения и эксплуатации программного средства качеству уделяется много внимания. Существует целая отрасль по управлению качеством со своими "всемирно известными" методами, международными и национальными премиями, стандартами. Однако, далеко не все понимают под качеством одно и то же.
2.1. Качество
Как проверить, что требования определены достаточно полно и описывают все, что хотелось бы видеть в будущей программной системе? Это можно сделать, проследив, все ли необходимые аспекты качества ПО (программных средств, ПС) отражены в них. Именно понятие качественного ПО соответствует представлению о том, что программа достаточно успешно справляется со всеми возложенными на нее задачами и не приносит проблем ни конечным пользователям, ни их начальству, ни службе поддержки, ни специалистам по продажам.
Если попросить группу людей высказать своё мнение по поводу того, что такое качественные ПС, можно получить следующие варианты ответов.
· Их легко использовать
· Они демонстрирует хорошую производительность
· В них нет ошибок
· Они не портит пользовательские данные при сбоях
· Их можно использовать на разных платформах
· Они может работать 24 часа в сутки и 7 дней в неделю
· В них легко добавлять новые возможности
· Они удовлетворяют потребности пользователей
· Они хорошо документированы
Все это действительно имеет непосредственное отношение к качеству ПС. Но все эти ответы выделяют характеристики, важные для конкретного пользователя, разработчика или группы таких лиц. Для того, чтобы удовлетворить потребности всех заинтересованных сторон (конечных пользователей, заказчиков, разработчиков, администраторов систем, в которых оно будет работать, регулирующих организаций и пр.), для достижения прочного положения разрабатываемого по на рынке и повышения потенциала его развития важен учет всей совокупности характеристик ПС, важных для всех заинтересованных лиц.
Приведенные выше ответы показывают, что качество ПО может быть описано большим набором разнородных характеристик. Такой подход к описанию сложных понятий называется холuстuческuм (от греческого целое). Он не дает единой концептуальной основы для рассмотрения затрагиваемых вопросов, какую дает целостная система представлений (например, Ньтоновская механика в физике или классическая теория вычислимости на основе машин Тьюринга), но позволяет, по крайней мере, не упустить ничего достаточно важного.
Качество программных средств определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.
Тот же стандарт ISO 9126 дает следующее представление качества.
1. При рассмотрении качества ПС различаются понятия внутреннего качества, связанного с характеристиками ПС самих по себе, без учета их поведения, внешнего качества, характеризующего ПС с точки зрения их поведения, и качество ПС при использовании в различных контекстах - то качество, которое ощущается пользователями при конкретных сценариях работы ПС. Для всех этих взглядов на качество введены метрики, позволяющие оценить его. Кроме того, при создании качественных ПС существенно качество технологических процессов их разработки.
2.2. Стандарты качества
В начале 1990-х, Международная Организация Стандартизации (МОС) попыталась соединить воедино различные взгляды на качество ПО в одной модели. Основным документом, регламентирующим показатели качества программных средств ранее являлся международный стандарт ISO 9126:191 «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению».
Данный стандарт был впоследствии дополнен аналогичным стандартом (ISO/IEC 9126), состоящим из четырех частей, представляющих собой описание характеристик и субхарактеристик качества, внешних характеристик качества, внутренних характеристик качества и характеристик качества в использовании. Кроме того, появился еще один стандарт ISO/IEC 14598, отражающий оценку программного продукта.
В стандарт ISO/IEC 9126 были введены нормативные подхарактеристики, определено качество программного продукта при использовании, процесс оценки выделился в отдельный документ, а содержание двух стандартов сделали согласованным.
В серии стандартов ISP/IEC 9126 была введена иерархическая модель с шестью основными характеристиками качества, каждая из которых охватывает достаточно широкий спектр вопросов. В связи с этим они были в дальнейшем разбиты на 27 субхарактеристик, определяющих качество внутренней части системы, и 21 характеристику, определяющие внешние качества. ISP/IEC 9126-1 связана, в основном, с определением характеристик качества и субхарактеристик в конечном продукте. ISP/IEC 9126-2 приводит некоторые примеры метрик, характеризующих качество внешней части
системы. ISP/IEC 9126-3 дает некоторые примеры метрик, характеризующих качество внутренней части системы.
2.3. Показатели качества при использовании
Опишем процесс оценки качества ПП при использовании. Процесс включает в себя следующее:
1) установление требований оценки:
· цели (приобретения, снабжения, разработки, функционирования, сопровождения);
· идентификации типа продукции;
· уточнения модели качества.
2) уточнение оценки:
· определения ситуаций использования ПП (пользователей, целей, среды функционирования);
· выбора какой-либо ситуации для оценки;
· выбора показателей (измерения, эффективности, производительности, безопасности, удовлетворения);
· установления критерия оценки;
· интерпретации измерений.
· Для повышения доверия к показателям раскрыты понятия:
· желательных их свойств (надёжности, указательности, доступности, стоимостной эффективности, правильности, осмысленности),
· демонстрации подтверждения эффективности показателей (взаимозависимости, прослеживаемости, логичности, предсказуемости, распознаваемости),
· использования показателей для прогнозирования (прогнозирования будущего и настоящего качества на основе текущих фактов),
· обнаружения отклонений и некорректностей в проблеме качества компонентов,
· отображения результатов измерений.
· Для анализа качества ПП рекомендуется:
· установить различия между средой испытаний и средой эксплуатации;
· установить различия между выполнением функций на испытаниях и при фактической эксплуатации;
· проанализировать состав пользователей;
· оценить степень адекватности результатов между средой испытаний и средой эксплуатации;
· оценить баланс в степени исследования функционирования и измерений;
· установить корректность спецификаций.
Каждый показатель характеризуется следующими данными:
· наименованием;
· назначением;
· методом применения;
· способом измерения, формульной зависимостью и данными, позволяющими проведение расчётов;
· интерпретацией измеряемых величин;
· типами размерности показателей;
· типами измерения (объёмных, временных, расчётных характеристик);
· исходными данными для измерений;
· ссылкой на процесс жизненного цикла, определённый в ISO/IEC 12207;
· полезностью для пользователя.
Рассмотрим теперь более подробно показатели качества при использовании ПП, предлагаемые в стандарте.
1. Показатели эффективности
1.1. Эффективность задачи - характеристика показывает, какая часть задачи завершилась корректно.
1.2. Полнота выполнения задачи - характеристика показывает, какая часть задачи выполнена.
1.3. Частота ошибок
1.4. Частота подсказок - метрика показывает, насколько часто были обращения к помощи (подсказкам). Характеризует интуитивную понятность программы.
2. Показатели производительности
2.1. Производительность задачи - характеристика показывает, насколько производителен пользователь, работающий с программным обеспечением.
2.2. Экономическая производительность - эффективность работы пользователя (с данным ПС) и соотношение его с затратами.
2.3. Соразмерность производительности - характеристика показывает, какая часть (доля) времени работы с ПС используется для решения задачи, т.е. «чистое» время расчета (не включая освоение ПС).
2.4. Относительная продуктивность пользователя – показатель отражает продуктивность пользователя относительно продуктивности эксперта.
3. Показатели безопасности
2.4. Качество программных средств
2.4.1 Модель характеристик качества
Стандарты определяют модель характеристик качества ПС (см. рис. 1), которая состоит из нескольких видов атрибутов качества:
- внутренние атрибуты качества (требования к качеству кода и внутренней архитектуре);
- внешние атрибуты качества (требования к функциональным возможностям и т.д.);
- атрибуты «качества в использовании» (данные атрибуты качества относятся не только к ПС, а ко всей информационной системе, они характеризуют эффект для пользователя от использования ПС в разных контекстах использования);
Рисунок 1. — Качество в жизненном цикле ПС
Требования пользователя к качеству в спецификациях (см. рисунок 2) должны в процессе верификации (проверку того, что ПС разработаны в соответствии со всеми требованиями к нему или что очередной этап разработки выполнен в соответствии с ограничениями, сформулированными на предшествующих этапах) преобразовываться в требования к внешнему качеству, а затем в требования к внутреннему качеству. Процессы реализации требований к внутреннему качеству должны обеспечивать внешнее качество, а последнее — воплощаться в качество для пользователей.
Рисунок 2. — Различные подходы к качеству ПС и соответствующим метрикам качества.
2.4.2 Характеристики качества
Модель внутренних и внешних характеристик качества ПС состоит из шести групп базовых показателей, каждая из которых детализирована несколькими нормативными субхарактеристиками:
1. функциональная пригодность;
1. пригодностью для применения;
2. корректностью (правильностью, точностью);
3. способностью к взаимодействию;
4. защищенностью;
2. надежность;
1. уровнем завершенности (отсутствия ошибок);
2. устойчивостью к дефектам;
3. восстанавливаемостью;
4. доступностью;
5. готовностью;
3. эффективность;
1. временной эффективностью;
2. используемостью ресурсов;
4. применимость;
1. понятностью;
2. простотой использования;
3. изучаемостью;
4. привлекательностью;
5. сопровождаемость;
1. удобством для анализа;
2. изменяемостью;
3. стабильностью;
4. тестируемостью;
6. переносимость;
1. адаптируемостью;
2. простотой установки (инсталляции);
3. сосуществованием (соответствием);
4. замещаемостью.
Дополнительно каждая характеристика сопровождается субхарактеристикой — согласованностью, которая должна отражать отсутствие противоречий с прочими стандартами и нормативными документами, а также с другими показателями в этих сериях стандартов.
В стандартах также определена модель характеристик качества в использовании. В этой модели используются несколько другие базовые характеристики по сравнению с моделью внутреннего и внешнего качества. Основными характеристиками качества ПС в использовании являются:
- системная эффективность применения программного продукта (ПП) по назначению;
- продуктивность;
- безопасность;
- удовлетворение требований и затрат пользователей в соответствии с целями применения ПС.
2.5. Тестирование программного обеспечения.
Тестирование ПО - это процесс выполнения программы с целью обнаружения в ней ошибок
Тестирование проводится с целью обеспечить качество разрабатываемого программного продукта. Стандарт ISO-8402, посвященный описанию систем обеспечения качества программного обеспечения, под качеством понимает "совокупность характеристик программного продукта, относящихся к его способности удовлетворять установленные и предполагаемые потребности клиента". Основным параметром качества программы является надёжность. Надёжность определяется как вероятность его работы без отказов в течении определённого периода времени, рассчитанная с учётом стоимости для пользователя каждого отказа. Отказ программного обеспечения - это проявление ошибки в нём. Отсюда тестирование ПО - это процесс выполнения программы с целью обнаружения в ней ошибок. "Удачным" тестом является такой, на котором выполнение программы завершилось с ошибкой. Напротив, "неудачным" называется тест, не позволивший выявить ошибку в программе. Основные принципы организации тестирования:
1. Необходимой частью каждого теста должно являться описание ожидаемых результатов работы программы;
2. Программе не должна тестироваться её автором;
3. Организация - разработчик программного обеспечения не должна "единолично " его тестировать;
4. Необходимо подбирать тесты не только для правильных (предусмотренных) входных данных, но и для неправильных (непредусмотренных);
5. При анализе результатов каждого теста необходимо проверять, не делает ли программа того, что она не должна делать;
6. "Принцип скопления ошибок" - вероятность наличия не обнаруженных ошибок в некоторой части программы прямо пропорциональна числу ошибок, уже обнаруженных в этой части;
Процесс тестирования состоит из трёх этапов:
1. Проектирование тестов.
2. Исполнение тестов.
3. Анализ полученных результатов.
На первом этапе решается вопрос о выборе некоторого подмножества множества тестов, которое сможет найти наибольшее количество ошибок за наименьший промежуток времени. На этапе исполнения тестов проводят, запуск тестов и отлавливают ошибки в тестируемом программном продукте. Существует две методологии тестирования - "чёрного" и "белого" ящика.
- "Чёрный ящик" - тестирование функционального поведения программы с точки зрения внешнего мира (текст программы не используется).
- "Белый ящик" - тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка на котором она писалась.
Полученные результаты тестирования позволяют сделать вывод о надёжности программного продукта. Они служат основой его сертификации и гарантией качества.
Чтобы облегчить и ускорить процесс тестирования широко применяют автоматизацию одного или ряда сложных этапов тестирования. На рынке программного обеспечения (ПО) существует множество фирм, предлашгающих свои автоматизированные средства тестирования. Ниже приведён список наиболее известных среди них:
- Compuware Corporation (DevPartner`s)
- Rational Software from IBM
- Gcov (open source program for TrueCoverage)
- Различные редакторы и средства облегчающие редактирование текста(EditPlus 2, WinEdit и т.д.)
Автоматизированные средства разрабатываются в основном для следующих этапов процесса тестирования:
- Тестирование функциональных требований
- Тестирование пользовательского интерфейса
- Тестирование отдельных модулей
- Комплексное тестирование
- Анализ сложности программных модулей
- Тестирование покрытия программного кода
- Тестирование скорости загрузки системы
- Тестирование граничных условий
- Тестирование утечки памяти
Существует два основных вида тестирования: функциональное и структурное. При функциональном тестировании программа рассматривается как "черный ящик" (то есть ее текст не используется). Происходит проверка соответствия поведения программы ее внешней спецификации. Критерием полноты тестирования в этом случае является перебор всех возможных значений входных данных, что невыполнимо. Поскольку исчерпывающее функциональное тестирование невозможно, речь может идти о разработки методов, позволяющих подбирать тесты не "вслепую", а с большой вероятностью обнаружения ошибок в программе. При структурном тестировании программа рассматривается как "белый ящик" (т.е. ее текст открыт для пользования). Происходит проверка логики программы. Полным тестированием в этом случае будет такое, которое приведет к перебору всех возможных путей на графе передач управления программы (ее управляющем графе). Если ограничиться перебором только линейных не зависимых путей, то и в этом случае исчерпывающее структурное тестирование практически невозможно, т. к. неясно, как подбирать тесты, чтобы обеспечить "покрытие" всех таких путей. Поэтому при структурном тестировании необходимо использовать другие критерии его полноты, позволяющие достаточно просто контролировать их выполнение, но не дающие гарантии полной проверки логики программы. Но даже если предположить, что удалось достичь полного структурного тестирования некоторой программы, в ней тем не менее могут содержаться ошибки, т.к.
1) программа может не соответствовать своей внешней спецификации, что в частности, может привести к тому, что в ее управляющем графе окажутся пропущенными некоторые необходимые пути; 2) не будут обнаружены ошибки, появление которых зависит от обрабатываемых данных (т.е. на одних исходных данных программа работает правильно, а на других - с ошибкой).
Таким образом, ни структурное, ни функциональное тестирование не может быть исчерпывающим. Чтобы увеличить процент обнаружения ошибок при проведении функционального и структурного тестирования используют средства автоматизации тестирования.
2.5.1. Организация тестирования программ.
Тестирование программного продукта одновременно проводится в 3-ёх направлениях:
1. Проверка кода (review): Тестер просматривает исходный код визуально и пытается найти нём ошибки, а так же различные несоответствия кода и требований к нему. Под требованием понимается стандарт, которого придерживается разработчики данного проекта, реакция на те или иные действия со стороны среды воздействия на ПО, поведение программного продукта в различных ситуациях.
2.Тестирование высокого уровня: Здесь главная цель тестирования - выяснить, удовлетворяет ли разработка всем требованиям заказчика. Для программного продукта пишутся эмуляторы, с помощью которых тестер может наблюдать за работой системы в роли оператора. Он видит, как система осуществляет диалог с пользователем, какие сообщения она выдаёт, как реагирует на различные события, сохраняет информацию и т.д.. Большинство обнаруживаемых ошибок на этом этапе связанно с ошибками взаимодействия программного продукта с пользователем - вывод ошибочных сообщений, не правильная реакция на запрос от оператора и т.п.
3.Тестирование низкого уровня: Тестер проверяет, на сколько логически полно исходный код покрывает всё возможные варианты работы системы, для которой он разрабатывается.
Существуют стандарты тестирования, они зависят от того в какой области применяется разрабатываемое ПО. Ниже представлены некоторые из них:
Стандарт ISO 9001
ISO 9001 - стандарт, основанный на принципах контроля качества. В нём, по существу, задаются ключевые функциональные требования, для каждого из которых нужно сказать, что делается, как сделать то, что сказано, и иметь возможность показать, что было сделано. Реализация данного стандарта в среде ПО - ISO 9000-3.
Стандарт ISO/IEC 12207 и IEEE/EIA 12207
ISO/IEC 12207 - это международный стандарт, описывающий структуру процессов жизненного цикла ПО от концепции до изъятия из обращения. Стандарт IEEE/EIA 12207 - адаптация ISO/IEC 12207 для США.
В соответсвии с этими стандартами в той или иной отрасли производства выдвигаются требования к тестрованию ПО. Например в авиации США на основе ISO/IEC 12207 был выработан стандарт RTCA(Requirements and Technical Concepts for Aviation). В нём перечисленны следующие требования к тестированию верхнего и нуижнего уровня: Тестирование верхнего уровня:
- Требования высокого уровня должны включать в себя системные требования к ПО
- Требования высокого уровня должны формулироваться с учётом архитектуры ПО
- Программный код должен удовлетворять архитектуре ПО и требованиям низкого уровня
- Откомпилированный и готовый к использованию код должен удовлетворять требованиям к ПО
- Используемые значения должны технически соответствовать поставленным целям и выполнять их для всех уровней ПО
Тестирование нижнего уровня:
- Проверку (Verification) требований нижнего уровня
- Проверку архитектуры программного обеспечения (ПО)
- Проверку логического покрытия для всех функций написанных в ПО
- Контроль процедур тестирования
- Независимость ПО от тестирования. Т.е. ПО не должно перестраиваться особым образом под тесты
- Тестирование должно несколько раз покрывать исходный код, для обнаружения определённого класса ошибок
- Робастное тестирование
- Тестирование на предмет косвенного обнаружения ошибок. Например: соответствие стандартам разработки ПО.
2.5.2. Верификация и валидация
Валидация – процесс, позволяющий определить, насколько точно с позиций потенциального пользователя некоторая модель представляет заданные сущности реального мира.
Верификация - процесс, позволяющий определить, что разработанное программное средство точно реализует концептуальное описание данной системы.
Согласно модели T.I.N.A. (www.tinac.com — «Открытая архитектура для разработки распределенного программного обеспечения»), верификация продолжается вплоть до момента кодирования программы, а валидация осуществляется непосредственно после. Однако в большинстве случаев процессы верификации, валидации, тестирования и реализации пересекаются по времени.
Сегодня используются два подхода к валидации программного обеспечения. Первый подход, дедуктивный, представлен такими направлениями исследований, как автоматическое доказательство теорем, использованием мультимножеств и графов, а также разнообразных специализированных алгебр. Программная система описывается в рамках некоего формализма, после чего выполняется строгое математическое доказательство обладания данной системой тех или иных свойств. Второй подход — модельный; его последователи не стремятся вписать систему в рамки теории, а вместо этого строят модель системы, которую можно рассматривать как машину или автомат. Любое требование к системе проверяется для каждого возможного состояния автомата.
Сильные и слабые стороны модельного подхода
Модельных подходов известно, по меньшей мере, несколько дюжин — конечные автоматы, сети Петри, временные автоматы, логическое описание и т.п. Попробуем перечислить присущие им общие сильные свойства.
Модельный подход поддерживает не только полную, но и частичную верификацию, которая может быть направлена на проверку только одного небольшого свойства, абстрагировавшись от менее важных деталей системы. Иными словами, для проведения верификации не обязательно добиваться формализации всех без исключения требований спецификации. В отличие от тестирования и использования симуляторов, в модельном подходе не существует такого понятия, как вероятность обнаружения ошибки: если ошибка есть, она будет обнаружена за конечное время.
В том случае, когда свойство оказывается нарушенным, в виде контрпримера предоставляется диагностирующая информация.
Процесс проверки моделей не требует ни ручного управления со стороны пользователя, ни высокого уровня профессионализма. Имея модель, можно автоматически проверять на ней необходимые свойства. Процесс проверки интегрируется в стандартный цикл проектирования, позволяя, как показывает практика, уменьшить время создания приложений с учетом проведения рефакторинга программного кода.
Однако у модельного подхода есть и слабые стороны. Верификация осуществляется по модели, а не по реальной системе, поэтому ценность полученного результата напрямую зависит от корректности модели, что требует высокого уровня подготовки персонала, создающего модели программ.
Преобладает ориентация на приложения, в которых главную роль играет поток управления, а не поток данных, так как данные имеют тенденцию принимать значения из бесконечных множеств. Такая ориентация уменьшает возможности универсального применения, однако обычно это не столь существенно при разработке больших аппаратно-программных комплексов, поскольку практически все существующие виды модульных приложений, из которых складываются подобные комплексы, можно либо в том или ином виде привести к модели «потока управления», либо корректировать методику тестирования для каждого конкретного модуля. Модельный подход не может эффективно применяться без точных алгоритмов принятия решений. Нет гарантий полноты: проверяются только те свойства, которые указаны явно.
Построение моделей и формулировка требований требуют высокого уровня знаний и умения их применять. Результаты могут вводить в заблуждение (верификатор — тоже программа и тоже может ошибаться, модель может содержать ошибку и т.п.; правда, основные процедуры проверки моделей формально доказаны с помощью пакетов автоматического доказательства теорем). Нет верификаторов, поддерживающих обобщения, например, нельзя проверить систему, если в ней не зафиксировать число сущностей.
Примеры успешного применения модельного подхода можно обнаружить, изучая процесс разработки сложных систем, оперирующих большими потоками данных: СУБД, комплексы потоковой обработки речевой и текстовой информации, системы обеспечения информационной безопасности. Модельный подход к верификации программного обеспечения позволяет, при правильном разбиении всего комплекса, при проектировании и разработке модулей и более атомарных составляющих выявлять логические ошибки еще на этапе проектирования. Так, при разработке программного обеспечения потоковой обработки растровых изображений в рамках модельного подхода была сформирована модель для верификации менеджера заданий для потоковой обработки и обработчиков атомарных заданий, позволившая выявить ошибки в проектировании протоколов взаимодействия модулей комплекса и алгоритме определения обработчика атомарного задания. Данная модель основана на использовании сетей Петри и сопутствующих алгоритмов.
|
