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

Текст из файла (страница 4)

Рисунок 3.2-Медот описывающий вход в команды основного меню

Метод, который заменяет внутренности вкладки «Параметры», добавляет соответствующие акселераторы и вставляет на главную форму меню с элементами выбранного компонента программы, представлен на рисунке 3.3.

Рисунок 3.3- Метод по загрузке выбранных компонентов

Были созданы классы Leikoformula, Mielogramma, Trombocity. Базовым классом для создания выше перечисленных классов является Data. Представление класса Data представлено на рисунке 3.4.

Рисунок 3.4- Представление класса Data

Представление класса Leikoformula представлено на рисунке 3.5.

Рисунок 3.5- Представление класса Leikoformula

Представление класса Mielogramma представлено на рисунке 3.6.

Рисунок 3.6- Представление класса Mielogramma

1. 3.2 Взаимодействие приложения с источниками данных

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

Представление класса CLeikoformulaSetAccessor представлено на рисунке 3.7.

Рисунок 3.7 – Представление класса CLeikoformulaSetAccessor

Карата событий, в которой происходит привязка объекта LEIKOFORMULA к соответствующим полям таблицы «Лейкоформула» в базе данных представлена на рисунке 3.8.

Рисунок 3.8 – Карта событий

Представление класса CMielogrammaSetAccessor представлено на рисунке 3.9.

Рисунок 3.9 – Представление класса CMielogrammaSetAccessor

Карата событий, в которой происходит привязка объекта MIELOGRAMMA к соответствующим полям таблицы «Миелограмма» в базе данных представлена на рисунке 3.10.

Рисунок 3.10 – Карта событий

1. 3.3 Тестирование приложения

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

Тестирование приложения «Гематологический счетчик» производилось в среде разработки MS Visual Studio 2005, удобство этого средства тестирования заключается в возможности его использования в режиме отладки приложения под управлением встроенного отладчика Visual Studio.

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

Рисунок 3.11 – «Сообщение об ошибке».

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

Рисунок 3.12 – «Ошибка в приложении».

Пример распознавания ошибки показан на рисунке 3.12. В файле Hematology_CounterView.cpp была задана функция в которую было передано неправильное значение параметра. Можно сделать следующий вывод о том что был задан неправильный идентификатор на этапе разработке.

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

Рисунок 3.12 – «Работающее приложение».

1. 3.4 Методика развертывания приложения

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

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

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

На сервере должна быть установлена программа SQL Server 2005. Заведующему КДЛ и врачу-лаборанту должны быть предоставлены права на внесение изменений в базу данных.

2. Выводы к разделу

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

Продемонстрирована реализация взаимодействия компонента с СУБД и с клиентским приложением.

1. 4. Управление информационным проектом

   2. 4.1 Выбор жизненного цикла разработки

В соответствии с определением, приведенным в [Error: Reference source not found], модель жизненного цикла разработки ПО (software life cycle model, SLCM) схематически объясняет, в каком порядке будут выполняться действия по разработке программного продукта. Такая последовательность может быть не линейной, так как фазы могут следовать последовательно, повторяться, или происходить одновременно.

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

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

Таблица 4.1- Определение оптимальной модели жизненного цикла в баллах

Из данных приведенных в таблице можно сделать следующие выводы. Для разрабатываемой ЛИС для лабораторного отделения БСМП-2,наиболее подходящей моделью ЖЦ является метод быстрой разработки приложений «RAD».

Характерной чертой «RAD» является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций эволюционной системы или прототипов, критический анализ которых обсуждается с заказчиком. В процессе такого анализа формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени, который, как правило, составляет 60 дней и называется временным блоком.

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

При выполнении нашего проекта, для которого модель «RAD» подходит в достаточной мере, появляются следующие преимущества:

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

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

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

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

• модель обеспечивает эффективное использование имеющихся в наличии средств и структур;

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

• в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

• основное внимание переносится с документации на код, причем при этом, соблюдая принцип «получите то, что видите»;

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

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

1. 4.2 Определение цели и области действия программного проекта

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

Задачи проекта:

• выполнить сбор, спецификацию и аттестацию требований

• выполнить проектирование информационного и программного обеспечения системы;

• разработать скрипты описания базы данных и программные коды приложения;

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

Программный проект должен быть:

• продуктом для внутреннего использования в БСМП-2;

• проектом для осуществления многопользовательского доступа;

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

Программный проект не должен быть:

• проектом, доступным для посторонних лиц.

При определении области действия программного продукта эффективнее всего воспользоваться методикой «будет,/не будет». Ниже определены рамки проекта.

Проект будет:

• сетевым;

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

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

• применяться в операционных системах Windows.

Проект не будет:

• локальным;

• использоваться в системах отличных от Windows.

1. 4.3 Создание структуры пооперационного перечня работ

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

• планирование и активизация проекта;

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

• фаза описания пользователя;

• фаза «расчистки».

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

Модель RAD, представляет собой специальный случай линейной модели. Главной отличительной чертой этой модели является то, что для нее присущ чрезвычайно короткий цикл разработки ПО, при осуществлении которого используется конструкция, основанная на компонентах. Для данного дипломного проекта была выбрана модель RAD и посредствам ее показана версия задач и действий, необходимых для построения жизненного цикла ЛИС.

Характеристики

Список файлов ВКР