Содержание курса

• Предмет исследования

• Варианты организации производства

• Жизненный цикл производства информационных систем

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

Как уже упоминалось выше, понимание ЖЦ производства ИС является фундаментом профессиональной грамотности для любого профессионала IT-отрасли, от разработчика до топ-менеджера. Это не просто абстрактная теория, а практический инструмент, который напрямую влияет на вклада каждого специалиста в общий успех проекта, превращая хаотическую деятельность в управляемый процесс. Поскольку в последнее время значительно меняются условия ИТ-производства, смещаются акценты, размываются границы этапов и прочее, важно иметь представление об основных устоявшиеся стандартах. Поэтому перед тем как преступить к подробному рассмотрению стадий и этапов современного ИТ-производства пройдемся кратко по магистральным трендам.

1.  Стандарты моделей жизненного цикла производства ИС

Существует несколько стандартных моделей, на основе которых были разработаны специфические вариации. Вот наиболее значимые из них:

1.1.  Стандарт ISO/IEC 12207

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

Стандарт группирует структуру процессов по трем основным категориям:

• Основные: закупка; поставка; разработка; эксплуатация; сопровождение.

• Вспомогательные (проектные): управление проектом; управление рисками; управление качеством; управление конфигурациями; верификация; валидация и др.

• Организационные: управление ЖЦ; управление инфраструктурой; управление портфелем проектов; управление человеческими ресурсами; управление знаниями; улучшение процессов; обучение.

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

Проблемы: громоздкость; не является методикой; много бюрократии.

На его основе строятся многие другие стандарты и модели. ISO/IEC 15288 — аналогичный стандарт для системной инженерии, определяет более широкое понятие, включающее ПО, железо, людей. Ценность стандарта заключается в предоставлении полной, структурированной и общепризнанной системы координат для управления созданием, эксплуатацией и сопровождением программного обеспечения. Даже если компания не внедряет его формально, понимание этого стандарта помогает выстроить логичный и полный набор процессов.

1.2.  Стандарт ГОСТ 34.601–90

Серия государственных стандартов СССР/РФ, регламентирующих создание, развитие и сопровождение Автоматизированных систем (далее АС), включая информационные системы.

Стандарт устанавливает строгую последовательность стадий и этапов создания АС, под которыми понимаются не просто программы, а и комплекс аппаратно-программных средств, людей и процессов для управления. Но чаще всего под ГОСТ 34 имеют в виду модель жизненного цикла и состав документации при создании АС.

Стандарт делит создание АС на 9 стадий, каждая из которых содержит строго определенные этапы. Вот они в порядке следования:

1)  Формирование требований к АС: обследование объекта автоматизации; формирование требований к АС; оформление отчета о выполнении и тактико-технического задания (ТТЗ) на создание АС.

2)   Разработка концепции АС: изучение объекта автоматизации; проведение научно-исследовательских работ (НИР); разработка вариантов концепции и выбор оптимального; оформление отчета и концепции АС.

3)  Техническое задание (ТЗ): формальное составление и утверждение Технического задания, определяющего цели, требования, сроки и стадии создания АС.

ТЗ выступает промежуточным итогом фазы предпроектных исследований.

4)  Эскизный проект: разработка предварительных проектных решений; разработка документации на АС и ее части.

5)  Технический проект: разработка проектных решений; разработка документации на АС; разработка и оформление документации на поставку;

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

6)  Рабочая документация: разработка рабочей документации на АС и ее части; разработка и адаптация программ.

7)  Ввод в действие: подготовка к вводу АС в действие; подготовка персонала; комплектация АС изделиями и программами; строительно-монтажные работы; пусконаладочные работы; проведение предварительных испытаний; проведение опытной эксплуатации; проведение приемочных испытаний.

8)  Сопровождение АС: выполнение работ в соответствии с гарантийными обязательствами; послегарантийное обслуживание.

9)  Завершение работ (стадия, часто опускаемая в описаниях): оформление акта сдачи системы в постоянную эксплуатацию.

Преимущество: высокая управляемость; юридическая определенность; подходит для сложных и критичных ИС.

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

На практике ГОСТ 34 используют как контрактную рамку, а внутри стадий применяют: итерационную разработку, Agile, DevOps. Для современного ИТ-специалиста знание этого стандарта важно не для прямого применения, а для понимания классического подхода и истоков многих процессов, для контраста с гибкими методологиями, чтобы осознанно выбирать подход.

1.3.  Каскадная (Водопадная) модель (Waterfall)

Последовательное, линейное выполнение фаз, в которой переход к следующей фазе возможен только после полного завершения предыдущей. Это не универсальная модель, а инструмент для предсказуемых, регламентированных и риск-критичных систем.

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

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

Стандарт основан в конце 70х годов прошлого века, в значительной степени на основе MIL-STD-498 (военный стандарт США) и повлиял на многие корпоративные методологии. Модель стандарта пережила естественный отбор, но в настоящее время, в связи с радикальным изменением инструментов производства ИТ-продуктов, в чистом виде занимает небольшую и специфическую нишу в ИТ-отрасли: медицинское ПО, госсектор, авиастроение, проекты по созданию аппаратных средств. Также может эффективно использоваться в гибридных моделях, верхний уровень (этапы) Waterfall, а внутри этапа Agile.

1.4.  Методология RUP (Rational Unified Process)

Итеративный, инкрементальный процесс разработки ПО, созданный компанией Rational Software (позже приобретенной IBM). Это не жесткая последовательность шагов, а каркас (framework), который можно и нужно адаптировать под конкретный проект. Итеративный процесс, структурированный по двум измерениям:

1)  Временное (динамика, фазы): Начало, Проектирование, Построение, Внедрение.

2)  Процессное (статическая структура, виды деятельности): Бизнес-моделирование, Требования, Анализ и проектирование, Реализация, Тестирование, Внедрение.

RUP систематизировал 6 ключевых практик, ставших впоследствии стандартом:

• Итеративная разработка, в основе которой положено управление рисками и адаптация к изменениям.

• Управление требованиями, через их отслеживание и приоритизацию.

• Компонентная архитектура — создание гибкой, масштабируемой системы.

• Визуальное моделирование (преимущественно на UML), позволяет получить общее наглядное понимание архитектуры.

• Постоянный контроль качества, через тестирование на всех этапах.

• Управление изменениями, через контроль версий и отслеживание изменений требований.

Каждая фаза (кроме начальной) разбита на итерации — ограниченные по времени циклы (2-6 недель), по итогам которых производится рабочий, протестированный, интегрированный продукт (инкремент). Каждая итерация проходит через все нужные ей дисциплины (требования, дизайн, кодирование, тестирование).

Преимущество: универсальность, баланс между гибкостью и дисциплиной, использование лучших практик (UML, управление требованиями).

Проблемы: относительная сложность, может быть избыточным для небольших проектов, требует опытной команды, может выродиться в “Тяжелый водопад”.

Это дисциплинарный, умный подход, который, при правильном (адаптивном) применении, может быть очень эффективным. Его прямое наследие живет в большинстве современных корпоративных практик разработки. Де-факто стандарт для крупных корпоративных проектов до эры Agile. Сейчас существует его упрощенная версия — OpenUP и Agile Unified Process (AUP).

1.5.  Гибкие методологии (Agile)

Семейство итеративно-инкрементных подходов, описанное в «Манифесте гибкой разработки ПО». Подход стал не просто набором практик, а культурной и управленческой революцией, которая сформировала тренды современной индустрии разработки ИС, по факту выступивший ответом на неэффективность «Тяжелых» водопадных моделей. 

Ключевые принципы Agile, используемые на практике:

• Доставка работающего ПО — главный показатель прогресса.

• Изменение требований приветствуется даже на поздних стадиях.

• Работающий продукт поставляется часто (от пары недель до пары месяцев).

• Непосредственное общение — лучший способ обмена информацией.

• Проектами должны заниматься мотивированные профессионалы, которым создают условия для работы.

Agile объединяет под собой конкретные фреймворки и методики, использующие типичные для подхода инструменты:

• практики организации работ и управления процессом: самоорганизация; итеративная разработка; работа через бэклог продукта; постоянная синхронизация команды через митинги; ретроспективы; визуализация задач и прочее;

• практики работы с требованиями и заказчиком: приоритизация по ценностям, частая обратная связь от заказчика и прочее;

• инженерные практики качества: непрерывная интеграция; разработка через тестирование; рефакторинг, непрерывная поставка ценности и прочее;

• практики оценки и планирования: относительная оценка сложности задач в «сторипоинтах» (Story Points); график, показываю

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

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

Стандарт ISO/IEC 26515 определяет модель Agile-разработки. Также есть Scaled Agile Framework (SAFe), LeSS для масштабирования Agile на большие компании.

 В дальнейшем, мы будем более детально рассматривать возможность использования (комбинирования) лучших практик и инструментов, характерных для разных стандартов и методик, в зависимости от сложившихся условий производства.

2.   Стадии и этапы производства ИС, рассматриваемые в данном курсе

Систематизация стадий и этапов, предлагаемая в данном курсе отличается от некоторых стандартов и продиктована современными трендами развития ИТ-индустрии.

В основе большинства стандартов лежит обобщенный процесс, который можно представить следующими ключевыми фазами ЖЦ:

2.1.  Инициация (идеи), анализ и формализация Потребностей

Стадия посвящена превращению неопределенности, неясной идеи или боли в набор четко сформулированных, измеримых и приоритизированных Потребностей бизнеса.

В данном контексте под “Потребностями” предполагают требования к организации бизнес-решений, интегрируемых в экосистему компании.

Основные проблемы на данном этапе возникают из-за неразделенности акцентов между двумя мирами – “Мира бизнеса” (домен Проблем) и “Мира технологий” (домен Решений). Главная задача стадии как раз и заключается в трансляции деловых решений в технические, причем перевод осуществляется в обе стороны для снятия коммуникационного барьера между командами бизнеса и технологической. Фокус на этой стадии все время должен оставаться на стороне Проблем, а не Решений.

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

Подробно процесс сбора и формализации Потребностей заинтересованных лиц описан в курсе: “Проектирование Информационных систем. Часть 5. Формализация потребностей заказчика”

Основные задачи фазы:

• Выявление реальной проблемы или возможности бизнеса, формулировка гипотез.

• Формирование концепции проекта, выявление стейкхолдеров.

• Сбор, анализ и документирование потребностей заказчиков, пользователей и прочих заинтересованных лиц (функциональные и нефункциональные).

• Создание общего видения (Shared Vision) для всех участников. Согласование контекста с ними.

• Оценка жизнеспособности (Viability), выполнимости (Feasibility) и ценности (Desirability) решения (техническая, экономическая, операционная).

Этап “Инициации и анализа” – это больше творческий и исследовательский процесс, цель которого — найти наикратчайший путь создания ценности для пользователя и бизнеса и убедиться, что по этому пути целесообразно идти.

В результате успешного прохождения стадии должны появиться: бизнес-идея; vision /концепция; обоснование (документ с определением критериев успеха, оценкой ценности, затрат, рисков и рекомендацией); решение о запуске проекта (оформленное документально).

2.2.  Проектирование, дизайн, формирование требований

Цель фазы: спроектировать решение, определяющее КАК система будет удовлетворять выявленные на предыдущей стадии Потребности заинтересованных лиц.

В некоторых стандартах разделяют стадию “Анализ и требования” и стадию “Проектирование”. Основывается данное решение на разграничении активностей, связанных с пространством “Проблем” (деловых) от пространства “Решений” (технических). Предполагается, что результат стадии “Анализ и требования” формирует Требования к бизнес решениям, а стадия “Проектирование” — Требования к ИС (техническая реализация). По факту же в реальном производстве артефакты: Требования, Техническое задание, Спецификации требований уже содержат техническое решение, в той или иной степени. Для того же, чтобы Требования были неразрывно связаны с Потребностями заинтересованных лиц их необходимо постоянно синхронизировать и трассировать на полноту покрытия.

А потому в данном курсе мы разделили понятие Требование на:

1) “Потребность” стейкхолдеров (бизнес-требования), выявляемые на стадии Инициации;

2) и непосредственно “Требования” (системные), проектного решения в той или иной степени представляющие требования к ИС.  Подробно процесс сбора и формализации Требований описан в курсе: “Проектирование Информационных систем. Часть 10.2. Формирование спецификаций требований”

Ключевые проблемы данной стадии: противоречия Дизайн vs Проектирование; “дырки” в требованиях; неуправляемая сложность и объем заявляемых требований; зависимости и конфликты требований; “дизайн в вакууме”, в отрыве от реальных данных; сложность управления изменениями и прочее.

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

Основные задачи фазы:

• Создание технического задания (ТЗ) или спецификации требований к программному обеспечению (SRS).

• Архитектурное проектирование: выбор технологий; определение высокоуровневой структуры системы; компонентов и их взаимодействия.

• Детальное проектирование: проектирование базы данных (ER-диаграммы); пользовательских интерфейсов (прототипы, макеты); поведенческих моделей; алгоритмов; API.

• Выбор инструментов и платформ разработки.

• Создание и согласование проектной документации.

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

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

2.3.  Разработка (реализация), тестирование и верификация

Чаще всего фаза является сердцевиной ЖЦ производства, где планы и проектные решения трансформируются в работающий продукт. Цель стадии: создать качественную, работающую систему, а также убедиться, что система работает корректно и соответствует Требованиям, разработанным на предыдущем этапе.

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

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

К таким противоречим можно отнести:

• Скорость (Time-to-Market) vs Качество. Пожалуй, это главное противоречие. Давление бизнеса на быстрый релиз противоречит необходимости тщательного тестирования, рефакторинга и создания надежной архитектуры.

• Гибкость (Agility) vs Предсказуемость. Необходимость быстро реагировать на изменение требований (Agile) конфликтует с потребностью в точных оценках сроков, бюджета и жёстком соблюдении плана (Waterfall).

• Инновации vs Технический долг. Стремление внедрять новые технологии и подходы сталкивается с необходимостью поддерживать работоспособность legacy-кода и отдавать долги за прошлые упрощения.

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

Основные задачи фазы:

• Управление работами по реализации проектного решения.

• Написание исходного кода на выбранных языках программирования.

• Создание хранилищ данных и механизмов доступа к ним.

• Создание компонентов, интеграция отдельных модулей в единое целое.

• Модульное тестирование, проверка отдельных функций.

• Интеграционное тестирование, проверка взаимодействия модулей.

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

• Исправление выявленных ошибок (багов).

• Управление требованиям и их трассируемость с разработанным решением.

• Настройка инфраструктуры для непрерывной интеграции и доставки решения конечному потребителю.

Результаты: исходный код, конфигурации и сборки /артефакты, размещенные в репозитории артефактов; отчёты о дефектах; подтверждение соответствия требованиям.

2.4.  Внедрение (Развертывание), ввод в эксплуатацию

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

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

На данной стадии на практике так же выполняются активности, относящиеся к функциям тестирования, связанные с подтверждением заявленных технико-эксплуатационных показателей уже на оборудовании заказчика.

Основные задачи фазы:

• Планирование и подготовка этапов внедрения, согласование и утверждение их с заказчиком.

• Развертывание системы на реальном оборудовании или в production-среде.

• Миграция данных из старых систем (при необходимости).

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

• Приемочное тестирование (UAT), проверка системы заказчиком /конечными пользователями в условиях, близких к реальным.

• Подготовка эксплуатационной документации.

• Плавный переход на новую систему.

Результаты: планы развертывания, коммуникаций, обучения; релиз; подготовленные пользователи; работающая система (актив).

2.5.  Эксплуатация и техническая поддержка, развитие

Обеспечение стабильной и полезной работы системы. Организация активностей по поддержанию системы в рабочем состоянии.

В зависимости от условий и приоритетов стадия часто совмещает два типа параллельных и иногда конкурирующих типа активностей:

1)  Эксплуатация и техническая поддержка: в основном рутинная, реактивная деятельность по обеспечению стабильности, доступности и безопасности работающей системы.

2)  Развитие: через проактивную деятельность по изменению и улучшению системы для соответствия новым бизнес-требованиям. В данном контексте эволюционно.

Основные задачи фазы:

• Мониторинг производительности и доступности, с целью минимизировать простои и сбои.

• Техническая поддержка пользователей, с принятым уровнем качества сервисов.

• Исправление ошибок, обнаруженных в процессе эксплуатации.

• Резервное копирование данных и обеспечение отказоустойчивости.

• Анализ и оптимизация.

• Добавление функциональности, развитие систем.

Результаты: стабильно работающая система, генерирующая выгоды предприятию; обратная связь с анализом проблем, недоработок, перспектив развития.

2.6.  Завершение (Вывод из эксплуатации)

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

Основные задачи фазы:

• Принятие решения о замене системы на новую или модернизации.

• Архивация данных.

• Отключение серверов и служб.

• Миграция пользователей на новое решение.

• Анализ накопленного опыта для будущих проектов.

• Утилизация команды, поддерживающей работу системы.

Управляемый вывод системы из эксплуатации — это признак зрелости ИТ-менеджмента компании.

3.  Итоги

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

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