45
Система передается в виде веб-сайта для установки на сервер Заказчика в
установленные сроки. Приемка системы осуществляется комиссией.
2. Назначение и цели создания системы
Для разработки информационной системы необходимо определить
список автоматизируемых функций и требований к системе.
Формализация процесса прохождения тендера строится следующим
образом: входной объект – заявки, управление – Федеральные законы РФ,
внутренние правила, механизм – информационная система. Выходные данные –
данные для архива и подписанные контракты.
Основные функции, которые предоставляет информационная система –
регистрация в системе, поиск вручную, автоматический поиск, оказание
дополнительных услуг, учет прохождения тендера, архивация.
Автоматический поиск подразумевает рекомендации пользователям,
предоставление информации о важных тендерах для компании, а также
отправление заявок на конкурсы и настройку электронной подписи в личном
кабинете. Функция оказания дополнительных услуг подразумевает
индивидуальный подход к пользователю, помощь при составлении заявки,
подготовку пакета документов. Функция формирования пакета документов
использует результаты предыдущих функций – результаты ручного и
автоматического поиска и оказанные дополнительные услуги. С помощью
функции архивации осуществляется анализ данных, который необходим для
работы функции автоматического поиска, кроме того, архивируются данные,
которые будут использованы в дальнейшей работе.
Информационная система проведения и архивации тендеров позволяет
совместить инструменты Internet-закупки с корпоративным регламентами и
нормами гражданского законодательства, а также автоматизирует рутинные
операции, ограничивая при этом действия персонала рамками служебных
полномочий, но внутри этих рамок давая ему полную свободу для принятия
46
решений. В такой системе, ядро которой включает подсистему управления
документами, основным понятием является электронный документ.
Работа с данными ведется через браузер: для каждой роли пользователя в
бизнес-процессе формируется свое автоматизированное рабочее место. С него в
соответствии с правами доступа можно вести различные операции – создавать,
корректировать, дополнять, подписывать документы (в том числе с
использованием ЭЦП), отзывать подпись, если бизнес-процесс это позволяет,
присоединять сопроводительные документы из файловой системы. Документ
предоставляется в виде, удобном для прочтения. Можно посмотреть кто и когда
создал документ, кто какие изменения внес, как менялся статус документа.
Создаваемая информационная система должна удовлетворять следующим
условиям функциональности:
а) представить веб-сервис, посредством которого будет передаваться
информация в систему;
б) обеспечить механизм криптографической защиты для передаваемых
документов с помощью программного обеспечения «КриптоПро»;
в) обеспечить логирование операций экспорт-импорт в системе;
г) разработать базу данных для обеспечения функционирования системы;
д) разработать windows-сервис, обеспечивающий передачу информации
по расписанию о состоянии тендеров;
е) обеспечить функционирование системы согласно регламенту
проведения тендеров.
2.1 Назначение ИС
Информационная система проведения и архивации тендеров позволяет
совместить инструменты Internet-закупки с корпоративным регламентами и
нормами гражданского законодательства, а также автоматизирует рутинные
операции, ограничивая при этом действия персонала рамками служебных
полномочий, но внутри этих рамок давая ему полную свободу для принятия
47
решений. В такой системе, ядро которой включает подсистему управления
документами, основным понятием является электронный документ.
Работа с данными ведется через браузер: для каждой роли пользователя в
бизнес-процессе формируется свое автоматизированное рабочее место. С него в
соответствии с правами доступа можно вести различные операции – создавать,
корректировать, дополнять, подписывать документы (в том числе с
использованием ЭЦП), отзывать подпись, если бизнес-процесс это позволяет,
присоединять сопроводительные документы из файловой системы. Документ
предоставляется в виде, удобном для прочтения. Можно посмотреть кто и когда
создал документ, кто какие изменения внес, как менялся статус документа.
2.2 Основная цель создания ИС
Централизованное управление доступом к приложениям, а так же легкость
и удобство использования веб-приложения пользователями.
2.3 Критерии оценки достижения целей создания системы
Обеспечение автоматизации бизнес-процессов по проведению и
архивации тендеров.
Удобство и простота использования веб-приложения в ходе
эксплуатации .
2.4 Основные задачи
Основные задачи, которые решает информационная система –
регистрация в системе, поиск вручную, автоматический поиск, оказание
дополнительных услуг, учет прохождения тендера, архивация.
3. Требования к ИС
3.1. Требования к системе в целом
Система должна быть простой и понятной пользователю.
Внедрение ИС должно привести к положительному
экономическому эффекту.
Использование ИС должно обеспечить высокую скорость
обработки информации.
48
3.2. Требования к функциям, которые должна выполнять система
Подсистемами системы проведения и архивации тендеров являются:
Подсистема поиска предоставляет пользователям возможность
осуществлять поиск и сортировку тендеров. Поиск может быть осуществлен с
помощью ручного метода, также возможен отбор конкурсов по необходимым
критериям в рекомендуемых системой тендерах.
Подсистема дополнительных услуг предоставляет пользователю
возможность выбрать необходимые для него услуги: составление заявки,
напоминание о сроках и изменении условий, подготовка пакета документов.
Подсистема прохождения тендера осуществляет работу по
взаимодействию установленной программы с государственными и
коммерческими площадками посредством интерфейса.
Подсистема динамической фильтрации осуществляет подбор
рекомендательных тендеров для компании. Основываясь на математических
методах и статистике, сформированной в системе архива.
Подсистема архива подразумевает хранение информации по сделкам и
клиентам, а также ее поиск в хранилище данных.
3.3. Требования к надежности
В системе должны быть предусмотрены средства защиты от некорректных
действий пользователя, вывод соответствующих сообщений.
3.4. Требования к эргономике и технической эстетике
Взаимодействие пользователей с программным обеспечением должно
осуществляться посредством визуального графического интерфейса.
Интерфейс системы должен быть понятным и удобным, не должен быть
перегружен графическими элементами. Навигационные элементы должны быть
выполнены в удобной для пользователя форме. Ввод-вывод данных системы,
прием управляющих команд и отображение результатов их исполнения должны
выполняться в интерактивном режиме. Интерфейс должен соответствовать
49
современным эргономическим требованиям и обеспечивать удобный доступ к
основным функциям и операциям системы.
Интерфейс должен быть рассчитан на преимущественное использование
сенсорных экранов (либо механической клавиатуры, если устройство обладает
таковым).
Все надписи и сообщения, выдаваемые пользователю (кроме системных
сообщений) должны быть на русском языке.
Система должна обеспечивать корректную обработку аварийных ситуаций,
вызванных неверными действиями пользователей, неверным форматом или
недопустимыми значениями входных данных. В указанных случаях система
должна выдавать пользователю соответствующие сообщения, после чего
возвращаться в рабочее состояние, предшествовавшее неверной
(недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований
унификации:
все экранные формы пользовательского интерфейса должны быть
выполнены в едином графическом дизайне, с одинаковым
расположением основных элементов управления и навигации;
для обозначения сходных операций должны использоваться
сходные графические значки, кнопки и другие управляющие
(навигационные) элементы. Термины, используемые для
обозначения типовых операций (добавление информационной
сущности, редактирование поля данных), а также
последовательности действий пользователя при их выполнении,
должны быть унифицированы;
внешнее поведение сходных элементов интерфейса (реакция на
нажатии сенсорной или механической кнопки, переключение
фокуса) должны реализовываться одинаково для однотипных
элементов.
50
4. Состав и содержание работ по созданию системы
Предпроектная стадия включает в себя:
определение требований заказчика;
разработка проекта ИС в соответствии с требованиями заказчика;
разработка технического задания в соответствии с ГОСТ 34.602–89.
Проектная стадия:
внедрение ИС;
сопровождение системы.
Исполнителями работ являются:
разработчик ИС.
Ответственный за выполнение всех работ по всем этапам является
разработчик ИС.
5. Порядок контроля и приемки системы
Сдача-приёмка работ производится в соответствии с разработанным
планом, в установленные сроки.
Все создаваемые в рамках настоящей работы программные изделия (за
исключением покупных) передаются Заказчику, как в виде готовых модулей,
так и в виде исходных кодов, представляемых в электронной форме на
машинном носителе.
6. Требования к составу и содержанию работ по подготовке
объекта автоматизации к вводу системы в действие
В ходе выполнения проекта на объекте автоматизации требуется
выполнить работы по подготовке к вводу системы в действие. При подготовке
Заказчик должен обеспечить выполнение следующих работ:
назначить ответственных должностных лиц, ответственных за
внедрение и проведение опытной эксплуатации ИС;
51
обеспечить соблюдение требований, предъявляемых к программно –
техническим средствам, на которых должно быть развернуто
программное обеспечение системы;
провести опытную эксплуатацию ИС.
Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие, включая перечень основных
мероприятий и их исполнителей должны быть уточнены на стадии подготовки
рабочей документации и по результатам опытной эксплуатации.
7. Требования к документированию
Документация оформляется согласно стандартам ЕСКД, ЕСПД и ГОСТ.
В процессе разработки ИС могут быть использованы стандарты
комплекса ГОСТ 19. ЕСПД.
ГОСТ 19.001. – 77. ЕСПД. «Общие положения»;
ГОСТ 19.006. – 82. ЕСПД. «Общие требования к программным
документам, выполненным печатным способом» и др.
Для системы на различных стадиях создания должны быть выпущены
документы из числа предусмотренных в ГОСТ 34.201–89 «Информационная
технология. Комплекс стандартов на автоматизированные системы»
Выводы по второй главе.
Во второй главе приведена общая характеристика предприятия. Описаны
основные бизнес-процессы по проведению тендерных закупок. Выявлены
основные задачи в бизнес-процессе, которые подлежат автоматизации. На
основании проведенного анализа были разработаны функциональные и
нефункциональные требования к проектируемой информационной системе,
которые были реализованы в виде технического задания.
52
Глава 3. Разработка программного обеспечения информационной системы
проведения и архивации тендеров
3.1. Разработка базы данных и интерфейса пользователя
Концептуальная модель данных представляет собой структурированное
бизнес-представление данных, необходимых для поддержки бизнес-процессов,
записи бизнес-событий и отслеживания связанных показателей
производительности. Эта модель фокусируется на идентификации данных,
используемых в бизнесе, но не на процессе обработки или физических
характеристиках данных. Перспектива этой модели не зависит от каких-либо
базовых бизнес-приложений. Например, она позволяет заинтересованным
сторонам просматривать данные о продажах, расходах, клиентах и продуктах -
бизнес-субъектах, которые находятся в интегрированной модели и вне самих
приложений.
Концептуальная модель данных представляет собой общую структуру
данных, необходимую для поддержки бизнес-требований, независимо от
программного обеспечения или структуры хранения данных. Характеристики
концептуальной модели данных включают в себя:
Общее представление о структуре данных в бизнес-контексте.
Функции, которые не зависят от какой-либо базы данных или
физической структуры хранения.
Объекты, которые могут никогда не быть реализованы в
физических базах данных. Существуют некоторые концепции и
процессы, которые не найдут свое отражение в моделях, но они
необходимы бизнесу, чтобы понять и объяснить, что нужно на
предприятии.
Данные, необходимые для выполнения бизнес-процессов или
операций предприятия.
Концептуальная модель данных - это инструмент для бизнеса и ИТ,
позволяющий определить:
53
Объем требований к данным.
Бизнес-термины и меры для разных бизнес-единиц и те, которые
согласованы для использования в масштабах всего предприятия.
Имена, типы данных и характеристики объектов и их атрибуты
Логическая модель данных или модель информационных систем - это
более структурированная интерпретация концептуальной бизнес-модели. Она
существует как механизм связи в более технических средах, которые
заполняются аналитиками и проектировщиками баз данных, а также
системными аналитиками и проектировщиками. Она более явна по своей
природе, чем концептуальная модель, и фокусируется на уровне детализации
сущностей и их отношений. Однако в логических моделях существуют те же
проблемы, что и в концептуальных. Модель должна быть беспристрастной к
тому, как данные используются и расположены таким образом, который
естественным образом связан, и что семантика (в меньшей степени в
логическом моделировании) важна.
Первый шаг - преобразовать концептуальную модель в нормальную
форму. Это означает, что модель оптимизирована с точки зрения
последовательности обработки сущностей: сущности, определенные простым и
стандартным способом, устранение избыточности в содержании сущности (без
перекрывающихся сущностей) и стабильность сущностей, как определено
соответствующей проблемной областью бизнеса.
Следующим шагом в этом процессе является разрешение любых
отношений «многие ко многим» путем определения объекта ассоциации. Этот
объект должен быть приписан всем элементам данных, которые уникально
связаны с интерфейсом объекта. Здесь необходимо предпринять
дополнительный шаг для всех объектов объединения. Он должен рассмотреть, с
целью нормализации, все вновь приписанные элементы данных. Особое
внимание должно быть уделено удалению повторяющихся групп.
54
Следующим шагом является определение тех элементов данных, которые
однозначно идентифицируют вхождение объекта. Таких идентификаторов
может быть много, называемых идентификаторами кандидатов. Все должно
быть задокументировано относительно содержания и структуры.
Сразу после того, как идентификаторы были определены, выбор
первичных идентификаторов должен быть сделан из списка кандидатов. Это
конкретные идентификаторы, которые однозначно идентифицируют единичное
вхождение объекта. Другие кандидаты не должны быть отброшены, поскольку
они являются жизнеспособными идентификаторами, которые могут
использоваться для других целей. Эти первичные идентификаторы могут
упоминаться как первичные ключи.
Следующий последовательный шаг - это атрибуты сущностей, которые
были определены и обозначены ключом. Процесс атрибуции состоит в том,
чтобы найти единственный, наиболее подходящий дом для элемента данных на
одном из присутствующих объектов. Если дом не найден, возможно, найден
новый объект. Если это происходит, предмет должен быть исследован и решен,
прежде чем продолжить. Атрибуция сильно зависит от семантического
определения элемента данных, а также от его характеристик. Они должны быть
правильными, иначе может произойти неправильное распределение (это будет
обнаружено позже, но зачем тратить время?).
Первичные ключи должны затем распространяться вниз на все зависимые
объекты (характеристики и объекты ассоциации) в качестве внешних ключей.
Большие (много столбцов) ключи должны быть отмечены для оценки в
физическом переводе. Объединение ключей будет необходимо в объектах
ассоциации. Все уникальные атрибуты от родительских объектов (супертипы)
распространяются на объекты категории (подтипы) иерархий обобщения. Это
также должно быть сделано для любых агрегатов, участвующих в модели. Это
очень важно для выполнения, так как дальнейший анализ в области проблем
бизнеса может указывать на то, что следует сохранить только родительский