Разработка автоматизированной системы учета электронных подписей
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Понятие, законодательное
регулирование и виды электронных подписей
.2 Анализ существующих систем учета
электронных подписей
.3 Постановка задачи
.4 Выбор решения и его обоснование
2. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ
ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО УЧЕТУ ЭЛЕКТРОННЫХ ПОДПИСЕЙ
2.1 Выбор модели проектирования
.2 Разработка структурной схемы
приложения
.3 Диаграмма прецедентов
.4 Диаграммы классов
.5 Разработка структуры базы данных
.6 Проектирование интерфейса
приложения
.7 Руководство пользователя
3. РАСЧЕТ ЗАТРАТ НА ВНЕДРЕНИЕ СИСТЕМЫ
ЗАКЛЮЧЕНИЕ
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ПРИЛОЖЕНИЕ
ВВЕДЕНИЕ
Компьютерная техника и информационные технологии проникают в нашу жизнь
все больше и больше. Одновременно с этим растут возможности компьютерных
устройств и систем и скорость их внедрения. То, на что раньше уходили долгие
годы, сейчас внедряется за месяцы и то, что раньше казалось чуть ли не
фантастикой, сейчас уже вполне обычная и часто используемая технология.
Совершенствование компьютерной техники идет также по пути упрощения
интерфейса устройств и уменьшения порога вхождения для их использования (в
качестве примера можно привести клавиатуру компьютера, которая не потеряла
своей актуальности, и количество кнопок на панели управления смартфона или
планшетного компьютера).
Новые технологии проникают во все сферы человеческой жизни и становятся
все более доступными для большинства людей. Если изначально информационные и
компьютерные технологии были доступны для военной и научной инфраструктуры, то
сейчас гораздо большее количество информационных технологий используются для
развлечений и повышения комфорта людей.
Вместе с возможностями компьютерной техники совершенствуются также
алгоритмы, структуры данных, способы обработки информации и архитектура
устройств, что позволяет повышать их производительность, так как потребности в
обработке больших объемов информации растут гораздо быстрее, чем растут
возможности вычислительных устройств.
В настоящее время многие организации пользуются электронной подписью,
т.к. она является полноценной заменой рукописной подписи.
Каждая электронная подпись имеет свой срок годности. Срок действия
сертификата ЭП зависит от системы в которой используется, но как правило
составляет 1 год.
Для того чтобы не прерывалась работа в информационной системе с
электронной подписью, необходимо заблаговременно озаботится продлением
сертификата ЭП.
Под продлением сертификата ЭП или обновлением сертификата ЭП понимается
выпуск нового ключа электронной подписи и нового сертификата на замену
имеющемуся.
В НУЗ «Отделенческая больница на ст.Вологда ОАО «РЖД» учет ЭП ведется без
использования средств автоматизации, а т.к. общее количество электронных
подписей более 20-ти, то вести учет довольно проблематично.
Целью моей работы является разработка автоматизированной системы учета
электронных подписей в НУЗ «Отделенческая больница на ст.Вологда ОАО «РЖД»,
которая позволит не только вести учет всех электронных подписей, но и
заблаговременно подготовить комплект документов на повторный выпуск
сертификата.
Для достижения цели необходимо решить следующие задачи:
провести анализ предметной области;
спроектировать приложение;
произвести выбор инструментария, используемый для реализации приложения.
1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1
Понятие, законодательное регулирование и виды электронных подписей
Электронная подпись - реквизит электронного документа, полученный в
результате криптографического преобразования информации с использованием
закрытого ключа подписи и позволяющий проверить отсутствие искажения информации
в электронном документе с момента формирования подписи (целостность),
принадлежность подписи владельцу сертификата ключа подписи (авторство), а в
случае успешной проверки подтвердить факт подписания электронного документа
(неотказуемость) [1].
Квалифицированная электронная подпись предназначена для определения лица,
подписавшего электронный документ, и является аналогом собственноручной подписи
в случаях, предусмотренных законом.
Квалифицированная электронная подпись применяется при совершении
гражданско-правовых сделок, оказании государственных и муниципальных услуг,
исполнении государственных и муниципальных функций, при совершении иных
юридически значимых действий.
Существует несколько схем построения цифровой подписи.
На основе алгоритмов симметричного шифрования. Данная схема
предусматривает наличие в системе третьего лица - арбитра, пользующегося
доверием обеих сторон. Авторизацией документа является сам факт зашифрования
его секретным ключом и передача его арбитру.
На основе алгоритмов асимметричного шифрования. На данный момент такие
схемы ЭП наиболее распространены и находят широкое применение.
Кроме этого, существуют другие разновидности цифровых подписей (групповая
подпись, неоспоримая подпись, доверенная подпись), которые являются
модификациями описанных выше схем. Их появление обусловлено разнообразием
задач, решаемых с помощью ЭП.
Поскольку подписываемые документы - переменного (и как правило достаточно
большого) объёма, в схемах ЭП зачастую подпись ставится не на сам документ, а
на его хэш. Для вычисления хэша используются криптографические хэш-функции, что
гарантирует выявление изменений документа при проверке подписи. Хэш-функции не
являются частью алгоритма ЭП, поэтому в схеме может быть использована любая
надёжная хэш-функция.
Использование хэш-функций даёт следующие преимущества.
Вычислительная сложность. Обычно хэш цифрового документа делается во
много раз меньшего объёма, чем объём исходного документа, и алгоритмы
вычисления хэша являются более быстрыми, чем алгоритмы ЭП. Поэтому формировать
хэш документа и подписывать его получается намного быстрее, чем подписывать сам
документ.
Совместимость. Большинство алгоритмов оперирует со строками бит данных,
но некоторые используют другие представления. Хэш-функцию можно использовать
для преобразования произвольного входного текста в подходящий формат.
Целостность. Без использования хэш-функции большой электронный документ в
некоторых схемах нужно разделять на достаточно малые блоки для применения ЭП.
При верификации невозможно определить, все ли блоки получены и в правильном ли
они порядке.
Важной проблемой всей криптографии с открытым ключом, в том числе и
систем ЭП, является управление открытыми ключами. Так как открытый ключ
доступен любому пользователю, то необходим механизм проверки того, что этот
ключ принадлежит именно своему владельцу. Необходимо обеспечить доступ любого
пользователя к подлинному открытому ключу любого другого пользователя, защитить
эти ключи от подмены злоумышленником, а также организовать отзы́в ключа в случае его компрометации.
Задача защиты ключей от подмены решается с помощью сертификатов.
Сертификат позволяет удостоверить заключённые в нём данные о владельце и его
открытый ключ подписью какого-либо доверенного лица. Существуют системы
сертификатов двух типов: централизованные и децентрализованные. В
децентрализованных системах путём перекрёстного подписывания сертификатов
знакомых и доверенных людей каждым пользователем строится сеть доверия. В
централизованных системах сертификатов используются центры сертификации,
поддерживаемые доверенными организациями.
Центр сертификации формирует закрытый ключ и собственный сертификат,
формирует сертификаты конечных пользователей и удостоверяет их аутентичность
своей цифровой подписью. Также центр проводит отзы́в истекших и компрометированных
сертификатов и ведёт базы (списки) выданных и отозванных сертификатов.
Обратившись в сертификационный центр, можно получить собственный сертификат
открытого ключа, сертификат другого пользователя и узнать, какие ключи
отозваны.
Закрытый ключ является наиболее уязвимым компонентом всей криптосистемы
цифровой подписи. Злоумышленник, укравший закрытый ключ пользователя, может
создать действительную цифровую подпись любого электронного документа от лица
этого пользователя. Поэтому особое внимание нужно уделять способу хранения
закрытого ключа. Пользователь может хранить закрытый ключ на своем персональном
компьютере, защитив его с помощью пароля. Однако такой способ хранения имеет
ряд недостатков, в частности, защищённость ключа полностью зависит от
защищённости компьютера, и пользователь может подписывать документы только на
этом компьютере.
В настоящее время существуют следующие устройства хранения закрытого
ключа:
дискеты;
смарт-карты;
USB-брелоки;
«таблетки» Touch-Memory;
реестр (в защищённой памяти компьютера).
Кража или потеря одного из таких устройств хранения может быть легко
замечена пользователем, после чего соответствующий сертификат должен/может быть
немедленно отозван.
Наиболее защищённый способ хранения закрытого ключа - хранение на
смарт-карте. Для того, чтобы использовать смарт-карту, пользователю необходимо
не только её иметь, но и ввести PIN-код, то есть, получается двухфакторная
аутентификация. После этого подписываемый документ или его хэш передаётся в
карту, её процессор осуществляет подписывание хэша и передаёт подпись обратно.
В процессе формирования подписи таким способом не происходит копирования
закрытого ключа, поэтому все время существует только единственная копия ключа.
Кроме того, произвести копирование информации со смарт-карты немного сложнее,
чем с других устройств хранения.
В соответствии с законом «Об электронной подписи», ответственность за
хранение закрытого ключа владелец несёт сам.
В России юридически значимый сертификат электронной подписи выдаёт
удостоверяющий центр. Правовые условия использования электронной цифровой
подписи в электронных документах регламентирует Федеральный закон Российской
Федерации от 6 апреля 2011 года № 63-ФЗ «Об электронной подписи».
В криптографии центр сертификации или удостоверяющий центр - сторона, чья
честность неоспорима, а открытый ключ широко известен. Задача центра
сертификации - подтверждать подлинность ключей шифрования с помощью
сертификатов электронной подписи.
Технически центр сертификации реализован как компонент глобальной службы
каталогов, отвечающий за управление криптографическими ключами пользователей.
Открытые ключи и другая информация о пользователях хранится удостоверяющими
центрами в виде цифровых сертификатов.
Центр сертификации - это компонент, отвечающий за управление
криптографическими ключами пользователей.
Открытые ключи и другая информация о пользователях хранится центрами
сертификации в виде цифровых сертификатов, имеющих следующую структуру:
серийный номер сертификата;
объектный идентификатор алгоритма электронной подписи;
имя удостоверяющего центра;
срок действия сертификата;
имя владельца сертификата (имя пользователя, которому принадлежит
сертификат);
открытые ключи владельца сертификата (ключей может быть несколько);
объектные идентификаторы алгоритмов, ассоциированных с открытыми ключами
владельца сертификата;
электронная подпись, сгенерированная с использованием секретного ключа
удостоверяющего центра (подписывается результат хэширования всей информации, хранящейся
в сертификате).
Отличием аккредитованного центра является то, что он находится в
договорных отношениях с вышестоящим удостоверяющим центром и не является первым
владельцем самоподписанного сертификата в списке удостоверенных корневых
сертификатов. Корневой сертификат аккредитованного центра удостоверен
вышестоящим удостоверяющим центром в иерархии системы удостоверения. Таким
образом, аккредитованный центр получает «техническое право» работы и наследует
«доверие» от организации, выполнившей аккредитацию.
Аккредитованный центр сертификации ключей обязан выполнять все
обязательства и требования, установленные законодательством страны нахождения
или организацией, проводящей аккредитацию в своих интересах и в соответствии со
своими правилами.
Порядок аккредитации и требования, которым должен отвечать
аккредитованный центр сертификации ключей, устанавливаются соответствующим
уполномоченным органом государства или организации, выполняющей аккредитацию.
Центр сертификации ключей имеет право:
предоставлять услуги по удостоверению сертификатов электронной цифровой
подписи
обслуживать сертификаты открытых ключей
получать и проверять информацию, необходимую для создания соответствия
между информацией, указанной в сертификате ключа, и предъявленными документами.
1.2 Анализ
существующих систем учета электронных подписей
В настоящее время в НУЗ «Отделенческая больница на ст. Вологда ОАО «РЖД»
ведется журнал поэкземплярного учета СКЗИ, представленный в таблице,
эксплуатационной и технической документации к ним, ключевых документов.
Таблица - Журнал учета
|
Отметка о
подключении (установке) СКЗИ
|
Отметка об
изъятии СКЗИ из аппаратных средств, уничтожении ключевых документов
|
Примечание
|
|
Ф.И.О.
сотрудников органа криптографической
защиты, пользователя СКЗИ, произведших подключение (установку)
|
Дата подключения (установки) и подписи лиц, произ-ведших подключение (установку)
|
Номера
аппаратных средств, в которые установлены или к которым
подключены СКЗИ
|
Дата изъятия (уничто-жения)
|
Ф.И.О.
сотрудников органа криптографической
защиты, пользователя СКЗИ, производивших изъятие (уничтожение)
|
Номер акта или расписка об уничтожении
|
|
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
Единицей поэкземплярного учета ключевых документов считается ключевой
носитель многократного использования, ключевой блокнот. Если один и тот же
ключевой носитель многократно используют для записи криптоключей, то его каждый
раз следует регистрировать отдельно.
1.3
Постановка задачи
Реализация любого программного продукта, который будет применен на
производстве, в каких-либо еще бизнес-процессах, в общественной или
государственной деятельности, всегда начинается с написания технического
задания.
Техническое задание - документ, содержащий требования заказчика к объекту
закупки или разработки, определяющие условия и порядок ее проведения, в
соответствии с которым осуществляются поставка товара, выполнение работ,
оказание услуг и их приемка.
Грамотное составление технического задания позволяет:
исключить ошибочные и неправомерные требования;
проверить соответствие товаров, работ, услуг требованиям
законодательства;
правильно рассчитать сроки, необходимые для выполнения работ, оказания
услуг;
подробно и понятно описать предмет разработки, назначить ответственных
специалистов;
представить результат разработки;
исключить несогласованности и ошибки;
осуществить проверку разработанного продукта.
При составлении технического задания заказчику следует руководствоваться
следующими рекомендациями:
описание потребностей заказчика должно носить объективный характер;
формулировки задания должны быть понятными, лаконичными,
непротиворечивыми, соответствовать сложившейся практике и обычаям делового
оборота, не должны противоречить законодательству;
задание не должно предусматривать для исполнителя больше рисков и
обременений, чем для заказчика.
В техническом задании целесообразно указать:
общую информацию о разработке;
информацию об объекте разработки;
требования к исполнителю;
условия исполнения контракта;
информацию о приложениях.
Как показывает практика, отсутствие технического задания или его небрежное
составление очень часто приводит к значительно большим финансовым потерям, чем
было сэкономлено времени на этом этапе. Кроме финансовых потерь, в данном
случае также возможны репутационные потери компании-подрядчика, что, как
правило, гораздо хуже, чем финансовые потери. В зависимости от стадии
разработки, когда были обнаружены проблемы с техническим заданием, финансовые
потери для компании-подрядчика составляют (указана кратность потерянного
времени к сэкономленному времени):
этап проектирования - два раза;
этап реализации - пять раз;
этап тестирования - десять раз;
этап эксплуатации - до ста раз.
Приведенные выше значения получены эмпирическим путем, при опросе
нескольких разработчиков и архитекторов информационных систем и приложений.
Кроме этого, к финансовым потерям компании-разработчика могут добавиться
финансовые потери компании или организации, эксплуатирующей приложение,
особенно, если приложение используется не в тестовом режиме, а уже включено в
рабочие- и бизнес-процессы организации.
Приведем краткое техническое задание на разработку приложения для учета
электронных подписей в компании.
Необходимо произвести проектирование и реализацию приложения,
предназначенного для учета электронных подписей в рамках одной организации.
Приложение должно давать возможность добавлять, редактировать и удалять
информацию об электронных подписях, которые имеются у сотрудников данной
организации, а также выполнять подписание документов с помощью криптопровайдера
КриптоПро и проверять корректность уже подписанных документов.
Также приложение должно давать возможность добавлять информацию об
операциях, производимых с сертификатами электронной подписи (выпуск
сертификата, его отзыв и компрометирование и так далее).
Приложение должно корректно работать под управлением операционной системы
семейства Windows, версии XP и более младших (Vista, Seven, Windows 8, Windows
10). При проектировании приложения необходимо учесть вероятную потребность
переноса приложения на операционные системы семейства Unix, iOS, Android.
Проектирование приложения должно включать в себя следующие части:
разработку UML-диаграмм
приложения (прецедентов, компонентов, классов);
разработку диаграмм, не входящих во множество диаграмм языка
проектирования UML (структурная и
ER-диаграмма);
проектирование интерфейса приложения;
проектирование базы данных приложения.
Интерфейс приложения для учета электронных подписей в организации должен
быть максимально простым и понятным для пользователя, а также снабжен
необходимыми подсказками, чтобы обеспечить низкий порог вхождения и минимальное
время обучения сотрудников организации.
Приложение должно корректно реагировать на возможные ошибки в процессе
работы, не прерывать работу, если это возможно, и по возможности возвращать
сообщение об ошибке с понятным пользователю описанием.
После реализации приложения необходимо произвести его описание и
тестирование правильности его работы на различных наборах входных данных.
Также требуется произвести технико-экономическое обоснование
целесообразности разработки и внедрения приложения путем расчета трудозатрат и
финансовых затрат на описанные выше в техническом задании действия.
На этом составление технического задания на разработку приложения для
учета электронных подписей в организации можно считать завершенным.
1.4 Выбор
решения и его обоснование
Для реализации приложения для ПК был выбран язык программирования C# и среда разработки Visual Studio.
C# -
объектно-ориентированный язык программирования. Разработан в 1998-2001 годах
группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как язык разработки приложений для
платформы Microsoft .NET Framework [2].
.NET Framework - программная платформа, выпущенная
компанией Microsoft в 2002 году. Основой платформы
является общеязыковая среда исполнения Common Language Runtime (CLR),
которая подходит для разных языков программирования [3]. Функциональные
возможности CLR доступны в любых языках
программирования, использующих эту среду.
C#
относится к семье языков с C-подобным
синтаксисом, из них его синтаксис наиболее близок к C++ и Java.
Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку
операторов, делегаты, атрибуты, события, свойства, обобщённые типы и методы,
итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML [4].
Microsoft Visual Studio - линейка продуктов компании Microsoft, включающих интегрированную среду
разработки программного обеспечения и ряд других инструментальных средств.
Данные продукты позволяют разрабатывать как консольные приложения, так и
приложения с графическим интерфейсом, в том числе с поддержкой технологии Windows Forms, а также веб-сайты, веб-приложения, веб-службы как в
родном, так и в управляемом кодах для всех платформ, поддерживаемых Windows, Windows Mobile, Windows CE, .NET Framework, Xbox, Windows Phone .NET Compact Framework и Silverlight.
Visual Studio включает в
себя редактор исходного кода с поддержкой технологии IntelliSense и возможностью простейшего
рефакторинга кода. Встроенный отладчик может работать как отладчик уровня
исходного кода, так и отладчик машинного уровня. Остальные встраиваемые
инструменты включают в себя редактор форм для упрощения создания графического
интерфейса приложения, веб-редактор, дизайнер классов и дизайнер схемы базы
данных. Visual Studio позволяет создавать и подключать сторонние дополнения
(плагины) для расширения функциональности практически на каждом уровне, включая
добавление поддержки систем контроля версий исходного кода, добавление новых
наборов инструментов или инструментов для прочих аспектов процесса разработки
программного обеспечения.
В качестве языка для разработки Web-приложения был выбран язык программирования PHP, в качестве программной платформы - фреймворк Yii2, а в качестве систему управления
базами данных - СУБД MySQL [5].
PHP -
скриптовый язык общего назначения, интенсивно применяемый для разработки
веб-приложений. В настоящее время поддерживается подавляющим большинством
хостинг-провайдеров и является одним из лидеров среди языков, применяющихся для
создания динамических веб-сайтов [6].
Язык и его интерпретатор разрабатываются группой энтузиастов в рамках
проекта с открытым кодом. Проект распространяется под собственной лицензией,
несовместимой с GNU GPL.
В области веб-программирования, в частности серверной части, PHP - один из популярных сценарных
языков.
Популярность в области построения веб-сайтов определяется наличием
большого набора встроенных средств для разработки веб-приложений:
автоматическое извлечение POST и
GET-параметров, а также переменных
окружения веб-сервера в предопределённые массивы;
взаимодействие с большим количеством различных систем управления базами
данных (MySQL, PostgreSQL, Oracle и так далее);
автоматизированная отправка HTTP-заголовков;
работа с HTTP-авторизацией;
работа с cookies и
сессиями;
работа с локальными и удалёнными файлами, сокетами;
обработка файлов, загружаемых на сервер;
работа с Xforms.
Синтаксис PHP подобен
синтаксису языка Си. Некоторые элементы, такие как ассоциативные массивы и цикл
foreach, заимствованы из Perl.
Для работы программы не требуется описывать какие-либо переменные,
используемые модули и т. п. Любая программа может начинаться непосредственно с
оператора PHP.
PHP
является языком программирования с динамической типизацией, не требующим
указания типа при объявлении переменных, равно как и самого объявления
переменных. Преобразования между скалярными типами зачастую осуществляются
неявно без дополнительных усилий (впрочем, PHP предоставляет широкие возможности и для явного
преобразования типов).
PHP-скрипты
обычно обрабатываются интерпретатором в порядке, обеспечивающем
кроссплатформенность разработанного приложения:
лексический анализ исходного кода и генерация лексем;
синтаксический анализ полученных лексем;
генерация байт-кода;
выполнение байт-кода интерпретатором (без создания исполняемого файла).
Для увеличения быстродействия приложений возможно использование
специального программного обеспечения, так называемых акселераторов. Принцип их
работы заключается в кэшировании однажды сгенерированного байт-кода в памяти и/или
на диске, таким образом, из процесса работы приложения исключаются этапы 1-3,
что в общем случае ведёт к значительному ускорению работы.
Важной особенностью является то, что разработчику нет необходимости
заботиться о распределении и освобождении памяти. Ядро PHP реализует средства для автоматического управления
памятью; вся выделенная память возвращается системе после завершения работы
скрипта [7].
Интерпретатор PHP имеет
специальный конфигурационный файл - php.ini, содержащий множество настроек,
изменение которых влияет на поведение интерпретатора. Имеется возможность
отключить использование ряда функций, изменить ограничения на используемую
скриптом оперативную память, время выполнения, объём загружаемых файлов,
настроить журналирование ошибок, работу с сессиями и почтовыми сервисами,
подключить дополнительные расширения, а также многое другое.
Yii2 -
объектно-ориентированный компонентный фреймворк, написанный на PHP и реализующий парадигму MVC.
Возможности фреймворка Yii2:
высокая производительность относительно других фреймворков, написанных на
PHP;
парадигма Модель-представление-контроллер;
интерфейсы DAO и ActiveRecord для работы с базами данных (PDO);
поддержка интернационализации;
кэширование страниц и отдельных фрагментов;
перехват и обработка ошибок;
ввод и валидация форм;
аутентификация и авторизация (RBAC и ACL);
использование AJAX и интеграция
с jQuery;
генерация базового PHP-кода
для CRUD-операций.
MySQL
- свободная реляционная система управления базами данных. Разработку и
поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку
вместе с поглощённой Sun Microsystems,
которая ранее приобрела шведскую компанию MySQL AB.
Гибкость СУБД MySQL
обеспечивается поддержкой большого количества типов таблиц: пользователи могут
выбрать как таблицы типа MyISAM,
поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных
записей [8]. Более того, СУБД MySQL
поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов
таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.
MySQL
портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris,
SunOS, SCO OpenServer, UnixWare, Tru64, Windows
95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows
Server 2003, WinCE, Windows Vista, Windows 7 и Windows 10.
MySQL
имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk, Компонентный Паскаль и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.
Максимальный размер таблиц в MySQL 3.22 до 4 гигабайт, в последующих версиях ограничений нет.
Размер таблицы ограничен её типом. В общем случае тип MyISAM ограничен предельным размером файла
в файловой системе операционной системы. Например, в NTFS этот размер теоретически может быть до 32 эксабайт. В
случае InnoDB одна таблица может храниться в
нескольких файлах, представляющих единое табличное пространство. Размер
последнего может достигать 64 терабайт.
В отличие от MyISAM, в InnoDB имеется значительное ограничение на
количество столбцов, которое можно добавить в одну таблицу. Размер страницы
памяти по умолчанию составляет 16 килобайт, из которых под данные отведено 8123
байта. Размер указателя на динамические поля составляет 20 байт. Таким образом,
в случае использования динамического формата строки, одна таблица может
вместить максимум 409 столбцов типа blob или text.
2. ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА
АВТОМАТИЗИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ПО УЧЕТУ ЭЛЕКТРОННЫХ ПОДПИСЕЙ
2.1 Выбор
модели проектирования
Проектирование информационной системы является не менее важной частью
разработки, чем непосредственно сама реализация системы.
Необходимость проектирования связана с тем, что изначально невозможно
предусмотреть все нюансы проектируемого приложения, понять все требования
заказчика, так как они могут быть как некорректно сформулированы, так и изменится
в процессе разработки. Отдельным пунктом среди этого следует выделить процесс
проектирования интерфейса приложения, так это требует дополнительных
консультаций с людьми, которые будут пользоваться им.
Ошибки и неточности встречаются постоянно, чем раньше они диагностируются
и локализуются, тем меньше стоимость переделки. Наиболее оптимальным является
выявление ошибок и неточностей на этапе составления технического задания или на
этапе проектирования приложения.
Кроме этого, при проектировании закладывается возможность расширения
приложения, его более гибкой настройки и управления им.
Также в процессе проектирования определяется способ разработки
приложения, наиболее подходящий для конкретной задачи. Существуют следующие
способы разработки информационных систем и программного обеспечения:
каскадная модель - особенность данной модели в том, что каждый этап
разработки начинается только после завершения предыдущего этапа разработки;
поэтапная модель с промежуточным контролем - разработка приложения ведется
итерациями с циклами обратной связи между этапами;
спиральная модель - суть данной модели в том, что выполняется множество
итераций разработки и в каждой итерации реализуется какая-либо версия продукта,
производится проверка системы (приложения) и уточнение требований к ней для их
реализации в следующей итерации [9].
Для разработки приложения для учета электронных подписей была выбрана
каскадная модель разработки, так как эта модель наиболее подходит для небольшой
команды разработчиков, а в данном случае имеется только такая команда.
При проектировании приложения будет применен язык проектирования UML, так как данный язык проектирования
является, фактически, монополистом в своей предметной области, обладает всеми
необходимыми возможностями для проектирования и имеет подробную документацию.
2.2
Разработка структурной схемы приложения
Структурная схема - это совокупность элементарных звеньев объекта и
связей между ними, один из видов графической модели. Под элементарным звеном
понимают часть объекта, системы управления и так далее, которая реализует
элементарную функцию [10].
Действительное расположение составных частей на структурной схеме не
учитывают и способ связи не раскрывают. Построение схемы должно давать
наглядное представление о:
составе изделия;
последовательности взаимодействия функциональных частей в изделии.
Функциональные части на схеме изображают в виде прямоугольников или условных
графических обозначений. При изображении функциональных частей в виде
прямоугольников их наименования, типы и обозначения вписывают внутрь
прямоугольников.
Направление хода процесса, происходящего в изделии, обозначают стрелками,
соединяющими функциональные части. На схемах простых изделии функциональные
части располагают в виде цепочки в соответствии с ходом рабочего процесса в
направлении слева направо. Схемы, содержащие несколько основных рабочих
каналов, рекомендуется вычерчивать в виде параллельных горизонтальных строк
[11].
Структурная схема приложения для определения качества подготовки
специалистов приведена на рисунке 2.1.
Рисунок 2.1 - Структурная схема приложения
Как видно из приведенной выше структурной схемы, приложение будет
состоять из двух основных частей:
приложения для ПК;
Web-приложения
для администрирования.
Модель «клиент-сервер» была выбрана для данного приложения, потому что
таким приложением значительного легче управлять, чем если бы приложение
полностью (со всей необходимой базой данных) устанавливалось на каждый ПК.
2.3
Диаграмма прецедентов
Диаграмма вариантов использования (диаграмма прецедентов) - диаграмма,
отражающая отношения между актёрами и прецедентами и являющаяся составной
частью модели прецедентов, позволяющей описать систему или приложение на
концептуальном уровне.
Прецедент - возможность моделируемой системы (часть её функциональности),
благодаря которой пользователь может получить нужный ему результат. Прецедент
соответствует отдельному сервису системы, определяет один из вариантов её
использования и описывает типичный способ взаимодействия пользователя с
системой. Варианты использования обычно применяются для спецификации внешних
требований к системе или приложению.
Основное назначение диаграммы - описание функциональности и поведения,
позволяющее всем лицам, так или иначе участвующим в разработке, совместно
обсуждать проектируемую или существующую систему [12].
Диаграмма прецедентов приложения для проверки качества подготовки
специалистов приведена на рисунке 2.2.
Как видно из диаграммы вариантов использования, в приложении имеется два
актера:
пользователь;
администратор.
Пользователь представляет собой сотрудника компании, который использует
приложение для работы с информацией об электронных подписях.
Рисунок 2.2 - Диаграмма прецедентов
Администратор представляет собой сотрудника компании, который имеет
полномочия управлять программным продуктом (добавлять и редактировать
удостоверяющие центры в список, добавлять и удалять пользователей).
Диаграмма компонентов - статическая структурная диаграмма, показывает
разбиение программной системы на структурные компоненты и связи между
компонентами. В качестве физических компонентов могут выступать файлы,
библиотеки, модули, исполняемые файлы, пакеты и так далее.
Диаграмма компонентов приложения для учета электронных подписей приведена
на рисунке 2.3.
Рисунок 2.3 - Диаграмма компонентов приложения
Как видно из диаграммы компонентов, приложение будет состоять из
следующих элементов:
контроллер;
модель;
база данных;
представление;
сеть Интернет;
API-адаптер;
программный код приложения, реализующий его логику.
Сеть Интернет можно отнести к приложению лишь условно, однако без них
приложение не сможет функционировать. Без сети Интернет приложение для ПК не
сможет получить информацию от Web-приложения,
а также передать ему результаты своей работы (добавление, редактирование,
удаление информации об электронных подписях в организации).
2.4
Диаграммы классов
Диаграмма классов - диаграмма, демонстрирующая классы системы, их
атрибуты, методы и взаимосвязи между ними. В диаграмме классов не учитывается
конкретный язык реализации системы.
Диаграмма классов является ключевым элементом в объектно-ориентированном
моделировании. На диаграмме классы представлены в рамках, содержащих три
компонента:
в верхней части написано имя класса, выравнивается по центру, пишется
полужирным шрифтом и начинается с заглавной буквы
посередине располагаются поля (атрибуты) класса, выровненные по левому
краю и начинающиеся с маленькой буквы;
нижняя часть содержит методы класса, также выровненные по левому краю и
начинающиеся с маленькой буквы.
Если предполагается использовать модификаторы доступа к членам класса
(полям и методам), то используются следующие обозначения перед их
наименованиями (таблица 2.1).
Таблица 2.1 - Обозначение модификаторов доступа
|
Обозначение
|
Назначение
|
|
+
|
Публичный
|
|
-
|
Приватный
|
|
#
|
Защищенный
|
Диаграммы классов приложения приведены на рисунках 2.4 и 2.5. На рисунке
2.4 приведена диаграмма классов Web-приложения.
На рисунке 2.5 приведена диаграмма классов приложения для ПК.
Как видно из диаграммы на рисунке 2.4, в Web-приложении будут реализованы следующие классы:
Users
- класс-модель, применяемый для авторизации и работы со списком пользователей и
с отдельными их учетными записями;
Files
- класс-модель, используемый для работы со списком загруженных в приложение
файлов и с каждым файлом по отдельности;
Logs -
класс-модель, применяемый для работы со списком записей истории действий
пользователя, а также работы с отдельными записями истории (добавление,
удаление);
CertCentres - класс-модель, предназначенный для работы со списком удостоверяющих
центров, выдающих сертификаты электронной подписи, а также работы с отдельными
элементами этого списка;
Certificates - класс-модель, применяемый для работы со списком сертификатов
электронной подписи пользователей, а также для работы с отдельными элементами
этого списка;
Рисунок 2.4 - Диаграмма классов Web-приложения
- класс-модель, используемый для работы с таблицей связи файлов
электронных подписей с файлами, которые были использованы для подписания;-
класс-контроллер для авторизации администратора в приложении;- класс-контроллер
для взаимодействия приложения для ПК с Web-приложением;- абстрактный
класс-контроллер, в котором реализована проверка авторизации пользователя-администратора
перед обработкой запросов от него; все контроллеры, которые расположены в
панели администрирования приложения, наследуются от этого контроллера;
UsersController - класс-контроллер, предназначенный для просмотра,
добавления, редактирования и удаления пользователей приложения;
CertCentersController - класс-контроллер, применяемый для работы с удостоверяющими
центрами (просмотр списка, добавление, редактирование, удаление);
HistoryController - класс-контроллер, используемый для просмотра истории
действий пользователя;
ApiController - класс-контроллер, предназначенный для взаимодействия приложения для ПК
с Web-приложением.
Классы ActiveRecord, ActiveController и Controller представляют собой стандартные классы
PHP-фреймворка Yii2 (о нем будет написано ниже), которые предоставляют базовый
функционал модели, REST-контроллера и
контроллера соответственно.
Рисунок 2.5 - Диаграмма классов приложения для ПК
Как видно из диаграммы на рисунке 2.5, в приложении для ПК будут
реализованы следующие классы:
ApiAdapter - класс, применяемый для взаимодействия приложения для ПК с Web-приложением (получение информации от
него и передача ему информации);
Form1
- класс, используемый для отображения формы авторизации пользователя и обмена
авторизационной информацией с Web-приложением;
FormAccount - класс, применяемый для отображения формы личного кабинета
пользователя;
FormCertificates - класс, используемый для отображения формы со списком
сертификатов пользователя;
FormAddCertificate - класс, применяемый для отображения формы добавления
сертификата пользователя;
FormCheck - класс, используемый для отображения формы проверки электронной
подписи;
FormSignatures - класс, применяемый для отображения формы со списком
подписанных файлов сотрудника;
FormAddSignature - класс, применяемый для отображения формы добавления
подписи файла;
Settings - класс, используемый для хранения настроек приложения;
CertificateModel - класс, используемый для описания сертификата электронной
подписи;
CertCenterModel - класс, используемый для описания удостоверяющего центра;
SignatureModel - класс, применяемый для описания подписанного файла;
NetworkChecker - класс, используемый для проверки наличия подключения к
сети Интернет.
2.5
Разработка структуры базы данных
Несмотря на то, что проектирование базы данных и построение ER-диаграммы
приведено после построения всех остальных диаграмм приложения, важность данного
этапа не следует преуменьшать. База данных является важнейшей частью
приложения, в которой закладывается, частично, и логика работы приложения и
даже небольшие изменения в базе данных могут приводить к значительным
изменениям логики работы приложения.диаграмма базы данных приложения приведена
на рисунке 2.6.- таблица, в которой содержится основная информация о
пользователях и администраторах приложения. Данная таблица представлена
следующими полями:
id - идентификатор пользователя;
login - авторизационное имя пользователя;
password - пароль пользователя;
fullName - полное имя пользователя;
type - тип пользователя (user - обычный пользователь или admin -
администратор);
enabled - флаг, указывающий на то, включена ли учетная запись
пользователя или нет.
Рисунок 2.6 - ER-диаграмма базы
данных приложения
Files - таблица, в которой хранится информация о файлах, который
загружены в приложение. Данная таблица представлена следующими полями:
id - идентификатор файла;
name - имя файла;
path - адрес расположения файла;
size - размер файла;
mime - тип файла;
dateAdd - дата добавления файла.
Logs -
таблица, в которой содержится информация о действиях, совершаемых
пользователями приложения. Данная таблица содержит следующие поля:
id -
идентификатор записи;
userId
- идентификатор пользователя;
description - описание действия пользователя;
dateAdd
- дата добавления записи.
Signatures - таблица, в которой находится информация о подписях файлов. Данная
таблица представлена следующие поля:
id -
идентификатор записи;
fileId
- идентификатор файла;
signatureFileId - идентификатор файла с подписью;
certificateId - идентификатор сертификата электронной подписи, который был использован
для подписания файла.
CertCenters - таблица, в которой содержится список удостоверяющих центров. Данная
таблица содержит следующие поля:
id -
идентификатор удостоверяющего центра;
name -
наименование удостоверяющего центра;
certificateFileId - идентификатор файла корневого сертификата;
ocspUrl
- URL-адрес, предназначенный для проверки
работоспособности сертификата.
Certificates - таблица, содержащая список сертификатов электронной подписи
пользователей. Данная таблица представлена следующими полями:
id -
идентификатор сертификата;
userId
- идентификатор пользователя;
centerId - идентификатор удостоверяющего центра;
position - должность пользователя;
companyName - наименование компании;
email
- адрес электронной почты;
INN -
ИНН пользователя или юридического лица;
KPP -
КПП юридического лица;
fileId
- идентификатор файла сертификата.
2.6
Проектирование интерфейса приложения
Обоснование
вида интерфейса
Интерфейс приложения и его удобство для пользователя является не менее
важным, чем его функционал. Есть множество примеров программного обеспечения,
которое обладало нужным для пользователей функционалом, однако из-за того, что
у приложения был неудобный для пользователя интерфейс, оно не могло занять свое
место на рынке.
Также для пользователей является важным низкий порог вхождения для работы
с приложением, так как не все его пользователи обладают высоким уровнем
компьютерной грамотности.
Так как приложение состоит из двух частей (Web-приложения и приложения для ПК), то интерфейс этих
частей также будет спроектирован отдельно, так как в этих частях интерфейс
реализуется принципиально различными способами:
интерфейс приложения для ПК реализуется в процессе разработки путем
размещения элементов управления на форме в среде разработки;
интерфейс Web API реализуется с помощью языка разметки
HTML путем набора текста в любом
текстовом редакторе.
Проектирование интерфейсов производится путем построения макетов в векторном
графическом редакторе, так как вопрос дизайна интерфейса и его эстетической
привлекательности выходит за пределы данной главы.
Разработка
структуры интерфейса
Макеты интерфейса Web API приведены на
рисунках 2.7 - 2.12.
На рисунке 2.7 представлен макет страницы авторизации. Он содержит два
текстовых поля для ввода имени и пароля пользователя и кнопку подтверждения
входа в систему. После подтверждения входа в систему будет произведен вход в
систему.
Рисунок 2.7 - Страница «Авторизация»
На рисунке 2.8 представлена таблица о пользователях, которые имеют доступ
к системе, которая содержит в себе информацию о порядковом номере и полном
имени пользователя.
Рисунок 2.8 - Страница «Пользователи»
На рисунке 2.9 представлена форма редактирования пользователя, которая
позволяет редактировать данные об уже существующем пользователе или завести в
системе нового пользователя. Для этого на форме имеются поля для ввода
следующей информации: имя пользователя, пароль, подтверждение пароля и полное
имя пользователя и кнопки сохранения или отмены действия.
Рисунок 2.9 - Страница «Редактирование пользователя»
Рисунок 2.10 представляет форму, где представлена информация об
удостоверяющих центрах, выдавших электронную подпись.
На рисунке 2.11 представлена форма редактирования удостоверяющего центра,
которая позволяет редактировать данные об уже существующем удостоверяющем
центре или добавить новый удостоверяющий центр. Для этого на форме имеются поля
для ввода следующей информации: наименование центра, URL-адрес OCSP-запроса
и кнопки сохранения или отмены действия.
Рисунок 2.10 - Страница «Удостоверяющие центры»
Рисунок 2.11 - Страница «Редактирование удостоверяющего центра»
На рисунке 2.12 отображена страница «История действий» которая,
представляет собой журнал истории действий пользователей в системе. Данная
информация используется для составления отчетов и ведения учета электронных
подписей. Информация представляет собой порядковый номер пользователя, самого
пользователя, описание действий совершенных в системе, дату и время совершенных
действий. Также присутствует возможность удалить записи о действиях.
Рисунок 2.12 - Страница «История действий»
Листинг Web-приложения приведен в приложении 1.
Макеты окон приложения для ПК приведены на рисунках 2.13 - 2.20.
Так же присутствует макет страницы авторизации, представленный на рисунке
2.13. Он содержит два текстовых поля для ввода имени и пароля пользователя и
кнопку подтверждения входа в систему и выхода из системы.
Рисунок 2.13 - Окно авторизации
При успешной авторизации будет произведен вход в личный кабинет. На
рисунке 2.14 представлено окно личного кабинета пользователя, которое дает
возможность просмотреть информацию о сертификатах, подписанных документах и
проверить подписи для каждого пользователя вошедшего в систему. электронный подпись
приложение интерфейс
Рисунок 2.14 - Окно личного кабинета пользователя
На рисунке 2.15 представлена форма, которая отображает информацию. На
форме находятся кнопки добавления, удаления сертификата и формирования заявки
на выдачу сертификата. Так же на форме находится поле, в котором выводится
информация об имеющихся сертификатах.
Рисунок 2.15 - Окно списка сертификатов
Рисунок 2.16 отображает форму «Заявка на сертификат». Для формирования
заявки необходима следующая информация: наименование подразделения и должность
сотрудника, номер комнаты, где установлено автоматизированное рабочее место,
адрес электронной почты, номер телефона, область применения сертификата ключа
подписи.
Рисунок 2.16 - Окно создания заявки на сертификат
Листинг приложения для ПК приведен в приложении 2.
2.7
Руководство пользователя
Руководство
пользователя Web-приложения.
На рисунке 2.17 представлено окно авторизации на главной странице, где
используются имя пользователя и пароль, которые вводятся в соответствующие поля
для заполнения.
Именем пользователя является последовательность букв латинского алфавита
без специальных символов, длиной не более N символов. Пароль - не превышает 8
символов и состоит из цифр и букв латинского алфавита.
После успешной авторизации пользователь попадает на страницу выбора
вменяемых ему функций, например: «Пользователи», «Удостоверяющие центры»,
«История действий» и «Выход». При выборе интересуемой функции открывается окно,
где непосредственно создается или редактируется информация.
Рисунок 2.17 - Страница «Авторизация»
Для создания нового пользователя необходимо нажать на кнопку «Добавить
пользователя», после чего открывается окно, где уже вносятся все необходимые
данные, которые нужно опубликовать. Внесенную ранее информацию о пользователе
можно отредактировать с помощью кнопки «Редактировать» или удалить с помощью
кнопки «Удалить», как представлено на рисунке 2.18.
Рисунок 2.18 - Страница «Пользователи»
Рисунок 2.19 - Страница «Редактирование пользователя»
Так же можно добавить новый удостоверяющий центр с помощью кнопки
«Добавить удостоверяющий центр». Внесенную ранее информацию об удостоверяющем
центре так же можно отредактировать с помощью кнопки «Редактировать» или
удалить с помощью кнопки «Удалить», как представлено на рисунке 2.20.
Рисунок 2.20 - Страница «Удостоверяющие центры»
На рисунке 2.21 представлено окно, где уже вносятся все необходимые
данные, которые нужно опубликовать.
Рисунок 2.21 - Страница «Редактирование удостоверяющего центра»
На рисунке 2.22 изображена закладка «История действий» представляет собой
журнал истории действий пользователей в системе. Данная информация используется
для составления отчетов и ведения учета электронных подписей. С помощью кнопки
«Очистить историю» можно удалить весь журнал, или с помощью кнопки «Удалить»
удалить некоторые действия совершенные в системе.
Рисунок 2.22 - Страница «История действий»
Руководство
пользователя приложения для персонального компьютера.
Как представлено на рисунке 2.23 в приложении для ПК так же присутствует
окно авторизации на главной странице, в котором используются имя пользователя и
пароль, которые вводятся в соответствующие поля для заполнения.
Именем пользователя является последовательность букв латинского алфавита
без специальных символов, длиной не более N символов. Пароль - не превышает 8
символов и состоит из цифр и букв латинского алфавита.
Рисунок 2.23 - Окно авторизации
После успешной авторизации пользователь попадает в личный кабинет, с
кнопками: «Сертификаты», «Подписанные документы» и «Проверка подписи» как
представлено на рисунке 2.24.
Рисунок 2.24 - Окно личного кабинета
На рисунке 2.25 представлен раздел «Сертификаты», где имеется возможность
добавить, удалить сертификат и сформировать заявку на сертификат в
удостоверяющий центр РЖД. Так же на форме находится поле, в котором выводится
информация об уже имеющихся сертификатах.
Рисунок 2.25 - Окно списка сертификатов
На рисунке 2.26 представлено окно для формирования заявки на сертификат
необходимо ввести в поля следующую информацию: наименование подразделения и
должность сотрудника, номер комнаты, где установлено автоматизированное рабочее
место, адрес электронной почты, номер телефона, область применения сертификата
ключа подписи.
Рисунок 2.26 - Окно создания заявки на сертификат
С помощью кнопки «Проверка подписи» можно проверить электронную подпись
на актуальность, как представлено на рисунке 2.27
Рисунок 2.27 - Окно проверки электронной подписи
3. РАСЧЕТ ЗАТРАТ НА ВНЕДРЕНИЕ СИСТЕМЫ
Любые инвестиции в бизнес должны быть экономически обоснованы. И если
некоторые инвестиции продиктованы законами Российской Федерации (например,
оборудование здания противопожарной системой), то принятие решение о разработке
приложения для учета электронных подписей - исключительно бизнес-решение.
Для обоснования экономической эффективности и целесообразности разработки
и внедрения приложения для учета электронных подписей необходимо и достаточно,
чтобы стоимость проектирования и разработки приложения была окупаемая в
ближайшей перспективе времени. То есть, если разработка приложения окупится
лишь через несколько десятков лет, то назвать ее целесообразной весьма сложно.
Стоимость работ по разработке приложения для учета электронных подписей
складывается из стоимости оборудования для разработки приложения, стоимости
программного обеспечения, размера заработной платы сотрудников, занятых в
разработке приложения и размера социальных отчислений на данных сотрудников.
Кроме этого, в стоимость разработки приложения вкладывается стоимость покупки
доменного имени и стоимость аренды выделенного сервера.
Произведем расчет стоимости оборудования, которое необходимо для
разработки приложения для учета электронных подписей. Стоимость оборудования и
его количество приведены в таблице 3.1.
Таблица 3.1 - Стоимость оборудования
|
Наименование
оборудования
|
Количество
единиц оборудования, шт.
|
Стоимость за одну
единицу, руб.
|
Общая
стоимость, руб.
|
|
Ноутбук Acer
ES1-523
|
4
|
24490
|
97800
|
|
Сетевой фильтр
Buro 600SH-1.8-B
|
2
|
390
|
780
|
|
Итого:
|
98580
|
Таким образом, стоимость оборудования, необходимого для разработки
приложения для учета электронных подписей, равна 98580 рублей.
Произведем расчет стоимости работ по проектированию и реализация
приложения для учета электронных подписей.
Для определения трудоемкости разработки используются типовые нормы
времени по производству проектировочных работ и работ по реализации
программного обеспечения. Нормы времени рассчитаны на комплексы задач, так как
проектировочные работы по сути и есть набор небольших задач и указаны в
человеко-днях при пятидневной рабочей неделе с продолжительностью рабочего дня
восемь часов.
Расчет трудоемкости разработки приложения производится по формуле [14]:
,
где tj - трудоемкость работ по этапам
проектирования и реализации;
k -
количество этапов проектирования и реализации.
Воспользуемся экспертными методами определения трудоемкости работ на
каждый этап процесса. Определим максимальное и минимальное время, которое
необходимо для выполнения каждого этапа разработки. Исходя из этих значений,
определим ожидаемое время. Ожидаемое время определяется по формуле:
,
где: Tож - ожидаемое (реальное) время
выполнения;
tmin -
минимальное время;
tmax -
максимальное время.
Временные затраты на каждый этап разработки и реализации проекта
приложения для учета электронных подписей, вычисленные с помощью формул 1 и 2,
представлены в таблице 3.2.
Таблица 3.2 - Временные затраты
|
Этап разработки
проекта
|
tmin, дни
|
tmax, дни
|
Ожидаемые
затраты времени, Tож, человеко-день
|
|
1. Подготовка,
составление технического задания
|
2
|
3
|
2
|
|
2. Анализ
теоретической информации
|
3
|
4
|
3
|
|
3.
Проектирование приложения
|
5
|
7
|
6
|
|
4.
Проектирование интерфейса приложения
|
2
|
3
|
2
|
|
5. Реализация
приложения
|
21
|
25
|
23
|
|
6. Тестирование
приложения
|
3
|
5
|
4
|
|
7. Установка и
развертывание приложения
|
2
|
3
|
2
|
|
Итого:
|
38
|
50
|
42
|
Для разработки и реализации приложения для учета электронных подписей
необходимы следующие специалисты:
менеджер проекта;
инженер-программист;
системный администратор;
инженер по тестированию (тестировщик).
Приведем функции специалистов на различных этапах разработки и реализации
приложения для учета электронных подписей в таблице 3.3.
Таблица 3.3 - Функции специалистов
|
Этапы
разработки
|
Трудоемкость,
человеко-день
|
Исполнители
|
Доля участия, %
|
Фонд времени,
дней
|
|
1
|
2
|
3
|
4
|
5
|
|
1. Подготовка,
составление технического задания
|
2
|
менеджер
|
50
|
1
|
|
|
программист
|
30
|
0,6
|
|
|
системный
администратор
|
20
|
0,4
|
|
|
тестировщик
|
0
|
0
|
|
2. Анализ
теоретической информации
|
3
|
менеджер
|
20
|
0,6
|
|
|
программист
|
80
|
2,4
|
|
|
системный
администратор
|
0
|
0
|
|
|
тестировщик
|
0
|
0
|
|
3.
Проектирование приложения
|
6
|
менеджер
|
20
|
1,2
|
|
|
программист
|
50
|
3
|
|
|
системный
администратор
|
30
|
1,8
|
|
|
тестировщик
|
0
|
0
|
В таблице 3.4 приведем занятость в проекте по должностям.
Таблица 3.4 - Занятость в проекте по должностям
|
Должность
сотрудника
|
Занятость в
проекте, человеко-дней
|
|
Менеджер проекта
|
3,6
|
|
Инженер-программист
|
27,6
|
|
Системный
администратор
|
5,5
|
|
Тестировщик
|
5,3
|
|
Итого:
|
42
|
Заработная плата персонала определяется исходя из фонда времени каждого
исполнителя и среднедневной заработной платы.
Среднедневная заработная плата каждого участника рассчитывается по
формуле:
,
где: ЗМЕС - среднемесячный
заработок, руб.;- среднее количество рабочих дней в месяце (d = 22).
Примем следующие размеры
окладов для участников разработки и реализации приложения для учета
многооборотной почтовой тары:
менеджер проекта - 40000
рублей;
инженер-программист - 60000
рублей;
системный администратор -
45000 рублей;
тестировщик - 35000 рублей.
Основная заработная плата
рассчитывается по формуле:
,
где ЗДН - среднедневная заработная
плата, руб.;
Т - трудоемкость,
человеко-день.
Отчисления страховых взносов
составляют 30,2% от основной заработной платы ЗОСН и определяются по формуле:
,
Ставки страховых взносов
составляют:
26% в пенсионный фонд;
,1% в фонд медицинского
страхования;
2,9% в фонд социального
страхования;
0,2% в фонд страхования от
несчастных случаев.
Общий фонд заработной платы
рассчитывается по формуле:
Приведем расчет фонда
заработной платы специалистов в таблице 3.5.
Таблица 3.5 - Расчет фонда
заработной платы
|
Специалист
|
Трудо-емкость
|
ЗДН
|
ЗОСН
|
ЗСОЦ
|
Фонд заработной
платы
|
|
Менеджер
проекта
|
3,6
|
1818,18
|
6545,45
|
2965,09
|
12783,27
|
|
Инженер-программист
|
27,6
|
2727,27
|
75272,72
|
34098,54
|
147007,63
|
|
Системный
администратор
|
5,5
|
2045,45
|
11250
|
5096,25
|
21971,25
|
|
Тестировщик
|
5,3
|
1590,9
|
8431,81
|
3819,61
|
16467,34
|
|
Итого:
|
8181,81
|
101500
|
45979,5
|
198229,5
|
Накладные расходы рассчитываются в процентах от основной заработной платы
(60%) по формуле:
рублей,
Произведем расчет стоимости программного обеспечения, необходимого для
разработки приложения для учета электронных подписей.
Для разработки приложения для ПК инженеру-программисту потребуется пакет
для разработки Visual Studio 2015 от компании Microsoft. Согласно официальному
сайту компании Microsoft, стоимость данного пакета равна 26770 рублей.
Остальные программные продукты, используемые в процессе разработки приложения,
являются свободно-распространяемым программным обеспечением.
Приведем расчет стоимости ежемесячных трат на разработку приложения в
таблице 3.6.
Таблица 3.6 - Ежемесячные траты на разработку приложения
|
Наименование
услуги
|
Стоимость в
месяц
|
Количество
месяцев
|
Стоимость
|
|
Аренда
выделенного сервера
|
375
|
2
|
750
|
|
Аренда
доменного имени
|
99
|
1
|
99
|
|
Итого:
|
849
|
Приведем вычисленные ранее значения слагаемых общей стоимости разработки
приложения для учета электронных подписей в таблице 3.7.
Таблица 3.7 - Стоимость разработки приложения
|
Расходы
|
Стоимость
|
|
Стоимость
оборудования
|
98580
|
|
Фонд оплаты
труда сотрудников
|
198229,5
|
|
Накладные
расходы
|
60900
|
|
Стоимость
программного обеспечения
|
26770
|
|
Ежемесячные
расходы
|
849
|
|
Итого:
|
385328
|
Таким образом, общая стоимость разработки и внедрения приложения для
учета электронных подписей равна 385328 рублей.
Рассчитанная сумма является вполне посильной даже для небольшой компании,
или даже для среднеобеспеченного человека. Кроме этого, оборудование для
разработки может уже быть у компании в наличии на момент начала проекта, что
сильно уменьшает траты. Если же оборудования в наличии нет, то приобретенное
оборудование может быть использовано в дальнейшей деятельности компании, так
как за время разработки приложения оно не может прийти в негодность.
В результате приведенной выше информации можно сделать вывод, что
разработка приложения для учета электронных подписей компании является
экономически целесообразной.
ЗАКЛЮЧЕНИЕ
В ходе создания дипломной работы по проектированию и разработке
приложения для учета электронных подписей в организации были решены следующие
задачи.
Проведен анализ предметной области. Перед производством технических работ
по разработке приложения в рамках данного раздела было изучено такое средство
защиты информации, как электронная подпись. Были изучены принципы ее
формирования, разновидности, программные средства, необходимые для ее создания,
а также правовые основы, на которых на территории Российской Федерации
используется электронная подпись.
Произведено проектирование приложения с помощью универсального языка
моделирования (UML). В рамках
проектирования были построены следующие типы диаграмм (перед построением
каждого типа диаграмм приведено краткое описание данного типа диаграммы):
структурная диаграмма приложения для учета электронных подписей, описывающая
структуру приложения и взаимодействие частей приложения друг с другом;
диаграмма прецедентов (UseCase-диаграмма)
- описание действий пользователя при работе с приложением;
диаграмма компонентов приложения, описывающая отдельные части приложения
и взаимодействие между ними; данная диаграмма схода по назначению со
структурной диаграммой, однако же, в отличие от нее, учитывает особенности
программной реализации приложения (в частности, использование PHP-фреймворка Yii2);
диаграммы классов приложения для ПК и серверного Web-приложения; также было приведено краткое описание
классов, представленных на данных диаграммах;
ER-диаграмма
базы данных приложения для учета электронных подписей, где описаны сущности и
связи между ними; данная диаграмма зачастую не включается в множество языка
проектирования UML, однако же
играет чрезвычайно важную роль в проектировании любого приложения, которое
использует базу данных для хранения информации.
Построены макеты окон приложения для ПК, а также макеты страниц Web-приложения.
Произведен выбор инструментария, используемый для реализации Web-приложения и приложения для ПК:
язык программирования PHP и PHP-фреймворк (программная платформа) Yii2;
реляционная система управления базами данных MySQL;
язык программирования C#;
программная платформа для разработки Windows-приложений .NET Framework 4.0;
среда визуальной разработки Visual Studio 2015.
В качестве операционной системы для работы приложения для ПК была
использована операционная система Windows 7 64-х разрядная, а для Web-приложения - 64-х разрядная операционная система Ubuntu 16.04.
В качестве подтверждения правильности работы приложений в разделе,
описывающем реализацию приложения, приведены снимки окон приложения для ПК, а
также Web-приложения с выведенными
результатами работы.
На этом проектирование и разработку приложения для учета электронных
подписей можно считать завершенной.
СПИСОК
ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Виссер
Дж. Разработка обслуживаемых программ на языке C# / Виссер Дж. - Москва: ДМК
Пресс, 2016. - 292 с.
2. Рихтер,
Дж. CLR via C#. Программирование на платформе Microsoft .NET Framework4.0 на языке C#. 3-е изд. - СПб.: Питер, 2012. - 982 с.
. Албахари
Д. C# 6.0. Справочник. Полное описание языка. 6-е изд. / Албахари Д., Албахари
Б. - Москва: OReilly, 2016. - 1040 с.
4. Гольцман
В. MySQL 5.0. Библиотека программиста / СПб: Питер, 2010. - 253 с.
5. Шлосснейгл
Дж., Профессиональное программирование на PHP / Москва: Вильямс, 2006. - 624 с.
. Симдянов
И. PHP 7. В подлиннике / Симдянов И., Котеров Д. - Санкт-Петербург:
БХВ-Петербург, 2016. - 1073 с.
. Исаев
Г.Н. Проектирование информационных систем / Москва: Омега-Л-Москва, 2015. - 512
с.
. Проектирование
информационных систем (на примере методов структурного системного анализа):
учебное пособие / сост. О. Г. Инюшкина. - Екатеринбург: Форт-Диалог Исеть,
2014. - 240 с.
. Леоненков
А. Самоучитель языка UML. - СПб: БХВ-Петербург, 2007. - 576 с.
. Буч
Г., Рамбо Д., Якобсон А. Язык UML. Руководство пользователя. Второе издание.
ДМК, 2006, 496 с
11. Теслюк
Л.М. Оценка эффективности инвестиционного проекта / Теслюк Л.М., Румянцева А.В.
- Москва: Фолио, 2011 - 145 с.
ПРИЛОЖЕНИЕ
(информационное)
Листинг Web-приложения
class Files extends \yii\db\ActiveRecord
{
/**
* @inheritdoc
*/
public static function tableName()
{
return 'Files';
}
/**
* @inheritdoc
*/
public function rules()
{
return [
[['name', 'path', 'mimo', 'size', 'dateAdd'], 'required'],
[['name', 'path', 'mimo'], 'string'],
[['size'], 'integer'],
[['dateAdd'], 'safe'],
];
}
/**
* @inheritdoc
*/
public function attributeLabels()
{
return [
'id' => 'ID',
'name' => 'Name',
'path' => 'Path',
'mimo' => 'Mimo',
'size' => 'Size',
'dateAdd' => 'Date Add',
];
}
}Users extends \yii\db\ActiveRecord implements
IdentityInterface
{
const SCENARIO_LOGIN = 'login';
const SCENARIO_PROFILE = 'profile';
public $entranceIds = [];
public static function tableName()
{
return 'Users';
}
/**
* @inheritdoc
*/
public function rules()
{
return [
[['login', 'password'], 'required', 'message' => 'Поле не должно быть пустым'],
[['login'], 'safe'],
[['enabled'], 'integer'],
[['password'], 'string', 'max' => 40],
];
}function scenarios()
{
$scenarios = parent::scenarios();
$scenarios[self::SCENARIO_LOGIN] = ['login', 'password'];
$scenarios[self::SCENARIO_PROFILE] = ['login'];
return $scenarios;
}
/**
* @inheritdoc
*/
public function attributeLabels()
{
return [
'id' => 'ID',
'login' => 'Login',
'password' => 'Password',
'lastLogin' => 'Last Login',
'enabled' => 'Enabled',
];
}
public static function login($login, $password)
{
$user = self::find()->where(['login' => $login,
'password' => sha1($password)])->one();
if ($user && isset($user->id) &&
$user->id)
{
Yii::$app->getUser()->login($user);
return true;
}
else
{
return false;
}
}
public static function findIdentity($id)
{
return static::findOne($id);
}
public static function findIdentityByAccessToken($token,
$type = null)
{
return static::findOne(['access_token' => $token]);
}
public function getId()
{
return $this->id;
}
public function getAuthKey()
{
return $this->authKey;
}
public function validateAuthKey($authKey)
{
return $this->authKey === $authKey;
}
}frontend\controllers;yii\web\Controller;app\models\Users;yii\web\Response;Yii;yii\data\ActiveDataProvider;yii\helpers\ArrayHelper;UsersController
extends AuthController
{
public $ipp = 20;
public function actionIndex()
{
$query = Users::find();
$provider = new ActiveDataProvider([
'query' => $query,
'pagination' => [
'pageSize' => 10
]
]);
return $this->render('index', [
'provider' => $provider
]);
}
public function actionEdit()
{
$id = Yii::$app->request->get('id', null);
if ($id)
{
$model = Users::find()->where(['id' => $id])->one();
}
else
{
$model = new Users();
}
$model->scenario = 'profile';
if (Yii::$app->request->isPost)
{
$post = Yii::$app->request->post('Users');
$model->setAttributes ($post, false);
if (!empty($post['password']))
$model->password = sha1($post['password']);
$model->status = 'user';
$model->save(false);
return $this->redirect('/users');
}
return $this->render('edit', [
'model' => $model,
]);
}
public function actionDelete()
{
$id = Yii::$app->request->get('id', null);
if ($id)
{
$model = Users::find()->where(['id' => $id])->one();
$model->delete();
return $this->redirect('/users');
}
return $this->redirect('/users');
}
}
(информационное)
Листинг приложения для ПК
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
NetworkChecker nc = new NetworkChecker();
if (!nc.checkNetwork())
{
MessageBox.Show("Соединение с Интернетом отсутствует или
ограничено!");
Application.Exit();
}
}
private void button1_Click(object sender, EventArgs e)
{
if (textBox1.Text == "" || textBox2.Text ==
"")
{
MessageBox.Show("Для авторизации необходимо ввести имя пользователя
и пароль!");
return;
}
ApiAdapter a = new ApiAdapter();
if (a.login(textBox1.Text, textBox2.Text) > 0)
{
FormAccount fa = new FormAccount();
fa.Show();
this.Hide();
}
else
{
MessageBox.Show("Неверное имя пользователя или пароль!");
}
}
private void button2_Click(object sender, EventArgs e)
{
Application.Exit();
}
}
class ApiAdapter
{
public String domain = "";
public static int userId = 0;
public static String userName = "";
public static String password = "";
public static String fullName = "";
public int login(String login, String password)
{
ReqParam p1 = new ReqParam();
p1.name = "login";
p1.value = login;
ReqParam p2 = new ReqParam();
p2.name = "password";
p2.value = password;
ReqParam p3 = new ReqParam();
p3.name = "type";
p3.value = "json";
List<ReqParam> pl = new List<ReqParam>(0);
pl.Add(p1);
pl.Add(p2);
pl.Add(p3);
JObject lr = this.getRequest("/login/login", pl);
String r = lr.GetValue("result").ToString();
if (r == "True")
{
ApiAdapter.userId = Convert.ToInt32(lr.GetValue("userId").ToString());
ApiAdapter.userName =
lr.GetValue("login").ToString();
ApiAdapter.fullName =
lr.GetValue("fullName").ToString();
}
return ApiAdapter.userId;
}
public JObject getRequest(String uri, List<ReqParam>
pl)
{
String url = this.domain + uri + "?";
for (int i = 0; i < pl.Count; i++)
{
if (i > 0)
url += "&";
url += (pl[i].join());
}
HttpWebRequest request =
(HttpWebRequest)HttpWebRequest.Create(url);
try
{
HttpWebResponse responce =
(HttpWebResponse)request.GetResponse();
if (responce.StatusCode != HttpStatusCode.OK)
{
return null;
}
using (StreamReader sr = new
StreamReader(responce.GetResponseStream()))
{
String json = sr.ReadToEnd();
JObject jObject = JObject.Parse(json);
return jObject;
}
}
catch
{
return null;
}
}
}
public class CertCenterModel
{
public int id = 0;
public String name = "";
public String ocspUrl = "";
}
public class CertificateModel
{
public int id = 0;
public String fullName = "";
public int centerId = 0;
public String position = "";
public String companyName = "";
public String INN = "";
public String KPP = "";
public int fileId = 0;
public String fileUrl = "";
}
public class SignatureModel {
public int id = 0;
public String name = "";
public String url = "";
public String signatureUrl = "";
public int signatureId = 0;
}
public class ReqParam
{
public String name = "";
public String value = "";
public String join()
{
return this.name + "=" + this.value;
}
}
public class NetworkChecker
{
public Boolean checkNetwork()
{
Boolean res = true;
try
{
IPHostEntry entry =
Dns.GetHostEntry("dns.msftncsi.com");
if (entry.AddressList.Length == 0)
{
return false;
}
else
{
if
(!entry.AddressList[0].ToString().Equals("131.107.255.255"))
{
return false;
}
}
}
catch
{
return false;
}
// Проверить загрузку документа ncsi.txt
{
HttpWebResponse responce =
(HttpWebResponse)request.GetResponse();
if (responce.StatusCode != HttpStatusCode.OK)
{
return false;
}
using (System.IO.StreamReader sr = new
StreamReader(responce.GetResponseStream()))
{
if (sr.ReadToEnd().Equals("Microsoft NCSI"))
{
return true;
}
else
{
return false;
}
}
}
catch
{
return false;
}
return res;
}
}