
- •Виды, взаимосвязь и свойства требований
- •Что такое «требование»?
- •Виды требований
- •Функциональные требования
- •Нефункциональные требования
- •Нефункциональные требования к продукту
- •Нефункциональные требования к процессу
- •Вопросы для самоконтроля
- •Определение образа и границ проекта
- •Анализ предметной области
- •Анализ осуществимости
- •Определение целей и области действия
- •Документирование образа и границ проекта
- •Вопросы для самоконтроля
- •Выявление требований
- •Определение способа сбора и анализа требований
- •Источники возникновения требований
- •Заинтересованные в проекте лица
- •Опрос (интервью)
- •Подготовка
- •Проведение опроса
- •Определение последующих действий
- •Совместные семинары
- •”Мозговой штурм”
- •Роли во время сеансов
- •Правила проведения сеанса
- •Подготовка к сеансу
- •Проведение сеанса
- •Обработка результатов сеанса
- •Сценарии
- •Сценарии событий
- •Варианты использования
- •Применение модели msc uml
- •Выявление требований на основе различных точек зрения. Метод vord
- •Идентификация точек зрения
- •Структурирование точек зрения
- •Документирование и отображение системы точек зрения
- •Этнографический подход
- •Вопросы для самоконтроля
- •Разработка системных требований
- •Детализация требований пользователей
- •Системные модели
- •Модели потоков данных
- •Модели конечных автоматов
- •Модели данных
- •Прототипы
- •Роль прототипов при разработке требований
- •Виды прототипов
- •Разработка прототипов
- •Экспериментальное прототипирование
- •Эволюционное прототипирование
- •Риски прототипирования
- •Системные требования
- •Структурированный естественный язык
- •Языки описания программ
- •Графические нотации
- •Документирование системных требований
- •Вопросы для самоконтроля
- •Документирование требований
- •Спецификация требований
- •Состав спецификации требований
- •Рекомендации по разработке требований
- •Стандартные шаблоны спецификации
- •Вопросы для самоконтроля
- •Анализ спецификации требований
- •Оценка качества спецификации требований
- •Характеристики качества спецификации
- •Аттестация требований
- •Экспертиза спецификации
- •Прототипирование
- •Автоматизированный анализ
- •Тестирование требований
- •Вопросы для самоконтроля
- •Управление требованиями
- •Причины изменений требований
- •Принципы управления требованиями
- •Управление изменениями
- •Управление версиями
- •Управление связями требований
- •Риски, связанные с требованиями
- •Риски этапа выявления требований
- •Риски этапа анализа и спецификации требований
- •Риски управления требованиями
- •Вопросы для самоконтроля
- •Case-средства для управления требованиями
- •Выбор case-средств для управления требованиями
- •Уровень зрелости и используемые инструменты
- •Моделирование требований
- •Трассировка требований
- •Управление версиями
- •Возможности case-средств управления требованиями
- •Средства idf-моделирования
- •Средства uml
- •Вопросы для самоконтроля
- •Список литературы
Уровень зрелости и используемые инструменты
В зрелой организации располагающей развитой инфраструктурой и корпоративной культурой, поддерживающей процесс разработки программных систем:
имеются четко определенные процедуры создания программного продукта и управления программными проектами;
оценки времени и стоимости выполнения работ основываются на накопленном опыте;
существуют стандарты на процессы разработки, кодирования, тестирования, внедрения и сопровождения продукта.
Модель зрелости способностей предприятий в области разработки программного обеспечения (Capability Maturity Model for Software – CMM) определяет уровни зрелости, характеризующей способности коллектива к разработке программного продукта.
В модели CMM различают пять уровней зрелости (наивысшим из которых является пятый) и насчитывается 24 ключевые области процесса, которые распределены по уровням зрелости. Ключевые области процесса – это основные компоненты способностей предприятия по разработке программ. Напомним особенности первых трех уровней.
Уровень 1. Начальный (Initial)
На начальном уровне процесс разработки программного продукта либо неустойчивый и хаотичный, либо про него ничего не известно. (На этот уровень попадают все предприятия-разработчики, поскольку на нем отсутствуют какие-либо требования к процессу.)
Уровень 2. Управляемый (Managed)
На втором уровне процесс разработки программного продукта становится управляемым. Предприятие, находящееся на втором уровне зрелости, добилось того, что все процессы планируются, документируются, выполняются, оцениваются и контролируются на уровне программных проектов.
Уровень 3. Определенный (Defined)
Для третьего уровня зрелости процесса характерно, что все виды деятельности, связанные с процессом, основаны на одном, общем для всего предприятия, стандартном наборе процессов, которые подогнаны под конкретные условия, хорошо понимаемы и описаны в корпоративных стандартах, руководствах и т.п. Разработанный на предприятии набор стандартных процессов постоянно усовершенствуется и является базисом для развития и внедрения согласованных процессов во всех проектах, которые ведутся на предприятии.
Разработка, анализ и управление требованиями очень важны в программном проекте, поэтому соответствующие ключевые области определены уже для второго и третьего уровней зрелости. Приведем список таких ключевых областей.
На втором уровне зрелости определены следующие ключевые области:
Управление требованиями (Requirements Management) – обеспечение возможности установления единого с заказчиком понимания требований к разрабатываемому продукту.
Управление конфигурацией (Configuration Management) – установление и поддержка целостности всех продуктов проекта или процесса за счет обеспечения единой системы идентификации компонентов продукта, контроля над изменениями и управления изменениями компонентов.
Третий уровень характеризуется включением ключевой области:
Разработка требований (Requirements Development)» – разработка и анализ требований заказчика, требований к программному продукту и отдельным его компонентам.
Для обеспечения данных ключевых областей перечислим [6] следующие специфические типы инструментов:
моделирование требований;
трассировка требований;
управление версиями.
Существует взаимосвязь между уровнями зрелости и используемыми инструментами. Для этапа разработки требований набор инструментов, поддерживающий ключевые области процесса, приведен в таблице 8.1.
Таблица 8.1
Уровень |
Основная цель применения |
Ключевые области процесса |
Инструменты |
Минимальный набор инструментов |
2 Повторяемый |
Процесс осуществления менеджмента проектов |
1. Управление требованиями |
1.Моделирование требований |
Visio, Access |
2. Трассировка |
Excel | |||
2. Менеджмент конфигурации |
3. Управление версиями |
Visual Source Safe |