Измерения в отношении процессов (Process Measurement)

Измерения в отношении процессов и продуктов (Process and Product Measurement)

В силу того, что приложение количественных оценок к программной инженерии может быть достаточно сложным, в частности, в терминах моделирования или методов анализа, существует ряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе многих более детальных измерений и процессов анализа. Более того, результаты усилий по совершенствованию процессов и продуктов, могут быть оценены только в том случае, если установлены количественные характеристики заданных параметров <процессов и продуктов> для заданных вех или, более точно (так как измерения, все же, выходят за рамки вех конкретных проектов, если, конечно, сама SPI-деятельность не позиционировать как проект, что, конечно, возможно), так называемых “базовых линий” (baseline*).

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

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

Ключевые понятия, термины и методы измерений в приложении к программному обеспечению определены в стандарте ISO 15939 “Software Engineering - Software Measurement Process” и международном словаре метрологии ISO. ISO 15939 также определяет стандартный процесс для измерения характеристик процессов и продуктов.

Необходимо отметить, что в литературе встречаются некоторые терминологические отличия, например, термин “ метрика ” (metric) часто используется вместо термина “ измерение ” (measure)**.

** В данном переводе эти термины используются взаимозаменяемым образом, за исключением случаев, когда контекст обсуждения предполагает разделение процесса измерения – “измерения”, как такового, и критериев/параметров или результатов измерения – “метрик”.

Используемый здесь термин “process measurement” – “измерения в отношении процесса” подразумевает сбор, анализ и интерпретацию количественной информации о процессе. Измерения используются для идентификации сильных и слабых сторон процесса (strenghts and weaknessess) и для оценки процесса после того, как он реализован и/или изменен.

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

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

Рисунок 2. Связь между процессом и его результатами (или "выходом процесса" - process outcome).

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

Хотя определенные усилия могут направляться на решение вопросов использования соответствующего инструментария, главный ресурс, который нуждается управлении – персонал. Как результат, наиболее важные метрики касаются оценки продуктивности команд и процессов (например, может использоваться оценка функциональных точек, производимых на единицу трудозатрат* – “person-effort”), а также, ассоциированного с этим уровня опыта в программной инженерии, в целом, и в отдельных технологиях, в частности.

* трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или “человеко-месяц”; здесь полезно обратиться к юбилейному второму изданию классического труда Фреда Брукса “Мифический человеко-месяц” [Брукс, 1995].

Результаты процесса могут, например, оцениваться в отношении качества продукта (как число сбоев на тысячу строк кода – KLOC, Kilo-Lines of Code или на функциональную точку – FP, Function Point), сопровождаемость (усилия, необходимые для реализации определенного типа изменений), продуктивность (LOC, Lines Of Code или FP за человеко-месяц), время вывода продукции на рынок (time-to-market) или степень удовлетворенности потребителей (по измерениям результатов опросов пользователей). Метод оценки связи между процессом и его “выходом” (результатом) зависит от конкретного контекста, например, масштабов (размеров) организации.

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

Конечно, не только процессы непосредственно влияют на результат <проекта>. Существуют и другие факторы, играющие не менее важную роль, например, возможности инструментов и потенциал, знания и опыт специалистов. Когда оценивается влияние изменения процессов, такие факторы должны учитываться (например, попытка внедрения развитых процессов программной инженерии при отсутствии ресурсов или в неподготовленной организационной среде практически наверняка приведет к краху таких инициатив). Кроме того, важна степень институализации процессов (process institualization или process fidelity – следование заданным процессам как повседневная практика работы). Фактор институализации в большинстве случаев объясняет, почему “хорошие” процессы не приводят к желаемому результату, когда процессы полностью или частично остаются лишь на бумаге.

Дата добавления: 2014-10-22