- •"Управление качеством разработки программного обеспечения" Содержание
- •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
- •Автоматизированное тестирование
- •Обработка требований на ошибки
- •Приемка
- •Приемосдаточные испытания
- •Регрессионное тестирование
- •Система отслеживания ошибок
- •Тестирование
4.4. Управление требованиями
Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято считать, что требования описаны неполностью, если для них не заданы правила V&V (verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.
Способы описания требований и анализ требований.
Спецификация — (Specification) инженерный термин, обозначающий набор требований и параметров, которым удовлетворяет некоторая сущность. К примеру, мост через реку удовлетворяет таким параметрам, как максимальный общий вес нагрузки, максимальная нагрузка на ось, максимальная скорость ветра и т. д.
Согласно определению, приведенному в Единой системе конструкторской документации (ЕСКД) спецификация — документ, определяющий состав сборочной единицы, комплекса, комплекта. В спецификации содержится подробное перечисление узлов и деталей какого-либо изделия, конструкции, установки, и т. п., входящих в состав сборочного или монтажного чертежа.
Также под спецификацией часто подразумевается документ с перечислением условий, которым должен удовлетворять производственный заказ (то есть требования клиента к производителю). Чаще всего в русском языке такую спецификацию называют техническим заданием. Тем не менее, в сфере программирования и компьютерных систем этот термин употребляется наравне. К примеру, спецификация программного комплекса включает описания диалогов пользователя, требования к памяти и процессорам, производительности системы.
Спецификация, часто, является базисом для создания стандарта, который отвечает наиболее важным требованиям этой спецификации.
Требования к программному обеспечению — совокупность утверждений относительно свойств программной системы, подлежащая реализации при создании программного обеспечения. Создаются в процессе анализа требований к программному обеспечению.
Требования могут выражаться в виде текстовых утверждений и графических моделей
Виды требований по уровням
Бизнес-требования — определяют назначение программного обеспечения
Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия)
Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе
Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять
Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).
К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и программному обеспечению.