Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Диаграмма последовательности для Use Case



 

Диаграмма последовательностей отражают временную зависимость событий, происходящих в рамках варианта использования. Стрелки соответствуют сообщениям, передаваемым между действующим лицом и объектами для выполнения требуемой функции. [1]

Диаграммы последовательности сделаны для четырех вариантов использования (см. приложение N).

1. Диаграмма последовательности для варианта использования «Регистрация в системе» (см. рисунок N1). К примеру, можно прокомментировать данную диаграмму:

На диаграмме изображен один актер – участник, один контроллер (Контроллер обработки данных) и две сущности (База данных User и интерфейс взаимодействия (форма «Регистрация нового участника»)).

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

2. Диаграмма последовательности для варианта использования «Авторизация в системе» (см. рисунок N2). К примеру, можно прокомментировать данную диаграмму:

На диаграмме изображен один актер – участник (верно и для актера «Администратор»), один контроллер (Контроллер взаимодействия с БД User) и две сущности (База данных User и интерфейс взаимодействия (форма «Авторизация в системе»)).

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

3. Диаграмма последовательности для варианта использования «Формирование отчета» (см. рисунок N3).

4. Диаграмма последовательности для варианта использования «Участие в турнире» (см. рисунок N4).

Диаграмма классов по уровням

 

Диаграмма классов описывает структуру системы, показывая её классы, их атрибуты и операторы, а также взаимосвязи этих классов.[2]

Архитектуры клиент - сервер в системах управления предприятием связана с делением любой прикладной программы на три основных компонента или слоя:

1. База данных – ER модель.

2. Компоненты визуализации данных – интерфейсы.

3. Компоненты бизнес логики – контроллеры.

Как уже говорилось в главе 4 «Разработка концепции АСОИУ», данное деление удовлетворяет основным принципам проектирования архитектуры:

1. Принцип «слабой вешней связанности» – количество связей между отдельными подсистемами должно быть минимальным;

2. Принцип «сильного внутреннего сцепления» – связность отдельных частей внутри каждой подсистемы должна быть максимальной.

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

1. Слой данных – ER модель. Слой данных описывает структуру таблиц хранящихся в БД. Атрибуты классов соответствуют полям таблицы.[1] Диаграмма слоя данных представлена в приложении P, рисунок P1. ER модель включает 6 сущностей:

1. Таблица «User» - таблица пользователей (логин, пароль и т.д.);

2. Таблица «Message» - таблица, которая хранит в себе сообщений с сайта;

3. Таблица «Role» - таблица с правами доступа (т.е. роли: «Администратор», «Пользователь (участник турнира)»);

4. Таблица «Event» - таблица (список) турниров (т.е. хранятся турниры со ссылкой на таблицу «Problem»);

5. Таблица «Problem» - таблица с вопросами (условиями задач) и ответами для турниров;

6. Таблица «Player» - таблица, в которой хранятся результаты турниров.

2. Слой представления – интерфейсы. Слой представлений описывает формы, существующие в системе. Каждый класс соответствует своей форме. Диаграмма слоя представления изображена в приложении P, рисунок P2.

Список форм, существующих в системе:

· Форма авторизации в системе;

· Форма регистрации в системе;

· Форма обратной связи;

· Форма записи на турнир;

· Форма ввода ответа;

· Форма создания предварительного турнира;

· Форма добавления задач;

· Форма активации турнира.

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

 

3. Сервисный слой – контроллеры (см приложение P рисунок P3). Сервисный слой описывает элементы бизнес – логики, т.е. основные классы, методы которых, выполняют функциональные требования. Каждый класс содержит методы связанные с определенной работой. Контроллеры принимают поступающие от форм запросы, и обрабатывают их (см. приложение N рисунки N1, N2, N3 и N3). По характеру выполняемых функций контроллеры разделены на пять классов. Атрибутов у классов контроллеров в диаграмме сервисного слоя нет.

Список классов контроллеров:

· Контроллер взаимодействия с БД User;

· Контроллер взаимодействия с БД Event;

· Контроллер логики данных;

· Контроллер обработки данных;

· Контроллер формирования отчета.

 


Заключение

 

В результате курсового проектирования, поставленные перед разработчиком задачи, были выполнены. Для Югорского физико-математического лицея – интерната была спроектирована программная система проведения соревнований школьников по различным общеобразовательным предметам.

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

1. Администратору системы:

· Возможность создания ограниченных по времени турниров по различным общеобразовательным предметам (предполагается, что в рамках общего времени проведения карусели на решение каждой задачи будет предоставляться не ограниченное время) и работы над ними, а именно:

- Добавление и редактирование (при необходимости) условий задач и ответов к ним (предполагается создание вопросов с любым контентом);

- Активация, деактивация или удаление необходимого турнира (с возможностью установления пароля для участия в турнире);

· Возможность одновременного проведения нескольких турниров;

· Возможность автоматизированной проверки введенных ответов на задачу и подсчета результатов.

· Возможность автоматического вычисления статистики по соревнованию (по его завершению соответственно);

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

· Возможность изменения прав доступа любого пользователя в системе;

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

2. Участнику турнира:

· Возможность быстрой и удобной регистрации/авторизации в системе;

· Возможность просмотра списка активных или предстоящих турниров, а так же информации о них.

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

· Возможность просмотра предварительных результатов и конечных (по завершению турнира);

· Возможность просмотра архива прошедших турниров и их результатов (список участников и занятых ими мест);

· Возможность связи с администратором (отправка сообщения).

При обследовании объекта автоматизации с использованием конструктивной модели стоимости COCOMO была вычислена оценка затрат на проектирование системы. Трудозатраты составили примерно 11, 4 (чел-мес), а время, которое понадобится для разработки системы одним человеком, составляет 6 месяцев и 9 дней.

На этапе формирования требований к проектируемой АСОИУ были составлены два нормативных документа:

1. План управления программным проектом в соответствии со стандартом IEEE 1058.1-1987.

2. Техническое задание на создание АСОИУ, оформленное в соответствии с ГОСТ 34.602 – 89.

Были построены диаграммы IDEF0, DFD, IDEF3 модели «AS-IS» и «TO-BE», а также UML-диаграммы:

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

2. Диаграммы последовательности вариантов использования.

3. Диаграмма деятельности для системы в целом.

4. Диаграммы классов по уровням (ER модель, слой представления (интерфейсы), сервисный слой (контроллер)).

Был разработан эскиз ГПИ. Создан макет типовой формы и описана диаграмма состояний форм системы.

В процессе разработки концепции АСОИУ была аргументировано выбрана клиент-серверная архитектура системы.

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

 

 


Список используемой литературы

 

  1. Мелихов А. Ю. Проектирование автоматизированных систем обработки информации и управления: Методические указания к лабораторным работам/ Сост. А. Ю. Мелихов– Ханты-Мансийск, Югорский гос. ун-т, РИЦ ЮГУ, 2010. – 172 с.
  2. Мелихов А. Ю. Проектирование автоматизированных систем обработки информации и управления: Методические указания по курсовому проектированию / Сост. А. Ю. Мелихов– Ханты-Мансийск, Югорский гос. ун-т, РИЦ ЮГУ, 2009. – 63 с.
  3. ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения. – Введ. 1992–01–01. – М.: Изд-во стандартов, 1992. – 14 с.
  4. ГОСТ 24.103-84. Автоматизированные системы управления. Основные положения. – Введ. 1985–07–01. – М.: Изд-во стандартов, 1985. – 2 с.
  5. ГОСТ 24.104-85. Автоматизированные системы управления. Общие требования. – Введ. 1987–01–01. – М.: Изд-во стандартов, 1987. – 7 с.
  6. ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств. – Введ. 1999–12–23. – М. : Изд-во стандартов, 2000. – 84 с.
  7. ГОСТ 24.602-86. Состав и содержание работ по стадиям создания. – Введ. 1988–01–01. – М.: Изд-во стандартов, 1988. – 6 с.
  8. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. – Введ. 1992–01–01. – М.: Изд-во стандартов, 1992. – 3 с.
  9. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. – Введ. 1990–01–01. – М.: Изд-во стандартов, 1990. – 6 с.
  10. Фаулер М. UML. Основы / М. Фаулер. – СПб: Символ-Плюс, 2004. – 192 с.
  11. Официальный сайт LMS Moodle. [http: // moodle.org/]
  12. Официальный сайт GNU. [http: //www.gnu.org/]
  13. Свободная энциклопедия [http: //ru.wikipedia.org]
  14. Мясникова Т.С., Мясников С.А. Система дистанционного обучения MOODLE. – Харьков: Издательство Шейниной Е.В., 2008. – 232 с., ил.
  15. Интернет Карусель [http: //karusel.desc.ru/]

 

 


Приложение A

Структурно-функциональная модель системы. IDEF0 «AS - IS»

Рисунок А1. Диаграмма IDEF0. Модель «Чёрный ящик»


Рисунок А2. Декомпозиция контекстной диаграммы «Система проведения турниров»


Рисунок А3. Диаграмма декомпозиции функционального блока «Подготовка турнира»


Рисунок А4. Диаграмма декомпозиции функционального блока «Подготовка места для проведения турнира»

Рисунок А5. Диаграмма декомпозиции функционального блока «Создание списка участников турнира»

Рисунок А6. Диаграмма декомпозиции функционального блока «Проведение турнира»

Рисунок А7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира»

Рисунок А8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов»

Приложение B

Диаграмма потоков данных системы по методологии DFD («AS - IS»)

Рисунок B1. Диаграмма DFD. Модель «Чёрный ящик»

Рисунок B2. Декомпозиция контекстной диаграммы «Система проведения турниров»

Рисунок B3. Диаграмма декомпозиции функционального блока «Подготовка турнира»

Рисунок B4. Диаграмма декомпозиции функционального блока «Подготовка места для проведения турнира»

Рисунок B5. Диаграмма декомпозиции функционального блока «Создание списка участников»

Рисунок B6. Диаграмма декомпозиции функционального блока «Проведение турнира»

Рисунок B7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира»

Рисунок B8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов»

Приложение C

Структурно-функциональная модель системы по методологии IDEF0 («TO - BE»)

Рисунок C1. Диаграмма IDEF0. Модель «Чёрный ящик»


Рисунок C2. Декомпозиция контекстной диаграммы «Автоматизированная система проведения турниров»


Рисунок C3. Диаграмма декомпозиции функционального блока «Подготовка заданий»


Рисунок C4. Диаграмма декомпозиции функционального блока «Конфигурирование турнира»

Рисунок C5. Диаграмма декомпозиции функционального блока «Создание списка участников турнира»

Рисунок C6. Диаграмма декомпозиции функционального блока «Проведение турнира»

Рисунок C7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира»

Рисунок C8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов»

Приложение D

Диаграмма потоков данных системы по методологии DFD («TO - BE»)

Рисунок D1. Диаграмма DFD. Модель «Чёрный ящик»

Рисунок D2. Декомпозиция контекстной диаграммы «Автоматизированная система проведения турниров»

Рисунок D3. Диаграмма декомпозиции функционального блока «Подготовка заданий»

Рисунок D4. Диаграмма декомпозиции функционального блока «Конфигурирование турнира»

Рисунок D5. Диаграмма декомпозиции функционального блока «Создание списка участников»

Рисунок D6. Диаграмма декомпозиции функционального блока «Проведение турнира»

Рисунок D7. Диаграмма декомпозиции функционального блока «Анализ проведенного турнира»

Рисунок D8. Диаграмма декомпозиции функционального блока «Создание и публикация отчетов»

Приложение E

Диаграмма последовательности системы. Методология IDEF3 «TO-BE»

Рисунок E1. Диаграмма последовательности системы «Система проведения турниров»


Приложение G

(обязательное)

 

IEEE 1058.1-1987 ПЛАН УПРАВЛЕНИЯ ПРОГРАММНЫМ ПРОЕКТОМ

(SOFTWARE PROJECT MANAGEMENT PLAN – SPMP)

 

Утверждаю ____________

Дата ____________

 

01.09.11 Н.А. Аристов: Начало работы над КП

02.09.11 Н.А. Аристов: Получение задания на КП

09.09.11 Н.А. Аристов: Проведение обследования объекта автоматизации

27.09.11 Н.А. Аристов: Формирование требований к АСОИУ

14.10.11 Н.А. Аристов: Разработка концепции АСОИУ

25.10.11 Н.А. Аристов: Эскизный проект

16.12.11 Н.А. Аристов: Создание первой версии

13.02.12 Н.А. Аристов: Доработка первой версии

22.02.12 Н.А. Аристов: Проверка для выпуска

27.02.12 Н.А. Аристов: Окончательное форматирование

09.03.12 Н.А. Аристов: Выпуск

 

1. Введение

1.1. Обзор проекта

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

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

1.2. Результирующие артефакты проекта

Следующие материалы должны быть поставлены в указанные сроки.

Версия 1 (прототип) с документацией — третья неделя двенадцатого месяца.

Версия 2 с документацией — вторая неделя второго месяца.

Документация включает в себя SPMP.

Аббревиатуры определены в разделе 1.5.

1.3. Развитие SPMP

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

1.4. Ссылочные материалы

Все необходимые стандарты IEEE опубликованы в сборнике стандартов IEEE.

1.5. Аббревиатуры

IEEE (Institute of Electrical and Electronics Engineers) – институт инженеров по электротехнике и радиоэлектронике.

QA (Quality Assurance) – контроль качества.

SPMP (Software Project Management Plan) – план управления программным проектом (данный документ).

USDP (Unified Software Development Process) – унифицированный процесс разработки программного обеспечения.

SRS (Software Requirements Specification) – спецификация требований к программному обеспечению.

SDD (Software Design Document) – проектная документация программного обеспечения.

 

2. Организация проекта

2.1. Модель процесса

Первые две версии проекта будут выполнены с использованием спирального процесса разработки, по одной итерации на версию. Итерации проводятся в соответствии с USDP. Согласно USDP, итерации классифицируются на начальные итерации, итерации проектирования, конструирования и перехода. Первая итерация будет состоять только из обследования объекта автоматизации и формирования требований к АСОИУ. Количество последующих итераций и состав будут определены после того, как будет готова первая итерация.

a. Организационная структура

На рисунке G1 изображена типовая структура технологии подготовки и проведения тестирования учащихся.

 

 

Рисунок G1. – Структура технологии подготовки и проведения тестирования учащихся

 

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

 

Рисунок G2. Организация проекта

 

2.3. Организационные рамки и взаимосвязи

Не предусмотрено.

2.4. Ответственность за проект

Ответственность участников проекта показана в таблице G1. Ответственность за документ подразумевает следующее:

- документ должен быть создан вовремя;

- лидер команды определяет, кто пишет документ;

- документ поддерживается в актуальном состоянии.

 

Таблица G1. Ответственность участников проекта

Участник Лидер команды Ответственный за
конфигурацию качество требования проектирование
Отвечает за документ SPMP SCMP SQAP SRS SDD

 

3. Управляющий процесс

3.1. Цели и приоритеты

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

3.2. Допущения, зависимости и ограничения

Нет.

3.3 Управление рисками

Информация об идентификации и обработки рисков заносится в таблицу G2. Описание рисков приведено в пояснительной записке по курсовому проекту, раздел 2.2 «План управления программным проектом».

 

Таблица G2. Идентификация и обработка рисков

№№ Название Вероятность возникновения риска, 1-10 Ущерб, 1-10 Стоимость устранения, 1-10 Итоговый приоритет План устранения Ответственный за исправление Дата завершения
Отсутствие навыков программ-мирования на C# (11-10)* (11-9)*7=14 Изучение литературы, посвященной языку программирования C# Н.А. Аристов 20.01.12
Отсутствие стабильности в проведении собраний с заказчиком (11-7)* (11-7)*5=45 Составление плана-графика очередных собраний и фиксирование сроков их проведения Н.А. Аристов 10.12.11
Малый опыт проектирования баз данных (11-10)* (11-10)* 10=10 Воспользоваться помощью специалистов в данной области. Н.А. Аристов 20.01.12

 

3.4. Механизмы мониторинга и контроля

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

3.5. План расстановки кадров

Назначение ролей указано в таблице G3. Каждый участник команды имеет дополнительные обязанности по резервированию и инспектированию.

 

Таблица G3. Назначение ролей участников проекта

Участник Лидер команды Ответственный за
конфигурацию качество требования проектирование
Н.А. Аристов ˅ ˅ ˅ ˅ ˅

 

4. Технический процесс

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

4.1. Методы, инструменты и технологии

• Реализация ведется на языке C# (С Sharp). Во всех случаях используется объектно-ориентированный подход.

• Средство реализации – ASP.NET MVC.

• ORM (Object – relational mapping) – Entity Framework 4.1.

4.2. Функции сопровождения проекта

Сопровождением проекта будет заниматься лидер проекта.

 

5. Распределение работ, план-график и бюджет

5.1. Распределение работ

Основные работы выполняются совместно всеми участниками команды: проведение обследования объекта автоматизации, формирование требований к проектируемой АСОИУ, разработка концепции АСОИУ, разработка ТЗ. При разработке эскизного проекта работы, связанные с проектированием модели данных, а также работы, связанные с проектированием пользовательского интерфейса, возлагаются на Аристова Н.А. Инспектирование необходимо производить всем участникам команды.

5.2. Зависимости

Нет.

5.3. Потребности в ресурсах

Аппаратные ресурсы составят один компьютер с процессором Intel Dual-Core 3, 0 ГГц (так же не менее 2 Гбайт RAM и не менее 16 Гбайт свободного пространства на жестком диске) и операционной системой Windows Server 2008 R2 с программным обеспечением:

• Сервер IIS 7.5.

• СУБД MSSQL 2008.

5.4. Выделение бюджета и ресурсов

На проектирование информационной системы выделено четыре месяца.

5.5. План-график

План график (диаграмма Ганта) приведен на рисунке G3.

Рисунок G3. Диаграмма Ганта


Приложение H

(обязательное)

 

Техническое задание

 

1. Общие сведения

1.1. Настоящее техническое задание описывает задачу создания автоматизированной системы проведения турниров для школьников с нестандартной системой проведения и подсчета очков по различным общеобразовательным предметам.

1.2. Заказчик проекта: Алексеев А.В., Югорский физико-математический лицей – интернат (до 2007 г. бывший ЮФМШ), г. Ханты – Мансийск.

1.3. Основанием для создания ИС являются результаты экспресс – обследования и задание на курсовой проект.

1.4. Сроки проведения работ: сентябрь 2011 – март 2012.

 

2. Назначение и цели создания системы

2.1. Назначение автоматизированной системы

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

2.2. Цели создания автоматизированной системы:

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

 

3. Характеристика объектов автоматизации

3.1. Объектом автоматизации в данном курсовом проекте является деятельность преподавательского состава учебного заведения (среднего образования) в организации проведения соревнований для школьников с нестандартной системой проведения и подсчета очков по различным общеобразовательным предметам.

 

4. Требования к системе

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

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

4.1.1.2. Система может функционировать в двух режимах, которые определяются аутентификацией пользователя:

· Режим Администратора – Создание/редактирование/проведение соревнований (турниров). Работа с базами данных пользователей, турниров, задач и ответов к ним, результатов проведения турниров.

· Режим Участника – участие в соревновании (турнире).

4.1.2. Требования к персоналу

4.1.2.1. Система должна обслуживаться одним человеком на протяжении всего рабочего цикла.

4.1.2.2. Квалификация пользователей:

· Администратор – углубленные знания ПК, умение пользоваться любым интернет - браузером, знание правил использования системы, знание руководства, опыт программирования на языке C# (C Sharp). Базовые знания технологий IIS 7.5, MSSQL 2008, Windows Server 2008 r2, ASP.NET MVC, Entity Framework 4.1.

· Участник – базовые знания ПК, умение пользоваться любым интернет – браузером, знание правил использования системы, знание руководства.

4.1.3. Показатели назначения:

4.1.3.1. Должно достигаться изменение следующих показателей:

· Количество хранимых записей в таблицах базы данных (до 1.000.000).

· Формат вывода отчетов.

4.1.4. Требования к основным показателям системы:

4.1.4.1. Безопасность достигается за счет правильных настроек локальной сети и надежности функционирования используемой СУБД.

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

4.2. Требования к функциям

4.2.1. Перечень подлежащих автоматизации задач

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

· Система должна предоставлять возможность создавать ограниченные по времени турниры по различным общеобразовательным предметам (предполагается, что в рамках общего времени проведения карусели на решение каждой задачи будет предоставляться не ограниченное время) и осуществление работы над ними, а именно:

o Добавлять и редактировать (при необходимости) условия задач и ответов к ним (предполагается создание вопросов с любым контентом);

o Активировать, деактивировать или удалять необходимый турнир (с возможностью установления пароля для участия в турнире);

· Система должна предоставлять возможность одновременного проведения нескольких турниров;

· Система должна предоставлять возможность автоматической проверки введенных ответов на задачу и подсчета результатов.

· Система должна предоставлять возможность автоматического вычисления статистики по соревнованию (по его завершению соответственно);

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

· Система должна предоставлять возможность изменять права доступа любого пользователя в системе;

· Система должна предоставлять возможность быстрой и удобной регистрации/авторизации в системе;

· Система должна предоставлять возможность просматривать список активных или предстоящих турниров, а так же информации о них.

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

· Система должна предоставлять возможность просматривать предварительные результаты и конечные (по завершению турнира);

· Система должна предоставлять возможность просматривать архив прошедших турниров и их результатов (список участников и занятых ими мест);

· Система должна предоставлять возможность связи с администратором (отправка сообщения).

4.2.2. Перечень нефункциональных требований

· Производительность. Требования к производительности определяют временные ограничения, которые должны быть выполнены в программе. Для ускорения обмена данными необходимо использовать MS SQL БД, в которой представлены таблицы. Для ускорения обработки запросов к БД ввести " индексы". Для ускорения ответа установить Кеш на некоторые страницы. Требования к производительности связаны с обеспечением комфортности работы пользователей.

· Надежность и безопасность. Требования надежности определяют надежность в измеряемых величинах. Для решения вопроса обеспечения безопасности системы, связанного с несанкционированным доступом в систему, должна быть предусмотрена предварительная идентификация пользователей перед началом работы, посредством ввода личного логина и пароля. Также необходимо, чтобы клиент - серверное приложение удерживало 100 запросов в секундуи функционировало 24 часа в сутки.

· Обработка ошибок. Система должна проверять корректность введенных пользователем данных. На всех формах две проверки " клиентская" (написанная на Javascript) и " серверная" на уровне приложения. В случае возникновения ошибки выдавать соответствующее информационное сообщение. Также, дополнительно, необходимо использовать триггеры в БД.

· Интерфейсные требования. Создать панель администрирования для удобного управления.

· Ограничения. Не обозначены.

4.2.3. Требования к качеству реализации каждой функции, к форме представления выходной информации:

4.2.3.1. Выходная информация представляется в виде таблиц БД.

4.2.4. Перечень и критерии отказов

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

4.2.4.1. Отказы в системе могут возникать по причине сбоев работы используемой СУБД.

4.2.4.2. Неисправность в аппаратных средствах.

4.2.4.3. Неверная конфигурация операционной системы.

4.3. Требования к видам обеспечения

4.3.1. Требования к информационному обеспечению

4.3.1.1. Все данные организованы в таблицы и хранятся в базе данных. В качестве СУБД используется MSSQL 2008.

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

4.3.2. Требования к лингвистическому обеспечению

4.3.2.1. Используется язык программирования C# (С Sharp). Причины данного выбора обусловлены тем, что С# - это очень удобный и мощный язык среды разработки ПО Microsoft Visual Studio 2010 (которая в свою очередь не требует установки дополнительного ПО) и в сочетании с технологией.Net – это лучший подход для написания ПО под Windows на сегодняшний день.

4.3.3. Требования к программному обеспечению

4.3.3.1. ИС должна функционировать под управлением операционной системы Windows Server 2008 R2.

4.3.3.2. ORM (Object – relational mapping) – Entity Framework 4.1.

4.3.3.3. Сервер IIS 7.5.

4.3.3.4. СУБД MSSQL 2008

4.3.3.5. Пакет.Net 4.0

4.3.4. Требования к техническому обеспечению

Рабочее место администратора (Минимальные требования):

- Клавиатура, мышь;

- Материнская плата;

- Жесткий диск (не менее 16 Гбайт свободного пространства на жестком диске);

- Процессор AMD/Intel с тактовой частотой не менее 2000 МГц;

- Видеокарта с объемом видеопамяти не менее 32 Мб;

- Оперативная память не менее 2 Гб;

 

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

5.1. Перечень стадий и этапов работ

5.1.1. Проведение обследования объекта автоматизации:

· Опрос заказчика проекта.

· Сбор документов.

· Формирование С-требований к ИС.

5.1.2. Формирование детальных требований к ИС.

5.1.3. Разработка концепции ИС.

5.1.4. Разработка технического задания.

5.1.5. Детальное проектирование.

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

План будет описан при помощи диаграммы Ганта в приложении G к ПЗ.

 

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

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

Прием проекта будет произведен руководителем проектирования.

 

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

Не обозначены

 

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

8.1. Перечень подлежащих разработке документов

8.1.1. Техническое задание.

8.1.2. План управления проектом.

 

9. Источники разработки

Основанием для разработки автоматизированной системы являются следующие документы:

• ГОСТ 34.602-89 «Техническое задание на создание АС»;

• задание на курсовой проект;

• план управления проектом;

 


Приложение J

Рисунок J1. Сценарий выполнения (диаграмма Use Case)

Приложение K

Рисунок K1. Диаграмма состояний (последовательность форм)

Приложение L

 

 

Рисунок L1. Макетные виды страниц:

A – главная страница, вкладка «Главная»; B – форма обратной связи; С – главная страница, вкладка «Правила»; D – главная страница, вкладка «Архив»; E – страница информации о турнире; F – страница информации об участниках


Поделиться:



Последнее изменение этой страницы: 2017-05-11; Просмотров: 493; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.226 с.)
Главная | Случайная страница | Обратная связь