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

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

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

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

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

Исторически сложилось так, что структура, классификация и терминология атрибутов и показателей, применимых к управление качеством программного обеспечения были получены или извлечены из ISO 9126-3 и последующий ISO 25000: 2005^[3] качественная модель, также известная как SQuaRE.^[4] На основе этих моделей Консорциум качества ИТ-программного обеспечения (CISQ) определила пять основных желательных структурных характеристик, необходимых для того, чтобы часть программного обеспечения обеспечивала ценность бизнеса: Надежность, эффективность, безопасность, ремонтопригодность и (адекватный) размер.

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

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

Мотивация

«Наука так же зрела, как и ее инструменты измерения» (Луи Пастер в Эберт и Думке, п. 91). Измерение качества программного обеспечения мотивируется как минимум двумя причинами:

• Управление рисками: Программный сбой вызвал больше, чем неудобство. Программные ошибки привели к человеческим жертвам. Причины варьируются от плохо разработанных пользовательских интерфейсов до прямых ошибки программирования. Пример ошибки программирования, которая привела к многочисленным смертельным случаям, обсуждается в статье доктора Левесона.^[6] Это привело к появлению требований к разработке некоторых типов программного обеспечения, в частности, исторически для встроенное программное обеспечение в медицинских и других устройствах, которые регулируют критически важные инфраструктуры: «[Инженеры, которые пишут встроенное программное обеспечение] видят, что программы Java останавливаются на одну треть секунды, чтобы выполнить сборку мусора и обновить пользовательский интерфейс, и они представляют себе самолеты, падающие с неба».^[7] В США в пределах Федеральная авиационная администрация (FAA) Служба сертификации самолетов FAA предоставляет программное обеспечение, политику, руководство и обучение, уделяя особое внимание программному обеспечению и сложному электронному оборудованию, которое влияет на бортовой продукт («продукт» - это самолет, двигатель или пропеллер) .^[8]
• Управление затратами. Как и в любой другой области инженерии, приложение с хорошим качеством структурного программного обеспечения требует меньше затрат на обслуживание и его легче понять и изменить в ответ на насущные потребности бизнеса. Отраслевые данные демонстрируют низкое структурное качество приложений в ядре. бизнес-приложения (такие как Планирование ресурсов предприятия (ERP), управление взаимоотношениями с клиентами (CRM) или большой обработка транзакции системы финансовых услуг) приводит к перерасходу средств и сроков, а также к отходам в виде переделок (до 45% времени разработки в некоторых организациях^[9]). Более того, низкое качество структуры тесно связано с серьезными сбоями в работе из-за поврежденных данных, сбоев приложений, нарушений безопасности и проблем с производительностью.

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

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

Определения

Есть много разных определений качества. Для некоторых это «способность программного продукта соответствовать требованиям». (ИСО / МЭК 9001,^[10] прокомментировал^[11]), в то время как для других это может быть синонимом «потребительской ценности» (Highsmith, 2002) или даже уровня дефекта.

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

Пять взглядов Китченхема, Пфлегера и Гарвина на качество

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

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

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

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

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

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

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

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

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

Модель качества CISQ

Несмотря на то, что «качество является перцептивным, условным и в некоторой степени субъективным атрибутом, и разные люди могут его понимать по-разному» (как отмечалось в статье о качество в бизнесе ), характеристики качества структуры программного обеспечения были четко определены Консорциумом качества программного обеспечения для ИТ (CISQ). Под руководством Билл Кертис, соавтор Модель зрелости возможностей framework и первый директор CISQ; и Каперс Джонс, Заслуженный советник CISQ, CISQ определила пять основных желаемых характеристик программного обеспечения, необходимого для обеспечения ценность бизнеса.^[19] в Дом Качества модели, вот "Что" необходимо достичь:

Надежность

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

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

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

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

Мера вероятности потенциальных нарушений безопасности из-за плохой практики кодирования и архитектуры. Это позволяет количественно оценить риск обнаружения критических уязвимостей, наносящих ущерб бизнесу.^[20]

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

Ремонтопригодность включает понятие адаптируемости, переносимость и переносимость (от одной команды разработчиков к другой). Измерение и мониторинг ремонтопригодности является обязательным условием для критически важных приложений, в которых изменения обусловлены жесткими сроками вывода на рынок и где важно, чтобы ИТ-отделы оставались отзывчивыми на изменения, обусловленные бизнесом. Также важно держать под контролем расходы на техническое обслуживание.

Размер

Хотя размер исходного кода не является атрибутом качества как таковым, он является характеристикой программного обеспечения, которая, очевидно, влияет на ремонтопригодность. В сочетании с указанными выше характеристиками качества размер программного обеспечения может использоваться для оценки объема работы, выполняемой и выполняемой командами, а также их производительности посредством корреляции с данными табеля рабочего времени и другими SDLC -связанные метрики.

Функциональное качество программного обеспечения определяется как соответствие явно заявленным функциональным требованиям, определенным, например, с помощью Голос Заказчика анализ (часть Дизайн для шести сигм инструментарий и / или задокументирован сценарии использования ) и уровень удовлетворенности конечных пользователей. Последний называется юзабилити и озабочен тем, насколько интуитивно понятным и отзывчивым пользовательский интерфейс насколько легко можно выполнять простые и сложные операции и насколько полезны Сообщения об ошибках находятся. Как правило, методы и инструменты тестирования программного обеспечения гарантируют, что часть программного обеспечения ведет себя в соответствии с исходным дизайном, запланированным пользовательским интерфейсом и желаемым проверяемость, т.е. часть программного обеспечения, поддерживающая критерии приемки.

Двойное структурное / функциональное измерение качества программного обеспечения согласуется с моделью, предложенной в Стив МакКоннелл с Код завершен который делит характеристики программного обеспечения на две части: внутренние и внешние характеристики качества. Внешние качественные характеристики - это те части продукта, с которыми сталкиваются пользователи, а внутренние качественные характеристики - это те части продукта, которые не видны.^[21]

Альтернативные подходы

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

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

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

Измерение

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

Введение

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

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

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

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

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

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

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

Многие из существующих программных мер учитывают структурные элементы приложения, которые возникают в результате анализа исходного кода для таких отдельных инструкций (Park, 1992),^[27] жетоны (Halstead, 1977),^[28] управляющие структуры (McCabe, 1976) и объекты (Chidamber & Kemerer, 1994).^[29]

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

Такой взгляд на качество программного обеспечения в линейном континууме должен быть дополнен определением дискретных Критические ошибки программирования. Эти уязвимости не могут не пройти тест, но они являются результатом неправильной практики, которая при определенных обстоятельствах может привести к катастрофическим отключениям, снижению производительности, нарушениям безопасности, повреждению данных и множеству других проблем (Nygard, 2007).^[30] которые делают данную систему де-факто непригодной для использования независимо от ее рейтинга, основанного на совокупных измерениях. Хорошо известным примером уязвимости является Перечень общих слабых мест,^[31] репозиторий уязвимостей в исходном коде, которые делают приложения уязвимыми для защиты.

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

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

Надежность

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

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

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

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

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

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

• Практики архитектуры приложений
• Соответствующее взаимодействие с дорогими и / или удаленными ресурсами
• Производительность доступа к данным и управление данными
• Управление памятью, сетью и дисковым пространством
• Кодирование практики
• Соблюдение передовых практик объектно-ориентированного и структурированного программирования (при необходимости)
• Соответствие передовым практикам программирования SQL

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

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

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

• Практики архитектуры приложений
• Соответствие многослойному дизайну
• Лучшие практики безопасности (проверка ввода, внедрение SQL, межсайтовые сценарии и т. Д.^[34] )
• Практики программирования (уровень кода)
• Обработка ошибок и исключений
• Лучшие практики безопасности (доступ к системным функциям, контроль доступа к программам)

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

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

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

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

Размер

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

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

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

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

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

CISQ объявила о доступности своего первого метрического стандарта, Automated Function Points, для членов CISQ в CISQ Technical. Эти рекомендации были разработаны в формате запроса на комментарии OMG и переданы в процесс стандартизации OMG.^{[нужна цитата ]}

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

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

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

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

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

Действующие модели качества

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

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

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

• Международная организация по стандартизации. Программная инженерия - Качество продукции - Часть 1. Модель качества. ISO, Женева, Швейцария, 2001. ISO / IEC 9126-1: 2001 (E).
• Спинеллис, Диомидис (4 апреля 2006 г.). Качество кода: взгляд на открытый исходный код. Река Аппер-Сэдл, Нью-Джерси, США: Addison-Wesley Professional. ISBN  978-0-321-16607-4.
• Хо-Вон Чжон, Сын-Гвон Ким и Чанг-Син Чунг. Измерение качества программного продукта: обзор ISO / IEC 9126. Программное обеспечение IEEE, 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.
• Гириш Сурьянараяна, Программный процесс против качества проектирования: перетягивание каната? ^[39]
• Ассоциация морских менеджеров в области информационных технологий и коммуникаций (AMMITEC). Руководство по качеству морского программного обеспечения. Сентябрь 2017 г.

использованная литература

Примечания

Список используемой литературы

внешняя ссылка

• Linux: меньше ошибок, чем конкурентов Wired Magazine, 2004 г.
• Автоматизированные функциональные точки Бета 1 от OMG
• Стандарты качества кода от CISQ ™