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

 

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

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

 

1) 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 «С – требования».

 

2) Системы Ejudge, Dudge, DOMjudge. [13]

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

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

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

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

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

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

· и т.д.

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

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

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

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

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

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

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

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

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

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

· и т.д.

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

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

 

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

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

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

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

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

· IQ тесты.

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

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

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

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

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

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

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

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

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

 

4) Alltests [13] – онлайн система тестирования и сертификации студентов.

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

 

Прежде чем приступать к этапу формирования требований к системе необходимо определить и систематизировать нормативные документы, определяющие основные понятия в области автоматизированных систем, устанавливающие термины и определения, основные положения, общие требования, процессы жизненного цикла, стадии создания автоматизированной системы. [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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

⇐ Предыдущая12345Следующая ⇒

Поделиться: