Дипломная работа: Автоматизированная система и учета ремонта компьютерного оборудования в компании ООО "Талес"
Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
51
2.1.
2.1.1.
Жизненный цикл (далее по тексту – ЖЦ) – период времени, который
начинается с принятия решения о создании программного обеспечения и
заканчивается в момент изъятия его из эксплуатации [1].
Понятие жизненного цикла (ЖЦ) ИС является одним из базовых в
программной инженерии. Жизненный цикл ИС определяется как период
времени, который начинается с момента принятия решения о необходимости
создания ИС и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим состав процессов
жизненного цикла, является международный стандарт ISO/IEаC 12207:
“Information Techаnology – Software Life Cyаcle Processes”. ISO – Internаtional
Organization for Standardizаtion – Международная организация по
стандартизации, IEC – Internаtional Electrotechnical Commission –
Международная комиссия по электротехнике. Данный стандарт определяет
структуру жизненного цикла, содержащую процессы, действия и задачи,
которые должны быть выполнены во время создаания ИС.
Наиболее оптимальным вариантом является международный стандарт
ГОСТ Р 12207-2010. В настоящее время этот стандарт является основным
международным документом в области создания и развития программных
продуктов [1].
Жизненный цикл информационной системы можно представить как
череду событий, происходящих с данной системой от процессе ее создания до
утилизации. В данный момент известны и используются такие модели
жизненного цикла, как:
каскадная модель предусматривает поэтапное выполнение всех
пунктов проекта в строгой последовательности. Переход к следующему этапу
означает, что работы на предыдущем были завершены полностью;
52
поэтапная модель с промежуточным контролем. Разработка
информационной системы происходит итерациями обратной связью между
всеми этапами. Данные связи позволяют проводить корректировки и учитывать
реально существующее значение взаимовлияние результатов разработки на
любом этапе; время жизни любого из этапов продлевается на весь период
разработки информационной системы;
цикличная модель. На каждом витке создается очередная версия
готово продукта, уточняются все требования проекта, так же определяется его
качество, далее выявляются потребности, и в конечном счете планируются
работы следующего цикла. Пристальное внимание уделяется таким этапам
разработки, как анализ и проектирование, где реализация тех или иных
решений проверяется и обосновывается посредством создания прототипов
(макетирования).
Для реализации данного проекта необходимо и достаточно использовать
каскадную модель.
Выбор стратегии внедрения
1) Параллельная стратегия — для случая, когда старую работающую
систему необходимо заменить новой.
2) Скачок означает, что прежняя система работала еще в пятницу а в
понедельник начала работать по новой системе [18].
Если данные не столь точные, как хотелось бы, если люди не обучены,
тогда есть риск ввергнуться в хаос, сорвать поставки и финансовые расчеты.
3) Опытная эксплуатация пилотного проекта — это тактика скачка, но
применяемая к ограниченному числу изделий. Область применения стратегии
— малый участок деятельности. Такой подход наиболее надежен, он снижает
риск, и сегодня практически все фирмы применяют эту тактику.
4) Узкое место — это наиболее критичная малая часть
производственного процесса. При внедрении узкого места план внедрения
выполняется только для узкого места и для людей, работающих в нем.
53
При стратегии узкого места объем работ уменьшается значительно, и при
заданных ресурсах узкое место может быть завершено в более короткие сроки,
чем внедрение во всей фирме.
Свойство этой стратегии — сосредоточение на узком месте в
производственном процессе — упрощает внедрение.
Узкое место служит испытательным полигоном для дальнейших работ.
Оно может явиться успешным примером, помогающим внедрению во всей
фирме.
Выбираем стратегию внедрения узкое место.
В ходе жизненного цикла информационной системы всегда могут
возникнуть риски, могущие сорвать разработку. Для их избежания проводится
оценка вероятных рисков и разрабатываются способы, позволяющие избегнуть
эти риски или минимизировать их влияние.
Существуют различные типы моделей ЖЦ ИС, и разные компании могут
использовать наиболее удобные для себя подходы.
Каждая из приведенных стадий несет в себе определенный набор угроз,
которые должны быть своевременно учтены и обработаны. Наиболее
распространенные угрозы:
неверная формулировка требований к ИС;
неадекватный выбор процессов ЖЦ и вовлеченных в них участников;
принятие неверных проектных решений;
внесение разработчиком дефектов на уровне архитектурных решений;
внесение разработчиком недокументированных возможностей в ИС в
целом или в ее отдельные компоненты;
неадекватная (неполная, противоречивая и пр.) реализация
предъявленных к ИС требований;
54
сборка ИС с нарушением предъявляемых требований, приводящая к
появлению недокументированных возможностей в ИС либо к неадекватной
реализации требований;
разработка некачественной документации;
неверное конфигурирование ИС;
приемка ИС, не отвечающей требованиям, установленным в компании;
внесение недокументированных возможностей в ИС в процессе
проведения приемочных испытаний посредством использования
недокументированных возможностей функциональных тестов и тестов ИБ [16].
Безопасность при разработке ИС может быть обеспечена следующими
мерами:
1. Определение процедур разработки ИС. С целью снижения вероятности
возникновения проблем с безопасностью заранее должны быть определены
методы и средства разработки. Они должны охватывать все используемые
языки программирования (C++, JavaScript, SQL и пр.).
2. Организация среды разработки. Для организации безопасного процесса
разработки рекомендуется выделить рабочие места ответственных лиц в
отдельный защищенный сетевой сегмент, обеспечить рабочие места средствами
антивирусной безопасности и защиты от НСД, использовать "чистую"
лицензионную политику. Эти простые меры позволят значительно снизить
риски несанкционированного доступа и изменения кода посторонними лицами.
3. Обучение персонала методам безопасной разработки. Понимание
проблем безопасности современных приложений и новых способов атак крайне
необходимо для создания защищенной ИС, поэтому проведение тренингов по
ИБ для разработчиков может существенно повысить качество и безопасность
ИС.
4. Анализ и тестирование исходных кодов на наличие уязвимостей и не
декларированных возможностей. Исходные коды должны периодически
анализироваться с помощью автоматизированных средств или в ручном режиме
55
на наличие распространенных ошибок, в том числе: межсайтовый скриптинг,
переполнение буфера, ошибки при проверке входных данных для обработки,
ошибки в процессе обработки данных, пароли в открытом виде и т.д.
Альтернативным решением может стать использование услуг третьих сторон
по анализу кода на уязвимость.
5. Разработка (получение) документации на ИС. Документация на ИС
должна включать описание применяемых защитных мер и функций, описанных
в техническом задании. С точки зрения ИБ документация как минимум должна
содержать:
• описание ролевой системы;
• описание механизмов доступа, регистрации событий, целостности,
резервирования;
• параметры настроек безопасности.
При приобретении ИС необходимо уделить особое внимание
оформлению договорных обязательств. Помимо указанных выше требований
по обеспечению безопасной разработки и поставки ИС, на поставщика должна
быть возложена ответственность на случай возникновения каких-либо
инцидентов ИБ, связанных с некачественной разработкой, нарушением правил
поставки и пр. Также следует учитывать наличие у разработчика необходимых
лицензий на разработку и эксплуатацию средств и систем защиты.
2.1.3. --
Система мероприятий, направленных на защиту данных в
разрабатываемой системе включает ряд аспектов, а именно:
защита данных непосредственно в ИС от различных внутренних
угроз;
защита информации от внешних угроз.
Источник: https://baza.diplomsite.ru/previewfile/2512