- •2007 Г.
- •0. Задание 3
- •1. Требования 3
- •2. Физическая модель приложения 14
- •3. Порядок контроля и приемки 17
- •0. Задание
- •1. Требования
- •1.1. Определение образа и границ проекта
- •1.1.1. Анализ предметной области
- •1.1.2. Анализ осуществимости
- •1.2.2. Совместные семинары
- •1.2.3. “Мозговой штурм”
- •1.2.4. Сценарии
- •1.2.5. МетодVord(на основе различных точек зрения)
- •1.2.6. Этнографический подход
- •1.3. Разработка системных требований
- •1.3.1. Системные модели
- •1.3.2. Разработка прототипов
- •1.3.3. Системные требования
- •1.4. Документирование требований
- •2. Физическая модель приложения
- •3. Порядок контроля и приемки
- •Заключение
- •Список литературы
- •Приложение
1.2.3. “Мозговой штурм”
К сожалению, в нашей организации только 2 человека могут принять участие в генерации идей. Поэтому чёткого разделение на роли (лидер, секретарь, учстник) у нас не будет, а каждый из двух участников будет частично выполнять каждую роль.
Участники: Крупицкий М.В. и Мещеряков А.А.;
Роли: не разделены;
Место проведения: квартира;
Время проведения: 18.04.07;
Продолжительность сеанса: 2 час;
Тема обсуждения: Требования к проекту.
Проведение сеанса:
Перед началом сеанса указали его тему и обсудили правила.
Сначала провелась 5-10 минутная разминка, тема которой была нейтральной и понятной всем участникам, но не связанной с основной темой сеанса (“Подготовка к экзаменам”).
“Мозговой штурм”. Были высказаны разные (рациональные, радикальные, необычные) идеи, которые приходили на ум. Активная работа продолжалась 10 – 15 минут, после чего был сделан перерыв. После перерыва работа была продолжена ещё на 10-15 минут. В конце сеанса были рассмотрины и уточнины записанные идеи. Подобные идеи были объединены, дубликаты были удалены.
Результаты “мозгового штурма” были сведены в документ (см. Приложение 4), который в дальнейшем будет использован для спецификации требований.
1.2.4. Сценарии
Сценарий – это способ описания структуры задачи, представляющий собой повествовательный рассказ о совершаемых действиях, происходящих в данных временных рамках и в данном контексте.
Сценарии событий:
Событие “Планирование поступления в ВУЗ”:
Информация по
ВУЗам
Выборка ВУЗов
Занесение в список
“Выбранные”
ВУЗы
Работа с календарём
Желаемые ВУЗы
не найдены
Предложение
повторного выбора
Найденные ВУЗы
не подходят
Возвращение к
выбору вузов
Варианты использования:
Вариант использования описывает поведение системы при ее ответах на запрос одного из участников (пользователей) системы, называемого основным действующим лицом, в различных условиях.
Вариант использования “Планирование поступления в ВУЗ”.
Основное действующее лицо: Абитуриент.
Область действия: Все вузы и информация о них.
Уровень: Цель пользователя.
Основной сценарий:
Абитуриент заполняет форму фильтра ВУЗов желаемыми данными
Программа демонстрирует пользователю подходящие ВУЗы
Пользователь добавляет ВУЗы в список «Выбранные»
Пользователь просматривает информацию о важных событиях, связанных с поступлением в выбранные ВУЗы
Пользователь заносит её в календарь событий
Расширения:
2а. ВУЗов удовлетворяющих запросу пользователя не найдено
2а1. Пользователь вводит другие критерии поиска
3а. Выбранные ВУЗы не устраивают абитуриента и он вводит новые критерии поиска
4а. Пользователь не добавляет события в календарь или удаляет их оттуда
Модель MSC UML:
UML (Unified Modeling Language) – это унифицированный язык моделирования. UML представляет собой формальный искусственный язык, который постоянно развивается.
В данном проекте описание с помощью модели UML не требуется, т.к. слишком простое. Но приведём его для примера использования:
Система
Абитуриент