|
Измерения проводятся для того, чтобы держать проект под контролем, поскольку без этого невозможно эффективное
управление проектом. Показатели позволяют оценить, насколько проект близок к завершению с точки зрения объема
выполненной работы, качества, соответствия требованиям и т.п.
Кроме того, измерения проводятся для повышения качества прогнозирования стоимости, качества и объема необходимых усилий
для реализации новых проектов. В конечном счете мы измеряем рост ключевых показателей, влияющих на общую
производительность процесса, со временем, чтобы исследовать влияние вносимых изменений.
Измерение ключевых показателей проекта требует определенных расходов. Поэтому не ставится задача измерить все, что
только можно. Необходимо очень тщательно сформулировать цели сбора информации и измерять только те показатели, которые
позволят нам достичь поставленной цели.
Различают два вида целей:
-
Цели в отношении знаний: эти цели обычно характеризуются глаголами "оценить", "спрогнозировать",
"отследить". Их объединяет стремление лучше понять процесс разработки. Примерами целей могут служить оценка
качества продукта, прогноз усилий, которых потребует тестирование, мониторинг тестирования и отслеживание изменения
требований.
-
Цели в отношении изменений и достижений: эти цели обычно характеризуются глаголами "увеличить", "сократить",
"улучшить" и "достигнуть". Как правило, они связаны с постепенным улучшением отдельных показателей и компонентов
процесса по мере выполнения итераций и проектов.
Примеры:
-
Мониторинг хода выполнения работ и соблюдения плана
-
Повышение степени удовлетворения клиентов
-
Повышение производительности труда
-
Повышение предсказуемости
-
Максимальная утилизация многоразовых элементов
Для таких неопределенных целей непросто подобрать адекватные показатели. Эти цели нужно разбить на составляющие их цели
меньшего масштаба (цели действий), в отношении которых будет проще определить, какие действия нужно выполнить
для их достижения. Кроме того, необходимо убедиться в том, что члены проектной группы понимают преимущества.
Примеры
Цель "повысить степень удовлетворения клиентов" можно разбить на следующие цели:
-
Определение понятия степени удовлетворения клиентов
-
Измерение степени удовлетворения клиентов на протяжении нескольких выпусков
-
Проверка гипотезы о том, что степень удовлетворения повышается
Цель "повысить производительность труда" можно разбить на следующие составляющие
-
Измерение затрачиваемых усилий
-
Измерение продвижения проекта
-
Расчет производительности труда в течение нескольких итераций или проектов
-
Сравнение результатов
Затем для некоторых (не всех) малых целей нужно сформулировать показатели для измерения.
Пример
Цели "Измерить степень удовлетворения клиентов" можно достичь следующими способами:
-
Опрос клиентов (в котором клиенты будут оценивать различные аспекты продукта)
-
Количество и серьезность обращений в службу оперативной поддержки
Дополнительные сведения приведены в публикации [AMI95].
Очень полезно разделить цели на категории по характеру соответствующих показателей (показатели могут быть
организационными, проектными и техническими). После этого будет проще разбить их на составные цели по аналогии с
приведенным выше примером.
Организация заинтересована в знании (и, возможно, улучшении) таких показателей, как стоимость за "единицу продукции" и
продолжительность разработки (скорость вывода на рынок) при условии, что разрабатывается продукт определенного
(субъективно и объективно) качества с определенной потребностью в обслуживании. Организация нуждается в регулярном (или
даже постоянном) повышении эффективности своей работы для сохранения конкурентоспособности. Для сокращения рисков
организация должна знать квалификацию и опыт своего персонала и обеспечивать наличие всех необходимых ресурсов для
конкуренции в определенной сфере. Организация должна быть способна внедрять новые технологии и оценивать соотношение их
стоимости и преимуществ. В следующей таблице приведены примеры важных показателей для организаций, занимающихся
разработкой программного обеспечения.
|
Фактор
|
Показатель
|
|
Стоимость продукции
|
Стоимость строки кода, стоимость функционального модуля, стоимость варианта использования. Нормированный
объем затрачиваемых усилий (по определенным сегментам жизненного цикла, языкам программирования, уровням
квалификации персонала и т.д.) на строку кода, функциональный модуль и вариант использования. Учтите, что
эти показатели - не просто числа. Они очень сильно зависят от масштабов разрабатываемой системы и сжатости
графика.
|
|
Продолжительность конструирования
|
Количество времени, затрачиваемого на строку кода и на функциональный модуль. Этот показатель также зависит
от масштабов системы. Разработку можно ускорить, если привлечь больше сотрудников, но только до
определенного предела. Точность определения этого предела зависит от квалификации руководства компании.
|
|
Концентрация ошибок в поставленном продукте
|
Количество ошибок (обнаруженных после поставки) на строку кода и на функциональный модуль.
|
|
Субъективное качество
|
Простота эксплуатации системы и то, насколько она нравится клиентам. Хотя эти показатели весьма
субъективны, существуют определенные методики их измерения.
|
|
Простота обслуживания
|
Стоимость на строку кода или на функциональный модуль в год.
|
|
Профиль квалификации и опыта
|
Управление кадров должно вести определенную базу данных навыков.
|
|
Технологии
|
-
Инструменты - организация должна располагать информацией о том, какими инструментами она пользуется
регулярно, и информацией об опыте работы с инструментами, которыми она пользуется нерегулярно.
-
Зрелость процессов - например, какую оценку организация получила по шкале зрелости SEI CMM?
-
Охват предметных областей - в каких предметных областях может вести работу организация?
|
|
Показатели улучшения процессов
|
-
Стоимость выполнения процессов и количество затрачиваемых усилий.
-
Концентрация ошибок, причинная статистика, удельное количество исправляемых ошибок, переделываемого
кода и повторной работы.
|
Для успешного завершения проект должен удовлетворять следующим условиям:
-
выполнены функциональные и нефункциональные требования
-
обеспечено соответствие техническим ограничениям
-
обеспечено соответствие бюджету и графику
-
достигнуты определенные показатели в отношении поставки продукта, его эксплуатации и обслуживания
Руководитель проекта должен видеть, насколько он приближается к этим целям. В этом ему могут помочь различные проектные
показатели, некоторые из которых приведены в следующей таблице:
|
Фактор
|
Бюджет проекта и количество затраченных усилий
-
Насколько бюджет и объем потраченных усилий соответствуют плану?
|
График проекта
-
Соблюдается ли график проекта?
|
Внедрение и установка
-
Приемлемы ли прогнозы в отношении объема усилий, стоимости и необходимых навыков?
|
Операция
-
Подходит ли клиенту прогноз в отношении объема усилий и необходимых навыков?
|
Простота обслуживания и поддержки
-
Подходит ли клиенту прогноз в отношении объема усилий и необходимых навыков?
|
Функциональные требования
-
Полны ли и допустимы ли предъявляемые требования?
-
Распределены ли требования по итерациям?
-
Соблюдается ли план выполнения требований?
|
Нефункциональные требования
-
Производительность
-
Удовлетворяет ли система требованиям к реактивности, пропускной способности и времени
восстановления?
-
Емкость
-
Способна ли система одновременно поддерживать нужное количество пользователей? Способен ли
сайт обработать нужное количество запросов в секунду? Достаточно ли памяти для сохранения
нужного количества записей заказчиков?
-
Факторы качества
-
Надежность: насколько часто допускается возникновение сбоев и что называется сбоем?
-
Простота эксплуатации: насколько просто и приятно работать с системой? Как долго нужно
учиться работе с системой и какие навыки требуются для работы с ней?
-
Отказоустойчивость, надежность, безотказность и живучесть системы: способна ли система
продолжать работу после сбоя? Корректно ли система обрабатывает недопустимые входные
данные? Способна ли система автоматически восстановить свою работоспособность после сбоя?
-
Особые инженерные требования
-
Безопасность: способна ли система работать безопасно для персонала и имущества (движимого и
недвижимого)?
-
Защищенность и безопасность: защищает ли система данные от несанкционированного доступа?
Защищена ли система от злоумышленников?
-
Влияние на окружающую среду: соответствует ли система экологическим требованиям?
-
Прочие требования законодательных и контролирующих органов
-
Ограничения
-
Внешняя среда: способна ли система работать в той среде, в которой она будет
эксплуатироваться?
-
Ресурсы: удовлетворяет ли система требованиям к процессорам, памяти, языкам и
программно-аппаратной среде?
-
Применение массового (COTS) и другого программного обеспечения: удовлетворяет ли система
требованиям в отношении повторного использования?
-
Доступность и навыки персонала: достаточно ли имеющегося в распоряжении персонала и его
навыков для создания системы?
-
Совместимость и поддержка интерфейсов: способна ли система поддерживать необходимые
интерфейсы взаимодействия с другими системами?
-
Возможность многократного использования: что сделано для того, чтобы систему можно было
использовать многократно?
-
Стандарты: соответствуют ли система и метод разработки установленным стандартам?
-
Прочие ограничения на структуру проекта (например, архитектурные или алгоритмические):
выполнены ли требования, предъявляемые к стилю архитектуры? Применяются ли
предписанные алгоритмы?
|
Это обширный, но отнюдь не полный список вопросов, которые должны волновать руководителя проекта. Некоторые из этих
вопросов потребуют измерения и анализа показателей, некоторые - разработки специализированных тестов, необходимых для
проведения соответствующих измерений.
Многие требования, предъявляемые к проекту, нельзя привязать напрямую к каким-либо показателям, но даже если найден
показатель, остается открытым вопрос о том, что сделать для улучшения этого показателя. С помощью низкоуровневых
атрибутов качества можно добиться повышения качества атрибутов высокого уровня, например атрибутов стандарта ISO 9126
(Показатели и характеристики качества программного обеспечения) или перечисленных выше атрибутов проектного уровня.
Технические показатели характеризуют состояние инженерных (структурных или поведенческих) аспектов процесса и продукта.
В следующей таблице перечислены атрибуты, которые использовались для создания примера набора показателей для процесса и
рабочих продуктов Rational Unified Process. Подробные сведения об этом приведены в разделе Рекомендации по рабочему продукту: Метрики.
|
Качество
|
Атрибуты
|
|
Качество требований
|
-
Изменчивость: частота внесения изменений и ввода новых требований
-
Обоснованность: справедливы ли требования?
-
Полнота: все ли требования обозначены?
-
Правильность формулировок: правильно ли сформулированы требования?
-
Ясность: все ли требования сформулированы понятно и однозначно?
|
|
Качество проекта
|
-
Связность: насколько тесно связаны элементы системы между собой?
-
Четкость: у всех ли компонентов единое, четко прописанное назначение?
-
Примитивность: можно ли сконструировать методы или операции класса из других методов или операций
класса? Если да - методы и операции не примитивны (желательная характеристика).
-
Полнота: все ли требования охватывает проект?
-
Изменчивость: частота изменения архитектуры.
|
|
Качество реализации
|
-
Размер: насколько близка реализация к минимальному возможному размеру (для решения задачи)? Будет
ли реализация соответствовать предъявляемым к ней требованиям?
-
Сложность: сложен ли код алгоритмически? Сложно ли понять и изменить его?
-
Полнота: все ли требования проекта охвачены в реализации?
|
|
Качество тестирования
|
-
Охват: насколько полно тест охватывает программное обеспечение? Все ли инструкции выполняются в
результате проведения набора тестов? Проверяет ли тест работу различных ветвей кода?
-
Обоснованность: корректно ли тесты отражают суть требований к системе?
|
|
Качество процесса (на самом низком уровне)
|
-
Частота и причины возникновения ошибок: насколько часто встречаются ошибки при выполнении задач и
каковы их причины?
-
Усилия и продолжительность: сколько усилий нужно приложить человеку для выполнения операции и
какова продолжительность выполнения операции?
-
Производительность труда: какую пользу приносит операция за единицу человеческих усилий?
-
Качество рабочих продуктов: насколько часто встречаются ошибки в выходных данных задач?
|
|
Эффективность изменения инструментов и процесса
|
(то же самое, что качество процесса, но выражается не в абсолютных значениях, а в процентном изменении):
-
Частота и причины возникновения ошибок
-
Необходимые усилия и продолжительность операций
-
Производительность труда
-
Качество рабочих продуктов
|
Подробное исследование концепции показателей можно найти в источнике [WHIT97].
Мы рассматриваем два вида показателей:
-
Показатель - это измеримый атрибут объекта. Например, объем усилий, затрачиваемых на проект - это измеримый
атрибут (то есть, показатель) размера проекта. Для вычисления этого показателя нужно сложить все записи ведомостей
отработанного времени по проекту.
-
Примитивный показатель - это объект данных, применяемый для вычисления показателя. В предыдущем примере
записи ведомости отработанного времени являются примитивными показателями. Большинство примитивных показателей
представляют собой значения, которые хранятся в базе данных но не интерпретируются в отрыве от других значений.
Каждый показатель состоит из одного или нескольких примитивных показателей. Поэтому необходимо четко описать все
примитивные показатели и сформулировать процедуру их сбора.
Показатели, необходимые для обоснования изменения целей, часто называют "первой производной" по времени (или по
итерации, или по проекту). Нас интересуют тенденции, а не абсолютные значения. Для "повышения качества" нужно убедиться
в том, что остаточный уровень известных ошибок снижается со временем.
Шаблоны показателей
|
Имя
|
Название показателя и его синонимы
|
|
Определение
|
Атрибуты объектов, измеряемые с помощью этого показателя, способ расчета показателя и совокупность
примитивных показателей, на основе которых проводится расчет данного показателя.
|
|
Цели
|
Список целей и вопросов, относящихся к показателю. Кроме того, некое объяснение того, зачем осуществляется
измерение показателя.
|
|
Процедура анализа
|
Способ использования показателя и условия его интерпретации (например, допустимый диапазон значений других
показателей). Целевые значения тенденций. Модели технологий анализа и используемых инструментов. Неявные
предположения (например, в отношении среды или моделей). Процедуры калибровки. Память.
|
|
Ответственность.
|
Кто будет заниматься сбором и объединением данных, анализом и подготовкой отчета?
|
Шаблон примитивного показателя
|
Имя
|
Название примитивного показателя
|
|
Определение
|
Однозначное описание показателя в терминологии среды проекта.
|
|
Процедура сбора
|
Описание процедуры сбора показателя. Используемая форма и инструмент сбора данных. Точки жизненного цикла,
в которых осуществляется сбор данных. Применяемая процедура проверки. Место хранения данных, формат и
точность хранения.
|
|
Ответственность.
|
Лицо, ответственное за сбор данных. Лицо, ответственное за проверку данных.
|
Предусмотрены две задачи:
-
Создать план измерений
-
Провести измерения
План измерений создается один раз в течение цикла разработки - на начальном этапе, как правило, в составе общего
планирования, либо в рамках настройки процесса в варианте разработки. В ходе проекта план измерений может уточняться
подобно любым другим разделам плана разработки программного обеспечения.
Измерения проводятся регулярно, по крайней мере по разу в каждой итерации, а иногда и более часто, например, каждую
неделю в ходе итерации, продолжающейся несколько месяцев.
Результаты измерения заносятся в документ оценки состояния для дальнейшего анализа при изучении хода выполнения и
общего состояния проекта. Кроме того, значения показателей в дальнейшем могут применяться для анализа тенденций в
рамках проекта и всей организации.
Оценка
Руководитель проекта в первую очередь отвечает за планирование - распределение ресурсов по задачам с бюджетами и
графиками. Либо объем усилий и продолжительность проекта прогнозируются исходя из того, что нужно разработать, либо
наоборот - при наличии фиксированного количества ресурсов и ограниченного времени можно оценить, что можно успеть
сделать. Как правило, в ходе оценки проводится изучение потребностей в ресурсах на основе других факторов - обычно
размера и производительности труда - в целях планирования.
Прогнозирование
Прогнозирование отличается от оценки только тем, что в ходе прогнозирования делается предположение относительно
будущего значения какого-либо показателя на основе текущего значения этого показателя и дополнительных факторов.
Например, статистические данные о производительности применяются для прогнозирования поведения системы под полной
нагрузкой, а также при нехватке ресурсов и в ограниченных конфигурациях. В моделях прогнозирования надежности данные об
удельном количестве ошибок применяются для определения того, когда система достигнет определенного уровня надежности.
Спланировав операцию, руководитель проекта заинтересуется данными, которые позволят ему спрогнозировать дату завершения
проекта и объем усилий, которые будут потрачены на него.
Оценка
Оценка применяется для измерения текущих показателей и их сравнения с пороговыми значениями, либо для выявления
тенденций, сравнения альтернативных вариантов или прогнозирования.
Дополнительные сведения о применении показателей в управлении проектами приведены в разделе [ROY98].
|
