Жизненные циклы разработки. Анализ требований

Записаться

Мы продолжаем курс «Анализ требований к информационным системам». Сегодня мы перейдем к лекции 2, в которой более пристальное внимание уделим рассмотрению жизненного цикла разработки информационных систем, а также жизненного цикла самих информационных продуктов.

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

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

Основной объект нашего внимания в этой лекции – SDLC (Software development lifecycle), если дословно перевести на русский язык – «жизненный цикл разработки информационных систем и продуктов». В области информационных систем применительно к процессам разработки выделяют жизненные циклы самих систем и процессов разработки. Это важное различие, которое разделяет фокус внимания специалистов, участвующих в создании информационных систем. Основное прикладное назначение жизненных циклов – объединять различные специализированные этапы в разные рабочие методологии, назначением которых является создание информационных систем по разным критериям и с вниманием к разным аспектам создаваемых систем. Мы рассмотрим три основных типа жизненных циклов, которые демонстрируют эволюционное развитие подходов к разработке информационных систем. Основная тема нашего курса – анализ требований, поэтому важно рассмотреть то, как он изменяется и применяется и каково его назначение в разных типах жизненного цикла. Этому сравнению мы уделим отдельный рабочий модуль. Поняв различия в применении анализа, мы сделаем выводы о том, что траектория профессионального развития аналитика сильно зависит от той методологии, в которой он функционирует как специалист. На основе этих выводов мы сделаем заключение о том, как следует развиваться аналитику.

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

Понятие жизненного цикла интуитивно. Речь идет о процессе с момента появления замысла, то есть идеи, до момента, когда эта идея, воплощенная в виде материального или информационного артефакта, утилизируется – то есть «от момента рождения до момента смерти». Жизненный цикл описывает эти этапы и акцентирует внимание на тех из них, которые представляют наибольшую ценность для создаваемого продукта. Часть этапов может детализироваться и иметь продолжение, которое оказывает влияние на смежные циклы. В этом случае нужно четко понимать, что от этих результатов требуется для поддержания жизненных циклов, в которых они задействованы. Цель жизненного цикла – достичь запланированного, понятного, воспроизводимого результата деятельности.

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

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

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

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

Исторически первая методология – фундаментальная. Она наиболее комплексная и уделяет максимум в части теории тому, как достигать запланированного результата в определенных временных рамках. Это каскадная модель. Еще ее называют Waterfall. Существует она в двух видах. Перечислю основные моменты, характеризующие эту методологию: очень высокая цена ошибки, если таковая допускается во время разработки продукта; очень высокий расчет на профессионализм исполнителей. При этом фундаментальная методология – самая романтичная и идеалистичная, она не учитывает риски и верит в то, что все будет хорошо. Следующая методология, по ходу исторического развития, – разработка через тестирование. Это модель разработки, принятая и до сих пор используемая в компании НАСА, она делает акцент на постоянной валидации запланированного и сделанного. Для этой методологии также требуются исполнители высокой профессиональной зрелости, замотивированные на работу. При этом, эволюционно решая многие проблемы, которые приводили к рискам в каскадной модели, эта разработка наполнена дополнительными контрольными процедурами и тестированием, что приводит к появлению дополнительных ролей и, как следствие, удорожанию процесса разработки информационных продуктов. Следующая – спиральная модель. Уникальность этой модели состоит в том, что она заложила основу по работе с рисками и качественно изменила линейность складывающихся процессов с понятными началом и концом в сторону спирального, бесконечного развития, подкрепляемого целями и ценностью от создаваемого продукта. И последний, то есть самый востребованный подход – Agile. Здесь сложность и комплексность, как элемент современных систем, выходят на другой уровень. Задача процесса разработки – решать понятные, маленькие и очень ценные задачи. Ошибки, допускаемые в ходе процесса разработки, можно и даже нужно исправлять как можно раньше рано за счет того, что над продуктом работает саморегулируемая команда специалистов. А теперь уступим место статистике.

Статистика – злая, но крайне справедливая наука. Спорить с ней бесполезно – она оперирует фактами. Эти факты необходимо интерпретировать, обращая при этом внимание на методы их сбора. С 2015 по 2019 год было проведено исследование, основанное на фактах, собранных из 15 тысяч проектов. Основным параметром сравнения является эффективность и удовлетворенность компаний от использования waterfall- и agile-подходов. Полная статистика показывает, что 39% опрошенных говорят об успешности применения Agile, 52% считают его эффективность спорной и 9% недовольны результатами его применения. 11% опрошенных довольны waterfall-подходом, 60% считают его результаты спорными и 29% не удовлетворены его применением. Если посмотреть глубже и разделить проекты на большие, средние и малые, то окажется, что тренд к лидированию Agile в категории успешности сохраняется по проектам всех размеров, кроме малых, в которых наблюдается примерное равенство по успешности между Agile и Waterfall. Причина в том, что в малых проектах фактически Waterfall становится Agile – как структурно, так и по выполняемым операциям. Waterfall уделяет большое внимание и выполнению целевых показателей, что во многом делает сотрудников, вовлеченных в процесс, заложниками намеченных планов.

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

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

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

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