22
передается в последующую работу. Это может послужить причиной срыва
графика и усложнения взаимоотношений между группами разработчиков,
выполняющих отдельные этапы.
Самый плохой вариант, когда недоработки предыдущего этапа
обнаруживаются не на следующем этапе, а позднее. Например, на стадии
опытной эксплуатации могут проявиться ошибки в описании предметной
области. Это означает, что часть проекта должна быть возвращена на
начальный этап работы.
Сложность параллельного ведения работ связана с необходимостью
согласования различных частей проекта, чем сильнее взаимосвязь отдельных
частей проекта, тем чаще и тщательнее должна выполняться синхронизация,
тем сильнее зависят друг от друга группы разработчиков. В результате
преимущества параллельного проведения работ просто теряются; отсутствие
параллелизма негативно сказывается и на организации работы всего
коллектива.
Проблема информационной перенасыщенности возникает вследствие
сильной зависимости между различными группами разработчиков. Дело в
том, что при внесении изменений в одну из частей проекта, необходимо
оповещать тех разработчиков, которые использовали (могли использовать) ее
в своей работе. При наличии большого числа взаимосвязанных подсистем
синхронизация внутренней документации становится отдельной важнейшей
задачей: разработчики должны постоянно знакомятся с изменениями и
оценивать, как скажутся эти изменения на полученных результатах.
Сложность управления проектом в основном обусловлена строгой
последовательностью стадий разработки и наличием сложных взаимосвязей
между различными частями проекта. Регламентированная
последовательность работ приводит к тому, что одни группы разработчиков
должны ожидать результатов работы других команд, поэтому требуется
административное вмешательство для согласования сроков и состава
передаваемой документации.
23
В случае же обнаружения ошибок в работе необходим возврат к
предыдущим этапам; текущая работа тех, кто ошибся, прерывается.
Следствием этого обычно является срыв сроков выполнения как
исправляемого, так и нового проектов.
Упростить взаимодействие между разработчиками и уменьшить
информационную перенасыщенность документации можно, сокращая
количество связей между отдельными частями проекта, но далеко не каждую
АИС можно разделить на слабо связанные подсистемы.
Высокий уровень риска. Чем сложнее проект, тем дольше длится
каждый этап разработки и тем сложнее взаимосвязи между отдельными
частями проекта, количество которых также увеличивается. Причем
результаты разработки можно реально увидеть и оценить лишь на этапе
тестирования, т. е. после завершения анализа, проектирования и разработки –
этапов, выполнение которых требует значительного времени и средств.
Запоздалая оценка порождает серьезные проблемы при выявлении
ошибок анализа и проектирования – требуется возврат на предыдущие
стадии и повторение процесса разработки. Однако возврат на предыдущие
стадии может быть связан не только с ошибками, но и с изменениями,
произошедшими в предметной области или в требованиях заказчика за время
разработки. При этом никто не гарантирует, что предметная область снова не
изменится к тому моменту, когда будет готова следующая версия проекта.
Фактически это означает, что существует вероятность «зацикливания»
процесса разработки: расходы на проект будут постоянно расти, а сроки
сдачи готового продукта постоянно откладываться.
Следующая модель жизненного цикла АИС – итерационная модель,
или как её еще иногда называют – поэтапная модель с промежуточным
контролем. Основная идея данного подхода заключается в серии коротких
циклов (шагов) по планированию, реализации, изучению, действию.
Создание сложных АИС предполагает проведение согласований
проектных решений, полученных при реализации отдельных задач. Подход к
24
проектированию «снизу–вверх» обусловливает необходимость таких
итераций возвратов, когда проектные решения по отдельным задачам
объединяются в общие системные. При этом возникает потребность в
пересмотре ранее сформировавшихся требований.
Преимущество итерационной модели заключается в том, что
межэтапные корректировки обеспечивают меньшую трудоемкость
разработки по сравнению с каскадной моделью.
Недостатки итерационной модели:
время жизни каждого этапа растягивается на весь период работки;
вследствие большого числа итераций возникают рассогласования
выполнения проектных решений и документации;
запутанность архитектуры;
трудности использования проектной документации на стадиях
внедрения и эксплуатации вызывают необходимость перепроектирования
всей системы.
Третий подход к организации жизненного цикла АИС – спиральная
модель, которая, в отличие от каскадной, но аналогично итерационной
предполагает итерационный процесс разработки АИС. При этом возрастает
значение начальных этапов, таких как анализ и проектирование, на которых
проверяется и обосновывается реализуемость технических решений путем
создания прототипов.
Каждая итерация представляет собой законченный цикл разработки,
приводящий к выпуску внутренней или внешней версии изделия (или
подмножества конечного продукта), которое совершенствуется от итерации к
итерации, чтобы стать законченной системой (Рисунок 5).
25
Рисунок 5 – Спиральная модель жизненного цикла АИС
Таким образом, каждый виток спирали соответствует созданию
фрагмента или версии программного изделия, на нем уточняются цели и
характеристики проекта, определяется его качество, планируются работы на
следующем витке спирали [35]. Каждая итерация служит для углубления и
последовательной конкретизации деталей проекта, в результате этого
выбирается обоснованный вариант окончательной реализации.
Использование спиральной модели позволяет осуществлять переход на
следующий этап выполнения проекта, не дожидаясь полного завершения
текущего, — недоделанную работу можно будет выполнить на следующей
итерации. Главная задача каждой итерации — как можно быстрее создать
работоспособный продукт для демонстрации пользователям. Таким образом,
существенно упрощается процесс внесения уточнений и дополнений проект.
Спиральный подход к разработке программного обеспечения позволяет
преодолеть большинство недостатков каскадной модели, кроме того,
обеспечивает ряд дополнительных возможностей, делая процесс разработки
более гибким.
Преимущества спирального подхода [35]:
итерационная разработка существенно упрощает внесение
изменений в проект при изменении требований заказчика;
26
при использовании спиральной модели отдельные элементы АИС
интегрируются в единое целое постепенно. Поскольку интеграция
начинается с меньшего количества элементов, то возникает гораздо меньше
проблем при ее проведении;
снижение уровня рисков (следствие предыдущего преимущества,
так как риски обнаруживаются именно во время интеграции). Уровень
рисков максимален в начале разработки проекта, по мере продвижения
разработки он снижается;
итерационная разработка обеспечивает большую гибкость в
управлении проектом, давая возможность внесения тактических изменений в
разрабатываемое изделие. Так, можно сократить сроки разработки за счет
снижения функциональности системы или использовать в качестве
составных частей продукцию сторонних фирм вместо собственных
разработок (актуально при рыночной экономике, когда необходимо
противостоять продвижению изделия конкурентов);
итерационный подход упрощает повторное использование
компонентов, поскольку гораздо проще выявить (идентифицировать) общие
части проекта, когда они уже частично разработаны, чем пытаться выделить
их в самом начале проекта. Анализ проекта после нескольких начальных
итераций позволяет выявить общие многократно используемые компоненты,
которые на последующих итерациях будут совершенствоваться;
спиральная модель позволяет получить более надежную и
устойчивую систему. Это связано с тем, что по мере развития системы
ошибки и слабые места обнаруживаются и исправляются на каждой
итерации. Одновременно корректируются критические параметры
эффективности, что в случае каскадной модели доступно только перед
внедрением системы;
итерационный подход позволяет совершенствовать процесс
разработки – в результате анализа в конце каждой итерации проводится
27
оценка изменений в организации разработки; на следующей итерации она
улучшается.
Основная проблема спирального цикла – трудность определения
момента перехода на следующий этап [28]. Для ее решения необходимо
ввести временные ограничения на каждый из этапов жизненного цикла.
Иначе процесс разработки может превратиться в бесконечное
совершенствование уже сделанного.
Выводы по главе
В первой главе были рассмотрены теоретические основы создания и
использования автоматизированных информационных систем. Были
выделены цели и задачи, для которых создаются АИС и применяются в
различных сферах деятельности человека. Затем рассмотрен внутренний
состав АИС, их структура в общем виде, были выделены функциональный
блок и обеспечивающие подсистемы, каждая из которых также была
подробно рассмотрена.
Завершающим этапом теоретического исследования АИС стало
изучение моделей жизненного цикла АИС. Были рассмотрены наиболее
популярные подходы: каскадный, итерационный и спиральный. Для каждого
из них были выделены достоинства и недостатки.
28
ГЛАВА 2. ПРОЕКТИРОВАНИЕ АИС «РЕГИСТР
МЕДИЦИНСКИХ СПРАВОК» В ГБУЗ «СОКПТД имени. Н.В.
Постникова»
2.1. Постановка задачи
2.1.1 Назначение системы
Автоматизированная информационная система «Регистр медицинских
справок» (АИС «РМС») предназначена для автоматизации процессов
прохождения медицинского освидетельствования гражданами Российской
Федерации, иностранными гражданами или лицами без гражданства в
медицинских организациях Самарской области, в том числе в
государственном бюджетном учреждении здравоохранения «Самарский
областной клинический противотуберкулезный диспансер имени Н.В.
Постникова» (ГБУЗ «СОКПТД»).
Основные задачи, для решения которых создается АИС «РМС»:
электронное подтверждение подлинности документа,
удостоверяющего факт прохождения медицинского освидетельствования
гражданином Российской Федерации, иностранным гражданином или лицом
без гражданства и проведения проверки достоверности представленных в
нем сведений;
контроль использования бланков строгой отчетности в
медицинских организациях (медицинская справка о допуске к управлению
транспортными средствами, сертификат об отсутствии ВИЧ-инфекции,
врачебное свидетельство о состоянии здоровья иностранного гражданина,
лица без гражданства, членов его семьи);
организация межведомственного электронного взаимодействия
между министерством здравоохранения Самарской области и Управлением
ГИБДД, Главного управления Министерства внутренних дел Российской
Федерации по Самарской области, между министерством и УФМС
Российской Федерации по Самарской области.
29
АИС «РМС» обеспечивает автоматизацию работы с медицинскими
справками граждан РФ и иностранных граждан в следующих организациях
Самарской области:
Министерство здравоохранения Самарской области (далее – МЗ
СО);
ГБУЗ Самарский областной медицинский информационно-
аналитический центр (далее – МИАЦ);
Медицинские организации Самарской области (далее – МО),
прошедшие регистрацию в МИАЦ и имеющие на момент регистрации
обращения гражданина актуальную запись в справочнике «Справочник
организаций сферы здравоохранения Самарской области»;
Управление государственной инспекции безопасности дорожного
движения Министерства внутренних дел Российской Федерации (далее –
ГИБДД);
Органы управления Федеральной миграционной службы
Российской Федерации по Самарской области (далее – УФМС).
2.1.2 Функции системы
Выделение адресного пространства номеров бланков строгой
отчетности для ЛПУ.
Формирование и ведение электронной карты гражданина,
обратившегося в ЛПУ за справкой.
Регистрация медицинского бланка строгой отчетности.
Проведение осмотра гражданина соответствующими профильными
специалистами ЛПУ в зависимости от типа освидетельствования.
Подтверждение результатов медицинского освидетельствования
гражданина пользователем с ролью «Председатель комиссии».
Выдача справки гражданину с соответствующим заключением («годен»
/ «не годен»).
30
Проверка результата прохождения медицинского осмотра кандидата на
выдачу водительских прав или мигранта, формирование и обработка
экстренных сообщений.
Формирование решения о подтверждении / об отказе в УФМС о факте
выдачи акта медицинского освидетельствования.
Формирование ежемесячной информации о количестве пациентов,
прошедших медицинское освидетельствование, и его результатах.
Печать гражданину направления на осмотр.
Выгрузка данных о прохождении пациентами медицинского
освидетельствования, медицинских заключений о состоянии их здоровья в
Единую информационную систему ГИБДД, УФМС.
Поиск информации по пациенту: фамилия, имя, отчество, серия и
номер документа, удостоверяющего личность; а также по реквизитам
медицинской справки.
Защита от несанкционированного доступа к персональным данным в
соответствии с требованиями нормативно-правовых актов по защите
персональных данных.
Администрирование учетных записей пользователей системы.
Эксплуатация ПО «Регистр медицинских справок» осуществляется на
основе функционально-ролевого подхода.
Всего имеется двенадцать ролей пользователей:
Администратор
Специалист медицинского информационно-аналитического центра
(МИАЦ);
Специалист Министерства здравоохранения Самарской области
(МЗ СО);
Регистратор медицинских учреждений (МО);
Профильный специалист;
Председатель комиссии;
31
Пользователь Управления Федеральной Миграционной службы
(УФМС);
Пользователь Государственной инспекции безопасности дорожного
движения (ГИБДД);
Оператор АИС.
Для каждой pоли имеется набор специфичных функций. Описание
состава функций каждой роли системы приведено в таблице 1.
Таблица 1 – Функциональные роли пользователей
Роль
Функции
Администратор
Администрирование ПО:
Ведение списка пользователей ПО.
Управление ролями пользователей.
Конфигурирование медицинских освидетельствований.
Мониторинг журнала действий пользователей.
Администрирование справочников системы.
Специалист
МИАЦ
Выделение адресного пространства номеров бланков
строгой отчетности;
Формирование и ведение серий бланков строгой отчетности;
Формирование и ведение журнала присвоения адресного
пространства номеров бланков строгой отчетности.
Специалист МЗ
СО
Просмотр выданных медицинских справок.
Ведение (просмотр, проверка, согласование, печать)
реестров мигрантов для проверки подлинности документа,
подтверждающего факт прохождения медицинского
освидетельствования.
Формирование электронного подтверждения в УФМС о
факте выдачи акта медицинского освидетельствования.
Профильный
специалист
Подтверждение результатов прохождения осмотра / исследования
медицинского освидетельствования специалистом (в том числе при
помощи электронной подписи)
Председатель
комиссии
Подтверждение результатов прохождения комплекса медицинского
освидетельствования (в том числе при помощи электронной
подписи)
Пользователь
УФМС
Проверка результатов прохождения медицинского
освидетельствования иностранным гражданином или лицом
без гражданства.
Создание и ведение (просмотр, печать, наполнение) реестров
мигрантов для проверки в МЗ СО подлинности документа,
подтверждающего факт прохождения медицинского
освидетельствования.
Пользователь
ГИБДД
Проверка результатов прохождения медицинского
освидетельствования кандидатов на выдачу (замену) водительских