Второй возможностью доступа к данным является использование OLE DB Provider. Такой способ позволяет осуществлять доступ к любому OLE DB провайдеру, включая Access.

В реализованном приложении ADO.NET мы использовали одно пространство имен -- System.Data. Кроме того, нам практически во всех ситуациях потребуется использовать еще либо пространство имен System.Data.OleDb-- для установления соединения с источником данных.

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

§ открыть соединение (connection) с базой данных;

§ вызвать на исполнение метод или команду, указав ей в качестве параметра текст SQL-запроса;

§ закрыть соединение с базой данных.

Связь с базой данных остается активной только на достаточно короткий срок -- на период выполнения запроса. [45]

После записи информации из таблиц в приложение связи с БД закрывается.

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

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

В данном дипломном проекте в качестве тестирования был использован метод тестирования «черного ящика».

План тестирования ПО представлен в ПРИЛОЖЕНИИ Г.

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

1. Нет данных;

2. Повторное выполнение;

3. Верные данные.

Пример теста когда «нет данных» показан на рисунке 3.3.1:

Рисунок 3.3.1 - тестовый пример «нет данных»

Пример теста когда «повторное выполнение», т.е. введение одних и тех же значений, показан на рисунке 3.3.2:

Рисунок 3.3.2 - тестовый пример «Повторное выполнение»

Пример теста когда «верные данные» показан на рисунке 3.3.3.

Рисунок 3.3.2 - тестовый пример «Повторное выполнение»

Реализация и аттестация информационной системы один из самых важных процессов создания программы «Информационная система МРССиСТ». В заключении необходимо добавить, что этап реализации начинается сразу после проектирования информационной системы. На данном этапе были составлены бизнес-правила, показаны алгоритмы и циклы используемые при реализации приложения. Описано взаимодействие приложения с источниками данных ADO.NET -- это новая технология доступа к базам данных. На этапе реализации было проведено тестирование созданной системы методам «черного ящика». В результате был получен отчёт о тестировании. В целом этап прошёл успешно.

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

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

Разработка разбивается на четыре этапа:

- планирование;

- анализ риска;

- оценка заказчика;

- конструирование.

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

- небольшую команду программистов (от 2 до 10 человек);

- короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

- фаза анализа и планирования требований;

- фаза проектирования;

- фаза построения;

- фаза внедрения.

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

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

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

- общая информационная модель системы;

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

- точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

- построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности. [14]

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

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

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

- определяется необходимость распределения данных;

- производится анализ использования данных;

- производится физическое проектирование базы данных;

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

- определяются способы увеличения производительности;

- завершается разработка документации проекта.

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

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

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

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

Таблица 4.1 - Размер приложения

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10