Диплом: Организация корпоративных информационных систем на примере ГАУЗ МО Подольского наркологического диспансера

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
32
работана пользователем системы, а также разработана с нуля. Число установ-
ленных компонент в конфигурации определяет функционалᶥьные возможности
будущей информационной системы.
Наличие единой технологической платформы и общей методологии
обеспечивает: высокую скорость создания и внедрения решений за счет мак-
симального использования опробованной функциональности низкую стои-
мость прикладных решений - затраты на их создание существенно ниже соб-
ственных разработок.
Данная среда разработки была выбрана, т.к. в редакции уже приобретена
лицензия на 1С:Предприятие 8.2. Сотрудники редакции имеют опыт работы с
данной программой, а следовательно, не потᶥребуется время и денежные затра-
ты на обучение персонала.
1.4.3 Обоснование проектных решений по техническому обеспечению
Для обоснования выбора технического обеспечения, требующегося для
решения задачи, описываются: тип ЭВМ, устройства периферии (принтеры,
сканеры, плоттеры и т.д.), средства связи и другие технические элементы.
Для решения задач не требуется прᶥиобретать технᶥическое обеспечение, т.к. все
оборудование уже имеется в редакции. Все аппаратные средства предоставляют
возможность их использования для решения задач по учету заказов от клиен-
тов.
33
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Опишем жизненный цикл проекта. Жизненный цикл включает четыре
этапа:
1) планирование и анализ требований;
2) проектирование системы;
3) реализация системы;
4) оформление документации.
Планирование и анализ требований включает изучение документации,
консультации со специалистами по различным вопросам данной предметной
области.
В данный этап так же должны входить работы по рассмотрению усло-
вий, при которых будет использоваться система, описание выполняемых систе-
мой функций и выявление возможных ограничений при разработке системы.
Программная документация оформляется в соответствии ГОСТ 19.106-78
Этап 2. Проектирование системы
На данном этапе разработки должны быть выполнены работы по моде-
лированию функцᶥиональных требований к проектируемой системе и работы по
разработке логической и физической модели данных системы. После завер-
шения данных работ, должен быть осуществлен выбор программных средств
решения поставленных задач, проведено описание структуры входных и вы-
ходных данных и разработка структуры и интерфейса отдельных модулей про-
граммы.
Этап 3. Реализация системы.
34
На данном этапе должна быть выполнена начальная (показательная) ре-
ализация интерфейса подсистем, заполнение справочников, входящих в базу
данных системы и реализация одного из алгоритмов представления системы.
Этап 4. Оформление документации
Данный этап включает работы по оформлению пояснительной записки к
работе, расчет экономических затрат на разработку системы и оценку технико-
экономических показателей системы, разработку графической части. Про-
граммная документация оформляется в соответствии ГОСТ 19.106-78
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Оценим возможные риски, применительно к каждому этапу жизненного
цикла информационной системы.
На первом этапе «Планирование и анализ требований» возможны риски
по ошибкам в планировании и не полный охват требований.
На втором этапе «Проектирование системы» возможны риски, такие как,
ошибки в моделировании бизнес-процессов и проектировании структуры дан-
ных.
На третьем этапе «Реализация системы» возможны риски, такие как, не-
корректная работа программного продукта, ошибки в расчетах.
На четвертом этапе «Оформление документации» возможны риски, та-
кие как, неполное описание инсталляции и функционирования системы.
Причем на всех этапах жизненного цикла могут возникнуть риски, кото-
рые могут привести к различным последствиям:
1. задержка решения задачи;
2. потеря данных;
3. несанкционированный доступ к базе данных;
4. неверный ввод данных;
5. неверные действия пользователей;
6. задержка разработки программного обеспечения.
35
2.1.3 Организационно-правовые и программно-аппаратные средства обес-
печения информационной безопасности и защиты информации
По требованиям безопасности подсистема должна гарантировать воз-
можность безопасной установки, наладки, эксплуатации, обслуживания и ре-
монта ее технических средств.
Нормативы, гарантирующие безопасное взаимодействие человека с тех-
ническими средствами, установлены для электромагнитных полей, электриче-
ского напряжения и тока, излучений оптического диапазона, ионизирующих
излучений, опасных и вредных факторов.
Уровни освещенности рабочих мест пользователей должны соответ-
ствовать характеру и условиям труда. Мониторы должны соответствовать стан-
дартам на электромагнитное излучение, частоты развертки, разрешения экрана.
Также должна быть предусмотрена защита от слепящего действия света и
устранения бликов.
При выполнении работ с использование ЭВМ в производственных по-
мещениях уровень вибрации не должен превышать допустимых значений виб-
рации для рабочих мест в соответствии с действующими санитарноэпидемио-
логическими нормами.
В производственных помещениях при выполнении основных или вспо-
могательных работ с использованием ЭВМ уровни шума на рабочих местах не
должны превышать предельно допустимых значений, установленных для дан-
ных видов работ в соответствии с действующими санитарноэпидемиологиче-
скими нормами.
Рабочие столы следует размещать таким образом, чтобы видеодисплей-
ные терминалы были ориентированы боковой стороной к световым проемам,
чтобы естественный свет падал преимущественно слева. Искусственное осве-
щение в помещениях для эксплуатации ЭВМ должно осуществляться системой
общего равномерного освещения.
36
Локальная вычислительная сеть должна гарантировать высокую степень
защиты, безопасности и производительности своей работы, гибкую систему
управления пользователями.
Для обеспечения безопасности предполагается оснастить разрабатывае-
мую информационную подсистему контролем доступа к данным, на основе
введения уникальных идентификационных паролей и системой соответствую-
щих логинов.
Для защиты от внутренних угроз определим группы пользователей раз-
рабатываемой системы и назначим им соответствующие права доступа к пап-
кам и модулям системы, определим требования к паролям и частоте их смены, а
также другие параметры использования ИС.
Данные представим в форме таблицы 2.
Таблица 2 Разграничение прав пользователей
Группы поль-
зователей
Общая папка
Модуль отчеты
Смена пароля
Доступ в
интернет
Главный врач
чтение
Чтение / редак-
тирование / пе-
чать
Чтение/редактирование
Полный
Специалист IT
Чтение/редактирование
Чтение/печать
Чтение/редактирование
Полный
Врачи
Чтение
Чтение / редак-
тирование / пе-
чать
Скрыто
Полный
Остальной
персонал
Скрыто
Чтение / редак-
тирование / пе-
чать
Скрыто
Полный
37
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и ее описание
В исследуемой предметной области можно выделить следующие ин-
формационные объекты:
Справочник «Пациент» предназначен для отображения информации о
пациентах. Включает следующие атрибуты:
1) Номер полиса;
2) ФИО пациента;
3) Дата рождения;
4) Пол;
5) Место жительства;
6) Телефон;
7) Место работы;
8) Паспортные данные.
Справочник «Специалисты» предназначен для отображения информа-
ции о специалистах. Включает следующие атрибуты:
1) Код специалиста;
2) ФИО специалиста;
3) Должность;
4) Телефон.
Справочник «Отделение» предназначен для отображения информации
об отделениях. Включает следующие атрибуты:
1) Код отделения;
2) Наименование отделения.
Справочник «Тип учета» предназначен для отображения информации о
типах учета. Включает следующие атрибуты:
1) Код типа;
2) Наименование типа.
38
Справочник «Заболевания» предназначен для отображения информации
о заболеваниях. Включает следующие атрибуты:
1) Код заболевания;
2) Наименование заболевания;
3) Описание заболевания.
Справочник «Амбулаторная карта» предназначен для отображения ин-
формации о амбулаторной карте. Включает следующие атрибуты:
1) Код карты;
2) Дата оформления;
3) Номер полиса;
4) Дата снятия с учета;
5) Код специалиста;
6) Код заболевания;
7) Код отделения;
8) Код типа;
9) Дата поступления;
10) Дата выписки.
Сущности, рассматриваемой предметной области, и связи между ними,
представлены в таблице 3.
Таблица 3 – Взаимосвязи сущностей предметной области АИС
Сущность 1
Связь
Сущность 2
«Амбулаторная карта»
Относятся (1:N)
«Пациенты»
«Специалисты»
Относятся (1:N)
«Амбулаторная карта»
«Амбулаторная карта»
Относятся (1:N)
«Заболевания»
39
На рисунке 6 приведена информационно-логическая модель предметной
области.
Рисунок 6 – Информационно-логическая модель данных
2.2.2 Характеристика нормативно-справочной, входной и оперативной
информации
Особенностью программы «1С:Предприятие» является отсутствие еди-
ного приложения, оно разбито на отдельные модули, расположенные в необхо-
димых местах.
Модулем называется программа на встроенном языке системы
«1С:Предприятие». В модулях 1С содержится исполняемый код, который необ-
ходим для того, чтобы отреагировать на действия системы или пользователя,
когда визуальных средств недостаточно для описания взаимодействия объектов
в конфигураторе. Также в программных модулях можно описывать собствен-
ные методы. [17]
Пациент
Номер полиса
ФИО пациента
Дата рождения
Пол
Место жительства
Телефон
Место работы
Паспортные данные
Специалисты
Код специалиста
ФИО специалиста
Телефон
Отделение
Кол отделения
Наименование отделения
Заболевания
Код заболевания
Наименование заболевания
Описание з аболевания
Тип учета
Код типа
Наименование учета
Должность
Код должности
Наименование должности
Код специалиста (FK)
Амбулаторная карта
Код карты
Дата снятия с учета
Дата оформления
Дата поступления
Дата выписки
Код специалиста (FK)
Номер полиса (FK)
Кол отделения (FK)
Код заболевания (FK)
Код типа (FK)
40
Основные модули платформы 1С:Предприятие:
1) модуль управляемого приложения;
2) модуль обычного приложения;
3) модуль внешнего соединения;
4) модулем сеанса;
5) общие модули;
6) модуль объекта;
7) модуль формы;
8) модуль менеджера объекта;
9) модуль менеджера значений;
10) модули наборов записей.
Классификация модулей:
1) Серверные. Компилируются только на стороне сервера – модуль объ-
екта, модуль менеджера, модуль набора записей.
2) Клиентские. Компилируются только на клиенте, например модуль
управляемого приложения.
3) Комбинированные. Могут компилироваться и на сервере и на клиенте
– модуль формы и общие модули.
Опишем назначение перечисленных модулей.
Модуль управляемого приложения. Предназначен в основном для опре-
деления момента запуска приложения и момент завершения работы. В модуль
включены обработчики, которые позволяют перехватить внешнее событие от
оборудования. В модуле управляемого приложения отслеживается именно ин-
терактивный запуск системы.
Модуль обычного приложения. События модуля обычного приложения
срабатывают при запуске толстого клиента обычного приложения.
Модуль обычного приложения доступен из палитры свойств корневого узла
конфигурации после установки в параметрах конфигуратора на вкладке «Об-
41
щие» опции «Редактирование конфигурации для режимов запуска» в положе-
ние «Управляемое приложение и обычное».
Модуль внешнего соединения. Модуль внешнего соединения предна-
значен для обработки события входа (в режиме COM-соединения) и выхода из
системы. Модуль внешнего соединения компилируется на сервере.
Модулем сеанса. Модуль сеансов создан для инициализации параметров
сеанса. Запускается в привилегированном режиме, когда не выполняется про-
верка прав доступа при обращении к БД. Модуль сеанса компилируется на сер-
вере.
Общие модули. Общие модули описывают некоторые общие алгоритмы,
содержат функции, которые могут вызываться из различных мест. Общие мо-
дули могут быть скомпилированы как на клиенте, так и на сервере.
В общих модулях доступен раздел описания процедур и функций. В общем мо-
дуле задаются некоторые параметры, которые влияют на его поведение.
Модуль объекта. Многие объекты конфигурации содержат модуль объ-
екта. В него вводятся стандартные события, такие как создание нового элемен-
та справочника, запись нового объекта, удаление, обработка проведения доку-
мента и т.д.
Модуль формы. Модуль формы предназначен для обработки действий
пользователя (обработка события нажатия кнопки и т.д.). [10]
Программа 1С для пользователя - это единство конфигурации и плат-
формы 1С. Платформа не имеет смысл, без конфигурации, так же, как и конфи-
гурация 1С не является полноценной программой 1С. Когда пользователь при-
обретает программный продукт от фирмы 1С, в комплекте идет диск, где рас-
полагаются эти два файла. [4]
К тому же, «1С:Предприятие» является комплексным программным
продуктом, который имеет много специализированных отраслевых версий.
Этой программе присуща гибкая конфигурация, настраивается она в зависимо-
сти от требований конкретного предприятия.

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран