38
отраслевые, используемые в рамках одной отрасли;
региональные, действующие на территории региона;
системные, принятые отдельным предприятием (организацией).
Назначение классификатора [8, 25]:
систематизация наименований кодируемых объектов;
однозначная интерпретации одних и тех же объектов в различных за-
дачах;
возможность обобщения информации по заданной совокупности при-
знаков;
возможность сопоставления одних и тех же показателей, содержащих-
ся в формах статистической отчетности;
возможность поиска и обмена информацией между различными внут-
рифирменными подразделениями и внешними информационными системами;
экономия памяти компьютера при размещении кодируемой информа-
ции.
В данной работе будет использоваться системный классификатор, содер-
жащий информацию, необходимую для решения задач в конкретной ИС и отсут-
ствующую в национальном или отраслевом классификаторе. В качестве класси-
фикатора будет использована система кодирования (номера заявок, артикул и
т.п.).
Разработка информационного обеспечения задачи включает подготовку
документов, содержащих информацию, необходимую для решения задачи авто-
матизации. Анализ этой информации позволит произвести формализацию дан-
ных, с целью их однозначного определения для хранения, поиска и обработки во
внутримашинной сфере.
Информационное обеспечение разрабатываемого ПО должно содержать
базу данных, справочники, виды и формы отчетов, участвующих в документо-
обороте. Информационное обеспечение должно удовлетворять следующим ос-
новным требованиям [31]:
быть необходимым и достаточным для выполнения всех автоматизиру-
емых функций (задач);
39
информационная база данных должна быть организована в виде нор-
мализованных массивов данных на машинных носителях;
применяемые в формах документов термины и сокращения должны
быть, общепринятыми в данной предметной области;
должны быть предусмотрены необходимые меры по контролю и об-
новлению данных в информационных массивах, а также по контролю идентич-
ности одноименной информации в различных базах данных;
доступ к информации должен быть максимально облегчен;
информация должна быть достоверной и актуальной;
информация должна быть достаточно полной и отвечать пожеланиям
оператора.
Оптимальным выбором хранения данных для решения данной задачи бу-
дет использование СУБД. В данной работе предполагается использование кли-
ент-серверного приложения, для удобства работы нескольких пользователей од-
новременно. При проектировании базы данных использовался реляционный
подход, обладающий преимуществами в простоте проектирования.
1.4.2. Обоснование проектных решений по программному обеспечению
Для
потребуются
решения задач автоматизации, необходимо использование
необходимостьнее было АРПАаапапаапаааппапапанеоаппарлдоло
специали-
зированного
данных
ПО. Для
информация
моделирования бизнес-процессов
которых
было использовано
CASE-средство Ramus
цельюК оьаппаор
,
десятки
поддерживающее нотацию IDEF0.
Для разработки базы данных была выбрана СУБД MS Access 2010 -
Microsoft Access – система управления базами данных, которую фирма Microsoft
неизменно включает в состав профессиональной редакции Microsoft Office.
СУБД Access занимает одно из ведущих мест среди систем для проектирования,
создания и обработки баз данных и обладает следующими достоинствами [5, 29]:
хранение всех данных в одном файле, как и положено реляционной
СУБД;
широкие возможности по импорту/экспорту данных в различные фор-
маты, от таблиц Excel и текстовых файлов, до практически любой серверной
СУБД через механизм ODBC;
40
наличие развитых встроенных средств разработки приложений. Боль-
шинство приложений, распространяемых среди пользователей, содержит тот или
иной объем кода VBA (Visual Basic for Applications);
совместимость со современными объектно-ориентированными языка-
ми программирования.
Для разработки ПО была выбрана среда Borland Delphi 7, обладающая та-
кими преимуществами как стабильность, скорость и заниженность требований к
аппаратному обеспечению. Причин для выбора Delphi в качестве инструмента
разработки более чем достаточно. Основными из них являются [5, 14, 29]:
объектно-ориентированная среда разработки;
быстрый компилятор с естественным кодом;
интегрированный отладчик;
наличие совершенных двусторонних инструментов;
наличие собственной СУБД «Database»;
непосредственный доступ к интерфейсу API.
Возможности Delphi полностью отвечают поставленным в работе требо-
ваниям и подходят для создания системы любой сложности. Система Delphi поз-
воляет писать небольшие программы и утилиты для персонального использова-
ния, а также корпоративные системы, работающие с базами данных на разных
платформах, включая свою собственную. Delphi 7 имеет расширенную поддерж-
ку баз данных (по специальным наборам данных ADO и InterBase), версию
MIDAS с поддержкой Интернета, инструмент управления версиями TeamSours,
возможности перевода, концепцию фреймов.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение, допустимое к использованию в БД должно
представлять собой комплекс взаимосвязанных технических средств, обеспечи-
вающих процессы сбора, регистрации, передачи, обработки, отображения и хра-
нения информации. При этом комплекс взаимоcвязанных технических средств
должен основываться на единой технологической платформе.
Комплекс технических средств должен иметь, возможность расширения
(замены) состава технических средств, входящих в комплекс, для улучшения их
41
эксплуатационно-технических характеристик по мере возрастания объемов об-
рабатываемой информации, расширения функций БД.
Технические средства, используемые в БД должны обеспечивать возмож-
ность использования наиболее распространенных в России программных про-
дуктов для решения задач: накопления и анализа информации, резервирования
информации и так далее.
Комплекс технических средств должен включать средства резервирования
и восстановления данных, должен легко адаптироваться к изменению числа
пользователей (терминалов и рабочих станций).
Для правильного
вызывает
функционирования ПО потребуются наличие рабочей
станции со следующими минимальными характеристиками
программпараметрампара
:
IntelPentiumII/233 МГц и выше;
ОС MicrosoftWindows XP/Vista/7/8/10.
64 Мб ОЗУ (рекомендуется 128 Мб);
монитор с разрешением SVGA или выше;
клавиатура, мышь или другой манипулятор.
Объем дискового пространства будет зависеть от размера базы данных.
Для печати отчетности необходим принтер (с любыми техническими ха-
рактеристиками, аппаратно и программно совместимыми с ПК).
Дополнительных требований
хран
к составу и параметрам
защиту
технических средств
информация
не предъявляется, все
выделяют
устройства должны
выбор
находиться в своей
разработкой
базовой парамет-
рической
реализации
настройке.
42
2. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Процессы жизненного цикла проекта автоматизации
Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии созда-
ния» выделяют следующие этапы создания АС [2]:
1. Формирование требований к АС. Этап включает предпроектное обсле-
дование: сбор исходных данных, анализ информационных потоков, обоснование
необходимости автоматизации.
2. Разработка концепции АС. Этап включает разработку вариантов кон-
цепции АС, удовлетворяющих требованиям пользователя, выбор варианта стра-
тегии автоматизации.
3. Формирование технического задания и графика проведения работ.
4. Эскизный проект. На данном этапе определяют: функции АС; функции
подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; кон-
цепции информационной базы, ее укрупненную структуру; функции системы
управления базой данных; состав вычислительной системы; функции и парамет-
ры основных программных средств.
5. Технический проект. На данном этапе обеспечивают разработку общих
решений по системе и ее частям, функционально-алгоритмической структуре
системы, по функциям персонала и организационной структуре, по структуре
технических средств, по алгоритмам решений задач и применяемым языкам, по
организации и ведению информационной базы, системе классификации и коди-
рования информации, по программному обеспечению.
6. Рабочая документация. На данном этапе осуществляют разработку ра-
бочей документации, содержащей все необходимые и достаточные сведения для
обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а
также для поддерживания уровня эксплуатационных характеристик (качества)
системы в соответствии с принятыми проектными решениями, ее оформление,
согласование и утверждение. Виды документов по ГОСТ 34.201 [1].
7. Ввод в действие. На данном этапе проводят работы по организационной
подготовке объекта автоматизации к вводу АС в действие, в т.ч.: реализацию
проектных решений по организационной структуре АС; обеспечение подразде-
43
лений объекта управления инструктивно-методическими материалами; внедре-
ние классификаторов информации; обучение персонала и проверку его способ-
ности обеспечить функционирование АС; обеспечивают получение комплекту-
ющих изделий серийного и единичного производства, материалов и монтажных
изделий. Проводят входной контроль их качества, выполнение работ по строи-
тельству специализированных зданий (помещений) для размещения технических
средств и персонала АС; сооружение кабельных каналов; выполнение работ по
монтажу технических средств и линий связи; испытание смонтированных техни-
ческих средств; сдачу технических средств для проведения пусконаладочных
работ. Проводят загрузку информации в базу данных и проверку системы ее ве-
дения; комплексную наладку всех средств системы. Осуществляют испытания
АС на работоспособность и соответствие техническому заданию в соответствии
с программой и методикой предварительных испытаний; устранение неисправ-
ностей и внесение изменений в документацию на АС; оформление акта о прием-
ке АС в опытную эксплуатацию. Проводят опытную эксплуатацию, оформление
акта о приемке АС в постоянную эксплуатацию.
8. Сопровождение АС. На данном осуществляют работы по устранению
недостатков, выявленных при эксплуатации АС в течение установленных гаран-
тийных сроков; внесению необходимых изменений в документацию на АС; ана-
лизу функционирования системы; выявлению отклонений фактических эксплуа-
тационных характеристик АС от проектных значений; установлению причин
этих отклонений; устранению выявленных недостатков и обеспечению стабиль-
ности эксплуатационных характеристик АС; внесению необходимых изменений
в документацию на АС.
Помимо этапов разработки АС необходимо выбрать структуру, определя-
ющую последовательность выполнения и взаимосвязи процессов, действий и за-
дач, выполняемых на протяжении всего жизненного цикла АС – модель.
Модель будет зависеть от специфики АС и специфики условий, в которых
последняя создается и функционирует. Среди известных моделей жизненного
цикла можно выделить следующие [3, 8, 9]:
каскадная модель,
позволяет
в которой переход
после
на следующий этап
каскадной
означает
полное
существует
завершение работ
защиты
на предыдущем этапе.
расчета
Каждый
опытная
этап завершается
этапы
вы-
44
пуском полного
необходимо
комплекта документации,
могут
достаточной для
месте
того, чтобы
специфики
разра-
ботка могла
тестир
быть продолжена
необнаружения
другой командой
которой
разработчиков. Реальный
месте
про-
цесс создания
быстрый
ПО ИС трудно уложить в
прежде
такую жёсткую
постепенное
схему, т.к. возникают
возможность
потребности возврата
основным
к предыдущим этапам;
поэтапная модель
опытная
с итерационными возвратами
этапе
на предыдущие этапы
мость
после выполнения
необходимо
очередного этапа устраняет
ствующую
недостатки вышеописанной
постепенное
мо-
дели. Межэтапные корректировки
быстрый
позволяют уменьшить
возможно
трудоёмкость процесса
качестве
разработки по сравнению
хотя
с каскадной моделью;
спиральная
была
модель, в
расчета
которой
мость
особое внимание
могут
уделяется начальным
этапы
этапам разработки:
быстрый
анализу и проектированию. Основным
этапе
принципом данной
узким
модели является углубление и
каскадной
последовательная конкретизация
опытная
деталей проекта,
специфики
и в результате чего,
узким
выбирается обоснованный
ствуют
вариант, который
возможные
доводится до
реализации.
Выбор
необнаружения
модели зависит от
реально
специфики разрабатываемого ПО и специфики
реально
условий, в которых последняя создается
защиты
и функционирует. Для разработки ПО
выбирается
ПОППОО
была
месте
выбрана спиральная
межэтапные
модель жизненного
узким
цикла, так
возможность
как она
некорректная
наиболее ре-
ально
качестве
отображает разработку
избежание
программного обеспечения
была
и позволяет учитывать
выбирается
риски на каждом
выбор
витке эволюции
позволяет
разработки ПО.
После
каскадной
проектирования и разработки ПО
месте ПО
следует этап
качестве
внедрения. Суще-
ствуют
тестир
разные стратегии
была
реализации данного
некорректная
этапа, такие
плексе
как [9]:
параллельная стратегия, постепенное подразумевающая постепенное
которой внедрение новой которой системы, при возможность одновременной
работе могут старой;
«скачок» – быстрый
после
переход от использования
пользованию
старой системы
существует
к ис-
пользованию новой,
качестве
с полным отказом
сосредоточение
от использования старой
быстрый
системы;
опытная эксплуатация
межэтапные
пилотного проекта – эта
этапе
стратегия «скачка»,
которой
применяемая лишь
быстрый
к части бизнес-процессов;
«узкое
возможные
место» – стратегия
могут
предполагает сосредоточение
детализировать
на «узком»
месте
детализировать
производственного процесса.
Для
техническим
внедрения разрабатываемого
зволяет
ПО была
некорректная
выбрана стратегия «узкое
данный
ме-
сто», предусматривающая сосредоточение
конкретизация
на «узком» месте
возможные
производственного
процесса,
пользованию
так как
внедрения
данный проект
быстрый
автоматизирует процесс,
хотя
связанный с работой
избежание
45
менеджера по продажам,
возможные
и узким местом
пользованию
является скорость
последняя
ручной обработки
заявок
постепенноезая
.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
На
существует
каждом этапе
плексе
жизненного цикла ПО
каскадной
могут возникать
детализировать
некоторые риски.
Ниже
расчета
приведены этапы
была
ЖЦ ПО и возможные риски.
На
опытная
этапе выработке
возможность
стратегии возможен
защиты
риск ошибочного
выбирается
расчета сроков
техническим
проекта и его
конкретизация
бюджета, некорректный
могут
подбор состава
специфики
группы исполнителей.
Во
детализировать
избежание такого
техническим
роды рисков
месте
необходимо провести
межэтапные
тщетный анализ
узким
предметной области,
детализировать
более детально
инструментарий
проработать задачи
инструментарий
проекта.
На этапе
возможно
планирования может
прежде
быть возникновение
выбор
риска неграмотного
специфики
выбора архитектуры
данный
решения задачи,
этапы
некорректной модели
последняя
проектирования, не-
корректная
опытная
разработка технического
плексе
задания. Минимизировать
защиты
такого рода
ствующую
рис-
ки возможно
опытная
лишь корректным
выбор
подбором специалистов
месте
в данной области.
На
узким
этапе разработки
необнаружения
возможны следующие
последняя
риски:
неправильная интерпретация
расчета
технического задания;
возможность
расчета
внесения случайных
избежание
ошибок в код
некорректная
программы;
неправильно подобранный
пользованию
инструментарий для
позволяет
разработки.
Для снижения
выбрана
подобных рисков
мость
необходимо на этапе
возможность
проектирования и
составления
более
технического задания
техническим
более подробно
специфики
описывать и детализировать
могут
задачи создания
техническим
АС. Помочь
данный
избежать случайных
некорректная
ошибок может
после
этап тестиро-
вания ПО. Хотя
постепенное
и на данном этапе
основным
могут возникнуть
более
риски необнаружения оши-
бок. Для
части
этого необходимо
хотя
детально проработать
пользованию
тестовые стенды
кументов
и задания.
На этапе
возможно
внедрения также
была
могут возникнуть
качестве
такие риски
после
как, несовмести-
мость
выбор
с существующей программно-аппаратной
этапы
платформой, нагрузка
опытная
на суще-
ствующую систему. Снизить
выбрана
такого рода
некорректная
риски можно
мость
детальной проработкой
существует
документации по техническим
была
и программным требованиям
выбирается
к работе ПО.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
В качестве организационных мер обеспечения безопасности в ООО «Си-
бирь-Профиль-Красноярск» существуют инструкции безопасности при работе с
46
ПК. Каждому сотруднику присваивается уникальный логин и пароль для входа в
ОС, поэтому система способна распознать конкретного пользователя.
Для защиты данных от угроз внешнего характера используется:
антивирус Kaspersky Endpoint Security (стандартный) предназанчен
для перекрытия возможных каналов распространения вредоносного ПО, непре-
рывного антивирусного мониторинга и автоматического реагирования на руше-
ние режима безопасности;
автоматическое обновление ПО и ОС;
proxy-сервер, ограничивает входящую и исходящую скорость (кроме
почтовых сообщений), запрещает скачивание файлов без подтверждения пользо-
вателей, запрещает загрузку сайтов с баннерами и рекламой;
Физическая безопасность обеспечивается интегрированной системой ви-
деонаблюдения и охранно-пожарной сигнализацией.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Для построения информационной модели было изучено существующее
ПО, решающее задачи автоматизации предметной области. На основании прове-
денных исследований получены следующие основные элементы информацион-
ной модели (рисунок 2.1).
Основой информационной модели является база данных, включающая в
себя несколько таблиц, содержащих сведения о клиентах, товаре, заявках и ме-
неджерах.
47
Рисунок 2.1 – Информационная модель
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
Входной информацией для ПО является:
сведения о клиентах;
сведения о товаре;
сведения о заявках.
Сведения о клиентах включают ФИО клиента (для физических лиц) или
наименование юридического лица, контактный номер телефона, e-mail, реквизи-
ты.
Сведения о товаре включают:
артикул;
наименование;
материал;
наполнение;
дизайн;