Измерения в отношении процессов (Process Measurement)
Используемый здесь термин “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 – следование заданным процессам как повседневная практика работы). Фактор институализации в большинстве случаев объясняет, почему “хорошие” процессы не приводят к желаемому результату, когда процессы полностью или частично остаются лишь на бумаге.
|
|
|
4.2* Измерения в отношении программных продуктов (Software Product Measurement)
Измерения в отношении программного продукта включают количественную оценку его размера, структуры и качества.
* данная тема рассматриваемой области знаний “потеряла” нумерацию в при верстке оригинального варианта SWEBOK 2004, поэтому, далее, нумерация тем смещена.
4.2.1 Оценка размера (Size measurement)
Размер программного продукта чаще всего оценивается по его “длине” (например, в количестве строк кода в модулях, страниц спецификаций требований и других документов) или функциональности (например, по количеству функциональных точек в спецификации). Принципы количественной оценки “функционального” размера программного обеспечения описываются в стандартах:
- IEEE 14143-1 “Information Technology - Software Measurement - Functional Size Measurement - Part 1:Definitions of Concepts”
- ISO 19761 “Software Engineering - Cosmic FPP - A Functional Size Measurement Method”
- ISO 20926 “Software Engineering - IFPUG 4.1 Unadjusted Functional Size Measurement Method-Counting Practices Manual”
- ISO 20968 “Software Engineering-MK II Function Point Analysis – Counting Practices Manual”
4.2.2 Оценка структуры (Structure measurement)
|
|
|
Существует широкий спектр метрик, которые можно использовать для оценки структуры программного обеспечения – в отношении высокоуровневого и низкоуровневого дизайна, а также артефактов кода для анализа потоков работ, потоков данных, вложенности <вызовов>, структур контроля, модульности, взаимодействия и т.п.
4.2.3 Оценка качества (Quality measurement)
Качество, как многомерная характеристика программного обеспечения, наиболее сложно для количественной оценки, в отличие от других характеристик, описанных выше. Более того, некоторые параметры качества требуют, в большей степени, применения качественной, а не количественной оценки. Детальное обсуждение вопросов оценки качества представлено в области знаний SWEBOK “Software Quality” (тема 3.4). ISO разработала соответствующие модели качества программного обеспечения и связанных с ним метрик (см. стандарт ISO 9126 “Software Engineering - Product Quality”, части 1-4).
Дата добавления: 2018-05-12; просмотров: 308; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!