Дипломная работа: Автоматизация управления процессом отгрузки товара в компании ООО "Мебельград"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
44
II.
Проектная часть
2.1. Разработка проекта автоматизации
2.1.1.
Этапы жизненного цикла проекта автоматизации
Жи з н ен н ый ци к л (да л ее п о т ек ст у – ЖЦ) – п ер и о д в р ем ен и , к о т о р ый н
а чи н а ет ся с п р и н ят и я р ешен и я о со з да н и и п р о гр а м м н о го о бесп ечен и я и з а
к а н чи в а ет ся в м о м ен т и з ъят и я его и з э к сп л уа т а ци и . Н а и бо л ее о п т и м а л ьн ым в а
р и а н т о м яв л яет ся м еждун а р о дн ый ст а н да р т ISO/IEC 12207:2008. В н а ст о ящее в р
ем я э т о т ст а н да р т яв л яет ся о сн о в н ым м еждун а р о дн ым до к ум ен т о м в о бл а ст и со з
да н и я и р а з в и т и я п р о гр а м м н ых продуктов.
Жизненный цикл информационной системы можно представить как череду
событий, происходящих с данной системой от процессе ее создания до утилизации. В
данный момент известны и используются такие модели жизненного цикла, как:
−
каскадная модель предусматривает поэтапное выполнение всех пунктов
проекта в строгой последовательности. Переход к следующему этапу означает, что
работы на предыдущем были завершены полностью;
−
поэтапная модель с промежуточным контролем. Разработка
информационной системы происходит итерациями обратной связью между всеми
этапами. Данные связи позволяют проводить корректировки и учитывать реально
существующее значение взаимовлияние результатов разработки на любом этапе; время
жизни любого из этапов продлевается на весь период разработки информационной
системы;
−
цикличная модель. На каждом витке создается очередная версия готово
продукта, уточняются все требования проекта, так же определяется его качество, далее
выявляются потребности, и в конечном счете планируются работы следующего цикла.
Пристальное внимание уделяется таким этапам разработки, как анализ и
проектирование, где реализация тех или иных решений проверяется и обосновывается
посредством создания прототипов (макетирования).
В настоящее время распространены несколько стандартов, в которых
описываются жизненные циклы информационной системы:
•
ГОСТ 33707-2016– стандарт распространяется на автоматизированные
системы, применяемые в разных видах деятельности, включая их
45
сочетания, создаваемые в компаниях. Стандарт определяет этапы и
стадии разработки автоматизированной системы;
•
ISO 12207 – стандарт используется при приобретении систем,
программных продуктов и предоставления соответствующих услуг (сопровождение,
внедрение). А также при поставке, создании, эксплуатации и сопровождении
программных систем и программных компонентов программно-аппаратных средств
внутри организации и вне ее;
•
ISO 15288 – стандарт регламентирует общие основы процессов, которые
составляют жизненной цикл систем, разработанных человеком;
•
RUP (Rational Unified Process – рациональный унифицированный процесс)
– это метод разработки ПО, созданная и распространяемая корпорацией Rational
Software. Она описывает упорядоченный способ распределения задач и обязанностей
в организации-разработчике;
•
XP (eXtreme Programming) – метод содержит в себе совершенно другие
базовые принципы, в отличие от RUP. Главными чертами данного метода являются
установление точных кратковременных планов, постоянное перепланирование,
непосредственное общение с заказчиком. Данная модель больше подходит для
инновационных и полуисследовательских проектов;
•
MSF (Microsoft Solutions Framework – метод создания программных
решений) – В модели процессов приводится общее описание организации работ над
проектом по разработке и внедрению ИТ-решений.
В этом проекте следует использовать стандарт ГОСТ 33707-2016 и каскадную
модель. Данной методологии будет достаточно. Выбираем стратегию внедрения узкое
место.
2.1.2.
Ожидаемые риски на этапах жизненного цикла и их описание
В процессе жизненного цикла ИС могут возникнуть риски, способные
саботировать разработку. Для минимизации негативных последствий проводится
оценка рисков и разрабатываются способы, позволяющие выявить риски на начальном
этапе или минимизировать их последствия.
Существуют различные типы моделей ЖЦ ИС, и разные компании могут
использовать наиболее удобные для себя подходы.
46
Каждая из приведенных стадий несет в себе определенный набор угроз, которые
должны быть своевременно учтены и обработаны. Наиболее распространенные
угрозы:
−
неверная формулировка требований к ИС;
−
неадекватный выбор процессов жизненного цикла и вовлеченных в
данные процессы участников;
−
принятие неверных решений при разработке проектаа;
−
внесение разработчиком дефектов (уязвимости «нулевого дня») на уровне
архитектурных решений;
−
внесение разработчиком возможностей, которые незадокументированны в
информационной системе в целом или в ее отдельные компоненты;
−
неадекватная (неполная, противоречивая и пр.) реализация
предъявленных к ИС требований;
−
сборка ИС с нарушением предъявляемых требований, приводящая к
появлению недокументированных возможностей в информационной системе, либо к
некорректной реализации требований;
−
разработка некачественной документации;
−
неверное конфигурирование ИС;
−
приемка ИС, не отвечающей требованиям, установленным в компании;
−
внесение недокументированных возможностей в информационную
систему в процессе проведения тестовых испытаний, посредством применения
скрытых возможностей функциональных тестов.
Безопасность при разработке ИС может быть обеспечена следующими мерами:
1.
Определение процедур разработки ИС. С целью снижения вероятности
возникновения проблем с безопасностью заранее должны быть определены методы и
средства разработки. Они должны охватывать все используемые языки
программирования.
2.
Организация среды разработки. Для организации безопасного процесса
разработки рекомендуется выделить рабочие места ответственных лиц в отдельный
защищенный сетевой сегмент, обеспечить рабочие места средствами антивирусной
безопасности и защиты от НСД, использовать "чистую" лицензионную политику. Эти
47
простые меры позволят значительно снизить риски несанкционированного доступа и
изменения кода посторонними лицами.
3.
Обучение персонала методам безопасной разработки. Понимание проблем
безопасности современных приложений и новых способов атак крайне необходимо для
создания защищенной ИС, поэтому проведение тренингов по ИБ для разработчиков
может существенно повысить качество и безопасность ИС.
4.
Анализ и тестирование исходных кодов на наличие уязвимостей и
недекларированных возможностей. Исходные коды должны периодически
анализироваться с помощью автоматизированных средств или в ручном режиме на
наличие распространенных ошибок, в том числе: межсайтовый скриптинг,
переполнение буфера, ошибки при проверке входных данных для обработки, ошибки
в процессе обработки данных, пароли в открытом виде и т.д. Альтернативным
решением может стать использование услуг третьих сторон по анализу кода на
уязвимость.
5.
Разработка (получение) документации на ИС. Документация на ИС должна
включать описание применяемых защитных мер и функций, описанных в техническом
задании. С точки зрения ИБ документация как минимум должна содержать:
−
описание ролевой системы;
−
описание механизмов доступа, регистрации событий, целостности,
резервирования;
−
параметры настроек безопасности.
Помимо указанных выше требований по обеспечению безопасной разработки и
поставки ИС, на поставщика должна быть возложена ответственность на случай
возникновения каких-либо инцидентов, связанных с некачественной разработкой,
нарушением правил поставки и пр. Также следует учитывать наличие у разработчика
необходимых лицензий на разработку и эксплуатацию средств и систем защиты.
2.1.3.
Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер для защиты информации в разрабатываемой инфомрационной
системе должен включать в себя следующие параметры:
48
−
защита информации непосредственно в самой информационной системе
от всевозможных внутренних угроз;
−
защита информации ИС от различных внешних угроз.
Для обеспечения защиты от внутренних угроз в данной информационной
системе применяется разделения прав доступа. Права доступа к информации
приведены в таблице 5.
Таблица 5
Разграничение прав пользователей
Группы
пользовател
ей
Модуль
«Авториза
ция»
Модуль
«Регистрация
документа»
Модуль
«Постановка
на контроль»
Модуль
«Резолюция»
Сотрудники
Чтение
Полный
Чтение
Ограничен
Руководитель
Чтение
Нет
Полный
Полный
Администра-
тор системы
Полный
Полный
Полный
Полный
Защита от внешних угроз в данной ИС осуществляется по средствам применения
следующих механизмом:
−
использованием различных программно-аппаратных комплексов защиты;
−
разработка, соблюдение и контроль за выполнением политик
безопасности;
−
применять защиту каналов связи при передаче конфиденциальной
информации;
−
использовать различные антивирусные средства как на рабочих станция,
так и на серверах;
−
применять средства для физической защиты помещений с информацие
явяляющейся коммерческой тайной ценной от несанкционированного доступа.
2.2. Информационное обеспечение задачи
2.2.1.
Информационная модель и её описание
Информационная модель – это совокупность информации об объекте,
описывающая свойства и состояние объекта, процесса или явления, а также связи и
отношения с окружающим миром. Информационная модель необходимая для
реализации данной ИС представлена на рисунке 7.
Источник: https://baza.diplomsite.ru/previewfile/1676