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

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

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Характеристика блока «Поиск информации»

Использование различных источников информации, для получения необходимых данных при разработке информационных систем. В данном случае для поиска информации были задействованы эксперты, использовались официальные документы, а так же различные отслеживающие факторы. Все эти средства поиска контролировались при помощи методическое литературы и текущего технического задания. Для описания блока «Поиск информации» используем методологию 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 работает с файлами документов.

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

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

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

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

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

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

Настольные СУБД - это хорошо знакомые всем Microsoft Access, Corel Paradox, Borland dBase, Microsoft FoxPro и другие, менее известные. А к серверным СУБД относятся Borland InterBase, MySQL, Microsoft SQL Server, PostgreSQL, Informix, Oracle, Sybase, IBM DB2 и мн. др.

Существует также особый класс программ для работы с данными - так называемые универсальные процессоры данных. Эти программы служат для предоставления настольным СУБД возможности работы с различными форматами баз данных, как настольных, так и серверных. Типичный пример универсального процессора данных - ODBC (Open DataBase Connectivity, открытый доступ к базам данных), поставляемый в составе Windows, и его аналог JDBC (Java DataBase Connectivity, доступ к базам данных для программ, написанных на языке Java). В настоящее время практически все настольные СУБД поддерживают ODBC; JDBC распространен гораздо меньше.

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

Таблица 4.1 - Сравнение СУБД

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

4.2 Выбор веб-сервера

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

Рассмотрим следующие пакеты, которые позволяют разрабатывать сайты без необходимости выхода в сеть Internet:

«Денвер» (Denwer)

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

Таблица 4.2 - Сравнение бесплатных серверных пакетов

Из представленных выше серверных пакетов, более подходящим является TopServer v2.1.

5. РАЗРАБОТКА БАЗЫ ДАННЫХ И СТРУКТУРЫ ВЕБ-ИНТЕРФЕЙСА

Прежде чем приступать к работе рассмотрим архитектуру веб-баз данных.

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

Рисунок 5.1 - Отношение типа «Клиен-сервер» между веб-браузером и веб-сервером требует наличия связи

Приложение веб-базы данных, которое будет разрабатываться, наследуют глобальную структуру веб-баз данных, показанную на рис. 1.2.

Рисунок 5.2 - Базовая архитектура веб-баз данных включает в себя веб-браузер, веб-сервер, сценарий механизма и сервер баз данных

Типичная транзакция веб-базы данных состоит из этапов, обозначенных цифрами на рис. 5.2.

Веб-браузер пользователя отправляет HTTP-запрос определенной веб-страницы.

Например, поиск всех протоколов производственного совещания, созданных в какой-то день, используя HTML-форму. Страница с результатами поиска называется search.php.

Веб-сервер принимает запрос на search.php, получает файл и передает его механизму РНР на обработку.

Механизм РНР начинает синтаксический анализ сценария. В сценарии присутствует команда подключения к базе данных и выполнения запроса в ней (поиск протоколов). РНР открывает соединение с сервером MySQL и отправляет необходимый запрос.

Сервер MySQL принимает запрос в базу данных, обрабатывает его, а затем отправляет результаты - в данном случае, список протоколов - обратно в механизм РНР.

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

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

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

5.1 Структура информационной системы

Структура информационной системы (ИС) разделена на две части: база данных (БД), содержащая в себе таблицы с информацией и веб-интерфейса для удобной работы пользователей, с информацией, хранимой в БД (рис. 5.3).

Рисунок 5.3 - Структура информационной системы

5.2 Работа с базой данных

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

Ниже, представлены описания полей и типов некоторых таблиц.

В таблице SETTINGS храниться текст, который выводится в начале страницы (например: приветствие).

Таблица 5.1 - Описание полей таблицы SETTINGS

В таблице NEWS содержится информация о созданных новостях, которые отображаются на главной странице системы.

Таблица 5.2 - Описание таблицы NEWS

Таблица PROT хранит в себе информацию о протоколах и документах

Таблица 5.3 - Описание таблицы PROT

В таблице VALUE_IMG хранится информация, используемая во время регистрации нового пользователя.

Таблица 5.4 - Описание таблицы VALUE_IMG

Таблица USERS хранит в себе информацию о зарегистрированных пользователях системы.

Таблица 5.5 - Структура таблицы USERS

5.2.1 Создание базы данных и таблиц

Для создания базы данных будем использовать СУБД MySQL и бесплатное программное обеспечение для графического управления БД phpMyAdmin.

Для начала работы следует запустить сервер Apache. Для перехода к панели администрирования в адресной строке браузера следует, указать путь #"656552.files/image024.gif">

Рисунок 5.4 - Создание БД

В следующем окне появится подтверждение о создании БД с отображением SQL-запроса. В том же окне требуется ввести название таблицы, и количество полей (см. рис. 5.5), которое будет создано в таблице после нажатия кнопки Пошел.

Рисунок 5.5 - Создание таблицы settings

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

Рисунок 5.6 - Создание полей таблицы settings

При успешном создании таблицы появится окно с подтверждением и SQL-запросом операции. Ниже будет отображена сама таблица с полями и их свойствами (см. рис. 5.7).

Рисунок 5.7 - Результат создания таблицы settings

Для создания новой таблицы следует нажать по названию БД в левой части окна.

Создадим оставшиеся таблицы по вышеизложенному описанию.

Рисунок 5.8 - Вид списка таблиц созданных в БД

5.2.2 Вставка записей в таблицы

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

Рисунок 5.9 - Добавление информации в таблицу

В результате появится подтверждение о добавлении новых записей с SQL-запросом данной операции (см. рис. 5.10)

Рисунок 5.10 - Результат вставки новых записей в таблицу settings

Чтобы посмотреть содержимое таблиц, достаточно нажать на надпись Обзор на панели операций вследствие чего появится SQL-запрос с выборкой записей, а ниже будут представлены записи таблицы (см. рис. 5.11).

Рисунок 5.11 - Список существующих записей в таблице settings

Теперь можно приступить к созданию веб-интерфейса.

5.3 Создание веб-интерфейса

Веб-интерфейс разделен на два модуля: модуль администратора; модуль пользователя.

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

Рисунок 5.12 - Структура веб-интерфейса

Рисунок 5.13 - Схема веб-интерфейса информационной системы

Основная часть и модуль пользователя

Рисунок 5.14 - Схема веб-интерфейса информационной системы

6. Охрана труда

.1 Анализ опасных и вредных факторов: действие на человека электромагнитных полей, их параметры и нормирование

Источниками электромагнитных полей является: атмосферное электричество, радиоизлучение солнца и галактик, квазистатические, электрические и магнитные поля земли. Искусственными источниками являются индукторы, конденсаторы термических установок с ламповыми генераторами (мощность которых обычно лежит в пределах 8 - 200 кВт); антенны, открыты концы волноводов, генераторы сверхвысоких частот; линии электропередач (ЛЕП) напряжением до 1150 кВ, открыты распределительные устройства, которые включают коммутационные аппараты, устройства защиты и автоматики, измерительные приборы, сборные, соединительные шины и вспомогательные устройства являются источниками электрических полей промышленной частоты.

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

ω - круговая частота электромагнитных колебаний;

μ - магнитная проницаемость этого вещества;

ν - удельная электропроводимость вещества экрана;- коэффициент затухания;- глубина проникновения электромагнитного поля в экран.

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

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

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

Уровни допустимого облучения, которые действуют, определенные ГОСТ 12.1.006-76* «Электромагнитные поля радиочастот. Общие требования безопасности». Согласно ГОСТ 12.1.006-84, нормируемыми параметрами в диапазоне частот 60 кГц - 300 МГц есть напряженности Е и Н электромагнитного поля. На рабочих местах и в местах возможного нахождения персонала, профессионально связанного с действием электромагнитного поля, предельно допустимая напряженность этого поля в течение всего рабочего дня не должна превышать нормативных значений. Объясняется это тем, что вокруг источника на значительные расстояния тянется зона индукции, в которой человек находится под воздействием практически независимых составляющих электромагнитного поля.

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

Таблица 6.1 - Предельно допустимая плотность потока энергии

Нормирование постоянных магнитных полей проводится по СН 1748-72 «Предельно допустимые уровни напряженности постоянного магнитного поля на рабочем месте при работе с магнитными устройствами и магнитными материалами». Напряженность на рабочем месте постоянных магнитных полей не должна превышать 8 кА/м.

Согласно ГОСТ 12.1.002-75 «Электрических полей токов промышленной частоты напряжением 400 кВ| и выше. Общие требования безопасности» облучения электрическим полем регламентируется как по величине напряженности, так и по продолжительности действия. Допустимые уровни напряженности и длительности пребывания что работают без средств защиты в электрическом поле приведенные в таблице 6.2.

Таблица 6.2 - Предельное допустимое время пребывания человека в электрическом поле напряжением 400 кВ и выше (50 Гц)

Эффект действия электромагнитного поля на биологический объект принято оценивать количеством электромагнитной энергии, которая поглощается этим объектом при нахождении его в поле, Вт:

где  - плотность потока мощности излучения электромагнитной энергии, Вт/м2;

 - эффективная поглощающая поверхность тела человека, м2.

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

Таблица 6.3 - Нормы облучения УВЧ и СВЧ

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

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

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

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

К инженерно-техническим средствам защиты также принадлежат:

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

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

дистанционное управление.

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

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

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

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

Для защиты тела используется одежда из металлизированных тканей радиопоглощающих материалов. Глаза защищают специальными очками из стекла с нанесенной на внутреннюю сторону ведущей пленкой двуокиси олова. Резиновая оправа очков имеет запрессованную металлическую сетку или обклеенная металлизированной тканью. Этими очками излучения НВЧ ослабляется на 20 - 30 дБ.

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

.2 Характеристика помещения

Общая площадь помещения составляет 29,76 м2, высота - 2,5 м, помещение имеет два окна. Количество работающих в помещении - 4 человека. Следовательно, на одного работающего в помещении приходится: 29,76 : 4 = 7,44 (м2/чел.) рабочей площади. Согласно СНиП 2.09.04 - 87 на каждого работающего в управленческих помещениях должны приходиться не менее 4 (м2/чел.) рабочей площади. Высота помещения - не менее 2,5 м. Следовательно, нормативы размеров и обеспечения работающих рабочей площадью в офисе соблюдены.

В помещении расположено 4 компьютера, сканер и лазерный принтер. Напряжение источника питания в помещении - 220 В. В помещении размещенные 4 письменных стола, один шкаф для хранения документов.

План помещения приведен на рисунке 6.1.

Рисунок 6.1 - Планирование помещения

Помещение по степени опасности поражения электрическим током относится к помещениям без повышенной опасности (в соответствии ГОСТ 12.1.019-79 ССБТ). Это - сухое, безпыльное помещение с нормальной температурой воздуха и изолирующим полом. В нем отсутствуют условия, какие свойственны опасным и особенно опасным помещением (t<300 C, φ<75%), нет токопроводящей пыли, отсутствует возможность одновременного прикосновения к электрооборудованию и металлическим частям, которые имеют контакт с землей, нет высокой влажности, отсутствует химически активная среда, которая повреждает изоляцию. В качестве улучшения техники безопасности в рабочем помещении предусмотрены следующие мероприятия: планово предупредительный ремонт оборудования; не допускается загромождения проходов посторонними предметами и материалами. Для оценки эффективности существующей в рабочем помещении вентиляции и естественного освещения рабочих мест необходимо провести их расчет и сравнить полученные значения освещения и вентиляции с нормируемыми значениями.

6.3 Анализ достаточности естественного освещения

Для анализа достаточности естественного освещения приведем схему помещения для расчета, которая изображена на рис. 6.2.

Рисунок 6.2 - Схема расчета естественного освещения. Вид сбоку

Рисунок 6.3 - Схема расчета естественного освещения. Вид сверху

Нормированное значение коэффициента естественного освещения (КЕО) для четвертого светового пояса, в котором расположена (), определяется в процентах по формуле:

 - нормированное значение КЕО для III светового пояса ( = 1,5 % согласно СНиП II - 4-79);- коэффициент светового климата ( для Украины m = 0,9 );

с - коэффициент солнечности (поскольку окна расположенные на юго-запад, то с = 0,75).

Тогда нормируемое значение коэффициента естественного освещения для четвертого светового пояса Украины енIV, %:

,

Для определения достаточности естественного освещения нужно рассчитать фактическое значение КЕО исходя из формулы:

,

о - площадь всех окон в помещении, м2;п - площадь пола помещения, м2;

τо - общий коэффициент светопроницаемости оконного прореза, берем τо = 0,4;- коэффициент, который учитывает отражение света от внутренних поверхностей помещения;

hо - световая характеристика окна;

Кзд - коэффициент, который учитывает затемнение окон другими домами (домов нет, Кзд = 1);

Кз - коэффициент запаса (Кз = 1,4).

,

Для расчета коэффициента r1 необходимо рассчитать такие параметры:

) отношение глубины помещения к высоте от уровня условной рабочей поверхности к верху окна: 4/1,4 = 2,85;

) отношение расстояния к расчетной точке от внешней стены к глубине помещения: 4/4,8 =0,83;

) средневзвешенный коэффициент отражения потолка, стен, пола: ρсз = 0,5;

) отношение длинны помещения к его глубине: 6,2/4,8 = 1,3;

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

,

уі - значение функции при i-ом аргументе;

уі+1 - значение функции при (i+1)-ом аргументе;

у (х) - значение функции при заданном аргументе, который находится между значениями аргументов хі и хі+1;

хі - i-тое значение аргумента;

хі+1 - (i+1)-тое значение аргумента.

Отсюда r1,будет равно

,

Для определения коэффициента ηо воспользуемся таблицей значений световой характеристики ηо световых прорезов при боковом освещении:

,

,

,

Таким образом:

,

Сравнивая значение нормированного коэффициенту естественного освещения для данного помещения ( =1,01 %) и фактического ( = 0,6 %) придем к выводу, что нужны дополнительные меры для улучшения естественного освещения.

6.4 Анализ достаточности искусственного освещения в помещении

Для освещения помещения применяются люминесцентные лампы мощностью 80 Вт. Система освещения - общая. Итак, нормированное значение освещенности должно составлять не меньше 300 люкс (СНиП II - 4-79).

Схема размещения светильников в помещении приведено на рисунке 6.3.

Рисунок 6.3 - Схема размещения светильников

Рассчитаем фактическое значение освещения (Еф), учитывая то, что мощность ламп - 80 Вт, количество ламп в светильнике - 2 шт.

Фактическое значение искусственного освещения (Еф) рассчитываем за формулой:

,

где Fл - световой поток лампы, лм (для люминесцентных ламп мощностью 80 Вт - 3440 - 4320 лм);

hи - коэффициент использования светового потока (hВ = 0,4 - 0,6);- количество светильников, шт.;- количество ламп в светильнике, шт.;- площадь помещения, м2;

К - коэффициент запаса (К = 1,5-2);- коэффициент неравномерности освещения (Z = 1,1).

Берем:

 (лм);

hВ = 0,5;=4 шт.;= 2 шт.;

К = 1,5;= 1,1;

 (люкс),

Фактическое значение искусственного освещения входит в диапазон допустимых отклонений от нормативного (+20% - -10%), 316 » 300 это свидетельствует о достаточности искусственного освещения в помещении.

6.5 Расчет естественной вентиляции

Схема расчета естественной вентиляции приведена на рисунке 6.4.

Рисунок 6.4 - Схема расчета естественной вентиляции

Рассчитаем объем помещения:

,

Рассчитаем объем административного помещения, которое приходится на один работающего:

,

Поскольку согласно СНиП 2.09.04 - 87 объем помещения, который приходится на 1-го работающего, должен составлять 40 (м3), что больше чем фактическое значение данного показателя - 18,6 (м3/чел.), в отделе нужно обеспечить воздухообмен не меньше L1 = 30 (м3/ч) на каждого работающего. Рассчитаем необходимый воздухообмен Lн, м3/ч по формуле:

где n - наибольшее возможное количество работающих в помещении.

,

Найдем фактическое значение воздухообмена, пользуясь схемой, приведенной на рисунке 4.4, по формуле:

где m - коэффициент затраты воздуха (m= 0,55);- площадь форточки (F =0,5*1= 0,5 м2);- скорость выхода воздуха через форточку или вентиляционный канал, м/с, которая рассчитывается за формулой:

,

где g - ускорение свободного падения (g = 9,8 (м/с2));- тепловое давление, которое рассчитывается за формулой:

где gн и gвн - соответственно объемный вес воздуха извне помещение и внутри него, кГ/м3.

Объемный вес воздуха рассчитывается за формулой:

,

где Рб - барометрическое давление, мм рт. ст. (Рб = 750 мм рт. ст.);

Т - температура воздуха, К0.

Для офисных помещений, в которых выполняется легкая работа, в соответствии с ДСН 3.3.6.042-99 для теплого периода года температура в помещении не должна быт выше t = 28 0С, или Т = 301 0К, для холодного периода года соответственно - t = 17 0С, или Т = 290 0К.

Для воздуха извне помещение температура определяется в соответствии со СНиП 2.04.05-91 [5]:

для теплого периода года t = 24 0 С, или Т = 297 0 К,

для холодного периода года t = -11 0 С, или Т = 262 0 К

;

;

;

.

Найдем h2 из соотношений:

;

 (м);

= (0,5) 2 = 0,25 (м2);

= (1,6) 2 = 2,56 (м2);

Решим систему:

;

;

;

;

;

;

Отсюда:

;

 ;

;

;

;

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

Таблица 6.4 - Итоговая таблица

6.6 Мероприятия по улучшению условий работы

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

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

Для теплого периода года:

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

Для холодного периода года:

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

7. РАЗДЕЛ ЭКОНОМИКИ

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

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

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

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

. Материалы и комплектующие изделия.

. Основная заработная плата.

. Дополнительная заработная плата.

. Отчисление на социальные мероприятия.

. Расходы на содержание и эксплуатацию оборудования.

. Общепроизводственные затраты.

. Административные расходы.

. Расходы на сбыт.

. Материалы и комплектующие изделия.

Балансовая стоимость одной ЕВМ с периферией.

Таблица 7.1 - Стоимость ЕВМ

. Расходы на основную заработную плату.

 (7.1)

где - суммарная трудоемкость разработки продукта (год). Определяется экспертным путем исходя из фактически потраченного времени на производство и наладку продукта;

 - средняя часовая тарифная ставка 1 рабочий, который задействован в производстве продукта, (грн/год);

- коэффициент трудового участия (разрядности);

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

Общее время на создание программы состоит из разных компонентов.

Структура общего времени на создание программного продукта представлена в табл.7.2

Таблица 7.2 - структура общего времени на создание продукта

Время рассчитывается в человеко-часах, причем берется по фактически отработанному времени, а время остальных этапов определяется расчетных по условному числу команд Q. Условно число команд Q находится за формулой:

, (7.2)

где q - коэффициент, который учитывает условное число команд в зависимости от типа задания.

Выбрать значение коэффициента  можно из таблицы 7.3.

Таблица 7.3 - Коэффициенты

Для данного задания коэффициент q принимается = 1450. Из - коэффициент, который учитывает новизну и сложность программы.

Программные продукты могут быть отнесены к одной из 4 групп:

группа А - разработка принципиально новых заданий;

группа Б - разработка оригинальных программ;

группа В - разработка программ с использованием типичных решений.

группа Г - разовое типичное задание.

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

Таблица 7.4 - Группы сложности

Для данной задачи коэффициент С = 1,26. Теперь, исходя из формулы 7.2 можно определить условное число команд Q:

Определяем время, потраченное на каждый этап создания программного продукта:  (время на подготовку описания задания), берется по факту и составляет:

 (время на описание задания) определяется по формуле:

 (7.3)

где В - коэффициент учета изменений задания, коэффициент В в зависимости от сложности задания и числа изменений выбирается в интервале от 1,2 до 1,5.

Для данного задания .

К - коэффициент, который учитывает квалификацию программиста.

Выбрать значение коэффициента можно из таблицы 7.5.

Таблица 7.5 - коэффициент квалификации

В данном случае коэффициент К = 0,8. Применяя формулу 3.3 подсчитываем время на описание задания.

 (время написания программы на языке программирования) определяется по формуле:

 (7.4)

 (время отладки и тестирования программы):

 (время набивки программы) определяется по формуле :

 (7.5)

Теперь, зная время, потраченное на каждом этапе, можно подсчитать общее время на создание программного продукта:

(грн)

Дополнительная заработная плата берется в размере 15 % от основной.

 (грн)

Общая заработная плата будет ровна сумме основной и дополнительной:

(грн)

4.Отчисление на социальные мероприятия

Содержат отчисление от суммы основной и дополнительной зарплаты за установленными ставками общим объемом 36,9%, в том числе:

на обязательное государственное пенсионное страхование - 33,2%;

на государственное страхование от несчастных случаев - 0,9%;

на обязательное государственное социальное страхование на случай безработицы - 1,3%;

на расходы, связанные со временной потерей работоспособности работниками, захоронением, и в связи с рождением ребенка - 1,5%

, (7.6)

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

Таблица 7.6 - Налоги

. Расходы на содержание и эксплуатацию оборудования:

а) если оборудование арендуется - аренда машинного времени (Ом)

 (7.7)

где  - величина машинного времени, необходимого для разработки

и наладки продукта, год;

 - стоимость аренды машинного времени, грн./год.

Ориентировочно размер арендной платы определяется за формулой:

, (7.8)

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

- срок эффективной работы (срок полезной работы согласно ТУ паспорту), лет;

- количество рабочих дней в году;

- длительность изменения, час.

б) если оборудование находится на балансе предприятия.

Расходы на содержание и эксплуатацию оборудования = основная зарплата %, определяется из сведений за анализом полной себестоимости продукта (в среднем 120-150%).

.

. Общепроизводственные затраты.

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

Определяются в размере 130÷250% от основной зарплаты.

Общепроизводственные затраты = 1512 * 200% = 3024 грн.

Сумма статей 1-6 составляет производственную себестоимость продукта.

Производственная себестоимость продукта = 9440 + 1512+ 1656+ 606,2+ 425,8 + 1965,6 + 3024 = 18620,6 грн.

. Административные расходы.

Могут заключать в себе:

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

• командировочные расходы служебные администрации предприятия;

• расходы на пожарную и сторожевую охрану;

• расходы, связанные с подготовкой (учебой) и переподготовкой кадров;

• расходы на перевозку работников к месту работы и назад;

• расходы в уплату процентов за финансовые кредиты, а также процентов за товарные и коммерческие кредиты; расходы, связанные с уплатой процентов за пользование материальными ценностями, взятыми в аренду (лизинг);

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

• налоги, отчисления.

Определяются в размере 140-200% от основной зарплаты.

Админ расходы = 1512 * 180% = 2721,6 грн.

8. Расходы на сбыт.

Включают расходы на рекламу и предреализационную подготовку программного продукта. Ориентировочно эти расходы определяются в размере 5-10% от производственной себестоимости.

Расходы на сбыт = 18620,6 * 5%= 931 грн.

Сумма статей 1-8 составляет полную себестоимость продукта.

Полная себестоимость продукта = 18620 + 2721,6+ 931= 22272,6 грн.

. Расчет цены продукта

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

Расчет оптовой цены продукта проведем за схемой «себестоимость плюс прибыль».

 (7.9)

где С - себестоимость программного продукта

П - величина прибыли.

Прибыль определяется исходя из норматива (показателя) рентабельности производства продукции устанавливаемого предприятием:

, (7.10)

где R - рентабельность продукции (продукту), принимается в размере до 35%.

Тогда оптовая цена программного продукта определяется:

 (7.11)

 (грн)

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

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

 (7.12)

ВЫВОДЫ

В ходе работы над дипломным проектом были рассмотрены принципы работы с документами посредством информационных систем документооборота.

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

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

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

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

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

Данная система разработана с помощью языков программирования PHP и SQL, что обеспечивает удобство и легкость восприятия системы. В качестве PHP-редактора использован RapidPHP Editor, который относить к числу продуктов со свободной лицензией.

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

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

СПИСОК ЛИТЕРАТУРЫ

1.      Алексеев Ю.М. Быстро и легко создаем, программируем, шлифуем и раскручиваем web-сайт. - М.: Лучшие книги, 2005. - 432 с.

.        Альтерман Б.Д., Дрожжинов В.И., Моисеенко Г.Е. Руководство по составлению плана действий для отдела информационных технологий// Jet Info Online. - №8. - 2003.

3.      Алянов Г.Н. Консалтинг при автоматизации предприятий: подходы, методы, средства - #"656552.files/image133.gif">

Рисунок Д.1 - Страница авторизации пользователей

а) раздел документов б) список пользователей

Рисунок Д.2 - Вид страниц для не авторизированного пользователя

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

Зарегистрированный пользователи имеют право просматривать новости и документы. Вид страницы новостей изображён на рис. Д.3. На рисунке Д.4 отображаются примеры доступных пользователю документов. Если пользователя интересует определенный документ, у него есть возможность найти его с помощью формы поиска, расположенной над списком документов. Так же при просмотре документов пользователь может подтвердить ознакомление, с документом нажав соответствующую кнопку ниже документа, вследствие чего в текстовом поле появится его Ф.И.О.

Рисунок Д.3 - Вид страницы новостей

Рисунок Д.4 - Вид страницы раздела документов

В модуле администратора, возможно, выполнять те же действия что и в пользовательском. Помимо этого администратор имеет права на добавление, редактирование и удаление новостей и документов, которые выводится на обозрение пользователю. В левой части окна представлено меню, перейдя по ссылкам, которого можно выполнять редактирование страниц сайта. Для удобного редактирования текста новостей и протоколов средствами языка JavaScript к текстовым полям прикреплен визуальный редактор TinyMCE.(англ. Tiny Moxiecode Content Editor) платформонезависимый Javascript HTML WYSIWYG редактор на основе веб. К основным характеристикам программы относятся поддержка тем/шаблонов, языковая поддержка и возможность подключения модулей (плагинов). Используется в различных системах управления содержимым (CMS).

В «корень» админ-модуля помещается папка с содержащая страницы с кодом редактора, а на странице с формой создания новой новости или протокола между тегами <head></head> вставляется скрипт:

<script type='text/javascript'='tinymce/jscripts/tiny_mce/tiny_mce.js'></script>

<script type='text/javascript'>

<!--.init({: "textareas",: "simple" <!--advanced, simple--> });

-->

</script>

В результате такой вставки кода, под текстовым полем отображается панель визуального редактора с базовыми элементами редактирования текста (рис. Д.5).

Рисунок Д.5 - Панель инструментов визуального редактора TinyMCE