VIII Международная студенческая научная конференция Студенческий научный форум - 2016

Методыиэтапыразработки. Необходимо разделять следующие этапы разработки ИС.

• Анализ требований и спецификация. Требования – это потребности пользователей. Это очень важно для полного понимания будущих возможностей программного обеспечения. Анализ требований должен привести к концептуальной модели всех данных, которые затем будут необходимы для обработки медицинской информации всеми подсистемами ИС. При этом должна быть составлена полная спецификация субъекта системы – т.е. медицинской информации. Как показывает практика, большинство ошибок, обнаруженных в период испытания или эксплуатации, вызвано ограниченным или плохими интерпретациями требований пользователей.

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

• Выполнение. Суть этой стадии – транскрипция проектов в код реального программного обеспечения. Выбираются средства разработки, конкретная платформа операционной системы и сервера базы данных. Необходимо отметить, что в настоящее время пакеты для разработки ПО становятся все проще и мощнее. Уже обязательной возможностью считается визуальное проектирование, когда программист строит свои приложения, используя готовые модули, как кубики. Примером могут служить все современные пакеты для разработчиков – Borland Delphi, Microsoft Visual Fox Pro, Microsoft Visual Studio. Net и т.д.;

• Испытание. Цель этого этапа – гарантия соответствия спецификации и отсутствия ошибок на момент внедрения программного обеспечения. Существует много видов испытаний - установка, приемные испытания и т.д. На этом этапе используется специальная группа пользователей – бета-тестеры. Они устанавливают программное обеспечение, производят его тестирование и сообщают команде разработчиков свои результаты и пожелания;

• Внедрение и сопровождение занимает около 60-70% всего жизненного цикла ИС. При этом обязательно идет оценка качества программного продукта, рентабельности, надежности работы и безопасности. Группе программистов крайне необходимо протоколировать все вносимые изменения и их причины, а также свои наблюдения и мысли, которые затем могут пригодиться в дальнейшей работе.

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

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

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

В литературе часто встречается определение Spiral Model для эволюционного пути развития. Как отмечает G. A. Claudio, при этом на каждом цикле жизни ИС создаются новые функции и она развивается по спирали, не теряя связи с пользователем – т. е. эволюционирует.[3]

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

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

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

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

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

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

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

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

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

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

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

Код для цитирования: Скопировать