Вход

Автоматизированная система бально-рейтинговой оценки успеваемости студентов

Дипломная работа* по педагогике
Дата создания: февраль 2012
Автор: Екатерина
Язык диплома: Русский
Word, docx, 1.2 Мб
Диплом можно скачать бесплатно
Скачать
Данная работа не подходит - план Б:
Создаете заказ
Выбираете исполнителя
Готовый результат
Исполнители предлагают свои условия
Автор работает
Заказать
Не подходит данная работа?
Вы можете заказать написание любой учебной работы на любую тему.
Заказать новую работу
* Данная работа не является научным трудом, не является выпускной квалификационной работой и представляет собой результат обработки, структурирования и форматирования собранной информации, предназначенной для использования в качестве источника материала при самостоятельной подготовки учебных работ.
Очень похожие работы

 

СОДЕРЖАНИЕ

АННОТАЦИЯ

ВВЕДЕНИЕ

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

 1.1. Анализ целей и задач рейтинговой системы контроля знаний

 1.2. Моделирование процесса проверки и анализа успеваемости

 1.3. Краткий обзор существующих разработок в сфере рейтингового учета успеваемости студентов

 1.4 Выводы

2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

 2.1. Основание для разработки

 2.2. Назначение разработки

 2.3. Требования к программному изделию

 2.3.1. Требования к функциональным характеристикам

 2.3.2. Требования к надежности

 2.3.3. Условия эксплуатации

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

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

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

 2.4.1. Руководство администратора

 2.4.2. Руководство пользователя

 2.5. Стадии и этапы разработки

 2.5.2. Этапы разработки

 2.5.3. Содержание работ по этапам

 2.6. Порядок контроля и приемки

2.6.1. Виды испытаний

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

3. КОНСТРУКТОРСКАЯ ЧАСТЬ

3.1 Архитектура программной системы

3.2 Обоснование выбора инструментальных средств разработки

3.3 Проектные модели программной системы

3.4 Модель данных

3.5 Проектирование интерфейса

4. ЭКСПЕРИМЕНТАЛЬНАЯ ЧАСТЬ

4.1. Описание методики тестирования

4.2. Тестирование программной системы в штатных условиях

4.3. Нагрузочное тестирование программной системы

4.4. Тестирование в исключительных ситуациях

4.5. Оценка полноты тестирования и надежности программной системы

ЗАКЛЮЧЕНИЕ

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

ВВЕДЕНИЕ

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

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

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

Таким образом, актуальность вопроса о методике определения уровня подготовки студентов в условиях современного высшего обучения определила тему работы «Автоматизированная система определения успеваемости студентов».

Объект исследования: методика определения качества знаний студентов.

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

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

Задачи исследования:

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

2. Рассмотреть сущность рейтинговой оценки знаний студентов.

3. Обосновать использование автоматизированного учета рейтинговой оценки знаний студентов в учебном процессе.

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

1. АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1. Анализ целей и задач рейтинговой системы контроля знаний

В новых исторических реалиях, сложившихся к исходу текущего столетия, в педагогическом процессе становятся преобладающими иные приоритеты. Каждый получающий среднее, а тем более высшее образование должен уметь ставить цели, генерировать идеи, находить смыслы, изыскивать решения в сложных, подчас неадекватных тому или иному предмету, ситуациях, т.е. в ситуациях исполненных неопределенности, от человека требуется умение адекватно ориентироваться в том, что обозначается понятиями “духовные ценности”, “активная позиция”, “смыслообразующая деятельность” [11].

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

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

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

Для более адекватного определения итогового уровня знаний, приобретенных студентами в ходе учебного процесса, в системе балльно-рейтинговой оценки на подготовку к экзаменам практически не отводится времени. Это объясняется тем, что на экзаменах, особенно по дисциплинам фундаментальной подготовки, как правило, выявляется и оценивается уровень остаточных знаний, усвоенных студентом в течение семестра, а не те знания, которые, будучи приобретенными «за три дня и три ночи» при подготовке к экзамену, к началу следующего семестра обычно в значительной мере утрачиваются. Таким образом, обеспечивается достаточно высокое качество определения компетентности и образованности будущего специалиста.

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

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

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

Исходя из вышесказанного, можно утверждать, что контроль выполняет свою функцию только тогда, когда он основан на непредвзятом подходе и объективности. Если контроль осуществляется человеком, то он всегда несет в себе влияние этого человека и отношение его к проверяемому. Использование рейтинг-контроля на базе применения ЭВМ позволяет устранить эти негативные факторы и проверять знания студентов вне зависимости от “человеческого фактора”.

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

Целью введения рейтинговой системы оценки успеваемости студентов является комплексная оценка качества учебной работы студентов в процессе обучения по программам профессионального образования. Также, цель балльно-рейтинговой технологии оценки знаний можно определить как способ личностно–ориентированного обучения, стимулирования систематической работы студентов, раскрытия их творческих способностей, дифференциации оценки знаний [15].

То есть, основными целями введения рейтинговой системы являются:

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

- снижение роли случайных факторов при сдаче экзаменов и/или зачетов;

- определение реального места, которое занимает студент среди сокурсников в соответствии со своими успехами;

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

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

Главные задачи рейтинговой системы заключаются в:

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

- повышении уровня организации образовательного процесса в вузе.

Преимущества рейтинговой системы:

- возможность организовать и поддерживать ритмичную систематическую работу студентов в течение всего семестра;

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

- повышение посещаемости и уровня дисциплины на занятиях; студентам «выгодно» посещать занятия;

- акцент на психологические особенности молодежной аудитории; уменьшение «сессионного стресса»;

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

- стимулирование творческого отношения к работе как студентов, так и преподавателей.

Балльно-рейтинговая система оценки знаний служит инструментом повышения объективности и достоверности оценки уровня подготовки студентов и используется в качестве одного из элементов управления учебным процессом в вузе [4].

Балльно-рейтинговая система позволяет студентам:

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

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

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

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

Балльно-рейтинговая система дает возможность преподавателям:

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

- своевременно вносить коррективы в организацию учебного процесса по результатам текущего рейтингового контроля;

- объективно определять итоговую оценку по дисциплине с учетом систематической работы;

- обеспечить градацию оценки уровня знаний по сравнению с традиционной системой.

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

Балльно-рейтинговая система позволяет обеспечить непрерывность контроля и оценки качества знаний, как по отдельной дисциплине, так и на протяжении семестра, на текущий этап обучения (все прошедшие семестры) и период обучения на данной ступени профессионального образования (ВПО). Рейтинг по дисциплине и другим видам учебной работы студента служит оценкой академической успеваемости, используемой для расчета рейтинга за соответствующий семестр [16].

Рейтинг за семестр является оценкой успеваемости студента по всем видам учебной работы, предусмотренной учебным планом. Таким образом, рейтинговая система оценки успеваемости студентов основана на использовании совокупности контрольных точек, оптимально расположенных на всем временном интервале изучения дисциплины, но при этом предполагается разделение всего курса на ряд более или менее самостоятельных, логически завершенных блоков и модулей и проведение по ним контрольных акций. Важным принципом рейтинговой системы является требование своевременного выполнения студентом всех учебных заданий [5].

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

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

Рассматриваемая система позволяет получать достаточно объективную информацию о степени успешности обучения студентов относительно друг друга. Уже по истечении двух - трех месяцев можно выделить лучших и худших студентов группы. Это дает администрации мощный рычаг, позволяющий поощрять лучших и наказывать худших [9]. Так как, уже на раннем этапе формируются массивы студентов по прогностическому показателю: претендентов на “отлично”, “хорошо”, ”удовлетворительно” и тех студентов, которые отстают от учебного плана и могут остаться не аттестованными. Ранний прогноз позволяет внести корректировку в дальнейшее обучение.

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

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

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

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

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

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

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

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

Методической основой рейтинговой системы являются три основополагающих принципа:

- самостоятельность изучения;

- индивидуализация обучения;

- объективность оценки знаний и самооценки.

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

Существуют также и трудности в рейтинговом оценивании - для эффективной работы необходимо наличие множительной техники; предъявляются и высокие квалификационные требования к преподавателю, как в методической, так и в предметно-профессиональной его деятельности. Но задачу уменьшения нагрузки преподавателя можно решить путем передачи контрольных функций компьютеру. И еще одна особенность: система лучше всего срабатывает на старших курсах, где ценится студентом время и существует уже достаточно сформированный уровень мотивации (профессиональная направленность). Также, она требует принципиально нового материально-технического и информационного обеспечения [15].

Рейтинговая технология уместна и эффективна лишь тогда, когда созданы необходимые условия для ее осуществления.

1.2. Моделирование процесса проверки и анализа успеваемости

Для построения модели «AS - IS» используем модель потока данных процесса определения успеваемости стандарта DFD.

Data Flow Diagram – (DFD) является одним из средств моделирования функциональных требований к системе. Требования представляются в виде иерархии функциональных компонентов (процессов), связанных потоками данных.

По нотации Гейн-Сарсона DFD блок изображается прямоугольником со скругленными углами. Каждый блок содержит номер для ссылки на него внутри диаграммы. Поток данных (документы, объекты, участники обработки информации) изображается стрелкой между объектами диаграммы, а ее направление указывает направление потока. При этом, каждый поток имеет имя [8].

Каждый узел-процесс DFD может развертываться в диаграмму нижнего уровня.

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

При интерпретации DFD-диаграммы используются правила:

1) функции преобразуют входящие потоки данных в выходящие;

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

3) преобразования потоков данных во внешних ссылках игнорируется.

1.3. Краткий обзор существующих разработок в сфере рейтингового учета успеваемости студентов

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

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

1) «Комкон:ВУЗ. Деканат 8» на платформе "1С:Предприятие 8";

2) система "Управление вузом" компании Галактика;

3) "БИТ: Учебная часть" на платформе "1С:Предприятие 8";

4) информационная система для ВУЗов ЧДК: ВУЗ 8.1 фирмы ЗАО "Что делать Внедрение".

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

Базой для разработки информационной системы «Комкон:ВУЗ. Деканат 8» выбрана платформа "1С:Предприятие 8".

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

• ведение списка вопросов и ответов для проведения тестирования по дисциплинам с указанием числа баллов;

• ведение учета по организационной структуре ВУЗа: факультеты, кафедры;

• ведение списка групп студентов по каждому факультету и кафедре;

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

• ведение списка специальностей по каждому факультету и кафедре;

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

• ведение списка интересов студентов таких, как: спорт, общественная деятельность, музыка, театр и др;

• ведение списка сертификатов и свидетельств, полученных студентом;

• ведение списка научно-исследовательских работ: опубликованные статьи, участие в конференциях, олимпиадах, конкурсах;

• ведение учета по учебно-методической нагрузке с последующим составлением отчетности;

• учета и формирование рабочих программ по дисциплине.

• учета посещаемости занятий студентами;

• ведение учета и формирование рейтинговых и экзаменационных ведомостей (по 100-бальной шкале);

• учет бонусов, получаемых студентами;

• получение рейтинга преподавателей по ряду показателей, в том числе по научно-исследовательской работе студентов;

Разработан ряд отчетов для анализа данных о студентах.

Недостатки этой системы заключаются в том, что «Комкон:ВУЗ. Деканат 8» не является самостоятельным программным продуктом, для его работы необходимо наличие установленной платформы "1С:Предприятие 8.1" версии 8.1.11.67 (и более поздних).

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

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

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

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

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

Конфигурация "БИТ: Учебная часть" предназначена для автоматизации процесса обучения в учреждениях высшего и среднего профессионального образования.

Основные функциональные возможности программы:

- Хранение информации о студентах в единой базе данных;

- Автоматизация процесса составления и ведения учебных планов;

- Автоматизация процесса формирования личного дела студента;

- Учет всех процессов, связанных с обучением и движениями студента в процессе обучения;

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

- Предоставление актуальной отчетности.

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

"БИТ: Учебная часть" - оригинальная, но не самостоятельная конфигурация, для ее работы необходимо наличие установленной платформы "1С:Предприятие 8.1" (любая поставка, кроме базовых версий).

ЧДК:ВУЗ 8.1 — интегрированная система автоматизации управления высшим учебным заведением. В архитектуру заложены возможности формирования индивидуальной программы обучения учащегося (блоки дисциплин по выбору, факультативные дисциплины), учет индивидуальной программы при выполнении таких функций, как формирование учебных потоков, формирование расписания занятий, учет проведения занятий, учет контрольных мероприятий, учет успеваемости и учебной нагрузки с использованием балльно-рейтинговой системы. В тоже время система полностью «ложится» на учебный процесс, организованный по классической отечественной схеме.

Являясь комплексным интегрированным решением, система ЧДК: ВУЗ 8.1 условно разделена на функциональные модули. Заказчик имеет возможность приобрести и внедрить часть системы с возможностью дальнейшего расширения функционала путем приобретения отдельных модулей.

Краткая характеристика функциональных модулей системы

Управление обучением

• Планирование выпуска специалистов.

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

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

• Контроль исполнения учебных планов в индивидуальных и сводных показателях.

Управление занятиями

• Формирование рабочего учебного плана учебного заведения (с точностью до занятия, учащегося, преподавателя, курса дисциплины, аудитории).

• Учет выполнения рабочего учебного плана ВУЗа (с точностью до занятия, учащегося, преподавателя, курса дисциплины, аудитории).

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

Система ЧДК:ВУЗ 8.1 разработана на платформе 1С:Предприятие 8.1. ЧДК:ВУЗ 8.1 спроектирована в соответствии с принципами стандарта «1С Совместно». Архитектура решения унифицирована с типовыми конфигурациями фирмы «1С» – «Зарплата и Управление Персоналом», «Бухгалтерский учет» и «Управление Производственным Предприятием». Это позволяет интегрировать систему ЧДК:ВУЗ 8.1 с данными продуктами.

Недостатки: программное обеспечение не ориентировано на балльно-рейтинговую систему учета успеваемости.

1.4. Информационная безопасность в современных системах управления базами данных

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

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

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

Пользователей СУБД можно разделить на три группы:

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

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

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

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

В современных СУБД достаточно развиты средства дискреционной защиты. Дискреционное управление доступом (discretionary access control) — разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.

Дискреционная защита является многоуровневой логической защитой.

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

Следуя технологии открытых систем, субъект доступа может обращаться посредством СУБД к базе данных только из программ, поставляемых в дистрибутиве или подготовленных им самим, и только с помощью штатных средств системы.

Все субъекты контроля системы хранятся в таблице полномочий системы и разделены для системы на ряд категорий, например CONNECT, RESOURCE и DBA. Набор таких категорий определяется производителем СУБД. Так происходит нарастание возможностей (полномочий) для каждого отдельного вида подключения:

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

RESOURCE — привилегированные пользователи, обладающие правом создания собственных объектов в базе данных (таблиц, представлений, синонимов, хранимых процедур). Пользователь — владелец объекта обладает полным набором привилегий для управления данным объектом;

DBA — категория администраторов базы данных. Включает возможности обеих предыдущих категорий, а также возможность вводить (удалять) в систему (из системы) субъекты защиты или изменять их категорию.

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

Недостаточность ресурсов. Администраторы БД уделяют обеспечению безопасности менее 7% своего рабочего времени. В основном они заняты текущими операциями и поддержкой БД.

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

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

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

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

1.4 Выводы

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

При этом, существующие программы-аналоги ориентированы, по своей сути, на традиционные формы контроля, но в то же время имеют практические черты, которые можно взять за основу функциональных требований к разрабатываемому программному обеспечению. Например, графическое представление итогов обучения в решении «Галактика Управление Вузом»; из системы «Комкон:ВУЗ. Деканат 8» - ведение списка интересов студентов таких, как спорт, общественная деятельность, музыка, театр и др. Так же, основное требование к системе - это ведение списка дисциплин и их зачетных единиц (согласно государственному образовательному стандарту 3 поколения) и, не менее важное, собственно учет непосредственных участников образовательного процесса.

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

Объект исследования: методика определения качества знаний студентов.

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

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

Задачи исследования:

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

2. Рассмотреть сущность рейтинговой оценки знаний студентов.

3. Обосновать использование автоматизации учета рейтинговой оценки знаний студентов в учебном процессе.

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

2. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Разрабатываемое программное обеспечение является автоматизированной системой учета успеваемости студентов на основе балльно-рейтингового учета успеваемости. Оно призвано упростить работу преподавателей по контролю успеваемости студентов и позволить перейти на современный образовательный стандарт [11].

2.1. Основание для разработки

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

2.2. Назначение разработки

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

Интуитивно-понятный интерфейс позволит пользователю легко приобрести навыки работы.

2.3. Требования к программному изделию

2.3.1. Требования к функциональным характеристикам

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

1) разделение уровня прав доступа к информации;

2) добавление новых участников учебного процесса;

3) фиксирование результатов учебного процесса;

4) построение отчетов и графиков по успеваемости студентов;

5) выведение общего рейтинга студента и его средней оценки по предмету.

Должно быть реализовано разделение пользователей на следующие группы:

• администратор;

• преподаватель;

• студент.

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

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

2.3.2. Требования к надежности

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

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

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

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

4) организация бесперебойного питания технических средств;

5) использование лицензионного программного обеспечения;

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

2.3.3. Условия эксплуатации

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

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

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

Программная система рассчитана на функционирование при следующем техническом обеспечении:

• компьютер с IBM совместимой архитектурой;

• оперативная память объемом 512 Mб;

• видеокарта и монитор с разрешающей способностью не менее 1024*768;

• клавиатура;

• манипулятор «мышь»;

• свободное дисковое пространство на жестком диске 10 Mб, не менее.

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

Для эксплуатации программной системы необходимо наличие установленной и сконфигурированной операционной системы Microsoft Windows XP (Service Pack 2 и выше) или Microsoft Windows Vista (Service Pack 2 и выше). Программа взаимодействует с BDE (Delphi7). При необходимости экспорта данных в формат *.xls обязательно наличие Microsoft Excel версии 2003 и выше.

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

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

2.4.1. Руководство администратора

Руководство администратора содержит следующую информацию:

• сведения о структуре программы, ее составных частях, о связях между подпрограммами;

• описание особенностей установки и конфигурации системы;

• условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т.п.).

2.4.2. Руководство пользователя

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

• описание функций, выполняемых программой;

• описание приемов работы с ней;

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

2.5. Стадии и этапы разработки

2.5.1. Стадии разработки

Разработка должна быть проведена в три стадии:

1) системный анализ;

2) рабочее проектирование;

3) внедрение.

2.5.2. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

1) разработка программы;

2) разработка программной документации;

3) испытания программы.

На стадии внедрения должен быть выполнен этап подготовки и сдачи программы.

2.5.3. Содержание работ по этапам

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

1) постановка задачи;

2) определение и уточнение требований к техническим средствам;

3) определение требований к программе;

4) определение стадий, этапов и сроков разработки программы и документации к ней;

5) согласование и утверждение технического задания.

На этапе разработки программы должны быть решены следующие задачи:

1) выбор архитектуры программной системы;

2) выбор средств разработки (среда разработки, язык программирования, СУБД);

3) разработка приложения;

4) отладка программной системы.

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

На этапе испытаний программы должны быть выполнены нижеперечисленные работы:

1) разработка, согласование и утверждение и методики испытаний;

2) проведение приемо-сдаточных испытаний;

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

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

2.6. Порядок контроля и приемки

2.6.1. Виды испытаний

Программная система должна пройти следующие виды испытаний:

• предварительные;

• опытная эксплуатация;

• приемочные.

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

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

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

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

3. КОНСТРУКТОРСКАЯ ЧАСТЬ

3.1 Архитектура программной системы

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

В настоящее время существует несколько основных типовых архитектур, которые широко применяются в разработке программных продуктов в мире (см. таб. 3.1).

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

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

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

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

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

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

Данная архитектура является старейшей из вышеуказанных архитектур. Она обладает рядом неоспоримых достоинств (см. рис. 3.1).

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

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

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

Несмотря на свои недостатки, локальная модель архитектуры до сих пор широко применяется на практике.

3.2 Обоснование выбора инструментальных средств разработки

Для реализации проекта была выбрана среда Borland, язык программирования Delphi [13].

Delphi - это комбинация нескольких технологий:

• Высокопроизводительный компилятор в машинный код;

• Объектно-ориентированная модель компонент;

• Визуальное, а, следовательно, и скоростное построение приложений из программных прототипов;

• Масштабируемые средства для построения баз данных

Этот компилятор в настоящее время является самым быстрым в мире, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL.

В Delphi компиляция производится непосредственно в родной машинный код. Объекты БД в Delphi основаны на SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к СУБД Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме. Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (к примеру, небольшую систему учета для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то приложение без изменений будет работать и в составе большой системы с архитектурой клиент-сервер. Готовое приложение может быть изготовлено либо в виде исполняемого модуля, либо в виде динамической библиотеки, которую можно использовать в приложениях, написанных на других языках программирования.

BDE (от англ. Borland Database Engine — «движок баз данных Borland») — 32-битный движок баз данных под Windows для доступа к БД из Borland Delphi, C++ Builder, IntraBuilder, Paradox for Windows и Visual dBASE for Windows [1].

Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). BDE позволяет осуществлять доступ к данным с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных.

C++ Builder — инструмент быстрой разработки приложений (RAD), интегрированная среда программирования (IDE), система, используемая для разработки программного обеспечения на языке C++ [12].

C++ Builder объединяет в себе комплекс объектных библиотек (STL, VCL, CLX, MFC и др.), компилятор, отладчик, редактор кода и многие другие компоненты. Цикл разработки аналогичен Delphi. Большинство компонентов, разработанных в Delphi, можно использовать и в C++ Builder без модификации, но обратное утверждение не верно.

Недостатки си++ Builder. Плохая поддержка модульности (по сути, в классическом C модульность на уровне языка отсутствует, её обеспечение переложено на компоновщик). Подключение интерфейса внешнего модуля через препроцессорную вставку заголовочного файла (#include) серьёзно замедляет компиляцию при подключении большого количества модулей, потому что результирующий файл, который обрабатывается компилятором, оказывается очень велик. Эта схема без изменений скопирована в C++. Для устранения этого недостатка многие компиляторы реализуют механизм прекомпиляции заголовочных файлов. Другим недостатком языка C++ является отсутствие встроенной системы сборки мусора (garbage collector). Препроцессор, унаследованный от C, очень примитивен.

3.3 Проектные модели программной системы

Use case - один из важнейших элементов UML, описывающий некоторый прецедент по использованию приложения, моделируемого при помощи UML. Диаграммы прецедентов, или use case диаграммы, предназначены для описания высокоуровнего поведения разрабатываемой программы, выделения основных действующих лиц и их взаимодействия с элементами системы (см. рис. 3.2.). Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций [8].

Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors).

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

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

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

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

Существует несколько стандартных видов отношений между актерами и вариантами использования:

ассоциации (association relationship);

расширения (extend relationship);

общения (generalization relationship);

включения (include relationship).

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

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

В данной диаграмме определяются все возможные состояния и процессы их смены, в которых может находиться конкретный объект. Есть начальное состояние Start и конечное Stop. Начальное – помечается черной точкой, оно определяет состояние, когда объект только был создан. Конечное – обозначается черной точкой в белом кружке, оно отражает состояние объекта непосредственно перед его уничтожением. При этом, начальное состояние может быть только одно, а конечных состояний может быть некое количество, соответствующее моделируемым исходам, или их может не быть вообще. Процессы, соответствующие динамике объекта в неком состоянии являются действиями и называются Actions.

3.4 Модель данных

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

3.5 Проектирование интерфейса

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

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

Основным критерием при разработке интерфейса является субъективная удовлетворенность пользователя, чтобы интерфейс легко воспринимался и на подсознательном уровне [3].

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

Система содержит следующие функциональные блоки:

1) внесение данных;

2) вывод текстовой и графической информации на экран и печать;

3) анализ данных.

При запуске приложения появляется диалоговое окно «Вход», которое позволяет определить уровень пользователя и наделить его соответствующими полномочиями 

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

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

При входе в программу под пользователем «Преподаватель» появляется помимо возможности просмотра ряда параметров, возможность внесения баллов студентам 

В окне «Запрос» нужно выбрать инициалы преподавателя и ввести соответствующий пароль

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

4. ЭКСПЕРИМЕНТАЛЬНАЯ ЧАСТЬ

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

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

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

4.1. Описание методики тестирования

Поскольку исчерпывающее структурное тестирование невозможно, необходимо выбрать такие критерии его полноты, которые допускали бы их простую проверку и облегчали бы целенаправленный подбор тестов. Наиболее слабым из критериев полноты структурного тестирования является требование хотя бы однократного выполнения каждого оператора программы. Более сильным критерием является критерий: каждая ветвь алгоритма (каждый переход) должна быть пройдена (выполнена) хотя бы один раз[14].

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

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

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

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

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

4.2. Тестирование программной системы в штатных условиях

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

Тестирование системы в штатных ситуациях включает проверки:

- проверка задания начальных данных;

- проверка функции построения решающего правила;

- проверка функции вычисления показателя;

- проверка функции построения диаграммы;

- проверка функций пользовательского интерфейса.

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

4.3. Нагрузочное тестирование программной системы

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

Оно включает в себя этапы:

- проверка задания большого числа входных данных;

- проверка создания отчетов большого размера;

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

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

4.4. Тестирование в исключительных ситуациях

Тестирование в исключительных ситуациях означает проверку работоспособности системы в случае сбоев, провокационных действий пользователя [6].

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

- удаление одной из таблиц БД;

- сохранность БД системы в случае скачков напряжения.

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

4.5. Оценка полноты тестирования и надежности программной системы

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

1. Барсегян, А.А. Технологии анализа данных. Data Mining, Visual Mining, Text Mining, OLAP. / А.А. Барсегян, М.С. Куприянов. – СПб.: БХВ – Петербург, 2008. – 384 с.

2. Басс, Л. Архитектура программного обеспечения на практике / Л. Басс, П. Клементс, Кацман Р. – СПб.: Питер, 2008 – 576 с.

3. Головач, В.В. Дизайн пользовательского интерфейса.

4. Демурчев, Н.Г. «Подходы к количественному анализу эффективности методики построения системы разграничения доступа (статья)». Материалы 51 научно-методической конференции преподавателей и студентов ставропольского государственного университета «Университетская наука – региону». – Ставрополь: Изд-во СГУ, 2008. – c. 356 - 359.

5. Демурчев, Н.Г., Шульгин А.О., Касимов Р.И. «Программный модуль «Абитуриентское тестирование» (свидетельство об отраслевой регистрации разработки)». Федеральное агентство по образованию, Отраслевой фонд алгоритмов и программ, свидетельство №6195 от 25.05.2008

6. Котляров, В.П. Основы тестирования программного обеспечения.

7. Кулямин, В.В. Архитектура среды тестирования на основе моделей, построенная на базе компонентных технологий. Труды ИСП РАН, 18:9 – 44, 2010.

8. Леоненков, А. Самоучитель UML 2 / А. Леоненков. – БХВ – Петербург, 2008. – 576 с.

9. Лепешкин, О.М., Демурчев Н.Г. «Моделирование безопасности автоматизированной информационной системы вуза (статья)». Научный журнал «Вестник СГУ» - 2008 №43. – c.143-151.

12. Страуструп, Бьерн, Программирование. Принципы и практика использования C++. – СПб.: Вильямс, 2011. – 1248 с.

13. Сухарев, М., Delphi. Полное руководство. – СП.: Наука и техника, 2010. – 1040 с.

14. Тестирование программных средств. – Режим доступа:

15. Шульгин, А.О., Демурчев А.О., Касимов Р.И., Москаленко А.С. «Автоматизированная информационная система Ставропольского государственного университета (статья)». Журнал «Компьютерные учебные программы и инновации» - 2008 – №1

16. Шульгин, А.О. «Модель информационных процессов с вариативными регламентами». Научно-технический журнал «Системы управления и информационные технологии» - 2008 – №2.1 (24) – с.204-207

© Рефератбанк, 2002 - 2024