Гусев А.В., член-корр. РАМН Дуданов И.П., Романов Ф.А., Дмитриев А.Г., Карельский научно-медицинский центр СЗО РАМН, Петрозаводск
В последние годы в России появился целый ряд уникальных разработок в области комплексных медицинских информационных систем (МИС), предназначенных для автоматизации работы учреждений здравоохранения. Одними из самых интересных являются: ин-формационная система "Интерин" (Институт программных систем РАН), МИС "Артемида", МИС "Амулет" и некоторые другие. Эти системы не только разработаны, но и активно раз-виваются - распространения и признания в практическом внедрении они получили за по-следние 2-3 года. В литературе опубликованы положительные отзывы коллективов клиник самого разного профиля и масштабов об опыте применения информационных систем в рабо-те [1, 3, 5, 10, 13, 14, 17-20]. Наметилась тенденция на комплексное решение разносторонних задач лечебного учреждения, что особенно радует и свидетельствует о качественном росте отечественных разработчиков в области медицинской информатики.
Однако при более глубоком изучении этого процесса все сильнее выделяется сущест-венная проблема: несмотря на наличие глубоко проработанных программных решений, практически отсутствует опыт полного перехода на электронный принцип хранения и обра-ботки информации в лечебном учреждении [8, 11]. Имеется ряд серьезных преград, через ко-торые не могут перешагнуть даже современно оснащенные клиники в своем стремлении от-казаться от бумажных носителей информации и повысить эффективность в организации сво-ей работы. Все они могут быть объединены в несколько групп.
Во-первых, существующая в России правовая база не обеспечивает должного уровня юридической защиты медицинских работников, применяющих информационные технологии в повседневной практике. Во-вторых, финансовые ресурсы большинства учреждений здра-воохранения пока не могут позволить им приобрести достаточное количество компьютерной техники и дорогостоящего программного обеспечения для комплексной автоматизации. По-этому этот процесс успешно протекает лишь в некоторых, зачастую далеких от медицинской направленности, разделах работы ЛПУ: статистика, бухгалтерия, автоматизация работы ад-министративного звена и т. д. В третьих, в России практически отсутствует школа, которая бы готовила профессионалов высокого уровня в области разработки и внедрения именно комплексных медицинских информационных систем, людей по определению работающих на стыке сложнейших наук - медицины и прикладной математики. Для становления отечест-венной школы в этой области творческим коллективам необходимо обмениваться наблюде-ниями и мнениями в разработке программных продуктов, накапливая тем самым специаль-ные знания и формируя потенциально выгодные направления в поиске эффективных реше-ний разработки и внедрения комплексных МИС.
Коллектив авторов имеет 5-летний опыт в разработке медицинской информационной системы. За это время изучена на практике эффективность различных подходов. Применя-лись Microsoft FoxPro разных версий, CA Clipper, Lotus Notes, начиная с версии 4.6, СУБД Microsoft SQL Server, Microsoft Access, Borland Paradox, MySQL и IBM DB2. Апробирован вариант написания программного обеспечения на Borland Delphi, сервлеты на Java, применя-лись Lotus Designer и мультиплатформенный Lotus Script и некоторые другие технологии. Серверная часть системы работала под управлением Microsoft Windows NT Server, Microsoft Windows 2000 Server и Red Hat Linux 6.0. В качестве клиентской операционной системы применялись все версии Windows, начиная с Microsoft Windows 95. Кроме инструментария, была проведена работа по изучению эффективности различных методик проектирования ба-зы данных МИС. В итоге мы остановились на применении принципа объектно-реляционной парадигмы в проектировании БД МИС [4]. Кратко концепция этого подхода выражается в том, что в силу особенностей предметной области необходимо разрабатывать информацион-ную систему на базе синтеза двух, различных по своей природе, систем управления базами данных (СУБД) - объектно-ориентированной и реляционной. Только на основе этого синтеза удается исключить недостатки обоих СУБД и использовать их достоинства. В качестве ос-новной СУБД используется Lotus Domino Server R6.0.3 для функционирования объектной части МИС и MySQL 4.0.17 для реляционной составляющей системы. Разработка программ-ного обеспечения ведется в среде Lotus Designer R6.0.2 и Borland Delphi 6 Professional SP3. В ходе изучения эффективных способов создания приложений для системы найдено несколько, на наш взгляд, интересных находок.
Во-первых, одной из самых существенных причин увеличения стоимости МИС мы считаем высокую стоимость самой разработки. Изучив причины этого явления, мы пришли к выводу, что не последнюю роль в этом сыграла традиция создания медицинских информа-ционных систем на основе так называемых АРМ-ов (автоматизированных рабочих мест). Причем зачастую под АРМ-ом понимается именно клиентское программное обеспечение, хотя изначально этот термин имел более широкое толкование [10]. Чаще всего разработка АРМ-ов ведется по следующей методике: разработчики выбирают некоторую общую задачу (например, создание электронной истории болезни для стационара), проектируют структуру базы данных, разрабатывают приложение для работы с ней. Нередко это приложение выпол-няется в виде нескольких версий - АРМ главного врача, АРМ регистратора, АРМ лаборанта и т. д. Разработка систем в 65% случаев ведется на Borland Delphi. При этом даже на выпуск очень сырой версии АРМа тратится 4-8 месяцев. Затем столько же времени уходит на обкат-ку. Вместе с тем, по нашим оценкам, разработчику приходится 10-20% времени тратить на создание специфичного для медицинской области кода. Остальная часть, причем самая тру-доемкая и ответственная, приходится на разработку механизмов, обеспечивающих целост-ность данных, подсистему безопасности и администрирования МИС, связь с периферийным медицинским оборудованием и т. д.
Однако, не вызывает сомнений, что эти решения значительно уступают промышлен-ным решениям для корпоративного рынка, над которыми трудятся лучшие специалисты и которые прошли многолетнюю проверку. В связи с этим вызывают недоумение подобные попытки "изобрести велосипед". На наш взгляд, разработка МИС не должна осуществляться созданием и дальнейшей интеграцией отдельных АРМов. Для создания МИС необходимо применять готовые программные платформы для групповой работы, уже имеющие в своем арсенале мощные средства для мультиплатформенной разработки программы, готовые тех-нологии для развертывания и управления подсистемой безопасности. В своей работе мы вы-брали пакет групповой работы Lotus Notes/Domino, разрабатываемый в настоящее время корпорацией IBM. Эта платформа является за рубежом стандартом "де факто" для создания мощных информационных систем, ориентированных на обработку электронных документов и мы считаем, что она наиболее подходит для создания медицинских информационных сис-тем.
Работа над созданием МИС "Кондопога" на основе Lotus Notes/Domino версии 4.6 на-чата в сентябре 1999 года. Через 2 месяца МИС, включающая подсистемы работы врача, клинической и биохимической лаборатории, функциональной и рентгенологической диагно-стики, аптеки и планирования рабочего времени была поставлена в эксплуатацию. А еще че-рез 2 месяца лечебное учреждение, использующее систему, полностью перешло на элек-тронный способ хранения информации, отказавшись от бумажных носителей.
Вторым важным решением явился отказ от проектирования базы данных МИС по функциональному назначению, когда для отдельной задачи (например, подсистема лабора-тории, функциональной диагностики, консультационная и т. д.) создавалась своя база дан-ных. Хотя такой подход имеет ряд преимуществ, главным из которого является снижение требований к аппаратной мощности сервера за счет разделения потоков пользовательских запросов к отдельным БД. Однако было избрано проектирование БД МИС таким способом, что вся информация собиралась вокруг пациента и хранилась физически в одной БД.
Однако количество таких БД в МИС является вариабельным и зависит от количества функциональных групп пользователей, имеющихся в ЛПУ. Так, в стационаре это может быть выделенная БД для каждого отделения или корпуса. Для поликлиники - это могут быть БД, разделенные по участкам обслуживания. Кроме того, в этих БД специальным образом хра-нится только актуальная информация, а неиспользуемые данные помещаются в БД архива. Для решения ряда задач может быть принята либо связанная с объектно-ориентированным ядром реляционная БД, либо специальным образом сконструированные представления, ко-торые мы называем регистрами (рис. 1).
Рис. 1. Укрупненная схема объектно-реляционной базы данных медицинской информационной системы
Проектирование структуры БД, таким образом, позволяет достичь стабильно малого объема БД МИС в течение практически всего срока ее эксплуатации, а тем самым обеспе-чить максимально возможную производительность работы МИС. Так, начиная с 1999 года база данных историй болезни пациентов, проходящих реабилитацию в медицинском центре, имеет объем 26-29 Мбайт. При этом вся информация за время работы центра сохранена, а скорость работы остается стабильно высокой. Сложностью указанной методики является то, что программное обеспечение информационной системы должно поддерживать любое коли-чество физических баз данных в ядре системы, объединенных в одну логическую структуру.
Таким образом, необходимо разработать алгоритмы всех программ МИС так, чтобы они могли корректно работать с базой данных текущих документов, состоящей из одной или не-скольких частей. Это вызвано тем, что в некоторых случаях программам необходимо обра-ботать данные не только по отдельной части базы данных, но и по всей имеющейся в ней информации. В связи с этим необходимо перед каждым обращением к серверу выполнять ряд последовательных шагов:
определить, какое количество физических баз данных и их имен соответственно установ-лено на сервере;
определить возможность доступа к каждой базе данных в отдельности;
выполнить соответствующий запрос к каждой базе данных, указав в правильном формате полный адрес, включающий имя сервера и имя базы данных на нем;
обработать и запомнить полученный ответ;
повторить шаги 2-4 для каждой базы данных;
сложить накопленные ответы и обработать их, как единый пакет информации.
Доказано [5, 10, 16, 17, 19, 20, 22], что для эффективного решения такой задачи необхо-димо исключить в текстах программ МИС прямое обращение к базам данных. Взамен этого предложено использовать специальное промежуточное программное обеспечение, называе-мое сервисами middleware. Схема работы МИС на базе сервисов middleware показана на ри-сунке 2. С целью определения эффективности разработки системы с применением объектно-ориентированной технологии на основании использования сервисов middleware, авторами был выполнен анализ работы по созданию информационной системы в период 1999-2001 гг. Были получены следующие данные (таблица 1).
Таблица 1
Использование однотипного программного кода в различных подсистемах МИС
| Подсистема | Общий код | Уникальный код | ||
| % от всего | % времени на разработку | % от всего | % времени на разработку | |
| Документы ИБ и АК | 45 | 10 | 55 | 90 |
| Лабораторная подсистема | 74 | 38 | 26 | 62 |
| Статистика | 17 | 9 | 83 | 91 |
Как представлено в таблице 1, в некоторых видах ПО доля повторяющегося кода со-ставляет значительную часть. Исключение его из этапа разработки нового приложения по-зволило сократить среднее время создания новой программы с 3,8 до 2,9 недель (на 23,68%). Кроме этого, использование проверенных библиотек позволило значительно, на 35-50%, со-кратить количество последующих исправлений ошибок. Фактически вся основная работа над ошибками была связана с исправлением уникального кода приложения, в редком случае (в среднем 5-7 ошибок на 100 исправлений) исправлением используемых middleware-сервисов.
Таблица 2
Анализ ошибок и исправлений в МИС
| Подсистема | До применения middleware | После применения middleware | ||
| Количество ошибок в неделю | Время ис-правления ч/неделю | Количество ошибок в неделю | Время ис-правления ч/неделю | |
| Микроядро системы | 26 | 4,5 | 2,9 | 3,5 |
| Статистика | 8 | 6,2 | 1,3 | 0,8 |
| Лабораторная подсистема | 1,2 | 3,4 | 0,2 | 1,2 |
| Внешние программы | 13 | 14,2 | 2,5 | 6,5 |
| Календари | 3 | 4,4 | 0,4 | 1,2 |
Дополнительно с широким применением базовых библиотек класса middleware, выпол-ненных в виде динамически подсоединяемых библиотек (dynamic link libraries DLL), было предложено встроить во все основные функции единый обработчик ошибок. В случае фа-тального прекращения работы какой-то функции middleware он пересылал системе резуль-тат, переданный по умолчанию, и дополнительно отправлял максимально возможную ин-формацию разработчику по e-mail. Это позволило сократить время, необходимое на анализ и исправление ошибки в среднем на 45-55%. Нередко исправление ошибки производилось уже до того, как пользователь сообщал об этом программистам [10, 14].
Необходимо отметить, что применение модели программного обеспечения системы на основе использования общих сервисов middleware позволяет применять эволюционный ме-тод, называемый в литературе Spiral Model [12, 18]. При этом возможно внедрение новых версий информационной системы путем простого подмена базовых сервисов на новые вер-сии. Эти версии могут работать как со старой информационной системой, так и с новой, без необходимости повторного обучения персонала или исправлений в структуре существующей базы данных.
Таким образом, применение сервисов middleware позволило в среднем увеличить появ-ление новых версий программ с 4 до 7 в месяц (на 75%), снизив удельную стоимость каждой новой версии на 22%. Применение указанных технологий позволило разработать систему со значительной экономией. Так, разработка крупнейшей отечественной МИС "Интерин" длит-ся 9 лет, штат разработчиков насчитывает 25 человек. Разработка ИС, в которой принимают участие авторы, осуществляется 4 года и только 2 последних из них в ней постоянно участ-вует 2 программиста. Приняв, что данная МИС содержит только 50% от возможностей МИС "Интерин", зарплата одного программиста составляет около $300 (долл. США), а работа ве-дется 11 месяцев в году, получена экономия по сравнению с традиционными технологиями около $75900 в год. Таким образом, за 4 года работы стоимость разработки МИС на основе объектно-реляционного подхода составила 5,3% от суммы, которая потребовалась бы для создания МИС с применением традиционного подхода.
Рис. 2. Схема работы промежуточного программного обеспечения и его место в структуре программ медицинской информационной системы
На этапе, когда ИС становится пакетом многочисленных программ, остро встает вопрос их поддержки. Актуальность ее растет вместе со сроком эксплуатации и ростом количества пользователей. Наряду с начальными капитальными затратами, администрирование инфор-мационной системы составляет значительную цифру в смете расходов ЛПУ [3, 5, 10, 14]. Применение сложных комплексных информационных систем требует высококвалифициро-ванного штата программистов и администраторов [12, 15]. С ростом количества подключен-ных к базе данных системы пользователей растет и сложность ее обслуживания. В таблице 3 приведены средние еженедельные затраты времени работы администратора МИС, получен-ные в результате хронометрических исследований в медицинском центре.
Таблица 3
Трудозатраты администратора МИС
| № | Вид деятельности | % общего времени | Примечание |
| 1 | Обслуживание вызовов пользователей на местах | 38 | |
| 2 | Установка пакетов исправлений | 17 | |
| 3 | Отправка сообщений об ошибках разработчикам системы | 7.8 | |
| 4 | Плановое обслуживание клиентских ПК (дефраг-ментация диска, проверка на вирусы) | 6,9 | |
| 5 | Знакомство с литературой | 5 | |
| 6 | Анализ журналов безопасности | 4 | |
| 7 | Установка новых приложений | 3,5..45,7 | 45,7% при вне-дрении системы |
| 8 | Контроль за новыми версиями ПО и публикация-ми исправлений | 3,2 | |
| 9 | Исправление сбоев в клиентских операционных системах | 0,1-2,1 | Максимум при Windows 95/98 |
| 10 | Внесение исправлений в системные справочники, текущие изменения настроек приложений | 0,3-8,6 | Максимум - при внедрении |
| 11 | Прочие | 14,2 |
Использование встроенных в middleware-приложений глобальных обработчиков оши-бок позволяет сократить время по п. 3 (отправка отчетов об ошибках) практически до нуля, т. к. вся ключевые отчеты система формирует и отправляет автоматически. Обслуживание вызовов пользователей, исправление локальных сбоев на компьютерах пользователей и вне-сение исправлений в справочники системы являются практически неуправляемыми факто-рами. Плановое обслуживание компьютеров, анализ журналов работы системы, чтение спе-циальной литературы являются постоянными величинами, истекающими из функциональ-ных обязанностей администратора системы.
Следовательно, управляемыми факторами, способными сократить (перераспределить) трудозатраты технического персонала на обслуживание системы являются: установка при-ложений системы, установка исправлений (в т. ч. самой ИС и общесистемного ПО), контроль за новыми версиями ПО. Причиной высоких показателей в этих категориях является тради-ционный способ установки прикладного ПО: администратор сети запускает инсталляцион-ные пакеты на компьютерах пользователей, а затем по мере появления и т. н. "заплатки" к ним. Учитывая высокие показатели в выходе новых версий отдельных программ МИС на ба-зе ООП, 1 администратор может обслуживать до 22-25 пользователей. По нашему опыту, время от появления пакета исправлений до его полной инсталляции на всех компьютерах се-ти может составлять от 2-3 суток при работе 50 станций до 4-7 суток при работе 100-150 станций. Этот факт чреват тем, что злоумышленник может воспользоваться этим промежут-ком для нарушения системы безопасности или другого нанесения вреда, если он знает меха-низм ошибки, которую планируется исправить "заплаткой".
Анализируя эти проблемы, было предложено использовать технологию установки и об-новления приложений [8, 11, 14]. Суть ее работы состоит в следующем: в системе имеется выделенная база данных дистрибутивов приложений. Все команды на запуск приложений используют в своей работе специальный сервис, предоставляемый системой. Ей передается команда на запуск приложения, содержащая код программы и параметры ее запуска. Всю необходимую работу выполняет система, используя следующий алгоритм (рис. 3).
Определяется, имеется ли описание программного продукта с переданным кодом в цен-тре программ. Если описание не найдено, выдается сообщение об ошибке.
Вычисляются из описания программы необходимые данные, в частности: номер версии ПО, имя исполняемого файла и т. д.
Проверяется, имеется ли вызываемое ПО на компьютере пользователя: если нет, произ-водится инсталляция программного обеспечения - из базы данных извлекаются необхо-димые файлы и настройки, создается программная папка и выполняется копирование файлов и т. д. После окончания процесса установки исполняемый файл запускается.
Если вызываемое ПО имеется на компьютере пользователя, проверяется его версия и сравнивается с версией в центре программ. В случае, если на локальном компьютере со-держится устаревшая версия, производится обновление программных файлов в зависимо-сти от настроек одним из следующих способов:
метод переустановки. Он является наиболее простым решением. При его использова-нии, однако, механизм синхронизации должен оценить следующие факторы: доступность обновленного дистрибутива, его объем и время копирования на данную рабочую станцию, права доступа данного пользователя к нужному дистрибутиву, возможные ограничения, накладываемые администратором сети на данный дистрибутив;
метод обновления. Он более трудоемкий. Его суть в том, что на данном компьютере приложение не переустанавливается целиком, а лишь перезаписывается его исправленная часть. Этот метод имеет преимущество в том, что объем данных для исправления значи-тельно меньше по сравнению с полным дистрибутивом.
метод исправления справочников. Применяется, если приложение само не изменило свою версию, однако его справочник устарел по сравнению с эталоном системы.
Если все проверки пройдены, исполняемый файл запускается.
Рис. 3. Алгоритм работы подсистемы установки и обновления программ
Применение данной технологии позволило сократить время, необходимое на обновле-ние клиентского программного обеспечения с 2-3 дней до 5-10 сек. (в среднем), снизить за-траты ЛПУ на администрирование информационной системы на 47,8% за счет снижения трудозатрат администратора системы и возможности совмещения ставок программиста и администратора. Ежегодная экономия составляет около $72 на одного пользователя.
Список литературыАйламазян А. К., Гулиев Я. И. Данные, документы и архитектура медицинских инфор-мационных систем. http://interin.botik.ru
Айламазян А. К., Гулиев Я. И., Матвеев Г. Н., Турна И. А., Белова И. А. ИС КОТЕМ-2001: Требования, проблемы, решения. http://interin.botik.ru
Андерсон К., Минаси М. Локальные сети. Полное руководство: Пер. с англ. - К.: ВЕК+, ЭНТРОП, Спб.: КОРОНА принт, 1999. - 624 с.
Андреев А. М., Березкин Д. В., Кантонистов Ю. А. Выбор СУБД для построения инфор-мационных систем корпоративного уровня на основе объектной парадигмы // СУБД 1998. - № 4-5. - С.26-50.
Губин И. М., Тарасов В. В., Антонов Р. А. и другие. Разработка и внедрение новой авто-матизированной информационной системы ЦКБ // Кремлевская медицина. Клинический вестник, 2000. - №4. - С.51-54.
Гусев А. В., Романов Ф. А., Дуданов И. П.. Опыт разработки медицинской информаци-онной системы // Медицинский академический журнал, 2001.- №1.- Приложение 1.- С.18.
Гусев А. В., Романов Ф. А., Осиик Т. А.. Применение медицинской информационной системы в работе клинических лабораторий медицинского центра // Медицинский ака-демический журнал, 2001. - № 1. - Приложение 1. - С.19.
Гусев А. В., Дуданов И. П. Оценка 3-летнего опыта разработки и внедрения информаци-онной системы: выводы и перспективы // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - С.56-57.
Гусев А. В., Дуданов И. П., Романов Ф. А. Информационная система в медицине - кон-цептуальная модель.http://surgery.karelia.ru
Гусев А. В., Романов Ф. А., Дуданов И. П., Воронин А. В., Информационные системы в здравоохранении. ПетрГУ. Петрозаводск, 2002. - 120 с.
Дуданов И. П., Гусев А. В., Романов Ф. А., Воронин А. В. и соавт.. Информационная система в здравоохранении - концептуальная модель // Сердечно-сосудистые заболева-ния. Бюллетень НЦССХ им. А. Н. Бакулева РАМН. Том 3. - № 11. - 2002. - С.332.
Дуданов И. П., Гусев А. В., Романов Ф. А., Воронин А. В. Информационные системы в здравоохранении // Медицинский академический журнал, 2002. - № 1.- Том 2.- Стр.58-77.
Дуданов И. П., Гусев А. В., Романов Ф. А., Кемпи С. И. Региональная информационная система "Кондопога" // Сердечно-сосудистые заболевания. Бюллетень НЦССХ им. А. Н. Бакулева РАМН. 2002. - Том 3. - № 11. - С.335.
Дуданов И. П., Гусев А. В., Романов Ф. А., Кемпи С. И. и соавт. Создание "паспорта здо-ровья" больных с сердечно-сосудистыми заболеваниями с использования информацион-ной системы // Медицинский академический журнал, 2003. - Том 3. - № 3. - С.125-133.
Ильмаст А. В., Марусенко К. М., Моисеев Е. В. Некоторые вопросы технологии разра-ботки МИС // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - С.85-86.
Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Пер. с англ. - М.: Издательско-торговый дом "Русская редакция", 2000. - 608 с.
Шеррер Жан-Рауль. Информационные системы в здравоохранении: технология и орга-низация // Кремлевская медицина. Клинический вестник, 2000. - № 4. - С.15-17.
Claudio G. A. da-Costa, MD, Rodrigo P. Quaresma, BE and Renato M. E. Sabbatini, PhD. A Software Engineering Approach to the Development of Computer-Based Patient Record Sys-tems. http://home.nib.unicamp.br/~claudiog/slides/seandcpr/seandcpr.htm
Ramamoorthy C. V., Prakash A., Tsai W. T., Usuda Y. Software Engineering: problems and perspectives. Computer. Outubro. 1984. - P.191-209.
Reidsema C., Szczerbicki E. A Blackboard database model of the design planning process in concurrent engineering. Cybernetics and Systems: An International Journal, 2001. - 32. - Р.755-774.
Sherrer J. R., Lovis C., Baund R., Borst F., Spahni S. Integrated Computerised Patient Records: The DIOGEN2 Distributed Architecture Paradigm with Special Emphasis on its Middleware Design. In User Acceptance of health Telematics Applications (I Iakovidis et al., Eds) IOS Press, Technology and Informatics 56. - P.15-31.
Spahni S., Sherrer Jr. Sauquet D., Sottile PA. Consensual trends of optimizing the constitution of middleware. ACM SIGCOMM Computer Communication. - 1998. - V.28, №5. - P.76-
Похожие работы
... 6. Справка. Представление графа сценария задачи представлено на рисунке 1. Рис.1 Граф сценария задачи «Библиотека вуза» 3.2 Разработка контекстной диаграммы Контекстной диаграмма позволяет наглядно представить бизнес-процессы, протекающие в данной информационной системе, документооборот и информационные массивы При построении данной диаграммы используется принцип ...
... позволяет исключить случайные ошибки, связанные с неправильным заполнением документов, и уменьшить временные затраты на выполнение функций. Наименование программы – "Информационная система работы отдела кадров предприятия". 2. Основание для разработки Выполнение курсового проекта по курсу "Базы данных". 3. Назначение разработки Информационная система призвана упростить работу отдела кадров, ...
... я хотела бы посвятить именно приемному отделению ТК «Жуковка». Я считаю, что будет вполне целесообразно разработать и внедрить на данном предприятии автоматизированную информационную систему планирования сбыта, что в свою очередь ускорит и существенно облегчит работу приемного отделения ТК «Жуковка». План-схема приемного отделения и структура работы службы приема и размещения ТК «Жуковка» ...
... охватывало бы вопросы воспитания, взаимодействия учителей с родителями учеников и самими учениками, вопросы самоподготовки желающих учиться учеников, помощи отстающим и т.п. 5. РАЗРАБОТКА ШКОЛЬНОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ (ШИС) НА ОСНОВЕ IT-ТЕХНОЛОГИЙ ДЛЯ МОУ СОШ № 97 Поставленные в предыдущем разделе задачи могут быть решены путем организации широчайшего (относительно родителей, учеников и ...
0 комментариев