CC BY
385
Основными целями проведения ретроспективных обзоров являются:
• обобщение и анализ обозреваемых результа-
тов, документирование, сохранение в исторической базе данных результатов обзора для использования в будущем приобретенных в процессе выполнения проекта ПИ новых знаний и опыта;
• сравнение плановых дат завершения отдельных работ по проекту, отдельных фаз жизненного цикла и проекта ПИ в целом с реальными для корректировки при необходимости соответствующих метрик СП организации;
• обсуждение возникших отклонений от плановых сроков (как в сторону задержки завершения, так и в сторону опережения), анализ вызвавших отклонения причин и сохранение результатов анализа в исторической базе данных для обеспечения возможности повышения качества планирования проектов ПИ в будущем;
• анализ аппаратного, программного, информационного и организационного обеспечения проекта, выявление недостатков в обеспечении и организации работ по проведению проекта как руководителем ГП, так и администрацией ИДУ для выработки предложений по повышению качества всех видов обеспечения в будущем.
В заключение сделаем одно важное замечание. Наш пятилетний опыт работы над проектами ПИ, предназначенными для различных предметных областей, показывает, что без внедрения эффективных средств автоматизации управления проектом ПИ (автоматизированных средств по составлению проектных планов и по отслеживанию хода выполнения проектов ПИ, сбору, хранению и анализу метрик, по управлению улучшением СП и качеством ПИ и т.п.) невозможно осуществить требуемый качественный скачок от внедрения методологии СММ в повседневной работе организации.
СБОР И АНАЛИЗ МЕТРИК ПРИ ВЫПОЛНЕНИИ ПРОЕКТОВ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Любое программное изделие (ПИ) как объект реальности обладает некоторым множеством собственных свойств (например жизненным циклом, уровнем качества его проектирования и качества поставленного ПИ). Из принципа Парето известно, что во множестве свойств ПИ имеется жизненно важное меньшинство (нетривиальное подмножество) и тривиальное большинство. Нетривиальное подмножество свойств ПИ играет определяющую роль в создании возможности успешного завершения программного проекта и выпуска ПИ в установленные сроки без превышения выделенного бюджета, а также в создании возможности управления их качеством, в то время как свойства ПИ из тривиального большинства оказывают второстепенное влияние или не влияют вовсе на создание таких возможностей.
Принято считать, что каждое свойство ПИ (в самом деле интерес представляют только свойства из
нетривиального подмножества) отображается некоторым множеством измеряемых характеристик (множеством метрик), по которым можно судить о количественных оценках этого свойства (например о свойстве "качество поставляемого ПИ" можно судить по метрике "плотность дефектов в поставленном ПИ"). Одна из задач правильной организации программного проекта состоит в том, чтобы найти необходимый и достаточный набор метрик свойств ПИ из нетривиального подмножества, организовать достоверный и регулярный сбор и анализ этих метрик с целью обеспечения возможности периодического отслеживания хода выполнения проекта ПИ, управления проектом и качеством поставляемых ПИ [1].
Отметим, что теория управления проектами и качеством поставляемых ПИ не настолько развита, чтобы дать теоретическое решение поставленной задачи. Предлагаемое в настоящей статье решение ос-
новано на анализе и обобщении более чем трехлетнего опыта работы по методологии СММ [2] над проектами ПИ для различных предметных областей с качеством 5 сигма [3] в АОЗТ ИДУ.
Приведем основные метрики, сбор и анализ которых осуществляется в ИДУ. Использование результатов анализа этих метрик способствовало успешному выполнению в течение трех лет более 10 программных проектов в различных предметных областях.
Трудоемкость. Практические наблюдения показали, что одной из важных метрик нетривиального подмножества для управления проектом и качеством поставляемых ПИ является метрика "Трудоемкость". Различают фактическую и плановую трудоемкость. Фактическая трудоемкость выполнения какой-либо работы - это сумма измеренных фактически затраченных на выполнение именно этой работы отрезков времени всеми ее участниками, включая всех вовлеченных в работу, но не являющихся ее непосредственными исполнителями (руководство организацией, служба снабжения и т.п.). Трудоемкость измеряется в ИДУ в человеко-часах при сборе метрик, в человеко-неделях - в метрических отчетах.
Трудоемкость проекта ПИ является главной составляющей, определяющей его стоимость и, как следствие этого, стоимость выпускаемого ПИ. Заметим, что эффективное управление проектом по созданию ПИ заключается в том, чтобы выполнить проект в плановые сроки без превышения выделенного бюджета.
Регулярное отслеживание затраченной трудоемкости на выполнение разного рода работ по проекту (например трудоемкости функционального проектирования, кодирования отдельных модулей, нахождения и устранения ошибок и дефектов в отдельности и т.п.) и сравнение их с плановыми дает ясную картину расходования выделенных ресурсов на проект, позволяет предвидеть возможности возникновения проблем в выполнении проекта и принимать своевременные меры по их предотвращению.
Обратная величина трудоемкости какой-либо работы называется производительностью выполнения этой работы. Часто встречающаяся ошибка при проведении проектов ПИ заключается в том, что некоторые исполнители принимают производительность кодирования отдельных программных модулей ПИ за производительность создания ПИ. Это приводит к грубым промахам при определении количественного и качественного состава исполнителей проекта, что, естественно, приводит к срыву сроков поставки готового ПИ и увеличению финансовых затрат на проеДктл.я избежания возможности возникновения такого грубого промаха в проекте следует использовать раздельно метрику "Трудоемкость создания программного кода ПИ" и метрику "Трудоемкость создания ПИ". Трудоемкость создания ПИ включает в себя трудоемкость создания программного кода ПИ, а также трудоемкости планирования по проекту, составления и согласования требований, проведения обзоров созданных продуктов, трудоемкость фазы
системного тестирования, обнаружения дефектов в ПИ и их последующего устранения, трудоемкости работ по проекту всех вовлеченных в него участников, включая администрацию, на всех фазах жизненного цикла ПИ. Из определения производительности и различия трудоемкостей создания программного кода ПИ и ПИ в целом видно, насколько значительно отличается производительность кодирования отдельных программных модулей ПИ и создания ПИ в целом.
Для получения полной картины при отслеживании хода выполнения проектов ПИ в каждой проектной группе в ИДУ осуществляется сбор следующих основных метрик по трудоемкости.
Фактическая трудоемкость выполнения каждой плановой работы. Сбор и анализ метрики "Трудоемкость" по каждой плановой работе необходим для того, чтобы иметь полную картину расхождений плановых и действительных данных по трудоемкости выполнения работ с целью своевременной выработки корректирующих действий при управлении проектом и для использования накопленного опыта в прошлом (на выполненных проектах) с целью повышения точности планирования в будущем (в новых проектах).
Суммарная трудоемкость выполнения каждой фазы жизненного цикла ПИ и суммарная трудоемкость выполнения всего проекта необходимы для осуществления оценки реальных затрат на проект и для ретроспективного анализа и использования результатов этого анализа в будущем.
Трудоемкость обнаружения и устранения ошибки и трудоемкость нахождения и обнаружения дефекта являются основой при планировании работ по предотвращению дефектов в проекте и управлении качеством выпускаемых ПИ.
Трудоемкость обзоров кодов и документов в отдельности. Сбор и анализ этих метрик предназначен для повышения эффективности проведения всех видов обзоров - сокращения сроков проведения обзоров при одновременном повышении качества обозреваемых продуктов.
Метрики трудоемкости являются исходными данными для формирования всех метрических отчетов, метрик завершения отдельных фаз и проекта в целом. Кроме того, они используются при планировании работ по проекту, при оценке длительности отдельных фаз жизненного цикла ПИ и отдельных плановых работ на фазах, они являются основными при управлении проектом и качеством ПИ.
Повторное использование продуктов. Для учета использования в проекте ПИ ранее созданных продуктов применяют коэффициент повторного использования (К(пи)).
К(пи) определяется как отношение трудоемкости создания повторно используемого продукта в какой-либо работе к общей трудоемкости выполнения этой работы без повторного использования:
К(пи) всегда имеет значения меньше единицы. Применение повторного использования продуктов в
.1 работ
К(пи)=
Трудоемкость этой работы без повторного использования
проекте ПИ приводит к уменьшению его трудоемкости. Чем больше используется в новом проекте ПИ ранее созданных продуктов, тем больше сокращается продолжительность выполнения проекта. Повторное использование ранее созданных продуктов является действенным средством для повышения эффективности проекта ПИ (сокращения жизненного цикла ПИ, снижения трудоемкости проекта, повышения качества ПИ).
Принято считать проект ПИ новым, если при его выполнении используется не более 75 % ранее созданных продуктов.
Коэффициент риска при выполнении проекта ПИ. Поскольку практически невозможно точно определить оценку общей трудоемкости нового проекта ПИ, то разумно ввести специальную метрику этой неопределенности - коэффициент риска (К(р)).
К(р) предназначен для покрытия возможного просчета в определении оценки общей трудоемкости нового проекта ПИ. В организациях с хорошо налаженным процессом создания выпускаемых на рынок ПИ значения этого коэффициента обычно выбираются из интервала [1<К(р)<1.25].
Значение К(р) в каждом конкретном случае определяется руководителем проекта из своего предыдущего опыта работы или путем усреднения показаний не менее трех независимых экспертов.
Размер программного кода. В процессе разработки ПИ различают несколько разновидностей его программного кода.
. В ИДУ метрические отчеты по размерам разновидностей кодов разрабатываемого ПИ обновляются раз в неделю, для того чтобы повысить эффективность обнаружения возможного отставания от графика выполнения плановых работ по созданию ПИ, обнаружения возможного снижения требуемого качества разработки ПИ и т.п. При каждом последующем измерении метрик ПИ предшествующий суммарный размер кода этого ПИ учитывается как размер базового.
К размеру вновь разработанного кода (рис.1) приводится оценка допустимого количества ошибок и дефектов в проекте ПИ [1] с целью прогнозирования возможного качества разрабатываемого ПИ.
Суммарный размер кода ПИ используется, кроме отслеживания плановых показателей, еще и для определения текущего уровня качества создаваемого ПИ. В случае наблюдения в очередном метрическом отчете снижения уровня качества разрабатываемого ПИ необходимо принимать неотложные меры по
Немодифици-рованный код
Модифицированный код
Размер базового кода
Вновь разработанный
Повторно используемый код
Заимствованный Коммерческий
Размер нового кода ПИ
Суммарный размер кода ПИ Суммарный размер созданного кода при разработке П И
восстановлению требуемого качества и по дальнейшему его улучшению.
Кроме того, отношение суммарного размера кода ПИ к суммарному размеру созданного кода при разработке ПИ определяет коэффициент полезного действия разработки кода ПИ, который характеризует эффективность работы коллектива исполнителей проекта ПИ по созданию поставляемого кода (чем ближе этот коэффициент к единице, тем выше эффективность работы исполнителей проекта).
Остальные разновидности кодов, показанные на рисунке 1, используются руководителями проектов для более детального анализа производства программного кода ПИ с целью уменьшения трудоемкости его создания и повышения его качества, повышения эффективности работы коллектива исполнителей проекта.
Плотность дефектов в документе (П(дд)) определяется как отношение суммарного количества обнаруженных дефектов в этом документе к его размеру:
Метрика П(дд) приводится к миллиону байтов и используется в метрических отчетах, а также при определении уровня качества выпускаемых ПИ.
Плотность дефектов в программном коде ПИ (П(дк)) определяется как отношение суммарного количества обнаруженных дефектов в этом коде к его размеру:
суииарнын размер програииного кода тщ
П(дк)=
КУЕГОС
дефектов
дефектов в коде суииарное количество обнаруженных
Метрика П(дк) приводится к 1000 КЛБЬОС и используется в метрических отчетах, а также при определении уровня качества выпускаемых ПИ [1].
Метрики завершения отражают количественные оценки некоторых выбранных для анализа важных свойств проекта и ПИ на момент окончания проекта. Метрики завершения определяются специально для использования в ретроспективных обзорах по завершению каждой фазы жизненного цикла ПИ и проекта в целом (в разных организациях могут быть определены разные метрики в зависимости от стратегических целей организаций).
Метрики завершения характеризуют накопленный в результате проделанной работы опыт по выполнению проектов ПИ и прогресс в достижении поставленных перед организацией стратегических целей. Эти метрики являются объективным средством для сохранения и обеспечения возможности использования накопленного опыта в прошлом, для увеличения точности планирования, повышения качества ПИ и снижения трудоемкости проектов ПИ в будущем.
Удаленный код
Рис. 1. Разновидность кодов на момент измерения метрик ПИ
Сбор метрик. Практическая ценность от применения результатов анализа метрик впрямую зависит от их достоверности, строгого соблюдения правил сбора и хранения.
Самая важная метрика - трудоемкость выполненной работы - определяется самим исполнителем этой работы. Поэтому необходимо обратить серьезное внимание на то, чтобы сбор этой метрики не раздражал исполнителя и не отнимал у него лишнего времени, происходил в привычной для исполнителя манере с обязательным автоматизированным занесением определенных значений метрики в метрическую базу данных.
Кроме того, для обеспечения сохранности уровня достоверности собираемых метрик, определенного исполнителем работы, следует защитить метрическую базу данных от несанкционированного доступа после внесения в нее очередных данных, то есть обеспечить невозможность корректировки метрик в базе данных сразу после их занесения и в последующие моменты времени.
В ИДУ принята электронная форма заполнения метрик, которая может быть вызвана на экран монитора своего компьютера каждым исполнителем или вовлеченным в программный проект в течение рабочего дня в удобное для них время.
В окне формы "дата" высвечивается текущая дата, привязанная к системному времени компьютера, где она защищена от каких-либо изменений. Все данные, которые будут внесены в таблицу, автоматически привязываются к этой дате в момент их зане-
сения в метрическую базу данных.
Из проектного плана в таблицу автоматически заносятся все работы, которые должен выполнять на текущую дату исполнитель этого проекта, вызвавший таблицу на экран своего монитора. Задача исполнителя работ по сбору метрик заключается в том, чтобы заполнить соответствующие колонки в строках работ, выполняемых на текущую дату, достоверными данными. Имеется возможность редактирования вводимых данных до момента их записи в метрическую базу данных. После записи значений метрик, внесенных в электронную таблицу, в метрической базе данных их невозможно изменить.
Метрики, хранящиеся в базе данных, используются для последующей автоматизированной обработки с целью генерации принятых в ИДУ метрических отчетов и отчетов о ходе выполнения проектов.
Метрические отчеты, принятые В ИДУ, представлены на рисунках 2 и 3.
Первый из них является текущим метрическим отчетом и представляется администрации ИДУ каждой проектной группой один раз в две недели. Этот отчет занимает одну страницу формата А4 и состоит из шести графиков. Первый график, верхний слева, представляет собой отчет о ходе создания кода ПИ. Прямая, параллельная оси абсцисс на этом графике, показывает первоначальную оценку размера кода разрабатываемого ПИ, а четыре кривые на графике отображают размеры нового, удаленного, повторно используемого и суммарного кода ПИ на момент представления метрического отчета в соответствии с
АОЗТ Информационные деловые услуги
Санкт-Петербург, 1998
ОШхшШлШЯШ ™ ГС ГШ й Ш1ЫШ1
Риг.тф программисте
...1.......;........;........
1=
1 -----
.........I-........!■.............1........
......... ........^.....4
П 5 1 1 5 я а 2 : ; 1 § 1
I-
1 5 I здздза^йй
И
»
V: ■ П
¡¿.и г -а- *.......
.А 11
й ::::
7 '...... —+—
С
:
Количеств« вшнбпс
Р 1*
¿о
п
П
ги
ГИ Г1 II п
^ г 5 Й г
ОТЧЕТ СФОРМИРОВАН НА I 18Ш58
Рис. 2. Двухнедельный метрический отчет АОЗТ ИДУ
СФОРМИРОВАТЬ ОТЧЕТ НА
[ 1s.03.98]
РАСПЕЧАТАТЬ ДВУХНЕДЕЛЬНЫЙ ОТЧЕТ
ВОЗВРАТ В ШЕНЮ ОТЧЕТОВ
метрикой рисунка 1. Все перечисленные кривые строятся с нарастающим итогом.
Следующий, средний график в верхнем ряду, представляет собой отчет о суммарном размере всех созданных на момент представления метрического отчета документов. Он также представляется с нарастающим итогом.
Последний график в верхнем ряду отображает количество найденных, устраненных и открытых на момент представления метрического отчета ошибок и дефектов. Все кривые на этом графике строятся также с нарастающим итогом.
Два первых графика в нижнем ряду (рис. 2) представляют относительное время, затраченное на проведение семинаров и обзоров продуктов при разработке ПИ соответственно. В ИДУ опытным путем установлено (метрика стандартного процесса - прямые, параллельные оси абсцисс на графиках), что на подготовку и проведение эффективных обзоров (в смысле получения наибольших выгод от их проведения) достаточно планировать 10 % от времени, затраченного на создание обозреваемого объекта.
Наконец, последний график в нижнем ряду представляет собой распределение плановых и фактических трудоемкостей выполнения "ключевых" работ при разработке ПИ. По этому графику легко судить о точности планирования, он строится по любым двухнедельным метрикам и помогает руководителю проекта ПИ оценить сделанные им плановые прогнозы по трудоемкостям отдельных проектных работ. Поскольку этот график строится по двухнедельным результатам, то у руководителя проекта имеется воз-
можность оперативной коррекции своих действий при планировании в случае неудовлетворительных результатов. Удовлетворительным в ИДУ считается планирование, при котором отличие плановых цифр от фактических не превышает 15 %.
На рисунке 3 представлен принятый в ИДУ од-ностраничный ретроспективный метрический отчет, который используется при проведении ретроспективных обзоров.
Ретроспективным называется обзор выполненных работ, созданных продуктов и достигнутых целей, выполненных планов и графиков по завершению фаз жизненного цикла или проекта ПИ в целом.
На рисунке представлен пример ретроспективного метрического отчета по окончании проекта ПИ в ИДУ. В него включены распределения оценок точностей определения плановых трудоемкостей фаз жизненного цикла ПИ и трудоемкостей плановых ключевых работ на фазах - верхние графики, а также распределения оценок точностей определения их плановой продолжительности - нижние графики.
В отчете также указывается реальная (фактическая) трудоемкость проекта в целом и оценка точности ее определения.
Содержание ретроспективного отчета может меняться в зависимости от стратегических целей, которые преследует организация в некоторый исторический момент времени ее развития.
В заключение отметим, что все метрические отчеты, принятые в ИДУ, генерируются автоматически из метрической базы данных, которая пополняется каждый день при заполнении исполнителями проекта
АОЗТ ИНФОРМАЦИОННЫЕ ДЕЛОВЫЕ УС ЛУ ГИ
Санкт-Петербург, 1998
Точнсстх [>ци(<); труде влксстм фаз
\ И И ! I
Тенит сшяюк понппжнтепыштн 4
В 5 ? И
Тфиюстх «щанас трудовпкоетт хлю-иш работ
а >■
Тс'ммп оцашг: лродсттшнрстк
I I I
i i i м
Реальная трудоемкость: 750 человеко-недель Точность оценки трудоемкости : 80 процентов
ОТЧЕТ СФОРМИРОВАН НА
Рис. 3. Ретроспективный метрический отчет
СФОРМИРОВАТЬ ОТЧЕТ НА
iT.oe.9s
РАСПЕЧАТАТЬ ОТЧЕТ
ВОЗВРАТ В МЕНЮ ОТЧЕТОВ
ПИ метрических электронных форм. Метрическая база данных ИДУ формируется в виде линейного массива, содержащего информацию о ежедневно выполняемой работе. Такая организация метрической базы данных дает возможность простыми средствами организовать генерацию любого нового метрического отчета. Это позволяет при необходимости оперативно вносить изменения в формы и в содержание метрических отчетов, принятых для представления при проведении различного вида обзоров.
Список литературы
1. Grady R.B. Practical Software Metrics for Project Management and Process Improvement. Englewood Cliffs: Prentice Hall, 1992. - 270 p.
2. Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software
3. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ// Программные продукты и системы. -1998. - № 2. -С.2-6.
ОТСЛЕЖИВАНИЕ ХОДА ВЫПОЛНЕНИЯ ПРОЕКТОВ ПРОГРАММНЫХ ИЗДЕЛИЙ
С.Н. Баранов, А.Н. Домарацкий, Н.К. Ласточкин, В.П. Морозов
Одной из ключевых областей процесса второго уровня в соответствии с моделью СММ* стала ключевая область "Отслеживание и наблюдение проектов ПИ".
Целью этой области является определение и установление наглядных форм и способов отображения состояния проекта ПИ, а также процедур, правил, механизмов и мероприятий отслеживания хода его выполнения. Достижение этой цели обеспечивает руководителю проекта, администрации организации и заказчику возможность своевременного принятия эффективных мер всякий раз, когда выполнение проекта отклоняется от плановых показателей.
Все принятые формы, правила, процедуры, механизмы и мероприятия, обеспечивающие выполнение деятельностей по наблюдению и отслеживанию проектов ПИ должны быть включены в стандартный процесс.
В АОЗТ ИДУ приняты стандартные формы метрических отчетов (см. с. 24-29 наст. ном. журн.) и формы еженедельного и месячного одностраничных отчетов о ходе выполнения проекта ПИ.
Метрические отчеты и отчеты о состоянии проекта используются в ИДУ руководителями проектов на еженедельных научно-организационных семинарах в качестве иллюстрационного материала при докладе о ходе выполнения проектов.
Еженедельный одностраничный отчет состоит из трех диаграмм и одной таблицы, кроме того, есть еще и некоторые кнопки, относящиеся к системе автоматической генерации этого отчета. Для генерации отчета необходимо ввести отчетную дату. При генерации в таблицу из базы данных проекта (формируется средствами программного пакета MS Project) переносятся плановые задания, плановые и фактические даты их завершения, введенные в базу данных
* Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993) Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software.
руководителем проекта в процессе оценки готовности выполнения плановых работ за предыдущие 7 календарных дней и планирования работ на 7 последующих.
По фактическим датам завершения плановых работ автоматически строится "Диаграмма хода выполнения работ". Кривая этой диаграммы представляет собой огибающую фактических дат завершения плановых работ.
Диаграммы "Ключевые работы" (трудоемкость ключевых работ в отчетный период) и "Недельные трудоемкости" автоматически строятся по данным из метрической базы данных проекта.
В ИДУ принят такой порядок представления од-ностраничных отчетов на научно-организационных семинарах, при котором в таблицы отчетов заносятся реальные и плановые данные за прошедшую неделю и плановые данные на будущую. Одностраничный отчет распечатывается на прозрачной пленке и проецируется при докладе о ходе выполнения проекта на большой экран для всеобщего обозрения. Такая форма представления и содержание одностраничного отчета обеспечивают эффективный (быстрый и наглядный) способ оценки хода выполнения проекта на отчетную дату.
Недельный период отчетности многократно позволял администрации ИДУ своевременно обнаруживать недостатки планирования в проектах, на ранних стадиях выявлять причины отставания от плановых дат завершения отдельных работ по проектам и своевременно предпринимать корректирующие шаги для предотвращения возможных проблем в проектах. Эксперименты с увеличением отчетного периода до двух недель, проводимые в ИДУ, привели к неприемлемым результатам: заметно увеличились промахи в планировании, что незамедлительно привело к ухудшению качества создаваемых продуктов.
Ежемесячный отчет состоит из 8 секций: 1) краткое описание проекта; 2) перечень ключевых плано-
