Разработка проекта по управлению рисками на этапах жизненного цикла ИС на предприятии (на примере конкретной организации);

1.1. Технико-экономическая характеристика предметной области и предприятия

В этом разделе необходимо описать предметную область «проект управления рисками ЖЦ ИС» и дать общую характеристику АО «ЖЦ-Риски»: организационную структуру, основные направления деятельности, используемые ИТ-решения, текущие подходы к управлению рисками.

Пример: АО «ЖЦ-Риски» — организация, специализирующаяся на сопровождении информационных систем в государственном секторе. В компании отсутствует формализованный процесс управления рисками на этапах жизненного цикла ИС, что приводит к задержкам внедрения и перерасходу бюджета.

Сложности:

• Отсутствие открытых данных о внутренних процессах предприятия;
• Необходимость обобщения информации без нарушения конфиденциальности.

Время: 10–12 часов.

1.2. Характеристика комплекса задач и обоснование необходимости автоматизации

Здесь формулируется, какие именно задачи связаны с управлением рисками ЖЦ ИС на предприятии. Необходимо показать, что текущий ручной или фрагментированный подход неэффективен, и обосновать необходимость разработки проекта по управлению рисками.

Пример: В АО «ЖЦ-Риски» идентификация рисков осуществляется разными отделами без единой методики. Это приводит к дублированию усилий и пропуску критических угроз. Автоматизация процесса «разработка проекта» позволит централизовать сбор, анализ и мониторинг рисков.

Сложности:

• Сложно чётко отделить задачи управления рисками от других ИТ-процессов;
• Требуется аргументация с опорой на стандарты (например, ISO 31000).

Время: 8–10 часов.

1.3. Анализ существующих разработок и выбор стратегии автоматизации

Анализируются аналогичные системы управления рисками (например, RiskWatch, RiskMatrix, внутренние решения крупных ИТ-компаний). Оцениваются их сильные и слабые стороны. На основе сравнения выбирается стратегия: использовать готовое ПО, адаптировать open-source решение или разрабатывать с нуля.

Пример: В ходе анализа установлено, что коммерческие системы слишком дороги для АО «ЖЦ-Риски», а open-source решения не соответствуют требованиям по интеграции с внутренними ИС. Решено разрабатывать собственный модуль в рамках существующей ИТ-платформы.

Сложности:

• Недостаток информации о функционале аналогов;
• Опасность поверхностного сравнения без учёта специфики предприятия.

Время: 10–12 часов.

1.4. Обоснование проектных решений

Формулируются ключевые проектные решения: выбор методологии управления рисками (например, на основе COBIT или PMBOK), архитектурные принципы будущей системы, требования к функционалу.

Пример: Для проекта «разработка проекта» принято решение использовать итеративную модель жизненного цикла, а риск-реестр реализовать как модуль в существующей ERP-системе АО «ЖЦ-Риски».

Сложности:

• Сложность обоснования выбора без технического задания;
• Необходимость соответствия ГОСТ Р ИСО/МЭК 12207.

Время: 8–10 часов.

Выводы по главе 1

Подводятся итоги аналитической части: выявлены проблемы, обоснована необходимость автоматизации, выбрана стратегия и сформулированы проектные решения. Выводы должны чётко вести к переходу к проектированию.

Время: 4–6 часов.

2.1. Разработка проекта автоматизации

Описывается архитектура системы управления рисками, диаграммы (например, DFD, UML), сценарии использования. Детализируется, как именно будет реализована «разработка проекта» в рамках ИС.

Пример: В системе предусмотрены роли: аналитик рисков, руководитель проекта, аудитор. Процесс начинается с идентификации рисков на этапе проектирования ИС и завершается формированием отчёта после эксплуатации.

Сложности:

• Требуется знание нотаций моделирования;
• Сложно сбалансировать детализацию и объём.

Время: 16–20 часов.

2.2. Информационное обеспечение задачи

Приводятся структуры данных: сущности (проект, риск, мера, статус), атрибуты, связи. Формируются таблицы базы данных, описания справочников.

Пример: Таблица «Риски» содержит поля: ID, название, категория (технический, организационный), вероятность, воздействие, статус, ID проекта.

Сложности:

• Ошибка в нормализации БД;
• Недостаточная проработка связей между сущностями.

Время: 10–12 часов.

2.3. Программное обеспечение задачи

Описывается выбор технологического стека (язык, СУБД, фреймворк), архитектурные паттерны, ключевые модули системы. Приводятся фрагменты кода (если требуется).

Пример: Система разработана на Python с использованием фреймворка Django, СУБД PostgreSQL. Реализован REST API для интеграции с другими ИС АО «ЖЦ-Риски».

Сложности:

• Необходимость демонстрации кода без реальной реализации;
• Сложность описания архитектуры без опыта.

Время: 12–16 часов.

2.4. Контрольный пример реализации проекта и его описание

Приводится пример применения разработанной системы на реальном или смоделированном проекте в АО «ЖЦ-Риски». Показывается, как система помогает выявить и снизить риски.

Пример: При внедрении ИС «Учёт договоров» система выявила риск несвоевременного обновления нормативной базы. Была назначена мера — автоматическое уведомление юридического отдела за 30 дней до истечения срока.

Сложности:

• Создание правдоподобного сценария;
• Связь примера с теоретической частью.

Время: 10–12 часов.

Выводы по главе 2

Подтверждается, что спроектированная ИС решает поставленные задачи, соответствует требованиям и готова к внедрению. Указываются ограничения и возможные доработки.

Время: 4–6 часов.

3.1. Выбор и обоснование методики расчёта экономической эффективности

Выбирается методика (например, NPV, ROI, срок окупаемости). Обосновывается, почему именно она подходит для проекта по управлению рисками ЖЦ ИС.

Пример: Для расчёта выбран метод NPV, так как он учитывает временну́ю стоимость денег и позволяет оценить долгосрочную выгоду от снижения рисков в проектах АО «ЖЦ-Риски».

Сложности:

• Непонимание различий между методиками;
• Сложность обоснования выбора для нетипового проекта.

Время: 6–8 часов.

3.2. Расчёт показателей экономической эффективности проекта

Приводятся расчёты: затраты на разработку, эксплуатацию, ожидаемая экономия (например, за счёт сокращения простоев, штрафов, переделок). Формируется таблица с цифрами.

Пример: Годовые затраты на поддержку — 450 тыс. руб. Ожидаемая экономия от снижения рисков — 1,2 млн руб. в год. Срок окупаемости — 6 месяцев.

Сложности:

• Отсутствие реальных данных по затратам;
• Ошибки в расчётах или завышенные оценки выгоды.

Время: 8–10 часов.

Выводы по главе 3

Подтверждается экономическая целесообразность внедрения системы. Указывается, что проект окупается в короткие сроки и приносит стратегическую пользу.

Время: 4–6 часов.