Разработка подсистемы учета гематологических анализов для КДЛ ГБСМП-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-средства Erwin4.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 Server2005, 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- Представление класса Mielogramma3.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 Studio2005, удобство этого средства тестирования заключается в возможности егоиспользования в режиме отладки приложения под управлением встроенного отладчика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(gi) – степень достижения цели, баллы;
/> –значение показателя, баллы;
K – количество показателей.
Весовой коэффициент вычисляется по формуле:
/>,                                 (4.2)
где    />– весовой коэффициент, баллы;
Vi – оценка, баллы.
Расчет оценки ведется по формуле:
/>,                                 (4.3)
где Vi – оценка, баллы;
Rmin – минимальное значениеранга, баллы;
Ri – сумма рангов, баллы.
Для расчета суммы рангов воспользуемсяформулой:
/>,                                   (4.4)
где Ri – сумма рангов,баллы;
ri – значение, выставленноеэкспертом, баллы;
n – количество экспертов.
При этом проверяется согласованность мнений экспертов путем расчетазначения известного коэффициента q Кендала (конкордации), для оценок данныхэкспертами.
Общий показатель эффективности рассчитывается как:
/>,                       (4.5)
где    Em – показатель эффективности, баллы;
wi – весовой коэффициент,баллы;
u(gi) – степень достиженияцели, баллы.
Теперь, рассмотрев общие положения методики оценки информационнойсистемы перейдем к расчету конкретного показателя эффективности работы ИС.
Для начала, определим цели и показатели работы системы, а так жеукажем уровень достижения показателей при создании прототипа. После чегорассчитаем степень достижения целей.
Все это сведем в таблицу (таблица 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 Server2005. Проведено тестирование программного кода с использованием стандартныхсредств предоставляемых 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.  Лабораторные информационные системы – цели установки, основные функции,проблемы выбора и внедрения. [Электронный документ] laboratory.rusmedserv.com/laborauto/Проверен 20.05.08.
/>2.  Лабораторные информационные системы на отечественном рынке. [Электронныйдокумент] www.asutp.ru/?p=600629 Проверен 20.05.08.
3.   Нуцков,Ю.В., Хиллхауз Б. Интеграция LabWare LIMS и SAP R/3 QM // Мир компьютернойавтоматизации. 2003. 4. С. 56-63
4.   LabWare LIMS.[Электронный документ] 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.   ЛИСХимик-аналитик/Краткая информация. [Электронный документ] www.chemsoft.ru/index.php?razdel=products&info=small&text1=2&text2=1&tema=c_2Проверен 20.05.08.
9.   Лабораторныеинформационные системы. [Электронный документ] www.intralab.ruПроверен 20.05.08.
10.         Точность (правильность и прецизионность) методов и результатовизмерений. Государственный стандарт Российской Федерации. [Электронныйдокумент] 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 isModel-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 [Электронный документ] – www.pda-digipoint.ru/index.php?productID=91 – 2007. – Проверен9.05.08.
23.         SQL Server General Technical Articles. TheMicrosoft Data Warehousing Strategy. A Platform for Improved Decision-Makingthrough 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 Server2005)
Среда разработки
Visual Studio 2005
Язык программирования
С++, sql– запросы
Операционная система
 WindowsXP
Хранилище данных
MS SQL Server2005
Требования к производительности
Требования к производительности не определены.
Требования к охране труда
Требования к охране труда не определены.
Требования к безопасности
Требования к безопасности не определены.
Атрибуты качества ПО
Доступность-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 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(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
 #pragmaonce
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++;
(*pLeikoformula)++;
return true;
}
void Leikoformula::Remove()
{
if(0
}
bool Leikoformula::Create(CDialog ** dForm,Data** pData)
{
 
 if((*dForm)&&(*dForm)->IsKindOf(RUNTIME_CLASS(Form_Leikoformula)))returnfalse;
 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)))returnfalse;
 (*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
#pragmaonce
#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)))returnfalse;
 (*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/DDVsupport
         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/DDVsupport
         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/DDVsupport
         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 Инкрементная Будет ли присутствие пользователей ограниченно в ЖЦ Да Да Нет Да Да Да Будут ли пользователи знакомы с определением системы Нет Нет Да Да Да Да Будут ли пользователи ознакомлены с проблемами предметной области Нет Нет Да Нет Да Да Будут ли пользователи вовлечены во все фазы ЖЦ Нет Нет Да Нет Да Нет Будет ли заказчик отслеживать ход выполнения проекта Нет Нет Да Да Нет Нет