Основы жизненного цикла, стандартизации и внедрения информационных систем

Стандарты и жизненный цикл ИС: международный регламент ISO/IEC 12207 и отечественный комплекс ГОСТ 34

Представьте, что вы строите огромный небоскреб без единого чертежа, полагаясь только на интуицию рабочих. В ИТ-индустрии такой подход гарантированно приводит к катастрофе: бюджеты исчерпаны, сроки сорваны, а система не работает. Чтобы этого избежать, были созданы стандарты жизненного цикла — «правила игры», которые определяют, что и в какой последовательности нужно делать с информационной системой (ИС) от момента возникновения идеи до её полной утилизации.

Архитектура процессов ISO/IEC 12207

Международный стандарт ISO/IEC 12207 — это своего рода «конституция» для разработчиков и заказчиков во всем мире. Он не диктует конкретные методы программирования, но устанавливает общую структуру процессов. Весь жизненный цикл здесь разделен на три крупные группы, которые взаимодействуют друг с другом как шестеренки в сложном механизме.

Основные процессы (Primary Processes)

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

Заказ (Acquisition) — действия заказчика, который определяет потребность в системе.

Поставка (Supply) — действия поставщика, который обязуется создать систему.

Разработка (Development) — проектирование, кодирование и сборка.

Эксплуатация (Operation) — работа системы в реальных условиях, помощь пользователям.

Сопровождение (Maintenance) — внесение изменений, исправление ошибок и адаптация к новым условиям.

Вспомогательные процессы (Supporting Processes)

Они не создают продукт напрямую, но обеспечивают его качество и прозрачность. Представьте, что разработка — это приготовление блюда, тогда вспомогательные процессы — это проверка свежести продуктов и заточка ножей. Сюда относятся документирование, управление конфигурацией (чтобы не запутаться в версиях кода), обеспечение качества (QA) и верификация (проверка того, что мы делаем систему правильно согласно спецификации).

Организационные процессы (Organizational Processes)

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

> Жизненный цикл ИС — это непрерывный процесс, начинающийся с момента принятия решения о необходимости создания системы и заканчивающийся в момент её полного изъятия из эксплуатации.

Отечественный подход: Комплекс ГОСТ 34

В то время как ISO 12207 фокусируется на процессах (что делать?), российский комплекс стандартов ГОСТ 34 (полное название — ГОСТ 34.601-90) делает упор на стадии и документальный результат каждой стадии. Это более жесткая, «инженерная» структура, которая идеально подходит для крупных государственных и индустриальных систем.

Если в ISO процессы могут идти параллельно и циклично, то ГОСТ 34 традиционно ассоциируется с каскадной моделью («водопадом»). Основные стадии по ГОСТ 34 включают:

Формирование требований: сбор «хотелок» заказчика и их анализ.

Разработка концепции: поиск вариантов реализации.

Техническое задание (ТЗ): главный документ, юридическая основа проекта. Если функции нет в ТЗ, разработчик имеет право её не делать.

Эскизный проект: предварительные проектные решения.

Технический проект: детальное описание структуры системы.

Рабочая документация: инструкции, схемы, коды.

Ввод в действие: монтаж, пусконаладка, обучение и приемочные испытания.

| Характеристика | ISO/IEC 12207 | ГОСТ 34 | | :--- | :--- | :--- | | Объект стандартизации | Процессы жизненного цикла | Стадии и виды работ | | Гибкость | Высокая (подходит для Agile/Scrum) | Низкая (строгая последовательность) | | Главный фокус | Взаимоотношения сторон | Документальное оформление | | Применение | Коммерческая разработка, международные проекты | Госзаказы, промышленность, КИИ |

Модели жизненного цикла: от Водопада до Спирали

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

Каскадная модель (Waterfall) подразумевает, что переход на следующую стадию происходит только после полного завершения предыдущей. Это как строительство моста: вы не можете начать заливать бетон, пока не закончен проект опор. Пример: Разработка системы управления атомной электростанцией. Ошибки недопустимы, требования жестко зафиксированы, изменения в процессе стоят миллионы.

Итерационная (инкрементная) модель позволяет разбивать проект на части. Сначала мы выпускаем версию 1.0 с базовыми функциями, затем 2.0 и так далее. Это снижает риски: если мы ошиблись в дизайне, мы узнаем об этом через месяц, а не через два года. Пример: Создание интернет-магазина. Сначала запускаем только каталог, затем добавляем корзину, потом — онлайн-оплату.

Спиральная модель (модель Боэма) делает акцент на рисках. Каждый виток спирали — это этап проектирования, на котором обязательно проводится анализ рисков и создание прототипа. Если риск слишком велик, проект может быть остановлен. Пример: Разработка инновационного ПО с использованием нейросетей, где изначально неясно, удастся ли достичь нужной точности распознавания.

Сравнительный анализ и выбор стратегии

Выбор между ISO 12207 и ГОСТ 34 — это не вопрос «что лучше», а вопрос контекста. Современные крупные компании часто используют гибридный подход. Они берут процессную модель из ISO для управления командой разработчиков, но оформляют результаты (ТЗ, акты приемки) по ГОСТу, чтобы соответствовать требованиям законодательства или службы безопасности.

Важно понимать, что нарушение последовательности жизненного цикла ведет к «техническому долгу». Если пропустить стадию формирования требований (ГОСТ) или процесс верификации (ISO), на этапе эксплуатации система начнет «рассыпаться», а стоимость исправления одной ошибки вырастет в десятки раз по сравнению с этапом проектирования.

где — порядковый номер стадии жизненного цикла. Если на стадии анализа требований ошибка стоит 1 рубль, то на стадии эксплуатации она может стоить 1000 рублей.

Если из этой главы запомнить три вещи — это:

ISO 12207 — это про процессы и управление, ГОСТ 34 — про стадии и документы.

Жизненный цикл охватывает всё: от идеи до утилизации (вывода из эксплуатации).

Модель жизненного цикла (водопад, итерация, спираль) выбирается исходя из неопределенности требований и рисков проекта.

Качество программного обеспечения: классификация характеристик, метрики и методы объективной оценки

Когда мы говорим, что программа «хорошая», мы часто имеем в виду субъективное ощущение. Однако в профессиональной инженерии качество — это измеряемая величина. Если мы не можем измерить надежность или удобство использования, мы не можем ими управлять. Оценка качества ПО строится на международных стандартах (таких как ISO/IEC 25010), которые раскладывают абстрактное понятие «качество» на конкретные атомарные характеристики.

Модель качества ISO/IEC 25010

Современный стандарт выделяет восемь ключевых характеристик качества, которые применимы к любой информационной системе. Понимание этих критериев позволяет составить «профиль качества» для конкретного проекта. Например, для банковского приложения критична безопасность, а для видеоигры — производительность.

Функциональная пригодность: делает ли программа то, что должна? Сюда входит полнота функций и их корректность.

Надежность: способность системы сохранять работоспособность в определенных условиях. Это отсутствие отказов и быстрое восстановление после сбоев.

Производительность (эффективность): как быстро система реагирует на запросы и сколько ресурсов (памяти, процессора) она при этом потребляет.

Удобство использования (Usability): насколько легко пользователю понять интерфейс и выполнить свою задачу без долгого обучения.

Безопасность: защита данных от несанкционированного доступа и обеспечение подлинности пользователей.

Совместимость: способность системы работать в одной среде с другим ПО или обмениваться с ним данными.

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

Мобильность (переносимость): возможность переноса ПО с одного сервера на другой или из одной операционной системы в другую.

> Качество ПО — это степень, в которой система соответствует заявленным и подразумеваемым потребностям заинтересованных сторон.

Метрики и методы измерения

Чтобы перевести характеристики в цифры, используются метрики. Метрика — это формула или правило, по которому вычисляется показатель.

Количественные показатели

Они измеряются объективно. Например, для оценки надежности часто используют показатель MTBF (Mean Time Between Failures) — среднее время между отказами.

где — общее время работы системы, а — количество зафиксированных сбоев. Если сервер проработал 1000 часов и упал 2 раза, его MTBF составит 500 часов.

Для оценки производительности измеряют время отклика (Response Time) — за сколько миллисекунд база данных выдает результат на запрос пользователя.

Качественные (экспертные) методы

Не всё можно измерить секундомером. Для оценки удобства использования или сопровождаемости применяют: * Метод экспертных оценок: группа специалистов выставляет баллы по шкале от 1 до 10. * Анкетирование пользователей: сбор субъективных мнений о комфорте работы. * Статический анализ кода: специальные программы проверяют код на наличие «запахов» (плохих практик), которые затрудняют его поддержку.

Эксплуатационные характеристики и их мониторинг

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

Доступность (Availability): вероятность того, что система будет работоспособна в любой момент времени. Обычно измеряется в «девятках». Например, доступность означает, что система может простаивать не более 8.76 часов в год.

Пропускная способность (Throughput): количество операций, которые система обрабатывает в единицу времени (например, транзакций в секунду — TPS).

Масштабируемость: способность системы сохранять производительность при росте нагрузки путем добавления ресурсов (процессоров или серверов).

Сравним два типа систем по приоритетам качества в таблице ниже:

| Тип системы | Приоритет 1 | Приоритет 2 | Приоритет 3 | | :--- | :--- | :--- | :--- | | Банковский бэк-офис | Безопасность | Надежность | Функциональная пригодность | | Мобильная игра | Удобство (UX) | Производительность | Мобильность | | Медицинское оборудование | Надежность | Функциональная корректность | Сопровождаемость |

Практический пример: Оценка качества системы документооборота

Представим, что мы внедряем систему электронного документооборота (СЭД). * Шаг 1. Определение критических метрик. Мы решаем, что для нас важнее всего «Время отклика при поиске документа» и «Время восстановления после сбоя». * Шаг 2. Замер базовых показателей. Тестировщики проводят нагрузочное тестирование: при 100 одновременных пользователях поиск занимает 2 секунды. * Шаг 3. Установка порогов (SLA). Мы прописываем в регламенте: «Поиск не должен превышать 3 секунды». * Шаг 4. Мониторинг. Если в процессе эксплуатации время поиска выросло до 5 секунд, это сигнал о снижении качества, требующий оптимизации базы данных.

Часто думают, что качество — это отсутствие ошибок в коде. На самом деле, программа может не иметь ни одной ошибки (бага), но быть абсолютно некачественной, если она неудобна пользователю или работает слишком медленно. Качество — это баланс между ожиданиями бизнеса и техническим совершенством.

Если из этой главы запомнить три вещи — это:

Качество — это не абстракция, а набор из 8 измеряемых характеристик по ISO 25010.

Для каждой характеристики существуют свои метрики (MTBF для надежности, TPS для производительности).

Приоритеты качества всегда зависят от назначения системы.

Процессы внедрения и модели коллективной разработки: стратегии, этапы и сценарии развертывания

Разработка программы — это только половина дела. Настоящее испытание начинается тогда, когда код встречается с реальной ИТ-инфраструктурой и живыми пользователями. Процесс внедрения информационной системы (ИС) — это комплекс мероприятий по вводу системы в эксплуатацию, который требует не только технических навыков, но и стратегического планирования.

Стратегии внедрения: как «переключить» организацию

Выбор стратегии внедрения зависит от масштаба системы и допустимых рисков. Существует три классических сценария:

Параллельная стратегия: Старая и новая системы работают одновременно в течение некоторого времени. Пользователи дублируют операции в обеих программах.

Плюс: Максимальная безопасность. Если новая система «упадет», работа не остановится. Минус: Двойная нагрузка на персонал и риск рассинхронизации данных.

Пилотное внедрение (метод «плацдарма»): Систему запускают только в одном подразделении или филиале. После отработки всех ошибок опыт тиражируется на всю организацию.

Пример: Внедрение новой CRM-системы сначала в отделе продаж Москвы, а через месяц — по всей России.

Прямое внедрение (шоковая терапия): В назначенный день старая система выключается, а новая включается.

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

Этапы процесса внедрения

Внедрение — это не разовое событие, а последовательность этапов, каждый из которых имеет свою цель:

* Подготовка инфраструктуры: Закупка и настройка серверов, прокладка сетей, установка системного ПО. * Установка и настройка (конфигурирование): Развертывание кода ИС, настройка параметров под конкретный бизнес-процесс (например, ввод налоговых ставок или прав доступа). * Миграция данных: Самый сложный этап. Нужно перенести информацию из старых таблиц Excel или баз данных в новую структуру, сохранив целостность и очистив данные от «мусора». * Обучение пользователей: Проведение семинаров, подготовка видеоинструкций. Без этого этапа даже самая лучшая система будет встречена саботажем. * Опытная эксплуатация: Работа в реальных условиях, но под усиленным наблюдением разработчиков. На этом этапе выявляются скрытые дефекты.

Модели коллективной разработки

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

Централизованная модель: Весь код хранится на одном сервере. Чтобы внести изменения, разработчик «забирает» файл, правит его и «отдает» обратно. Проблема: Если сервер недоступен, работа встает.

Распределенная модель (например, на базе Git): У каждого разработчика есть полная копия всего проекта на его компьютере. Синхронизация происходит через специальные запросы на слияние (Merge Requests). Это позволяет работать над разными функциями параллельно, не мешая друг другу.

Коллективная разработка часто строится по сценарию CI/CD (Continuous Integration / Continuous Deployment):

Разработчик пишет код и отправляет его в общую ветку.

Робот автоматически собирает программу и запускает тесты.

Если тесты пройдены, код автоматически «выкатывается» на тестовый сервер (Staging).

После одобрения менеджером код попадает к реальным пользователям (Production).

Сценарии развертывания (Deployment)

В зависимости от архитектуры, развертывание может происходить по-разному: * On-premise: Система устанавливается на собственные серверы компании. Это дает полный контроль и безопасность, но требует штата системных администраторов. * SaaS (Software as a Service): Система работает в облаке провайдера. Пользователи заходят через браузер. Это дешевле и быстрее, но данные хранятся «на стороне». * Гибридный сценарий: Чувствительные данные (персональные данные клиентов) хранятся на своих серверах, а вычислительные мощности (например, нейросеть для обработки фото) арендуются в облаке.

> Внедрение — это не только техническая инсталляция, но и социальный процесс адаптации сотрудников к новым инструментам труда.

Многие думают, что внедрение заканчивается нажатием кнопки «Install». На самом деле, 70% успеха внедрения зависит от качества миграции данных и готовности персонала. Если в базе данных будут ошибки, пользователи быстро разочаруются в системе, какой бы красивой она ни была.

Если из этой главы запомнить три вещи — это:

Пилотное внедрение — самый сбалансированный способ минимизации рисков.

Миграция данных — «бутылочное горлышко» любого внедрения.

Современная разработка немыслима без распределенных систем контроля версий и автоматизации CI/CD.

Обеспечение надежности: методы тестирования, многоуровневая безопасность и техническая поддержка ИС

Информационная система — это живой организм. После внедрения она сталкивается с агрессивной средой: хакерскими атаками, ошибками пользователей и сбоями оборудования. Чтобы система не «умерла» в первый же месяц, инженеры используют три линии обороны: глубокое тестирование, комплексную модель безопасности и структурированную поддержку.

Методы и типы тестирования ПО

Тестирование — это не просто поиск багов, это проверка системы на прочность. Существует два фундаментальных подхода:

Метод «Черного ящика»: Тестировщик не знает, как устроен код. Он вводит данные и проверяет результат. Если нажать «Купить», товар должен появиться в корзине.

Метод «Белого ящика»: Тестировщик анализирует саму логику кода, проверяя все ветвления и циклы.

По уровням проверки тесты делятся на: * Модульные (Unit-тесты): Проверка отдельных функций (например, правильно ли считается скидка). * Интеграционные: Проверка того, как разные части системы общаются друг с другом (например, передает ли сайт заказ в базу данных). * Системные: Проверка всей системы в целом на соответствие требованиям. * Приемочные (UAT): Финальный тест, который проводит сам заказчик, чтобы решить — платить за работу или нет.

Три составляющие информационной безопасности (Триада CIA)

Безопасность ИС — это не только пароли. Международный стандарт определяет три столпа защиты:

Конфиденциальность: Данные доступны только тем, кто имеет на это право. (Пример: врач видит медкарту, а бухгалтер — нет).

Целостность: Данные защищены от случайного или намеренного искажения. (Пример: сумма перевода в банке не может измениться в процессе отправки).

Доступность: Система готова к работе всегда, когда она нужна легальному пользователю. (Защита от DDoS-атак).

Для реализации этой триады используются модели безопасности: * Дискреционная (DAC): Владелец файла сам решает, кому дать доступ (как в папках Windows). * Ролевая (RBAC): Доступ зависит от должности. «Менеджер» может смотреть отчеты, «Администратор» — удалять пользователей. * Мандатная (MAC): Каждому объекту присваивается уровень секретности (например, «Секретно»), а пользователю — уровень допуска. Самая строгая модель, используется в госсекторе.

Организация обновлений и техническая поддержка

Система начинает устаревать в момент выхода. Для поддержания её «здоровья» используется трехуровневая модель поддержки (L1–L3): * L1 (Service Desk): Принимают звонки, сбрасывают пароли, отвечают на простые вопросы по инструкциям. * L2 (Технические специалисты): Настраивают ПО, исправляют ошибки конфигурации, разбираются в логах серверов. * L3 (Разработчики): Исправляют ошибки в самом коде или выпускают новые версии (патчи).

Обновления (патчи) бывают двух видов: * Hotfix: Срочное исправление критической дыры в безопасности или ошибки, остановившей работу. * Release: Плановое обновление с новыми функциями и мелкими правками.

Резервное копирование и восстановление

Надежность невозможна без бэкапов. Существует три основных типа резервного копирования:

Полное (Full): Копируются все данные. Долго, занимает много места, но восстанавливать проще всего.

Дифференциальное (Differential): Копируются все изменения с момента последнего полного бэкапа.

Инкрементальное (Incremental): Копируются только изменения с момента любого последнего бэкапа. Самый быстрый способ копирования, но самый сложный для восстановления (нужна вся цепочка копий).

> Правило 3-2-1: Храните как минимум 3 копии данных, на 2 разных носителях, причем 1 копия должна находиться в другом здании (географически удаленно).

Часто думают, что антивирус — это и есть безопасность. На самом деле, большинство утечек происходит из-за ошибок в правах доступа (нарушение конфиденциальности) или отсутствия бэкапов (нарушение доступности). Безопасность — это процесс, а не продукт.

Если из этой главы запомнить три вещи — это:

Тестирование «белого ящика» проверяет код, «черного» — функции.

Триада безопасности: Конфиденциальность, Целостность, Доступность.

Инкрементальный бэкап экономит место, но требует бережного хранения всей цепочки архивов.

Документирование по стандартам ЕСПД и инструментальные CASE-технологии автоматизации внедрения

Завершающий этап создания информационной системы — это её «паспортизация». Без качественной документации система превращается в «черный ящик», который невозможно поддерживать или развивать. В России стандарты оформления программной документации объединены в систему ЕСПД (Единая система программной документации).

Состав и назначение ЕСПД

ЕСПД (серия ГОСТ 19) — это набор правил, которые определяют, как должны выглядеть документы на программу. Если ГОСТ 34 (из первой статьи) говорит о системе в целом, то ГОСТ 19 фокусируется именно на программном коде и пояснительных текстах к нему.

Основные документы по ЕСПД включают:

Спецификация: Главный документ, перечисляющий все части программы (файлы, модули).

Пояснительная записка: Описание того, как работает программа, какие алгоритмы в ней заложены.

Текст программы: Собственно исходный код (сейчас распечатывается редко, но формально входит в состав).

Описание применения: Краткая справка о том, для чего нужна программа и какие условия нужны для её запуска.

Эксплуатационная документация: Руководство оператора

Это самый важный документ для тех, кто будет работать с системой ежедневно. Согласно ГОСТ 19.505-79, Руководство оператора должно содержать строго определенные разделы: * Назначение программы: Какие задачи решает пользователь. * Условия выполнения: Минимальные требования к компьютеру (ОЗУ, процессор, ОС). * Выполнение программы: Пошаговая инструкция — как запустить, как ввести данные, как нажать «ОК». * Сообщения оператору: Расшифровка всех ошибок. Если система пишет «Error 404», в руководстве должно быть сказано, что делать пользователю.

Отдельно стоит Руководство системного программиста (или администратора). В нем описывается настройка серверов, создание бэкапов и установка обновлений.

CASE-технологии: Автоматизация внедрения и разработки

Разрабатывать документацию и проектировать сложные системы вручную — слишком долго. Для этого существуют CASE-средства (Computer-Aided Software Engineering). Это программы, которые помогают создавать другие программы.

CASE-технологии делятся на: * Upper CASE: Инструменты для аналитиков. Позволяют рисовать схемы бизнес-процессов и диаграммы баз данных (например, в нотации UML). * Lower CASE: Инструменты для программистов. Генераторы кода, которые превращают визуальную схему в готовые таблицы базы данных. * Integrated CASE: Системы, сопровождающие проект от ТЗ до генерации документации.

Применение CASE-средств позволяет автоматически поддерживать документацию в актуальном состоянии. Если вы изменили структуру базы данных в визуальном редакторе, CASE-средство само обновит описание в «Пояснительной записке».

Аппаратно-программные платформы и настройка доступа

Для успешного внедрения документация должна четко описывать среду развертывания. Серверные платформы сегодня делятся на: * Башенные (Tower): Похожи на обычные ПК, подходят для малого бизнеса. * Стоечные (Rack): Устанавливаются в специальные шкафы, экономят место в дата-центрах. * Блейд-серверы: Сверхплотные системы, где в одном корпусе находятся десятки серверов.

При настройке в среде Windows ключевым моментом является управление сетевым доступом. Это включает:

Настройку разрешений NTFS: Кто может читать или удалять файлы на диске.

Настройку Share-доступа: Права доступа к папке через сеть.

Настройку брандмауэра (Firewall): Открытие портов (например, порт 80 для веб-сайта или 1433 для SQL-сервера), чтобы пользователи могли «достучаться» до системы.

Совместимость и конфликты ПО

Одной из задач документации является описание вопросов совместимости. * Горизонтальная совместимость: Работа с другими программами того же уровня (например, антивирус не должен конфликтовать с системой учета). * Вертикальная совместимость: Работа программы на разных версиях ОС (Windows 10 vs Windows 11).

Для решения проблем несовместимости при внедрении часто используют виртуализацию или контейнеризацию (Docker). Это позволяет запустить программу в изолированной «коробке», где есть все нужные ей библиотеки, не ломая настройки остального сервера.

Если из этой главы запомнить три вещи — это:

ЕСПД (ГОСТ 19) — это стандарты для программной документации, а Руководство оператора — библия пользователя.

CASE-технологии автоматизируют рутину: от рисования схем до генерации кода и отчетов.

Правильная настройка сетевого доступа и учет совместимости — залог того, что внедренная система не «отвалится» при первом же обновлении Windows.