РАСШИРЕНИЕ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ СПИСКОВ И БИБЛИОТЕК ДОКУМЕНТОВ ПОРТАЛА SHAREPOINT 2010 ПУТЕМ РАЗРАБОТКИ ДОПОЛНЕНИЙ В СРЕДЕ VISUAL STUDIO

Романов Д.Ю. 1

1Набережночелнинский институт КФУ

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

Выпускная квалификационная работа на тему «Расширение функциональных возможностей списков и библиотек документов портала SharePoint 2010 путем разработки дополнений в среде Visual Studio» содержит 80 страниц пояснительной записки, рисунков – 25, таблиц – 10, использованных источников – 13.

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

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

Изучение SharePoint со стороны его функциональности;
Изучение среды Visual Studio 2010, язык программирования c#;
Постановка задачи на улучшение функциональности;
Реализация поставленных задач.

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

Оглавление

Аннотация 4

Введение 7

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 8

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

1.1.1. Описание портала предприятия 10

1.1.2. Библиотеки документов портала 11

1.1.3. Уровни разрешений, группы и права доступа 13

1.1.4. Установленные решения и параметры семейства сайтов 16

1.2. Постановка задачи 17

1.3. Обзор аналогов решений 19

1.4. Необходимость разработки и внедрения решений 20

1.5. Средства реализации поставленных задач 20

1.5.1. MS SharePoint Designer 2010 21

1.5.2. MS InfoPath Designer 2010 22

1.5.3. MS Visual Studio 2010 23

1.5. Выбор среды реализации поставленных задач 24

1.6. Выводы по главе 24

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 23

2.1. Функциональное моделирование предметной области с использованием методологии IDEF1X 26

2.2. Описание модели разрабатываемого решения с использованием методологии UML 28

2.3. Логическая модель данных 36

2.4. Физическая модель данных 37

2.5. Выводы по главе 38

3. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ 45

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

3.2. Типы проектов SharePoint в Visual Studio 2010 41

3.3. SharePoint Event Receiver 42

3.4. Физическая структура проекта решения 45

3.5. Описание программных модулей 51

3.5.1. Решение DocLibRestrict 51

3.5.2. Решение LogListRec 53

3.6. Выводы по главе 54

4. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ 56

4.1. Особенности корпоративных сетей 56

4.2. Стандарты информационной безопасности 56

4.3. Сервисы безопасности 58

4.3.1. Идентификация и аутентификация. 58

4.3.2. Разграничение доступа. 60

4.3.3. Протоколирование/аудит. 61

4.3.4. Экранирование. 62

4.3.5. Туннелирование. 63

4.3.6. Контроль защищенности 63

4.3.7. Обнаружение отказов и оперативное восстановление 64

4.4. Политики безопасности 64

4.5. Расчет уровня уязвимости корпоративной сети «ПАО КАМАЗ» 65

4.6. Выводы по главе 68

5. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ СИСТЕМЫ 64

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

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

5.3. Расчет объема инвестиций 71

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

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

5.3.3. Расчет расходов на амортизацию и износ 72

5.4. Расчет текущих затрат 73

5.4.1. Расчет заработной платы администратора портала 73

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

5.4.3. Расчет расходов на амортизацию и износ 75

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

5.6. Выводы по главе 78

Заключение 79

Список использованных источников 80

Введение

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

Одним из вариантов реализации подсистемы КИС является корпоративный портал. Корпоративный портал – это, в общем случае, веб-интерфейс для доступа сотрудника к корпоративным данным и приложениям. Альтернативная точка зрения состоит в том, что корпоративный портал – это лишь видимая для пользователя часть интернета [1]. Корпоративный портал становится первичным интерфейсом для взаимодействия пользователя и компании. Поэтому выбрана тема диплома, тесно связанная с электронной коммерцией, а именно разработкой функциональных возможностей интернет портала предприятия, с установленной платформой Microsoft SharePoint Foundation 2010.

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

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

Кроме того, службы SharePoint Foundation 2010 предоставляют платформу для создания легко настраиваемых и масштабируемых сетевых бизнес-приложений в соответствии с меняющимися и растущими потребностями компании. Надежные средства администрирования, предназначенные для управления хранилищем и сетевой инфраструктурой, позволяют эффективно внедрять высокопроизводительные среды совместной работы и управлять ими [2].

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

1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ

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

Как было сказано ранее, корпоративный портал (в общем случае) - это веб-интерфейс для доступа сотрудника к корпоративным данным и приложениям. Помимо доступа к данным и приложениям, портал SharePoint предоставляет возможность вести версии этих документов и приложений, контролировать их загрузку-выгрузку, управлять рабочими процессами, устанавливать статус и другие атрибуты документа, необходимые для документов конкретного типа на предприятии. Именно для этой цели и был создан портал предприятия «ПАО КАМАЗ». Далее будет описан корпоративный портал данного предприятия, обоснована цель и необходимость портала, показаны все возможности и установленные решения.

1.1.1. Описание портала предприятия

Корпоративный портал предприятия «ПАО КАМАЗ» установлен на платформе MS SharePoint Server 2010; система – Windows server 2008 R2. Портал имеет URL адрес «https://tcc.kamaz.ru» и установлен на сервере «s171».

Домашняя (главная) страница расположена по адресу «https://tcc.kamaz.ru/SitePages/Домашняя.aspx» и служит только для размещения объявлений и новостей портала, а также для перехода на сайты поставщиков. Домашняя (главная) страница и страница поставщиков (на примере ЗАО ПК «Технотрон») показаны в приложении 1 и 2.

Определим, кто такие поставщики для «ПАО КАМАЗ». Согласно определению, поставщик - это любое юридическое (организация, предприятие, учреждение) или физическое лицо, поставляющие товары или услуги заказчикам, которые, в свою очередь, заинтересованы в выполнении исполнителем работ [3]. В текущей теме, заказчиком выступает ПАО «КАМАЗ», а в качестве товара или услуги – конструкторская документация (КД). Каждому поставщику на портале присвоен свой личный сайт с одноименным названием, доступ к которому имеют только администраторы семейства сайтов и лица, непосредственно связанные с работой КД – поставщики и участники. Участниками являются сотрудники отдела комплектующих изделий ПАО «КАМАЗ».

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

1.1.2. Библиотеки документов портала

На каждом сайте поставщиков имеется четыре библиотеки документов:

Входящая КД КАМАЗ;
Исходящая КД поставщиков;
Технические требования, ТЗ;
Заявки.

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

Библиотека «Технические требования, ТЗ» необходима для загрузки технической документации участниками и поставщиками.

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

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

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

Название – служит для записи дополнительной информацию об имени загруженного документа. Тип столбца – однострочный текст.
Задача – данный столбец необходим для установки текущей задачи по документу или ТЗ. Тип столбца – выбор. На выбор предоставляется пять вариантов установки текущей задачи. Устанавливать и изменять задачу имеют право только участники портала.
Статус – столбец для установки текущего состояния по работе с документом. Тип столбца – выбор. Вариантов установки статуса – восемь. Статус могут изменять и поставщики, и участники портала.
Комментарий - служит для записи заметок и рекомендаций по текущему документу. Тип столбца – многострочный текст.
№ извещения;
№ заявки;
№ ревизии (изменения);
Проект;
Кем создано;
Кем изменено;
Кем извлечено.

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

Столбцы «Кем создано», «Кем изменено» и «Кем извлечено» являются стандартными для списков SharePoint и содержат информацию соответственно о том, кто создал, последним изменил или извлек текущий документ. В данные столбцы записываются полные фамилия, имя и отчество пользователя, работающего с документом. Тип столбцов – пользователь или группа.

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

1.1.3. Уровни разрешений, группы и права доступа

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

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

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

Виды прав доступа

По умолчанию в SharePoint определяются следующие виды прав доступа:

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

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

Для портала «ПАО КАМАЗ» созданы дополнительные уровни разрешений с индивидуальными правами доступа:

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

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

На самом верхнем уровне - к набору сайтов (сайтовую коллекцию), ферму SharePoint – что доступно только администраторам фермы (сервера);
К сайту, подсайту;
К отдельной функции на сайте;
К библиотеке документов или списку;
К папке в библиотеке документов или в списке;
К отдельному файлу.

Группы доступа

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

Для управления правами доступа пользователей портала «ПАО КАМАЗ» было создано пять групп:

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

SharePoint также предоставляет возможности установки уровня разрешений для определенных пользователей портала. Одним из пользователей с индивидуальным разрешением является «Системная учетная запись» с уровнем разрешений «Полный доступ». Данный пользователь является администратором и фермы (сервера) и коллекции сайтов, подсайтов.

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

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

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

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

Так, на портале «ПАО КАМАЗ», сайты поставщиков наследуют лишь часть разрешений родительского сайта. Сайты поставщиков имеют уникальные разрешения для пользователя-поставщика, который определен на каждом сайте и является единоличным пользователем с уникальным уровнем доступа типа «Поставщик-участник». Остальные пользователи данного сайта получают разрешения через группы родительского сайта:

TCC – владельцы;
TCC – посетители;
TCC – участники;
Средства просмотра.

Уникальные разрешения для сайта (на примере сайта-поставщика ЗАО ПК «Технотрон») показаны на рисунке 2.

Рис 2. Уникальные разрешения для сайта.

1.1.4. Установленные решения и параметры семейства сайтов

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

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

На портале «ПАО КАМАЗ» также установлены дополнительные решения. Установленные и активированные решения на домашней (главной) странице показаны в приложении 3.

Все решения, кроме решений «Teamcenter community collaboration», являются стандартными решениями платформы SharePoint 2010, разработанные корпорацией Microsoft для расширения стандартных возможностей портала. Это такие решения, которые позволяют создавать wiki страницы, списки для групп с расширенными возможностями, шаблоны списков. Также данные решения предоставляют возможности навигации и фильтрации метаданных, синхронизацию внешних списков и почты, организатор контента и пр.

Решения «Teamcenter community collaboration» являются разработкой компании Siemens PLM Software, созданные для расширения возможностей совместной работы SharePoint 2010. Данные решения предоставляют инструменты социальных сетей, таких как вики, блоги, профили, опросы и многое другое, повышая производительность за счет координации повседневной деятельности. Siemens PLM Software интегрировал возможности среды Teamcenter в SharePoint 2010, что значительно расширяет удобство работы с их продуктом.

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

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

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

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

Реализация ограничений на изменение полей для участников портала. Реализовать ограничение на изменения поля статус: разрешить устанавливать значение поля только на «требуется принять решение».
Реализация ограничений на изменение полей для поставщиков портала. Ограничить изменение поля статус: разрешить изменять значение данного поля, только если это значение установлено на «требуется принять решение», т.е. поставщик имеет право изменять поле статус только один раз. Также необходимо ограничить изменение полей «задача» и «№ заявки» для поставщиков; установить запрет на изменение данных полей. Изменять задачу и устанавливать № заявки могут только участники портала.
Реализация записи изменений свойств документа в отдельный список. Каждая запись в списке должна содержать полное ФИО пользователя, который добавил, извлек или изменил документ. Также, должно быть записано, каким изменениям был подвергнут документ, когда это произошло и в какой библиотеке документов.

Целью решения поставленных задач является расширение возможностей портала SharePoint предприятия «ПАО КАМАЗ», для контроля и ограничения изменения документов в списках библиотек сайтов-поставщиков.

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

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

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

Исследование платформы SharePoint 2010 со стороны его функциональных возможностей;
Исследование средств разработки дополнительных решений для платформы SharePoint 2010;
Разработка методов решения поставленных задач в выбранной среде реализации;
Создание и тестирование готовых решений на портале предприятия;
Внедрение и установка готовых решений;

Разрабатываемое решение для портала «ПАО КАМАЗ» является узконаправленным решением, функционал которого полностью работоспособен только для конкретного портала предприятия, и неработоспособен на аналогичных других порталах или платформах. Причиной данных ограничений является специфичность обработки и хранения документации на различных порталах, а также несовместимость различных версий платформы SharePoint в плане разрабатываемых решений для повышения стандартного функционала. Однако, разработанные в процессе реализации поставленных задач программные модули и решения, могут использоваться для разработки новых, аналогичных решений для внедрения на различных порталах других компаний.

1.3. Обзор аналогов решений

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

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

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

Разрабатываемые решения для портала «ПАО КАМАЗ», установленного на платформе SharePoint Server 2010, является необходимым условием корректной работы с документами в списках библиотек портала. Данные решения позволяют организовать необходимую логику обработки атрибутов документа, установить определенные ограничения для различных групп пользователей на изменение свойств документа, вести запись таких изменений.

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

1.5. Средства реализации поставленных задач

SharePoint 2010 предоставляет различные инструменты для улучшения или расширения стандартных функций и возможностей платформы. Для настройки стандартных функций портала, SharePoint предоставляет средства администрирования, встроенные по умолчанию в данную платформу. Однако, данные решения не подойдут для реализации поставленных задач, описанных в разделе 1.2 - постановка задачи. Для реализации более сложных задач и решений помогут сторонние программные продукты, разработанные корпорацией Microsoft, такие как:

MS SharePoint Designer 2010.
MS InfoPath Designer 2010
MS Visual Studio 2010;

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

1.5.1. MS SharePoint Designer 2010

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

Приложение SharePoint Designer 2010 предоставляет интерфейс для создания сайтов и служит единой средой для разработки сайта, настройки его компонентов, проектирования логики на основе бизнес-процесса и развертывания сайта в виде пакетного решения [5].

Для решения поставленных задач на портале «ПАО КАМАЗ», приложение SharePoint (SP) Designer 2010 позволяет редактировать формы, которые служат для отображения и редактирования данных, содержащихся в списках библиотек. Так, например, можно настроить форму редактирования и создания данных, чтобы прописать логику ограничений на изменение свойств документа, описанных в разделе 1.2, этапы два и три постановки задачи. Для этого, в данных формах, необходимо добавить JavaScript код в HTML разметку формы, в полях, для которых необходимо установить ограничения на редактирование данных.

JavaScript (аббр. JS) - прототипно-ориентированный сценарный язык программирования. JS обычно используется как встраиваемый язык для программного доступа к объектам приложений. Наиболее широкое применение находит в браузерах как язык сценариев для придания интерактивности веб-страницам.

HTML (от англ. HyperText Markup Language - «язык гипертекстовой разметки») - стандартизированный язык разметки документов. Язык HTML интерпретируется браузерами; полученный в результате интерпретации форматированный текст отображается на экране монитора компьютера или мобильного устройства [6].

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

Недостатками решений в SP Designer 2010 является сложность реализации и написания, отладки программных модулей в данной среде. Также, серьезным недостатком является сложность администрирования данных решений – для настройки или внесения изменений в программные модули, необходимо открывать HTML разметку формы редактирования и находить нужный модуль в многочисленных строках кода формы.

1.5.2. MS InfoPath Designer 2010

MS InfoPath 2010 – это программа в составе Microsoft Office, позволяющая создавать формы для сбора данных и подачи заявок-отчетов, поддерживающая публикацию веб-форм и их заполнение через браузер.

Для чего подходят формы:

Редактирование форм списков портала;

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

Для чего формы не подходят:

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

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

1.5.3. MS Visual Studio 2010

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

Visual Studio 2010 предоставляет все необходимые шаблоны и инструменты, необходимые для разработки комплексных решений SharePoint. Приложения Visual Studio создаются на основе .NET Framework – той же платформы, на которой построен SharePoint. В SharePoint платформа .NET Framework используется в элементах управления ASP.NET, страницах компоновки, мастер-страницах, элементах управления ASCX и страницах ASPX. Можно разрабатывать проекты SharePoint с помощью Visual Basic или visual C#. Код, разработанный на одном языке, может ссылаться на код, разработанный на другом языке .NET.

MS Visual Studio 2010 поддерживает стандартизированный и упрощенный способ для упаковки и развертывания пакетов решений (WSP) SharePoint. Под пакетом решений подразумевается CAB-файл с расширением .wsp, в котором содержится код приложения, манифест и один или более каталогов с файлами приложения внутри. Visual Studio позволяет развертывать, деактивировать и отменять развёртывание пакетов решений без открытия командной строки и оболочки PowerShell [9, с. 797,798].

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

1.5. Выбор среды реализации поставленных задач

Изучение и анализ различных методов и инструментов для создания решений SharePoint, позволили выбрать два наиболее подходящих продукта: MS Visual Studio 2010 и MS SharePoint Designer 2010. В результате сравнения плюсов и минусов данных продуктов, предпочтение было отдано среде Visual Studio, так как данный продукт предоставляет все инструменты, необходимые для решения поставленных задач, описанных в разделе 1.2 – постановка задачи. Понятный и удобный интерфейс, общеизвестные и простые в освоении языки программирования, такие как C# и Visual Basic, а также простота поддержки и администрирования готовых решений SharePoint способствовали выбору среды Visual Studio.

1.6. Выводы по главе

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

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

2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1. Функциональное моделирование предметной области с использованием методологии IDEF1X

IDEF - методологии семейства ICAM (Integrated Computer-Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. Цель такого представления - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами [7].

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

Рис. 2.1.1. Первичная диаграмма А-0

Рис. 2.1.2. Диаграмма А0

Рис.2.1.3. Диаграмма А.1.1

Рис.2.6. Диаграмма А.4.1.

2.2. Описание модели разрабатываемого решения с использованием методологии UML

UML (англ. Unified Modeling Language - унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. Методология UML включает себя целый ряд диаграмм, с помощью которых можно описать конкретный процесс:

Диаграммы классов/пакетов:

Диаграммы объектов
Диаграммы вариантов использования
Диаграммы последовательности
Диаграммы взаимодействия
Диаграммы состояний
Диаграммы активности

Входными данными информационной системы портала «ПАО КАМАЗ» являются конструкторская документация, техническое задание, данные о документе. Выходной информацией является список документов, данные о документе, список изменений в библиотеке, информация о пользователе. Внешними сущностями системы является пользователь и администратор портала SharePoint. Контекстная диаграмма показана на рисунке 2.1.1.

Рис. 2.1.1. Контекстная диаграмма

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

Ограничение на изменение полей для поставщиков;
Ограничение на изменение полей для участников;
Запись изменений документа в список логирования;

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

Рис. 2.2.2. Диаграмма вариантов использования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Решения SharePoint для портала «ПАО КАМАЗ» разделены на две независимых друг от друга части: DocLibRestrict, для установки ограничений на изменение атрибутов документа, и LogListRec, для записи изменений документа – загрузка, выгрузка, изменение атрибутов документа. На портале SharePoint «ПАО КАМАЗ» создан список «Log», для хранения и записи перечисленных изменений. Данный список содержит поля:

Название – полное название именного документа в виде ссылки на документ в библиотеке документов. Тип поля – однострочный текст;
Изменен – дата и время изменения документа. Тип поля –дата/время;
Изменения – краткое описание изменений документа. Тип поля – однострочный текст;
Пользователь – полное ФИО пользователя портала, изменявшего документ. Тип поля – однострочный текст;
Библиотека – название библиотеки документов, в которой был изменен документ. Тип поля – однострочный текст;

Внешний вид списка «Log» (на примере тестового сайта «TEST») и примеры изменений документа показаны на рисунке 2.2.4.

Рис. 2.2.4. Внешний вид списка «Log».

SharePoint решение LogListRec записывает изменения документов в списке библиотек портала. В список записываются такие изменения, как:

Загрузка нового документа в список библиотеки документов;
Извлечение документа из списка библиотеки документов;
Изменение атрибута поля «Статус» и «Задача».

Решение LogListRec записывает изменения документа только при наличии в списках сайта портала списка «Lоg». Алгоритм работы решения LogListRec показан на рисунке 2.2.5.

Рис. 2.2.5. Алгоритм работы решения LogListRec.

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

Статус;
Задача;
№ Заявки.

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

Пользователи, принадлежащие группе поставщиков, могут изменять значение поля статус, только если значение этого поля изначально установлено на «требуется принять решение», т.е. поставщик имеет право изменять поле статус только один раз. Также, поставщикам запрещено изменять поле «Задача» и «№ заявки». Изменять задачу и устанавливать № заявки могут только участники или администратор портала. Алгоритм работы решения DocLibRestrict показан на рисунке 2.2.3.

Рис. 2.2.3. Алгоритм работы решения DocLibRestrict.

Для более полного понимания системы приведен один из ее сценариев для решения DocLibRestrict (таблица 2.2.1).

Таблица 2.2.1. Пример сценария работы решения DocLibRestrict

Шаг	Событие	Действие
		Пользователь-поставщик изменяет поле № заявки
1	Изменен атрибут документа № заявки	Проверка и получение данных о принадлежности пользователя к группе поставщиков.
2	Сохранение изменений атрибута документа № заявки	Отмена сохранения и выдача сообщения об ошибке с указанием типа ошибки пользователю.

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

Рис. 2.2.6. Диаграмма сотрудничества.

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

2.3. Логическая модель данных

Модель данных корпоративного хранилища представляет собой ER-модель (Entity-relationship model - модель «сущность-связь»), описывающую на нескольких уровнях набор взаимосвязанных сущностей, которые сгруппированы по функциональным областям и отражают потребности бизнеса в аналитическом анализе и отчетности. Логическая модель данных представляет структуру данных, их связей и атрибутов с помощью графических и визуальных средств, описаний и ограничений. При создании логической модели строится визуальная модель объекта. Построение логической модели данных предполагает наличие атрибутов и сущностей. Для этого выделим информационные объекты (таблица 2.3.1).

Таблица 2.3.1. Информационные объекты

ИО	Название Реквизита
Входящая КД КАМАЗ Исходящая КД поставщика Технические требования, ТЗ	Имя Тип № извещения № ревизии (изменения) Задача Статус Комментарий № заявки Проект Изменен Кем изменено
Заявки	Имя Тип № ревизии (изменения) Задача Статус Комментарий № заявки Проект Изменен Кем изменено
Log	Название Изменен Изменения Пользователь Библиотека

На рисунке 2.3.1. представлена диаграмма логической модели данных.

Рис. 2.3.1. Диаграмма логической модели данных

2.4. Физическая модель данных

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

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

Таблица 2.4.1. Списки библиотек документов.

Атрибут	Тип данных	Размер поля	Обязательный
Имя	файл	1	Да
Тип	-	-	Да
№ извещения	Однострочный текст	255	Нет
№ ревизии (изменения)	Однострочный текст	255	Нет
Задача	Выбор	5	Нет
Статус	Выбор	8	Нет
Комментарий	Многострочный текст	6 строк	Нет
№ заявки	Однострочный текст	255	Нет
Проект	Однострочный текст	255	Нет
Изменен	Дата/время	-	Нет
Кем изменено	Пользователь или группа	-	Нет

Список «Log» необходим для записи изменений документа решениями DocLibRestrict и LogListRec. (таблица 2.4.2).

Таблица 2.4.2.«Показатели водителя текущие»

Атрибут	Тип данных	Размер поля	Обязательный
Название	Однострочный текст	1	Да
Изменен	Дата/время	-	Да
Изменения	Однострочный текст	150	Да
Пользователь	Однострочный текст	100	Да
Библиотека	Однострочный текст	50	Да

2.5. Выводы по главе

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

3. РАЗРАБОТКА ИНФОРМАЦИОННОЙ СИСТЕМЫ

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

Для реализации ограничений на изменение атрибутов документа в списках библиотек документов портала «ПАО КАМАЗ» разработано решение DocLibRestrict.

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

Статус;
Задача;
№ заявки.

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

Документ загружен в библиотеку;
Документ выгружен;
Изменен статус;
Изменена задача.

Решения разработаны в среде Visual Studio 2010, шаблон проекта SharePoint Event Receiver. Данный шаблон проекта позволяет решить все поставленные задачи, описанные в разделе 1.2. – постановка задачи. На рисунке 3.1.1. представлена структура информационной системы.

Рис. 3.1.1. Структура информационной системы обработчика событий SharePoint

3.2. Типы проектов SharePoint в Visual Studio 2010

При создании нового проекта SharePoint в Visual Studio, в проект SharePoint добавляется решение вместе со всеми элементами проекта, необходимыми для выбранного типа. Например, если создать проект «веб-часть» Silverlight, Visual Studio создает решение, содержащее визуальный элемент проекта «веб-часть», а элемент проекта приложения Silverlight вместе со всеми файлами будут этими элементами проекта. Шаблоны элементов проектов используются для добавления элементов проекта к существующему проекту SharePoint, например добавление приемника событий, столбец сайта или списка.

Для просмотра шаблонов проектов SharePoint в Visual Studio, в диалоговом окне, необходимо создать проект, развернув узел SharePoint под ссылками (языками) Visual C# или Visual Basic. На рис. 3.2.1. показано диалоговое окно создания нового проекта SharePoint в Visual Studio 2010. Шаблоны проектов SharePoint позволяют создавать веб-части, столбцы и списки сайта, рабочие процессы, приемники событий и пр. Также проекты шаблонов позволяют импортировать рабочие проекты и пакеты готовых решений.

При создании нового проекта необходимо указать имя проекта и его расположение, имя конечного решения. Также необходимо установить программную платформу среды исполнения .NET Framework. По умолчанию, в Visual Studio 2010 для SharePoint, платформой установлен .NET Framework 4.

Рис. 3.2.1. Диалоговое окно создания нового проекта SharePoint в Visual Studio

3.3. SharePoint Event Receiver

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

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

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

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

Все события могут быть инициированы в следующих уровнях SharePoint:

События списков (List events);
События элементов списка (List Item events);
События входящей-исходящей почты (List email events);
События сайта (Site events);
События рабочих процессов (List workflow events);
События решений SharePoint (SharePoint Feature events).

Проекты приемников событий в Visual Studio 2010 реализованы как .NET классы, которые происходят из определенного класса приемника событий SharePoint, соответствующего объекту, к которому необходимо принять событие. Если нужно получить (отловить) событие, происходящее например, в списке SharePoint, необходимо использовать класс SPListEventReciever. Также к базовым классам относятся SPItemEventReceiver, SPWebEventReceiver, SPEmailEventReceiver, SPWorkflowEventReceiver и SPFeatureReceiver. Все эти классы, за исключением SPFeatureReceiver, происходят из общего базового класса под названием SPEventReceiverBase. У всех этих классов есть специальная необходимая инфраструктура для ответа на события, происходящие на портале SharePoint.

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

Элемент добавлен в список (ItemAdded);
Элемент будет добавлен в список (ItemAdding);
Элемент удален (ItemDeleted);
Элемент будет удален (ItemDeleting);
Документ возвращен в список (ItemCheckedIn);
Документ будет возвращен (ItemCheckingIn);
Извлечен документ (ItemCheckedOut);
Документ будет извлечен (ItemCheckingOut);
Элемент обновлен (ItemUpdated);
Элемент будет обновлен (ItemUpdating);
Добавлен файл к элементу списка(ItemAttachmentAdded);
Будет добавлен файл (ItemAttachmentAdding);
Удален присоединённый файл элемента списка (ItemAttachmentDeleted);
Будет удален присоединённый файл (ItemAttachmentDeleting);
Перемещен файл (ItemFileMoved);
Будет перемещен файл(ItemFileMoving);
Конвертация файла списка(ItemFileConverted);

Класс SPItemEventReceiver содержит такие важные свойства, как BeforeProperties и AfterProperties, позволяющие получить значение элемента (поля) до и после выполнения приемника событий соответственно. Также, данный класс содержит свойства списка, сайта, пользователя, для которых срабатывает данный приемник событий [10, стр. 317-330]. Значения, хранящиеся в свойствах BeforeProperties и AfterProperties для различных событий списков и библиотек документов, показаны в таблице 3.3.1 и 3.3.2.

Табл. 3.3.1. Значение свойств BeforeProperties и AfterProperties для списков Sharepoint.

Список	BeforeProperties	AfterProperties	Значение элемента списка
ItemAdding	Нет значений	Новое значение	Пусто
ItemAdded	Нет значений	Новое значение	Новое значение
ItemUpdating	Нет значений	Измененное значение	Исходное значение
ItemUpdated	Нет значений	Измененное значение	Измененное значение
ItemDeleting	Нет значений	Нет значений	Исходное значение
ItemDeleted	Нет значений	Нет значений	Пусто

Табл. 3.3.2. Значение свойств BeforeProperties и AfterProperties для библиотеки документов Sharepoint.

Библиотека	BeforeProperties	AfterProperties	Значение элемента списка
ItemAdding	Нет значений	Нет значений	Пусто
ItemAdded	Нет значений	Нет значений	Новое значение
ItemUpdating	Исходное значение	Измененное значение	Исходное значение
ItemUpdated	Исходное значение	Измененное значение	Измененное значение
ItemDeleting	Нет значений	Нет значений	Исходное значение
ItemDeleted	Нет значений	Нет значений	Пусто

Приемники событий SharePoint и Visual Studio предоставляют все необходимые инструменты для решения поставленных задач, описанных в разделе 1.2. – постановка задачи. Другие проекты Visual Studio не позволяют решить поставленных задач, поэтому был выбран такой метод решения задачи при помощи приемников событий Sharepoint. Далее будет описано, как был создан проект решения приемника события для портала «ПАО КАМАЗ», а также описан алгоритм работы данного решения и методы его реализации.

3.4. Физическая структура проекта решения

Для решения задач, поставленных в разделе 1.2. – постановка задачи, использован проект Visual Studio для платформы SharePoint, шаблон – Event Reciever (приемник событий). Для удобства администрирования и настройки готовых решений, этапы поставленных задач разделены на две независимых друг от друга части: отдельное решение для реализации ограничений на изменение элементов списка пользователями портала, и другое решение, для записи в список логирования изменений, которым подвергаются документы списков библиотек портала. Решение, ограничивающее изменение элементов списка названо DocLibRestrict, сокращение как «ограничение библиотеки документов». Решение, записывающее изменение в списках логирования изменений списка библиотек названо LogListRec, сокращенно как «запись в список Log». Установленные на портале «ПАО КАМАЗ» названные решения показаны на рисунках 3.4.1. и 3.4.2.

Рис. 3.4.1. Установленные и активированные решения ограничений и логирования портала.

Рис. 3.4.2. Командная консоль SharePoint. Установленные и активированные решения портала.

После выбора шаблона приемника событий и установки названия проекта, необходимо выбрать сервер (ферму) SharePoint, на котором будет установлено и активировано данное решение. Выбрав сервер, необходимо выбрать уровень доверия для решения Sharepoint. Решение можно установить как полноценное серверное решение, так и ограниченное решение, называемое «SandBoxed» - решение в «песочнице». SandBoxed решения позволяют создавать, устанавливать или изменять создаваемые решения SharePoint без возможного вреда для портала; например, вредоносный или неоптимизированный код обработчика событий. Окно выбора сервера и типа решения показаны на рис 3.4.3.

Рис. 3.4.3. Окно выбора сервера и типа решения портала.

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

Рис. 3.4.4. Окно выбора источника приемника и типа событий.

Для реализации ограничений на изменение полей списков библиотеки документов, для решения DocLibRestrict выбран тип событий «An item is being updated» - элемент списка будет обновлен. Данный тип событий позволит отменить нежелательное изменение полей до их изменения и сохранения в базе данных. Для решения LogListRec, позволяющего записывать изменение свойств или извлечения, добавления документа в библиотеках, выбраны следующие типы событий:

An item was updated – элемент списка обновлен;
An item was added – добавлен элемент списка;
An item was checked out – извлечен документ.

После выбора источника приемника и необходимых типов событий, открывается окно для конечного программирования решения SharePoint. Структура проекта приемника событий показана на рисунке 3.4.5. Проект приемника событий SharePoint создается в папке элемента проекта (DocLibRestrict и LogListRec), и содержит файл Elements.xml и файл кода.

Рис. 3.4.5. Структура проекта приемника событий.

Файл Elements.xml описывает приемник событий в SharePoint после его загрузки на сервер и содержит основное описание и структуру решения. Содержание этого файла для решения DocLibRestrict показано на рисунке 3.4.6.

Рис. 3.4.6. Содержание файла проекта Elements.xml.

Типы событий, которые были выбраны при создании проекта, определены в этом XML-файле. Число в элементе «SequenceNumber» определяет порядок выполнения событий. Если есть два или более приемников событий, и они обрабатываются в одном решении, то, события с меньшим числом в элементе SequenceNumber выполнятся раньше остальных.

Элемент «Type» содержит имя события, на которое реагирует приемник событий. Элементы «Assembly» и «Class» определяют расположение описания и класс проекта SharePoint.

В файле кода EventReceiver1.cs содержится класс, который наследуется от основного приемника событий (SPItemEventReceiver), и содержит обработчик событий для методов, выбранных при создании проекта. Содержание этого файла, сгенерированное для решения DocLibRestrict, показано на рисунке 3.4.7.

Рис. 3.4.7. Сгенерированный Visual Studio C# код файла EventReceiver1.cs.

В структуре проекта, в каталоге Feautre, можно задать название и описание решения, которое отображается в списке установленных решений на сайте портала SharePoint. Также, в данном каталоге настраивается конечное расположение установленного решения и наличие, расположение файлов проекта. Решение можно установить на уровне сервера (фермы), семействе сайтов, на определенном сайте или на веб-приложении. Окно настройки каталога Feature, для решения DocLibRestrict, показано на рисунке 3.4.8.

Рис.3.4.8. Окно настройки каталога Feature.

3.5. Описание программных модулей

Решения, позволяющие реализовать поставленные задачи, разделены на два независимых проекта: DocLibRestrict, для установки ограничений, и LogListRec, для записи изменений документа в списках библиотек портала «ПАО КАМАЗ».

3.5.1. Решение DocLibRestrict

Решение DocLibRestrict разработано в классе EventReceiver1, и реагирует на события списка ItemUpdating – элемент списка будет обновлен. Данный класс содержит в себе 4 метода:

userInGroup – метод типа bool, возвращающий значение «истина» при наличии пользователя в выбранной группе, иначе возвращает «ложь»;
errorMessage – метод, позволяющий вывести окно ошибки, с указание типа ошибки и заданного текста. Также, данный метод завершает выполнение приемника событий с отменой всех изменений документа;
beforeNoAfter – метод типа bool, возвращающий значение «истина», если измененное значение поля не совпадает с изначальным значением данного поля, иначе возвращает «ложь»;
ItemUpdating – метод, непосредственно связанный с обработчиком событий SharePoint, выполняющий пользовательский программный код.

Блок-схема алгоритма данного решения показана на рисунке 3.5.1.

Рис. 3.5.1. Блок-схема решения DocLibRestrict.

3.5.2. Решение LogListRec

Решение LogListRec разработано в классе EventReceiver1 проекта LogListRec, и реагирует на события списка:

ItemUpdated – элемент списка обновлен;
ItemAdded – добавлен документ в библиотеку документов;
ItemCheckedOut – извлечен документ из библиотеки.

Данный класс содержит в себе 4 метода:

RecNewItemInLog – метод, создающий в списке «Log» новую запись, в которую записывает изменения документа, имя пользователя, название библиотеки, текущее время и название документа;
ItemUpdated, ItemAdded, ItemCheckedOut – методы, непосредственно связанные с обработчиками событий SharePoint, выполняющие пользовательский программный код.

Блок-схема алгоритма данного решения показана на рисунке 3.5.3 – 3.5.4.

Рис. 3.5.3. Блок-схема решения для методов ItemAdded и ItemCheckedOut.

Рис. 3.5.4. Блок-схема решения для метода ItemUpdated.

3.6. Выводы по главе

В данной главе спроектирована структура информационной системы, разработаны алгоритмы работы решений DocLibRestrict и LogListRec, описаны методы данных решений. Также, приведено подробное описание программных модулей системы, показаны блок-схемы алгоритмов обработчиков событий портала «ПАО КАМАЗ».

4. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

1. Особенности корпоративных сетей

Существующие в настоящий момент большие корпоративные сети возникли не сразу, а развивались в течении многих лет. За прошедшие годы несколько раз менялись поколения вычислительной техники, технологий связи и программного обеспечения. Наличие сложных сетевых конфигураций в совокупности с требованиями к безопасности и надежности функционирования сервисов – в больших системах приводит к проблемам, которые начинают принимать глобальные масштабы. Характерной особенностью больших сетей, таких как портал «ПАО КАМАЗ», является использование большого числа разнообразных аппаратно-технических средств. Они различаются своими характеристиками, производительностью, аппаратными платформам и базовыми технологиям. Подобное разнообразие объясняется несколькими причинами: аппаратура приобреталась в разное время; ее подключение производилось разными специалистами, использовавшими разные технологии построения информационной сети; развивалась и топология сети путем присоединения корпоративных сетей региональных научных центров. Указанные обстоятельства породили ряд серьезных проблем для обеспечения информационной совместимости и безопасности систем [10].

1. Стандарты информационной безопасности

В области информационной безопасности в настоящий момент действует большое число стандартов, взаимодополняющих друг друга, как международных, так и отечественных. Наиболее важными из них являются рекомендации серии Х рабочей группы № 17 международного телекоммуникационного союза (ITU-T). Рекомендации этой серии описывают основы информационной безопасности в привязке к эталонной семиуровневой модели ISO/OSI. Эти рекомендации предусматривают администрирование средств безопасности и следующие сервисы безопасности:

Аутентификация. Имеются в виду аутентификация партнеров по общению и аутентификация источника данных.
Управление доступом. Обеспечение защиты от несанкционированного использования ресурсов.
Конфиденциальность данных. Предусматривается как защита, так и защита трафика.
Целостность данных. Данный сервис подразделяется на подвиды в зависимости от того, что контролируется — целостность сообщений или потока данных, обеспечивается ли восстановление в случае нарушения целостности.
Неотказуемость. Данный сервис относится к прикладному уровню, то есть имеется в виду невозможность отказаться от содержательных действий.

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

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

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

1. Сервисы безопасности

Более подробно основные сервисы безопасности корпоративных систем рассмотрены ниже.

1. 1. Идентификация и аутентификация.

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

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

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

Существует несколько способов реализации службы идентификации/аутентификации. К первой относится, например, традиционная, для приложений в различных OC, предусматривающая аутентификацию каждого приложения. Отсутствие целостности и централизации в этой схеме затрудняет ее администрирование. Не обеспечивается гибкость в применении различных механизмов (способов) аутентификации, так как в этом случае требуется перекомпиляция приложения. Второй способ основан на библиотеке встроенных интерактивных модулей PAM (Pluggable Authentication Modules), являющейся частью OC Red Hat Linux, представляет собой целостную централизованную систему, обеспечивающую гибкое использование различных механизмов аутентификации. Узким местом этого способа аутентификации и библиотеки PAM является обязательное требование интерактивности, что не всегда реализуемо на гетерогенной сетевой среде, и относительно сложный прикладной интерфейс.

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

1. 1. Разграничение доступа.

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

1. 1. Протоколирование/аудит.

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

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

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

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

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

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

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

1. 1. Экранирование.

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

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

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

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

1. 1. Туннелирование.

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

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

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

1. 1. Контроль защищенности

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

1. 1. Обнаружение отказов и оперативное восстановление

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

1. Политики безопасности

Для выполнения требований информационной безопасности необходим поиск новых способов к формализации политик безопасности (ПБ) [13]. К их числу можно отнести следующие:

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

1. Расчет уровня уязвимости корпоративной сети «ПАО КАМАЗ»

Решения, разработанные для портала «ПАО КАМАЗ», установлены и активированы на платформе SharePoint Server 2010. Данная платформа установлена на сервере научно-технического центра КАМАЗа, на системе Windows Server 2008 R2 Enterprise, под управлением баз данных SQL Server 2008.

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

Режимы проверки подлинности. В SharePoint Server 2010 поддерживается два режима проверки подлинности: на основе утверждений и классический режим. Проверка подлинности на основе утверждений основана на платформе Windows Identity Foundation (WIF), которая представляет собой набор классов .NET Framework, используемых для реализации системы идентификации на основе утверждений. В классическом режиме используется проверка подлинности Windows, и SharePoint Server 2010 считает все учетные записи пользователя учетными записями доменных служб Active Directory (AD DS). Службы IIS предоставляют три встроенных типа проверки подлинности: встроенная проверка подлинности Windows, дайджест-проверка подлинности и обычная проверка подлинности.
Действующие разрешения. Определяет разрешения пользователя или группы для всех ресурсов в семействе веб-сайтов.
Служба Secure Store. Служба Secure Store осуществляет хранение и сопоставление учетных данных с именами и паролями учетных записей. Она позволяет безопасно хранить данные учетных записей, необходимых для подключения к внешним системам, и связывать такие учетные данные с конкретным удостоверением или группой удостоверений.
Параметр "Обработка файлов в браузере". В SharePoint 2010 метод загрузки заголовка безопасности в веб-браузер клиента является ограничительным. По умолчанию используется параметр "Строгий", который запрещает запуск определенных типов файлов (например, Adobe Flash или Adobe PDF).
Изолированные решения. Изолированные решения в продуктах SharePoint 2010 позволяют выполнять код в ограниченной среде выполнения.
Уровень разрешения "Ограниченный доступ". Этот уровень разрешения предоставляет группам доступ к определенному списку, библиотеке, папке, документу или элементу, не предоставляя доступа к сайту целиком.

Все перечисленные функции безопасности по умолчанию используются на портале «ПАО КАМАЗ». На портале уставлены такие ограничения, как:

Разграничение прав доступа для различных групп пользователей портала;
Запрет на загрузку или запуск определенных типов файлов;
Защищенные учетные записи;
Изолированные решения;
Проверка подлинности пользователей;

Данные ограничения позволяют повысить информационную безопасность и снизить вероятность искажения информации до 90%. Оценка вероятности угроз и уязвимостей портала представлена в таблице 4.1.

Таблица 4.1. Расчёт вероятности угроз

Угроза	Уязвимость	Уровень риска, %
Искажение информации	Отсутствие защиты от вредоносного ПО	2
Искажение информации	Отказ сети Интернет	1
Потеря информации	Отсутствие резервных копий	5
Отказ системы	Колебания напряжения	0,5
Отказ системы	Отказ работы сервера	1,5

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

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

Таблица 4.2. Расчёт ущерба от реализации угроз

Угроза	Ущерб, %
Искажение информации	3
Потеря информации	5
Отказ системы	2

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

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

Контрмера	Стоимость контрмеры, руб.	Эффективность, %
Резервное копирование	10000	95
Установка защиты от вредоносного ПО	30000	96,5
Установка дублирующего сервера	112000	98
Итого	152000	98

После применения контрмер защищенность системы увеличится до 98%.

1. Выводы по главе

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

5. ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ РАЗРАБОТКИ СИСТЕМЫ

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

Проект представляет собой программный продукт, который создан для установки ограничений на изменение атрибутов документа пользователями портала предприятия, и записи данных изменений в список контроля. В настоящее время, контроль над изменением данных осуществляется администратором портала «ПАО КАМАЗ», однако администратор не может обеспечить полнофункциональный контроль работы с документами.

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

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

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

Показатели	Условные обозначения	Единицы измерения	Варианты
Показатели	Условные обозначения	Единицы измерения	Базовый	Проектируемый
Объем энергии, потребляемой компьютером в час	A	кВт	0,4	0,4
Объем энергии, необходимой для освещения в час		кВт	0,052	0,052
Число дней, необходимых разработчику для работы на компьютере	B_р1	дн.	-	30
Число дней при разработке, в течение которых происходит потребление энергии за счет освещения	B_р2	дн.	-	30
Время работы разработчика за компьютером в течение рабочего дня	Ч_р1	час.	-	8
Продолжительность использования освещения в течение рабочего дня	Ч_р2	час.	-	4
Продолжительность ежедневной работы	Р	час.	8	8
Балансовая стоимость оборудования	К_б	руб.	30000	30000
Стоимость лицензии Visual Studio	VS	руб.	32000	32000
Количество дней в месяц, необходимых для выполнения поставленной задачи	Д	дн.	24	14
Число дней в месяц, необходимых для работы	B₁	дн.	24	14
Число дней в месяц, в течение которых происходит потребление энергии за счет освещения	B₂	дн.	24	14
Месячный должностной оклад сотрудника отдела	О	Руб	14000	18000
Среднее количество рабочих дней в месяце	К	дн.	24	24
Число разработчиков	N_р	чел.	-	1

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

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

К = М + Э + Т + VS + САМ, (5.1)

где

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

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

VS – стоимость лицензии Visual Studio, руб.;

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

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

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

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

М = t * ИМб * КП, (5.2)

где

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

ИМб – стоимость пользования интернет трафиком (на одного человека), руб./мес.;

КП – количество пользователей, чел.

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

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

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

Э = a*k*Bр1*Чр1 + b*k*Bр2*Чр2, (5.3)

где

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

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

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

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

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

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

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

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

Э = 0,4*0.9467*30*8 + 0,052*0.9467*30*4 = 96.79 руб.

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

Э = 1*96.79 = 96.79 руб.

5.3.3. Расчет расходов на амортизацию и износ

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

, (5.4)

где

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

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

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

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

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

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

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

где

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

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

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

руб.

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

К =25,00 + 96,79 + 18000 * 1 + 32000 + 5400 = 55521.79 руб.

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

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

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

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

5.4.1. Расчет заработной платы администратора портала

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

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

где

О – месячный должностной оклад, руб.;

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

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

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

ЗПм = (1 + 0,262) * (18000*24/24) = 22716,00 руб.

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

ЗПм = (1 + 0,262) * (18000*14/24) = 13251,00 руб.

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

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

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

Э = a * k * B1 * Чр1+ b * k * B2* Чр2, (5.7)

где

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

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

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

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

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

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

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

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

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

Э = 0,4*0.9467*24*8 + 0,052*0.9467*24*4 = 77,43 руб.

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

Э = 0,4*0.9467*14*8 + 0,052*0.9467*14*4 = 45,17 руб.

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

5.4.3. Расчет расходов на амортизацию и износ

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

, (5.8)

где

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

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

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

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

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

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

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

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

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

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

где

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

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

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

руб.

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

руб.

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

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

С1 = 22716,00 + 77,43 + 4300,00 = 27093,43 руб.

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

С2 = 13251,00+ 45,17 + 2520,00 = 15816,17 руб.

Данный проект обеспечивает снижение эксплуатационных затрат ежемесячно на 11277,26 рублей, ежеквартально на 33831,78, ежегодно на 135327,12.

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

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

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

rp = i + r0 + i*r0, (5.10)

где

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

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

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

rp = 0,06 + 0,14 + 0,06*0,14 = 0,2084

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

, (5.11)

где

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

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

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

(5.12)

где

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

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

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

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

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

Значение NPV составит:

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

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

(5.13)

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

Или

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

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

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

(5.14)

Рентабельность проекта составит:

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

5.6. Выводы по главе

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

Заключение

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

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

Результатом проделанной работы является:

Решение DocLibRestrict для установки ограничений на изменение атрибутов документа в списках библиотек портала;
Решение LogListRec для записи изменений документа в списках библиотек портала.

Разработанные решения для портала «ПАО КАМАЗ» являются узконаправленными решениями, функционал которых полностью работоспособен только для конкретного портала предприятия, и неработоспособен на аналогичных других порталах или платформах. Причиной данных ограничений является специфичность обработки и хранения документации на различных порталах, а также несовместимость различных версий платформы SharePoint в плане разрабатываемых решений для повышения стандартного функционала. Однако, разработанные в процессе реализации поставленных задач программные модули и решения, могут использоваться для разработки новых, аналогичных решений для внедрения на различных порталах других компаний.

Список использованных источников

Википедия. Свободная энциклопедия. Корпоративный портал. URL: https://ru.wikipedia.org/wiki/ Корпоративный_портал.
Сайт корпорации Microsoft. URL: https:// technet.microsoft.com ru-ru/library.
Википедия. Свободная энциклопедия. Определения: поставщик и заказчик. URL: https://ru.wikipedia.org/wiki.
Корпорация Microsoft. Microsoft SharePoint 2010. Оценочное руководство.
Сайт корпорации Microsoft. Вводные сведения о SharePoint Designer 2010. https://support.office.com/ru-ru/article/Вводные-сведения-о-SharePoint-Designer-2010.
Википедия. Свободная энциклопедия. Определения: языки HTML и JavaScript.
Википедия. Свободная энциклопедия. IDEF. URL: https://ru.wikipedia.org/wiki/IDEF.
Microsoft SharePoint 2010. Полное руководство. Майкл Ноэл, Колин Спенс. Москва, 2011.
SharePoint 2010 development with Visual Studio 2010. Eric Carter, Boris Scholl, Peter Jausovec. 2011г.
SharePoint 2010. Просто для пользователей. 2011г.
Администрирование информационно-вычислительных сетей. Кустов Н.Т. 2015 г.
Модели безопасности компьютерных систем. Управление доступом и информационными потоками Девянин П.Н. 2014 г.
Computer security and cryptography. Alan G., Konheim. 2014 г.
Финансовый анализ. Инструментарий практика: учебное пособие. Артюшин В.В. 2013 г.
Экономический анализ. Румянцева Е.Е. 2016г.
Комплексный экономический анализ деятельности. Русакова Е.В. 2016 г.

Просмотров работы: 581

Код для цитирования:

IX Международная студенческая научная конференция Студенческий научный форум - 2017

РАСШИРЕНИЕ ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ СПИСКОВ И БИБЛИОТЕК ДОКУМЕНТОВ ПОРТАЛА SHAREPOINT 2010 ПУТЕМ РАЗРАБОТКИ ДОПОЛНЕНИЙ В СРЕДЕ VISUAL STUDIO

Студенческий научный форум - 2017
IX Международная студенческая научная конференция