Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

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

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

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

Мотивация [ править ]

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

  • Управление рисками : Программный сбой вызвал больше, чем неудобство. Ошибки программного обеспечения могут привести к гибели людей (см., Например: Список ошибок программного обеспечения ). Причины варьировались от плохо разработанных пользовательских интерфейсов для прямых ошибок программирования , [18] [19] [20] смотри, например , Boeing 737 случая или ускорения Непреднамеренных случаев [21] [22] или Therac-25 случаев. [23] Это привело к появлению требований к разработке некоторых типов программного обеспечения, в частности, исторически для встроенного программного обеспечения.в медицинских и других устройствах, которые регулируют критически важные инфраструктуры: «[Инженеры, которые пишут встроенное программное обеспечение] видят, что программы Java останавливаются на одну треть секунды, чтобы выполнить сборку мусора и обновить пользовательский интерфейс, и они представляют себе самолеты, падающие с неба». [24] В Соединенных Штатах в рамках Федерального авиационного управления (FAA) Служба сертификации самолетов FAA предоставляет программное обеспечение, политику, рекомендации и обучение, уделяя особое внимание программному обеспечению и сложному электронному оборудованию, которое оказывает влияние на бортовой продукт (" продукт "- самолет, двигатель или пропеллер". [25] Стандарты сертификации, такие как DO-178C , ISO 26262 , IEC 62304.и т. д. предоставляют рекомендации.
  • Управление затратами : как и в любых других областях инженерии, программный продукт или услуга, регулируемые хорошим качеством программного обеспечения, обходятся дешевле, их легче понять и они могут меняться более экономично в ответ на насущные потребности бизнеса. [26] Отраслевые данные демонстрируют, что низкое структурное качество приложений в основных бизнес-приложениях (таких как планирование ресурсов предприятия (ERP), управление взаимоотношениями с клиентами (CRM) или системы обработки крупных транзакций в финансовых услугах) приводит к затратам, перерасходу графика и создает ненужные затраты. форма переделки (см. Муда (японский термин) ). [27] [28] [29]Более того, низкое качество структуры тесно связано с серьезными сбоями в работе бизнеса из-за поврежденных данных, сбоев приложений, нарушений безопасности и проблем с производительностью. [30]
    • CISQ сообщает о стоимости некачественной оценки последствий:
      • 2,08 триллиона долларов в 2020 году [31] [32]
      • 2,84 триллиона долларов в 2018 году
    • В отчете IBM «Стоимость утечки данных за 2020 год» оценивается, что средние глобальные затраты на утечку данных: [33] [34]
      • 3,86 миллиона долларов

Определения [ править ]

ISO [ править ]

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

ASQ [ править ]

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

NIST [ править ]

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

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

PMI [ править ]

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

Прочие общие и исторические [ править ]

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

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

  • Трансцендентальная перспектива имеет дело с метафизическим аспектом качества. С этой точки зрения качества, это «то, к чему мы стремимся как к идеалу, но никогда не сможем реализовать его полностью». [46] Это трудно определить, но это похоже на то, что федеральный судья однажды прокомментировал по поводу непристойности: «Я знаю это, когда вижу». [47]
  • Точка зрения пользователя связана с соответствием продукта заданному контексту использования. В то время как трансцендентный взгляд бесплотен, взгляд пользователя более конкретен, основан на характеристиках продукта, которые соответствуют потребностям пользователя. [46]
  • С точки зрения производства качество рассматривается как соответствие требованиям. Этот аспект качества подчеркивается такими стандартами, как ISO 9001, который определяет качество как «степень, в которой набор неотъемлемых характеристик соответствует требованиям» (ISO / IEC 9001 [48] ).
  • Перспектива продукта подразумевает, что качество можно оценить, измерив неотъемлемые характеристики продукта.
  • Конечная точка зрения на качество основана на ценностях. [37] Эта точка зрения признает, что разные точки зрения на качество могут иметь разное значение или ценность для разных заинтересованных сторон.

Проблема, присущая попыткам определить качество продукта, почти любого продукта, была сформулирована мастером Walter A. Shewhart. Сложность определения качества состоит в том, чтобы преобразовать будущие потребности пользователя в измеримые характеристики, чтобы продукт можно было спроектировать и создать таким образом, чтобы он приносил удовлетворение по цене, которую заплатит пользователь. Это непросто, и как только человек чувствует себя достаточно успешным в своем начинании, он обнаруживает, что потребности потребителя изменились, появились конкуренты и т. Д. [49]

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

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

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

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

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

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

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

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

Измерение [ править ]

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

Введение [ править ]

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

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

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

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

  • Практики архитектуры приложений
  • Кодирование практики
  • Сложность приложения
  • Документация
  • Портативность
  • Технический и функциональный объем

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

Анализ на основе кода [ править ]

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

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

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

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

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

Надежность [ править ]

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

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

  • Практики архитектуры приложений
  • Кодирование практики
  • Сложность алгоритмов
  • Сложность практики программирования
  • Соблюдение передовых практик объектно-ориентированного и структурированного программирования (если применимо)
  • Коэффициент повторного использования компонента или рисунка
  • Грязное программирование
  • Обработка ошибок и исключений (для всех уровней - графический интерфейс, логика и данные)
  • Соответствие многослойному дизайну
  • Управление ограничениями ресурсов
  • Программное обеспечение избегает шаблонов, которые могут привести к неожиданному поведению
  • Программное обеспечение управляет целостностью и согласованностью данных
  • Уровень сложности транзакции

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

Эффективность [ править ]

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

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

  • Практики архитектуры приложений
  • Соответствующее взаимодействие с дорогими и / или удаленными ресурсами
  • Производительность доступа к данным и управление данными
  • Управление памятью, сетью и дисковым пространством
  • Соответствие методам кодирования [67] ( Лучшие практики кодирования )

Безопасность [ править ]

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

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

  • Внедрение, управление процессом разработки с учетом требований безопасности и усилением защиты , например, Security Development Lifecycle (Microsoft) или IBM Secure Engineering Framework. [72]
  • Практики архитектуры безопасных приложений [73] [74]
  • Соответствие многослойному дизайну
  • Лучшие практики безопасности (проверка ввода, внедрение SQL, межсайтовые сценарии, контроль доступа и т. Д.) [75] [76]
  • Безопасные и хорошие методы программирования [67]
  • Обработка ошибок и исключений

Ремонтопригодность [ править ]

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

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

  • Практики архитектуры приложений
  • Документация по архитектуре, программам и коду, встроенная в исходный код
  • Читаемость кода
  • Кодовые запахи
  • Уровень сложности транзакций
  • Сложность алгоритмов
  • Сложность практики программирования
  • Соблюдение передовых практик объектно-ориентированного и структурированного программирования (если применимо)
  • Коэффициент повторного использования компонента или рисунка
  • Контролируемый уровень динамического кодирования
  • Коэффициент сцепления
  • Грязное программирование
  • Документация
  • Аппаратное обеспечение, ОС, промежуточное ПО, программные компоненты и независимость от базы данных
  • Соответствие многослойному дизайну
  • Портативность
  • Практики программирования (уровень кода)
  • Уменьшение дублирования кода и функций
  • Чистота организации файлов исходного кода

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

Размер [ править ]

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

  • Существует несколько широко описанных методов технического определения размеров программного обеспечения . Наиболее распространенный технический метод определения размера - это количество строк кода (#LOC) для каждой технологии, количество файлов, функций, классов, таблиц и т. Д., На основе которых могут быть вычислены функциональные точки обратного эффекта;
  • Наиболее распространенным для измерения функционального размера является анализ функциональных точек . Анализ функциональных точек измеряет размер поставляемого программного обеспечения с точки зрения пользователя. Размер функциональных точек выполняется на основе требований пользователя и обеспечивает точное представление как размера для разработчика / оценщика, так и ценности (функциональность, которая должна быть предоставлена), а также отражает бизнес-функциональность, предоставляемую заказчику. Метод включает идентификацию и взвешивание распознаваемых пользователем входов, выходов и хранилищ данных. Затем значение размера доступно для использования вместе с многочисленными мерами для количественной оценки и оценки поставки и производительности программного обеспечения (стоимость разработки на функциональную точку; количество доставленных дефектов на функциональную точку; функциональных баллов на персонал в месяц).

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

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

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

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

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

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

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

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

  • Надежность
    • Избегайте программных шаблонов, которые могут привести к неожиданному поведению ( неинициализированная переменная , нулевые указатели и т. Д.)
    • Методы, процедуры и функции, выполняющие вставку, обновление, удаление, создание таблицы или выбор, должны включать управление ошибками.
    • Многопоточные функции должны быть потокобезопасными, например, классы сервлетов или struts не должны иметь статических полей экземпляра / не финального значения.
  • Эффективность
    • Обеспечьте централизацию клиентских запросов (входящих и данных) для уменьшения сетевого трафика.
    • Избегайте запросов SQL, которые не используют индекс для больших таблиц в цикле
  • Безопасность
    • Избегайте полей в классах сервлетов, которые не являются окончательными статическими
    • Избегайте доступа к данным, не включая управление ошибками
    • Проверьте коды возврата управления и внедрите механизмы обработки ошибок
    • Обеспечьте проверку входных данных, чтобы избежать ошибок межсайтового скриптинга или ошибок SQL-инъекций.
  • Ремонтопригодность
    • Следует избегать деревьев глубокого наследования и вложенности, чтобы улучшить понимание.
    • Модули должны быть слабо связаны (разветвители, посредники), чтобы избежать распространения модификаций.
    • Обеспечьте соблюдение однородных соглашений об именах

Действующие модели качества [ править ]

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

Интересные факты [ править ]

  • «Наука настолько же зрелая, насколько и ее инструменты измерения». [83]
  • « Я знаю это, когда вижу ».
  • «Вы не можете контролировать то, что не можете измерить». [7] ( Том ДеМарко )
  • «Вы не можете проверить качество продукта». ( У. Эдвардс Деминг ) [84]
  • «Горечь низкого качества остается еще долго после того, как сладость соблюдения графика была забыта». (Аноним) [84]
  • «Если вы не начнете со спецификации, каждый написанный вами фрагмент кода будет патчем». ( Лесли Лэмпорт )

См. Также [ править ]

  • ИСО / МЭК 9126
  • Улучшение программного процесса и определение возможностей - ISO / IEC 15504
  • Аномалия в программном обеспечении
  • Доступность
  • Доступность
  • Лучшие практики кодирования
  • Сплоченность и сцепление
  • Цикломатическая сложность
  • Соглашения о кодировании
  • Компьютерная ошибка
  • Надежность
  • GQM
  • Стиль программирования
  • Качество : контроль качества , полное управление качеством .
  • Управление требованиями
  • Scope_ (project_management)
  • Безопасность
  • Инженерия безопасности
  • Гарантия качества программного обеспечения
  • Архитектура программного обеспечения
  • Контроль качества программного обеспечения
  • Показатели программного обеспечения
  • Возможность повторного использования программного обеспечения
  • Стандарт программного обеспечения
  • Тестирование программного обеспечения
  • Тестируемость
  • Статический анализ программы

Дальнейшее чтение [ править ]

  • Международная Организация Стандартизации. Программная инженерия - Качество продукта - Часть 1: Модель качества . ISO, Женева, Швейцария, 2001. ISO / IEC 9126-1: 2001 (E).
  • Спинеллис, Диомидис (4 апреля 2006 г.). Качество кода: взгляд на открытый исходный код . Река Аппер Сэдл, Нью-Джерси, США: Addison-Wesley Professional. ISBN 978-0-321-16607-4.
  • Хо-Вон Чжон, Сунг-Гвён Ким и Чанг-Син Чунг. Измерение качества программного продукта: обзор ISO / IEC 9126 . IEEE Software , 21 (5): 10–13, сентябрь / октябрь 2004 г.
  • Стивен Х. Кан. Метрики и модели в разработке качества программного обеспечения . Аддисон-Уэсли, Бостон, Массачусетс, второе издание, 2002 г.
  • Омар Альшатри, Хельге Янике, «Оптимизация обеспечения качества программного обеспечения», compsacw, стр. 87–92, 2010 г. Семинары 34-й ежегодной конференции по компьютерному программному обеспечению и приложениям IEEE, 2010 г.
  • Роберт Л. Гласс. Создание качественного программного обеспечения . Прентис-Холл, Верхняя Седл-Ривер, Нью-Джерси, 1992.
  • Роланд Петраш, « Определение« качества программного обеспечения »: практический подход », ISSRE, 1999.
  • Каперс Джонс и Оливье Бонсиньур, «Экономика качества программного обеспечения», Addison-Wesley Professional, 1-е издание, 31 декабря 2011 г., ISBN 978-0-13-258220-9 
  • Измерение качества программного продукта: серия ISO 25000 и CMMI (сайт SEI)
  • MSQF - основа качества программного обеспечения, основанная на измерениях, Библиотека Корнельского университета
  • Стефан Вагнер. Контроль качества программного продукта . Спрингер, 2013.
  • Гириш Сурьянараяна, Программный процесс против качества проектирования: перетягивание каната? [85]
  • Ассоциация морских менеджеров в области информационных технологий и коммуникаций (AMMITEC). Руководство по качеству морского программного обеспечения . Сентябрь 2017 г.
  • Специалист по качеству программного обеспечения, [86] Американское общество качества (ASQ)
  • Журнал качества программного обеспечения [87] , Springer Nature
  • CAT Lab - Лаборатория инструментов анализа кода CNES (на Github)

Ссылки [ править ]

Заметки

  1. ^ Совет (IREB), Разработка международных требований. «Изучение истории: пример разработки требований к программному обеспечению - журнал« Разработка требований »» . Изучение истории: случай разработки требований к программному обеспечению - журнал «Разработка требований» . Проверено 25 февраля 2021 .
  2. ^ Прессман, Роджер С. (2005). Программная инженерия: подход практикующего (Шестое международное издание). McGraw-Hill Education. п. 388. ISBN. 0071267824.
  3. ^ «Об автоматической версии 1.0 спецификации показателей качества исходного кода» . www.omg.org . Проверено 25 февраля 2021 .
  4. ^ «Как выполнить сквозное тестирование» . smartbear.com . Проверено 25 февраля 2021 .
  5. ^ «Как создать отказоустойчивые, безопасные, эффективные и легко изменяемые ИТ-системы в соответствии с рекомендациями CISQ» (PDF) . Архивировано (PDF) из оригинала 28 декабря 2013 года . Проверено 18 октября 2013 .
  6. ^ 14: 00-17: 00. «ИСО / МЭК 25010: 2011» . ISO . Проверено 23 февраля 2021 .CS1 maint: numeric names: authors list (link)
  7. ^ a b Броня, Филипп Г. (01.06.2012). «Мера контроля» . Коммуникации ACM . 55 (6): 26–28. DOI : 10.1145 / 2184319.2184329 . ISSN 0001-0782 . 
  8. ^ Voas, J. (ноябрь 2011). «Секрет программного обеспечения:« -способности »[качество программного обеспечения]» . Программное обеспечение IEEE . 21 (6): 14–15. DOI : 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. ^ J. Бонет, J. Döllner архивации 2014-04-27 в Wayback Machine , «Контроль качества кода и развития деятельностипомощью программного обеспечения Maps». Материалы семинара IEEE ACM ICSE по управлению техническим долгом, стр. 9-16, 2011 г.
  12. ^ «IIA - Глобальное руководство по аудиту технологий: Управление изменениями в ИТ: критически важно для успеха организации» . na.theiia.org . Проверено 26 февраля 2021 .
  13. ^ Boursier, Жером (2018-01-11). «Последствия Meltdown и Spectre: проблемы с установкой исправлений сохраняются» . Malwarebytes Labs . Проверено 26 февраля 2021 .
  14. ^ местью. «Рекомендации по обновлению программного обеспечения - Configuration Manager» . docs.microsoft.com . Проверено 26 февраля 2021 .
  15. ^ Райт, Хайрам К. (2009-08-25). «Процессы выпуска релизов, модели и метрики» . Материалы докторского симпозиума для ESEC / FSE на докторском симпозиуме . Докторантский симпозиум ESEC / FSE '09. Амстердам, Нидерланды: Ассоциация вычислительной техники: 27–28. DOI : 10.1145 / 1595782.1595793 . ISBN 978-1-60558-731-8.
  16. ^ ван дер Хук, Андре; Холл, Ричард С .; Хаймбигнер, Деннис; Вольф, Александр Л. (ноябрь 1997 г.). «Управление выпуском программного обеспечения» . Примечания по разработке программного обеспечения ACM SIGSOFT . 22 (6): 159–175. DOI : 10.1145 / 267896.267909 . ISSN 0163-5948 . 
  17. ↑ Мур, Майк Саттон и Тим (30 июля 2008 г.). «7 способов улучшить управление выпусками программного обеспечения» . ИТ-директор . Проверено 26 февраля 2021 .
  18. ^ Кларк, Митчелл (2021-02-24). «iRobot говорит, что пройдет несколько недель, прежде чем он сможет навести порядок в своем последнем обновлении программного обеспечения Roomba» . Грань . Проверено 25 февраля 2021 .
  19. ^ «25 самых популярных ошибок программного обеспечения | Институт SANS» . www.sans.org . Проверено 25 февраля 2021 .
  20. ^ « „ Включите его выключить и снова каждый 149 часов“Является Относительно Remedy для Airbus самолета Software Bug $ 300 млн» . Gizmodo . Проверено 25 февраля 2021 .
  21. ^ Программное обеспечение, Gimpel. «MISRA C, Toyota и смерть задачи X» . Проверено 25 февраля 2021 .
  22. ^ «Обновленная информация о Toyota и« Barr Code »при непреднамеренном ускорении» . embeddedgurus.com . Проверено 25 февраля 2021 .
  23. ↑ Medical Devices: Therac-25 * Архивировано 16 февраля2008 г. в Wayback Machine , Нэнси Левесон, Вашингтонский университет.
  24. ↑ Встроенное программное обеспечение, заархивированное 05.07.2010 в Wayback Machine , Эдвард А. Ли, «Появиться в Advances in Computers» (М. Зельковиц, редактор), 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» . Agile Alliance | . Проверено 25 февраля 2021 .
  28. ↑ 26 января, Скотт Мэттесон в программном обеспечении; 2018; Пст, 7:54. «Отчет: сбой программного обеспечения привел к финансовым убыткам в 1,7 триллиона долларов в 2017 году» . TechRepublic . Проверено 25 февраля 2021 .CS1 maint: numeric names: authors list (link)
  29. ^ Кохан, Райан (2017-11-16). «Финансовые затраты на программные ошибки» . Средний . Проверено 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, получено 2021-02-25
  31. ^ «Низкое качество программного обеспечения обошлось предприятиям в 2 триллиона долларов в прошлом году и поставило под угрозу безопасность» . CIO Dive . Проверено 26 февраля 2021 .
  32. ^ «Исследование CISQ, спонсируемое Synopsys, оценивает стоимость плохого качества программного обеспечения в 2,08 триллиона долларов США в 2020 году» . finance.yahoo.com . Проверено 26 февраля 2021 .
  33. ^ «Сколько стоит утечка данных в 2020 году?» . Цифровой хранитель . 2020-08-06 . Проверено 8 марта 2021 .
  34. ^ «Стоимость отчета об утечке данных 2020 | IBM» . www.ibm.com . 2020 . Проверено 8 марта 2021 .
  35. ^ «ISO - Семейство ISO 9000 - Менеджмент качества» . ISO . Проверено 24 февраля 2021 .
  36. ^ 14: 00-17: 00. «ISO / IEC / IEEE 24765: 2017» . ISO . Проверено 24 февраля 2021 .CS1 maint: numeric names: authors list (link)
  37. ^ a b «Освоение автомобильного программного обеспечения | McKinsey» . www.mckinsey.com . Проверено 25 февраля 2021 .
  38. ^ 14: 00-17: 00. «ИСО / МЭК 25010: 2011» . ISO . Проверено 24 февраля 2021 .CS1 maint: numeric names: authors list (link)
  39. Перейти ↑ Wallace, DR (2002). «Практическое моделирование надежности программного обеспечения» . Материалы 26-го ежегодного семинара NASA по разработке программного обеспечения Годдарда . Гринбелт, Мэриленд, США: IEEE Comput. Soc: 147–155. DOI : 10,1109 / SEW.2001.992668 . ISBN 978-0-7695-1456-7.
  40. ^ «Что такое качество программного обеспечения? | ASQ» . asq.org . Проверено 24 февраля 2021 .
  41. ^ «SAMATE - главная страница проекта Software Assurance Metrics and Tool Evaluation» . samate.nist.gov . Проверено 26 февраля 2021 .
  42. ^ Программное расширение к руководству PMBOK . Институт управления проектами (5-е изд.). Площадь Ньютаун, Пенсильвания. 2013. ISBN. 978-1-62825-041-1. OCLC  959513383 .CS1 maint: others (link)
  43. ^ Шухарта, WALTER A. (2015). Economioc контроль качества выпускаемой продукции . [Место публикации не указано]: MARTINO FINE Books. ISBN 1-61427-811-3. OCLC  1108913766 .
  44. ^ Kitchenham, B .; Pfleeger, SL (январь 1996 г.). «Качество программного обеспечения: неуловимая цель [раздел специальных выпусков]» . Программное обеспечение IEEE . 13 (1): 12–21. DOI : 10.1109 / 52.476281 . ISSN 1937-4194 . 
  45. ^ Гарвин, Дэвид А. (1988). Управление качеством: стратегическое и конкурентное преимущество . Нью-Йорк: Свободная пресса. ISBN 0-02-911380-6. OCLC  16005388 .
  46. ^ a b Б. Китченхэм и С. Пфлегер, «Качество программного обеспечения: неуловимая цель», IEEE Software, vol. 13, вып. 1. С. 12–21, 1996.
  47. ^ Кан, Стивен Х. (2003). Метрики и модели в инженерии качества программного обеспечения (2-е изд.). Бостон: Эддисон-Уэсли. ISBN 0-201-72915-6. OCLC  50149641 .
  48. ^ Международная организация по стандартизации, «ISO / IEC 9001: Системы менеджмента качества - Требования», 1999.
  49. ^ WE Деминг, «Выйти из кризиса: качество, производительность и конкурентоспособность». Издательство Кембриджского университета, 1988.
  50. ↑ А.В. Фейгенбаум, «Полный контроль качества», McGraw-Hill, 1983.
  51. ↑ JM Juran, «Справочник Джурана по контролю качества», McGraw-Hill, 1988.
  52. ^ Вайнберг, Г. (1991). "Управление качеством программного обеспечения Том 1: Системное мышление" . не определено . Проверено 24 февраля 2021 .
  53. ^ "Управление качеством программного обеспечения (серия программного обеспечения качества) Том 2: Измерение первого порядка" . GeraldMWeinberg.com . 2019-12-05 . Проверено 24 февраля 2021 .
  54. Перейти ↑ Crosby, P., Quality is Free , McGraw-Hill, 1979
  55. ^ «SUP.9 - Управление разрешением проблем - Kugler Maag Cie» . www.kuglermaag.com . Проверено 25 февраля 2021 .
  56. ^ а б Хойпт (29.11.2019). «Организации часто используют термины« обеспечение качества »(QA) по сравнению с« контролем качества »(QC)…» . Средний . Проверено 25 февраля 2021 .
  57. ^ Уоллес, Д .; Watson, AH; Маккаб, TJ (1996-08-01). «Структурированное тестирование: методология тестирования с использованием метрики цикломатической сложности» . Cite journal requires |journal= (help)
  58. ^ Беллэрс, Ричард. «Что такое качество кода? И как улучшить качество кода» . Программное обеспечение Perforce . Проверено 28 февраля 2021 .
  59. ^ «OMG Whitepaper | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Проверено 26 февраля 2021 .
  60. ^ «Как создать отказоустойчивые, безопасные, эффективные и гибкие ИТ-системы в соответствии с рекомендациями CISQ - Белая книга | Группа управления объектами» (PDF) . Архивировано (PDF) из оригинала 28 декабря 2013 года . Проверено 18 октября 2013 .
  61. ^ «Измерение размера программного обеспечения: основа для подсчета исходных утверждений» . resources.sei.cmu.edu . Проверено 24 февраля 2021 .
  62. ^ Холстед, Морис Х. (1977). Elements of Software Science (серия «Операционные и программные системы») . США: ISBN Elsevier Science Inc. 978-0-444-00205-1.
  63. ^ Чидамбер, SR; Кемерер, CF (июнь 1994 г.). «Набор метрик для объектно-ориентированного дизайна» . IEEE Transactions по разработке программного обеспечения . 20 (6): 476–493. DOI : 10.1109 / 32.295895 . ЛВП : 1721,1 / 48424 . ISSN 1939-3520 . 
  64. ^ Nygard, Майкл (2007). Отпустите его! . Safari компании O'Reilly Media (1-е изд.). ISBN 0978739213. OCLC  1102387436 .
  65. ^ «CWE - Common Weakness Enumeration» . cwe.mitre.org . Архивировано 10 мая 2016 года . Проверено 20 мая 2016 .
  66. ^ Бем, Б., Браун, JR, Каспар, Х., Lipow, М., Маклеода, ГДж, и Мерритт, МДж (1978). Характеристики качества программного обеспечения. Северная Голландия.
  67. ^ a b c «Стандарты кодирования SEI CERT - Безопасное кодирование CERT - Confluence» . wiki.sei.cmu.edu . Проверено 24 февраля 2021 .
  68. ^ «Качество кода и безопасность кода: как они связаны? | Synopsys» . Блог о целостности программного обеспечения . 2019-05-24 . Проверено 9 марта 2021 .
  69. ^ «Стоимость отчета об утечке данных 2020 | IBM» . www.ibm.com . 2020 . Проверено 9 марта 2021 .
  70. ^ «Ключевые выводы из отчета о затратах на утечку данных за 2020 год» . Блюфин . 2020-08-27 . Проверено 9 марта 2021 .
  71. ^ «CWE - Common Weakness Enumeration» . Cwe.mitre.org. Архивировано 14 октября 2013 года . Проверено 18 октября 2013 .
  72. ^ Безопасность в разработке: IBM Secure Engineering Framework | IBM Redbooks . 2016-09-30.
  73. ^ Архитектура безопасности предприятия с использованием решений безопасности IBM Tivoli | IBM Redbooks . 2016-09-30.
  74. ^ "Определения проектирования безопасной архитектуры | CISA" . us-cert.cisa.gov . Проверено 9 марта 2021 .
  75. ^ «OWASP Foundation | Фонд с открытым исходным кодом для безопасности приложений» . owasp.org . Проверено 24 февраля 2021 .
  76. ^ "Топ 25 CWE" . Sans.org . Проверено 18 октября 2013 .
  77. ^ IfSQ Level-2 Стандарт базового уровня для исходного кода компьютерных программ. Архивировано 27 октября 2011 г.в Wayback Machine , второе издание, август 2008 г., Грэм Болтон, Стюарт Джонстон, IfSQ, Институт качества программного обеспечения.
  78. ↑ Фаулер, Мартин (14 октября 2009 г.). "TechnicalDebtQuadrant" . Архивировано 2 февраля 2013 года . Проверено 4 февраля 2013 года .
  79. ^ Prause, христианин; Дурдик, Зоя (3 июня 2012 г.). «Архитектурное проектирование и документация: отходы в гибкой разработке?». 2012 Международная конференция по программному обеспечению и системным процессам (ICSSP) . Компьютерное общество IEEE. С. 130–134. DOI : 10.1109 / ICSSP.2012.6225956 . ISBN 978-1-4673-2352-9. S2CID  15216552 .
  80. ^ «Стандарты размеров программного обеспечения | CISQ - Консорциум по качеству информации и программного обеспечения» . www.it-cisq.org . Источник 2021-01-28 .
  81. ^ «Почему программное обеспечение терпит неудачу» . IEEE Spectrum: Новости технологий, инженерии и науки . Проверено 20 марта 2021 .
  82. ^ Вагнер, Стефан; Геб, Андреас; Хайнеманн, Ларс; Клас, Майкл; Лампасона, Констанца; Лохманн, Клаус; Майр, Алоис; Плёш, Рейнхольд; Зайдл, Андреас (2015). «Действующие модели качества продукции и оценка: подход Quamoco» (PDF) . Информационные и программные технологии . 62 : 101–123. arXiv : 1611.09230 . DOI : 10.1016 / j.infsof.2015.02.009 . S2CID 10992384 .  
  83. ^ Эберт, Кристоф (2010). Измерение программного обеспечения: установить - извлечь - оценить - выполнить . ISBN 9783642090806. OCLC  941931829 .
  84. ^ a b «Управление неуправляемым: больше практических правил» . www.managingtheunmanageable.net . Проверено 26 февраля 2021 .
  85. ^ Сурьянараяна, Гириш (2015). «Программный процесс против качества дизайна: перетягивание каната?» . Программное обеспечение IEEE . 32 (4): 7–11. DOI : 10.1109 / MS.2015.87 . S2CID 9226051 . 
  86. ^ "Профессиональное качество программного обеспечения | ASQ" . asq.org . Источник 2021-01-28 .
  87. ^ "Журнал качества программного обеспечения" . Springer . Источник 2021-01-28 .

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

  • Альбрехт, AJ (1979), Измерение производительности разработки приложений. В материалах совместного симпозиума по разработке приложений IBM SHARE / GUIDE. , IBM
  • Бен-Менахем, М .; Марлисс, GS (1997), Качество программного обеспечения, Производство практичного и согласованного программного обеспечения , Thomson Computer Press
  • Boehm, B .; Браун, младший; Kaspar, H .; Lipow, M .; MacLeod, GJ; Мерритт, MJ (1978), Характеристики качества программного обеспечения , Северная Голландия.
  • Chidamber, S .; Кемерер, К. (1994), Набор метрик для объектно-ориентированного дизайна. IEEE Transactions по разработке программного обеспечения, 20 (6) , стр. 476–493
  • Эберт, Кристоф; Думке, Райнер, Измерение программного обеспечения: установить - извлечь - оценить - выполнить , Kindle Edition, стр. 91
  • Garmus, D .; Херрон, Д. (2001), Анализ функциональных точек , Аддисон Уэсли
  • Холстед, штат Мэн (1977), Элементы науки о программном обеспечении , Elsevier North-Holland
  • Hamill, M .; Госева-Попстоянова, К. (2009), Общие сбои в программных сбоях и данные сбоев. IEEE Transactions of Software Engineering, 35 (4) , стр. 484–496.
  • Джексон, DJ (2009), Прямой путь к надежному программному обеспечению. Сообщения ACM, 52 (4).
  • Мартин, Р. (2001), Управление уязвимостями в сетевых системах , IEEE Computer.
  • МакКейб, Т. (декабрь 1976 г.), Мера сложности. IEEE Transactions по разработке программного обеспечения
  • МакКоннелл, Стив (1993), Code Complete (Первое издание), Microsoft Press
  • Найгард, MT (2007), Release It! Разработка и развертывание программного обеспечения , готового к производству, программисты- прагматики.
  • Park, RE (1992), Измерение размера программного обеспечения: основа для подсчета исходных утверждений. (CMU / SEI-92-TR-020). , Институт программной инженерии, Университет Карнеги-Меллона
  • Прессман, Роджер С. (2005). Программная инженерия: подход практикующего (Шестое международное издание). McGraw-Hill Education. ISBN 0071267824.
  • Спинеллис, Д. (2006), Качество кода , Эддисон Уэсли

Внешние ссылки [ править ]

  • Когда код важен: совершенствование автомобильного программного обеспечения (McKinsey, 2021 г.)
  • Качество встроенного системного программного обеспечения: почему оно так часто ужасно? Что мы можем с этим поделать? ( Филип Купман )
  • Стандарты качества кода от CISQ ™
  • Блог CISQ: https://blog.it-cisq.org
  • Руководство по обеспечению качества программного обеспечения (ESA)
  • Руководство по применению стандартов программной инженерии ESA к небольшим программным проектам (ESA)
  • Обзор услуг ESA Software Product Assurance Services (NASA / ESA)
  • Наш подход к качеству в Центре разработки программного обеспечения Volkswagen в Лиссабоне
  • Руководства по стилю Google
  • Обеспечение качества продукции в Google (2011 г.)
  • НАСА Software Assurance
  • Группа качества программного обеспечения NIST
  • Автоматизированные функциональные точки OMG / CISQ ( ISO / IEC 19515 )
  • Стандарт автоматического технического долга OMG
  • Автоматизированная проверка качества ( сформулирована в IREB Гарри Снидом)
  • Структурированное тестирование: методология тестирования с использованием метрики цикломатической сложности (1996)
  • Анализ качества приложений с помощью инструментов анализа кода (Microsoft, документация, Visual Studio, 2016)