Влияние организованности процесса разработки ПО на качество программ и на личную производительность в Индивидуальном процессе разработки

Совсем скоро, 17 декабря, в учебном центре Luxoft Training пройдет мастер-класс ^[1] Марка Паулка, соавтора модели зрелости возможностей создания ПО (Capability Maturity Model for Software).
Марк Паулк разрабатывает и преподает курсы по разработке ПО, совершенствованию процесса разработки ПО (CMM и CMMI), зрелости процессов, agile-методологиям, управлению проектами по разработке ПО и статистическому анализу.
Предлагаем вам ознакомиться с его статьей, посвященной взаимосвязи между организованностью процесса разработки ПО, качеством ПО и личной производительностью.

Влияние организованности процесса разработки ПО на качество программ и на личную производительность в Индивидуальном процессе разработки

Марк Паулк, Университет Карнеги-Меллон

ВВЕДЕНИЕ

Одним из базовых положений в современной теории процессов разработки программного обеспечения является то, что усиление роли процессов, или приверженности «лучшим практикам», повышает производительность разработчиков и улучшает создаваемые ими продукты. На практике отделить одно от другого довольно трудно, поскольку между двумя этими категориями выстроена сеть сложных причинно-следственных связей, однако такое разделение все же производится весьма часто, поскольку каждое из этих понятий является комплексным и включает несколько измерений. И хотя организованность процесса разработки не гарантирует успешного завершения проекта, она все же повышает такую вероятность.
Вера в то, что организованность процесса разработки ПО повышает ценность, лежит в основе таких моделей и стандартов, как Модель зрелости процессов разработки ПО (CMM) и CMM Integration (CMMI). Характер улучшений зависит от бизнес-процесса, но, как правило, они затрагивают производительность и качество. Для того чтобы продемонстрировать, какое влияние оказывает Индивидуальный процесс разработки ПО (Personal Software Process – PSP) на производительность и качество, можно использовать статистические данные, полученные в ходе анализа. PSP демонстрирует рост производительности и качества, следующий за принятием упорядоченного процесса разработки, но он также иллюстрирует некоторые трудности в определении этих понятий. Уоттс Хамфри успешно применил принципы организованности разработки ПО к CMM, Командному процессу разработки ПО (Team Software Process – TSP) и PSP. Многие исследования показывают влияние этих принципов на качество и производительность организации, команды (проекта) и индивида соответственно.
PSP пошагово применяет понятия процесса разработки и количественного управления к работе разработчика в учебной среде. В PSP существует 4 основных процесса: PSP0, PSP1, PSP2 и PSP3. Каждый процесс надстраивается над предыдущим путем добавления инженерных или управленческих задач. Пошаговое добавление задач позволяет разработчику проанализировать влияние, которое новые методики оказывают на его или ее личную эффективность. Обычно дается 10 заданий. Данные PSP хорошо подходят для исследований, так как многие факторы, влияющие на производительность проекта и вносящие «помехи» в данные исследований, такие как изменчивость требований и трудности командной работы, в PSP либо сдерживаются, либо полностью устраняются. Студенты в PSP используют самые разнообразные языки программирования, однако в выборку были включены только программы, написанные на C (если не указано иное) (чтобы исключить возможное искажение данных), общей численностью 2435.

ВЛИЯНИЕ НА КАЧЕСТВО

Для простого анализа качества в PSP используются доступные данные по плотности дефектов. В разработке ПО данные о количестве дефектов, обнаруженных в первый год (или в первые полгода или другой период времени), часто используются как мера качества. Поскольку обучение PSP осуществляется в учебной аудитории, продукты не проходят «полевых испытаний». Разумным вариантом является использование метрики плотности дефектов, обнаруженных при тестировании. На ящичковой диаграмме (рис. 1) показаны измеримые и статистически значимые улучшения в качестве ПО, произошедшие за 4 PSP-процесса. Качество улучшилось на 79 процентов, а изменчивость снизилась на 81 процент.
Однако необходимо сделать оговорку: несмотря на то, что плотность дефектов может использоваться для измерения качества, заказчиков волнуют не дефекты, а отказы. Дефекты могут годами оставаться незамеченными, не влияя на нормальную эксплуатацию продукта. Даже такое измерение качества, как среднее время между отказами, не является совершенным, поскольку для заказчиков имеют значение многие аспекты программных продуктов (а заказчик – это главный оценщик качества). Например, Гарвин выделяет девять измерений качества (производительность, характеристики, функциональность, безопасность, соответствие стандартам, надежность, долговечность, обслуживаемость и эстетичность), указывая на сложность понятия «всеобщего качества». К характеристикам качества ПО, перечисленным в ISO 9126, относятся функциональность, надежность, удобство использования, производительность, сопровождаемость и переносимость. К сожалению, в контексте PSP возможен лишь анализ плотности дефектов без возможности учета большего контекста. Однако и здесь трудности могут быть весьма серьезными.

Рис. 1. Улучшение качества в PSP

На ящичковой диаграмме «ящики» изображены на 25-й и 75-й процентилях набора данных, а медианой является центральная линия. В этом варианте ящичковой диаграммы «контакты» представлены полуторным межквартильным размахом и могут использоваться для определения выбросов. Линия, проходящая через всю диаграмму, представляет общее среднее для всего массива данных. t-критерий Стьюдента для каждой пары (Each Pair Student’s t) и множественное сравнение Тьюки-Крамера всех пар групп (All Pairs Tukey-Kramer) дают либеральные и консервативные критерии сравнения соответственно; если сравнительные круги не накладываются друг на друга или внешний угол их пересечения меньше 90 градусов, можно сделать вывод о том, что средние значения различных групп существенно отличаются при данном уровне доверительной вероятности (α=0,05).

Рис. 2. Улучшение качества по заданиям

Другим резонным вопросом может стать такой: не даст ли изучение числа дефектов больше информации, чем анализ их плотности, учитывая, что размер заданий примерно одинаков? Как можно видеть на рис. 3, по размерам пять последних заданий больше, чем пять первых, но изменчивость размеров подчеркивает непригодность использования числа строк кода (LOC) в качестве меры определения размера проекта. Поскольку всем студентам давались одни и те же задания и использовался один язык программирования, различия должны объясняться решениями, которые принимал каждый отдельно взятый программист.

Рис. 3. Различные размеры (количество строк кода) заданий PSP

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

Рис. 4. Число дефектов, обнаруженных при тестировании в PSP

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

Рис. 5. Качественные тренды по способностям программистов

ВЛИЯНИЕ НА ПРОИЗВОДИТЕЛЬНОСТЬ

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

Рис. 6. Повышение производительности в PSP

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

Рис. 7. Усилия, затраченные на выполнение заданий

Анализ не выявил влияние образования и количества лет опыта на производительность. Для всего массива данных PSP языки C++ и Java показали «большую производительность», чем C и Visual Basic при измерении числа строк кода в час. Однако если посмотреть на количество усилий, затраченных на решение проблем (как показано на рис. 8 для задания номер 10), то разницы между языками программирования не было выявлено.

Рис. 8. Различия в усилиях при использовании разных языков (задание номер 10)

При измерении производительности как числа строк кода в час, способности программиста оказывают влияние на производительность. Более того, было выявлено, что производительность растет вместе с качеством (что и предполагалось).

ЗАКЛЮЧЕНИЕ

Результаты, представленные в настоящей статье, перекликаются с результатами предыдущих работ по PSP, однако уделяют внимание некоторым трудностям, связанными с интерпретацией результатов. Высказывались сомнения о возможности делать выводы о реальных проектах на основании задач, выполняемых студентами. Однако занятия по PSP часто проводятся в реальных условиях, а не в учебных аудиториях, и разработчики в этой выборке имеют до 34 лет опыта работы со срединным значением 7 лет опыта работы. В этом отношении студенты, обучающиеся PSP, больше похожи на типичных разработчиков, занятых в проектах, нежели на студентов факультета информатики.
Более важным вопросом является степень, до которой задания, выполняемые в ходе обучения PSP, соответствуют реальным проектным задачам. И хотя каждое задание вписывается в рамки реальных проектных работ, задачи в PSP не связаны с такими проблемами, как неопределенность и высокая изменчивость требований или интеграция продукта, которые представляют наибольшие трудности в реальных проектах и являются теми областями, где опыт и подготовка могут сыграть ключевую роль для достижения успеха. PSP учит основам Командного процесса разработки (TSP), и было выявлено, что в TSP-проектах также улучшилось качество и повысилась производительность.
Наиболее трудный вопрос, поднятый настоящим исследованием, является характерным для всей индустрии разработки ПО: как можно достоверно измерить производительность и качество? Как показала данная работа, распространенные метрики плотности дефектов и числа строк кода в час имеют существенные недостатки. Потенциально более достоверная метрика такая, как объем переработки (процент времени, затраченного на исправление дефектов), известна далеко не всем и сравнительно редко используется. Возможно, описанные метрики и окажутся полезными, учитывая, что найти и реализовать лучшие варианты вряд ли удастся, но любые выводы на основании этих анализов должны быть тщательно взвешены до принятия каких-либо решений. В доказательном менеджменте огромное значение играет контекст.
Один из рецензентов настоящей статьи заметил, что справедливо было бы задать и другой вопрос: почему PSP не используется чаще, если он так успешен? К сожалению, не все из многих лучших практик инженерии разработки ПО принимаются компаниями, несмотря на убедительные доказательства выгоды их применения. Например, существует огромное количество исследований, подтверждающих эффективность и результативность инспектирования, однако много ли организаций систематически используют какую-либо форму дружественного оценивания и уж тем более строгого рецензирования? Исследователи могут собрать доказательства для помощи в принятии взвешенных решений и, как учителя и консультанты, могут бороться за принятие тех или иных лучших практик, но организованность процессов в инженерии разработки ПО пока что остается сравнительно молодой.

Capability Maturity Model, CMM и CMMI являются зарегистрированными торговыми знаками Университета Карнеги-Меллон.

SMCMM Integration, Personal Software Process, PSP, и SEI являются знаками обслуживания Университета Карнеги-Меллон.

Подробнее ^[1] о мастер-классе Марка Паулка 17 декабря в Luxoft Training.

Автор: Evgenia_s5

Источник ^[2]