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

Управление качеством программного обеспечения ( SQM ) — это процесс управления, целью которого является разработка и управление качеством программного обеспечения таким образом, чтобы наилучшим образом гарантировать, что продукт соответствует стандартам качества, ожидаемым клиентом, а также отвечает всем необходимым нормативным требованиям и требованиям разработчиков. если таковые имеются. ^[1]^[2]^[3]Менеджеры по качеству программного обеспечения требуют, чтобы программное обеспечение было протестировано перед его выпуском на рынок, и они делают это, используя циклическую оценку качества на основе процессов, чтобы выявить и исправить ошибки перед выпуском. Их работа заключается не только в обеспечении того, чтобы их программное обеспечение было в хорошем состоянии для потребителя, но и в поощрении культуры качества на всем предприятии. ^[1]^[2]^[3]

Деятельность по управлению качеством [ править ]

Деятельность по управлению качеством программного обеспечения обычно разделяется на три основных компонента: обеспечение качества, планирование качества и контроль качества. ^[1]^[2] Некоторые, например, инженер-программист и писатель Ян Соммервилл, не используют термин «контроль качества» (поскольку контроль качества часто рассматривается как скорее производственный термин, чем термин разработки программного обеспечения), а связывают связанные с ним понятия с концепцией обеспечения качества. ^[3] Однако в остальном три основных компонента остаются прежними.

Гарантия качества [ править ]

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

Этот этап может включать в себя:

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

Планирование качества [ править ]

Планирование качества работает на более детальном уровне, основанном на проекте, определяя атрибуты качества, которые будут связаны с результатами проекта, и то, как эти атрибуты следует оценивать. Кроме того, на этом этапе к проекту могут быть применены любые существующие организационные стандарты. Проекту разработки программного обеспечения могут быть присвоены такие атрибуты, как «надежность», «доступность» и «модульность». ^[1]^[2] Хотя это может быть более формализованный и целостный процесс, те, кто использует более гибкий метод управления качеством, могут уделять меньше внимания строгим структурам планирования. ^[3] План качества может также касаться предполагаемого рынка, критических дат выпуска, целей в области качества, ожидаемых рисков и политики управления рисками. ^[2]^[3]

Контроль качества [ править ]

Группа контроля качества тестирует и проверяет программное обеспечение на различных этапах, чтобы гарантировать соблюдение процессов и стандартов обеспечения качества как на уровне организации, так и на уровне проекта. ^[1]^[2] (Некоторые, например, Соммервилл, связывают эти обязанности с обеспечением качества, а не называют это контролем качества. ^[3]) Эти проверки оптимально проводятся отдельно от команды разработчиков, чтобы обеспечить более объективное представление о тестируемом продукте. ^[2]^[3] Однако менеджеры проектов со стороны разработки также должны оказывать помощь, помогая продвигать на этом этапе «культуру, которая обеспечивает поддержку без обвинений при обнаружении ошибок». ^[3]В фирмах по разработке программного обеспечения, применяющих более гибкий подход к обеспечению качества, эта деятельность может быть менее формальной; однако переход к гибким методам из более формальной структуры управления качеством может создать проблемы, если процедуры управления не будут соответствующим образом адаптированы. ^[3]

Мероприятия включают в себя:

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

программного жизненный цикл обеспечения Качество программного обеспечения и

Измерение качества программного обеспечения отличается от измерения качества производства; допуски неприменимы (по крайней мере, в том же смысле), а объективных выводов о том, соответствует ли программное обеспечение спецификациям, трудно, если вообще возможно, достичь. ^[3] Однако качество и пригодность программного обеспечения по-прежнему могут быть реализованы по-разному в зависимости от организации и типа реализуемого проекта. ^[4] Это достигается за счет поддержки всего жизненного цикла разработки программного обеспечения , что означает:

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

Ссылки на ИТ-методы [ править ]

Управление качеством программного обеспечения — это тема, тесно связанная с различными методами управления проектами, разработкой и эксплуатацией ИТ, включая:

Метод управления проектами PRINCE2 ^[5] определяет:

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

Метод управления проектами PMBOK 4-е издание ^[6] определяет область знаний «Управление качеством проекта» и следующие процессы:

3.4.12 Качество плана,
3.5.2. Обеспечить качество,
3.6.7. Выполнить контроль качества

Методика разработки RUP определяет дисциплину тестирования, которая проводится на всех этапах, начиная с Начального уровня и заканчивая Переходным этапом.
Метод разработки MSF определяет роль тестировщика и этап стабилизации, который фокусируется в основном на тестировании решения. ^[7]
Гибкие методы не определяют точно роль тестировщика или механизмы, связанные с управлением качеством программного обеспечения. Методы определяют только такие приемы, как непрерывная интеграция и разработка через тестирование . Тем не менее, наконец-то появилась публикация об гибком тестировании .
Операционный метод CMMI определяет, среди прочего, область процесса PPQA «Обеспечение качества процессов и продукции», которая требуется уже на уровне CMMI 2.
Операционный метод COBIT определяет, среди прочего, процесс P08 «Управление качеством».
Операционный метод ITIL определяется, среди прочего, публикацией «Постоянное улучшение обслуживания».
V-Model – модель, определяющая жизненный цикл разработки программного обеспечения и процесс тестирования.
ISO 9000 — семейство стандартов, связанных с системами управления качеством и предназначенных для того, чтобы помочь организациям обеспечить удовлетворение потребностей клиентов и других заинтересованных сторон[1], одновременно соблюдая законодательные и нормативные требования, относящиеся к продукции.

Ассоциации и организации [ править ]

Американское общество качества (ASQ) — это профессиональная организация, которая предоставляет своим членам сертификацию, обучение, публикации, конференции и другие услуги, связанные с управлением качеством, постоянным улучшением и безопасностью продукции.
Международный совет по квалификации тестировщиков программного обеспечения (ISTQBP — это некоммерческая международная ассоциация, зарегистрированная в Бельгии. Он управляет процессом сертификации тестировщиков программного обеспечения и имеет более 535 000 выданных сертификатов в более чем 120 странах. ^[8]

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

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

^ Перейти обратно: ^а ^б ^с ^д ^Это ^ж Жолт, У. (февраль 2014 г.). «Управление качеством программного обеспечения» (PDF) . Процессы разработки программного обеспечения и обеспечение качества программного обеспечения . Университет Паннонии. стр. 117–121 . Проверено 7 декабря 2017 г.
^ Перейти обратно: ^а ^б ^с ^д ^Это ^ж ^г ^час Максим, БР (2014). «Управление качеством программного обеспечения» (ППТ) . Мичиганский университет — Дирборн . Проверено 7 декабря 2017 г.
^ Перейти обратно: ^а ^б ^с ^д ^Это ^ж ^г ^час ^я ^дж ^к ^л Соммервилл, И. (2011). «Глава 24: Управление качеством». Программная инженерия (9-е изд.). Аддисон-Уэсли. стр. 651–680. ISBN 9780137035151 .
^ Келемен, З.Д. (2013). Унификация на основе процессов для улучшения процессов многомодельного программного обеспечения Эйндховен: Технологический университет Эйндховена. ISBN 978-90-386-3313-8
^ OGC (Управление государственной торговли) (2009). Управление успешными проектами с помощью PRINCE2 (изд. 2009 г.). ТСО (Канцелярский офис). ISBN 978-0-11-331059-3
^ Руководство по своду знаний по управлению проектами, четвертое издание , PMI, США, 2008 г.
^ Microsoft Solution Framework - Глава 18, этап стабилизации, дата публикации: 27 апреля 2005 г. [1]
^ «Сертификация тестировщиков программного обеспечения по всему миру» . Международный квалификационный совет по тестированию программного обеспечения . Проверено 7 декабря 2017 г.

[ZsoltSoftware14-1] Перейти обратно: ^а ^б ^с ^д ^Это ^ж Жолт, У. (февраль 2014 г.). «Управление качеством программного обеспечения» (PDF) . Процессы разработки программного обеспечения и обеспечение качества программного обеспечения . Университет Паннонии. стр. 117–121 . Проверено 7 декабря 2017 г.

[MaximSoftware14-2] Перейти обратно: ^а ^б ^с ^д ^Это ^ж ^г ^час Максим, БР (2014). «Управление качеством программного обеспечения» (ППТ) . Мичиганский университет — Дирборн . Проверено 7 декабря 2017 г.

[SommervilleSoftware11-3] Перейти обратно: ^а ^б ^с ^д ^Это ^ж ^г ^час ^я ^дж ^к ^л Соммервилл, И. (2011). «Глава 24: Управление качеством». Программная инженерия (9-е изд.). Аддисон-Уэсли. стр. 651–680. ISBN 9780137035151 .

[4] Келемен, З.Д. (2013). Унификация на основе процессов для улучшения процессов многомодельного программного обеспечения Эйндховен: Технологический университет Эйндховена. ISBN 978-90-386-3313-8

[5] OGC (Управление государственной торговли) (2009). Управление успешными проектами с помощью PRINCE2 (изд. 2009 г.). ТСО (Канцелярский офис). ISBN 978-0-11-331059-3

[6] Руководство по своду знаний по управлению проектами, четвертое издание , PMI, США, 2008 г.

[7] Microsoft Solution Framework - Глава 18, этап стабилизации, дата публикации: 27 апреля 2005 г. [1]

[ISTQBHome-8] «Сертификация тестировщиков программного обеспечения по всему миру» . Международный квалификационный совет по тестированию программного обеспечения . Проверено 7 декабря 2017 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]