Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Шпоры Файзера Двухсторонние.doc
Скачиваний:
11
Добавлен:
18.11.2018
Размер:
719.87 Кб
Скачать

24. Парадигма Бейзили

Парадигма Бейзили «цель, вопрос, метрика» («Goal, Question, Metric», GQM) является широко применяемым и хорошо зарекомендовавшим себя подходом к определению метрик, наиболее подходящим для контроля над проектом и формирования решения.

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

В.Бейзили разработал методику, в основе которой лежит процесс, состоящий из семи этапов.

Этап 1 GQM: определение набора целей

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

Цель - представление, оценивание, прогнозирование, мотивация процесса (или продукта, модели, метрики и т.д.), позволяющие его представить, оценить, проконтролировать, исследовать, изучить, усовершенствовать и т. д.

Представление или характеристика предполагает формирование модели объекта, в которой удобно представить собранные данные.

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

Мотивация предполагает наличие точной модели, позволяющей правильно представить объект или позитивное качество.

К проблемным факторам относятся человеческие факторы, а также факторы процесса, продукта и ресурса.

Человеческие факторы — число пользователей, уровень экспертизы программного инженеринга, вопросы организации групп, опыт в предметной области разработки приложений, опыт выполнения процесса и экспертиза инструментария.

Факторы процесса — выбор модели жизненного цикла для проектирования, методов, методик, инструментов и языков программирования.

Факторы продукта — внутренние поставки, размер системы и требуемый уровень качества (например, надежность, переноси-МОСТЕ)).

Факторы ресурса основаны на аналогиях в целевых механизмах и механизмах проектирования, календарном времени, объемах бюджетных средств и существующего программного кода, доступного для повторного использования. Примером полностью сформированной цели является следующая формулировка: «Проанализируйте и оцените с точки зрения команды разработчиков проекта поставленный продукт с учетом сложности интерфейса и в контексте объектно-ориентированной разработки, которая применяется в проекте». Цели также следует подвергать измерениями руководствоваться моделями, принятыми в бизнесе.

Примеры метрик ддя определения прогресса в продвижении к тактической цели по минимизации дефектов и управлению качеством тестирования:

  • среднее время фиксации служебного запроса;

  • суммарный объем обнаруженных дефектов;

  • время фиксации дефектов, соотношение оценочного и реального времени;

  • идентифицированные дефекты, остающиеся открытыми;

  • распределение источников дефектов;

  • среднее время между появлениями дефектов.

Этап 2 GQM: формирование набора вопросов, характеризующих цели

Цели определяются на абстрактном уровне, а вопросы предназначаются для освещения уровня выполняемых операций. Отвечая на вопросы, необходимо уточнять, достигнута ли поставленная цель. Например, если цель процесса формулируется следующим образом: «Совершенствовать способность к реагированию на проблемы заказчиков, сокращая циклическое время, предназначенное для анализа и коррекции этих проблем», то могут возникнуть следующие вопросы.

Этап 3 GQM: определение метрических показателей, необходимых для ответа на вопросы

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

С помощью лишь одной метрики можно получить ответы на несколько вопросов.

С другой стороны, для ответа на один вопрос могут потребоваться несколько метрик.

Этап 4 GQM: разработка механизмов сбора данных

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

Сбор ведет тот, кто «ближе» находится к данным.

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

Каким образом организовать сбор данных наиболее точно и эффективно? Лучше всего воспользоваться автоматизированными инструментами. Механизмы по сбору данных должны быть удобными в работе.

Кто непосредственно работает с метриками? Все зависит от «точки зрения» или от перспективы, описанной в целевом утверждении. Сбор метрических данных должен быть удобными простым.

Этап 5 GQM: сбор, подтверждение и анализ данных

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

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

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

Этап 6 GQM: анализ данных с использованием подпрограммы для оценки соответствия целями рекомендации для дальнейшего совершенствования

Необработанные метрические данные обычно весьма трудны для понимания. Однако если в течение определенного периода времени ведется определенная статистика, то эти данные можно использовать для принятия решения относительно того, достигнута ли цель.

Этап 7 GQM: поддержка обратной связи для организаторов проекта с его участниками

Все сотрудники проекта и другие пользователи, а особенно те, кто собирал данные, должны иметь возможность просматривать результаты своей работы.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]