From de997e3a7ef23558089e30493fdf7ebb895b37b8 Mon Sep 17 00:00:00 2001 From: spirik Date: Fri, 11 Sep 2026 11:15:40 +0000 Subject: [PATCH] =?UTF-8?q?=D0=97=D0=B0=D0=B3=D1=80=D1=83=D0=B7=D0=B8?= =?UTF-8?q?=D1=82=D1=8C=20=D1=84=D0=B0=D0=B9=D0=BB=D1=8B=20=D0=B2=20=C2=AB?= =?UTF-8?q?/=C2=BB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...кция_Жизненный_цикл_информационных_систем.md | 735 ++++++++++++++++++ 1 file changed, 735 insertions(+) create mode 100644 Лекция_Жизненный_цикл_информационных_систем.md diff --git a/Лекция_Жизненный_цикл_информационных_систем.md b/Лекция_Жизненный_цикл_информационных_систем.md new file mode 100644 index 0000000..b159a2f --- /dev/null +++ b/Лекция_Жизненный_цикл_информационных_систем.md @@ -0,0 +1,735 @@ +# Лекция. Жизненный цикл информационных систем + +**Дисциплина:** Внедрение информационных систем +**Тема:** Жизненный цикл информационных систем + + +## 1. Тема, цель и задачи лекции + +Добрый день. Сегодня мы будем говорить не о том, «как написать ещё одну программу», а о том, **как система живёт во времени**. Информационная система (information system, IS) не появляется в момент установки дистрибутива и не исчезает в день приёмки. Она задумывается, обосновывается, проектируется, внедряется, эксплуатируется, меняется и когда-нибудь выводится из эксплуатации. Этот путь и называют жизненным циклом. + +**Тема лекции:** жизненный цикл информационных систем: понятие, стандарты, модели, стадии, роли участников и документационное обеспечение. + +**Задачи лекции:** + +1. Дать точные определения жизненного цикла, стадии, этапа и процесса и показать, чем эти понятия отличаются. +2. Разобрать ключевые положения ГОСТ 34.601-90, ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288 и ГОСТ Р ИСО/МЭК 12207-2010 со ссылками на конкретные пункты. +3. Сравнить основные модели жизненного цикла и научиться выбирать модель под тип системы, степень неопределённости требований и организационный контекст. +4. Подробно пройти стадии создания автоматизированной системы по ГОСТ 34.601-90 и связать их с ролями и комплектами документов. +5. На реальных кейсах ERP, CRM и государственной ИС показать, как решения по управлению жизненным циклом влияют на успех или провал проекта. +6. Выделить типичные ошибки и риски, которые повторяются из проекта в проект. + +--- + +## 2. Актуальность темы + +Почему эта тема нужна именно вам, которые уже писали курсовые, собирали базы данных и, возможно, работали на стажировке? + +Во-первых, **внедрение информационной системы — это не установка ПО**. Когда вы приходите в компанию как аналитик, консультант, руководитель проекта или специалист службы заказчика, вас оценивают не по умению нарисовать диаграмму классов, а по умению провести систему через обследование, согласование требований, приёмку, опытную эксплуатацию и сопровождение. Работодатель спрашивает: умеете ли вы читать техническое задание по ГОСТ 34.602, понимать, что такое опытная эксплуатация по п. 7.7 ГОСТ 34.601-90, и объяснить, почему для госконтракта нельзя «просто работать по Scrum» без адаптации. + +Во-вторых, **большинство провалов ИТ-проектов — это провалы жизненного цикла, а не кода**. Классические исследования Standish Group (отчёты CHAOS) годами фиксируют одну и ту же картину: проекты срываются из-за неясных требований, слабого вовлечения заказчика, нереалистичных сроков и позднего обнаружения ошибок. Всё это — признаки неверно выбранной или плохо управляемой модели жизненного цикла. + +В-третьих, **российская практика двойственна**. В коммерческом секторе вы встретите Agile, SAFe, гибридные схемы «водопад на контракте — итерации внутри команды». В государственном секторе, на объектах КИИ, в оборонке и на крупных промышленных предприятиях вас встретят ГОСТ 34, 44-ФЗ / 223-ФЗ, экспертиза документации и акты приёмки. Специалист, который знает только Scrum, в этом мире беспомощен. Специалист, который знает только ГОСТ 34 и не понимает итеративности, тоже. + +В-четвёртых, **стандарты — это язык профессии**. ISO/IEC/IEEE 12207 и ISO/IEC/IEEE 15288 используются в системной инженерии Airbus, NASA, в крупных интеграторах. ГОСТ Р ИСО/МЭК 12207-2010 — российская гармонизация этой логики. Если вы умеете говорить на языке процессов (process), выходов (outcome) и адаптации (tailoring), вас понимают и в министерстве, и в международном проекте. + +В-пятых, **ваша карьера будет двигаться вдоль жизненного цикла**. На 3–4 курсе вы чаще всего попадаете в разработку или тестирование. Через несколько лет — в аналитику, внедрение, сопровождение, управление проектом, службу заказчика. Человек, который видит систему целиком, быстрее становится тимлидом и руководителем проекта, чем тот, кто видит только свой спринт. + +Представьте два сценария. В первом вы устраиваетесь в интегратор, который внедряет 1С:ERP на машиностроительном заводе. Заказчик требует комплект по ГОСТ 34, потому что предприятие входит в контур госкорпорации. Во втором — вы попадаете в продуктовую команду, которая развивает облачный CRM для малого бизнеса и выпускает релиз каждые две недели. В обоих случаях объект называется «информационная система», но жизненный цикл устроен по-разному. Сегодняшняя лекция как раз о том, чтобы вы не применяли один шаблон ко всем проектам. + +**Вывод по разделу.** Тема актуальна потому, что именно управление жизненным циклом определяет стоимость, сроки, качество и саму возможность приёмки системы — и в коммерческом, и в государственном контуре. + +--- + +## 3. Ключевые понятия и определения + +Прежде чем спорить о моделях, зафиксируем словарь. В стандартах одни и те же русские слова часто означают разное. + +### 3.1. Информационная система и автоматизированная система + +**Информационная система** (information system) — совокупность информационных технологий, персонала, данных, регламентов и технических средств, предназначенная для сбора, обработки, хранения и выдачи информации в интересах достижения целей организации. + +**Автоматизированная система** (automated system) в терминологии комплекса ГОСТ 34 — система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций. Обратите внимание: в ГОСТ 34 человек — часть системы, а не «пользователь снаружи». Это принципиально. Если вы спроектировали блестящий интерфейс, но не подготовили персонал (этап 7.2 ГОСТ 34.601-90), система по стандарту ещё не введена в действие. + +В ISO/IEC/IEEE 15288 используется более широкое понятие **системы, представляющей интерес** (system-of-interest): искусственно созданная система, которая может включать аппаратуру, программные средства, данные, людей, процессы, процедуры, сооружения и материалы. + +### 3.2. Жизненный цикл + +**Жизненный цикл информационной системы** (system life cycle, software life cycle) — совокупность процессов, работ и задач, охватывающих весь период существования системы: от замысла и обоснования потребности до прекращения применения и утилизации. + +Важная оговорка. ГОСТ 34.601-90 формально описывает не весь жизненный цикл в современном смысле, а **стадии создания** автоматизированной системы — от формирования требований до сопровождения. Эксплуатация как самостоятельная длительная стадия в таблице п. 2.1 стандарта не выделена: она подразумевается между вводом в действие и работами по сопровождению, а также в логике «развития АС» (п. 1.3). Международные стандарты ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207 смотрят шире: у них есть процессы функционирования (operation), сопровождения (maintenance) и прекращения применения (disposal). + +### 3.3. Стадия, этап, процесс, деятельность, задача + +Эти пять слов студенты часто употребляют как синонимы. Это ошибка. + +| Понятие | Английский эквивалент | Смысл | Где закреплено | +| --- | --- | --- | --- | +| Стадия | stage | Крупный отрезок создания системы, выделяемый для планирования и завершаемый заданным результатом | ГОСТ 34.601-90, п. 1.2 | +| Этап | step / activity group | Часть стадии, имеющая более локальный результат | ГОСТ 34.601-90, п. 2.1, таблица | +| Процесс | process | Совокупность взаимосвязанных действий, преобразующих входы в выходы и имеющая цель и результаты | ГОСТ Р ИСО/МЭК 12207-2010, разд. 5; ISO/IEC/IEEE 12207:2017, п. 5.5 | +| Деятельность (работа) | activity | Набор задач внутри процесса | ISO/IEC/IEEE 12207, описание процессов | +| Задача | task | Атомарное требование «что должно быть сделано» | ISO/IEC/IEEE 12207, 15288 | + +**Стадия** отвечает на вопрос: *в какой фазе находится система как проект?* +**Процесс** отвечает на вопрос: *какая работа должна выполняться, возможно, на нескольких стадиях сразу?* + +Пример. Процесс менеджмента рисков (risk management process, ГОСТ Р ИСО/МЭК 12207-2010, п. 6.3.4) не «живёт» только на стадии проектирования. Он идёт от обследования до сопровождения. А стадия «Технический проект» — это конкретный отрезок календаря с конкретным комплектом документов. + +### 3.4. Модель жизненного цикла + +**Модель жизненного цикла** (life cycle model) — схема организации стадий и процессов во времени: последовательность, итерации, условия перехода, точки принятия решений (decision gates). + +ГОСТ Р ИСО/МЭК 12207-2010 в п. 5.1.12 прямо указывает: стандарт **не предписывает** конкретную модель жизненного цикла. Он задаёт процессы, а модель выбирает организация. Это одна из самых важных фраз курса. Стандарт — не «водопад по умолчанию». + +### 3.5. Заинтересованная сторона и правообладатель + +**Заинтересованная сторона** (stakeholder) — лицо или организация, которые влияют на систему, зависят от неё или считают себя затронутыми её существованием. + +В ГОСТ Р ИСО/МЭК 12207-2010 используется термин **правообладатель** (stakeholder) в процессе определения требований правообладателей (п. 6.4.1). Для вас как будущих аналитиков это сигнал: требования собирают не только у «пользователя, который будет кликать кнопки», но и у службы безопасности, юристов, бухгалтерии, регулятора, службы эксплуатации. + +### 3.6. Верификация и валидация + +**Верификация** (verification) — подтверждение того, что продукт соответствует спецификации: «мы сделали систему правильно». +**Валидация** (validation) — подтверждение того, что продукт удовлетворяет потребности заинтересованных сторон: «мы сделали правильную систему». + +Путаница этих понятий дорого стоит. Система может идеально соответствовать техническому заданию (верификация пройдена) и при этом быть бесполезной в реальной работе склада (валидация провалена). Именно поэтому в V-модели и в ISO/IEC/IEEE 15288 верификация и валидация — разные технические процессы (п. 6.4.9 и 6.4.11 ISO/IEC/IEEE 15288:2015). + +### 3.7. Сопровождение, развитие, вывод из эксплуатации + +**Сопровождение** (maintenance) — работы по сохранению и восстановлению работоспособности системы, устранению дефектов, адаптации к изменившейся среде. +**Развитие** (evolution / enhancement) — изменение функциональности; по п. 1.3 ГОСТ 34.601-90 развитие АС выполняют по тем же стадиям, что и создание. +**Прекращение применения** (disposal / retirement) — вывод системы из эксплуатации, миграция данных, уничтожение или архивирование носителей, снятие с учёта. + +**Вывод по разделу.** Стадия — единица планирования проекта, процесс — единица инженерной работы; модель жизненного цикла связывает их во времени, а верификация и валидация отвечают на разные вопросы о качестве системы. + +--- + +## 4. Основное содержание + +### 4.1. Понятие жизненного цикла ИС + +Представим информационную систему как живой организм — но без лишней поэзии, на языке инженерии. + +У системы есть **зачатие**: кто-то в организации чувствует боль. Склад не сходится с бухгалтерией. Гражданин не может получить справку без очереди. Коммерческий директор не видит воронку продаж. Эта боль ещё не требование и тем более не техническое задание. Это потребность (need). + +Дальше потребность превращается в **замысел**: нужно ли вообще создавать систему? Не дешевле ли нанять ещё трёх человек, купить коробочный продукт или изменить регламент? ГОСТ 34.601-90 на этапе 1.1 прямо требует оценить целесообразность создания АС — технико-экономическую, социальную и иную. Если вы пропускаете этот шаг, вы рискуете автоматизировать хаос. + +Затем система проходит **создание**: требования, концепция, проект, реализация, ввод в действие. После этого начинается самая длинная и часто самая дорогая часть — **функционирование**. Исследования стоимости владения (total cost of ownership, TCO) для корпоративных систем показывают: разработка редко превышает 20–40% совокупных затрат. Остальное — лицензии, инфраструктура, сопровождение, доработки, обучение, простои. + +Наконец, система **умирает** или, точнее, выводится. Данные мигрируют, контуры отключают, носители уничтожают по требованиям информационной безопасности и архивного дела. В государственных системах это ещё и вопрос 152-ФЗ, отраслевых регламентов и актов на списание. + +Жизненный цикл — это способ **сделать этот путь управляемым**. Управляемым значит: + +- есть понятные точки принятия решений (можно ли переходить дальше); +- есть ответственные роли; +- есть документированные требования и конфигурация; +- есть оценка рисков и качества; +- есть возможность объяснить регулятору и заказчику, почему система такая, какая есть. + +С точки зрения ISO/IEC/IEEE 15288 жизненный цикл раскладывается на типовые стадии системной инженерии: замысел (concept), разработка (development), производство (production), применение (utilization), поддержка (support), списание (retirement). Эти стадии можно накладывать на ГОСТ 34, на каскад, на спираль, на Agile. Модель — способ развернуть процессы во времени, а не замена самих процессов. + +Ещё одно важное свойство: жизненный цикл **рекурсивен**. Большая государственная информационная система состоит из подсистем, каждая из которых имеет свой цикл. Модуль «Личный кабинет» может уже эксплуатироваться, пока модуль «Аналитика» ещё в проектировании. ISO/IEC/IEEE 15288 прямо допускает применение процессов одновременно, итеративно и рекурсивно к системе и её элементам. + +Для внедрения это означает практический вывод: вы почти никогда не внедряете «всю систему сразу». Вы внедряете контуры, очереди, релизы, площадки. Вопрос в том, как вы это называете в договоре и как синхронизируете документацию. + +**Вывод по разделу.** Жизненный цикл ИС — управляемая последовательность процессов от потребности до вывода из эксплуатации; создание системы — лишь часть этого пути, а самая дорогая часть обычно приходится на функционирование и сопровождение. + +--- + +### 4.2. Стандарты, регламентирующие жизненный цикл + +Стандарты в нашей теме — не «формальность для зачёта». Это разные оптики, через которые смотрят на одну и ту же систему. Разберём четыре ключевых документа и их связь. + +#### 4.2.1. ГОСТ 34.601-90. Стадии создания автоматизированных систем + +Полное наименование: *Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания*. + +Область применения — автоматизированные системы, используемые в различных видах деятельности (исследование, проектирование, управление и их сочетания), создаваемые в организациях и на предприятиях. + +Ключевые положения, которые вы должны уметь цитировать: + +- **п. 1.1.** Процесс создания АС — совокупность упорядоченных во времени, взаимосвязанных, объединённых в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. +- **п. 1.2.** Стадии и этапы выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом. +- **п. 1.3.** Работы по развитию АС осуществляют по тем же стадиям и этапам. +- **п. 1.4.** Состав и правила выполнения работ определяют в документации организаций-участников. +- **п. 2.1.** Приведена нормативная таблица из восьми стадий и детализирующих их этапов (1.1–8.2). +- **п. 2.2.** Стадии и этапы участников устанавливаются в договорах и ТЗ. Допускается исключать стадию «Эскизный проект», объединять «Технический проект» и «Рабочую документацию» в «Технорабочий проект», выполнять отдельные этапы до завершения предшествующих стадий, вести работы параллельно, включать новые этапы. + +Приложение 1 (справочное) детализирует содержание работ на каждом этапе. Приложение 2 перечисляет организации-участники: заказчик, разработчик, поставщик, генпроектировщик, проектировщики смежных частей, строительно-монтажные и наладочные организации. + +Рядом с 34.601 всегда живут «соседи» комплекса ГОСТ 34: + +- **ГОСТ 34.602** — техническое задание на создание АС (актуальная редакция — ГОСТ 34.602-2020); +- **ГОСТ 34.201** — виды, комплектность и обозначение документов (актуальная редакция — ГОСТ 34.201-2020); +- **ГОСТ 19.101-77** — виды программных документов (на него прямо ссылается приложение 1 ГОСТ 34.601-90 при разработке программ). + +Практический смысл ГОСТ 34.601-90 для внедрения: он задаёт **каркас приёмки**. Если в государственном контракте написано «создание АС по ГОСТ 34», вы обязаны понимать, что такое предварительные испытания (этап 7.6), опытная эксплуатация (7.7) и приёмочные испытания (7.8). Без этих трёх актов система юридически не введена в постоянную эксплуатацию. + +#### 4.2.2. ISO/IEC/IEEE 12207. Процессы жизненного цикла программных средств + +Международный стандарт *Systems and software engineering — Software life cycle processes*. Актуальная редакция — **ISO/IEC/IEEE 12207:2017**. Предшественник — ISO/IEC 12207:2008, который лёг в основу российского ГОСТ Р ИСО/МЭК 12207-2010. + +Стандарт задаёт **общую рамку процессов** для приобретения, поставки, разработки, функционирования, сопровождения и прекращения применения программных продуктов и услуг. Он не говорит: «сначала сделайте эскизный проект». Он говорит: «в организации должны быть процессы с определёнными целями и выходами; выберите и адаптируйте их». + +В редакции 2017 года структура гармонизирована с ISO/IEC/IEEE 15288. Раздел 6 описывает процессы: + +- **п. 6.1.** Процессы соглашения (agreement processes): приобретение (acquisition), поставка (supply); +- **п. 6.2.** Процессы организационного обеспечения проекта (organizational project-enabling processes): менеджмент модели ЖЦ, инфраструктуры, портфеля, качества и др.; +- **п. 6.3.** Процессы технического менеджмента (technical management processes): планирование, оценка и контроль, решения, риски, конфигурация, информация, измерения; +- **п. 6.4.** Технические процессы (technical processes): от анализа бизнеса и определения потребностей заинтересованных сторон до функционирования, сопровождения и прекращения применения. + +Адаптация (tailoring) вынесена в нормативное приложение A: организация вправе выбрать подмножество процессов, но должна это **заявить**. Нельзя молча «выкинуть» верификацию и потом утверждать соответствие стандарту. + +Для внедрения особенно важны процессы соглашения. Пока нет ясного приобретения и поставки — кто что покупает, что является результатом, как принимается работа, — техническая команда работает в юридическом вакууме. + +#### 4.2.3. ISO/IEC/IEEE 15288. Процессы жизненного цикла систем + +Полное наименование: *Systems and software engineering — System life cycle processes*. Базовая для курса редакция — **ISO/IEC/IEEE 15288:2015**; действует также редакция 2023 года. Российская гармонизация логики 15288 — **ГОСТ Р 57193-2016**. + +Если 12207 смотрит на программные средства, то 15288 смотрит на **систему как целое**: аппаратура, ПО, люди, процессы, сооружения. Для внедрения корпоративных и государственных ИС это часто более честная оптика. ERP — это не только программа. Это серверы или облако, каналы связи, сканеры штрихкода, регламент склада, обучение кладовщика и приказ о новой учётной политике. + +Технические процессы по п. 6.4 ISO/IEC/IEEE 15288:2015: + +| Пункт | Процесс | Английский термин | +| --- | --- | --- | +| 6.4.1 | Анализ бизнеса или миссии | Business or mission analysis | +| 6.4.2 | Определение потребностей и требований заинтересованных сторон | Stakeholder needs and requirements definition | +| 6.4.3 | Определение системных требований | System requirements definition | +| 6.4.4 | Определение архитектуры | Architecture definition | +| 6.4.5 | Определение проекта (дизайна) | Design definition | +| 6.4.6 | Системный анализ | System analysis | +| 6.4.7 | Реализация | Implementation | +| 6.4.8 | Комплексирование (интеграция) | Integration | +| 6.4.9 | Верификация | Verification | +| 6.4.10 | Передача в эксплуатацию (транзит) | Transition | +| 6.4.11 | Валидация | Validation | +| 6.4.12 | Функционирование | Operation | +| 6.4.13 | Сопровождение | Maintenance | +| 6.4.14 | Прекращение применения | Disposal | + +Сравните с ГОСТ 34. Вы увидите знакомые смыслы, но другую нарезку: здесь нет «эскизного проекта» как обязательной стадии, зато явно выделены бизнес-анализ, транзит и disposal. + +Процессы технического менеджмента (п. 6.3) — планирование, оценка и контроль, менеджмент решений, рисков, конфигурации, информации, измерений, обеспечения качества — это то, чем на проекте внедрения ежедневно занимается руководитель проекта и служба качества. + +#### 4.2.4. ГОСТ Р ИСО/МЭК 12207-2010 + +Национальный стандарт Российской Федерации, утверждён приказом Росстандарта от 30.11.2010 № 631-ст. Это аутентичный перевод ISO/IEC 12207:2008 с учётом российской терминологии. + +Структура, которую нужно помнить: + +**Раздел 5** — ключевые понятия и применение: внедрение на уровне организации и проекта, адаптация, временные отношения процессов, модели и стадии ЖЦ (п. 5.1.12), категории процессов (п. 5.2). + +**Раздел 6** — процессы жизненного цикла систем: + +- **6.1.** Процессы соглашения: 6.1.1 приобретение, 6.1.2 поставка; +- **6.2.** Процессы организационного обеспечения проекта: 6.2.1 менеджмент модели ЖЦ, 6.2.2 инфраструктура, 6.2.3 портфель проектов, 6.2.4 людские ресурсы, 6.2.5 качество; +- **6.3.** Процессы проекта: 6.3.1 планирование, 6.3.2 оценка и управление, 6.3.3 решения, 6.3.4 риски, 6.3.5 конфигурация, 6.3.6 информация, 6.3.7 измерения; +- **6.4.** Технические процессы: 6.4.1 требования правообладателей, 6.4.2 анализ системных требований, 6.4.3 архитектура системы, 6.4.4 реализация, 6.4.5 комплексирование системы, 6.4.6 квалификационное тестирование системы, 6.4.7 инсталляция программных средств, 6.4.8 поддержка приёмки, 6.4.9 функционирование, 6.4.10 сопровождение, 6.4.11 прекращение применения. + +**Раздел 7** — процессы жизненного цикла программных средств: + +- **7.1.** Реализация программных средств: 7.1.1 реализация, 7.1.2 анализ требований к ПС, 7.1.3 проектирование архитектуры ПС, 7.1.4 детальное проектирование, 7.1.5 конструирование, 7.1.6 комплексирование, 7.1.7 квалификационное тестирование; +- **7.2.** Поддержка: документация, конфигурация, гарантия качества, верификация, валидация, ревизия, аудит, решение проблем; +- **7.3.** Повторное применение: инженерия доменов, менеджмент активов, менеджмент повторного применения. + +Обратите внимание на тонкость, которую любят спрашивать на экзамене. В ГОСТ Р ИСО/МЭК 12207-2010 (версия 2008) технические процессы раздела 6 ближе к «системному контуру», а раздел 7 детализирует именно программные средства. В ISO/IEC/IEEE 12207:2017 нарезка уже почти совпадает с 15288. Когда в дипломе или отчёте вы ссылаетесь на стандарт, **указывайте редакцию**. + +#### 4.2.5. Как стандарты стыкуются на реальном проекте внедрения + +Типичная рабочая схема для российского внедрения: + +1. **Договор и предмет** описывают создание / развитие АС по комплексу ГОСТ 34 (стадии, ТЗ, виды документов, испытания). +2. **Внутренняя инженерия исполнителя** строится по процессам ГОСТ Р ИСО/МЭК 12207 / ISO/IEC/IEEE 12207: управление требованиями, конфигурацией, верификацией, рисками. +3. **Системный контур** (инфраструктура, интеграции, персонал, регламенты) осмысляется через ISO/IEC/IEEE 15288 / ГОСТ Р 57193. +4. **Модель ЖЦ** (каскад, V, инкременты, Agile) выбирается в процессе менеджмента модели жизненного цикла (п. 6.2.1 ГОСТ Р ИСО/МЭК 12207-2010) и фиксируется в плане проекта. + +Иными словами: ГОСТ 34 отвечает на вопрос *«какие стадии и какие документы сдаём заказчику»*. ISO 12207/15288 отвечают на вопрос *«какие процессы должны работать внутри, чтобы эти стадии не превратить в театр»*. + +**Вывод по разделу.** ГОСТ 34.601-90 задаёт стадии создания и каркас приёмки, а ISO/IEC/IEEE 12207, 15288 и ГОСТ Р ИСО/МЭК 12207-2010 задают процессную модель, которую организация адаптирует; стандарты дополняют друг друга, а не конкурируют. + +--- + +### 4.3. Модели жизненного цикла + +Теперь — о том, как процессы раскладываются во времени. Модель — это не религия. Это ответ на три вопроса: насколько стабильны требования, насколько тяжёла цена ошибки, насколько заказчик готов участвовать непрерывно. + +#### 4.3.1. Каскадная модель (водопад, waterfall) + +Классическая схема Уинстона Ройса (Winston W. Royce, 1970) — хотя сам Ройс предупреждал о рисках «чистого» каскада. Идея: работы идут строго последовательно — требования → проектирование → реализация → тестирование → внедрение → сопровождение. Переход к следующей фазе — после формального завершения предыдущей. + +В российской практике каскад почти буквально совпадает с «общим случаем» таблицы п. 2.1 ГОСТ 34.601-90. Поэтому студенты иногда думают, что ГОСТ 34 *есть* водопад. Это неточно. Пункт 2.2 прямо разрешает параллельность, пропуск эскизного проекта и технорабочий проект. ГОСТ задаёт стадии, но не запрещает итерации. + +**Когда каскад честен:** требования относительно стабильны; предметная область хорошо изучена; высока цена изменения после начала реализации; заказчик и регулятор требуют полный комплект документации до кодирования (АСУ ТП, отдельные контуры КИИ, сертифицируемые системы). + +**Слабое место:** ошибка в требованиях всплывает поздно. Стоимость исправления растёт по мере продвижения по стадиям — это эмпирическое правило Боэма (Boehm): чем позже найден дефект, тем дороже он обходится. + +#### 4.3.2. V-модель (V-model) + +V-модель — развитие каскада. Левая ветвь — декомпозиция и проектирование, правая — интеграция и проверка. Каждый уровень спецификации зеркально связан с уровнем проверки: + +- требования пользователя ↔ приёмочные испытания (валидация); +- системные требования ↔ системные испытания; +- архитектурное проектирование ↔ интеграционные испытания; +- детальное проектирование ↔ модульные испытания. + +Это прямая иллюстрация пары «верификация / валидация». V-модель широко используется в автомобильной промышленности (Automotive SPICE), авиации, медицинских изделиях, где нужно доказать прослеживаемость (traceability) от требования до теста. + +Для внедрения ИС V-модель полезна даже тогда, когда разработка идёт итеративно: уже на стадии ТЗ вы закладываете программу и методику испытаний, а не пишете их «под занавес». + +#### 4.3.3. Итеративная модель (iterative model) + +Итеративная модель предполагает повторение цикла «планирование — реализация — оценка» с уточнением системы целиком. На первой итерации вы можете сделать «скелет» всех ключевых подсистем, на второй — наполнить их, на третьей — довести качество. + +Отличие от чистого инкремента: итерация чаще уточняет *всю* систему, а не обязательно добавляет готовый к поставке кусок функции. На практике границы размыты, и в литературе их часто объединяют. + +Итеративность хорошо ложится на п. 2.2 ГОСТ 34.601-90 (параллельность и выполнение этапов до завершения предшествующих стадий) и на логику ISO: процессы применяются итеративно. + +#### 4.3.4. Спиральная модель (spiral model) + +Предложена Барри Боэмом (Barry Boehm, 1986, 1988). Спираль — это не «ещё один водопад по кругу», а **модель, управляемая риском** (risk-driven). Каждый виток включает четыре сектора: + +1. определение целей, альтернатив, ограничений; +2. оценка и разрешение рисков (прототипы, модели, симуляции); +3. разработка и верификация очередного продукта витка; +4. планирование следующего витка. + +Спираль особенно уместна, когда главный враг проекта — не «не успеем написать код», а «не угадали архитектуру, интеграцию, нагрузку, согласие профсоюза, юридический статус ПДн». Типичный пример — первая в отрасли государственная система с биометрией или новая схема межведомственного взаимодействия. + +Слабое место спирали: она требует зрелого менеджмента рисков (п. 6.3.4 ГОСТ Р ИСО/МЭК 12207-2010). Если команда не умеет выявлять и закрывать риски, спираль превращается в бесконечное прототипирование. + +#### 4.3.5. Инкрементная модель (incremental model) + +Система поставляется **частями, имеющими самостоятельную ценность**. Первый инкремент — учёт договоров. Второй — биллинг. Третий — аналитика. Каждый инкремент проходит свой мини-цикл проектирования, реализации, испытаний и ввода. + +Для внедрения корпоративных систем это, пожалуй, самая частая взрослая схема. Ни один нормальный директор завода не согласится «выключить старый учёт на полгода, пока пишут всю ERP». Он согласится на очереди внедрения: финансы → закупки → производство → склад. + +Инкрементная модель хорошо сочетается с ГОСТ 34: каждая очередь может иметь своё ТЗ, свои испытания и свой акт ввода. Юридически это развитие АС по п. 1.3. + +#### 4.3.6. Agile и смежные гибкие подходы + +**Agile** — это не одна модель, а семейство подходов, опирающихся на Agile Manifesto (2001): люди и взаимодействие важнее процессов и инструментов; работающий продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования плану. + +На практике вы встретите: + +- **Scrum** — короткие спринты, роли Product Owner, Scrum Master, Developers, инкремент продукта в конце спринта; +- **Kanban** — визуализация потока, ограничение незавершённой работы (WIP), непрерывная поставка; +- **Extreme Programming (XP)** — TDD, парное программирование, частые релизы; +- **SAFe, LeSS, Nexus** — масштабирование Agile на программу из нескольких команд; +- **DevOps / непрерывную поставку** (continuous delivery) как инженерное продолжение гибкости. + +Для дисциплины «Внедрение информационных систем» критично понять границы Agile. Гибкость отлично работает, когда заказчик доступен, продукт можно делить на мелкие ценности, регулятор не требует полного ТЗ до старта кодирования. Она плохо работает «в чистом виде», когда: + +- закупка идёт по 44-ФЗ с фиксированным предметом и сметной документацией; +- нужно сертифицировать СЗИ или аттестовать ГИС; +- заказчик юридически не может принимать работу каждую вторую пятницу; +- предметная область требует согласованного изменения оргструктуры и учётной политики. + +Отсюда появилась нормальная профессиональная практика — **гибрид** (hybrid life cycle): внешне, для договора и регулятора, стадии ГОСТ 34; внутри команды разработки — спринты, ретроспективы, непрерывная интеграция. Это не лицемерие, если вы честно описали адаптацию процессов. Это лицемерие, если «Agile» означает отсутствие требований, а «ГОСТ» — кипу никому не нужных томов, написанных после того, как систему уже сдали. + +Отдельно скажу о распространённом студенческом мифе: «Agile отменяет документацию». Манифест говорит «важнее», а не «вместо». Процесс менеджмента документации (п. 7.2.1 ГОСТ Р ИСО/МЭК 12207-2010) никуда не девается. Меняется момент, объём и форма: пользовательские истории, критерии приёмки, архитектурные решения (ADR), автотесты как живая спецификация. + +**Вывод по разделу.** Модель жизненного цикла выбирают по неопределённости требований, цене ошибки и способу приёмки: каскад и V-модель сильны там, где нужна прослеживаемость, спираль — где доминирует риск, инкременты и Agile — где ценность можно поставлять частями. + +--- + +### 4.4. Сравнительный анализ моделей + +| Модель | Преимущества | Недостатки | Когда применять | +| --- | --- | --- | --- | +| Каскадная (waterfall) | Простое управление; понятные вехи и акты; хорошо ложится на ГОСТ 34 и госконтракт; легко аудировать | Позднее обнаружение ошибок требований; слабая реакция на изменения; риск «большого взрыва» на внедрении | Стабильные требования; регулируемые и сертифицируемые системы; понятный аналог уже существует | +| V-модель | Жёсткая связь требований и испытаний; ранняя закладка тестовой стратегии; высокая прослеживаемость | Та же жёсткость, что у каскада; дорого поддерживать трассировку при частых изменениях | Системы с высокими требованиями к безопасности и качеству; приёмка по ПМИ; автомобильные, медицинские, АСУ ТП-контуры | +| Итеративная | Ранняя обратная связь; возможность уточнять архитектуру; снижение риска «не то сделали» | Сложнее фиксировать объём и цену; риск «вечного улучшения» без поставки ценности | Новая предметная область; интерфейсы и UX критичны; заказчик готов смотреть промежуточные версии | +| Спиральная | Решения опираются на анализ рисков; прототип дешевле, чем ошибка в архитектуре; гибкость витков | Требует зрелой культуры рисков; трудно объяснить заказчику «почему снова прототип»; может затянуть сроки | Высокая новизна; критичные интеграции; неопределённость технологии, нагрузки или правового режима | +| Инкрементная | Ранняя поставка ценности; проще внедрять организационные изменения; удобна для очередей ERP/ГИС | Риск несовместимости инкрементов; нужна сильная архитектура «на вырост»; интеграционный долг | Крупные внедрения с очередями; замена legacy по контурам; когда бизнес не может остановиться | +| Agile (Scrum/Kanban и др.) | Быстрая обратная связь; высокий темп поставки; прозрачность команды; хорошо для эволюции продукта | Слабо стыкуется с фиксированным ТЗ и 44-ФЗ без гибрида; риск потери цельной архитектуры; зависит от дисциплины команды и Product Owner | Продуктовая разработка; развитие уже внедрённой системы; цифровой сервис с частым релизом; внутренняя автоматизация при доступном заказчике | + +Как выбирать модель на практике? Я предлагаю студентам простой фильтр из пяти вопросов. + +1. **Можно ли заморозить требования на 6–12 месяцев?** Если да — каскад или V допустимы. Если нет — итерации, инкременты, Agile. +2. **Цена поздней ошибки угрожает жизни, экологии, бюджету региона, непрерывности производства?** Если да — усиливайте V-логику, независимое верификационное тестирование, формальные гейты. +3. **Есть ли у системы самостоятельные контуры ценности?** Если да — инкременты почти обязательны. +4. **Главная неизвестность — технология, нагрузка, согласие пользователей, право?** Если да — спираль или хотя бы явные прототипы рисков. +5. **Как заказчик платит и принимает работу?** Форма контракта часто важнее вкуса команды. Контракт с фиксированной ценой и фиксированным ТЗ толкает к каскаду или к жёстко описанным инкрементам. Контракт time & materials и выделенная продуктовая команда толкают к Agile. + +Частый правильный ответ на экзамене и в проекте: **гибрид**. Например: стадии ГОСТ 34 и акты испытаний — снаружи; внутри стадии «рабочая документация / ввод в действие» — инкременты по контурам; внутри команды разработки каждого контура — Scrum. Главное — записать это в план управления проектом и в раздел ТЗ о стадиях, как того требует п. 2.2 ГОСТ 34.601-90. + +**Вывод по разделу.** Универсальной модели нет; профессиональный выбор опирается на стабильность требований, цену ошибки, делимость ценности и юридическую схему приёмки, а на крупных внедрениях чаще всего используют гибрид. + +--- + +### 4.5. Стадии жизненного цикла по ГОСТ 34.601-90 + +Переходим к ядру российской практики внедрения. Разберём восемь стадий таблицы п. 2.1 и содержание работ приложения 1. Для удобства сгруппируем их так, как это обычно делают в курсе внедрения: требования, проектирование, разработка, внедрение, сопровождение. + +#### 4.5.1. Формирование требований к АС (стадия 1) + +**Этап 1.1. Обследование объекта и обоснование необходимости создания АС.** Собирают данные об объекте и видах деятельности; оценивают качество функционирования; выявляют проблемы, которые вообще решаются автоматизацией; оценивают целесообразность создания АС. + +Это место, где рождается или умирает проект. Типичная ошибка студента-аналитика — сразу рисовать экранные формы. Сначала ответьте: *какая деятельность болеет и почему именно система, а не регламент?* На заводе «нехватка отчётов» часто лечится дисциплиной закрытия смен, а не новым дашбордом. + +**Этап 1.2. Формирование требований пользователя к АС.** Готовят исходные данные: характеристика объекта, требования к системе, ограничения затрат на разработку, ввод и эксплуатацию, ожидаемый эффект, условия создания и функционирования. Затем формулируют и оформляют требования пользователя. + +Здесь полезно держать в голове процесс 6.4.1 ГОСТ Р ИСО/МЭК 12207-2010 (требования правообладателей) и 6.4.2 ISO/IEC/IEEE 15288:2015. Требования пользователя — ещё не системные требования. «Хочу, чтобы кладовщик видел остатки онлайн» — потребность. «Система должна обеспечивать отображение доступного остатка с задержкой не более 5 секунд после проведения расходного ордера, с раздельным учётом брака и карантина» — уже ближе к системному требованию. + +**Этап 1.3. Отчёт и заявка на разработку АС (тактико-техническое задание).** Фиксируют результаты стадии и оформляют заявку либо заменяющий документ. + +Практический совет. Даже если заказчик просит «сразу ТЗ», не пропускайте обследование. Иначе ТЗ станет списком желаний отдела, который первым добежал до ИТ. + +#### 4.5.2. Разработка концепции АС (стадия 2) + +**Этапы 2.1–2.2.** Разработчик детально изучает объект и при необходимости проводит НИР, оформляет отчёты. Это важно для нетиповых систем: распознавание документов, биометрия, оптимизация маршрутов, отраслевые расчётные ядра. + +**Этап 2.3.** Разрабатывают альтернативные варианты концепции и планы реализации; оценивают ресурсы; сопоставляют преимущества и недостатки; выбирают вариант; определяют порядок оценки качества и условия приёмки; оценивают эффекты. + +Запомните слово **альтернативные**. Стандарт требует не один красивый слайд, а сравнение вариантов. Типовые развилки внедрения: коробочный продукт и адаптация; заказная разработка; гибрид; облако или контур заказчика; одна платформа или интеграция best-of-breed. + +**Этап 2.4.** Отчёт с описанием и обоснованием выбранного варианта концепции. + +Концепция — лучшее место, где спиральная логика Боэма входит в ГОСТ 34: именно здесь дешевле проверить рискованные гипотезы прототипом, чем заложить их в ТЗ как «очевидность». + +#### 4.5.3. Техническое задание (стадия 3) + +**Этап 3.1.** Разработка, оформление, согласование и утверждение ТЗ на АС и при необходимости ТЗ на части АС. + +Содержание ТЗ задаёт ГОСТ 34.602. В общем случае там появляются: общие сведения; назначение и цели; характеристика объекта автоматизации; требования к системе (к функциям, видам обеспечения, надёжности, безопасности, персоналу, эргономике и т.д.); состав и содержание работ; порядок контроля и приёмки; требования к составу и содержанию работ по подготовке объекта; требования к документированию; источники разработки. + +Для вас как будущих внедренцев ТЗ — это **юридический интерфейс** между замыслом и приёмкой. Испытания по этапам 7.6 и 7.8 проводятся на соответствие ТЗ. Плохое ТЗ нельзя спасти блестящей архитектурой: комиссия будет смотреть в документ. + +Как совместить ТЗ и Agile? Через декомпозицию: в ТЗ фиксируют цели, границы, нефункциональные требования, интеграции, требования ИБ, стадии и правила изменения требований. Детали интерфейсов и частные сценарии выносят в приложения, пользовательские истории, частные технические задания на очереди. Изменение ТЗ оформляют дополнением, а не «устным договорённостям в чате». + +#### 4.5.4. Проектирование: эскизный и технический проект (стадии 4–5) + +**Стадия 4. Эскизный проект.** По этапу 4.1 определяют: функции АС; функции подсистем, цели и эффекты; состав комплексов задач; концепцию и укрупнённую структуру информационной базы; функции СУБД; состав вычислительной системы; функции и параметры основных программных средств. По этапу 4.2 выпускают документацию в объёме, достаточном для дальнейших работ (виды — по ГОСТ 34.201). + +Эскизный проект по п. 2.2 можно исключить. Так часто и делают на типовых внедрениях 1С или коробочного CRM. Но если система территориально распределённая, с неясной архитектурой интеграций, эскиз экономит месяцы. + +**Стадия 5. Технический проект.** Этап 5.1 требует общих решений по системе и её частям: функционально-алгоритмическая структура; функции персонала и оргструктура; структура технических средств; алгоритмы и языки; организация информационной базы; классификация и кодирование; программное обеспечение. + +Это сердце проектирования внедрения. Обратите внимание: **функции персонала и организационная структура** входят в технический проект наравне с серверами. Внедрение ERP, которое «не трогает оргструктуру», в терминах ГОСТ 34 ещё не спроектировано. + +Этап 5.2 — документация технического проекта. +Этап 5.3 — документы на поставку изделий и ТЗ на несерийные изделия. +Этап 5.4 — задания на проектирование в смежных частях: строительство, электрика, слаботочка, санитарная техника. Для ЦОД, ситуационных центров и промышленных АСУ это не теория, а реальные кабель-каналы и помещения. + +Связь с ISO: стадия 5 примерно покрывает процессы 6.4.3–6.4.5 ISO/IEC/IEEE 15288:2015 (системные требования, архитектура, дизайн) и 7.1.3–7.1.4 ГОСТ Р ИСО/МЭК 12207-2010 (архитектура и детальное проектирование ПС). + +#### 4.5.5. Разработка: рабочая документация и программы (стадия 6) + +**Этап 6.1.** Рабочая документация должна содержать все сведения, необходимые и достаточные для ввода АС в действие, эксплуатации и поддержания качества в соответствии с проектными решениями. Виды документов — по ГОСТ 34.201. + +**Этап 6.2.** Разработка программ и программных средств, выбор, адаптация и привязка приобретаемых средств, программная документация по ГОСТ 19.101. + +Для внедрения типовых платформ «разработка» часто выглядит как: настройка, доработка, перенос данных, разработка обменов, роли и права, печатные формы, тестовые сценарии. Не недооценивайте это. Адаптация 1С:ERP на крупном предприятии по трудоёмкости сопоставима с заказной системой. + +Пункт 2.2 позволяет объединить стадии 5 и 6 в **технорабочий проект**. Так поступают, когда решения типовые и отдельный технический проект был бы ритуалом. + +Именно на стадии 6 команда обычно включает конвейер CI/CD, юнит-тесты, код-ревью — то есть деятельности процессов 7.1.5–7.1.7 и 7.2 ГОСТ Р ИСО/МЭК 12207-2010. Если этих процессов нет, «рабочая документация» превращается в набор инструкций к нестабильному коду. + +#### 4.5.6. Внедрение: ввод в действие (стадия 7) + +Это самая недооценённая студентами и самая болезненная на практике стадия. Восемь этапов — не бюрократия, а карта настоящего внедрения. + +**7.1. Подготовка объекта.** Организационная структура, инструктивно-методические материалы, внедрение классификаторов. Если справочник номенклатуры не нормализован, никакая ERP не «поедет». + +**7.2. Подготовка персонала.** Обучение и проверка способности обеспечить функционирование. Не «провели вебинар», а убедились, что персонал способен работать. На приёмке комиссия имеет право это проверить. + +**7.3. Комплектация.** Поставка программных, технических, информационных изделий, входной контроль качества. + +**7.4. Строительно-монтажные работы.** Помещения, кабель-каналы, монтаж техники и линий связи, испытания смонтированных средств. + +**7.5. Пусконаладочные работы.** Автономная наладка, загрузка информации в базу и проверка ведения, комплексная наладка. + +**7.6. Предварительные испытания.** Испытания на работоспособность и соответствие ТЗ по программе и методике; устранение неисправностей и правка документации; акт о приёмке в опытную эксплуатацию. + +**7.7. Опытная эксплуатация.** Работа системы в реальных или близких к реальным условиях; анализ результатов; доработка ПО и наладка техники; акт о завершении опытной эксплуатации. + +**7.8. Приёмочные испытания.** Испытания на соответствие ТЗ по ПМИ; устранение недостатков; акт о приёмке в постоянную эксплуатацию. + +Связь с ISO очевидна: это процессы инсталляции, поддержки приёмки, транзита, верификации и валидации (п. 6.4.7–6.4.8, 6.4.10–6.4.11 в соответствующих редакциях). + +Практическое правило внедрения: **не путайте опытную эксплуатацию с бета-тестом в свободное от работы время**. Опытная эксплуатация — штатный режим с фиксацией инцидентов, ролями и критериями успеха. Если критерии не заданы в ТЗ и ПМИ, стадия 7 превратится в бесконечный спор «готово / не готово». + +#### 4.5.7. Сопровождение АС (стадия 8) + +**Этап 8.1. Гарантийные обязательства.** Устранение недостатков, выявленных в гарантийный срок, и внесение изменений в документацию. + +**Этап 8.2. Послегарантийное обслуживание.** Анализ функционирования; выявление отклонений фактических характеристик от проектных; установление причин; устранение недостатков; обеспечение стабильности характеристик; актуализация документации. + +Это почти дословно процесс сопровождения п. 6.4.10 ГОСТ Р ИСО/МЭК 12207-2010 и п. 6.4.13 ISO/IEC/IEEE 15288:2015. В реальной жизни сюда же попадают заявки на развитие. Помните п. 1.3: развитие — это новое прохождение стадий, пусть и в сокращённом виде, а не «ещё один хотфикс без ТЗ». + +Сопровождение нужно проектировать заранее: SLA, уровни поддержки (L1–L3), регламент изменений (change management), резервное копирование, мониторинг, управление конфигурацией (п. 6.3.5 ГОСТ Р ИСО/МЭК 12207-2010). Иначе после красивого акта 7.8 система начинает жить в чате администратора. + +**Вывод по разделу.** ГОСТ 34.601-90 описывает восемь стадий от обследования до послегарантийного обслуживания; для внедрения ключевы качество требований и ТЗ, проектирование оргструктуры вместе с ИТ-контуром и дисциплина испытаний на стадии ввода в действие. + +--- + +### 4.6. Роли участников на разных стадиях ЖЦ + +Приложение 2 ГОСТ 34.601-90 называет организации. На проекте внедрения эти организации «проявляются» через роли. Ниже — рабочая карта, которой я пользуюсь со студентами. + +| Стадии | Ключевые роли | Главный вклад | +| --- | --- | --- | +| 1. Требования | Заказчик (sponsor), владелец бизнес-процесса, бизнес-аналитик, ИТ-директор, специалист по ИБ, экономист | Боль объекта, ограничения, эффект, заявка на разработку | +| 2. Концепция | Архитектор решения, аналитик, представитель вендора, служба эксплуатации | Варианты, оценка рисков, выбор платформы и контура | +| 3. ТЗ | Аналитик, юрист/контрактный управляющий, служба ИБ, метролог/отраслевой эксперт, руководитель проекта | Согласованные и проверяемые требования, правила приёмки | +| 4–5. Проектирование | Системный архитектор, прикладные консультанты, дизайнер UX, инженер по интеграциям, кадровик/оргпроектировщик | Проектные решения по функциям, данным, ТС, персоналу | +| 6. Разработка | Разработчики, консультанты по настройке, тестировщики, технический писатель, администратор конфигурации | Работоспособный контур, рабочая и программная документация | +| 7. Ввод в действие | Руководитель внедрения, ключевые пользователи, администраторы, служба обучения, приёмочная комиссия, монтаж/ПУЭ | Готовность объекта, персонал, данные, акты испытаний | +| 8. Сопровождение | Служба поддержки, владелец системы, администраторы, менеджер изменений, аудитор ИБ | Стабильность характеристик, развитие, актуальность документации | + +Несколько ролей, которые студенты обычно забывают. + +**Владелец бизнес-процесса** — не «тот, кто подпишет акт», а тот, кто завтра будет отвечать за цифры в системе. Без него аналитик собирает противоречивые хотелки исполнителей. + +**Служба информационной безопасности** должна входить не на этапе 7.6, а на этапах 1.2 и 3.1. Иначе вы получите систему, которую нельзя аттестовать. + +**Служба эксплуатации** (operation) смотрит на мониторинг, резервное копирование, регламентные окна, права доступа. ISO/IEC/IEEE 15288 специально выделяет процесс функционирования (п. 6.4.12). Если эксплуатацию не пригласили в проект, она унаследует чужую архитектуру. + +**Приёмочная комиссия** — юридически значимая роль на этапах 7.6–7.8. Состав комиссии определяют приказом заказчика. Разработчик готовит ПМИ и контур, но не «принимает сам у себя». + +**Product Owner** в Agile — близкий родственник владельца процесса и заказчика требований, но с оперативным правом приоритизации бэклога. В гибридном госконтракте эта роль часто расщепляется: формальный заказчик по договору и рабочий владелец продукта внутри команды. + +Примечание 1 приложения 2 ГОСТ 34.601-90 допускает совмещение функций заказчика, разработчика и поставщика. На малых проектах это нормально. На крупных ГИС совмещение «заказчик сам себе разработчик и сам себе комиссия» — конфликт интересов и типичный источник претензий Счётной палаты. + +**Вывод по разделу.** На каждой стадии есть свой центр ответственности: на требованиях — заказчик и аналитик, на проектировании — архитектор, на вводе — комиссия и ключевые пользователи, на сопровождении — служба эксплуатации; безопасность и эксплуатацию нельзя подключать в конце. + +--- + +### 4.7. Документация на каждой стадии + +Документ в жизненном цикле — не «бумажка для архива», а носитель решения и основание приёмки. Комплекс ГОСТ 34 задаёт виды документов, ГОСТ Р ИСО/МЭК 12207-2010 в п. 7.2.1 — процесс менеджмента документации, в п. 6.3.6 — менеджмент информации, в п. 6.3.5 — менеджмент конфигурации. + +| Стадия | Типовые документы | Зачем нужны | +| --- | --- | --- | +| 1. Формирование требований | Отчёт об обследовании; описание AS-IS; заявка / ТТЗ; протокол интервью; оценка эффективности | Обосновать необходимость и зафиксировать потребности | +| 2. Концепция | Отчёт о концепции; сравнительный анализ вариантов; отчёты НИР; укрупнённый план и оценка рисков | Выбрать вариант и границы решения | +| 3. Техническое задание | ТЗ на АС и частные ТЗ на подсистемы (ГОСТ 34.602); перечень стадий и документов | Задать предмет договора и критерии приёмки | +| 4. Эскизный проект | Пояснительная записка; схемы организационной и функциональной структур; концепция ИБ и ИО | Зафиксировать предварительные решения | +| 5. Технический проект | П2 (пояснительная записка); схемы комплексов технических средств, организационной структуры; описание информационного, программного, организационного обеспечения; задания на смежные части; ведомости покупных изделий | Дать полную совокупность проектных решений | +| 6. Рабочая документация | Руководства пользователя и администратора; технологические инструкции; спецификации; программа и методика испытаний; формуляр / паспорт; программные документы по ГОСТ 19.101 | Обеспечить ввод, эксплуатацию и поддержание качества | +| 7. Ввод в действие | Приказы о комиссиях и опытной эксплуатации; протоколы обучения; протоколы ПНР; протоколы и акты предварительных испытаний, опытной эксплуатации, приёмочных испытаний; журнал дефектов | Юридически ввести систему в действие | +| 8. Сопровождение | Регламент сопровождения и SLA; журнал заявок; релизы и описания изменений; обновлённые руководства; акты гарантийных работ | Сохранять соответствие характеристик и управлять изменениями | + +Несколько правил, которые отличают профессионала от «автора тома на 400 страниц». + +Первое. Документ должен иметь **владельца, версию и статус**. Это менеджмент конфигурации, а не канцелярия. + +Второе. Между требованием, проектным решением, реализацией и тестом должна быть **прослеживаемость**. V-модель здесь — лучший учитель. + +Третье. Объём документации должен быть **достаточным и необходимым**, как сказано в приложении 1 к этапам 4.2, 5.2 и 6.1. Писать «всё, что можно» так же вредно, как не писать ничего. + +Четвёртое. В Agile-контуре документ может быть цифровым: эпик в трекере, ADR в репозитории, автотест, дашборд мониторинга. Но на стадии ввода в действие государственной ИС вам всё равно понадобятся ПМИ и акты. Готовьте их не в последнюю ночь. + +**Вывод по разделу.** Документация сопровождает каждую стадию как носитель решений и основание приёмки; её вид задают ГОСТ 34.201, ГОСТ 34.602 и ГОСТ 19.101, а жизненность документов обеспечивает управление конфигурацией. + +--- + +## 5. Практические примеры + +### 5.1. Кейс ERP: внедрение на промышленном предприятии (российская практика) + +Типовой сюжет, который многократно воспроизводился на машиностроительных и пищевых предприятиях при внедрении 1С:ERP, SAP ERP / S/4HANA, «Галактики». + +Предприятие ведёт учёт в парке разрозненных баз: бухгалтерия в «1С:Бухгалтерии», производство в Excel и цеховых журналах, склад в локальной программе 2000-х годов. Директор инициирует внедрение ERP, чтобы «видеть себестоимость». Интегратор, польстившись на срок в контракте, предлагает почти каскад: экспресс-обследование — ТЗ — опытная эксплуатация через девять месяцев — запуск «всего завода» в январе. + +Что происходит дальше, предсказуемо. На стадии требований не фиксируют, что конструкторский состав изделия и фактический цеховой состав расходятся. На концепции выбирают «максимальную функциональность» без пилота. В ТЗ пишут расплывчато: «система должна обеспечивать оперативный учёт производства». На проектировании забывают оргструктуру: мастер смены физически не успевает закрывать операции в системе. На стадии 6 идут бесконечные доработки печатных форм. На стадии 7 пытаются загрузить «грязные» справочники. Опытная эксплуатация совпадает с пиком сезона. Приёмочные испытания формально проходят по сценарным тестам, не похожим на реальную смену. Через два месяца после акта директору приносят себестоимость, которой никто не верит. + +Где сломался жизненный цикл? Не в платформе. Сломались этапы 1.1–1.2 (не отделена автоматизация от наведения порядка в НСИ), этап 2.3 (нет альтернативы «пилот одного цеха»), стадия 7 (нет настоящей подготовки персонала и критериев опытной эксплуатации), стадия 8 (нет владельца системы). + +Как выглядит зрелый контур того же проекта: + +- обследование отдельно фиксирует проблемы процесса и проблемы учёта; +- концепция сравнивает «большой взрыв» и очереди (финансы и склад → производство → себестоимость); +- выбирается инкрементная модель с элементами спирали: пилот на одном переделе как способ снять главный риск; +- ТЗ пишется на первую очередь, а не «на всю жизнь»; +- в техническом проекте проектируют роли мастера, технолога, кладовщика; +- опытная эксплуатация идёт на пилотной площадке с журналом отклонений и критерием «три закрытых периода подряд»; +- только после этого тиражирование — как развитие АС по п. 1.3 ГОСТ 34.601-90. + +Международный контрапункт — неудачные ERP-программы Hershey (конец 1990-х) и Lidl (проект модернизации торговых процессов на базе SAP, свёрнут после многолетних затрат). В обоих случаях система не «не умела считать». Не совпали модель внедрения, готовность организации и способность освоить изменения темпом, который заложили в график. + +### 5.2. Кейс CRM: продуктовый контур и внедрение в коммерческой службе + +Второй сюжет — внедрение CRM (Bitrix24, amoCRM, Microsoft Dynamics, Salesforce) в компании с полевыми продажами. + +Коммерческий директор хочет «чтобы менеджеры всё вносили в воронку». ИТ-отдел покупает облачную лицензию, настраивает стадии за два дня и рассылает логины. Формально жизненный цикл уместился в одну неделю. Через месяц воронка пустая: менеджеры ведут учёт в записных книжках, потому что мобильный сценарий неудобен, дублировать данные в Excel для отчёта директору всё равно приходится, а премия не связана с качеством данных в CRM. + +С точки зрения стандартов система прошла какую-то пародию на стадии 6–7 и не прошла стадии 1–2 и 7.2. Не было требований правообладателей (п. 6.4.1 ГОСТ Р ИСО/МЭК 12207-2010): молчали сами продавцы, служба сервиса, маркетинг, юристы (оферта и 152-ФЗ). Не было валидации: проверили, что карточка создаётся, но не проверили, что процесс продажи в поле реально через неё идёт. + +Зрелый цикл для CRM чаще всего **Agile + инкременты**: + +- инкремент 1 — единая карточка клиента и запрет на отчёт вне системы; +- инкремент 2 — мобильный сценарий визита; +- инкремент 3 — интеграция с телефонией и почтой; +- инкремент 4 — прогнозирование и регламент качества данных. + +Скрам-команда выпускает инкременты каждые две недели, но у проекта есть «внешний» каскад: политика обработки ПДн, инструкция, приказ о вводе, обучение, критерии приёмки («не менее 90% новых сделок созданы в CRM в течение 24 часов»). Вот вам гибрид без идеологии. + +Международный акцент: экосистема Salesforce десятилетиями строится вокруг постоянной эволюции (releases три раза в год на платформе). Клиент, который воспринимает CRM как «внедрил и забыл», конфликтует с жизненным циклом самого продукта. Сопровождение здесь — не гарантийный ремонт, а непрерывное развитие. + +### 5.3. Кейс государственной ИС: ЕПГУ / ЕСИА и логика ГИС + +Третий сюжет — государственные информационные системы: Единый портал государственных услуг (ЕПГУ), ЕСИА, региональные системы уровня ЕМИАС, федеральные ФГИС. + +Государственная ИС рождается в особом правовом поле: федеральные законы, постановления Правительства, требования к ГИС, защита информации, закупки по 44-ФЗ, межведомственное электронное взаимодействие (СМЭВ). Это почти всегда означает: + +- формализованные стадии и комплекты документов; +- ТЗ как предмет закупки; +- приёмку комиссией; +- аттестованный контур; +- последующее развитие отдельными этапами госконтрактов. + +История «Госуслуг» поучительна именно как эволюция жизненного цикла. Ранние версии портала критиковали за «витрину без глубины»: услуга была опубликована, но реальный межведомственный процесс оставался бумажным. Это классический разрыв валидации и верификации: по ТЗ страница услуги существует, по потребности гражданина услуга не оказывается. + +Зрелость пришла, когда жизненный цикл стали мыслить не как запуск портала, а как конвейер: нормативное закрепление услуги → перевод в электронный вид → подключение ведомства через СМЭВ → опытная эксплуатация на ограниченном регионе или типе заявителей → тиражирование → сопровождение и развитие (новые суперсервисы, мобильные сценарии, проактивные уведомления). По сути это инкрементная модель внутри жёсткой государственной обвязки ГОСТ 34 и 12207. + +ЕМИАС в Москве даёт другой урок. Медицинская информационная система затрагивает врачей, регистратуру, льготные рецепты, запись к специалисту, нагрузку поликлиник. Технически «записать пациента» несложно. Трудно пройти стадии подготовки персонала и объекта: расписание кабинетов, нормативы приёма, привычка врача. Там, где внедрение шло как организационный проект с очередями и обучением, эффект появлялся. Там, где ставили интерфейс поверх старого хаоса расписания, пользователи саботировали систему теневыми журналами. + +Для студента отсюда правило: **государственная ИС почти никогда не прощает пропуск стадий 1, 2, 7.2 и 7.7**. Можно спорить о том, нужен ли эскизный проект. Нельзя спорить о том, нужны ли понятные требования, концепция межведомственного взаимодействия, обучение и опытная эксплуатация. + +**Вывод по разделу.** ERP ломается на НСИ, оргструктуре и «большом взрыве»; CRM — на валидации реального процесса продаж; государственная ИС — на разрыве между формальной приёмкой и действительным оказанием услуги. + +--- + +## 6. Типичные ошибки и риски при управлении ЖЦ + +Разберём ошибки так, как они выглядят в аудитории защиты проекта и на совещании у заказчика. + +**1. Смешение стадии и процесса.** «У нас процесс проектирования закончился, значит риски больше не ведём». Процесс менеджмента рисков (п. 6.3.4 ГОСТ Р ИСО/МЭК 12207-2010) не заканчивается вместе со стадией 5. + +**2. Водопад по умолчанию.** Команда копирует таблицу п. 2.1 ГОСТ 34.601-90 в календарный план и считает, что стандарт запрещает итерации. Пункт 2.2 говорит об обратном. + +**3. Agile как отсутствие инженерии.** Нет бэклога с критериями приёмки, нет определения готовности (Definition of Done), нет регрессионных тестов, нет владельца продукта. Это не гибкость, это импровизация. + +**4. ТЗ-фетишизм и ТЗ-нигилизм.** Две крайности. В первой ТЗ пишут на 200 страниц без проверяемых критериев. Во второй ТЗ заменяют презентацией. Испытания 7.6 и 7.8 в обоих случаях превращаются в торг. + +**5. Поздние требования ИБ и 152-ФЗ.** Система спроектирована, затем служба безопасности требует иной контур, иные роли, запрет облака. Это дефект стадии 1 и 3, а не «вредный СБ». + +**6. Внедрение без подготовки объекта и персонала.** Пропущены этапы 7.1–7.2. Классика ERP и медицинских систем. + +**7. Опытная эксплуатация без критериев.** Нет метрик («доля документов, проведённых в системе», «время закрытия периода», «число критических инцидентов»). Акт либо подписывают формально, либо не подписывают месяцами. + +**8. Игнорирование сопровождения в экономике проекта.** Бюджет съеден созданием. После акта 7.8 нет SLA, нет администратора, нет регламента изменений. Через год система «устарела», хотя на самом деле её бросили. + +**9. Конфликт ролей.** Разработчик сам пишет ПМИ, сам проводит испытания, сам входит в комиссию. Приложение 2 допускает совмещение, но на значимых системах это риск независимости верификации (п. 7.2.4–7.2.5 ГОСТ Р ИСО/МЭК 12207-2010). + +**10. Неуправляемая конфигурация.** Никто не знает, какая версия на продуктивном контуре, какие доработки вошли в релиз, какая инструкция актуальна. Процесс 6.3.5 отсутствует де-факто. + +**11. Большой взрыв вместо инкрементов.** Попытка сменить учёт всего предприятия в одну дату. Риск операционной остановки превышает любой технический риск. + +**12. Отказ от disposal.** Старую систему «просто выключают». Данные не мигрированы, лицензии не закрыты, права доступа живут, персональные данные остаются на дисках. Процесс 6.4.11 ГОСТ Р ИСО/МЭК 12207-2010 и 6.4.14 ISO/IEC/IEEE 15288:2015 существуют не для красоты классификатора. + +Карта рисков для руководителя внедрения: + +| Риск | Где зарождается | Чем закрывать | +| --- | --- | --- | +| Не те требования | Стадии 1–3, процесс 6.4.1 | Обследование, прототипы, рецензия правообладателей | +| Не та архитектура | Стадия 2–5, процессы 6.4.3–6.4.4 15288 | Сравнение вариантов, пилот, нагрузочный прототип | +| Срыв интеграций | Стадии 5–7 | Контракты на интерфейсы, стенд СМЭВ/шины, ранние тесты | +| Саботаж пользователей | 7.1–7.2 | Оргпроект, обучение, мотивация, ключевые пользователи | +| Юридическая неприёмка | 3, 7.6–7.8 | Проверяемые требования, ПМИ, независимая комиссия | +| Развал после запуска | Стадия 8 | SLA, мониторинг, change management, бюджет сопровождения | + +**Вывод по разделу.** Главные риски ЖЦ — не язык программирования, а неверная модель, слабые требования, формальная приёмка, забытые люди и брошенное сопровождение; каждый из них закрывается конкретным процессом стандарта, а не лозунгом. + +--- + +## 7. Выводы + +1. Информационная система живёт дольше, чем проект разработки. Жизненный цикл охватывает потребность, создание, функционирование, сопровождение, развитие и вывод из эксплуатации. + +2. Стадия, этап и процесс — разные сущности. Стадии ГОСТ 34.601-90 нужны для планирования и приёмки. Процессы ISO/IEC/IEEE 12207, ISO/IEC/IEEE 15288 и ГОСТ Р ИСО/МЭК 12207-2010 нужны для инженерной полноты работ. + +3. ГОСТ 34.601-90 в п. 1.1–1.3 и 2.1–2.2 задаёт восемь стадий создания АС и одновременно разрешает адаптацию: пропуск эскизного проекта, технорабочий проект, параллельность, развитие по тем же стадиям. + +4. Международные стандарты не навязывают водопад. Они требуют заявить и поддерживать набор процессов: соглашение, организационное обеспечение, менеджмент проекта, технические процессы, реализацию и поддержку программных средств. + +5. Модель жизненного цикла выбирают. Каскад и V-модель дают управляемость и прослеживаемость. Спираль управляет неопределённостью. Инкременты и Agile поставляют ценность частями. На внедрениях чаще всего побеждает гибрид. + +6. Для дисциплины внедрения решающие стадии — формирование требований, ТЗ, проектирование оргструктуры вместе с ИТ, ввод в действие с обучением и испытаниями, сопровождение. + +7. Документы — часть системы, а не приложение к ней. ТЗ по ГОСТ 34.602 связывает замысел с испытаниями. ПМИ и акты 7.6–7.8 делают внедрение юридическим фактом. + +8. Кейсы ERP, CRM и ГИС показывают одну закономерность: техника редко проигрывает первой. Первыми проигрывают обследование, валидация, подготовка людей и честность модели внедрения. + +Если унесёте с лекции одну фразу, пусть будет такой: **сначала выберите, как система будет жить и как вы это докажете заказчику, — и только потом спорьте о фреймворке и платформе.** + +--- + +## 8. Вопросы для самопроверки + +1. Чем жизненный цикл информационной системы отличается от жизненного цикла программного средства? Опирайтесь на разницу оптик ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 12207. +2. Сформулируйте определения стадии, этапа и процесса. Почему процесс менеджмента рисков нельзя «закрыть» вместе со стадией технического проекта? +3. Что устанавливает п. 1.1 ГОСТ 34.601-90 и почему в определении есть слова «необходимо и достаточно»? +4. Какие допущения содержит п. 2.2 ГОСТ 34.601-90? Можно ли, ссылаясь на этот пункт, вести итеративную разработку внутри стадий ГОСТ 34? +5. Перечислите восемь стадий таблицы п. 2.1 ГОСТ 34.601-90 и укажите этапы стадии «Ввод в действие». +6. Чем верификация отличается от валидации? На каких ветвях V-модели и в каких пунктах ISO/IEC/IEEE 15288:2015 закреплены эти процессы? +7. Сравните каскадную и спиральную модели: какой вопрос является главным при выборе спирали? +8. Почему инкрементная модель часто лучше «большого взрыва» при внедрении ERP? Свяжите ответ с п. 1.3 ГОСТ 34.601-90. +9. Какие группы процессов описаны в разделе 6 ГОСТ Р ИСО/МЭК 12207-2010? Чем раздел 7 отличается от раздела 6? +10. Какие организации-участники перечислены в приложении 2 ГОСТ 34.601-90? В чём риск совмещения ролей разработчика и приёмочной комиссии? +11. Какие документы обязательно появляются на стадиях 3, 6 и 7? Почему программа и методика испытаний должна рождаться не после окончания кодирования? +12. На примере государственной ИС покажите, как система может пройти верификацию по ТЗ и не пройти валидацию для гражданина. Какой стадии или какого процесса не хватило? + +--- + +## 9. Список литературы и нормативных документов + +1. ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. — М.: Стандартинформ, 2009 (переиздание). +2. ГОСТ 34.602-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. +3. ГОСТ 34.201-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем. +4. ГОСТ 19.101-77. Единая система программной документации. Виды программ и программных документов. +5. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. +6. ГОСТ Р 57193-2016. Системная и программная инженерия. Процессы жизненного цикла систем (гармонизация с ISO/IEC/IEEE 15288). +7. ISO/IEC/IEEE 12207:2017. Systems and software engineering — Software life cycle processes. — Geneva: ISO, 2017. +8. ISO/IEC/IEEE 15288:2015 (а также ред. 2023). Systems and software engineering — System life cycle processes. — Geneva: ISO. +9. Боэм Б. У. Инженерное проектирование программного обеспечения : пер. с англ. — М.: Радио и связь, 1985. (Boehm B. W. Software Engineering Economics; см. также Boehm B. A Spiral Model of Software Development and Enhancement // IEEE Computer. 1988. Vol. 21, No. 5.) +10. Royce W. W. Managing the Development of Large Software Systems // Proceedings of IEEE WESCON. 1970. +11. Agile Manifesto. Manifesto for Agile Software Development. 2001. URL: https://agilemanifesto.org/ +12. Вендров А. М. Проектирование программного обеспечения экономических информационных систем : учебник. — 2-е изд. — М.: Финансы и статистика, 2006. +13. Грекул В. И., Денищенко Г. Н., Коровкина Н. Л. Проектирование информационных систем : учебник и практикум. — М.: Юрайт, 2023. +14. Соммервилл И. Инженерия программного обеспечения : пер. с англ. — 9-е изд. — М.: Вильямс, 2015. (Sommerville I. Software Engineering.) +15. ISO/IEC/IEEE 24748-1:2024. Systems and software engineering — Life cycle management — Part 1: Guidelines for life cycle management. +16. Постановление Правительства РФ от 06.07.2015 № 676 (ред. действ.) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем…» — для сопоставления стадий ГИС с логикой ЖЦ. + +--- + +## 10. Задание для самостоятельной работы + +**Тема задания.** Проектирование жизненного цикла внедрения информационной системы для конкретного объекта автоматизации. + +**Формат.** Письменная работа объёмом 8–12 страниц (шрифт Times New Roman, 14 пт, интервал 1,5) плюс 5–7 слайдов для защиты на семинаре. Работа выполняется индивидуально или в паре. + +**Исходные данные.** Выберите один объект из списка (или согласуйте свой с преподавателем): + +1. Внедрение ERP на машиностроительном заводе (200–400 сотрудников, есть «1С:Бухгалтерия» и цеховой учёт в Excel). +2. Внедрение CRM в компании с полевыми продажами (30 менеджеров, облачный контур, обработка ПДн). +3. Развитие региональной государственной информационной системы записи на социальные услуги (интеграция с ЕСИА и СМЭВ, закупка по 44-ФЗ). + +**Что нужно сделать.** + +1. Кратко описать объект автоматизации, заинтересованные стороны и главную «боль», которую должна снять система. +2. Обосновать выбор модели жизненного цикла (или гибрида). В обосновании ответьте на пять фильтрующих вопросов из раздела 4.4 лекции. +3. Построить карту стадий и этапов по ГОСТ 34.601-90. Для каждой стадии укажите: результат, роли, комплект документов, решение «выполняем / объединяем / исключаем» со ссылкой на п. 2.2 стандарта. +4. Наложить на эту карту не менее восьми процессов ГОСТ Р ИСО/МЭК 12207-2010 (обязательно: 6.1.1 или 6.1.2, 6.3.4, 6.3.5, 6.4.1, 7.2.4, 7.2.5, 6.4.10). Покажите, на каких стадиях каждый процесс активен. +5. Составить эскиз программы и методики испытаний для одного критичного требования: что проверяем, на каком этапе стадии 7, какой акт появляется. +6. Назвать пять рисков управления ЖЦ именно вашего объекта и способ закрытия каждого риска. +7. Сформулировать, чем будет отличаться сопровождение (стадия 8) от развития системы (п. 1.3 ГОСТ 34.601-90) в вашем случае. + +**Критерии оценки.** + +| Критерий | Баллы | +| --- | --- | +| Корректность ссылок на пункты стандартов | 20 | +| Обоснованность выбора модели ЖЦ | 20 | +| Полнота карты стадий, ролей и документов | 20 | +| Связь процессов 12207 со стадиями ГОСТ 34 | 15 | +| Реалистичность рисков и ПМИ | 15 | +| Качество устной защиты | 10 | + +**Срок.** К следующему семинарскому занятию (через одну учебную неделю). Файл работы: `Фамилия_ЖЦ_ИС.pdf`. + +--- + +*Конец лекции.*