Модели и характеристики качества. Повышение качества.

Загрузить архив:
Файл: ref-22276.zip (24kb [zip], Скачиваний: 90) скачать

МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

Санкт-Петербургский государственный университет

аэрокосмического приборостроения

Кафедра № 44

Преподаватель                                                            Пятлина Е.О.     

Модели и характеристики качества.

Повышение качества.

ДОКЛАД

по курсу: Технология программирования

Работу выполнил

Студент группы 4142                                                          Гарезин А.С.

Санкт-Петербург

2006

1. Модели ихарактеристики качества

1.1Модели ихарактеристики качества (Models andQuality Characteristics)
Вразличных источниках (таксономиях имоделях) терминология характеристик качества программного обеспечения отличается. Каждая модель включает различное число уровней иерархии иобщее число <”распознанных”> характеристик качества. Различные авторы создали разные модели качества сосвоим набором характеристик иатрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла разработки программного обеспечения, которая рассматривается автором зарамками перевода икомментирования SWEBOK). Этимодели могут быть полезны дляобсуждения, планирования, (адаптации, прим. автора) иоценки качества программных продуктов. ISO/IEC определяет трисвязанных модели качества программного обеспечения (ISO 9126–01 Software Engineering – Product Quality, Part 1: Quality Model) – внутреннее качество, внешнее качество икачество впроцессе эксплуатации, атакже набор соответствующих работ пооценке качества программного обеспечения (ISO14598–98 Software Product Evaluation).



1.2 Качество процессов программного обеспечения (Software engineering process quality)
Управление качеством (software quality management) икачество процессов программной инженерии (software engineering process quality) имеют непосредственное отношение ккачеству создаваемого программного продукта.

Модели икритерии оценки возможностей организаций, занимающихся разработкой программного обеспечения, прежде всего касаются рассмотрения организации проектных работ иаспектов управления. Соответственно, онирассматриваются вобластях знаний SWEBOK “Управление программной инженерией” и“Процесс программной инженерии”. Конечно, невозможно полностью отделить качество процесса откачества продукта.


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



Существует дваважнейших стандарта вобласти качества программного обеспечения. TickIT – касается рассмотрения общей системы менеджмента качества ISO9001–00 вприложении кпрограммным проектам (и, вчастности, сочетания такого взгляда сположениями стандарта жизненного цикла ISO12207, прим. автора) ипредставленный, также, ввиде специальных рекомендаций ISO90003–04 “Software andSystems Engineering – Guidelines forthe Application ofISO9001:2000 toComputer Software”.



Другой важный стандарт – CMMI, обсуждаемый вобласти знаний “Процесс программной инженерии”, предоставляет рекомендации посовершенствованию процесса. (здесь нельзя неупомянуть иISO 15504 “Information Technology – Software Process Assessment”, известный какSPICE – Software Process Improvement andCapability dEtermination, который также рассматривается вупомянутой области знаний, прим. автора). Непосредственно суправлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса ипродукта (process andproduct quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) иаттестация (validation, категория “Engineering”). Приэтом, CMMI классифицирует обзор (review) иаудит (audit) вкачестве методов верификации, ноне каксамостоятельные процессы, вотличие, например, отстандарта 12207.



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



1.3 Качество программного продукта (Software product quality)
Прежде всего, инженеры должны определить цели создания программного обеспечения. Вэтом контексте, особо важно помнить, чтотребования заказчика – первичны исодержат требования вотношении качества, ане только функциональности (функциональные требования). Таким образом, инженеры ответственны заизвлечение требований ккачеству, которые невсегда представлены явно, атакже обсуждение ихважности истепени сложности ихдостижения. Всепроцессы, ассоциированные скачеством (например, сборка, проверка иповышение качества), должны проектироваться сучетом этих требований инесут насебе тяжесть дополнительных расходов (как важную составную часть стоимости программного обеспечения, прим. автора).



Стандарт ISO9126–01 (Software Engineering – Product Quality, Part 1: Quality Model) определяет длядвух изтрех описанных внем моделей, связанные характеристики и«суб-характеристики» качества, атакже метрики, полезные дляоценки качества программных продуктов.


Понимание термина “продукт” расширено включением всех артефактов, создаваемых навыходе всех процессов, используемых длясоздания конечного программного продукта. Примерами продукта являются (но неограничиваются этим): полная спецификация системных требований (system requirements specification), спецификация программных требований дляпрограммных компонент системы (software requirements specification, SRS), модели, код, тестовая документация, отчеты, создаваемые врезультате работ поанализу качества. Хотя, чаще всего термин качество используется вотношении конечного продукта иповедения системы впроцессе эксплуатации, хорошей инженерной практикой является требование ктому, чтобы соответствие заданным характеристикам качества оценивалось идля промежуточных результатов/продуктов жизненного цикла врамках всех процессов программной инженерии.

2. Стандарт ISO 9126

Еще не так давно все требования к приложениям делились на функциональные и нефункциональные. Первые, как правило, были представлены двоичным значением «работает/не работает», а вторые — длинным списком свойств, верифицируемых субъективно (например, «дружелюбность, устойчивость, безопасность»). В последнее время ситуация изменилась, и полный список типов возможных требований был стандартизован в рамках стандарта ISO 9126 .

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

  • Пригодность. - Выполняет ли приложение предназначенную ему задачу? Может быть верифицировано путем моделирования правильного сопутствующего окружения (подход, аналогичный тестированию).
  • Точность. - Насколько точны результаты работы приложения? Трудно реализуется при модельном подходе; логическая верификация в данном случае будет более эффективна.
  • Безопасность. - Не происходит ли неавторизованной утечки информации? Верифицируется напрямую с формулированием соответствующих запросов. Также существует целый ряд немодельных верификаторов, решающих эту же задачу.
  • Соответствие. - Соответствует ли реализованная функция данному стандарту? Стандарт используется как спецификация (источник требований), реализация функции моделируется.
  • Совместимость. - Может ли данное приложение общаться с соответствующими программными продуктами от других производителей? Близким приближением является подразумеваемая совместимость при наличии соответствия стандарту и отсутствии недокументированных возможностей. При необходимости более точной проверки выполняет автоматическое дизассемблирование и эмуляцию заданных участков программного кода, ручную отладку, построение графа передачи управления и данных.

Множество атрибутов надежности характеризуюет способность программного обеспечения поддерживать определенный уровень предоставляемых услуг при данных условиях и в течение заданного промежутка времени :

  • Завершенность. - Является ли изначально предоставляемый уровень услуг достаточным? Все ли было реализовано? Это свойство по определению не может быть проверено формальным тестированием: на каждую ожидаемую функцию формулируется требование (или множество требований), которые проверяются на модели.
  • Устойчивость к ошибкам. - Ведет ли себя программа адекватно в случае предоставления заведомо неверных входных данных? Очень неэффективно и громоздко реализуется в модельном подходе, существуют неплохие методы тестирования, решающие эту проблему.
  • Устойчивость к окружению (прочность). - Может ли приложение работать нормально в нестандартном или неустойчивом окружении? Применение модельного подхода в данном случае возможно только при наличии возможности моделирования окружения. Однако корректное моделирование стресс-ситуации - весьма нетривиальная задача.
  • Восстанавливаемость. - Может ли приложение продолжать работу после сбоя? Как правило, это свойство явно прописывается в программе и нуждается только в проверке. Может быть проверено как модельной верификацией, так и тестированием.

Множество атрибутов по удобству пользования характеризует трудности при использовании программного обеспечения и их субъективную оценку тем или иным множеством пользователей:

  • Понятность. - Насколько интуитивно ясен пользовательский интерфейс приложения? Не поддается научной формализации, несмотря на то, что менее формальные правила существуют уже давно, модельная верификация невозможна.
  • Обучаемость. - Приспосабливается ли приложение к специфике пользователя? Используются алгоритмы искусственного интеллекта, которые могут быть верифицированы, соответственно, может быть верифицирован и признак.
  • Управляемость. - Легко ли управлять работой приложения? Эта область, традиционная для бета-тестирования, в последнее время переходит в руки специалистов по пользовательским интерфейсам.

Множество атрибутов производительности выявляет связь уровня предоставляемых приложением услуг с объемом используемых при этом ресурсов:

  • Поведение во времени. - Адекватен ли временной график использования ресурсов? В данном случае нужно тестировать реальную систему, а не ее модель (например, для нахождения утечки памяти). Абсолютно не подходит для модельной верификации.
  • Использование ресурсов. - Эффективно ли используются ресурсы? Имеется направленность на реальную систему и существуют эффективные методы формального тестирования, которые в основном базируются на смеси сетй Петри и специализированных языках описания моделей верификации, при прогонке которых происходит количественная оценка потенциально используемых ресурсов; максимальное значение дает вполне эффективную оценку, пригодную для большинства реализаций.
  • Алгоритмизация. - Насколько оптимальны использованные алгоритмы? Классический анализ алгоритмов вместе с формальной их верификацией дает быстрые и точные результаты.

Множество атрибутов поддержки связано с усилиями по внесению определенных изменений в работающее приложение:

  • Анализируемость. - Насколько легко определить части, нуждающиеся в изменении? Hе поддается формализации.
  • Изменяемость. - Какие усилия требуются для внесения изменений? Hе поддается формализации, уровень может быть установлен априори.
  • Hастраиваемость. - Можно ли достичь желаемого эффекта без изменения самой программы, изменяя только настройки? Задача решается тестированием в реальных условиях.
  • Стабильность. - Как ведет себя программа при внесении изменений на лету? Эффективно решается модельной верификацией с помощью недетерминированных параллельных процессов.
  • Тестируемость. - Насколько легко проверяется работа изменившегося контура? Решается параллельно с тестированием или превентивно явным образом и к верификации отношения практически не имеет.

Множество атрибутов переместимости характеризует способность программного обеспечения быть перенесенным из одного окружения в другое:

  • Приспособляемость. - Может ли приложение изменяться в соответствии с изменениями окружения? Взаимодействующие недетерминированные последовательные процессы дают хороший результат, в том числе, и в модельном подходе.
  • Устанавливаемость. - Может ли приложение устанавливаться на разные платформы или в разные конфигурации? Как правило, явно задается в спецификации и явно реализуется и в проверке не нуждается.
  • Согласованность. - Какие стандарты были использованы в приложении? Hе нуждается в проверке, однако само соответствие стандартам проверять можно и нужно.
  • Заменяемость. - Может ли приложение быть использовано так же, как его эквивалент от другого производителя? Зависит ли от списка опций соответствующих приложений, которые могли бы быть или должны были быть реализованы? Это относится к фазе формулирования требований, поэтому в верификации не участвует.

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

3. Пример1. Модель управления качеством ISO 9001:2001

Модель управления качеством в ISO 9001:2000 состоит из четырех разделов: Административная ответственность , Управление ресурсами , Производство продукта  Измерение, анализ, улучшение . Остальные разделы ISO 9001 носят вспомогательный характер.



4. Повышение качества.

Качество программного обеспечения может повышаться засчет итеративного процесса постоянного улучшения. Этотребует контроля, координации иобратной связи впроцессе управления многими одновременно выполняемыми процессами: (1) процессами жизненного цикла, (2) процессом обнаружения, устранения ипредотвращения сбоев/дефектов и(3) процессов улучшения качества.



Кпрограммной инженерии применимы теории иконцепции, лежащие воснове совершенствования качества. Например, предотвращение иранняя диагностика ошибок, постоянное совершенствование (continuous improvement) ивнимание ктребованиям заказчика (customer focus), составляющие принцип “building inquality”. Этиконцепции основываются наработах экспертов покачеству, пришедших кмнению, чтокачество продукта напрямую связано скачеством используемых дляего создания процессов.



Такие подходы, какTQM (Total Quality Management – всеобщее управление качеством) PDCA (Plan, Do, Check, Act– Планирование, Действие, Проверка, Реакция/Корректировка), являются инструментами достижения задач, связанных скачеством. Поддержка менеджмента помогает ввыполнении процессов, оценке продуктов иполучению всех необходимых данных. Кроме этого, разрабатываемая программа совершенствования (improvement program, обычно является целевой иохватывает работу подразделения илиорганизации, вцелом, прим. автора) детально идентифицирует вседействия ипроекты поулучшению <отдельных аспектов деятельности> врамках определенного периода времени, закоторый такие проекты можно осуществить суспешным решением соответствующих задач. Приэтом, поддержка менеджмента означает, чтовсе проекты поулучшению обладают достаточными ресурсами длядостижения поставленных целей. Поддержка менеджмента тесно связана среализацией активного взаимодействия вколлективе, идолжна предупреждать возникновение потенциальных проблем (и пассивного илидаже активного противодействия реализации программы совершенствования илиотдельных еепроектов, прим. автора). Формирование рабочих групп, поддержка менеджеров среднего звена ивыделенные ресурсы науровне проекта – этивопросы обсуждаются вобласти знаний “Процесс программной инженерии”.

5. Принципы TQM

Бове и Тилл дают следующее определение подходу ТQМ: "Всеобщее управление качеством - это философия организации, которая основана на стремлении к качеству и практике управления, которая приводит к всеобщему качеству, отсюда качество - это не то, что Вам приходится отслеживать или добавлять на каком-то этапе производственного процесса, это сама сущность организации".

В большей степени подходы TQM изложены в МС ИСО 9004:2000, являющемся методическим пособием по применению системы качества. МС ИСО 9001:2000 содержит минимум требований для удовлетворения запросов потребителей. Но все же между стандартами ИСО серии 9000 и концепцией TQM можно выделить ряд отличий, которые приведены в таблице:

Стандарты ISO 9000 и TQM

ISO 9000

TQM
  • Нет необходимости фокуса на определенного потребителя
  • Фокус на определенного потребителя
  • Не интегрировано в корпоративную стратегию
  • Интегрированная стратегия компании
  • Фокус на технические системы и процедуры
  • Фокус на философию, концепции, инструменты и методологию
  • Вовлеченность всех сотрудников не обязательна
  • Подчеркивает необходимость вовлечения всех сотрудников
  • Не фокусирует на непрерывном улучшении
  • Непрерывное улучшение и TQM являются синонимами, в результате чего TQM представляется непрерывным и не оканчивающимся путешествием в качество
  • Ответственность за качество должна быть определена и документально оформлена, но часто ответственность за качество возлагается на соответствующие подразделения, например отдел качества
  • Каждый сотрудник ответственен за качество
  • Возможность фокуса на подразделения
  • Организация всех подразделений, функций и уровней
  • В основном статичен

Подразумевает изменение процесса и культуры

Основное же отличие TQM от стандартов ИСО серии 9000 состоит в том, что TQM является вершиной современных методов управления качеством и ориентирована на повышение качества изделий, когда уже имеется некий достигнутый уровень, а внедрение стандартов ИСО серии 9000 скорее направлено на снижение вероятности сделать что-либо неверно.

Наибольший вклад в развитие теории TQM внесли В.Эдвардс Деминг, Джозеф М.Джуран и Филип Б.Кросби, которые подчеркивали необходимость подхода к качеству на уровне организации.

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

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

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

10 этапов для повышения качества по Джозефу М.Джурану

1. Сформируйте осознание потребности в качественной работе и создайте возможность для улучшения качества.

2. Установите цели для постоянного совершенствования деятельности.

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

4. Предоставьте обучение всем сотрудникам организации.

5. Выполняйте проекты для решения проблем.

6. Информируйте сотрудников о достигнутых улучшениях.

7. Выражайте свое признание сотрудникам, внесшим наибольший вклад в улучшение качества.

8. Сообщайте о результатах.

9. Регистрируйте успехи.

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

14-этапный план Филипа Б.Кросби по повышению качества

1. Четко определите приверженность руководства идее качества.

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

3. Измеряйте качество и раскрывайте текущие и потенциальные проблемы с качеством.

4. Подсчитайте стоимость качества.

5. Скажите подчиненным, сколько стоит некачественная работа.

6. Предпримите корректирующие действия.

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

8. Обучите наставников, которые будут внедрять программу нулевых ошибок.

9. Проведите "день нулевых ошибок ", чтобы объяснить программу и подчеркнуть тот факт, что в организации к этой проблеме будут относиться по-новому.

10. Устанавливайте и поощряйте персонал устанавливать цели, ориентированные на улучшение качества.

11. Поощряйте подчиненных сообщать о тех проблемах, которые не позволяют им работать без ошибок.

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

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

14. Проделывайте это снова и снова, подчеркивая, что у данной программы нет завершения.

Учитывая, что некоторые из этих шагов или пунктов перекликаются или являются составными частями других пунктов, Джон Рэббит и Питер Бергх объединили их в семь успешных факторов качества:

1) фокус на потребителя;

2) фокус на процесс и его результаты;

3) управление участием/ответственностью;

4) непрерывное улучшение;

5) проблемы, зависящие от рабочих, должны составлять не более 20 %;

6) проведение измерений;

7) постоянно действующие сквозные функциональные Советы, представляющие собой постоянно действующие команды по улучшению качества.

Использованная литература.

1)Качество.Стандарты ISO. Статьи Клайда Пирча (Clyde Pearch) на www.asupt.ru

2) Статьи Джилл Китка (JillKitka), (EagleGroupUSA, Inc.) на на

3) Сайт KnowledgeBase.