Как контролировать качество системы? Как точно узнать, что программа делает именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна, переносима, удобна в использовании? Ответы на эти вопросы можно получить с помощью процессов верификации и валидации.
- Верификация обозначает проверку того, что программное обеспечение разработано в соответствии со всеми требованиями к нему, или что результаты очередного этапа разработки соответствуют ограничениям, сформулированным на предшествующих этапах.
- Валидация — это проверка того, что сам продукт правилен, т.е. подтверждение того, что он действительно удовлетворяет потребностям и ожиданиям пользователей, заказчиков и других заинтересованных сторон.
Эффективность верификации и валидации, как и эффективность разработки программного обеспечения в целом, зависит от полноты и корректности формулировки требований к программному продукту.
Основой любой системы обеспечения качества являются методы его обеспечения и контроля. Методы обеспечения качества представляют собой техники, гарантирующие достижение определенных показателей качества при их применении. Мы будем рассматривать подобные методы на протяжении всего курса.
Методы контроля качества позволяют убедиться, что определенные характеристики качества программного обеспечения достигнуты. Сами по себе они не могут помочь их достижению, они лишь помогают определить, удалось ли получить в результате то, что хотелось, или нет, а также найти ошибки, дефекты и отклонения от требований. Методы контроля качества программного обеспечения можно классифицировать следующим образом:
- Методы и техники, связанные с выяснением свойств программного обеспечения во время его работы.
Это, прежде всего, все виды тестирования, измерение количественных показателей качества, которые можно определить по результатам работы программного обеспечения — эффективности по времени и другим ресурсам, надежности, доступности и пр.
- Методы и техники определения показателей качества на основе симуляции работы программного обеспечения с помощью моделей разного рода.
К этому виду относятся проверка на моделях (model checking), а также прототипирование (макетирование), используемое для оценки качества принимаемых решений.
- Методы и техники, нацеленные на выявление нарушений формализованных правил построения исходного кода программного обеспечения, проектных моделей и документации.
К методам такого рода относится инспектирование кода, заключающееся в целенаправленном поиске определенных дефектов и нарушений требований в коде на основе набора шаблонов, автоматизированные методы поиска ошибок в коде, не основанные на его выполнении, методы проверки документации на согласованность и соответствие стандартам.
- Методы и техники обычного или формализованного анализа проектной документации и исходного кода для выявления их свойств.
К этой группе относятся многочисленные методы анализа архитектуры программного обеспечения, о которых пойдет речь в следующей лекции, методы формального доказательства свойств ПО и формального анализа эффективности применяемых алгоритмов.
Стоимость качества.
Фраза «стоимость качества» (“cost of quality”) широко применяется и вводит в заблуждение. Это не цена качества продукта или сервиса. Это не стоимость создания качественного продукта или сервиса. Это - стоимость «плохого качества» (Д. Джуран). Это суммарная стоимость издержек на:
инвестиции в предупреждение несоответствий требованиям
оценку продукта\сервиса на соответствие требованиям
исправление несоответствий требованиям
Preventive costs (стоимость предотвращения низкого качества продукта\сервиса):
• Обзор (review) нового продукта (требований)
• Планирование качества
• Разработка/оценка процессов
• Планирование улучшения качества
• Обучение
• Стоимость всех активностей для предотвращения ошибок (QA)
Appraisal costs (стоимость оценки – измерение, оценка и проверка продукта\сервиса с целью обеспечения соответствия стандартам качества):
• Стоимость тестирования
• Стоимость выполнения ревью
• Стоимость выполнения инстпекций
• Все затраты на выявление дефектов (QC)
Failure cost (цена «неудач»/ошибок, обнаруженных до поставки поставки продукта\предоставления сервиза заказчику и после: internal failure cost and external failure cost):
• Стоимость идентификации, анализа, исправления ошибок и проверки исправления ошибок
• Повторное тестирование
• Стоимость переработок
• Стоимость работ по обработке жалоб заказчика
Удельная стоимость исправления дефектов быстро растет по мере продвижения продукта к стадии эксплуатации. Так, в статье B. Boehm and V. Basili «Software Defect Reduction Top 10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1, January 2001, pp. 135-137.) показано, что стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период выработки требований к продукту.
Рис. 8. Стоимость качества.
Что необходимо сделать:
• Определите, что такое качество в вашей компании (стандарты качества)
• Определите, что такое качественный продукт\услуга (стандарты)
• Подумайте над стоимостью плохого качества
• Определите действия для предотвращения плохого качества, оценки качества продукта\услуги на соответствие стандартам качества
• Уменьшайте стоимость исправления ошибок путем увеличения затрат на предупреждение и оценку качества.
• Балансируйте затраты
Введение в CMMI
«Каркасом» процесса разработки программного обеспечения служит модель зрелости функциональных возможностей (Capability Maturity Model, CMM). Она основана на практических действиях, отображает лучшие результаты и определяет потребности индивидов, работающих над усовершенствованием процесса разработки программного обеспечения и выполняющих оценочный анализ этого процесса. Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки.
Исходный. Процесс разработки программного обеспечения можно охарактеризовать как специальный, подобранный для определенного случая процесс, а иногда и как хаотический. Определить можно лишь небольшое количество процессов, и успех зависит от приложенных усилий и предпринимаемых решительных действий.
Повторяющийся. Основные процессы управления проектом создаются для того, чтобы отслеживать затраты, график работы и функциональные возможности. Здесь соблюдается необходимый порядок выполнения процесса, предназначенный для повторения достижений, полученных ранее при выполнении подобных проектов.
Определенный. Во всех проектах используется испытанная, адаптированная версия стандартного процесса разработки программного обеспечения данной организации.
Управляемый. Собираются детальные показатели процесса разработки программного обеспечения и качественные характеристики продукта. Управление процессом разработки программных продуктов осуществляется на количественном уровне.
Уровень оптимизации. Непрерывное усовершенствование процесса разработки достигается с помощью количественной обратной связи, достигаемой при осуществлении самого процесса, а также на базе новаторских идей и технологий.
Определение процесса включает в себя разработку и сопровождение стандартного процесса разработки определенной организации, а также относящиеся к нему ценные свойства процесса, такие как описательные характеристики жизненных циклов разработки ПО, руководящие принципы адаптации процесса и его критерии
Целью разработки CMMI явилось желание его создателей избежать проблем, связанных с использованием различных моделей CMM. Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:
- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software – SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM)
На основе этих моделей и был построен CMMI. Он вобрал в себя лучшее из этих моделей, устранив неоднозначность трактования некоторых понятий ввиду наличия множества моделей.
Прежде всего, хотелось бы упомянуть о том, что CMMI является референтной моделью, которая шаг за шагом помогает организации усовершенствовать свои бизнес процессы.
Использование данной модели позволяет организации оценить эффективность бизнес-процессов, установить приоритетные направления их усовершенствования, а также внедрить данные усовершенствования. Однако следует помнить, что нельзя улучшать бизнес-процессы во имя их улучшения, данные улучшения должны помогать бизнесу, достичь поставленных перед ним целей. Также необходимо иметь в виду, что улучшение процессов это долговременное, стратегическое усилие организации.
Существует два подхода (репрезентации) в совершенствовании бизнес-процессов в контексте CMMI:
- непрерывная репрезентация
- поэтапная репрезентация
Чем же отличаются эти два подхода?
Примечание: репрезентация подобна представлению (view) в базе данных. Данные, используемые в обоих подходах одинаковы, отличаются средства их организации и представления.
При выборе непрерывной репрезентации организация оставляет за собой право выбора последовательности действий ведущих к совершенствованию бизнес процессов. В данном случае усовершенствуются процессы определенной области процессов. Данный подход позволяет мигрировать с модели EIA/IS 731 на модель CMMI.
Поэтапная репрезентация предполагает определенную, доказавшую право на существование, последовательность действий, которая ведет к совершенствованию всех процессов организации в целом, а не определенной области процессов как в предыдущем подходе. Данная репрезентация помогает осуществить переход с модели SW-CMM к модели CMMI.
Примечание. Необходимо заметить, что наличие предыдущих моделей помогает перейти к модели CMMI, но ни в коей мере не является необходимым условием для внедрения CMMI.
В непрерывной репрезентации для оценки (измерения) степени улучшения процессов используется уровень устойчивости (capability level), в то время как в поэтапной репрезентации используется уровень зрелости (maturity level). Основное различие между этими двумя понятиями заключается в следующем:
Уровни устойчивости, используемые в непрерывной репрезентации, применяются для улучшения процессов в каждой области процессов. Существует шесть таких уровней, пронумерованных от 0 до 5. Уровень устойчивости включает в себя общую цель и набор общих и специфических практик (см. глоссарий). Непрерывная репрезентация имеет два типа специфических практик: общие и дополнительные, в поэтапной репрезентации такого деления нет.
Непрерывная репрезентация.
| Уровень устойчивости | Название уровня |
| Незавершенный уровень | |
| Выполненный уровень | |
| Управляемый уровень | |
| Определенный уровень | |
| Количественно-управляемый уровень | |
| Оптимизированный уровень |
В свою очередь уровень зрелости описывает общую организационную зрелость, и он включает в себя предопределенный набор областей процессов (см. Таблица 1). Существует пять уровней зрелости, пронумерованных от 1 до 5. В поэтапной репрезентации может присутствовать лишь одна общая цель для одной области процессов.
Поэтапная репрезентация
| Уровень зрелости | Название уровня |
| Начальный уровень | |
| Управляемый уровень | |
| Определенный уровень | |
| Количественно-управляемый уровень | |
| Оптимизированный уровень |
Рис. 9. Иллюстрация различий в двух подходах:
| 
|
| Различные области процессов (ОП) могут находиться на разных уровнях устойчивости (УУ) | Все области процессов находятся на одном уровне зрелости (УЗ) |
Рис. 10. Структурная схема CMMI – поэтапная репрезентация
Краткий глоссарий CMMI:
Область процессов (Process Area) – набор связанных практик данной области, исполняются для достижения ряда целей, которые считаются важными в контексте улучшения процессов в данной области.
В CMMI области процессов одинаковы для непрерывной и поэтапной репрезентации.
Практики (practices) – это действия, производимые для достижения поставленных целей в данной области процессов.
Практики являются основным конструктивным элементом на основе, которого построена модель CMMI.
Специфические цели (specific goals) – цели, конкретизирующие основную (общую) цель
Общие цели (generic goals) – это цели, достижение которых в данной области свидетельствует о достижении зрелости процессов в данной области процессов. Слово общие говорит о том, что одна и та же цель может присутствовать во многих областях процессов.
Специфические практики (specific practices) – практики, выполнение которых способствует достижению специфических целей.
Общие практики (generic practices) – практики, выполнение которых способствует достижению общих целей.
Общие признаки (common features) – на самом деле общие свойства - это логическая группировка общих целей.
Субпрактики (subpractices) – представляют собой детализированные описания, поясняющие специфические и общие практики.
Дисциплина (discipline) – область знаний связанная с одной из четырех составляющих применения CMMI. В модели CMMI существует четыре дисциплины:
- разработка программного обеспечения
- системный инжиниринг
- интегрированная разработка процессов и продуктов
- выбор (отбор) поставщиков
Уровень зрелости (maturity level) – представляет собой точно определенное эволюционное плато на пути к достижению полной зрелости процессов организации. Каждый уровень зрелости формирует отдельный слой фундамента для постоянного совершенствования производственного процесса, включает в себя набор целей процесса, которые, по мере их достижения, приводят к стабилизации значимых компонентов производственного процесса. Каждый уровень зрелости является основой для более высокого уровня зрелости. Каждый уровень зрелости состоит из определенных областей процессов.
Управление требованиями
Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято считать, что требования описаны неполностью, если для них не заданы правила V&V (verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.