Software & Systems

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

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

Отметим, что теория управления проектами и качеством поставляемых ПИ не настолько развита, чтобы дать теоретическое решение поставленной задачи. Предлагаемое в настоящей статье решение основано на анализе и обобщении более чем трехлетнего опыта работы по методологии СММ [2] над проектами ПИ для различных предметных областей с качеством 5 сигма [3] в АОЗТ ИДУ.

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

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

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

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

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

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

Для получения полной картины при отслеживании хода выполнения проектов ПИ в каждой проектной группе в ИДУ осуществляется сбор следующих основных метрик по трудоемкости.

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

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

Трудоемкость обнаружения и устранения ошибки и трудоемкость нахождения и обнаружения дефекта являются основой при планировании работ по предотвращению дефектов в проекте и управлении качеством выпускаемых ПИ.

Трудоемкость обзоров кодов и документов в отдельности. Сбор и анализ этих метрик предназначен для повышения эффективности проведения всех видов обзоров – сокращения сроков проведения обзоров при одновременном повышении качества обозреваемых продуктов.

Метрики трудоемкости являются исходными данными для формирования всех метрических отчетов, метрик завершения отдельных фаз и проекта в целом. Кроме того, они используются при планировании работ по проекту, при оценке длительности отдельных фаз жизненного цикла ПИ и отдельных плановых работ на фазах, они являются основными при управлении проектом и качеством ПИ.

Повторное использование продуктов. Для учета использования в проекте ПИ ранее созданных продуктов применяют коэффициент повторного использования (К(пи)).

К(пи) определяется как отношение трудоемкости создания повторно используемого продукта в какой-либо работе к общей трудоемкости выполнения этой работы без повторного использования:

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

Принято считать проект ПИ новым, если при его выполнении используется не более 75 % ранее созданных продуктов.

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

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

Значение K(p) в каждом конкретном случае  определяется руководителем проекта из своего предыдущего опыта работы или путем усреднения показаний не менее трех независимых экспертов.

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

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

К размеру вновь разработанного кода (рис.1) приводится оценка допустимого количества ошибок и дефектов в проекте ПИ [1] с целью прогнозирования возможного качества разрабатываемого ПИ.

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

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

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

Плотность дефектов в документе (П(дд)) определяется как отношение суммарного количества обнаруженных дефектов в этом документе к его размеру:

Метрика П(дд) приводится к миллиону байтов и используется в метрических отчетах, а также при определении уровня качества выпускаемых ПИ.

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

Метрика П(дк) приводится к 1000 KAELOC и используется в метрических отчетах, а также при определении уровня качества выпускаемых ПИ [1].

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

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

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

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

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

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

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

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

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

Метрические отчеты, принятые В ИДУ, представлены на рисунках 2 и 3.

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

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

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

Два первых графика в нижнем ряду (рис. 2) представляют относительное время, затраченное на проведение семинаров и обзоров продуктов при разработке ПИ соответственно. В ИДУ опытным путем установлено (метрика стандартного процесса – прямые, параллельные оси абсцисс на графиках), что на подготовку и проведение эффективных обзоров (в смысле получения наибольших выгод от их проведения) достаточно планировать 10 % от времени, затраченного на создание обозреваемого объекта.

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

На рисунке 3 представлен принятый в ИДУ одностраничный ретроспективный метрический отчет, который используется при проведении ретроспективных обзоров.

Ретроспективным называется обзор выполненных работ, созданных продуктов и достигнутых целей, выполненных планов и графиков по завершению фаз жизненного цикла или проекта ПИ в целом.

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

В отчете также указывается реальная (фактическая) трудоемкость проекта в целом и оценка точности ее определения.

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

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

Список литературы

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.