Загрузка данных



Ниже приведена детальная проектная матрица рисков, разработанная в ходе анализа условного программного продукта (информационной системы):
| Идентификатор | Категория риска | Описание рискового события | Вероятность (P) | Влияние (I) | Критичность (R) | Стратегия реагирования и превентивные меры (Минимизация) |
|---|---|---|---|---|---|---|
| **RSK-01** | Технический | Конфликт совместимости со старыми версиями ОС Windows (Win 7/8) при развертывании пакета. | 3 | 4 | **12** | **Минимизация:** Раннее создание виртуального тестового стенда; использование обратной совместимости API. |
| **RSK-02** | Безопасность | Обнаружение критических уязвимостей (0-day) в используемых сторонних Open-Source библиотеках. | 4 | 5 | **20** | **Предотвращение:** Автоматическое сканирование зависимостей через Snyk/OWASP Dependency Check в CI/CD пайплайне. |
| **RSK-03** | Технологический | Ошибки и ограничения выбранного игрового движка (например, Construct 2) при масштабировании логики игры. | 2 | 4 | **8** | **Принятие/Обход:** Архитектурное разделение графического интерфейса и вычислительной логики для возможности переноса. |
| **RSK-04** | Человеческий фактор | Недостаточная квалификация инженеров в области написания безопасных скриптов развертывания (WiX/MSI). | 3 | 3 | **9** | **Передача/Обучение:** Проведение внутренних технических семинаров, парное программирование, аудит кода старшим инженером. |
| **RSK-05** | Управление | Нечетко сформулированные функциональные требования заказчика, приводящие к постоянному изменению ТЗ. | 4 | 4 | **16** | **Минимизация:** Использование гибких методологий (Agile/Scrum), фиксация спринтов, еженедельные демонстрации прототипов. |
## 3.3. Планирование реагирования на риски
Разрабатываются четыре основных сценария работы со сквозными рисками:
 1. **Уклонение от риска (Avoidance):** Изменение плана проекта с целью полной ликвидации угрозы (например, отказ от интеграции нестабильного стороннего модуля).
 2. **Минимизация (Mitigation):** Снижение вероятности или последствий (например, проведение регулярного рефакторинга кода снижает технический долг).
 3. **Передача (Transfer):** Перенаправление ответственности третьей стороне (аутсорсинг разработки сложного модуля безопасности специализированной компании).
 4. **Принятие (Acceptance):** Осознанное решение не предпринимать никаких действий ввиду низкой критичности или экономической нецелесообразности защитных мер (выделяется резервный бюджет времени).
# ГЛАВА 4. ПРОВЕДЕНИЕ ТЕСТИРОВАНИЯ КАЧЕСТВА ПРОГРАММНОГО МОДУЛЯ ПО ОПРЕДЕЛЕННОМУ СЦЕНАРИЮ
## 4.1. Методология тестирования программных модулей
Тестирование программного модуля (компонентное тестирование) направлено на верификацию изолированной единицы исходного кода (класса, функции, метода) на соответствие заложенным требованиям. В рамках практики было проведено сценарное функциональное тестирование модуля авторизации и валидации данных пользователей информационной системы методом «черного ящика» (Black Box Testing).
Критерии оценки качества модуля базировались на стандарте ISO/IEC 25010 (функциональная полнота, корректность, защищенность).
## 4.2. Разработка сценария и тест-кейсов (Test Cases)
Для полной проверки функционала разработан детальный перечень тест-кейсов, покрывающих как позитивные сценарии использования, так и негативные (ввод некорректных данных, граничные значения).
### Сценарий: Проверка компонента валидации регистрационной формы
#### Тест-кейс TC-001 (Позитивный)
 * **Название:** Валидация корректных учетных данных.
 * **Предусловия:** Модуль запущен, база данных доступна, учетная запись отсутствует в системе.
 * **Шаги выполнения:**
   1. Ввести в поле Логин значение: user_2026.
   2. Ввести в поле Email значение: test.user@steeit.ru.
   3. Ввести в поле Пароль значение: P@ssw0rd_Secure!.
   4. Нажать кнопку «Зарегистрироваться».
 * **Ожидаемый результат:** Модуль возвращает статус Success (Код 201). Данные зашифрованы и успешно внесены в СУБД. Пользователь перенаправлен на страницу личного кабинета.
 * **Фактический результат:** Статус Success, запись создана.
 * **Статус:** **Пройден (Passed)**.
#### Тест-кейс TC-002 (Негативный — Граничные значения)
 * **Название:** Проверка минимальной длины пароля.
 * **Предусловия:** Модуль запущен.
 * **Шаги выполнения:**
   1. Ввести корректный логин и email.
   2. Ввести в поле Пароль строку длиной 5 символов: 12345.
   3. Нажать кнопку «Зарегистрироваться».
 * **Ожидаемый результат:** Модуль блокирует отправку формы. Возникает ошибка валидации: «Длина пароля не может быть менее 8 символов». Статус выполнения: ValidationError (Код 400).
 * **Фактический результат:** Форма заблокирована, отображено корректное сообщение об ошибке.
 * **Статус:** **Пройден (Passed)**.
#### Тест-кейс TC-003 (Негативный — Безопасность / Инъекция)
 * **Название:** Проверка устойчивости к SQL-инъекциям в поле авторизации.
 * **Предусловия:** Модуль находится в режиме обработки запросов аутентификации.
 * **Шаги выполнения:**
   1. В поле Логин ввести строку: ' OR '1'='1.
   2. В поле Пароль ввести: any_string.
   3. Нажать кнопку «Войти».
 * **Ожидаемый результат:** Запрос обрабатывается как строка. Система выдает ошибку: «Неверный логин или пароль». Не происходит обхода авторизации или падения СУБД. Статус: Unauthorized (Код 401).
 * **Фактический результат:** Допущена ошибка экранирования символов. Модуль выдал внутреннюю ошибку сервера Internal Server Error (Код 500), раскрыв структуру SQL-запроса в стек-трейсе.
 * **Статус:** **Провален (Failed)** — Оформлен Баг-репорт (Дефект зарегистрирован).
## 4.3. Регистрация дефектов и регрессионное тестирование
По результатам провала тест-кейса TC-003 был составлен отчет об ошибке (Bug Report) со следующим содержанием:
 * **Критичность:** Высокая (High).
 * **Уязвимость:** Небезопасная фильтрация входных данных, приводящая к SQL-инъекции.
 * **Локализация:** Класс AuthService, метод ValidateUserCredentials().
После исправления программного кода разработчиками (внедрение параметризованных SQL-запросов и ORM-экранирования вместо динамической конкатенации строк) было проведено **регрессионное тестирование** — повторное выполнение всего набора тест-кейсов (TC-001 – TC-003) для подтверждения исправления дефекта и контроля того, что изменения кода не нарушили работу остальных смежных функций. Повторный прогон зафиксировал статус **Passed** для всех кейсов.
# ГЛАВА 5. НАСТРОЙКА ОТДЕЛЬНЫХ КОМПОНЕНТ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
## 5.1. Архитектура конфигурационных файлов ПО
Современное ПО проектируется в соответствии с принципами слабой связанности (Loose Coupling). Все изменяемые параметры, сетевые адреса, учетные записи и режимы работы выносятся из скомпилированного бинарного кода в текстовые конфигурационные файлы конфигурации. Это позволяет настраивать компоненты приложения под конкретную инфраструктуру без необходимости перекомпиляции исходного кода.
Основные форматы конфигурационных файлов:
 * JSON (JavaScript Object Notation) — популярен в веб-приложениях, Node.js, .NET Core. Поддерживает сложную иерархию и типы данных.
 * XML (Extensible Markup Language) — классический Enterprise-формат, поддерживающий строгую валидацию схем (XSD).
 * YAML / INI — форматы с высокой читаемостью, активно используемые в системном администрировании и конфигурациях CI/CD.
## 5.2. Практическая настройка веб-сервера и СУБД приложения
В ходе выполнения работ по развертыванию программного обеспечения компьютерной системы была произведена детальная настройка двух ключевых компонентов: СУБД *PostgreSQL* и бэкенд-модуля приложения.
Ниже представлен пример рабочей конфигурации прикладного модуля (файл appsettings.json), настроенной в процессе прохождения практики:
```json
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "System.Net.Http": "Error"
    },
    "FileProvider": {
      "Path": "C:\\Logs\\Application\\sys_log.txt",
      "RollingInterval": "Day"
    }
  },
  "ConnectionStrings": {
    "ProductionDatabase": "Server=192.168.10.25;Port=5432;Database=AppProductionDb;User Id=db_app_user;Password=K9$mLx#2pQ!zW;Maximum Pool Size=100;Connection Timeout=30;"
  },
  "ApplicationSettings": {
    "EnableSelfHealing": true,
    "CacheTimeoutMinutes": 15,
    "AllowedHosts": "localhost;192.168.10.*",
    "Security": {
      "MaxLoginAttempts": 5,
      "LockoutDurationSeconds": 900,
      "RequireTwoFactor": false
    }
  }
}

```
### Анализ выполненных настроек конфигурации:
 1. **Блок логирования (Logging):** Задан уровень детализации Information. Ошибки сетевого стека ограничены уровнем Error во избежание переполнения диска. Настроен ротационный файловый провайдер: логи записываются в каталог C:\Logs\Application\, файлы разделяются посуточно (RollingInterval: Day).
 2. **Строка подключения к БД (ConnectionStrings):** Задан статический IP-адрес сервера баз данных внутри защищенного периметра (192.168.10.25), стандартный порт PostgreSQL 5432. Пул подключений ограничен значением 100 для предотвращения исчерпания ресурсов ОЗУ сервером баз данных. Время ожидания сессии ограничено 30 секундами.
 3. **Безопасность (Security):** Ограничено количество попыток неверного ввода пароля (до 5), после чего учетная запись блокируется на 15 минут (900 секунд). Поле AllowedHosts ограничивает обработку входящих сетевых пакетов только локальным хостом и подсетью уровня предприятия.
# ГЛАВА 6. ОПИСАНИЕ ВЫПОЛНЕНИЯ ОТДЕЛЬНЫХ ВИДОВ РАБОТ НА ЭТАПЕ ПОДДЕРЖКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КОМПЬЮТЕРНОЙ СИСТЕМЫ
## 6.1. Модель жизненного цикла поддержки ПО
Этап поддержки (эксплуатации и сопровождения) является наиболее длительным в жизненном цикле ПО. Согласно стандарту ISO/IEC 14764, сопровождение разделяется на четыре основные категории:
 1. **Исправляющее (Corrective):** Устранение дефектов и багов, обнаруженных конечными пользователями в процессе эксплуатации продукта.
 2. **Адаптирующее (Adaptive):** Модификация ПО для сохранения работоспособности при изменении внешних условий (аппаратной части, обновлении ОС, изменении нормативных законов).
 3. **Совершенствующее (Perfective):** Добавление новых функциональных возможностей по запросам пользователей, улучшение производительности интерфейса.
 4. **Профилактическое (Preventive):** Нахождение скрытых проблем и оптимизация кода до того, как они приведут к явным сбоям системы.
## 6.2. Регламент выполнения работ по поддержке на предприятии
В процессе практики были изучены и практически отработаны следующие технологические процедуры поддержки ИТ-инфраструктуры и программного обеспечения компьютерной системы:
### Работа с системой Service Desk (Обработка инцидентов)
Поступающие от пользователей заявки о сбоях ПО регистрируются в централизованной системе учета. Инженер поддержки выполняет следующий алгоритм:
 * **Классификация и определение приоритета:** На основе критичности сбоя (например, полная остановка сервиса — приоритет Critical, ошибка опечатки в интерфейсе — приоритет Low).
 * **Диагностика:** Сбор логов с рабочей станции пользователя (%appdata%/Local/CrashDumps), анализ системных событий Windows.
 * **Локализация и обходное решение (Workaround):** Предоставление временного решения для восстановления бизнес-процесса пользователя без изменения основного кода (например, очистка кэша, перезапуск службы).
 * **Закрытие инцидента:** Фиксация решения в базе знаний (Knowledge Base) для ускорения обработки аналогичных инцидентов в будущем.
### Мониторинг производительности и сбор метрик
Поддержка серверных компонент ПО включает непрерывный мониторинг использования системных ресурсов. Для этого настраиваются счетчики производительности (Performance Counters):
 * Процент утилизации ядер центрального процессора (% Processor Time).
 * Объем доступной физической оперативной памяти (Available MBytes).
 * Длина очереди к дисковым накопителям (Avg. Disk Queue Length).
При превышении пороговых значений (например, утилизация CPU > 85% в течение 10 минут) система мониторинга автоматически генерирует оповещение (Alert), сигнализирующее о необходимости проведения оптимизации или горизонтального масштабирования (добавления ресурсов).
### Регламентное резервное копирование и архивация
Обеспечение непрерывности бизнеса требует строгого выполнения графика резервного копирования баз данных и конфигурационных сред прикладного ПО. В рамках регламента поддержки выполняются:
 * Ежедневное инкрементное копирование (сохраняются только изменения за сутки).
 * Еженедельное полное резервное копирование (Full Backup) с выгрузкой архивов на изолированный сервер хранения (отделенный от основной сети сетевым экраном для защиты от вирусов-вымогателей).
# ЗАКЛЮЧЕНИЕ
В результате прохождения учебной практики и выполнения индивидуального задания были детально изучены и практически применены методы инженерии, настройки, защиты и сопровождения программного обеспечения компьютерных систем.
Разработка инсталляционных пакетов формата MSI продемонстрировала важность стандартизации развертывания ПО в корпоративной среде. Полученные навыки качественного анализа рисков и сценарного компонентного тестирования позволяют минимизировать вероятность появления критических ошибок на этапе промышленной эксплуатации программных модулей. Регламентные работы по настройке конфигурационных сред и поддержке инфраструктуры закрепили понимание принципов обеспечения высокой доступности, отказоустойчивости и информационной безопасности современных вычислительных комплексов.