Разработка информационной системы медицинского учреждения

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

Поток деловой информации не только огромен в количественном отношении, но и удивительно разнообразен по видам ее представления и источникам. Более 70% информации хранится на бумаге в неструктурированном виде. Проблема быстрого, а главное, своевременного поиска нужного документа становится все более трудноразрешимой, при этом возникают случаи потери документов, их дублирования, долгого перемещением от одного исполнителя к другому. По оценкам аналитиков, до 30% рабочего времени сотрудников уходит на создание, поиск и согласование документов, каждый внутренний документ копируется до 20 раз, до 15% документов теряется. Поэтому для любого учреждения повышение эффективности работы с документами - ключевой вопрос. При этом традиционные методы работы с последними становятся малоэффективными. На помощь приходят информационные системы электронного документооборота (ИС), которые позволяют создавать и обрабатывать документы электронными средствами. ИС обеспечивают процесс создания, управления доступом и распространения больших объемов документов в компьютерах и сетях, а также обеспечивают контроль над потоками документов в организации.

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

Целью данной дипломной работы является создание информационной системы медицинского учреждения - Коммунального учреждения ”Сумской городской детской клинической больницы Святой Зинаиды”.

Для достижения цели необходимо решить следующие задачи:

- изучить структуру документации медицинского заведения;

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

- разработать пользовательский интерфейс и навигацию по системе;

- обеспечить возможность добавление/удаление пользователей, ограничение доступа к определенным задачам;

- разработать шаблоны документов, формирование документов, занесение данных о документах в базу данных;

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

- разработать поиск данных о документах с учетом критериев поиска используя структурированные SQL-запросы к базе данных, обеспечить возможность открыть найденные документы;

- разработать руководство пользователя.

1. ОРГАНИЗАЦИЯ РАБОТЫ С ДОКУМЕНТАМИ ПОСРЕДСТВОМ ИНФОРМАЦИОННОЙ СИСТЕМЫ ДОКУМЕНТООБОРОТА

документооборот база данные интерфейс

Общими возможностями информационных систем (ИС) документооборота являются издание документов, управление доступом к ним, их преобразование и безопасность.

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

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

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

Процесс принятия управленческого решения состоит из:

- получения информации;

- ее переработки;

- анализа, подготовки и принятия решения.

Все эти этапы самым тесным образом связаны с документационным обеспечением управления.

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

Это приводит к ухудшению качества управления и увеличению сроков принятия решений и числу неверных решений.

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

Основными задачами документационного обеспечения управления являются:

- сокращение информационных потоков до оптимального минимума;

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

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

К сожалению, в настоящее время документационное обеспечение деятельности украинских учреждений осуществляется, в основном, стихийно.

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

происходит потеря документов;

задержки прохождения и исполнения;

избыточность документооборота;

противоречивость принимаемых решений;

бесконтрольность исполнителей;

невозможность восстановления истории работы с документами.

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

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

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

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

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

Проектируемая система должна поддерживать жизненный цикл документа, состоящий из двух стадий:

Стадия разработки документа:

а) собственно разработка содержания документа;

б) оформление документа;

в) утверждение документа.

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

Стадия опубликованного документа:

а) активный доступ;

б) архивный документ;

в) краткосрочное хранение;

г) долгосрочное хранение;

д) уничтожение документа

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

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

Маршруты могут быгь более сложными, чем простые последовательные или параллельные:

комбинированные из последовательных и параллельных элементов;

условные, с переходами в зависимости от состояния тех или иных переменных маршрутов.

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

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

Интеграция с операцией публикования документа. Задача состоит в том, что после окончания маршрута документ, ассоциированный с маршрутом, меняет свой статус на опубликованный.

Для автоматизации делопроизводства необходимо использовать технологические достижения примерно в таком комплексе:

системы управления базами данных;

системы поиска документов и анализа текстов;

среду клиент-сервер;

Internet.

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

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

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

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

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

2. ИНФОРМАЦИОННОЕ ПРОЕКТИРОВАНИЕ

2.1 Жизненный цикл информационной системы

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

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

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

В основе деятельности по созданию и использованию программного обеспечения (ПО) ИС лежит понятие eго жизненного цикла (ЖЦ). ЖЦ является моделью создания и использования ПО отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей.

Традиционно выделяются следующие основные этапы ЖЦ ПО ИС:

анализ требований;

проектирование;

кодирование (программирование);

тестирование и отладка;

эксплуатация и сопровождение.

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

Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. В соответствии с этим наибольшее распространение получили три следующие модели ЖЦ:

- каскадная модель (рис. 2.1);

- поэтапная модель с промежуточным контролем (рис. 2.2);

-спиральная модель (рис. 2.3).

Рисунок 2.1 - Каскадная модель разработки ИС



Рисунок 2.2 - Поэтапная модель с промежуточным контролем разработки ИС

Рисунок 2.3 - Спиральная модель разработки ИС

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

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



2.2 Описание бизнес-процессов посредством CASE-технологий

При использовании CASE-технологий изменяются все этапы жизненного цикла программной системы, при этом наибольшие изменения касаются этапов анализа и проектирования.

Разработка информационной системы происходит с учетом задач бизнес-реинжиниринга (BPR - business process reengineering по Хаммеру/Чампи). Такой подход к рассматриваемой теме целесообразен по той причине, что часто приходится сталкиваться с зауженной трактовкой понятий "офис" и "автоматизация офиса", а вследствие этого с неоправдано суженной трактовкой методов бизнес-реинжиниринга и средств построения офисных ИС. В указанных случаях задачи сводятся к автоматизации рутинной деятельности по оформлению, хранению, передаче, контролю исполнения и поиску документов, отчего смысл понятий "бизнес-реинжиниринг" и "информационная система" выхолащивается или совсем исчезает. Вместе с ними исчезает или искажается система критериев, основываясь на которой можно принимать обоснованные проектные решения по применению или неприменению тех или иных средств автоматизации рутинных операций с документами. В тоже время, известно исходное требование BPR рассматривать "автоматизацию" как деятельность, противоречащую принципам реинжиниринга.

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

- общих основополагающих положений бизнес-анализа;

- основных положений и правил BPR;

- особенностей применения средств Workflow в условиях В PR.

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

В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE-средствами являются Rational Rose, BPwin, Silverrun, Process Analyst. В работе используется программа разработанная компанией AllFusion Process Modeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов.

Графически представленная схема выполнения работ, обмена информацией, документооборота визуализирует модель бизнес-процесса. AllFusion Process Modeler 7 (BPwin) помогает четко документировать важные аспекты любых бизнес-процессов: действия, которые необходимо предпринять, способы их осуществления и контроля, требующиеся для этого ресурсы, а также визуализировать получаемые от этих действий результаты. AllFusion Process Modeler 7 повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений.

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

«Создание информационной системы» (рис.2.4) - это главный блок, контекстная диаграмма, далее как ИС. Можно сказать, что существует потребность создания такого ИС, все это подкреплено техническим заданием. Контролируется данный процесс создания ИС нормативной документацией, методической литературой и законодательством страны. Механизмами выполнения являются: Интернет, офисное ПО и различное техническое обеспечение. В результате на выходе получаем программное обеспечение в виде ИС, а так же набор шаблонов необходимой документации для разработки информационных систем.

Для отображение всех процессов были использованы IDEF0 и IDEF3 методологии, для описания различных ситуаций и процессов, при проектировании информационной системы. Каждая из этих методологий по-своему хорошо позволяет отобразить бизнес-процессы. Для эффективности описания, был использован метод комбинации методологий IDEF0 и IDEF3.

Рисунок 2.4- Контекстная диаграмма ИС

Далее происходит процесс декомпозиции при помощи методологии IDEF0 (рис.2.5):

Рисунок 2.5 - Диаграмма декомпозиции 2-го уровня

2.2.1 Характеристика блока «Работа с документами ТЗ»

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

2.2.2 Характеристика блока «Поиск информации»

Использование различных источников информации, для получения необходимых данных при разработке информационных систем. В данном случае для поиска информации были задействованы эксперты, использовались официальные документы, а так же различные отслеживающие факторы. Все эти средства поиска контролировались при помощи методическое литературы и текущего технического задания. Для описания блока «Поиск информации» используем методологию IDEF0 (рис.2.6).

Рисунок 2.6 - Диаграмма декомпозиции «Поиск информации»

Рассмотрим структуру этого блока:

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

Официальные документы - это всевозможные отчеты, факсы, письма, методички, книги и прочие бумаги, связанные с данным поиском информации;

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

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

2.2.3 Характеристика блока «Разработка и реализация ИС»

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

Рисунок 2.7 -Диаграмма декомпозиции «Разработка и реализация ИС»

В разработке модели данные блок является основным, так как в нём описаны все ключевые моменты, которые понадобятся для создания ИС.

Рассмотрим структуру этого блока:

Разработка стратегии

Определение стратегии предполагает обследование системы. Основная задача обследования - оценка реального объема проекта, его целей и задач, а также получение определений сущностей и функций на высоком уровне. Результатом этапа определения стратегии является документ, где четко сформулировано, что получит заказчик, если согласится финансировать проект; когда он получит готовый продукт (график выполнения работ); сколько это будет стоить. В документе должны быть отражены не только затраты, но и выгода, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить) (рис 2.8).

Рисунок 2.8 - Блок «Разработка стратегии»

Рассмотрим структуру этого блока декомпозированного при помощи IDEF3 (рис.2.9):

Рисунок 2.9 - Диаграмма декомпозиции «Разработка стратегии»

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

Собираем информацию - на этом этапе выполняются несколько процессов, которые отображены в виде перекрестка, который начинается от блока «собираем информацию» и заканчивается в «рассчитываем проект». Такой способ отображения модели возможен только в IDEF3.

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

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

Формируем документацию - после завершения этапа расчёта, формируется документации, в которой должны быть отображены, четкие данные о том, что получит заказчик, когда он получит готовый проект, сколько это будет стоить. В документе должны быть отражены не только затраты, но и выгода, например время окупаемости проекта, ожидаемый экономический эффект. Выполненная на данном этапе работа позволяет ответить на вопрос, стоит ли продолжать данный проект и какие требования заказчика могут быть удовлетворены при тех или иных условиях. Может оказаться, что проект продолжать не имеет смысла, например из-за того, что те или иные требования не могут быть удовлетворены по каким-то объективным причинам. Если принимается решение о продолжении проекта, то для проведения следующего этапа анализа уже имеются представление об объеме проекта и смета затрат. Далее, если заказчик доволен, то необходимо переходить к следующему этапу разработки ИС - анализу. Если же, заказчик остался недоволен, то проект либо закрывается, либо пересматриваются другие варианты решения проблемы.

Анализ

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

Рисунок 2.10 - Блок «Анализ»

Рассмотрим структуру этого блока декомпозированного при помощи IDEF3 (рис.2.11):

Рисунок 2.11 - Диаграмма декомпозиции «Анализ»

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

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

Устанавливаем связи - нужно выяснить, отражают ли связи действительно важные отношения, наблюдаемые между сущностями. Так же необходимо выяснить, не является ли связь переносимой и не относится ли конструкция связи к редко используемым. Определяем функции ИС - на этом этапе аналитиками разрабатываются функции системы, которые предоставил заказчик в техническом задании. В процессе разработки ИС, они могут быть изменены, удалены или добавлены. Декомпозируем пункт «Определяем функции ИС» при помощи методологии IDEF3 (рис.2.12).

Рисунок 2.12 - Диаграмма декомпозиции «Определяем функции ИС»

Для подробного описания функции декомпозируем каждый из блоков при помощи методологии IDEF3. Проведение анализа технического обеспечения (рис.2.13):

Рисунок 2.13 - Диаграмма декомпозиции «Проведение анализа тех. обеспечения»

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

Работа с заявками пользователей (рис.2.14):

Рисунок 2.14 - Диаграмма декомпозиции «Работа с заявками пользователей»

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

В конце месяца подает руководству общий отчёт о проведенных работах.

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

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

Проектирование и реализация (рис.2.15) - на этапе проектирования формируется модель данных.

Конечным продуктом этапа проектирования являются:

схема базы;

набор спецификаций модулей системы (они строятся на базе моделей функций).

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

В нем также описывают принятый подход к решению каких-либо сложных технических вопросов.

Рисунок 2.15 - Блок «Проектирование и реализация»

Рассмотрим декомпозицию данного блока при помощи IDEF0 (рис.2.16):

Рисунок 2.16 - Диаграмма декомпозиции «Проектирование и реализация»

Рассмотрим каждый блок диаграммы в отдельности:

Рассмотрение результатов анализа

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

Оценка ограничений и определение целевой архитектуры

Ограничениями, известными с момента обследования бизнес-процессов, являются смета затрат и сроки внедрения. Могут быть и другие ограничения, например допуск персонала к той или иной информации. Если какие-либо требования не могут быть удовлетворены в принципе, принимается решение о доведении этого факта до сведения спонсоров проекта. Под выбором архитектуры понимается и выбор платформы (платформ), и выбор операционной системы (операционных систем). В системе могут работать несколько компьютеров на разных аппаратных платформах и под управлением различных операционных систем.

Изучение продуктов третьих фирм

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

Проектирование БД

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

Разработка интерфейса

Интерфейсы конечного пользователя - это то, что заказчик критикует в наибольшей степени, в силу того, что именно эти части информационной системы он может более или менее квалифицированно оценить. Это означает, что интерфейсы являются наиболее часто изменяемым элементом информационной системы именно на этапе реализации. Часто изменяемый компонент (компоненты) информационной системы следует изолировать от редко изменяемых компонентов, чтобы одни изменения не влекли за собой другие. Следует также установить достаточно жесткие правила для внешнего вида интерфейсов пользователя. Должно создаваться впечатление единого стиля для всех компонентов информационной системы.

Реализация ИС

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

Проектирование процесса тестирования

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

Тестирование (рис.2.17)

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

Задача оценки характеристик зависимости производительности информационной системы от роста объемов обрабатываемой информации не может быть решена без генераторов данных.

Рисунок 2.17 - Блок «Тестирование»

Декомпозируем данный блок при помощи методологи IDEF3 (рис.2.18):

Рисунок 2.18 - Диаграмма декомпозиции «Тестирование»

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

О результатах тестирования, руководство узнает через отчёты, после изучения которых, делается вывод о дальнейших действиях относительно ИС. Либо происходит переход к процессу внедрения, либо повторного тестирования, а так же возможен вариант доработки, который является крайне нерентабельным для разработчиков.

Внедрение (рис.2.19)

Рисунок 2.19 - Блок «Внедрение»

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

2.2.4 Характеристика блока «Разработка документации»

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

2.2.5 Характеристика блока «Написание диплома»

Этот блок отображает процесс написания дипломной работы, которые требует поэтапное проектирование выполняемых действий при реализации ДП (рис.2.20).

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

Рисунок 2.20 - Декомпозиция диаграммы «Написание диплома»



3. ФОРМИРОВАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ НА ИНФОРМАЦИОННУЮ СИСТЕМУ

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

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

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

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

На основе существующих стандартов об авторстве на ТЗ, у заказчика есть широкая возможность выбора разработчика. ТЗ может быть разработано:

силами самого заказчика;

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

конкурсными исполнителями, чьи обязанности включают только написание ТЗ;

силами сторонних исполнителей.

Для тех ТЗ, которые пишутся исполнителем, существует ряд нормативной документации:

ГОСТ 21.408-93 «Правила выполнения рабочей документации автоматизации технологических процессов»;

ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»;

ГОСТ 24.703-85 «Типовые проектные решения в АСУ. Основные положения»;

ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения»;

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

ГОСТ 34.602-90 «Техническое задание на создание автоматизированной системы»;

ГОСТ 19.201- 78 Единая система программной документации;

ГОСТ 2.114-95 Единая система конструкторской документации.

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

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

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

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

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

Титульный лист дополнения к ТЗ оформляют аналогично титульному листу технического задания. Вместо наименования «Техническое задание» пишут «Дополнение №... к ТЗ на AC... »

На последующих листах дополнения к ТЗ помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

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

На начальном этапе разработки ТЗ исполнитель создает примерный план содержания.

Используем существующие рекомендации к содержанию на основе стандартов:

Общие сведения;

Назначения и цели создания системы;

Характеристика объекта автоматизации;

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

Условия эксплуатации;

Требования к программной документации;

Технико-экономические показатели;

Стадии и этапы разработки;

Порядок контроля и приемки.

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

При необходимости исполнитель создает список принятых сокращений и глоссарий.

Техническое задание на разработку ИС медицинского учреждения размещено в приложении Б.

4. ВЫБОР ПРОГРАМНОГО ОБЕСПЕЧЕНИЯ

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

4.1 Выбор системы управления базами данных

Система управления базами данных (СУБД) - это программа для работы с базами данных. Именно с помощью СУБД пользователь и другие программы получают доступ к данным, хранящимся в базе. Как правило, любая СУБД состоит из двух частей. Первая часть - это та программа, с которой работает пользователь, - клиент данных. Вторая же часть непосредственно занимается базой данных: принимает от клиента данных запросы на выборку и изменение данных, выполняет их и возвращает клиенту. Это так называемый процессор данных. Можно сказать, что клиент данных занимается приемом запросов от пользователя и выводом результатов, а процессор - собственно обработкой данных. И в зависимости от того, как реализованы клиент и процессор данных, СУБД делятся на две большие группы: настольные и клиент-серверные.

Настольная СУБД реализована в виде одной единственной программы; и клиент, и процессор данных слиты воедино в одном исполняемом файле.

Это первое отличие. Второе отличие: настольная СУБД работает непосредственно с файлами баз данных, точно так же, как Microsoft Word работает с файлами документов.

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