Управление качеством Результативность IT

техническим требованиям. Здесь возникает ряд проблем:
Технические требования.
Должны

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

за процессом разработки ПО. Сам же процесс управления качеством состоит

из трех основных видов деятельности:

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

Планирование качества.
Выделение подмножества стандартов и процедур и их адаптация к
данному проекту.

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

качеством:

Контрольные проектные элементы в процессе разработки ПО являются

основой контроля качества. Это дает возможность своевременного
получения информации о проблемах и трудностях.












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

D1

D2

D3

D4

Процесс
разработки ПО

Процесс
управления
качеством

Стандарты и
процедуры

Отчеты по
контролю
качества

План
обеспечения
качества

D- контрольные проектные
элементы

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

качества ISO 9000

Руководство
Организации
по качеству

План обеспечения
качества проекта 3

План обеспечения
качества проекта 1

План обеспечения
качества проекта 2

Процесс обеспечения
качества

Управление
качеством проекта

Существуют
в виде

документация

Используется для создания

Существует в виде

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

стандарты на сопроводительную документацию. Применимы к готовым продуктам.
Стандарты на процесс создания ПО.
Определяют ход процесса создания программного продукта.

стандартов. Описание стандартов должно содержать
не

только изложение норматива качества, но и
объяснение необходимости выбора именно его.

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

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

легко читать и воспринимать.
Выделяют три основные типа стандартов на документацию:

1.

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

2. Стандарты на документ.
Определяют структуру и внешний вид.

3. Стандарты на обмен документами.
Гарантируют совместимость всех электронных версий документов.

наиболее подходящие
к создаваемому ПО. Предлагается следующая структура плана:

Представление продукта.

Описание продукта, намечаемый рынок его сбыта, а также ожидаемые
свойства.
Планы выпуска продукта.
Назначение крайних сроков выпуска версий программного продукта,
распределение ответственности за его разработку и обслуживание.
3.     Описания процессов.
Представление процессов разработки и обслуживания программного
продукта в ходе выполнения проекта и управления им.
4.     Цели качества.
Планы и цели обеспечения качества продукта, включая описание наиболее
важных его характеристик.
5.     Риски и управление рисками.
Описание основных видов риска, которые могут оказать влияние на
уровень качества продукта, и мероприятия, направленные на снижение рисков.

могут быть использованы в процессе разработки ПО. Они должны иметь

четкую структуру.

Выделяют два взаимодополняющих подхода к процессу контроля качества:

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

2. Программный продукт и его документация проверяется специальной компьютерной программой на его соответствие стандарту.

Контроль качества

процесс разработки в целом. В таблице представлены некоторые типы проверок.
Проверки

качества

программного продукта или процесса его
разработки.

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

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

Показатели делятся на два вида: контрольные и
прогнозируемые. Контрольные показатели обычно
соотносятся с процессом разработки ПО, а прогнозируемые
- с готовым программным продуктом.

качества, показан на рисунке.

показателей для измерения.
Определяются измеряемые показатели
2.   

Отбор системных компонентов.
Часто совсем необязательно оценивать показатели всех компонентов программной системы.
3.   Измерение показателей компонентов.
Это процесс измерения значений выбранных показателей для отобранных компонентов.
4.   Определение аномальных данных.
Значения измеренных показателей нужно сравнить между собой и с предыдущими измерениями, занесенными в базу данных.
5.   Анализ аномальных компонентов.
Определив компоненты с аномальными показателями, их следует
изучить для выявления возможного отрицательного влияния на качество программного продукта в целом

1. Динамические показатели, которые измеряются в процессе
выполнения

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

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

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

ли она тех, для кого предназначена?
Какой ценой, т.е. за счет расхода каких ресурсов это достигается?
В какой мере опыт ведения конкретного проекта может распространяться на другие проекты?
Внутренний и внешний аспекты (по отношению к проекту) показателей результативности
Результативность — оценочная, но не только итоговая характеристика проекта
Способность компании организовывать результативные процессы разработки проектов → понятие уровней зрелости компании

ходе развития проекта
Познаваемость продукта — необходимо, чтобы пользователь продукта был

в состоянии понимать:
что можно получать, используя предлагаемую систему, документацию и пр.
чего нельзя ожидать от них
как активизировать функции системы,
как трактовать (для применения) получаемые результаты;
Познаваемость процесса разработки продукта — необходимо, чтобы разработчики были в состоянии:
развивать проект,
принимать согласованные решения,
сбалансированно выполнять коллективную работу.
Программные результаты
предлагаемая пользователю система
сопутствующие инструменты
демонстрации и др.
Документные результаты
Что это за документы?
Могут ли и должны ли они использоваться за пределами проекта?
Как минимизировать затраты на их производство?

программного продукта; только он в состоянии давать адресные и самые

квалифицированные консультации, конструктивно отвечать на вопросы пользователей
Документация — это заместитель разработчика при используемой программе →
Критерий качества документации: она тем лучше, чем точнее имитирует непосредственное взаимодействие разработчиков с пользователями
В разных ситуациях использования требуются различные консультации и разъяснения → и разные варианты документов (в частности: система помощи не заменяет документацию!)
Виды рабочих продуктов проекта в первом приближении:
Программные продукты: целевая программная система, компоненты ПО для внешнего применения (библиотеки, библиотеки классов и др.), инструменты, появляющиеся в рамках проекта для тех или иных целей (например, для построения специальных структур данных);
Документы для пользователей — все бумажные и электронные текстовые материалы (возможно, с рисунками, схемами и т.д.);
Документы для сопровождения и развития — для поддержки работ, связанных с обслуживанием пользователей программного продукта.

НЕТ!
Это лишь первая группа — целевые продукты
Вторая группа —

продукты, отражающие процесс развития проекта:
Планы, контрольные мероприятия и другие материалы, с помощью которых осуществляется управление развитием проекта;
Задания, отчеты об их выполнении, технические предложения и другие материалы, формирующие процесс выполнения проекта как коллективную деятельность;
Соглашения, правила и регламенты коммуникаций между разработчиками, которые используются в ходе выполнения проекта.
Третья группа — продукты, отражающих наблюдение за проектом:
Сведения об оценивании развития целевых продуктов. Результаты оценочной деятельности полезны не только для данного проекта, но и, например, для принятия решений в аналогичных ситуациях в будущем. Это возможно, если оценочные сведения надлежащим образом оформлены документально;
Сведения об измерениях целевых продуктов в их развитии. Они отражают различные аспекты качества продукта. Оформленные в виде продукта, используются как инструмент управления и в иных, не зависящих от проекта целях;
Сведения о наблюдении за процессами производства, сопровождения и поддержки. Показатели, полезные для управляемого развития процесса, могут использоваться и без непосредственной связи с данным проектом (опытные данные, например, в качестве основы классификации проектов;
Сведения о распространении продуктов. Как распространяются продукты проекта, могут ли применяться не только для работ фазы использования, но и в других целях. Сравнения их с первоначальными гипотезами → выводы о качестве прогноза и предварительной оценки конкурентоспособности продукта.
Необходимость планирования ресурсов для оформления рабочих продуктов!

нужно иметь возможность убедиться в этом → на уровень рабочих

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

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

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

работы с подобными проектами
Возможность воспроизведения успешных практик прежних проектов
Если в

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

проведения разработки и сопровождения программного обеспечения, в рамках которого обеспечена

интеграция процессов построения и управления.
Разработка и сопровождение полностью документированы, что позволяет организовать наблюдение и контроль выполнения проектов. (в CMM такой стандарт называется стандартным производственным процессом организации)
Для конкретных проектов стандартный производственный процесс адаптируется с целью учета его особенностей:
определяются критерии готовности, качества и т.д., а также механизмы контроля.
Руководство получает точную картину развития проектов
Продуктивность производственного процесса характеризуется как стандартная и согласованная.
К рабочим продуктам каждой из групп предъявляются требования:
они должны быть представлены таким образом, чтобы специфика проекта явно отделялась от стандартизованного содержания, то есть чтобы при производстве рабочих продуктов максимально повышалась возможность их независимого от проекта применения

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

процессы оснащены средствами для проведения четко определенных и согласованных измерений
Продуктивность производственного процесса характеризуется как предсказуемая (процесс функционирует в заданных и измеряемых пределах)
Предполагается, что за счет количественных показателей качества удается организовать наблюдение за любой проектной деятельностью, которое позволяет удерживать траекторию в области допустимости.
Дополнительные требования к рабочим продуктам этого уровня:
конкретизируется и получает статус обязательного стандарта группы продуктов, отражающих процесс развития проекта, а также измерения и наблюдение за проектом.
Количественные показатели и измерения полезны для оценки результативности. Но что и как нужно измерять? Попытки ответить так, чтобы в показателях качество отражалось с функциональной точностью к ощутимым результатам не привели. Неудачи обычно связывают с тем, что
понятие «качество» не определено строго
оно меняется от методологии к методологии
субъективная составляющая качества превалирует над объективной.
Но причины глубже и принципиальнее: коренные причины проблем количественных показателей обусловлены существенной креативностью программистской деятельности, а надежных критериев качества любой деятельности такого рода просто не существует.
Вместо точных измерений в практике прибегают к оценкам, что зачастую (но далеко не всегда!) оказывается достаточным

уровне, но организация сосредоточена на усовершенствовании производственного процесса.
Есть средства

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

принятым подходом, берет обязательства продвигаться вверх по лестнице развития зрелости
Эволюция

представления о том, какими должны быть рабочие продукты
Критика: стремление втиснуть все схемы менеджмента в прокрустово ложе унифицированных процедур слежения за развитием проектов с помощью раз и навсегда «хорошо себя зарекомендовавших» практик

проекты, в которых уделяется внимание сопутствующим продуктам. Отсюда впечатление о

причинно-следственной связи, зависимости успешности от дополнительных продуктов
Стремление к технологизации на основе опыта (+ возможность «объективного» сравнения → независимого контроля)

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

процесса:
Искушение распространения удачного опыта за пределы его области применимости
Многие методы

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