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

Управление качеством программного обеспечения – Введение

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

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

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

• Software Quality Assurance – Software Quality Assurance (SQA) – это комплекс мероприятий, направленных на обеспечение качества процессов разработки программного обеспечения, которые в конечном итоге приводят к качественным программным продуктам. Деятельность устанавливает и оценивает процессы, которые производят продукты. Это включает процессно-ориентированные действия.

• Контроль качества программного обеспечения – Контроль качества программного обеспечения (SQC) – это комплекс мероприятий по обеспечению качества программных продуктов. Эти действия направлены на выявление дефектов в фактической продукции. Это включает в себя действия, ориентированные на продукт.

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

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

Software Quality Assurance – Software Quality Assurance (SQA) – это комплекс мероприятий, направленных на обеспечение качества процессов разработки программного обеспечения, которые в конечном итоге приводят к качественным программным продуктам. Деятельность устанавливает и оценивает процессы, которые производят продукты. Это включает процессно-ориентированные действия.

Контроль качества программного обеспечения – Контроль качества программного обеспечения (SQC) – это комплекс мероприятий по обеспечению качества программных продуктов. Эти действия направлены на выявление дефектов в фактической продукции. Это включает в себя действия, ориентированные на продукт.

Проблема качества программного обеспечения

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

Сложность продукта

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

Видимость продукта

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

Разработка продукта и производственный процесс

В промышленном продукте дефекты могут быть обнаружены на следующих этапах –

• Разработка продукта – На этом этапе проектировщики и сотрудники отдела обеспечения качества (QA) проверяют и тестируют прототип продукта для выявления его дефектов.

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

• Производство – на этом этапе применяются процедуры QA для выявления сбоев самих продуктов. Дефекты продукта, обнаруженные в первом периоде производства, обычно могут быть исправлены путем изменения конструкции или материалов продукта или производственных инструментов таким образом, чтобы устранить такие дефекты в продуктах, выпускаемых в будущем.

Разработка продукта – На этом этапе проектировщики и сотрудники отдела обеспечения качества (QA) проверяют и тестируют прототип продукта для выявления его дефектов.

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

Производство – на этом этапе применяются процедуры QA для выявления сбоев самих продуктов. Дефекты продукта, обнаруженные в первом периоде производства, обычно могут быть исправлены путем изменения конструкции или материалов продукта или производственных инструментов таким образом, чтобы устранить такие дефекты в продуктах, выпускаемых в будущем.

Однако в случае программного обеспечения единственная фаза, в которой могут быть обнаружены дефекты, – это фаза разработки. В случае программного обеспечения этапы планирования производства и изготовления продукта не требуются, поскольку изготовление копий программного обеспечения и печать руководств по программному обеспечению осуществляются автоматически.

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

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

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

Факторы качества программного обеспечения

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

Несколько моделей факторов качества программного обеспечения и их категоризация были предложены за эти годы. Классическая модель факторов качества программного обеспечения, предложенная McCall, состоит из 11 факторов (McCall et al., 1977). Аналогично, модели, состоящие из 12-15 факторов, были предложены Дойчем и Уиллисом (1988) и Эвансом и Марсиниаком (1987).

Все эти модели существенно не отличаются от модели Маккола. Факторная модель Макколла предоставляет практичный, современный метод классификации требований к программному обеспечению (Pressman, 2000).

Модель Фактора Маккола

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

• Факторы работы продукта – правильность, надежность, эффективность, целостность, удобство использования.

• Факторы пересмотра продукта – ремонтопригодность, гибкость, тестируемость.

• Факторы перехода продукта – Переносимость, Возможность повторного использования, Совместимость.

Факторы работы продукта – правильность, надежность, эффективность, целостность, удобство использования.

Факторы пересмотра продукта – ремонтопригодность, гибкость, тестируемость.

Факторы перехода продукта – Переносимость, Возможность повторного использования, Совместимость.

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

Согласно модели Макколла, категория работы продукта включает пять факторов качества программного обеспечения, которые отвечают требованиям, которые непосредственно влияют на ежедневную работу программного обеспечения. Они заключаются в следующем –

правильность

Эти требования касаются правильности вывода программного обеспечения системы. Они включают в себя –

• Выходная миссия

• Требуемая точность вывода, на которую могут отрицательно повлиять неточные данные или неточные расчеты.

• Полнота выводимой информации, на которую могут повлиять неполные данные.

• Актуальность информации, определяемой как время между событием и ответом системы программного обеспечения.

• Доступность информации.

• Стандарты кодирования и документирования программного обеспечения системы.

Выходная миссия

Требуемая точность вывода, на которую могут отрицательно повлиять неточные данные или неточные расчеты.

Полнота выводимой информации, на которую могут повлиять неполные данные.

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

Доступность информации.

Стандарты кодирования и документирования программного обеспечения системы.

надежность

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

КПД

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

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

целостность

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

Юзабилити

Требования юзабилити связаны с кадровыми ресурсами, необходимыми для обучения нового сотрудника и эксплуатации системы программного обеспечения.

Факторы качества редакции продукта

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

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

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

гибкость

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

способность быть свидетелем в суде

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

Фактор качества программного обеспечения для перехода продукта

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

портативность

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

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

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

Interoperability

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

SQA Компоненты

Software Quality Assurance (SQA) – это комплекс мероприятий по обеспечению качества в процессах разработки программного обеспечения. Это гарантирует, что разработанное программное обеспечение соответствует и соответствует определенным или стандартизированным спецификациям качества. SQA – это непрерывный процесс в рамках жизненного цикла разработки программного обеспечения (SDLC), который регулярно проверяет разработанное программное обеспечение, чтобы убедиться, что оно соответствует требуемым показателям качества.

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

Включает в себя следующие виды деятельности –

• Определение и реализация процесса
• Аудиторская проверка
• Повышение квалификации

Процессы могут быть –

• Методология разработки программного обеспечения
• Управление проектом
• Управление конфигурацией
• Разработка требований / Управление
• Предварительный расчет
• Разработка программного обеспечения
• Тестирование и др.

После того, как процессы определены и внедрены, Контроль качества выполняет следующие обязанности:

• Выявить слабые места в процессах
• Исправьте эти недостатки, чтобы постоянно улучшать процесс

Компоненты системы SQA

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

Предпроектные компоненты

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

Компоненты оценки жизненного цикла проекта

Жизненный цикл проекта состоит из двух этапов: этап жизненного цикла разработки и этап эксплуатации-обслуживания.

Компоненты этапа жизненного цикла разработки выявляют ошибки проектирования и программирования. Его компоненты подразделяются на следующие подклассы: обзоры, мнения экспертов и тестирование программного обеспечения.

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

Компоненты инфраструктуры предотвращения и улучшения ошибок

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

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

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

Компоненты стандартизации, сертификации и оценки системы SQA

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

Организация для SQA – человеческие компоненты

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

Предпроектные компоненты качества программного обеспечения

Эти компоненты помогают улучшить предварительные шаги, предпринятые перед началом проекта. Включает в себя –

• Обзор контракта
• Планы развития и качества

Обзор контракта

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

В частности, действия по рассмотрению контракта включают в себя –

• Разъяснение требований заказчика

• Обзор графика проекта и сметных потребностей

• Оценка способности профессионального персонала выполнять предложенный проект

• Оценка способности клиента выполнять свои обязательства

• Оценка рисков развития

Разъяснение требований заказчика

Обзор графика проекта и сметных потребностей

Оценка способности профессионального персонала выполнять предложенный проект

Оценка способности клиента выполнять свои обязательства

Оценка рисков развития

Планы развития и качества

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

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

Основные вопросы, рассматриваемые в плане развития проекта:

• Расписание
• Требуемые людские и аппаратные ресурсы
• Оценка рисков
• Организационные вопросы: члены команды, субподрядчики и партнерства
• Методология проекта, инструменты разработки и др.
• Планы повторного использования программного обеспечения

Основные вопросы, рассматриваемые в плане качества проекта:

• Цели в области качества, выраженные в соответствующих измеримых терминах

• Критерии начала и окончания каждого этапа проекта

• Списки обзоров, тестов и других запланированных действий по проверке и валидации

Цели в области качества, выраженные в соответствующих измеримых терминах

Критерии начала и окончания каждого этапа проекта

Списки обзоров, тестов и других запланированных действий по проверке и валидации

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

Метрики программного обеспечения можно разделить на три категории –

• Метрики продукта – описывает характеристики продукта, такие как размер, сложность, особенности дизайна, производительность и уровень качества.

• Метрики процесса – эти характеристики могут использоваться для улучшения деятельности по разработке и сопровождению программного обеспечения.

• Метрики проекта – эти метрики описывают характеристики и исполнение проекта. Примеры включают число разработчиков программного обеспечения, штатное расписание в течение жизненного цикла программного обеспечения, стоимость, график и производительность.

Метрики продукта – описывает характеристики продукта, такие как размер, сложность, особенности дизайна, производительность и уровень качества.

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

Метрики проекта – эти метрики описывают характеристики и исполнение проекта. Примеры включают число разработчиков программного обеспечения, штатное расписание в течение жизненного цикла программного обеспечения, стоимость, график и производительность.

Некоторые показатели относятся к нескольким категориям. Например, показатели качества процесса в проекте являются как показателями процесса, так и показателями проекта.

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

Метрики качества программного обеспечения можно разделить на три категории:

• Метрики качества продукции
• Показатели качества в процессе
• Метрики качества обслуживания

Метрики качества продукции

Эти показатели включают в себя следующее –

• Среднее время до отказа
• Плотность дефектов
• Проблемы с клиентами
• Удовлетворенность клиентов

Среднее время до отказа

Это время между неудачами. Этот показатель в основном используется с критически важными системами безопасности, такими как системы управления воздушным движением, авионика и оружие.

Плотность дефектов

Он измеряет дефекты относительно размера программного обеспечения, выраженного в виде строк кода или функциональной точки и т. Д., Т. Е. Измеряет качество кода на единицу. Этот показатель используется во многих коммерческих системах программного обеспечения.

Проблемы с клиентами

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

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

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Куда,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

PUM обычно рассчитывается для каждого месяца после выпуска программного обеспечения на рынок, а также для среднемесячных значений по годам.

Удовлетворенность клиентов

Удовлетворенность клиентов часто измеряется данными опросов клиентов по пятибалльной шкале –

• Очень доволен
• Довольный
• нейтральный
• неудовлетворенный
• Очень Недовольный

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

• Процент полностью удовлетворенных клиентов
• Процент довольных клиентов
• Процент недовольных клиентов
• Процент неудовлетворенных клиентов

Обычно этот процент удовлетворения используется.

Показатели качества в процессе

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

• Плотность дефектов при машинном тестировании
• Схема прибытия дефекта во время машинного тестирования
• Схема устранения дефектов на основе фазы
• Эффективность устранения дефектов

Плотность дефектов при машинном тестировании

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

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

Схема прибытия дефекта во время машинного тестирования

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

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

• Образец действительных дефектов прибывает, когда определение проблемы сделано на сообщенных проблемах. Это истинный образец дефекта.

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

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

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

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

Схема устранения дефектов на основе фазы

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

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

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

Эффективность устранения дефектов

Это можно определить следующим образом:

DRE= fracДефектудаленвовремяadevelopmentphaseДефектыскрытыйintheproduct times100%

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

Метрики качества обслуживания

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

• Исправить отставание и индекс управления отставанием
• Исправьте время отклика и исправьте реакцию
• Проценты по просроченным платежам
• Исправить качество

Исправить отставание и индекс управления отставанием

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

Индекс управления отставанием (BMI) используется для управления отставанием от открытых и нерешенных проблем.

BMI= fracЧислоofпроблемызакрытовтечениемесяцЧислоизпроблемприбыловтечениемесяц раз100%

Если ИМТ больше 100, это означает, что отставание уменьшается. Если ИМТ меньше 100, то отставание увеличивается.

Исправьте время отклика и исправьте реакцию

Показатель времени отклика исправления обычно рассчитывается как среднее время всех проблем от открытия до закрытия. Короткое время отклика приводит к удовлетворению клиента.

Важными элементами оперативного реагирования на исправления ошибок являются ожидания клиентов, согласованное время выполнения заказа и способность выполнять свои обязательства перед клиентом.

Проценты по просроченным платежам

Он рассчитывается следующим образом –

PercentDelinquentFixes=

 fracNumberofисправляетчтопревышеноответвремякритериипоceveritylevelNumberofисправленодоставленоinaуказановремя times100%

Исправить качество

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

Дефектное исправление может быть записано двумя способами: запишите его в том месяце, в котором оно было обнаружено, или запишите его в том месяце, когда оно было доставлено. Первый – это мера клиента; вторая – это процессная мера. Разница между двумя датами заключается в скрытом периоде дефектного исправления.

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

Основы измерения

Измерение – это действие измерения чего-либо. Это присвоение номера характеристике объекта или события, которое можно сравнить с другими объектами или событиями.

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

Измерение в повседневной жизни

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

Измерение берет информацию об атрибутах сущностей. Сущность – это объект, такой как человек, или событие, такое как путешествие в реальный мир. Атрибут – это особенность или свойство объекта, такие как рост человека, стоимость поездки и т. Д. В реальном мире, хотя мы думаем об измерении вещей, на самом деле мы измеряем атрибуты этих вещей.

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

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

Измерение является прямой количественной оценкой, тогда как вычисление является косвенной, где мы объединяем различные измерения, используя некоторые формулы.

Измерение в программной инженерии

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

Для большинства проектов развития,

• Мы не можем установить измеримые цели для наших программных продуктов
• Мы не понимаем и количественно не оцениваем стоимость компонентов программных проектов
• Мы не оцениваем и не прогнозируем качество производимой нами продукции.

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

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

• Чтобы понять, что происходит во время разработки и обслуживания
• Контролировать, что происходит в проекте
• Чтобы улучшить процессы и цели

Репрезентативная теория измерения

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

Эмпирические отношения

В реальном мире мы понимаем вещи, сравнивая их, а не присваивая им цифры.

Например, для сравнения высоты мы используем термины «выше чем», выше чем. Таким образом, эти «выше, чем», выше, чем эмпирические отношения для высоты.

Мы можем определить более одного эмпирического отношения на одном наборе.

Например, X выше, чем Y. X, Y намного выше, чем Z.

Эмпирические отношения могут быть одинарными, двоичными, троичными и т. Д.

X высокий, Y не высокий одинарные отношения.

X выше, чем Y – бинарное отношение.

Эмпирические отношения в реальном мире могут быть сопоставлены с формальным математическим миром. В основном эти отношения отражают личные предпочтения.

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

Шкала Лайкерта

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

Например – Это программное обеспечение работает хорошо.

Полностью согласен	Согласен	Ни согласен, ни несогласен	не соглашаться	Сильно не согласен

Принудительный рейтинг

Порядок заданных альтернатив от 1 (лучший) до n (худший).

Например: ранжируйте следующие 5 программных модулей в соответствии с их производительностью.

Наименование модуля	Ранг
Модуль А
Модуль Б
Модуль С
Модуль D
Модуль Е

Вербальная частотная шкала

Например – Как часто эта программа дает сбой?

Всегда	Часто	Иногда	Редко	Никогда

Порядковый масштаб

Здесь пользователям будет предоставлен список альтернатив, и они должны выбрать один.

Например – Как часто эта программа дает сбой?

• почасовой
• Ежедневно
• еженедельно
• ежемесячно
• Несколько раз в год
• Один или два раза в год
• Никогда

Сравнительная шкала

Здесь пользователь должен дать число, сравнивая различные варианты.

Очень высокий О том же Очень низкий

1 2 3 4 5 6 7 8 9 10

Числовой масштаб

Здесь пользователь должен указать число в соответствии с его важностью.

Неважно Важно

1 2 3 4 5 6 7 8 9 10

Правила отображения

Чтобы выполнить сопоставление, мы должны указать домен, диапазон, а также правила для выполнения сопоставления.

Например – Домен – Реальный мир

• Диапазон – математический мир, такой как целые числа, действительные числа и т. Д.

• Правила – Для измерения высоты, обувь носить или нет

Диапазон – математический мир, такой как целые числа, действительные числа и т. Д.

Правила – Для измерения высоты, обувь носить или нет

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

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

Условие представления утверждает, что отображение измерений (M) должно отображать объекты в числа, а эмпирические отношения в числовые отношения таким образом, чтобы эмпирические отношения сохранялись и сохранялись посредством числовых отношений.

Например: эмпирическое отношение «выше чем» отображается в числовое отношение «>», т. Е. X выше, чем Y, если и только если M (X)> M (Y)

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

Для унарного отношения «высокий» мы могли бы иметь числовое отношение

X> 50

Условие представления требует, чтобы для любой меры М ,

Х высокий тогда и только тогда, когда М (Х)> 50

Ключевые этапы формальных измерений

Основные этапы измерения можно обобщить следующим образом:

Измерение и модели

Модели полезны для интерпретации поведения числовых элементов реальных объектов, а также для их измерения. Чтобы помочь процессу измерения, модель отображения также должна быть дополнена моделью области отображения. Модель также должна указывать, как эти объекты связаны с атрибутами и как соотносятся характеристики.

Измерение бывает двух типов –

• Прямое измерение
• Косвенное измерение

Прямое измерение

Это измерения, которые могут быть измерены без участия какого-либо другого объекта или атрибута.

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

• Длина исходного кода по LOC
• Продолжительность цели тестирования по истекшему времени
• Количество дефектов, обнаруженных в процессе тестирования путем подсчета дефектов
• Время, которое программист тратит на программу

Косвенные измерения

Это измерения, которые могут быть измерены с точки зрения любого другого объекта или атрибута.

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

 smallProgrammerПроизводительность= fracLOCпроизведеноЧеловекмесяцыизусилия

 smallМодульДефектПлотность= fracЧислоofдефектовМодульразмер

 smallDefectDetectionEfficiency= fracNumberofдефектовобнаруженоВсегочислоofдефектов

 smallТребованиеСтабильность= fracЧислоofисходныйтребованияИтогочислоofтребований

 smallTestэффективностькоэффициент= fracчислоизпредметовпокрытыйвсегочислоизпредметов

 smallSystemspoilage= fracУсилиепотраченонаисправлениенеисправностиИтогопроектусилие

Измерение для прогноза

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

Весы измерения

Шкалы измерения – это отображения, используемые для представления эмпирической системы отношений. В основном это 5 типов –

• Номинальная шкала
• Порядковый масштаб
• Интервальная шкала
• Масштаб отношения
• Абсолютная шкала

Номинальная шкала

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

У него есть две основные характеристики –

• Эмпирическая система отношений состоит только из разных классов; среди классов нет понятия упорядоченности.

• Любая четкая нумерация или символическое представление классов является приемлемой мерой, но нет никакого понятия величины, связанной с числами или символами.

Эмпирическая система отношений состоит только из разных классов; среди классов нет понятия упорядоченности.

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

Порядковый масштаб

Он размещает элементы в упорядоченной схеме классификации. Он имеет следующие характеристики –

• Эмпирическая система отношений состоит из классов, упорядоченных по атрибуту.

• Любое отображение, которое сохраняет порядок, является приемлемым.

• Числа представляют только рейтинг. Следовательно, сложение, вычитание и другие арифметические операции не имеют смысла.

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

Любое отображение, которое сохраняет порядок, является приемлемым.

Числа представляют только рейтинг. Следовательно, сложение, вычитание и другие арифметические операции не имеют смысла.

Интервальная шкала

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

Он имеет следующие характеристики –

• Это сохраняет порядок как порядковый масштаб.

• Это сохраняет различия, но не соотношение.

• Сложение и вычитание могут быть выполнены в этом масштабе, но не умножение или деление.

Это сохраняет порядок как порядковый масштаб.

Это сохраняет различия, но не соотношение.

Сложение и вычитание могут быть выполнены в этом масштабе, но не умножение или деление.

Если атрибут измерим в интервальной шкале, а M и M ‘ являются отображениями, которые удовлетворяют условию представления, то мы всегда можем найти два числа a и b, таких что,

M = aM ‘+ b

Масштаб отношения

Это самая полезная шкала измерений. Здесь существует эмпирическое отношение для определения коэффициентов. Он имеет следующие характеристики –

• Это отображение измерений, которое сохраняет порядок, размер интервалов между объектами и соотношение между объектами.

• Существует нулевой элемент, представляющий полное отсутствие атрибутов.

• Отображение измерений должно начинаться с нуля и увеличиваться через равные интервалы, известные как единицы измерения.

• Все арифметические операции могут быть применены.

Это отображение измерений, которое сохраняет порядок, размер интервалов между объектами и соотношение между объектами.

Существует нулевой элемент, представляющий полное отсутствие атрибутов.

Отображение измерений должно начинаться с нуля и увеличиваться через равные интервалы, известные как единицы измерения.

Все арифметические операции могут быть применены.

Здесь отображение будет иметь вид

M = aM ‘

Где «а» – это положительный скаляр.

Абсолютная шкала

В этом масштабе будет только одна возможная мера для атрибута. Следовательно, единственно возможным преобразованием будет преобразование идентичности.

Он имеет следующие характеристики –

• Измерение производится путем подсчета количества элементов в наборе сущностей.

• Атрибут всегда принимает форму «количество вхождений x в сущности».

• Существует только одно возможное отображение измерений, а именно фактическое количество.

• Все арифметические операции могут быть выполнены с результирующим счетом.

Измерение производится путем подсчета количества элементов в наборе сущностей.

Атрибут всегда принимает форму «количество вхождений x в сущности».

Существует только одно возможное отображение измерений, а именно фактическое количество.

Все арифметические операции могут быть выполнены с результирующим счетом.

Эмпирические исследования

Эмпирические исследования включают научное исследование любого инструмента, техники или метода. Это исследование в основном содержит следующие 4 принципа.

• Выбор метода расследования
• Изложение гипотезы
• Поддержание контроля над переменной
• Делать расследование значимым

Выбор методики расследования

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

• Опрос
• Тематическое исследование
• Формальный эксперимент

Опрос

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

В этом случае мы не можем контролировать ситуацию под рукой. Мы можем записать ситуацию и сравнить ее с аналогичной.

Тематическое исследование

Это метод исследования, в котором вы определяете ключевые факторы, которые могут повлиять на результат действия, а затем документируете действие: его входные данные, ограничения, ресурсы и выходные данные.

Формальный эксперимент

Это строгое контролируемое расследование деятельности, где ключевые факторы выявляются и управляются для документирования их влияния на результат.

Конкретный метод расследования может быть выбран в соответствии со следующими рекомендациями –

• Если действие уже произошло, мы можем выполнить опрос или тематическое исследование. Если это еще не произошло, можно выбрать тематическое исследование или формальный эксперимент.

• Если у нас есть высокий уровень контроля над переменными, которые могут повлиять на результат, то мы можем использовать эксперимент. Если у нас нет контроля над переменной, то предпочтительным методом будет тематическое исследование.

• Если репликация невозможна на более высоких уровнях, то эксперимент невозможен.

• Если стоимость репликации низкая, то мы можем рассмотреть эксперимент.

Если действие уже произошло, мы можем выполнить опрос или тематическое исследование. Если это еще не произошло, можно выбрать тематическое исследование или формальный эксперимент.

Если у нас есть высокий уровень контроля над переменными, которые могут повлиять на результат, то мы можем использовать эксперимент. Если у нас нет контроля над переменной, то предпочтительным методом будет тематическое исследование.

Если репликация невозможна на более высоких уровнях, то эксперимент невозможен.

Если стоимость репликации низкая, то мы можем рассмотреть эксперимент.

Изложение гипотезы

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

Поддержание контроля над переменными

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

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

Например, если мы хотим определить, может ли изменение языка программирования повлиять на производительность проекта, тогда этот язык будет переменной состояния. Предположим, что в настоящее время мы используем FORTRAN, который мы хотим заменить на Ada. Тогда FORTRAN будет контрольным языком, а Ada – экспериментальным.

Делать расследование значимым

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

Соответствующие теории и общепринятая мудрость

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

Изучение отношений

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

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

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

Оценка точности моделей

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

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

Валидационные меры

Существует множество программных мер для захвата значения атрибута. Следовательно, необходимо провести исследование, чтобы проверить, отражает ли данная мера изменения в атрибуте, который она должна фиксировать. Проверка выполняется путем соотнесения одной меры с другой. Вторая мера, которая также является прямой и действительной мерой влияющего фактора, должна использоваться для проверки. Такие меры не всегда доступны или их легко измерить. Кроме того, используемые меры должны соответствовать человеческим представлениям об измеряемом факторе.

Измерение программного обеспечения

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

• Классификация объектов, подлежащих проверке
• Определение соответствующих целей измерения
• Определение уровня зрелости, которого достигла организация

Классификация сущностей, подлежащих проверке

В программной инженерии существует в основном три класса сущностей. Они –

• Процессы
• Товары
• Ресурсы

Все эти объекты имеют как внутренние, так и внешние объекты.

• Внутренние атрибуты – это те, которые могут быть измерены исключительно с точки зрения самого процесса, продукта или ресурсов. Например: размер, сложность, зависимость между модулями.

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

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

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

Различные атрибуты, которые могут быть измерены для каждого из объектов, следующие:

Процессы

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

• Продолжительность процесса или одного из его действий

• Усилия, связанные с процессом или одним из его видов деятельности

• Количество инцидентов определенного типа, возникающих в ходе процесса или одного из его действий

Продолжительность процесса или одного из его действий

Усилия, связанные с процессом или одним из его видов деятельности

Количество инцидентов определенного типа, возникающих в ходе процесса или одного из его действий

Различные внешние атрибуты процесса – это стоимость, управляемость, эффективность, качество и стабильность.

Товары

Продукты – это не только элементы, которые руководство обязуется предоставить, но также любые артефакты или документы, созданные в течение жизненного цикла программного обеспечения.

Различные внутренние атрибуты продукта – это размер, усилия, стоимость, спецификация, длина, функциональность, модульность, повторное использование, избыточность и синтаксическая корректность. Среди этих размеров, усилия и стоимость относительно легко измерить, чем другие.

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

Ресурсы

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

Различными внутренними атрибутами для ресурсов являются возраст, цена, размер, скорость, объем памяти, температура и т. Д. Различными внешними атрибутами являются производительность, опыт, качество, удобство использования, надежность, комфорт и т. Д.

Определение соответствующих целей измерения

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

Парадигма цель-вопрос-метрика (GQM)

Подход GQM обеспечивает структуру, включающую следующие три этапа:

• Перечисление основных целей проекта разработки или сопровождения

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

• Решите, что должно быть измерено, чтобы иметь возможность адекватно отвечать на вопросы

Перечисление основных целей проекта разработки или сопровождения

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

Решите, что должно быть измерено, чтобы иметь возможность адекватно отвечать на вопросы

Чтобы использовать парадигму GQM, сначала мы выражаем общие цели организации. Затем мы генерируем вопросы так, чтобы ответы были известны, чтобы мы могли определить, достигаются ли цели. Позже, проанализируйте каждый вопрос с точки зрения того, какое измерение нам нужно, чтобы ответить на каждый вопрос.

Типичные цели выражаются с точки зрения производительности, качества, риска, удовлетворенности клиентов и т. Д. Цели и вопросы должны строиться с точки зрения их аудитории.

Чтобы составить цели, вопросы и показатели, Basili & Rombach предоставили серию шаблонов.

• Цель – Чтобы (охарактеризовать, оценить, предсказать, мотивировать и т. Д.) (Процесс, продукт, модель, метрика и т. Д.), Чтобы понять, оценить, управлять, спроектировать, выучить, улучшить и т. Д. Пример : охарактеризовать продукт для того, чтобы выучить его.

• Перспектива – Изучите (стоимость, эффективность, правильность, дефекты, изменения, показатели продукта и т. Д.) С точки зрения разработчика, менеджера, клиента и т. Д. Пример . Изучите дефекты с точки зрения заказчика.

• Среда . Среда состоит из следующих факторов: факторы процесса, факторы персонала, проблемные факторы, методы, инструменты, ограничения и т. Д. Пример . Клиентами этого программного обеспечения являются те, кто ничего не знает об инструментах.

Цель – Чтобы (охарактеризовать, оценить, предсказать, мотивировать и т. Д.) (Процесс, продукт, модель, метрика и т. Д.), Чтобы понять, оценить, управлять, спроектировать, выучить, улучшить и т. Д. Пример : охарактеризовать продукт для того, чтобы выучить его.

Перспектива – Изучите (стоимость, эффективность, правильность, дефекты, изменения, показатели продукта и т. Д.) С точки зрения разработчика, менеджера, клиента и т. Д. Пример . Изучите дефекты с точки зрения заказчика.

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

Измерение и улучшение процесса

Обычно измерение полезно для –

• Понимание процесса и продуктов
• Установление базовой линии
• Доступ и прогнозирование результата

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

Уровень 1: Ad hoc

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

Уровень 2: Повторяемый

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

Мерами ввода могут быть размер и изменчивость требований. Результат может быть измерен с точки зрения размера системы, ресурсов с точки зрения усилий персонала и ограничений с точки зрения затрат и графика.

Уровень 3: Определен

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

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

Уровень 4: Управляемый

На этом уровне отзывы о ранних действиях проекта могут использоваться для определения приоритетов для текущей деятельности, а затем и для деятельности проекта. Мы можем измерить эффективность процесса деятельности. Измерение отражает характеристики всего процесса и взаимодействия между основными видами деятельности и между ними.

Уровень 5: Оптимизация

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

На данном уровне зрелости мы можем собрать измерения для этого уровня и всех уровней ниже него.

Определение уровня зрелости

Процесс зрелости предлагает измерять только то, что видно. Таким образом, сочетание зрелости процесса с GQM обеспечит наиболее полезные меры.

• На уровне 1 , проект, вероятно, будет иметь плохо определенные требования. На этом уровне измерение характеристик требований затруднено.

• На уровне 2 требования четко определены, и может быть собрана дополнительная информация, такая как тип каждого требования и количество изменений каждого типа.

• На уровне 3 промежуточные действия определяются с критериями входа и выхода для каждого действия

На уровне 1 , проект, вероятно, будет иметь плохо определенные требования. На этом уровне измерение характеристик требований затруднено.

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

На уровне 3 промежуточные действия определяются с критериями входа и выхода для каждого действия

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

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

Проверка измерения программного обеспечения

Проверка правильности измерения программного обеспечения системы включает в себя два этапа –

• Валидация измерительных систем
• Валидация систем прогнозирования

Валидация измерительных систем

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

Валидация системы измерения программного обеспечения – это процесс обеспечения того, что мера является надлежащей числовой характеристикой заявленного атрибута, показывая, что условие представления удовлетворяется.

Для проверки системы измерения нам нужна как формальная модель, которая описывает сущности, так и числовое отображение, которое сохраняет атрибут, который мы измеряем. Например, если есть две программы P1 и P2, и мы хотим объединить эти программы, то мы ожидаем, что любая мера длины m удовлетворяет этому,

m (P1 + P2) = m (P1) + m (P2)

Если программа P1 имеет большую длину, чем программа P2 , то любая мера m также должна удовлетворять:

м (Р1)> м (Р2)

Длина программы может быть измерена путем подсчета строк кода. Если это число удовлетворяет вышеуказанным отношениям, мы можем сказать, что строки кода являются допустимым показателем длины.

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

Валидация систем прогнозирования

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

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

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

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

Метрики измерения программного обеспечения

Метрики программного обеспечения – это стандарт измерения, который содержит множество действий, которые включают в себя некоторую степень измерения. Его можно разделить на три категории: метрики продуктов, метрики процессов и метрики проектов.

• Метрики продукта описывают такие характеристики продукта, как размер, сложность, особенности дизайна, производительность и уровень качества.

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

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

Метрики продукта описывают такие характеристики продукта, как размер, сложность, особенности дизайна, производительность и уровень качества.

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

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

Некоторые показатели относятся к нескольким категориям. Например, показатели качества процесса в проекте являются как показателями процесса, так и показателями проекта.

Объем программных метрик

Метрики программного обеспечения содержат много действий, которые включают следующее –

• Оценка затрат и усилий
• Меры и модель производительности
• Сбор информации
• Количественные модели и меры
• Надежность моделей
• Модели производительности и оценки
• Структурные и сложные показатели
• Способность – оценка зрелости
• Управление по метрикам
• Оценка методов и инструментов

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

Оценка стоимости и усилий

Усилие выражается как функция одной или нескольких переменных, таких как размер программы, возможности разработчиков и уровень повторного использования. Модели оценки затрат и усилий были предложены для прогнозирования стоимости проекта на ранних этапах жизненного цикла программного обеспечения. Предлагаемые разные модели –

• Модель Бома КОКОМО
• Тонкая модель Путнэма
• Функциональная точечная модель Альбрехта

Модель и меры производительности

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

Сбор информации

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

Качественные модели и меры

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

Понятие «разделяй и властвуй» было реализовано как стандартный подход к измерению качества программного обеспечения.

Модели надежности

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

Оценка производительности и модели

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

Структурные и Сложность Метрики

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

Оценка зрелости

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

Управление метриками

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

Оценка методов и инструментов

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

Манипуляция данными

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

Что такое хорошие данные?

Собранные данные можно рассматривать как хорошие данные, если они могут дать ответы на следующие вопросы:

• Они правы? – Данные могут считаться правильными, если они были собраны в соответствии с точными правилами определения метрики.

• Они точны? – Точность относится к разнице между данными и фактическим значением.

• Они точно точны? – Точность связана с количеством десятичных знаков, необходимых для выражения данных.

• Они последовательны? – Данные могут считаться непротиворечивыми, если они не показывают существенных отличий от одного измерительного устройства к другому.

• Связаны ли они с определенной деятельностью или периодом времени? – Если данные связаны с определенной деятельностью или периодом времени, то они должны быть четко указаны в данных.

• Могут ли они быть воспроизведены? – Обычно такие исследования, как опросы, тематические исследования и эксперименты, часто повторяются при разных обстоятельствах. Следовательно, данные также должны быть легко воспроизведены.

Они правы? – Данные могут считаться правильными, если они были собраны в соответствии с точными правилами определения метрики.

Они точны? – Точность относится к разнице между данными и фактическим значением.

Они точно точны? – Точность связана с количеством десятичных знаков, необходимых для выражения данных.

Они последовательны? – Данные могут считаться непротиворечивыми, если они не показывают существенных отличий от одного измерительного устройства к другому.

Связаны ли они с определенной деятельностью или периодом времени? – Если данные связаны с определенной деятельностью или периодом времени, то они должны быть четко указаны в данных.

Могут ли они быть воспроизведены? – Обычно такие исследования, как опросы, тематические исследования и эксперименты, часто повторяются при разных обстоятельствах. Следовательно, данные также должны быть легко воспроизведены.

Как определить данные?

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

• Необработанные данные. Необработанные данные являются результатом первоначального измерения процесса, продуктов или ресурсов. Например: еженедельное расписание сотрудников в организации.

• Уточненные данные – уточненные данные получаются в результате извлечения основных элементов данных из необработанных данных для получения значений атрибутов.

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

Уточненные данные – уточненные данные получаются в результате извлечения основных элементов данных из необработанных данных для получения значений атрибутов.

Данные могут быть определены в соответствии со следующими пунктами –

• Место нахождения
• тайминг
• симптомы
• Конечный результат
• Механизм
• причина
• Строгость
• Стоимость

Как собирать данные?

Сбор данных требует наблюдения человека и отчетности. Менеджеры, системные аналитики, программисты, тестировщики и пользователи должны записывать данные строк в формы. Для сбора точных и полных данных важно:

• Сделайте процедуры простыми

• Избегайте ненужной записи

• Обучите сотрудников необходимости записи данных и процедурам, которые будут использоваться

• Своевременно и в удобной форме предоставлять результаты сбора и анализа данных исходным поставщикам, которые помогут им в их работе.

• Проверьте все данные, собранные в центральном пункте сбора

Сделайте процедуры простыми

Избегайте ненужной записи

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

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

Проверьте все данные, собранные в центральном пункте сбора

Планирование сбора данных включает в себя несколько этапов –

• Решите, какие продукты измерять на основе анализа GQM

• Убедитесь, что продукт находится под контролем конфигурации

• Определите, какие именно атрибуты измерять и как будут получены косвенные показатели

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

• Установите процедуру обработки форм, анализа данных и представления результатов.

Решите, какие продукты измерять на основе анализа GQM

Убедитесь, что продукт находится под контролем конфигурации

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

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

Установите процедуру обработки форм, анализа данных и представления результатов.

Планирование сбора данных должно начинаться, когда начинается планирование проекта. Сбор фактических данных происходит на многих этапах разработки.

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

Как хранить и извлекать данные

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

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

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

Анализ данных измерений программного обеспечения

После сбора соответствующих данных, мы должны проанализировать их соответствующим образом. Есть три основных момента, которые следует учитывать при выборе метода анализа.

• Природа данных
• Цель эксперимента
• Особенности дизайна

Природа данных

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

Выборка, население и распределение данных

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

Параметры популяции представляют собой значения, которые были бы получены, если бы были измерены все возможные предметы.

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

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

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

Цель эксперимента

Обычно проводятся эксперименты –

• Чтобы подтвердить теорию
• Чтобы исследовать отношения

Для достижения каждого из них, цель должна быть формально выражена в терминах гипотезы, а анализ должен непосредственно касаться гипотезы.

Чтобы подтвердить теорию

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

Необходимо рассмотреть два случая данных: нормальные данные и ненормальные данные .

Если данные взяты из нормального распределения и есть две группы для сравнения, для анализа можно использовать t-критерий Стьюдента. Если нужно сравнить более двух групп, можно использовать общий анализ дисперсии, называемый F-статистикой.

Если данные не являются нормальными, то данные могут быть проанализированы с помощью теста Крускала-Уоллиса путем ранжирования.

Чтобы исследовать отношения

Исследования предназначены для определения взаимосвязи между точками данных, описывающими одну переменную или несколько переменных.

Есть три метода, чтобы ответить на вопросы об отношениях: коробочные графики, точечные диаграммы и корреляционный анализ.

• Квадратный график может представлять сводку диапазона набора данных.

• Диаграмма разброса представляет связь между двумя переменными.

• Корреляционный анализ использует статистические методы, чтобы подтвердить, существует ли истинная связь между двумя атрибутами.

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

  • Для ненормальных данных ранжируйте данные и используйте коэффициент корреляции ранга Спирмена в качестве меры ассоциации. Другой мерой для ненормальных данных является надежный коэффициент корреляции Кендалла , который исследует взаимосвязь между парами точек данных и может идентифицировать частичную корреляцию.

Квадратный график может представлять сводку диапазона набора данных.

Диаграмма разброса представляет связь между двумя переменными.

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

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

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

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

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

Особенности дизайна

План исследования должен учитываться при выборе методов анализа. В то же время, сложность анализа может влиять на выбранный дизайн. Несколько групп используют F-статистику, а не T-критерий Стьюдента с двумя группами.

Для сложных факторных планов с более чем двумя факторами необходим более сложный тест связи и значимости.

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

Внутренние атрибуты продукта

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

Измерение внутренних атрибутов продукта

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

Измерение размера

Размер программного обеспечения можно описать тремя атрибутами:

• Длина – это физический размер продукта.

• Функциональность – описывает функции, предоставляемые продуктом пользователю.

• Сложность – Сложность бывает разных типов, например.

  • Сложность проблемы – Измеряет сложность основной проблемы.

  • Алгоритмическая сложность – измеряет сложность алгоритма, реализованного для решения задачи

  • Структурная сложность – Измеряет структуру программного обеспечения, используемого для реализации алгоритма.

  • Когнитивная сложность – измеряет усилия, необходимые для понимания программного обеспечения.

Длина – это физический размер продукта.

Функциональность – описывает функции, предоставляемые продуктом пользователю.

Сложность – Сложность бывает разных типов, например.

Сложность проблемы – Измеряет сложность основной проблемы.

Алгоритмическая сложность – измеряет сложность алгоритма, реализованного для решения задачи

Структурная сложность – Измеряет структуру программного обеспечения, используемого для реализации алгоритма.

Когнитивная сложность – измеряет усилия, необходимые для понимания программного обеспечения.

Измерение этих трех атрибутов можно описать следующим образом:

длина

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

Спецификация и дизайн

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

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

Для этих измерений атомные объекты должны быть определены для различных типов диаграмм и символов.

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

Код

Код может быть создан различными способами, такими как процедурный язык, объектная ориентация и визуальное программирование. Наиболее часто используемая традиционная мера длины исходного кода программы – это строки кода (LOC).

Общая длина,

LOC = NCLOC + CLOC

т.е.

LOC = без комментариев LOC + с комментариями LOC

Помимо строки кода, для измерения длины могут использоваться и другие альтернативы, такие как размер и сложность, предложенные Морисом Холстедом.

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

Он начал с определения программы P как набора токенов, классифицированных по операторам или операндам. Основные метрики для этих токенов были,

• μ ₁ = количество уникальных операторов

• μ ₂ = количество уникальных операндов

• N ₁ = Всего вхождений операторов

• N ₂ = количество уникальных операторов

μ ₁ = количество уникальных операторов

μ ₂ = количество уникальных операндов

N ₁ = Всего вхождений операторов

N ₂ = количество уникальных операторов

Длина P может быть определена как

N=N1+N2

Словарный запас

 mu= mu1+ mu2

Объем программы = количество умственных сравнений, необходимых для написания программы длиной N , равно

V=N timeslog2 mu

Программный уровень программы P громкости V составляет,

L= fracV astV

Где V ast – потенциальный объем, т. Е. Объем реализации P минимального размера

Инверсией уровня является сложность –

D=1 diagupL

Согласно теории Холстеда, мы можем вычислить оценку L как

L′=1 diagupD= frac2 mu1 times frac mu2N2

Точно так же примерная длина программы составляет  mu1 timeslog2 mu1+ mu2 timeslog2 mu2

Усилие, необходимое для генерации P определяется как

E=V diagupL= frac mu1N2Nlog2 mu2 mu2

Где единица измерения E – элементарное умственное различение, необходимое для понимания P

Другие альтернативы для измерения длины:

• С точки зрения количества байтов памяти компьютера, необходимых для текста программы

• По количеству символов в тексте программы

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

По количеству символов в тексте программы

Объектно-ориентированная разработка предлагает новые способы измерения длины. Pfleeger et al. Установлено, что подсчет объектов и методов приводит к более точным оценкам производительности, чем те, которые используют строки кода.

функциональность

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

Метод функциональной точки Альбрехта

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

Мера Function Point, изначально разработанная Альбрехтом, получила все большую популярность благодаря созданию Международной группы пользователей Function Point (IFPUG) в 1986 году. В 2002 году функциональные точки IFPUG стали международным стандартом ISO – ISO / IEC 20926.

Что такое функциональная точка?

FP (Function Point) – наиболее распространенная метрика функционального типа, подходящая для количественной оценки программного приложения. Он основан на пяти идентифицируемых пользователем логических «функциях», которые разделены на два типа функций данных и три типа транзакционных функций. Для данного программного приложения каждый из этих элементов определяется количественно и взвешивается, считая его характерные элементы, такие как ссылки на файлы или логические поля.

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

Применение метода функциональных точек Альбрехта

Давайте теперь поймем, как применить метод Точки функции Альбрехта. Его процедура заключается в следующем –

Определите количество компонентов (EI, EO, EQ, ILF и ELF)

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

• EO – номер внешнего выхода. Это элементарные процессы, в которых производные данные проходят через границу изнутри наружу. В примере системы базы данных библиотеки отобразите список книг, извлеченных для покровителя.

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

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

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

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

EO – номер внешнего выхода. Это элементарные процессы, в которых производные данные проходят через границу изнутри наружу. В примере системы базы данных библиотеки отобразите список книг, извлеченных для покровителя.

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

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

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

Вычислить нескорректированный счетчик функциональных точек (UFC)

• Оцените каждый компонент как низкий, средний или высокий .

• Для транзакций (EI, EO и EQ) рейтинг основан на FTR и DET .

  • FTR – количество файлов, обновленных или на которые есть ссылки.

  • DET – количество распознаваемых пользователем полей.

  • На основании следующей таблицы EI, который ссылается на 2 файла и 10 элементов данных, будет ранжироваться как среднее .

Оцените каждый компонент как низкий, средний или высокий .

Для транзакций (EI, EO и EQ) рейтинг основан на FTR и DET .

FTR – количество файлов, обновленных или на которые есть ссылки.

DET – количество распознаваемых пользователем полей.

На основании следующей таблицы EI, который ссылается на 2 файла и 10 элементов данных, будет ранжироваться как среднее .

финансовые права на передачу	дец
1-5	6-15	> 15
0-1	Низкий	Низкий	Средний
2-3	Низкий	Средний	Высоко
> 3	Средний	Высоко	Высоко

• Для файлов (ILF и ELF) рейтинг основан на RET и DET .

  • RET – количество распознаваемых пользователем элементов данных в ILF или ELF .

  • DET – количество распознаваемых пользователем полей.

  • На основании следующей таблицы ILF, который содержит 10 элементов данных и 5 полей, будет иметь высокий рейтинг.

Для файлов (ILF и ELF) рейтинг основан на RET и DET .

RET – количество распознаваемых пользователем элементов данных в ILF или ELF .

DET – количество распознаваемых пользователем полей.

На основании следующей таблицы ILF, который содержит 10 элементов данных и 5 полей, будет иметь высокий рейтинг.

ТВЭ	дец
1-5	6-15	> 15
1	Низкий	Низкий	Средний
2-5	Низкий	Средний	Высоко
> 5	Средний	Высоко	Высоко

• Преобразуйте рейтинги в UFC .

Преобразуйте рейтинги в UFC .

Рейтинг	Ценности
Е.О.	EQ	EI	ILF	ELF
Низкий	4	3	3	7	5
Средний	5	4	4	10	7
Высоко	6	5	6	15	10

Вычислить конечный счетчик функциональных точек (FPC)

• Вычислить поправочный коэффициент (VAF) на основе 14 общих характеристик системы (GSC) .

Вычислить поправочный коэффициент (VAF) на основе 14 общих характеристик системы (GSC) .

Общая характеристика системы	Краткое описание
GSC 1	Передача данных	Сколько средств связи существует для помощи в передаче или обмене информацией с приложением или системой?
GSC 2	Распределенная обработка данных	Как обрабатываются распределенные данные и функции обработки?
GSC 3	Спектакль	Требуется ли пользователю время отклика или пропускная способность?
GSC 4	Сильно используемая конфигурация	Насколько интенсивно используется текущая аппаратная платформа, на которой будет выполняться приложение?
GSC 5	Коэффициент транзакций	Как часто транзакции выполняются ежедневно, еженедельно, ежемесячно и т. Д.?
GSC 6	Ввод данных онлайн	Какой процент информации вводится онлайн?
GSC 7	Эффективность конечного пользователя	Было ли приложение разработано для эффективности конечного пользователя?
GSC 8	Онлайн обновление	Сколько ILF обновляется онлайн транзакцией?
GSC 9	Комплексная обработка	Имеет ли приложение обширную логическую или математическую обработку?
GSC 10	Повторное использование	Было ли приложение разработано для удовлетворения потребностей одного или нескольких пользователей?
GSC 11	Простота установки	Насколько сложна конвертация и установка?
GSC 12	Операционная простота	Насколько эффективны и / или автоматизированы процедуры запуска, резервного копирования и восстановления?
GSC 13	Несколько сайтов	Было ли приложение специально разработано, разработано и поддерживается для установки на нескольких сайтах для нескольких организаций?
GSC 14	Облегчить изменение	Было ли приложение специально разработано, разработано и поддержано для облегчения изменений?

• Взвесьте каждый GSC по шкале от 0 до 5, основываясь на том, не влияет ли он на сильное влияние.

• Вычислить FPC следующим образом –

  FPC = UFC * (0,65+ (сумма ( GSC ) * .01))

Взвесьте каждый GSC по шкале от 0 до 5, основываясь на том, не влияет ли он на сильное влияние.

Вычислить FPC следующим образом –

FPC = UFC * (0,65+ (сумма ( GSC ) * .01))

сложность

Сложность – это отдельная составляющая размера. Это двух типов –

• Сложность проблемы – это количество ресурсов, необходимое для оптимального решения проблемы.

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

  • Сложность времени – ресурс компьютерного времени.

  • Пространство сложности – ресурс памяти компьютера.

Сложность проблемы – это количество ресурсов, необходимое для оптимального решения проблемы.

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

Сложность времени – ресурс компьютерного времени.

Пространство сложности – ресурс памяти компьютера.

Измерение сложности

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

Например: если алгоритм для решения всех случаев конкретной задачи требует вычислений f (n) , то f (n) является асимптотически оптимальным, если для любого другого алгоритма со сложностью g, который решает задачу, f является O (g) . Тогда сложность данной задачи велика – O асимптотически оптимального алгоритма решения задачи.

Измерение структуры

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

Типы структурных мероприятий

Структура программного обеспечения состоит из трех частей. Они –

• Структура потока управления – это последовательность выполнения инструкций в программе.

• Структура потока данных – это поведение данных при взаимодействии с программой.

• Структура данных – это организация элементов данных в форме списков, очереди, стеков или других четко определенных структур вместе с алгоритмом их создания, изменения или удаления.

Структура потока управления – это последовательность выполнения инструкций в программе.

Структура потока данных – это поведение данных при взаимодействии с программой.

Структура данных – это организация элементов данных в форме списков, очереди, стеков или других четко определенных структур вместе с алгоритмом их создания, изменения или удаления.

Измерение структуры управления потоком

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

Если «m» является структурной мерой, определенной в терминах модели потокового графа, и если программа A является структурно более сложной, чем программа B , то мера m (A) должна быть больше, чем m (B) .

Измерение структуры потока данных

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

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

• Локальный прямой поток – если либо модуль вызывает второй модуль и передает ему информацию, либо вызванный модуль возвращает результат вызывающей стороне.

• Локальный косвенный поток – если вызванный модуль возвращает информацию, которая впоследствии передается во второй вызываемый модуль.

• Глобальный поток – если информация перемещается из одного модуля в другой через глобальную структуру данных.

Локальный прямой поток – если либо модуль вызывает второй модуль и передает ему информацию, либо вызванный модуль возвращает результат вызывающей стороне.

Локальный косвенный поток – если вызванный модуль возвращает информацию, которая впоследствии передается во второй вызываемый модуль.

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

Сложность информационного потока может быть выражена по Генри и Кафуре как,

Сложность потока информации (M) = длина (M) × разветвление (M) × (разветвление (M)) ²

Куда,

• Fan-in (M) – количество локальных потоков, оканчивающихся на M + количество структур данных, из которых информация извлекается M.

• Fan-out (M) – количество локальных потоков, исходящих из M + количество структур данных, которые обновляются M.

Fan-in (M) – количество локальных потоков, оканчивающихся на M + количество структур данных, из которых информация извлекается M.

Fan-out (M) – количество локальных потоков, исходящих из M + количество структур данных, которые обновляются M.

Структура данных измерений

Структура данных может быть как локальной, так и глобальной .

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

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

Стандарты и Сертификаты

Несколько национальных и международных институтов по стандартизации, профессиональные и отраслевые организации были вовлечены в разработку стандартов SQA.

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

• IEEE (Институт инженеров по электротехнике и электронике) Компьютерное общество
• ISO (Международная организация по стандартизации)
• Министерство обороны США (Министерство обороны США)
• ANSI (Американский национальный институт стандартов)
• IEC (Международная электротехническая комиссия)
• EIA (Ассоциация электронной промышленности)

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

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

Они также предоставляют инструменты для самооценки системы SQA организации и ее функционирования. Примерами этого подхода являются Модель зрелости емкости (CMM), разработанная Институтом разработки программного обеспечения (SEI), Университетом Карнеги-Меллона и стандартом ISO / IEC Std 15504.

Стандарты SQA

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

• Стандарты управления обеспечением качества программного обеспечения, включая методологии сертификации и оценки (стандарты управления качеством)

• Стандарты процесса разработки программного обеспечения (стандарты процесса проекта)

Стандарты управления обеспечением качества программного обеспечения, включая методологии сертификации и оценки (стандарты управления качеством)

Стандарты процесса разработки программного обеспечения (стандарты процесса проекта)

Стандарты управления качеством

Они ориентированы на систему, инфраструктуру и требования SQA организации, оставляя выбор методов и инструментов для организации. Благодаря стандартам управления качеством организации могут уверенно гарантировать, что их программные продукты достигают приемлемого уровня качества.

Пример – ИСО 9000-3 и модель зрелости возможностей (CMM)

Стандарты процесса проекта

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

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

Естественно, благодаря своим характеристикам многие стандарты SQA в этом классе могут служить стандартами разработки программного обеспечения и наоборот.

Характеристики этих двух классов стандартов приведены в следующей таблице.

Характеристики	Стандарты управления качеством	Стандарты процесса проекта
Целевая единица	Управление разработкой программного обеспечения, обслуживанием и конкретными подразделениями SQA	Команда проекта разработки и сопровождения программного обеспечения
Основное внимание	Организация систем SQA, инфраструктуры и требований	Методология выполнения проектов разработки и сопровождения программного обеспечения.
Цель стандарта	«Что» достичь	«Как» выполнить
Цель стандарта	Обеспечение качества программного обеспечения поставщика и оценка возможностей его программного процесса	Обеспечение качества программного обеспечения поставщика и оценка возможностей его программного обеспечения. Обеспечение качества конкретного программного проекта.
Примеры	ISO 9000-3 SEI CMM	ISO / IEC 12207 IEEEStd 1012-1998

Сертификация ISO 9001

ISO (Международная организация по стандартизации) – всемирная федерация национальных органов стандартизации. Технические комитеты ISO готовят международные стандарты. ИСО тесно сотрудничает с Международной электротехнической комиссией (МЭК) по всем вопросам электротехнической стандартизации.

Международные стандарты разрабатываются в соответствии с правилами, приведенными в Директивах ИСО / МЭК, часть 2. Проект международных стандартов, принятый техническими комитетами, направляется в органы-члены для голосования. ISO 9001 был подготовлен Техническим комитетом ISO / TC 176, Управление качеством и обеспечение качества, Подкомитетом SC 2, Системы качества.

Процессный подход

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

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

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

• Понимание и выполнение требований
• Необходимо рассмотреть процессы с точки зрения добавленной стоимости
• Получить результаты производительности и эффективности процесса
• Постоянное улучшение процессов на основе объективного измерения

ISO 9001 – Применение к программному обеспечению: инициатива TickIT

TickIT был запущен в конце 1980-х годов британской индустрией программного обеспечения в сотрудничестве с Министерством торговли и промышленности Великобритании для содействия разработке методологии для адаптации ISO 9001 к характеристикам индустрии программного обеспечения, известной как инициатива TickIT.

Кроме того, TickIT специализируется на информационных технологиях (ИТ). Он охватывает весь спектр коммерческих услуг по разработке и сопровождению программного обеспечения. TickIT, в настоящее время управляемый и поддерживаемый Департаментом DISC BSI (Британский институт стандартов), аккредитован для сертификации ИТ-организаций в Великобритании и Швеции.

Его деятельность включает в себя –

• Публикация Руководства TickIT, которое поддерживает усилия индустрии программного обеспечения по распространению сертификации ISO 9001. Текущее руководство (издание 5.0, TickIT, 2001), которое включает ссылки на ИСО / МЭК 12207 и ИСО / МЭК 15504, распространяется среди всех клиентов TickIT.

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

• Провести сертификационный аудит ISO 9000.

Публикация Руководства TickIT, которое поддерживает усилия индустрии программного обеспечения по распространению сертификации ISO 9001. Текущее руководство (издание 5.0, TickIT, 2001), которое включает ссылки на ИСО / МЭК 12207 и ИСО / МЭК 15504, распространяется среди всех клиентов TickIT.

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

Провести сертификационный аудит ISO 9000.

Аудиторы TickIT, проводящие аудиторские оценки и сертификационные аудиты, зарегистрированы Международным регистром сертифицированных аудиторов (IRCA). Зарегистрированные аудиторы IRCA обязаны, помимо прочего, иметь опыт управления и разработки программного обеспечения; они также должны успешно пройти курс одитора.

Зарегистрированные ведущие аудиторы должны иметь подтвержденный опыт в проведении и руководстве аудитами TickIT.

Оценка процесса разработки программного обеспечения

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

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

• Самооценка (первичная оценка) выполняется внутри организации персоналом организации.

• Оценка сторонней организации выполняется внешней группой по оценке, или организация оценивается заказчиком.

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

Самооценка (первичная оценка) выполняется внутри организации персоналом организации.

Оценка сторонней организации выполняется внешней группой по оценке, или организация оценивается заказчиком.

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

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

Оценка зрелости программного процесса

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

Когда целью оценки является организация, результаты оценки процесса могут отличаться даже при последовательном применении одного и того же метода. Есть две причины для разных результатов. Они есть,

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

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

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

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

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

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

Цикл Оценки Программного Процесса

Согласно Paulk и коллегам (1995), подход к оценке на основе CMM использует шестиступенчатый цикл. Они –

• Выберите команду. Члены команды должны быть профессионалами, обладающими знаниями в области разработки программного обеспечения и управления.

• Представители оцениваемого сайта заполняют стандартную анкету зрелости процесса.

• Команда оценки выполняет анализ ответов на вопросник и определяет области, которые требуют дальнейшего изучения, в соответствии с ключевыми областями процесса ШМ.

• Команда оценки проводит посещение сайта, чтобы понять процесс разработки программного обеспечения, сопровождаемого сайтом.

• Команда оценки составляет список результатов, которые идентифицируют сильные и слабые стороны процесса разработки программного обеспечения организации.

• Команда по оценке готовит анализ профиля ключевой области процесса (KPA) и представляет результаты соответствующей аудитории.

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

Представители оцениваемого сайта заполняют стандартную анкету зрелости процесса.

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

Команда оценки проводит посещение сайта, чтобы понять процесс разработки программного обеспечения, сопровождаемого сайтом.

Команда оценки составляет список результатов, которые идентифицируют сильные и слабые стороны процесса разработки программного обеспечения организации.

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

Например, группа по оценке должна возглавляться уполномоченным ведущим оценщиком SEI. Команда должна состоять из четырех-десяти членов команды. По крайней мере, один член команды должен быть из оцениваемой организации, и все члены команды должны пройти курс SEI «Введение в CMM» (или его эквивалент) и курс обучения команды SEI CBA IPI. Члены команды также должны соответствовать некоторым правилам отбора.

Что касается сбора данных, ИПБ ЦБА использует четыре метода:

• Стандартный вопросник зрелости
• Индивидуальные и групповые интервью
• Обзоры документов
• Отзывы о рассмотрении проекта выводов с участниками оценки

SCAMPI

Стандартный метод оценки CMMI для улучшения процессов (SCAMPI) был разработан для удовлетворения требований модели CMMI (Software Engineering Institute, 2000). Он также основан на IPA ЦБА. И CBA IPI, и SCAMPI состоят из трех этапов:

• План и подготовка
• Провести оценку на месте
• Отчет о результатах

Действия для плана и подготовительного этапа включают в себя –

• Определите область оценки
• Разработать план оценки
• Подготовить и обучить оценочную команду
• Сделайте краткую оценку участникам
• Администрирование оценочной анкеты CMMI
• Изучите ответы на анкету
• Провести первоначальный обзор документа

Мероприятия для этапа оценки на месте включают в себя –

• Провести встречу открытия
• Проводить интервью
• Консолидировать информацию
• Подготовить презентацию проекта выводов
• Представить проект выводов
• Объединить, оценить и подготовить окончательные выводы

Мероприятия на этапе представления отчетности включают в себя:

• Представьте окончательные результаты
• Провести исполнительную сессию
• Завершите оценку

Гарантия качества

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

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

Цели деятельности SQA

Цели деятельности SQA заключаются в следующем –

В разработке программного обеспечения (процессно-ориентированный)

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

• Обеспечение приемлемого уровня уверенности в том, что программное обеспечение будет соответствовать управленческому планированию и бюджетным требованиям.

• Инициирование и управление деятельностью по улучшению и повышению эффективности разработки программного обеспечения и деятельности SQA.

Обеспечение приемлемого уровня уверенности в том, что программное обеспечение будет соответствовать функциональным техническим требованиям.

Обеспечение приемлемого уровня уверенности в том, что программное обеспечение будет соответствовать управленческому планированию и бюджетным требованиям.

Инициирование и управление деятельностью по улучшению и повышению эффективности разработки программного обеспечения и деятельности SQA.

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

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

• Обеспечение с приемлемым уровнем уверенности в том, что деятельность по сопровождению программного обеспечения будет соответствовать управленческому планированию и бюджетным требованиям.

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

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

Обеспечение с приемлемым уровнем уверенности в том, что деятельность по сопровождению программного обеспечения будет соответствовать управленческому планированию и бюджетным требованиям.

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

Организация для обеспечения качества

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

Менеджеры

• Руководители высшего звена, особенно руководители, непосредственно отвечающие за обеспечение качества программного обеспечения

• Руководители отдела разработки и сопровождения программного обеспечения

• Менеджеры отдела тестирования программного обеспечения

• Менеджеры проектов и руководители команд разработки и сопровождения проектов

• Лидеры команд тестирования программного обеспечения

Руководители высшего звена, особенно руководители, непосредственно отвечающие за обеспечение качества программного обеспечения

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

Менеджеры отдела тестирования программного обеспечения

Менеджеры проектов и руководители команд разработки и сопровождения проектов

Лидеры команд тестирования программного обеспечения

Тестеры

• Члены команд тестирования программного обеспечения

Специалисты SQA и заинтересованные практики –

• SQA попечители
• Члены комитета SQA
• Участники форума SQA
• Члены команды подразделения SQA

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

Роль менеджмента в QA

По сути, в организациях по разработке программного обеспечения существует трехуровневая структура управления –

• Высшее руководство
• Управление отделом
• Управление проектом

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

Ниже приведены обязанности высшего руководства по обеспечению качества программного обеспечения.

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

• Сообщите о важности качества продукции и услуг в дополнение к удовлетворенности клиентов сотрудникам на всех уровнях.

• Обеспечить удовлетворительное функционирование и полное соответствие требованиям заказчика

• Убедитесь, что цели качества установлены для системы SQA организации и что ее цели достигнуты

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

• Вмешиваться напрямую для поддержки разрешения кризисных ситуаций и минимизации ущерба

• Обеспечить доступность ресурсов, необходимых для систем SQA

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

Сообщите о важности качества продукции и услуг в дополнение к удовлетворенности клиентов сотрудникам на всех уровнях.

Обеспечить удовлетворительное функционирование и полное соответствие требованиям заказчика

Убедитесь, что цели качества установлены для системы SQA организации и что ее цели достигнуты

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

Вмешиваться напрямую для поддержки разрешения кризисных ситуаций и минимизации ущерба

Обеспечить доступность ресурсов, необходимых для систем SQA

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

• Создание и обновление политики качества программного обеспечения организации.

• Назначение одного из руководителей, таких как вице-президент по SQA, ответственным за вопросы качества программного обеспечения

• Проведение регулярных управленческих обзоров производительности по вопросам качества программного обеспечения

Создание и обновление политики качества программного обеспечения организации.

Назначение одного из руководителей, таких как вице-президент по SQA, ответственным за вопросы качества программного обеспечения

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

Политика качества программного обеспечения

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

• Соответствие цели и задачам организации

• Приверженность общим концепциям обеспечения качества программного обеспечения

• Приверженность стандартам качества, принятым организацией

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

• Стремление к постоянному улучшению качества и производительности организации

Соответствие цели и задачам организации

Приверженность общим концепциям обеспечения качества программного обеспечения

Приверженность стандартам качества, принятым организацией

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

Стремление к постоянному улучшению качества и производительности организации

Ответственный за качество программного обеспечения

Обязанности исполнительного директора, отвечающего за вопросы качества программного обеспечения, можно классифицировать как –

• Ответственность за подготовку ежегодной программы мероприятий и бюджета SQA

• Ответственность за подготовку планов развития системы SQA

• Общий контроль за выполнением ежегодной программы регулярных мероприятий SQA и запланированных проектов развития SQA

• Презентация и пропаганда вопросов SQA для исполнительного руководства

Ответственность за подготовку ежегодной программы мероприятий и бюджета SQA

Ответственность за подготовку планов развития системы SQA

Общий контроль за выполнением ежегодной программы регулярных мероприятий SQA и запланированных проектов развития SQA

Презентация и пропаганда вопросов SQA для исполнительного руководства

Ответственность за подготовку ежегодной программы мероприятий SQA

Это требует исполнительной власти –

• Установить цели системы SQA на предстоящий год

• Рассмотреть предложения, подготовленные отделом SQA для ежегодной программы мероприятий, и проверить потенциал предложения для достижения целей, установленных для системы SQA.

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

• Определить достаточность рабочей силы и других ресурсов, запланированных для реализации программы SQA

• Утвердить окончательный вариант годовой программы мероприятий и бюджета SQA.

Установить цели системы SQA на предстоящий год

Рассмотреть предложения, подготовленные отделом SQA для ежегодной программы мероприятий, и проверить потенциал предложения для достижения целей, установленных для системы SQA.

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

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

Утвердить окончательный вариант годовой программы мероприятий и бюджета SQA.

Ответственность за подготовку планов развития системы SQA

Эти планы должны быть адаптированы к изменениям в технологии, а также требованиям клиентов и конкуренции. В обязанности входит –

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

• Рассмотреть предложения по адаптации SQA, таким как подготовка новых процедур, соответствующих новым инструментам и стандартам SQA.

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

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

• Утверждение окончательной версии запланированных проектов развития SQA, включая их графики и бюджеты.

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

Рассмотреть предложения по адаптации SQA, таким как подготовка новых процедур, соответствующих новым инструментам и стандартам SQA.

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

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

Утверждение окончательной версии запланированных проектов развития SQA, включая их графики и бюджеты.

Общий контроль выполнения годовой программы SQA

Ответственный исполнитель несет ответственность за:

• Общий надзор за ежегодной программой мероприятий

• Обзор хода реализации адаптационных проектов SQA

• Общий надзор за действиями, предпринимаемыми для реализации качественных достижений, продиктованных целями команд (на основе периодических отчетов)

• Проверка соответствия процедурам и стандартам SQA на основе внутренних аудитов качества

• Общее отслеживание соблюдения графиков и бюджетов проектов разработки программного обеспечения

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

Общий надзор за ежегодной программой мероприятий

Обзор хода реализации адаптационных проектов SQA

Общий надзор за действиями, предпринимаемыми для реализации качественных достижений, продиктованных целями команд (на основе периодических отчетов)

Проверка соответствия процедурам и стандартам SQA на основе внутренних аудитов качества

Общее отслеживание соблюдения графиков и бюджетов проектов разработки программного обеспечения

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

Презентация и пропаганда вопросов SQA для исполнительного руководства

Для повышения качества и устранения трудностей системы SQA требуется:

• Презентация для окончательного утверждения предлагаемой годовой программы мероприятий и бюджета

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

• Инициирование и руководство периодическими совещаниями управленческого анализа, посвященными качеству программного обеспечения организации.

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

Презентация для окончательного утверждения предлагаемой годовой программы мероприятий и бюджета

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

Инициирование и руководство периодическими совещаниями управленческого анализа, посвященными качеству программного обеспечения организации.

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

Ответственность руководства департамента за SQA

Обязанности среднего звена по обеспечению качества включают в себя:

• Управление системой менеджмента качества программного обеспечения (задачи, связанные с системой качества)

• Управление задачами, связанными с проектами и услугами, выполняемыми группами или командами под руководством конкретного менеджера (задачи, связанные с проектами)

Управление системой менеджмента качества программного обеспечения (задачи, связанные с системой качества)

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

Обязанности, связанные с системой качества

К ним относятся действия SQA, которые должны выполняться на уровне отдела –

• Подготовка годовой программы и бюджета SQA для отдела на основе рекомендованной программы, подготовленной подразделением SQA

• Подготовка планов развития систем SQA департамента на основе рекомендованного плана, подготовленного подразделением SQA

• Контроль за выполнением ежегодной программы деятельности SQA отдела и проектов развития

• Представление вопросов SQA отдела высшему руководству

Подготовка годовой программы и бюджета SQA для отдела на основе рекомендованной программы, подготовленной подразделением SQA

Подготовка планов развития систем SQA департамента на основе рекомендованного плана, подготовленного подразделением SQA

Контроль за выполнением ежегодной программы деятельности SQA отдела и проектов развития

Представление вопросов SQA отдела высшему руководству

Обязанности, связанные с проектом

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

• Контроль за соблюдением процедур обеспечения качества в подразделениях департамента, включая органы CAB, SCM и SCCA

• Подробное отслеживание результатов рассмотрения контракта и согласования предложений

• Проверка эффективности выполнения запланированных мероприятий; утверждение проектной документации и завершение фазы проекта

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

• Отслеживание хода выполнения графиков проектов по разработке программного обеспечения и бюджетных отклонений

• Консультирование и поддержка руководителей проектов в решении проблем с графиком, бюджетом и отношениями с клиентами

• Контроль качества предоставления сервисных услуг

• Подробное отслеживание рисков проекта и их решения

• Отслеживание соответствия проекта требованиям заказчика и удовлетворенности потребителя

• Утверждение крупных заказов на изменение программного обеспечения и существенных отклонений от спецификаций проекта

Контроль за соблюдением процедур обеспечения качества в подразделениях департамента, включая органы CAB, SCM и SCCA

Подробное отслеживание результатов рассмотрения контракта и согласования предложений

Проверка эффективности выполнения запланированных мероприятий; утверждение проектной документации и завершение фазы проекта

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

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

Консультирование и поддержка руководителей проектов в решении проблем с графиком, бюджетом и отношениями с клиентами

Контроль качества предоставления сервисных услуг

Подробное отслеживание рисков проекта и их решения

Отслеживание соответствия проекта требованиям заказчика и удовлетворенности потребителя

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

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

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

Его задачи включают профессиональные практические и управленческие задачи, в частности следующие:

• Профессиональные практические задания

  • Подготовка проекта и планов качества и их обновления

  • Участие в совместном комитете заказчик-поставщик

  • Тщательное наблюдение за персоналом проектной команды, включая участие в подборе, обучении и обучении

• Задачи управления

  Руководители проектов решают следующие вопросы, такие как –

  • Выполнение проверок и последующие исправления

  • Деятельность подразделения по разработке и сопровождению программного обеспечения, а также деятельность по интеграции и тестированию системы, а также исправления и регрессионные тесты

  • Выполнение приемочных испытаний

  • Установка программного обеспечения на удаленных клиентских сайтах и ​​выполнение программного обеспечения клиентом.

  • SQA обучение и инструктаж членов проектной команды

  • Графики и ресурсы, выделенные для деятельности по проекту

  • Запросы клиентов и удовлетворение

  • Развивающиеся риски развития проекта, применение решений и контроль результатов

Профессиональные практические задания

Подготовка проекта и планов качества и их обновления

Участие в совместном комитете заказчик-поставщик

Тщательное наблюдение за персоналом проектной команды, включая участие в подборе, обучении и обучении

Задачи управления

Руководители проектов решают следующие вопросы, такие как –

Выполнение проверок и последующие исправления

Деятельность подразделения по разработке и сопровождению программного обеспечения, а также деятельность по интеграции и тестированию системы, а также исправления и регрессионные тесты

Выполнение приемочных испытаний

Установка программного обеспечения на удаленных клиентских сайтах и ​​выполнение программного обеспечения клиентом.

SQA обучение и инструктаж членов проектной команды

Графики и ресурсы, выделенные для деятельности по проекту

Запросы клиентов и удовлетворение

Развивающиеся риски развития проекта, применение решений и контроль результатов

SQA Unit

Структура подразделения SQA варьируется в зависимости от типа и размера организации. На следующем рисунке показан пример стандартной структуры и всех компонентов блока SQA. В этой главе мы обсудим роли и обязанности каждого подразделения.

Задачи, выполняемые начальником отдела SQA

Руководитель подразделения SQA отвечает за все задачи обеспечения качества, выполняемые подразделением SQA и его подразделениями. Эти задачи можно разделить на следующие категории –

• Планирование задач
• Управление подразделением
• SQA профессиональная деятельность

Планирование задач

• Подготовка предлагаемой годовой программы деятельности и бюджета для подразделения

• Планирование и обновление системы управления качеством программного обеспечения организации

• Подготовка рекомендуемых ежегодных программ мероприятий SQA и планов развития систем SQA для отделов разработки и обслуживания программного обеспечения

Подготовка предлагаемой годовой программы деятельности и бюджета для подразделения

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

Подготовка рекомендуемых ежегодных программ мероприятий SQA и планов развития систем SQA для отделов разработки и обслуживания программного обеспечения

Задачи управления

• Управление деятельностью команды SQA

• Мониторинг реализации программы деятельности SQA

• Назначение членов команды, членов комитета SQA и попечителей SQA

• Подготовка специальных и периодических отчетов, например, о состоянии проблем с качеством программного обеспечения в организации и ежемесячных отчетах о производительности

Управление деятельностью команды SQA

Мониторинг реализации программы деятельности SQA

Назначение членов команды, членов комитета SQA и попечителей SQA

Подготовка специальных и периодических отчетов, например, о состоянии проблем с качеством программного обеспечения в организации и ежемесячных отчетах о производительности

SQA Профессиональная деятельность

• Участие в совместных проектных комитетах
• Участие в официальных обзорах дизайна
• Рассмотрение и утверждение отклонений от спецификаций
• Консультация с менеджерами проектов и руководителями команд
• Участие в комитетах и ​​форумах SQA

Проект жизненного цикла SQA

Задачи SQA, относящиеся к подразделу жизненного цикла проекта, можно разделить на две группы:

• «Чистые» управленческие задачи контроля и одобрения (задачи управления жизненным циклом проекта)

• «Практическое занятие» или активное участие в деятельности SQA команды проекта, где требуется профессиональный вклад (задачи участия)

«Чистые» управленческие задачи контроля и одобрения (задачи управления жизненным циклом проекта)

«Практическое занятие» или активное участие в деятельности SQA команды проекта, где требуется профессиональный вклад (задачи участия)

Задачи управления жизненным циклом проекта

• Отслеживание соответствия команды разработчиков и сопровождения процедурам SQA и рабочим инструкциям

• Утверждение или рекомендация программных продуктов согласно соответствующим процедурам

• Контроль за предоставлением услуг по сопровождению программного обеспечения внутренним и внешним клиентам

• Мониторинг удовлетворенности клиентов и поддержание контактов с представителями по обеспечению качества клиентов

Отслеживание соответствия команды разработчиков и сопровождения процедурам SQA и рабочим инструкциям

Утверждение или рекомендация программных продуктов согласно соответствующим процедурам

Контроль за предоставлением услуг по сопровождению программного обеспечения внутренним и внешним клиентам

Мониторинг удовлетворенности клиентов и поддержание контактов с представителями по обеспечению качества клиентов

Задачи участия

Эти задачи включают участие в –

• Контрактные обзоры
• Подготовка и обновление планов развития проекта и качества
• Формальные дизайнерские обзоры
• Официальные обзоры дизайна субподрядчиков
• Тестирование программного обеспечения, включая приемочные тесты
• Приемочные испытания программного обеспечения субподрядчиков
• Установка новых программных продуктов

Операционные задачи инфраструктуры SQA

Системы SQA используют различные компоненты инфраструктуры для бесперебойной работы, а именно:

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

Более конкретно, задачи подразделения SQA относительно этих компонентов включают в себя:

• Публикация обновленных версий процедур, рабочих инструкций, шаблонов, контрольных списков и т. Д. Вместе с их распространением в печатном виде и / или электронными средствами.

• Передача обучения и инструкций относительно соблюдения и применения процедур SQA, рабочих инструкций и аналогичных предметов для нового и текущего персонала

• Инструкция попечителей SQA относительно новых и пересмотренных процедур, а также инструментов и методов разработки, среди других компонентов

• Мониторинг и поддержка внедрения новых и пересмотренных процедур SQA

• Последующие мероприятия по сертификации персонала

• Предложение вопросов, требующих профилактических и корректирующих действий, включая участие в комитетах CAB

• Последующие действия по управлению конфигурацией, включая участие в комитетах CCA

• Контроль за соблюдением процедур документирования и рабочих инструкций

Публикация обновленных версий процедур, рабочих инструкций, шаблонов, контрольных списков и т. Д. Вместе с их распространением в печатном виде и / или электронными средствами.

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

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

Мониторинг и поддержка внедрения новых и пересмотренных процедур SQA

Последующие мероприятия по сертификации персонала

Предложение вопросов, требующих профилактических и корректирующих действий, включая участие в комитетах CAB

Последующие действия по управлению конфигурацией, включая участие в комитетах CCA

Контроль за соблюдением процедур документирования и рабочих инструкций

Задачи внутреннего аудита и сертификации SQA

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

• Внутренние аудиты

• Аудиты субподрядчиков и поставщиков для оценки их систем SQA

• Внешние аудиты, проводимые органами по сертификации

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

Внутренние аудиты

Аудиты субподрядчиков и поставщиков для оценки их систем SQA

Внешние аудиты, проводимые органами по сертификации

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

Первые два класса проверок инициируются и выполняются подразделением SQA, последние два – внешними органами.

Блок SQA выполняет следующие задачи для внутренних аудитов SQA

• Подготовка годовых программ для внутренних аудитов SQA

• Проведение внутренних аудитов SQA

• Последующие исправления и улучшения, которые должны быть выполнены проверенными командами и другими подразделениями

• Подготовка периодических сводных отчетов о состоянии результатов аудита, включая рекомендации по улучшению

Подготовка годовых программ для внутренних аудитов SQA

Проведение внутренних аудитов SQA

Последующие исправления и улучшения, которые должны быть выполнены проверенными командами и другими подразделениями

Подготовка периодических сводных отчетов о состоянии результатов аудита, включая рекомендации по улучшению

Подразделение SQA выполняет следующие задачи для аудитов субподрядчиков и поставщиков –

• Подготовка годовой программы аудита SQA субподрядчиков и поставщиков

• Проведение SQA аудитов субподрядчиков и поставщиков

• Последующие исправления и улучшения должны выполняться проверенными субподрядчиками и поставщиками

• Сбор данных о работе субподрядчиков и поставщиков из внутренних и внешних источников

• Периодическая оценка систем SQA сертифицированных субподрядчиков и поставщиков организации на основе аудиторских отчетов и информации, полученной из других внутренних и внешних источников. Отчет об оценке включает в себя –

  • Рекомендации по сертификации субподрядчиков и поставщиков

  • Внешние аудиты, проводимые органами по сертификации, включают следующие задачи:

    • Согласование содержания и графика сертификационного аудита

    • Подготовка документов, указанных органами по сертификации

    • Инструктирование проверенных команд и выполнение подготовительных работ, необходимых для сертификационных аудитов

    • Участие в сертификационных аудитах

    • Убедитесь, что необходимые исправления и улучшения выполнены

Подготовка годовой программы аудита SQA субподрядчиков и поставщиков

Проведение SQA аудитов субподрядчиков и поставщиков

Последующие исправления и улучшения должны выполняться проверенными субподрядчиками и поставщиками

Сбор данных о работе субподрядчиков и поставщиков из внутренних и внешних источников

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

Рекомендации по сертификации субподрядчиков и поставщиков

Внешние аудиты, проводимые органами по сертификации, включают следующие задачи:

Согласование содержания и графика сертификационного аудита

Подготовка документов, указанных органами по сертификации

Инструктирование проверенных команд и выполнение подготовительных работ, необходимых для сертификационных аудитов

Участие в сертификационных аудитах

Убедитесь, что необходимые исправления и улучшения выполнены

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

• Согласование содержания и графика аудита

• Подготовка документов, указанных аудитором заказчика

• Обучение проверенных команд и выполнение подготовительных мероприятий, необходимых для аудитов SQA, клиентами организации.

• Участие в аудитах

• Убедитесь, что необходимые исправления и улучшения выполнены

Согласование содержания и графика аудита

Подготовка документов, указанных аудитором заказчика

Обучение проверенных команд и выполнение подготовительных мероприятий, необходимых для аудитов SQA, клиентами организации.

Участие в аудитах

Убедитесь, что необходимые исправления и улучшения выполнены

Задачи поддержки SQA

Большинство потребителей услуг поддержки SQA находятся внутри организации. Они включают руководителей проектов, руководителей команд и попечителей SQA. Их задачи включают в себя –

• Подготовка планов проекта и планов качества проекта

• Штатные обзорные бригады

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

• Выбор мер для устранения задержек в графике и превышения бюджета

• Выбор метрик SQA и компонентов стоимости программного обеспечения

• Использование информационной системы SQA

• Выбор методологий и инструментов разработки, отражающих данные об отказах, накопленные модулем SQA

Подготовка планов проекта и планов качества проекта

Штатные обзорные бригады

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

Выбор мер для устранения задержек в графике и превышения бюджета

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

Использование информационной системы SQA

Выбор методологий и инструментов разработки, отражающих данные об отказах, накопленные модулем SQA

SQA Стандарты и процедуры Задачи

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

• Подготовить годовую программу для разработки новых процедур и процедур обновления

• Отвечать за разработку новых процедур и обновлений процедур с участием в соответствующих комитетах и ​​форумах.

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

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

Подготовить годовую программу для разработки новых процедур и процедур обновления

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

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

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

SQA Инженерные задачи

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

Следовательно, основные инженерные задачи включают в себя следующее –

• Тестирование аспектов качества и производительности в отношении новых инструментов разработки и новых версий используемых в настоящее время инструментов разработки

• Оценка качества и производительности новых методов разработки и сопровождения и улучшения методов

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

• Разработка методов измерения качества программного обеспечения и производительности команды

• Оказание технологической поддержки комитетам CAB при анализе сбоев разработки программного обеспечения и разработке предлагаемых решений.

Тестирование аспектов качества и производительности в отношении новых инструментов разработки и новых версий используемых в настоящее время инструментов разработки

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

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

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

Оказание технологической поддержки комитетам CAB при анализе сбоев разработки программного обеспечения и разработке предлагаемых решений.

Задачи SQA Information Systems

Информационные системы SQA предназначены для облегчения и улучшения функционирования систем SQA. Задачи включают в себя –

• Разработка информационных систем SQA для подразделений по разработке и сопровождению программного обеспечения для

  • сбор данных о деятельности

  • обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

  • обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

• Разработка информационных систем SQA, облегчающих обработку блоком SQA информации, предоставляемой блоками разработки и обслуживания программного обеспечения, включая оценки показателей качества программного обеспечения и затрат на качество программного обеспечения

• Обновление информационных систем SQA

• Разработка и поддержка сайта организации SQA Internet / Intranet

Разработка информационных систем SQA для подразделений по разработке и сопровождению программного обеспечения для

сбор данных о деятельности

обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

обработка, например, периодических отчетов, списков, отчетов об исключениях и запросов

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

Обновление информационных систем SQA

Разработка и поддержка сайта организации SQA Internet / Intranet

SQA попечители и их задачи

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

Их задачи могут варьироваться в зависимости от организации. Соответственно, это могут быть задачи, связанные с подразделениями и / или организацией.

Задачи, связанные с юнитами

• Поддержка коллег в решении трудностей при внедрении процедур качества программного обеспечения и рабочих инструкций

• Помогите руководителю подразделения в выполнении связанных задач SQA

• Содействовать соблюдению и контролировать выполнение процедур SQA и рабочих инструкций коллегами

• Сообщать о существенных и систематических событиях несоблюдения в отдел SQA

• Сообщить о серьезных сбоях качества программного обеспечения в блок SQA

Поддержка коллег в решении трудностей при внедрении процедур качества программного обеспечения и рабочих инструкций

Помогите руководителю подразделения в выполнении связанных задач SQA

Содействовать соблюдению и контролировать выполнение процедур SQA и рабочих инструкций коллегами

Сообщать о существенных и систематических событиях несоблюдения в отдел SQA

Сообщить о серьезных сбоях качества программного обеспечения в блок SQA

Задачи, связанные с организацией

• Инициировать изменения и обновления общеорганизационных процедур SQA и рабочих инструкций

• Триггерные улучшения процессов разработки и сопровождения в организации

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

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

Инициировать изменения и обновления общеорганизационных процедур SQA и рабочих инструкций

Триггерные улучшения процессов разработки и сопровождения в организации

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

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

Комитеты SQA и их задачи

Комитеты SQA могут быть постоянными или специальными. Задачи могут значительно отличаться от организации к организации.

• Постоянные комитеты обычно имеют дело с SCC (Software Change Control), CA (корректирующие действия), процедурами, инструментами разработки методов и показателями качества.

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

Постоянные комитеты обычно имеют дело с SCC (Software Change Control), CA (корректирующие действия), процедурами, инструментами разработки методов и показателями качества.

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

Постоянные комитеты SQA являются неотъемлемой частью организационной структуры SQA; их задачи и деятельность обычно определяются в процедурах SQA организации.

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

Как встроить качество в процессы производства ПО?

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

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

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

Что же такое качество?

Для начала давайте определимся что же такое качество? Как гарантировать качество? Как его контролировать и управлять? 

Существует множество международных стандартов, таких как ISO9000, ISO9126 (был заменен ISO/IEC 25010:2011) и т.д., которые дают некоторые определения качеству и процессам.

Так, к примеру согласно ISO9000. Качество — это степень соответствия совокупности присущих характеристик объекта требованиям.

Хмм…Окей. Выглядит заумно. Как насчет программного обеспечения? На это отвечает стандарт ISO 9126.

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

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

• Весь объём признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым требованиям.

• Степень, в которой система, компонент или процесс удовлетворяют требованиям или ожиданиям заказчика или пользователя.

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

Согласно тому же стандарту ISO9126 качество программного обеспечения имеет внутренние и внешние характеристики. Каждая характеристика детализируется субхарактеристиками.

К внешним характеристика качества относятся:

• Функциональность (Functionality) — Набор атрибутов, которые влияют на существование набора функций и их заданных свойств. Функции — это характеристики ПО, которые удовлетворяют заявленные или подразумеваемые потребности.

• Надежность (Reliability) — Набор атрибутов, которые влияют на способность программного обеспечения поддерживать свой уровень производительности при указанных условиях в течение указанного периода времени.

• Юзабилити (Usability) — Набор атрибутов, которые влияют на усилия, необходимые для использования, и на индивидуальную оценку такого использования заявленным или подразумеваемым набором пользователей.

• Эффективность (Efficiency) — Набор атрибутов, которые влияют на взаимосвязь между уровнем производительности программного обеспечения и количеством используемых ресурсов при указанных условиях

• Портируемость (Portability) — Набор атрибутов, влияющих на возможность передачи программного обеспечения из одной среды в другую.

К внутренним качествам относятся:

• Сопровождаемость (Maintainability) — Набор атрибутов, влияющих на усилия, необходимые для внесения определённых изменений.

• Тестируемость (Testability) — Набор атрибутов, влияющих на усилия, необходимые для проверки программного обеспечения после проведения какого-либо видоизменения.

Данные семь характеристик достаточны для того, чтобы программное обеспечение считалось качественным.

Но как гарантировать качество? Как контролировать и управлять? Какие процессы отвечают за это?

Но как гарантировать качество?

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

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

Quality Management (QM) или управление качеством — это процесс наблюдения за всеми действиями и задачами, необходимыми для поддержания желаемого уровня качества. Управление качеством включает определение политики качества, создание и реализацию планирования и обеспечения качества (QA), а также контроль качества (QC) и улучшения качества. Управление качеством требует, чтобы все заинтересованные стороны бизнеса работали вместе надо улучшением процессов, продуктов, услуг и культуры самой компании.

Обеспечение качества (QA) — это часть управления качеством, направленная на обеспечении уверенности (гарантированности) в том, что требования к качеству будут выполнены.

Управление качеством (QC) — это рабочие методы и активности, нацеленные на выполнение требований к качеству.

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

Как видно между QA, QC и тестированием есть разница. Да, они об одном и том же — о качестве, но работают с ним с разных уровней.

Так, QA задействован в процессе верификации и позволяет получить ответ на вопрос — Создаю ли я продукт правильно? У QA ориентация на процессы и их постоянное улучшение. Поэтому QA это проактивный процесс, направленный на предотвращение дефектов путем постепенного совершенствования производственных процессов, политик и процедур. QA отвечает за разработку стандартов и методологий, аудит, обучение и т.д.

А вот QC задействован в процессе валидации и позволяет получить ответ на вопрос — Создаю ли я правильный продукт? В отличии от QA, QC ориентирован на продукт и является реактивным процессом, который направлен на эффективное выявление дефектов в программном обеспечении до релиза и отправки клиентам. QC следует стандартам и регламентам, методологиям, за которые отвечает QA.

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

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

• Что такое обеспечение качества программного обеспечения?

Что такое обеспечение качества программного обеспечения?

• Software Quality Assurance (SQA) — это комплекс мероприятий для обеспечения качества разрабатываемого программного обеспечения. Исследования показали, что 98% проектов в конце концов провалились на рынке из-за следующих причин, таких как расчетное время, изменение требований, более высокая стоимость, чем ожидалось, или высокая стоимость обслуживания. Поэтому очень важно помнить о различных параметрах перед разработкой программного обеспечения, чтобы минимизировать риск сбоя.
• Чтобы минимизировать риск сбоя программного обеспечения на рынке, обеспечение качества программного обеспечения вошло в картину.
• Он включает в себя набор действий, процессов, процедур и стандартов, которые подходят для проекта. Он охватывает все стандарты качества программного обеспечения от сбора требований до его разработки, выпуска и обслуживания.
• SQA работает параллельно с жизненным циклом разработки программного обеспечения, который регулярно проверяет, что разрабатываемое программное обеспечение должно соответствовать его стандартам на каждом этапе, чтобы проблемы можно было предотвратить на ранних этапах, а не решать их после завершения проекта.
• SQA включает Аудит, Обучение, Определение процесса и Внедрение в качестве основных видов деятельности. Как только процесс определен, SQA начинает находить в нем слабые места и способы их устранения для улучшения программного обеспечения.

Деятельность по обеспечению качества программного обеспечения

Ниже приведены некоторые виды деятельности по обеспечению качества программного обеспечения.

1. Установка контрольной точки

Команда SQA устанавливает контрольные точки через определенные промежутки времени, чтобы проверить ход, качество, производительность программного обеспечения и то, выполняется ли работа по качеству программного обеспечения вовремя согласно графику и документам.

2. Измерьте влияние изменения

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

3. Наличие нескольких стратегий тестирования

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

4. Ведение записей и отчетов

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

5. Управление хорошими отношениями

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

6. План управления SQA

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

Компоненты системы SQA

Компоненты SQA можно разделить на 6 классов:

1. Предпроектные компоненты

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

2. Компоненты жизненного цикла проекта программного обеспечения

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

3. Компоненты инфраструктуры для предотвращения ошибок и улучшения

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

4. Управление SQA Компоненты

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

5. Компоненты стандартизации, сертификации и оценки системы SQA

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

6. Организация для SQA Human Components

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

Стандарты обеспечения качества программного обеспечения

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

1. IEEE
2. DOT
3. ISO
4. ANSI
5. EIA
6. IEC

Стандарты SQA в основном делятся на две категории:

1. Стандарт обеспечения качества программного обеспечения, известный как Стандарты управления качеством.

Пример: ISO 9000-3, CMM (модель зрелости возможностей).

Они сосредоточены на инфраструктуре организации, системе SQA, требованиях, оставляя выбор инструментов и методов тестирования для организации. Их стандартная цель — «чего» достичь. Это гарантирует, что организации достигают приемлемого качества программного обеспечения.

2. Стандарты процесса разработки программного обеспечения, известные как стандарты процесса проекта.

Пример: ISO / IEC 12207 IEEEStd 1012-1998.

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

SQA Techniques

Есть несколько методов SQA. Некоторые из них упомянуты ниже:

1. Рецензирование

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

2. Аудит

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

3. Функциональное тестирование

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

4. Стандартизация

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

5. Проверка кода

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

6. Прохождение

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

7. Стресс-тестирование

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

8. Проверка конструкции

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

Преимущества SQA

Давайте обсудим преимущества SQA.

1. Увеличивает доверие клиента

Надлежащая проверка качества на разных уровнях программного обеспечения, таких как проверка, проверка, аудит и т. Д., А также с привлечением как внутренних, так и внешних заинтересованных сторон повышает доверие клиентов к представлению еженедельных отчетов о дефектах и ​​метриках требований, также очень помогает в обеспечении клиент, что работа выполняется вовремя.

2. SQA экономит деньги

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

3. Повысить удовлетворенность клиентов

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

4. Повышает производительность и эффективность

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

5. Предотвращает от непредвиденных чрезвычайных ситуаций

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

6. Уменьшает время окончания клиентских конфликтов

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

Недостатки SQA

Давайте обсудим недостатки SQA.

1. Иногда сложно реализовать

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

2. Отнимает много времени

Реализация каждого действия в SQA занимает очень много времени, а иногда тратит больше времени на документирование и встречи, а не на саму разработку и тестирование программного обеспечения.

3. Высокая стоимость

Благодаря внедрению SQA, хотя стоимость исправления ошибок на более поздних этапах может быть уменьшена путем их обнаружения и исправления только в начале, но для небольших проектов с низким бюджетом очень трудно внедрить SQA, так как количество ресурсов увеличивается. проект так же, как и бюджет проекта. Для небольших проектов найм всей команды QA и внедрение SQA приводят к резкому увеличению стоимости проекта.

Вывод

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

Рекомендуемые статьи

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

1. Принципы тестирования программного обеспечения
2. Жизненный цикл тестирования программного обеспечения
3. Agile Software
4. Обеспечение качества против контроля качества
5. Методы испытаний черного ящика

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)

Соседние файлы в папке Книги

• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

Стандарты качества программного обеспечения

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

1. ISO/IEC 25000 — Стандарт, который определяет модели качества программного обеспечения. Он включает в себя набор требований и рекомендаций, которые помогают разработчикам и тестировщикам оценить и улучшить качество своих продуктов.
2. ISO/IEC 9126 — Стандарт, который определяет качественные характеристики программного обеспечения и соответствующие им метрики. Он включает в себя такие характеристики, как функциональность, надежность, удобство использования, эффективность, сопровождаемость и переносимость.
3. ISO/IEC 12207 — Стандарт, который описывает жизненный цикл программного обеспечения. Он включает в себя такие этапы, как разработка, тестирование, управление конфигурацией, сопровождение и др.
4. IEEE 829 — Стандарт, который определяет требования к документации тестирования программного обеспечения. Он включает в себя такие документы, как план тестирования, протоколы тестирования, отчеты об ошибках и т.д.
5. CMMI — Модель, которая описывает процессы разработки и сопровождения программного обеспечения. Она включает в себя 5 уровней зрелости, которые отражают степень организованности и эффективности процессов в компании.
6. ITIL — Руководство по управлению информационной технологией, которое описывает процессы управления ИТ-сервисами. Оно включает в себя такие процессы, как управление инцидентами, проблемами, изменениями, конфигурацией и т.д.

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

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

Характеристики качества программного обеспечения являются важной составляющей оценки и улучшения качества ПО. Некоторые из основных характеристик качества программного обеспечения включают в себя:

1. Функциональность — способность ПО выполнять необходимые функции и соответствовать требованиям пользователя. Функциональность может быть измерена с помощью тестирования функциональности.
2. Надежность — способность ПО работать стабильно и предсказуемо в различных условиях. Надежность может быть измерена с помощью тестирования стабильности и надежности ПО.
3. Эффективность — способность ПО выполнять свои функции быстро и с минимальным использованием ресурсов. Эффективность может быть измерена с помощью тестирования производительности.
4. Удобство использования — способность ПО быть легким в использовании для конечного пользователя. Удобство использования может быть измерено с помощью тестирования пользовательского интерфейса и UX-тестирования.
5. Сопровождаемость — способность ПО быть легко изменяемым и сопровождаемым после его выпуска. Сопровождаемость может быть измерена с помощью тестирования обновлений и модификаций ПО.
6. Совместимость — способность ПО работать с другими системами и программным обеспечением. Совместимость может быть измерена с помощью тестирования совместимости.
7. Безопасность — способность ПО защищать данные и систему от внешних угроз. Безопасность может быть измерена с помощью тестирования безопасности и аудита безопасности.
8. Поддерживаемость — способность ПО быть поддерживаемым и обслуживаемым с помощью документации и справочной информации. Поддерживаемость может быть измерена с помощью тестирования документации и руководства пользователя.

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

Как делают упор на качество в больших компаниях

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

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

Кроме того, Microsoft активно использует автоматизированное тестирование, что позволяет более быстро и точно выявлять ошибки в коде. Для этого используются различные инструменты и технологии, такие как Visual Studio и Azure DevOps.

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

Adobe System: качество программного обеспечения в приоритете

Adobe Systems известна своими программными продуктами, такими как Adobe Photoshop, Adobe Illustrator, Adobe Acrobat и многими другими. Они делают упор на высокое качество программного обеспечения, и это одна из основных причин их успеха на рынке.

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

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

В целом, Adobe Systems является примером компании, которая делает упор на качество программного обеспечения, и это помогает им держаться на вершине индустрии и удерживать лояльность своих клиентов.

Вместо заключения

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