Для повышения успешности проекта нужно четко представлять, чего нужно достигнуть, т.е. сформулировать цели проекта. Основное требование к цели – конкретность. Например, цели для АИС «Преподаватель»:
Бизнес-цель 1. Уменьшить количество затрачиваемого за неделю времени на контроль учебного процесса на 50% (до 1 астрономического часа).
Бизнес-цель 2. Уменьшить количество ошибок при аттестации студентов в 2 раза.
Бизнес-цель 3. Уменьшить время на получение сводной информации по всем группам, по всем предметам до минимума в 2 минуты.
После определения целей проекта, необходимо сформулировать критерии успешности проекта. Критерии должны поддаваться измерению, т.е. нужно задать правило, которое позволит четко определить, является проект успешным или нет.
Критерий успеха 1. От работы с системой не откажутся 50% преподавателей в течение первых 2-х месяцев работы.
Критерий успеха 2. 75% преподавателей станут использовать систему в следующем семестре.
Группы пользователей
Следующий этап – это определение групп пользователей, которых так или иначе будут взаимодействовать с проектируемой системой.
| Заинтересованные лица | Понимание основной ценности проекта | Отношение | Основные интересы | Ограничение |
| Преподаватели | Увеличение точности учета, сокращение затрат личного времени | Большой энтузиазм, но могут использовать систему меньше, чем ожидается | Сокращение расходов времени | Возможно потребуется обучение работе с системой |
Функциональные возможности
Функциональные возможности системы – это то, что может делать система, т.е. то, что нужно будет реализовать в программном коде. Функциональные возможности разрабатываемой системы должны быть определены еще до начала написания какого-либо программного кода.
Основные функции 1. Создание, редактирование, удаление группы студентов.
Основные функции 2. Создание, редактирование, удаление студента.
Основные функции 3. Создание, редактирование, удаление предмета и его рабочей программы.
Основные функции 4. Ввод информации по посещаемости занятий.
Бизнес-правила
Бизнес-правила – это формализованные или неформализованные правила, которые используются при работе. Обычно бизнес-правила задают ограничения для программ, из которых состоит система. Основные трудности вызывают неформализованные бизнес-правила, которые используются не очень часто, т.е. многие сотрудники используют такие правила, даже не задумываясь о том, что кому-то это может быть неизвестно. Задача разработчика – выявить и формализовать такие правила.
Примеры бизнес-правил для АИС «Деканат»:
Бизнес-правило 1. Количество студентов в группе может быть от 1 до 35.
Бизнес-правило 2. Название группы в общем случае имеет следующий формат: XXXX[-A], где X – цифры, A – буквы, квадратными скобками обозначена необязательная часть.
Варианты использования системы
Варианты использования системы – это сценарии работы пользователей в системе. Сценарий реализует одну или несколько функциональных возможностей. Разработка вариантов использования производится по шаблону (см. пример).
Пример. Вариант использования из АИС «Преподаватель»:
| Название | Создание группы | ||
| Автор | Галиуллин Л.А. | Последнее обновление | Галиуллин Л.А. |
| Дата создания | 09.07.2008 | Дата последнего обновления | 09.07.2008 |
| Действующие лица | Преподаватель | ||
| Описание | Преподаватель создает в системе новую группу студентов, у которых он ведет занаятия | ||
| Предварительные условия | 1. Преподаватель загрузил систему «Преподаватель» | ||
| Выходные условия | 1. В системе появляется новая группа 2. Обновляется список доступных групп | ||
| Нормальное направление | 1.0. Создание одной группы 1. Преподаватель делает запрос на создание группы (нажимает кнопку) 2. Система просит пользователя ввести имя группы 3. Пользователь вводит имя группы 4. Пользователь подтверждает создание группы 5. Система записывает данные о новой группе в свою базу 6. Система выводит сообщение о результате операции создания группы 7. Пользователь нажимает OK | ||
| Альтернативные направления | 1.1. Создание нескольких групп (ответвление после пункта 6) 1. Пользователь делает запрос на создание еще одной группы 2. Возврат к пункту 2. | ||
| Исключения | 1.0.И.1 Недопустимое количество символов в имени группы (в пункте 3) 1. Система извещает пользователя, что имя группы слишком длинное 2а. Пользователь отменяет ввод 2б. Система завершает вариант использования 3а. Пользователь решает исправить ввод 3б. Система начинает вариант использования сначала | ||
| Включает | - | ||
| Приоритет | высокий | ||
| Частота использования | приблизительно 10-15 раз в начале семестра | ||
| Бизнес-правила | Бизнес-правило 2 | ||
| Особые требования | Нет | ||
| Допущения | Предполагается, что в 30% случаев группы будут создаваться по несколько сразу | ||
| Замечания и вопросы | Нет |