Главная | Обратная связь | Поможем написать вашу работу!

Качество процесса создания ПО и качество программного продукта

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

Рис. 24.4. Обеспечение качества продукции путем достижения должного уровня качества производственного процесса

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

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

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

1. Определение стандартов на процесс разработки ПО, например способ проведение проверок создаваемого ПО, времени, когда их следует проводить, и т.д.

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

3. Создание отчетности о ходе процесса разработки для менеджера проекта и заказчика программного обеспечения.

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

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

Планирование качества

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

Из всех организационных стандартов в плане обеспечения качества должны быть отображены наиболее подходящие к создаваемому программному продукту или процессу его разработки. Если в проекте используются новые методы или инструментальные средства, то могут быть добавлены новые стандарты к уже существующим. В книге по управлению разработкой ПО [171], которую можно считать классической, предлагается приведенная ниже структура плана обеспечения качества.

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

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

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

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

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

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

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

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

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

Надежность	Понятность	Переносимость
Безопасность	Возможность тестирования	Удобство эксплуатации
Безотказность	Адаптируемость	Возможность повторного использования
Устойчивость к внешним воздействиям	Модульность	Эффективность

Контроль качества

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

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

Существует два взаимодополняющих подхода к процессу контроля качества.

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

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

Проверки качества

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

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

Таблица 24.4. Типы проверок

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

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

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

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

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

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

⇐ Предыдущая 165 166 167 168 169170171 172 173 174 Следующая ⇒