- •"Управление качеством разработки программного обеспечения" Содержание
- •1. Введение
- •2. Основные определения
- •3. Процесс разработки программного обеспечения.
- •3.1 Жизненный цикл программного обеспечения.
- •3.2 Модели жизненного цикла программного обеспечения.
- •3.2.1 Каскадная модель (1970, w.W. Royce)
- •3.2.2. Инкрементная модель жизненного цикла разработки программного обеспечения
- •3.2.3 Итерационная модель
- •3.2.4 Спиральная модель (Бари Боэм, 1988.)
- •3.2.6 Модель быстрого прототипирования
- •3.2.7 Agileметодологии
- •Преимущества непрерывной интеграции:
- •Недостатки непрерывной интеграции:
- •3.2.7.3 Гибкая разработка - scrum(Ken Schwaber & Jeff Sutherland, 1996)
- •Планирование спринта, митинг первый
- •Планирование спринта, митинг второй
- •Остановка спринта (Sprint Abnormal Termination).
- •Демо и ревью спринта.
- •3.2.8 Подгонка модели жизненного цикла разработки.
- •4 Качество программных продуктов.
- •4.1 Определение качества. Стандарты качества.
- •Методы контроля качества
- •4.2 Стоимость качества.
- •4.3 Введение в cmmi
- •4.4. Управление требованиями
- •Способы описания требований и анализ требований.
- •Виды требований по уровням
- •Виды требований по характеру
- •Типы документов требований
- •5. Тестирование программного обеспечения.
- •5.1. Цели и задачи. Основные определения.
- •5.1.1 Методологии тестирования
- •5.1.2 Уровни тестирования
- •5.2 Процесс тестирования.
- •5.2.3 Планирование тестирования.
- •Кто будет тестировать?
- •Что нужно тестировать?
- •В каком объеме тестировать?
- •Виды тест планов
- •Оценка качества тестов
- •Тестовые метрики
- •5.2.4. Автоматизация тестирования
- •Упрощение интеграции
- •Документирование кода
- •Отделение интерфейса от реализации
- •Ограничения
- •Приложения модульного тестирования
- •5.3. Дефекты. Причины, описания, отслеживание.
- •***Этимология
- •Жизненный цикл дефекта
- •Примеры систем отслеживания ошибок
- •5.4. Типы дефектов и статические методы тестирования (Майерс)
- •5.5 Техники создания тест-кейсов.
- •5.5.1 Проектирование и исполнение.
- •5.5.2 Техники создания тест-кейсов: методология «черного ящика»
- •Свойства правильно выбранного теста
- •Техники стратегии чёрного ящика
- •Эквивалентное разбиение
- •Анализ граничных значений
- •Анализ причинно-следственных связей
- •Предположение об ошибке
- •5.5.3 Техники создания тест-кейсов: методология «белого ящика».
- •Структура rup
- •Продукты, поддерживающие rup
- •Артефакты и роли
- •Введение в uml
- •Принципы моделирования
- •Сущности в uml
- •Отношения в uml
- •Виды диаграмм uml
- •Автоматизированное тестирование
- •Обработка требований на ошибки
- •Приемка
- •Приемосдаточные испытания
- •Регрессионное тестирование
- •Система отслеживания ошибок
- •Тестирование
3.2.1 Каскадная модель (1970, w.W. Royce)
В первые годы практики программирования сначала записывался программный код, а затем происходила его отладка. Общепринятым считалось правило начинать работу не с разработки плана, а с общего ознакомления с продуктом. Без лишних формальностей можно было спроектировать, закодировать, отладить и протестировать программного обеспечения еще до того, как оно будет готово к выпуску. В структуре такого процесса есть несколько "неправильностей" (или недостатков). Во-первых, поскольку изначально не существовало официального проекта или анализа, невозможно было узнать о моменте завершения процесса. Также отсутствовал способ определения соответствия требованиям относительно достижения качества.
В 1970 году каскадная модель была впервые определена как альтернативный вариант метода разработки программного обеспечения по принципу кодирование-устранение ошибок, который был широко распространен в то время. Это была первая модель, которая формализовала структуру этапов разработки программного обеспечения, придавая особое значение исходным требованиям и проектированию, а также созданию документации на ранних этапах процесса разработки.
Каскадная модель (или «водопадная модель», waterfall) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Характерна для периода 1970-1985 гг.
Рис. 1. Каскадная модель.
На начальном периоде каскадная модель сыграла ведущую роль как метод регулярной разработки сложного программного обеспечения. В семидесятых-восьмидесятых годах XX века модель была принята как стандарт министерства обороны США.
Со временем недостатки каскадной модели стали проявляться все чаще и возникло мнение, что она безнадежно устарела. Между тем, каскадная модель не утратила своей актуальности при решении следующих типов задач:
Требования и их реализация максимально четко определены и понятны; используется неизменяемое определение продукта и вполне понятные технические методики. Это задачи типа:
научно-вычислительного характера (пакеты и библиотеки научных программ типа расчета несущих конструкций зданий, мостов и т.д.)
операционные системы и компиляторы
системы реального времени управления конкретными объектами
Кроме того, каскадная модель применима в условиях:
повторная разработка типового продукта (автоматизированного бухгалтерского учета, системы электронного документооборота и т.п.)
выпуск новой версии уже существующего продукта, если вносимые изменения вполне определены и управляемы (миграция уже существующего продукта на новую платформу)
Принципы каскадной модели находят применение как элементы моделей других типов, о чем речь пойдет ниже (где перечислить разделы).
Можно выделить следующие положительные стороны применения каскадного подхода:
на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении относительно простых систем, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе.
Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания программного обеспечения оказывается соответствующим поэтапной модели с промежуточным контролем
Каскадная модель имеет следующие преимущества:
Проста и понятна заказчикам, т.к часто используется другими организациями для отслеживания проектов, не связанных с разработкой программного обеспечения
Проста и удобна в применении:
процесс разработки выполняется поэтапно.
ее структурой может руководствоваться даже слабо подготовленный в техническом плане или - неопытный персонал;
она способствует осуществлению строгого контроля менеджмента проекта;
Каждую стадию могут выполнять независимые команды (все документировано)
Позволяет достаточно точно планировать сроки и затраты
При использовании каскадной модели для «неподходящего» проекта могут проявляться следующие ее основные недостатки:
Попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике;
Интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок;
Запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат
Недостатки каскадной модели особо остро проявляются в случае, когда трудно (или невозможно) сформулировать требования или требования могут меняться в процессе выполнения проекта. В этом случае разработка программного обеспечения имеет принципиально циклический характер.