Учебно-методическое пособие "Управление качеством разработки программного обеспечения"



страница7/18
Дата18.10.2016
Размер1.92 Mb.
ТипУчебно-методическое пособие
1   2   3   4   5   6   7   8   9   10   ...   18

4.2 Стоимость качества.


Фраза «стоимость качества» (“cost of quality”) широко применяется и вводит в заблуждение. Это не цена качества продукта или сервиса. Это не стоимость создания качественного продукта или сервиса. Это - стоимость «плохого качества» (Д. Джуран). Это суммарная стоимость издержек на:

инвестиции в предупреждение несоответствий требованиям

оценку продукта\сервиса на соответствие требованиям

исправление несоответствий требованиям



Preventive costs (стоимость предотвращения низкого качества продукта\сервиса):

  • Обзор (review) нового продукта (требований)

  • Планирование качества

  • Разработка/оценка процессов

  • Планирование улучшения качества

  • Обучение

  • Стоимость всех активностей для предотвращения ошибок (QA)

Appraisal costs (стоимость оценки – измерение, оценка и проверка продукта\сервиса с целью обеспечения соответствия стандартам качества):

  • Стоимость тестирования

  • Стоимость выполнения ревью

  • Стоимость выполнения инстпекций

  • Все затраты на выявление дефектов (QC)

Failure cost (цена «неудач»/ошибок, обнаруженных до поставки поставки продукта\предоставления сервиза заказчику и после: internal failure cost and external failure cost):

  • Стоимость идентификации, анализа, исправления ошибок и проверки исправления ошибок

  • Повторное тестирование

  • Стоимость переработок

  • Стоимость работ по обработке жалоб заказчика

Удельная стоимость исправления дефектов быстро растет по мере продвижения продукта к стадии эксплуатации. Так, в статье B. Boehm and V. Basili «Software Defect Reduction Top 10 List» (IEEE Computer, IEEE Computer Society, Vol. 34, No.1, January 2001, pp. 135-137.) показано, что стоимость исправления дефекта после ввода системы в эксплуатацию вдвое превышает аналогичную стоимость на стадии тестирования продукта и более чем в тысячу раз — в период выработки требований к продукту.

Рис. 8. Стоимость качества.





Что необходимо сделать:

  • Определите, что такое качество в вашей компании (стандарты качества)

  • Определите, что такое качественный продукт\услуга (стандарты)

  • Подумайте над стоимостью плохого качества

  • Определите действия для предотвращения плохого качества, оценки качества продукта\услуги на соответствие стандартам качества

  • Уменьшайте стоимость исправления ошибок путем увеличения затрат на предупреждение и оценку качества.

  • Балансируйте затраты


4.3 Введение в CMMI


«Каркасом» процесса разработки программного обеспечения служит модель зрелости функциональных возможностей (Capability Maturity Model, CMM). Она основана на практических действиях, отображает лучшие результаты и определяет потребности индивидов, работающих над усовершенствованием процесса разработки программного обеспечения и выполняющих оценочный анализ этого процесса. Модель СММ представляет собой схему, по которой этапы разработки соответствуют пяти уровням развития функциональных возможностей, на основе которых осуществляется непрерывное усовершенствование процесса разработки.

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

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

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

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

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

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

Целью разработки CMMI явилось желание его создателей избежать проблем, связанных с использованием различных моделей CMM. Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:

- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software – SW-CMM)


- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM)

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

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

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

Существует два подхода (репрезентации) в совершенствовании бизнес-процессов в контексте CMMI:

- непрерывная репрезентация


- поэтапная репрезентация

Чем же отличаются эти два подхода?



Примечание: репрезентация подобна представлению (view) в базе данных. Данные, используемые в обоих подходах одинаковы, отличаются средства их организации и представления.

При выборе непрерывной репрезентации организация оставляет за собой право выбора последовательности действий ведущих к совершенствованию бизнес процессов. В данном случае усовершенствуются процессы определенной области процессов. Данный подход позволяет мигрировать с модели EIA/IS 731 на модель CMMI.

Поэтапная репрезентация предполагает определенную, доказавшую право на существование, последовательность действий, которая ведет к совершенствованию всех процессов организации в целом, а не определенной области процессов как в предыдущем подходе. Данная репрезентация помогает осуществить переход с модели SW-CMM к модели CMMI.

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

В непрерывной репрезентации для оценки (измерения) степени улучшения процессов используется уровень устойчивости (capability level), в то время как в поэтапной репрезентации используется уровень зрелости (maturity level). Основное различие между этими двумя понятиями заключается в следующем:

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

Непрерывная репрезентация.



Уровень устойчивости

Название уровня

0

Незавершенный уровень

1

Выполненный уровень

2

Управляемый уровень

3

Определенный уровень

4

Количественно-управляемый уровень

5

Оптимизированный уровень

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

Поэтапная репрезентация



Уровень зрелости

Название уровня

1

Начальный уровень

2

Управляемый уровень

3

Определенный уровень

4

Количественно-управляемый уровень

5

Оптимизированный уровень

Рис. 9. Иллюстрация различий в двух подходах:





Различные области процессов (ОП) могут находиться на разных уровнях
устойчивости (УУ)

Все области процессов находятся на одном уровне зрелости (УЗ)

Рис. 10. Структурная схема CMMI – поэтапная репрезентация



Краткий глоссарий CMMI:

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

В CMMI области процессов одинаковы для непрерывной и поэтапной репрезентации.



Практики (practices) – это действия, производимые для достижения поставленных целей в данной области процессов.

Практики являются основным конструктивным элементом на основе, которого построена модель CMMI.



Специфические цели (specific goals) – цели, конкретизирующие основную (общую) цель

Общие цели (generic goals) – это цели, достижение которых в данной области свидетельствует о достижении зрелости процессов в данной области процессов. Слово общие говорит о том, что одна и та же цель может присутствовать во многих областях процессов.

Специфические практики (specific practices) – практики, выполнение которых способствует достижению специфических целей.

Общие практики (generic practices) – практики, выполнение которых способствует достижению общих целей.

Общие признаки (common features) – на самом деле общие свойства - это логическая группировка общих целей.

Субпрактики (subpractices) – представляют собой детализированные описания, поясняющие специфические и общие практики.

Дисциплина (discipline) – область знаний связанная с одной из четырех составляющих применения CMMI. В модели CMMI существует четыре дисциплины:

- разработка программного обеспечения


- системный инжиниринг
- интегрированная разработка процессов и продуктов
- выбор (отбор) поставщиков

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

4.4. Управление требованиями


Определение требований напрямую связано с процедурами проверки (verification) и утверждения (аттестации - validation, как это сформулировано в ГОСТ Р и ISO/IEC 12207). Вообще говоря, принято считать, что требования описаны неполностью, если для них не заданы правила V&V (verification&validation – проверка и аттестация), то есть не определены способы проверки и утверждения. Процедуры проверки являются отправной точкой для инженеров-тестировщиков и специалистов по качеству, непосредственно отвечающих за соответствие получаемого программного продукта предъявляемым к нему требованиям.

Способы описания требований и анализ требований.


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

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

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

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


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

Требования могут выражаться в виде текстовых утверждений и графических моделей



Каталог: shared -> files -> 201211
201211 -> 1. 1 Предмет и содержание курса 2 Вопросы стандартизации систем
201211 -> Учебное пособие 10 часть Основы общей теории управления. Функциональный и процессный подходы к управлению организацией 15
201211 -> Учебное пособие Санкт-Петербург 2012
files -> Технологические подходы к разработке по [Алексеев П. С.]
files -> Статья 48. Архитектурно-строительное проектирование
files -> Программа дисциплины вычислительная геометрия Цели изучения дисциплины
files -> Методы расчета расходов на it совокупная стоимость владения


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   10   ...   18


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал