Характеристики методов, оценки качества ПО




Содержание

1. Система качества ПО………………………………………………2-3 стр.
2. Характеристики методов, оценки качества ПО…………………..4-10 стр.
3. Показатели качества ПО…………………………………………...11-17 стр.
4. Список литературы………………………………………………...18 стр.

 

Система качества ПО

Качество программного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014).

Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015) определяет модель качества продукта, которая включает восемь характеристик верхнего уровня:

· функциональная пригодность;

· уровень производительности;

· совместимость;

· удобство пользования;

· надёжность;

· защищённость;

· сопровождаемость;

· переносимость (мобильность).

В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от субъективного качества в использовании (англ. quality in use model), которое может сильно отличаться для различных стейкхолдеров. Модель включает следующие характеристики верхнего уровня:

· результативность;

· производительность;

· удовлетворенность;

· свобода от риска;

· покрытие контекста.

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

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

В свою очередь, преподаватель психологии и антропологии разработки программного обеспечения Джеральд Вайнберг в своей работе 1992 года Quality Software Management: Volume 1, Systems Thinking дал определение качества как «значимого для какого-либо человека», подчеркивая тем самым, что понятие качества является по своей природе субъективным — разные люди будут оценивать качество одного и того же программного обеспечения по-разному. Одной из сильных сторон этого определения являются вопросы, на которые должны ответить команды разработчиков программного обеспечения, такие как «Кто те люди, которые будут оценивать наше программное обеспечение?» и «Что будет ценным для них?».

В последнее время появляются новые подходы к формализации моделей качества программного обеспечения, такие как SQUALE и Quamoco, предусматривающие прямую интеграцию определений атрибутов качества и их измерений. В данных моделях производится декомпозиция основных сложных атрибутов качества (таких, как надежность и ремонтопригодность), которая может быть проведена с введением дополнительных характеристик, что позволяет сделать эти атрибуты более измеримыми и, следовательно, управляемыми. Эти модели качества были применены в промышленных условиях, но пока не получили широкого распространения.

 

 

Характеристики методов, оценки качества ПО

Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на этот вопрос можно получить с помощью процессов верификации и валидации.

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

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

Эффективность верификации и валидации, как и эффективность разработки ПО в целом зависит от точности и корректности формулировки требований к программному продукту.

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

· Методы и техники, связанные выяснением свойств ПО во время его работы. Это, прежде всего, все виды тестирования, а также профилирование и измерение количественных показателей качества, которые можно определить по результатам работы ПО — эффективности по времени и другим ресурсам, надежности, доступности и пр.

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

· Методы и техники, предназначенные для выявления нарушений формализованных правил построения исходного кода ПО, проектных моделей и документации.

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

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

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

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

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

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

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

Рис.1 - Схема процесса тестирования.

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

На основе исходных данных, используемых для построения тестов, тестирование делят на следующие виды.

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

· Тестирование белого ящика, оно же структурное тестирование — тесты создаются на основе знаний о структуре самой системы и о том, как она работает. Критерии полноты основаны на проценте элементов кода, которые отработали в ходе выполнения тестов. Для оценки степени соответствия требованиям могут привлекаться дополнительные знания о прослеживании требований в определенные ограничения на значения внутренних данных системы (например, на значения параметров вызовов, результатов и локальных переменных).

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

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

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

· Модульное тестирование (unit testing) предназначено для проверки правильности отдельных модулей, вне зависимости от их окружения. При этом проверяется, что, если модуль получает на вход данные, удовлетворяющие определенным критериям корректности, то и результаты его корректны. Для описания критериев корректности входных и выходных данных часто используют программные контракты — предусловия, описывающие для каждой операции, на каких входных данных она предназначена работать, постусловия, описывающие для каждой операции, как должны соотноситься входные данные с возвращаемыми ею результатами, и инварианты, определяющие критерии целостности внутренних данных модуля. Модульное тестирование является важной составной частью отладочного тестирования, выполняемого разработчиками для отладки написанного ими кода.

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

· Системное тестирование (system testing) предназначено для проверки правильности работы системы в целом, ее способности правильно решать поставленные пользователями задачи в различных ситуациях. Системное тестирование тесно связано с тестированием пользовательского интерфейса (или через пользовательский интерфейс), проводимым при помощи имитации действий пользователей над элементами этого интерфейса. Частными случаями этого вида тестирования являются тестирование графического пользовательского интерфейса (Graphical User Interface, GUI) и пользовательского интерфейса Web-приложений (WebUI). Если интеграционное и модульное тестирование чаще всего проводят, воздействуя на компоненты системы при помощи операций предоставляемого ими программного интерфейса (Application Programming Interface, API), то на системном уровне без использования пользовательского интерфейса не обойтись, хотя тестирование через API в этом случае также часто возможно.

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

Рис.2 - Схема процесса проверки свойств ПО на моделях.

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

 

 

Показатели качества ПО

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

Если попросить группу людей высказать своё мнение по поводу того, что такое качественное ПО, можно получить следующие варианты ответов.

· Его легко использовать

· Оно демонстрирует хорошую производительность

· В нем нет ошибок

· Оно не портит пользовательские данные при сбоях

· Его можно использовать на разных платформах

· Оно может работать 24 часа в сутки и 7 дней в неделю

· В него легко добавлять новые возможности

· Оно удовлетворяет потребности пользователей

· Оно хорошо документировано

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

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

Качество программного обеспечения определяется в стандарте ISO 9126 как вся совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.

Тот же стандарт ISO 9126 [1-4] дает следующее представление качества.

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

Рис. 3 - Основные аспекты качества ПО по ISO 9126

Стандарт ISO 9126 [1-4] предлагает использовать для описания внутреннего и внешнего качества ПО многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества ПО. Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Для каждого атрибута определяется набор метрик, позволяющих оценить этот атрибут. Набор характеристик и атрибутов качества согласно ISO 9126 показан на Рис. 4.

Рис.4 - Характеристики и атрибуты качества ПО по ISO 9126.

Ниже приведены определения этих характеристик по стандарту ISO 9126:2001.

· Функциональность (functionality).

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

o Функциональная пригодность (suitability).

Способность решать нужный набор задач.

o Точность (accuracy).

Способность выдавать нужные результаты.

o Способность к взаимодействию (interoperability).

Способность взаимодействовать с нужным набором других систем.

o Соответствие стандартам и правилам (compliance).

Соответствие ПО имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам.

o Защищенность (security).

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

· Надежность (reliability).

Способность ПО поддерживать определенную работоспособность в заданных условиях.

o Зрелость, завершенность (maturity).

Величина, обратная к частоте отказов ПО.

o Устойчивость к отказам (fault tolerance).

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

o Способность к восстановлению (recoverability).

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

o Соответствие стандартам надежности (reliability compliance).

· Удобство использования (usability) или практичность.

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

o Понятность (understandability).

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

o Удобство обучения (learnability).

Показатель, обратный к усилиям, затрачиваемым пользователями чтобы научиться работе с ПО.

o Удобство работы (operability).

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

o Привлекательность (attractiveness).

Способность ПО быть привлекательным для пользователей.

o Соответствие стандартам удобства использования (usability compliance).

· Производительность (efficiency) или эффективность.

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

o Временная эффективность (time behaviour).

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

o Эффективность использования ресурсов (resource utilisation).

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

o Соответствие стандартам производительности (efficiency compliance).

· Удобство сопровождения (maintainability).

Удобство проведения всех видов деятельности, связанных с сопровождение программ.

o Анализируемость (analyzability) или удобство проведения анализа.

Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа на предмет необходимых изменений и их возможных эффектов.

o Удобство внесения изменений (changeability).

Показатель, обратный к трудозатратам на проведение необходимых изменений. o Стабильность (stability). Показатель, обратный к риску возникновения неожиданных эффектов при внесении необходимых изменений.

o Удобство проверки (testability).

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

o Соответствие стандартам удобства сопровождения (maintainability compliance).

· Переносимость (portability).

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

Для описания качества ПО при использовании стандарт ISO 9126-4 [4] предлагает набор характеристик.

· Эффективность (effectiveness).

Это способность ПО предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте.

· Продуктивность (productivity).

Способность ПО предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов.

· Безопасность (safety).

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

· Удовлетворение пользователей (satisfaction).

Способность ПО приносить удовлетворение пользователям при использовании в заданном контексте.

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

 

Список литературы

ГОСТ 28195-89 — Оценка качества программных средств
В. В. Липаев. Методы обеспечения качества крупномасштабных программных средств. М.: Синтег, 2003.
Э. М. Кларк, О. Грамберг, Д. Пелед. Верификация моделей программ: Model Checking. М.: МЦНМО, 2002.
https://www5.in.tum.de/~huckle/bugse.html https://infotech.fanshawec.on.ca/gsantor/Computing/FamousBugs.htm https://www.ima.umn.edu/~arnold/disasters/ariane5rep.html https://www.elcon.org/Documents/EconomicImpactsOfAugust2003Blackout.pdf
Э. Дж. Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004.
Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного обеспечения. М.: Мир, 1991.



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-03-31 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: