курсовые,контрольные,дипломы,рефераты
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
Санкт-Петербургский государственный университет
аэрокосмического приборостроения
Кафедра № 44
Преподаватель Пятлина Е.О.
Модели и характеристики качества.
Повышение качества.
по курсу: Технология программирования
Работу выполнил
Студент группы 4142 Гарезин А.С.
Санкт-Петербург
2006
1.1Модели и характеристики качества (Models
and Quality 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 “Управление программной инженерией” и “Процесс программной инженерии”. Конечно, невозможно полностью отделить качество процесса от качества продукта.
Качество процесса, обсуждаемое в области знаний “Процесс программной
инженерии”, влияют на характеристики качества продукта, которые,
в свою очередь, отражаются в восприятии качества продукта
в процессе эксплуатации со стороны заказчика.
Существует два важнейших стандарта в области качества программного обеспечения. Tick IT – касается рассмотрения общей системы менеджмента качества ISO 9001–00 в приложении к программным проектам (и, в частности, сочетания такого взгляда с положениями стандарта жизненного цикла ISO 12207, прим. автора) и представленный, также, в виде специальных рекомендаций ISO 90003–04 “Software and Systems Engineering – Guidelines for the Application of ISO9001:2000 to Computer Software”.
Другой важный стандарт – CMMI, обсуждаемый в области знаний “Процесс программной инженерии”, предоставляет рекомендации по совершенствованию процесса. (здесь нельзя не упомянуть и ISO 15504 “Information Technology – Software Process Assessment”, известный как SPICE – Software Process Improvement and Capability dEtermination, который также рассматривается в упомянутой области знаний, прим. автора). Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation, категория “Engineering”). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207.
Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что сертификация по ISO 9001 помогает в достижении старших уровней зрелости по CMMI.
1.3 Качество программного продукта (Software product
quality)
Прежде всего, инженеры должны определить цели создания программного
обеспечения. В этом контексте, особо важно помнить, что требования
заказчика – первичны и содержат требования в отношении качества,
а не только функциональности (функциональные требования). Таким образом,
инженеры ответственны за извлечение требований к качеству, которые не всегда
представлены явно, а также обсуждение их важности и степени
сложности их достижения. Все процессы, ассоциированные
с качеством (например, сборка, проверка и повышение качества), должны
проектироваться с учетом этих требований и несут на себе тяжесть
дополнительных расходов (как важную составную часть стоимости программного
обеспечения, прим. автора).
Стандарт ISO 9126–01 (Software Engineering – Product Quality, Part 1: Quality Model) определяет для двух из трех описанных в нем моделей, связанные характеристики и «суб-характеристики» качества, а также метрики, полезные для оценки качества программных продуктов.
Понимание термина “продукт” расширено включением всех артефактов, создаваемых
на выходе всех процессов, используемых для создания конечного
программного продукта. Примерами продукта являются (но не ограничиваются
этим): полная спецификация системных требований (system requirements
specification), спецификация программных требований для программных
компонент системы (software requirements specification, SRS), модели, код,
тестовая документация, отчеты, создаваемые в результате работ
по анализу качества. Хотя, чаще всего термин качество используется
в отношении конечного продукта и поведения системы в процессе
эксплуатации, хорошей инженерной практикой является требование к тому, чтобы
соответствие заданным характеристикам качества оценивалось и для
промежуточных результатов/продуктов жизненного цикла в рамках всех
процессов программной инженерии.
2. Стандарт ISO 9126
Еще не так давно все требования к приложениям делились на функциональные и нефункциональные. Первые, как правило, были представлены двоичным значением «работает/не работает», а вторые — длинным списком свойств, верифицируемых субъективно (например, «дружелюбность, устойчивость, безопасность»). В последнее время ситуация изменилась, и полный список типов возможных требований был стандартизован в рамках стандарта ISO 9126 .
Говоря о функциональности, обычно подразумевают некоторое множество атрибутов, рассчитанных на существование определенного набора функций и их специальных свойств, достигающих поставленных целей :
Множество атрибутов надежности характеризуюет способность программного обеспечения поддерживать определенный уровень предоставляемых услуг при данных условиях и в течение заданного промежутка времени :
Множество атрибутов по удобству пользования характеризует трудности при использовании программного обеспечения и их субъективную оценку тем или иным множеством пользователей:
Множество атрибутов производительности выявляет связь уровня предоставляемых приложением услуг с объемом используемых при этом ресурсов:
Множество атрибутов поддержки связано с усилиями по внесению определенных изменений в работающее приложение:
Множество атрибутов переместимости характеризует способность программного обеспечения быть перенесенным из одного окружения в другое:
Мы привели общий список свойств, которые могут быть проверены с помощью техник модельной верификации и валидации, сделав его насколько возможно кратким.
3. Пример1. Модель управления качеством ISO 9001:2001
Модель управления качеством в ISO 9001:2000 состоит из четырех разделов: Административная ответственность , Управление ресурсами , Производство продукта Измерение, анализ, улучшение . Остальные разделы ISO 9001 носят вспомогательный характер. |
|
|
4. Повышение качества.
Качество программного обеспечения может повышаться за счет итеративного процесса постоянного улучшения. Это требует контроля, координации и обратной связи в процессе управления многими одновременно выполняемыми процессами: (1) процессами жизненного цикла, (2) процессом обнаружения, устранения и предотвращения сбоев/дефектов и (3) процессов улучшения качества.
К программной инженерии применимы теории и концепции, лежащие в основе совершенствования качества. Например, предотвращение и ранняя диагностика ошибок, постоянное совершенствование (continuous improvement) и внимание к требованиям заказчика (customer focus), составляющие принцип “building in quality”. Эти концепции основываются на работах экспертов по качеству, пришедших к мнению, что качество продукта напрямую связано с качеством используемых для его создания процессов.
Такие подходы, как 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 от стандартов ИСО серии 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) Статьи Джилл Китка (Jill Kitka), (Eagle Group USA, Inc.) на на www.asupt.ru
3) Сайт KnowledgeBase.
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ Санкт-Петербургский государственный университет аэрокосмического приборостроения Кафедра № 44 Преподаватель Пятлина Е.О.
Copyright (c) 2024 Stud-Baza.ru Рефераты, контрольные, курсовые, дипломные работы.