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

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

изучение структуры создания и редактирования тестов;

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

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

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

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

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

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

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

Задачи программного продукта:

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

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

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

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

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

Проект представляет собой программный продукт, предназначенный для создания и редактирования тестов. Данная программа была разработана во время изучения курса «Создание 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. Внутренние спецификации.

Внешние спецификации включают в себя:

- внешние интерфейсы;

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

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

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

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

- реализация интерфейсов;

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

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

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

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

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

- структура и среда тестовой системы;

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

- периодичность тестирования.

3. План информационной разработки.

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

· SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

· DFD (Data Flow Diagrams) диаграммы потоков данных;

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

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

SADT-диаграмма

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

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

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

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

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

Рис.2.2.1. SADT-диаграмма

Рис.2.2.2. Декомпозиция SADT-диаграммы

DFD-диаграмма

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

Рис. 2.2.3. DFD - диаграмма

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

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

3.Программная реализация

3.3 Работа справки в программе «Система тестирования знаний»

void __fastcall TForm3::Button3Click(TObject *Sender) - описана функция нажатия кнопки, т.е. при нажатие кнопки выполняется:

{

Application->HelpCommand(HELP_CONTEXT,3); - открывается 3 страница справки (вычисление).

}

Стадия подготовки к внедрению включает в себя SADT и DFD-диаграммы, которые были представлены в предыдущем разделе.

Фаза внедрения состоит из этапов:

1. комплексные испытания;

2. подготовка кадров для эксплуатации;

3. подготовка документации;

4. сдача заказчику;

5. ввод в эксплуатацию;

6. сопровождение системы;

7. поддержка;

8. сервисное обслуживание.

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

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

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

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

4. Создана справки с помощью программы «Система тестирования знаний». Реализован программный код.

Заключение

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