вфвф. 76. Критерии эффективного проектирования
 Скачать 5.31 Mb.
|
76. Критерии эффективного проектированияКритерии проектирования соотносятся с другими и образуют понятие «качество опыта» - - определяется так: взятые вместе, критерии поднимают один ключевой вопрос: «Как эффективный интерактивный дизайн обеспечивает людям успешный и положительный опыт работы?» Модели ПИ Проектирование «интерфейса» использует модельное представление как способ восприятия мира человеком. Модели ПИ: - модель пользователя, - программиста и - проектировщика. Модель пользователя: опыт взаимодействия в реальном мире – задачи, процессы, инструменты, результаты. Модель программиста: платформа, ОС, оболочка, инструменты разработки, принципы и методы. Модель проектировщика: концептуальная модель пользователя, модель программиста, принципы и методы проектирования ПИ. Ментальная модель (ММ) не обязательно точно отображает ситуацию и ее компоненты. Пока ментальная модель помогает людям предсказывать, что произойдет далее, она будет служить для понимания, анализа и принятия решений. Когда мы переносим знания об окружающем нас мире в мир компьютеров, начинает действовать концепция метафор. Метафора – понятие, переносящее свойства или признаки одного объекта на другой для выяснения их свойства или аналогии. – помогают пользователям освоить новые для себя области деятельности, осмысляя их в терминах области, которая им уже знакома и понятна. Для ПИ программ существует три парадигмы: технологическая, метафорическая и идиоматическая. Технологическая парадигма - основана на понимании механизма работы программы - сложный подход. Метафорическая основана - на интуитивном понимании - проблематичный подход. Идиоматическая парадигма - основана на знании о том, как решать ту или иную задачу - естественный для человека процесс. 77. Психология человека и компьютера.Психология пользователей Когнитивная психология объясняет то, - как работает наш мозг, - как мы мыслим, - как мы запоминаем, - как мы обучаемся. Это информационно-процессуальная модель человеческого познания – модель, которая показывает нам схожесть человеческого познания с компьютером и то, что единая теория вычислений может быть использована для проведения исследований и проектирования в психологии и компьютерной отрасли. Но: это разные модели восприятия, и человеческое познание много сложнее простой обработки и сохранения информации. Восприятие и внимание человека – комбинирование информационных потоков, поступающих в мозг от наших органов чувств – зрения, слуха, вкуса, обоняния, осязания – со знаниями, опытом прошлого. – процесс сравнения новых образцов информации со старыми образцами. Информационный поток, состоящий из опыта и ожиданий пользователя, который осуществляется через взаимосвязь человека и компьютера. Информационные процессы человека: память и познание Хранение информации от органов чувств есть установка буферов памяти, где содержаться результаты автоматической обработки информации, полученной от наших органов чувств. Сообщение должно оставаться на экране столько времени, сколько это необходимо для того, чтобы пользователь не только прочитал его, но и понял. Человеческая система чувств воспринимает информацию от всего, что находится на дисплее компьютера. Анимация на заднем плане забавна, но если вы с ней работаете в окне, ваш мозг будет выполнять слишком много ненужных операций. Ваша система обработки информации будет занята задним планом окна, а не работой – это приведет к усталости и напряжению глаз. 78. Слабые и сильные стороны людей и компьютеров.Люди Сильные стороны: Распознавание образов; Переключение внимания; Бесконечная емкость долговременной памяти; Богатая многокодовая долговременная память; Способность к обучению Слабые стороны: Краткосрочная память с малой емкостью; Быстрая потеря данных из краткосрочной памяти; Медленная обработка данных; Ошибки; Затрудненный доступ к долговременной памяти Компьютеры Сильные стороны: Память с большой емкостью; Долговременная память; Высокая скорость обработки; Обработка без ошибок; Безотказный доступ к памяти Слабые стороны: Простое сравнение с эталоном; Ограниченные способности к обучению; Ограниченная емкость долгосрочной памяти; Ограниченная интеграция данных 79. Принципы проектирования пользовательского интерфейса.3 принципа разработки ПИ: контроль пользователем интерфейса; уменьшение загрузки памяти пользователя; последовательность ПИ. Хансен (Hansen) представил список принципов проектирования: знать пользователя; сократить запоминание; оптимизировать операции; устранить ошибки. Принципы, которые дают пользователю контроль над системой: 1 Используйте режимы благоразумно (безрежимность) 2. Предоставьте пользователю возможность выбирать: работать либо мышью, либо клавиатурой, либо их комбинацией (гибкость) 3. Позвольте пользователю сфокусировать внимание (прерываемость) 4. Демонстрируйте сообщения, которые помогут ему в работе (полезность) 5. Создайте условия для немедленных и обратимых действий, а также обратной связи 6. Обеспечьте соответствующие пути и выходы (способность ориентировки) 7. Приспосабливайте систему к пользователям с различным уровнем подготовки (доступность) 8. Сделайте ПИ более понятным (облегченность в пользовании) 9. Дайте пользователю возможность настраивать интерфейс по своему вкусу 10. Разрешите пользователю напрямую манипулировать объектами интерфейса (интерактивность) 11. Используйте режимы благоразумно Принципы, позволяющие снизить загрузку памяти пользователя Не загружайте кратковременную память (запоминание), Полагайтесь на распознавание, а не на повторение (распознавание),Представьте визуальные заставки (информирование),Предусмотрите установки по умолчанию, команды Undo и Redo, Предусмотрите «быстрые» пути (быстрота), Активизируйте синтаксис действий с объектами (интуитивность), Используйте метафоры из реального мира (перенос), Применяйте раскрытие и объяснение понятий и действий (контекст), Увеличьте визуальную яркость (организация), !Не нагружайте кратковременную память. 80. Стандарты и руководящие принципы проектирования интерфейса.Прогресс в разработке ПИ привел к появлению соответствующих стандартов сначала на уровне ведущих компаний-разработчиков, а позднее и ISO. В основе - накопленный опыт разработки и оценки качества наиболее продвинутых ПП. Стандартизация олицетворяет консервативную сторону прогресса. Выделяют классы интерфейсов:- классы, задаваемые базовыми интерактивными средствами, целесообразно разбить на подклассы, например, в пределах графического класса различаются подклассы: - двухмерные (WIMP, Windows, Icons, Menus, Pointer) и - трехмерные интерфейсы. Система управляющих средств ПИ конкретного подкласса - одновременно шаблон возможного «текста» на некотором языке пиктограмм управления и имитация с помощью средств машинной графики управляющей панели инструмента обработки данных. Роль синтаксиса играют выразительные формы интерфейса и последовательности манипуляций с ними. В таком виде интерфейса, как командная строка, язык пиктограмм вырождается в конкретный программный язык управления заданиями. Цель введения стандартов - стимулировать широкое практическое использование руководящих принципов, а также накопление опыта для их последующего уточнения и развития. Стандартизированная модель отражает, по крайней мере, минимальный набор обязательных (или общепризнанных) принципов. При проектировании ПИ исходным решением является выбор базовых стандартов типов управляющих средств интерфейса, который должен учитывать специфику соответствующей предметной области. Конкретизация стиля ПИ осуществляется в нормативных документах отраслевого и фирменного уровня. При разработке ПИ необходим учет характеристик предполагаемых конечных пользователей разрабатываемого программного средства. Спецификация типа ПИ определяет только его синтактику. Второе направление стандартизации в области проектирования - формирование конкретной системы руководящих эргономических принципов. 81. Понятие удобства применения продукта. Цели и задачи тестирования. Условие успехаПоследовательность действий, которые необходимо выполнять для тестирования. Изучение спецификации. Стадия анализа дизайна и/или требований или «тестирование спецификации». Нужно внимательно прочитать документацию (спецификацию) по приложению. Дымовое тестирование. Проверить работает ли система вообще (правильно ли работает, правильно ли «ругается» при не правильной отработке и т.д.). Это делается для того, чтоб понять пригодно ли приложение для дальнейшего тестирования или оно вообще не работает (работает не правильно). «Позитивное» тестирование. Проверить результат работы приложения при получении им «правильных» входных данных. «Негативное» тестирование. Посмотреть, как ведет себя приложение, получая на вход «неправильные» данные. Это делается для того, чтоб определить, как ведет себя приложение в таком случае. Если такой вариант описан в спецификации, а он должен быть описан, то сравнить ожидаемый результат с полученным результатом. Процесс тестирования: Проверить, как работает приложение, когда оно получает на вход «правильные» данные. Если все работает и работает правильно, следующим шагом является проверка граничных значений (т.е. там, где начинаются «правильные» данные и там где они заканчиваются); Проверка работы приложения при вводе данных, которые не входят в область допустимых значений. Наиболее распространена на сегодняшний день экспертная оценка. Это достаточно экономичный и оперативный вид работ, позволяющий в кратчайшее время выявить основные проблемы и наметить пути их решения. Зачастую используются методы лабораторного тестирования: пользователям дается определенное задание, и процесс его выполнения записывается на видеопленку (при этом фиксируются и их действия, и то, что они видят на экране компьютера). Затем специалист по проектированию интерфейсов (при необходимости вместе с разработчиками) анализирует полученную видеозапись и выявляет интерфейсные решения, вызвавшие наибольшие затруднения. «Интерфейс» документации тоже должен быть надлежащего качества. Язык, структура подачи материала, доступность для понимания, возможности поиска нужной информации представляют собой характеристики, исключительно важные для пользователя и непосредственно влияющие на его общее впечатление о программном продукте. Хорошо написанная документация часто маскирует недостатки программирования. 82. Этапы разработки пользовательского интерфейса.Коллективный подход к разработке Идеальная команда для разработки ПП (+ПИ) должна обладать следующими навыками: - проблемный анализ, - программирование, - разработка ПИ и команд, - графическое проектирование, - написание технической документации, - тестирование на удобство применения. + специалисты по вопросам бизнеса. Цель разработки - создание единого интерфейса для всех пользователей!!! Первый этап - действия по сбору и анализу информации - 5 шагов:1. определение профиля пользователей; 2. анализ стоящих перед ними задач; 3. сбор требований, предъявляемых клиентами; 4. анализ рабочей среды пользователей; 5. соответствие требований пользователей стоящим перед ними задачам. Этап разработки: определение цели с точки зрения удобства применения продукта; разработка задач и сценария действий пользователей; определение целей и операций интерфейса; определение иконок объектов и визуального представления; разработка меню объектов и окон; оптимизация визуальной разработки. Третий шаг, самый сложный в процессе разработки: выделить объекты, данные и действия из сценариев и задач, стоящих перед пользователями; просмотреть и уточнить список объектов и действий совместно с пользователями; начертить диаграмму взаимодействия между объектами; заполнить матрицу прямого манипулирования объектами. Разработка иконок объектов Разработчики видят объекты не так, как пользователи. Поэтому имеет смысл предоставить графическим разработчикам возможность делать эту работу вместе с пользователями. Разработка визуальных представлений После создания компьютерных иконок для объектов вы можете показать, как будут выглядеть некоторые объекты-контейнеры при открытии, поскольку они будут содержать некоторый набор объектов, представленный в виде иконок. Разработка меню объекта и окна Список объектов и действий и матрица прямого манипулирования объектами из третьего шага являются отправными пунктами для пятого шага. Теперь самое время перестроить эти схемы и определить действия, относящиеся к объектам, представленным в виде иконок, а также к открытым в окнах просмотра. Разработчики должны обязательно присутствовать при проведении тестирования. Разработка и проектирование ПП могут потребовать внедрения множества подсистем, сетей, БД, др. программ и т.д. ОС, языки программирования и инструментарий для проектирования определяются раньше, еще до разработки ПИ. Разработка на базе системы может предопределить тип проектируемого ПИ. 83. Визуальный дизайн.Наиболее эффективна зрительная модальность, поскольку зрительный анализатор принимает информацию очень быстро в образной форме, а слуховой последовательно с некоторой задержкой. Визуальное оформление можно разделить на 3 условных части: Дизайн интерфейса – это организация элементов, облегчающая взаимодействие; Дизайн навигации – организация элементов, упрощающая управление; Информационный дизайн – организация элементов для донесения информации до пользователя. Визуальное оформление отвечает: - за эстетическое восприятие информации оператором, - за эффективность поддержки целей, определенных на каждом из нижележащих уровней, - за целостность всей структуры системы На визуальное оформление ложится задача системы: - по удовлетворению пользователя, - созданию комфортных для него условий выполнения профессиональных обязанностей. Основные характеристики визуального оформления: цвет, анимация, форма, графика, текст и расположение представляемой информации, дополнительной характеристикой м. являться звук. Основные характеристики визуального оформления определяют направление движение зрачков, выделяя при этом доминирующие элементы. Если дизайн ПИ удачен, то траектория движения взгляда по странице обладает 2 важными характеристиками: 1) Она плавная. Когда люди говорят, что дизайн «тяжелый» или «громоздкий», они в действительности реагируют на тот факт, что дизайн не ведет их плавно по странице. Их взгляд перескакивает с одного элемента на другой, поскольку все элементы настойчиво требуют внимания. 2) Предлагает пользователю своего рода «экскурсию» по странице, раскрывая имеющиеся возможности, но, не перегружая его подробностями. Основной инструмент привлечения внимания пользователя - контраст. Контраст - для привлечения внимания пользователя к существенным аспектам интерфейса, - помогает пользователю разобраться в отношениях между навигационными элементами, - основное средство обозначения концептуальных групп в информационном дизайне. - привлекает пользователя к объекту, заставляя его быстрее реагировать на изменение ситуации и принимать необходимые решения. 84. Единообразие в дизайне.- существенно помогает выстроить эффективную коммуникацию с оператором, не запутывая и не перегружая. - проявляет себя во многих аспектах визуального дизайна (например, единый размер элементов облегчает их комбинирование и реорганизацию при необходимости). - помогает повышать толерантность операторов к системе, обеспечивая формированию у него стереотипов деятельности, - дает чувство контроля над системой, повышая процент интуитивно выполняемых действий. - помогает решить проблемы внутренней рассогласованности системы (объекты должны образовать систему, работающую как непротиворечивое единое целое). Неудачное визуальное представление ПИ вместо ожидаемого облегчения трудовой деятельности увеличивает психологическую напряженность труда, → причина - возникновения ошибок, - снижения скорости выполнения задач, - низкой удовлетворенности трудом пользователя. 85. Понятие иммерсивного интерфейса.Такие среды - иммерсивные (погружающие) среды. В них реализованы любые формы связи человека с содержанием среды, образующие иммерсивный интерфейс. При этом классическая методология, описывающая линейные отношения человека с физическим миром в рамках концепции отражения не работает. - Теория иммерсивных сред: понятие интерфейса расширяется на все формы взаимодействий (физические, информационные) человека со средой, формирующие эффективную систему взаимодействий. К интерфейсу относятся внешние физические атрибуты связи, психические механизмы, формирующие устойчивые формы взаимодействий человека со средами. Иммерсивный интерфейс в виртуальных средах Интерфейс характеризует свойства и технологию человеко–машинной связи, обеспечивающей деятельность человека в технической или социальной системе. Интерфейс обеспечивает условия, порождающие профессиональную /обучающую среду.   86. Системы иммерсивного интерфейса на базе индуцированных сред.Нужно отличать средства интерфейса как совокупность технико–технологических и программно–аппаратных решений от среды генерируемой данными средствами. Системы иммерсивного интерфейса с «тождественным отображением» – генерируемая в них виртуальная среда точно повторяет эволюцию и содержание реальной среды, а виртуальная копия управляемого объекта дублирует наблюдаемое поведение реального управляемого объекта, подчиняющегося командам оператора. Пример систем данного класса - классические системы дистанционного управления. Они позволяют: - вывести оператора из опасной рабочей зоны ; - исключить действие на оператора экстремальных физических факторов; - избежать длительного срока доставки оператора до места деятельности. Системы иммерсивного интерфейса для «слежения в неоптических диапазонах» – являются вариантом систем с тождественным отображением. В них в качестве источника информации об объекте наблюдения используются данные о положении маркеров систем телеметрии, расположенных на управляемом объекте. При этом объект управления непосредственно оператором не наблюдаем. Основная проблема – выделение и генерация параметров фона и объекта в виртуальной сцене, которые могут быть реализованы в виде синхронизируемого фона, или в фиксированной, использующей абстрактную, не связанную с естественной средой, форме. В качестве примера такого рода систем можно рассматривать тепловизоры и приборы ночного видения. Системы «фильтрующие отображение», – в генерируемой среде повторяются только важные для выполнения профессиональной задачи элементы «реальной среды», объекты управляются синхронно. Системы, «реконструирующие отображение», – в генерируемой среде создается объект, обладающий иной, нежели реальный объект управления, перцептивной формой, но они синхронизированы между собой по основным рабочим признакам реального объекта. 87. Технические документы информационных системНазначение ТД - составляющая проекта на всем протяжении ЖЦ. Комплекс ТДрегламентирует деятельность разработчиков -нормативно-методическое обеспечение (НМО):
НМО регламентирует порядок разработки, общие требования к составу и качеству ПО, связям между компонентами, определяет содержание проектной и программной документации. Основное назначение ТД - обеспечение эффективных процедур разработки и использования ИС как ПП + организация обмена между разработчиками и пользователями ИС. Функции ТД:
Требования к ТД:
88. Стандарты в области информационных систем.  89. Программные документы по фазам ЖЦ |
| на подсистемы ИС; | на программные средства. |
В ТЗ указываются
| назначение объекта, | стадии разработки конструкторской документации, | сроки исполнения и т.д., |
| область его применения, | ее состав, | + ее состав, |
ТЗ составляют на основе анализа результатов предпроектного обследования, расчетов и моделирования. Как инструмент коммуникации в связке общения заказчик- исполнитель, ТЗ позволяет:
обеим сторонам
| представить готовый продукт; | выполнить попунктную проверку готового продукта; | уменьшить число ошибок, связанных с изменением требований в результате их неполноты или ошибочности (на всех стадиях и этапах создания, кроме испытаний); |
заказчику
| осознать, что именно ему нужно; | требовать от исполнителя соответствия продукта всем условиям, оговоренным в ТЗ; |
исполнителю
| понять суть задачи, показать заказчику технический облик будущего программного изделия или автоматизированной системы; | спланировать выполнение проекта и работать по намеченному плану; | отказаться от выполнения работ, не указанных в ТЗ. |
92. Эскизный и технический проекты.
Эскизный проект (ЭП) – для создания прообраза будущей АС. Разработчик определяет основные контуры будущей системы, получает представление об основных чертах будущего объекта автоматизации и анализирует их возможную применимость в последующей работе.
В результате оформляется, согласовывается и утверждается документация в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию системы.
При разработке ЭП составляются:
Ведомость ЭП (общая информация по проекту). Структурная схема комплекса техн.средств (техническая составляющая АС, включающая в себя набор серверов, рабочих станций, схему ЛВС и структурированной кабельной системы).
Пояснительная записка к ЭП (вводная информация, позволяющая ее потребителю быстро освоить данные по конкретному проекту).
Схема функциональной структуры (описание задач, которые будут использоваться в работе подсистем).
Схема организационной структуры (описание организационной структуры организации, которая будет использовать создаваемую автоматизированную систему в практической работе).
Схема автоматизации (логический процесс создания автоматизированной системы от начала до конца)
93. Спецификация.
В отличие от компьютерной программы спецификация обращена, прежде всего, к человеку и представляет собой описание в терминах, характерных для самой задачи, а не для ее реализации.
Необходимость спецификации: можно получить точную оценку стоимости, рисков и затрат
времени; спецификация служит основой для формирования другой ТД; клиент может более четко сформировать собственное видение проекта; нет дублирования задач; заказчик и исполнитель будут иметь одинаковое представление о продукте; спецификация позволяет структурировать проблемы, чтобы решать их проще и быстрее; спецификация может помочь выявить оптимальный набор функций; спецификация помогает понять, какие результаты считаются оптимальными при тестировании.
К основным свойствам спецификации можно отнести следующее: спецификация не должна содержать деталей реализации, в отличие от программы она указывает, что надо сделать, а не как это делать; спецификация должна быть понятной, в общем случае она должна быть более понятным описанием задачи, чем программа, так как краткость не всегда содействует ясности и понятности;
спецификация должна обладать формальностью, причем диапазон требований очень широк – от полностью формализованного описания до слегка формализованного; спецификация должна обладать полнотой описания задачи, ничто существенное не должно быть упущено.
В спецификации программы выделяют по меньшей мере две существенно разные части:
Функциональная спецификация. Описывает функции программы, решающей задачу.
Как правило, спецификация содержит следующие разделы:
1. Введение; Цели; Определения, сокращения и аббревиатуры; Масштаб проекта; Организационное построение спецификации. 2. Общее описание; Обзор ПП, его взаимосвязь с другими продуктами или проектами, будет ли он независимым или станет частью более крупной системы; Характеристика пользователей и то, как она влияет на требования к ПО; Функции продукта; Общие ограничения. 3. Требования; Функциональные требования; Эксплуатационные требования, которые определяют критерии для оценки важных параметров работы системы; Может быть приведена аргументация необходимости тех или иных требований. 4. Специальные требования. Схема информационных потоков 5. Модели. Помогут сформировать представление о базовой структуре и пользовательском интерфейсе.
94. Рабочая документация.
Состав рабочей документации: руководство пользователя (РП), руководство администратора, руководство программиста, руководство оператора, руководство системного администратора, руководство системного программиста.
Основная цель - обеспечение пользователя необходимой информацией для самостоятельной работы с программой или АС
Структура РП: 1. Введение. Раздел должен предоставлять пользователю общую информацию о программе (системе): область применения; краткое описание возможностей; уровень подготовки пользователя. 2. Перечень эксплуатационной документации. Перечисляется документация, которая позволит пользователю избежать определенного рода ошибок. 3. Назначение и условия применения. Подразделяет основную задачу программы (системы) на подзадачи и описывает каждую из них: виды деятельности, функции, для автоматизации которых предназначено данное средство автоматизации; условия, при соблюдении (выполнении, наступлении) которых обеспечивается применение средства автоматизации в соответствии с назначением (например, вид ЭВМ и конфигурация технических средств, ОС и общесистемные программные средства, входная
информация, носители данных, БД, требования к подготовке специалистов и т. п.).
4. Подготовка к работе. Должен содержать пошаговую инструкцию для запуска программы + можно отнести установку дополнительных приложений, идентификацию, аутентификацию: состав и содержание дистрибутивного носителя данных; порядок загрузки данных и программ.
5. Проверка работоспособности. Описываются показатели, позволяющие определить, что ПО работает нестабильно.
6. Описание операций. Содержит пошаговую инструкцию для выполнения того или иного действия пользователем.
7. Аварийные ситуации. Описываются действия в случае длительных отказов технических средств, обнаружении несанкционированного вмешательства в данные, действия по восстановлению программ или данных.
95. Руководство программиста.
96. Руководство пользователя.
97. План управления конфигурацией ПО. 108. Lean (бережливая разработка ПО)
98. Обеспечение качества и тестирование ПО. Основные понятия и определения
99. Характеристика качества ПО.
100. Модель качества ПО
(Многоуровневая модель качества ПО, представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО, каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки).
101. Причины появления дефектов в программном коде.
102. Принципы тестирования.
Тестирование ПО – креативная и интеллектуальная работа.
1. Тестирование показывает наличие дефектов Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие. Важно составлять тест-кейсы, которые будут находить как можно больше багов. Т.о., при должном тестовом покрытии, тестирование позволяет снизить вероятность наличия дефектов в ПО. Даже если дефекты не были найдены при тестировании, нельзя утверждать, что их нет.
2. Исчерпывающее тестирование невозможно Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации пользовательского ввода и состояний системы, за исключением примитивных случаев. Вместо этого необходимо использовать анализ рисков и расстановку приоритетов, что позволит более эффективно распределять усилия по обеспечению качества ПО.
3. Раннее тестирование Тестирование д. начинаться как можно раньше в ЖЦ разработки ПО и его усилия д.б. сконцентрированы на определенных целях.
4. Скопление дефектов Разные модули системы могут содержать разное количество дефектов, о есть плотность скопления дефектов в разных элементах программы может отличаться. Усилия о тестированию должны распределяться пропорционально фактической плотности дефектов. В основном, большую часть критических дефектов находят в ограниченном количестве модулей.
5. Парадокс пестицида Прогоняя одни и те же тесты, Вы столкнетесь с тем, что они находят все меньше новых ошибок. Система эволюционирует, многие из ранее найденных дефектов исправляют и старые тест-кейсы больше не срабатывают. Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в используемые тесты, рецензировать и корректировать их с тем, чтобы они отвечали новому состоянию системы и позволяли находить большее количество дефектов.
103. Методы оценки характеристик качества.
104. Принципы и методы обеспечения надежности ПО
105. Классификации моделей надежности программных средств
106. Типовая структура показателей качества
107.Причины появления дефектов в программном коде. QA, QC и тестирование.
