8-software_engineering_process (1133548), страница 4
Текст из файла (страница 4)
Эти методы были разработаны длямодели CMM-SW. С выходом CMMI (интегрированной модели, объединяющей различные моделиCMM), соответственно, получило развитие новое семейство методов - SCAMPI (Standard CMMIAppraisal Method for Process Improvement). Деятельность, выполняемая в процессе оценки,распределение усилий по соответствующим работам и общая атмосфера оценки (касающаяся, впервую очередь, степени формализации, сопутствующей оценке) могут серьезно отличаться, взависимости от того, направлена ли оценка на совершенствование процессов или проводится вконтексте контракта/договора подряда.* SEI разделяет общее понятие appraisal на assessment и evaluation. Assessment – внутренняядеятельность в организации, направленная на оценку и совершенствование собственногопроцесса в рамках всей организации.
Evaluation подразумевает аудит и мониторинг процессовпоставщика (подрядчика, исполнителя) со стороны заказчика, в первую очередь, в процессесамого выполнения работ, т.е. уже после заключения контракта/договора подряда. CBA-IPIотносится к общей категории методов Software Process Assessment (SPA) как части работ поCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Процесс программной инженерии.совершенствованию процессов – Software Process Improvements (SPI). SPI как деятельность посовершенствованию процесса(-ов) сегодня считается достаточно общим термином, используемымза рамками CMM/CMMI, например, в контексте таких фреймворков, как ISO 15504 или TQM (TotalQuality Management).Существует определенная критика моделей, методов (да и самой идеи) оценки.
Такая критика,обычно, основана на эмпирической природе оценки. Однако, по прошествии определенногопериода времени, после публикации таких критических материалов, опыт и практика индустриисформировали достаточно четкие доказательства (в том числе, собрав необходимыестатистические данные – см. отчеты SEI CMU по результатам внедрения и использования CMMI)обоснованности современных принципов, моделей и методов оценки.4. Измерения в отношении процессов и продуктов (Process and Product Measurement)В силу того, что приложение количественных оценок к программной инженерии может бытьдостаточно сложным, в частности, в терминах моделирования или методов анализа, существуетряд фундаментальных аспектов измерений в программной инженерии, лежащих в основе многихболее детальных измерений и процессов анализа.
Более того, результаты усилий посовершенствованию процессов и продуктов, могут быть оценены только в том случае, еслиустановлены количественные характеристики заданных параметров <процессов и продуктов> длязаданных вех или, более точно (так как измерения, все же, выходят за рамки вех конкретныхпроектов, если, конечно, сама SPI-деятельность не позиционировать как проект, что, конечно,возможно), так называемых “базовых линий” (baseline*).* термин baseline обычно используется в контексте управления изменениями, требованиями и,часто, конфигурациями, в целом, для именования временных “срезов” всего комплексасоответствующих активов.Измерения могут проводиться для поддержки инициирования реализации и изменения процессови для оценки результатов таких работ.
Также, измерения могут выполняться и в отношении самихпродуктов.Ключевые понятия, термины и методы измерений в приложении к программному обеспечениюопределены в стандарте ISO 15939 “Software Engineering - Software Measurement Process” имеждународном словаре метрологии ISO. ISO 15939 также определяет стандартный процесс дляизмерения характеристик процессов и продуктов.Необходимо отметить, что в литературе встречаются некоторые терминологические отличия,например, термин “метрика” (metric) часто используется вместо термина “измерение” (measure)**.** В данном переводе эти термины используются взаимозаменяемым образом, за исключениемслучаев, когда контекст обсуждения предполагает разделение процесса измерения – “измерения”,как такового, и критериев/параметров или результатов измерения – “метрик”.4.1 Измерения в отношении процессов (Process Measurement)Используемый здесь термин “process measurement” – “измерения в отношении процесса”подразумевает сбор, анализ и интерпретацию количественной информации о процессе.Измерения используются для идентификации сильных и слабых сторон процесса (strenghts andweaknessess) и для оценки процесса после того, как он реализован и/или изменен.Также, проведение количественной оценки процесса может преследовать и другие цели.Например, соответствующие измерения полезны для управления программными проектами.
Вобсуждаемом здесь контексте, фокус измерений в отношении процессов направлен на оценкуреализации и/или изменения процесса.Рисунок 2 иллюстрирует важность предположений, делаемых в большинстве программныхпроектов, в которых процесс непосредственно влияет на результаты проекта. Соответствующийконтекст воздействует на связь между процессом и его результатом.
Другими словами, этоозначает, что связь процесс-результат процесса находится в зависимости от контексте.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия. Процесс программной инженерии.Рисунок 2. Связь между процессом и его результатами (или “выходом процесса” – processoutcome).Далеко не каждый процесс обладает положительным влиянием на получаемые результаты.Например, внедрение инспекции <получаемого> программного обеспечения может сократитьусилия и стоимость по тестированию, но может и увеличить время, если каждая инспекцияприводит к нарушению расписания просто в силу продолжительности соответствующихинспекционных действий. Поэтому, рекомендуется использовать множество метрическихпоказателей (метрик), по которым оценивается процесс и его результат(ы), безусловно, вконтексте значимых для бизнеса характеристик.Хотя определенные усилия могут направляться на решение вопросов использованиясоответствующего инструментария, главный ресурс, который нуждается управлении – персонал.Как результат, наиболее важные метрики касаются оценки продуктивности команд и процессов(например, может использоваться оценка функциональных точек, производимых на единицутрудозатрат* – “person-effort”), а также, ассоциированного с этим уровня опыта в программнойинженерии, в целом, и в отдельных технологиях, в частности.* трудозатраты чаще всего определяются как “человеко-час”, “человеко-день” или “человекомесяц”; здесь полезно обратиться к юбилейному второму изданию классического труда ФредаБрукса “Мифический человеко-месяц” [Брукс, 1995].Результаты процесса могут, например, оцениваться в отношении качества продукта (как числосбоев на тысячу строк кода – KLOC, Kilo-Lines of Code или на функциональную точку – FP, FunctionPoint), сопровождаемость (усилия, необходимые для реализации определенного типа изменений),продуктивность (LOC, Lines Of Code или FP за человеко-месяц), время вывода продукции на рынок(time-to-market) или степень удовлетворенности потребителей (по измерениям результатовопросов пользователей).
Метод оценки связи между процессом и его “выходом” (результатом)зависит от конкретного контекста, например, масштабов (размеров) организации.В общем случае, мы фокусируемся на результатах процесса. Однако, для достижения заданныхрезультатов (например, в терминах более высокого качества, лучшей сопровождаемости, большейудовлетворенности пользователей) мы должны внедрить соответствующие процессы.Конечно, не только процессы непосредственно влияют на результат <проекта>. Существуют идругие факторы, играющие не менее важную роль, например, возможности инструментов ипотенциал, знания и опыт специалистов.
Когда оценивается влияние изменения процессов, такиефакторы должны учитываться (например, попытка внедрения развитых процессов программнойинженерии при отсутствии ресурсов или в неподготовленной организационной среде практическинаверняка приведет к краху таких инициатив). Кроме того, важна степень институализациипроцессов (process institualization или process fidelity – следование заданным процессам какповседневная практика работы).
Фактор институализации в большинстве случаев объясняет,почему “хорошие” процессы не приводят к желаемому результату, когда процессы полностью иличастично остаются лишь на бумаге.4.2* Измерения в отношении программных продуктов (Software Product Measurement)Измерения в отношении программного продукта включают количественную оценку его размера,структуры и качества.* данная тема рассматриваемой области знаний “потеряла” нумерацию в при версткеоригинального варианте SWEBOK 2004, поэтому, далее, нумерация тем смещена.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия. Процесс программной инженерии.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 MeasurementMethod-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)Качество, как многомерная характеристика программного обеспечения, наиболее сложно дляколичественной оценки, в отличие от других характеристик, описанных выше.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
