РЕФЕРАТ

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

ИНФОРМАЦИОННАЯ СИСТЕМА, РАБОТА С ДАННЫМИ, ИНТЕФЕЙС, ТРЕБОВАНИЯ, МОДЕЛЬ ЖИЗНЕННОГО ЦИКЛА, МОДЕЛИРОВАНИЕ, ПРОЕКТИРОВАНИЕ, РЕАЛИЗАЦИЯ, ЛОГИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, ФИЗИЧЕСКАЯ МОДЕЛЬ СТРУКТУРЫ ДАННЫХ, БАЗА ДАННЫХ, ТЕСТИРОВАНИЕ, ФИЗИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ, ЛОГИЧЕСКОЕ ПРЕДСТАВЛЕНИЕ СИСТЕМЫ.

Темой дипломного проекта является «Разработка подсистемы учета гематологических анализов для КДЛ ГБСМП-2».

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

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

СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. РАЗРАБОТКА ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
• 1.1 Анализ существующих решений по автоматизации предметной области
• 1.2 Анализ предметной области
• 1.3 Выбор методологии проектирования информационной системы
• 1.4 Сбор требований
• 1.5 Спецификация требований
• 1.6 Аттестация требований
• Выводы
• 2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 2.1 Архитектурное проектирование
• 2.2 Проектирование интерфейса информационной системы
• 2.3 Проектирование базы данных
• 2.4 Обоснование выбора платформы создания информационной системы
• 2.5 Проектирование модулей
• Выводы к разделу
• 3. РЕАЛИЗАЦИЯ И АТТЕСТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ
• 3.1 Реализация приложения
• 3.2 Взаимодействие приложения с источниками данных
• 3.3 Тестирование приложения
• 3.4 Методика развертывания приложения
• Выводы к разделу
• 4. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМ ПРОЕКТОМ
• 4.1 Выбор жизненного цикла разработки
• 4.2 Определение цели и области действия программного проекта
• 4.3 Создание структуры пооперационного перечня работ
• 4.4 Идентификация задач и действий
• 4.5 Оценка размера и возможности повторного использования
• 4.6 Оценка длительности и стоимости разработки проекта
• 4.7 Распределение ресурсов проекта
• 4.8 Оценка экономической эффективности проекта
• Выводы к разделу
• ЗАКЛЮЧЕНИЕ
• СПИСОК СОКРАЩЕНИЙ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ПРИЛОЖЕНИЕ А Спецификация требований к программному обеспечению
• ПРИЛОЖЕНИЕ Б - Прототиты пользовательского интерфейса
• ПРИЛОЖЕНИЕ В - Атрибуты управляющих таблиц проектируемой подсистемы ЛИС
• ПРИЛОЖЕНИЕ Г - DDL сценарий создания объектов базы данных
• ПРИЛОЖЕНИЕ Д - Тексты программ
• ПРИЛОЖЕНИЕ Е - ОБОСНОВАНИЕ МОДЕЛИ ВЫБОРА ЖИЗНЕННОГО ЦИКЛА

Введение

Рассматриваемая дипломная работа написана на базе клинико-диагностической лаборатории (КДЛ) МЛПУ ГБСМП №2 г. Ростова-на-Дону.

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

Однако при этом одной из проблем КДЛ ГБСМП №2 является практическое отсутствие автоматизации учета проведенных гематологических исследований. Между тем, в условиях развития страховой медицины все больше возрастает необходимость эффективного учета затрат на проведение анализов, расчет заработной платы сотрудников в соответствии с реальной нагрузкой на работающий медперсонал, составление различных отчетов о результатах деятельности КДЛ в целом. Эти не производственные затраты отнимают значительное время как у руководителей, так и у персонала КДЛ.

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

Внедрение лабораторной информационной системы (ЛИС) клинико-диагностической лаборатории МЛПУ ГБСМП №2 актуально для всей больницы в целом, так как может позволить ускорить получение текущей информации о проводимых анализах. А внедрение подсистемы позволит автоматизировать процесс учета гематологических анализов, т.е. результаты исследования будут автоматически сохраняться в БД.

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

Для достижения вышеуказанной цели необходимо решить следующие задачи:

- осуществить бизнес-моделирование процессов лаборатории, для разрабатываемой подсистемы информационной системы;

- провести анализ требований к системе и ее проектирование;

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

- осуществить тестирование серверной части;

- провести оценку эффективности технологии разработки.

1. Разработка требований к программному обеспечению

1.1 Анализ существующих решений по автоматизации предметной области

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

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

Принципиально новым направлением является внедрение и широкое использование жидкостных гематологических анализаторов, выполняющий частичный или практически полный анализ клеток крови и определяющих показатели красной крови, в том числе гемоглобин, гематокрит и эритроцитарные индексы. Для подсчета и анализа клеток крови используют гематологические анализаторы разного уровня сложности. Преимуществом современных технологий подсчета и оценки форменных элементов крови является: высокая производительность (до 100-120 проб в час), небольшой объем крови для анализа (12-150 мкл), анализ большого массива (десятки тысяч) клеток, определение с высокой точностью и воспроизводимостью 20 и более параметров анализа крови одновременно, графическое представление результатов исследований (гистограммы, скетограммы). По сравнению с визуальной техникой автоматический подсчет - более точный метод оценки концентрации клеток. Автоматизированный анализ крови открыл много новых диагностических возможностей, но одновременно он располагает и некоторыми ограничениями, особенно касающихся морфологических исследований клеток. Несмотря на все достоинства, даже самые современные анализаторы не в состоянии полностью заменить метод микроскопической оценки клеток.

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

В настоящее время на российском рынке существуют следующие виды ЛИС для клинико-диагностических лабораторий:

- «ALTEY Laboratory»;

- Медицинская лабораторная информационная система АИС «АЛИС»;

- «Химик-аналитик»;

- ЛИС «ИНТРАЛАБ» и «Лабораторный журнал»;

Автоматизированная лабораторная медицинская информационная система (АЛИС) (см. рисунок 1.1) предназначена для автоматизации работы клинической лаборатории лечебно-профилактических учреждений (ЛПУ).



Рисунок 1.1 - Структура АЛИС

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

ИС «Химик-аналитик» не является системой разрабатывавшейся непосредственно для лабораторий медицинских учреждений . С этим связаны ее особенности.

Данная ЛИС предназначена для решения следующих задач:

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

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

- внутрилабораторный контроль в соответствии с ГОСТ Р ИСО 5725-2002 и МИ 2335-2003 [10]; строить градуировочную характеристику методом наименьших квадратов и рассчитывать по ней значения измеряемой величины; оценивать метрологические характеристики (правильность, прецизионность, точность) в каждой конкретной лаборатории по МИ 2336-2002;

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

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

- организация системы менеджмента качества лаборатории по ГОСТ Р ИСО/МЭК 17025-2000.

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

ЛИС «ИНТРАЛАБ» (см. рисунок. 1.2) разработана для автоматизации и оптимизации деятельности клинико-диагностической лаборатории и внутрилабораторного управления качеством. Функциональные возможности данной системы включают:

- обеспечение ввода и хранения справочной информации;

- ввод и хранение проводимых лабораторией исследований (тестов);

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

- ведение клиентской базы пациентов;

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



Рисунок 1.2 - ЛИС «ИНТРАЛАБ»

ЛИС «ИНТЕРЛАБ» позволяет вести учет гематологических анализов, но из описания данной системы можно сделать вывод о том, что для КДЛ БСМП она не подходит. Установка этого пакета программ потребует больших финансовых затрат. Данная ЛИС подходит для более мелких лабораторий, основанных на коммерческой основе.

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

1.2 Анализ предметной области

Разрабатываемая подсистема используется в следующих отделах КДЛ ГБСМП №2 [11]:

- гематологический;

- клинической экспресс лаборатории.

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

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

Основными задачами отделения являются:

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

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

- постоянный контроль качества проведенных гематологических исследований;

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

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

Рисунок 1.3 - Диаграмма основных категорий сотрудников БСМП, имеющих доступ к подсистеме гематологических анализов

Основные типы лабораторных анализов представлены на рис. 1.4.

Рисунок 1.4 - Типы лабораторных анализов

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

На диаграмме бизнес-вариантов использования представлены основные направления деятельности врача-лаборанта, лаборанта и лечащего врача (рисунок 1.5) [12].



Рисунок 1.5 - Диаграмма бизнес-вариантов использования

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

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

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

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

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

Гематологические исследования _ это анализ свойств крови. Материалом для исследования является венозная или капиллярная кровь. Мазок крови представлен на рисунке 1.7.

Рисунок 1.7- Мазок крови

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

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

1.3 Выбор методологии проектирования информационной системы

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

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

- выбор больного из базы данных;

- определение отделения, подающего заявку;

- задание времени;

- выбор типов проводимых исследований.

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

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

На современном этапе развития технологии проектирования одной из популярных технологий реализации подобных систем является технология COM и ActiveX элементов [14, 15]. Данные объекты реализуются на основе множественного наследования и обладают открытым интерфейсом взаимодействия с объектами внешнего мира.

Разработка подсистемы как набора COM и ActiveX объектов позволит реализовать пространство решений для использования в других прикладных системах подобного типа.

1.4 Сбор требований

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

На этапе формирования и анализа требований в соответствии с технологией разработки программного обеспечения Microsoft Solution Framework (MSF):

- осуществляется сбор требований;

- составляются профили заинтересованных лиц;

- разрабатываются варианты использования.

Методология сбора требований обычно основывается на использовании метода интервьюирования и изучения документации, описывающей деятельность КДЛ БСМП-2, для которой осуществляется разработка информационной системы.

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

1.5 Анализ и моделирование требований

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

Основными требованиями к подсистеме учета гематологических анализов для проектируемой ЛИС являются следующие:

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

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

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

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



Рисунок 1.8 - Диаграммы вариантов использования для основных категорий пользователей подсистемы гематологических исследований

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

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

1.6 Аттестация требований

Аттестация требований определяет степень соответствия программного продукта (ПП) установленным требованиям [18, 21].

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

1. Обзор требований - процесс просмотра системной спецификации на предмет неточных описаний и ошибок.

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

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

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

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

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



Рисунок 1.9 - Диаграмма состояний проектируемой подсистемы

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

Выводы

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

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

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

2. Проектирование информационной системы

2.1 Архитектурное проектирование

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

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

Основной сервер ЛИС, поддерживающий функционирование базы данных системы, совмещается либо с автоматизированным рабочим местом (АРМ) заведующего лабораторией или старшего лаборанта, что было определено на предыдущем этапе проектирования ЛИС. Рабочие места сотрудников гематологического отдела и клинической экспресс-лаборатории оборудуются мини ноутбуками с установленной Windows XP.

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

Рисунок 2.1 - Примерная архитектура ЛИС для учета гематологических анализов.

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

Данное приложение связывается с сервером БД на основании реализации клиент-серверной архитектуры. Запуск приложения производится из диспетчерской программы ЛИС. Компонентная модель гематологической подсистемы представлена на рисунке 2.2.



Рисунок 2.2 - Компонентная модель для учета гематологических анализов

В целом гематологическая подсистема работает на основе технологии COM/DCOM. При этом бизнес процессы системы реализуются как отдельные COM модули, которые осуществляют доступ к данным [23]. Гематологический счетчик является независимым MFC приложением, взаимодействующим с гематологической подсистемой через автоматизацию объектов. А взаимодействие с лабораторной БД осуществляется на основе технологии OLE DB. Архитектура доступа к данным представлена на рисунке 2.3.

Рисунок 2.3 - Универсальная архитектура доступа к данным.

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

2.2 Проектирование интерфейса информационной системы

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

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

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

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

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

Графическое изображение интерфейса главного меню представлено на рисунке 2.4.



Рисунок 2.4- Графическое изображение интерфейса главного окна программы.

Графическое изображение окна для подсчета лейкоцитарной формулы представлено на рисунке 2.5.

Рисунок 2.5- Графическое изображение окна для подсчета лейкоцитарной формулы.

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



Рисунок 2.6- Графическое изображение окна для подсчета миелограммы.

2.3 Проектирование базы данных

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

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

Разработка концептуальной модели данных была осуществлена с использованием Case-средства Erwin 4.0. Данное программное средство использовалось в связи с тем, что Rational Rose Enterprise Edition 2002 не поддерживает взаимосвязи с Microsoft SQL Server 2005.

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

- создание логической модели;

- создание физической модели.

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

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

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

Для описания гематологических исследований такими сущностями являются: «Лейкоформула», «Тромбоциты», «Миелограмма», «Ед. измерения», «Показатели числовые». Доработанная логическая модель данных системы лабораторных исследований представлена на рисунке 2.4.



Рисунок 2.4 - Логическая модель данных

Внесенные изменения в структуру БД Laboratory, реализованную в MS SQL Server 2005 представлены на рисунке 2.5.

Рисунок 2.6 - Структура данных подсистемы учета гематологических анализов

2.4 Обоснование выбора платформы создания информационной системы

Платформой для создания программного продукта по учету гематологических анализов является Visual Studio 2005. Приложение реализуется на языке C++. Этот выбор обусловлен тем, что существующая версия ПО и все подключаемые модули системы реализованы на C++ для Visual Studio 2005 [39]. В качестве базовой библиотеки классов для основного управляющего компонента ПО используется библиотека MFC, обеспечивающая реализацию архитектуры Document/View. Настройка данной библиотеки под шаблон реализации комплекса реализованы в используемой динамически подключаемой библиотеке MFC_Lab.dll. Эта библиотека обеспечивает реализацию программного интерфейса взаимодействия с компонентами прорисовки графиков в основном окне управляющего компонента, а также интерфейсы межпрограммного взаимодействия.

2.5 Проектирование модулей

Основная задача проектирования заключается в том, чтобы превратить модели анализа в документы детализированного проектирования, на основе которых реализуется система. Логическая модель проектируемой подсистемы строится на основе технологии Rational [30], используя основные объектно-ориентированные подходы языка UML [33, 34].

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

Основными функциями, реализуемыми над этими сущностями, являются функции ввода нового элемента, удаления и модификации существующих элементов.

Каждый ActiveX-элемент с одной стороны является сервером для модуля, осуществляющего управление вызовами используемых элементов. С другой стороны данные элементы являются клиентами, осуществляющими запросы соответствующих данных из хранилища и их модификацию. Взаимодействие ActiveX-элементов с СУБД, как указывалось, осуществляется с использованием технологии OLE DB.

Для реализации функциональности сервера, взаимодействующего с клиентом, реализованном на произвольном языке программирования, данные элементы наследуются от интерфейса IDispatch. Для взаимодействия с сервером БД используются модуль стандартной динамической библиотеки stdole.dll. Диаграмма классов данного модуля, обеспечивающего функциональность COM, представлена на рисунке 2.7.



Рисунок 2.7 - Диаграмма классов, модулем гематологического счетчика

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

Во втором разделе выполнено проектирование подсистемы учета гематологических анализов для КДЛ.

На данном этапе были построены модели логического и физического представления подсистемы. Разработана база данных подсистемы.

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

3. Реализация и аттестация информационной системы

3.1 Реализация приложения

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

Разработка модулей приложения производится при помощи следующих программных средств: Microsoft SQL Server 2005, MS Visual Studio 2005. С помощью этих средств был разработан модуль «Гематологический счетчик».

Добавление обработки вкладки команды основного меню представлено на рисунке 3.1

Рисунок 3.1- Обработка вкладки команды основного меню

Метод, который описывает вход во вкладку команд основного меню и выбор одной из команд, представлен на рисунке 3.2.



Рисунок 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

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

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

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



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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	5	5	2	2	5	4
Участники команды разработчиков	4	5	5	2	6	5
Коллектив пользователей	3	6	5	8	4	6
Типы проектов и рисков	1	1	3	1	8	3
Итого	13	17	15	13	23	18

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- сетевым;

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

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

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

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

- локальным;

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

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

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

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

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

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

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

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

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

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



Рисунок 4.1 - Пооперационный перечень работ ИС

4.4 Идентификация задач и действий

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

Разрабатываемый модуль является частью проектируемой ЛИС. ЛИС разрабатывается на основе спиральной модели, первые два прохода которой выполнены в 2006-2007 году. В настоящее время идет третий проход разработки. Подсистема по учету гематологических анализов разрабатывается в рамках третьего прохода как независимый проект. Для этого модуля была определена технология проектирования RAD. Данный проект включает в себя следующие фазы:

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

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

- Описание пользователя (процесс разработки проекта, разработка проекта, процесс внедрения);

- «расчистка», которая включает в себя установку.

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