Характеристика объектов информатизации

⇐ ПредыдущаяСтр 2 из 2

Краткое описание работы кафедры

К основным направлениям работы кафедры относятся:

· Учебно-методическая работа;

· Научная работа;

· Организационно-методическая работа;

· Работа со студентами заочниками;

· Общественная работа;

· Воспитательная работа.

…

Описание объектов информатизации

К основным объектам информатизации системы относятся:

Кафедра

· Наименование кафедры

· Факультет, к которому относится кафедра

· Веб-сайт кафедры

· Заведующий кафедрой

…

Учебно-методическая работа

План учебно-методической работы кафедры

· Учебный год

· Заведующий кафедрой, составивший план

· Кафедра

Тема для учебно-методической работы

· Названия работ

· Сроки исполнения

· Ответственные за выполнение темы

…

Требования к информационной системе

Базовые принципы разработки подсистем

При проектировании и разработке подсистем должны использоваться следующие базовые принципы:

· Исключение дублирования ввода информации и повышение ее достоверности, за счет отождествления ранее введенной информации;

…

Система должна удовлетворять следующим требованиям:

· Пользовательский интерфейс системы должен быть сформирован в соответствии с навыками и профилем пользователей;

…

Система должна содержать:

· Средства поиска информации;

…

Выбор прикладного программного обеспечения системы должен удовлетворять следующим критериям:

· Интеграция с базами данных, поддерживающих Web-технологии;

…

Требования к архитектуре системы.

Архитектура системы «Система» является трехзвенной. В качестве клиентского приложения выступает стандартный веб-браузер.

…

Требования к способам и средствам связи для информационного обмена между компонентами (модулями) Системы

Подсистемы должны взаимодействовать в пределах единой компьютерной сети (Интернет/Интранет), в которой происходит весь обмен информацией.

…

Требования к характеристикам взаимосвязей системы со смежными системами

Смежными системами для информационной системы «Система» являются: «Система2»,

…

Требования к режимам функционирования подсистемы

Разрабатываемая система должна функционировать 24 часа в сутки, 365 дней в году…

…

Требования к пользователям

Система подразумевает четыре типа пользователя:

· Сотрудник – имеет доступ к просмотру общих данных по своей кафедре, а также к просмотру и редактированию личных данных, имеет возможность;

…

Требования по эргономике и технической эстетике

Основными требованиями по эргономике и технической эстетике является адекватность времени реакции модулей системы на сложность запроса пользователя к базам данных:

· При выполнении стандартных запросов пользователь должен работать с системой в реальном режиме времени;

…

Требования к численности и квалификации персонала системы и режиму его работы.

Квалификация персонала, порядок его подготовки и контроль знаний и навыков.

…

Требования к защите информации от несанкционированного доступа.

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

…

Требования к обмену данными

· Обмен данными должен происходить по сети в среде Intranet/Internet с поддержкой протокола TCP/IP;

…

Требования к внешней среде системы

Сервер баз данных или сервер приложений должен обеспечивать:

…

Требования к хранению данных

База данных «Система» должна содержать следующие данные:

· Данные о планировании учебно-методической работы;

…

Требования к отдельным подсистемам

Учебно-методическая работа

Функции заведующего кафедрой

· Создание плана учебно-методической работы на учебный семестр, заполнения, редактирования и удаления данных плана;

…

Состав и содержание работ по созданию Системы

Разработать модель БД, позволяющую хранить и обрабатывать все необходимые…

…

Приемо-сдаточные испытания Системы

После завершения всех работ по разработке компонентов, настройке подсистем и

…

Внесение корректировок в программный продукт, связанных с ошибками в Системе

Все ошибки, которые будут выявлены в работе Системы в течении 12 месяцев

…

Тестирование

Перед сдачей Модулей и Компонент Заказчику для выявления возможных сбоев в работе

…

Порядок контроля и приемки Системы

Для проверки выполнения заданных функций Системы, определения и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик Системы, выявления и устранения недостатков в действиях Системы и в разработанной документации, поэтапного контроля над ходом разработки должны быть проведены следующие виды испытаний:

· Предварительные;

…

Процедуры тестирования и контроля качества

При проведении испытаний должны использоваться следующие типы процедур тестирования и контроля качества:

· функциональное тестирование - тестирование ПОна соответствие функциональным спецификациям;

…

Общие требования к приемке работ

Сроки и место приемки, порядок приемки работ определяются в соответствии с настоящим ТЗ.

…

Требования к документированию

Требования к проектной документации

Состав и комплектность проектной документации должна соответствовать требованиям ГОСТ 34.201-89.

Перечень документации по созданию системы включает:

· Описание информационного обеспечения системы (П5);

…

Диаграмма вариантов использования

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (usecase) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

Вариант использования

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 1).

Рис. 1. Графическое обозначение варианта использования

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

Каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемую сущность или систему по запросу пользователя (актера).

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

Актеры

Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Стандартным графическим обозначением актера на диаграммах является фигурка «человечка», под которой записывается конкретное имя актера (рис. 2).

Рис. 2. Графическое обозначение актера

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

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

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

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

Интерфейсы

Интерфейс (interface) служит для спецификации параметров модели, которые видимы извне без указания их внутренней структуры. Применительно к диаграммам вариантов использования, интерфейсы определяют совокупность операций, которые обеспечивают необходимый набор сервисов или функциональности для актеров. Интерфейсы не могут содержать ни атрибутов, ни состояний, ни направленных ассоциаций. Они содержат только операции без указания особенностей их реализации. Формально интерфейс эквивалентен абстрактному классу без атрибутов и методов с наличием только абстрактных операций.

На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рис. 3, а). В качестве имени может быть существительное (например, «датчик», «сирена», «видеокамера»), но чаще строка текста (например, «запрос к базе данных», «форма ввода», «устройство подачи звукового сигнала»). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor (рис. 3, б).

Рис. 3. Графическое изображение интерфейсов на диаграммах вариантов использования

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

Рис. 4. Графическое изображение взаимосвязей интерфейсов с вариантами использования

⇐ Предыдущая 12