stringtranslate.com

Качество программного обеспечения

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

Многие аспекты структурного качества можно оценить только статически посредством анализа внутренней структуры программного обеспечения, его исходного кода (см. Метрики программного обеспечения ), [3] на уровне единицы и на уровне системы (иногда называемом сквозным). завершение тестирования [4] ), что, по сути, означает, что его архитектура соответствует здравым принципам архитектуры программного обеспечения , изложенным в статье по этой теме Object Management Group (OMG). [5]

Однако некоторые структурные качества, такие как удобство использования , можно оценить только динамически (пользователи или другие лица, действующие от их имени, взаимодействуют с программным обеспечением или, по крайней мере, с каким-то прототипом или частичной реализацией; даже взаимодействие с макетом, выполненным в картоне, представляет собой динамическое тестовый, поскольку такую ​​версию можно считать прототипом). Другие аспекты, такие как надежность, могут касаться не только программного обеспечения, но и базового оборудования, поэтому их можно оценивать как статически, так и динамически ( стресс-тест ). [ нужна цитата ]

Функциональное качество обычно оценивается динамически, но также можно использовать статические тесты (например, обзоры программного обеспечения ). [ нужна цитата ]

Исторически структура, классификация и терминология атрибутов и показателей, применимых к управлению качеством программного обеспечения, были получены или извлечены из ISO 9126 и последующего стандарта ISO/IEC 25000. [6] На основе этих моделей (см. «Модели») Консорциум по качеству ИТ-программного обеспечения (CISQ) определил пять основных желательных структурных характеристик, необходимых для того, чтобы часть программного обеспечения обеспечивала ценность для бизнеса : [7] Надежность, эффективность, безопасность, ремонтопригодность и надежность. (адекватный) Размер. [8] [9] [10]

Измерение качества программного обеспечения дает количественную оценку того, в какой степени программное обеспечение или система оценивается по каждому из этих пяти измерений. Совокупный показатель качества программного обеспечения может быть рассчитан с помощью качественной или количественной схемы оценки или их сочетания, а затем с помощью системы взвешивания, отражающей приоритеты. Этот взгляд на качество программного обеспечения, позиционируемый как линейный континуум, дополняется анализом «критических ошибок программирования», которые при определенных обстоятельствах могут привести к катастрофическим сбоям в работе или снижению производительности, что делает данную систему непригодной для использования независимо от рейтинга, основанного на агрегированных измерениях. Такие ошибки программирования, обнаруженные на системном уровне, составляют до 90 процентов производственных проблем, в то время как на уровне единицы, даже если их гораздо больше, ошибки программирования составляют менее 10 процентов производственных проблем (см. также Правило девяноста-девяноста ). Как следствие, качество кода без контекста всей системы, как его описал У. Эдвардс Деминг , имеет ограниченную ценность. [ нужна цитата ]

Для просмотра, исследования, анализа и передачи результатов измерений качества программного обеспечения концепции и методы визуализации информации предоставляют визуальные интерактивные средства, полезные, в частности, если несколько показателей качества программного обеспечения должны быть связаны друг с другом или с компонентами программного обеспечения или системы. Например, карты программного обеспечения представляют собой специализированный подход, который «может выражать и объединять информацию о разработке программного обеспечения, качестве программного обеспечения и динамике системы». [11]

Качество программного обеспечения также играет роль на этапе выпуска программного проекта. В частности, качество и организация процессов выпуска (также процессов исправления ), [12] [13] управления конфигурацией [14] являются важными частями общего процесса разработки программного обеспечения. [15] [16] [17]

Мотивация

Качество программного обеспечения мотивируется как минимум двумя основными точками зрения:

Определения

ИСО

Качество программного обеспечения — это «способность программного продукта соответствовать требованиям». [35] [36], в то время как для других это может быть синонимом создания клиентов или ценности [37] [38] или даже уровня дефектов. [39] Измерения качества программного обеспечения можно разделить на три части: качество процесса, качество продукта, которое включает внутренние и внешние свойства, и, наконец, качество использования, которое является результатом программного обеспечения. [40]

ASQ

ASQ использует следующее определение: Качество программного обеспечения описывает желательные атрибуты программных продуктов. Существует два основных подхода: управление дефектами и атрибуты качества. [41]

НИСТ

Software Assurance (SA) охватывает как имущество, так и процесс его достижения: [42]

PMI

Руководство PMBOK «Расширение программного обеспечения» Института управления проектами определяет не само «качество программного обеспечения» , а обеспечение качества программного обеспечения (SQA) как «непрерывный процесс, который проверяет другие процессы программного обеспечения, чтобы гарантировать, что эти процессы выполняются (включает, например, план управления качеством программного обеспечения).» тогда как контроль качества программного обеспечения (SCQ) означает «заботу о применении методов, инструментов и приемов для обеспечения соответствия рабочих продуктов требованиям к качеству программного обеспечения, находящегося в стадии разработки или модификации». [43]

Другие общие и исторические

Первое определение качества, которое помнит история, было дано Шухартом в начале 20 века: «Есть два общих аспекта качества: один из них связан с рассмотрением качества вещи как объективной реальности, независимой от существования Человек. Другой имеет дело с тем, что мы думаем, чувствуем или ощущаем как результат объективной реальности. Другими словами, существует субъективная сторона качества». [44]

Китченхем и Пфлигер, далее сообщая об учении Дэвида Гарвина, выделяют пять различных точек зрения на качество: [45] [46]

Проблема, присущая попыткам определить качество продукта, практически любого продукта, была сформулирована мастером Уолтером А. Шухартом. Трудность определения качества заключается в том, чтобы преобразовать будущие потребности пользователя в измеримые характеристики, чтобы можно было спроектировать и создать продукт, приносящий удовлетворение по цене, которую заплатит пользователь. Это непросто, и как только человек почувствует себя вполне успешным в своем начинании, он обнаружит, что потребности потребителя изменились, появились конкуренты и т. д. [50]

-  В. Эдвардс Деминг

Качество — это определение потребителя, а не решение инженера, не решение маркетинга и не определение общего руководства. Он основан на реальном опыте клиента с продуктом или услугой, сопоставляемом с его или ее требованиями – заявленными или невысказанными, сознательными или просто ощущаемыми, технически действующими или полностью субъективными – и всегда представляет собой движущуюся цель на конкурентном рынке. [51]

Слово качество имеет несколько значений. Два из этих значений доминируют в использовании этого слова: 1. Качество состоит из тех свойств продукта, которые удовлетворяют потребности клиентов и тем самым обеспечивают удовлетворение продукта. 2. Качество состоит из отсутствия недостатков. Тем не менее, в таком справочнике удобно использовать краткое определение слова «качество» как «пригодность к использованию». [52]

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

Другое определение, предложенное Джеральдом Вайнбергом в книге «Управление качеством программного обеспечения: системное мышление», звучит так: «Качество — это ценность для какого-то человека». [53] [54] В этом определении подчеркивается, что качество по своей сути субъективно: разные люди по-разному воспринимают качество одного и того же программного обеспечения. Одной из сильных сторон этого определения являются вопросы, которые оно предлагает рассмотреть командам разработчиков программного обеспечения, например: «Какие люди мы хотим ценить наше программное обеспечение?» и «Что для них будет ценным?».

Другие значения и противоречия

Одна из проблем определения качества заключается в том, что «каждый чувствует, что понимает это» [55], а другие определения качества программного обеспечения могут быть основаны на расширении различных описаний концепции качества, используемой в бизнесе.

Качество программного обеспечения также часто путают с обеспечением качества , управлением разрешением проблем [56] , контролем качества [57] или DevOps . Он пересекается с ранее упомянутыми областями (см. также определения PMI), но отличается тем, что фокусируется не только на тестировании, но также на процессах, управлении, улучшениях, оценках и т. д. [57]

Измерение

Хотя концепции, представленные в этом разделе, применимы как к структурному, так и к функциональному качеству программного обеспечения, измерение последнего по существу осуществляется посредством тестирования программного обеспечения . [58] Однако тестирования недостаточно: согласно одному исследованию, «отдельные программисты менее чем на 50% эффективны при поиске ошибок в своем собственном программном обеспечении. А большинство форм тестирования эффективны только на 35%. Это затрудняет определение качество [программного обеспечения]». [59]

Введение

Связь между желаемыми характеристиками программного обеспечения (справа) и измеримыми атрибутами (слева)

Измерение качества программного обеспечения заключается в количественном определении того, в какой степени система или программное обеспечение обладает желаемыми характеристиками. Это может быть выполнено с помощью качественных или количественных средств или их сочетания. В обоих случаях для каждой желаемой характеристики существует набор измеримых атрибутов, существование которых в программном обеспечении или системе имеет тенденцию коррелировать и ассоциироваться с этой характеристикой. Например, атрибутом, связанным с переносимостью, является количество операторов, зависящих от цели, в программе. Точнее, при использовании подхода развертывания функции качества эти измеримые атрибуты представляют собой «как», которые необходимо реализовать, чтобы реализовать «что» в приведенном выше определении качества программного обеспечения.

Структура, классификация и терминология атрибутов и показателей, применимых к управлению качеством программного обеспечения, были получены или извлечены из ISO 9126-3 и последующей модели качества ISO/IEC 25000:2005. Основное внимание уделяется внутреннему структурному качеству. Подкатегории были созданы для обработки конкретных областей, таких как архитектура бизнес-приложений и технические характеристики, такие как доступ к данным и манипулирование ими, или понятие транзакций.

Дерево зависимости между характеристиками качества программного обеспечения и их измеримыми атрибутами представлено на диаграмме справа, где каждая из 5 характеристик, имеющих значение для пользователя (справа) или владельца бизнес-системы, зависит от измеримых атрибутов (слева):

Корреляция между ошибками программирования и производственными дефектами показывает, что базовые ошибки кода составляют 92 процента от общего числа ошибок в исходном коде. Эти многочисленные проблемы на уровне кода в конечном итоге составляют лишь 10 процентов дефектов в производстве. Плохие методы разработки программного обеспечения на уровне архитектуры составляют лишь 8 процентов от общего числа дефектов, но отнимают более половины усилий, затрачиваемых на устранение проблем, и приводят к 90 процентам серьезных проблем с надежностью, безопасностью и эффективностью в производстве. [60] [61]

Анализ на основе кода

Многие из существующих программных мер подсчитывают структурные элементы приложения, возникающие в результате анализа исходного кода для таких отдельных инструкций [62], токенов [63] , управляющих структур ( Сложность ) и объектов. [64]

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

Этот взгляд на качество программного обеспечения как на линейный континуум должен быть дополнен выявлением дискретных критических ошибок программирования. Эти уязвимости не могут не пройти проверку, но они являются результатом неправильной практики, которая при определенных обстоятельствах может привести к катастрофическим сбоям в работе, снижению производительности, нарушениям безопасности, повреждению данных и множеству других проблем [65] , которые де-факто делают данную систему уязвимой. непригоден для использования независимо от его рейтинга, основанного на совокупных измерениях. Хорошо известным примером уязвимости является Common Weakness Enumeration , [66] хранилище уязвимостей в исходном коде, которые делают приложения уязвимыми для нарушений безопасности.

Измерение критических характеристик приложения включает в себя измерение структурных атрибутов архитектуры приложения, кодирования и встроенной документации, как показано на рисунке выше. Таким образом, на каждую характеристику влияют атрибуты на многих уровнях абстракции приложения, и все они должны быть включены в расчет меры характеристики, если она должна быть ценным предиктором качественных результатов, влияющих на бизнес. Многоуровневый подход к расчету характеристических показателей, показанный на рисунке выше, был впервые предложен Бёмом и его коллегами из TRW (Boehm, 1978) [67] и является подходом, использованным в стандартах серии ISO 9126 и 25000. Эти атрибуты можно измерить на основе результатов статического анализа исходного кода приложения. Даже динамические характеристики приложений, такие как надежность и эффективность производительности, имеют свои причинные корни в статической структуре приложения.

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

Надежность

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

Оценка надежности требует проверки как минимум следующих передовых методов разработки программного обеспечения и технических характеристик:

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

Эффективность

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

Оценка эффективности производительности требует проверки как минимум следующих передовых методов разработки программного обеспечения и технических характеристик:

Безопасность

Качество программного обеспечения включает в себя безопасность программного обеспечения . [69] Многие уязвимости безопасности возникают из-за плохого кодирования и архитектурных практик, таких как внедрение SQL или межсайтовое выполнение сценариев. [70] [71] Они хорошо документированы в списках, поддерживаемых CWE, [72] и SEI/Центром компьютерных аварийных ситуаций (CERT) в Университете Карнеги-Меллона. [68]

Оценка безопасности требует как минимум проверки следующих передовых методов разработки программного обеспечения и технических характеристик:

Ремонтопригодность

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

Оценка ремонтопригодности требует проверки следующих передовых методов разработки программного обеспечения и технических характеристик:

Ремонтопригодность тесно связана с концепцией технического долга Уорда Каннингема , которая является выражением затрат, возникающих в результате отсутствия ремонтопригодности. Причины низкой ремонтопригодности можно классифицировать как безрассудные и расчетливые и преднамеренные и непреднамеренные [79] [80] и часто возникают в неспособности разработчиков, нехватке времени и целей, их невнимательности и несоответствии стоимости создания. документации и, в частности, поддерживаемого исходного кода . [81]

Размер

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

Стандарт определения размеров анализа функциональных точек поддерживается Международной группой пользователей функциональных точек ( IFPUG ). Его можно применять на ранних этапах жизненного цикла разработки программного обеспечения, и он не зависит от строк кода, как, например, несколько неточный метод Backfireing. Этот метод не зависит от технологии и может использоваться для сравнительного анализа между организациями и отраслями.

С момента появления анализа функциональных точек появилось несколько его вариаций, а семейство методов функционального определения расширилось и теперь включает в себя такие меры определения размера, как COSMIC, NESMA, точки вариантов использования, FP Lite, ранние и быстрые FP и, совсем недавно, Story Points. Тем не менее, функциональные баллы имеют давнюю историю статистической точности и использовались в качестве общей единицы измерения работы в многочисленных проектах по управлению разработкой приложений (ADM) или аутсорсингу, выступая в качестве «валюты», в которой предоставляются услуги и измеряется производительность.

Одним из распространенных ограничений методологии Function Point является то, что это ручной процесс, и поэтому он может быть трудоемким и дорогостоящим в крупномасштабных инициативах, таких как разработка приложений или аутсорсинг. Этот негативный аспект применения методологии, возможно, побудил ИТ-лидеров отрасли сформировать Консорциум по качеству ИТ-программного обеспечения, ориентированный на внедрение стандарта вычислимых показателей для автоматизации измерения размера программного обеспечения, в то время как IFPUG продолжает продвигать ручной подход, поскольку большая часть его деятельности опирается на о сертификации счетчиков ФП.

CISQ определяет определение размера как оценку размера программного обеспечения для поддержки оценки затрат, отслеживания прогресса или других связанных действий по управлению программным проектом. Используются два стандарта: автоматические функциональные точки для измерения функционального размера программного обеспечения и автоматические точки расширения для измерения размера как функционального, так и нефункционального кода в одной мере. [82]

Выявление критических ошибок программирования

Критические ошибки программирования — это конкретные неверные методы архитектуры и/или кодирования, которые приводят к максимальному, немедленному или долгосрочному риску нарушения бизнеса. [83]

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

Критические ошибки программирования также можно классифицировать по характеристикам CISQ. Базовый пример ниже:

Реализованные модели качества

Новые предложения моделей качества, такие как Squale и Quamoco [84], пропагандируют прямую интеграцию определения атрибутов качества и измерения. Разбивая атрибуты качества или даже определяя дополнительные уровни, сложные абстрактные атрибуты качества (такие как надежность или ремонтопригодность) становятся более управляемыми и измеримыми. Эти модели качества применялись в промышленном контексте, но не получили широкого распространения.

Смотрите также

дальнейшее чтение

Рекомендации

Примечания

  1. ^ «Изучение истории: случай разработки требований к программному обеспечению - журнал разработки требований» . Уроки истории: пример разработки требований к программному обеспечению — журнал «Разработка требований» . Проверено 25 февраля 2021 г.
  2. ^ Прессман, Роджер С. (2005). Программная инженерия: подход практикующего специалиста (Шестое международное изд.). Макгроу-Хилл Образование. п. 388. ИСБН 0071267824.
  3. ^ «О спецификации автоматизированных показателей качества исходного кода версии 1.0» . www.omg.org . Проверено 25 февраля 2021 г.
  4. ^ «Как провести сквозное тестирование» . smartbear.com . Проверено 25 февраля 2021 г.
  5. ^ «Как предоставить отказоустойчивые, безопасные, эффективные и легко изменяемые ИТ-системы в соответствии с рекомендациями CISQ» (PDF) . Архивировано (PDF) из оригинала 28 декабря 2013 г. Проверено 18 октября 2013 г.
  6. ^ «ISO/IEC 25010:2011». ИСО . Проверено 23 февраля 2021 г.
  7. ^ Армор, Филипп Г. (1 июня 2012 г.). «Мера контроля». Коммуникации АКМ . 55 (6): 26–28. дои : 10.1145/2184319.2184329. ISSN  0001-0782. S2CID  6059054.
  8. ^ Воас, Дж. (ноябрь 2011 г.). «Секрет программного обеспечения: «-ilities» [качество программного обеспечения]». Программное обеспечение IEEE . 21 (6): 14–15. дои : 10.1109/MS.2004.54. ISSN  1937-4194.
  9. ^ «Стандарты качества кода | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Проверено 25 февраля 2021 г.
  10. ^ «Стандарты определения размера программного обеспечения | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Проверено 25 февраля 2021 г.
  11. ^ Дж. Бонет, Дж. Дёлльнер. Архивировано 27 апреля 2014 г. на Wayback Machine , «Мониторинг качества кода и активности разработки с помощью карт программного обеспечения». Материалы семинара IEEE ACM ICSE по управлению техническим долгом, стр. 9–16, 2011 г.
  12. ^ «IIA - Руководство по глобальному технологическому аудиту: Управление изменениями в ИТ: решающее значение для успеха организации» . na.theiia.org . Проверено 26 февраля 2021 г.
  13. ^ Бурсье, Жером (11 января 2018 г.). «Последствия Meltdown и Spectre: проблемы с исправлениями сохраняются». Лаборатория Малваребайтс . Проверено 26 февраля 2021 г.
  14. ^ «Рекомендации по обновлению программного обеспечения — Configuration Manager» . docs.microsoft.com . Проверено 26 февраля 2021 г.
  15. ^ Райт, Хайрам К. (25 августа 2009 г.). «Релиз процессов, моделей и показателей разработки релизов». Материалы докторского симпозиума ESEC/FSE на Докторантурном симпозиуме . Докторский симпозиум ESEC/FSE '09. Амстердам, Нидерланды: Ассоциация вычислительной техники. стр. 27–28. дои : 10.1145/1595782.1595793. ISBN 978-1-60558-731-8. S2CID  10483918.
  16. ^ ван дер Хук, Андре; Холл, Ричард С.; Хаймбигнер, Деннис; Вольф, Александр Л. (ноябрь 1997 г.). «Управление выпуском программного обеспечения». Заметки по разработке программного обеспечения ACM SIGSOFT . 22 (6): 159–175. дои : 10.1145/267896.267909 . ISSN  0163-5948.
  17. ^ Саттон, Майк; Мур, Тим (30 июля 2008 г.). «7 способов улучшить управление выпусками программного обеспечения». ИТ-директор . Проверено 26 февраля 2021 г.
  18. ^ Кларк, Митчелл (24 февраля 2021 г.). «iRobot говорит, что пройдет несколько недель, прежде чем он сможет устранить проблему с последним обновлением программного обеспечения Roomba». Грань . Проверено 25 февраля 2021 г.
  19. ^ «25 главных ошибок программного обеспечения» . www.sans.org . Проверено 25 февраля 2021 г.
  20. ^ «Выключайте и снова включайте его каждые 149 часов» — тревожное средство от ошибки в программном обеспечении самолета Airbus стоимостью 300 миллионов долларов» . Гизмодо . 30 июля 2019 года . Проверено 25 февраля 2021 г.
  21. ^ «MISRA C, Toyota и смерть Task X» . Проверено 25 февраля 2021 г.
  22. ^ «Обновленная информация о Toyota и непреднамеренном ускорении «Код Барра» . www.embeddedgurus.com . Проверено 25 февраля 2021 г.
  23. ^ Медицинские устройства: Therac-25 *. Архивировано 16 февраля 2008 г. в Wayback Machine , Нэнси Левесон, Вашингтонский университет.
  24. ^ Встроенное программное обеспечение. Архивировано 5 июля 2010 г. в Wayback Machine , Эдвард А. Ли, появится в журнале «Достижения в области компьютеров» ( Марвин Виктор Зелковиц , редактор), Vol. 56, Academic Press, Лондон, 2002 г., в редакции меморандума UCB ERL M01/26 Калифорнийский университет, Беркли, Калифорния 94720, США, 1 ноября 2001 г.
  25. ^ «Программное обеспечение для сертификации самолетов и бортовое электронное оборудование» . Архивировано из оригинала 4 октября 2014 года . Проверено 28 сентября 2014 г.
  26. ^ «Цена плохого качества программного обеспечения в США: отчет за 2020 год | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Проверено 25 февраля 2021 г.
  27. ^ «Что такое отходы? | Agile Alliance» . Гибкий Альянс | . 20 апреля 2016 г. Проверено 25 февраля 2021 г.
  28. Рианна Мэттесон, Скотт (26 января 2018 г.). «Отчет: сбой программного обеспечения привел к финансовым потерям в размере 1,7 триллиона долларов в 2017 году». Техреспублика . Проверено 25 февраля 2021 г.
  29. ^ Кохейн, Райан (16 ноября 2017 г.). «Финансовые затраты на ошибки программного обеспечения». Середина . Проверено 25 февраля 2021 г.
  30. ^ Элофф, Ян; Белла, Мадлен Бихина (2018), «Сбои программного обеспечения: обзор», Исследование сбоев программного обеспечения , Cham: Springer International Publishing, стр. 7–24, doi : 10.1007/978-3-319-61334-5_2, ISBN 978-3-319-61333-8, получено 25 февраля 2021 г.
  31. ^ «Низкое качество программного обеспечения обошлось предприятиям в 2 триллиона долларов в прошлом году и поставило под угрозу безопасность» . Погружение ИТ-директора . Проверено 26 февраля 2021 г.
  32. ^ «Исследование CISQ, спонсируемое Synopsys, оценивает стоимость низкого качества программного обеспечения в 2,08 триллиона долларов США в 2020 году» . финансы.yahoo.com . Проверено 26 февраля 2021 г.
  33. ^ «Сколько будет стоить утечка данных в 2020 году?» Цифровой страж . 06.08.2020 . Проверено 8 марта 2021 г.
  34. ^ «Стоимость отчета об утечке данных 2020 | IBM» . www.ibm.com . 2020 . Проверено 8 марта 2021 г.
  35. ^ «ISO - семейство ISO 9000. Менеджмент качества» . ИСО . Проверено 24 февраля 2021 г.
  36. ^ «ISO/IEC/IEEE 24765:2017». ИСО . Проверено 24 февраля 2021 г.
  37. ^ ab «Освоение автомобильного программного обеспечения». www.mckinsey.com . Проверено 25 февраля 2021 г.
  38. ^ «ISO/IEC 25010:2011». ИСО . Проверено 24 февраля 2021 г.
  39. ^ Уоллес, ДР (2002). «Практическое моделирование надежности программного обеспечения». Материалы 26-го ежегодного семинара НАСА по разработке программного обеспечения имени Годдарда . Гринбелт, Мэриленд, США: IEEE Comput. Соц. стр. 147–155. дои :10.1109/SEW.2001.992668. ISBN 978-0-7695-1456-7. S2CID  57382117.
  40. ^ «ISO/IEC 25023:2016». ИСО . Проверено 6 ноября 2023 г.
  41. ^ «Что такое качество программного обеспечения? | ASQ» . asq.org . Проверено 24 февраля 2021 г.
  42. ^ «SAMATE - Главная страница проекта показателей Software Assurance и оценки инструментов» . НИСТ . 3 февраля 2021 г. Проверено 26 февраля 2021 г.
  43. ^ Программное расширение для руководства PMBOK. Институт управления проектами (5-е изд.). Ньютаун-сквер, Пенсильвания. 2013. ISBN 978-1-62825-041-1. ОКЛК  959513383.{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка ) CS1 maint: другие ( ссылка )
  44. ^ Шуарт, Уолтер А. (2015). Экономический контроль качества выпускаемой продукции. [Место публикации не указано]: Martino Fine Books. ISBN 978-1-61427-811-5. ОСЛК  1108913766.
  45. ^ Китченхэм, Б .; Пфлегер, С.Л. (январь 1996 г.). «Качество программного обеспечения: неуловимая цель [раздел специальных вопросов]». Программное обеспечение IEEE . 13 (1): 12–21. дои : 10.1109/52.476281. ISSN  1937-4194.
  46. ^ Гарвин, Дэвид А. (1988). Управление качеством: стратегическое и конкурентное преимущество. Нью-Йорк: Свободная пресса. ISBN 0-02-911380-6. ОСЛК  16005388.
  47. ^ аб Б. Китченхем и С. Пфлигер, «Качество программного обеспечения: неуловимая цель», IEEE Software, vol. 13, нет. 1, стр. 12–21, 1996.
  48. ^ Кан, Стивен Х. (2003). Метрики и модели в разработке качества программного обеспечения (2-е изд.). Бостон: Аддисон-Уэсли. ISBN 0-201-72915-6. ОСЛК  50149641.
  49. ^ Международная организация по стандартизации, «ISO/IEC 9001: Системы менеджмента качества. Требования», 1999.
  50. ^ У. Э. Деминг, «Выход из кризиса: качество, производительность и конкурентоспособность». Издательство Кембриджского университета, 1988.
  51. ^ А. В. Фейгенбаум, «Тотальный контроль качества», McGraw-Hill, 1983.
  52. ^ Дж. М. Джуран, «Справочник по контролю качества Джурана», McGraw-Hill, 1988.
  53. ^ Вайнберг, Джеральд М. (1991). Управление качеством программного обеспечения: Том 1, Системное мышление. Нью-Йорк, штат Нью-Йорк: Дорсет Хаус. ISBN 0-932633-22-6. ОСЛК  23870230.
  54. ^ Вайнберг, Джеральд М. (1993). Управление качеством программного обеспечения: Том 2, Измерение первого порядка. Нью-Йорк, штат Нью-Йорк: Дорсет Хаус. ISBN 0-932633-22-6. ОСЛК  23870230.
  55. ^ Кросби, П., Качество бесплатно , McGraw-Hill, 1979.
  56. ^ «SUP.9 - Управление решением проблем - Kugler Maag Cie» . www.kuglermaag.com . Проверено 25 февраля 2021 г.
  57. ^ Аб Хоипт (29 ноября 2019 г.). «Организации часто используют термины «гарантия качества» (QA) и «контроль качества» (QC)…». Середина . Проверено 25 февраля 2021 г.
  58. ^ Уоллес, Д.; Уотсон, АХ; Маккейб, Ти Джей (1 августа 1996 г.). «Структурированное тестирование: методология тестирования с использованием метрики цикломатической сложности». НИСТ .
  59. ^ Беллерс, Ричард. «Что такое качество кода? И как улучшить качество кода». Программное обеспечение Perforce . Проверено 28 февраля 2021 г.
  60. ^ «Информационный документ OMG | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Проверено 26 февраля 2021 г.
  61. ^ «Как предоставить отказоустойчивые, безопасные, эффективные и гибкие ИТ-системы в соответствии с рекомендациями CISQ - Технический документ | Группа управления объектами» (PDF) . Архивировано (PDF) из оригинала 28 декабря 2013 г. Проверено 18 октября 2013 г.
  62. ^ «Измерение размера программного обеспечения: основа подсчета исходных заявлений» . resources.sei.cmu.edu . 31 августа 1992 года . Проверено 24 февраля 2021 г.
  63. ^ Холстед, Морис Х. (1977). Элементы программного обеспечения (серия «Операционные и программные системы»). США: ISBN Elsevier Science Inc. 978-0-444-00205-1.
  64. ^ Чидамбер, СР; Кемерер, CF (июнь 1994 г.). «Набор метрик для объектно-ориентированного проектирования». Транзакции IEEE по разработке программного обеспечения . 20 (6): 476–493. дои : 10.1109/32.295895. hdl : 1721.1/48424 . ISSN  1939-3520. S2CID  9493847.
  65. ^ Найгард, Майкл (2007). Выпустите это!. Сафари компании O'Reilly Media (1-е изд.). ISBN 978-0978739218. ОКЛК  1102387436.
  66. ^ «CWE - Перечень общих слабостей» . cwe.mitre.org . Архивировано из оригинала 10 мая 2016 г. Проверено 20 мая 2016 г.
  67. ^ Бем, Б., Браун, младший, Каспар, Х., Липоу, М., МакЛауд, Г.Дж., и Мерритт, М.Дж. (1978). Характеристики качества программного обеспечения. Северная Голландия.
  68. ^ abc «Стандарты кодирования SEI CERT — Безопасное кодирование CERT — Confluence» . wiki.sei.cmu.edu . Проверено 24 февраля 2021 г.
  69. ^ «Качество кода и безопасность кода: как они связаны? | Synopsys». Блог о целостности программного обеспечения . 24 мая 2019 г. Проверено 9 марта 2021 г.
  70. ^ «Стоимость отчета об утечке данных 2020 | IBM» . www.ibm.com . 2020 . Проверено 9 марта 2021 г.
  71. ^ «Основные выводы из отчета о стоимости утечки данных в 2020 году» . Голубой плавник . 27 августа 2020 г. Проверено 9 марта 2021 г.
  72. ^ «CWE - Перечень общих слабостей» . Cwe.mitre.org. Архивировано из оригинала 14 октября 2013 г. Проверено 18 октября 2013 г.
  73. ^ Безопасность в разработке: IBM Secure Engineering Framework | Красные книги IBM. 30 сентября 2016 г.
  74. ^ Архитектура безопасности предприятия с использованием решений безопасности IBM Tivoli | Красные книги IBM. 30 сентября 2016 г.
  75. ^ «Определения проектирования безопасной архитектуры | CISA» . us-cert.cisa.gov . Проверено 9 марта 2021 г.
  76. ^ «Фонд OWASP | Фонд открытого исходного кода для безопасности приложений» . owasp.org . Проверено 24 февраля 2021 г.
  77. ^ "Топ-25 CWE" . Санс.орг . Проверено 18 октября 2013 г.
  78. ^ IfSQ Level-2 Стандарт базового уровня для исходного кода компьютерных программ. Архивировано 27 октября 2011 г. в Wayback Machine , второе издание, август 2008 г., Грэм Болтон, Стюарт Джонстон, IfSQ, Институт качества программного обеспечения.
  79. ↑ Фаулер, Мартин (14 октября 2009 г.). «Технический долговой квадрант». Архивировано из оригинала 2 февраля 2013 года . Проверено 4 февраля 2013 г.
  80. ^ «Качество кода: забота о бизнесе, прибыли и чутких программистах» . Переполнение стека . 18 октября 2021 г. Проверено 5 декабря 2023 г.
  81. ^ Прауз, Кристиан; Дурдик, Зоя (3 июня 2012 г.). «Архитектурное проектирование и документация: потери в гибкой разработке?». Международная конференция по программному обеспечению и системным процессам (ICSSP), 2012 г. Компьютерное общество IEEE. стр. 130–134. doi : 10.1109/ICSSP.2012.6225956. ISBN 978-1-4673-2352-9. S2CID  15216552.
  82. ^ «Стандарты определения размера программного обеспечения | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Проверено 28 января 2021 г.
  83. ^ «Почему программное обеспечение терпит неудачу» . IEEE Spectrum: Новости технологий, техники и науки . 2 сентября 2005 г. Проверено 20 марта 2021 г.
  84. ^ Вагнер, Стефан; Геб, Андреас; Хайнеманн, Ларс; Клас, Майкл; Лампасона, Констанца; Лохманн, Клаус; Майр, Алоис; Плёш, Райнхольд; Зайдль, Андреас (2015). «Реализованные модели и оценка качества продукции: подход Quamoco» (PDF) . Информационные и программные технологии . 62 : 101–123. arXiv : 1611.09230 . doi :10.1016/j.infsof.2015.02.009. S2CID  10992384.
  85. ^ Сурьянараяна, Гириш (2015). «Программный процесс против качества дизайна: перетягивание каната?». Программное обеспечение IEEE . 32 (4): 7–11. дои : 10.1109/MS.2015.87 . S2CID  9226051.
  86. ^ «Профессионал по качеству программного обеспечения | ASQ» . asq.org . Проверено 28 января 2021 г.
  87. ^ "Журнал качества программного обеспечения" . Спрингер . Проверено 28 января 2021 г.

Библиография

Внешние ссылки

На Wikimedia Commons есть средства массовой информации, связанные с качеством программного обеспечения .