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

Размещено на http://www.allbest.ru/

Содержание

• Введение
• 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

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

Название системы	Интегра-ция с пакетом MS Office	Интуитивно понятный интерфейс	Доступ по web	Возможность доработки системы штатным персоналом	Возможность разработки модулей интеграции
Босс «Референт»	-	+	-	-	-
Дело «Предпри-ятие»	-	+	-	-	-
Евфрат «Докумен-тооборот»	+	-	+	-	-

Стоимость систем колеблется в пределах от 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, диаграмма потоков данных - в приложении 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.3 Вероятности безотказной работы компонентов архитектуры системы
Компонент архитектуры	Вероятность безотказной работы
Локальная сеть	0,98
Клиентская машина	0,96
Web-сервер	0,98
Сервер БД	0,98

Построим граф моделирующий взаимодействие узлов в системе (рис. 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)

	N1	N2	N3	N4	N5	N6	N7	N8	N9	C	F
N1	0	0,96	0,00	0,000	0,00	0,00	0,00	0,00	0,00	0,00	0,014
N2	0	0,00	0,98	0,000	0,00	0,00	0,00	0,00	0,00	0,00	0,012
N3	0	0,00	0,00	0,98	0,00	0,00	0,00	0,00	0,00	0,00	0,012
N4	0	0,00	0,00	0,000	0,98	0,00	0,00	0,00	0,00	0,00	0,012
N5	0	0,00	0,00	0,000	0,00	0,98	0,00	0,00	0,00	0,00	0,012
N6	0	0,00	0,00	0,00	0,00	0,00	0,98	0,00	0,00	0,00	0,012
N7	0	0,00	0,00	0,00	0,00	0,00	0,00	0,98	0,00	0,00	0,012
N8	0	0,00	0,00	0,00	0,00	0,00	0,00	0,00	0,98	0,00	0,012
N9	0	0,00	0,00	0,00	0,00	0,00	0,00	0,00	0,00	0,96	0,014
C	0	0,00	0,00	0,000	0,00	0,00	0,00	0,00	0,00	1,00	0,000
F	0	0,00	0,00	0,000	0,00	0,00	0,00	0,00	0,00	0,00	1,000

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

Таблица 1.5

Матрица Q

	N1	N2	N3	N4	N5	N6	N7	N8	N9
N1	0	0,96	0,00	0,00	0,00	0,00	0,00	0,00	0,00
N2	0	0,00	0,98	0,00	0,00	0,00	0,00	0,00	0,00
N3	0	0,00	0,00	0,98	0,00	0,00	0,00	0,00	0,00
N4	0	0,00	0,00	0,00	0,98	0,00	0,00	0,00	0,00
N5	0	0,00	0,00	0,00	0,00	0,98	0,00	0,00	0,00
N6	0	0,00	0,00	0,00	0,00	0,00	0,98	0,00	0,00
N7	0	0,00	0,00	0,00	0,00	0,00	0,00	0,98	0,00
N8	0	0,00	0,00	0,00	0,00	0,00	0,00	0,00	0,96
N9	0	0,00	0,00	0,00	0,00	0,00	0,00	0,00	0,00

Для каждого целого 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

	N1	N2	N3	N4	N5	N6	N7	N8	N9
N1	1	0,96	0,95	0,949	0,920	0,911	0,89	0,87	0,860
N2	0	1,00	0,98	0,968	0,939	0,915	0,903	0,901	0,891
N3	0	0,00	1,00	0,98	0,968	0,921	0,910	0,89	0,860
N4	0	0,00	0,00	1,000	0,98	0,932	0,89	0,905	0,845
N5	0	0,00	0,00	0,000	1,000	0,98	0,921	0,87	0,891
N6	0	0,00	0,00	0,00	0,00	1,000	0,98	0,915	0,860
N7	0	0,00	0,00	0,00	0,00	0,00	1,000	0,98	0,970
N8	0	0,00	0,00	0,00	0,00	0,00	0,00	1,000	0,960
N9	0	0,00	0,00	0,00	0,00	0,00	0,00	0,00	1,000

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

R = 0,98

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