Разработка подсистемы как набора 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.