50
5
Сетевая карта
Ethernet 10/100 Mbps
6
Устройства ввода
Клавиатура, мышь
7
Устройства вывода
МФУ Ricoh, монитор с разрешением 1600х900
Все эти критерии имеются в организации ПАО ФК «Открытие» поэтому
можно сделать вывод что технические средства подходят по всем критериям
51
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Цель: выбрать определенный стандарт и модель жизненного цикла для
разработки и внедрения программного продукта., а также указать ключевых
участников, требования к выходной информации и получаемый результат.
Сегодня жизненный цикл продукта является одним из приоритетов при его
создании. Говоря просто это время начало создание проекта или точнее
программного продукта, его разработка ,тестирование и так до конца его
реализации и внедрения.
Жизненный цикл для программного продукта протекает в соответствии
с выбранной моделью жизненного цикла. Существует ряд общеизвестных
стандартов
ГОСТ 34 в данном стандарте существует три подкатегории по
автоматизации
1. ГОСТ 34.602-89 Техническое задание на создание автоматизированной
системы. Более частый используемый стандарт по написанию
технического задания. При выборе данного стандарта крайне важно
придерживается других стандартов так как это может негативно
сказаться на разработке технического задания
2. ГОСТ 34.201-89 Виды, комплектность и обозначения документов при
создании автоматизированных систем. Этот стандарт в котором
приводится перечень документов ГОСТ 34, то как правильно
кодировать документы и как их можно обеднить
3. РД 50-34.698-90 Автоматизированные системы. Требования к
содержанию документов. Самый крупный стандарт, в нем идет
описание проектных документов. В качестве индекса использует ГОСТ
34.201-89
52
ISO / IEC 12207 - это международный стандарт разработки
программного обеспечения, который определяет процессы и действия
по разработке программного обеспечения, связанные с жизненным
циклом программного обеспечения. процесс от замысла до конца
продукта . Этот стандарт определяет набор подходящих роли для
практиков программного обеспечения и следует за циклом план-дел-
проверка-действие для улучшения качество продукта
ISO/IEC 15288 Этот стандарт, уже вышедший на пенсию, называется
«Системная инженерия Процессы жизненного цикла системы », имеет
чрезвычайно широкую сферу применения. Это относится «… к полной
жизни цикл систем, включая концепцию, разработку, производство,
использование, поддержку и выход из системы и их приобретение и
снабжение ». Процессы, указанные в ISO/IEC 15288, охватывают все
приобретение, программу управление и техническое развитие.
Также помимо стандартов или ГОСТов существует несколько моделей
жизненных циклов, которые выбираются под конкретную задачу и под
определенный проект и также необходимого результата, его контроля
разработки. На сегодняшний день можно выделить 3 модели жизненного
цикла информационных систем
Спиральная модель, данная модель представляет собой процесс разработки
программного обеспечения оно включает в себя как проектирование так и
прототипирование то есть по сути она является итерационной моделью, т ем
самым каждый ее виток соответствует определенной стадии процесса
создания
53
Рисунок 8 Спиральная модель
К неоспоримым преимуществам данной модели жизненного цикла можно
отнести быстрота получения данных, повышения конкурентоспособности и
изменяющиеся требования
Каскадная модель жизненного цикла это уже последовательная модель,
которая делит разработку программного обеспечения на заранее
определенные фазы. Каждая из этих фаз должна быть завершена, прежде чем
следующая фаза может начатся без между фазами. Каждый из этих этапов
предназначен для выполнения действий на этапе
54
Рисунок 9 Каскадная модель
Эволюционная модель представляет собой комбинацию итеративного и
поэтапного подхода к разработке программного обеспечения. Поставка
вашей системы в режиме «большого взрыва», поэтапный процесс с течением
времени - это действие, выполняемое в этой модели. Некоторые
первоначальные требования и предполагаемая архитектура должны быть
выполнены. Идеально подходит для программных продуктов, чьи наборы
функций переопределяются во время разработки из-за отзывов пользователей
и других факторов. Эволюционная модель делит цикл разработки на более
мелкие, инкрементные модели водопада, в которых пользователи могут
получить доступ к продукту в конце каждого цикла. доступ к продукту в
конце каждого цикла.
55
Рисунок 10 Эволюционная модель
Аналзируя все модели жизненных циклов выбор можно сделать на
спиральной модели жизненого цикла, так как она имеет наименьшие риски и
более быстрый процесс разработки.
Процесс услуг по разработке программного обеспечения в России
проходит ряд этапов поэтапно, за которыми следует почти каждая
развивающаяся компания. Известный как «жизненный цикл разработки
программного обеспечения», эти шесть этапов включают планирование,
анализ, проектирование, разработку и внедрение, тестирование,
развертывание и обслуживание. Давайте рассмотрим каждый из этих шагов,
чтобы узнать, как разрабатывается идеальное программное обеспечение
56
Планирование: без идеального плана, расчета сильных и слабых сторон
проекта, разработка программного обеспечения не имеет смысла.
Планирование запускает проект безупречно и положительно влияет на
его прогресс.
Анализ. Этот этап предназначен для анализа производительности
программного обеспечения на различных этапах и внесения заметок о
дополнительных требованиях. Анализ очень важен, чтобы перейти к
следующему шагу.
Проектирование. После завершения анализа наступает этап
проектирования, который в основном строит архитектуру проекта.
Этот шаг помогает устранить возможные недостатки, устанавливая
стандарт и пытаясь придерживаться его.
Разработка и внедрение: актуальная задача разработки программного
обеспечения начинается здесь с записи данных в фоновом режиме. Как
только программное обеспечение разработано, наступает этап
внедрения, когда продукт проходит пилотное исследование, чтобы
проверить, правильно ли оно работает.
Тестирование. Стадия тестирования оценивает программное
обеспечение на наличие ошибок и документирует ошибки, если
таковые имеются.
Обслуживание. После того, как программное обеспечение проходит все
этапы без каких-либо проблем, оно должно пройти процесс
обслуживания, при котором оно будет время от времени
поддерживаться и обновляться для адаптации к изменениям.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
При начальных этапах жизненного цикла программного обеспечения
могут возникнуть риски, которые могут сорвать разработку. Для того чтобы
минимизировать риски необходимо проведения оценки вероятных рисков и
57
также разрабатываются способы, позволяющие избегнуть эти риски или
минимизировать их влияние.
Рассмотрим наиболее вероятные риски спиральной модели:
На начальном этапе основным риском является неспособность
разработать бизнес-план и стратегию, которые позволят программному
обеспечению стать прибыльной, поскольку она делает продажи и получает
доход. Другие существенные риски включают зависимость от начальных
денег для покрытия эксплуатационных расходов в течение более длительного
периода, чем ожидалось, или нехватку средств для покрытия растущих затрат
на персонал и инфраструктуру.
Еще один риск - это дорогостоящие последствия ошибок при приеме на
работу неквалифицированных работников на ранних этапах жизненного
цикла ПО, так как они могут неправильно заложить фундамент для будущего
программного обеспечения, тем самым дальнейшие разработки могут
провалится из фатальных ошибок в ядре программы. Для того чтобы
избежать данный риск необходимо тщательно проводить отбор кандидатов,
проверять их на достаточную квалификацию
Также не маловажным риском будет непонятный пользовательский
интерфейс. То что специалисту который разрабатывал данное программное
обеспечение будет все понятно или тестировщику который будет проверять
конечный продукт, но рядовому пользователю интерфейс может быть не
понятен, а это уже скажется скорости работы сотрудников. Для избежание
данного риска необходимо разрабатывать интуитивно понятный интерфейс,
который поймет рядовой пользователь который сразу же после установки
программного обеспечения сможет приступить к своим трудовым
обязанностям
На этапе проектирования фирма может столкнутся с таким риском как
неверная оценка времени разработки проекта. К примеру во время
разработки могут возникнут технические сложности в развёртывания
58
тестового сервера что замедлит работу по разработки ПО. Для снижения
данного риска необходимо привлечение дополнительных ресурсов и
специалистов соответсвующего профиля
На этапе разработки может произойти ситуация что проект отличается
от начального задуманного ТЗ так как невозможно реализовать в реалиях
фирмы те или иные функции или же в техническом задании были не четко
сформулированы требования к будущему программному обеспечению. Для
снижения риска необходимо четко формулировать Техническое задание и
понимать сможет ли фирма реализовать это у себя используя текущие
мощности оборудования и также рекомендовано привлекать к составлению
задания профильных специалистов которые смогут четко сформулировать ТЗ
Во время этапа тестирования тестировщики могут столкнутся с
проблемой по документации продукта, к примеру когда тестировщики уже
подготовили свою документацию созадли кейсы, но у заказчика к примеру
поменялась концепция конечного продукта и он решил изменить ТЗ, и за
этого отделу тестирования приходится вводить для тестирования уже другие
вводные данные и создавать другие кейсы. Решением данного риска является
опять же корректно составленное ТЗ, чтобы в дальнейшем не изменять
концепцию ПО и не тормозить тем самым разработку продукта
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации.
Для организации безопасного обмена информацией по каналам связи в сети
интернет необходимо применение систем криптографической защиты
информации. Поэтому необходимо внедрение программного комплекса
КриптоПро CSP Криптопровайдер КриптоПро CSP предназначен для:
авторизации и обеспечения юридической значимости
электронных документов при обмене ими между пользователями,
посредством использования процедур формирования и проверки
59
электронной цифровой подписи (ЭЦП) в соответствии с отечественными
стандартами ГОСТ Р 34.11-94 / ГОСТ Р 34.11-2012 и ГОСТ Р 34.10-2001 /
ГОСТ Р 34.10-2012;
обеспечения конфиденциальности и контроля целостности
информации посредством ее шифрования и имитозащиты, в соответствии с
ГОСТ 28147-89;
обеспечения аутентичности, конфиденциальности и
имитозащиты соединений по протоколу TLS;
контроля целостности системного и прикладного программного
обеспечения для его защиты от несанкционированных изменений и
нарушений правильности функционирования;
управления ключевыми элементами системы в соответствии с
регламентом средств защиты.
В дистрибутив СЗИ "КриптоПро CSP" помимо самого
криптопровайдера входят следующие продукты:
Модуль поддержки сетевой аутентификации КриптоПро TLS,
входящий в состав СЗИ КриптоПро CSP, реализует протокол Transport Layer
Security (TLS v. 1.0, RFC 2246), с использованием российских
криптографических стандартов. Протокол TLS предназначен для
обеспечения криптографическими средствами аутентификации отправителя
(клиента) - адресата (сервера), контроля целостности и шифрования данных
информационного обмена.
КриптоПро Winlogon предназначен для ОС семейства Microsoft
Windows и реализует первоначальную аутентификацию пользователя
протокола Kerberos V5 (RFC 4120) по сертификату и ключевому носителю
(смарт-карта, USB-токен) с использованием сертифицированного СЗИ
"КриптоПро CSP" версии 3.0 и выше.
КриптоПро Revocation Provider.
Реализуемые алгоритмы: