OSS / Системноинженерное мышление в управлении жизненным циклом(2014)

TechInvestLab, 14 июня 2014

181

стадия жизненного цикла включает выполнение многих практик. Горбатая диаграмма для методологии RUP (Rational Unified Process):

На этой диаграмме phases (фазы) это стадии жизненного цикла, которые в свою очередь разбиты на итерации. Практики названы "дисциплинами" (и помним, что практики обычно называют именно по названиям дисциплин, а не по названию рабочих продуктов или инструментов, так что ничего тут странного -- особенно, если учесть, что это диаграмма самого общего вида, а рабочие продукты и инструменты будут конкретизированы только в рамках конкретной организации, и даже конкретного проекта). Чётко видно, что работы по требованиям продолжаются вплоть до стадии передачи в эксплуатацию (transition), а тестирование начинается на начальных стадиях, а не только при подготовке к передаче в эксплуатацию.

Вот ещё один пример горбатой диаграммы: распределение труда по стадиям жизненного цикла в практиках архитектурной работы по MFESA:

TechInvestLab, 14 июня 2014

182

Этот пример показывает, что hump диаграму можно рисовать не только для практик в целом (например, архитектурная работа в RUP), но и для подпрактик (пример разбиения архитектурной работы на её подпрактики/tasks в MFESA).

Водопад и agile

Вид жизненного цикла

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

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

●Формы жизненного цикла

●Метод разработки (development method). Напомним: метод -- это прежде всего набор необходимых для работы практик, метод может не закрывать полного жизненного цикла). Полный синоним -- методология разработки

TechInvestLab, 14 июня 2014

183

(development methodology). Слово "разработка" обычно означает стадии жизненного цикла вплоть до эксплуатации.

●Процессы разработки (development process), в том числе процесс разработки программных средств (software process).

●Модель жизненного цикла (life cycle model) -- но не путайте с рабочим продуктом-моделью (моделью в значении "упрощённое представление системы")! Речь тут идёт просто об именовании варианта альфы определения жизненного цикла (т.е. использование слова "модель" как для указания моделей автомобилей: модель ВАЗ 2110, Ford Focus ST, или модели фотоаппаратов: Nikin D3300, Sony SLT-A77 II, Olympus OM-D E-M10).

По большому счёту, это всё одно и то же: определение того, как будет устроена разработка (т.е. до стадии изготовление, иногда включая стадию изготовление) -- какие практики, какие стадии (в том числе гейты), какие правила лежат в части выбора практик и распределения работы по стадиям.

Виды жизненного цикла, которые "на слуху" -- это RUP (Rational Unified Processel), SCRUM, спиральная модель, и так далее: их сотни.

Стили разработки: водопад и agile

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

●Водопад (cascade, но переводят "каскад" редко, хотя такой перевод и более правилен)

●Agile (на русский обычно не переводится, хотя иногда говорят о "гибких методах")

К водопадным стилям относят такие, при которых отдельные практики выполняются последовательно, как вода проходит какскад -- сначала разрабатываются требования, потом архитектура, потом проект, потом проходит изготовление, потом сборка и т.д. Все рабочие продукты стадий проходят hand over (передачу) на следующую стадию, и дальше не меняются, а используются для получения продуктов этой стадии.

Ключевая предпосылка "водопада" -- это то, что практики совпадают со стадиями жизненного цикла. То есть "проектирование" -- это и практика, и стадия жизненного цикла. "Тестирование" -- это и практика, и название жизненного цикла.

Рисуют это примерно так (оригинальная статья Royce, Winston (1970), «Managing the Development of Large Software Systems» -- http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_win ston_royce.pdf):

TechInvestLab, 14 июня 2014

184

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

Для борьбы с этим были придуманы альтернативные стили, самой популярным из которых был придуманный Barry Boehm стиль "спиральной" модели жизненного цикла -- в которой говорилось, что разработка происходит "по спирали", в которой одновременно выполняется цикл из нескольких практик, поэтому практики и стадии жизненного цикла оказались разъединены. Вот типичное изображение спиральнуой модели (http://mydotnetcoolfaqs.blogspot.ru/2011/04/software- development-life-cycle-sdlc.html -- и по этой ссылке ещё некоторое количество древних моделей жизненного цикла):

TechInvestLab, 14 июня 2014

185

Разными оттенками зелёного показаны стадии жизненного цикла (разработка концепции, разработка системы, усиление системы, сопровождение/обслуживание системы), а практики показаны как сектора на круге (liason тут -- customer communications).

Проблема оставалась: практики предполагались последовательно выполняющиеся на каждом витке спирали, т.е. сохранялся "микроводопад".

Потом было предложено огромное количество других моделей/видов жизненного цикла, пытающихся снять недостатки "водопада", но в 2001 году группа программистов (software engineers) предложила Agile manifesto (http://agilemanifesto.org/):

TechInvestLab, 14 июня 2014

186

Официальный русский перевод (http://agilemanifesto.org/iso/ru/):

Agile-манифест разработки программного обеспечения

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой

TechInvestLab, 14 июня 2014

187

непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Люди и взаимодействие важнее процессов

и инструментов

Работающий продукт важнее

исчерпывающей документации

Сотрудничество с заказчиком важнее

согласования условий контракта

Готовность к изменениям важнее

следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

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

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

На практике оказалось, что следование принципам agile методов разработки и предлагаемым ими моделям жизненного цикла (чаще всего делящих жизненный цикл на стадии "релизов" с выделением мелких подстадий "итераций") может приводить как к впечатляющим успехам, так и к впечатляющим провалам. Также оказалось, что и "водопад" в чистом виде никто не использует, поскольку "по документам" работа описывалась одним образом, а "в жизни" элементы agile использовались много больше. Много было и обычного непонимания. Так, "люди и взаимодействие важнее процессов и инструментов" -- это вовсе не был призыв к луддитству и отказу от инструментов. Просто не было ещё инструментов, которые поддерживали agile-методы разработки. В итоге перестали использоваться как чисто гибкие методы (на их использование ещё и менеджеров было трудно уговаривать, потому как они не дают хорошо спланировать работу заранее и потом контролировать выполнение планов), так и "водопады" (ибо жестко

TechInvestLab, 14 июня 2014

188

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

В системной инженерии "железных" систем методы agile пока используются мало, ибо принято считать, что в существенной мере действует "водопадная" модель. Но в последние годы ситуация быстро меняется: разработка определения системы в существенной мере оказывается похожей на разработку программного обеспечения, и в ней для разработки моделей могут быть использованы те же практики, которые хорошо зарекомендовали себя при разработке программного обеспечения. Единственное что, так это временной лаг: модные в программной инженерии идеи попадают в системную инженерию с задержкой в примерно 10-15 лет. Как раз сейчас начинают говорить о том, что какие-то agile элементы в системной инженерии возможны. Но вот воплощение системы обычно проходит в стиле "водопада": если хорошо проработан проект, и имеется большой опыт создания аналогичных систем, то неожиданностей и "возвратов назад" в проекте будет мало, сборка проходит в точном соответствии с планом, испытания проходят с первого раза.

Хороший пример того, как agile проникает в системную инженерию -- это организация хода разработок в компании SpaceX (см. https://www.aiaa.org/uploadedFiles/Events/Conferences/2012_Conferences/2012- Complex-Aerospace-Systems-Exchange-Event/Detailed_Program/CASE2012_2- 4_Muratore_presentation.pdf).

Паттерны жизненного цикла

Конечно, оппозиция "водопад vs agile" слишком груба. В зависимости от распределения различных рисков по стадиям жизненного цикла вместо обсуждения водопадных и agile стилей в работе http://csse.usc.edu/csse/TECHRPTS/2009/usc-csse-2009-502/usc-csse-2009-502.pdf

предложили различать следующие паттерны:

●Купи готовое (Use Single NDI),

●Гибкий (Agile),

●Гибкий с архитектурой (Architected Agile),

●Формальные методы (Formal Methods),

●Оборудование с программными компонентами (Hardware with embedded Software component),

●Неделимость для начала эксплуатации (Indivisible Initial Operational Capability),

●Много закупок (NDI-intensive) -- проектирование (в отличие от конструирования)

TechInvestLab, 14 июня 2014

189

●Гибрид гибкости и плана (Hybrid agile/plan-driven system),

●Много собственников в системе систем (Multiowner system of systems),

●Семейство систем (Family of systems),

●Brownfield (модернизация)

●Акцент на сервисах (Services-Intensive)

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

Основной жизненный цикл

Состояния альф

Каждая альфа инженерного проекта меняется во времени в его ходе: она проходит по графу состояний. Например, альфа "работа" проходит следующие состояния:

●Инициирована -- работа была запрошена

●Подготовлена -- все предусловия для начала работы выполнены.

●Начата -- работа происходит.

●Под контролем -- работа продвигается хорошо, риски под контролем, уровень производительности достаточен для достижения удовлетворительного результата.

●Закончена -- работа по производству результата была закончена.

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

Конечно, такая последовательность только гипотетична. В жизни альфы могут проходить через состояния циклически, какие-то состояния могут пропускаться, могут существовать альтернативные пути через другие состояния, даже не показанные на этом "счастливом пути" (happy path) по графу состояний. Граф состояний может иметь весьма сложную и запутанную структуру. Но мы будем существенно упрощать представление состояний, показывая только ситуацию прохода по "счастливому пути" -- без возвратов, пропусков и альтернативных

TechInvestLab, 14 июня 2014

190

состояний.

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

Основной жизненный цикл

Важно понимать, что в ходе инженерного проекта меняется отнюдь не только состояния альф инженерного решения (определения и воплощения системы) и их подальф (требований, архитектуры, компонент, модулей и т.д.). Нет, меняется состояние всех альф. Если взять основные (kernel из Essence -- оба слова можно перевести как "основа") альфы инженерного проекта, то можно назвать его основным жизненным циклом. Вот как можно его представить для какого-то более-менее типового проекта: