Войти
В контексте программного обеспечения инженерия, качество программного обеспечения относится к двум взаимосвязанным, но различным понятиям:
Многие аспекты структурного качества можно оценить только статически посредством анализа внутренней структуры программного обеспечения, его источника. код, на уровне единицы, технологический уровень и системный уровень, который, по сути, отражает то, как его архитектура соответствует здравым принципам архитектуры программного обеспечения, изложенным в статье OMG по данной теме. Но некоторые структурные качества, такие как удобство использования, можно оценить только динамически (пользователи или другие лица, действующие от их имени, взаимодействуют с программным обеспечением или, по крайней мере, некоторые прототип или частичная реализация; даже взаимодействие с макетной версией, выполненной из картона, представляет собой динамический тест, потому что такую версию можно считать прототипом). Другие аспекты, такие как надежность, могут включать не только программное обеспечение, но и лежащее в основе оборудование, поэтому его можно оценивать как статически, так и динамически (стресс-тест ).
Функциональное качество обычно оценивается динамически, но также можно использовать статические тесты (например, обзоры программного обеспечения ).
Исторически структура, классификация и терминология атрибутов и показателей, применимых к менеджменту качества программного обеспечения, были получены или извлечены из ISO 9126-3 и последующих ISO 25000: модель качества 2005, также известная как SQuaRE. На основе этих моделей Консорциум качества программного обеспечения ИТ (CISQ) определил пять основных желательных структурных характеристик, необходимых для того, чтобы программное обеспечение могло обеспечить ценность для бизнеса : надежность, эффективность, безопасность, Ремонтопригодность и (адекватный) размер.
Измерение качества программного обеспечения позволяет количественно оценить, в какой степени программа или система оценивают каждое из этих пяти измерений. Агрегированный показатель качества программного обеспечения может быть рассчитан с помощью качественной или количественной схемы оценки или их комбинации, а затем системы взвешивания, отражающей приоритеты. Этот взгляд на качество программного обеспечения, помещенный в линейный континуум, дополняется анализом «критических ошибок программирования», которые при определенных обстоятельствах могут привести к катастрофическим сбоям в работе или снижению производительности, которые делают данную систему непригодной для использования независимо от рейтинга, основанного на агрегированных измерениях. Такие ошибки программирования, обнаруживаемые на системном уровне, составляют до 90% производственных проблем, в то время как на уровне подразделения, даже если они гораздо более многочисленны, ошибки программирования составляют менее 10% производственных проблем. Как следствие, качество кода без контекста всей системы, как W. Эдвардс Деминг описал это, имеет ограниченное значение.
Для просмотра, изучения, анализа и передачи измерений качества программного обеспечения, концепции и методы визуализации информации предоставляют визуальные интерактивные средства, полезные, в частности, если необходимо связать несколько показателей качества программного обеспечения друг к другу или к компонентам программного обеспечения или системы. Например, карты программного обеспечения представляют собой специализированный подход, который «может выражать и объединять информацию о разработке программного обеспечения, качестве программного обеспечения и динамике системы».
«Наука настолько зрелая, насколько его измерительные инструменты »(Луи Пастер в Ebert Dumke, стр. 91). Оценка качества программного обеспечения мотивирована как минимум двумя причинами:
Однако различие между измерением и улучшением качества программного обеспечения во встроенной системе (с акцентом на управление рисками), а качество программного обеспечения в программном обеспечении для бизнеса (с упором на управление затратами и ремонтопригодностью) становится несколько неактуальным. Встроенные системы теперь часто включают в себя пользовательский интерфейс, и их проектировщики не меньше озабочены проблемами, влияющими на удобство использования и производительность пользователей, чем их коллеги, которые сосредоточены на бизнес-приложениях. Последние, в свою очередь, рассматривают ERP или CRM систему как корпоративную нервную систему, время безотказной работы и производительность которой жизненно важны для благополучия предприятия. Эта конвергенция наиболее заметна в мобильных вычислениях: пользователь, который обращается к приложению ERP на своем смартфоне, зависит от качества программного обеспечения на всех типах программных уровней.
В обоих типах программного обеспечения теперь используются многоуровневые технологические стеки и сложная архитектура, поэтому анализом и измерением качества программного обеспечения необходимо управлять комплексным и согласованным образом, независимо от конечного назначения или использования программного обеспечения. В обоих случаях инженеры и руководство должны иметь возможность принимать рациональные решения на основе измерений и анализа, основанного на фактах, в соответствии с заповедью «В Бога (мы) верим. Все остальные приносят данные». ((ошибочно) приписывается У. Эдвардсу Демингу и другим).
Есть много разных определений качества. Для некоторых это «способность программного продукта соответствовать требованиям». (ISO / IEC 9001, комментарий), в то время как для других это может быть синонимом «потребительской ценности» (Highsmith, 2002) или даже уровня дефекта.
Первое определение качества, которое помнит история, дано Шухартом в начале 20 века: есть два общих аспекта качества: один из них связан с рассмотрением качества вещи как объективной реальности. независимо от существования человека. Другой имеет отношение к тому, что мы думаем, чувствуем или ощущаем в результате объективной реальности. Другими словами, есть субъективная сторона качества. (Шухарт)
Китченхэм и Пфлегер, далее сообщая об учении Дэвида Гарвина, выделяют пять различных точек зрения на качество:
Проблема, присущая попыткам определить качество продукта, почти любого продукта, была заявил мастер Уолтер А. Шухарт. Сложность определения качества состоит в том, чтобы преобразовать будущие потребности пользователя в измеримые характеристики, чтобы продукт можно было спроектировать и произвести таким образом, чтобы он приносил удовлетворение по цене, которую заплатит пользователь. Это непросто, и как только человек чувствует себя достаточно успешным в своем начинании, он обнаруживает, что потребности потребителя изменились, появились конкуренты и т. Д.
— W. Эдвардс ДемингКачество - это определение клиента, а не определение инженера, не маркетинговое решение или определение общего руководства. Он основан на фактическом опыте клиента с продуктом или услугой, измеренном в соответствии с его или ее требованиями - заявленными или негласными, осознанными или просто ощущаемыми, технически действующими или полностью субъективными - и всегда представляет собой движущуюся цель на конкурентном рынке.
Слово качество имеет несколько значений. Два из этих значений доминируют в использовании слова: 1. Качество состоит из тех характеристик продукта, которые удовлетворяют потребности клиентов и тем самым обеспечивают удовлетворение продукта. 2. Качество заключается в отсутствии недостатков. Тем не менее, в подобном справочнике удобно стандартизировать краткое определение слова «качество» как «пригодность для использования».
Даже несмотря на то, что «качество является перцептуальным, условным и несколько субъективный атрибут и могут по-разному пониматься разными людьми »(как отмечалось в статье о качестве в бизнесе ), структурные характеристики качества программного обеспечения были четко определены Консорциумом качества программного обеспечения ИТ (CISQ). Под руководством Билла Кертиса, соавтора концепции модели зрелости возможностей и первого директора CISQ; и Каперс Джонс, выдающийся советник CISQ, CISQ определила пять основных желаемых характеристик программного обеспечения, необходимого для обеспечения ценности для бизнеса. В модели House of Quality это «Что» необходимо достичь:
Функциональное качество программного обеспечения определяется как соответствие явно заявленным функциональным требованиям, определенным, например, с помощью анализа Голос клиента (часть инструментария Дизайн для шести сигм и / или задокументировано с помощью вариантов использования ) и уровня удовлетворенности конечных пользователей. Последнее называется удобство использования и связано с тем, насколько интуитивно понятен и быстро реагирует пользовательский интерфейс, насколько легко можно выполнять простые и сложные операции и насколько полезна ошибка . сообщения есть. Как правило, методы и инструменты тестирования программного обеспечения гарантируют, что часть программного обеспечения ведет себя в соответствии с первоначальным дизайном, запланированным пользовательским интерфейсом и желаемой тестируемостью, то есть с настройкой части программного обеспечения для поддержки критериев приемлемости.
Двойное структурное / функциональное измерение качества программного обеспечения согласуется с моделью, предложенной в Стива МакКоннелла в Code Complete, которая разделяет характеристики программного обеспечения на две части: внутренние и внешние качественные характеристики. Внешние качественные характеристики - это те части продукта, с которыми сталкиваются пользователи, а внутренние качественные характеристики - те, которых нет.
Одна из проблем при определении качества заключается в том, что "каждый чувствует они понимают это », и другие определения качества программного обеспечения могут быть основаны на расширении различных описаний концепции качества, используемых в бизнесе.
Доктор. Том ДеМарко предположил, что «качество продукта зависит от того, насколько он меняет мир к лучшему». Это можно интерпретировать как то, что функциональное качество и удовлетворенность пользователей более важны, чем структурное качество при определении качества программного обеспечения.
Другое определение, данное Джеральдом Вайнбергом в книге «Управление качеством программного обеспечения: системное мышление», - «Качество - это ценность для некоторых людей». Это определение подчеркивает, что качество по своей сути субъективно - разные люди будут по-разному воспринимать качество одного и того же программного обеспечения. Одной из сильных сторон этого определения являются вопросы, которые оно предлагает разработчикам обсудить, например: «Кто такие люди, которым мы хотим ценить наше программное обеспечение?» и «Что будет для них ценным?».
Хотя концепции, представленные в этом разделе, применимы как к структурному, так и к функциональному качеству программного обеспечения, измерение последнего в основном выполняется посредством тестирования [см. Основную статью: Тестирование программного обеспечения ].
Взаимосвязь между желательными характеристиками программного обеспечения (справа) и измеряемыми атрибутами (слева). Измерение качества программного обеспечения - это количественная оценка того, в какой степени система или программное обеспечение обладают желательными характеристиками. Это может быть выполнено с помощью качественных или количественных средств или их сочетания. В обоих случаях для каждой желательной характеристики существует набор измеримых атрибутов, наличие которых в программном обеспечении или системе имеет тенденцию коррелировать и связывать с этой характеристикой. Например, атрибут, связанный с переносимостью, - это количество зависимых от цели операторов в программе. Точнее, при использовании подхода Развертывание функции качества эти измеримые атрибуты являются «как», которые необходимо обеспечить, чтобы включить «что» в приведенном выше определении качества программного обеспечения.
Структура, классификация и терминология атрибутов и показателей, применимых к менеджменту качества программного обеспечения, были получены или извлечены из модели качества ISO 9126-3 и последующей модели качества ISO / IEC 25000: 2005. Основное внимание уделяется качеству внутренней структуры. Подкатегории были созданы для обработки конкретных областей, таких как архитектура бизнес-приложений и технических характеристик, таких как доступ к данным и манипулирование ими или понятие транзакций.
Дерево зависимости между характеристиками качества программного обеспечения и их измеряемыми атрибутами представлено на диаграмме справа, где каждая из 5 характеристик, имеющих значение для пользователя (справа) или владельца бизнес-системы, зависит от измеримых атрибутов. (слева):
Корреляция между ошибками программирования и производственными дефектами показывает, что основные ошибки кода составляют 92% от общего числа ошибок в исходном коде. Эти многочисленные проблемы на уровне кода в конечном итоге составляют лишь 10% производственных дефектов. Плохие методы разработки программного обеспечения на уровне архитектуры составляют лишь 8% от общего числа дефектов, но потребляют более половины усилий, затрачиваемых на устранение проблем, и приводят к 90% серьезных проблем с надежностью, безопасностью и эффективностью в производственной среде.
Многие из существующих программных показателей подсчитывают структурные элементы приложения, которые возникают в результате анализа исходного кода для таких отдельных инструкций (Park, 1992), токенов (Halstead, 1977), управляющих структур. (McCabe, 1976) и объекты (Chidamber Kemerer, 1994).
Измерение качества программного обеспечения - это количественная оценка того, в какой степени система или программное обеспечение оценивают по этим параметрам. Анализ может быть выполнен с использованием качественного или количественного подхода или их сочетания для получения совокупного представления [с использованием, например, средневзвешенных значений, которые отражают относительную важность между измеряемыми факторами].
Такой взгляд на качество программного обеспечения в линейном континууме должен быть дополнен идентификацией дискретных критических ошибок программирования. Эти уязвимости не могут не пройти тест, но они являются результатом неправильной практики, которая при определенных обстоятельствах может привести к катастрофическим отключениям, снижению производительности, нарушениям безопасности, повреждению данных и множеству других проблем (Nygard, 2007), из-за которых данная система де-факто непригоден для использования независимо от его рейтинга, основанного на совокупных измерениях. Хорошо известным примером уязвимости является Common Weakness Enumeration, хранилище уязвимостей в исходном коде, которые делают приложения уязвимыми для нарушений безопасности.
Измерение критических характеристик приложения включает измерение структурных атрибутов архитектуры приложения, кодирования и встроенной документации, как показано на рисунке выше. Таким образом, на каждую характеристику влияют атрибуты на различных уровнях абстракции в приложении, и все они должны быть включены в расчет показателя характеристики, если она должна быть ценным предиктором качественных результатов, влияющих на бизнес. Многослойный подход к вычислению характеристических показателей, показанный на рисунке выше, был впервые предложен Бемом и его коллегами из TRW (Boehm, 1978) и является подходом, принятым в стандартах серий ISO 9126 и 25000. Эти атрибуты можно измерить на основе проанализированных результатов статического анализа исходного кода приложения. Даже динамические характеристики приложений, такие как надежность и производительность, имеют свои причинные корни в статической структуре приложения.
Структурный анализ и измерение качества выполняются посредством анализа исходного кода, архитектуры, программной среды, схемы базы данных в отношении принципов и стандартов, которые вместе определяют концептуальную и логическую архитектуру системы. Это отличается от базового локального анализа кода на уровне компонентов, обычно выполняемого инструментами разработки, которые в основном связаны с соображениями реализации и имеют решающее значение во время отладки и тестирования деятельность.
Основные причины низкой надежности обнаруживаются в сочетании несоблюдения надлежащей архитектуры и практики программирования. Это несоответствие может быть обнаружено путем измерения статических атрибутов качества приложения. Оценка статических атрибутов, лежащих в основе надежности приложения, позволяет оценить уровень бизнес-риска и вероятность потенциальных сбоев и дефектов приложения, с которыми оно столкнется при запуске в эксплуатацию.
Оценка надежности требует проверки, по крайней мере, следующих передовых методов разработки программного обеспечения и технических атрибутов:
В зависимости от архитектуры приложения и используемых сторонних компонентов (например, внешних библиотек или фреймворков) пользовательские проверки должны быть определены в соответствии с приведенным выше списком передовых практик, чтобы обеспечить лучшую оценку надежности поставляемого программного обеспечения.
Как и в случае с надежностью, причины неэффективности производительности часто находятся в нарушениях надлежащей архитектуры и практики кодирования, которые могут быть обнаружены путем измерения статических атрибутов качества приложения. Эти статические атрибуты предсказывают потенциальные узкие места в операционной производительности и будущие проблемы масштабируемости, особенно для приложений, требующих высокой скорости выполнения для обработки сложных алгоритмов или огромных объемов данных.
Оценка эффективности производительности требует проверки, по крайней мере, следующих передовых методов разработки программного обеспечения и технических атрибутов:
Большинство уязвимостей безопасности возникает из-за плохого кодирования и архитектурных практик, таких как внедрение SQL или межсайтовые сценарии. Они хорошо задокументированы в списках, поддерживаемых CWE и SEI / Computer Emergency Center (CERT) в Университете Карнеги-Меллона.
Для оценки безопасности требуется, по крайней мере, проверка следующих передовых методов разработки программного обеспечения и технических атрибутов:
Поддерживаемость включает концепции модульности, понятности, изменяемости, тестируемости, возможности повторного использования и передачи от одной группы разработчиков к другой. Они не принимают форму критических проблем на уровне кода. Скорее, плохая ремонтопригодность, как правило, является результатом тысяч незначительных нарушений с лучшими практиками в документации, стратегией предотвращения сложности и базовыми методами программирования, которые отличает чистый и легко читаемый код от неорганизованного и трудно читаемого кода..
Оценка ремонтопригодности требует проверки следующих передовых методов разработки программного обеспечения и технических атрибутов:
Ремонтопригодность тесно связана с концепцией технического долга Уорда Каннингема, которая отражает затраты, связанные с отсутствием ремонтопригодности. Причины низкой ремонтопригодности могут быть классифицированы как безрассудные и осмотрительные, преднамеренные и непреднамеренные, и часто они происходят из неспособности разработчиков, нехватки времени и целей, их небрежности и несоответствий в стоимости создания и выгодах от документации и, в частности, поддерживаемый исходный код.
Для измерения размера программного обеспечения необходимо правильно собрать весь исходный код, включая сценарии структуры базы данных, исходный код манипулирования данными, заголовки компонентов, файлы конфигурации и т. д. По сути, существует два типа размеров программного обеспечения, которые необходимо измерить: технический размер (занимаемая площадь) и функциональный размер:
Анализ функциональной точки. Стандарт калибровки поддерживается Международной группой пользователей функциональных точек (IFPUG). Его можно применять на ранних этапах жизненного цикла разработки программного обеспечения, и он не зависит от строк кода, как несколько неточный метод обратной вспышки. Этот метод не зависит от технологий и может использоваться для сравнительного анализа между организациями и отраслями.
С момента создания анализа функциональных точек было разработано несколько вариаций, и семейство методов функционального определения размеров расширилось за счет включения таких мер определения размера, как COSMIC, NESMA, Use Case Points, FP Lite, Early и Quick FPs, и совсем недавно Story Points. Тем не менее, функциональные точки обладают историей статистической точности и используются в качестве общей единицы измерения работы в многочисленных проектах по управлению разработкой приложений (ADM) или аутсорсингу, выступая в качестве «валюты», в которой предоставляются услуги и измеряется производительность.
Одним из общих ограничений методологии Function Point является то, что это ручной процесс, и поэтому он может быть трудоемким и дорогостоящим в крупномасштабных инициативах, таких как разработка приложений или аутсорсинг. Этот негативный аспект применения методологии может быть тем, что побудило отраслевых ИТ-лидеров сформировать Консорциум по качеству ИТ-программного обеспечения, направленный на введение стандарта вычислимых показателей для автоматизации измерения размера программного обеспечения, в то время как IFPUG продолжает продвигать ручной подход, поскольку большая часть его деятельности зависит от по сертификации счетчиков FP.
CISQ объявила о доступности своего первого метрического стандарта, Automated Function Points, для членов CISQ в CISQ Technical. These recommendations have been developed in OMG's Request for Comment format and submitted to OMG's process for standardization.
Critical Programming Errors are specific architectural and/or coding bad practices that result in the highest, immediate or long term, business disruption risk.
These are quite often technology-related and depend heavily on the context, business objectives and risks. Some may consider respect for naming conventions while others – those preparing the ground for a knowledge transfer for example – will consider it as absolutely critical.
Critical Programming Errorsтакже могут быть классифицированы по характеристикам CISQ. Базовый пример ниже:
Новые предложения по моделям качества, такие как Squale и Quamoco, пропагандируют прямую интеграцию определения атрибутов качества и измерения. Разбивая атрибуты качества или даже определяя дополнительные уровни, сложные абстрактные атрибуты качества (такие как надежность или ремонтопригодность) становятся более управляемыми и измеримыми. Эти модели качества применялись в промышленных условиях, но не получили широкого распространения.
Примечания
Библиография
 | На Wikimedia Commons есть материалы, относящиеся к Качество программного обеспечения. |
