Реферат: Модели и характеристики качества. Повышение качества.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙФЕДЕРАЦИИ
Санкт-Петербургскийгосударственный университет
аэрокосмическогоприборостроения
Кафедра № 44
Преподаватель ПятлинаЕ.О.
Модели и характеристики качества.
Повышение качества.
ДОКЛАДпо курсу:Технология программирования
Работу выполнил
Студент группы 4142 ГарезинА.С.
Санкт-Петербург
2006
<span Times New Roman",«serif»; color:windowtext">1. Модели и характеристики качества<span Times New Roman",«serif»; color:windowtext"><span Verdana",«sans-serif»;color:black">
1.1Модели и характеристики качества (Modelsand Quality Characteristics)<span Times New Roman",«serif»;color:black">
В различных источниках (таксономиях и моделях) терминологияхарактеристик качества программного обеспечения отличается. Каждая модельвключает различное число уровней иерархии и общее число<”распознанных”> характеристик качества. Различные авторы создали разныемодели качества со своим набором характеристик и атрибутов (вчастности, Барри Боэм, автор спиральной модели жизненного цикла разработкипрограммного обеспечения, которая рассматривается автором за рамкамиперевода и комментирования SWEBOK). Эти модели могут быть полезныдля обсуждения, планирования, (адаптации, прим. автора) и оценкикачества программных продуктов. ISO/IEC определяет три связанных моделикачества программного обеспечения (ISO 9126–01Software Engineering – Product Quality, Part 1: Quality Model) – внутреннеекачество, внешнее качество и качество в процессе эксплуатации,а также набор соответствующих работ по оценке качества программногообеспечения (ISO14598–98 Software Product Evaluation).
1.2 Качество процессов программного обеспечения (Software engineeringprocess quality)<span Times New Roman",«serif»;color:black">
Управление качеством (software quality management) и качество процессовпрограммной инженерии (software engineering process quality) имеютнепосредственное отношение к качеству создаваемого программного продукта.
<span Times New Roman",«serif»;color:black">Модели и критерииоценки возможностей организаций, занимающихся разработкой программногообеспечения, прежде всего касаются рассмотрения организации проектных работи аспектов управления. Соответственно, они рассматриваютсяв областях знаний SWEBOK “Управление программной инженерией”и “Процесс программной инженерии”. Конечно, невозможно полностью отделитькачество процесса от качества продукта.
Качество процесса, обсуждаемое в области знаний “Процесс программнойинженерии”, влияют на характеристики качества продукта, которые,в свою очередь, отражаются в восприятии качества продуктав процессе эксплуатации со стороны заказчика.
<span Times New Roman",«serif»;color:black">Существуетдва важнейших стандарта в области качества программного обеспечения. Tick IT – касается рассмотрения общей системыменеджмента качества ISO 9001–00в приложении к программным проектам (и, в частности, сочетаниятакого взгляда с положениями стандарта жизненного цикла ISO 12207,прим. автора) и представленный, также, в виде специальныхрекомендаций ISO 90003–04 “Softwareand Systems Engineering – Guidelines for the Applicationof ISO9001:2000 to Computer Software”.
<span Times New Roman",«serif»;color:black">Другой важный стандарт –CMMI, обсуждаемый в области знаний “Процесс программной инженерии”,предоставляет рекомендации по совершенствованию процесса. (здесь нельзяне упомянуть и ISO 15504 “Information Technology – Software ProcessAssessment”, известный как SPICE – Software Process Improvementand Capability dEtermination, который также рассматриваетсяв упомянутой области знаний, прим. автора). Непосредственно с управлениемкачеством связаны процессные области (области компетенции) CMMI: обеспечениекачества процесса и продукта (process and product quality assurance,категория процессов CMMI “Support”), проверка (verification, категория“Engineering”) и аттестация (validation, категория “Engineering”).При этом, CMMI классифицирует обзор (review) и аудит (audit)в качестве методов верификации, но не как самостоятельныепроцессы, в отличие, например, от стандарта 12207.
<span Times New Roman",«serif»;color:black">Дебаты в отношениитого, какой именно стандарт стоит использовать инженерам для обеспечениякачества программного обеспечения – CMMI или ISO 9001, продолжаютсяс самого создания этих стандартов. Сегодня можно сказать о том,что данные стандарты все же рассматривают как взаимодополняющиеи, что сертификация по ISO 9001 помогает в достижении старшихуровней зрелости по CMMI.
1.3 Качество программного продукта (Software productquality)<span Times New Roman",«serif»;color:black">
Прежде всего, инженеры должны определить цели создания программногообеспечения. В этом контексте, особо важно помнить, что требованиязаказчика – первичны и содержат требования в отношении качества,а не только функциональности (функциональные требования). Таким образом,инженеры ответственны за извлечение требований к качеству, которые не всегдапредставлены явно, а также обсуждение их важности и степенисложности их достижения. Все процессы, ассоциированныес качеством (например, сборка, проверка и повышение качества), должныпроектироваться с учетом этих требований и несут на себе тяжестьдополнительных расходов (как важную составную часть стоимости программногообеспечения, прим. автора).
<span Times New Roman",«serif»;color:black">Стандарт ISO 9126–01 (Software Engineering – Product Quality, Part 1:Quality Model) определяет для двух из трех описанных в неммоделей, связанные характеристики и «суб-характеристики» качества,а также метрики, полезные для оценки качества программных продуктов.
Понимание термина “продукт” расширено включением всех артефактов, создаваемыхна выходе всех процессов, используемых для создания конечногопрограммного продукта. Примерами продукта являются (но не ограничиваютсяэтим): полная спецификация системных требований (system requirementsspecification), спецификация программных требований для программныхкомпонент системы (software requirements specification, SRS), модели, код,тестовая документация, отчеты, создаваемые в результате работпо анализу качества. Хотя, чаще всего термин качество используетсяв отношении конечного продукта и поведения системы в процессеэксплуатации, хорошей инженерной практикой является требование к тому, чтобысоответствие заданным характеристикам качества оценивалось и дляпромежуточных результатов/продуктов жизненного цикла в рамках всехпроцессов программной инженерии.
<span Times New Roman",«serif»">2.Стандарт ISO 9126
<span Times New Roman",«serif»">Ещене так давно все требования к приложениям делились на функциональные инефункциональные. Первые, как правило, были представлены двоичным значением«работает/не работает», а вторые — длинным списком свойств, верифицируемыхсубъективно (например, «дружелюбность, устойчивость, безопасность»). Впоследнее время ситуация изменилась, и полный список типов возможных требованийбыл стандартизован в рамках стандарта ISO 9126 .
<span Times New Roman",«serif»">Говоряо функциональности, обычно подразумевают некоторое множество атрибутов,рассчитанных на существование определенного набора функций и их специальныхсвойств, достигающих поставленных целей :
Пригодность. — Выполняет ли приложение предназначенную ему задачу? Может быть верифицировано путем моделирования правильного сопутствующего окружения (подход, аналогичный тестированию). Точность. — Насколько точны результаты работы приложения? Трудно реализуется при модельном подходе; логическая верификация в данном случае будет более эффективна. Безопасность. — Не происходит ли неавторизованной утечки информации? Верифицируется напрямую с формулированием соответствующих запросов. Также существует целый ряд немодельных верификаторов, решающих эту же задачу. Соответствие. — Соответствует ли реализованная функция данному стандарту? Стандарт используется как спецификация (источник требований), реализация функции моделируется. Совместимость. — Может ли данное приложение общаться с соответствующими программными продуктами от других производителей? Близким приближением является подразумеваемая совместимость при наличии соответствия стандарту и отсутствии недокументированных возможностей. При необходимости более точной проверки выполняет автоматическое дизассемблирование и эмуляцию заданных участков программного кода, ручную отладку, построение графа передачи управления и данных.<span Times New Roman",«serif»">Множествоатрибутов надежности характеризуюет способность программного обеспеченияподдерживать определенный уровень предоставляемых услуг при данных условиях и втечение заданного промежутка времени :
Завершенность. — Является ли изначально предоставляемый уровень услуг достаточным? Все ли было реализовано? Это свойство по определению не может быть проверено формальным тестированием: на каждую ожидаемую функцию формулируется требование (или множество требований), которые проверяются на модели. Устойчивость к ошибкам. — Ведет ли себя программа адекватно в случае предоставления заведомо неверных входных данных? Очень неэффективно и громоздко реализуется в модельном подходе, существуют неплохие методы тестирования, решающие эту проблему. Устойчивость к окружению (прочность). — Может ли приложение работать нормально в нестандартном или неустойчивом окружении? Применение модельного подхода в данном случае возможно только при наличии возможности моделирования окружения. Однако корректное моделирование стресс-ситуации — весьма нетривиальная задача. Восстанавливаемость. — Может ли приложение продолжать работу после сбоя? Как правило, это свойство явно прописывается в программе и нуждается только в проверке. Может быть проверено как модельной верификацией, так и тестированием.<span Times New Roman",«serif»">Множествоатрибутов по удобству пользования характеризует трудности при использованиипрограммного обеспечения и их субъективную оценку тем или иным множествомпользователей:
Понятность. — Насколько интуитивно ясен пользовательский интерфейс приложения? Не поддается научной формализации, несмотря на то, что менее формальные правила существуют уже давно, модельная верификация невозможна. Обучаемость. — Приспосабливается ли приложение к специфике пользователя? Используются алгоритмы искусственного интеллекта, которые могут быть верифицированы, соответственно, может быть верифицирован и признак. Управляемость. — Легко ли управлять работой приложения? Эта область, традиционная для бета-тестирования, в последнее время переходит в руки специалистов по пользовательским интерфейсам.<span Times New Roman",«serif»">Множествоатрибутов производительности выявляет связь уровня предоставляемых приложениемуслуг с объемом используемых при этом ресурсов:
Поведение во времени. — Адекватен ли временной график использования ресурсов? В данном случае нужно тестировать реальную систему, а не ее модель (например, для нахождения утечки памяти). Абсолютно не подходит для модельной верификации. Использование ресурсов. — Эффективно ли используются ресурсы? Имеется направленность на реальную систему и существуют эффективные методы формального тестирования, которые в основном базируются на смеси сетй Петри и специализированных языках описания моделей верификации, при прогонке которых происходит количественная оценка потенциально используемых ресурсов; максимальное значение дает вполне эффективную оценку, пригодную для большинства реализаций. Алгоритмизация. — Насколько оптимальны использованные алгоритмы? Классический анализ алгоритмов вместе с формальной их верификацией дает быстрые и точные результаты.<span Times New Roman",«serif»">Множествоатрибутов поддержки связано с усилиями по внесению определенных изменений вработающее приложение:
Анализируемость. — Насколько легко определить части, нуждающиеся в изменении? Hе поддается формализации. Изменяемость. — Какие усилия требуются для внесения изменений? Hе поддается формализации, уровень может быть установлен априори. Hастраиваемость. — Можно ли достичь желаемого эффекта без изменения самой программы, изменяя только настройки? Задача решается тестированием в реальных условиях. Стабильность. — Как ведет себя программа при внесении изменений на лету? Эффективно решается модельной верификацией с помощью недетерминированных параллельных процессов. Тестируемость. — Насколько легко проверяется работа изменившегося контура? Решается параллельно с тестированием или превентивно явным образом и к верификации отношения практически не имеет.<span Times New Roman",«serif»">Множествоатрибутов переместимости характеризует способность программного обеспечениябыть перенесенным из одного окружения в другое:
Приспособляемость. — Может ли приложение изменяться в соответствии с изменениями окружения? Взаимодействующие недетерминированные последовательные процессы дают хороший результат, в том числе, и в модельном подходе. Устанавливаемость. — Может ли приложение устанавливаться на разные платформы или в разные конфигурации? Как правило, явно задается в спецификации и явно реализуется и в проверке не нуждается. Согласованность. — Какие стандарты были использованы в приложении? Hе нуждается в проверке, однако само соответствие стандартам проверять можно и нужно. Заменяемость. — Может ли приложение быть использовано так же, как его эквивалент от другого производителя? Зависит ли от списка опций соответствующих приложений, которые могли бы быть или должны были быть реализованы? Это относится к фазе формулирования требований, поэтому в верификации не участвует.<span Times New Roman",«serif»">Мыпривели общий список свойств, которые могут быть проверены с помощью техникмодельной верификации и валидации, сделав его насколько возможно кратким.
<span Times New Roman",«serif»">3.Пример1. Модель управления качеством
<span Times New Roman",«serif»; mso-ansi-language:EN-US">ISO<span Times New Roman",«serif»"> 9001:2001<table cellspacing=«0» cellpadding=«0» "> <table cellspacing=«0» cellpadding=«0» ">Модель управления качеством в ISO 9001:2000 состоит из четырех разделов: Административная ответственность, Управление ресурсами, Производство продукта Измерение, анализ, улучшение. Остальные разделы ISO 9001 носят вспомогательный характер.
<table cellspacing=«0» cellpadding=«0» "><img src="/cache/referats/22276/image002.jpg" v:shapes="_x0000_i1025">
<span Times New Roman",«serif»">4.Повышение качества.
<span Times New Roman",«serif»;color:black">Качество программногообеспечения может повышаться за счет итеративного процесса постоянногоулучшения. Это требует контроля, координации и обратной связив процессе управления многими одновременно выполняемыми процессами: (1)процессами жизненного цикла, (2) процессом обнаружения, устраненияи предотвращения сбоев/дефектов и (3) процессов улучшения качества.
<span Times New Roman",«serif»;color:black">К программной инженерииприменимы теории и концепции, лежащие в основе совершенствованиякачества. Например, предотвращение и ранняя диагностика ошибок, постоянноесовершенствование (continuous improvement) и внимание к требованиямзаказчика (customer focus), составляющие принцип “building in quality”.Эти концепции основываются на работах экспертов по качеству,пришедших к мнению, что качество продукта напрямую связанос качеством используемых для его создания процессов.
<span Times New Roman",«serif»;color:black">Такие подходы, как TQM(Total Quality Management – всеобщее управление качеством) PDCA (Plan, Do,Check, Act – Планирование, Действие, Проверка, Реакция / Корректировка<a href=«mirror.ntu-kpi.kiev.ua/mirrors/software-testing.ru/kb/КачествоПО/ОсновыКачества/Реакция/Корректировка/edit?add=»1.html" title=«Создать эту страницу»>?
), являются инструментами достижения задач,связанных с качеством. Поддержка менеджмента помогает в выполнениипроцессов, оценке продуктов и получению всех необходимых данных. Кромеэтого, разрабатываемая программа совершенствования (improvement program, обычноявляется целевой и охватывает работу подразделения или организации,в целом, прим. автора) детально идентифицирует все действияи проекты по улучшению <отдельных аспектов деятельности>в рамках определенного периода времени, за который такие проектыможно осуществить с успешным решением соответствующих задач.При этом, поддержка менеджмента означает, что все проектыпо улучшению обладают достаточными ресурсами для достиженияпоставленных целей. Поддержка менеджмента тесно связана с реализациейактивного взаимодействия в коллективе, и должна предупреждатьвозникновение потенциальных проблем (и пассивного или даже активногопротиводействия реализации программы совершенствования или отдельныхее проектов, прим. автора). Формирование рабочих групп, поддержкаменеджеров среднего звена и выделенные ресурсы на уровне проекта –эти вопросы обсуждаются в области знаний “Процесс программнойинженерии”.<span Times New Roman",«serif»">5.Принципы
<span Times New Roman",«serif»;mso-ansi-language:EN-US">TQM<span Times New Roman",«serif»">Бовеи Тилл дают следующее определение подходу ТQМ: «Всеобщее управлениекачеством — это философия организации, которая основана на стремлении ккачеству и практике управления, которая приводит к всеобщему качеству, отсюдакачество — это не то, что Вам приходится отслеживать или добавлять на каком-тоэтапе производственного процесса, это сама сущность организации».
<span Times New Roman",«serif»">Вбольшей степени подходы TQM изложены в МС ИСО 9004:2000, являющемсяметодическим пособием по применению системы качества. МС ИСО 9001:2000 содержитминимум требований для удовлетворения запросов потребителей. Но все же междустандартами ИСО серии 9000 и концепцией TQM можно выделить ряд отличий, которыеприведены в таблице:
<span Times New Roman",«serif»">СтандартыISO 9000 и TQM
<span Times New Roman",«serif»">ISO 9000
TQM
Нет необходимости фокуса на определенного потребителя Фокус на определенного потребителя Не интегрировано в корпоративную стратегию Интегрированная стратегия компании Фокус на технические системы и процедуры Фокус на философию, концепции, инструменты и методологию Вовлеченность всех сотрудников не обязательна Подчеркивает необходимость вовлечения всех сотрудников Не фокусирует на непрерывном улучшении Непрерывное улучшение и TQM являются синонимами, в результате чего TQM представляется непрерывным и не оканчивающимся путешествием в качество Ответственность за качество должна быть определена и документально оформлена, но часто ответственность за качество возлагается на соответствующие подразделения, например отдел качества Каждый сотрудник ответственен за качество Возможность фокуса на подразделения Организация всех подразделений, функций и уровней В основном статиченПодразумевает изменение процесса и культуры
<span Times New Roman",«serif»">Основноеже отличие TQM от стандартов ИСО серии 9000 состоит в том, что TQM являетсявершиной современных методов управления качеством и ориентирована на повышениекачества изделий, когда уже имеется некий достигнутый уровень, а внедрениестандартов ИСО серии 9000 скорее направлено на снижение вероятности сделатьчто-либо неверно.
<span Times New Roman",«serif»">Наибольшийвклад в развитие теории TQM внесли В.Эдвардс Деминг, Джозеф М.Джуран и ФилипБ.Кросби, которые подчеркивали необходимость подхода к качеству на уровнеорганизации.
<span Times New Roman",«serif»">Самымглавным в подходе В.Эдвардса Деминга к качеству является следующее: признаниетого, что всегда существуют отклонения, отслеживание «неестественных»отклонений и затем выяснение причин, лежащих в их основе. Если в процессевозникают экстремальные отклонения, это может весьма затруднить прогноз, и,значит, организации может потребоваться больше персонала, сырья и материалов,чтобы свести до минимума влияние нерегулярных поставок от поставщиков.
<span Times New Roman",«serif»">Интересно,что Деминг выдвигает идею об отмене оценки заданий и результатов выполненияработы, так как, по его мнению, они создают атмосферу страха, способствуюткраткосрочному вкладу в работу, игнорируя долгосрочные задачи, и разрушаютработу в командах.
<span Times New Roman",«serif»">Вто время как в работе Деминга основное внимание уделяется улучшению качестваприменительно прежде всего к процессам, системам и статистике, Джозеф М.Джуранподчеркивает необходимость для каждого менеджера непосредственно заниматьсядеятельностью, приводящей к повышению качества. Он является сторонникомподхода, который предусматривает вовлеченность персонала в процедуры,обеспечивающие качество и решение проблем.
<span Times New Roman",«serif»">10этапов для повышения качества по Джозефу М.Джурану
<span Times New Roman",«serif»"><span Times New Roman",«serif»">1.Сформируйте осознание потребности в качественной работе и создайте возможностьдля улучшения качества.
<span Times New Roman",«serif»">2.Установите цели для постоянного совершенствования деятельности.
<span Times New Roman",«serif»">3.Создайте организацию, которая будет работать над достижением целей, создавусловия для определения проблем, выбора проектов, сформировав команды и выбравкоординаторов.
<span Times New Roman",«serif»">4.Предоставьте обучение всем сотрудникам организации.
<span Times New Roman",«serif»">5.Выполняйте проекты для решения проблем.
<span Times New Roman",«serif»">6.Информируйте сотрудников о достигнутых улучшениях.
<span Times New Roman",«serif»">7.Выражайте свое признание сотрудникам, внесшим наибольший вклад в улучшениекачества.
<span Times New Roman",«serif»">8.Сообщайте о результатах.
<span Times New Roman",«serif»">9.Регистрируйте успехи.
<span Times New Roman",«serif»">10.Внедряйте достижения, которых Вам удалось добиться в течение года, в системы ипроцессы, регулярно функционирующие в организации, тем самым закрепляя их.
<span Times New Roman",«serif»">14-этапныйплан Филипа Б.Кросби по повышению качества
<span Times New Roman",«serif»"><span Times New Roman",«serif»">1.Четко определите приверженность руководства идее качества.
<span Times New Roman",«serif»">2.Используйте команды по работе над улучшением качества для привлечения иинформирования о качестве всех членов организации.
<span Times New Roman",«serif»">3.Измеряйте качество и раскрывайте текущие и потенциальные проблемы с качеством.
<span Times New Roman",«serif»">4.Подсчитайте стоимость качества.
<span Times New Roman",«serif»">5.Скажите подчиненным, сколько стоит некачественная работа.
<span Times New Roman",«serif»">6.Предпримите корректирующие действия.
<span Times New Roman",«serif»">7.Организуйте специальный комитет, который будет работать над программой нулевыхошибок.
<span Times New Roman",«serif»">8.Обучите наставников, которые будут внедрять программу нулевых ошибок.
<span Times New Roman",«serif»">9.Проведите «день нулевых ошибок », чтобы объяснить программу иподчеркнуть тот факт, что в организации к этой проблеме будут относитьсяпо-новому.
<span Times New Roman",«serif»">10.Устанавливайте и поощряйте персонал устанавливать цели, ориентированные наулучшение качества.
<span Times New Roman",«serif»">11.Поощряйте подчиненных сообщать о тех проблемах, которые не позволяют имработать без ошибок.
<span Times New Roman",«serif»">12.Высказывайте признание тем, кто добивается поставленных целей и отличновыполняет работу.
<span Times New Roman",«serif»">13.Организуйте советы качества, состоящие из профессионалов и руководителейкоманд, которые будут регулярно общаться друг с другом.
<span Times New Roman",«serif»">14. Проделывайте это снова иснова, подчеркивая, что у данной программы нет завершения.
<span Times New Roman",«serif»">Учитывая,что некоторые из этих шагов или пунктов перекликаются или являются составнымичастями других пунктов, Джон Рэббит и Питер Бергх объединили их всемь успешных факторов качества:
<span Times New Roman",«serif»">1)фокус на потребителя;
<span Times New Roman",«serif»">2)фокус на процесс и его результаты;
<span Times New Roman",«serif»">3)управление участием/ответственностью;
<span Times New Roman",«serif»">4)непрерывное улучшение;
<span Times New Roman",«serif»">5)проблемы, зависящие от рабочих, должны составлять не более 20 %;
<span Times New Roman",«serif»">6)проведение измерений;
<span Times New Roman",«serif»">7)постоянно действующие сквозные функциональные Советы, представляющие собойпостоянно действующие команды по улучшению качества.
Использованная литература.
1)Качество.Стандарты ISO. Статьи Клайда Пирча (Clyde Pearch) на www.asupt.ru
2) Статьи Джилл Китка (JillKitka), (EagleGroupUSA,Inc.) на на www.asupt.ru
3) Сайт KnowledgeBase.