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

РЕФЕРАТ

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

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

Темой дипломного проекта является «Разработка подсистемы учета гематологических анализов для КДЛ ГБСМП-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. Данный проект включает в себя следующие фазы:

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

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

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

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

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

4.5      Оценка размера и возможности повторного использования

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

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

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

Повторное использование может обеспечить прогресс на следующих направлениях:

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

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

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

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

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

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

4.6 Оценка длительности и стоимости разработки проекта

Оценку длительности разработки любого программного продукта можно определить только после того, как будет определен пооперационный перечень работ необходимых для создания и внедрения данного продукта. Перечень необходимых работ для разработки и внедрения ИС «Учет гематологических анализов» был освещен и показан в пункте 4.3 рисунок 4.1. Оценку длительности изображают с помощью диаграммы Ганта. Диаграммы являются графическим средством отображения содержащейся в проектном файле информации. Диаграммы дают визуальное представление о последовательности задач, их относительной длительности и длительности проекта в целом.

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

В MS Project диаграмма Ганта является основным средством визуализации плана проекта. Эта диаграмма представляет собой график, на котором по горизонтали размещена шкала времени, а по вертикали расположен список задач. При этом длина отрезков, обозначающих задачи, пропорциональна длительности задач /4/.

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

Одним из наиболее важных свойств любого ресурса является стоимость (Cost (Затраты)) его использования в проекте. В MS Project выделяется два типа стоимости ресурсов: повременная ставка и стоимость за использование. Повременная ставка (Rate) выражается в стоимости использования ресурса в единицу времени, например 60 рублей в час или 480 рублей в день. Повременная ставка используется для людских, а также для каких-либо материальных ресурсов. В таком случае стоимость участия ресурса в проекте составит время, в течение которого он работает в проекте, умноженное на почасовую ставку. В разработанном мной проекте использовалась повременная ставка (рисунок 4.2) Общие же затраты на использование ресурсов по всему проекту можно увидеть на рисунке 4.3.

Рисунок 4.2 – Повременная ставка в использовании ресурса

Рисунок 4.3 – Общие затраты на использовании ресурсов проекта в третьем проходе

4.7 Распределение ресурсов проекта

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

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

Распределение ресурсов проекта при создании системы «учета гематологических анализов» можно представить в виде перечня представленного на рисунке 4.4.

Рисунок 4.4 – Распределение ресурсов проекта для третьего прохода

4.8 Оценка экономической эффективности проекта

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

Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

¾        Выделить цели работы системы.

¾        Определить наборы показателей, характеризующих определенную цель.

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

¾        Рассчитать степень достижения каждой цели по выдвинутым показателям.

¾        Определить весовые коэффициенты целей.

¾        Рассчитать общий показатель эффективности разрабатываемой информационной системы.

Для оценки эффективности воспользуемся методом экспертных оценок. Метод расчета в данном случае состоит из нескольких этапов:

¾        Выделить цели работы системы.

¾        Определить наборы показателей, характеризующих определенную цель.

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

¾        Рассчитать степень достижения каждой цели по выдвинутым показателям.

¾        Определить весовые коэффициенты целей.

¾        Рассчитать общий показатель эффективности разрабатываемой информационной системы.

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

, (4.1)

где u(g_i) – степень достижения цели, баллы;

 – значение показателя, баллы;

K – количество показателей.

Весовой коэффициент вычисляется по формуле:

, (4.2)

где – весовой коэффициент, баллы;

V_i – оценка, баллы.

Расчет оценки ведется по формуле:

, (4.3)

где V_i – оценка, баллы;

R_min – минимальное значение ранга, баллы;

R_i – сумма рангов, баллы.

Для расчета суммы рангов воспользуемся формулой:

, (4.4)

где R_i – сумма рангов, баллы;

r_i – значение, выставленное экспертом, баллы;

n – количество экспертов.

При этом проверяется согласованность мнений экспертов путем расчета значения известного коэффициента q Кендала (конкордации), для оценок данных экспертами.

Общий показатель эффективности рассчитывается как:

, (4.5)

где E_m – показатель эффективности, баллы;

w_i – весовой коэффициент, баллы;

u(g_i) – степень достижения цели, баллы.

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

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

Все это сведем в таблицу (таблица 1).

Таблица 1 – Цели, показатели и уровень достижения работы ИС

Цель	Показатель	Уровень достижения, баллы	Степень достижения целей
g1 – технический уровень	y11 - минимизация количества ошибок при выполнении лабораторных исследований	0,85	0,916666667
	y12 – автоматизированный ввод результатов ручных методов исследований	0,9
	y13 – автоматизация получения заказов, выдачи результатов и отчетов	1
g2 – коммуникация	y21 – оперативность	0,82	0,86
	y22 – удобство использования	0,9
g3 – социальные цели	y31 – улучшение условий труда	0,85	0,88
	y32 – внедрение групповых форм работы	0,79
	y33 – уменьшение времени выполнения иссле-дований	1
g4 – получение отчетности	y41 – автоматическое получение отчетов	0,9	0,95
	y42 – уменьшение объема рутинной работы пер-сонала лаборатории	1
g5 – простота использования	y51 – легко понимаемый интерфейс пользовате-ля	0,95	0,883333333
	y52 – возможность поиска	0,8
	y53 – возможность сохранения, извлечения и редактирования документов	0,9

Для определения весовых коэффициентов был применен экспертный опрос десяти человек. Список опрошенных приведен в таблице 2.

Таблица 2–Список опрошенных.

ФИО опрошенного		Должность
Романенко Н.А		Зав. лабораторией
Колесникова Н.А.	Старшая медицинская сестра
Наумов Н.П.	Старший лаборант
Солонина Е.А.	Врач
Петрова С.А.	Врач
Шеховцов Д.В.	Врач
Малахина Н.П.	Младший медицинский работник
Токарева И.Р.	Зав. отделением больницы
Игнатенко Е.В.	Сотрудник КДЛ
Понамарева В.С.	Сотрудник КДЛ
Чернова Т.С.	Сотрудник КДЛ

Результаты опроса представлены в таблице 3.

Таблица 3 – Результаты опроса в баллах

Эксперты	Критерии оценки
	g1	g2	g3	g4	g5
Э1	4	3	4	1	2
Э2	3	4	5	1	2
Э3	3	4	5	2	1
Э4	5	1	4	2	3
Э5	3	2	5	4	1
Э6	3	5	4	1	2
Э7	3	4	5	2	1
Э8	5	3	4	2	1
Э9	4	3	2	1	5
Э10	3	4	5	2	1
Ранг R	36	33	43	18	19
Ранг минимальный	18
Оценка	0,50	0,55	0,42	1,00	0,95
Общая оценка	3,41
Весовой коэффициент	0,14656621	0,15989041	0,12270659	0,293132	0,27770439
Общий показатель эффективности	0,903184109

Таким образом, можно сказать, что эффективность работы разработанной нами информационной системы по отношению к заданным целям составляет 0 баллов, то есть только на 90% система работает оптимально. Неэффективность работы ИС составляет 10%. На основании представленных результатов можно сделать вывод, что внедрение проекта «Разработка подсистемы учета анализов для информационной системы лабораторного отделения ГБСМП-2» – целесообразно.

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

 

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

Заключение

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

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

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

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

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

После проектирования интерфейса программы, осуществлено моделирование структуры данных (логическая и физическая модели). Программное средство используемое для создания CASE-средства использовался программный продукт Rational Rose 2000 Enterprise Edition. Был рассмотрен использованный программный инструментарий. В качестве среды разработки программного обеспечения была использована Microsoft Visual Studio 2005 и язык программирования C++.

В третьем разделе дипломного проекта рассмотрена реализация программного продукта и вопросы связанные с реализацией. Реализованы функции и классы взаимодействия с базой данных. Приведены методы и свойства классов. Продемонстрирован фрагментарно исходный код. Так же рассмотрена и продемонстрирована методика взаимодействия приложения с СУБД MS SQL Server 2005. Проведено тестирование программного кода с использованием стандартных средств предоставляемых Microsoft Visual Studio 2005.

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

В четвертом разделе дипломного проекта определялась цель и область действия программного продукта. Осуществлен выбор модели жизненного цикла процесса разработки по результатам представленным в таблице 4.1 – «Определение оптимальной модели жизненного цикла в баллах». Составлена структура пооперационного перечня работ с использованием пакета управления проектами Microsoft Project 2003, на её основе построен график выполнения работ, приведена диаграмма Ганта. Была рассчитана экономическая эффективность проекта.

По ходу выполнения дипломного проектирования были использованы такие программные продукты как:

-     ERWin 4.0;

-     MS SQL Server 2005;

-     MS Project 2003;

-     MS Word 2003;

-      MS Excel 2003;

-     Rational Rose.

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

Список сокращений

АРМ – автоматизированное рабочее место;

БД – база данных;

ЖЦ – жизненный цикл;

ИС – информационная система

КДЛ – клинико-диагностическая лаборатория;

ЛИС – лабораторная информационная система;

ПО – программное обеспечение;

ПП – программный продукт;

ПК – персональный компьютер;

СУБД – система управления базами данных;

COM – component object model;

OLAP – Online Analytical Processing, система обработки аналитической информации;

SLCM – software life cycle model, модель жизненного цикла;

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1.   Лабораторные информационные системы – цели установки, основные функции, проблемы выбора и внедрения. [Электронный документ] http://laboratory.rusmedserv.com/laborauto/ Проверен 20.05.08.

2.   Лабораторные информационные системы на отечественном рынке. [Электронный документ] http://www.asutp.ru/?p=600629 Проверен 20.05.08.

3.   Нуцков, Ю.В., Хиллхауз Б. Интеграция LabWare LIMS и SAP R/3 QM // Мир компьютерной автоматизации. 2003. 4. С. 56-63

4.   LabWare LIMS. [Электронный документ] http://www.labanswer.com/solutions/Labware.asp Проверен 20.05.08.

5.   Савельев, Е.В. Лабораторно-информационные менеджмент-системы или автоматизация лаборатории "в целом" // Партнеры и конкуренты. 2005. 4. С. 41-43.

6.   Меркуленко, Н.Н. LIMS. Современный этап развития // Лабораторные информационные системы LIMS. Сборник статей: ООО "Маркетинг. Информационные технологии". 2006. С. 215-219

7.   Терещенко, А.Г., Терещенко О.В., Соколов В.В., Юнусов Р.Ш. АРМ "Химик-аналитик" в системе качества продукции // Материалы международной НПК "Качество-стратегия XXI века". 11-12.11.99. Томск, 1999. С. 71-72

8.   ЛИС Химик-аналитик/Краткая информация. [Электронный документ] http://www.chemsoft.ru/index.php?razdel=products&info=small&text1=2&text2=1&tema=c_2 Проверен 20.05.08.

9.   Лабораторные информационные системы. [Электронный документ] http://www.intralab.ru Проверен 20.05.08.

10.          Точность (правильность и прецизионность) методов и результатов измерений. Государственный стандарт Российской Федерации. [Электронный документ] http://www.labinfo.ru/bibl/knigi/gost/index.htm Проверен 20.05.08.

11.          Деятельность клинико-диагностической лаборатории МЛПУ ГБСМП-2 г. Ростов-на-Дону за 2006 год. (Рукописный) – 2007 г. 10 стр.

12.          Приказ №183

13.          Цимбал А. Технология CORBA для профессионалов. – СПб.: Питер. – 2001. – 624 с.

14.          Оберг Р. Технология COM+. Основы и программирование. / Пер. с англ. Уч. пос. – М.: Издательский дом «Вильямс». – 2000. – 480 с.

15.          Армстронг Т. ActiveX: создание Web-приложений. К.: BHV. 1998. – 592 с.

16.          Чарнецки К. Порождающее программирование: методы, инструменты, применение. Для профессионалов. Пер. с англ. / Чарнецки К., Айзенекер У. – СПб.: Питер. – 2005. – 731 с.

17.          Software Engineering Institute. What is Model-Based Software Engineering. [Электронный документ] – www.sei.cmu.edu/mbse/ – 1997. – Проверен 5.06.08.

18.          Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат.: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. – М.: Издательский дом "Вильямс", 2003.

19.          Вигерс, К. Разработка требований к программному обеспечению.: Пер. с англ. / К. Вигерс.:– М.: Издательско-торговый дом «Русская редакция», 2004

20.          Мацяшек, Л. А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. / Л. А. Мацяшек. Пер. с англ. – М.: Издательский дом «Вильямс». – 2002.

21.          Вендров, А.М. CASE технологии Современные методы и средства проектирования информационных систем. / А.М. Вендров.- М.: Финансы и статистика, 1998. – 193 с.

22.          Digital Point – лучший среди равных. Каталог. Acer N311 [Электронный документ] – http://www.pda-digipoint.ru/index.php?productID=91 – 2007. – Проверен 9.05.08.

23.          SQL Server General Technical Articles. The Microsoft Data Warehousing Strategy. A Platform for Improved Decision-Making through Easier Data Access and Analysis. MSDN. - 2006.

24.          Справочник по Microsoft OLE DB 1.1. / Пер. с англ. – М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd». 1997. – 624 с.

25.          Мандел Т. Дизайн интерфейсов: Модели пользовательского интерфейса; Объектно-ориентированные интерфейсы; Этапы разработки интерфейса; Web-интерфейсы. Самоучитель. / Пер. с англ. – М.: ДМК Пресс. 2005. – 425 с.

26.          Конноли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. / Конноли Т., Бегг К.: Пер. с англ. – М.: Изд. Дом «Вильямс», 2001. – 1120 с.

27.          Дейт, К. Дж. Введение в системы баз данных. / К. Дж. Дейт.: Пер. с англ. – М.: Изд. Дом «Вильямс», 2002. – 1072с.

28.          Диго, С.М. Проектирование и использование баз данных. / С.М. Диго. - М.: Финансы и статистика. 1995. – 216с.

29.          Когаловский, М.Р. Энциклопедия технологий баз данных / М.Р. Когаловский. – М.: Финансы и статистика, 2002. – 800с.

30.          Боггс У., Боггс М. UML и Rational Rose. 2002. / Боггс У., Боггс М. – М.: ЛОРИ. - 2002. - 582 с.

31.          Бергер, А. Б. Microsoft SQL Server 2005 Analysis Services. OLAP и многомерный анализ данных / Бергер А. Б., Горбач И. В., Меломед Э. Л. И др. / Под общ. ред. А. Б. Бергера, И. В. Горбач. – СПб.: БХВ-Петербург, 2007. – 928 с.

32.          Каленик, А. И. Использование новых возможностей Microsoft SQL Server 2005. – М.: «Русская редакция»; СПб.: «Питер», 2006. – 334 с.

33.          Буч Г. Объектно-ориентированный анализ и проектирование. / Буч Г.: Пер. с англ. – М: «Издательство Бином», 1999.

34.          Буч Г., Рамбо Д., Джекобсон А. UML – руководство пользователя. / Буч Г., Рамбо Д., Джекобсон А.: Пер с англ. – М: «ДМК», 2001

35.          Страуструп, Б. Язык программирования С++, 3-е изд./Пер. с англ. – М.: «Издательство Бином», СПб: «Невский диалект», 1999. – 991 с.

36.          Секунов, Н. Самоучитель Visual C++ 6. / Н. Секунов. – СПб: БХВ. – 1999. – 960 с.

37.          Шилд Г. Теория и практика С++. – СПб.: BVH-Санкт-Петербург, 1996. – 416 с.

38.          Пол А. Объектно-ориентированное программирование на С++. – СПб.; М.: “Невский Диалект” – “Издательство БИНОМ”, 1999. – 462 с.

39.          Янг М. Microsoft Visual C++ для профессионалов: Пер. с англ. – К.: ВЕК+, М.: ЭНТРОП, 1997. – 704 с.

40.          Трельсен Э. Модель COM и применение ATL 3.0. / Пер. с англ. – СПб: BHV. 2000. – 926 с.

41.          Тамрле, Л. Введение в тестирование программного обеспечения. : Пер. с англ.. – М.: Издательский дом "Вильямс", 2003. – 368 с.

42.          Ван Тассел Д. Стиль, разработка, эффективность, отладка и испытание программ. – М.: Мир. – 1981

43.          Коллинз, Г. Структурные методы разработки систем: от стратегического планирования до тестирования. / Коллинз Г., Блей Дж. Пер. с англ. – М.: Финансы и статистика, 1986. 264 с.

44.          Богдатских, В.А. Экономика, разработка и использование программного обеспечения ЭВМ: Учебник. / В.А. Богдатских. - М.: Финансы и статистика, 1995. – 288 с.

45.          Корнеев, И.К. Информационные технологии в управлении / И.К Корнеев, В.А. Машурцев . – М.:ИНФРА – М, 2001. – 651 с.

46.          Хубаев, Г.Н. Экономическая оценка потребительского качества программных средств: Текст лекций / Г.Н. Хубаев. - РГЭА.: Ростов-на-Дону, 1997. – 94 с.

47.          Хубаев, Г.Н. Маркетинг информационных продуктов и услуг: Учебное пособие / Г.Н. Хубаев. - Ростов-на-Дону: Изд-во РГЭУ «РИНХ», 2005. – 224 с

Приложение А Спецификация требований к программному обеспечению

Введение

Назначение

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

Область действия

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

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

Общее описание

Описание продукта

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

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

-     просмотр результатов анализа;

-     регистрация в журнале;

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

-     расчет формулы.

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

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

Классы и характеристики пользователей

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

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

Общие ограничения

Операционная среда-1. Минимальные требования к операционной системе - Windows ХР.

Ограничения дизайна и реализации-1. База данных должна быть спроектирована на SQL Server 2005.

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

Документация для пользователей

Документация для пользователей-1. Разрабатывается руководство пользователя.

Специфические требования

Функциональные требования

Требование	Описание
1.          Ведение справочников
Изменение справочников
Нормы гематологических анализов	Ввести данные по допустимым нормам компонентов крови .
Типы гематологических анализов	Ввести данные по номенклатуре проводимых лабораторией гематологических анализов для гематологического отдела и клинической экспресс лаборатории
2.          Анализы гематологического отдела
Лейкоформула	Подсчет показателей лейкоцитарной формулы с помощью счетчика
Тромбоциты	Подсчет тромбоцитов с помощью счетчика
Миелограмма	Подсчет показателей миелограммы с помощью счетчика
Гематологические анализы	Ввод данных результатов ручных исследований по гематологии
Отчет о результате исследования	Формирование отчета о результатах гематологических исследований
Фиксация заявки на проведение гематологических анализов	Ввод информации о приеме заявки на выполнение гематологического анализа

Требования к внешнему интерфейсу

Интерфейсы пользователя

Интерфейсы пользователя-1. Экраны вывода должны соответствовать общепринятым стандартам.

Интерфейсы пользователя-2. Система должна обеспечивать ссылку на справку на каждой форме, объясняющую, как пользоваться этой формой.

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

Требования к системе

Требование	Описание
Архитектура	Сервер данных (MS SQL Server 2005)
Среда разработки	Visual Studio 2005
Язык программирования	С++, sql – запросы
Операционная система	Windows XP
Хранилище данных	MS SQL Server 2005

Требования к производительности

Требования к производительности не определены.

Требования к охране труда

Требования к охране труда не определены.

Требования к безопасности

Требования к безопасности не определены.

Атрибуты качества ПО

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

Надежность-1. Система должна восстанавливать незавершенные отчеты в случае сбоя в сети или системе.

Приложение Б – Прототиты пользовательского интерфейса

Рисунок Б.1 – Пиктографическое меню для подсчета лейкоформулы.

Рисунок Б.2 –.

Рисунок Б.3-

Рисунок Б.4-

Рисунок Б.5-

Рисунок Б.6-

Приложение В – Атрибуты управляющих таблиц проектируемой подсистемы ЛИС

Имя поля		Тип		Значение
Атрибуты таблицы «Единицы измерения»
ID		Числовой		Счетчик
Название		Текстовый		Название ед. измерения
Сокращение		Текстовый		Ед. измерения в сокращенном виде
Порядок		Числовой		Порядок
Атрибуты таблицы «Показатели числовые»
ID		Числовой		Счетчик
Название		Текстовый		Название числового показателя
ID_Анализ		Числовой		Идентификатор анализа
ID_Ед_Измерения		Числовой		Идентификатор ед. измерения
Степень		Текстовый		Порядок
Атрибуты таблицы «Лейкоформула»
ID		Числовой		Счетчик
ID_Заявки		Числовой		Идентификатор заявки
ID_Исследования		Числовой		Идентификатор исследования
Палочкоядерные		Числовой		Количество палочкоядерных
Сегментарные		Числовой		Количество сегментарных
Моноциты		Числовой		Количество моноцитов
Лимфоциты		Числовой		Количество лимфоцитов
Миелоциты		Числовой		Количество миелоцитов
Метамелоциты		Числовой		Количество метамелоцитов
Эозинофилы		Числовой		Количество эозинофилов
Базофилы		Числовой		Количество базофилов
Нормобласты		Числовой		Количество нормобластов
Атрибуты таблицы «Тромбоциты»
ID		Числовой		Счетчик
ID_Заявки		Числовой		Идентификатор заявки
ID_Исследования		Числовой		Идентификатор исследования
Тромбоциты/ретикулоциты		Числовой		Количество тромбоцитов
№ прохода		Числовой		Номер прохода
Эритроциты		Числовой		Количество эритроцитов
Атрибуты таблицы «Миелограмма»
ID		Числовой		Счетчик
ID_Заявки		Числовой		Идентификатор заявки
ID_Исследования		Числовой		Идентификатор исследования
Палочкоядерные		Числовой		Количество палочкоядерных
Сегментарные		Числовой		Количество сегментарных
Моноциты		Числовой		Количество моноцитов
Лимфоциты		Числовой		Количество лимфоцитов
Миелоциты		Числовой		Количество миелоцитов
Метамелоциты		Числовой		Количество метамелоцитов
Эозинофилы		Числовой		Количество эозинофилов
Базофилы		Числовой		Количество базофилов
10		Числовой		Параметр крови
11		Числовой		Параметр крови
12		Числовой		Параметр крови
13		Числовой		Параметр крови
14		Числовой		Параметр крови
15		Числовой		Параметр крови
16		Числовой		Параметр крови
17		Числовой		Параметр крови
18		Числовой		Параметр крови
19		Числовой		Параметр крови
20		Числовой		Параметр крови
21	Числовой		Параметр крови
22	Числовой		Параметр крови
23	Числовой		Параметр крови
24	Числовой		Параметр крови

 Приложение Д – Реализация запросов к базе данных

Рисунок Д.1- Реализация запроса «Заявка- анализ»

Рисунок Д.2- Реализация запроса «Отдел-исследование-анализ»

Рисунок Д.3- Реализация запроса «Отдел-анализ»

Приложение Е – Тексты программ

Константы ресурсов

#define IDP_OLE_INIT_FAILED 100

#define IDD_ABOUT 100

#define IDD_FORM 101

#define IDR_MAINFRAME 128

#define IDR_Hematology_CounTYPE 129

#define IDD_FORM_LEIKOFORMULA 132

#define IDD_FORM_TROMBOCITY 133

#define IDD_FORM_MIELOGRAMMA 134

#define IDR_LEIKOFORMULA 136

#define IDR_TROMBOCITY 137

#define IDR_MIELOGRAMMA 138

#define IDR_MIELOGRAMM 138

#define IDC_BUTTON_PERCENT 1004

#define IDC_BUTTON_RESTART 1009

#define IDC_STATIC_PALOCHKOYADERN 1010

#define IDC_STATIC_SEGMEHTARN 1011

#define IDC_STATIC_MONOCIT 1012

#define IDC_STATIC_LIMFOCIT 1013

#define IDC_STATIC_MIELOCIT 1014

#define IDC_STATIC_METAMELOCIT 1015

#define IDC_STATIC_EOZILOFIL 1016

#define IDC_STATIC_BAZOFIL 1017

#define IDC_STATIC_SUM 1018

#define IDC_STATIC_NORMOBLAST 1021

#define IDC_STATIC_9 1022

#define IDC_STATIC_10 1023

#define IDC_STATIC_11 1024

#define IDC_STATIC_12 1025

#define IDC_STATIC_13 1026

#define IDC_STATIC_14 1027

#define IDC_STATIC_15 1028

#define IDC_STATIC_16 1029

#define IDC_STATIC_17 1030

#define IDC_STATIC_18 1031

#define IDC_STATIC_19 1032

#define IDC_STATIC_20 1033

#define IDC_STATIC_21 1034

#define IDC_STATIC_22 1035

#define IDC_STATIC_23 1036

#define IDC_STATIC_24 1037

#define IDC_BUTTON1 1038

#define IDC_EDIT1 1039

#define ID_LEIKOFORMULA_NORMOBLAST 3201

#define ID_LEIKOFORMULA_PALOCHKOYADERN 3202

#define ID_LEIKOFORMULA_SEGMEHTARN 3203

#define ID_LEIKOFORMULA_MONOCIT 3204

#define ID_LEIKOFORMULA_LIMFOCIT 3205

#define ID_LEIKOFORMULA_MIELOCIT 3206

#define ID_LEIKOFORMULA_METAMELOCIT 3207

#define ID_LEIKOFORMULA_EOZILOFIL 3208

#define ID_LEIKOFORMULA_BAZOFIL 3209

#define ID_MIELOGRAMMA_PALOCHKOYADERN 32012

#define ID_MIELOGRAMMA_SEGMEHTARN 32013

#define ID_MIELOGRAMMA_MONOCIT 32014

#define ID_MIELOGRAMMA_LIMFOCIT 32015

#define ID_MIELOGRAMMA_MIELOCIT 32016

#define ID_MIELOGRAMMA_METAMELOCIT 32017

#define ID_MIELOGRAMMA_EOZILOFIL 32018

#define ID_MIELOGRAMMA_BAZOFIL 32019

#define ID_MIELOGRAMMA_9 32020

#define ID_MIELOGRAMMA_10 32021

#define ID_MIELOGRAMMA_11 32022

#define ID_MIELOGRAMMA_12 32023

#define ID_MIELOGRAMMA_13 32024

#define ID_MIELOGRAMMA_14 32025

#define ID_MIELOGRAMMA_15 32026

#define ID_MIELOGRAMMA_16 32027

#define ID_MIELOGRAMMA_17 32028

#define ID_MIELOGRAMMA_18 32029

#define ID_MIELOGRAMMA_19 32030

#define ID_MIELOGRAMMA_20 32031

#define ID_MIELOGRAMMA_21 32032

#define ID_MIELOGRAMMA_22 32033

#define ID_MIELOGRAMMA_23 32034

#define ID_MIELOGRAMMA_24 32035

#define ID_LEIKOFORMULA 32786

#define ID_TROMBOCITY 32787

#define ID_MIELOGRAMMA 32788

#define ID_BUTTON32871 32871

#define ID_PARAMETR 32880

#define ID_PARAMETRES 32881

#define ID_BUTTON32883 32883

#ifdef APSTUDIO_INVOKED

#ifndef APSTUDIO_READONLY_SYMBOLS

#define _APS_NEXT_RESOURCE_VALUE 167

#define _APS_NEXT_COMMAND_VALUE 32884

#define _APS_NEXT_CONTROL_VALUE 1032

#define _APS_NEXT_SYMED_VALUE 101

#endif

#endif

Представление и определение класса CHematology_CounterDoc

#pragma once

#include "Leikoformula.h"

#include "Mielogramma.h"

#include "Trombocity.h"

class CHematology_CounterDoc : public CDocument

{

protected:

CHematology_CounterDoc();

DECLARE_DYNCREATE(CHematology_CounterDoc)

public:

virtual BOOL OnNewDocument();

virtual ~CHematology_CounterDoc();

#ifdef _DEBUG

virtual void AssertValid() const;

virtual void Dump(CDumpContext& dc) const;

#endif

protected:

DECLARE_MESSAGE_MAP()

private:

 CView* Get_View() const;

public:

 afx_msg void UpdateLeikoformula(UINT ID);

afx_msg void UpdateMielogramma(UINT ID);

afx_msg void OnNormoblast();

afx_msg void OnBnClickedButtonRestart();

afx_msg void OnBnClickedButtonPercent();

afx_msg void OnUndo();

afx_msg void OnFileSave();

CList<int*> Undo;

Data* DATA;

};

Реализация класса CHematology_CounterDoc

#include "stdafx.h"

#include "Hematology_Counter.h"

#include "Hematology_CounterDoc.h"

#ifdef _DEBUG

#define new DEBUG_NEW

#endif

IMPLEMENT_DYNCREATE(CHematology_CounterDoc, CDocument)

BEGIN_MESSAGE_MAP(CHematology_CounterDoc, CDocument)

 ON_COMMAND_RANGE(ID_LEIKOFORMULA_PALOCHKOYADERN,ID_LEIKOFORMULA_BAZOFIL,&CHematology_CounterDoc::UpdateLeikoformula)

 ON_COMMAND_RANGE(ID_MIELOGRAMMA_PALOCHKOYADERN,ID_MIELOGRAMMA_24 ,&CHematology_CounterDoc::UpdateMielogramma)

ON_COMMAND(ID_LEIKOFORMULA_NORMOBLAST, &CHematology_CounterDoc::OnNormoblast)

ON_COMMAND(ID_EDIT_UNDO, &CHematology_CounterDoc::OnUndo)

ON_BN_CLICKED(IDC_BUTTON_RESTART, &CHematology_CounterDoc::OnBnClickedButtonRestart)

ON_BN_CLICKED(IDC_BUTTON_PERCENT, &CHematology_CounterDoc::OnBnClickedButtonPercent)

ON_COMMAND(ID_FILE_SAVE, &CHematology_CounterDoc::OnFileSave)

END_MESSAGE_MAP()

CHematology_CounterDoc::CHematology_CounterDoc():DATA(new Leikoformula())

{}

CHematology_CounterDoc::~CHematology_CounterDoc()

{

if(DATA){delete DATA; DATA=0;}

}

BOOL CHematology_CounterDoc::OnNewDocument()

{

if (!CDocument::OnNewDocument())

return FALSE;

 DATA->RemoveAll();

Undo.RemoveAll();

return TRUE;

}

#ifdef _DEBUG

void CHematology_CounterDoc::AssertValid() const

{

CDocument::AssertValid();

}

void CHematology_CounterDoc::Dump(CDumpContext& dc) const

{

CDocument::Dump(dc);

}

#endif

CView* CHematology_CounterDoc::Get_View() const

{

POSITION Position=NULL;

Position=this->GetFirstViewPosition();

return this->GetNextView(Position);

}

void CHematology_CounterDoc::UpdateLeikoformula(UINT ID)

{

 int * pLeikoformula=&((Leikoformula*)DATA)->PALOCHKOYADERN+(ID-ID_LEIKOFORMULA_PALOCHKOYADERN);

 if(DATA->Add(pLeikoformula))

 {

 Undo.AddTail(pLeikoformula);

 Get_View()->UpdateData(0);

 }

}

void CHematology_CounterDoc::UpdateMielogramma(UINT ID)

{

 int * pMielogramma=&((Mielogramma*)DATA)->PALOCHKOYADERN+(ID-ID_MIELOGRAMMA_PALOCHKOYADERN);

 if(DATA->Add(pMielogramma))

 {

 Undo.AddTail(pMielogramma);

 Get_View()->UpdateData(0);

 }

}

void CHematology_CounterDoc::OnNormoblast()

{

 if(100>((Leikoformula*)DATA)->GetSum())

 {

 ((Leikoformula*)DATA)->NORMOBLAST++;

 Undo.AddTail(&((Leikoformula*)DATA)->NORMOBLAST);

 Get_View()->UpdateData(0);

 }

}

void CHematology_CounterDoc::OnBnClickedButtonRestart()

{

DATA->RemoveAll();

Get_View()->UpdateData(0);

Undo.RemoveAll();

}

void CHematology_CounterDoc::OnBnClickedButtonPercent()

{

}

void CHematology_CounterDoc::OnUndo()

{

if(Undo.GetTailPosition())

{

(*(Undo.GetTail()))--;

Undo.RemoveTail();

DATA->Remove();

Get_View()->UpdateData(0);

}

}

void CHematology_CounterDoc::OnFileSave()

{

}

Представление и определение класса CHematology_CounterView

#pragma once

class Form_Leikoformula;

class CHematology_CounterView : public CFormView

{

protected: CHematology_CounterView();

DECLARE_DYNCREATE(CHematology_CounterView)

public:

enum{ IDD = IDD_FORM };

CHematology_CounterDoc* GetDocument() const;

virtual BOOL PreCreateWindow(CREATESTRUCT& cs);

protected:

virtual void DoDataExchange(CDataExchange* pDX);

virtual void OnInitialUpdate();

public:

virtual ~CHematology_CounterView();

#ifdef _DEBUG

virtual void AssertValid() const;

virtual void Dump(CDumpContext& dc) const;

#endif

private:

 CDialog * dForm;

protected:

DECLARE_MESSAGE_MAP()

public:

 void OnDATA(UINT id);

afx_msg void OnDestroy();

afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);

afx_msg void OnLeikoformula();

afx_msg void OnTrombocity();

afx_msg void OnMielogramma();

 void CreateMenuParametre(UINT ID);

};

#ifndef _DEBUG

inline CHematology_CounterDoc* CHematology_CounterView::GetDocument() const

 { return reinterpret_cast<CHematology_CounterDoc*>(m_pDocument); }

#endif

Реализация класса CHematology_CounterView

#include "stdafx.h"

#include "Hematology_Counter.h"

#include "Hematology_CounterDoc.h"

#include "Hematology_CounterView.h"

#include "Form.h"

#include "MainFrm.h"

#ifdef _DEBUG

#define new DEBUG_NEW

#endif

IMPLEMENT_DYNCREATE(CHematology_CounterView, CFormView)

BEGIN_MESSAGE_MAP(CHematology_CounterView, CFormView)

ON_WM_DESTROY()

ON_WM_CREATE()

ON_COMMAND_RANGE(ID_LEIKOFORMULA,ID_MIELOGRAMMA,&CHematology_CounterView::OnDATA)

END_MESSAGE_MAP()

CHematology_CounterView::CHematology_CounterView()

: CFormView(CHematology_CounterView::IDD),dForm(NULL)

{

}

CHematology_CounterView::~CHematology_CounterView()

{

 if(dForm){delete dForm;dForm=NULL;}

}

void CHematology_CounterView::DoDataExchange(CDataExchange* pDX)

{

CFormView::DoDataExchange(pDX);

 if(dForm)dForm->UpdateData(0);

}

BOOL CHematology_CounterView::PreCreateWindow(CREATESTRUCT& cs)

{

return CFormView::PreCreateWindow(cs);

}

void CHematology_CounterView::OnInitialUpdate()

{

CFormView::OnInitialUpdate();

GetParentFrame()->RecalcLayout();

ResizeParentToFit();

CHematology_CounterDoc* Doc=GetDocument();

 if(!Leikoformula::Create(&dForm,&Doc->DATA))return;

dForm->Create(IDD_FORM_LEIKOFORMULA,this);

CreateMenuParametre(IDR_LEIKOFORMULA);

}

#ifdef _DEBUG

void CHematology_CounterView::AssertValid() const

{

CFormView::AssertValid();

}

void CHematology_CounterView::Dump(CDumpContext& dc) const

{

CFormView::Dump(dc);

}

CHematology_CounterDoc* CHematology_CounterView::GetDocument() const

{

ASSERT(m_pDocument->IsKindOf(RUNTIME_CLASS(CHematology_CounterDoc)));

return (CHematology_CounterDoc*)m_pDocument;

}

#endif

void CHematology_CounterView::OnDestroy()

{

dForm->DestroyWindow();

if(dForm){delete dForm;dForm=NULL;}

CFormView::OnDestroy();

}

int CHematology_CounterView::OnCreate(LPCREATESTRUCT lpCreateStruct)

{

if (CFormView::OnCreate(lpCreateStruct) == -1)return -1;

return 0;

}

void CHematology_CounterView::OnDATA(UINT id)

{

CHematology_CounterDoc* Doc=GetDocument();

switch(id)

{

case ID_LEIKOFORMULA:

{

if(!Leikoformula::Create(&dForm,&Doc->DATA))return;

}

break;

case ID_TROMBOCITY:

{

 if(!Trombocity::Create(&dForm,&Doc->DATA))return;

 break;

}

case ID_MIELOGRAMMA:

 if(!Mielogramma::Create(&dForm,&Doc->DATA))return;

 break;

}

CreateMenuParametre(IDR_LEIKOFORMULA+id-ID_LEIKOFORMULA);

dForm->Create(IDD_FORM_LEIKOFORMULA+id-ID_LEIKOFORMULA,this);

Doc->Undo.RemoveAll();

}

void CHematology_CounterView::CreateMenuParametre(UINT ID)

{

CMenu** parametres=&(((CMainFrame*)AfxGetMainWnd())->ParametresMenu);

if((*parametres)){(*parametres)->DestroyMenu();delete (*parametres);}

(*parametres)=new CMenu;

 (*parametres)->LoadMenuW(ID);

 AfxGetMainWnd()->GetMenu()->ModifyMenuW(2,MF_BYPOSITION| MF_POPUP ,(UINT_PTR)((*parametres)->m_hMenu),L"Параметры");

 DestroyAcceleratorTable(((CMainFrame*)AfxGetMainWnd())->m_hAccelTable);

 ((CMainFrame*)AfxGetMainWnd())->m_hAccelTable=LoadAccelerators(AfxGetApp()->m_hInstance,MAKEINTRESOURCEW(ID));

 AfxGetMainWnd()->GetMenu()->CheckMenuRadioItem(ID_LEIKOFORMULA,ID_MIELOGRAMMA,ID_LEIKOFORMULA+ID-IDR_LEIKOFORMULA,MF_BYCOMMAND);

 ((CMainFrame*)AfxGetMainWnd())->ParametresToolBar.LoadToolBar(ID);

}

Представление и определение класса Data

 #pragma once

class Data

{

protected:

 Data();

public:

 virtual ~Data();

 virtual void RemoveAll()=0;

 virtual bool Add(int*)=0;

 virtual void Remove()=0;

};

Реализация класса Data

#include "StdAfx.h"

#include "Data.h"

Data::Data(){}

Data::~Data(){}

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

#pragma once

#include "Data.h"

class CDialog;

class Leikoformula: public Data

{

private:

int Sum;

public:

Leikoformula();

int & GetSum();

 static bool Create(CDialog ** dForm,Data** pData);

virtual void RemoveAll();

virtual bool Add(int * pLeikoformula);

 virtual void Remove();

int NORMOBLAST;

int PALOCHKOYADERN;

 int SEGMEHTARN;

 int MONOCIT;

 int LIMFOCIT;

 int MIELOCIT;

 int METAMELOCIT;

 int EOZILOFIL;

 int BAZOFIL;

};

Реализация класса Leikoformula

#include "StdAfx.h"

#include "Leikoformula.h"

#include "Form.h"

Leikoformula::Leikoformula():Data(),PALOCHKOYADERN(0),SEGMEHTARN(0),MONOCIT(0),LIMFOCIT(0),MIELOCIT(0),METAMELOCIT(0),EOZILOFIL(0),BAZOFIL(0),NORMOBLAST(0),Sum(0)

{

}

int & Leikoformula::GetSum()

{

return Sum;

}

void Leikoformula::RemoveAll()

{

PALOCHKOYADERN=SEGMEHTARN=MONOCIT=LIMFOCIT=MIELOCIT=METAMELOCIT=EOZILOFIL=BAZOFIL=NORMOBLAST=Sum=0;

}

bool Leikoformula::Add(int * pLeikoformula)

{

if(100<=Sum)return false;

Sum++;

(*pLeikoformula)++;

return true;

}

void Leikoformula::Remove()

{

if(0<Sum)Sum--;

}

bool Leikoformula::Create(CDialog ** dForm,Data** pData)

{

 

 if((*dForm)&&(*dForm)->IsKindOf(RUNTIME_CLASS(Form_Leikoformula)))return false;

 if((*dForm)){(*dForm)->DestroyWindow();delete (*dForm);(*dForm)=0;}

 (*dForm)=new Form_Leikoformula();

 if((*pData)){delete (*pData);(*pData)=0;}

 (*pData)=new Leikoformula;

 ((Form_Leikoformula*)*dForm)->pData=(*pData);

 return true;

}

Реализация класса Mielogramma

#include "StdAfx.h"

#include "Mielogramma.h"

#include "Form.h"

Mielogramma::Mielogramma():Data(),PALOCHKOYADERN(0),SEGMEHTARN(0),MONOCIT(0),LIMFOCIT(0),MIELOCIT(0),METAMELOCIT(0),EOZILOFIL(0),BAZOFIL(0)

,_9(0)

,_10(0)

,_11(0)

,_12(0)

,_13(0)

,_14(0)

,_15(0)

,_16(0)

,_17(0)

,_18(0)

,_19(0)

,_20(0)

,_21(0)

,_22(0)

,_23(0)

,_24(0)

{

}

Mielogramma::~Mielogramma(){}

bool Mielogramma::Create(CDialog ** dForm,Data** pData)

{

 if((*dForm)&&(*dForm)->IsKindOf(RUNTIME_CLASS(Form_Mielogramma)))return false;

 (*dForm)->DestroyWindow();

 if((*dForm)){delete (*dForm);(*dForm)=0;}

 (*dForm)=new Form_Mielogramma();

 if((*pData)){delete (*pData);(*pData)=0;}

 (*pData)=new Mielogramma;

 ((Form_Mielogramma*)*dForm)->pData=(*pData);

 return true;

}

void Mielogramma::RemoveAll()

{

PALOCHKOYADERN=SEGMEHTARN=MONOCIT=LIMFOCIT=MIELOCIT=METAMELOCIT=EOZILOFIL=BAZOFIL=_9=_10=_11=_12=_13=_14=_15=_16=_17=_18=_19=_20=_21=_22=_23=_24=0;

}

bool Mielogramma::Add(int * pMielogramma)

{

(*pMielogramma)++;

return true;

}

void Mielogramma::Remove(){}

Представление и определение класса Trombocity

#pragma once

#include "Data.h"

class Data;

class CDialog;

class Trombocity: public Data

{

public:

Trombocity();

~Trombocity();

static bool Create(CDialog ** dForm,Data** pData);

virtual void RemoveAll();

 virtual bool Add(int * pTrombocity);

 virtual void Remove();

};

Реализация класса Trombocity

#include "StdAfx.h"

#include "Trombocity.h"

#include "Form.h"

Trombocity::Trombocity():Data(){}

Trombocity::~Trombocity(){}

bool Trombocity::Create(CDialog ** dForm,Data** pData)

{

 if((*dForm)&&(*dForm)->IsKindOf(RUNTIME_CLASS(Form_Trombocity)))return false;

 (*dForm)->DestroyWindow();

 if((*dForm)){delete (*dForm);(*dForm)=0;}

 (*dForm)=new Form_Trombocity();

 if((*pData)){delete (*pData);(*pData)=0;}

 (*pData)=new Trombocity;

 ((Form_Trombocity*)*dForm)->pData=(*pData);

 return true;

}

void Trombocity::RemoveAll(){}

bool Trombocity::Add(int * pTrombocity){return 1;}

void Trombocity::Remove(){}

Представление и определение классов: Form_Leikoformula, Form_Mielogramma, Form_Trombocity.

#pragma once

#include "resource.h"

class Data;

class Form_Leikoformula : public CDialog

{

DECLARE_DYNAMIC(Form_Leikoformula)

public:

Form_Leikoformula(CWnd* pParent = NULL); // standard constructor

virtual ~Form_Leikoformula();

enum { IDD = IDD_FORM_LEIKOFORMULA };

protected:

virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support

DECLARE_MESSAGE_MAP()

public:

Data * pData;

};

class Form_Mielogramma : public CDialog

{

DECLARE_DYNAMIC(Form_Mielogramma)

public:

Form_Mielogramma(CWnd* pParent = NULL); // standard constructor

virtual ~Form_Mielogramma();

enum { IDD = IDD_FORM_MIELOGRAMMA };

protected:

virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support

DECLARE_MESSAGE_MAP()

public:

 Data * pData;

};

class Form_Trombocity : public CDialog

{

DECLARE_DYNAMIC(Form_Trombocity)

public:

Form_Trombocity(CWnd* pParent = NULL); // standard constructor

virtual ~Form_Trombocity();

enum { IDD = IDD_FORM_TROMBOCITY };

protected:

virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support

DECLARE_MESSAGE_MAP()

public:

 Data * pData;

};

Реализация классов: Form_Leikoformula, Form_Mielogramma, Form_Trombocity.

#include "stdafx.h"

#include "Hematology_Counter.h"

#include "Form.h"

#include "Leikoformula.h"

IMPLEMENT_DYNAMIC(Form_Leikoformula, CDialog)

Form_Leikoformula::Form_Leikoformula(CWnd* pParent /*=NULL*/)

: CDialog(Form_Leikoformula::IDD, pParent),pData(NULL)

{

}

Form_Leikoformula::~Form_Leikoformula()

{

}

void Form_Leikoformula::DoDataExchange(CDataExchange* pDX)

{

CDialog::DoDataExchange(pDX);

if(!pData)return;

Leikoformula* LEIKOFORMULA=(Leikoformula*)pData;

 DDX_Text(pDX, IDC_STATIC_PALOCHKOYADERN,LEIKOFORMULA->PALOCHKOYADERN);

 DDX_Text(pDX, IDC_STATIC_SEGMEHTARN,LEIKOFORMULA->SEGMEHTARN);

DDX_Text(pDX, IDC_STATIC_MONOCIT, LEIKOFORMULA->MONOCIT);

DDX_Text(pDX, IDC_STATIC_LIMFOCIT, LEIKOFORMULA->LIMFOCIT);

DDX_Text(pDX, IDC_STATIC_MIELOCIT,LEIKOFORMULA->MIELOCIT);

DDX_Text(pDX, IDC_STATIC_METAMELOCIT, LEIKOFORMULA->METAMELOCIT);

DDX_Text(pDX, IDC_STATIC_EOZILOFIL,LEIKOFORMULA->EOZILOFIL);

DDX_Text(pDX, IDC_STATIC_BAZOFIL, LEIKOFORMULA->BAZOFIL);

DDX_Text(pDX, IDC_STATIC_NORMOBLAST,LEIKOFORMULA->NORMOBLAST);

DDX_Text(pDX, IDC_STATIC_SUM, LEIKOFORMULA->GetSum());

}

BEGIN_MESSAGE_MAP(Form_Leikoformula, CDialog)

END_MESSAGE_MAP()

#include "Mielogramma.h"

IMPLEMENT_DYNAMIC(Form_Mielogramma, CDialog)

Form_Mielogramma::Form_Mielogramma(CWnd* pParent /*=NULL*/)

: CDialog(Form_Mielogramma::IDD, pParent),pData(NULL)

{

}

Form_Mielogramma::~Form_Mielogramma()

{

}

void Form_Mielogramma::DoDataExchange(CDataExchange* pDX)

{

CDialog::DoDataExchange(pDX);

if(!pData)return;

Mielogramma* MIELOGRAMMA=(Mielogramma*)pData;

DDX_Text(pDX, IDC_STATIC_PALOCHKOYADERN,MIELOGRAMMA->PALOCHKOYADERN);

DDX_Text(pDX, IDC_STATIC_SEGMEHTARN,MIELOGRAMMA->SEGMEHTARN);

DDX_Text(pDX, IDC_STATIC_MONOCIT, MIELOGRAMMA->MONOCIT);

DDX_Text(pDX, IDC_STATIC_LIMFOCIT, MIELOGRAMMA->LIMFOCIT);

DDX_Text(pDX, IDC_STATIC_MIELOCIT,MIELOGRAMMA->MIELOCIT);

DDX_Text(pDX, IDC_STATIC_METAMELOCIT, MIELOGRAMMA->METAMELOCIT);

DDX_Text(pDX, IDC_STATIC_EOZILOFIL,MIELOGRAMMA->EOZILOFIL);

DDX_Text(pDX, IDC_STATIC_BAZOFIL, MIELOGRAMMA->BAZOFIL);

DDX_Text(pDX, IDC_STATIC_9,MIELOGRAMMA->_9);

 DDX_Text(pDX, IDC_STATIC_10,MIELOGRAMMA->_10);

DDX_Text(pDX, IDC_STATIC_11, MIELOGRAMMA->_11);

DDX_Text(pDX, IDC_STATIC_12, MIELOGRAMMA->_12);

DDX_Text(pDX, IDC_STATIC_13,MIELOGRAMMA->_13);

DDX_Text(pDX, IDC_STATIC_14, MIELOGRAMMA->_14);

DDX_Text(pDX, IDC_STATIC_15,MIELOGRAMMA->_15);

DDX_Text(pDX, IDC_STATIC_16,MIELOGRAMMA->_16);

 DDX_Text(pDX, IDC_STATIC_17,MIELOGRAMMA->_17);

DDX_Text(pDX, IDC_STATIC_18, MIELOGRAMMA->_18);

 DDX_Text(pDX, IDC_STATIC_19, MIELOGRAMMA->_19);

DDX_Text(pDX, IDC_STATIC_20,MIELOGRAMMA->_20);

DDX_Text(pDX, IDC_STATIC_21, MIELOGRAMMA->_21);

DDX_Text(pDX, IDC_STATIC_22,MIELOGRAMMA->_22);

DDX_Text(pDX, IDC_STATIC_23,MIELOGRAMMA->_23);

 DDX_Text(pDX, IDC_STATIC_24,MIELOGRAMMA->_24);

}

BEGIN_MESSAGE_MAP(Form_Mielogramma, CDialog)

END_MESSAGE_MAP()

#include "Trombocity.h"

IMPLEMENT_DYNAMIC(Form_Trombocity, CDialog)

Form_Trombocity::Form_Trombocity(CWnd* pParent /*=NULL*/)

: CDialog(Form_Trombocity::IDD, pParent),pData(NULL)

{

}

Form_Trombocity::~Form_Trombocity()

{

}

void Form_Trombocity::DoDataExchange(CDataExchange* pDX)

{

CDialog::DoDataExchange(pDX);

if(!pData)return;

}

BEGIN_MESSAGE_MAP(Form_Trombocity, CDialog)

END_MESSAGE_MAP()

Приложение Ж – ОБОСНОВАНИЕ МОДЕЛИ ВЫБОРА ЖИЗНЕННОГО ЦИКЛА

Таблица Е.1 - Выбор модели ЖЦ на основе характеристик требований

Требования	Каскадная	V-образная	Прото-типиро-вание	Спиральная	RAD	Инкрементная
Являются ли требования легко определимыми и/или хорошо известными	Да	Да	Нет	Нет	Да	Нет
Могут ли требования заранее определятся в цикле	Да	Да	Нет	Нет	Да	Да
Часто ли изменяются требования в цикле	Нет	Нет	Да	Да	Нет	Нет
Нужно ли демонстрировать требования с целью определения	Нет	Нет	Да	Да	Да	Нет
Требуется ли демонстрация возможностей проверка концепции	Нет	Нет	Да	Да	Да	Нет
Будут ли требования отражать сложность системы	Нет	Нет	Да	Да	Нет	Да
Обладает ли требование функциональными свойствами на раннем этапе	Нет	Нет	Да	Да	Да	Да

Таблица Е.2 - Выбор модели ЖЦ на основе характеристик участников команды разработчиков

Команда разработчиков проекта	Каскадная	V- образная	Прото-типиро-вание	Спиральная	RAD	Инкрементная
Являются ли проблемы предметной области проекта новыми для большинства разработчиков	Нет	Нет	Да	Да	Нет	Нет
Является ли технология предметной области проекта новой для большинства разработчиков	Да	Да	Нет	Да	Да	Да
Являются ли инструменты, используемые проектом, новыми для большинства разработчиков	Да	Да	Нет	Да	Да	Нет
Изменяются ли роли участников проекта во время ЖЦ	Нет	Нет	Да	Да	Нет	Да
Могут ли разработчики проекта пройти обучение	Нет	Да	Нет	Нет	Да	Да
Является ли структура более значимой для разработчиков, чем гибкость	Да	Да	Нет	Нет	Да	Да
Будет ли менеджер проекта строго отслеживать прогресс проекта	Да	Да	Нет	Да	Нет	Да
Важна легкость распределения ресурсов	Да	Да	Нет	Нет	Да	Да
Приемлет ли команда равноправные обзоры инспекций, менеджмент/обзоры заказчиков, а так же стадии	Да	Да	Да	Да	Да	Да

Таблица В.З - Выбор модели ЖЦ на основе характеристик типа проектов и рисков

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

Таблица В.4 - Выбор модели ЖЦ на основе характеристик пользователей

Коллектив пользователей	Каскадная	V- образная	Прото-типиро-вание	Спиральная	RAD	Инкрементная
Будет ли присутствие пользователей ограниченно в ЖЦ	Да	Да	Нет	Да	Да	Да
Будут ли пользователи знакомы с определением системы	Нет	Нет	Да	Да	Да	Да
Будут ли пользователи ознакомлены с проблемами предметной области	Нет	Нет	Да	Нет	Да	Да
Будут ли пользователи вовлечены во все фазы ЖЦ	Нет	Нет	Да	Нет	Да	Нет
Будет ли заказчик отслеживать ход выполнения проекта	Нет	Нет	Да	Да	Нет	Нет