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

1. Устав профсоюза строителей г. Геленджик

2. Инструкция по работе с информационной системой

На выходе системы могут быть получены:

1. Отказ в удовлетворении заявления;

2. Отчет о состоянии дел по заявлению;

3. Результат исполнения заявления.

Механизмами осуществления деятельности системой являются:

1. Информационная система;

2. Профсоюз;

3. Члены профсоюза.

Рассмотрим с помощью методологии IDEF0 данный процесс более подробно (рисунок 2.5)

Рисунок 2.5 - Диаграмма декомпозиции первого уровня

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

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

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

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

Детализируем некоторые процессы приведенной выше диаграммы. Начнем с процесса регистрации на портале, диаграмма декомпозиции в нотации IDEF3 которого показана на рисунке 2.6



Рисунок 2.6 - Диаграмма декомпозиции процесса регистрации в системе

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

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

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

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

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

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

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

Рисунок 2.7 - Диаграмма декомпозиции процесса подачи заявления

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

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

Подписать и отправить. Если работник заполнил и проверил заявление, то он может нажать кнопку «отправить»

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

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

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

3 Проектирование информационной системы профсоюза строителей г. Геленджик

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

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

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

Система управления содержимым (контентом) (англ. Content management system, CMS) -- компьютерная программа или система, используемая для обеспечения и организации совместного процесса создания, редактирования и управления текстовыми и мультимедиа документами (содержимым или контентом). Обычно это содержимое рассматривается как неструктурированные данные предметной задачи в противоположность структурированным данным, обычно находящимися под управлением СУБД [10].

Drupal, Joomla и WordPress -- бесплатные системы управления, на основе которых можно создавать функциональные и легко управляемые сайты без серьезных финансовых затрат. Попробуем провести анализ и сравнить эти системы между собой. Мы выбрали наиболее важные аспекты, которые скорее всего заинтересуют разработчиков, планирующих построить программный продукт на базе cms/cmf решений.

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

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

Критерии:

1. Безопасность -- защита от взлома, стабильность работы проекта.

2. Версии -- наличие обновлений, их регулярность, стабильность и проверенность временем.

3. Наличие документации, в том числе русскоязычной.

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

5. Борьба со спамом -- защита проекта от все возможного спама

6. Интеграция с другими проектами -- java, flash, форум, чат и тд.

7. Визуальный редактор -- минимальный порог вхождения для управления и поддержки данной системы.

8. Работа с изображениями -- встроенные средства для обработки изображений и работы с ними.

9. Шаблоны оформления -- наличие базы дизайнов и тем для проекта

10. Расширенная функциональность (плагины) -- объем и качество существующих наработок ведущих специалистов, расширяющих или изменяющих функциональность проекта.

11. Виджеты/блоки -- возможность проекта выделять отдельные составляющие в блоки и работа с ними.

12. Современные технологии: трекбаки, пинги, XML-RPC, RSS

13. Кодировки -- возможность работы с разными кодировками и наиболее популярной сего дня UTF-8

14. Комментирование -- работа с комментариями, уровни доступа и управляемость данного функционала.

15. Экспорт/импорт данных - управление по токами информации входящей и выходя щей из проекта.

Проведем анализ каждой из CMS по соответствующим пунктам

3.1.1 Drupal

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

Версии. Версии выходят регулярно. Выпущена 6-я версия. Предыдущая 5-я версия по срав нению с 4.7 выглядит хорошим эволюционным этапом. Новые версии подолгу тестируются. Ядро стабильное. Ошибки в востребованных модулях обычно исправляются оперативно.

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

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

Борьба со спамом. Широкий выбор всевозможных решений от механического до аналитического фильтра посетителей.

Интеграция с форумом. Базовый пакет Drupal содержит достаточно функциональный форум, который подойдет для организации небольших сообществ. Для организации больших сообществ он тоже, впрочем, подойдет-- на форуме drupal.org сейчас более 320 000 сообщений.

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

Визуальный редактор. В Drupal можно встроить TinyMCE или FCKEditor. И тот и другой гибко настраиваются. Оба являются мощными средствами. В TinyMCE, например, можно работать с таблицами, добавляя и удаляя строки и столбы и объединяя ячейки, может фильтровать скопированные из Word'а тексты от избыточных тегов.

Работа с изображениями. Поддерживается изменение размеров картинки при за грузке и генерация изображений preview.

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

Расширенная функциональность (плагины). Сейчас в официальном репозитории хранится под тысячу бесплатных модулей. Среди прочих есть решение для электронной коммерции, CRM-система, wiki-движок. Еще отмечу модули Views и CCK, которые дают полное право именоваться CMF, а не CMS. CCK (Content Construction Kit), к примеру, позволяет при по мощи графического интерфейса описывать объекты предметной области в базе данных и сразу же создавать формы для управления ими.

Виджеты/блоки. В Drupal это называется «блоки». Их можно располагать в разных областях страниц в зависимости от возможностей шаблона. В каждой области блоки можно сортировать для управления порядком вывода. Изначально областей пять-- шапка, центральная, левая и правая колонки, подвал. Блоки можно показывать не на всех страницах.

Современные «фишки»: трекбаки, пинги, XML-RPC, RSS. Друпал популярен в мире, поэтому все инновационные решения быстро реализуются. В базовом пакете есть возможность ведения блога по­средствам блогового клиента. Есть модуль, пингующий специальные каталоги Drupal-сайтов.

Кодировки. Drupal работает на UTF-8. Каких-то забытых строковых функций, не работающих с UTF-8 не замечено. Некоторые хостеры по старинке отдают страницы в cp1251, но это легко чинится. Проблемы с MySQL тоже обычно решаются одной строчкой кода.

Комментирование. Комментарии в блогах могут быть и «плоскими» («flat») и древовидными («treaded»). Всё это находится в базовом пакете. Извещения по email делаются внешним модулем.

Экспорт/импорт данных. Для Друпала написано много разных конвертеров, в основном связанных с форумными миграциями. Любые RSS по токи. Экспорта в RDF или CSV, XML и SQL.

3.1.2 Joomla

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

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

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

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

Борьба со спамом. Борьба со спамом в интернете на данный момент ведется только в одном месте-- комментарии к публикациям.

Интеграция с форумом. Вместе с Joomla не поставляется компонента форума, однако на данный момент самым оптимальным вари антом создания встроенного форума является FireBoard и его русская редакция от Adeptus'а. Что же касается интеграций-- они существуют. Самой распространенной является связка Joomla-SMF, под которую есть не одна интеграция, даже коммерческая.

Визуальный редактор. Таковых под нее множество: в основном это портированные и самые распространенные редакторы. Однако самым удобным и хорошим из бесплатных является редактор JCE, разработанный специально для Joomla (а изначально еще для Mambo, тогда он назывался MosCE), способный составить очень хорошую альтернативу плат ному WysiwygPro.

Работа с изображениями. Существует три типа расширений - компонент, модули и мамботы. Причем каждый тип расширений позволяет решать свои типы задач, что позволяет добавлять фактически любой новый функционал не залезая в "ядро". (extensions.joomla.org).

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

Расширенная функциональность (плагины). Их существует несколько видов, есть специальная система установки, позволяющая при помощи xml-файла описывать все действия необходимые для совершения при создании записи о расширении (например, SQL-запросы, копируемые файлы или действия выполняемые сразу после установ­ки, которые нельзя вы полнить автоматически).

Виджеты/блоки. Отсутствует.

Современные «фишки»: трекбаки, пинги, XML-RPC, RSS

Joomla это CMS, и говорить о внедрении таких вещей можно только на уровне сторонних компонентов.

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

Экспорт/импорт данных. Не предусмотрен. Исключительно sql запросами.

3.1.3 Wordpress

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

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

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

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

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

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

Визуальный редактор. Стандартно в WordPress'е используется немного урезанный TinyMCE и простой текстовый редактор (переключение между ними «на лету»). Нужно отметить, что в WordPress'е есть возможность сторонним плагинам добавлять кнопки в редактор. Таким образом можно например получить функции для добавления видео, аудио и т.д.

Работа с изображениями. В WordPress'е вполне удобно можно добавлять картинки в редактор. Автоматически будет сделана миниатюра. То есть расчет на то, что бы с этой задачей справился неопытный пользователь.

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

Расширенная функциональность (плагины). WordPress можно расширить за счет плагинов-- это различные php-скрипты, которые автоматически подключаются к основному «ядру». Таким образом можно не просто добавить нужную функциональность, но и изменить уже существующую. Плагинов для WordPress написано несколько тысяч (только на одном wp-plugins.net-- 2568, но думаю, что целом цифру можно удвоить), поэтому можно найти плагин практически под любые нужды.

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

Современные «фишки»: трекбаки, пинги, XML-RPC, RSS. Трекбаки, пинги поддерживаются уже давно. Причем для их использования не нужно вообще никаких дополнительных действий: все работает на уровне «движка». Что касается XML-RPC, то WordPress поддерживает сразу несколько API, поэтому добавлять/редактировать записи в WordPress можно с многих программ блог-клиентов или он-лайн, например с помощью Google-Docs.

WordPress полностью поддерживает RSS и Atom. Можно подписаться на последние записи блога, определенной рубрики, комментарии или все комментарии. С помощью отдельного плагина можно сделать автоматическую переадресацию RSS-ленты блога на feedburner.com.

Кодировки. В самом WordPress'е есть возможность установить любую кодировку. Главное, что бы кодировка базы данных совпадала с кодировкой блога. Правда, начиная с версии 2.1 WordPress должен работать в UTF-8. Это напрямую связано с использованием AJAX. Поэтому для русскоязычных пользователей основная проблема состоит только в том, что на серверах часто стоит CP1251. Сейчас можно довольно уверенно сказать, что особых проблем с кодировками в WordPress'е нет.

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

Экспорт/импорт данных. WordPress позволяет экспортировать записи и комментарии блога в XML-файл. Можно экспортировать записи отдельного автора. Для им порта записей в WordPress можно воспользоваться 9 способами. Так же в RSS и свой XML-формат.

3.1.4 Оценка аналогов и прототипов с помощью метода анализа иерархий

Рассмотрим процесс оценки прототипов с более формальной и точной математической точки зрения. Проведем их анализ с помощью метода анализа иерархий (МАИ).

Ограничимся семью наиболее важными критериями:

1. Безопасность

2. Русская документация

3. Интеграция с форумом

4. Шаблоны оформления

5. Расширенная функциональность (плагины)

6. Виджеты/блоки

7. Экспорт/импорт данных

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

Таблица 3.1 - Относительные веса критериев

	Безопасность	Русская документация	Интеграция с форумом	Шаблоны оформления	Плагины	Виджеты	Экспорт/импорт данных	Оценки компонент собственного вектора	Нормализованные оценки вектора приори-тета	л max
Интеграция с форумом	1	1/8	1/7	1/5	1/3	1/2	1/5	0,3573	0,0309	0,9582
Плагины	8	1	1	2	3	4	2	3,0000	0,2595	0,9624
Виджеты	7	1	1	2	2	3	2	2,5714	0,2224	0,8845
Шаблоны оформления	5	1/2	1/2	1	2	3	1	1,8571	0,1607	1,1300
	Безопасность	Русская документация	Интеграция с форумом	Шаблоны оформления	Плагины	Виджеты	Экспорт/импорт данных	Оценки компонент собственного вектора	Нормализованные оценки вектора приори-тета	л max
Русская документация	3	1/3	1/2	1/2	1	2	1/3	1,0952	0,0947	1,1212
Безопасность	2	1/4	1/3	1/3	1/2	1	1/3	0,6786	0,0587	0,9686
Экспорт/импорт данных	5	1/2	1/2	1	3	3	1	2,0000	0,1730	1,1880
ИТОГО:	31,0000	3,7083	3,9762	7,0333	11,8333	16,5000	6,8667	11,5597		7,2128

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

Таблица 3.2 - Сравнение критериев

Критерии		Нормализованные оценки вектора приоритета
Интеграция с форумом	__	0,0309
Плагины	___________________	0,2595
Виджеты	__________________	0,2224
Шаблоны оформления	_____________	0,1607
Русская документация	________	0,0947
Безопасность	_____	0,0587
Экспорт/импорт данных	______________	0,1730

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

Определим индекс согласованности (ИС), который дает информацию о степени непротиворечивости суждений при составлении матрицы попарных сравнений критериев.

ИС = (л _max - n)/(n - 1),

где л max - максимальное собственное значение матрицы (л _max ? n),

n-размерность матрицы

ИС = (7,2128- 7)/ (7-1) = 0,0354

Разделив ИС на число, соответствующее случайной согласованности матрицы шестого порядка, равного 1,32, получим отношение согласованности (ОС). Величина ОС должна быть порядка 10% или менее, чтобы быть приемлемой. В некоторых случаях допускается ОС до 20%, но не более, иначе надо проверить свои суждения.

ОС = 0,0354 / 1,32 = 2,68% < 10%, т.е. пересматривать свои суждения нет нужды.

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

Таблица 3.3 - Сравнительные оценки систем по критерию «Интеграция с форумом»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	1/2	1/2	0,6667	0,2000	1
Joomla	2	1	1	1,3333	0,4000	1
Wordpress	2	1	1	1,3333	0,4000	1
ИТОГО:	5,0000	2,5000	2,5000	3,3333		3

Относительная согласованность матрицы равна 1,08%, т.е. <10%.

Таблица 3.4 - Сравнительные оценки систем по критерию «Плагины»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	5	5	3,6667	0,7143	1
Joomla	1/5	1	1	0,7333	0,1429	1
Wordpress	1/5	1	1	0,7333	0,1429	1
ИТОГО:	1,4000	7,0000	7,0000	5,1333		3

Относительная согласованность матрицы равна 1,28%, т.е. <10%.

Таблица 3.5 - Сравнительные оценки систем по критерию «Виджеты»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	3	2	2,0000	0,5538	1,01538
Joomla	1/3	1	1	0,7778	0,2154	1,07692
Wordpress	1/2	1	1	0,8333	0,2308	0,92307
ИТОГО:	1,8333	5,0000	4,0000	3,6111		3,01538

Относительная согласованность матрицы равна 0,32%, т.е. <10%.

Таблица 3.6 - Сравнительные оценки систем по критерию «Шаблоны оформления»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	1	1	1,0000	0,3333	1
Joomla	1	1	1	1,0000	0,3333	1
Wordpress	1	1	1	1,0000	0,3333	1
ИТОГО:	3,0000	3,0000	3,0000	3,0000		3

Относительная согласованность матрицы равна 0,01 %, т.е. <10%.

Таблица 3.7 - Сравнительные оценки систем по критерию «Русская документация»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	3	2	2,0000	0,5294	0,97058
Joomla	1/3	1	1/2	0,6111	0,1618	0,97058
Wordpress	1/2	2	1	1,1667	0,3088	1,08088
ИТОГО:	1,8333	6,0000	3,5000	3,7778		3,02205

Относительная согласованность матрицы равна 2,32%, т.е. <10%.

Таблица 3.8 - Сравнительные оценки систем по критерию «Безопасность»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	2	1/4	1,0833	0,1924	1,05814
Joomla	1/2	1	1/7	0,5476	0,0973	0,97251
Wordpress	4	7	1	4,0000	0,7104	0,98942
ИТОГО:	5,5000	10,000	1,3929	5,6310		3,02008

Относительная согласованность матрицы равна 1,56%, т.е. <10%.

Таблица 3.9 - Сравнительные оценки систем по критерию «Импорт-экспорт данных»

	Drupal	joomla	WordPress	Оценки компонент собственного вектора	Нормализованные оценки вектора приоритета	л max
Drupal	1	2	1/4	1,0833	0,1818	1
Joomla	1/2	1	1/8	0,5417	0,0909	1
Wordpress	4	8	1	4,3333	0,7273	1
ИТОГО:	5,5000	11,000	1,3750	5,9583		3

Относительная согласованность матрицы равна 0%, т.е. <10%.

Результаты оценок информационных систем по всем критериям сведены в таблицу 3.10.

Таблица 3.10 - Сравнительные оценки систем по всем критериям

Альтернативы	Безопасность	Русская документация	Интеграция с форумом	Шаблоны оформления	Плагины	Виджеты	Экспорт/импорт данных	Нормализованные оценки вектора приоритета
	Численное значение вектора приоритета
Drupal	0,2000	0,7143	0,5538	0,3333	0,5294	0,1924	0,1818	0,46114674
Joomla	0,4000	0,1429	0,2154	0,3333	0,1618	0,0973	0,0909	0,18766849
Wordpress	0,4000	0,1429	0,2308	0,3333	0,3088	0,7104	0,7273	0,35110052

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

Таблица 3.11 - Сравнение альтернатив

Наименование информационной системы		Глобальные приоритеты
Drupal	___________________________	0,46114674
Joomla	___________	0,18766849
Wordpress	_____________________	0,35110052

Таким образом, аналогом и прототипом информационной системы профсоюза строителей г. Геленджик можно считать CMS Drupal.

3.2 Формирование требований к объекту проектирования

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

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

· Модуль личного кабинета;

· Модуль оформления электронных документов;

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

· Модуль хранения данных;

· Модуль работы с системой через Интернет;

· Модуль безопасности.

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

· Автоматизированное формирование электронных документов по введенным работниками данным;

· Возможность отправки документа без распечатки в виде твердой копии;

· Формирование отчета о текущем состоянии заявления;

· Экспорт данных в открытые форматы;

· Подготовка и выдача результатов обработки заявлений.

3.3 Выбор архитектуры информационной системы профсоюза строителей г. Геленджик

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

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы (рисунок 3.1) [11]:

· системы на основе архитектуры файл-сервер;

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

· системы на основе многоуровневой архитектуры;

· системы на основе технологии интернет/интранет.

Рисунок 3.1 - Деление информационных систем по способу организации

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

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

· системы на основе архитектуры файл-сервер;

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

· системы на основе многоуровневой архитектуры.

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

Таблица 3.12 - Типовые функциональные компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic(логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
Обозна-чение	Наименование	Характеристика
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

Объектами разработки в файл-серверном приложении являются компоненты приложения, определяющие логику диалога PL, а также логики обработки BL и управления данными DL. Разработанное приложение реализуется либо в виде законченного загрузочного модуля, либо в виде специального кода для интерпретации.

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

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

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

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

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

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней:

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

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

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

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

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

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

Интернет/Интранет-технологии

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

Благодаря интеграции Интернет/Интранет-технологии и архитектуры клиент-сервер процесс внедрения и сопровождения корпоративной информационной системы существенно упрощается при сохранении достаточно высокой эффективности и простоты совместного использования информации

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

Архитектура информационной системы показана на рисунке 3.2.

Рисунок 3.2 - Архитектура информационной системы

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

3.4 Проектирование структуры баз данных

Методология IDEF 1.x. IDEF1X [12] является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу "AS IS", тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1. Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы (скажем с помощью метода IDEF1) и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.

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

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

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

· задание первичных и альтернативных ключей;

· определение атрибутов сущностей;

· приведение модели к требуемому уровню нормальной формы;

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

· задание триггеров, процедур и ограничений;

· генерация базы данных.

Логическая структура базы показана на рисунке 3.5.

Рисунок 3.3 - Логическая структура БД

Структура базы данных состоит из следующих сущностей:

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

· Id работника - первичный ключ;

· Фамилия;

· Имя;

· Отчество;

· Дата рождения;

· Пол;

· Семейное положение;

· Количество детей;

· Место работы - внешний ключ в справочник подразделений;

· Должность.

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

· id (первичный ключ);

· Название;

· Подчинение - в чьем ведомстве находится;

· Тип - производственное, обслуживающее и т.д.;

· Начальник подразделения;

· Контактная информация.

Заявление. Сущность, экземпляры которой привязываются к конкретном работникам:

· № заявления (первичный ключ);

· Работник - внешний ключ в таблицу;

· Дата подачи;

· Тип;

· Содержание;

· Состояние обслуживания - внешний ключ в таблицу.

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

· ID (первичный ключ);

· Логин;

· Пароль;

· Работник - внешний ключ в таблицу;

· Настройки кабинета - конфигурационный файл;

Статус обслуживания. Сущность, описывающая состояния заявок:

· Номер заявления (внешний ключ);

· Регистрационный номер;

· Местонахождение;

· Вердикт председателя профсоюза;

· Результат исполнения заявления.

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

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

Рисунок 3.4 - Физическая модель БД

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

4 Реализация информационной системы

4.1 Выбор используемых средств реализации

4.1.1 Операционная система

1) SUSE Linux Enterprise Server - масштабируемая и высокопроизводительная основа для защищенного функционирования вычислительных систем масштаба предприятия. Благодаря широким функциональным возможностям этот продукт компании Novell® отвечает требованиям современных сетей и запросам пользователей. Развертывание, настройка и обслуживание продукта SUSE Linux Enterprise Server 9 в масштабах предприятия не вызывает затруднений. SLES поддерживает широкий спектр аппаратных платформ и сертифицирован ведущими мировыми разработчиками ПО, например, корпорацией Oracle. Благодаря уникальным и открытым средствам управления, можно легко устанавливать, распространять, конфигурировать, защищать и обновлять Linux-серверы в любой части корпоративной сети.

2) Mac OS X Server - операционная система от Apple, построенная на основе операционной системы Mac OS X, и объединяющая в себе мощь UNIX-сервера с простотой в использовании Макинтош. Ее устойчивый фундамент предоставляет вам все преимущества, присущие основанной на UNIX операционной системе, такие как, например, вытесняющая многозадачность, поддержка симметричной многопроцессорности, защищенная память, а также поддержка самых разных сетевых технологий и стандартов обеспечения безопасности. Средства удаленного администрирования позволяют легко производить безопасный мониторинг и администрирование ваших служб из любого места локальной сети или через Интернет. Для максимизации времени бесперебойной работы сервера Mac OS X Server предлагает системы защиты от сбоев, автоматически обнаруживающие и нейтрализующие сбои в системных службах. Основанная на ядре с открытым кодом и доказавших себя в деле индустриальных стандартах, таких как сетевые BSD технологии, операционная система эффективно действует и в многоплатформенном мире. Отличается высокой надежностью и простотой в использовании.

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

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

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

1. Надежность - так как планируется интернет-архитектура, то требования к надежности ОС высоки: бесперебойная работа 24 часа 7 дней в неделю с защитой от вредоносных воздействий

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

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

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

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

Таблица 4.1 - Сравнительная оценка серверных операционных систем

Параметры сравнения/ оценка	Важность параметра	SUSE Linux Enterprise Server	Mac OS X Server	Microsoft Windows Server
Надежность	0,35	5	5	4
Удобство использования	0,25	3	4	5
Стоимость	0,15	4	3	4
Доступное ПО	0,25	4	4	5
Общая оценка		4,1	4,2	4,5

Вывод: Таким образом проведенные оценки показывают, что нам для решаемой задачи наиболее подходит серверная операционная система Microsoft Windows Server.

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

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

В качестве СУБД, из которых будет производиться выбор для использования их в ИС, выбраны следующие: