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