Скачать презентацию ПРИНЦИПЫ ОРГАНИЗАЦИИ ПРОЦЕССА КОНТРОЛЯ КАЧЕСТВА  Система качества Скачать презентацию ПРИНЦИПЫ ОРГАНИЗАЦИИ ПРОЦЕССА КОНТРОЛЯ КАЧЕСТВА Система качества

Лекция_1_Качество.ppt

  • Количество слайдов: 42

ПРИНЦИПЫ ОРГАНИЗАЦИИ ПРОЦЕССА КОНТРОЛЯ КАЧЕСТВА ПРИНЦИПЫ ОРГАНИЗАЦИИ ПРОЦЕССА КОНТРОЛЯ КАЧЕСТВА

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

Обеспечение качества QA Ø Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий, Обеспечение качества QA Ø Обеспечение качества (Quality Assurance - QA) - это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения (ПО) информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения качества выпускаемого продукта. Ø Контроль качества (Quality Control - QC) - это совокупность действий проводимых над объектом тестирования в процессе разработки для получения информации об актуальном состоянии объекта тестирования в разрезах: "готовность Продукта к выпуску", "Соответствие зафиксированным требованиям", "Соответствие заявленному уровню качества продукта". Ø Тестирование программного обеспечения (Software Testing) - это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). ]

Качество Ø Качество — это пригодность к использованию ( Качество Ø Качество — это пригодность к использованию ("conformance to requirements" ) − взгляд заказчика. Ø Качество — это соответствие специфицированным и собранным требованиям ("fitness for use") − взгляд разработчика.

Качество ПО 1) Качество программного обеспечения (Software Quality) - это степень, в которой программное Качество ПО 1) Качество программного обеспечения (Software Quality) - это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061 -1998 IEEE Standard for Software Quality Metrics Methodology] Ø 2) Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402: 1994 Quality management and quality assurance] Ø

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

Стандарт ISO 9000 -2000 По ISO, качество - это полнота свойств и характеристик продукта, Стандарт ISO 9000 -2000 По ISO, качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям. Современные способы обеспечения качества базируются на подходах TQM (Total Quality Management). Это управление ресурсами и применение количественных методов анализа для улучшения материалов и услуг, поставляемых в организацию, всех процессов внутри организации, а также степени удовлетворенности настоящих и будущих потребностей клиентов.

Характеристики качества ПО Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным Характеристики качества ПО Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т. е. эта характеристика отвечает за то, что ПО работает исправно и точно, функционально совместимо, соответствует стандартам отрасли и защищено от несанкционированного доступа. Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость. Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя. Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствие с выделенными ресурсами, временем и другими обозначенными условиями. Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к именующемуся окружению. Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.

Модель качества ПО Модель качества ПО

Принципы построения организационной системы Ø Концентрация на потребностях заказчика. Ø Активная лидирующая роль руководства. Принципы построения организационной системы Ø Концентрация на потребностях заказчика. Ø Активная лидирующая роль руководства. Ø Вовлечение исполнителей в процессы совершенствования. Ø Реализация процессного подхода. Ø Системный подход к управлению. Ø Обеспечение непрерывных улучшений. Ø Принятие решений на основе фактов. Ø Взаимовыгодные отношения с поставщиками.

Как сделать продукт качественным Как сделать продукт качественным

ЦЕНА КАЧЕСТВА Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления ЦЕНА КАЧЕСТВА Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления несоответствий. Ø Несогласованная цена - это незапланированные потери, связанные с рекламациями, переделками, переносом сроков проекта и т. д. Ø Несогласованная цена качества уменьшается существенно быстрее, чем увеличивается согласованная цена.

ПЕРСОНАЛ Ø Ø тестированием должны заниматься специально подготовленные люди; при необходимости должно осуществляться консультирование ПЕРСОНАЛ Ø Ø тестированием должны заниматься специально подготовленные люди; при необходимости должно осуществляться консультирование заинтересованных лиц по вопросам тестирования; должно проводиться штатное обучение участников проекта методикам, подходам тестирования, работе со специализированными техническими средствами организации процесса тестирования и т. д. в обязательном порядке должно осуществляться внутреннее тестирование разработчиками своих разработок.

Процесс тестирования Тестирование программного обеспечения (software testing)— это процесс анализа или эксплуатации программного обеспечения Процесс тестирования Тестирование программного обеспечения (software testing)— это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов. Слово процесс (process) используется для того, чтобы подчеркнуть, что тестирование суть плановая, упорядоченная деятельность. Тестирование предусматривает "анализ" или "эксплуатацию" программного продукта.

Тестирование программного обеспечения выполняет две базовых функции: Верификация (verification) обеспечивает соответствие результатов конкретной фазы Тестирование программного обеспечения выполняет две базовых функции: Верификация (verification) обеспечивает соответствие результатов конкретной фазы процесса разработки требованиям данной и предшествующей стадий. Верификация (verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т. е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы. Ø Аттестация (validation) есть гарантия того, что программный продукт удовлетворяет системным требованиям. Валидация (validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS 7925 -1]. Ø

Static Testing Статическое тестирование - тестовая деятельность, связанная с анализом результатов разработки программного обеспечения. Static Testing Статическое тестирование - тестовая деятельность, связанная с анализом результатов разработки программного обеспечения. Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска на машине, т. е. проверку за столом (desk checks).

СТАТИЧЕСКИЕ МЕТОДЫ ТЕСТИРОВАНИЯ Ø инспекции - совещания, на которых рабочий продукт анализируется с целью СТАТИЧЕСКИЕ МЕТОДЫ ТЕСТИРОВАНИЯ Ø инспекции - совещания, на которых рабочий продукт анализируется с целью обнаружения дефектов; Ø сквозной контроль, Ø экспертные оценки.

Dynamic Testing Динамическое тестирование - тестовая деятельность, предусматривающая эксплуатацию программного продукта. Базовые стратегии — Dynamic Testing Динамическое тестирование - тестовая деятельность, предусматривающая эксплуатацию программного продукта. Базовые стратегии — тестирование "черного ящика" и тестирование "стеклянного ящика" — являются динамическими. Программа запускается, вводятся данные, и программист или тестировщик анализирует результат. Разница только в том, на какой информации основывается подбор тестов.

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

Фазы процесса тестирования 1. 2. 3. 4. 5. Определение целей (требований к тестированию) Планирование: Фазы процесса тестирования 1. 2. 3. 4. 5. Определение целей (требований к тестированию) Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Разработка тестов Выполнение тестов Анализ результатов.

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

Затраты на исправление дефектов Когда дефекты попадают в требования, возникает их волнообразное распространение на Затраты на исправление дефектов Когда дефекты попадают в требования, возникает их волнообразное распространение на весь процесс разработки, устранение последствий которого требует больших затрат средств и времени. Если затраты на обнаружение и устранение дефекта на стадии формулирования требований составляют $1, то на стадии проектирования эти затраты увеличиваются до $5, на стадии кодирования — $10, на стадии модульного тестирования — $20, а после поставки программного продукта заказчику стоимость работ по устранению того же дефекта достигает $200.

Затраты на исправление дефектов Затраты на исправление дефектов

Интеграция разработки и тестирования Интеграция разработки и тестирования

Интеграция разработки и тестирования Интеграция разработки и тестирования

Причины неудачных проектов Исследование основных факторов, вызвавших перерасход средств на создание продукта или неудачу Причины неудачных проектов Исследование основных факторов, вызвавших перерасход средств на создание продукта или неудачу проекта в целом, показали, что более чем в 50% случаев эти факторы имеют отношение к процессу выработки требований к программному продукту. Основные факторы, имеющие отношение к процессу формулирования требований, повлекшие за собой провал проекта: • Неполнота требований (13. 1%) • Неучастие пользователя в разработке требований (12. 4%) • Нереалистичные ожидания (9. 9%) • Изменение требований и спецификаций (8. 7%) • Отпала потребность в системе (7. 5%). Одним из результатов этого отчета является вывод о том, что большое число дефектов может быть внесено в продукт уже на стадии формулирования требований.

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

Типы требований Функциональные средства. Интерфейсы. Данные. Производительность. Пользователи и человеческий фактор. Физическая среда. Безопасность. Типы требований Функциональные средства. Интерфейсы. Данные. Производительность. Пользователи и человеческий фактор. Физическая среда. Безопасность. Документация. Устранение неисправностей. Сопровождение. План поставки версий.

Типы требований Ø Функциональные средства. Этот набор требований определяет, какие функции должен выполнять данный Типы требований Ø Функциональные средства. Этот набор требований определяет, какие функции должен выполнять данный программный продукт на системном или пользовательском уровне. Для ясности может быть указано, чего ие должен делать данный продукт. Ø Интерфейсы. Эта категория требований описывает входы, получаемые из внешних систем, и выходы, направляемые во внешние системы. Накладываются ли на эти интерфейсы какие-то ограничения, связанные с форматами данных и носителями информации? Данные. Эти требования описывают входные и выходные данные системы. Какой при этом используется формат? Какие данные нужно сохранять? Какой объем данных поступает в систему и из системы, и с какой скоростью передачи? С какой точностью должны выполняться вычисления? Ø

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

Типы требований Ø Безопасность. Эта категория требований описывает, как осуществляется доступ к системе и Типы требований Ø Безопасность. Эта категория требований описывает, как осуществляется доступ к системе и как осуществляется управление ее данными. Данная категория является подходящим местом для описания, как должны дублироваться системные данные. Как часто следует выполнять дублирование? На каких носителях сохраняются дублированные данные? Ø Документация. Эта категория требований связана с документацией и тем, должна ли она быть представлена в печатном виде или выдается в интерактивном режиме. Кроме того, здесь же определяется категория лиц, для которых эта документация предназначена. Ø Устранение неисправностей. Эта категория требований описывает, как система реагирует на возникновение неисправностей. Будет ли система обнаруживать неисправность и выдавать аварийные сигналы? Какой должна быть средняя длительность промежутка времени между двумя неисправностями? Каким должно быть максимальное время простоя?

Типы требований Ø Сопровождение. Эти требования определяют, как производится устранение проблем, обнаруженных в системе, Типы требований Ø Сопровождение. Эти требования определяют, как производится устранение проблем, обнаруженных в системе, как усовершенствованные версии системы поставляются заказчику и как пользователи должны переходить на усовершенствованную версию системы. Ø План поставки версий. Если требованиям назначены приоритеты, возможно, необходимо будет определить временной график поставки версий, который показывает, реализации каких требований уделяется внимание в конкретной версии.

Критерии качества требований Ø Полнота. Ø Однозначность. Ø Непротиворечивость. Ø Прослеживаемость. Ø Осуществимость. Ø Критерии качества требований Ø Полнота. Ø Однозначность. Ø Непротиворечивость. Ø Прослеживаемость. Ø Осуществимость. Ø Контролепригодность.

Критерии качества требований 1. Полнота. Набор требований считается полным, если все его составные части Критерии качества требований 1. Полнота. Набор требований считается полным, если все его составные части представлены и каждая такая часть выполнена в полном объеме. При тестировании набора требований на полноту необходимо обратить особое внимание на следующие моменты: • Требования не должны содержать выражений типа "подлежит определению", "и так далее", "и прочие" и им подобных. • Требования не должны ссылаться на несуществующую справочную информацию, такую как, например, несуществующая спецификация. • Требование не должно ссылаться на функциональные средства, которые еще не определены. Ø 2. Однозначность. Каждое требование должно быть точно и ясно сформулировано; оно должно допускать единственное толкование. Требование должно быть удобочитаемым и понятным. Если требование отличается особой сложностью, для облегчения понимания может быть привлечен вспомогательный материал, такой как, диаграммы или таблицы. Если для пущей убедительности используются выражения наподобие "это очевидно" или "само собой разумеется", то вполне возможно, что автор пытается отвлечь ваше внимание от того или иного двусмысленного утверждения. Ø

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

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

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

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

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

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

Каскадная модель тестирования Ø Стадия формулирования требований. Ø Стадия системного проектирования. Ø Стадии тестирования Каскадная модель тестирования Ø Стадия формулирования требований. Ø Стадия системного проектирования. Ø Стадии тестирования проектов программ, программных кодов, модульного тестирования и комплексных испытаний. Ø Системные испытания. Ø Приемочные испытания. Ø Регрессионное тестирование.

План тестирования Ø Ø Ø Ø Идентификатор тестового плана. Введение. Тестируемые элементы. Тестируемые функции. План тестирования Ø Ø Ø Ø Идентификатор тестового плана. Введение. Тестируемые элементы. Тестируемые функции. Нетестируемые функции. Подход. Критерии прохождения тестов. Критерии приостановки и возобновления работ. Документация. Задачи тестирования. Необходимое оборудование. Ответственность. Необходимый персонал и обучение. Календарный план. Риски и непредвиденные обстоятельства. Утверждение.