Управление качеством ПО на стадиях жизненного цикла
=1=
Под качеством проекта понимается выполнение работ по созданию продукта проекта в соответствии с согласованными требованиями заказчика или в соответствии с техническим заданием в заданные сроки и без превышения плановой сметы.
Управление качеством выполняется в течение всего жизненного цикла проекта и включает ряд типовых процессов:
1. планирование качества,
2. процесс обеспечения качества (выполнение плановых работ по качеству)
3. процесс контроля качества.
Процесс планирования качества включает определение того, какие стандарты качества применимы к проекту, и разработку способов удовлетворения их требованиям.
Цель планирования качества — удостовериться в том, что продукт/результат проекта будет соответствовать планируемым целевым показателям. В процессе планирования качества устанавливаются критерии, по которым будет измеряться продукт/результат проекта по его завершении.
Этапыпланирования качества проекта:
1. Составляется перечень измеряемых показателей качества проекта – атрибуты качества (например, требования к продукции, к компетенции членов команды и т. д.).
2. Определяются стандарты или нормативы качества, с которыми эти показатели будут сравниваться.
3. Устанавливается необходимый уровень показателей качества проекта и их измеримые границы показателя, при превышении которого необходимо предпринимать действия по корректировке качества.
4. Указываются используемые инструменты и методы, определяются ответственные лица и лица, принимающих решение о корректировке качества при его нарушении; процедуры проведения такой корректировки; даты контроля и наименование используемой документации.
Процесс обеспечения качества – это регулярная проверка хода реализации проекта, принятие плановых систематических мер, обеспечивающих выполнение всех предусмотренных процессов, необходимых для того, чтобы проект удовлетворял требованиям по качеству.
Обеспечение качества проекта связано с:
1.Качеством создаваемого продукта.
2.Обеспечением качества планирования, разработки проектной документации.
3. Качеством выполнения работ по проекту в соответствии с плановой документацией.
4.Качеством ресурсного обеспечения проекта.
Процесс контроля качества — это мониторинг результатов проекта с целью установления удовлетворяют ли они стандартам качества, и определения путей устранения причин, вызывающих неудовлетворительные результаты. Процесс контроля качества необходим, чтобы избежать последующих проблем с приемом работ заказчиком.
Принципы управления качеством проекта:
1: ориентация предприятия-разработчика на потребителя-заказчика. «Предприятия зависят от своих потребителей и, таким образом, должны понимать текущие и будущие потребности потребителей-заказчиков, удовлетворять их требования и стремиться превзойти их ожидания».
2: лидерство-руководство. «Лидеры обеспечивают единство назначения и направления деятельности предприятия. Они должны создавать и поддерживать внутреннюю окружающую среду, в которой специалисты могут в полной мере участвовать в достижении стратегических целей предприятия».
3: вовлечение персонала. «Люди составляют сущность предприятия на всех уровнях, и их полноценное участие в деятельности способствует применению их способностей на благо целей предприятия».
4: процессный подход. «Желаемый результат достигается более эффективно, когда требуемые ресурсы и деятельность специалистов предприятия управляются как единый связанный процесс».
5: системный подход к административному управлению. «Выявление и понимание задач и административное управление системой взаимосвязанных процессов для заданной стратегической цели, повышает эффективность и результативность предприятия».
6: постоянное усовершенствование. «Непрерывное усовершенствование процессов и повышение качества продукции должно быть постоянной стратегической целью предприятия и его специалистов».
7: подход к принятию решений основанный на фактах. «Эффективные решения должны базироваться на анализе только реальных данных и достоверной информации».
8: взаимовыгодные отношения с поставщиками. «Предприятие-пользователь и его поставщики-разработчики взаимозависимы, и взаимовыгодные отношения между ними повышают способность обоих производить качественную продукцию».
=2=
Атрибуты программной системы, характеризующие ее качество, измеряются с использованием метрик качества.
Метрика - это комбинация конкретного метода измерения (способа получения значений), атрибута сущности и шкалы измерения (средства, используемого для структурирования получаемых значений). (см. рисунок 3.1).
Рис. 3.1. Система измерения качества
Определение требований к качеству начинается с перечисления внешних характеристик качества, отражающих требования к 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. эксплуатационное качество – качество программной системы, измеряемое в терминах результатов ее использования, а не свойств. Пользователь оценивает только те атрибуты качества ПС, которые видны ему в ходе фактического использования, поэтому качество ПО в пользовательской среде может отличаться от качества в среде разработки из-за недоучета особенностей среды и сценариев применения программного средства и, как следствие, неадекватного тестирования.