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

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

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

4. Стандарты и модели качества программного обеспечения: Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE).

=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. качественные - соответствуют практичности, сопровождаемости и мобильности программных средств.

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

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

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

=4=

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

В начале 90-х годов появились ряд новых стандартов и методологий. Примерами наиболее удачных и содержательных стандартов могут служить

- Capability Maturity Model (CMM)

- ISO/IEC 15504 (SPICE).

Capability Maturity Model (1991 год, американский институт программной инженерии SEI при университете Карнеги-Меллон)

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

Базовым понятием модели СММ считается зрелость компании-разработчика. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются «на ходу». В зрелой компании работают ясные процедуры управления проектами и построения программных продуктов.

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

Рис. -Пять уровней зрелости в модели CMM.

Начальный уровень (initial level) - это основа для сравнения со следующими уровнями. Характеризуется фактическим отсутствием в компании стабильных условий для создания качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект.

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

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

На управляемом уровне (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от предыдущего уровня состоит в более объективной, количественной оценке продукта и процесса. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.

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

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

При сертификации проводится оценка соответствия всех ключевых областей по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям:

1. Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.).

2. Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение).

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

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

К сожалению, использование CMM затрудняют следующие проблемы:

- стандарт CMM является собственностью Software Engineering Institute и не является общедоступным (в частности, дальнейшая разработка стандарта ведется самим институтом, без заметного влияния остальной части программистского сообщества);

- оценка качества процессов организаций может проводиться только специалистами, прошедшими специальное обучение и аккредитованными SEI;

- стандарт ориентирован на применение в относительно крупных компаниях.

ISO/IEC 15504 (SPICE) (1991 год, Международная организация по стандартизации инициировала работу по созданию единого стандарта оценки программных процессов )

Стандарт получил имя SPICE (сокращение от Software Process Improvement and Capability Etermination, определение возможностей и улучшение процесса создания программного обеспечения). Официально стандарт называется ISO/IEC 15504: Information Technology - Software Process Assessment и на данный момент существует в качестве рабочей версии, последний выпуск которой состоялся в мае 1998 года.

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

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

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

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

3. Улучшение процесса. После этого весь цикл работ начинается сначала.

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

Одним из важных достоинств SPICE является его открытость и свободное распространение.

И CMM, и SPICE на сегодняшний день представляют наиболее развитые модели качества, прошедшие применение на практике. Они я являются серьезной альтернативой для ISO 9000-9004. Соответствие стандарту - не только свидетельство достижения некоторого уровня качества, но и способ реального улучшения существующих в организации процессов разработки ПО.

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

Дата добавления: 2013-12-13