- •______________________________________________________
- •Технология разработки программного обеспечения. Разработка и анализ требований
- •Виды, взаимосвязь и свойства требований
- •Что такое «требование»?
- •Виды требований
- •Функциональные требования
- •Нефункциональные требования
- •Нефункциональные требования к продукту
- •Нефункциональные требования к процессу
- •Вопросы для самоконтроля
- •Определение образа и границ проекта
- •Анализ предметной области
- •Анализ осуществимости
- •Определение целей и области действия
- •Документирование образа и границ проекта
- •Вопросы для самоконтроля
- •Выявление требований
- •Определение способа сбора и анализа требований
- •Источники возникновения требований
- •Заинтересованные в проекте лица
- •Опрос (интервью)
- •Подготовка
- •Проведение опроса
- •Определение последующих действий
- •Совместные семинары
- •”Мозговой штурм”
- •Роли во время сеансов
- •Правила проведения сеанса
- •Подготовка к сеансу
- •Проведение сеанса
- •Обработка результатов сеанса
- •Сценарии
- •Сценарии событий
- •Варианты использования
- •Применение модели msc uml
- •Выявление требований на основе различных точек зрения. Метод vord
- •Идентификация точек зрения
- •Структурирование точек зрения
- •Документирование и отображение системы точек зрения
- •Этнографический подход
- •Вопросы для самоконтроля
- •Разработка системных требований
- •Детализация требований пользователей
- •Системные модели
- •Модели потоков данных
- •Модели конечных автоматов
- •Модели данных
- •Прототипы
- •Роль прототипов при разработке требований
- •Виды прототипов
- •Разработка прототипов
- •Экспериментальное прототипирование
- •Эволюционное прототипирование
- •Риски прототипирования
- •Системные требования
- •Структурированный естественный язык
- •Языки описания программ
- •Графические нотации
- •Документирование системных требований
- •Вопросы для самоконтроля
- •Документирование требований
- •Спецификация требований
- •Состав спецификации требований
- •Рекомендации по разработке требований
- •Стандартные шаблоны спецификации
- •Вопросы для самоконтроля
- •Анализ спецификации требований
- •Оценка качества спецификации требований
- •Характеристики качества спецификации
- •Аттестация требований
- •Экспертиза спецификации
- •Прототипирование
- •Автоматизированный анализ
- •Тестирование требований
- •Вопросы для самоконтроля
- •Управление требованиями
- •Причины изменений требований
- •Принципы управления требованиями
- •Управление изменениями
- •Управление версиями
- •Управление связями требований
- •Риски, связанные с требованиями
- •Риски этапа выявления требований
- •Риски этапа анализа и спецификации требований
- •Риски управления требованиями
- •Вопросы для самоконтроля
- •Case-средства для управления требованиями
- •Выбор case-средств для управления требованиями
- •Уровень зрелости и используемые инструменты
- •Моделирование требований
- •Трассировка требований
- •Управление версиями
- •Возможности case-средств управления требованиями
- •Средства idf-моделирования
- •Средства uml
- •Вопросы для самоконтроля
- •Список литературы
- •Карта памяти к разделу 1
Прототипирование
При аттестации требований прототип демонстрируется пользователям, которые, экспериментируя с ним, могут убедиться в том, что он отвечает их потребностям.
Автоматизированный анализ
Использование автоматизированных средств возможно, если требования представлены в виде структурных или формальных системных моделей. Для автоматизированной проверки непротиворечивости требований строится база данных требований, а соответствующий анализатор требований готовит отчет обо всех обнаруженных противоречиях.
Тестирование требований
Экспертиза спецификации требований – это просмотр документа, для которого не требуется компьютер. Тестирование– процесс динамический, который выполняется на компьютере, и поэтому может быть применен только для функциональных требований [9].
Для того, чтобы представить себе, как будет в определенных условиях вести себя система, нужно на основе требований, записанных в спецификации, разработать варианты тестирования. Варианты тестирования– это еще один способ анализа и выявления дефектов требований. Варианты тестирования, разрабатываемые совместно разработчиком и пользователем, позволяют не только выработать общее понимание работы продукта, но и будут незаменимы для оценки моделей, прототипов и требований. Варианты должны охватывать не только поведение продукта в нормальном режиме, но и все исключительные ситуации, определенные в ходе анализа.
Исходной информацией для функциональных требований и вариантов тестирования являются пользовательские требования, поэтому их разработка должна вестись параллельно. Разработчик пишет функциональные требования, а тестировщик – варианты тестирования для них. По мере проектирования и реализации приложения варианты тестирования также будут наполняться конкретным содержанием. Нужно заметить, что разработку и тестирование (созидание и разрушение) лучше поручить разным исполнителям.
Планирование процесса тестирования должно производиться параллельно с проектированием. Виды планов, разрабатываемых на разных этапах проектирования, хорошо иллюстрируются на примере V-образной модели жизненного цикла (см. рис. 6.3).
Рис. 6.3
Пунктирными линиями здесь соединены этапы, которые нужно рассматривать параллельно [10]. Остановимся на первых двух связях.
Требования к проекту и планирование
Здесь определяются требования, и производится планирование ресурсов. Этот этап связан с этапами эксплуатации и сопровождения, предваряемые приемочными испытаниями. Приемочные испытания позволяют пользователю протестировать функциональные возможности системы на их соответствие с исходными требованиями, после чего продукт принимается в эксплуатацию. Планирование приемочных испытаний проводится на фазе разработки требований, а разработка тестов должна выполняться пользователями.
Требования к продукту и анализ спецификации
На этом этапе происходит планирование системного тестирования, которое позволяет проверить функционирование системы в условиях реального окружения в соответствии со спецификацией требований. Основной критерий при проведении системного тестирования – критерий приемлемости, который определяет степень соответствия продукта задокументированным требованиям. Разработка тестов для системного тестирования также должна выполняться пользователями.
Тесты приемлемости отслеживают, в основном, нормальные линии поведения вариантов использования. При оценке приемлемости основные группы пользователей должны обращать внимание на наиболее общие и важные варианты использования. Для минимизации трудоемкости тестирования, в котором участвуют пользователи, нужно использовать средства автоматизации.