Проектирование программной системы проведения соревнований школьников по различным предметам

 

ДИПЛОМНЫЙ ПРОЕКТ

Дисциплина: «Технология проектирования и разработки программного обеспечения»

на тему: «Проектирование программной системы проведения соревнований школьников по различным предметам»

Список сокращений

АС- автоматизированная система

АСУ- автоматизированная система управления

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

БД- база данных

ГПИ- графический пользовательский интерфейс

ДО- дистанционное образование

ИС- информационная система

МСФО- международные стандарты финансовой отчётности

ПО- программное обеспечение

СУБД- система управления реляционными базами данных

ЦДО- центр дистанционного образования

ЮНЕСКО- организация Объединённых Наций по вопросам образования, науки и культуры.

Аннотация

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

Предмет проектирования - разработка АС «Карусель ikobu».

Пояснительная записка к проекту состоит из введения, 5 глав и заключения.

Во введении представлено краткое описание предметной области, обоснована актуальность исследования работы, определена цель создания АСОИУ и сформулированы задачи для ее достижения.

В первой главе «Проведение обследования объекта автоматизации» проводится обзор аналогов проектируемой АСОИУ, делается вывод о целесообразности ее разработки, анализируются данные об объекте автоматизации, определяется состав процессов, подлежащих автоматизации, а также проводятся первоначальные оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ (на основе диаграммы потоков данных системы (DFD «AS - IS»).

Во второй главе «Документация проекта» рассматривается ряд нормативных документов, использованных при подготовке проекта.

В третьей главе «Формирование требований к проектируемой АСОИУ» формулируются цели и задачи создания АСОИУ, производятся выбор и обоснование состава процессов, подлежащих автоматизации, формирование требований к проектированной АСОИУ, проектирование ГПИ, а также, на основе диаграммы потоков данных системы (DFD «TO - BE»), проводятся дополнительные оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ.

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

В пятой главе «Эскизный проект» рассматривается структура автоматизированной системы, и разрабатываются ее предварительные проектные решения.

В заключении подведены общие итоги проделанной работы и изложены основные выводы.

Пояснительная записка изложена на 95 страницах, включает 61 рисунок, 11 таблиц и 13 приложений, представляющих собой документацию проекта и диаграммы IDEF0, DFD, IDEF3, ERD, UML. Библиографический список включает 15 наименований используемой литературы.

Содержание

Список сокращений

Введение

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

.1 Описание и список бизнес процессов

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

.3 Диаграмма потоков данных системы. Методология DFD: AS - IS

.4 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: AS - IS

.5 Сбор и анализ данных об отечественных и зарубежных аналогах

Глава 2. Документация проекта

.1 Исходные материалы и документы по созданию АСОИУ

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

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

Глава 3. Формирование требований к проектируемой АСОИУ

.1 Анализ и выявление ключевых процессов

.1.1 Формулирование целей и задач создания АСОИУ

.1.2 Cостав процессов, подлежащих автоматизации

.2 Структурно - функциональная модель системы. Методология IDEF0: TO - BE

.3 Диаграмма потоков данных системы. Методология DFD: TO - BE

.4 Диаграмма последовательности системы. Методология IDEF3

.5 С - требования

.6 D - требования

.7 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: TO - BE

.8 Проектирование графического пользовательского интерфейса (ГПИ)

.8.1 Описание последовательности форм (диаграмма состояний)

.8.2 Описание макета типовой формы

Глава 4. Разработка концепции АСОИУ

Глава 5. Эскизный проект

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

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

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

Заключение

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

Введение

Международная комиссия ЮНЕСКО определяет два основных принципа современного образования: "образование для всех" и "обучение в течение всей жизни". Эти принципы, несомненно, верны, но в суровых российских условиях и под влиянием стереотипов возникает несколько проблем [13]:

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

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

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

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

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

Одними из самых больших плюсов ДО являются [14]:

1. Для учащихся:

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

система оценки знаний (электронные тесты) объективна и независима от преподавателя;

. Для преподавателей:

Возможность автоматизировать систему оценки знаний;

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

. Для учебных заведений:

повышение престижа;

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

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

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

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

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

Разрешение всех вышеперечисленных проблем обусловило выбор темы моего проекта: «Проектирование программной системы проведения соревнований школьников по различным предметам», и разработку АС «Карусель ikobu».

Целью создания АСОИУ является повышение эффективности работы преподавательского состава учебного заведения (среднего образования) в организации проведения соревнований для школьников, в том числе и младших классов, по различным общеобразовательным предметам для развития их познавательной деятельности.

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

) Обследовать объект автоматизации.

) Произвести детальный анализ аналогов проектируемой системы (дистанционных систем тестирования).

) Сформировать требования к проектируемой системе.

) Разработать концепцию автоматизированной системы.

) Провести детальное проектирование системы.

) Разработать модель данных.

) Разработать прототип пользовательского интерфейса.

) Составить комплект нормативных документов.

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

1.1 Описание и список бизнес процессов

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

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

Для обследования объекта автоматизации составил матрицу бизнес - процессов, в которой отображены основные бизнес - процессы системы и соответствующие им примеры элементарных бизнес - процессов (см. таблицу 1):

Таблица 1. Матрица бизнес - процессов

Основные бизнес - процессыЭлементарные бизнес-процессы1) Подготовка турнира- Сбор необходимых ресурсов для разработки задач турнира; - Формирование пакета задач; - Формирование папки бланков ответов и заданий турнира;2) Подготовка места для проведения турнира- Поиск необходимого места для проведения турнира; - Подготовка территории для проведения турнира; 3) Создание списка участников турнира- Ознакомление с правилами; - Принятие решения об участии в турнире; - Формировании списка участников турнира;4) Проведение турнира- Запуск турнира; - Выдача заданий турнира; - Написание ответов на вопросы турнира; - Проверка решений;5) Анализ проведенного турнира- Предварительный подсчет; - Рассмотрение жалоб; - Перерасчет результатов; - Формирование окончательных результатов;6) Создание и публикация отчетов- Принятие решения о закрытии турнира; - Формирование отчета о прошедшем турнире; - Публикация и информирование о результатах турнира; - Анализ окончательных результатов;

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

Основная идея методологии IDEF0 заключается в организации моделируемого процесса в виде совокупности взаимосвязанных функций. Функции строятся по иерархическому принципу, корнем иерархии является основная функция моделируемого процесса.

Модель AS - IS. Описание разработки IDEF0. - IS - описывает состояние моделируемой предметной области на момент создания модели. Графическое построение модели начинается с контекстной диаграммы, которая отображает контекст функционирования моделируемой системы как единого целого. [2]

Итак, при обследовании объекта автоматизации построена модель «черного ящика» системы (см. приложение А рисунок А1) представляющую собой систему проведения турниров. На диаграмме:

. Вход: «Заявки на участие в турнире»; «Список доступных мест для проведения турнира»;

. Выход (результат функционирования системы): «Отказ от участия в турнире»; «Результаты проведения турнира»; «Отчет о прошедшем турнире»;

) Механизмы (ресурсы, необходимые для выполнения работы): «Администратор»; «Наблюдатели», «Секретарь», «Участники», «Жюри», «Преподаватель»

) Управление (управляющее воздействие): «Приказ о проведении турнира»; «Регламент турнира»;

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

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

Дерево функциональных блоков структурно - функциональной модели IDEF0 («AS - IS») представлено на рисунке 1:

Рисунок 1. Структурно - функциональная модель IDEF0 (AS-IS)

Как показано на рисунке 1:

. Функциональный блок «Подготовка турнира» включает в свой состав три функциональных блока (см. приложение А рисунок А3):

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

- Формирование пакета задач;

- Формирование папки бланков ответов и заданий турнира.

. Функциональный блок «Подготовка места для проведения турнира» включает в свой состав два функциональных блока (см. приложение А рисунок А4):

Поиск необходимого места для проведения турнира;

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

. Функциональный блок «Создание списка участников турнира» включает в свой состав три функциональных блока (см. приложение А рисунок А5):

Ознакомление с правилами;

Принятие решения об участии в турнире;

Формировании списка участников турнира;

. Функциональный блок «Проведение турнира» включает в свой состав четыре функциональных блока (см. приложение А рисунок А6):

Запуск турнира;

Выдача заданий турнира;

Написание ответов на вопросы турнира;

Проверка решений;

. Функциональный блок «Анализ проведенного турнира» включает в свой состав четыре функциональных блока (см. приложение А рисунок А7):

Предварительный подсчет;

Рассмотрение жалоб;

Перерасчет результатов;

Формирование окончательных результатов;

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

Принятие решения о закрытии турнира;

Формирование отчета о прошедшем турнире;

Публикация и информирование о результатах турнира;

Анализ окончательных результатов;

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

.3 Диаграмма потоков данных системы. Методология DFD: AS - IS

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

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

Модель AS - IS. Описание разработки DFD:

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

Рассмотрение объекта автоматизации как «черного ящика» системы «AS - IS», приведено в диаграмме потоков данных (см. приложение B рисунок B.1.) с использованием методологии DFD. В данной диаграмме:

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

) Конкретная функция системы или процесс - система проведения турниров.

) Источник/приемник данных от системы (внешняя сущность) - секретарь, преподаватель, жюри, участники турнира и т.д.

На декомпозирующих диаграммах будут иметь место накопители данных («Текущий турнир», «Место для турнира», «Список ворсов и ответов турнира» и т.д.) - пассивные объекты в составе диаграмм потоков данных, содержащие информацию, которая может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке.

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

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

Рисунок 2. Диаграмма потоков данных DFD (AS-IS)

В приложении B на рисунке B2 приведена диаграмма DFD (AS-IS), представляющая декомпозицию первого уровня модели «чёрного ящика» - «Система проведения турниров», включающая в свой состав шесть функциональных блоков: «Подготовка турнира», «Подготовка места для проведения турнира», «Создание списка участников турнира», «Проведение турнира», «Анализ проведенного турнира», «Создание и публикация отчетов» и как показано на рисунке 2:

. Функциональный блок «Подготовка турнира» включает в свой состав три функциональных блока (см. приложение B рисунок B3):

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

- Формирование пакета задач;

- Формирование папки бланков ответов и заданий турнира.

. Функциональный блок «Подготовка места для проведения турнира» включает в свой состав два функциональных блока (см. приложение B рисунок B4):

Поиск необходимого места для проведения турнира;

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

. Функциональный блок «Создание списка участников» включает в свой состав три функциональных блока (см. приложение B рисунок B5):

Ознакомление с правилами;

Принятие решения об участии в турнире;

Формировании списка участников турнира;

. Функциональный блок «Проведение турнира» включает в свой состав четыре функциональных блока (см. приложение B рисунок B6):

Запуск турнира;

Выдача заданий турнира;

Написание ответов на вопросы турнира;

Проверка решений;

. Функциональный блок «Анализ проведенного турнира» включает в свой состав четыре функциональных блока (см. приложение B рисунок B7):

Предварительный подсчет;

Рассмотрение жалоб;

Перерасчет результатов;

Формирование окончательных результатов;

. Функциональный блок «Создание и публикация отчетов» включает в свой состав четыре функциональных блока (см. приложение B рисунок B8):

Принятие решения о закрытии турнира;

Формирование отчета о прошедшем турнире;

Публикация и информирование о результатах турнира;

Анализ окончательных результатов;

Итак, для примера можно прокомментировать диаграмму декомпозиции функционального блока «Подготовка турнира» (см. приложение B рисунок B3.):

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

1.4 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: AS - IS

(Functional Points) - это методология оценивания функционального размера для оценки ожидаемой эффективности, проектируемой ИС, которая заключается в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. Затем это число можно использовать для оценки числа строк кода, стоимости и сроков проекта. [2]

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

Таблица 2. Информационные характеристики и их ранг

ХранилищаИнформационная характеристикаСсылкиЭлементы данныхРангТекущий турнирВнут. лог. файл78Средний (10)Текущий турнирВнешний ввод68Высокий (6)Текущий турнирВнешний вывод38Средний (5)Текущий турнирВнешний запрос28Средний (4)Место для турнираВнут. лог. файл23Низкий (7)Место для турнираВнешний ввод13Низкий (3)Место для турнираВнешний вывод13Низкий (4)Участники турнираВнут. лог. файл412Низкий (7)Участники турнираВнешний ввод112Низкий (3)Участники турнираВнешний вывод112Низкий (4)Список вопросов, ответов турнираВнут. лог. файл35Низкий (7)Список вопросов, ответов турнираВнешний ввод25Средний (4)Список вопросов, ответов турнираВнешний вывод25Средний (5)ОтчетыВнут. лог. файл28Низкий (7)ОтчетыВнешний ввод18Низкий (3)ОтчетыВнешний вывод28Средний (5)

Где:

1.Внешний ввод - элементарный процесс, перемещающий данные из внешней среды в приложение.

.Внешний вывод - элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду.

3.Внешний запрос - элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат - данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов.

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

Перейдем к расчету метрики - количества функциональных указателей FP. В таблицу 3 заносятся количественное значение характеристики каждого вида (по всем уровням сложности). Полученные в каждой характеристике значения суммируются, после чего формируется общее количество информационных характеристик. [2]

Таблица 3. Исходные данные для расчета FP - метрик

Имя характеристикиКоличествоНизкийСреднийВысокийИтогоВнешние вводы3 * 3 = 91 * 4 = 41 * 6 = 619Внешние выводы2 * 4 = 83 * 5 = 150 * 7 = 023Внешние запросы0 * 3 = 01 * 4 = 40 * 6 = 04Внутренние логические файлы4 * 7 = 281 * 10 = 100 * 15 = 038Внешние интерфейсные файлы0 * 5 = 00 * 7 = 00 * 10 = 00Общее количество:84

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

FP = Общее количество × (0,65+ 0,01 × ), (1)

где Fi - коэффициенты сложности. Каждый коэффициент может принимать следующие значения: 0 - нет влияния, 1 - случайное, 2 - небольшое, 3 - среднее, 4 - важное, 5 - основное.

Значение каждого - ого коэффициента определяется эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (см. таблицу 4).

Таблица 4. Определение системных параметров приложения

№Системный параметрЗначение1Передача данных32Распределенная обработка данных33Производительность44Распространенность используемой конфигурации25Скорость транзакций36Оперативный ввод данных47Эффективность работы конечного пользователя38Оперативное обновление49Сложность обработки210Повторная используемость411Легкость инсталляции312Легкость эксплуатации413Разнообразные условия размещения114Гибкость3Итого:43

Подставив значения из таблицы 3 в формулу 1, получим количество функциональных указателей:

FP = 84 × (0,65+ 0,01 × 43) = 90,72, (2)

После вычисления функционального размера FP формируются метрики производительности, качества и т. д. Для этого с помощью стандартных таблиц по функциональному размеру вычисляют количество строк кода (см. таблицу 5). [2]

Таблица 5. Языки программирования и количество их операторов на один FP

Язык программированияКоличество операторов (LOC) на один FPАссемблер320С128Паскаль90С++64Java/С#53Visual C++34Visual Basic32Delphi Pascal29Perl21FP - оценки легко пересчитать в LOC - оценки, а результаты пересчета зависят от языка программирования, используемого для реализации ПО. Подсчитаем количество строк для языка C#. Для этого количество функциональных указателей умножим на количество операторов языка C# на один FP, которое равно 53.

(3)

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

Для оценивания затрат труда и продолжительности проекта необходимо использовать конструктивную модель стоимости СОСОМО Барри Боэма. [2]состоит из иерархии трех последовательно детализируемых и уточняемых форм. Первый уровень - базовый (COCOMO Model 1: Basic), подходит для быстрых, ранних оценок стоимости разработки ПО и обладает неточностью вследствие некоторых факторов, которые невозможно учесть на ранних стадиях разработки. Средний уровень (COCOMO Model 2: Intermediate) учитывает эти факторы, тогда как детальный уровень (COCOMO Model 3: Advanced/Detailed) дополнительно учитывает влияние отдельных фаз проекта на его общую стоимость.

Подмодели СОСОМО могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

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

2.Полунезависимый тип - средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

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

В нашем случае ведётся разработка распространённого типа программного проекта. Уравнения базовой подмодели COCOMO имеют вид:

Е = [чел - мес]; (4)= [мес], (5)

где Е - затраты в человеко - месяцах, D - время разработки, KLOC - количество тысяч строк в программном продукте.

Коэффициенты а, b, с, d определяются по таблице 6.

Таблица 6 - Коэффициенты для базовой подмодели COCOMO

Тип проектааbcdРаспространенный2,41,052,50,38Полунезависимый3,01,122,50,35Встроенный3,61,202,50,32

Подставив коэффициенты a, b, c и d для распространенного типа проекта в формулы 4 и 5 получим:

[чел/мес]

[мес]6 месяцев и 15 дней

Полученные оценки позволят скорректировать сроки выполнения проекта.

1.5 Сбор и анализ данных об отечественных и зарубежных аналогах

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

Обзор показал, что существует множество подобных систем, одни из которых:

) Moodle - модульная объектно - ориентированная развиваемая обучающая среда, позволяющая создавать курсы, базирующиеся в Internet. Данная система относится к свободно распространяемому программному обеспечению [11].

Система дистанционного обучения Moodle реализует философию «педагогики социального конструкционизма» и ориентирована прежде всего на организацию взаимодействия между преподавателем и учениками, хотя подходит и для организации традиционных дистанционных курсов, а также поддержки очного обучения. Важнейшим достоинством системы является поддержка ряда международных стандартов в области образовательных ресурсов. [11]

СДО Moodle переведена на десятки языков, в том числе и русский и используется почти в 50 тысячах организаций из более чем 200 стран мира. В РФ зарегистрировано более 600 инсталляций. Количество пользователей Moodle в некоторых инсталляциях достигает 500 тысяч человек.

Лидером и идеологом системы является Martin Dougiamas из Австралии. Проект является открытым и в нем участвует и множество других разработчиков. Русификацию Moodle осуществляет команда добровольцев из России, Белоруссии и Украины.

Вывод по данной системе:

Использование системы Moodle не требует финансовых затрат на приобретение дополнительных программных продуктов и мы получим лицензионно чистое и на 100% легальное программное обеспечение для организации дистанционного обучения. Легальность использования гарантируется открытым лицензионным соглашением GNU General Public License. [12] Цель GNU GPL - предоставить пользователю права использовать, копировать, модифицировать и распространять программы. Но так как данная система содержит достаточно много кода (более 1000 строк), проще создать что-то новое, чем модифицировать данную систему, чтобы она соответствовала требованиям заказчика, описанных в пункте 3.5 «С - требования».

) Системы Ejudge, Dudge, DOMjudge. [13]- это система для проведения различных мероприятий, в которых необходима автоматическая проверка программ.

Поддерживаемые возможности:

·Ограниченные и неограниченные по времени турниры.

·Поддержка виртуальных турниров.

·Одновременное проведение нескольких турниров.

·Автоматическая регистрация участников турнира. Моделируемая регистрация участников турнира.

·и т.д.- это универсальная система для проведения олимпиад по программированию и другим предметам, написанная на Java и J2EE с использованием СУБД PostgresQL и распространяющаяся по лицензии GPL.

Основные возможности системы:

·Автоматизированная проверка исходных текстов решения на наборе тестов.

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

·Хранение информации о ходе соревнования, базы участников и их рейтинга.

·Вычисление статистики по соревнованию.

·Распределенная проверка решений, отправленных участниками, на нескольких проверяющих компьютерах.

·Проверка решений на Windows и Linux системах.

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

·Работа на любой платформе, на которой работает Java.

·и т.д.

Вывод по данным системам:

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

) eSkill [13] - online тесты для оценки профессиональных знаний, в т.ч.:

·бухгалтерские тесты (от рядового до главного бухгалтера);

·тесты по МСФО;

·тесты для экономистов и финансистов;

·тесты для юристов;

·IQ тесты.

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

·при приеме на работу;

·аттестации сотрудников;

·для планирования обучения и контроля результата.

Основные плюсы:

·объективность оценки;

·снижение общих затрат, связанных с оценкой персонала более чем в 10 раз.

Вывод по данной системе:

Данная система является коммерческим продуктом («закрытой») и внесение изменения в функциональность системы не возможно, так как исходный код не предоставляется вместе с системой. Конкретно для меня это очень критично, поэтому рассматривать данную систему - не имеет смысла.

) Alltests [13] - онлайн система тестирования и сертификации студентов.онлайн система Alltests, написанная на языке php, распространяется бесплатно (GNU General Public License) - это значит, что можно изменить ее исходный код (дается право использовать, копировать, модифицировать и распространять программы) и использовать для своих целей. Система очень универсальна - понимает почти все виды тестов.

Вывод по данной системе:

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

) Интернет Карусель [15] - соревнования по математике, информатике, русскому и английскому языкам, физике, географии, которое проводит ЦДО "Дистанционное обучение" (г.Москва) для всех желающих школьников в Российской Федерации и за её пределами.

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

Вывод по данной системе:

Можно назвать данную систему, как главный аналог разрабатываемой мной системы. Но у нее есть один, достаточно критичный недостаток, она тоже является коммерческим продуктом («закрытой») и внесение изменения в функциональность системы не возможно (естественно и размещение на собственном сервере). Именно поэтому, мне необходимо разработать систему - аналог данной.

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

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

·Функциональность системы будет полностью подходить по формату проведения турниров;

·Интерфейс будущей системы будет наиболее полно отвечать требованиям и характеристикам заказчика;

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

·И еще одна немаловажная причина: во многих аналогах слишком сложная система регистрации и авторизации, в то время как в проектируемой системе этот процесс будет прост и удобен.

После завершения этапа проектирования ИС, будет создано Web приложение в сочетании с СУБД, размещенное в сети Internet.

Глава 2. Документация проекта

.1 Исходные материалы и документы по созданию АСОИУ

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

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

·План управления программным проектом (Software Project Management Plan - SPMP) в соответствии со стандартом IEEE 1058.1-1987 [2];

·Техническое задание (ТЗ) в соответствии со стандартом ГОСТ 34.602-89 [2];

Иерархия нормативных документов, разрабатываемых в ходе проектирования, представлена на диаграмме (см. рисунок 3). Данная диаграмма представляет собой распределение документации по процессам жизненного цикла [2].

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

·ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» [3];

·ГОСТ 24.103-84 «Автоматизированные системы управления. Основные положения» [4];

·ГОСТ 24.104-85 «Автоматизированные системы управления. Общие требования» [5];

·ГОСТ Р ИСО/МЭК 12.207-99 «Информационная технология. Процессы жизненного цикла программных средств» [6];

·ГОСТ 24.602-86 «Автоматизированные системы управления. Состав и содержание работ по стадиям создания» [7];

·ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» [8];

·ГОСТ 34.602-89 «Автоматизированные системы. Техническое задание на создание автоматизированной системы» [9].

В ходе основного процесса разработки будет составлено техническое задание (ТЗ) в соответствии со стандартом ГОСТ 34.602-89.

В ходе процесса управления будет составлен план управления программным проектом (Software Project Management Plan - SPMP) в соответствии со стандартом IEEE 1058.1-1987.

Рисунок 3. Диаграмма распределения документации по процессам жизненного цикла

2.2 План управления программным проектом

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

Основное значение в управлении программным проектом имеет проблема управления рисками. [2]

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

Существуют два типа рисков:

1.риски, которых можно избежать или которые можно предотвратить (устранимые);

2.риски, которых невозможно избежать.

Управление риском состоит из нескольких действий:

1.идентификация;

2.планирование устранения;

.выбор приоритетов;

.устранение или уменьшение.

Основными факторами риска являются перечисленные ниже:

1.недостаточная вовлеченность в проект высшего руководства;

2.невозможность привлечения пользователей;

.непонимание требований;

.привлечение неадекватных пользователей;

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

.изменение области применения или целей проекта;

.нехватка знаний или навыков у персонала.

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

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

Техническое задание (ТЗ) на АСОИУ является основным документом, определяющим требования и порядок создания (развития или модернизации) автоматизированной системы, в соответствии с которым проводится разработка АСОИУ и ее приемка при вводе в эксплуатацию. ТЗ включает в себя системное описание расширенных требований к разрабатываемому изделию и составляется на основе исходного задания по проекту с учетом всей проведенной выше работы в отношении формулирования и спецификации требований. [2]

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

Техническое задание на создание АСОИУ, оформленное в соответствии с ГОСТ 34.602 - 89 «Информационная технология. Комплекс стандартов на автоматизированные системы». [9] Техническое задание на создание автоматизированной системы», помещается в приложение H.

Глава 3. Формирование требований к проектируемой АСОИУ

.1 Анализ и выявление ключевых процессов

.1.1 Формулирование целей и задач создания АСОИУ

Целью создания АСОИУ является повышение эффективности работы преподавательского состава учебного заведения (среднего образования) в организации проведения соревнований для школьников, в том числе и младших классов, по различным общеобразовательным предметам для развития их познавательной деятельности.

Для достижения поставленной цели поставлена задача создания простой и платформо - независимой системы проведения турниров для школьников с нестандартной системой проведения и подсчета очков (правила проведения турнира см. ниже).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для достижения цели определены следующие задачи:

1.Разработка интуитивно понятного интерфейса для удобной работы, как администратора, так и участников турнира с системой.

.Разработать структуру базы данных для хранения данных;

3.Разработать автоматизированную систему, связанную с требованиями, описанными выше.

Правила проведения турнира.

Во время игры участник получает задачу, решает ее и дает ответ. Независимо от результата (верный ответ или нет), участник получает следующую задачу. Время на решение каждой задачи не ограничено, определено только общее время проведения карусели.. Всем участникам предлагается одинаковый набор задач. Задачи даются в одинаковом порядке. Участие в турнире заканчивается, если участник прошёл все задачи или вышло время проведения турнира

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

Начисление баллов осуществляется следующим образом:

Первая задача стоит 3 балла. Если к задаче дан верный ответ, то команда получает ее стоимость, а следующая задача будет стоить на 1 балл больше. Если на задачу дан неверный ответ, то команда получает за решение 0 баллов, а следующая задача будет стоить на 3 балла меньше, но не менее 3 баллов.

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

Рисунок 4. Пример начисления баллов

3.1.2 Состав процессов, подлежащих автоматизации

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

1.Подготовка заданий;

2.Конфигурирование турнира;

.Создание списка участников;

.Проведение турнира;

.Анализ проведенного турнира;

.Создание и публикация отчетов.

Все функции представляют собой основные бизнес - процессы диаграммы декомпозиции первого уровня модели «черный ящик» диаграммы потоков данных системы по методологии DFD «TO - BE» (см. приложение D).

Выбор сделан исходя из общих целей создания АСОИУ и анализа процессов влияющих на ее качество.

3.2 Структурно - функциональная модель системы. Методология IDEF0: TO - BE

В результате перехода от диаграммы «AS - IS» к диаграммам «TO - BE» были добавлены процессы, а именно:

В модели «черного ящика» системы (см. приложение C рисунок C1) был удален результат функционирования системы - «Результаты проведения турнира», в связи с тем, что он является результатом функционирования процесса «Анализ проведенного турнира» внутри системы. Был удален и один из входов в систему, а именно «Список доступных мест для проведения турнира», так как он не актуален для разрабатываемой АСУ (участники проходят турнир дистанционно). Помимо всего этого, были удалены три механизма (ресурсы, необходимые для выполнения работы): «Наблюдатели», «Секретарь» и «Жюри» в связи с ненадобностью их использования.

На декомпозиции первого уровня контекстной диаграммы «Автоматизированная система проведения турниров» (см. приложение C рисунок C2), был удален процесс «Подготовки места для проведения турнира» по той же причине, что и вход в систему «Список доступных мест для проведения турнира». На данной декомпозиции был добавлен процесс «Конфигурирования турнира» в котором происходит установка параметров турнира: добавление задач и т.д. (см. приложение C рисунок C4) Процесс «Подготовка турнира» был заменен процессом «Подготовка заданий» в котором происходит формирование предварительного турнира и формирование пакета задач (см. приложение C рисунок C3).

В процессе «Создание списка участников» был добавлен процесс, связанный с регистрацией в системе (см. приложение C рисунок C5).

В процессе «Проведение турнира» процесс, связанный с написанием ответов на вопросы турнира (см. приложение C рисунок C6) был заменен на процесс «Парсинг ответов участников».

В процессе «Анализ проведенного турнира» процессы «Рассмотрение жалоб» и «Пересчет результатов» были объединены в один процесс «Перерасчет согласно жалоб» (см. приложение C рисунок C7).

В процессе «Создание и публикация отчетов» был удален процесс «Формирование отчета о прошедшем турнире», так как разрабатываемая система не предусматривает создание/хранение каких либо отчетных форм (см. приложение C рисунок C8).

Дерево функциональных блоков структурно - функциональной модели по методологии IDEF0 («TO - BE») представлено на рисунке 5.

Рисунок 5. Дерево функциональных блоков структурно - функциональной модели по методологии IDEF0 («TO - BE»)

3.3 Диаграмма потоков данных системы. Методология DFD: TO - BE

Рассмотрение объекта автоматизации как «черного ящика» системы «TO - BE», приведено в диаграмме потоков данных (см. приложение D рисунок D1) с использованием методологии DFD. На данной диаграмме в результате перехода от диаграммы «AS - IS» к диаграммам «TO - BE» были удалены внешние сущности «Секретарь» и «Жюри» в связи с ненадобностью их использования. Была добавлена сущность «Администратор».

В результате перехода от диаграммы «AS - IS» к диаграммам «TO - BE», помимо уже упомянутых процессов в пункте 3.2 «Структурно - функциональная модель системы. Методология IDEF0: TO - BE», были удалены хранилища данных:

·«Место для турнира» в связи с ненадобностью его использования (как говорилось ранее, проведение турниров происходит дистанционно) - см. приложение D рисунок D2;

·«Отчеты» так как разрабатываемая система не предусматривает создание/хранение каких либо отчетных форм (см. приложение D рисунок D8).

Было добавлено хранилище данных «Жалобы», которое хранит в себе сообщения с жалобами от пользователей системы (см. приложение C рисунок C6).

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

Рисунок 6. Диаграмма потоков данных DFD (TO-BE)

В приложении D на рисунке D2 приведена диаграмма DFD (TO-BE), представляющая декомпозицию первого уровня модели «чёрного ящика» - «Автоматизированная система проведения турниров», включающая в свой состав шесть функциональных блоков: «Подготовка заданий», «Конфигурирование турнира», «Создание списка участников», «Проведение турнира», «Анализ проведенного турнира», «Создание и публикация отчетов» и как показано на рисунке 2:

. Функциональный блок «Подготовка заданий» включает в свой состав два функциональных блока (см. приложение D рисунок D3):

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

Формирование пакета задач.

. Функциональный блок «Конфигурирование турнира» включает в свой состав три функциональных блока (см. приложение D рисунок D4):

Добавление задач в турнир;

Установка параметров турнира;

Активация турнира;

. Функциональный блок «Создание списка участников» включает в свой состав четыре функциональных блока (см. приложение D рисунок D5):

Ознакомление с правилами системы;

Регистрация в системе;

Принятие решения об участии в турнире;

Формировании списка участников турнира;

. Функциональный блок «Проведение турнира» включает в свой состав четыре функциональных блока (см. приложение D рисунок D6):

Запуск турнира;

Отображение заданий турнира;

Парсинг решений участников;

Проверка решений;

. Функциональный блок «Анализ проведенного турнира» включает в свой состав три функциональных блока (см. приложение D рисунок D7):

Предварительный подсчет;

Перерасчет согласно жалоб;

Формирование окончательных результатов;

. Функциональный блок «Создание и публикация отчетов» включает в свой состав три функциональных блока (см. приложение D рисунок D8):

Принятие решения о закрытии турнира;

Публикация и информирование о результатах турнира;

Анализ окончательных результатов;

Следует отметить, что в результате перехода от диаграммы «AS - IS» к диаграммам «TO - BE» так же были отредактированы названия потоков данных, отображающих передачу информации от одного процесса к другому или от одного процесса к внешней сущности.

3.4 Диаграмма последовательности системы. Методология IDEF3

- методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Цель IDEF3 - дать аналитикам описание последовательности выполнения процессов, а также объектов, участвующих совместно в одном процессе.[2]

На диаграмме последовательности (Приложение E рисунок E1) рассматривается процесс организации проведения турнира.

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

3.5 С - требования

В начале проектирования системы было проведено обследование объекта автоматизации. В ходе этого обследования были организованы интервью с представителями заказчика, по результатам которых определили желания и потребности, что явилось основанием для формирования С-требований. Ниже перечислены С-требования к системе, проверенные и согласованные с заказчиком:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для выражения взаимодействия приложения с внешним пользователем воспользуемся диаграммами вариантов использования (Use Case) UML. [10] Общая схема Use Case представлена в приложении J на рисунке J1.

. Варианты использования для актера «Участник» представлены на рисунке 7:

Рисунок 7. Варианты использования для актера «Пользователь»

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

. Варианты использования для актера «Администратор» представлены на рисунке 8.

Рисунок 8. Варианты использования для актера «Администратор»

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

3.6 D - требования

Разработчикам программного обеспечения нужна база для проектирования и разработки. Эта база представляет собой детальные требования (D - требования). D - требования состоят из полного списка конкретных свойств и функциональности, которую должна иметь программа. D - требования должны быть согласованы с С - требованиями. [2]

Существует несколько типов D - требований:

) Функциональные требования.

Функциональные требования определяют работы, которые должна выполнять проектируемая система. Согласно проведенному обследованию к ним относятся все функции, описанные в пункте 3.5 «C - требования».

2) Нефункциональные требования. [2]

Ниже представлен список нефункциональных требований:

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

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

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

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

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

) Обратные требования. [2]

Обратные требования - это тот функционал, который система не обеспечивает.

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

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

3.7 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: TO - BE

Для оценки затрат и предварительного расчета ожидаемой эффективности АСОИУ точно также воспользуемся методологией оценивания функционального размера, которая заключается в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. [2] Было принято решение отталкиваться от внешних хранилищ данных, так как в процессе создания диаграммы потоков данных по методологии DFD (TO - BE) их количество уменьшилось.

Информационные характеристики и их ранг представлены в таблице 7.

Таблица 7. Информационные характеристики и их ранг

ХранилищаИнформационная характеристикаСсылкиЭлементы данныхРангТекущий турнирВнут. лог. файл78Средний (10)Текущий турнирВнешний ввод88Высокий (6)Текущий турнирВнешний вывод28Средний (5)Текущий турнирВнешний запрос48Высокий (6)ЖалобыВнут. лог. файл23Низкий (7)ЖалобыВнешний ввод13Низкий (3)ЖалобыВнешний вывод13Низкий (4)Участники турнираВнут. лог. файл412Низкий (7)Участники турнираВнешний ввод312Высокий (6)Участники турнираВнешний вывод212Средний (5)Участники турнираВнешний запрос112Низкий (3)Список вопросов, ответов турнираВнут. лог. файл35Низкий (7)Список вопросов, ответов турнираВнешний ввод15Низкий (3)Список вопросов, ответов турнираВнешний вывод35Средний (5)

Перейдем к расчету метрики - количества функциональных указателей FP. В таблицу 8 заносятся количественное значение характеристики каждого вида (по всем уровням сложности). Полученные в каждой характеристике значения суммируются, после чего формируется общее количество информационных характеристик. [2]

Таблица 8. Исходные данные для расчета FP - метрик

Имя характеристикиКоличествоНизкийСреднийВысокийИтогоВнешние вводы2 * 3 = 60 * 4 = 02 * 6 = 1218Внешние выводы1 * 4 = 43 * 5 = 150 * 7 = 019Внешние запросы1 * 3 = 30 * 4 = 01 * 6 = 69Внутренние логические файлы3 * 7 = 211 * 10 = 100 * 15 = 031Внешние интерфейсные файлы0 * 5 = 00 * 7 = 00 * 10 = 00Общее количество:77

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

FP = Общее количество × (0,65+ 0,01 × ), (1)

где Fi - коэффициенты сложности. Каждый коэффициент может принимать следующие значения: 0 - нет влияния, 1 - случайное, 2 - небольшое, 3 - среднее, 4 - важное, 5 - основное.

Значение каждого - ого коэффициента определяется эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (см. таблицу 9).

Таблица 9. Определение системных параметров приложения

№Системный параметрЗначение1Передача данных32Распределенная обработка данных33Производительность44Распространенность используемой конфигурации25Скорость транзакций36Оперативный ввод данных47Эффективность работы конечного пользователя38Оперативное обновление49Сложность обработки210Повторная используемость411Легкость инсталляции312Легкость эксплуатации413Разнообразные условия размещения114Гибкость3Итого:43

Подставив значения из таблицы 8 в формулу 1, получим количество функциональных указателей:

FP = 77 × (0,65+ 0,01 × 43) = 83,16, (2)

Подсчитаем количество строк для языка C#. Для этого количество функциональных указателей умножим на количество операторов языка C# на один FP, которое равно 53.

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

(3)

Для оценивания затрат труда и продолжительности проекта необходимо использовать конструктивную модель стоимости СОСОМО Барри Боэма. [2]

Подмодели СОСОМО могут применяться к трем типам программных проектов. В нашем случае ведётся разработка распространённого типа программного проекта. Уравнения базовой подмодели COCOMO имеют вид:

Е = [чел - мес]; (4)= [мес], (5)

где Е - затраты в человеко - месяцах, D - время разработки, KLOC - количество тысяч строк в программном продукте.

Коэффициенты а, b, с, d определяются по таблице 10.

Таблица 10 - Коэффициенты для базовой подмодели COCOMO

Тип проектааbcdРаспространенный2,41,052,50,38Полунезависимый3,01,122,50,35Встроенный3,61,202,50,32

Подставив коэффициенты a, b, c и d для распространенного типа проекта в формулы 4 и 5 получим:

[чел/мес]

[мес]6 месяцев и 9 дней

Полученные оценки позволят скорректировать сроки выполнения проекта.

3.8 Проектирование графического пользовательского интерфейса (ГПИ)

Ввиду ограниченного объема времени, выделенного на проектирование, проработку ГПИ следует выполнять в два этапа:

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

. подготовка итогового эскиза путем переработки чернового варианта ГПИ в соответствии с описанной на страницах ПЗ концепцией.

Описание макета типовой формы и последовательности форм будет приведено ниже, в пунктах 3.8.1 «Описание последовательности форм (диаграмма состояний)» и 3.8.2 «Описание макета типовой формы».

3.8.1 Описание последовательности форм (диаграмма состояний)

Диаграмма состояний предназначена для описания состояний объекта и условий перехода между ними. Данный тип диаграмм позволяет представить все поведение полученного программного объекта в виде графических значков состояний. [2] Проектируемая система взаимодействует с восьмью типами форм различных по функциональности (см. приложение K рисунок K1).

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

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

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

3.8.2 Описание макета типовой формы

Пользовательский графический интерфейс был составлен в соответствии с требованиями заказчика. Эскизы форм интерфейса представлены в приложении L.

На рисунке L1 представлены макетные виды страниц (на рисунках изображены ссылки на страницы в соответствии со своей буквой): - главная страница, вкладка «Главная»; - форма обратной связи;

С - главная страница, вкладка «Правила»; - главная страница, вкладка «Архив»; - страница информации о турнире; - страница информации об участниках турнира.

На рисунке L2 представлены макетные виды страниц:- страница регистрации нового участника; - информационная страница успешной регистрации.

На рисунке L3 представлены макетные виды страниц:- страница авторизации в системе; - информационная страница успешной авторизации (Вход выполнен, как «Пользователь»);- информационная страница успешной авторизации (Вход выполнен, как «Администратор»).

На рисунке L4 под буквой Z представлен макетный вид страницы записи на турнир.

На рисунке L5 представлены макетные виды страниц:- страница информации о турнире с активной кнопкой «Участвовать»; - страница прохождения турнира.

На рисунке L6 под буквой M представлен макетный вид главной страницы, вкладки «Управление».

На рисунке L7 под буквой N представлен макетный вид страницы создания турнира с последующим созданием вопросов с любым контентом.

Глава 4. Разработка концепции АСОИУ

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

Рассмотрим основные типы архитектур, приведенных Гарланом и Шоу [2].

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

. Архитектура независимых компонентов состоит из компонентов, функционирующих параллельно во времени.

2.1Наиболее ярким примером такого типа архитектуры является клиент-серверная. Существуют многочисленные модификации клиент-серверной архитектуры, в частности, широкое распространение получили трехуровневые системы, в которых помимо традиционных клиента и сервера выделен промежуточный уровень, отвечающий за преобразование данных и их перенаправление (например, CORBA, COM).

2.2Архитектура параллельно взаимодействующих процессов характеризуется тем, что в ней одновременно запускается несколько процессов (в различных потоках).

.3Приложение, построенное по архитектуре событийно-управляемых систем, представляет собой набор компонентов, каждый из которых находится в состоянии ожидания, пока не произойдет воздействующее на него событие.

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

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

Сравнение архитектур для данной системы приведено в таблице 11.

Таблица 11. - Сравнение архитектур

№ПоказательВес (1-10)Архитектура 1Архитектура 2.1Архитектура 2.2Архитектура 2.3Архитектура 3Архитектура 41Обеспечение обслуживания пользовательских процессов1041035562Малое сцепление между компонентами68978583Налаженная работа с базами данных83966310Итог:24152816191324

Из итоговых значений таблицы видно, что наиболее подходящей для рассматриваемой системы является архитектура 2.1 (клиент-серверная архитектура). Архитектура клиент-сервер дает пользователю большую безопасность, устойчивость, согласованность, масштабируемость, повышенную конфиденциальность и надежность обработки и хранения информации. Развитие систем с архитектурой клиент-сервер в немалой степени обязано проверенному факту: подключение к недорогим серверам недорогих ПК позволяет получить оптимальное соотношение цены и производительности. Основной фактор целесообразности разработки систем для архитектуры клиент-сервер - быстродействие, к примеру, одним из важнейших преимуществ является снижение сетевого трафика при выполнении запросов.

Преимущества архитектуры:

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

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

.Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

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

Ключевая задача проектирования архитектуры системы состоит в соблюдении двух принципов:

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

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

Архитектура большинства корпоративных приложений включает в свой состав три слоя:

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

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

.Слой источника данных (data source) - отвечает за обращение к БД, обмен сообщениями, управление транзакциями с внешними приложениями.

Глава 5. Эскизный проект

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

Диаграмма деятельности (диаграмма активности, Activity diagram) ? это специальная разновидность диаграммы состояний. В этом типе диаграмм большинство используемых знаков - это знаки активности, переходы между которыми вызваны завершением одних действий и началом других. Activity diagram подходит для моделирования последовательности действий, так же позволяет определить независимо выполняемые действия и показать зависимость дальнейшей работы от внешних условий или решений.[10]

Диаграммы деятельности (Activity Diagram) позволяет изобразить поток операций в системном, производственном или технологическом процессе. Диаграммы деятельности используется для моделирования прецедента в виде последовательности действий (activity), описывающих взаимодействие актера с системой. Эта диаграмма концентрирует внимание на том, какие действия выполняются, и кто несет ответственность за их выполнение.

Диаграмма деятельности для системы в целом представлена на рисунке M1 в приложении M.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления: Методические указания к лабораторным работам/ Сост. А.Ю. Мелихов- Ханты-Мансийск, Югорский гос. ун-т, РИЦ ЮГУ, 2010. - 172 с.

2.Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления: Методические указания по проектированию / Сост. А.Ю. Мелихов- Ханты-Мансийск, Югорский гос. ун-т, РИЦ ЮГУ, 2009. - 63 с.

.ГОСТ 34.003-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения. - Введ. 1992-01-01. - М.: Изд-во стандартов, 1992. - 14 с.

.ГОСТ 24.103-84. Автоматизированные системы управления. Основные положения. - Введ. 1985-07-01. - М.: Изд-во стандартов, 1985. - 2 с.

.ГОСТ 24.104-85. Автоматизированные системы управления. Общие требования. - Введ. 1987-01-01. - М.: Изд-во стандартов, 1987. - 7 с.

.ГОСТ Р ИСО/МЭК 12207-99. Информационная технология. Процессы жизненного цикла программных средств. - Введ. 1999-12-23. - М.: Изд-во стандартов, 2000. - 84 с.

.ГОСТ 24.602-86. Состав и содержание работ по стадиям создания. - Введ. 1988-01-01. - М.: Изд-во стандартов, 1988. - 6 с.

.ГОСТ 34.601-90. Автоматизированные системы. Стадии создания. - Введ. 1992-01-01. - М.: Изд-во стандартов, 1992. - 3 с.

.ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. - Введ. 1990-01-01. - М.: Изд-во стандартов, 1990. - 6 с.

.Фаулер М. UML. Основы / М. Фаулер. - СПб: Символ-Плюс, 2004. - 192 с.

.Официальный сайт LMS Moodle. [#"justify">.Официальный сайт GNU. [#"justify">.Свободная энциклопедия [#"justify">.Мясникова Т.С., Мясников С.А. Система дистанционного обучения MOODLE. - Харьков: Издательство Шейниной Е.В., 2008. - 232 с., ил.

.Интернет Карусель [http://karusel.desc.ru/]

ДИПЛОМНЫЙ ПРОЕКТ Дисциплина: «Технология проектирования и разработки программного обеспечения» на те

Больше работ по теме: