Поведение системы

Резюме

Постановка задачи регистрации курсов

Риски задачи регистрации курсов

Группа разработчиков определила, что главный риск системы связан с возможностью эффективно сохранять и получать информацию об учебных планах. С этой целью было создано несколько прототипов, чтобы оценить механизмы хранения и доступа к информации для каждой рассматриваемой системы управления базами данных. Результаты испытания прототипов показали, что риск неэффективной работы базы данных может быть уменьшен. Дополнительные прототипы были использованы для оценки аппаратных ресурсов, необходимых при создании онлайновой системы регистрации.

В начале каждого семестра студенты могут запросить каталог курсов, в который включен список учебных предметов, предлагаемых в данном семестре. Информация о курсах должна содержать фамилию преподавателя, название факультета и краткое описание, помогающее студентам сделать выбор.

Новая система позволит студенту выбрать четыре курса из предложенных в наступающем семестре. Кроме того, каждому студенту нужно дополнительно указать еще два варианта, на случай если курс будет переполнен или отменен. На курс не должно быть записано более десяти или менее трех студентов. Курс, на который запишутся менее трех студентов, будет отменен. По завершении регистрации система регистрации направляет информацию в систему оплаты для выставления счетов студентам.

Преподаватели должны иметь возможность онлайнового доступа к системе для указания курсов, которые они будут читать, и для просмотра списка записавшихся студентов.

В каждом семестре выделяется определенное время, в течение которого студенты могут менять свое расписание и получать доступ к системе для добавления или удаления выбранных курсов.

Фаза задумки — это этап открытия. Задача оговаривается и обсуждается в группе разработчиков с привлечением заказчиков. Все высказанные предположения и допущения могут быть утверждены или отклонены после апробации на прототипах. Результаты этой фазы — описание внешних интерфейсов, оценка начальных рисков, определение требований к системе. Заказчики, клиенты, пользователи и другие заинтересованные стороны обсуждают различные идеи и точки зрения и предлагают возможные пути получения необходимых ресурсов и инструментов.

Глава 3. Создание прецедентов

Поведение разрабатываемой системы (то есть функциональность, обеспечиваемая системой) описывается с помощью функциональной модели, которая отображает системные прецеденты (use cases), системное окружение (действующих лиц или актеров — actors) и связи между прецедентами и актерами (диаграммы прецедентов — use cases diagrams). Основная задача модели прецедентов — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

Разработка модели прецедентов начинается на стадии задумки с выбора актеров и определения общих принципов функционирования системы. Затем на этапе проработки модель дополняется детальной информацией к существующим прецедентам, а при необходимости добавляются новые.

Дата добавления: 2014-01-07