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

⇐ ПредыдущаяСтр 5 из 16Следующая ⇒

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

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

– процесс обеспечения качества;

– процесс верификации;

– процесс аттестации;

– процесс совместного анализа;

– процесс аудита.

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

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

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

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

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

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

Проверка (верификация) и аттестация

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

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

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

Оценка и аудит

Оценки можно поделить на управленческие и технические:

1 Назначение управленческих оценок состоит в отслеживании развития проекта (продукта), определения статуса планов и расписаний, утверждения требования и распределения ресурсов, или оценки эффективности управленческих подходов, используемых для достижения поставленных целей. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Управленческие оценки поддерживают принятие решений о внесении изменений и выполнении корректирующих действий, необходимых в процессе выполнения программного проекта. Управленческие оценки определяют адекватность планов, расписаний и требований, в то же время, контролируя их прогресс или несоответствие. Эти оценки могут выполняться в отношении продукта, будучи фиксируемы в форме отчетов аудита, отчетов о состоянии (развитии),

2 Назначением технических оценок является исследование программного продукта для определения его пригодности для использования в надлежащих целях. Цель состоит в идентификации расхождений с утвержденными спецификациями и стандартами. [IEEE 1028-97 “IEEE Standard for Software Reviews]. Для обеспечения технических оценок необходимо распределение следующих ролей: лицо, принимающее решения, лидер оценки, регистратор, а также технический персонал, поддерживающий (непосредственно исполняющий) действия по оценке. Техническая оценка требует, в обязательном порядке, наличия следующих входных данных:

– формулировки целей;

– конкретного программного продукта (подвергаемого оценке);

– заданного плана проекта (плана управления проектом);

– списка проблем (вопросов), ассоциированных с продуктом;

– процедуры технической оценки.

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

В дополнение к оценкам ISO 12207 [”] вводит понятия инспекций, прогонок и аудитов:

1 Назначение инспекций состоит в обнаружении и идентификации аномалий в программном продукте. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Существует два серьезных отличия инспекций от оценок (управленческой и технической):

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

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

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

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

2 Назначение прогонки состоит в оценке программного продукта. Прогонка может проводиться с целью ознакомления (обучения) аудитории с программным продуктом. [IEEE 1028-97 “IEEE Standard for Software Reviews”].

Главные цели прогонки состоят (по IEEE 1028) в:

– Поиске аномалий

– Улучшении продукта

– Обсуждении альтернативных путей реализации

– Оценке соответствия стандартам и спецификациям

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

3 Назначением аудита программного обеспечения является независимая оценка программных продуктов и процессов на предмет их соответствия применимым регулирующим документам, стандартам, руководящим указаниям, планам и процедурам. [IEEE 1028-97 “IEEE Standard for Software Reviews”]. Аудит является формально организованной деятельностью, участники которой выполняют определенные роли, такие как главный аудитор, второй аудитор, регистратор и инициатор. В аудите принимает участие представитель оцениваемой организации/организационной единицы. В результате аудита идентифицируются случаи несоответствия и формируется отчет, необходимый команде разработки для принятия корректирующих действий.

Характеристика дефектов

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

Управления качеством ПС обеспечивает сбор информации на всех стадиях разработки и сопровождения программного обеспечения. Различные стандарты предполагают различное смысловое наполнение терминов, связанных с понятием «дефект». Частичные определения понятий такого рода (из стандарта IEEE 610.12-90 “ IEEE Standard Glossary of Software Engineering Terminology ”) выглядят следующим образом:

– Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом < полученным с использованием программного обеспечения> ”

– Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютерной программе”

– Сбой (failure): “< Некорректный> результат, полученный в результате недостатка”

– Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее к некорректному результату”

Под дефектом будем понимать результат сбоя программного обеспечения.

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

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

⇐ Предыдущая 1 2 3 456 7 8 9 10 Следующая ⇒