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

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

·              TScrollbar - полоса прокрутки, появляется автоматически в объектах редактирования, ListBox'ах при необходимости прокрутки текста для просмотра.

·              TGroupBox используется для визуальных целей и для указания Windows, каков порядок перемещения по компонентам на форме (при нажатии клавиши TAB).

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

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

Это полный список объектов на первой странице Палитры Компонент. Если Вам нужна дополнительная информация, то выберите на Палитре объект и нажмите клавишу F1 - появится Справочник с полным описанием данного объекта.

2.3 Описание информационной системы медицинского учреждения с использованием современных информационных технологий

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

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

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

Примечание: [составлено автором]

Рисунок 6. - Запись на прием

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

На следующем рисунке представлена база данных пациентов прикрепленных к данному медицинскому учреждению.

Примечание: [составлено автором]

Рисунок 7. - Прикрепление пациента к мед. учреждению

Примечание: [составлено автором]

Рисунок 8. - Добавление врача

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

Примечание: [составлено автором]

Рисунок 9 - Регистрация времени приема врача

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

Примечание: [составлено автором]

Рисунок 10. - Закрепление кабинета

. РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ И БЕЗОПАСНОСТИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

.1 Оценка затрат на разработку продукта и расчет себестоимости информационной системы

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

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

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

·  оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOG - Lines Of Code), а в настоящее время является количество функциональных точек (FPs - Function Points). Определение функциональной точки приведено;

·        оценка трудоемкости в человеко-месяцах или человеко-часах;

·        оценка продолжительности проекта в календарных месяцах;

·        оценка стоимости проекта;

·  оценка размера проекта базируется на знании требований к системе.

Для такой оценки существуют два основных способа:

·  По аналогии. Если в прошлом приходилось иметь дело с подобным проектом, и его оценки известны, то можно, отталкиваясь от них, приблизительно оценить свой проект;

·  Путем подсчета размера по определенным алгоритмам на основании исходных данных - требований к системе.

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

·  организации аккуратно документируются реальные результаты предыдущих проектов;

·        по крайней мере, один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;

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

Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритмических методов оценки (например, модель СОСОМО (Constructive COst MOdel - конструктивная стоимостная модель) Барри Боэма).

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

Согласно Эдварду Йордану, все доступные средства оценки классифицируются следующим образом:

Средства оценки, являющиеся коммерческими продуктами, такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software Productivity Research (SPR)). Глава фирмы SPR Каперс Джонс, "гуру" в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип "что заложишь, то и получишь"). В лучшем случае с помощью таких продуктов можно получить оценку с точностью +10%. Даже если точность будет +50%, это все равно лучше, чем брать данные "с потолка".

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

Аналитические модели для оценки проектов, описанные в литературе. Лучшими являются работы Барри Боэма (модель СОСОМО, разработанная им в начале 80-х гг., была позднее модифицирована в модель СОСОМО-2). Другой классической работой является книга Фредерика Брукса "Мифический человеко-месяц", так же переизданная в 1995 г. с учетом современной технологии и практики разработки ПО.

Различные руководства и отчеты организаций, подобных SoftwareEngineering Institute (SEI), которые могут помочь при выполнении уценки проектов.

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

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

Метод разработан на основе опыта реализации множества проектов создания ПО и поддерживается международной организацией IFPUG (International Function Point User Group). Существуют специальные программные средства, автоматизирующие проведение оценок по методу функциональных точек и позволяющие оценить, насколько быстро и с какими затратами в действительности удастся реализовать проект. Одним из таких средств является Knowledge PLAN - продукт фирмы SPR.

Knowledge PLAN создан на основе исследований, проведенных в фирме SPR в области оценок сложности, трудоемкости и производительности при разработке программного обеспечения. Оценка и планирование в пакете KnowledgePLAN ведутся на основе статистических закономерностей, выведенных путем анализа более чем 8 тыс. успешно завершенных проектов из различных областей применения. Исходные данные для вычислений находятся в специальном репозитории, который обновляется по результатам выполнения реальных проектов. В качестве метрик для оценки размеров программного обеспечения используются методика подсчета функциональных точек и метод оценки сложности программного продукта (собственная разработка фирмы SPR) -метрика, позволяющая учесть алгоритмическую сложность разрабатываемых программ.

KnowledgePLAN имеет следующие возможности:

·  формирование близкого к реальному плана работ по проекту;

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

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

·        проведение анализа "what - if ("что, если") для поиска лучших решений;

·        проведение сравнительного анализа качества и производительности разработки разнотипных проектов или однотипных проектов, при выполнении которых использовались различные технологии;

·  накопление статистической многомерной информации о проекте и его участниках;

·        классификация проектов для принятия решения о структуре управления проектом;

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

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

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

·  разработка методики наладки;

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

·        контроль на соответствие формализованным правилам построения;

·        проверка процесса просмотра материала и информационной технологии;

·        обнаружение и локализация ошибок;

·        обработка результатов, т.е. использование в производстве;

·        оценка времени работы программы.

Расчет стоимости:

Расчет заработной платы разработчика, создающего программное обеспечение по формуле:

S з/п = К * Т ;                                                    (1),

где: S з/п - заработная плата разработчика;

К - стоимость одного часа программиста;

Т - время, которое потребовалось на создание программы.

Подставив значения, получим:

S з/п = 500 * 100 = 50000;

Расчет стоимости энергии, потребляемой компьютером, по формуле:

SW = W * T * C ;                                               (2),

где: SW - стоимости энергии, потребляемая компьютером;

W - мощность, потребляемая компьютером;

·  С - Стоимость одного кВт.

·        Подставив значения, получим:

·  SW = 0,3 * 500 * 12 = 1800 (тенге).

·  Расчет общей суммы созданной программы S:

·  S = S з/п+ Sw                                                 (3)

·  S = 50000+ 1800

Общая стоимость составляет 51800 тенге.

3.2 Основные требования к внедрению информационной системы

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

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

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