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

бесплатно 0
4.5 123
Сферы применения методологии RAD. Особенности создания программного продукта, предназначенного для редактирования тестов. Рассмотрение моделей жизненного цикла: каскадная, спиральная. Этапы построения начальной контекстной диаграммы. Анализ DFD-диаграммы.


Аннотация к работе
Проект должна быть разработана в сроки, указанные заказчиком, и в то же время не содержать ошибок проектирования и минимальное количество ошибок реализации, поэтому потребуется использование RAD-среды разработки. В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Таким образом, методология RAD оптимально подходит для реализации данного проекта в силу хорошо налаженной обратной связи между заказчиком и исполнителем, что позволяет наиболее полно раскрыть пожелания заказчика и варьировать реализацию по мере создания программного средства. Поиск альтернативных программ в сети Internet дал много результатов, но у этой программы свои плюсы не доступные в других программах.В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Диаграммы - главные компоненты модели, все функции ПП и интерфейсы на них представлены как блоки и дуги. В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней по отношению к нему. На этапе проектирования проведен структурный анализ программного продукта, рассмотрены основные модели жизненного цикла программного продукта, и построены соответствующие диаграммы: SADT-диаграмма и DFD-диаграмма.Проведены исследование и анализ предметной области, выявлена структура теоретико-практического курса обучения, построена начальная контекстная диаграмма. На этапе проектирования проведен структурный анализ программного продукта, рассмотрены основные модели жизненного цикла программного продукта, и построены соответствующие диаграммы: SADT-диаграмма и DFD-диаграмма.Программный продукт «Система тестирования знаний»Следующая вкладка в программе тестирования идет вкладка Тест, где можно выбрать либо начать тестирование, либо закончить тестирование. Работа с программой начинается с создание теста в редакторе тестов программы «Test v.1.0». Нужно указать название теста, а так же количество вопросов в тесте (всего) и количество вопросов задаваемых при тестировании, так как прохождение программа сама выберет тесты. Далее после сохранения теста, открываем его с помощью программы для тестирования знаний «Test v.1.0» и нажимаем во вкладке Тест, на кнопку начать тестирование. Следующие действие это завершение работы теста, если тест с защитой, то его нельзя выключить пока не введешь пароль доступа.

План
2. План тестирования. Данный план работает по следующим пунктам: - структура и среда тестовой системы;

- методология тестирования;

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

Введение
программный редактирование методология диаграмма

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

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

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

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

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

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

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

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

2. Достаточная информация обо всех объектах.

3. Многофункциональность.

Рекомендуемые аппаратные требования: · процессор Intel Pentium IV 1.7 ГГЦ;

· 512MB оперативной памяти;

· 16MB видеопамяти;

· Свободное местно на жестком диске, равный 25Мб.

Требования к программному обеспечению: ОС MS Windows XP или выше, набор драйверов.

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

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

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

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

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

В приложение 1 приведен полный состав сопутствующей проекту документации, с оглавлением состава и с краткими выдержками их содержимого.

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

Цели и задачи работы

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

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

Задачи работы: 1. Разработать программу, в которой будет возможность составление тестов и сохранение их в формате tes. Развернутое функциональное наименование проекта: «Система тестирования знаний».

2. Реализация всевозможных функций.

3. Более детальна настройка аудио треков.

Новизна работы

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

Практическая значимость

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

Структура и объем работы

Пояснительная записка к курсовой работе состоит из введения, трех разделов и заключения, содержит 18 рисунков и 3 таблицы. Список использованной литературы содержит 21 наименований. Общий объем пояснительной записки - 55 страниц машинописного текста, введение - 5 страницы, основная часть - 31 страницы, заключение - 1, приложения - 21 страниц.

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

В первом разделе представлено описание предметной области.

Во втором разделе описано проектирование программного продукта.

В третьем разделе описана программная реализация.

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

В приложение 1 описание техническое задание.

В приложение 2 описание руководство пользователя.

В приложение 3 представлен листинг программы

1. Описание предметной области

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

Для достижения поставленной цели должно быть реализовано: изучение структуры создания и редактирования тестов;

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

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

ознакомление со структурой организации создания и редактирования тестов;

формирование пакета документации;

проведение тестирования и отладка проекта;

проект должен иметь интуитивно-понятный интерфейс;

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

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

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

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

Входные данные: учебный материал.

Выходные данные: тесты для прохождения тестирования.

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

Работа с программой проходит в одном режиме - режиме пользователя. В нем выполняются все действия по работе с программой.

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

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

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

2. Требования пользователя: · Быть надежной в работе, то есть сохранять все изменения, внесенные пользователем после подтверждения, и выдавать их при дальнейшем запуске системы;

· устойчиво работать в течение длительного времени;

· работать под операционной системой семейства Windows;

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

· иметь надписи на кнопках понятные для пользователя;

· иметь эргономичное цветовое оформление;

· иметь надписи, свободно читаемые (кегль шрифта 10-14 пт.);

· быть способной параллельно работать с другими приложениями.

3. Функциональные требования: · Должна быть обеспечена возможность ввода, изменения данных и их удаления;

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

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

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

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

3. Определены функциональные требования к ПП, для обеспечения устойчивости и гибкости ПП.

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

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

2. Проектирование программного обеспечения

2.1 Жизненный цикл программного продукта

У каждого программного продукта существует свой жизненный цикл (ЖЦ). ЖЦ - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПП и заканчивается моментом полного изъятия ПП из эксплуатации. Современный рынок программного обеспечения требует, чтобы выпуск программ был быстрым, а его дальнейшая эксплуатация - долговременной и надежной. Для достижения этого необходима хорошая организация и тщательное планирование всего жизненного цикла программного продукта. Жизненный цикл программ состоит из нескольких этапов: Анализ предметной области, проектирование, реализация, анализ и тестирование, эксплуатация.

В настоящее время широкое распространены 2 модели жизненного цикла: 1. Каскадная

2. Спиральная

Каскадная

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

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

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

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

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

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

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

· Удобна для ПП, где уже в начале достаточно полно сформулированы все требования.

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

Спиральная

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

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

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

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

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

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

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

- От этапа к этапу можно переходить до завершения работ на предыдущем этапе.

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

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

2.2 Фаза проектирования

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

На фазе проектирования происходит: 1. Описание модели и сценариев поведения продукта в контексте среды разработки и языков программирования. Стадию проектирования можно разделить на 2 пункта: a. Внешние спецификации;

b. Внутренние спецификации.

Внешние спецификации включают в себя: - внешние интерфейсы;

- функциональное наполнение, видимое пользователю;

- взаимодействие между процессами;

- форматы файлов;

Внутренние спецификации включают в себя: - реализация интерфейсов;

- реализация функционального наполнения;

- внутренние структуры данных;

- описание алгоритмов;

- внутренняя обработка ошибок.

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

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

3. На этапе проектирования проведен структурный анализ программного продукта, рассмотрены основные модели жизненного цикла программного продукта, и построены соответствующие диаграммы: SADT-диаграмма и DFD-диаграмма.

4. Выбраны технологии реализации программной системы: выбрана среда разработки Delphi для реализации ПП и приведены обоснования для этого выбора.

5. Реализованы основные алгоритмы и модули программной системы, в результате чего получили готовый ПП.

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

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

Список литературы
1.Дж. Банкел, Фундаментальные алгоритмы и структура данных в Delphi изд. Москва Dia Soft 2003г.Дж. Банкел, Фундаментальные алгоритмы и структура данных в Delphi изд. Москва Dia Soft 2003г.

2.Брябрин В.М. Программное обеспечение персональных ЭВМ. Изд. 2-е, стер. - М.: Наука, 1989г.

3.Архангельский А.Я., Программирование в Delphi 7. - М.: Бином, 2005. -1152 с.

4.Марка Д.А., МАКГОУЭН К. Методология структурного анализа и проектирования. М., "МЕТАТЕХНОЛОГИЯ", 1993.

5.Рассел Арчибальд. Модели жизненного цикла высокотехнологичных проектов. http://www.pmo.ru/models.php.

6.Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. http://www.citforum.ru/database/ case/index.shtml.

7.Дарахвелидзе П , Марков Е. Программирование в Delphi 7 изд. БХВ-Петербург 2003г.

8.Сергей Орлик, Введение в программную инженерию и управление жизненным циклом ПО. Модели жизненного цикла программного обеспечения. - Электронные текстовые данные. Моделирование и анализ систем. Практикум. Черемных С.В. 2001 г.

9.Case-технологии: Консалтинг в автоматизации бизнес-процессов Г. Н. Калянов. 2004 г.

10.Интеллектуальные информационные системы. Андрейчиков А.В., Андрейчикова О.Н. 2000г.

11.Методические рекомендации по выполнению работ для студентов. Шкарина Л.Н.

12.Структурный подход к программированию. Хьюз Дж., Мичтом Дж. 1980 г.;

13.Надежность программного обеспечения систем обработки данных. Шураков В. В. 1987 г.;

14.Ильина О.П. Организация и технология разработки информационной базы АСУ. Учебн. пособие. - М.: Наука, 1986 г.

15.Мартин Дж. Организация баз данных в вычислительных системах. - М.: Мир, 1980.

16.Глушаков С.В., Клевцов А.Л., Теребилов С.А. Программирование на Delphi 5.0. - Харьков: Фолио, 2002. - 518 с.

17.Microsoft Windows 2000 Sever. Учебный курс MCSE. Пер. с англ.-2е издание, переработанное. - М.:Издательско-торговый дом «Русская Редакция», 2001 г.

18.Благодомских В.А., Енгибарян М.А., Ковалевская Е.В., Экономика, разработка и использование программного обеспечения ЭВМ - М. Финансы и статистика, 1995.

19.Котляров В.П., Минаев Д.В.. Методы и средства автоматизации тестирования программного проекта. Учебное пособие. - СПБ.: Изд-во Санкт-Петербургского государственного технического университета, 1998.

20.Семенов А.И., Семенова О.В. Практикум по программированию на Турбо Паскале: Учеб. пособие для вузов. В 2-х ч. Ч.1. - 3-е изд. - Абакан: Изд-во Хакасского государственного университета им. Н.Ф.Катанова, 2004 г.

21.Шкарина Л.Н. Методические рекомендации по выполнению научно-исследовательских работ для студентов информационных специальностей. - Абакан; Издательство Хакасского государственного университета им. Н.Ф. Катанова, 2003.
Заказать написание новой работы



Дисциплины научных работ



Хотите, перезвоним вам?