✖


Jump to content

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

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

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

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

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

Использование автоматических тестов и фитнес-функций может помочь сохранить некоторые атрибуты качества. [6]

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

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

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

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

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

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

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

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

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

ИСО [ править ]

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

ASQ [ править ]

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

НИСТ [ править ]

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

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

PMI [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

  • Альбрехт, AJ (1979), Измерение производительности разработки приложений. В материалах совместного симпозиума по разработке приложений SHARE/GUIDE IBM. , IBM
  • Бен-Менахем, М.; Марлисс, Г.С. (1997), Качество программного обеспечения, создание практичного и согласованного программного обеспечения , Thomson Computer Press
  • Бём, Б.; Браун, младший; Каспар, Х.; Липов, М.; Маклауд, Дж.Дж.; Мерритт, MJ (1978), Характеристики качества программного обеспечения , Северная Голландия.
  • Чидамбер, С.; Кемерер, К. (1994), Набор метрик для объектно-ориентированного проектирования. Транзакции IEEE по разработке программного обеспечения, 20 (6) , стр. 476–493.
  • Эберт, Кристоф; Думке, Райнер, Измерение программного обеспечения: создание – извлечение – оценка – выполнение , Kindle Edition, стр. 91
  • Гармус, Д.; Херрон, Д. (2001), Анализ функциональных точек , Аддисон Уэсли
  • Холстед, Мэн (1977), Элементы науки о программном обеспечении , Elsevier, Северная Голландия.
  • Хэмилл, М.; Госева-Попстоянова, К. (2009), Распространенные ошибки в данных о сбоях и отказах программного обеспечения. IEEE Transactions of Software Engineering, 35 (4) , стр. 484–496.
  • Джексон, DJ (2009), Прямой путь к надежному программному обеспечению. Сообщения АКМ, 52 (4).
  • Мартин, Р. (2001), Управление уязвимостями в сетевых системах , IEEE Computer.
  • Маккейб, Т. (декабрь 1976 г.), Мера сложности. Транзакции IEEE по разработке программного обеспечения
  • МакКоннелл, Стив (1993), Code Complete (первое издание), Microsoft Press
  • Найгард, Монтана (2007), Выпустите это! Разработка и внедрение готового программного обеспечения , Программисты-прагматики.
  • Парк, Р.Э. (1992), Измерение размера программного обеспечения: основа для подсчета исходных заявлений. (CMU/SEI-92-TR-020). , Институт программной инженерии, Университет Карнеги-Меллона
  • Прессман, Роджер С. (2005). Программная инженерия: подход практикующего специалиста (Шестое международное изд.). Макгроу-Хилл Образование. ISBN  0071267824 .
  • Спинеллис, Д. (2006), Качество кода , Эддисон Уэсли

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

На Wikimedia Commons есть средства массовой информации, связанные с качеством программного обеспечения .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_quality&oldid=1226822445"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: b20d1716f3a89d25f49e9f5f8d0f7132__1717281060
URL1:https://arc.ask3.ru/arc/aa/b2/32/b20d1716f3a89d25f49e9f5f8d0f7132.html
Заголовок, (Title) документа по адресу, URL1:
Software quality - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)