52
– объем жесткого диска;
– наличие графической подсистемы.
Основной характеристикой ЛВС является ее максимальная пропускная
способность. При использовании разрабатываемого программного обеспечения
во время работы планируется передавать незначительные объемы информации,
таким образом существующая пропускная способность линий связи скоростью
до 100 Мбит в секунду является достаточной, следовательно модернизация не
потребуется.
Учитывая, что разрабатываемое ПО будет построено на технологии
клиент-сервер и вычисления будут выполняться сервером, используемые
организацией в работе компьютеры по своим техническим характеристикам
удовлетворяют для решения поставленной задачи.
Кроме того, для оптимального распределения нагрузки на используемые в
работе сервера, принято решение разместить разрабатываемое ПО на более
мощном сервере, характеристики которого приведены в таблице 6.
53
ГЛАВА 2. ПРОЕКТНАЯ ЧАСТЬ
2.1 Разработка проекта автоматизации.
2.1.1 Этапы жизненного цикла проекта автоматизации.
Жизненный цикл (ЖЦ) ИС – совокупность стадий и этапов, которые
проходит ИС в своем развитии от момента принятия решения о создании
системы до момента прекращения ее функционирования. [22]
К стандартам, описывающим ЖЦ ИС, относятся:
– ГОСТ Р ИСО/МЭК 15288-2005 – данный стандарт распространяется на
системы, которые созданы человеком и состоят из одного или нескольких
следующих элементов: технические средства, программные средства, люди,
процессы (например, процесс оценки), процедуры (например, инструкции
оператора), основные средства и природные ресурсы (например, вода, объекты
живой природы, минералы);
– ГОСТ Р ИСО/МЭК 12207-2010 – настоящий стандарт используется при
приобретении систем, программных продуктов и услуг, при их поставке,
разработке, применении по назначению, сопровождении и прекращении
применения программных продуктов и программных компонентов системы как
в самой организации, так и вне ее. Эти аспекты системного определения
включаются в настоящий стандарт для обеспечения содержания понятий
программных продуктов и услуг;
– ГОСТ 34.601-90 – настоящий стандарт распространяется на
автоматизированные системы (АС), используемые в различных видах
деятельности (исследование, проектирование, управление и т.п.), включая их
сочетания, создаваемые на предприятиях (организациях). Стандарт
устанавливает стадии и этапы создания АС;
– RUP (Rational Unified Process – рациональный унифицированный
процесс) – это методология разработки программного обеспечения, созданная
компанией Rational Software, использует итеративную модель.
– XP (eXtreme Programming – экстремальное программирование) –
упрощенная методология организации разработки программ для небольших и
средних по размеру команд разработчиков, занимающихся созданием
программного продукта в условиях неясных или быстро меняющихся
54
требований. Основными целями XP являются резкое сокращение сроков
разработки продукта и минимизация ошибок на ранних стадиях разработки.
– MSF (Microsoft Solutions Framework) – методология создания
программных решений, разработанная корпорацией Microsoft. Она предлагает
проверенные методики для планирования, проектирования, разработки и
внедрения ИТ-решений. Благодаря своей гибкости, масштабируемости и
отсутствию жестких инструкций данная методология способна удовлетворить
нужды организации или проектной группы любого размера.
– COBIT (Control Objectives for Information and Related Technology –
задачи управления для информационных и смежных технологий) – стандарт,
разработанный ISACA (Information Systems Audit and Control Association,
Ассоциацией контроля и аудита систем). COBIT определяет ключевые действия,
необходимые для достижения требуемого качества и содержит способы
контроля над правильностью выполнения ключевых ИТ процессов, а также
методы их корректировки.
– Oracle CDM (Custom Development Method – методология создания ИС
под заказ), позволяющая стандартизировать процесс создания приложений.
CDM может использоваться при разработке ИС разных типов с использованием
разных подходов, как самостоятельно, так и в качестве составной части других
стандартов.
Ввиду того, что стандарт РФ ГОСТ 34.601-90 описывает большинство АС,
для описания жизненных циклов проектируемой ИС был выбран именно он.
Кроме того, данный стандарт позволяет охватить весь жизненный цикл ПО.
В таблице 17 приводится сравнение различных моделей жизненного
цикла.
55
Таблица 17
Общее количество выполненных запросов
Модель
Преимущества модели
Недостатки модели
Каскадная
– легкость в управлении;
– прозрачность при анализе;
– формирование законченного
набора проектной
документации на каждом этапе;
– логичная последовательность
этапов позволяет проводить
планирование сроков и
расходов.
– отсутствие обратных
связей между этапами;
– не всегда соответствует
реальным условиям
разработки программного
продукта.
Каскадная с
промежуточным
контролем
– наличие обратной связи
между этапами;
– снижение риска получения
некачественного продукта.
– увеличение сроков
разработки ПО.
Спиральная
– создание прототипа для
проверки на соответствие
требованиям заказчика;
– снижение риска получения
некачественного продукта.
– возрастание стоимости
реализации проекта для
простых проектов;
– усложненная структура.
Принимая во внимание, что будет выполнена разработка относительно
простой ИС, а также учитывая приведенную в таблице информацию, для
реализации проекта ИС выбор остановлен на каскадной модели жизненного
цикла как наиболее соответствующая поставленным задачам.
Выполнение проекта автоматизации поставленной задачи опирается на
ГОСТ 34.601-90, кроме того принимались во внимание стандарты ГОСТ Р
ИСО/МЭК 15288-2005 и ГОСТ Р ИСО/МЭК 12207-2010. Разработанное
техническое задание учитывает рекомендации руководящего документа РД 50-
34.698-90 (отмененного Приказом Росстандарта № 216 от 12.02.2019) и включает
в себя следующие пункты:
1. Формирование требований к проектируемой ИС, выполняемое
аналитической группой учреждения, схематично изображено на рисунке 11.
56
Рисунок 11. Этапы формирования требований к ИС
2. Разработка вариантов концепции ИС, также выполняемая
аналитической группой учреждения, приводится на рисунке 12.
Рисунок 12. Концептуальная фаза
3. На этапе формирования технического предложения аналитиками
учреждения выполняются действия, изображенные на рисунке 13.
Рисунок 13. Этап подготовки технического плана
4. Следующим этапом является техническое проектирование. Данный этап
выполняется разработчиками и схематически отражен на рисунке 14.
57
Рисунок 14. Этап технического проектирования
5. На этапе разработки ИС, также выполняемом разработчиками, проект
проходит стадии, отражены на рисунке 15.
Рисунок 15. Этап разработки ИС
6. Следующим шагом является ввод системы в эксплуатацию. Данную
фазу осуществляют разработчики, ее содержание отражено на рисунке 16.
58
.
Рисунок 16. Этап ввода в эксплуатацию
Выделяют следующие варианты внедрения разрабатываемой ИС:
– параллельная стратегия;
– скачок;
– пилотный проект;
– узкое место.
Специфика функционирования ГАУ АО «МФЦ по г. Благовещенску» не
допускает возможности приостановки оказания услуг из-за внедрения новой
разработки, поскольку это может повлечь за собой ошибки в выполнении
документооборота и, как следствие, недовольство заявителей и упущенную
выгоду. Как следствие – вероятность неудачного внедрения ИС в учреждении
должна быть минимальной или отсутствовать.
При использовании метода «скачка» организация должна полностью
отказаться от существующей системы работы и мгновенно перейти на новую
ИС. Положительным эффектом данного метода является потенциально быстрое
освоение системы специалистами, однако отрицательной стороной является
высокая вероятность остановки предоставления услуг, если в новой системе
произойдет сбой.
Стратегия «пилотного проекта» является частным случаем стратегии
«скачка» и применяется к ограниченному диапазону функций системы на
59
ограниченном участке хозяйственной деятельности учреждения. Положительной
стороной данного метода является снижение рисков при внедрении.
Использование метода «узкого места» позволяет выполнить
автоматизацию малой доли учреждения на определенном небольшом участке
деятельности. Несомненным преимуществом данной стратегии является
уменьшение сроков работ в более сжатые сроки, и являться отправной точкой
для дальнейшей автоматизации.
Применение параллельной стратегии внедрения ИС позволяет сохранить
работоспособность старой и новой системы, провести сравнение результатов
функционирования. Если разночтений за длительное время обнаружено не
будет, можно переходить на новую систему. Главным преимущество
использование параллельной стратегии является практические нулевая
вероятность риска срыва работы предприятия.
Для снижения шокового эффекта от внедрения новой ИС и осуществления
процесса оцифровки архива поквартирных карточек, бумажный способ
оформления справок будет осуществляться наравне с цифровым. В дальнейшем
произойдет постепенное вытеснение старых методов работы, соответственно
будет применяться параллельная стратегия.
На основании описанной концепции разрабатываемая ИС будет
реализована по этапам, приведенным в таблице 18.
Таблица 18
Этапы разработки ИС
Этап
разработки
Содержание этапа
Срок
выполнения
Разработка
технического
задания
– разработка и утверждение требований к
ИС;
– разработка модели системы «как должно
быть»;
– согласование технического задания на ИС.
30 дней
Разработка
системы
– создание ИС согласно требованиям ТЗ;
– разработка документации;
– пусконаладочные работы;
– обучение сотрудников учреждения.
35 дней
Опытная
эксплуатация
– проведение тестовой эксплуатации ИС;
– доработка системы;
– сдача ИС в промышленную эксплуатацию.
35 дней
60
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание.
К понятию «риски» относятся негативные события и их величины,
отражающие потери, убытки или ущерб от процессов или продуктов, вызванные
дефектами при проектировании требований, недостатками обоснования
проектов ИС, а также при последующих этапах разработки, реализации и всего
жизненного цикла комплексов программ. [23]
Возможными рисками для проектируемой ИС являются увеличение
сроков выполнения проекта и увеличение стоимости его реализации.
Возможными причинами для возникновения рисков являются:
– вероятность неполного или некорректного описания требований к
разрабатываемой ИС ведет к росту затрат на переработку ТЗ или самой ИС.
Следовательно, необходимо очень тщательно выполнять проверку ТЗ, возможно
с привлечением сторонних экспертов;
– при разработке ИС существует вероятность обнаружения
недокументированных свойств языка программирования, что в свою очередь
это приведёт к временным затратам. Необходимо минимизировать вероятность
данного риска путем тщательного изучения документации;
– снижение уровня квалификации сотрудников, осуществляющих
взаимодействие с ИС, может привести к возможному выходу из строя ИС или
оборудования. Решением является регулярное обучение с последующей
аттестацией сотрудников с целью контроля уровня знаний;
– во время эксплуатации ИС так же риски неполноты проверки
функциональных возможностей и пропуск ошибки.
При эксплуатации и сопровождении проектируемой ИС существует
вероятность появления следующих групп рисков:
– риски персонала возникают в связи с ошибками и противоправными
действиями сотрудников учреждения, их низкой квалификацией и высокой
загруженностью;
– технические риски возникают в связи с непредсказуемыми или
неконтролируемыми свойствами технических систем.
Для решения рисков персонала необходимо применять следующие меры:
– при приеме на работу сотрудников в трудовых соглашениях обязательно
61
наличие пункта о неразглашении конфиденциальной информации, в случае
нарушения данного пункта применение штрафных санкций согласно
законодательству РФ;
– организация системы поощрений для сотрудников, работающих с
программным продуктом.
Причинами технических рисков могут выступать:
– ошибки в программе, вызывающие затруднение выполнения действий и
зависание системы, а также использование этих ошибок в корыстных целях;
– воздействие вредоносными программами (вирусами, троянами и т.д.),
перехват информации по линиям связи и несанкционированный доступ к
информации;
– неправильное использование оборудования;
– сбой в работе третьего лица (например, поставщиков услуг связи),
может стать причиной невозможности обслуживания заявителей как в офисах,
так и в ТОСПах.
Для того, чтобы снизить вероятность перечисленных рисков, необходимо
выполнение:
– очень внимательного тестирования с целью нахождения ошибок при
разработке ИС;
– оперативного устранения недостатков силами специально обученного
персонала;
– обеспечение системным администратором безопасность информации с
помощью всех доступных программно-аппаратных средств (групповые
политики, антивирус, брандмауэр, СКЗИ);
– наличие резервных каналов связи для осуществления передачи данных.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации.
При реализации мероприятий по защите информации в проектируемой
системе следует учитывать следующие пункты:
– обеспечение защиты информации от внутренних угроз;
– обеспечение защиты информации от внешних угроз.
Для обеспечения защиты от внутренних угроз в программном продукте