Жизненные циклы разработки

Записаться

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

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

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

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

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

Мы уже говорили о типах жизненного цикла и их эволюционном развитии. С точки зрения наиболее популярных методик разработки информационных продуктов, есть четыре конкретных модели – каскадная, классическая, первая модель разработки информационных систем. Следующая модель, эволюционно более продвинутая, но развитая на основе каскадной модели, – разработка через тестирование. Эта модель основное внимание уделяет качеству создаваемого продукта и до сих пор де-факто является основной для создания информационных систем, в которых много внимания уделяется качеству и надежности. Следующая модель – спиральная, в которой основное внимание уделяется возможности постоянного развития создаваемого продукта. Эта модель создана на основе предыдущих, ее основное назначение – уделять постоянное внимание и создавать возможности для беспрепятственного развития информационных систем, сервисов и продуктов. Название модели отражает ее характеристики, которые способствуют повышению ценности продукта от прохода по новому витку спирали. И последняя модель – Agile – развивает спиральную, регламентируя проход по каждой спирали определенными временными рамками. Итерация – закрытый по времени временной отрезок прохода спирали, который приносит заказчикам ценность от использования развивающегося информационного продукта.

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

Следующая стадия – анализ требований. На основе отлаженных процессов мы продолжаем создавать нашу систему. Идем к заинтересованным сторонам – стейкхолдерам, – просматриваем и анализируем регламентные документы и на основе собранных данных начинаем создавать документы и артефакты, которые затем лягут в основу разработки следующих систем. Именно тут, в этой самой точке мы должны собрать всю ту информацию, которая потом будет автоматизирована в создаваемом продукте. Возможности что-то переделать не будет – все это нужно делать здесь и сейчас. Затем всю собранную информацию мы начинаем синтезировать в единое решение, визуализировать и формализовывать в том виде, который должен помочь нам с принятием основных проектных решений, с пониманием того, какой путь избрать для реализации всех намеченных планов. Дальше мы начинаем проектировать решение, разбивать его на модули и компоненты. Мы строим дизайн системы, ее суть. Тут закладываются основные функциональные и нефункциональные характеристики, которые еще называются атрибутами качества.

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

Следующий этап – тестирование. На этом этапе проверяется уровень качества и, если результаты проверки неудовлетворительны, продукт снова передается в разработку. Отдельная тема для обсуждения – метрики и параметры, которым должен соответствовать создаваемый продукт. Метрики – это те значения, которые помогут в подтверждении того, что достигнут нужный уровень качества. Эти метрики разрабатываются отдельно всей командой разработки, но основой для их разработки является информация, полученная на этапе анализа. Затем метрики будут использованы на этапе тестирования. Далее следует непосредственно установка и настройка программного обеспечения – это стадия развертывания, ну и после того, как система будет готова, начинается ее эксплуатация, сопровождение и обеспечение продуктивной работы.

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

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

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

Следующая из специфичных моделей – спиральная разработка, которая является шагом вперед в осознании возможностей и потенциала развития жизненного цикла создания инновационных продуктов и услуг. Эта модель шагает вперед по сравнению со своими предшественниками не только количественно, но качественно. Количественность – включение новых этапов по сравнению с предшествующими, а качественность – включение этапов из смежных областей деятельности. Это приводит к большей сложности при запуске и сопровождении этой модели, но привносит дополнительную ценность в формирование конечного результата деятельности. Главное отличие этой модели от более ранних – начало работы с рисками внутри циклов. Оборот каждой спирали должен приводить к созданию законченного продукта, пригодного для следующей итерации развития. Ключевое место – анализ требований, который должен формировать законченный продукт на основе ожиданий пользователей. Эта модель явилась рубиконом и послужила формированию идей Agile. Именно на почве этой модели стало возможным выращивать эффективную agile-культуру разработки информационных продуктов и услуг.

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

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

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

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

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

Итак, анализ требований тренды. Во-первых, сквозная автоматизация и продолжение процессов  DevOps, прежде всего –  BizDevOps. У нас появляется еще одно направление, которое должно привести к ускорению разработки программного обеспечения, – это прототипирование и кодогенерация. Инструментов для создания прототипов, по которым можно оценить верность выбранного пути автоматизации, становится все больше и больше. Это работа над логикой исполнения процессов, интерфейсами и прочими деталями, а также все большее сближение анализа, документирования и непосредственно разработки программного обеспечения.

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