Тема 8: Управление качеством it-проекта.

1. Понятие, процессы и принципы управления качеством it-проекта

2. Система измерения качества it-проекта: метрики качества.

3. Управление качеством по на стадиях жизненного цикла

=1=

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

Управление качеством выполняется в течение всего жизненного цикла проекта и включает ряд типовых процессов:

1. планиро­вание качества,

2. процесс обеспечения качества (выполнение плановых работ по качеству)

3. процесс контроля качества.

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

Цель планирования качества — удостовериться в том, что продукт/результат проекта будет соответство­вать планируемым целевым показателям. В процессе планирования качества устанавливаются критерии, по которым будет измеряться продукт/результат проекта по его завершении.

Этапы планирования качества проекта:

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

2. Определяются стандарты или нормативы качества, с которыми эти показатели будут сравниваться.

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

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

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

Обеспечение качества проекта связано с:

1. Качеством создаваемого продукта.

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

3. Качеством выполнения работ по проекту в соответствии с плановой доку­ментацией.

4. Качеством ресурсного обеспечения проекта.

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

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

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

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

3: вовлечение персонала. «Люди составляют сущность предприятия на всех уровнях, и их полноценное участие в деятельности способствует применению их способностей на благо целей предприятия».

4: процессный подход. «Желаемый результат достигается более эффективно, когда требуемые ресурсы и деятельность специалистов предприятия управляются как единый связанный процесс».

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

6: постоянное усовершенствование. «Непрерывное усовершенствование процессов и повышение качества продукции должно быть постоянной стратегической целью предприятия и его специалистов».

7: подход к принятию решений основанный на фактах. «Эффективные решения должны базироваться на анализе только реальных данных и достоверной информации».

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

=2=

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

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

Определение требований к качеству начинается с перечисления внешних характеристик качества, отражающих требования к IT-проекту. Далее выбираются внешние измеримые свойства (внешние атрибуты) IT-проекта, связанные с ними метрики и приемлемые диапазоны изменения значений (мер).

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

Аналогично определяются внутренние характеристики, атрибуты и метрики качества - это те, которые связаны с не работающими на компьютере рабочими продуктами ПС (документами, текстами кода, тестами и др.), получаемыми на стадиях разработки, предшествующих тестированию (определение требований, проектирование, кодирование).

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

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

1. категорийные (описательные (номинальные) - используются для оценки функциональных возможностей программных средств;

2. количественные - применимы для измерения надежности и эффективности сложных комплексов программ;

3. качественные - соответствуют практичности, сопровождаемости и мобильности программных средств.

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

Табл. 3.1. Характеристики качества программного обеспечения

1. Функциональные возможности1 - способность ПО реализовать установленные или предполагаемые потребности пользователей
Пригодность для применения по назначению	Наличие и соответствие набора функций конкретным задачам
Правильность/корректность реализации требований2	Способность программного обеспечения обеспечивать правильность (или соответствие) результатов
Способность к взаимодействию с компонентами и средой3	Способность ПО взаимодействовать с конкретными системами
Согласованность	Способность ПО придерживаться соответствующих стандартов или соглашений, или подробных рекомендаций
Защищенность/безопасность функционирования	Способность ПО предотвращать несанкционированный доступ (случайный или преднамеренный) к программам и данным
2. Надежность4 - способность программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный период времени
Стабильность/уровень завершенности	Характеризуется частотой отказов, вызванных наличием ошибок в ПО
Устойчивость к ошибке	Способность ПО поддерживать определенный уровень качества функционирования в случаях программных ошибок
Восстанавливаемость после проявления дефектов5	Способность ПО восстанавливать уровень качества функционирования и данные, непосредственно поврежденные в случае отказа. Характеризуется необходимыми для этого затратами усилий и времени
3. Практичность6 - характеризуется объемом работ, требуемых для использования программного обеспечения определенным или предполагаемым кругом пользователей
Понятность функций и документации	Характеризует усилия пользователя по пониманию общей логической концепции ПО и его применимости
Изучаемость процессов функционирования и применения	Характеризует усилия пользователя по обучению применению ПО (например, оперативному управлению, вводу, выводу)
Простота использования	Характеризует усилия пользователя по эксплуатации и оперативному управлению ПО
4. Эффективность 7 - определяется соотношением между уровнем качества функционирования программного обеспечения и объемом используемых ресурсов при установленных условиях
Временная эффективность реализации комплекса программ	Характеризуется временем отклика и скоростью выполнения функций
Используемость вычислительных ресурсов	Характеризуется объемом используемых ресурсов и продолжительностью использования ПО при выполнении функции
5. Сопровождаемость8 - характеризует объем работ, требуемых для проведения конкретных изменений
Анализируемость	Характеризует усилия, необходимые для диагностики недостатков или случаев отказов или определения составных частей для модернизации
Изменяемость компонентов и комплекса программ	Характеризует усилия, необходимые для модификации, устранения отказа или для изменения условий эксплуатации
Устойчивость	Характеризует риск от непредвиденных эффектов модификации
Тестируемость изменений при сопровождении	Характеризует усилия, необходимые для проверки модифицированного программного обеспечения
6. Мобильность9 - способность программного обеспечения быть перенесенным из одного окружения в другое
Адаптируемость к изменениям среды	Характеризует удобство адаптации ПО к различным конкретным условиям эксплуатации, без применения других действий или способов, кроме тех, что предназначены для этого в рассматриваемом программном обеспечении
Простота установки /внедрения/ инсталляции после переноса	Характеризует усилия, необходимые для внедрения программного обеспечения в конкретное окружение
Соответствие	Способность программного обеспечения подчиняться стандартам или соглашениям, относящимся к мобильности
Взаимозаменяемость компонентов при корректировке комплекса программ10	Характеризует простоту и трудоемкость применения данного ПО вместо другого конкретного программного средства в среде этого средства

=3=

Стандарт ISO/IEC 9126 предлагает варьировать взгляды на качество продукта по стадиям ЖЦ следующим образом:

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

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

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

4. оцененное (или прогнозируемое) качество продукта – качество, которое оценивается или предсказывается как качество конечного программного продукта на каждой стадии разработки на основании характеристик качества программного проекта.

5. качество поставляемого продукта – это качество готового к поставке продукта, как правило, протестированного в моделируемой среде на моделируемых данных.

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