современные модели качества программного обеспечения

42
Современные модели Современные модели качества программного качества программного обеспечения обеспечения

Upload: cezium

Post on 16-Jun-2015

1.319 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: современные модели качества программного обеспечения

Современные модели Современные модели качества программного качества программного

обеспеченияобеспечения

Page 2: современные модели качества программного обеспечения

Современная индустрия программного Современная индустрия программного обеспечения (ПО) характеризуется очень обеспечения (ПО) характеризуется очень высокой степенью конкуренции. Для высокой степенью конкуренции. Для успешной работы на этом рынке компания успешной работы на этом рынке компания должна разрабатывать, внедрять и должна разрабатывать, внедрять и сопровождать программное обеспечение сопровождать программное обеспечение быстро, в срок и с удовлетворительным быстро, в срок и с удовлетворительным качеством. Поэтому многие компании качеством. Поэтому многие компании вкладывают деньги в улучшение качества вкладывают деньги в улучшение качества процесса, памятуя о том, что подобное процесса, памятуя о том, что подобное вложение денег обязательно окупается – вложение денег обязательно окупается – изучение документированных случаев изучение документированных случаев улучшения процессов разработки ПО улучшения процессов разработки ПО показывает, что в успешных случаях показывает, что в успешных случаях наблюдается существенное улучшение наблюдается существенное улучшение производительности и качества со средним производительности и качества со средним уровнем возврата вложений от 5:1 до 8:1 [1]. уровнем возврата вложений от 5:1 до 8:1 [1].

Page 3: современные модели качества программного обеспечения

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

Однако время не стоит на месте, и методики, положенные Однако время не стоит на месте, и методики, положенные в основу стандартов серии ISO 9000, постепенно в основу стандартов серии ISO 9000, постепенно устаревают. Выделим наиболее существенные устаревают. Выделим наиболее существенные недостатки: недостатки: • недостаточная подробность стандарта, возможность недостаточная подробность стандарта, возможность

самых различных его толкований в зависимости от самых различных его толкований в зависимости от представлений аудитора; представлений аудитора;

• неточность оценки качества процессов, задействованных неточность оценки качества процессов, задействованных при создании и внедрении программного обеспечения; при создании и внедрении программного обеспечения;

• отсутствие в стандарте механизмов, способствующих отсутствие в стандарте механизмов, способствующих улучшению существующих процессов. улучшению существующих процессов.

Page 4: современные модели качества программного обеспечения

Перечисленные проблемы заставили экспертов Перечисленные проблемы заставили экспертов разрабатывать более совершенные решения в области разрабатывать более совершенные решения в области обеспечения качества, что привело к созданию в обеспечения качества, что привело к созданию в начале 90-х годов целого ряда новых стандартов и начале 90-х годов целого ряда новых стандартов и методологий. В данной статье мы опишем два наиболее методологий. В данной статье мы опишем два наиболее удачных и содержательных стандарта – Capability удачных и содержательных стандарта – Capability Maturity Model (CMM) и ISO/IEC 15504 (SPICE). Maturity Model (CMM) и ISO/IEC 15504 (SPICE). Существуют и другие достаточно развитые Существуют и другие достаточно развитые методологии, но, к сожалению, невозможно осветить методологии, но, к сожалению, невозможно осветить все перспективные направления данной области в все перспективные направления данной области в рамках одной статьи. Поэтому мы ограничимся рамках одной статьи. Поэтому мы ограничимся упоминанием того, что за рамками данного обзора упоминанием того, что за рамками данного обзора остались такие стандарты, как Bootstrap, во многом остались такие стандарты, как Bootstrap, во многом схожий с рассматриваемыми станадртами CMM и SPICE, схожий с рассматриваемыми станадртами CMM и SPICE, Trillium, ориентированный на разработку продуктов в Trillium, ориентированный на разработку продуктов в области телекоммуникаций и ISO 12207, посвященный области телекоммуникаций и ISO 12207, посвященный жизненному циклу программного обеспечения. жизненному циклу программного обеспечения. На протяжении всей статьи мы будем проводить На протяжении всей статьи мы будем проводить параллели между двумя рассматриваемыми параллели между двумя рассматриваемыми стандартами и ISO 9001, чтобы подчеркнуть сходства и стандартами и ISO 9001, чтобы подчеркнуть сходства и различия между ними. различия между ними.

Page 5: современные модели качества программного обеспечения

Capability Maturity ModelCapability Maturity Model Официальная история CMM (Официальная история CMM (CCapability apability MMaturity aturity MModel, что обычно odel, что обычно

переводят как "модель зрелости процесса разработки ПО", переводят как "модель зрелости процесса разработки ПО", хотя более верным по смыслу был бы перевод "модель хотя более верным по смыслу был бы перевод "модель совершенствования возможностей") начинается в 1991 году, совершенствования возможностей") начинается в 1991 году, когда американский институт SEI (Software Engineering когда американский институт SEI (Software Engineering Institute – Институт системного программирования при Institute – Институт системного программирования при университете Карнеги-Меллон) опубликовал первую версию университете Карнеги-Меллон) опубликовал первую версию этого стандарта. этого стандарта.

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

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

Page 6: современные модели качества программного обеспечения

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

Page 7: современные модели качества программного обеспечения

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

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

Page 8: современные модели качества программного обеспечения

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

Page 9: современные модели качества программного обеспечения

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

Page 10: современные модели качества программного обеспечения

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

Page 11: современные модели качества программного обеспечения

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

Page 12: современные модели качества программного обеспечения

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

Page 13: современные модели качества программного обеспечения

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

Page 14: современные модели качества программного обеспечения

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

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

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

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

Page 15: современные модели качества программного обеспечения

В принципе, можно сертифицировать только В принципе, можно сертифицировать только один процесс или подразделение один процесс или подразделение организации, например, подразделение организации, например, подразделение разработки программного обеспечения разработки программного обеспечения компании IBM сертифицировано на пятый компании IBM сертифицировано на пятый уровень. Кстати, в мире существует совсем уровень. Кстати, в мире существует совсем немного компаний, которые могут немного компаний, которые могут похвастаться наличием у них пятого уровня похвастаться наличием у них пятого уровня CMM хотя бы в одном из подразделений – CMM хотя бы в одном из подразделений – таких всего около 50. С другой стороны, таких всего около 50. С другой стороны, насчитывается несколько тысяч компаний, насчитывается несколько тысяч компаний, сертифицированных по 3 или 4 уровню, то сертифицированных по 3 или 4 уровню, то есть существует колоссальный разрыв между есть существует колоссальный разрыв между оптимизированным уровнем зрелости и оптимизированным уровнем зрелости и предыдущими уровнями. Однако еще больший предыдущими уровнями. Однако еще больший разрыв наблюдается между количеством разрыв наблюдается между количеством организаций начального уровня и числом их организаций начального уровня и числом их более продвинутых собратьев – по некоторым более продвинутых собратьев – по некоторым оценкам, свыше 70% всех компаний-оценкам, свыше 70% всех компаний-разработчиков находится на первом уровне разработчиков находится на первом уровне CMM [2]. CMM [2].

Page 16: современные модели качества программного обеспечения

Интересен вопрос о соотношении уровней CMM Интересен вопрос о соотношении уровней CMM со стандартом ISO 9001: на каком уровне CMM со стандартом ISO 9001: на каком уровне CMM должна находиться организация, чтобы должна находиться организация, чтобы получить сертификат соответствия ISO 9001? получить сертификат соответствия ISO 9001? На первый взгляд, для этого необходимо На первый взгляд, для этого необходимо иметь как минимум 3 или 4 уровень CMM. Тем иметь как минимум 3 или 4 уровень CMM. Тем не менее, существуют примеры организаций не менее, существуют примеры организаций 1-го уровня, имеющих сертификат ISO 9001. 1-го уровня, имеющих сертификат ISO 9001. Одной из причин для возникновения подобных Одной из причин для возникновения подобных несуразиц является высокий уровень несуразиц является высокий уровень абстракции ISO 9001 и связанная с этим абстракции ISO 9001 и связанная с этим свобода его интерпретации аудитором. свобода его интерпретации аудитором. Иногда, как это ни странно, аудиторам не Иногда, как это ни странно, аудиторам не хватает элементарного знакомства с реальной хватает элементарного знакомства с реальной практикой разработки программ. практикой разработки программ.

Page 17: современные модели качества программного обеспечения

Некоторые важные вопросы, например, Некоторые важные вопросы, например, отбор, повышение квалификации и отбор, повышение квалификации и сохранение компетентных сотрудников, сохранение компетентных сотрудников, остались за рамками CMM. Тем не остались за рамками CMM. Тем не менее, эти вопросы исключительно менее, эти вопросы исключительно важны, ибо как замечено в статье [4] "и важны, ибо как замечено в статье [4] "и 20-30 лет назад было известно, что два 20-30 лет назад было известно, что два программиста, сидящих за соседними программиста, сидящих за соседними столами и получающих примерно столами и получающих примерно одинаковую зарплату, могут писать одинаковую зарплату, могут писать программы, отличающиеся по скорости программы, отличающиеся по скорости счета, скажем, в 10 раз". Кстати, счета, скажем, в 10 раз". Кстати, ситуация в России еще сложнее по ситуация в России еще сложнее по сравнению с западными странами – сравнению с западными странами – российские программисты могут не российские программисты могут не только перейти на другую работу, но и только перейти на другую работу, но и переехать в другую страну с более переехать в другую страну с более высоким уровнем зарплаты! высоким уровнем зарплаты!

Page 18: современные модели качества программного обеспечения

Естественно, особенно важен подбор Естественно, особенно важен подбор сотрудников для организаций первого сотрудников для организаций первого уровня, так как сотрудники для них уровня, так как сотрудники для них являются единственной гарантией являются единственной гарантией качества. Но и на более высоких качества. Но и на более высоких уровнях зрелости "человеческий уровнях зрелости "человеческий фактор" сохраняет свою значимость. фактор" сохраняет свою значимость. Поэтому в 1995 году был опубликован Поэтому в 1995 году был опубликован стандарт People CMM, являющийся стандарт People CMM, являющийся дополнением к Software CMM и дополнением к Software CMM и имеющий, в целом, похожую структуру. имеющий, в целом, похожую структуру. Внедрение этого стандарта Внедрение этого стандарта параллельно с обычным CMM параллельно с обычным CMM обеспечивает организацию целым обеспечивает организацию целым набором процедур по оценке и набором процедур по оценке и развитию всей системы найма, развитию всей системы найма, обучения и сохранения обучения и сохранения квалифицированных сотрудников. квалифицированных сотрудников.

Page 19: современные модели качества программного обеспечения

Кроме People CMM, возникло еще несколько Кроме People CMM, возникло еще несколько моделей, дополняющих CMM, например, в моделей, дополняющих CMM, например, в приобретении ПО или разработке крупных приобретении ПО или разработке крупных систем. В целях полной интеграции этих систем. В целях полной интеграции этих моделей и снижения общих затрат по их моделей и снижения общих затрат по их внедрению, был предпринят проект CMM внедрению, был предпринят проект CMM Integration (ради его выполнения в 1998 году Integration (ради его выполнения в 1998 году был даже отменен выпуск CMM версии 2.0). был даже отменен выпуск CMM версии 2.0).

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

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

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

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

Page 20: современные модели качества программного обеспечения

SPICESPICE В 1991 году Международная организация по В 1991 году Международная организация по

стандартизации инициировала работу по стандартизации инициировала работу по созданию единого стандарта оценки созданию единого стандарта оценки программных процессов. Стандарт получил имя программных процессов. Стандарт получил имя SPICE (сокращение от SPICE (сокращение от SSoftware oftware PProcess rocess IImprovement and mprovement and CCapability dapability dEEtermination, termination, определение возможностей и улучшение определение возможностей и улучшение процесса создания программного обеспечения). процесса создания программного обеспечения). Официально стандарт называется "ISO/IEC Официально стандарт называется "ISO/IEC 15504: Information Technology - Software Process 15504: Information Technology - Software Process Assessment" и на данный момент существует в Assessment" и на данный момент существует в качестве рабочей версии, последний выпуск качестве рабочей версии, последний выпуск которой состоялся в мае 1998 года. которой состоялся в мае 1998 года.

Задачей SPICE является создание международного Задачей SPICE является создание международного стандарта, в котором был бы учтен весь стандарта, в котором был бы учтен весь накопленный опыт в области разработки ПО. На накопленный опыт в области разработки ПО. На рисунке 2 показаны наиболее значительные рисунке 2 показаны наиболее значительные стандарты, идеи которых были использованы стандарты, идеи которых были использованы при создании SPICE: при создании SPICE:

Page 21: современные модели качества программного обеспечения

Рисунок 2. Предшественники стандарта SPICE.Рисунок 2. Предшественники стандарта SPICE.

Page 22: современные модели качества программного обеспечения

Итак, стандарт SPICE унаследовал Итак, стандарт SPICE унаследовал многие черты более ранних многие черты более ранних стандартов, в том числе и уже стандартов, в том числе и уже упоминавшихся ISO 9001 и CMM. упоминавшихся ISO 9001 и CMM. Для этого пришлось прибегнуть к Для этого пришлось прибегнуть к повышению уровня детализации повышению уровня детализации стандарта. Следствием такого стандарта. Следствием такого основательного подхода является основательного подхода является большой объем стандарта: большой объем стандарта: документация к нему содержит документация к нему содержит около 500 страниц! около 500 страниц!

Page 23: современные модели качества программного обеспечения

Больше всего SPICE напоминает CMM. Точно так Больше всего SPICE напоминает CMM. Точно так же, как и в CMM, основной задачей же, как и в CMM, основной задачей организации является постоянное улучшение организации является постоянное улучшение процесса разработки ПО. Кроме того, в SPICE процесса разработки ПО. Кроме того, в SPICE тоже используется схема с различными тоже используется схема с различными уровнями возможностей (в SPICE определено 6 уровнями возможностей (в SPICE определено 6 различных уровней), но эти уровни различных уровней), но эти уровни применяются не только к организации в применяются не только к организации в целом, но и к отдельно взятым процессам. В целом, но и к отдельно взятым процессам. В таблице 1, заимствованной из статьи [6], таблице 1, заимствованной из статьи [6], приведен список уровней способностей приведен список уровней способностей модели SPICE и характерные для них модели SPICE и характерные для них процедуры управления. Отметим, что на процедуры управления. Отметим, что на данный момент не существует русского данный момент не существует русского перевода стандарта SPICE, поэтому перевода стандарта SPICE, поэтому использованные термины не являются использованные термины не являются общепринятыми или официально общепринятыми или официально зарегистрированными зарегистрированными

Page 24: современные модели качества программного обеспечения

Таблица 1. Уровни способностей процесса в стандарте Таблица 1. Уровни способностей процесса в стандарте SPICESPICE Уровни Название

Уровень 0 Процесс не выполняется

Уровень 1 Выполняемый процесс

1.1 Измерение производительности процесса

Уровень 2 Управляемый процесс

2.1 Управление производительностью

2.2 Управление созданием продуктов

Уровень 3 Установленный процесс

3.1 Документирование процесса

3.2 Отслеживание ресурсов процесса

Уровень 4 Предсказуемый процесс

4.1 Измерение процесса

4.2 Управление процессом

Уровень 5 Оптимизирующий процесс

5.1 Изменение процесса

5.2 Постоянное совершенствование

Page 25: современные модели качества программного обеспечения

Таким образом, процессы в модели SPICE могут быть представлены Таким образом, процессы в модели SPICE могут быть представлены следующим образом: следующим образом:

Рисунок 3. Упрощенная модель оценки процессов в стандарте SPICE.Рисунок 3. Упрощенная модель оценки процессов в стандарте SPICE.

Здесь Pn обозначает процессы, а CL (Capability Levels) обозначает уровни Здесь Pn обозначает процессы, а CL (Capability Levels) обозначает уровни

способностей этих процессов.способностей этих процессов.

Page 26: современные модели качества программного обеспечения

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

Page 27: современные модели качества программного обеспечения

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

выполняются следующие задачи (см. рисунок 4):выполняются следующие задачи (см. рисунок 4):

Рисунок 4. Основные элементы стандарта Рисунок 4. Основные элементы стандарта SPICE.SPICE.

Page 28: современные модели качества программного обеспечения

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

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

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

Page 29: современные модели качества программного обеспечения

Скажем несколько слов о структуре Скажем несколько слов о структуре документации по стандарту SPICE. Набор документации по стандарту SPICE. Набор документов по SPICE состоит из 9 частей. документов по SPICE состоит из 9 частей. Первая часть "Введение и основные Первая часть "Введение и основные концепции" и девятая часть "Словарь" носят концепции" и девятая часть "Словарь" носят чисто информативный характер. Самым чисто информативный характер. Самым важным элементом SPICE является оценка важным элементом SPICE является оценка процессов, поэтому ей посвящена наибольшая процессов, поэтому ей посвящена наибольшая часть документов, а именно части со второй часть документов, а именно части со второй по шестую. Например, вторая часть стандарта по шестую. Например, вторая часть стандарта содержит так называемую "эталонную содержит так называемую "эталонную модель" (reference model), которая описывает модель" (reference model), которая описывает процессы. Практически, это модель процессов процессы. Практически, это модель процессов из ISO 12297, хотя, к сожалению, эти модели из ISO 12297, хотя, к сожалению, эти модели не полностью идентичны. Результаты оценки не полностью идентичны. Результаты оценки процессов с помощью SPICE выглядят процессов с помощью SPICE выглядят достаточно сложно и потому требуют достаточно сложно и потому требуют некоторого упрощения для понимания некоторого упрощения для понимания неподготовленным человеком (например, неподготовленным человеком (например, такое упрощение было проделано при такое упрощение было проделано при создании рисунка 3). создании рисунка 3).

Page 30: современные модели качества программного обеспечения

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

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

Page 31: современные модели качества программного обеспечения

В таблице 2 кратко сформулированы преимущества SPICE по сравнению с ISO 9001.В таблице 2 кратко сформулированы преимущества SPICE по сравнению с ISO 9001. SPICE ISO 9001

Объемный и подробный документ Краткий документ

Детальная модель Абстрактная модель

Улучшение процесса и определение возможностей

Только сертификация

Шесть уровней возможностей процессов

Сертификация/отказ

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

Только модель

Дополняет ISO 9001Может быть детализирован с

помощью SPICE

Page 32: современные модели качества программного обеспечения

SPICE предоставляет более полный набор средств по SPICE предоставляет более полный набор средств по обеспечению качества и улучшению процессов, чем ISO обеспечению качества и улучшению процессов, чем ISO 9001. Поэтому для обеспечения качества процессов 9001. Поэтому для обеспечения качества процессов разработки ПО мы рекомендуем использовать именно разработки ПО мы рекомендуем использовать именно SPICE. Это поможет организации заметно улучшить SPICE. Это поможет организации заметно улучшить существующие процессы, а затем при необходимости существующие процессы, а затем при необходимости получить и сертификат ISO 9001. Накопленный опыт получить и сертификат ISO 9001. Накопленный опыт решения проблемы качества по такой схеме отражен в решения проблемы качества по такой схеме отражен в статье [7] (в частности, в ней сформулирован набор статье [7] (в частности, в ней сформулирован набор минимальных требований к различным процессам в минимальных требований к различным процессам в организации согласно модели SPICE, достаточный для организации согласно модели SPICE, достаточный для получения сертификата ISO 9001). получения сертификата ISO 9001).

Использовать SPICE можно и в небольших компаниях – об Использовать SPICE можно и в небольших компаниях – об этом свидетельствуют результаты работы проекта этом свидетельствуют результаты работы проекта SPIRE, в рамках которого проводилось внедрение SPIRE, в рамках которого проводилось внедрение процессов улучшения качества в малых (менее 50 процессов улучшения качества в малых (менее 50 человек) компаниях из различных стран Европы. Как человек) компаниях из различных стран Европы. Как показал этот опыт, и при небольших денежных показал этот опыт, и при небольших денежных вложениях в маленьких компаниях можно добиться вложениях в маленьких компаниях можно добиться существенного увеличения производительности труда существенного увеличения производительности труда и улучшения качества произведенных продуктов.и улучшения качества произведенных продуктов.

Page 33: современные модели качества программного обеспечения

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

В России стандарт SPICE пока еще делает только В России стандарт SPICE пока еще делает только самые первые шаги. В октябре 1997 года в самые первые шаги. В октябре 1997 года в Санкт-Петербурге состоялся первый семинар, Санкт-Петербурге состоялся первый семинар, посвященный SPICE. Его организатором посвященный SPICE. Его организатором выступили финские компании SEC Oy и STTF выступили финские компании SEC Oy и STTF Oy. С тех пор семинары по SPICE в Санкт-Oy. С тех пор семинары по SPICE в Санкт-Петербурге проводятся этими компаниями не Петербурге проводятся этими компаниями не реже двух раз в год. реже двух раз в год.

Page 34: современные модели качества программного обеспечения

ЗаключениеЗаключение

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

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

Page 35: современные модели качества программного обеспечения

ГлоссарийГлоссарий: :

Page 36: современные модели качества программного обеспечения

Возможность процесса разработки ПОВозможность процесса разработки ПО (software process (software process capability) описывает ожидаемый результат, который можно capability) описывает ожидаемый результат, который можно достигнуть, следуя достигнуть, следуя процессу разработкипроцессу разработки. .

Зрелость процесса разработки ПО (software process Зрелость процесса разработки ПО (software process maturity)maturity) – это степень определенности, управляемости, – это степень определенности, управляемости, измеряемости и эффективности процесса разработки ПО. измеряемости и эффективности процесса разработки ПО.

Качество (quality)Качество (quality) – степень соответствия системы, – степень соответствия системы, компоненты, процесса или службы потребностям и компоненты, процесса или службы потребностям и ожиданиям клиента или пользователя. ожиданиям клиента или пользователя.

Количественное управление процессомКоличественное управление процессом (quantitative (quantitative process management) заключается в выявлении причин для process management) заключается в выявлении причин для особых отклонений процесса от планируемого и подобающего особых отклонений процесса от планируемого и подобающего исправления этих причин (таким образом, качество процесса исправления этих причин (таким образом, качество процесса измеряется не в количестве написанных строк кода или измеряется не в количестве написанных строк кода или найденных ошибок, а в соответствии процесса исходному найденных ошибок, а в соответствии процесса исходному плану). плану).

Обеспечение качества ПООбеспечение качества ПО (software quality assurance) (software quality assurance) предназначено для информирования руководства об предназначено для информирования руководства об успешности и зрелости процесса разработки ПО и конечных успешности и зрелости процесса разработки ПО и конечных продуктах продуктах

Page 37: современные модели качества программного обеспечения

Определение процесса Определение процесса (process definition) - это рабочее (process definition) - это рабочее определение набора мер, необходимых для достижения определение набора мер, необходимых для достижения намеченных целей. Характеризуется стандартами, намеченных целей. Характеризуется стандартами, процедурами, обучением, средствами и методами. процедурами, обучением, средствами и методами.

Планирование проектаПланирование проекта (software project planning) (software project planning) устанавливает разумные планы для разработки ПО, на устанавливает разумные планы для разработки ПО, на основе которых производится управление программным основе которых производится управление программным проектом. проектом.

Постоянное улучшение процессовПостоянное улучшение процессов (continuous process (continuous process improvement) обеспечивает повышение improvement) обеспечивает повышение производительности, качества продуктов и уменьшение производительности, качества продуктов и уменьшение цикла разработки ПО. цикла разработки ПО.

Предотвращение дефектовПредотвращение дефектов (defect prevention) (defect prevention) заключается в определении причин возникновения заключается в определении причин возникновения дефектов и в принятии мер по предотвращению их дефектов и в принятии мер по предотвращению их дальнейшего возникновения. дальнейшего возникновения.

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

Page 38: современные модели качества программного обеспечения

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

Производительность программного процессаПроизводительность программного процесса (software process performance) представляет собой (software process performance) представляет собой реальные результаты венедрения программного реальные результаты венедрения программного процесса. процесса.

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

Управление конфигурацией ПОУправление конфигурацией ПО (software (software configuration management) создает и поддерживает configuration management) создает и поддерживает целостность продуктов программного проекта в целостность продуктов программного проекта в течение всего жизненного цикла ПО.течение всего жизненного цикла ПО.

Page 39: современные модели качества программного обеспечения

Управление изменениями технологийУправление изменениями технологий (technology change (technology change management) помогает определить и организованно внедрить management) помогает определить и организованно внедрить на предприятии потенциально выгодные новые технологии на предприятии потенциально выгодные новые технологии (т.е. средства, методы и процессы). (т.е. средства, методы и процессы).

Управление программным проектомУправление программным проектом (software project (software project tracking and oversight) состоит в отслеживании степени tracking and oversight) состоит в отслеживании степени успешности и продвижении программного проекта и в успешности и продвижении программного проекта и в принятии соответствующих мер при возникновении принятии соответствующих мер при возникновении существенных отклонений проекта от плана. существенных отклонений проекта от плана.

Управление субподрядчикамиУправление субподрядчиками (software subcontract (software subcontract management) заключается в выборе квалифицированных management) заключается в выборе квалифицированных субподрядчиков и эффективном управлении ими. субподрядчиков и эффективном управлении ими.

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

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

Page 40: современные модели качества программного обеспечения

ISO 9000-9004ISO 9000-9004

Page 41: современные модели качества программного обеспечения

Стандарты серии ISO 9000 разработаны Стандарты серии ISO 9000 разработаны Международной Организацией по Стандартизации (ISO) Международной Организацией по Стандартизации (ISO) и состоят из следующих частей: и состоят из следующих частей:

• ISO 9000ISO 9000 "Общее руководство качеством и стандарты по "Общее руководство качеством и стандарты по обеспечению качества"; обеспечению качества";

• ISO 9001 ISO 9001 "Система Обеспечения Качества: Модель "Система Обеспечения Качества: Модель обеспечения качества при проектировании, разработке, обеспечения качества при проектировании, разработке, производстве, монтаже и обслуживании"; производстве, монтаже и обслуживании";

• ISO 9002ISO 9002 "Система Обеспечения Качества: Модель "Система Обеспечения Качества: Модель обеспечения качества при производстве, монтаже и обеспечения качества при производстве, монтаже и обслуживании" обслуживании"

• ISO 9003ISO 9003 "Система Обеспечения Качества: Модель "Система Обеспечения Качества: Модель обеспечения качества при окончательном контроле и обеспечения качества при окончательном контроле и испытаниях"; испытаниях";

• ISO 9004ISO 9004 "Общее руководство качеством и элементы "Общее руководство качеством и элементы системы качества". системы качества".

Стандарты ISO 9000 и ISO 9004 – не более чем Стандарты ISO 9000 и ISO 9004 – не более чем справочники. Стандартами соответствия являются справочники. Стандартами соответствия являются только ISO 9001, 9002 и 9003. Таким образом, только ISO 9001, 9002 и 9003. Таким образом, бессмысленно говорить о сертификации или бессмысленно говорить о сертификации или регистрации по ISO 9000 или ISO 9004. Предприятие регистрации по ISO 9000 или ISO 9004. Предприятие может получить только сертификаты на соответствие может получить только сертификаты на соответствие ISO 9001, 9002 или 9003. ISO 9001, 9002 или 9003.

Page 42: современные модели качества программного обеспечения

Для организаций, занимающихся Для организаций, занимающихся изготовлением программных изготовлением программных продуктов, соответствующими продуктов, соответствующими стандартами являются ISO 9001 и ISO стандартами являются ISO 9001 и ISO 9000-3 "Руководящие указания по 9000-3 "Руководящие указания по применению ISO 9001 при разработке, применению ISO 9001 при разработке, поставке и обслуживании поставке и обслуживании программного обеспечения". программного обеспечения".

Стандарты ISO – дорогое удовольствие. Стандарты ISO – дорогое удовольствие. Платным в этой системе является все: Платным в этой системе является все: от самих стандартов до аудита и от самих стандартов до аудита и собственно сертификации. собственно сертификации.