Метрики успеха: RUP и научный подход

Gary Pollice, Профессор прикладных наук, Worcester Polytechnic Institute

Оригинал статьи: http://www.ibm.com/developerworks/rational/library/jul06/pollice/index.html?S_TACT=105AGX15&S_CMP=EDU

Картинка статьи по оценке метрик процесса на основе IBM Rational Unified Process (RUP) с использованием научного подхода

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

Я уже неоднократно утверждал в течение последней пары лет, что термин "программная инженерия" (software engineering) часто употребляется некорректно. В реальности мы занимаемся разработкой программного обеспечения (software development). Филипп Крачтен (Philippe Kruchten) и другие специалисты уже высказывались о двух вещах, которые делают разработку программного обеспечения отличной от других инженерных дисциплин: каждый программный проект уникален и не существует никаких фундаментальных законов, применяемых к ПО. Но означает ли это, что мы должны отбросить все надежды найти фундаментальные законы и выработать инженерный подход применительно к разработке ПО?

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

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

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

Я хочу рассмотреть этот последний пункт более детально -- сбор данных для проверки преимуществ процесса.

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

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

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

Да, команда сообщила, что она следовала процессу и входящие нее специалисты сами верят и честно утверждают, что так оно и было. Но в действительности это совсем не означает, что они соблюдали процесс, особенно, учитывая, что выбранный процесс был новым для организации. Возможно, они больше беспокоились о том, как построить саму систему, просто потому, что им было известно о Вашем желании собрать данные об их производительности. Это пример т.н. эффекта Хоторна (Hawthorne Effect)1. Так что все же вопрос остается: как понять, что следует измерять?

Измерение процесса, построенного на принципах Rational Unified Process

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

Rational Unified Process или RUP включает руководства для большинства областей разработки программного обеспечения. Чтобы успешно использовать Rational Unified Process/RUP, необходимо таким образом сконфигурировать этот процесс, чтобы он наиболее полно соответствовал текущему проекту. Большинство конфигураций RUP базируются на наборе "лучших практик" (best practices) и других техниках, которые уже доказали свою эффективность в разнообразных софтверных проектах, лежащих в области разработки программного обеспечения.

Подход очень простой. Выбираем практику и рассматриваем, как можно измерить степень ее использования проектной командой. Применим технику "Метод задания целевого вопроса" (Goal Question Method, GQM). При этом цель формулируется прямо. Мы хотим знать, действительно ли команда использует процесс. Далее составляем такие вопросы, которые помогут получить ответы и благодаря этому определить, достигнута ли поставленная цель или нет. Наконец, для каждого ответа следует определить, что именно он измеряет.

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

Мы рассмотрим лишь три базовые области RUP: управление требованиями (requirements management), итеративный подход к разработке (iterative development) и контроль качества (testing). Существует множество вариантов и их комбинаций, позволяющих взять любую из них и использовать в нашей работе. Но целью данной статьи является простой выбор какой-либо техники или метода и попытка провести измерения, чтобы лучше понимать эффективность процесса.

Управление требованиями

Большинство вариантов или конфигураций RUP акцентированы на применении сценариев использования (use-cases), как центрального элемента разработки ПО. Это означает, что для выявления функциональных требований (требований, которые определяют, что в действительности должна делать система) используются сценарии использования для описания поведения системы. Какие вопросы можно было бы задать, чтобы определить, использовала ли в действительности команда сценарии использования для описания системы с функциональной точки зрения? Очевидный вопрос типа “Использовала ли команда сценарии использования” не предоставляет ответа, который можно использовать при расчетах в числовом виде. Первый адекватный вопрос, который приходит на ум: "Все ли функции реализованные в коде, описаны в сценариях использования"? Этот вопрос представляется достаточно прямым и откровенным. Если можно идентифицировать, какие функции были реализованы, то можно сравнить их с функциями, описанными с помощью сценариев использования. Трудность заключается лишь в том, чтобы определить, какие же функции реализованы на самом деле. Если это может быть сделано, то можно рассчитать следующую метрику эффективности сценариев использования:

Формула для расчета метрики эффективности применения сценариев использования

где Fi - это число всех реализованных функций и Fs - число функций, которые были и реализованы, и описаны. Если умножить U на 100, то можно получить процент реализованных функций, которые были описаны в сценариях использования в действительности.

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

Есть лишь одна проблема с нашей метрикой. Как получить реальные значения Fs и Fi? Во-первых, поделите сценарии использования на дискретные функции, Fs, это не сложно. Мы исследуем сценарии использования и обычно соглашаемся с теми специфическими свойствами, которые в них указаны. Можно было бы рассмотреть каждый шаг сценариев, связанный с описанием поведения системы, в качестве базы для нахождения функций. Но гораздо тяжелее вычислить Fi. Если просто протестировать описанные функции, то можно получить в результате, что все они реализованы, но невозможно на основании этого точно определить, реализовали или нет разработчики какие-либо неописанные функции.

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

Другой путь поиска неописанных, но реализованных, функций состоит в том, чтобы позволить тестировщикам провести что-то типа т.н. исследовательского тестирования программной системы. Исследовательское тестирование -- это техника, пропагандируемая Сэмом Канером (Cem Kaner) и Джеймсом Бахом (James Bach). Используя эту технику, тестировщик начинает свою работу не с набора сформированных сценариев тестирования или тестовых скриптов. Тестировщик просто "исследует" программное обеспечение и смотрит, что оно может делать. Он старается выяснить, что можно делать с помощью этого продукта. При этом дополнительно можно предоставить тестировщику сценарии использования, чтобы он использовал их в качестве руководств. Когда тестировщик находит нечто отсутствующее в сценариях использования, то он фиксирует это в виде того, что было реализовано, но не было описано.

Предпочитаемый мной самим метод определения значения Fi основан на гибридном подходе:

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

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

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

Итеративная разработка

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

Какие вопросы можно было бы задать, чтобы понять, использовала ли команда на практике итеративный подход к разработке ПО? Одной из характеристик итерации является то, что она фиксирована в своих границах (time-boxed). То есть, приступая к итерации, следует определить ее дату завершения. Когда эта дата наступает, то итерация считается завершенной. В результат выполнения итерации входят только законченные функции или что-то такое, что можно использовать для измерения прогресса, например, поставляемый заказчику продукт (iteration deliverable). Если имеется функция, которая почти реализована, но все же требуется небольшая ее доделка, то она не считается входящей в продукт поставки -- то есть при этом итерация не расширяется для того, чтобы доработать недоделанную функцию. В этом случае единственный вопрос, который может быть задан "Были ли у итераций на самом деле зафиксированные границы?" То есть, была ли определена дата окончания итерации при ее старте и стала ли она реальной датой ее завершения?

Мы можем определить метрику для определения степени соблюдения итеративности с помощью следующей формулы:

Формула для расчета метрики - степени соблюдения итеративности

где Im является числом итераций, в которых дата окончания была скорректирована (уже после старта итерации) и It является общим числом итераций. Если команда строго следовала итеративному подходу, то результатом будет ноль. На другой стороне возможных вариантов будет случай, когда команда корректировала конечные даты для каждой начавшейся итерации. В этом случае получим единицу. Такую метрику легко вычислить в независимости от того, как ведутся проектные планы. Все, что необходимо, это проследить изменения дат в проектных планах. Итерации с фиксированными границами необходимы, но недостаточны для подтверждения применения командой итеративного подхода к разработке ПО. Что еще следует узнать? Другой вопрос, который можно было бы задать: "Выпускалось ли работающее программное обеспечение в конце каждой итерации?" Это может быть определено подсчетом числа итераций, в которых выпускалось работающее программное обеспечение. Если велась архивация конфигураций программного обеспечения в конце каждой итерации, обычно с помощью расстановки меток в системе управления версиями и конфигурациями, и пересборка в случае необходимости, то можно оценить, существовали ли работоспособные релизы системы в течение тех самых коротких промежутков времени.

Как только получена информация по каждой итерации, то можно рассчитать коэффициент работоспособного ПО, W, следующим образом:

Формула для расчета метрики - коэффициента работоспособного ПО

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

Практики тестирования

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

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

Предположим, что в планах тестирования указана необходимость разработки компонентных тестов (unit tests) разработчиками для каждой создаваемой функции, а также то, что тестировщики должны разработать набор интеграционных и приемочных тестов, связанных с требованиями, и собираются тестировать работоспособное программное обеспечение в каждой итерации. И снова возникает необходимость идентификации вопросов, которые помогут определить, действительно ли команда следовала процессу. Рассмотрим лишь один вопрос для нашего примера: "Использовали ли разработчики компонентное тестирование кода?" Это легко измерить в случае применения автоматизации тестирования, когда все компонентные тесты запускаются одной командой. Еще лучше, если можно настроить систему управления версиями и конфигурациями, чтобы запускались тесты после каждого возвращения кода в общий репозиторий (например, операций check-in для группы файлов).

Как узнать, все ли функции накрыты компонентными тестами? Это может быть не так просто определить объективно. Можно добиться, чтобы каждая строчка кода исследовалась компонентными тестами, но это может быть в некоторых случаях непродуктивно -- то есть будет намного дороже тратить столько усилий на разработку тестов, чем мы потеряем в случае реального возникновения необнаруженных проблем в коде. Одну вещь всегда надо принимать во внимание, что на все времени все равно не хватит, поэтому следует расставлять приоритеты, предпринимая что-либо. По разным причинам, можно решить, что достижение 100% покрытия компонентными тестами кода непрактично, но определенно оно должно быть близко к 100%. Одна из метрик, которая в этом случае приходит на ум, а каков процент покрытия кода компонентными тестами. Можно получать такие данные в конце каждой итерации или несколько раз в течение нее. То, что нам требуется, это тренд (изменение параметра с течением времени) данных. Именно он позволит узнать, применялось ли компонентное тестирование непрерывно в ходе всего проекта.

Пусть у нас было двенадцать итераций, и мы накопили соответствующие данные. График на Рисунке 1 представляет эти данные по трем проектам.

Картинка, представляющая процент тестового покрытия для двенадцати итераций, охватывающих три проекта

Рисунок 1: Процент тестового покрытия для двенадцати итераций, охватывающего три проекта

Исходя из этих данных, можно заключить, что Проект 2 (изображенный в виде резко падающей линии на Рисунке 1) фактически не следовал руководящим принципам формализованного процесса в области применения компонентного тестирования. А вот в Проектах 1 и 3, похоже, проделана неплохая работа. Можно продолжать копать и далее в этом же направлении, если имеются ежедневные данные, чтобы при необходимости получить еще более точную картину. График на Рисунке 2 показывает ежедневно оценивавшиеся данные по компонентным тестам для двух проектов, которые размещены в тех же координатных осях x и y, как на Рисунке 1, но при этом значительно отличаются из-за меньшего шага дискретизации координат. Рассмотрим лишь четыре итерации, имеющие недельную длительность для каждой (состоящие из пяти рабочих дней). В данном случае, в Проекте 2 не тратилось время на разработку тестов, пока выполнялась реализация кода, а в конце итерации отводилось время на написание тестов. Если оба проекта отличаются по степени достигнутого успеха -- например, если Проект 2 выпускает менее качественную продукцию, чем Проект 1, -- это может указывать на то, что тестирование способствует повышению качества.

Картинка, представляющая процент тестового покрытия, если команда в Проекте 2 разрабатывала тесты в конце каждой итерации

Рисунок 2: В этом случае, команда в Проекте 2 не тратилась на разработку тестов по мере создания кода, но делала это в конце каждой итерации.

Заключение

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

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

Примечания

1 Эффект Хоторна (Hawthorne Effect) ссылается на возникновение неожиданной связи между наблюдением и поведением; в частности, когда акт наличия наблюдения может привести к тому, что результаты поведения будут отличаться, возможно, приводя к более высоким результатам, чем в обычном режиме. Впервые такая связь была исследована с помощью экспериментов с производительностью труда на заводе Хоторна компании Western Electric.

© 2008-2023 Финэкософт.

 

Oracle Silver Partner
+7 (495) 234 8808
Учебный центр
Центр обучения и сертификации в области информационных технологий (IT).

Широкий выбор курсов и программ обучения. Подробности здесь.

Отправить письмо
Обратная связь

 

Для Ваших вопросов и отзывов