Жизненный цикл программного обеспечения

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

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

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

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

Охарактеризовать все методологии быстрого развития по отдельности не представляется возможным -- слишком различны их исходные принципы, слишком зависимы они от специфики коллективов, занимающихся разработками программного обеспечения, от зачастую стихийно складывающихся предпочтений и привычек. На стратегическом уровне их действительно объединяет так называемый Agile Manifesto, принятый энтузиастами в феврале 2001 года в местечке Сноуберд (США), который сводится к четырем постулатам:

· индивидуумы и их взаимодействие важнее процессов и инструментов;

· работоспособное программное обеспечение важнее обширной документации;

· сотрудничество с заказчиком важнее заключения контракта;

· готовность к изменениям важнее следования плану.

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

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

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

Таблица 6.1. Сопоставление жесткой и быстрой стратегий в методологиях программирования

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

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

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

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

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

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

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

Производственные функции в моделировании жизненного цикла: модель фазы-функции

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

· фазовое, отражающее этапы выполнения проекта и сопутствующие им события;

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

Фазовое измерение

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

· Этап исследования -- начинается, когда необходимость разработки признана руководством проекта (контрольная точка 0), и заключается в том, что для проекта обосновываются необходимые ресурсы (контрольная точка 1) и формулируются требования к разрабатываемому изделию (контрольная точка 2).

· Анализ осуществимости -- начинается на этапе исследования, когда определены исполнители проекта (контрольная точка 1), и завершается утверждением требований (контрольная точка 3). Цель этапа -- определить возможность конструирования изделия с технической точки зрения (достаточно ли ресурсов, квалификации и т.п.), будет ли изделие удобно для практического использования; решение вопросов экономической и коммерческой эффективности.

Рис. 6.5. Фазовое измерение модели фазы -- функции.

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

· Программирование -- начинается на этапе конструирования, когда становятся доступными основные спецификации на отдельные компоненты изделия (контрольная точка 4), но не ранее утверждения соглашения о требованиях (контрольная точка 3). Совмещение данной фазы с заключительным этапом конструирования обеспечивает оперативную проверку проектных решений и некоторых ключевых вопросов разработки. Цель этапа -- реализация программ компонентов с последующей сборкой изделия. Он завершается, когда разработчики заканчивают документирование, отладку и компоновку и передают изделие службе, выполняющей независимую оценку результатов работы (независимые испытания начались -- контрольная точка 7).

· Оценка -- является буферной зоной между началом испытаний и практическим использованием изделия. Этап начинается, как только проведены внутренние (силами разработчиков) испытания изделия (контрольная точка 6) и заканчивается, когда подтверждается готовность изделия к эксплуатации (контрольная точка 9).

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

Функциональное измерение

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

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

· содержание (цели) функции на различных этапах претерпевает изменение;

· интенсивность функции (в частности, потребности в ресурсах, необходимых для выполнения) меняется как при переходе от этапа к этапу, так и в рамках работ одного этапа.

Эти положения требуют отражения при моделировании жизненного цикла.

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

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

Исходя из этих предпосылок, строится второе измерение модели Гантера. Гантер говорит о следующем наборе функций (если угодно -- классов функций).

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

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

Рис. 6.6. Матрица фазы--функции модели Гантера.

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

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

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

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

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

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

Состав производственных функций и их интенсивность могут меняться от проекта к проекту в зависимости от его особенностей, от того, что руководство проекта считает главным или второстепенным. К примеру, если исходная квалификация коллектива не очень высока, в список функций может быть добавлено обучение персонала. Иногда бывает важно разграничить планирование и контроль (по Гантеру контрольные функции явно не выделяются). При объектно-ориентированном проектировании роль моделирования возрастает настолько, что его целесообразно перевести из разряда методов проектирования в явно выделенную функцию и т.п.

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

Учет итерационного развития

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

Расщепление линии жизненного цикла может означать два варианта хода развития проекта.

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

Рис.6.7. Учет итеративности в модели фазы-функции (фазовое измерение, показаны лишь некоторые возвраты).

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

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

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

Модели жизненного цикла в некоторых реальных методологиях программирования

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