Автоматизированная система утверждения электронных документов на основе MS SharePoint 2007

Содержание

Введение

1. Технический проект

1.1 Описание предметной области

1.2 Обзор аналогов

1.3 Постановка задачи

1.4 Цель
дипломного проекта

1.5 Цель и
назначение системы

1.6 Актуальность системы

1.7 Выбор средств и технологий

1.8 Модель потоков данных

1.9 Модель вариантов использования

1.10 Диаграммы деятельности

1.11 Модель классов предметной
области

1.12 Требования к техническому и
программному обеспечению

1.13 Требования к интерфейсам
информационной системы

1.14 Расчет надежности системы

2. Рабочий проект

2.1 Общие сведения о работе системы

2.2 Функциональное назначение
системы

2.3 Используемые средства
разработки

2.4 Установка и выполнение
программного продукта

2.5 Общий алгоритм работы
программного продукта

2.6 Руководство пользователя

3. Программа и методика испытаний

3.1 Пошаговый алгоритм загрузки
файла УП из программы «Учебные планы»

3.2 Пошаговый алгоритм загрузка
файла УП/ГУП с помощью модуля передачи файлов на сервер

3.3 Пошаговый
алгоритм одобрения документа сотрудником

3.4 Пошаговый алгоритм отклонения
документа сотрудником

4. Экономический эффект от разработанной системы

4.1 Технико-экономическое
обоснование проекта

4.2 Маркетинговые исследования

4.3 Исходные данные для расчета
экономической эффективности

4.4 Расчет объема инвестиций

4.5 Расчет текущих затрат

4.6 Оценка экономической
эффективности проекта

4.7 Вывод

5. Обеспечение эргономики рабочего места

5.1 Анализ
условий труда при эксплуатации программного продукта

5.2 Разработка инженерно-технических и организационных мероприятий по обеспечению
безопасности труда

5.3 Расчет
необходимой освещенности рабочего места пользователя

5.4 Требования
по электробезопасности

5.5 Требования по пожарной
безопасности

5.6 Мероприятия по повышению
устойчивости функционирования системы

5.7 Эргономика пользовательского
интерфейса

5.8 Выводы

Заключение

Литература

Приложение 1. Контекстная диаграмма

Приложение 2. Диаграмма потоков данных

Приложение 3. Диаграмма вариантов использования

Приложение 4. Диаграмма деятельности – учебные планы

Приложение 5. Диаграмма
деятельности – графики учебных процессов

Приложение 6. Модель классов предметной области

Приложение 7. Диаграмма развертывания

Приложение 8.
Программный продукт на оптическом носителе

Введение

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

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

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

Системы
электронного документооборота (СЭД) решают очень широкий спектр задач:

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

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

·         
поддержка
бумажного документооборота;

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

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

·         
совместная
подготовка документов;

·         
согласование
документов;

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

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

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

1. Технический проект

1.1     
Описание
предметной области

 

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

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

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

поток
входящей документации, состоящий из поступающих в организацию документов;

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

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

Документооборот – это движение документов в
организации с момента их создания или получения до завершения исполнения или
отправления.

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

1.        
Сотрудник создает
первую версию документа.

2.        
Документ
передается для визирования и рецензирования сотруднику, первому в списке
рецензентов.

3.        
Документ
возвращается с замечаниями (для внесения изменений) или с визой. Если документ
утвержден, происходит возвращение к шагу 2 для следующего сотрудника из списка
рецензентов. Иначе выполняются следующие шаги.

4.        
На основе
замечаний автором документа создается следующая версия документа.

5.        
Переход к шагу 2
для сотрудника, первого в списке рецензентов.

Производимая
работа направлена на создание автоматизированной системы утверждения документа
для АГТУ. Для учреждения такого масштаба, включающего в себя более 35 отделов и
более 60 кафедр, проблема управления документооборотом весьма актуальна,
поскольку в процессе документооборота принимает участие больше количество
сотрудников ВУЗа. Это не только научно-педагогический (профессорско-преподавательский
состав, научные работники), но и инженерно-технический,
административно-хозяйственный, производственный, учебно-вспомогательный
персонал. Виды документов, составляющих документопотоки в АГТУ, разнятся как по
способу фиксации информации, так и по способам согласования, степени гласности,
юридической силе и многим другим параметрам. Вот некоторые виды документов:

·         
учебные планы;

·         
графики учебного
процесса;

·         
докладные и
служебные записки;

·         
заявления (на
увольнение, на трудоустройство, пр.);

·         
трудовые договоры
и договоры на оказание услуг;

·         
приказы;

·         
уставы,
инструкции и т.д.

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

1.        
заведующий
кафедрой;

2.        
директор
института или декан факультета, за которым закреплена кафедра;

3.        
начальник
учебного отдела;

4.        
проректор по
учебно-методической работе;

5.        
ректор.

Графики учебного
процесса в АГТУ визируются в следующем порядке:

1.        
директор
института или декан факультета;

2.        
заведующие
кафедрами, которые закреплены за институтом/факультетом;

3.        
начальник учебного
отдела;

4.        
проректор по
учебно-методической работе;

5.        
ректор.

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

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

·         
ненаглядность
процесса утверждения;

·         
возможность
утери, порчи документа.

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

1.2 Обзор аналогов

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

·         
«ДЕЛО» - «Предприятие»:

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

Функции системы:
стандартный функционал по организации электронного документооборота,
дополнительные функции – назначение штрих-кодов документам, печать штрих-кодов
(при наличии соответствующего оборудования);

·         
«Босс» - «Референт»:

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

Функции системы:
стандартный функционал по организации электронного документооборота,
дополнительные функции – реализация совместной работы;

·         
«Евфрат» -
«Документооборот»:

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

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

Сравнение аналогов
приведено в табл. 1.1.

Таблица 1.1

Сравнение аналогов

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

1.3     
Постановка задачи

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

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

1.4     
Цель дипломного
проекта

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

1.5     
Цель и назначение
системы

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

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

1.6     
Актуальность
системы

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

1.7     
Выбор средств и
технологий

В качестве
платформы для реализации автоматизированной системы предлагается выбрать Microsoft Office SharePoint Server 2007, который уже используется в АГТУ. В качестве
средства обработки и хранения данных предлагается СУБД MS SQL Server 2005. В качестве веб-сервера предлагается
использовать MS IIS 6.0. Для проектирования предлагается использовать средства Enterprise Architect 7.5, для управления базой данных – MS SQL Server Management Studio, а для реализации проекта – MS Microsoft Visual Studio 2005, MS Visual Studio 2008 SP1 и MS Office SharePoint Designer 2007.

Microsoft Office SharePoint Server 2007

Сервер Office
SharePoint Server 2007 — это интегрированный набор серверных приложений,
способствующих улучшению организации труда благодаря возможностям по
организации документооборота, всестороннего управления информацией и
корпоративного поиска, ускорению совместно выполняемых бизнес-процессов и
упрощению обмена данными между отделами. Windows SharePoint Services полностью
построена на технологии ASP.NET, поэтому иметь дело придется с хорошо знакомыми
языками программирования, библиотеками классов ASP.NET и NET Framework и
привычными инструментами разработки. Пользователи могут быстро создавать узлы
SharePoint, поддерживающие публикацию определенного контента, управление
информацией, управление записями и бизнес-аналитику. Кроме того, можно
эффективно выполнять поиск людей, документов и данных, использовать
бизнес-процессы на основе форм, а также получать доступ к большому объему
бизнес-данных и анализировать их.

MS SQL Server

Microsoft SQL
Server — система управления реляционными базами данных, разработанная
корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL,
создан совместно Microsoft и Sybase. Transact-SQL является реализацией
стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями.
Используется от небольших и средних по размеру баз данных до крупных баз данных
масштаба предприятия, конкурирует с другими СУБД в этом сегменте рынка.

Microsoft SQL
Server в качестве языка запросов использует версию SQL, получившую название
Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO
для SQL) с множественными расширениями. T-SQL позволяет использовать
дополнительный синтаксис для хранимых процедур и обеспечивает поддержку
транзакций (взаимодействие базы данных с управляющим приложением). Microsoft
SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня
приложения под названием TabularDataStream (TDS, протокол передачи табличных
данных). Протокол TDS также был реализован в проекте FreeTDS с целью обеспечить
различным приложениям возможность взаимодействия с базами данных Microsoft SQL
Server и Sybase. Microsoft SQL Server также поддерживает
OpenDatabaseConnectivity (ODBC) — интерфейс взаимодействия приложений с СУБД.
Версия SQL Server 2005 обеспечивает возможность подключения пользователей через
веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам,
не предназначенным для Windows, кроссплатформенно соединяться с SQL Server.
Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий
приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с
Microsoft SQL Server 2000 и 2005.

SQL Server
поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL —
это совокупность одинаково конфигурированных серверов; такая схема помогает
распределить рабочую нагрузку между несколькими серверами. Все сервера имеют
одно виртуальное имя, и данные распределяются по IP-адресам машин кластера в
течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов
кластера доступен автоматический перенос нагрузки на другой сервер.

SQL Server
поддерживает избыточное дублирование данных по трем сценариям:

1.        
Снимок:
Производится «снимок» базы данных, который сервер отправляет получателям.

2.        
История
изменений: Все изменения базы данных непрерывно передаются пользователям.

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

В SQL Server
встроена поддержка .NET Framework. Благодаря этому, хранимые процедуры БД могут
быть написаны на любом языке платформы .NET, используя полный набор библиотек,
доступных для .NET Framework, включая CommonTypeSystem (система обращения с
типами данных в Microsoft .NET Framework). Однако, в отличие от других
процессов, .NET Framework, будучи базисной системой для SQL Server 2005,
выделяет дополнительную память и выстраивает средства управления SQL Server
вместо того, чтобы использовать встроенные средства Windows. Это повышает
производительность в сравнении с общими алгоритмами Windows, так как алгоритмы
распределения ресурсов специально настроены для использования в структурах SQL
Server.

MS SQL Server Management Studio

SQL Server Management Studio — это утилита, входящая в состав Microsoft SQL Server 2005 и более поздние версии, для конфигурирования,
менеджмента и администрирования всех компонентов Microsoft SQL Server. Утилита включает скрипт-редактор и графическую
программу, которая работает с объектами и настройками сервера.

Главным
инструментом SQL Server Management Studio является Object Explorer, который
позволяет пользователю просматривать, извлекать, и полностью управлять
объектами сервера.

MS IIS

IIS (Internet
Information Services, до версии 5.1 — Internet Information Server) —
проприетарный набор серверов для нескольких служб Интернета от компании
Майкрософт. IIS распространяется с операционными системами семейства Windows
NT.

Основным
компонентом IIS является веб-сервер, который позволяет размещать в Интернете
сайты. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.

Служба WWW в
составе IIS

Основным
компонентом IIS является веб-сервер — служба WWW (называемая также W3SVC),
которая предоставляет клиентам доступ к сайтам по протоколам HTTP и, если
настроено, HTTPS. Один сервер IIS может обслуживать несколько сайтов (IIS 6.0 и
выше). Каждый сайт имеет следующие атрибуты:

·         
IP-адрес сайта;

·         
TCP-порт, на
котором служба WWW ожидает подключений к данному сайту;

·         
Заголовок узла
(Host header name) — значение заголовка Host запроса HTTP, указывающее обычно
DNS-имя сайта.

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

Для каждого сайта
указывается домашний каталог — каталог в файловой системе сервера,
соответствующий «корню» сайта. Например, если сайту www.example.com сопоставлен
домашний каталог D:\example, то на запрос ресурса с адресом
http://www.example.com/index.htm веб-сервер вернёт файл D:\example\index.htm.

Архитектура
службы WWW

В IIS 6.0,
доступном в составе систем Windows Server 2003, служба WWW претерпела серьёзные
изменения. Был добавлен новый режим обработки запросов, называемый режимом
изоляции рабочих процессов (англ. Worker process isolation mode). В этом режиме
все веб-приложения, обслуживаемые сервером, работают в разных процессах, что
повышает стабильность и безопасность системы. Кроме того, для приёма запросов
HTTP был создан новый драйвер http.sys, который работает в режиме ядра, что
ускоряет обработку каждого запроса.

Все запросы к
статическому контенту, не требующие исполнения скриптов, исполняются самим
http.sys в ядре, что сближает IIS с HTTP-серверами режима ядра.

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

SSL поддерживается
отдельным процессом HTTP SSL, который служит мостом между TCP и http.sys.

Безопасность в
службе WWW

Веб-сервер IIS
предоставляет несколько способов разграничения доступа к сайтам и
веб-приложениям. Служба WWW в составе IIS отличается от других веб-серверов
тем, что функции обеспечения безопасности в ней тесно интегрированы с системой
Windows NT, на основе которой она работает. В частности, чтобы получить доступ
к защищённому ресурсу, посетитель должен ввести имя и пароль пользователя,
существующего в системе Windows, на которой установлен IIS (или в домене
ActiveDirectory, если сервер принадлежит к домену). После этого пользователь
работает с сайтом так же, как если бы он выполнил интерактивный вход в систему на
сервере. К нему применяются установленные файловой системой NTFS разрешения на
доступ к файлам и каталогам.

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

Определённый
пользователь Windows сопоставляется с каждым посетителем сайта даже в том
случае, когда ограничение доступа не требуется. Этот режим называется режимом
анонимного доступа. В этом случае посетитель представляется на сервере как
специальный пользователь, имя которого обычно имеет формат IUSR_xxxx (где xxxx
— имя компьютера, на котором установлен IIS, в седьмой версии этот специальный
пользователь не содержит имени компьютера, т.е. просто IUSR). Этому
пользователю должен быть разрешён доступ к ресурсам, которые открыты анонимным
посетителям.

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

·         
Базовая
аутентификация (basic authentication) — имя и пароль передаются по сети
открытым текстом.

·         
Сжатая
аутентификация (digest authentication) — пароль обрабатывается хеш-функцией
перед отправкой по сети, что делает невозможным его прочтение в случае
перехвата злоумышленником.

·         
Встроенная
аутентификация Windows (integrated Windows authentication) — выполняется
попытка входа на сервер с теми же учётными данными, под которыми работает
браузер пользователя.

Реализация
веб-приложений для IIS

Веб-сервер IIS
поддерживает несколько различных технологий создания веб-приложений:

1.        
ASP.NET —
разработанная Microsoft технология; для IIS это — основное на сегодняшний день
средство создания веб-приложений и веб-служб. IIS 6.0 поставляется вместе с
операционными системами, в которые также изначально входит .NET Framework, так
что поддержка ASP.NET как будто уже встроена в IIS 6.0; для более ранних версий
необходимо отдельно загрузить и установить .NET Framework.

2.        
ASP —
предшествовавшая ASP.NET технология создания динамических веб-страниц на основе
сценариев.

3.        
CGI — стандартная
межплатформенная низкоуровневая технология создания динамических веб-страниц.

4.        
FastCGI —
клиент-серверный протокол взаимодействия веб-сервера и приложения.

5.        
ISAPI —
низкоуровневая технология, аналогичная интерфейсу модулей Apache,
предоставляющая полный доступ ко всем возможностям IIS, возможность разработки
веб-приложений в машинном коде и возможность переопределения части функций IIS
и добавления к нему функций, как связанных с генерацией контента, так и не
связанных с этим. Подсистема исполнения скриптов ASP и подсистема ASP.NET
выполнены как модули ISAPI.

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

Сам сервер
поддерживает только CGI, FastCGI[3], ISAPI и SSI. Все остальные технологии
являются надстройками, работающими через CGI, FastCGI или ISAPI. При помощи CGI
приложения для IIS могут разрабатываться на основе практически любых, в том
числе сторонних, инструментов, допускающих запись в стандартный поток вывода и
чтение переменных среды — Perl, C/С++ и даже средствами интерпретатора
командной строки Cmd.exe. Технология ISAPI позволяет, с одной стороны,
создавать специальные приложения для IIS, требующие особенно тесного
взаимодействия с механизмом сервера, а с другой стороны является удобной
платформой для организации эффективного взаимодействия IIS с другими
технологиями разработки веб-приложений — например, PHP и Perl.

Почтовые
возможности

IIS поддерживает
работу SMTP/POP3 сервисов. В современных версиях MicrosoftExchangeServer
реализация протоколов SMTP, POP3 и IMAP выполнена в виде подсистем к IIS,
заменяющих поставляемые с IIS почтовые подсистемы.

Enterprise
Architect

Enterprise
Architect –
CASE-инструмент для проектирования и конструирования программного обеспечения.
EA поддерживает спецификацию UML2.0, описывающую визуальный язык, которым могут
быть определены модели проекта.

Некоторые из
ключевых функций ЕА:

·         
создание
элементов UML-моделей широкого круга назначения;

·         
размещение этих
элементов в диаграммах и пакетах;

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

·         
генерация кода
для конструируемого программного обеспечения (ПО).

Используя EA,
можно выполнять форвард и реверс-инжиниринг ActionScript, C++, C#, Delphi,
Java, Python, PHP, VB.NET и Visual Basic классов, синхронизировать код и
элементы моделей, проектировать и генерировать элементы баз данных. Из моделей
может быть быстро создана документация в стандартном rtf-формате и
импортирована в Word для финального редактирования, так же доступна генерация
HTML-документов.

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

1.8     
Модель потоков данных

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

Внешними сущностями системы являются:

·         
пользователь;

·         
администратор.

Контекстная
диаграмма приведена в приложении 1, диаграмма потоков данных – в приложении 2.

1.9     
Модель вариантов
использования

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

·         
загрузка
документа;

·         
выгрузка
документа;

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

·         
утверждение и
комментирование;

·         
поиск;

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

·         
запуск процесса;

·         
завершение этапа
процесса;

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

·         
получение списка
процессов;

·         
добавление
пользователей;

·         
удаление
пользователей;

·         
назначение
разрешений.

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

Описание
диаграммы вариантов использования:

1.        
Вариант
использования:
запуск процесса.

Актеры: пользователь, администратор.

Краткое описание: ручной запуск процесса утверждения
загруженного ранее документа.

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

Предусловие: пользователь должен быть
авторизован.

Постусловие: пользователю назначено задание по
утверждению документа.

2.        
Вариант
использования:
переход к следующему шагу процесса.

Актеры: пользователь, администратор.

Краткое описание: процесс утверждения переходит на
следующий шаг.

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

Предусловие: процесс утверждения документа
запущен.

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

3.        
Вариант
использования: утверждение
и комментирование.

Актеры: пользователь, администратор.

Краткое описание: утверждающий утверждает или
отклоняет документ и оставляет комментарий к документу.

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

Предусловие: пользователю назначено задание по
утверждению документа.

Постусловие: процесс утверждения документа
переходит к следующему шагу.

4.        
Вариант
использования:
поиск.

Актеры: пользователь, администратор.

Краткое описание: пользователь осуществляет поиск в
системе.

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

Предусловие: пользователь авторизован.

5.        
Вариант
использования:
загрузка документа.

Актеры: пользователь, администратор.

Краткое описание: пользователь загружает в систему
документ.

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

Предусловие: пользователь авторизован в системе.

Постусловие: файл загружается в систему.

6.        
Вариант
использования:
выгрузка документа.

Актеры: пользователь, администратор.

Краткое описание: пользователь выгружает документ на
локальный компьютер.

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

Предусловие: документ загружен на сервер.

7.        
Вариант
использования:
получение списка документов.

Актеры: пользователь, администратор.

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

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

Предусловие: пользователь должен быть
авторизован.

8.        
Вариант
использования:
прекращение процесса.

Актеры: администратор.

Краткое описание: администратор останавливает процесс
утверждения, связанный с документом.

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

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

9.        
Вариант
использования:
получение списка процессов.

Актеры: администратор.

Краткое описание: администратор получает список всех
процессов.

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

10.     
Вариант
использования:
добавление пользователей.

Актеры: администратор.

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

Полное описание: администратор системы имеет
возможность добавлять в систему пользователей. При этом учетные записи
пользователей должны быть существовать в списке пользователей службы Active
Directory.

Предусловие: пользователи с указанными именами
существуют в Active Directory.

Постусловие: пользователи добавлены в систему.

11.     
Вариант
использования:
удаление пользователей.

Актеры: администратор.

Краткое описание: администратор удаляет пользователей
из системы.

Полное описание: администратор системы имеет
возможность удалять из системы пользователей. При этом учетные записи
пользователей из списка пользователей службы Active Directory не удаляются.

Постусловие: пользователи удалены из системы.

12.     
Вариант
использования:
назначение разрешений.

Актеры: администратор.

Краткое описание: администратор назначает права
пользователям.

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

1.10   
Диаграммы
деятельности

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

1.11   
Модель классов
предметной области

Модель классов
предметной области описывает статическую структуру системы: объекты и отношения
между ними, атрибуты и операции для каждого класса объектов. Модель классов
(приложение 6), представленная в виде концептуальной диаграммы классов,
описывает основные сущности предметной области.

Рассмотрим
подробнее сущности:

1.        
«Пользователь» –
лицо, которое имеет доступ к системе:

·         
«Логин» - логин
пользователя;

·         
«Пароль» - пароль
пользователя на доступ к системе;

·         
«Роль в системе»
- группа безопасности, к которой пользователь относится в системе;

2.        
«Процесс
согласования» - процесс утверждения документа, который инициируется
пользователем:

·         
«Дата начала» -
дата создания процесса;

·         
«Дата изменения»
- дата последний изменений, внесенных в процесс;

3.        
«Статус процесса»
- статус процесса;

4.        
«Рецензия и
комментарий» - рецензия и комментарий, оставляемые пользователем документу;

5.        
«Документ» -
файл, требующий согласования:

·         
«Название» -
название документа, данное ему при загрузке в репозитарий;

·         
«Дата создания» -
дата загрузки документа в репозитарий;

·         
«Номер текущей
версии» - номер версия документа, которая отображается в качестве него самого;

6.        
«Версия
документа» - предыдущие версии документа, хранящиеся в репозитарии;

·         
«Примечание» -
примечание, вводимое пользователем при создании новой версии документа;

·         
«Дата создания» -
дата создания версии;

·         
«Дата изменения»
- дата внесения последних изменений в текущую версию документа;

·         
«Номер версии» -
номер версии документа, присваиваемый версии при сохранении в репозитарий.

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

1.12   
Требования к
техническому и программному обеспечению

1.12.1           
Требования к
техническому обеспечению

В качестве основного сервера и сервера БД
должны использоваться компьютеры с характеристиками не ниже следующих:

·         
процессор Intel или AMD – 2000 МГц;

·         
объём оперативной
памяти – 1024 Мб;

·         
объём свободного
места на HDD - 1 Гб;

·         
доступ к
локальной сети.

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

·         
процессор Intel или AMD с тактовой частотой 500 МГц;

·         
объём оперативной
памяти – 128 Мб;

·         
объём свободного
места на HDD – 10 Мб;

·         
доступ к локальной
сети.

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

1.12.2           
Требования к
программному обеспечению

Требования к программному обеспечению
на сервере следующие:

·         
операционная
система MS Windows 2003 Server;

·         
СУБД MS SQL Server 2005;

·         
Internet
Information Services 6.0 или выше;

·         
MOSS
2007;

·         
поддержка ASP .Net.

Требования к
программному обеспечению на клиенте:

·         
операционная
система: семейство MS Windows 98/2000/XP/Vista.

·         
браузер,
поддерживаемый операционной системой (Internet Explorer 6.x и выше, Firefox 2.x
и выше, Opera 7 и выше, Safari 1.x и выше, Camino 1.x и выше).

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

1.13   
Требования к
интерфейсам информационной системы

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

·         
выдержанная в спокойных
тонах цветовая гамма;

·         
простой и
очевидный порядок выполнение действий;

·         
удобная
навигация;

·         
эргономичное
расположение полей ввода и элементов управления.

Интерфейсы системы должны обеспечивать выполнение
следующих операций:

·         
рецензирование и
комментирование – должен осуществляться ввод пользователем рецензии и
комментария к документу;

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

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

·         
редактирование
процессов – редактирование должно обеспечить удаление и остановку процессов;

·         
редактирование
разрешений пользователей – редактирование должно обеспечить назначение пользователям
прав;

·         
загрузка
документа – окно загрузки документа и оставления комментария к версии
документа;

·         
поиск в системе –
должно позволять задание критерия поиска и области произведения поиска.

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

1.14    Расчет надежности системы

Рассмотрим модель
надежности архитектуры системы. Система состоит из следующих компонентов:
клиентских машин, Web-сервера и сервера БД. В качестве еще одного компонента
будем рассматривать локальную сеть.

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

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

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

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

Определим
вероятности R_i безотказной работы модулей N_i. Для этого
проведем серию испытаний модуля и, подсчитав количество успешных запусков m_i
и количество испытаний n_i, воспользуемся формулой статистической
вероятности:

                                          (1.1)

Проведем серию из
n_i=50 испытаний для каждого модуля. Результаты испытаний отразим в
гистограммах, причем «0» соответствует сбою, а «1» - успешному завершению
испытания. Итоговые данные о статистической вероятности отразим в таблице.

Рис. 1.1. Гистограмма испытаний для модуля 1 (клиентская
машина)

Рис. 1.2. Гистограмма испытаний для модуля 2 (сервер MOSS 2007)

Рис. 1.3. Гистограмма испытаний для модуля 3 (сервер БД)

Рис. 1.4. Гистограмма испытаний для модуля 4 (локальная сеть)

Построим граф
моделирующий взаимодействие узлов в системе (рис. 1.5).

Рис.1.5. Граф, моделирующий взаимодействие узлов в
системе

·         
«N1» – клиентская
машина;

·         
«N2» – локальная
сеть;

·         
«N3» –
Web-сервер;

·         
«N4» – локальная сеть;

·         
«N5» – сервер БД;

·         
«N6» – локальная сеть;

·         
«N7» – Web-сервер;

·         
«N8» – локальная
сеть;

·         
«N9» – клиентская
машина.

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

Рис.1.6. Марковская модель надежности системы

Построим матрицу
весов получившегося графа (табл. 1.4). Будем считать, что при проявлении ошибки
осуществляется переход в состояние F с вероятностью 1-R_i независимо
от правильности последующей обработки. Если узел сработал корректно, то
осуществляется переход к следующему узлу с вероятностью R_iP_ij,
где P_ij – вероятность перехода из узла P_i в узел P_j.
Переход из выходного состояния в состояние С соответствует корректному
завершению работы и происходит с вероятностью безотказной работы выходного
узла.

Таблица 1.4

Матрица весов марковской модели надежности системы (P)

Обозначим
получившуюся матрицу Р. Надежность всей системы может быть вычислена как
вероятность достижения конечного состояния С. Для этого рассмотрим матрицу Q
(табл. 1.5), которая получена из матрицы P после вычеркивания столбцов и строк,
соответствующих конечным состояниям С и F.

Таблица 1.5

Матрица Q

Для каждого целого
k>0 определим P_k как k-ю степень Р. P_k(i,j) – это
вероятность того, что Марковский процесс за k шагов перейдет из состояния i в
состояние j.

Тогда матрица

                                                       (1.3)

Определяет
вероятности перехода из одного состояния в другое за произвольное число шагов.

Пусть S квадратная
матрица размерности n такая, что

                                                      (1.4)

Положим W = I – Q,
тогда имеем

                                                                (1.5)

Отсюда надежность
системы

                                                                       (1.6)

После расчета
получаем следующую матрицу S (табл. 1.6).

Таблица 1.6

Матрица S

Получаем
надежность системы при выходном состоянии

R = 0,98                                                                             

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

2         
Рабочий проект

2.1     
Общие сведения о
работе системы

Программный
продукт спроектирован в среде Enterprise Architect 7.5 и разработан средствами MS Office SharePoint Designer 2007, MS Visual Studio 2005 и 2008 SP1.

Система использует
в качестве хранилища информации СУБД MS SQL Server 2005. Для корректного функционирования системы необходима
операционная система с установленным web-сервером IIS. Взаимодействие браузера с web-сервером осуществляется
по протоколу HTTP.

2.2     
Функциональное
назначение системы

Система выполняет
следующие функции:

·         
загрузка файла
учебного плана;

·         
загрузка файла
графика учебного процесса;

·         
запуск процесса
утверждения учебного плана;

·         
запуск процесса
утверждения графика учебного процесса;

·         
сбор рецензий и
комментариев от сотрудников-рецензентов;

·         
поиск в системе;

·         
версирование
файлов УП и ГУП.

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

2.3     
Используемые
средства разработки

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

·         
Enterprise
Architect 7.5;

·         
MS SQL
Server 2005;

·         
MS
Office SharePoint Designer 2007;

·         
MS
Visual Studio 2005 и 2008 SP1.

Программный
продукт Enterprise Architect использовался для проектирования системы.
Остальные продукты – инструменты для реализации системы.

2.4     
Установка и
выполнение программного продукта

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

·         
проверить
соответствие требований к техническому и программному обеспечению;

·         
установить MS
Windows Server 2003;

·         
установить MS Windows Service Pack
1;

·         
задать в качестве
роли для компьютера «Контроллер домена»;

·         
произвести
настройку домена;

·         
установить
компоненты Windows: IIS, поддержку ASP .Net, DNS, службы электронной почты;

·         
установить .Net
Framework 3.5;

·         
установить MS SQL
Server 2005 (установку можно произвести как на отдельный компьютер, так и на
текущий);

·         
установить Microsoft Office
SharePoint Server 2007;

·         
указать в
качестве хранилища данных экземпляр SQL-сервера (локальный или отдельный);

·         
произвести
настройки IIS;

·         
произвести настройки Microsoft Office SharePoint Server 2007;

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

·         
добавить
пользователей в список пользователей службы Active Directory.

Если все действия
выполнены правильно, то должна загрузиться главная страница портала. Структура
БД и все данные должны сохраняться в виде резервной копии.

2.4.1  
Резервное
копирование базы данных

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

Для ручного
копирования необходимо:

·         
остановить работу
сервера БД (Management Studio – Registered Servers – select server – Service
Control – Stop - Yes);

·         
открыть место
хранения файла БД и файла протокола (по умолчанию располагается в каталоге с
установленной программой);

·         
скопировать файлы
в каталог с архивами;

·         
воспользоваться
меню Backup соответствующей БД.

Для
автоматического создания резервных копий необходимо настройкой планов
обслуживания SQL Server.

2.5     
Общий алгоритм
работы программного продукта

2.5.1  
Диаграмма
развертывания

Диаграмма
развертывания системы приведена в приложении 7.

На диаграмме
развертывания показано раздельное использование web-сервера с Microsoft SharePoint Server 2007 и сервера БД. Однако web-сервер и сервер БД
могут работать совместно на одном сервере. При этом к такому серверу
применяются повышенные системные требования.

2.5.2  
Физическая
структура проекта

Универсальный
модуль загрузки файлов состоит из модулей, описание которых приведено в таблице
2.1.

Таблица 2.1

Состав
универсального модуля загрузки файлов

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

Таблица 2.2

Классы
динамической библиотеки

Таблица 2.3

Функции
динамической библиотеки

Для использования
модуля необходимо добавить в проект динамическую библиотеку, создать экземпляр
класса DocLibHelper и использовать функцию TryToUpload().

2.5.3  
Структура
хранилища данных

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

·         
директория
«Кафедра АСОИУ – Проекты УП»;

·         
директория «Кафедра
АСОИУ – Утвержденные УП»;

·         
директория «Кафедра
ИБ – Проекты УП»;

·         
директория «Кафедра
ИБ – Утвержденные УП»;

·         
директория «Деканат
ИИТиК – Проекты УП»;

·         
директория «Учебный
отдел – Проекты УП»;

·         
директория «Учебный
отдел – Утвержденные УП»;

·         
директория «Проректор
по УМР – На подпись»;

·         
директория «Ректор
– На подпись».

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

·         
директория «Деканат
ИИТиК – Проекты ГУП»;

·         
директория «Деканат
ИИТиК – Утвержденные ГУП»;

·         
директория
«Кафедра ИБ – Проекты ГУП»;

·         
директория
«Кафедра АСОИУ – Проекты ГУП»;

·         
директория «Учебный
отдел – Проекты ГУП»;

·         
директория «Учебный
отдел – Утвержденные ГУП»;

·         
директория «Проректор
по УМР – На подпись»;

·         
директория «Ректор
– На подпись».

Рассмотрим назначение каждой папки в
созданной структуре:

·         
«Кафедра –
Проекты УП», «Кафедра – Проекты ГУП» - в эту директорию загружаются
первоначальные версии учебных планов/графиков учебного процесса, рабочий
процесс также стартует отсюда;

·         
«Кафедра –
Утвержденные УП» - в эту директорию перемещаются окончательно утвержденные
учебные планы;

·         
«Деканат –
Проекты УП», «Деканат – Проекты ГУП» - в эту директорию копируются учебные планы/графики
учебного процесса, нуждающиеся в утверждении деканами факультетов и директорами
институтов;

·         
«Учебный отдел –
Проекты УП», «Учебный отдел – Проекты ГУП» - в эту директорию копируются
учебные планы/графики учебного процесса, нуждающиеся в проверке и утверждении
учебным отделом;

·         
«Учебный отдел –
Утвержденные УП», «Учебный отдел – Утвержденные ГУП» - в эту директорию
перемещаются утвержденные учебные планы/графики учебного процесса;

·         
«Проректор по УМР
– На подпись» - в эту директорию копируются учебные планы и графики учебного
процесса, нуждающиеся в утверждении проректором по УМР;

·         
«Ректор – На
подпись» - в эту директорию копируются учебные планы и графики учебного
процесса, нуждающиеся в утверждении ректором.

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

2.6     
Руководство
пользователя

2.6.1  
Описание форм

После перехода по
адресу сервера приложения на экране появляется главная страница (рис. 2.1).

Рис. 2.1. Стартовая страница сайта

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

Рис. 2.2. Структура директорий на сервере

Рис. 2.3. Одна из директорий для хранения файлов УП и
ГУП

Рис. 2.4 Список заданий пользователей

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

Рис. 2.5. Расширенный поиск

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

Рис. 2.6. Панель управления сайтом

2.6.2  
Сообщения системы

При попытке войти
на сайт без авторизации неавторизованный пользователь увидит следующую страницу
(рис. 2.7):

Рис. 2.7. Доступ запрещен

При вводе
неверного логина или пароля пользователь увидит следующую страницу (рис. 2.8):

Рис. 2.8. Неверные имя пользователя/пароль

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

3         
Программа и
методика испытаний

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

·         
загрузка файла УП
из программы «Учебные планы»;

·         
загрузка файла
УП/ГУП с помощью модуля передачи файлов на сервер;

·         
одобрение/отклонение документа сотрудником.

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

3.1     
Пошаговый
алгоритм загрузки файла УП из программы «Учебные планы»

1.        
Открыть папку с
программой «Учебные планы».

2.        
Открыть в
текстовом редакторе файл «Config.cfg».

3.        
Указать в файле
внутреннее имя директории на сервере SharePoint, в которую будет загружен файл документа УП - «DocLib3».

4.        
Сохранить
изменения в файле.

5.        
Запустить
программу «Учебные планы».

6.        
Выбрать опцию
«Открыть»

7.        
Выбрать в
открывшемся окне файл учебного плана и нажать кнопку «Открыть».

8.        
Выбрать опцию
«Загрузить на сервер».

9.        
Ввести название
для учебного плана, указать место для сохранения на жестком диске и нажать
кнопку «Сохранить».

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

3.2     
Пошаговый
алгоритм загрузка файла УП/ГУП с помощью модуля передачи файлов на сервер

1.        
Открыть папку с
модулем загрузки.

2.        
Открыть в
текстовом редакторе файл «Config.cfg».

3.        
Указать в файле
внутреннее имя директории на сервере SharePoint, в которую будет загружен файл документа УП - «DocLib3».

4.        
Сохранить
изменения в файле.

5.        
Запустить модуль
загрузки.

6.        
Выбрать опцию
«Открыть»

7.        
Выбрать в
открывшемся окне файл учебного плана и нажать кнопку «Открыть».

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

3.3     
Пошаговый
алгоритм одобрения документа сотрудником

1.        
Необходимо
авторизироваться на сайте.

2.        
Перейти по ссылке
«Задачи».

3.        
Выбрать щелчком
левой кнопки мыши назначенную Вам задачу.

4.        
Выбрать пункт
«Изменить».

5.        
В появившемся
окне выбрать из выпадающего меню пункт «Одобрить».

6.        
Ввести в
текстовом поле комментарий к документу.

7.        
Нажать кнопку
«Готово».

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

3.4     
Пошаговый
алгоритм отклонения документа сотрудником

1.        
Необходимо
авторизироваться на сайте.

2.        
Перейти по ссылке
«Задачи».

3.        
Выбрать щелчком
левой кнопки мыши назначенную Вам задачу.

4.        
Выбрать пункт
«Изменить».

5.        
В появившемся окне
выбрать из выпадающего меню пункт «Отклонить».

6.        
Ввести в
текстовом поле комментарий к документу.

7.        
Нажать кнопку
«Готово».

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

4         
Экономический
эффект от разработанной системы

4.1     
Технико-экономическое
обоснование проекта

 

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

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

Из таблицы видно, что по всем
показателям автоматизированная обработка сокращает временные затраты.

4.2     
Маркетинговые
исследования

В настоящий момент
существует несколько аналогов системы, которую предлагается разработать, среди
которых находится система планирования проектов Евфрат «Документооборот».
Наиболее серьёзными недостатками данной системы являются:

·  
трудный для
восприятия интерфейс;

·  
невозможность
доработки и настройки силами штатного персонала;

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

Отсюда следует
вывод, что наиболее целесообразным вариантом было бы не использовать
вышеназванную систему, а самостоятельно разработать автоматизированную систему
оптимизации распределения ресурсов с учетом изменения специфики АГТУ.

4.3     
Исходные данные
для расчета экономической эффективности

Исходные
данные для расчета экономической эффективности сведены в табл. 4.2.

 

4.4     
Расчет объема
инвестиций

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

К = М + Э + Т
+ С_АМ,  (4.1)

где

М –
материальные расходы, руб.;

Э – расходы
на электроэнергию, руб.;

Т –
трудозатраты, руб.;

С_АМ –
расходы на амортизацию оборудования, руб.

4.4.1  
Расчет
материальных расходов

При реализации
проекта использовалась информация из сети Интернет. Таким образом, рассчитаем
материальные расходы как стоимость использования сети Интернет:

М = t * И_1Мб * И_Мб,                                                          (4.2)

где

t – период
разработки, мес.;

И_1Мб –
стоимость 1 Мб трафика сети Интернет, руб.;

И_Мб –
потребляемый для разработки трафик в месяц, Мб/мес.;

Подставив
значения, получим: М = 4 * 1,80 * 25 = 180,00 руб.

4.4.2  
Расчет расходов
на электроэнергию

Рассчитаем расходы на электроэнергию
по формуле:

Э = a*k*B_р1*Ч_р1
+ b_Р*k*B_р2*Ч_р2,     (4.3)

где

а – количество энергии, потребляемой
компьютером в час, кВт;

b – количество энергии, необходимой
для освещения в час, кВт;

k – действующий тариф на
электроэнергию, руб/кВт*ч;

В_р1 – число дней,
необходимых для работы на компьютере, дн.;

В_р2 – число дней, в
течение которых происходит потребление энергии за счет освещения, дн;

Ч_р1 – время работы за
компьютером в течение рабочего дня, час;

Ч_р2 – количество часов
использования освещения в течение рабочего дня, час.

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

Э = 0,4*2,70*30*8 + 0,052*2,20*30*4 =
272,93 руб.

За все время разработки

Э = 4*272,93
= 1091,72 руб.

4.4.3   Расчет трудозатрат

Исходя из данных таблицы, рассчитаем
трудозатраты по формуле:

,        (4.4)

где

К – среднее количество рабочих дней в
месяце;

ЭВ_i – время, затрачиваемое
на i-й этап разработки;

З_ВПр – заработная плата
разработчика.

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

Т = (1 + 0,262) * (4500 / 21) *(15+10+15+8+20+5+5+13+5) = 25961,14 руб.

4.4.4   Расчет расходов на амортизацию и
износ (текущий ремонт)

Расходы на амортизацию рассчитываются
по формуле:

,         (4.5)

где

К_б – балансовая стоимость
оборудования;

α, β – норма отчислений на
амортизацию и износ (текущий ремонт) соответственно;

В_р1 – число дней,
необходимых для работы на компьютере, дн.;

Ч₁ –
количество часов работы оборудования;

ПФВР_р – полезный фонд
рабочего времени разработчика за все время разработки.

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

ПФВР_р = Ч_р1 * В_р1,                                                         (4.6)

где

Ч_р1 – время работы за
компьютером в течение рабочего дня, час;

В_р1 – число дней,
необходимых для работы на компьютере, дн.

Амортизация в базовом варианте
составит:

 руб.

Общие инвестиции составят:

К =1091,72+ 25961,14 + 4600,0 = 31652,86 руб.

4.5     
Расчет текущих
затрат

В затраты на эксплуатацию входят
следующие элементы:

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

·          
стоимость
потребляемых энергоресурсов;

·          
расходы на
амортизацию и текущий ремонт оборудования;

·          
расходные
материалы.

Таким образом получаем общие расходы
на эксплуатацию программного продукта.

4.5.1   Расчет заработной платы сотрудников
отдела

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

ЗП_м = (1 + 0,262) * (О* Д/К)*N,     (4.7)

где

О – месячный должностной оклад
обслуживающего персонала, руб.;

Д – количество дней за месяц,
необходимых для решения поставленной задачи, дни;

К – среднее количество рабочих дней в
месяце, дни;

N – количество сотрудников АГТУ,
которые будут использовать данную систему.

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

ЗП_м = (1 + 0,262) *
(5000*24/24)*5 = 31550 руб.

Определим месячную заработную плату
персонала – проектируемый вариант.

ЗП_м = (1 + 0,262) * (7000*14/24)*5
= 25765,83 руб.

Таким образом, ежемесячная экономия
заработной платы составляет 5784,17 рублей.

4.5.2   Расчет потребляемых энергоресурсов

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

Э = a * k * B₁ * Ч₁+ b * k * B₂* Ч₂, (4.8)

где

Э – стоимость потребляемой
электроэнергии в день, руб.;

а – количество энергии, потребляемой
компьютером в час, кВт;

b – количество энергии, необходимой
для освещения в час, кВт;

k – действующий тариф на
электроэнергию, руб/кВт*ч;

В₁ – число дней в месяц,
необходимых для работы на компьютере, дн.;

В₂ – число дней в месяц, в
течение которых происходит потребление энергии за счет освещения, дн;

Ч₁ – время работы
обслуживающего персонала за компьютером в течении рабочего дня, час;

Ч₂ – количество часов
использования освещения в течение рабочего дня, час.

Определим стоимость потребления
энергоресурсов в месяц – базовый вариант:

Э = 0,4*2,70*24*8 + 0,052*2,20*24*8 =
229,32 руб.

Определим стоимость потребления
энергоресурсов в месяц – проектируемый вариант.

Э = 0,4*2,70*24*4 + 0,052*2,20*24*8 =
125,64 руб.

Таким образом, ежемесячная экономия
средств на электроэнергию составит 103,68 рублей.

4.5.3   Расчет расходов на амортизацию и
износ (текущий ремонт)

Расходы на амортизацию рассчитываются
по формуле:

,     (4.9)

где

N – число машин;

К_б – балансовая стоимость
оборудования;

α, β – норма отчислений на
амортизацию и износ (текущий ремонт) соответственно;

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

Ч₁ – время работы
обслуживающего персонала за компьютером в течении рабочего дня, час;

ПФВР – полезный фонд рабочего времени
в год, час.

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

ПФВР = (D_k
– D_вп ) * Р,                                                    (4.10)

где

D_k – количество
календарных дней в году, дн.;

D_вп – количество выходных
дней и праздничных в году, дн.;

Р – продолжительность ежедневной
работы.

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

ПФВР = (360 – 116) * 8 = 2000 час.

Амортизация в базовом варианте
составит:

руб.

Амортизация в проектируемом варианте
составит:

 руб.

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

Ежемесячные эксплуатационные затраты
в базовом варианте составляют:

С₁ = 31550 + 229,32 +
441,6 = 32220,92 руб.

Ежемесячные эксплуатационные затраты
в проектируемом варианте составят:

С₂ = 25765,83 + 125,64 +
128,8 = 26020,27 руб.

Из вышесказанного видно, что данный
проект обеспечивает снижение эксплуатационных затрат ежемесячно на 6200,65
рублей, ежеквартально на 18601,95, ежегодно на 74407,8.

4.6     
Оценка
экономической эффективности проекта

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

Коэффициент дисконтирования r_p
определяется по следующей формуле:

r_p = i + r₀ +
i*r₀,   (4.11)

где

i – объявленный Правительством РФ
темп инфляции на текущий год;

r₀ – номинальная ставка
дисконтирования, определяемая ставкой рефинансирования установленной ЦБ РФ.

Таким образом, коэффициент
дисконтирования составит:

r_p = 0,07 + 0,08 +
0,07*0,08 = 0,1556

Рассчитаем квартальный коэффициент
дисконтирование по формуле:

                                                                  (4.12)

где

r_p – годовая ставка
дисконтирования.

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

Таким образом, денежные потоки будут
соответствовать данным, отраженным в табл. 4.3. Здесь периоды времени –
кварталы.

Для расчета чистой приведенной
стоимости проекта (NPV, Net Present Value) необходимо дисконтировать поток
платежей по проекту, то есть привести экономический эффект в ценах сегодняшнего
дня и учесть инфляционный фактор:

                                  (4.13)

где

D_i – доходы (входные
денежные потоки) i-го периода, руб;

З_i – текущие расходы
(выходные денежные потоки) i-го периода, руб.;

K_o – капитальные вложения,
руб.;

P_i – суммарный денежный
поток (чистый денежный поток) i-го периода, руб.;

r – коэффициент дисконтирования.

На основе данных,
представленных в табл. 4.3, значение NPV составит:

Как видно из
вышеприведенного расчета, NPV проекта больше 0, следовательно, проект не
является убыточным.

Для определения
срока окупаемости воспользуемся следующей формулой:

                                                              (4.14)

где n
такое, что:

    

Или           

Срок
окупаемости составит:

 месяца
= 5 месяцев и 4 дня.

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

Индекс
рентабельности инвестиций рассчитаем по формуле:

       (4.15)

Таким образом,
рентабельность проекта составит:

  

Т.к. индекс
рентабельности PI > 1, то проект является рентабельным.

Рассчитаем внутреннюю норму
доходности проекта. Под внутренней нормой доходности проекта IRR понимают
значение коэффициента дисконтирования (r), при котором NPV проекта равен 0:

,       (4.16)

значение внутренней нормы доходности
было получено средствами Microsoft Excel 2007: IRR = 42
%.

4.7     
Вывод

Приведенный
экономический анализ с использованием показателей текущей стоимости NPV,
внутренней нормы доходности IRR, срока окупаемости PP и рентабельности PI,
показал, что реализация проекта внедрения информационной системы является
выгодной и целесообразной. Показатели экономической эффективности проекта
достигают следующих значений: NPV = 20284,37 рублей, PP = 5 месяцев и 4 дня, PI = 1,47, IRR = 0,42. Помимо этого,
внедряемый программный продукт оказывает социальный эффект, выражающийся в
оперативности доступа к информации и облегчение труда персонала.

5         
ОБЕСПЕЧЕНИЕ
ЭРГОНОМИКИ РАБОЧЕГО МЕСТА

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

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

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

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

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

5.1     
Анализ условий
труда при эксплуатации программного продукта

При эксплуатации
данной автоматизированной системы можно выделить следующие наиболее
существенные факторы условий труда:

·    
санитарно-гигиенические
– освещение естественное и искусственное, температура воздуха, относительная
влажность, скорость движения воздуха, запыленность, шум, тепловые и
электромагнитные излучения;

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

·    
технические –
техническая безопасность оборудования.

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

5.1.1   Электромагнитное излучение

Дисплей
персональной ЭВМ, сконструированный на основе ЭЛТ, является источником
электростатических полей и широкополосных электромагнитных излучений: мягкого
рентгеновского, ультрафиолетового, инфракрасного, видимого, низкочастотного,
сверхнизкочастотного и высокочастотного.

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

Таким образом,
главная опасность исходит от электромагнитных излучений (в диапазоне 20 Гц -
300 МГц) и электростатического заряда, накапливающегося на экране.

5.1.2   Проблемы перегрузки зрения

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

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

5.1.3   Нагрузка на костно-мышечный аппарат

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

5.1.4   Ненормированный уровень шума

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

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

5.1.5   Проблемы, связанные с электро- и
пожаробезопасностью

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

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

5.2     
Разработка
инженерно-технических и организационных мероприятий по обеспечению безопасности
труда

5.2.1  
Обеспечение мер
безопасности по электромагнитным излучениям

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

Монитор должен соответствовать стандарту TCO-95, 99 защиты от воздействия
электрических и магнитных полей, а так же соответствовать санитарным нормам и
правилам по электромагнитному излучению и электростатическому полю приведены в
табл. 5.1.

Таблица 5.1

Допустимые значения параметров неионизирующих
электромагнитных излучений

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

Схемы размещения рабочих мест должны учитывать расстояние между рабочими
столами с дисплеями, которое должно быть не менее 2 м, а расстояние между боковыми поверхностями дисплеев - не менее 1,2 м (рис. 5.1).

5.2.2  
Снижение нагрузки
на глаза

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

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

Монитор, используемый при работе, должен иметь гигиенический сертификат и
маркировку соответствия РосСтандарт. Конструкция монитора должна обеспечивать
возможность фронтального наблюдения экрана путем поворота корпуса в
горизонтальной плоскости вокруг вертикальной оси и в вертикальной плоскости
вокруг горизонтальной с фиксацией в заданном положении. Корпуса монитора и
системного блока должны быть окрашены в матовый светло-серый свет, обеспечивающий
диффузное рассеивание света; коэффициент отражения – 0,42.

Для того чтобы уменьшить нагрузку на зрение человека, надо учитывать
следующие рекомендации. При работе с монитором расстояние от монитора до
пользователя должно быть равно 0,6 – 0,7 м.

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

Документ для ввода данных рекомендуется располагать на расстоянии 0,45 – 0,5 м от глаз оператора, преимущественно слева, при этом угол между экраном дисплея и документом в
горизонтальной плоскости должен составлять 30° – 40°. Угол наклона клавиатуры должен
быть равен 15°.

Экран дисплея, документы и клавиатуру располагают так, чтобы перепад
яркостей поверхностей, зависящий от их расположения относительно источника
света, не превышал 1:10 (рекомендуемое значение 1:3). При номинальных значениях
яркостей изображения на экране 50-100 кд/м² освещенность документа
должна составлять 300-500 лк. Устройства документирования и другие, нечасто
используемые технические средства, рекомендуется располагать справа от
оператора в зоне максимальной досягаемости, а средства связи слева, чтобы
освободить правую руку для записей.

Естественное освещение должно осуществляться через светопроемы,
ориентированные преимущественно на север и северо-восток и обеспечивать
коэффициент естественной освещенности (КЕО) не ниже 1,2% в зонах с устойчивым
снежным покровом и не ниже 1,5% на остальной территории.

Указанные значения КЕО нормируются для зданий, расположенных в III
световом климатическом поясе. Расчет КЕО для других поясов светового климата
проводится по общепринятой методике согласно СНиП "Естественное и
искусственное освещение". Пример расположения: компьютеров представлен на
рис. 5.2.

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

Согласно рекомендациям НИИ гигиены труда и профзаболеваний АМН РФ рабочий
день за компьютером должен быть не более 6 часов, с дополнительными перерывами
по 3 минуты через каждые полчаса, а через 2 часа работы по 15 – 20 минут.

5.2.3   Мероприятия по снижению статических
физических нагрузок

В целях снижения
статических физических нагрузок пульт дисплея следует располагать на столе или
подставке так, чтобы высота клавиатуры пульта по отношению к полу составляла
0,65 – 0,72 м (рис. 5.3). При размещении пульта на стандартном столе высотой 0,75 м необходимо использовать кресло с регулируемой высотой сидения.

Рис. 5.3. Правильная позиция за компьютером

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

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

При работе с
монитором расстояние от монитора до пользователя должно быть равно 0,6 – 0,7 м.

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

В горизонтальной
плоскости угол наблюдения экрана не должен превышать 60°.

Конструкция
клавиатуры должна соответствовать СанПиН 2.2.2.542-96, пункт 3.11. А именно:

·  
исполнение в виде
отдельного устройства с возможностью свободного перемещения;

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

·  
высоту среднего
ряда клавиш не более 30 мм;

·  
расположение
часто используемых клавиш в центре, внизу и справа, редко используемых - вверху
и слева;

·  
минимальный
размер клавиш - 13 мм, оптимальный - 15 мм;

·  
клавиши с
углублением в центре и шагом 19 ± 1 мм;

·  
расстояние между
клавишами не менее 3 мм.

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

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

1. Высота рабочей
поверхности стола должна регулироваться в пределах 0,68 – 0,8 м; при отсутствии такой возможности высота рабочей поверхности стола должна составлять 0,72 – 0,73 м.

2. Размерами
рабочей поверхности стола для мониторов и ПЭВМ следует считать: ширину 0,8, 1,
1,2 и 1,4 м, глубину 0,8 и 1 м при нерегулируемой его высоте, равной 0,72 - 0,73 м.

3. Рабочий стол
должен иметь пространство для ног высотой не менее 0,6 м, шириной - не менее 0,5 м, глубиной на уровне колен - не менее 0,45 м и на уровне вытянутых ног - не менее 0,65 м.

4. Рабочий стул
(кресло) должен быть подъемно – поворотным и регулируемым по высоте и углам
наклона сиденья и спинки, а также – расстоянию спинки от переднего края
сиденья.

Конструкция его
должна обеспечивать:

·  
ширину и глубину
поверхности сиденья не менее 0,4 м;

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

·  
регулировку
расстояния спинки от переднего края сиденья от 0,26 до 0,4 м;

·  
подлокотники не
менее 0,25 м и шириной 50-70 мм;

·  
регулировку
подлокотников по высоте над сиденьем в пределах 0,23 ± 0,03 м и внутреннего расстояния между подлокотниками в пределах 0,35 – 0,5 м.

5. Рабочее место
должно быть оборудовано подставкой для ног, имеющей ширину не менее 0,3 м, глубину не менее 0,4 м, регулировку по высоте в пределах до 0,15 м и по углу наклона опорной поверхности подставки до 20°. Поверхность подставки должна быть
рифленой и иметь по переднему краю бортик высотой 10 мм.

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

Согласно
рекомендациям НИИ гигиены труда и профзаболеваний АМН РФ рабочий день за
компьютером должен быть не более 6 часов, с дополнительными перерывами по 3
минуты через каждые полчаса, а через 2 часа работы по 15-20 минут.

5.2.4   Требования к микроклимату

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

Таблица 5.3

Оптимальные нормы параметров микроклимата

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

5.2.5  
Требования по
предотвращению шумов

Персональные
компьютеры являются источниками шума. Шум возникает вследствие работы
вентиляторов, находящихся в корпусе компьютера, и виброакустических шумов на
верхнем пороге слышимости, производимых строчным трансформатором дисплея. Так
же присутствуют шумы, издаваемые НЖМД, НГМД и НОМД.

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

Чтобы уменьшить
уровень шумов в помещении, используют звукоизолирующие преграды; стенки и
потолки отделывают специальными пористыми плитами, хорошо поглощающими звук.

5.3     
Расчет
необходимой освещенности рабочего места пользователя

Для освещения
помещения с установленными компьютерами используются главным образом
люминесцентные лампы, которые обладают следующими достоинствами: высокой
световой отдачей (до 75 лм/В и более), продолжительным сроком службы (до 10000
часов), малой яркостью освещаемой поверхности.

Наиболее
приемлемыми для помещения являются люминесцентные лампы типа ЛБ (лампы белого
цвета). Светильники, встраиваемые в потолок, должны устанавливаться так, чтобы
их колпаки выступали не более чем на 50 мм от поверхности потолка для уменьшения запыленности. Колпаки светильников изготавливаются из светорассеивающего
материала с коэффициентом пропускания не менее 0,7. Норма освещенности при
общей освещенности 400 лк.

Пусть помещение,
где установлены ЭВМ, имеет:

·         
длину А = 6 м;

·         
ширину В = 5 м;

·         
высоту Н = 3 м.

Подвесной потолок
оборудован светильниками ШОД (двухламповые с люминесцентными лампами ЛБ-40).

Коэффициент
отражения светового потолка от стен Рс = 0.5

Коэффициент
отражения светового потолка от потолка Рп = 0.7

Определим
необходимое число светильников при общей системе освещения.

Высота рабочей
поверхности стола 0,8 м. При этом расстояние от рабочей поверхности до потолка
h = 2,2 м. У светильников ШОД наивыгоднейшее отношение

Y = L/h = 1,4.

Расстояние между
рядами светильников определяется по формуле:

L = Y*h                                  (5.1)

Тогда расстояние
между рядами светильников равно:

L = 1,4*2,2 = 3м                   

Расстояние между
стенами и крайними рядами светильников определяется по формуле:

j = (0,3-0.5)*L                          (5.2)

Расстояние между
стенами и крайними рядами светильников составляет:

j = 0.35*3 =1 м

Индекс (показатель)
помещения при общем освещении Е = 400 Лк рассчитывается по формуле:

                         (5.3)

Индекс (показатель)
помещения при общем освещении Е = 400 Лк равен:

 

Из справочных
данных с учетом i, Рп, Рс и выбранным типом светильника находим коэффициент
использования излучения светового потока h = 0,45.

Номинальный
световой поток лампы ЛБ-40 Фл = 3120 Лм.

Число необходимых
светильников при общей системе освещения определяем по формуле:

                                  (5.4)

где

S
= 30 м - площадь помещения,

Е = 400 Лк – норма
освещенности для помещений с ЭВМ,

Кз = 1,4 –
коэффициент запаса,

Z = 1,1 –
коэффициент неравномерности освещения,

Фс – номинальный
световой поток одного светильника,

h = 0,45 –
коэффициент использования излучения светового потока,

Y = 0,8 –
коэффициент затемнения.

При ширине В = 5 м имеем число рядов n = 2.

Число необходимых
светильников при общей системе освещения равно:

При длине одного
светильника Lсв = 1,33, общая длина определяется по формуле:

N*L                                (5.5)

Общая длина
составляет:

N*L = 4*1,33 = 5,3 м

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

                            (5.6)

Разрывы между
светильниками составляют:

Таким образом, в
помещении длиной А = 6 м, шириной В = 5 м, высотой Н = 3 м для того, чтобы освещенность была равна Е = 400 Лк необходимо установить 8 светильников типа
ШОД.

Светильники
устанавливаются в 2 ряда по 4 светильников в каждом. Расстояние между
светильниками R = 0,25 м.

5.4     
Требования по
электробезопасности

Энергоснабжение
компьютера осуществляется через сеть бытового электропитания с номинальным
напряжением 220 В и частотой 50 Гц. Для обеспечения электробезопасности
персонала применяют защитное заземление, которое подключается к ЭВМ и
вспомогательным устройствам через вилку электропитания. Защитное заземление
используют для того, чтобы не возникало разности потенциалов между компьютером
и периферийными устройствами, раздельно подключенными к электросети, а также
между двумя соседними персональными компьютерами. Это особенно важно в случае
работы в помещении достаточно большого количества пользователей.

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

5.5     
Требования по
пожарной безопасности

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

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

Рабочее помещение
должно быть оснащено углекислотными огнетушителями, расположенными в
легкодоступных местах. (из расчета 1 на 100 м²).

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

5.6     
Мероприятия по
повышению устойчивости функционирования системы

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

·  
для сглаживания
скачков напряжения в сети сетевые фильтры (пилоты);

·  
источники бесперебойного
питания (ИБП).

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

Кроме того, для
повышения надёжности работы сервера, необходимо использовать ИБП.

5.7     
Эргономика
пользовательского интерфейса

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

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

·  
подобрана
оптимальная цветовая палитра оболочки и элементов управления на формах;

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

·  
количество полос
прокрутки сведено к необходимому минимуму.

5.8     
Выводы

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

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

Заключение

Результатом
выполнения работы является автоматизированная система для согласования учебных
планов и графиков учебного процесса в АГТУ. Система выполнена в соответствии с
техническим проектом.

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

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

В ходе разработки
было разработано:

·         
модуль интеграции
в программу «Учебные планы»;

·         
модуль загрузки
файлов УП и ГУП на сервер;

·         
3 рабочих
процесса;

·         
9 экранных форм;

·         
написано более
400 строк кода;

·         
получены навыки
по развертыванию и настройке MOSS
2007.

Интерфейсы
программного обеспечения спроектированы с учетом современных эргономических
требований.

Литература

1.              
Dr.Shahram
Khosravi «Microsoft Sharepoint 2007 Workflow Programming». - Wiley Publishing, 2008
– 621 с.

2.              
Vikram
Kartik «Microsoft SharePoint Designer 2007 Bible». – Wiley Publishing, 2009 –
604 с.

3.              
Mark
E.Gerow «Creating Client Extranets with Sharepoint 2003». – Apress, 2006 – 248 с.

4.              
Microsoft
Press «7 development projects for Microsoft Office Sharepoint Server 2007». –
Microsoft Corporation, 2006 – 214 c.

5.              
О. Пондер, Д.
Иделен «Службы SharePoint: шаг за
шагом». – М:Эком, 2006 – 376 с.

6.              
Троелсен Э. С# и
платформа .Net. Библиотека программиста. – СПб.: Питер, 2004. – 796с.

7.              
Л. Констайн, Л.
Локвуд «Разработка программного обеспечения». – Спб: Питер, 2004 – 592 с.

8.              
Л. Басс, П.
Клементс, Р. Кацман «Архитектура программного обеспечения на практике». 2-е
издание. – Спб: Питер, 2006 – 575 с.

9.              
Фаулер М., Скотт
К. UML в кратком изложении. Применение стандартного языка
объектно-ориентированного моделирования. – М: Мир, 1999 – 368 с.

10.            
К. Нейгел, Б. Ивьен,
Д. Глинн «C# 2005 для профессионалов». – Киев: Диалектика, 2006 – 1376 с.

11.            
Петрова И.Ю.,
Лазуткина Е.А. Организация баз данных: Учебное пособие для спец.
«Автоматизированные системы обработки информации и управления» / Астрахан.гос.
техн. ун-т. – Астрахань: Изд-во АГТУ, 1999.

– 340 с

12.            
С. Орлов.
Технологии разработки программного обеспечения: Учебник. – СПб.: Питер, 2002. –
464 с.

ПРИЛОЖЕНИЕ 1

 

КОНТЕКСТНАЯ ДИАГРАММА

ПРИЛОЖЕНИЕ
2

 

ДИАГРАММА ПОТОКОВ ДАННЫХ

ПРИЛОЖЕНИЕ 3

 

ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

ПРИЛОЖЕНИЕ
4

 

ДИАГРАММА ДЕЯТЕЛЬНОСТИ –
УЧЕБНЫЕ ПЛАНЫ

ПРИЛОЖЕНИЕ
5

 

ДИАГРАММА ДЕЯТЕЛЬНОСТИ –
ГРАФИКИ УЧЕБНЫХ ПРОЦЕССОВ

ПРИЛОЖЕНИЕ
6

 

МОДЕЛЬ КЛАССОВ ПРЕДМЕТНОЙ
ОБЛАСТИ

ПРИЛОЖЕНИЕ
7

 

ДИАГРАММА РАЗВЕРТЫВАНИЯ