БАЗА ПО ПИ

TODO:

тестирование интерфейса (5)
42-51 слайды Архитектура ИС (6)
!!!(7)

📘 1. Тестирование в жизненном цикле программного обеспечения

🧩 Общие понятия

Жизненный цикл программного обеспечения (ЖЦ ПО) — период от идеи создания ПО до снятия его с экспулатации.

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

Роль тестирования:

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

🔁 Тестирование в различных моделях ЖЦ ПО

📌 Водопадная модель (Каскадная модель, waterfall)

Этапы:

Общее планирование -> Пользовательские требования -> Системные требования -> Техническая архитектура -> Детализированный дизайн -> Разработка и отладка (начинает в явном виде проявляться тестирования) -> Интеграция и модульные тесты -> Инсталляционное тестирование -> Системное тестирование -> Приемочное тестирование -> Итоговая отчетность

Особенности:

Тестирование идет после завершения реализации.
Цена ошибки значительно растет в конце.
Нельзя вернуться на предыдущий этап

📌 V-модель (Verification and Validation)

Упрощённо можно сказать, что на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «наподъёме». Тестирование здесь появляется уже на самых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем.

Характеристики:

Расширение каскадной модели с акцентом на верификацию и валидацию.
Каждому этапу разработки соответствует этап тестирования.

Роль тестирования:

Включается с самого начала (тест-дизайн на основе требований).
Тестирование планируется параллельно этапам разработки.

Соответствие этапов:

Этап разработки	Соответствующий этап тестирования
Требования	Приемочное тестирование (Acceptance testing)
Архитектура	Системное тестирование
Дизайн	Интеграционное тестирование
Кодирование	Модульное тестирование

📌 Инкрементная и итеративная модель

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

Характеристики:

ПО разрабатывается по частям (инкрементам).
Итерации позволяют регулярно вносить изменения и улучшения.

Роль тестирования:

Тестирование проводится на каждом инкременте.
Активное использование юнит- и интеграционного тестирования.

📌 Спиральная модель

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

Характеристики:

Делает акцент на управление рисками.
Каждый виток включает планирование, анализ рисков, разработку и тестирование.

Роль тестирования:

Выполняется на каждом витке.
Большое внимание отводится валидации и верификации.

📌 Гибкая (гибкие методологии: Scrum, Kanban, Agile и др.)

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

Характеристики:

Короткие спринты, работа с изменяющимися требованиями.
Разработка и тестирование идут параллельно.

Роль тестирования:

Тестирование — непрерывный процесс.
Активное использование автоматизированного тестирования, юнит-тестов, интеграционного и приемочного тестирования.
Применяются практики TDD (разработка через тестирование).

📌 Agile

Гибкость и адаптивность – ключевые принципы Agile, делающие его идеальным для проектов с нечёткими или часто меняющимися требованиями.

🔹 Основные характеристики:

✔ Итеративная разработка – проект разбивается на небольшие циклы (итерации), по итогам которых заказчик получает рабочий продукт.
✔ Готовность к изменениям – требования могут уточняться и корректироваться в процессе работы.
✔ Фокус на людях – взаимодействие в команде важнее строгих процессов и документации.
✔ Рабочий продукт – главный показатель прогресса (вместо отчётов и планов).

🔹 Роль тестирования:

🔸 Тестирование интегрировано в каждый этап разработки.
🔸 QA-специалисты работают в одной команде с разработчиками.
🔸 Акцент на автоматизации и непрерывном улучшении качества.

📌 Scrum

Структурированный, но гибкий подход к управлению проектами в рамках Agile. Основан на коротких итерациях (спринтах) и чётких ролях.

🔹 Ключевые элементы:

✔ Роли:

Product Owner – определяет приоритеты и требования.
Scrum Master – устраняет препятствия и следит за процессом.
Development Team – самоорганизующаяся команда разработки.

✔ Артефакты:

Product Backlog – список всех задач и требований.
Sprint Backlog – задачи на текущий спринт.
Increment – готовый функционал после спринта.

✔ События:

Sprint Planning – планирование задач на спринт.
Daily Standup – короткие ежедневные встречи.
Sprint Review – демонстрация результатов.
Retrospective – анализ и улучшение процессов.

🔹 Роль тестирования:

🔸 Тестирование проводится в каждом спринте.
🔸 Чем раньше найдены дефекты – тем дешевле их исправить.
🔸 Автоматизированное тестирование ускоряет delivery.

🔄 Сравнение моделей разработки ПО

Модель	Преимущества	Недостатки	Особенности тестирования
Водопадная (каскадная)	- У каждой стадии есть чёткий проверяемый результат - Команда выполняет один вид работы в каждый момент - Хорошо подходит для небольших задач	- Полная неспособность адаптироваться к изменяющимся требованиям - Очень поздняя проверка работоспособности	- С середины проекта - Основное тестирование после реализации
V-образная	- Чёткий результат на каждой стадии - Тестирование планируется с самого начала - Подходит для проектов со стабильными требованиями	- Недостаточная гибкость - Отсутствие раннего прототипирования - Сложность устранения ранних ошибок	- На переходах между стадиями - Каждой стадии соответствует тип тестирования
Итерационная / Инкрементальная	- Раннее прототипирование - Простое управление итерациями - Декомпозиция на управляемые части	- Недостаточная гибкость внутри итераций - Сложность устранения ранних ошибок	- В определённые моменты итераций - Повторное тестирование после доработки
Спиральная	- Глубокий анализ рисков - Подходит для крупных проектов - Раннее прототипирование	- Высокие накладные расходы - Сложна для небольших проектов - Зависит от качества анализа рисков	- На каждом витке - Валидация, верификация, тестирование промежуточных прототипов
Гибкая	- Максимальное вовлечение заказчика - Работа с требованиями - Интеграция тестирования и разработки - Минимум документации	- Сложность масштабирования - Трудности со стабильными процессами	- В определённые моменты итераций и в любой необходимый момент - Поддержка TDD, BDD, CI/CD

📘 2. Критерии качества ПО

🧪 Определения и ключевые понятия

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

🔹 Качество программного обеспечения (Software Quality)

Определение 1: степень, в которой программное обеспечение обладает требуемой комбинацией свойств.
Определение 2: совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

🔹 Обеспечение качества (Quality Assurance, QA)

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

🔹 Контроль качества (Quality Control, QC)

Совокупность действий, проводимых над продуктом в процессе разработки для:

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

🔹 Тестирование ПО (Software Testing)

Одна из техник контроля качества, включающая:

Test Management — планирование работ по тестированию;
Test Design — проектирование тестов;
Test Execution — выполнение тестов;
Test Analysis — анализ результатов тестирования.

🔹 Верификация (Verification)

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

Проверяется: делаем ли мы продукт правильно?

🔹 Валидация (Validation)

Оценка соответствия готового ПО ожиданиям пользователя и бизнес-требованиям.

Проверяется: делаем ли мы правильный продукт?

📐 Основные характеристики качества ПО

Характеристика	Краткое описание
Функциональность	Соответствие поведения системы требованиям и ожиданиям пользователя
Надежность	Способность функционировать без сбоев и восстанавливаться после ошибок
Удобство использования	Легкость изучения и взаимодействия с ПО
Эффективность	Производительность при использовании ресурсов
Удобство сопровождения	Легкость анализа, модификации и тестирования
Портативность	Легкость переноса между различными средами

🧱 Расшифровка характеристик качества ПО

🔹 Функциональность (Functionality)

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

🔹 Надёжность (Reliability)

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

🔹 Удобство использования (Usability)

Простота изучения и понимания интерфейса.
Удобство работы пользователя.
Визуальная и логическая понятность системы.

🔹 Эффективность (Efficiency)

Временная эффективность (быстродействие).
Рациональное использование ресурсов (CPU, RAM и т. д.).

🔹 Удобство сопровождения (Maintainability)

Возможность легко анализировать код и поведение.
Простота модификации и исправления дефектов.
Адаптируемость к изменяющемуся окружению.

🔹 Портативность (Portability)

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

📘 3. Требования: уровни, виды. Сбор требований

📌 Определение

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

🧱 Уровни и типы требований

🔹 Пользовательские требования (User Requirements)

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

🔹 Бизнес-правила (Business Rules)

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

🔹 Атрибуты качества (Quality Attributes)

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

🔹 Функциональные требования (Functional Requirements)

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

🔹 Нефункциональные требования (Non-functional Requirements)

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

🔹 Ограничения (Constraints)

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

🔹 Требования к интерфейсам (External Interface Requirements)

Описывают взаимодействие с другими системами и операционной средой.
Включают протоколы, API, форматы данных.

🔹 Требования к данным (Data Requirements)

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

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

Software Requirements Specification (SRS) — структурированный документ, объединяющий все требования уровня продукта.

Может быть очень объемным (сотни и тысячи страниц).
Формирует основу для проектирования, тестирования и оценки готовности системы.

🎯 Свойства качественных требований

Хорошие требования должны быть:

Полными
Однозначными
Проверяемыми
Реалистичными
Прослеживаемыми
Согласованными

🛠️ Основные техники сбора и выявления требований

Метод	Описание
Интервью	Общение с заказчиками и пользователями
Фокусные группы	Групповые обсуждения с заинтересованными сторонами
Анкетирование	Массовый сбор мнений с помощью опросов
Семинары / брейншторм	Коллективная генерация идей и требований
Наблюдение	Изучение текущих процессов в действии
Прототипирование	Создание черновых макетов и моделей
Анализ документов	Изучение существующей документации
Моделирование процессов	Использование диаграмм, BPMN, UML
Самостоятельное описание	Инициатива от аналитика на основе опыта

📘 4. Разработка через тестирование. Виды и уровни тестирования (в том числе белый и черный ящик)

Разработка через тестирование (TDD) — методика разработки, позволяющая оптимизировать использование модульных тестов.

Задача TDD — достижение баланса между усилиями и результатом.

Цикл red/green/refactor

В первой фазе программист пишет тест.
Во второй — код, необходимый для того, чтобы тест работал.
В третьей, при необходимости, производится рефакторинг.

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

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

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

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

🔍 Уровни тестирования ПО

Уровни тестирования определяются степенью изоляции компонентов и масштабом проверяемых участков системы. Каждый уровень соответствует определённому этапу разработки.

Модульное тестирование (Unit Testing)

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

Интеграционное тестирование (Integration Testing)

Проверяет взаимодействие между компонентами системы.
Может быть горизонтальным (между модулями одного уровня) или вертикальным (между слоями архитектуры).
Часто используется совместно с заглушками (stubs) и драйверами (drivers).

Системное тестирование (System Testing)

Проверяется система в целом как «чёрный ящик».
Тестируются полные сценарии использования.
Проводится тестировщиками, без знания внутренней реализации.

Приёмочное тестирование (Acceptance Testing)

Проверяется соответствие системы ожиданиям заказчика.
Является критерием допуска системы к внедрению или сдаче.

🧪 Виды тестирования ПО

Функциональное тестирование (Functional Testing)

Базируется на функциях и пользовательских сценариях.
Проверяет соответствие поведения системы функциональным требованиям.
Применяется на всех уровнях тестирования.

Нефункциональное тестирование (Non-functional Testing)

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

Подвиды:

Производительность (Performance Testing) — измерение скорости и отклика.
Нагрузочное тестирование (Load Testing) — проверка работы под нормальной нагрузкой.
Стресс-тестирование (Stress Testing) — проверка при экстремальных нагрузках.
Юзабилити-тестирование (Usability Testing) — оценка удобства использования.
Безопасность (Security Testing) — защита от несанкционированного доступа и атак.

Тестирование, связанное с изменениями

Дымовое тестирование (Smoke Testing)

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

Короткий набор тестов для подтверждения запуска и работоспособности основных функций после сборки.

Регрессионное тестирование (Regression Testing)

Проверка, что исправления и изменения не повлияли на существующую функциональность.

Тестирование сборки (Build Verification Test)

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

Санитарное тестирование (Sanity Testing)

Узконаправленное тестирование конкретной изменённой функции для подтверждения её работоспособности.

⚫ Черный ящик

Тестирование «чёрного ящика» означает, что известны только функции программы, но не внутренняя реализация.

Любой способ тестирования «чёрного ящика» должен:

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

🧩 Способы тестирования «черного ящика»

Разбиение на классы эквивалентности

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

🧱 Пример: Пусть функция принимает число от 1 до 100.

Классы эквивалентности:

✅ Допустимый: 1–100 (например, 50)
❌ Недопустимый < 1 (например, 0)
❌ Недопустимый > 100 (например, 101)

Анализ граничных значений

Фокусируется на проверке значений на границах диапазонов и рядом с ними.

Выбираются:

Минимальное и максимальное допустимое значение
Значения ±1 от границ

🧱 Пример: Для диапазона 1–100 проверяют: 0, 1, 2, 99, 100, 101

Диаграммы причин-следствий

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

📌 Суть:

Определяются все возможные причины (входы)
Определяются все следствия (выходы)
Строится диаграмма связей
Формируются тесты на основе таблицы логических связей

⚪ Белый ящик

Тестирование «белого ящика» означает, что тестировщику известна внутренняя структура кода, его логика и алгоритмы.

Любой способ тестирования «белого ящика» должен:

обеспечивать покрытие кода — тесты должны «проходить» по всем ключевым участкам;
выявлять логические ошибки и дефекты в условиях, циклах, ветвлениях и т.п.

🧩 Способы тестирования «белого ящика»

Покрытие операторов (statement coverage)

Проверяется, был ли выполнен каждый оператор (строка кода) хотя бы один раз.
Базовый уровень покрытия.

Покрытие ветвей (branch coverage)

Проверяется, была ли выполнена каждая ветвь в логических конструкциях (if, else, case...).
Более полный охват логики, чем покрытие операторов.

Покрытие условий (condition coverage)

Проверяются все логические условия внутри составных выражений.

Пути (path coverage)

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

Модули и логика

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

📘 5. Проектирование интерфейса пользователя. Тестирование интерфейса.

🖥️ Общие понятия

Под интерфейсом понимается любой экранный информационный или интерактивный интерфейс. Таковыми являются:

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

🛠️ Этапы разработки

🔍 Исследование

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

📝 Пользовательские сценарии

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

🏗️ Структура интерфейса

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

📐 Прототипирование интерфейса

🎨 Определение стилистики

🖼️ Дизайн концепция

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

📱 Оформление всех экранов

🎬 Анимация интерфейса

💻 Подготовка материалов для разработчиков

🧪 Тестирование интерфейса

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

Цели тестирования интерфейса:

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

Подходы к тестированию интерфейса:

Подход	Описание	Преимущества	Недостатки
Ручное тестирование	Проводится тестировщиком вручную	Эффективно при проверке визуального представления. Позволяет выявлять проблемы удобства интерфейса.	Высокая трудоёмкость, риск пропустить ошибки
Автоматизированное тестирование	Используются инструменты автоматизации (например, Selenium, Cypress, TestCafe)	Применяется для регрессионного и функционального UI-тестирования. Подходит для повторяющихся действий.	Ограничено в части оценки визуальных дефектов

📘 6. Проектирование архитектуры ИС. Архитектура ИС. Выбор и обоснование архитектуры приложения.

📌 Общие понятия

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

Архитектура информационной системы — абстрактное понятие, определяющее, из каких составных частей (элементов, компонент) состоит приложение и как эти части между собой взаимодействуют.

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

Конструктивно архитектура обычно определяется как набор ответов на следующие вопросы:

Что делает система?
На какие части она разделяется?
Как эти части взаимодействуют?
Где эти части размещены?

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

🏛️ Триада Витрувия

Качества, которыми должна обладать архитектура:

Прочность конструкции
Польза
Красота

🏢 Бизнес-архитектура

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

💻 IT-архитектура

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

📊 Архитектура данных

Включает логические и физические хранилища данных и средства управления данными.
Архитектура данных должна быть поддержана ИТ-архитектурой.
В современных ИТ-системах, ориентированных на работу со знаниями, иногда выделяют отдельный тип архитектуры — архитектуру знаний (Knowledge Architecture).

📦 Программная архитектура

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

🛠️ Технологическая архитектура

Характеризует программно-аппаратные средства информационных систем и включает такие элементы, как:

Процессор
Память
Жесткие диски
Периферийные устройства
Элементы для их соединения
Операционные системы
Сетевые средства

🏗️ Централизованная архитектура

Основные особенности:

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

Плюсы:

«Нулевое» администрирование рабочих мест пользователей.
Централизованная разработка и обслуживание системы.

Минусы:

Дорогая аппаратура оправдана только для больших систем.
Взаимная зависимость пользователей на программном уровне.

💻 Персональный компьютер

Основные особенности:

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

Плюсы:

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

Минусы:

Серьезные ограничения в вычислительной мощности.
Крайне затруднен обмен данными.
Дублирование информации.

📁 Архитектура «файл-сервер»

Основные особенности:

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

Плюсы:

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

Минусы:

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

🔄 Архитектура «клиент-сервер»

Основные особенности:

Клиентское ПО работает с данными через запросы к серверному ПО.
Базовые функции приложения разделены между клиентом и сервером.

Плюсы:

Полная поддержка многопользовательской работы.
Гарантия целостности данных.

Минусы:

Бизнес-логика приложений осталась в клиентском ПО. При любом изменении алгоритмов надо обновлять пользовательское ПО.

🔄 Переходная архитектура (2,5-слойный клиент-сервер)

Основные особенности:

Использование хранимых процедур и вычисление данных на стороне сервера.
Использование систем управления базами данных (СУБД) со всеми их преимуществами.
Написание программ для серверной части, в основном, на специализированных встроенных языках СУБД, которые не позволяют написать всю бизнес-логику приложения, вследствие чего часть бизнес-логики все равно реализуется на стороне клиента.
Физически ИС состоит из двух компонентов.

Плюсы:

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

Минусы:

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

🔄 Трехуровневый «клиент-сервер»

Основные особенности:

Централизованы, но разделены функции бизнес-логики и хранения данных.
Клиентское ПО реализует только функции пользовательского интерфейса и общается только с сервером приложений.
Широкие возможности масштабирования. Одна и та же система может работать как на одном отдельно стоящем компьютере, выполняя на нем программы СУБД, СП и клиентской части, так и в сети, состоящей из сотен и тысяч машин. Единственным фактором, препятствующим бесконечной масштабируемости, является лишь требование ведения единой базы данных.
Упрощение расширения функциональных возможностей.

Плюсы:

Простота внесения изменений в бизнес-алгоритмы.
Клиентское ПО не нуждается в администрировании.

Минусы:

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

🌐 Архитектура на основе Internet/Intranet и CGI/API

CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») — стандарт интерфейса, используемого для связи внешней программы с веб-сервером.

Плюсы:

Web-сервер выступает в качестве сервера приложения (администрирование выполняется централизованно).
CGI интерфейс унифицирован и реализован во всех серверах.
Для доступа к БД можно использовать любой web-браузер.

Минусы:

Каждая CGI программа выполняется как процесс ОС, что занимает много времени.
CGI программа не поддерживает контекст связи с БД, то есть БД открывается при каждом вызове CGI программы.
Генерируемая форма имеет небольшие выразительные возможности.

API

Плюсы:

Они выполняются быстрее, чем CGI программы (нет переключения между задачами ОС).
ASP вместе с некоторыми дополнениями (Remote scripting, scriptlet) позволяют поддерживать контекст с БД.

Минусы:

API программы разных производителей не совместимы между собой.
API интерфейсы и соответствующие API программы зависят от платформы.

🌐 Архитектура на основе Internet/Intranet с мигрирующими программами

Плюсы:

Эта технология позволяет существенно разгрузить web-сервер, так как java-апплеты выполняются на рабочих станциях.
Java-апплеты мобильны. Язык java достаточно гибкий для создания сложных программ.
JDBC является универсальным интерфейсом. Язык SQL не зависит от СУБД.
Существует множество java-программ, которые можно использовать. Их можно запускать с различных серверов и связывать на рабочей станции.

Минусы:

Размеры java-апплетов должны быть небольшими. Это связано с ограничением времени передачи по сети.
Низкая производительность java-программ.
Относительная сложность разработки java-апплетов, выполняющих доступ к БД.

🔄 N-уровневый «клиент-сервер»

Основные особенности:

Много серверов приложений, взаимодействующих друг с другом. Каждый сервер решает свою бизнес-задачу.

Плюсы:

Простота внесения изменений в бизнес-алгоритмы.
Клиентское ПО не нуждается в администрировании.

Минусы:

Усложнение серверной инфраструктуры.

☁️ Облачные информационные системы

Облачные вычисления (англ. cloud computing) — технология распределенной обработки данных, в которой компьютерные ресурсы и мощности предоставляются пользователю как интернет-сервис.

Облако — это крупный дата-центр или сеть взаимосвязанных между собой серверов.

Типы облаков:

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

Модели предоставления услуг:

Модель	Описание
SaaS (Software as a Service)	Программное обеспечение, предоставляемое через интернет. Пользователи получают доступ к приложениям, которые управляются поставщиком услуг. Примеры включают электронную почту и офисные приложения.
PaaS (Platform as a Service)	Платформа, предоставляемая как услуга, которая позволяет разработчикам разрабатывать, запускать и управлять приложениями без необходимости поддерживать инфраструктуру. Обычно включает инструменты разработки, базы данных и системы управления.
IaaS (Infrastructure as a Service)	Инфраструктура как услуга, предоставляющая виртуальные вычислительные ресурсы через интернет. Пользователи могут арендовать серверы, хранилища и сетевые компоненты, управляя ими самостоятельно. Примеры включают виртуальные машины и хранилища данных.

📘 7. Паттерны проектирования. Классификация. Поведенческие, порождающие, структурные. Entity Framework

🧩 Общие понятия

Паттерны проектирования — это типовые решения часто встречающихся проблем в объектно-ориентированном программировании.

Классификация:

Порождающие (Creational) - решают проблемы создания объектов
Структурные (Structural) - решают проблемы композиции объектов
Поведенческие (Behavioral) - решают проблемы взаимодействия объектов

Entity Framework — ORM от Microsoft, который использует несколько паттернов:

Unit of Work
Repository
Identity Map

🔁 Классификация паттернов

📌 Порождающие паттерны (Creational)

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

Основные паттерны:

Одиночка (Singleton)
Фабрика (Factory)
Абстрактная фабрика (Abstract Factory)
Строитель (Builder)
Прототип (Prototype)

Особенности:

Инкапсулируют знания о конкретных классах
Скрывают детали создания объектов
Дают гибкость в создании объектов

📌 Структурные паттерны (Structural)

Описывают способы компоновки классов и объектов для получения новых структур.

Основные паттерны:

Адаптер (Adapter)
Мост (Bridge)
Декоратор (Decorator)
Фасад (Facade)
Приспособленец (Flyweight)
Заместитель (Proxy)

Особенности:

Упрощают проектирование системы
Позволяют изменять структуру независимо от реализации
Повышают гибкость и расширяемость

📌 Поведенческие паттерны (Behavioral)

Решают задачи эффективного взаимодействия между объектами.

Основные паттерны:

Стратегия (Strategy)
Наблюдатель (Observer)
Команда (Command)
Цепочка обязанностей (Chain of Responsibility)
Состояние (State)

Особенности:

Распределяют обязанности между классами
Упрощают взаимодействие между объектами
Делают поведение системы более гибким

🔄 Подробное описание ключевых паттернов (C#)

📌 Стратегия (Strategy) - Behavioral

Назначение: Определяет семейство алгоритмов, инкапсулирует каждый из них и делает взаимозаменяемыми.

// Интерфейс стратегии
public interface ISortStrategy
{
    void Sort(List<int> data);
}

// Конкретные стратегии
public class BubbleSort : ISortStrategy
{
    public void Sort(List<int> data) 
        => Console.WriteLine("Сортировка пузырьком");
}

public class QuickSort : ISortStrategy
{
    public void Sort(List<int> data) 
        => Console.WriteLine("Быстрая сортировка");
}

// Контекст
public class Sorter
{
    private ISortStrategy _strategy;
    
    public Sorter(ISortStrategy strategy) => _strategy = strategy;
    
    public void SetStrategy(ISortStrategy strategy) => _strategy = strategy;
    
    public void ExecuteSort(List<int> data) => _strategy.Sort(data);
}

// Использование
var data = new List<int> {1, 5, 3};
var sorter = new Sorter(new BubbleSort());
sorter.ExecuteSort(data);

sorter.SetStrategy(new QuickSort());
sorter.ExecuteSort(data);

📌 Фабрика простая (Simple Factory) - Creational

Назначение: Создает объекты без указания конкретного класса.

public interface IDoor
{
    int Height { get; }
    int Width { get; }
}

public class WoodenDoor : IDoor
{
    public int Height { get; }
    public int Width { get; }
    
    public WoodenDoor(int height, int width)
        => (Height, Width) = (height, width);
}

public static class DoorFactory
{
    public static IDoor CreateDoor(int height, int width)
        => new WoodenDoor(height, width);
}

// Использование
var door = DoorFactory.CreateDoor(200, 80);
Console.WriteLine($"Высота: {door.Height}, Ширина: {door.Width}");

📌 Фабричный метод (Factory Method) - Creational

Назначение: Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать.

public interface IInterviewer
{
    void AskQuestions();
}

public class Developer : IInterviewer
{
    public void AskQuestions() 
        => Console.WriteLine("Задает вопросы о паттернах");
}

public class HR : IInterviewer
{
    public void AskQuestions() 
        => Console.WriteLine("Задает вопросы о софт скиллах");
}

public abstract class HiringManager
{
    protected abstract IInterviewer MakeInterviewer();
    
    public void TakeInterview() 
        => MakeInterviewer().AskQuestions();
}

public class DevelopmentManager : HiringManager
{
    protected override IInterviewer MakeInterviewer() 
        => new Developer();
}

// Использование
var manager = new DevelopmentManager();
manager.TakeInterview(); // Вывод: Задает вопросы о паттернах

📌 Абстрактная фабрика (Abstract Factory) - Creational

Назначение: Предоставляет интерфейс для создания семейств связанных объектов.

public interface IFurnitureFactory
{
    IChair CreateChair();
    ITable CreateTable();
}

public class ModernFurnitureFactory : IFurnitureFactory
{
    public IChair CreateChair() => new ModernChair();
    public ITable CreateTable() => new ModernTable();
}

public interface IChair { void SitOn(); }
public interface ITable { void PutOn(); }

public class ModernChair : IChair
{
    public void SitOn() => Console.WriteLine("Сидим на современном стуле");
}

// Использование
IFurnitureFactory factory = new ModernFurnitureFactory();
var chair = factory.CreateChair();
chair.SitOn();

📌 Строитель (Builder) - Creational

Назначение: Позволяет создавать сложные объекты пошагово.

public class Burger
{
    public int Size { get; set; }
    public bool Cheese { get; set; }
    // Другие свойства
    
    public Burger(BurgerBuilder builder)
    {
        Size = builder.Size;
        Cheese = builder.Cheese;
        // Инициализация других свойств
    }
}

public class BurgerBuilder
{
    public int Size { get; set; }
    public bool Cheese { get; set; }
    // Другие свойства
    
    public BurgerBuilder(int size) => Size = size;
    
    public BurgerBuilder AddCheese()
    {
        Cheese = true;
        return this;
    }
    
    public Burger Build() => new Burger(this);
}

// Использование
var burger = new BurgerBuilder(15)
    .AddCheese()
    .Build();

📌 Декоратор (Decorator) - Structural

Назначение: Динамически добавляет объекту новые обязанности.

public interface ICoffee
{
    string Description { get; }
    double Cost { get; }
}

public class SimpleCoffee : ICoffee
{
    public string Description => "Простой кофе";
    public double Cost => 1.0;
}

public abstract class CoffeeDecorator : ICoffee
{
    protected ICoffee _coffee;
    
    public CoffeeDecorator(ICoffee coffee) => _coffee = coffee;
    
    public virtual string Description => _coffee.Description;
    public virtual double Cost => _coffee.Cost;
}

public class MilkDecorator : CoffeeDecorator
{
    public MilkDecorator(ICoffee coffee) : base(coffee) {}
    
    public override string Description => _coffee.Description + ", молоко";
    public override double Cost => _coffee.Cost + 0.5;
}

// Использование
ICoffee coffee = new SimpleCoffee();
coffee = new MilkDecorator(coffee);
Console.WriteLine($"{coffee.Description}: ${coffee.Cost}");

📌 Одиночка (Singleton) - Creational

Назначение: Гарантирует, что у класса есть только один экземпляр.

public sealed class Singleton
{
    private static Singleton _instance;
    private static readonly object _lock = new object();
    
    private Singleton() { }
    
    public static Singleton Instance
    {
        get
        {
            lock (_lock)
            {
                return _instance ??= new Singleton();
            }
        }
    }
    
    public void SomeMethod() 
        => Console.WriteLine("Метод синглтона");
}

// Использование
var instance1 = Singleton.Instance;
var instance2 = Singleton.Instance;

Console.WriteLine(instance1 == instance2); // True

📌 Фасад (Facade) - Structural

Назначение: Предоставляет простой интерфейс к сложной системе.

public class SubsystemA
{
    public void OperationA() 
        => Console.WriteLine("Операция A");
}

public class SubsystemB
{
    public void OperationB() 
        => Console.WriteLine("Операция B");
}

public class Facade
{
    private readonly SubsystemA _a;
    private readonly SubsystemB _b;
    
    public Facade(SubsystemA a, SubsystemB b)
        => (_a, _b) = (a, b);
    
    public void Operation()
    {
        _a.OperationA();
        _b.OperationB();
    }
}

// Использование
var facade = new Facade(new SubsystemA(), new SubsystemB());
facade.Operation();

🔄 Сравнение паттернов проектирования

Паттерн	Категория	Когда использовать	Преимущества	Недостатки
Стратегия	Поведенческий	При необходимости менять алгоритмы выполнения задачи	- Легкая замена алгоритмов - Избегание условных операторов - Соблюдение OCP	- Усложнение кода дополнительными классами - Клиент должен знать о существовании стратегий
Фабричный метод	Порождающий	Когда классу заранее неизвестно, объекты каких классов ему нужно создавать	- Гибкость в создании объектов - Избегание привязки к конкретным классам	- Необходимость создавать подклассы - Усложнение структуры кода
Абстрактная фабрика	Порождающий	При создании семейств связанных объектов	- Гарантирует совместимость объектов - Изолирует конкретные классы	- Сложность добавления новых видов продуктов - Громоздкость кода
Строитель	Порождающий	Для пошагового создания сложных объектов	- Позволяет варьировать внутреннее представление продукта - Изолирует код сборки	- Усложнение кода - Требуется создание конкретного строителя для каждого типа объекта
Декоратор	Структурный	Для динамического добавления обязанностей объектам	- Гибкость расширения функционала - Альтернатива наследованию	- Большое количество мелких классов - Сложность конфигурации многослойных декораторов
Одиночка	Порождающий	Когда нужен ровно один экземпляр класса	- Глобальный доступ - Контроль создания экземпляра	- Нарушает принцип единой ответственности - Усложняет тестирование
Фасад	Структурный	Для предоставления простого интерфейса к сложной системе	- Упрощает работу с подсистемой - Снижает связанность	- Может стать "божественным объектом" - Ограничивает гибкость
Адаптер	Структурный	Когда нужно согласовать несовместимые интерфейсы	- Позволяет работать с несовместимыми интерфейсами - Реиспользование существующего кода	- Увеличивает сложность системы - Временное решение, маскирующее проблему дизайна
Наблюдатель	Поведенческий	При реализации механизма подписки и уведомлений	- Гибкая связь между объектами - Поддержка принципа открытости/закрытости	- Непредсказуемый порядок уведомлений - Возможны утечки памяти

📘 8. Структурные методы анализа и проектирования ПО: IDEF1x и воронья лапка (sqldbm).

📌 Структурные методы анализа и проектирования ПО

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

Ключевые особенности:

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

📊 IDEF0 (Integration DEFinition for Function Modeling)

Метод моделирования функций и процессов системы. Основной целью является представление:

Что делает система;
Какие ресурсы использует;
Что на нее влияет.

Основные элементы диаграммы IDEF0:

Элемент	Описание
Функции (процессы)	Изображаются прямоугольниками
Стрелки	Входы (Input), выходы (Output), механизмы (Mechanism), управление (Control)
Иерархическая декомпозиция	Каждая функция может быть разложена на подфункции

📊 IDEF3

Метод описания сценариев поведения системы, то есть моделирования процессов и последовательностей операций.

Особенности:

Подходит для описания текущего состояния (AS-IS) и проектируемого (TO-BE).
Используются объектные и процессные схемы.
Визуализирует поток управления и временные зависимости между действиями.

📊 DFD (Data Flow Diagrams)

Диаграммы потоков данных, направлены на описание логики обработки информации в системе.

Основные элементы:

Элемент	Описание
Процессы	Трансформации данных (круги)
Хранилища данных	Базы или временные буферы (две параллельные линии)
Потоки данных	Стрелки между элементами
Внешние сущности	Источники и получатели данных (прямоугольники)

DFD отображает:

Что происходит с данными;
Где они хранятся;
Откуда поступают.

📊 IDEF1X (Integration DEFinition for Information Modeling)

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

Основные элементы:

Элемент	Описание
Сущности (Entities)	Прямоугольники
Атрибуты	Характеристики сущностей
Отношения (Relationships)	Связи между сущностями, отображаются линиями

❖ Важнейшее обозначение: "воронья лапка" (Crow's Foot Notation)

Один из стандартов записи связей в ER-диаграммах (Entity-Relationship).
Визуально показывает мощности связей:

Обозначение	Описание
"лапка" (три ответвления)	Означает "многие"
Прямая линия	Означает "один"
Круг	Возможен нулевой экземпляр
Черточка	Обязательное наличие

Примеры связей:

Связь	Описание
1:1	Один к одному
1:N	Один ко многим (классическая "воронья лапка")
M:N	Многие ко многим (реализуется через связующую сущность)

Преимущества IDEF1X:

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

📘 9. UML диаграммы, этапы проектирования ИС с применением UML. Виды UML.

🧩 Введение в UML

UML (Unified Modeling Language) — стандартизированный язык графического описания:

Объектно-ориентированных систем
Архитектуры ПО
Бизнес-процессов

Основные функции UML:

Визуализация
Спецификация
Документирование
Конструирование

🔄 Этапы проектирования ИС с UML

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

Диаграммы: Use Case, Activity
Цель: Выявление функциональных требований

2. Проектирование архитектуры

Диаграммы: Component, Deployment
Цель: Определение структуры системы

3. Детальное проектирование

Диаграммы: Class, Sequence
Цель: Проработка взаимодействия объектов

4. Реализация

Диаграммы: State Machine, Object
Цель: Отображение поведения системы

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

Диаграммы: Use Case (для тест-кейсов)
Цель: Верификация системы

📌 Основные виды UML диаграмм

1. Use Case Diagram (Диаграмма прецедентов)

Назначение: Описание взаимодействия акторов с системой

Элементы:

Актор (Actor) — внешняя сущность
Прецедент (Use Case) — функция системы
Связи:
- Ассоциация (→)
- Включение (<>)
- Расширение (<>)

2. Activity Diagram (Диаграмма активностей)

Назначение: Моделирование бизнес-процессов

Элементы:

Действие (Activity) — прямоугольник со скругленными углами
Решение (Diamond) — ветвление
Потоки:
- Управления (→)
- Данных (⤳)

3. Sequence Diagram (Диаграмма последовательностей)

Назначение: Отображение взаимодействия объектов во времени

Элементы:

Объекты (Lifeline) — вертикальные линии
Сообщения:
- Синхронные (→)
- Асинхронные (⟶)
- Возвратные (⤳)

4. Class Diagram (Диаграмма классов)

Назначение: Описание структуры системы

Элементы:

Класс:

┌──────────────┐
│   Order      │
├──────────────┤
│ -id: int     │
│ -date: Date  │
├──────────────┤
│ +Calculate() │
└──────────────┘

Связи:

Ассоциация Смысл: Обычная связь между классами
Суть: "Знает о" (например, [Преподаватель] — [Университет])
Наследование Смысл: Отношение "является"
Суть: Дочерний класс наследует родительский ([Животное] △ [Кот])
Реализация Смысл: Класс реализует интерфейс
Суть: "Обязуется выполнить контракт" ([Список] ⤳△ [IEnumerable])
Зависимость Смысл: Временное использование
Суть: "Использует иногда" ([Отчет] ⤳ [БД])
Агрегация Смысл: "Имеет" с независимыми частями
Суть: Колесо может существовать без машины ([Авто] ◇—— [Колесо])
Композиция Смысл: "Содержит" с общим жизненным циклом
Суть: Комната не существует без дома ([Дом] ◆—— [Комната])

🔍 Ключевые различия:

Сила связи: Композиция > Агрегация > Ассоциация > Зависимость
Жизненный цикл:
- Композиция: части умирают с целым
- Агрегация: части живут отдельно
Направленность:
- Стрелка показывает направление знания
- Нет стрелки = взаимное знание

🔄 Сравнение диаграмм UML

Тип диаграммы	Уровень детализации	Когда использовать	Основные элементы
Use Case	Высокий	На этапе сбора требований	Акторы, прецеденты, связи
Activity	Средний	Для бизнес-процессов	Действия, решения, потоки
Sequence	Низкий	При проектировании взаимодействий	Объекты, сообщения, временные оси
Class	Очень низкий	При проектировании архитектуры	Классы, интерфейсы, отношения

📘 10. BPMN

BPMN — стандарт графического моделирования бизнес-процессов. Позволяет наглядно описывать шаги, участников и логику выполнения процессов.

🧩 Основные элементы BPMN

1. Потоки (Flow Objects)

Действие (Activity) – прямоугольник со скругленными углами:
- Задача (Task) – единичное действие
- Подпроцесс (Sub-Process) – группа задач
События (Event) – кружки:
- Старт (Start Event) – начало процесса
- Промежуточное (Intermediate) – что-то произошло
- Конец (End Event) – завершение
Шлюзы (Gateway) – ромбы:
- Разветвление/соединение потока (XOR, AND, OR)

2. Соединения (Connecting Objects)

Поток операций (Sequence Flow) – сплошная линия со стрелкой
Поток сообщений (Message Flow) – пунктир с кружком
Ассоциации (Association) – пунктир без стрелки

3. Дорожки (Swimlanes)

Пулы (Pool) – крупные участники (компании, отделы)
Дорожки (Lane) – роли внутри пула (менеджер, клиент, система)

4. Артефакты (Artifacts)

Данные (Data Object) – документы, файлы
Группы (Group) – объединение задач
Аннотации (Text Annotation) – пояснения

💡 Когда использовать BPMN?

Оптимизация бизнес-процессов
Автоматизация workflow
Документирование для команды/заказчика

⚠️ Ошибки новичков

Слишком сложные диаграммы (разбивайте на подпроцессы).
Путаница между шлюзами (XOR vs. AND).
Отсутствие дорожек (непонятно, кто отвечает за шаг).

Name		Name	Last commit message	Last commit date
Latest commit History 9 Commits
README.md		README.md
bpmn1.jpg		bpmn1.jpg
bpmn2.jpg		bpmn2.jpg
скт.jpg		скт.jpg
стрелкиuml.jpg		стрелкиuml.jpg

Folders and files

Latest commit

History

Repository files navigation

БАЗА ПО ПИ

TODO:

📘 1. Тестирование в жизненном цикле программного обеспечения

🧩 Общие понятия

🔁 Тестирование в различных моделях ЖЦ ПО

📌 Водопадная модель (Каскадная модель, waterfall)

Этапы:

Особенности:

📌 V-модель (Verification and Validation)

Характеристики:

Роль тестирования:

Соответствие этапов:

📌 Инкрементная и итеративная модель

Характеристики:

Роль тестирования:

📌 Спиральная модель

Характеристики:

Роль тестирования:

📌 Гибкая (гибкие методологии: Scrum, Kanban, Agile и др.)

Характеристики:

Роль тестирования:

📌 Agile

🔹 Основные характеристики:

🔹 Роль тестирования:

📌 Scrum

🔹 Ключевые элементы:

🔹 Роль тестирования:

🔄 Сравнение моделей разработки ПО

📘 2. Критерии качества ПО

🧪 Определения и ключевые понятия

🔹 Качество программного обеспечения (Software Quality)

🔹 Обеспечение качества (Quality Assurance, QA)

🔹 Контроль качества (Quality Control, QC)

🔹 Тестирование ПО (Software Testing)

🔹 Верификация (Verification)

🔹 Валидация (Validation)

📐 Основные характеристики качества ПО

🧱 Расшифровка характеристик качества ПО

🔹 Функциональность (Functionality)

🔹 Надёжность (Reliability)

🔹 Удобство использования (Usability)

🔹 Эффективность (Efficiency)

🔹 Удобство сопровождения (Maintainability)

🔹 Портативность (Portability)

📘 3. Требования: уровни, виды. Сбор требований

📌 Определение

🧱 Уровни и типы требований

🔹 Пользовательские требования (User Requirements)

🔹 Бизнес-правила (Business Rules)

🔹 Атрибуты качества (Quality Attributes)

🔹 Функциональные требования (Functional Requirements)

🔹 Нефункциональные требования (Non-functional Requirements)

🔹 Ограничения (Constraints)

🔹 Требования к интерфейсам (External Interface Requirements)

🔹 Требования к данным (Data Requirements)

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

🎯 Свойства качественных требований

🛠️ Основные техники сбора и выявления требований

📘 4. Разработка через тестирование. Виды и уровни тестирования (в том числе белый и черный ящик)

🔍 Уровни тестирования ПО

🧪 Виды тестирования ПО

⚫ Черный ящик

🧩 Способы тестирования «черного ящика»

⚪ Белый ящик

🧩 Способы тестирования «белого ящика»

📘 5. Проектирование интерфейса пользователя. Тестирование интерфейса.

🖥️ Общие понятия

🛠️ Этапы разработки

🔍 Исследование

📝 Пользовательские сценарии

🏗️ Структура интерфейса

📐 Прототипирование интерфейса

🎨 Определение стилистики

🖼️ Дизайн концепция

📱 Оформление всех экранов

🎬 Анимация интерфейса