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