Влияние видов деятельности жизненного цикла на качество ПП

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

Виды деятельности	Функциона-льность	Качество пользователь-ского интерфейса	Надёжность	Качество дизайна и кода	Производи-тельность	Качество документа-ции
Разработка требований	*	*
Архитектурный анализ и дизайн		*	*	*	*
Кодирование			*	*	*
Тестирование		*	*		*
Разработка документации						*

Основной момент, на который хотелось бы обратить внимание здесь, следующий: на качество конечного продукта влияют все фазы и виды деятельности проекта без исключения – от самых ранних до самых поздних. Таким образом, то, насколько хорошо и качественно мы работаем на каждой фазе проекта (а не только, например, на фазе тестирования), зависит, насколько качественным получится разрабатываемый продукт. Или другими словами, качество процесса разработки определяет качество разрабатываемого продукта [2, стр. 470], т.е. качество продукта неотделимо от качества процесса, и для того, чтобы улучшить качество ПП, нужно улучшать качество процесса разработки этого ПП [1, стр. 271].

Обобщённое понятие дефекта

Удобно было бы ввести и использовать для анализа качества некий обобщённый критерий качества вместо нескольких разрозненных критериев. Таким критерием является обобщённое понятие дефекта:

Любое отклонение от «идеального» продукта, от стандартов качества, которые определены (или подразумеваются) для проекта, есть дефект.

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

Дефекты можно классифицировать по следующим параметрам:

· Тип дефекта (определяется фазой разработки или активностью, на которой он был внесён);

· Критичность дефекта (насколько критично его наличие в ПП);

· Приоритет дефекта (насколько важно его исправить);

· Сложность дефекта (насколько трудоёмко его исправить);

· и др.

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

Дата добавления: 2015-04-29