Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Sweebok создатель Mind Map: Sweebok

1. Конструирование

1.1. Основы конструирования

1.1.1. Минимизация сложности

1.1.1.1. Основной причиной использования компьютеров, являются ограниченные возможности людей в обработке и хранении и больших объемов информации (минимизация сложности)

1.1.2. Ожидание изменений

1.1.2.1. программные системы являются частью изменяющейся среды и должны меняться вместе с ней

1.1.3. Конструирование с возможностью проверки

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

1.1.4. Стандарты в конструировании

1.1.4.1. Стандарты, которые напрямую применяются при конструировании, включают себя:

1.1.4.1.1. языки программирования и соответствующие стили кодирования (например, Java Language Specification, являющийся частью стандартной документации JDK – Java Development Kit и Java Style Guide, предлагающий общий стиль кодирования для языка программирования Java)

1.1.4.1.2. Коммуникационные методы (стандарты форматов документов и <оформления> содержания)

1.1.4.1.3. платформы

1.1.4.1.4. инструменты (средства конструирования) UML как один из стандартов для определения нотаций для диаграмм, представляющих структура кода и его элементов или некоторых аспектов поведения кода

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

1.2. Управление конструированием

1.2.1. Модели конструирования

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

1.2.2. Планирования конструирования

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

1.2.3. Изменение в конструировании

1.2.3.1. исходный разработанный код, и модифицированный объем кода, и степень повторного использования, и многие другие характеристики.

1.3. Практические соображения

1.3.1. конструирование (в большей степени, чем любая другая область знаний) ведется на основе практических соображений и техник.

1.3.2. Проектирование в конструировании

1.3.2.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования.

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

1.3.3. Языки конструирования

1.3.3.1. Языки конструирования включают все формы коммуникаций, для решение проблемы

1.3.4. Кодирование

1.3.4.1. активное применение следующих соображений и техник:

1.3.4.1.1. техники создания легко понимаемого исходного кода

1.3.4.1.2. использование классов, переменных, именованных констант

1.3.4.1.3. документирование кода

1.3.5. Тестирование в конструировании

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

1.3.6. Повторное использование

1.3.7. Качество конструирования

1.3.7.1. Существует ряд техник, предназначенных для обеспечения качества кода. (фокус на программном (исходном) коде)

1.3.7.1.1. тестирование

1.3.7.1.2. пошаговое кодирование

1.3.7.1.3. технические обзоры и оценки

1.3.7.1.4. и т.п.

1.3.8. Интеграция

1.3.8.1. некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением.

2. Ключевые вопросы поддержки и эксплуатации

2.1. Технические вопросы

2.1.1. Ограниченное понимание

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

2.1.2. Тестирование

2.1.2.1. Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости.

2.1.3. Анализ влияния

2.1.3.1. Анализ влияния описывает как проводить полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.

2.1.4. Возможность сопровождения

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

2.2. Управленческие вопросы

2.2.1. Согласование с организационными целями

2.2.1.1. сопровождение системы преследует цели максимального продления срока эксплуатации программного обеспечения. Такой подход может основываться на необходимости обновления и расширения программного обеспечения

2.2.2. Проблемы кадрового обеспечения

2.2.2.1. Данная тема касается вопросов привлечения и удержания квалифицированного персонала по сопровождению.

2.2.3. Процесс

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

2.2.4. Организационное аспекты сопровождения

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

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

2.2.5. Аутсоурсинг

2.2.5.1. Суть его заключается в передаче работ, в первую очередь, вспомогательных “на сторону”. Крупные корпорации передают в управление другим организациям целые портфели программных систем, а, иногда, и целиком всю ИТ-инфраструктуру.

3. Поддержка при эксплуатации

3.1. Основы поддержки и эксплуатации

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

3.2. Процесс

3.2.1. Процессы сопровождения

3.2.1.1. Процесс сопровождения начинается по стандарту IEEE 1219 с момента передачи программной системы в эксплуатацию и касается таких вопросов, как планирование деятельности по сопровождению

3.2.2. Работы по сопровождению

3.2.2.1. В сопровождении необходимо проводить анализ, проектирование, кодирование, тестирование и документирование.

3.2.3. Уникальные работы

3.2.3.1. Существует ряд процессов, работ и практик, уникальных для деятельности по сопровождению.

3.2.3.1.1. Передача ПО на поддержку

3.2.3.1.2. Принятие/отклонение запросов на модификацию

3.2.3.1.3. Анализ влияния

3.2.3.1.4. Контракты и обязательства

3.2.4. Работы по планированию сопровождению

3.2.4.1. Планирование является более чем необходимым для адекватного проведения работ по сопровождению

3.2.4.1.1. структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового менеджмента и управления человеческими ресурсами.

3.3. Техники сопровождения

3.3.1. Понимание программных систем

3.3.1.1. Специалист по сопровождению должен понимать программный продукт и читает для этого составленную по ПО документацию. Чтобы можно было работать с кодом системы.

3.3.2. Реинжиниринг

3.3.2.1. Реинжиниринг определяется как детальная оценка и перестройка программного обеспечения.

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

3.3.3. Обратный инжиниринг

3.3.3.1. Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения.

4. Требования

4.1. Основы требований

4.1.1. Требование - это...

4.1.1.1. некоторое условие или возможность, свойство которое должно соответствовать система.

4.1.1.1.1. и разделяются на ..

4.1.2. Требование бывает...

4.1.2.1. К продукту или процессу

4.1.2.1.1. Есть требования к продукту, который будет разрабатываться, а есть требования к процессу этой разработки.

4.1.2.2. Функциональные и Нефункциональные

4.1.2.2.1. Функциональные

4.1.2.2.2. Нефункциональные

4.1.2.3. Системные и программные

4.1.2.3.1. Системные

4.1.2.3.2. Программные

4.1.2.4. Независимые или общие свойства

4.1.2.4.1. эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами

4.1.2.5. Требования с количественной оценкой

4.1.2.5.1. требования, поддающиеся количественному определению/измерению

4.1.3. Свойства требований:

4.1.3.1. 1. Полнота

4.1.3.1.1. Описывает все то, что требуется от разрабатываемой системы.

4.1.3.2. 2. Ясность

4.1.3.2.1. Должно воспринимается всеми совладельцами системы одинаково.

4.1.3.3. 3. Корректность - Согласованность

4.1.3.3.1. Требования не должны противоречить требованиям своего уровня иерархии и требованиям "родителя"

4.1.3.4. 4. Верифицируемость (пригодность к проверке)

4.1.3.4.1. Существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемом участниками процесса создания информационной системы, причем оно является полным, т.е. ни одна из важных для реализации деталей не упущена - значит, это требование можно проверить.

4.1.3.5. 5. Необходимость и полезность

4.1.3.6. 6. Осуществимость

4.1.3.6.1. Баланс между ценностью (степенью необходимости и полезности) и потребными ресурсами.

4.1.3.7. 7. Трассируемость

4.1.3.7.1. Трассируемость требования определяется возможностью отследить связь между требованиями различного уровня в системе.

4.1.3.8. 8. Упорядоченность по важности

4.1.3.8.1. Приоритет требования представляет собой степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика.

4.2. Изучение требований

4.2.1. Стратегии выявления требований:

4.2.1.1. Анкетирование

4.2.1.2. Самостоятельное описание требований

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

4.2.1.3. Интервьюирование

4.2.1.3.1. Подготовка

4.2.1.3.2. Проведение интервью

4.2.1.3.3. Завершение

4.2.1.3.4. информация должна быть проанализирована и трансформирована в требования

4.2.1.4. Наблюдение

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

4.2.1.5. Совместный семинар

4.2.1.5.1. особая форма встреч участников проекта и заинтересованных лиц со стороны заказчика, посвященная обсуждению тех вопросов, ответы на которые не могут быть определены в результате обычных интервью и которые требуют вовлечения большего количества лиц, чем просто пары “пользователь-аналитик”.

4.2.1.6. Прототипирование

4.2.1.6.1. Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика с последующим его улучшением и тестированием.

4.2.2. Концептуальное моделирование

4.2.2.1. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.

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

4.2.2.2.1. Природа проблемы (проблемной области)

4.2.2.2.2. Экспертиза и опыт инженеров

4.2.2.2.3. Требования заказчика к процессу

4.2.2.2.4. Доступность методов и инструментов

4.2.2.2.5. Внутрикорпоративные стандарты и регламенты

4.2.2.2.6. Культура разработки

4.2.3. Источники требований:

4.2.3.1. Заказчик

4.2.3.2. Документация

4.2.3.3. Группа работников предприятия

4.2.3.4. Прототип

4.3. Анализ требований

4.3.1. Классификация требований

4.3.1.1. Функциональные и нефункциональные требования

4.3.1.2. Требование к процессу или продукту

4.3.1.3. Приоритет требований

4.3.2. Разработка модели проблемы реального мира – ключевой элемент анализа требований. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы.

4.3.3. Архитектурное проектирование и распределение требований

4.3.3.1. Стандарт ISO12207

4.3.3.2. Модель Захмана

4.3.3.2.1. Модель Закмана — метод описания архитектуры предприятия.

4.3.3.3. TOGAF

4.3.3.3.1. Методология для систематического управления архитектурой предприятия, которая предлагает подход для проектирования, планирования, внедрения IT-архитектуры предприятия и управления ей.

4.4. Процесс работы

4.4.1. Модель процесса определения требований

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

4.4.2. Участники процессов

4.4.2.1. Пользователи

4.4.2.2. Заказчики

4.4.2.3. Аналитики

4.4.2.4. Регуляторы

4.4.2.4.1. Делают все по закону

4.4.2.5. Инженеры по ПО

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

4.4.3. Управление и поддержка процессов

4.4.3.1. Распределение ресурсов

4.4.3.2. Инициация и определение содержания

4.4.3.2.1. Инициация проекта– это убеждение руководства организации (или инвесторов) в необходимости выполнения проекта. Происходит четкое определение целей и задач проекта, назначение руководителя проекта, разработка устава, идентификация участников и заинтересованных лиц.

4.4.3.3. Управление в программной инженерии

4.4.3.3.1. Средства поддержки разработки ПО - это системы, помогающие в разработке и сопровождении программ.

4.4.3.3.2. CASE - это набор средств, предназначенных для как можно более полной стандартизации процесса разработки ПО.

4.4.4. Качество процессов

4.4.4.1. Измерение и количественная оценка

4.4.4.1.1. Контроль качественных показателей приводит к улучшению количественных показателей. Качественные показатели— это причина. Количественные показатели— следствие.

4.4.4.2. Планирование и реализация процесса улучшения

4.4.4.2.1. нет смысла заниматься улучшением ради улучшения, нужно четко понимать какая в настоящее время есть проблема в работе с требованиями, и насколько эта проблема значима, и только потом приступать к ее устранению, в частности через улучшение процессов.

4.5. Спецификация требований

4.5.1. Определение системы

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

4.5.1.2. Содержание документа определяет требования, часто – стратегические цели, для достижения которых создается программная система.

4.5.2. Спецификация системных и программных требований

4.5.2.1. спецификация системных требований описывает деятельность системных инженеров

4.5.2.1.1. Стандарт IEEE 1233 является одним из признанных руководств по разработке системных требований.

4.5.2.2. Программные требования устанавливают основные соглашения между пользователями (заказчиками) и разработчиками (исполнителями) в отношении того, что будет делать система и чего от нее не стоит ожидать.

4.5.2.2.1. Стандарт IEEE 830 является классическим примером стандарта на содержание структурирование и методы описания программных требований

4.6. Проверка требований

4.6.1. Прототипирование

4.6.1.1. быстрая «черновая» реализация базовой функциональности будущего продукта/изделия, для анализа работы системы в целом.

4.6.1.2. Превращение прототипа в реальную систему

4.6.2. Утверждение модели

4.6.2.1. Уверенность в соответствии модели заданным требованиям может быть закреплена формально со стороны пользователей/заказчика.

4.6.3. Приемочный тест

4.6.3.1. Требования, которые не могут быть проверены и утверждены – это всего лишь “пожелания”. Именно так они буду восприниматься разработчиками, даже в случае их высокой значимости для пользователей. Если описанное требование не сопровождается процедурами проверки – в большинстве случаев говорят о недостаточной детализации или неполном описании требования и, соответственно, требование должно быть отправлено на доработку.

4.7. Проектирование соображений

4.7.1. Интерактивная природа процесса работы с требованиями

4.7.1.1. Необходимо понимать неизбежность изменений и планировать шаги по уменьшению проблем, связанных с изменениями требований.

4.7.2. Управление изменениями

4.7.2.1. Им посвящена тема управления изменениями в приложении к требованиям.

4.7.3. Атрибуты требований

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

4.7.4. Трассировка требований

4.7.4.1. Трассировка является фундаментальной основой проведения анализа влияния при изменении требований, помогая предсказывать эффект от внесения таких изменений.

4.7.5. Измерение требований

4.7.5.1. С практической точки зрения, обычно полезно иметь нечто, позволяющее определить “объем” требований для заданного (создаваемого) программного продукта. Это число полезно для исследования “масштабов” изменений в требованиях.

5. Проектирование программного обеспечение

5.1. Основы проектирования

5.1.1. Эта секция вводит концепции, понятия и терминологию в качестве основы для понимания роли и содержания проектирования (как деятельности) и дизайна (архитектуры, как результата) программного обеспечения.

5.1.2. Общие концепции проектирования

5.1.2.1. Концепция- главный замысел, руководящая идея. Концепция определяет стратегию действий.

5.1.2.2. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.

5.1.3. Контекст проектирования

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

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

5.1.4. Процесс проектирования

5.1.4.1. Выходом этого процесса является реализации требований в программном коде.

5.1.4.2. Проектирование в основном рассматривается как двух-шаговый процесс:

5.1.4.2.1. Архитектурное проектирование – декомпозиция структуры и организации компонент;

5.1.4.2.2. Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.

5.1.5. Техники применения

5.1.5.1. техники применения рассматривают методы и подходы к проектированию по.

5.1.5.1.1. Абстракция

5.1.5.1.2. Связанность и соединение

5.1.5.1.3. Декомпозиция и разбиение на модули

5.1.5.1.4. Инкапсуляция/сокрытие информации

5.2. Ключевые вопросы проектирования

5.2.1. Как проводить декомпозицию? Как организовать и объединить компоненты в единую систему? Как обеспечить необходимую производительность?

5.2.2. Параллелизм в проектировании

5.2.2.1. Эта тема охватывает вопросы, подходы и методы организации процессов, эффективности, синхронизации и распределения (по времени) обработки информации.

5.2.3. Контроль и обработка событий

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

5.2.4. Ошибки обработка исключений и защищенность от сбоев

5.2.4.1. формулируется достаточно просто – как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы.

5.2.5. Взаимодействие и представление

5.2.5.1. Тема касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей.

5.2.6. Сохраняемость данных

5.2.6.1. Именно сохраняемость, а не сохранность, так как тема касается не доступа к базам данных, как такового, а также не гарантий сохранности информации. Суть вопроса – как должны обрабатываться “долгоживущие” данные.

5.3. Структура и архитектура ПО

5.3.1. Архитектурные структуры и точки зрения

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

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

5.3.2. Архитектурные стили

5.3.2.1. Архитектурный стиль, по своей сути, шаблон проектирования.

5.3.3. Шаблоны проектирования

5.3.3.1. общее решение общей проблемы в заданном контексте

5.3.3.1.1. Если мы хотим организовать системы таким образом, чтобы существовал один и только один экземпляр заданного ее компонента в процессе работы с данной системой – мы можем использовать шаблон проектирования

5.3.4. Свойства программ и фреймворков

5.3.4.1. фреймворки, обеспечивают решение одних и тех же задач

5.4. Анализ качества и оценка программного дизайна

5.4.1. Атрибуты качества

5.4.1.1. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п.

5.4.2. Анализ качества

5.4.2.1. распространены многие инструменты, техники и практики, помогающие добиться качественного дизайна:

5.4.2.1.1. обзор дизайна архитектуры членами проектной команды;

5.4.2.1.2. трассировка с требованиями

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

5.4.3. Измерения

5.4.3.1. Также известные как метрики. Могут быть использованы для количественной оценки.

5.4.3.1.1. например, размера <проекта>, структуры (ее сложности).

5.5. Нотации проектирования ПО

5.5.1. Часто под нотацией подразумевают визуальное (графическое) представление.

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

5.5.2. Структурные описания, статический взгляд

5.5.2.1. Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна.

5.5.3. Поведение описания, динамический взгляд

5.5.3.1. Следующие нотации и языки используются для описания динамического поведения программных систем и их компонентов (часть из которых – графические, часть - текстовые).

5.6. Стратегии и методы проектирования

5.6.1. Существуют различные общие стратегии, помогающие в проведении работ по проектированию.

5.6.1.1. методологии, сконцентрированные на процессе (в частности, проектирования) и предполагающие следование определенным правилам и соглашениям, в том числе – по используемым выразительным средствам.

5.6.2. Общие стратегии

5.6.2.1. Это обычно часто упоминаемые и общепринятые стратегии:

5.6.2.1.1. проектирование “сверху-вниз” и “снизу-вверх”

5.6.3. Функционально-ориетированный

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

5.6.4. Проектирование на основе структур данных

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

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

5.6.5. Компонентное проектирование

5.6.5.1. Проводится распределение системных функций по различным компонентам

5.6.6. Другие методы

6. Тестирование

6.1. Основы тестирования

6.1.1. Терминология тестирования

6.1.1.1. Тестирование – деятельность, выполняемая для оценки и улучшения качества программного обеспечения. Эта деятельность, в общем случае, базируется на обнаружении дефектов и проблем в программных системах.

6.1.1.1.1. Есть множество терминов, описывающих нарушение функционирования программных систем – недостатки, дефекты, сбои, ошибки и др.

6.1.2. Ключевые вопросы

6.1.2.1. Критерии отбора тестов/критерии адекватности тестов

6.1.2.1.1. Критерии отбора тестов могут использоваться как для создания набора тестов, так и для проверки, насколько выбранные тесты адекватны решаемым задачам (тестирования).

6.1.2.2. Эффективность тестирования/Цели тестирования

6.1.2.3. Тестирование для идентификации дефектов

6.1.2.3.1. подразумевает успешность процедуры тестирования, если дефект найден.

6.1.2.4. Теоретические и практические ограничения тестирования

6.1.2.4.1. тестирование программы может использоваться для демонстрации наличия дефектов, но никогда не покажет их отсутствие

6.1.2.5. Приёмочное тестирование

6.1.2.5.1. Проверяет поведение системы на предмет удовлетворения требований заказчика.

6.1.2.6. Установочное тестирование

6.1.2.6.1. данные тесты проводятся с целью проверки процедуры установки системы в целевом окружении.

6.1.2.7. Функциональные тесты/тесты соответствия

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

6.2. Уровни тестирования

6.2.1. Приемочное тестирование

6.2.1.1. Проверяет поведение системы на предмет удовлетворения требований заказчика.

6.2.2. Модульное тестирование

6.2.2.1. Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы.

6.2.3. Интеграционное тестирование

6.2.3.1. Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.

6.2.4. Системное тестирование

6.2.4.1. Системное тестирование охватывает целиком всю систему. Большинство функциональных сбоев должно быть идентифицировано еще на уровне модульных и интеграционных тестов.

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

6.3.1. Измерение результатов тестирования касается оценки качества получаемого продукта

6.3.2. Плотность дефектов

6.3.3. Эффективность тестирования

6.3.4. Плотность покрытия требований

6.4. Техники тестирования

6.4.1. Техники базирующиеся на природе приложения

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

6.4.2. Тестирование ориентированные на дефекты

6.4.2.1. Как это ни странно звучит на уровне названия таких техник тестирования, они, действительно, ориентированы на ошибки. Точнее – на специфические категории ошибок.

6.4.3. Техники, базирующиеся на интуиции и опыте инженера

6.4.3.1. Тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.

6.4.4. Техники, базирующиеся на условиях использования

6.4.4.1. Базируется на условиях использования системы.Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы.

6.4.5. Выбор и комбинации различных техник

6.4.5.1. Оба подхода не должны противопоставляться, но дополнять друг друга.

6.5. Процесс тестирования

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

6.5.2. Процесс тестирования определяет “правила игры” для членов команды тестирования