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