Техники управления качеством программного обеспечения (Software Quality Management Techniques)
Техники SQM могут быть распределены по нескольким категориям:
· статические;
· техники использования человеческих ресурсов;
· аналитические;
· динамические.
Статические техники (Static techniques)
Статические техники предполагают детальное исследование проектной документации, программного обеспечения и другой информации о программном продукте без его исполнения.
Эти техники могут включать другие, рассматриваемые ниже, действия по оценке (см. 3.3.2) или индивидуальному анализу (см. 3.3.3), вне зависимости от степени использования средств автоматизации.
Техники коллективной оценки (People - intensive techniques)
Обычно, такого рода техники предполагают очное взаимодействие специалистов. При этом, встречи специалистов могут требовать предварительной подготовки.
К ресурсам, используемым в таких техниках, наравне с исследуемыми артефактами (продуктом, документацией, моделями и т.п.) могут относится различного рода листы проверки и результаты аналитических техник и работ по тестированию.
Данные техники рассматриваются в стандарте 12207.
3.3.3. Аналитические техники (Analytical techniques)
Инженеры, занимающиеся программным обеспечением, как правило, применяют аналитические техники и гибкие технологии (Agile-методики).
Иногда, несколько инженеров используют одну и ту же технику, но в отношении разных частей продукта. Некоторые техники базируются на специфике применяемых инструментальных средств, другие – предполагают «ручную» работу. Многие могут помогать находить дефекты напрямую, но
|
|
|
чаще всего они используются для поддержки других техник (например, статической).
Ряд техник также включает различного рода экспертизу как составной элемент общего анализа качества. Примеры таких техник - анализ сложности (complexity analysis), анализ управляющей логики (или анализ контроля потоков управления - control flow analysis) и алгоритмический анализ.
Каждый тип анализа обладает конкретным назначением и не все типы применимы к любому проекту.
Примером техники поддержки является анализ направленный на выявление фрагментов дизайна системы, обладающих слишком высокой сложностью для корректной реализации, тестирования или сопровождения. Результат анализа сложности может также применяться для разработки тестовых сценариев.
Может также использоваться анализ управляющей логики. Например, для программного обеспечения с обширной алгоритмической логикой крайне важно применять алгоритмические техники, особенно в тех случаях, когда некорректный алгоритм (не его реализация, а именно логика) может привести к катастрофическим результатам (например, программное обеспечение авионики, для которой вопросы безопасности использования играют решающую роль).
|
|
|
Другие формальные методы применяются для проверки требований.
Проверка корректности применяется к критическим фрагментам программного обеспечения. Кроме того они используются для верификации особо важных частей систем, отвечающих за информационную безопасность и надежность.
Динамические техники (Dynamic techniques)
В процессе разработки и сопровождения программного обеспечения приходится обращаться к различным видам динамических техник. В основном, это техники тестирования.
В качестве динамических техник могут так же рассматриваться техники симуляции, проверки моделей и «символического» исполнения, при этом часто предполагается использование модулей – «пустышек» с эмулируемым входом и выходом при рассмотрении общего сценария поведения многомодульных систем.
Опытный инженер может исполнять код непосредственно в процессе его чтения, используя диалоговые средства пошаговой отладки для ознакомления или оценки чужого кода. Тем самым сочетая статическую (чтение) и динамическую (исполнение) техники.
В зависимости от организации ведения проекта, определенные работы по тестированию могут выполняться при разработке программных систем в SQA и V&V процессах.
|
|
|
План SQM тесно связан с вопросами тестирования. Соответствующие материалы в Лекции 3 «Тестирование ПО».
3.3.5. Тестирование (Testing)
Процессы подтверждения качества, описанные в SQA и V&V планах, исследуют и оценивают любой выходной продукт (включая промежуточный и конечный), связанный со спецификацией требований к программному обеспечению, на предмет трассируемости, согласованности, полноты, завершенности, корректности и выполнения требований.
Подтверждение качества охватывает также любые выходные артефакты процессов разработки и сопровождения, сбора, анализа и количественной оценки результатов.
SQA-деятельность обеспечивает гарантию того, что соответствующие типы тестов спланированы, разработаны и реализованы, а V&V гарантирует разработку планов тестов, стратегий, сценариев и процедур тестирования.
Два типа тестирования следуют задачам, задаваемым SQA и V&V, поэтому на них ложится ответственность за качество данных, используемых в проекте:
Оценка и тестирование инструментов, используемых в проекте (IEEE 1462-98, ISO/IEC 14102 «Information Technology - Guideline for the Evaluation and Selection of CASE Tools»).
|
|
|
Тестирование на соответствие (или оценка тестов на соответствие) компонентов и COTS - продуктов (COTS - commercial of-the-shelf, готовый к использованию продукт) для использования в создаваемом продукте. Для этого существует стандарт (IEEE Std 1465-1998//ISO/IEC12119:1994, IEEE Standard Adoption of International Standard IDO/IEC12119:1994(E), Information Technology – Software Packages - Quality Requirements and Testing.
Иногда, независимые V&V - организации могут требовать возможности мониторинга процесса тестирования и, в определенных случаях, заверять (или, чаще, документировать) реальное выполнение тестов.
Это делается на предмет проверки их поведения в соответствии с заданными процедурами.
С другой стороны, может быть сделано обращение к V&V для оценки самого тестирования: достаточности планов и процедур, соответствия и точности результатов.
Другой тип тестирования, которое проводится под началом V&V - организации – тестирование третьей стороной (third-party testing).
Такая третья сторона сама не является разработчиком продукта и ни в какой форме не связана с разработчиком продукта. Более того, третья сторона является независимым источником оценки, обычно аккредитованным на предмет обладания соответствующими полномочиями (например, организацией-разработчиком того или иного стандарта, соответствие которому оценивается независимым экспертом и чьи действия подтверждены создателем стандарта).
Назначение такого рода тестирования состоит в проверке продукта на соответствие определенному набору требований (например, по информационной безопасности).
Дата добавления: 2018-10-26; просмотров: 210; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!