Вопрос 2.

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

Классифицировать инструментальные средства можно по разным признакам. На практике чаще всего используют функциональную классификацию — по тому, какую задачу решает инструмент.

1. По этапу жизненного цикла ПО:

Средства анализа и проектирования — инструменты для моделирования (UML-диаграммы, ER-диаграммы), например, Draw.io, Enterprise Architect.
Средства реализации — компиляторы, интерпретаторы, редакторы кода, IDE.
Средства тестирования — фреймворки для модульного тестирования (JUnit, pytest), инструменты автоматизации UI-тестов (Selenium), нагрузочного тестирования (JMeter).
Средства сопровождения — системы контроля версий (Git), баг-трекеры (Jira, YouTrack), CI/CD (Jenkins, GitLab CI).

2. По способу распространения:

Бесплатные (Open Source): VS Code, Eclipse, Git, GCC, Python (интерпретатор).
Коммерческие: IntelliJ IDEA Ultimate, Microsoft Visual Studio Enterprise, JProfiler.

3. По уровню интеграции:

Отдельные утилиты — компилятор, линкер, отладчик запускаются по отдельности.
Интегрированные среды (IDE) — всё в одном окне.

4. По типу платформы:

Кроссплатформенные — работают на Windows, Linux, macOS (VS Code, Git).
Платформенно-зависимые — только под Windows (Visual Studio до недавнего времени) или только под macOS (Xcode).

5. По языку программирования:

Языко-специфичные — IntelliJ IDEA (Java), PyCharm (Python), Rust Analyzer.
Мультиязычные — VS Code, Eclipse, Sublime Text.

6. По назначению (узкая специализация):

Для веб-разработки — Chrome DevTools, Postman.
Для мобильной разработки — Android Studio, Xcode.
Для баз данных — DBeaver, pgAdmin.
Для DevOps — Docker, Kubernetes, Terraform.

Классификация помогает выбрать правильный инструмент под конкретную задачу. Например, для стартапа на Python и React можно взять VS Code + Git + GitHub + pytest, а для крупного банковского проекта на Java — IntelliJ IDEA Ultimate + Jira + Jenkins + SonarQube.

Вопрос 3.

Интегрированная среда разработки: назначение, состав, функции

Краткая теория: IDE (Integrated Development Environment) объединяет редактор, компилятор, отладчик и Git в одной программе.

Состав (что внутри):

Редактор кода (подсветка, автодополнение)
Компилятор / интерпретатор
Отладчик (точки останова, просмотр переменных)
Система сборки (кнопка «Запустить»)
Интеграция с Git
Терминал

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

Автодополнение (IntelliSense)
Переход к определению (F12)
Рефакторинг (переименовать всё и везде)
Подсветка ошибок красным
Запуск тестов одной кнопкой

Примеры IDE и для чего:

VS Code — для всего (JS, Python, C++, Go) — самая популярная.
IntelliJ IDEA — для Java и Kotlin.
PyCharm — для Python.
Xcode — для iPhone-приложений (только на Mac).

Пример: В PyCharm ты пишешь код, он сам подчёркивает ошибки, а по кнопке «Run» запускает программу и показывает результат в том же окне.

Вопрос 4.

Компиляторы, интерпретаторы и трансляторы: различия

Виды:

Транслятор — общее понятие (переводит код с одного языка на другой).
Компилятор — переводит весь код сразу в машинный, создаёт .exe файл.
Интерпретатор — выполняет код построчно, не создавая файла.

Пример различия (одна и та же программа):

python

# Простая программа
x = 10
y = 0
print(x / y)  # Ошибка: деление на ноль

Компилятор (C++): не даст собрать программу, если ошибка синтаксическая, но деление на ноль — ошибка времени выполнения. Соберёт, а при запуске — крах.
Интерпретатор (Python): выполнит строку x=10, потом y=0, потом на print(x/y) упадёт с ошибкой.

Сравнение простыми словами:

	Компилятор	Интерпретатор
Создаёт файл .exe	Да	Нет
Скорость работы	Быстро	Медленнее
Виден ли исходник пользователю?	Нет (только машинный код)	Да
Пример языков	C, C++, Go, Rust	Python, PHP, JS, Ruby

Пример компилятора: GCC (для C++) — скомпилировал один раз, получил program.exe, отдал пользователю.

Пример интерпретатора: Python — пользователь запускает файл .py, интерпретатор построчно читает и выполняет.

Переводит с одного высокоуровневого языка на другой. Пример: TypeScript → JavaScript (браузер понимает только JS, а разработчик пишет на TS).шибки, а по кнопке «Run» запускает программу и показывает результат в том же окне.

Вопрос 5.

Этапы создания программного продукта

Программа создаётся не «сразу кодом», а проходит 6 обязательных этапов. Пропуск любого этапа ведёт к проблемам.

Схема этапов (как строительство дома):

Анализ требований — что делать? → Техническое задание (ТЗ)
Проектирование — как сделать? → схемы, чертежи, UML
Кодирование — пишем код → исходники
Тестирование — ищем ошибки → отчёт о багах
Внедрение — отдаём пользователю → программа в работе
Сопровождение — исправляем баги после релиза → новые версии

Пример для приложения «Калькулятор»:

Этап	Что делаем	Результат
Анализ	Спрашиваем у заказчика: нужно сложение, вычитание, умножение, деление, память, проценты?	ТЗ из 8 пунктов
Проектирование	Рисуем расположение кнопок на экране, решаем, как хранить число в памяти, выбираем архитектуру	Макет в Figma, схема классов
Кодирование	Пишем код на Python (или C++, или JS)	main.py (500 строк)
Тестирование	Проверяем: 2+2=4? 5-3=2? 10/0 → ошибка? Сохраняется ли число в память?	Нашли 3 бага, исправили
Внедрение	Даём программу бабушке, устанавливаем на её компьютер	Бабушка пользуется
Сопровождение	Через месяц бабушка просит добавить кнопку «√» (корень)	Новая версия 1.1

Важные уточнения:

В реальных проектах этапы часто пересекаются (тестирование идёт параллельно с кодированием).
В Agile-методологиях этапы циклические: каждый спринт (2 недели) содержит анализ маленькой фичи → проектирование → кодирование → тестирование → внедрение в тестовую среду.

Почему нельзя пропустить анализ? Если не спросить у заказчика, нужна ли ему функция «проценты», можно потратить неделю на её реализацию, а заказчику она не нужна. Это потеря времени и денег.

Дополнительный пример: Классический провал проекта — когда заказчик говорит «сделайте удобную систему», программисты пишут код без анализа, а в итоге система работает, но не решает бизнес-задачу.

Вопрос 6.

Жизненный цикл программного обеспечения

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

5 фаз жизненного цикла (аналогия с жизнью человека):

Фаза	В жизни человека	В жизни ПО	Пример для игры «Сапёр»
1. Инициация	Зачатие, рождение идеи	Придумали идею, оценили бюджет	«Сделаем игру, где нужно открывать клетки, не наступив на мину»
2. Разработка	Рост, взросление	Проектирование, кодирование, тестирование	3 месяца работы команды из 2 человек
3. Внедрение	Рождение (появление на свет)	Выложили в магазин, установили на сервер	Появилась в Google Play и App Store
4. Эксплуатация	Жизнь, работа	Пользователи работают, выходят обновления	2 года популярности, 100 тысяч скачиваний
5. Вывод из эксплуатации	Смерть	Отключили серверы, удалили из магазинов	Удалили из магазинов, закрыли онлайн-таблицу рекордов

Подробное описание каждой фазы:

Фаза 1. Инициация и определение требований

Рождается идея. Проводится предварительный анализ: зачем нужна программа, кто будет пользоваться, какие риски. Составляется бизнес-план, оцениваются сроки и бюджет.
Результат: утверждённая идея и предварительный план.

Фаза 2. Разработка (проектирование, кодирование, тестирование)

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

Фаза 3. Внедрение (переход в эксплуатацию)

Программа устанавливается на серверы или компьютеры пользователей. Переносятся данные из старых систем. Проводится обучение пользователей. Запускается в «боевую» эксплуатацию.
Результат: программа в реальном использовании.

Фаза 4. Эксплуатация и сопровождение

Самая длительная фаза (годы, иногда десятилетия). Программа работает, принося пользу. В это время:
- Исправляются ошибки (корректирующее сопровождение).
- Добавляются новые функции (совершенствующее сопровождение).
- Программа адаптируется к новым версиям ОС и оборудования (адаптивное сопровождение).
- Проводится рефакторинг без изменения поведения (профилактическое сопровождение).
Результат: новые версии программы (1.1, 1.2, 2.0 и т.д.).

Фаза 5. Вывод из эксплуатации (снятие с поддержки)

Программа устарела морально или технически. Её заменяют новой. Постепенно отключают серверы, переносят данные в новую систему, оповещают пользователей. Программа «умирает».
Результат: программа полностью прекращает существование.

Примеры длительности ЖЦ для разных типов ПО (реальные цифры):

Тип ПО	Разработка	Эксплуатация	Вывод	Всего ЖЦ
Мобильная игра-однодневка	1 месяц	6 месяцев	1 месяц	8 месяцев
Популярная мобильная игра	6–12 месяцев	2–3 года	3–6 месяцев	3–4 года
Корпоративная CRM-система	1–2 года

Вопрос 7.

Модели жизненного цикла программного обеспечения

Модель ЖЦ — это схема, которая определяет порядок выполнения этапов разработки. Разные модели подходят для разных проектов. Выбор модели влияет на сроки, бюджет, гибкость и риски.

Основные модели ЖЦ (сравнение):

Модель	Суть	Когда применять	Плюсы	Минусы
Каскадная (Waterfall)	Этапы строго по очереди, назад нельзя	Военные, медицинские, авиационные системы (требования стабильны годами)	Простота, чёткие контрольные точки	Ошибку в требованиях обнаружат только на тестировании
Итеративная	Делаем кусками (итерациями), после каждой — работающий прототип	Крупные проекты с понятными, но уточняемыми требованиями	Заказчик видит результат рано	Нужна хорошая архитектура
Спиральная (Spiral)	Каждый виток: анализ рисков → разработка части → планирование следующего	Космические системы, АЭС, инновационные R&D-проекты	Постоянный контроль рисков	Сложно, дорого, много документации
Agile (Scrum, Kanban)	Спринты 1–4 недели, работающий продукт после каждого	Веб-сервисы, стартапы, быстро меняющиеся требования	Быстрая реакция на изменения	Не подходит для систем с жёсткими требованиями

Пример выбора модели на практике:

Ситуация	Какая модель	Почему
Система управления ракетой	Каскадная	Требования известны на 10 лет, ошибка стоит жизни
Корпоративная CRM на год	Итеративная	Заказчик хочет видеть прогресс каждые 2 месяца
Разработка нового лекарства (софт для моделирования)	Спиральная	Огромные риски, дорого ошибиться
Мобильное приложение для доставки еды	Agile (Scrum)	Рынок меняется каждую неделю, нужно быстро реагировать

Дополнительно — Kanban (разновидность Agile):

Визуализация задач на доске:

To Do	In Progress	Done
Задача 1	Задача 3	Задача 5
Задача 2	Задача 4	Задача 6

Ограничение: не больше 3 задач в столбце «In Progress» (WIP limit). Нет спринтов — задачи берутся по мере готовности.

Вопрос 8.

Понятие репозитория, коммита, ветки и слияния

Это основы Git — системы контроля версий. Git хранит историю изменений, позволяет работать в команде и не бояться что-то сломать. Без Git командная разработка превращается в хаос из папок «проект_финал_3_исправленный_вася_2».

Основные понятия (с аналогиями):

Понятие	Аналогия	Что это в Git
Репозиторий	База данных всех сохранений игры	Папка `.git` (скрытая), где хранятся все версии файлов
Коммит	Сохранение в игре (чекпоинт)	Снимок всех файлов в определённый момент, с комментарием
Ветка	Отдельная дорожка разработки (как сохранение «эксперимент»)	Указатель на цепочку коммитов
Слияние (merge)	Объединение двух сохранений	Взяли изменения из ветки A и добавили в ветку B
Конфликт	Два игрока изменили одну и ту же строку по-разному	Git не знает, что выбрать — решает человек

Как выглядит репозиторий (графически):

text

Коммиты:  A ← B ← C ← D  (главная ветка main)
              \
               E ← F ← G  (ветка feature)

В точке B создали ветку feature.
В main сделали коммиты C и D.
В feature сделали коммиты E, F, G.
Теперь нужно слить feature в main (merge).

После слияния (merge):

text

main:     A ← B ← C ← D ← H (коммит слияния, содержит E+F+G)
               \         /
feature:        E ← F ← G

Пример работы с Git (команды):

bash

# Создать новый репозиторий в текущей папке
git init

# Склонировать удалённый репозиторий
git clone https://github.com/user/project.git

# Посмотреть статус (какие файлы изменены)
git status

# Добавить файл в зону ожидания
git add main.py

# Создать коммит
git commit -m "Добавлена функция сложения"

# Посмотреть историю коммитов
git log --oneline
# a1b2c3d Добавлена функция сложения
# e4f5g6h Создан проект

# Создать новую ветку
git branch feature/new-button

# Переключиться на ветку
git checkout feature/new-button

# Или создать и переключиться одной командой
git checkout -b feature/new-button

# Слить ветку в текущую (находясь в main)
git merge feature/new-button

# Отправить коммиты на удалённый репозиторий
git push origin main

# Скачать чужие коммиты с удалённого репозитория
git pull origin main

Типичный конфликт слияния и его решение:

python

# В main:
def get_price():
    return 100

# В feature (ветке):
def get_price():
    return 200

При слиянии Git пишет:

text

CONFLICT in file.py
Auto-merge failed

Разработчик открывает файл и видит:

python

<<<<<<< HEAD
    return 100
=======
    return 200
>>>>>>> feature

Нужно вручную выбрать (или оставить оба варианта, или написать новый). После правки:

python

    return 150  # ручное решение

Затем: git add file.py && git commit (конфликт разрешён).

GitFlow (популярный процесс работы с ветками):

Ветка	Назначение	Создаётся от	Сливается в
`main`	Только стабильные релизы	—	—
`develop`	Основная разработка	`main`	`main` (при релизе)
`feature/название`	Новая функция	`develop`	`develop`
`release/версия`	Подготовка релиза (только баги)	`develop`	`main` и `develop`
`hotfix/название`	Срочное исправление бага в продакшене	`main`	`main` и `develop`

Упрощённый вариант (GitHub Flow):

Одна ветка main (стабильная)
На каждую задачу создаётся ветка feature/название
После завершения — Pull Request → код-ревью → слияние в main
Ветка удаляется

Практические советы:

Чаще делайте git pull, чтобы не было конфликтов.

Коммиты должны быть маленькими (один коммит — одно изменение)

Сообщение коммита понятное: Исправлен баг с нулевой ценой (а не фикс)

Не коммитьте сломанный код (тесты должны проходить)

Вопрос 9.

Работа с удалёнными репозиториями GitHub, GitLab, Bitbucket

Краткая теория: Удалённые репозитории — это Git-серверы в облаке или на своём сервере. Они позволяют команде иметь общий доступ к коду, делать код-ревью, автоматическую сборку и тестирование. Три основных хостинга: GitHub, GitLab, Bitbucket.

Сравнение трёх платформ (главное):

Характеристика	GitHub	GitLab	Bitbucket
Владелец	Microsoft	GitLab Inc.	Atlassian
Популярность	Огромная (100+ млн)	Средняя	Ниже
Бесплатные приватные репозитории	Да (без лимита)	Да (до 5 пользователей)	Да (до 5 разработчиков)
Self-hosted (свой сервер)	Платно (Enterprise)	Бесплатно (CE)	Платно (Server)
Встроенный CI/CD	GitHub Actions	GitLab CI (лучший)	Bitbucket Pipelines
Интеграция с Jira	Через плагины	Ограниченная	Родная (глубокая)
Open Source сообщество	Огромное	Среднее	Маленькое
Лучшая фишка	Сообщество, Actions	CI/CD, self-hosted	Связка с Jira

Что такое Pull Request (GitHub) / Merge Request (GitLab):

Запрос на слияние твоей ветки в основную. Включает:

Сравнение изменений (что добавлено, что удалено)
Обсуждение (можно комментировать каждую строку кода)
Code review (коллеги проверяют код до слияния)
Автоматические проверки (тесты, линтеры, сборка)

Процесс работы через Pull Request:

text

1. Создал ветку feature/payment на локальном компьютере
2. Написал код, сделал коммиты
3. git push origin feature/payment (отправил на GitHub)
4. На GitHub нажал "Compare & pull request"
5. Написал описание: "Добавлена оплата картой"
6. Коллеги видят PR, оставляют комментарии
7. Автоматически запускаются тесты (CI)
8. После одобрения (approve) нажимают "Merge pull request"
9. Ветка слита в main, можно её удалить

Особенности каждой платформы:

GitHub:

Самый популярный, стандарт индустрии
GitHub Actions — CI/CD с огромным количеством готовых действий
GitHub Copilot (ИИ-помощник) платный
GitHub Pages — бесплатный хостинг для статических сайтов
Sponsors — донаты для Open Source авторов

GitLab:

Один продукт вместо многих (репозиторий + CI/CD + мониторинг + реестр контейнеров)
GitLab CI — считается самым мощным, настраивается одним файлом .gitlab-ci.yml
Self-hosted бесплатно — банки и госорганы часто выбирают GitLab
Встроенный мониторинг (Prometheus, Grafana)

Bitbucket:

Глубокая интеграция с Jira: можно в коммите написать PROJ-123 и он привяжется к задаче
Поддержка Mercurial (редкость, но Mercurial почти умер)
Bitbucket Pipelines проще, чем GitLab CI, но слабее
Бесплатно до 5 разработчиков

Пример файла CI/CD для GitHub Actions (.github/workflows/test.yml):

yaml

name: Run tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - run: pip install pytest
      - run: pytest tests/

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

Выбор хостинга по ситуации:

Ситуация	Какой выбрать
Open Source проект	GitHub (сообщество, звёзды, форки)
Стартап с маленькой командой	GitHub (бесплатно, Actions)
Банк или госорганы (свой сервер)	GitLab (self-hosted бесплатно)
Компания уже использует Jira и Confluence	Bitbucket (родная интеграция)
Нужен мощный CI/CD без боли	GitLab
Студент, хочет портфолио	GitHub (профиль с зелёными квадратиками)

Вопрос 10.

Виды ошибок в программном обеспечении

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

1. Классификация по времени обнаружения:

Вид ошибки	Когда проявляется	Пример	Как искать
Синтаксическая	При компиляции или запуске интерпретатора	`pritn("Hello")` вместо `print`	Компилятор/интерпретатор укажет строку
Времени выполнения (runtime)	Во время работы программы	Деление на ноль, нулевой указатель	Отладчик, логирование
Логическая	Программа работает, но выдаёт неверный результат	Калькулятор выводит 2+2=5	Тесты, сравнение с эталоном

Примеры каждого вида:

python

# 1. Синтаксическая ошибка
if x = 5:        # Ошибка: должно быть ==, а не =
    print(x)

# 2. Ошибка времени выполнения
y = 0
x = 10 / y       # ZeroDivisionError

# 3. Логическая ошибка
def is_even(n):
    return n % 2 == 1   # Ошибка: должно быть == 0

2. Классификация по серьёзности (баг-трекеры Jira, YouTrack):

Уровень	Обозначение	Что значит	Пример	Действие
Blocker	P0	Дальше работать нельзя, программа не запускается	Приложение падает при старте	Исправить немедленно (релиз отложить)
Critical	P1	Важная функция полностью не работает	Кнопка «Оплатить» ничего не делает	Исправить до релиза
Major	P2	Важная функция работает с ошибками, но есть обходной путь	Цена отображается неверно, но в чеке правильная	Исправить в следующем релизе
Minor	P3	Мелкий баг, не влияет на основную работу	Кнопка чуть съехала влево	В плановом порядке
Trivial	P4	Косметическая ошибка	Опечатка в подсказке	Если есть время

3. Классификация по происхождению (причине):

Тип ошибки	Пример	Как предотвратить
Ошибка ввода-вывода	Файл не найден, нет прав на запись, диск заполнен	Проверять результат операций ввода-вывода
Ошибка многопоточности	Race condition (гонка данных), deadlock (взаимная блокировка)	Использовать блокировки, атомарные операции
Ошибка памяти	Утечка памяти, выход за границы массива, double free	Умные указатели (C++), сборщик мусора (Java, Python)
Ошибка бизнес-логики	При скидке 10% вычитается 10 рублей, а не 10%	Более тщательное тестирование, TDD
Ошибка окружения	На компьютере разработчика работает, на сервере — нет	Контейнеризация (Docker), CI/CD
Ошибка целочисленного переполнения	`2000000000 + 2000000000 = -294967296` (в 32-битном int)	Использовать типы с контролем переполнения
Ошибка неинициализированной переменной	`int x; cout << x;` (выведет мусор)	Всегда инициализировать переменные
Ошибка округления (float)	`0.1 + 0.2 = 0.30000000000000004`	Использовать Decimal для денег

Пример ошибки с плавающей точкой (неожиданный результат):

python

a = 0.1
b = 0.2
c = a + b
print(c)  # 0.30000000000000004, а не 0.3

4. Классификация по способу воспроизведения:

Тип	Что значит	Пример	Сложность исправления
Стабильные (постоянные)	Воспроизводятся всегда	Кнопка «Вход» не работает при пустом пароле	Низкая
Плавающие (эпизодические)	Возникают случайно, 1 раз из 100	Программа падает раз в день, неясно почему	Высокая (очень трудно искать)
Зависимые от данных	Появляются только на определённых данных	Ошибка возникает только при сумме > 1 000 000	Средняя

Плавающие ошибки — самые сложные. Часто связаны с:

Многопоточностью (состояние гонки)
Неинициализированными переменными
Проблемами с сетью (таймауты, потеря пакетов)

Как писать сообщение об ошибке (баг-репорт):

Поле	Что писать	Пример
Заголовок	Кратко суть	«Кнопка «Купить» не работает в Safari на iPad»
Шаги воспроизведения	Что нажать, в каком порядке	1. Открыть Safari 2. Зайти на сайт 3. Нажать «Купить»
Ожидаемый результат	Как должно работать	Открывается форма оплаты
Фактический результат	Что происходит на самом деле	Ничего не происходит, ошибка в консоли
Окружение	ОС, браузер, версия	iPadOS 16.4, Safari 16.4
Скриншот / лог	Доказательство	(вложение)
Серьёзность	Blocker/Critical/Major/Minor	Major

Пример правильного баг-репорта:

text

Заголовок: При попытке оплаты на Safari падает ошибка "undefined is not an object"

Шаги:
1. Открыть сайт на iPad Safari
2. Добавить товар в корзину
3. Нажать "Перейти к оплате"
4. Ввести карту 1111 2222 3333 4444
5. Нажать "Оплатить"

Ожидание: Оплата проходит, появляется чек
Реальность: Ошибка "undefined is not an object" (строка 147 в payment.js)

Окружение: iPadOS 16.4, Safari 16.4, версия сайта от 10.06.2024
Серьёзность: Critical (оплата не работает)

Вопрос 11.

Методы поиска и исправления ошибок в программе

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

Основные методы поиска ошибок (сравнение):

Метод	Как работает	Когда применять	Пример
Визуальный осмотр кода (code review)	Другой разработчик смотрит код	До слияния ветки, перед релизом	Коллега заметил `if x = 5` (присваивание вместо сравнения)
Отладка с точками останова	Программа останавливается на нужной строке	Когда ошибка воспроизводится	Остановились перед делением — увидели, что делитель = 0
Пошаговое выполнение	Выполняем код по одной строке	Когда неясно, где именно ошибка	Прошли 10 строк — переменная `x` стала отрицательной
Логирование	Вывод отладочных сообщений в файл/консоль	Плавающие ошибки, серверная разработка	`log.debug(f"x={x}, y={y}")`
Модульные тесты	Пишем тесты, проверяющие каждый кусок	Постоянно, после исправления ошибки	Тест: `assert divide(10,2) == 5`
Ассерты	Вставка проверок, которые «кричат» при нарушении	Для инвариантов (что всегда должно быть верно)	`assert y != 0, "Делитель не может быть нулём"`
Статический анализ (линтеры)	Программа проверяет код без запуска	Регулярно, в IDE или CI	Pylint: «переменная определена, но не используется»
Профилирование	Анализ времени выполнения функций	Когда программа работает медленно	Профилировщик показал: 80% времени в `sort_data()`
Бинарный поиск (git bisect)	Git ищет коммит, где появилась ошибка	Когда ошибка появилась недавно	Git нашёл коммит от вторника, где изменили формулу
Метод «утиной отладки»	Объясняем ошибку кому-то (или утке)	Когда зашли в тупик	В процессе объяснения сами поняли причину
Воспроизведение на минимальном примере	Сокращаем код до минимума, где ошибка ещё проявляется	Когда код большой и сложный	Из 1000 строк оставили 10 — ошибка осталась

Пример отладки с точками останова (пошагово):

python

def calculate_price(price, discount):
    result = price - discount * 2  # Ошибка: лишнее умножение на 2
    return result

final = calculate_price(100, 20)  # Ожидаем 80, получаем 60

Процесс отладки:

Шаг	Действие	Что видим
1	Ставим точку останова на строке `result = price - discount * 2`	Строка подсвечена
2	Запускаем отладку (Debug)	Программа остановилась
3	Смотрим значения переменных	`price = 100`, `discount = 20`
4	Выполняем строку (Step Over)	`result` стал `60`
5	Понимаем: формула неверная	Исправляем на `price - discount`

Метод «разделяй и властвуй» (бинарный поиск ошибки):

Если программа из 1000 строк выдаёт ошибку, ищем не с начала:

Шаг	Диапазон	Действие	Результат
1	1–1000	Проверяем строки 1–500	Ошибки нет → ошибка в 501–1000
2	501–1000	Проверяем 501–750	Ошибка есть → в 501–750
3	501–750	Проверяем 501–625	Ошибка есть → в 501–625
4	501–625	Проверяем 501–563	Ошибки нет → в 564–625

За 4 шага нашли 62 строки, за 10 шагов можно найти одну строку в 1000.

Метод «утиной отладки» (rubber duck debugging):

Берёте игрушечную утку (или просто представляете собеседника) и объясняете:

«Вот у меня есть функция, которая должна считать цену со скидкой. Берём цену 100 и скидку 20. Сначала вычитается скидка… А, понял! Я же умножил скидку на 2!»

В процессе объяснения ошибка становится очевидной.

Исправление ошибок (алгоритм):

Шаг	Действие	Пример
1	Понять причину, а не следствие	Деление на ноль из-за того, что `y` не проверяется
2	Исправить минимальным изменением	Добавить `if y == 0: return 0`
3	Написать тест, который ловит эту ошибку	`assert divide(10, 0) == 0`
4	Проверить, что не сломали другое	Запустить все старые тесты
5	Закоммитить с понятным сообщением	`git commit -m "Исправлен баг с делением на ноль"`

Важное правило: Исправляйте причину, а не следствие. Если исправить следствие (например, просто подавить ошибку try-except), она появится снова в другом месте.

Вопрос 12.

Тестирование программного обеспечения: понятие и цели

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

Основные цели тестирования:

Цель	Что значит	Пример
Найти ошибки	Обнаружить дефекты до того, как их увидит пользователь	Кнопка «Купить» не работает после обновления
Проверить соответствие требованиям	Программа делает то, что написано в ТЗ	В ТЗ: «скидка 10% при сумме > 1000» — проверяем
Оценить качество	Понять, готова ли программа к релизу	50 критических багов → не готово; 2 мелких → можно
Предотвратить ошибки	Улучшить процесс разработки на основе найденных багов	Часто ошибаются в модуле оплаты → усилить code review
Дать информацию для решений	Руководитель решает: выпускать или нет	95% тестов пройдено → можно выпускать
Снизить риски	Убедиться, что критичные функции работают	Проверили списание денег — это критично

Уровни тестирования (по объёму проверяемого кода):

Уровень	Что тестируем	Кто пишет	Пример
Модульное (unit)	Отдельные функции, классы	Программист	Функция `sum(2,3)` должна вернуть 5
Интеграционное	Как модули работают вместе	Программист или тестировщик	База данных + бизнес-логика: запрос возвращает данные
Системное	Вся программа целиком	Тестировщик	Полный сценарий: регистрация → покупка → оплата
Приёмочное (UAT)	Программа решает бизнес-задачи заказчика	Заказчик	Бухгалтер проверяет отчёт по налогам

Виды тестирования (по характеру проверок):

Вид	Что проверяем	Инструменты	Пример
Функциональное	Работают ли функции по ТЗ	JUnit, pytest, Selenium	Кнопка «Вход» открывает форму
Нагрузочное	Поведение под большой нагрузкой	JMeter, k6, Locust	1000 пользователей → время ответа < 2 сек
Безопасности	Можно ли взломать	OWASP ZAP, Burp Suite	SQL-инъекции не проходят
Юзабилити	Удобно ли пользоваться	Ручное тестирование	Кнопка «Купить» заметна и на месте
Регрессионное	Не сломались ли старые функции	Автоматические тесты	Добавили скидки — проверили обычную покупку
Дымовое (smoke)	Запускается ли программа вообще	Ручной запуск	Программа не падает при старте
Alpha-тестирование	Внутри команды разработки	Ручное	Разработчики проверяют новую версию
Beta-тестирование	Реальные пользователи	Сбор отзывов	Выпустили бета-версию для 1000 пользователей

Принципы тестирования (важные истины):

Принцип	Смысл	Пример
Нельзя протестировать всё	Всегда будут неохваченные сценарии	Тестируем только типичные и граничные случаи
Отсутствие ошибок не гарантия	Тесты прошли — но другие сценарии могут упасть	На Windows работает, на Linux — нет
Скопление дефектов	80% ошибок в 20% модулей	Самые сложные модули — самые бажные
Парадокс пестицида	Повторяя одни тесты, новых ошибок не найдёшь	Нужно обновлять тесты
Тестирование зависит от контекста	Разный подход для разных систем	Игру и банк тестируют по-разному

Пирамида тестирования

Самая вершина пирамиды: 10% UI-тесты (медленные, дорогие)

Середина пирамиды: 20% интеграционные тесты
Низ пирамиды: 70% модульные тесты (быстрые, дёшевые)

Пример тестирования простой функции:

python

def divide(a, b):
    return a / b

Набор тестов:

Тест	Вход	Ожидаемый результат
Обычное деление	divide(10, 2)	5
Деление на 1	divide(10, 1)	10
Деление на отрицательное	divide(10, -2)	-5
Деление нуля	divide(0, 5)	0
Деление на ноль	divide(10, 0)	ZeroDivisionError
Отрицательное на отрицательное	divide(-10, -2)	5

Вопрос 13.

Инструменты для тестирования программного обеспечения

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

1. Инструменты модульного тестирования (Unit testing):

Инструмент	Язык	Особенность	Пример кода
JUnit	Java	Стандарт де-факто	`assertEquals(5, calculator.add(2, 3))`
pytest	Python	Простой синтаксис	`assert add(2, 3) == 5`
unittest	Python	Встроенный в Python	`self.assertEqual(add(2,3), 5)`
Jest	JavaScript (React)	Снэпшот-тесты	`expect(sum(1,2)).toBe(3)`
Google Test	C++	От Google	`EXPECT_EQ(5, add(2, 3))`
NUnit	C#/.NET	Аналог JUnit	`[Test] public void AddTest()`

2. Инструменты интеграционного тестирования (API, БД):

Инструмент	Что делает	Пример использования
Postman	Тестирование REST API	Запрос `GET /users/1` → проверка JSON ответа
SoapUI	SOAP и REST API	Тестирование веб-сервисов
REST Assured	REST API на Java	`given().get("/users/1").then().statusCode(200)`
Testcontainers	Запуск БД в Docker	Поднять PostgreSQL, выполнить тесты, уничтожить

3. Инструменты тестирования UI (пользовательского интерфейса):

Инструмент	Что делает	Пример кода
Selenium	Автоматизация браузера	`driver.find_element(By.ID, "login").click()`
Cypress	UI-тесты для веб (быстрее Selenium)	`cy.get('#login').click()`
Playwright	От Microsoft (все браузеры)	`await page.click('#login')`
Appium	Мобильные приложения	Нажать на кнопку в Android/iOS

4. Инструменты нагрузочного тестирования (Performance):

Инструмент	Что делает	Особенность
JMeter	Создаёт нагрузку на сервер	1000 одновременных запросов
k6	Современный, на JS	`http.get('https://test.com')`
Locust	На Python, распределённый	1000 пользователей кладут товары в корзину
LoadRunner	Профессиональный (дорогой)	Для банковских систем

5. Инструменты тестирования безопасности:

Инструмент	Что делает	Пример
OWASP ZAP	Ищет уязвимости в веб	SQL-инъекции, XSS
Burp Suite	Перехват и модификация запросов	Изменить цену в запросе
SonarQube	Анализирует код на уязвимости	Нашёл `"SELECT * FROM users WHERE id = " + userId`

6. Статический анализ кода (линтеры):

Инструмент	Язык	Что проверяет
ESLint	JavaScript	Стиль, неиспользуемые переменные
Pylint	Python	Оценка кода (10/10), проблемы
Checkstyle	Java	Отступы, названия
Black	Python	Автоформатирование

7. Управление тестами и багами:

Инструмент	Что делает
Jira	Баг-трекер, управление задачами
YouTrack	Аналог Jira от JetBrains
TestRail	Хранение тест-кейсов и результатов
Allure	Красивые HTML-отчёты с графиками

Пример выбора инструментов по ситуации:

Ситуация	Инструменты
Небольшой проект на Python	pytest + Postman + ручное UI
Веб-приложение на Java	JUnit + Selenium + JMeter + SonarQube
Мобильное приложение	Appium + JUnit + Firebase Test Lab
Критичная система (банк)	Все выше + LoadRunner + Burp Suite

Вопрос 14.

Документирование программного обеспечения

Документация — это текстовое или графическое описание программы, её архитектуры, установки, использования. Без документации программа становится «чёрным ящиком». Хорошая документация экономит время на поддержку и обучение новых разработчиков.

Зачем нужна документация:

Причина	Объяснение
Обучение новых разработчиков	Читают руководство программиста → быстро входят в курс
Упрощение сопровождения	Через год вспоминают, почему приняли решение
Общение с заказчиком	ТЗ подписано — меньше споров
Установка и настройка	README: «скачай, запусти install.bat»
API для других разработчиков	Документация REST API: URL, параметры, ответы

Классификация документации по назначению:

Тип	Для кого	Что содержит
Пользовательская	Конечные пользователи	Установка, запуск, использование, настройки
Техническая	Разработчики	Архитектура, API, схемы БД, алгоритмы
Управленческая	Менеджеры, заказчики	ТЗ, планы, отчёты, бюджеты

Основные виды документации (с примерами):

Вид	Кто создаёт	Содержание
Техническое задание (ТЗ)	Аналитик	Функции, сроки, бюджет, требования
Руководство пользователя	Технический писатель	Как войти, как создать отчёт, горячие клавиши
Руководство администратора	Технический писатель	Установка, настройка БД, бэкапы
Руководство программиста	Разработчики	Описание модулей, API, сборка
README	Разработчики	Что за проект, как установить, как запустить
API-документация	Разработчики	`GET /users/{id}` → JSON с полями
Комментарии в коде	Программисты	`# Функция сортирует массив по возрастанию`
Релизные заметки	Менеджер	Что нового в версии 2.0
CHANGELOG	Разработчики	История изменений по версиям

Золотые правила документирования:

Правило	Почему
Пиши для человека через год	Через год ты забудешь детали
Не дублируй код	`i++ // увеличиваем i» — бесполезно \|
Объясняй «почему», а не «что»	Код показывает «что», комментарий — «почему»
Обновляй вместе с кодом	Устаревшая документация хуже, чем её отсутствие
Используй автогенерацию	Javadoc, Doxygen экономят время

Вопрос 15.

Виды программной документации

Программная документация — это не один документ, а целый набор. В разных стандартах (ГОСТ, ISO) перечисляются обязательные виды. На практике набор зависит от проекта: для мобильной игры — минимум, для авиационной системы — десятки документов.

Сводная таблица всех видов документации:

Вид	Содержание	Обязательность	Для кого
Техническое задание (ТЗ)	Требования заказчика: функции, сроки, бюджет	Обязательно для госзаказа	Заказчик, менеджеры
Пояснительная записка	Обоснование выбора архитектуры, алгоритмов	Часто	Разработчики
Руководство пользователя	Как пользоваться программой	Почти всегда	Пользователи
Руководство администратора	Установка, настройка БД, бэкапы	Для серверных систем	Администраторы
Руководство программиста	Описание модулей, API, сборка	Для крупных проектов	Разработчики
Описание API	Эндпоинты, параметры, ответы	Для веб-сервисов	Клиенты
Спецификация требований (SRS)	Детальные требования, use cases	Для крупных проектов	Разработчики, тестировщики
План тестирования	Что тестируется, как, какие инструменты	Для серьёзных проектов	Тестировщики
Программа и методика испытаний	Как будет проводиться приёмочное тестирование	По ГОСТ	Тестировщики, заказчик
README	Кратко: установка, запуск, примеры	Всегда для Open Source	Все
CHANGELOG	История изменений по версиям	Часто	Разработчики, пользователи
CONTRIBUTING	Как помочь проекту	Для Open Source	Контрибьюторы
ЛИЦЕНЗИЯ (LICENSE)	Условия использования кода	Для Open Source	Все
Архитектурная документация	Диаграммы компонентов, слоёв	Для крупных систем	Архитекторы
Схема БД (ER-диаграмма)	Таблицы, связи, индексы	Для систем с БД	Разработчики, DBA

Пример набора документации для разных проектов:

Тип проекта	Минимальный набор	Дополнительно
Студенческая курсовая	Пояснительная записка + листинг кода	—
Мобильное приложение	README + комментарии + API (если есть)	Руководство пользователя
Веб-сервис (стартап)	README + API (Swagger) + Release notes	Руководство программиста
Корпоративная система	ТЗ + руководства (пользователя, админа, программиста) + схема БД	План тестирования
Авиационная система	Все выше + десятки документов по ГОСТ	Сертификационные документы

Структура руководства пользователя (пример):

text

1. Введение
   - Назначение программы
   - Системные требования

2. Установка и запуск
   - Установка
   - Первый запуск
   - Регистрация

3. Работа с программой
   - Главное окно
   - Создание отчёта
   - Экспорт данных
4. Настройки
   - Профиль пользователя
   - Параметры отображения
5. Часто задаваемые вопросы (FAQ)
6. Решение типичных проблем
7. Алфавитный указатель

Вопрос 16.

Требования к оформлению технической документации

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

Основные требования к оформлению (по ГОСТ 19.106-78 и современной практике):

Требование	Что значит	Пример
Стандартный шрифт	Times New Roman или Arial, размер 12–14 пт	Весь документ одним шрифтом
Полуторный межстрочный интервал	Строки не слипаются	1,5 интервала
Поля	Левое — 30 мм, правое — 10 мм, верхнее/нижнее — 20 мм	Для подшивки в папку
Нумерация страниц	Сверху или снизу, по центру или справа	Страница 5 из 50
Нумерация разделов	1., 1.1., 1.1.1. — не более 4 уровней	2.3.1. Описание функции
Заголовки	Жирный шрифт, отделены от текста	1. Общие положения
Таблицы	Сквозная нумерация, заголовок над таблицей	Таблица 3 — Характеристики
Рисунки	Сквозная нумерация, подпись под рисунком	Рисунок 2 — Схема алгоритма
Ссылки	На разделы, таблицы, рисунки — по номерам	«как показано на рисунке 3»
Сокращения	Расшифровка при первом употреблении	ПО (программное обеспечение)
Приложения	Отдельная нумерация (Приложение А, Б)	Приложение А — Листинг кода

Структура технического документа (по ГОСТ):

Часть	Что содержит
Титульный лист	Название, автор, организация, дата
Аннотация	Краткое содержание (1 абзац)
Содержание	Список разделов с номерами страниц
Нормативные ссылки	ГОСТы, на которые ссылаетесь
Определения и сокращения	Расшифровка терминов
Основная часть	Разделы по теме документа
Приложения	Дополнительные материалы
Лист регистрации изменений	Кто и когда менял документ

Требования к тексту (стилистика):

Требование	Правильно	Неправильно
Безличные предложения	«Программа сохраняет файл»	«Я написал программу, которая сохраняет файл»
Единообразие терминов	«пользователь», «окно», «кнопка»	то «юзер», то «оператор», то «пользователь»
Краткость	«Нажмите кнопку ОК»	«Для того чтобы подтвердить действие, необходимо нажать на расположенную в правом нижнем углу кнопку с надписью ОК»
Активный залог	«Программа открывает окно»	«Окно открывается программой»

Что НЕЛЬЗЯ делать в технической документации:

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

Вопрос 17.

Назначение технического задания на разработку ПО

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

Назначение ТЗ (зачем он нужен):

Назначение	Объяснение	Пример
Фиксация требований	Заказчик говорит, что хочет; исполнитель записывает	«Кнопка «Купить» должна быть зелёной и в правом верхнем углу»
Правовая защита	Если спор — смотрят ТЗ	«Вы сказали сделать красную кнопку, а в ТЗ зелёная»
Планирование сроков и бюджета	По ТЗ оценивают, сколько времени нужно	10 экранов → 2 недели → 200 000 руб
Основа для приёмки	Заказчик проверяет по ТЗ, всё ли сделано	По ТЗ должна быть авторизация — проверили, работает
Снижение рисков	Меньше недопонимания между сторонами	Заказчик думал про «управление пользователями», а ТЗ уточняет: «добавление, удаление, редактирование»

Что даёт ТЗ каждой стороне:

Сторона	Что получает от ТЗ
Заказчик	Уверенность, что сделают то, что нужно; есть на что ссылаться при приёмке
Исполнитель (разработчик)	Чёткие границы работы; защита от «а давайте ещё добавим» без доплаты
Менеджер	Основа для планирования сроков и ресурсов
Тестировщик	Что проверять; что считается ошибкой, а что — не предусмотрено

Пример из жизни: Заказчик говорит: «Сделайте интернет-магазин». Без ТЗ разработчик делает самый простой вариант. А заказчик хотел: интеграцию с 1С, скидки по промокодам, личный кабинет с историей заказов. Спор. С ТЗ всё чётко: что есть в ТЗ — делаем, чего нет — не делаем или за доплату.

Когда ТЗ не нужно:

Ситуация	Почему
Студенческая курсовая	Преподаватель дал задание устно
Свой проект для себя	Сам себе заказчик
Очень маленькая доработка	«Поменять цвет кнопки» — можно в чате
Open Source проект	Обычно обходятся README и Issues

Вопрос 18.

Назначение технического задания на разработку ПО

Назначение ТЗ (зачем он нужен):

Назначение	Объяснение	Пример
Фиксация требований	Заказчик говорит, что хочет; исполнитель записывает	«Кнопка «Купить» должна быть зелёной и в правом верхнем углу»
Правовая защита	Если спор — смотрят ТЗ	«Вы сказали сделать красную кнопку, а в ТЗ зелёная»
Планирование сроков и бюджета	По ТЗ оценивают, сколько времени нужно	10 экранов → 2 недели → 200 000 руб
Основа для приёмки	Заказчик проверяет по ТЗ, всё ли сделано	По ТЗ должна быть авторизация — проверили, работает
Снижение рисков	Меньше недопонимания между сторонами	Заказчик думал про «управление пользователями», а ТЗ уточняет: «добавление, удаление, редактирование»

Что даёт ТЗ каждой стороне:

Сторона	Что получает от ТЗ
Заказчик	Уверенность, что сделают то, что нужно; есть на что ссылаться при приёмке
Исполнитель (разработчик)	Чёткие границы работы; защита от «а давайте ещё добавим» без доплаты
Менеджер	Основа для планирования сроков и ресурсов
Тестировщик	Что проверять; что считается ошибкой, а что — не предусмотрено

Когда ТЗ не нужно:

Ситуация	Почему
Студенческая курсовая	Преподаватель дал задание устно
Свой проект для себя	Сам себе заказчик
Очень маленькая доработка	«Поменять цвет кнопки» — можно в чате
Open Source проект	Обычно обходятся README и Issues

Вопрос 19.

Пользовательская документация и руководство пользователя

Пользовательская документация — это документы, которые читает конечный пользователь программы. Главный из них — Руководство пользователя. Оно объясняет, как установить, запустить и пользоваться программой, не углубляясь в технические детали.

Назначение руководства пользователя:

Назначение	Объяснение
Обучить пользователя	Человек впервые открыл программу — прочитал и понял, что делать
Снизить нагрузку на поддержку	Пользователи сами находят ответы, не звонят в техподдержку
Зафиксировать workflow	Как правильно выполнять типовые задачи
Объяснить настройки	Что означает каждый параметр

Структура руководства пользователя (стандартная):

Раздел	Что содержит	Пример
1. Введение	Назначение программы, для кого	«Программа учёта товаров для кассиров»
2. Системные требования	Что нужно для работы	Windows 10, 4 ГБ RAM, 100 МБ диска
3. Установка	Как установить программу	«Запустите setup.exe, следуйте инструкции»
4. Первый запуск	Как запустить, регистрация	«Ярлык на рабочем столе, логин: admin, пароль: admin»
5. Интерфейс	Обзор экранов и кнопок	Скриншот с подписями элементов
6. Типовые задачи	Пошаговые инструкции	«Как добавить товар: нажмите «Добавить» → введите данные → нажмите «Сохранить»»
7. Настройки	Изменение параметров	«Как сменить язык интерфейса»
8. Часто задаваемые вопросы (FAQ)	Типичные проблемы	«Что делать, если забыл пароль?»
9. Сообщения об ошибках	Что означают ошибки	«Ошибка 404 — файл не найден»
10. Алфавитный указатель	Быстрый поиск терминов	«Кнопка → 15, Корзина → 23, Отчёт → 45»

Пример раздела «Как добавить товар» (руководство пользователя):

5.2. Добавление нового товара
Чтобы добавить товар в систему:
1. Нажмите на кнопку «Товары» в левом меню.
   → Откроется список товаров.
2. Нажмите на кнопку «+ Добавить товар» в правом верхнем углу.
   → Откроется форма добавления товара.
3. Заполните поля:
   - Название товара (обязательно)
   - Цена (только цифры)
   - Количество на складе (целое число)
   - Категория (выберите из списка)
4. Нажмите на кнопку «Сохранить».
   → Появится сообщение: «Товар успешно добавлен».
5. Новый товар появится в списке товаров.

Примечание: Поле «Название товара» не может быть пустым. Если вы не заполните его, кнопка «Сохранить» будет неактивна.

Требования к руководству пользователя:

Требование	Что значит	Пример
Простой язык	Без технического жаргона	Вместо «аутентификация» — «вход по логину и паролю»
Много скриншотов	Пользователь видит, что должно быть на экране	Скриншот окна с подписями кнопок
Пошаговые инструкции	Нумерованные списки	1. Сделай это, 2. Сделай то
Выделение важного	Внимание, примечание, совет	«Важно: перед удалением товара сделайте бэкап»
Алфавитный указатель	Быстрый поиск	«Корзина — стр. 45, Оплата — стр. 67»

Онлайн-документация (современный подход):

Вместо PDF-файла многие делают веб-страницы:

Платформа	Особенность
ReadTheDocs	Бесплатно для Open Source
GitHub Wiki	Встроенная вики в репозитории
Confluence	Корпоративная вика (от Atlassian)
MkDocs	Markdown → красивый HTML-сайт
Notion / GitBook	Современные инструменты для документации

Вопрос 20.

Совместная разработка программного обеспечения

Совместная разработка — это когда над одним проектом работает команда из нескольких человек (от 2 до сотен). Это требует дисциплины, инструментов (Git, баг-трекеры, чаты) и чёткого распределения ролей. Без этого код превращается в хаос.

Основные проблемы совместной разработки и их решения:

Проблема	Решение	Инструменты
Код перезаписывается	Система контроля версий	Git
Непонятно, кто что делает	Задачи, баг-трекер	Jira, YouTrack, Trello
Разные стили кода	Линтеры, форматтеры, code style	ESLint, Black, Prettier
Ошибки попадают в продакшен	Code review, CI/CD, тесты	Pull Request, GitHub Actions
Нет документации	Вики, README, комментарии	Confluence, MkDocs
Разработчики не синхронизированы	Ежедневные встречи (daily standup)	Zoom, Slack, Discord

Модели совместной разработки:

Модель	Как работает	Плюсы	Минусы
Централизованная	Один репозиторий, все пушат в main	Просто	Легко сломать
С интеграционной веткой	Ветка develop, туда сливают фичи	Стабильный main	Чуть сложнее
GitFlow	main + develop + feature + release + hotfix	Полный контроль	Много веток
GitHub Flow	Только main + короткие feature-ветки	Просто, быстро	Не для частых релизов
Форки (Open Source)	Каждый делает форк репозитория	Безопасно	Сложно синхронизировать

Пример командной работы с Git (сценарий):

Петя и Вася работают над проектом.

1. Петя создаёт ветку feature/login:
   git checkout -b feature/login

2. Петя пишет код для входа, коммитит:
   git add .
   git commit -m "Добавлена форма входа"

3. Петя пушит ветку:
   git push origin feature/login

4. Вася делает свою ветку feature/payment:
   git checkout -b feature/payment

5. Вася пишет код оплаты, коммитит, пушит.

6. Петя открывает Pull Request на GitHub.

7. Вася (или тимлид) смотрит код, ставит аппрув.

8. Петя сливает ветку в main:
   git merge feature/login

9. Петя удаляет ветку (локально и на GitHub).

10. Вася перед началом работы подтягивает изменения:
    git pull origin main
    (переключается на свою ветку и сливает туда main, чтобы не было конфликтов)

Что такое Code Review (проверка кода):

Аспект	Что проверяют	Пример замечания
Логика	Правильно ли работает	«Здесь ты делишь на ноль, если y=0»
Стиль	Соответствует ли стандарту	«Назови переменную user_id вместо uid»
Эффективность	Можно ли быстрее	«Вместо O(n²) можно сделать O(n)»
Безопасность	Нет ли уязвимостей	«Конкатенация в SQL — риск инъекции»
Тесты	Есть ли тесты на новый код	«Добавь тест на случай, когда скидка 0%»
Документация	Понятно ли, что делает код	«Добавь комментарий к этой функции»

Правила хорошего Code Review:

Правило	Что значит
Будь вежлив	«Может, тут лучше использовать цикл?» вместо «Ты написал фигню»
Объясняй почему	Не просто «так не надо», а «так не надо, потому что…»
Не мельчи	Не придирайся к опечаткам, если их можно исправить автоматически
Хвали за хорошее	«Отлично, что добавил тест на этот случай»
Смотрите вместе	Иногда полезно посмотреть код на созвоне

Вопрос 21.

Роли участников команды разработки ПО

В современной команде разработки ПО есть несколько ролей. У каждой роли свои задачи и зона ответственности. В маленькой команде один человек может совмещать несколько ролей; в крупной (20+ человек) каждая роль может быть разделена на подроли.

Основные роли в команде разработки (сравнение):

Роль	Главная задача	Кому подчиняется	Типичный опыт
Product Owner (PO)	Определяет, какие функции делать	Бизнес	5+ лет
Project Manager (PM)	Следит за сроками и бюджетом	Руководство	5+ лет
Team Lead (TL)	Техническое руководство командой	Руководство / PM	5+ лет
Бизнес-аналитик (BA)	Собирает и формализует требования	PO / PM	3+ года
Архитектор	Проектирует архитектуру системы	TL / CTO	7+ лет
Разработчик (Developer)	Пишет код	TL	1–10 лет
Тестировщик (QA)	Проверяет программу на ошибки	TL / PM	1–8 лет
DevOps	Настраивает серверы, CI/CD, деплой	TL / CTO	3+ года
Технический писатель	Пишет документацию	PM	1–5 лет
UX/UI дизайнер	Проектирует интерфейс	PO / PM	2+ года
Системный администратор	Обслуживает серверы	DevOps / IT	2+ года

Подробное описание каждой роли:

1. Product Owner (Владелец продукта)

Задачи: Формирует бэклог (список задач), расставляет приоритеты, принимает работу.
Ключевые навыки: Понимание бизнеса, коммуникация, принятие решений.
Ответственность: Продукт решает задачи бизнеса.

2. Project Manager (Менеджер проекта)

Задачи: Составляет план, следит за сроками, управляет рисками, общается с заказчиком.
Ключевые навыки: Планирование, управление людьми, бюджетирование.
Ответственность: Проект сдан в срок и в бюджет.

3. Team Lead (Тимлид)

Задачи: Распределяет задачи внутри команды, проводит code review, помогает разработчикам.
Ключевые навыки: Знание технологий, менторство, коммуникация.
Ответственность: Качество кода и технические решения.

4. Бизнес-аналитик (Business Analyst)

Задачи: Интервьюирует заказчика, пишет ТЗ, спецификации, use cases.
Ключевые навыки: Анализ, документирование, внимание к деталям.
Ответственность: Требования собраны и задокументированы правильно.

5. Архитектор (System Architect)

Задачи: Выбирает технологии, проектирует структуру системы, решает технические риски.
Ключевые навыки: Глубокое знание архитектурных паттернов, опыт.
Ответственность: Архитектура выдерживает нагрузку и масштабируется.

6. Разработчик (Developer)

Уровни: Junior (1–2 года), Middle (2–5 лет), Senior (5+ лет)
Задачи: Пишет код, чинит баги, пишет тесты, проходит code review.
Ключевые навыки: Язык программирования, алгоритмы, Git, отладка.

7. Тестировщик (QA Engineer)

Уровни: Ручное тестирование (manual), автоматизация (automation)
Задачи: Пишет тест-кейсы, тестирует, заводит баги, проверяет исправления.
Ключевые навыки: Внимательность, знание инструментов (JUnit, Selenium).

8. DevOps (Development Operations)

Задачи: Настраивает CI/CD (GitHub Actions, Jenkins), управляет серверами, мониторинг.
Ключевые навыки: Linux, Docker, Kubernetes, облака (AWS, GCP).
Ответственность: Программа работает на сервере.

Пример состава команды для разных размеров проекта:

Размер проекта	Команда
Стартап (3-5 чел)	1 PM (он же PO), 2 разработчика, 1 тестировщик, 1 дизайнер (совмещает UI/UX)
Средний проект (10-15 чел)	PO, PM, TL, 2 аналитика, 5 разработчиков, 2 тестировщика, 1 DevOps, 1 дизайнер
Крупный проект (30+ чел)	Все роли + подроли (бэкенд, фронтенд, мобильные) + несколько тимлидов

Вопрос 22.

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

Системы управления задачами (баг-трекеры, task trackers) — это инструменты для учёта задач, багов, фич и их статусов. Они помогают команде не забыть ничего важного, видеть, кто чем занят, и отслеживать прогресс.

Популярные системы управления задачами:

Система	Кому подходит	Бесплатная версия	Особенность
Jira	Крупные и средние компании	До 10 пользователей	Мощная, сложная, от Atlassian
YouTrack	Команды, которые любят JetBrains	До 10 пользователей	Быстрая, можно на свой сервер
Trello	Маленькие команды, стартапы	Да (с ограничениями)	Простая, доски-колонки
Asana	Менеджмент любых задач	Да (с ограничениями)	Красивый интерфейс
Redmine	Open Source проекты	Полностью бесплатный	Старый, но надёжный
GitHub Issues	Проекты на GitHub	Да	Встроен в репозиторий
GitLab Issues	Проекты на GitLab	Да	Встроен, с досками
ClickUp	Малый бизнес	Да (с ограничениями)	Много функций

Основные сущности в системах управления задачами:

Сущность	Что значит	Пример
Задача (Task/Issue)	Единица работы	«Исправить баг с нулевой ценой»
Проект (Project)	Набор задач	«Разработка интернет-магазина»
Спринт (Sprint)	Период работы (1–4 недели)	«Спринт 12: 10-24 июня»
Статус	Где находится задача	To Do → In Progress → Review → Done
Тип задачи	Что это за задача	Баг, Фича, Технический долг
Приоритет	Насколько срочно	Blocker, Critical, Major, Minor
Оценка (Story Points)	Трудоёмкость	2 SP (≈ 2 часа)
Исполнитель (Assignee)	Кто делает	Иванов И.
Наблюдатели (Watchers)	Кто следит	Петров П.
Эпик (Epic)	Крупная задача из подзадач	«Интеграция с платежной системой»

Типичный жизненный цикл задачи:

1. Создание задачи (кто-то завёл баг или новую фичу)
2. To Do (задача в очереди)
3. In Progress (разработчик взял, делает)
4. Code Review / Testing (готово к проверке)
5. Done (проверено, закрыто)

Пример задачи в Jira (поля):

text

Тип: Баг
Заголовок: Не работает кнопка «Купить» при пустой корзине
Приоритет: Critical
Исполнитель: Иванов И.
Наблюдатели: Петров П., Сидорова А.
Статус: In Progress
Описание:
Шаги:
1. Зайти в корзину
2. Не добавляя товаров, нажать «Купить»
3. Ошибка 500
Ожидание: Сообщение «Корзина пуста»
Окружение: Chrome 120, Windows 11

Интеграция с Git (важная фишка):

Действие	Как работает
Привязать коммит к задаче	В сообщении коммита: `PROJ-123 Исправлен баг с ценой`
Автозакрытие задачи	`git commit -m "PROJ-123 #close Исправлен баг"`
Переход задачи по статусу	При пуше в ветку `feature/PROJ-123` задача переходит в In Progress

Выбор системы по ситуации:

Ситуация	Какую систему взять
Один разработчик	GitHub Issues (достаточно)
Маленький стартап (3-5 чел)	Trello или YouTrack
Средняя команда (5-20 чел)	Jira или YouTrack
Крупная компания (20+ чел)	Jira (стандарт индустрии)
Open Source проект	GitHub Issues или GitLab Issues
Бюджет = 0	Trello (бесплатный) или YouTrack (до 10 чел)

Вопрос 23.

Средства разработки веб-приложений

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

Классификация средств разработки веб-приложений:

Категория	Что делают	Примеры
Фронтенд (клиентская часть)	Внешний вид и поведение в браузере	React, Vue, Angular, Svelte
Бэкенд (серверная часть)	Логика, база данных, API	Node.js, Django, Spring Boot, Laravel
Базы данных	Хранение данных	PostgreSQL, MySQL, MongoDB, Redis
Средства сборки	Объединяют файлы, оптимизируют	Webpack, Vite, Parcel, esbuild
Отладка и тестирование	Поиск ошибок	Chrome DevTools, Jest, Postman, Selenium
CI/CD и деплой	Автовыкладка на сервер	GitHub Actions,

Архитектура веб-приложения:

Уровень	Что делает	Где работает	Примеры технологий
Фронтенд	Отображает интерфейс, обрабатывает действия пользователя	В браузере пользователя	React, Vue, Angular, Svelte
Бэкенд	Логика приложения, работа с БД, авторизация, API	На сервере	Node.js, Django, Spring Boot, Laravel, Ruby on Rails
База данных	Хранит все данные (пользователей, товары, заказы)	На отдельном сервере	PostgreSQL, MySQL, MongoDB, Redis

Инструменты для фронтенд-разработки:

Инструмент	Назначение	Пример использования
React	Библиотека для построения интерфейсов	Создание динамических страниц (лента новостей, корзина)
Vue	Прогрессивный фреймворк	Проще, чем React, для небольших проектов
Angular	Полноценный фреймворк от Google	Крупные корпоративные приложения
Svelte	Современный фреймворк без виртуального DOM	Высокая производительность
Webpack	Сборщик модулей	Объединяет все файлы в один бандл
Vite	Быстрый сборщик для современных проектов	Замена Webpack в новых проектах
Chrome DevTools	Отладка прямо в браузере	Просмотр HTML, CSS, сети, консоли

Инструменты для бэкенд-разработки:

Инструмент	Назначение	Для каких задач
Node.js	Серверная среда выполнения	Высоконагруженные приложения, чаты, API
Django	Полноценный фреймворк	Быстрая разработка, админка из коробки
Spring Boot	Фреймворк на Java	Крупные корпоративные системы
Laravel	Фреймворк на PHP	Веб-сайты, интернет-магазины
Express	Минималистичный фреймворк для Node.js	REST API, микросервисы
FastAPI	Современный фреймворк	Высокопроизводительные API

Инструменты для работы с базами данных:

Тип БД	Что хранит	Примеры	Когда использовать
Реляционные (SQL)	Структурированные данные с жёсткими связями	PostgreSQL, MySQL, Oracle	Финансы, учёт, заказы
Документные (NoSQL)	Свободные документы (JSON)	MongoDB, CouchDB	Каталоги товаров, логи
Ключ-значение	Очень быстрый доступ по ключу	Redis, Memcached	Кэширование, сессии
Графовые	Связи между объектами	Neo4j, ArangoDB	Социальные сети, рекомендации

Инструменты для API (обмена данными между фронтендом и бэкендом):

Инструмент	Назначение	Особенность
Postman	Тестирование API	Отправка запросов, просмотр ответов
Swagger (OpenAPI)	Документация API	Интерактивная документация с возможностью отправки запросов
GraphQL	Альтернатива REST	Клиент сам решает, какие поля ему нужны
REST API	Стандарт для веб-API	Использует HTTP-методы (GET, POST, PUT, DELETE)

Инструменты для сборки и деплоя (выкладки на сервер):

Инструмент	Назначение	Что делает
Docker	Контейнеризация	Упаковывает приложение со всеми зависимостями
Kubernetes	Оркестрация контейнеров	Управляет множеством контейнеров
GitHub Actions	CI/CD	Автоматически собирает и выкладывает приложение
GitLab CI	CI/CD	Аналог GitHub Actions, встроен в GitLab
Jenkins	CI/CD (классический)	Гибкая настройка для сложных проектов
Nginx	Веб-сервер	Раздаёт статику, проксирует запросы
Apache	Веб-сервер	Классический веб-сервер

Типичный набор инструментов для разных типов веб-приложений:

Тип приложения	Фронтенд	Бэкенд	База данных
Простой сайт-визитка	HTML/CSS (без фреймворков)	Не нужен	Не нужна
Блог или интернет-магазин	React или Vue	Django или Laravel	PostgreSQL или MySQL
Чат или онлайн-игра	React (с WebSocket)	Node.js	Redis (для быстрых операций)
Крупная корпоративная система	Angular	Spring Boot	Oracle или PostgreSQL
Микросервисная архитектура	React или Svelte	Node.js или FastAPI	MongoDB (документная)

Этапы разработки веб-приложения (без кода):

Этап	Что делаем	Какие инструменты
1. Проектирование	Рисуем макеты, схемы БД	Figma, Draw.io
2. Разработка фронтенда	Создаём интерфейс	React/Vue, Vite, Chrome DevTools
3. Разработка бэкенда	Пишем API, подключаем БД	Django/Node.js, Postman
4. Интеграция	Связываем фронтенд с бэкендом	Swagger, Postman
5. Тестирование	Проверяем, ищем ошибки	Jest (фронт), pytest (бэк), Selenium
6. Деплой	Выкладываем на сервер	Docker, GitHub Actions, Nginx
7. Мониторинг	Следим за работой	Grafana, Prometheus, Sentry

Вопрос 24.

Основные требования к качеству программного обеспечения

Качество ПО — это степень, в которой программа удовлетворяет заявленным требованиям и ожиданиям пользователей. Существуют стандарты качества (ISO 25010, ГОСТ Р ИСО/МЭК 25010-2015), которые выделяют несколько характеристик качества.

Модель качества ПО (по ISO 25010 — 8 характеристик):

Характеристика	Что означает	Пример нарушения
Функциональная пригодность	Программа делает то, что обещано	Калькулятор неправильно считает
Надёжность	Программа не падает, работает стабильно	Вылетает раз в час
Производительность	Работает достаточно быстро	Страница грузится 30 секунд
Удобство использования (юзабилити)	Пользователю понятно и комфортно	Кнопка «Купить» находится в неожиданном месте
Безопасность	Данные защищены от несанкционированного доступа	Пароли хранятся в открытом виде
Сопровождаемость	Код легко читать и изменять	Любое изменение ломает три других модуля
Совместимость	Работает с другими системами и в разных окружениях	Не открывается в Safari
Переносимость	Можно установить на разные ОС и оборудование	Работает только на Windows 10

Подробное описание каждой характеристики с подхарактеристиками:

1. Функциональная пригодность:

Подхарактеристика	Что значит
Полнота	Все заявленные функции реализованы
Правильность	Результаты работы верные
Уместность	Функции соответствуют потребностям пользователя

2. Надёжность:

Подхарактеристика	Что значит
Отсутствие сбоев	Не падает при нормальной работе
Устойчивость к ошибкам	Не падает при некорректном вводе
Восстанавливаемость	Может восстановиться после сбоя
Доступность	Работает нужный процент времени (например, 99.9%)

3. Производительность:

Подхарактеристика	Что значит
Время отклика	Быстро отвечает на действия пользователя
Пропускная способность	Обрабатывает много запросов в секунду
Использование ресурсов	Не жрёт всю память и CPU

4. Удобство использования (юзабилити):

Подхарактеристика	Что значит
Понятность	Пользователь понимает, что делать
Обучаемость	Легко освоить новичку
Эстетика	Приятный внешний вид
Доступность (инклюзивность)	Удобно для людей с ограничениями (экранные дикторы, контрастность)

Примеры требований к качеству (как они выглядят в ТЗ):

Характеристика	Конкретное требование
Производительность	Время загрузки главной страницы — не более 2 секунд
Надёжность	Система должна быть доступна 99.9% времени (не более 8 часов простоя в год)
Безопасность	Пароли должны храниться в зашифрованном виде (bcrypt)
Совместимость	Поддержка последних 2 версий Chrome, Firefox, Safari
Удобство использования	Количество кликов для оформления заказа — не более 5

Как измеряется качество (метрики):

Характеристика	Как измерить	Хорошее значение
Надёжность	Среднее время между сбоями (MTBF)	> 1000 часов
Производительность	Время ответа на запрос	< 200 мс
Безопасность	Количество критических уязвимостей	0
Сопровождаемость	Время на добавление новой функции	< 2 дней
Юзабилити	Процент пользователей, выполнивших задание без подсказки	> 80%

Что важнее — качество или скорость выхода на рынок?

Ситуация	Приоритет	Почему
Банковское приложение	Качество (безопасность, надёжность)	Ошибка стоит миллионов
Игра или развлекательное приложение	Скорость выхода	Лучше выпустить быстро, потом доделать
Медицинское ПО	Качество	Ошибка может стоить жизни
MVP стартапа	Скорость выхода	Нужно проверить гипотезу минимальными средствами

Вопрос 25.

Понятие программного обеспечения

Программное обеспечение (ПО) — это совокупность программ, данных и документации, предназначенная для решения определённых задач на компьютере. В отличие от «железа» (hardware), ПО можно копировать, модифицировать и передавать без физических носителей.

Три составляющих ПО (по определению):

Составляющая	Что входит	Пример
Программы	Исполняемый код (инструкции для компьютера)	Файл calc.exe
Данные	Информация, с которой работают программы	База данных клиентов
Документация	Инструкции, описание, комментарии	Руководство пользователя

Отличие ПО от других видов продуктов:

Характеристика	ПО	Физический продукт (стол)
Износ	Не изнашивается от использования	Изнашивается
Копирование	Бесплатно и мгновенно	Требует материалов и времени
Ошибки	Можно исправить без замены носителя	Бракованный стол надо переделывать
Разработка	Требует только умственного труда	Требует материалов и станков

Классификация ПО по назначению (кратко, подробнее в вопросе 26):

Группа	Примеры	Назначение
Системное ПО	Windows, Linux, драйверы	Управление компьютером
Прикладное ПО	Word, Excel, браузеры, игры	Решение задач пользователя
Инструментальное ПО	Компиляторы, IDE, Git	Создание других программ

Свойства ПО как продукта:

Свойство	Что значит
Нематериальность	Его нельзя потрогать, только результат работы
Масштабируемость	Можно установить на миллион компьютеров без доп. затрат
Сложность	Современное ПО может содержать миллионы строк кода
Обновляемость	Можно исправлять ошибки и добавлять функции без замены всего продукта
Зависимость от окружения	Может работать на одном компьютере и не работать на другом

История ПО (очень кратко):

Период	Что появилось	Примеры
1940-1950	Первые программы на машинном языке	Программы для ENIAC
1950-1960	Ассемблеры, первые компиляторы	Fortran, COBOL
1960-1970	Операционные системы, базы данных	IBM OS/360
1970-1980	Персональные компьютеры	MS-DOS, Apple DOS
1980-1990	Графический интерфейс, офисные пакеты	Windows, Mac OS, Microsoft Office
1990-2000	Интернет, веб-браузеры	Netscape, Internet Explorer
2000-2010	Мобильные приложения, облака	iOS, Android, SaaS
2010-2020	AI, блокчейн, контейнеризация	ChatGPT, Docker, смарт-контракты

Самые большие программы в истории (по объёму кода):

Программа	Оценка строк кода	Что делает
Google (все сервисы)	2+ миллиарда	Поиск, сервисы
Windows 11	~50 миллионов	Операционная система
Linux (ядро + окружение)	~30 миллионов	Операционная система
Android	~15 миллионов	Мобильная ОС
Chrome	~10 миллионов	Браузер

Вопрос 26.

Классификация программного обеспечения

Классификация ПО — это разделение всех программ на группы по определённым признакам. Основных признаков три: назначение (для чего нужно), способ распространения (как получить) и архитектура (как устроено внутри).

Основная классификация по назначению (три главных класса):

Класс	Что делает	Примеры	Для кого
Системное ПО	Управляет компьютером, обеспечивает работу других программ	Windows, Linux, macOS, драйверы, BIOS	Для компьютера и других программ
Прикладное ПО	Решает конкретные задачи пользователя	Word, Excel, 1С, браузеры, игры, Photoshop	Для конечных пользователей
Инструментальное ПО	Используется для создания других программ	Компиляторы, IDE, Git, системы тестирования	Для разработчиков

Детальная классификация системного ПО:

Подкласс	Что делает	Примеры
Операционные системы	Управляют ресурсами компьютера	Windows 11, Ubuntu, macOS, Android, iOS
Драйверы	Обеспечивают работу устройств	Драйвер видеокарты, принтера, звуковой карты
Утилиты	Выполняют вспомогательные функции	Антивирусы, дефрагментаторы, архиваторы
Программы резервного копирования	Делают бэкапы	Acronis, Time Machine, rsync

Детальная классификация прикладного ПО:

Подкласс	Что делает	Примеры
Офисное ПО	Работа с документами, таблицами, презентациями	Microsoft Office, LibreOffice, Google Docs
Графическое ПО	Создание и редактирование изображений, видео	Photoshop, GIMP, Figma, Premiere
Браузеры	Просмотр веб-страниц	Chrome, Firefox, Safari, Edge
Бухгалтерское ПО	Ведение бухгалтерии, учёта	1С, SAP, Oracle EBS
Игры	Развлечение	Minecraft, The Witcher, GTA
Образовательное ПО	Обучение	Электронные учебники, тренажёры
Медицинское ПО	Диагностика, учёт пациентов	МИС (медицинские информационные системы)
Коммуникационное ПО	Связь, общение	Zoom, Telegram, Slack, Outlook

Классификация ПО по способу распространения:

Тип	Что значит	Примеры	Плюсы	Минусы
Бесплатное (Freeware)	Можно скачать и использовать бесплатно	Chrome, Skype, Telegram	Бесплатно	Может содержать рекламу
Открытое (Open Source)	Исходный код доступен, можно изменять	Linux, Firefox, GIMP	Свобода, безопасность	Нужны специалисты
Проприетарное	Исходный код закрыт, нужно купить лицензию	Windows, Microsoft Office, Photoshop	Поддержка, гарантии	Дорого
Условно-бесплатное (Shareware)	Бесплатно на пробный период	WinRAR, многие игры	Можно попробовать	Ограничения по времени
SaaS (Software as a Service)	Аренда через браузер	Google Docs, Figma, Salesforce	Не надо устанавливать	Нужен интернет
Adware	Бесплатно, но показывает рекламу	Многие мобильные игры	Бесплатно	Раздражает реклама

Классификация ПО по архитектуре:

Тип	Что значит	Примеры
Локальное (десктопное)	Установлено на один компьютер	MS Office, Photoshop, игры
Клиент-серверное	Разделено на серверную и клиентскую части	Почта, веб-приложения, 1С (сервер)
Веб-приложение	Работает через браузер	Google Docs, Gmail, Trello
Мобильное	Работает на смартфонах	Instagram, Uber, приложения банков
Облачное	Работает в облаке, данные на серверах	Google Drive, Dropbox, iCloud
Встраиваемое	Работает на устройствах (микроволновки, машины)	ПО микроволновки, ЭБУ автомобиля

Классификация ПО по лицензии (юридическая):

Тип лицензии	Что можно делать	Примеры
GPL (General Public License)	Можно использовать, изменять, распространять	Linux, Git, WordPress
MIT License	Очень свободная, почти без ограничений	React, Node.js, jQuery
Apache License	Похожа на MIT, но с патентными оговорками	Kubernetes, Android
Proprietary (коммерческая)	Только использование по лицензии	Windows, Office, Photoshop
Freeware	Бесплатное использование, но код закрыт	Skype, TeamViewer (бесплатная версия)

Классификация ПО по уровню доступа к исходному коду:

Тип	Исходный код виден?	Можно изменять?
Open Source	Да	Да (с соблюдением лицензии)
Closed Source (проприетарное)	Нет	Нет
Source Available	Да (можно смотреть)	Нельзя изменять

Вопрос 27.

Понятие технологии разработки программного обеспечения

Технология разработки ПО — это совокупность методов, инструментов и процессов, которые используются для создания программного продукта. Она включает в себя всё: от сбора требований до сопровождения. Технология отвечает на вопрос «как делать», в отличие от «что делать» (требования) и «чем делать» (инструменты).

Три составляющих технологии разработки ПО:

Составляющая	Что включает	Примеры
Методы	Как подходить к решению задач	Анализ требований, проектирование, тестирование
Инструменты	Чем пользоваться	IDE, Git, Jira, CI/CD
Процессы	В каком порядке что делать	Каскад, Agile, Scrum, Kanban

Классификация технологий разработки ПО:

Классификация	Виды	Примеры
По модели ЖЦ	Каскадная, итеративная, спиральная, Agile	Waterfall, Scrum, Kanban
По подходу к кодированию	Структурный, объектно-ориентированный, функциональный	OOP, FP, структурное программирование
По организации команды	Традиционная (иерархия), Agile (самоорганизация), DevOps	Scrum-команда, отдел разработки
По автоматизации	Ручная, автоматизированная, CI/CD	Jenkins, GitHub Actions

Сравнение классических и современных технологий:

Аспект	Классические технологии (1970-1990)	Современные технологии (2000+)
Модель ЖЦ	Каскадная (Waterfall)	Agile (Scrum, Kanban)
Документация	Огромная, обязательная	Минимальная, работающий код важнее
Общение с заказчиком	В начале и в конце проекта	Постоянно (каждый спринт)
Тестирование	Отдельный этап в конце	Параллельно с разработкой
Релизы	Раз в год	Несколько раз в день
Инструменты	Мало (компилятор + редактор)	Много (IDE, Git, CI/CD, Docker)

Основные современные технологии разработки (подходы):

Технология	Суть	Ключевая идея
Agile (Scrum, Kanban)	Гибкая разработка, короткие спринты	Адаптация к изменениям важнее следования плану
DevOps	Совместная работа разработки и эксплуатации	Автоматизация, CI/CD, мониторинг
TDD (Test-Driven Development)	Сначала пишутся тесты, потом код	Тесты как спецификация
BDD (Behavior-Driven Development)	Тесты на естественном языке	Сценарии поведения пользователя
DDD (Domain-Driven Design)	Фокус на бизнес-логику	Код отражает модель предметной области
Continuous Integration (CI)	Частое слияние кода в общую ветку	Интегрироваться каждый день
Continuous Delivery (CD)	Автоматическая выкладка в тестовую среду	Всегда готово к релизу
Microservices	Приложение как набор маленьких сервисов	Каждый сервис независим

Жизненный цикл технологии разработки (с точки зрения внедрения):

Этап	Что происходит	Пример для Agile
1. Появление	Новая технология предложена	Манифест Agile (2001)
2. Раннее внедрение	Энтузиасты пробуют	Появление Scrum
3. Зрелость	Стандарт индустрии	Scrum — доминирующая методология
4. Закат	Появляется что-то лучшее	Возможно, со временем

Как выбрать технологию для проекта (факторы выбора):

Фактор	Что учитывать	Какой выбор
Размер команды	1 человек или 100	Для маленькой — Agile, для огромной — каскад + Agile
Стабильность требований	Меняются или нет	Стабильные → каскад, нестабильные → Agile
Бюджет	Сколько денег	Мало → Agile (меньше документации), много → можно и каскад
Риски	Высокие или низкие	Высокие → спиральная модель
Критичность	Ошибка стоит жизни?	Да → каскад или спираль (нужна документация)

Вопрос 28.

Основные этапы разработки программного обеспечения

Этапы разработки ПО — это последовательность действий, которые нужно выполнить, чтобы создать программу от идеи до готового продукта. Количество и названия этапов могут различаться в зависимости от модели ЖЦ, но суть одна. Ниже приведены этапы в классическом понимании.

Шесть основных этапов разработки ПО (с результатами):

№	Этап	Что делаем	Результат
1	Анализ требований	Собираем и фиксируем, что должна делать программа	Техническое задание (ТЗ)
2	Проектирование	Продумываем архитектуру, модули, БД, интерфейс	Проектная документация, схемы
3	Реализация (кодирование)	Пишем код, тесты, интегрируем с БД	Исходный код
4	Тестирование	Проверяем, что работает правильно, ищем ошибки	Отчёт о тестировании, список багов
5	Внедрение	Устанавливаем у пользователя, обучаем	Программа в эксплуатации
6	Сопровождение	Исправляем баги, добавляем функции, адаптируем	Новые версии

Детальное описание каждого этапа (что входит):

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

Действие	Результат
Интервью с заказчиком	Список пожеланий
Анализ конкурентов	Отчёт об аналогах
Формулировка функциональных требований	Список функций
Формулировка нефункциональных требований	Требования к производительности, безопасности
Согласование ТЗ	Подписанный документ

2. Проектирование:

Действие	Результат
Архитектурное проектирование	Схема компонентов
Проектирование БД (ER-диаграмма)	Схема таблиц и связей
Проектирование интерфейса	Макеты экранов
Детальное проектирование (классы, модули)	Спецификации модулей
Выбор технологий	Список используемого ПО (языки, фреймворки)

3. Реализация (кодирование):

Действие	Результат
Написание кода	Исходные файлы
Написание модульных тестов	Файлы с тестами
Настройка системы сборки	Скрипты сборки
Интеграция с БД и внешними API	Подключения и настройки
Code review	Проверенный код

4. Тестирование:

Уровень	Что тестируем	Кто проводит
Модульное	Каждая функция	Разработчик
Интеграционное	Модули вместе	Разработчик или тестировщик
Системное	Вся программа целиком	Тестировщик
Приёмочное (UAT)	Соответствие бизнес-задачам	Заказчик

5. Внедрение:

Действие	Результат
Установка на серверы или компьютеры	Программа установлена
Перенос данных из старых систем	Данные перенесены
Обучение пользователей (вебинары, инструкции)	Пользователи обучены
Запуск в «боевую» эксплуатацию	Программа работает с реальными данными
Настройка мониторинга	Система отслеживания сбоев

6. Сопровождение:

Вид сопровождения	Что делаем
Корректирующее	Исправляем ошибки, найденные после релиза
Адаптивное	Адаптируем под новые ОС, версии БД
Совершенствующее	Добавляем новые функции
Профилактическое	Рефакторим, улучшаем архитектуру без изменения поведения

Как этапы распределены во времени (процент от проекта):

Этап	Классический водопад	Agile (в сумме по спринтам)
Анализ	15%	5% (в каждом спринте)
Проектирование	20%	10% (в каждом спринте)
Кодирование	40%	50% (в каждом спринте)
Тестирование	20%	30% (в каждом спринте)
Внедрение	5%	5% (в конце проекта)

Вопрос 28.

Основные этапы разработки программного обеспечения

Краткая теория: Этапы разработки ПО — это последовательность действий, которые нужно выполнить, чтобы создать программу от идеи до готового продукта. Количество и названия этапов могут различаться в зависимости от модели ЖЦ, но суть одна. Ниже приведены этапы в классическом понимании.

Шесть основных этапов разработки ПО (с результатами):

№	Этап	Что делаем	Результат
1	Анализ требований	Собираем и фиксируем, что должна делать программа	Техническое задание (ТЗ)
2	Проектирование	Продумываем архитектуру, модули, БД, интерфейс	Проектная документация, схемы
3	Реализация (кодирование)	Пишем код, тесты, интегрируем с БД	Исходный код
4	Тестирование	Проверяем, что работает правильно, ищем ошибки	Отчёт о тестировании, список багов
5	Внедрение	Устанавливаем у пользователя, обучаем	Программа в эксплуатации
6	Сопровождение	Исправляем баги, добавляем функции, адаптируем	Новые версии

Детальное описание каждого этапа (что входит):

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

Действие	Результат
Интервью с заказчиком	Список пожеланий
Анализ конкурентов	Отчёт об аналогах
Формулировка функциональных требований	Список функций
Формулировка нефункциональных требований	Требования к производительности, безопасности
Согласование ТЗ	Подписанный документ

2. Проектирование:

Действие	Результат
Архитектурное проектирование	Схема компонентов
Проектирование БД (ER-диаграмма)	Схема таблиц и связей
Проектирование интерфейса	Макеты экранов
Детальное проектирование (классы, модули)	Спецификации модулей
Выбор технологий	Список используемого ПО (языки, фреймворки)

3. Реализация (кодирование):

Действие	Результат
Написание кода	Исходные файлы
Написание модульных тестов	Файлы с тестами
Настройка системы сборки	Скрипты сборки
Интеграция с БД и внешними API	Подключения и настройки
Code review	Проверенный код

4. Тестирование:

Уровень	Что тестируем	Кто проводит
Модульное	Каждая функция	Разработчик
Интеграционное	Модули вместе	Разработчик или тестировщик
Системное	Вся программа целиком	Тестировщик
Приёмочное (UAT)	Соответствие бизнес-задачам	Заказчик

5. Внедрение:

Действие	Результат
Установка на серверы или компьютеры	Программа установлена
Перенос данных из старых систем	Данные перенесены
Обучение пользователей (вебинары, инструкции)	Пользователи обучены
Запуск в «боевую» эксплуатацию	Программа работает с реальными данными
Настройка мониторинга	Система отслеживания сбоев

6. Сопровождение:

Вид сопровождения	Что делаем
Корректирующее	Исправляем ошибки, найденные после релиза
Адаптивное	Адаптируем под новые ОС, версии БД
Совершенствующее	Добавляем новые функции
Профилактическое	Рефакторим, улучшаем архитектуру без изменения поведения

Как этапы распределены во времени (процент от проекта):

Этап	Классический водопад	Agile (в сумме по спринтам)
Анализ	15%	5% (в каждом спринте)
Проектирование	20%	10% (в каждом спринте)
Кодирование	40%	50% (в каждом спринте)
Тестирование	20%	30% (в каждом спринте)
Внедрение	5%	5% (в конце проекта)

Вопрос 29.

Жизненный цикл программного обеспечения Дубл.

Жизненный цикл ПО (ЖЦПО) — это период времени от момента возникновения идеи создать программу до момента, когда программа полностью прекращает своё использование. Вопрос 6 уже рассматривался, здесь — углубление: процессы ЖЦ по стандарту ISO 12207.

Процессы жизненного цикла ПО (по ISO/IEC 12207):

Стандарт ISO 12207 выделяет несколько групп процессов:

Группа процессов	Что включает	Примеры процессов
Основные процессы	Напрямую связаны с созданием и использованием ПО	Разработка, эксплуатация, сопровождение
Вспомогательные процессы	Обеспечивают качество и управление	Документирование, тестирование, верификация
Организационные процессы	Управление проектом и инфраструктурой	Управление проектом, управление конфигурацией

Основные процессы (детально):

Процесс	Что делает	Вход	Выход
Приобретение	Заказчик закупает или заказывает ПО	Потребности бизнеса	Контракт, ТЗ
Поставка	Исполнитель передаёт ПО заказчику	Готовое ПО	Акт приёмки
Разработка	Создание ПО	Требования	Продукт + документация
Эксплуатация	Использование ПО пользователями	Продукт	Решённые задачи
Сопровождение	Поддержка и модификация	Продукт + запросы	Новые версии

Вспомогательные процессы (детально):

Процесс	Что делает
Документирование	Запись всей информации о продукте и процессах
Верификация	Проверка, что продукт соответствует требованиям
Валидация	Проверка, что продукт решает задачи пользователя
Совместный анализ	Обсуждение результатов с заинтересованными лицами
Аудит	Проверка соответствия стандартам и планам
Управление проблемами	Обработка ошибок и запросов на изменения

Организационные процессы (детально):

Процесс	Что делает
Управление проектом	Планирование, контроль, управление рисками
Управление конфигурацией	Учёт версий компонентов (через Git)
Управление инфраструктурой	Обеспечение оборудованием и ПО для разработки
Улучшение процессов	Анализ и оптимизация процессов разработки
Обучение	Повышение квалификации сотрудников

Связь между стандартами ЖЦ:

Стандарт	Где применяется	Особенность
ISO/IEC 12207	Международный	Базовый стандарт для всех процессов
ГОСТ 34.601-90	Россия (информационные системы)	Для автоматизированных систем
ГОСТ 19.xxx	Россия (программная документация)	Устаревший, но используется в госзаказе
IEEE 1074	США, IT-индустрия	Адаптирован под реальную практику

Пример ЖЦ для разных типов ПО (повтор с углублением):

Тип ПО	Разработка	Активная эксплуатация	Затухание	Полный ЖЦ
Мобильная игра	6 месяцев	2 года	1 год	3.5 года
Корпоративная CRM	1.5 года	8 лет	2 года	11.5 лет
Операционная система	4 года	10 лет	3 года	17 лет
ПО для АЭС	7 лет	25 лет	5 лет	37 лет

Что происходит на каждой фазе ЖЦ (таблица расходов):

Фаза	% времени	% бюджета	Основные затраты
Анализ и проектирование	15%	10%	Аналитики, архитекторы
Разработка	25%	20%	Разработчики
Тестирование	20%	15%	Тестировщики
Внедрение	5%	5%	DevOps, обучение
Сопровождение	35%	50%	Поддержка, исправление багов

Вопрос 30.

Модели жизненного цикла программного обеспечения Дубл.

Модель ЖЦ — это схема, описывающая порядок выполнения этапов разработки. Основные модели уже были рассмотрены в вопросе 7. Здесь — углублённое сравнение и дополнительные модели.

Сравнение четырёх основных моделей (сводная таблица):

Характеристика	Каскадная	Итеративная	Спиральная	Agile
Размер проекта	Крупный	Крупный/средний	Очень крупный	Средний/малый
Стабильность требований	Абсолютно стабильны	Уточняемые	Нестабильные	Постоянно меняющиеся
Риски	Низкие	Средние	Высокие	Средние
Заказчик видит результат	В самом конце	После каждой итерации	После каждого витка	После каждого спринта
Объём документации	Огромный	Средний	Большой	Минимальный
Стоимость изменений	Очень высокая	Средняя	Высокая	Низкая
Типичная длительность	1–5 лет	6–24 месяца	2–10 лет	1–12 месяцев

Дополнительные модели (менее известные, но важные):

Модель	Суть	Когда применять
V-Model (V-образная)	Расширение каскада: на каждый этап разработки приходится этап тестирования	Там, где нужна строгая верификация (медицина, авиация)
RAD (Rapid Application Development)	Быстрая разработка через прототипы	Проекты с жёсткими сроками
Lean Development	Минимизация потерь, делать только нужное	Стартапы с ограниченным бюджетом
Extreme Programming (XP)	Экстремальное программирование (парное, TDD, постоянный рефакторинг)	Высокорисковые проекты с меняющимися требованиями
DevOps-модель	Разработка + эксплуатация как единый процесс	Облачные сервисы, непрерывный деплой

RAD-модель (схема текстом):

Фаза 1: Планирование требований (совместно с заказчиком)
Фаза 2: Пользовательское проектирование (прототипы, обратная связь)
Фаза 3: Быстрая разработка (итерациями по 2–4 недели)
Фаза 4: Переход (внедрение, обучение)

Extreme Programming (XP) — ключевые практики:

Практика	Что значит
Парное программирование	Два разработчика за одним компьютером
TDD (Test-Driven Development)	Сначала тест, потом код
Постоянная интеграция (CI)	Слияние несколько раз в день
Коллективное владение кодом	Любой может менять любой код
Рефакторинг	Постоянное улучшение кода
Заказчик всегда в команде	Онлайн или офлайн для вопросов
Короткие итерации	1-3 недели

Как выбрать модель (алгоритм для менеджера):

Вопрос	Если ДА	Если НЕТ
Требования стабильны и понятны?	Каскад или V-Model	Agile или спираль
Риски очень высоки (ошибка стоит жизни)?	Спиральная	Agile или каскад
Нужна быстрая реакция на рынок?	Agile (Scrum, XP)	Каскад
Команда маленькая (до 10 человек)?	Agile	Каскад или спираль
Проект крупный (более 100 человек)?	Каскад (с элементами Agile)	Чистый Agile
Нужна полная документация (госзаказ)?	Каскад или V-Model	Agile

Тренды в моделях ЖЦ (что популярно сейчас):

Период	Доминирующая модель	Почему
1970-1990	Каскадная	Компьютеры дорогие, ошибки исправлять долго
1990-2000	RAD, итеративная	Появление персональных компьютеров
2000-2010	Agile (Scrum)	Манифест Agile, потребность в гибкости
2010-2020	Scrum, Kanban, DevOps	Контейнеризация, облака, CI/CD
2020-н.в.	Agile + DevOps (DevSecOps)	Безопасность с самого начала

Вопрос 31.

Понятие требований к программному обеспечению

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

Что такое требование (определение):

Аспект	Что значит
Потребность	Пользователю нужно что-то
Условие	При определённых обстоятельствах
Возможность	Программа может что-то сделать
Свойство	Программа обладает характеристикой

Три уровня требований (по степени детализации):

Уровень	Название	Для кого	Пример
Высокоуровневые	Бизнес-требования	Топ-менеджмент	«Увеличить продажи через интернет-магазин»
Среднего уровня	Пользовательские требования	Пользователи	«Пользователь может добавить товар в корзину»
Низкоуровневые	Функциональные требования (детальные)	Разработчики	«При нажатии кнопки «Добавить» товар появляется в корзине, а кнопка меняет цвет на зелёный»

Отличие требований от технического задания:

Характеристика	Требования	Техническое задание (ТЗ)
Кто пишет	Аналитик (совместно с заказчиком)	Аналитик или разработчик
Для кого	Для согласования с заказчиком	Для разработчиков
Степень детализации	Достаточная для понимания заказчиком	Достаточная для реализации
Содержит ли технические детали	Нет (минимум)	Да (протоколы, форматы данных)

Основные свойства хороших требований (по стандарту IEEE 830):

Свойство	Что значит	Пример нарушения
Корректность	Требование истинно, не противоречит реальности	«Программа должна работать на калькуляторе» (на калькуляторе нет ОС)
Однозначность	Только одно толкование	«Быстрый поиск» (что значит «быстрый»?)
Полнота	Описаны все ситуации	Нет требования про восстановление пароля
Непротиворечивость	Требования не противоречат друг другу	«Кнопка должна быть красной и синей одновременно»
Атомарность	Одно требование — одна мысль	«Пользователь может войти и купить товар» (это два требования)
Проверяемость	Можно проверить, выполнено или нет	«Интерфейс должен быть красивым» (проверить нельзя)
Приоритетность	Задана важность	Все требования помечены как «обязательные» (без приоритетов)
Отслеживаемость	Можно связать с исходным источником	Непонятно, кто попросил эту функцию

Пример требования с нарушением и исправлением:

Плохое требование	Проблема	Хорошее требование
«Программа должна работать быстро»	Непроверяемо	«Время загрузки главной страницы должно быть не более 2 секунд при скорости интернета 10 Мбит/с»
«Система должна быть удобной»	Непроверяемо	«90% пользователей должны успешно оформить заказ с первой попытки без подсказок»
«Пользователь может войти»	Неатомарно	«Система должна предоставлять форму входа с полями «Логин» и «Пароль»» + «Система должна проверять логин и пароль на сервере»

Что бывает, когда требования плохие (риски):

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

Вопрос 32.

Виды требований к программному обеспечению

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

Схема классификации требований

Требования к ПО
1.Функциональные требования (что делает)
  -Пользовательские функции
  -Административные функции
  -Системные функции (автоматические)
2.Нефункциональные требования (как делает)
  -Производительность
  -Надёжность
  -Безопасность
  -Удобство использования (юзабилити)
  -Совместимость
  -Сопровождаемость
  -Переносимость
  -Ограничения

Функциональные требования (F — Function):

Категория	Что описывает	Пример
Пользовательские функции	Что может делать пользователь в системе	«Пользователь может зарегистрироваться, указав email и пароль»
Административные функции	Что может делать администратор	«Администратор может заблокировать пользователя»
Системные функции	Что система делает автоматически	«Система отправляет email после регистрации»
Внешние интерфейсы	Как система общается с другими	«Система импортирует товары из 1С каждую ночь»

Нефункциональные требования (NFR — Non-Functional Requirements):

Категория	Что описывает	Пример
Производительность	Скорость, пропускная способность	«Время ответа API — не более 200 мс»
Надёжность	Доступность, восстановление после сбоев	«Доступность 99.9% (не более 8 часов простоя в год)»
Безопасность	Защита данных, аутентификация	«Пароли хранятся в зашифрованном виде (bcrypt)»
Юзабилити	Удобство для пользователя	«Количество кликов для заказа — не более 5»
Совместимость	Работа с другими системами, браузерами	«Поддержка Chrome, Firefox, Safari последних 2 версий»
Сопровождаемость	Лёгкость изменений и добавления функций	«Код должен быть покрыт тестами не менее 70%»
Переносимость	Возможность работы на разных ОС	«Работает на Windows, Linux, macOS»
Масштабируемость	Способность выдерживать рост нагрузки	«Система должна поддерживать 1000 одновременных пользователей»
Локализация	Поддержка разных языков и культур	«Интерфейс на русском и английском»

Сравнение функциональных и нефункциональных требований:

Характеристика	Функциональные	Нефункциональные
Отвечают на вопрос	«Что делает?»	«Как делает?»
Можно ли проверить по TDD	Да (написать тест)	Сложнее (измерять производительность)
Есть ли в пользовательской документации	Да (инструкция)	Частично (системные требования)
Кто в основном задаёт	Пользователь, заказчик	Архитектор, технический специалист
Стоимость нарушения	Не работает функция	Работает, но плохо

Примеры требований для интернет-магазина:

Тип	Требование
Функциональное	Пользователь может добавить товар в корзину
Функциональное	Пользователь может удалить товар из корзины
Функциональное	Пользователь может оформить заказ с указанием адреса
Нефункциональное	Время добавления товара в корзину не более 0.5 секунды
Нефункциональное	Система должна обрабатывать 100 одновременных оформлений заказа
Нефункциональное	Данные о заказах хранятся не менее 3 лет
Нефункциональное	Кнопка «Купить» должна быть заметной (размер не менее 40×40 пикселей)

Как приоритизировать требования (методы):

Метод	Что значит	Пример
MoSCoW	Must have (обязательно), Should have (очень желательно), Could have (можно), Won’t have (не сейчас)	Обязательно: вход и регистрация; Очень желательно: восстановление пароля
Kano model	Базовые (ожидаемые), Производительность (чем больше, тем лучше), Восхищающие (неожиданные)	Базовые: товар можно добавить в корзину; Восхищающие: рекомендации товаров
Стоимость реализации	Сколько времени/денег стоит функция	Дешёвое и важное — делать в первую очередь
Зависимости	Какие функции нужны для других	Регистрация нужна для оформления заказа

Вопрос 33.

Функциональные требования к ПО

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

Что описывают функциональные требования (детализация):

Аспект	Что значит	Пример
Входные данные	Что получает программа	«Форма логина: email и пароль»
Выходные данные	Что выдает программа	«При успешном входе — перенаправление на главную страницу»
Действия	Какие операции выполняет	«Проверка пароля на сервере»
Правила бизнес-логики	Какие условия применяются	«Скидка 10% при сумме заказа более 1000 рублей»
Граничные случаи	Что при особых условиях	«При неверном пароле — сообщение об ошибке»

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

Тип системы	Типовые функциональные требования
Сайт / веб-приложение	Регистрация, вход, поиск, фильтрация, корзина, оплата, история заказов
Мобильное приложение	Пуш-уведомления, авторизация через соцсети, камера, геолокация
CRM-система	Управление контактами, сделки, задачи, отчёты, импорт/экспорт
ERP-система	Учёт товаров, склад, закупки, продажи, производство, кадры
Бухгалтерская система	Проводки, счета, отчётность, налоги, выгрузка в госорганы
Игра	Создание персонажа, уровни, сохранение, мультиплеер, внутриигровые покупки

Формат записи функциональных требований (шаблон use case):

Элемент use case	Что значит	Пример для «Вход в систему»
Название	Краткое описание	«Аутентификация пользователя»
Актор	Кто выполняет	Зарегистрированный пользователь
Предусловие	Что должно быть до начала	Пользователь не авторизован
Основной сценарий	Успешный путь	1. Пользователь вводит логин и пароль 2. Система проверяет 3. Система открывает главную страницу
Альтернативный сценарий	Что при ошибке	2а. Неверный пароль → сообщение об ошибке
Постусловие	Что после успеха	Пользователь авторизован

Пример функционального требования (полный):

Поле	Значение
ID	FR-012
Название	Добавление товара в корзину
Описание	Авторизованный пользователь может добавить товар в корзину со страницы товара
Входные данные	ID товара, количество (по умолчанию 1)
Выходные данные	Сообщение «Товар добавлен», обновлённая корзина
Предусловие	Пользователь авторизован, товар есть в наличии
Постусловие	В корзине появился товар с указанным количеством
Исключения	Если товара нет в наличии — сообщение «Товар временно отсутствует»
Приоритет	Must have (обязательно)

Граничные случаи, которые нужно описывать в функциональных требованиях:

Граничный случай	Пример
Пустые значения	Что при пустом поле «Имя»?
Максимальные значения	Что при количестве товара 999999?
Минимальные значения	Что при количестве товара 0?
Отрицательные значения	Что при цене -100?
Спецсимволы	Что при имени пользователя `<script>`?
Дублирование	Что при попытке добавить товар, который уже в корзине?
Одновременные действия	Что если два пользователя покупают последний товар?

Проверка функциональных требований (контрольные вопросы):

Вопрос	Назначение
Каждое требование начинается с глагола?	Требование описывает действие
Можно ли написать тест на это требование?	Проверяемость
Нет ли в одном требовании двух разных действий?	Атомарность
Описаны ли граничные случаи?	Полнота
Понятно ли пользователю (не техническому)?	Понятность

Вопрос 34.

Нефункциональные требования к ПО

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

Основные категории нефункциональных требований (детально):

Категория	Что описывает	Как измерить	Пример
Производительность	Скорость работы	Время отклика, запросов в секунду	Время загрузки страницы < 2 секунд
Надёжность	Стабильность, доступность	Процент времени работы, MTBF	Доступность 99.9%
Безопасность	Защита данных	Уровень шифрования, количество уязвимостей	Шифрование трафика TLS 1.3
Юзабилити	Удобство использования	Время выполнения задачи, ошибки пользователя	Оформление заказа за < 3 минут
Совместимость	Работа с другими системами	Список поддерживаемых ОС, браузеров	Работает на Windows 10/11, macOS 12+
Сопровождаемость	Лёгкость изменений	Время на добавление новой функции	Добавление поля в форму < 2 часов
Переносимость	Работа на разных платформах	Количество поддерживаемых платформ	Работает на Windows, Linux, macOS
Масштабируемость	Рост под нагрузкой	Количество пользователей, данных	Поддержка 10 000 одновременных пользователей
Эффективность	Использование ресурсов	Память, CPU, диск	Занимает не более 1 ГБ оперативной памяти
Локализация	Поддержка языков и культур	Количество языков, форматы дат	Поддержка русского, английского

Детализация требований к производительности:

Показатель	Что значит	Хорошее значение
Время отклика (response time)	Время от запроса до ответа	< 200 мс (для API)
Время загрузки страницы	Полная загрузка в браузере	< 2 секунд
Пропускная способность	Запросов в секунду	1000 RPS
TTFB (Time To First Byte)	Время до первого байта	< 100 мс
Время запуска приложения	От клика до готовности	< 5 секунд

Детализация требований к надёжности:

Показатель	Что значит	Формула/значение
Доступность (availability)	Процент времени, когда система работает	99.9% (3 девятки) → 8.76 часа простоя в год
MTBF (Mean Time Between Failures)	Среднее время между сбоями	> 1000 часов
MTTR (Mean Time To Recovery)	Среднее время восстановления после сбоя	< 30 минут
Вероятность отказа	Шанс, что система упадёт	< 0.001
RTO (Recovery Time Objective)	Целевое время восстановления	< 4 часов
RPO (Recovery Point Objective)	Максимальный возраст данных, которые можно потерять	< 15 минут

Детализация требований к безопасности:

Аспект	Что значит	Пример требования
Аутентификация	Проверка личности пользователя	Двухфакторная аутентификация для администраторов
Авторизация	Проверка прав доступа	Пользователь видит только свои заказы
Шифрование	Защита данных при передаче и хранении	Передача данных только по HTTPS
Хранение паролей	Пароли в базе данных	Хеширование с солью (bcrypt)
Защита от атак	Предотвращение взлома	Защита от SQL-инъекций, XSS
Аудит	Логирование действий	Все действия администратора логируются
Безопасность сети	Защита на уровне сети	Только белые IP-адреса для доступа к админке

Детализация требований к юзабилити (удобству):

Аспект	Что значит	Пример требования
Обучаемость	Как легко освоить новичку	80% пользователей выполняют задачу без подсказок
Эффективность	Как быстро выполняются задачи	Оформление заказа занимает не более 3 минут
Запоминаемость	Как легко вспомнить после перерыва	Пользователь помнит, где кнопка «Купить» через месяц
Ошибки	Как часто пользователь ошибается	Не более 5% ошибок при заполнении формы
Удовлетворённость	Нравится ли пользователям	Оценка не менее 8 из 10 в опросе

Пример полного нефункционального требования:

Поле	Значение
ID	NFR-023
Категория	Производительность
Название	Время поиска товаров
Описание	Поиск по каталогу из 100 000 товаров должен занимать не более 1 секунды
Условия измерения	Сервер: 4 ядра, 8 ГБ ОЗУ; БД: PostgreSQL с индексами
Метрика	Время от отправки запроса до получения результата
Приоритет	High

Измеримость нефункциональных требований (плохо vs хорошо):

Плохо (непроверяемо)	Хорошо (проверяемо)
«Система должна работать быстро»	«Время загрузки главной страницы < 2 секунд»
«Система должна быть надёжной»	«Доступность 99.9% (не более 8.8 часов простоя в год)»
«Система должна быть безопасной»	«Все пароли должны храниться в виде bcrypt-хешей»
«Программа должна быть удобной»	«90% пользователей оформляют заказ с первой попытки»

Вопрос 35.

Методы сбора требований к программному обеспечению

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

Основные методы сбора требований (сравнение):

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

Подробное описание каждого метода:

1. Интервью:

Аспект	Значение
Формат	Один на один (аналитик + заинтересованное лицо)
Длительность	30–60 минут
Вопросы	Открытые («Что вы делаете?», «Что было бы удобно?»), закрытые («Вам нужно восстановление пароля?»)
Результат	Расшифровка беседы, список требований
Типичный вопрос	«Расскажите, как вы сейчас решаете эту задачу? Что вам мешает?»

2. Анкетирование:

Аспект	Значение
Формат	Письменные вопросы (бумага, Google Forms, SurveyMonkey)
Аудитория	От 10 до 10 000 респондентов
Вопросы	Преимущественно закрытые (с вариантами ответов)
Результат	Статистика: сколько процентов хотят ту или иную функцию
Типичный вопрос	«Как часто вы используете функцию поиска? (Ежедневно / Раз в неделю / Никогда)»

3. Наблюдение:

Аспект	Значение
Формат	Аналитик наблюдает за работой пользователя (иногда с записью экрана)
Длительность	1–2 часа за пользователем
Что узнаём	Реальные рабочие процессы, неудобства, лайфхаки пользователей
Результат	Карта текущего процесса, список «болей»
Типичное наблюдение	«Пользователь копирует данные из Excel вручную, потому что нет функции импорта»

4. Мастерские требований (requirements workshop):

Аспект	Значение
Участники	Аналитик (фасилитатор), заказчик, пользователи, разработчик, тестировщик
Длительность	2–4 часа (или несколько дней)
Процесс	Групповая работа: мозговой штурм, голосование, приоритизация
Результат	Согласованный список требований за одну сессию
Когда нужен	Спорные требования, много стейкхолдеров

5. Прототипирование:

Аспект	Значение
Уровень прототипа	Низкая детализация (бумага, каркасы), средняя (Figma без логики), высокая (кликабельный макет)
Что даёт	Заказчик может «потрогать» интерфейс и сказать, что не так
Результат	Уточнённые требования, исправленные ошибки до разработки
Типичный кейс	«А, я думал, кнопка «Купить» будет здесь! А она в другом месте»

Сравнение методов по затратам и эффективности:

Метод	Затраты (время аналитика)	Эффективность	Лучше всего подходит для
Интервью	Высокие	Высокая	Глубокое понимание
Анкетирование	Низкие	Средняя	Массовый сбор мнений
Наблюдение	Очень высокие	Очень высокая	Выявление реальных проблем
Мастерские	Средние	Очень высокая	Быстрое согласование
Прототипы	Высокие	Высокая	Уточнение интерфейсов

Какой метод выбрать (рекомендации):

Ситуация	Рекомендуемые методы
Новый проект (нет аналогов)	Интервью + мастерские + прототипы
Улучшение существующей системы	Наблюдение + интервью + анализ документов
Много пользователей (тысячи)	Анкетирование + наблюдение (выборочно)
Очень сжатые сроки	Мастерские + прототипы (быстро)
Распределённая команда	Анкетирование + онлайн-интервью

Вопрос 36.

Анализ требований к программному обеспечению

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

Задачи анализа требований:

Задача	Что делаем	Результат
Выявление скрытых требований	Ищем то, о чём заказчик забыл сказать	Полный список
Разрешение конфликтов	Согласовываем противоречивые требования	Компромисс
Приоритизация	Распределяем по важности	Список с приоритетами
Оценка реализуемости	Проверяем, можно ли сделать	Оценка рисков
Моделирование	Создаём диаграммы, use cases	Визуальное представление
Валидация	Подтверждаем с заказчиком	Подписанные требования

Модели, используемые при анализе требований:

Тип модели	Что показывает	Инструменты	Пример
Use case diagram	Кто (акторы) и что (use cases) делает	UML	Пользователь, Админ, «Войти», «Купить»
Activity diagram	Последовательность действий	UML	Блок-схема процесса заказа
State diagram	Состояния объекта	UML	Заказ: Новый → Оплачен → Отправлен → Доставлен
Sequence diagram	Взаимодействие объектов во времени	UML	Как пользователь, сервер и БД обмениваются сообщениями
Domain model	Сущности и их связи	UML, ER-диаграммы	Товар – Склад – Заказ – Пользователь

Этапы анализа требований (процесс):

Этап	Что делаем	Вопросы
1. Классификация	Разделяем на функциональные и нефункциональные	Это что или как?
2. Проверка свойств	Проверяем каждое требование на корректность, однозначность, проверяемость	Можно ли это проверить?
3. Обнаружение конфликтов	Ищем противоречия	«Красная кнопка» и «Синяя кнопка» — конфликт
4. Оценка реализуемости	Можно ли сделать за бюджет и сроки	Слишком дорого → ищем альтернативу
5. Приоритизация	Must have / Should have / Could have / Won’t have	Что делаем в первую очередь?
6. Валидация	Показываем заказчику, получаем подпись	Вы это имели в виду?

Типичные проблемы при анализе требований и их решения:

Проблема	Причина	Решение
Заказчик говорит «сделайте удобно»	Не может сформулировать	Прототип, примеры
Заказчик добавляет требования в процессе	Не знал, чего хочет	Заморозить требования после согласования
Требования противоречат друг другу	Разные заказчики	Мастерская, голосование
Требования слишком общие	Не детализировали	Задать уточняющие вопросы
Требования технически нереализуемы	Заказчик не технический	Объяснить ограничения, предложить альтернативу

Пример анализа конфликтующих требований:

Конфликт	Анализ	Решение
Требование A: Кнопка должна быть красной	Требование B: Кнопка должна быть синей	Красная кнопка — стандарт для опасных действий, синяя — для обычных. Уточнить, что делает кнопка
Требование A: Программа должна работать на Windows 7	Требование B: Программа должна использовать технологии, не совместимые с Windows 7	Оценить долю пользователей на Windows 7. Если <5% — отказаться от поддержки

Что такое «скрытые требования» (примеры):

Скрытое требование	Как выявить
Пользователь хочет не просто вход, а чтобы пароль не надо было вводить каждый день	Спросить: «Как часто вы входите в систему? Раздражает ли вас это?»
Пользователь хочет не просто поиск, а умный поиск с подсказками	Посмотреть, как пользователь сейчас ищет (вбивает много слов, исправляет ошибки)
Заказчик хочет не просто отчёт, а отчёт в Excel, как он привык	Спросить: «В каком формате вы работаете с отчётами?»

Вопрос 37.

Документирование требований

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

Основные документы для требований (сравнение):

Документ	Содержание	Кто пишет	Для кого	Объём
ТЗ (Техническое задание)	Требования + условия выполнения + сроки	Аналитик / менеджер	Заказчик, разработчики	20–100 страниц
SRS (Software Requirements Specification)	Детальные функциональные и нефункциональные требования	Аналитик	Разработчики, тестировщики	50–300 страниц
Пользовательские сценарии (User Stories)	Короткие описания функций с точки зрения пользователя	Аналитик / владелец продукта	Команда разработки	1–3 предложения

Вопрос 38.

Техническое задание на разработку программного продукта

Техническое задание (ТЗ) — это основной документ, который определяет, что именно нужно разработать. Он имеет юридическую силу: если программа не соответствует ТЗ, заказчик может не принять работу. ТЗ пишется на этапе анализа требований и утверждается обеими сторонами. Без ТЗ разработка превращается в «кота в мешке» — непонятно, что должно получиться в итоге.

Почему ТЗ так важен (три главные причины):

Причина	Объяснение
Единое понимание	Заказчик и разработчик одинаково представляют результат
Юридическая защита	Если заказчик просит то, чего нет в ТЗ — это отдельная работа за доплату
Основа для приёмки	Программа принята, если соответствует ТЗ

Типичные ошибки при составлении ТЗ:

Ошибка	Последствие
ТЗ слишком общее («удобный интерфейс»)	Непонятно, когда считать работу выполненной
В ТЗ нет приоритетов	Разработчик делает всё, а заказчик говорит «это было неважно»
ТЗ пишут после начала разработки	Уже написанный код могут не принять
ТЗ не подписали	При споре не на что ссылаться

Что должно быть в ТЗ (основные разделы с пояснениями):

Раздел	Что содержит	Пример
Цель разработки	Зачем нужна программа, какие бизнес-проблемы решает	«Автоматизация учёта товаров, сокращение ручного труда на 50%»
Функциональные требования	Что программа должна делать (список функций с деталями)	«Пользователь может добавить товар в корзину, указав количество»
Нефункциональные требования	Производительность, безопасность, надёжность	«Время ответа не более 2 секунд, доступность 99.9%»
Требования к составу документации	Какие документы нужно передать заказчику	«Руководство пользователя, руководство администратора»
Условия эксплуатации	Какое оборудование, ОС, сетевое окружение	«Windows 10/11, сервер Linux Ubuntu 22.04»
Порядок контроля и приёмки	Как проверяют, кто подписывает, какие тесты проводят	«Приёмочное тестирование заказчиком в течение 10 рабочих дней»
Сроки и этапы	Дорожная карта: когда что должно быть готово	«Этап 1 (15.02.2025) — прототип, Этап 2 (15.04.2025) — релиз»
Порядок изменений ТЗ	Как вносить изменения после подписания	«Изменения оформляются дополнительным соглашением»

Пример хорошей формулировки функции в ТЗ:

«Программа должна предоставлять форму авторизации с полями «Логин» (текст, 3–50 символов) и «Пароль» (текст, скрытый ввод, 6–100 символов). При успешном вводе пользователь перенаправляется на главную страницу. При трёх последовательных неудачных попытках учётная запись блокируется на 15 минут с выводом сообщения «Слишком много попыток, попробуйте через 15 минут». Пароль должен передаваться по протоколу HTTPS и храниться в базе данных в зашифрованном виде с использованием bcrypt.»

Почему ТЗ не может быть идеальным (причины):

Причина	Что с этим делать
Заказчик не знает, чего хочет, пока не увидит результат	Использовать гибкие методологии (Agile)
Требования меняются в процессе разработки	Фиксировать изменения документально
Полное ТЗ занимает слишком много времени	Делать ТЗ на первую версию (MVP), потом уточнять

в зашифрованном виде (bcrypt).»

Вопрос 39.

Структура технического задания

Структура ТЗ описана в ГОСТ 19.201-78, но на практике её адаптируют под конкретный проект. Важно не слепое следование стандарту, а полнота и понятность документа. Ниже — типичная структура, которая встречается в большинстве коммерческих ТЗ и проверена практикой.

Стандартная структура ТЗ (8 разделов):

Раздел	Что входит	Зачем нужен
1. Введение	Название программы, назначение, область применения	Чтобы все понимали, о чём речь
2. Требования к функциональности	Список функций по модулям (что должно быть реализовано)	Основа для разработки и тестирования
3. Требования к надёжности	Доступность, восстановление после сбоев	Чтобы программа не падала
4. Требования к производительности	Скорость работы, нагрузка	Чтобы программа работала быстро
5. Требования к безопасности	Шифрование, защита данных, аутентификация	Чтобы данные не украли
6. Требования к документации	Какие документы нужно предоставить	Чтобы было чему обучать пользователей
7. Сроки и этапы	Дорожная карта с датами	Чтобы контролировать выполнение
8. Порядок приёмки	Как проверяют, кто подписывает	Чтобы избежать споров при сдаче

Пример раздела «Функциональные требования» (фрагмент):

ID	Функция	Приоритет	Описание
FR-01	Регистрация	Must	Пользователь может создать аккаунт по email
FR-02	Вход в систему	Must	Вход по email и паролю
FR-03	Восстановление пароля	Should	Сброс пароля через email
FR-04	Просмотр товаров	Must	Каталог с поиском и фильтрацией
FR-05	Добавление в корзину	Must	Из каталога со страницы товара
FR-06	Оформление заказа	Must	Адрес, способ оплаты, подтверждение
FR-07	История заказов	Could	Просмотр предыдущих заказов

Что означает приоритет (обозначения):

Обозначение	Что значит	Пример
Must have	Без этого система не имеет смысла	Авторизация, добавление товара в корзину
Should have	Очень важно, но можно отложить	Восстановление пароля
Could have	Приятно, но не критично	Рекомендации товаров
Won’t have	Не делаем в этой версии (в следующей)	Интеграция с 1С

Пример раздела «Нефункциональные требования» (фрагмент):

ID	Категория	Требование
NFR-01	Производительность	Время загрузки главной страницы не более 2 секунд
NFR-02	Производительность	Поиск по каталогу из 100 000 товаров не более 1 секунды
NFR-03	Надёжность	Доступность 99.9% (не более 8.8 часов простоя в год)
NFR-04	Безопасность	Пароли хранить в зашифрованном виде (bcrypt)
NFR-05	Совместимость	Поддержка Chrome, Firefox, Safari последних 2 версий

Кто подписывает ТЗ и зачем:

Подпись	Кто	Что подтверждает
От заказчика	Руководитель проекта или директор	Согласен с требованиями
От исполнителя	Руководитель разработки	Берется выполнить за указанные сроки и бюджет
Согласующие	Юрист, главный инженер (в крупных проектах)	Документ не противоречит законам и нормативам

Вопрос 40.

Назначение спецификации требований

Спецификация требований (SRS — Software Requirements Specification) — это детальный технический документ, который описывает все требования к ПО на уровне, достаточном для разработки и тестирования. В отличие от ТЗ, SRS более техническая и содержит меньше коммерческих условий (сроки, бюджет). SRS — это «инструкция для разработчиков».

Основное отличие SRS от ТЗ:

Характеристика	Техническое задание (ТЗ)	Спецификация требований (SRS)
Основное назначение	Юридическая основа контракта	Техническая основа для разработки
Содержит сроки и бюджет	Да	Нет
Содержит детальные use cases	Не всегда	Да, обязательно
Содержит модели (диаграммы)	Редко	Да, часто
Для кого пишут	Заказчик, менеджер, разработчики	Разработчики, тестировщики
Длина	10–50 страниц	50–300 страниц

Что входит в SRS (по стандарту IEEE 830):

Раздел	Содержание	Пример
Введение	Цель документа, область действия, термины, ссылки	«Документ описывает требования к системе учёта товаров»
Общее описание	Контекст системы, пользовательские характеристики, ограничения, допущения	«Предполагается, что пользователи имеют базовые навыки работы с ПК»
Функциональные требования	Детальное описание каждой функции: входные данные, выходные, исключения, предусловия, постусловия	Таблица с FR-01, FR-02…
Нефункциональные требования	Производительность, безопасность, надёжность, юзабилити, совместимость	Таблица с NFR-01, NFR-02…
Внешние интерфейсы	Пользовательский интерфейс, API, аппаратные интерфейсы	«API соответствует OpenAPI 3.0»
Модели и диаграммы	Use case diagram, ER-диаграммы, диаграммы состояний, диаграммы последовательности	(вставка рисунка)
Приложения	Глоссарий, справочные материалы, примеры	«Глоссарий из 30 терминов»

Пример фрагмента SRS для функции «Вход» (детализация):

Поле	Значение
ID	FR-001
Название	Аутентификация пользователя
Описание	Пользователь может войти в систему, указав логин и пароль
Входные данные	Логин: строка, 3–50 символов, допустимые символы: латиница, цифры, @, ., -, _ . Пароль: строка, 6–100 символов, любые символы
Выходные данные	При успехе: сессионный токен (UUID), перенаправление на /dashboard. При ошибке: сообщение «Неверный логин или пароль»
Предусловие	Пользователь не авторизован, учётная запись существует и не заблокирована
Постусловие	Пользователь авторизован, сессия создана
Исключения	1) Неверный логин → ошибка. 2) Неверный пароль → ошибка. 3) 3 неудачных попытки → блокировка на 15 минут. 4) Блокированная учётная запись → ошибка «Аккаунт заблокирован»
Приоритет	Must have

Почему SRS важна для разработки:

Причина	Объяснение
Разработчики знают, что делать	Нет двусмысленностей
Тестировщики знают, что проверять	Каждое требование можно превратить в тест
Оценка сроков становится точнее	По детальным требованиям проще оценить трудоёмкость
Меньше споров при приёмке	Всё чётко описано

Вопрос 41.

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

Проектирование — это этап разработки, на котором определяют архитектуру программы, модули, базы данных и интерфейсы. Проектирование отвечает на вопрос «как делать?» после того, как собран ответ «что делать?» (требования). Это мост между требованиями и кодом.

Два уровня проектирования (детализация):

Уровень	Что делаем	Результат	Кто делает	Зачем
Высокоуровневое (архитектурное)	Выбираем общую структуру: клиент-сервер, микросервисы, слои. Определяем компоненты и их связи	Архитектурная схема, выбор технологического стека	Архитектор	Чтобы не переделывать всё потом
Низкоуровневое (детальное)	Проектируем классы, функции, схемы БД, конкретные алгоритмы, протоколы взаимодействия	Детальные спецификации, UML-диаграммы классов, ER-диаграммы	Ведущий разработчик	Чтобы программисты писали одинаково

Что даёт проектирование (преимущества):

Преимущество	Объяснение	Без проектирования
Понятная структура	Все модули чётко определены	Хаотичный код, где всё связано со всем
Распараллеливание работы	Разные модули делают разные люди	Ждут друг друга
Лёгкое тестирование	Каждый модуль тестируется отдельно	Тестировать можно только всю программу целиком
Возможность замены	Можно заменить один модуль на другой	Любое изменение ломает всё
Документация для новичков	Схемы помогают понять систему	Новичок читает код месяцами

Основные артефакты проектирования (что должно получиться):

Артефакт	Что показывает	Пример
Архитектурная схема	Крупные блоки и их связи (прямоугольники и стрелки)	Фронтенд ↔ Бэкенд ↔ БД
UML-диаграмма классов	Классы, их поля, методы и связи между ними	Класс User: поля name, email; методы register(), login()
UML-диаграмма последовательности	Порядок взаимодействия объектов во времени (кто кому что посылает)	Пользователь → Контроллер → Сервис → БД
Диаграмма состояний	Состояния одного объекта и переходы между ними	Заказ: Новый → Оплачен → Отправлен → Доставлен
ER-диаграмма БД	Таблицы, поля (атрибуты), первичные и внешние ключи, связи	Таблица Users связана с Orders по user_id
Макет интерфейса	Как выглядит экран, где расположены кнопки, поля, меню	Figma с прототипом экрана входа
Спецификация API	Какие эндпоинты, какие параметры, какие ответы, коды ошибок	POST /login принимает {email, password}, возвращает {token}

Когда проектирование особенно важно (а когда можно пропустить):

Ситуация	Нужно ли проектирование	Почему
Проект на 1000 строк кода (один разработчик)	Минимальное (набросок на салфетке)	Проще написать и переделать
Проект на 100 000 строк (команда 10 человек)	Обязательно детальное	Без схем люди запутаются
Проект на 1 млн строк (команда 100 человек)	Очень детальное, с документацией	Иначе хаос
Прототип для проверки идеи (MVP)	Минимальное	Всё равно переделают
Критичная система (банк, медицина)	Обязательно, с верификацией	Ошибки дорого стоят

Вопрос 42.

Основные принципы проектирования ПО

Принципы проектирования — это проверенные практикой правила, которые помогают создавать код, который легко читать, изменять и тестировать. Самые известные принципы — SOLID (для объектно-ориентированного проектирования) и несколько общих (DRY, KISS, YAGNI).

Принципы SOLID (пять принципов для ООП):

Принцип	Название	Смысл простыми словами	Пример нарушения
S	Single Responsibility	У класса должна быть одна причина для изменения (одна обязанность)	Класс «Отчёт» и считает данные, и рисует графики, и отправляет email
O	Open-Closed	Класс открыт для расширения, но закрыт для изменения	Чтобы добавить новый тип отчёта, приходится менять код существующего
L	Liskov Substitution	Дочерний класс должен заменять родительский без сбоев	Подкласс «Квадрат» от «Прямоугольник» ломает логику (несоразмерное изменение)
I	Interface Segregation	Не заставляй класс реализовывать то, что ему не нужно	Интерфейс «Работник» заставляет повара уметь программировать
D	Dependency Inversion	Зависеть от абстракций (интерфейсов), а не от конкретных классов	Класс «Уведомление» привязан напрямую к классу «Email», а не к интерфейсу «Отправитель»

Пример нарушения Single Responsibility (было и стало):

Было (плохо)	Стало (хорошо)
Один класс отвечает и за расчёт цены, и за сохранение в БД, и за отправку email	Отдельный класс для расчёта цены, отдельный — для работы с БД, отдельный — для email
При изменении email надо править класс с расчётом цены	Каждый класс меняется только по своей причине

Другие важные принципы проектирования (не из SOLID):

Принцип	Название	Смысл	Пример нарушения
DRY	Don’t Repeat Yourself	Не повторяй один и тот же код в двух местах	Один и тот же алгоритм расчёта скидки написан в трёх разных местах
KISS	Keep It Simple, Stupid	Простое решение лучше сложного	Вместо сложной архитектуры с десятью классами достаточно одной функции
YAGNI	You Aren’t Gonna Need It	Не делай того, что может не понадобиться	Сделали систему кэширования, а она никогда не использовалась
Least Astonishment	Принцип наименьшего удивления	Пользователь (или программист) не должен удивляться поведению	Функция `add_to_cart` не добавляет товар в корзину, а удаляет — это неожиданно

Что даёт соблюдение принципов проектирования:

Характеристика	Что значит	Почему хорошо
Низкое сцепление (loose coupling)	Модули мало зависят друг от друга	Модуль можно изменить, не ломая другие
Высокая связность (high cohesion)	Внутри модуля всё связано по смыслу	Модуль легко понять и тестировать
Лёгкая тестируемость	Каждый класс можно проверить отдельно	Легче находить ошибки
Лёгкая сопровождаемость	Новый разработчик быстро понимает код	Меньше времени на доработки

Антипаттерны (чего делать не надо):

Антипаттерн	Что это	Пример
Божественный объект	Один класс знает и делает всё	Класс «Application» на 10 000 строк
Спагетти-код	Код, в котором всё связано со всем	Одна функция вызывает другую, та — третью, и так по кругу
Золотой молоток	Одно и то же решение для всех задач	Везде использовать микросервисы, даже для калькулятора

Вопрос 43.

Архитектура программного обеспечения

Архитектура ПО — это крупная структура программы: из каких больших частей (компонентов, модулей, сервисов) она состоит и как эти части взаимодействуют. Архитектура — это «чертёж здания» до того, как начали строить. Правильная архитектура позволяет программе расти, не разрушаясь.

Что определяет архитектура (четыре ключевых аспекта):

Аспект	Что решает	Пример
Разделение на компоненты	Из каких крупных частей состоит система	Фронтенд (интерфейс), бэкенд (логика), база данных (хранение)
Связи между компонентами	Как компоненты общаются друг с другом	По HTTP API, через очереди сообщений, через общую базу данных
Место размещения	Где работает каждый компонент	В браузере пользователя, на сервере в облаке, на сервере БД
Технологический стек	Какие технологии использовать для каждого компонента	React + Python + PostgreSQL

Зачем нужна архитектура (пять главных причин):

Причина	Объяснение	Без архитектуры
Управление сложностью	Разбиваем большую систему на понятные части	Огромный непонятный монолит
Масштабирование	Знаем, что нужно увеличивать при росте нагрузки	Добавили серверов — не помогло
Переиспользование	Компоненты можно использовать в других проектах	Каждый раз пишем заново
Распределение работы	Разные команды делают разные компоненты	Все ждут один компонент
Устойчивость к изменениям	Изменение в одном компоненте не ломает другие	Починил одно — сломал другое

Ключевые понятия в архитектуре (обязательные к пониманию):

Понятие	Что значит	Пример
Компонент	Крупная часть системы, имеющая своё назначение	Модуль авторизации, модуль оплаты
Интерфейс	Способ взаимодействия компонентов (контракт)	REST API, очередь сообщений
Зависимость	Если компонент А не может работать без компонента Б	Фронтенд без бэкенда не работает
Абстракция	Скрытие сложности за простым интерфейсом	Пользователь не знает, как работает база данных
Архитектурное решение	Выбор, который трудно изменить потом	Выбрали базу данных PostgreSQL — менять сложно

Кто отвечает за архитектуру в проекте:

Роль	Что делает	Когда нужна
Архитектор	Принимает ключевые архитектурные решения, выбирает стиль и технологии	В крупных проектах (10+ разработчиков)
Ведущий разработчик (Team Lead)	Детализирует архитектуру до уровня модулей	В средних проектах (3–10 разработчиков)
Вся команда	Обсуждает и согласовывает архитектуру (архитектурный комитет)	В больших проектах (50+ разработчиков)

Вопрос 44.

Виды архитектуры программного обеспечения

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

Основные архитектурные стили (подробное сравнение):

Архитектура	Суть	Плюсы	Минусы	Когда применять
Монолитная	Вся программа в одном развёртываемом файле (одно приложение)	Простота разработки, один язык, легко тестировать	Трудно масштабировать, одно обновление — перезапуск всего	Маленькие проекты, стартапы, прототипы
Клиент-серверная	Клиент (интерфейс) и сервер (данные и логика) разделены по сети	Разделение ответственности, централизованные данные	Сеть как узкое место, сложность отладки	Веб-приложения, почтовые системы
Многоуровневая (n-tier)	Несколько слоёв (презентация, бизнес-логика, данные, интеграция)	Чёткое разделение, можно заменять слои	Каждый запрос проходит через все слои — медленнее	Корпоративные системы (CRM, ERP)
Микросервисная	Десятки маленьких независимых сервисов, каждый со своей БД	Масштабируемость, независимые релизы, разные технологии	Сложность управления, распределённые транзакции	Крупные проекты (Netflix, Amazon, Uber)
Событийно-ориентированная	Компоненты реагируют на события (слабая связанность)	Легко добавлять новые обработчики, хороша для асинхронных систем	Трудно отлаживать, сложно гарантировать порядок	Системы реального времени, IoT
Шина данных	Все модули общаются через центральную шину (промежуточное ПО)	Простое добавление новых модулей	Единая точка отказа (сама шина)	Интеграция разных систем, корпоративные сервисные шины

Простое объяснение каждого стиля (для новичков):

Стиль	Объяснение простыми словами
Монолит	Одна большая программа, всё внутри. Как швейцарский нож — много функций в одном корпусе
Клиент-сервер	Программа на телефоне (клиент) разговаривает с программой на сервере. Как ресторан: официант (клиент) и кухня (сервер)
Многоуровневый	Слои: показывать → считать → хранить. Как завод: цех сборки (показ), цех расчётов (логика), склад (данные)
Микросервисы	Десятки маленьких программ, каждая занимается своим. Как рынок: отдел мяса, отдел молока, касса
Событийный	Сервисы не вызывают друг друга, а кидают сообщения «кто-нибудь, обработай это». Как выкрикивают заказ в ресторане

Дополнительные архитектурные стили (менее распространённые, но важные):

Стиль	Суть	Когда использовать
Плагинная (микроядро)	Ядро системы минимально, все функции — подключаемые модули	IDE (VS Code), браузеры (расширения)
Потоковая (pipe-and-filter)	Данные проходят через цепочку обработчиков (фильтров)	Компиляторы, ETL-процессы
P2P (Peer-to-Peer)	Нет выделенного сервера, все узлы равны	Торренты, блокчейн
Бессерверная (Serverless)	Код выполняется на облачных функциях без управления серверами	Lambda-функции AWS, событийно-ориентированные приложения

Как выбрать архитектуру (алгоритм для принятия решения):

Вопрос	Ответ	Рекомендованная архитектура
Проект маленький (до 10 000 строк кода)?	Да	Монолит
Проект будет расти и меняться 2+ года?	Да	Не монолит
Команда большая (50+ человек)?	Да	Микросервисы
Нужна реакция на события в реальном времени (интерактив)?	Да	Событийно-ориентированная
Система должна работать без остановки (24/7)?	Да	Микросервисы (обновление частями)
Есть жёсткие требования к консистентности данных (банк)?	Да	Монолит или многоуровневая

Вопрос 45.

Модульная архитектура программного обеспечения

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

Что такое модуль (четыре ключевых свойства):

Свойство	Что значит	Пример
Функциональная законченность	Модуль делает что-то одно, законченное	Модуль «Авторизация» только отвечает за вход и регистрацию
Скрытие внутренностей (инкапсуляция)	Другие модули не знают, как он работает внутри	Модуль «Платежи» скрывает внутреннюю логику расчётов
Чёткий интерфейс	Есть понятный способ взаимодействия (входы и выходы)	Модуль имеет функцию `pay(amount)` и не имеет других точек входа
Независимость	Модуль можно разрабатывать и тестировать отдельно	Модуль «Отчёты» не зависит от модуля «Авторизация»

Пример разбиения интернет-магазина на модули:

Модуль	За что отвечает	Интерфейс (как с ним работать)
Модуль авторизации	Вход, регистрация, восстановление пароля	`login()`, `register()`, `resetPassword()`
Модуль каталога	Отображение товаров, поиск, фильтрация	`getProducts()`, `search()`, `filter()`
Модуль корзины	Добавление, удаление, изменение количества	`add()`, `remove()`, `updateQuantity()`
Модуль заказов	Оформление, история, статусы	`checkout()`, `getHistory()`, `getStatus()`
Модуль оплаты	Интеграция с платёжными системами	`pay()`, `refund()`
Модуль уведомлений	Email, push, SMS-уведомления	`sendEmail()`, `sendPush()`

Преимущества модульной архитектуры (почему это хорошо):

Преимущество	Объяснение	Пример из жизни
Параллельная разработка	Разные модули могут делать разные люди одновременно	Одна команда делает корзину, другая — оплату
Тестирование по отдельности	Можно протестировать модуль без всей системы	Тестируем модуль оплаты, не трогая каталог
Переиспользование	Модуль авторизации можно взять в другой проект	Тот же модуль входа для магазина и форума
Замена	Можно заменить модуль оплаты на другой (сменили провайдера)	Была оплата через Qiwi, стала через ЮKassa
Изоляция ошибок	Ошибка в одном модуле не ломает всю систему	Упал модуль «Рекомендации», но покупки работают
Понятность	Новый разработчик изучает один модуль, не всю систему	Новичок сразу берёт модуль «Каталог»

Два важных понятия: связность (cohesion) и сцепление (coupling):

Понятие	Что значит	Хорошо	Плохо
Связность (внутри модуля)	Как тесно связаны элементы внутри одного модуля	Высокая связность

Вопрос 46.

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

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

Связность (Cohesion) — что внутри модуля

Связность показывает, насколько сильно элементы внутри одного модуля связаны друг с другом по смыслу. Чем выше связность, тем лучше. Идеальный модуль делает одну вещь и делает её хорошо.

Шкала связности (от плохой к хорошей):

Уровень	Название	Что значит	Пример
1 (худший)	Случайная связность	В модуле собраны совершенно не связанные вещи	Модуль «Утилиты» содержит и вычисление налогов, и форматирование дат, и отправку email
2	Логическая связность	Элементы связаны логически (все операции ввода/вывода), но внутри разные	Модуль «Ввод-вывод» содержит и чтение файлов, и запись в БД, и печать на принтер
3	Временная связность	Элементы выполняются в одно время (инициализация)	Модуль «Загрузка системы» открывает соединения с БД, загружает конфиги, инициализирует кэш
4	Процедурная связность	Элементы связаны порядком выполнения (сначала А, потом Б, потом В)	Модуль «Обработка заказа»: проверить товар → зарезервировать → списать деньги
5	Коммуникационная связность	Элементы работают с одними и теми же данными	Модуль «Работа с клиентом»: добавить клиента, удалить клиента, найти клиента
6	Последовательная связность	Выход одного элемента — вход для другого	Модуль «Компилятор»: лексический анализ → синтаксический анализ → генерация кода
7 (лучший)	Функциональная связность	Модуль делает ровно одну законченную функцию	Модуль «Расчёт НДС»: принимает сумму, возвращает сумму с НДС

Пример хорошей и плохой связности:

Плохо (низкая связность)	Хорошо (высокая связность)
Модуль «Магазин»: и авторизация, и каталог, и корзина, и оплата, и отчёты, и логи	Модуль «Авторизация» — только авторизация
Изменение в одном месте ломает всё	Модуль «Каталог» — только каталог
5000 строк кода в одном файле	Модуль «Корзина» — только корзина

Сцепление (Coupling) — между модулями

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

Шкала сцепления (от хорошего к плохому):

Уровень	Название	Что значит	Пример
1 (лучший)	Сцепление по данным	Модули обмениваются только простыми данными (числа, строки) через параметры	Модуль «Расчёт цены» получает `price` и `quantity`, возвращает `total`
2	Сцепление по образцам	Модули обмениваются структурами данных (объектами), но не их внутренним устройством	Передаём объект «Заказ» целиком, но не лезем внутрь
3	Сцепление по управлению	Модуль передаёт другому флаг, который меняет его поведение	`process(order, is_express=true)` — флаг управляет логикой
4	Сцепление по внешним ссылкам	Модули используют одни и те же глобальные переменные	Оба модуля читают и пишут `global_config`
5	Сцепление по общей информации	Модули работают с одной и той же областью памяти или файлом	Оба модуля пишут в один и тот же лог-файл
6	Сцепление по управляющим структурам	Один модуль передаёт другому управление (goto, longjmp)	Модуль А прыгает внутрь модуля Б
7 (худший)	Сцепление по содержимому	Модуль напрямую обращается к внутренностям другого модуля	Модуль А меняет private-переменную модуля Б

Как связаны связность и сцепление

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

Пример для понимания (калькулятор):

Модуль	Как сделано	Связность	Сцепление
Хорошо	Модуль «Сложение»: только складывает два числа	Функциональная (отлично)	По данным (принимает два числа, возвращает сумму)
Плохо	Модуль «Вычисления»: и сложение, и вычитание, и умножение, и логирование	Логическая (плохо)	По общей информации (пишут в один лог-файл)

Вопрос 47.

Декомпозиция программной системы

Декомпозиция — это процесс разбиения сложной системы на более простые и понятные части (модули, компоненты, подсистемы). Это один из главных инструментов управления сложностью в разработке ПО. Декомпозиция позволяет решать задачу «разделяй и властвуй»: большую проблему разбить на маленькие, каждую решить отдельно.

Зачем нужна декомпозиция

Причина	Объяснение
Упрощение понимания	Маленький модуль понять легче, чем огромную систему
Разделение работы	Разные люди могут делать разные модули параллельно
Повторное использование	Один модуль можно использовать в нескольких проектах
Изоляция изменений	Изменяя один модуль, не нужно трогать другие
Независимое тестирование	Каждый модуль тестируется отдельно

Виды декомпозиции

Вид декомпозиции	Что разбиваем	На что разбиваем	Пример
Функциональная	Функции программы	Подфункции (по действиям)	Авторизация → Проверка логина → Проверка пароля → Выдача токена
Данных	Данные, которые хранит программа	Типы данных, сущности	Пользователь → Имя, Email, Пароль, Адрес
Процессная	Процессы обработки	Этапы процесса	Обработка заказа → Проверка → Оплата → Отгрузка
Событийная	Реакция на события	Обработчики событий	Нажатие кнопки → Обработчик клика
Пространственная	Физическое размещение	Серверы, клиенты	Бэкенд (сервер), Фронтенд (браузер), БД (отдельный сервер)

Пример декомпозиции интернет-магазина

Уровень 1 (система): Интернет-магазин

Уровень 2 (подсистемы):

Фронтенд (интерфейс пользователя)
Бэкенд (бизнес-логика)
База данных (хранение)

Уровень 3 (модули бэкенда):

Модуль авторизации
Модуль каталога
Модуль корзины
Модуль заказов
Модуль оплаты
Модуль уведомлений

Уровень 4 (функции модуля каталога):

Показать список товаров
Найти товар по названию
Отфильтровать по цене
Отсортировать по рейтингу
Показать карточку товара

Принципы хорошей декомпозиции

Принцип	Что значит	Нарушение
Один уровень абстракции	Все элементы одного уровня должны быть примерно одинаковой детализации	Смешали «показать товар» и «переместить байт в регистр»
Ортогональность	Модули не должны пересекаться по функциям	Два модуля оба умеют отправлять email
Завершённость	Все функции системы охвачены модулями	Есть функция, которая не попала ни в один модуль
Минимизация интерфейсов	Модули должны общаться через минимум параметров	Модуль требует 10 параметров для работы

Ошибки при декомпозиции

Ошибка	Что значит	Пример
Недостаточная декомпозиция	Модули слишком большие	Один модуль «Всё» на 50 000 строк
Избыточная декомпозиция	Слишком много мелких модулей	Каждая функция — отдельный модуль
Неверное разделение	Функции, которые часто меняются вместе, разнесены по разным модулям	Кнопка «Купить» и логика покупки в разных модулях
Циклические зависимости	Модуль А зависит от Б, Б от А	А → Б → А (замкнутый круг)

Вопрос 48.

Алгоритмизация в разработке программного обеспечения

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

Что такое алгоритм (определение)

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

Пример алгоритма «Как сварить яйцо всмятку»:

Взять яйцо
Поставить кастрюлю с водой на огонь
Дождаться кипения воды
Опустить яйцо в кипящую воду
Варить 3 минуты
Вынуть яйцо
Положить в холодную воду на 1 минуту

Свойства алгоритма (6 свойств)

Свойство	Что значит	Пример нарушения
Дискретность	Алгоритм разбит на отдельные шаги	«Сделай всё быстро» — не дискретно
Детерминированность	Каждый шаг понятен и недвусмыслен	«Добавь немного соли» — не детерминировано
Конечность	Алгоритм заканчивается за конечное число шагов	Бесконечный цикл — нарушение
Результативность	Алгоритм даёт правильный результат	Алгоритм не решает задачу
Массовость	Алгоритм работает для всех допустимых входных данных	Работает только для числа 5, а для 6 — нет
Понятность	Алгоритм можно понять и выполнить	Написан на неизвестном языке

Пример алгоритма с нарушением свойства

Шаг	Плохой алгоритм	Хороший алгоритм
1	Обработать данные как-нибудь (не детерминированно)	Считать число X из файла input.txt
2	Если X больше примерно 5… (не дискретно)	Если X > 5, то перейти к шагу 3
3	Сделать что-то умное (не понятно)	Y = X * 2
4	И так пока не надоест (бесконечно)	Повторить шаги 2-4, пока X < 100
5	Написать результат (не массово)	Записать Y в файл output.txt

Вопрос 49.

Способы записи алгоритмов

Краткая теория: Алгоритм можно записать по-разному. Способ записи зависит от того, для кого предназначен алгоритм: для человека (словесно, графически) или для компьютера (язык программирования). Чем формальнее запись, тем легче её автоматизировать.

Основные способы записи алгоритмов

Способ	Как выглядит	Для кого	Пример
Словесный (естественный язык)	Текст на русском или английском	Для человека	«Взять два числа, сложить их, результат вывести»
Графический (блок-схема)	Геометрические фигуры со стрелками	Для человека	Прямоугольники, ромбы, стрелки
Псевдокод	Смесь естественного языка и конструкций программирования	Для человека и программиста	`if x > 0 then print(x) else print(-x)`
Формульный	Математические формулы	Для математиков	`y = a * x + b`
Программа на языке программирования	Код на Python, C++, Java	Для компьютера	`print(a + b)`

Пример одного алгоритма разными способами

Задача: Найти максимальное из двух чисел.

Словесный способ:

Ввести два числа A и B
Если A больше B, то результатом будет A
Иначе результатом будет B
Вывести результат

Псевдокод:

text

ВВЕСТИ A, B
ЕСЛИ A > B ТО
    РЕЗУЛЬТАТ = A
ИНАЧЕ
    РЕЗУЛЬТАТ = B
ВЫВЕСТИ РЕЗУЛЬТАТ

Программа на Python:

python

a = int(input())
b = int(input())
if a > b:
    result = a
else:
    result = b
print(result)

Сравнение способов записи

Характеристика	Словесный	Блок-схема	Псевдокод	Программа
Понятен неспециалисту	Да	Да (с объяснением)	Средне	Нет
Можно выполнить на компьютере	Нет	Нет (без специальных средств)	Нет	Да
Точность	Низкая	Высокая	Высокая	Абсолютная
Трудоёмкость	Низкая	Средняя	Средняя	Высокая
Используется в документации	Да (редко)	Да (часто)	Да (иногда)	Да (в коде)

Вопрос 50.

Блок-схемы алгоритмов

Блок-схема — это графическое представление алгоритма с использованием геометрических фигур (блоков), соединённых стрелками. Это один из самых наглядных способов представления алгоритмов, особенно для обучения и документации. Стандарт блок-схем описан в ГОСТ 19.701-90.

Основные элементы блок-схем

Фигура	Название	Что обозначает	Пример
Овал	Терминатор (начало/конец)	Начало или конец алгоритма	Начало, Конец
Прямоугольник	Процесс (действие)	Выполнение операции	`x = a + b`
Ромб	Решение (условие)	Ветвление (да/нет)	`x > 0 ?`
Параллелограмм	Ввод/вывод	Ввод данных или вывод результата	Ввод `a`, Вывод `s`
Шестиугольник	Предопределённый процесс	Вызов подпрограммы	`Вызов сортировки`
Соединитель	Переход на другую страницу	Точка соединения (если схема не влезает)	`A`, `1`
Стрелка	Линия потока	Направление выполнения	→, ↓, ←, ↑

Примеры блок-схем

Пример 1 — линейный алгоритм:

    [Начало]
        ↓
    [Ввод a, b]
        ↓
    [c = a + b]
        ↓
    [Вывод c]
        ↓
     [Конец]

Пример 2 — разветвляющийся (нахождение модуля числа):

     [Начало]
         ↓
     [Ввод x]
         ↓
      ◇ x >= 0 ?
        /     \
       Да      Нет
       ↓        ↓
    [y = x]  [y = -x]
       └───┬───┘
           ↓
     [Вывод y]
           ↓
        [Конец]

Пример 3 — цикл (сумма чисел от 1 до N):

        [Начало]
            ↓
        [Ввод N]
            ↓
        [s = 0, i = 1]
            ↓
           ◇ i <= N ?
           /     \
          Да      Нет
           ↓       ↓
      [s = s + i]  ↓
           ↓       ↓
        [i = i+1]  ↓
           ↓       ↓
           └───────┘
                ↓
          [Вывод s]
                ↓
            [Конец]

Правила построения блок-схем

Правило	Что значит
Линии только сверху вниз и слева направо	Основное направление — сверху вниз, слева направо
Стрелки не пересекаются	По возможности избегать пересечений
Один вход и один выход	У каждого блока (кроме начала и конца)
Подписи внутри фигур	Что именно делает блок
Точки соединения при разрыве	Если схема не влезает на один лист

Вопрос 51.

Линейные алгоритмы

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

Характеристики линейного алгоритма:

Характеристика	Что значит
Последовательность	Шаги выполняются строго друг за другом
Однократность	Каждый шаг выполняется один раз
Отсутствие ветвлений	Нет условий (если… то…)
Отсутствие циклов	Нет повторяющихся действий
Простота	Самый простой для понимания вид

Пример линейного алгоритма (расчёт площади прямоугольника):

Ввести длину стороны A
Ввести длину стороны B
Вычислить площадь: S = A × B
Вывести значение S

Здесь нет условий («если сторона больше нуля») и нет повторений. Каждый шаг — один раз.

Примеры задач, решаемых линейными алгоритмами:

Задача	Действия
Сложение двух чисел	Ввод A → Ввод B → C = A + B → Вывод C
Перевод из метров в сантиметры	Ввод M → C = M × 100 → Вывод C
Расчёт скорости	Ввод S (расстояние) → Ввод T (время) → V = S / T → Вывод V
Конвертация валюты	Ввод рублей → Курс = 0.01 → Доллары = Рубли × Курс → Вывод

Где используются линейные алгоритмы:

Область	Пример
Математические расчёты	Площадь, периметр, объём
Преобразование данных	Перевод единиц измерения
Последовательная обработка	Чтение строки, разбор на части, вывод
Инициализация	Установка начальных значений переменных

Ограничения линейных алгоритмов:

Ограничение	Что нельзя сделать
Нет выбора	Нельзя выполнить разные действия при разных условиях
Нет повторов	Нельзя выполнить действие много раз
Нет пропусков	Нельзя пропустить шаг при определённом условии

Если задача требует выбора («если дождь, то взять зонт»), линейного алгоритма недостаточно — нужно использовать разветвляющийся алгоритм.

Вопрос 52.

Разветвляющиеся алгоритмы

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

Основные конструкции ветвления:

Конструкция	Смысл	Схема словесно
Полное ветвление	Если условие истинно, делаем действие 1; иначе — действие 2	«Если дождь, то взять зонт, иначе надеть панаму»
Неполное ветвление	Если условие истинно, делаем действие; иначе — ничего	«Если дождь, то взять зонт»
Множественное ветвление	Выбор одного из нескольких вариантов	«Если оценка = 5, то «отлично»; если 4, то «хорошо»; если 3, то «удовлетворительно»»

Пример полного ветвления (определение модуля числа):

Ввести число X
Если X >= 0, то Y = X
Иначе Y = -X
Вывести Y

Пример неполного ветвления (проверка пароля):

Ввести пароль
Если пароль = «12345», то вывести «Доступ разрешён»
(Если пароль неверный, ничего не делать — программа просто завершится)

Пример множественного ветвления (оценка за тест):

Баллы	Результат
90–100	«Отлично»
75–89	«Хорошо»
50–74	«Удовлетворительно»
0–49	«Неудовлетворительно»

Сложные условия (логические операции):

Операция	Смысл	Пример
И (AND)	Истинно, если оба условия истинны	«Если сегодня суббота И солнечно, то идём гулять»
ИЛИ (OR)	Истинно, если хотя бы одно условие истинно	«Если сегодня суббота ИЛИ воскресенье, то выходной»
НЕ (NOT)	Меняет истину на ложь и наоборот	«Если НЕ дождь, то идём гулять»

Пример сложного условия (покупка товара со скидкой):
«Если сумма покупки больше 1000 рублей И пользователь является постоянным клиентом, то предоставить скидку 10%»

Где используются разветвляющиеся алгоритмы:

Область	Пример
Авторизация	Проверка логина и пароля
Валидация данных	Проверка, что введённые данные корректны
Классификация	Определение категории по значению
Обработка ошибок	Если ошибка, то показать сообщение
Игры	Проверка условий победы/поражения

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

Вопрос 53.

Циклические алгоритмы

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

Три типа циклов:

Тип цикла	Когда повторяем	Когда заканчиваем	Пример
Счётный (for)	Заданное количество раз	После выполнения нужного числа повторений	«Повторить 10 раз»
С предусловием (while)	Пока условие истинно	Когда условие становится ложным	«Пока в баке есть бензин, ехать»
С постусловием (do-while)	Хотя бы один раз, затем пока условие истинно	Когда условие становится ложным	«Нажать кнопку; повторять, пока не выйдет»

Пример цикла со счётчиком (сумма чисел от 1 до N):

Ввести N
S = 0
Для I от 1 до N выполнять: S = S + I
Вывести S

Пример цикла с предусловием (ожидание правильного ввода):

Ввести возраст
Пока возраст < 0 или возраст > 150, выполнять:
- Вывести «Ошибка, введите возраст от 0 до 150»
- Ввести возраст заново
Вывести «Возраст принят»

Пример цикла с постусловием (меню программы):

Повторять:
- Показать меню: 1 — продолжить, 0 — выход
- Ввести выбор
- Если выбор = 1, выполнить действие
Пока выбор != 0

Сравнение типов циклов:

Характеристика	Счётный (for)	С предусловием (while)	С постусловием (do-while)
Количество повторений	Известно заранее	Неизвестно заранее	Неизвестно заранее
Минимальное количество	0 (если 0 раз)	0 (если условие сразу ложно)	1 (хотя бы один раз)
Когда использовать	Перебор массива, табуляция	Ожидание события, ввод данных	Меню, повтор до правильного ввода
Риск	Нет	Бесконечный цикл (если условие всегда истинно)	Бесконечный цикл (если условие всегда истинно)

Пример задачи, где нужен цикл (поиск максимального числа в списке):

Без цикла (плохо)	С циклом (хорошо)
Сравнить число 1 и 2	Максимум = первое число
Сравнить результат с числом 3	Для каждого следующего числа:
Сравнить результат с числом 4	Если число > максимума, то максимум = число
… (повторять для каждого числа)	(Одна и та же инструкция для любого количества чисел)

Как избежать бесконечного цикла (правила):

Правило	Что делать
Менять условие внутри цикла	Увеличивать счётчик, считывать новые данные
Проверять граничные условия	Убедиться, что цикл когда-нибудь закончится
Использовать защиту от зацикливания	Ограничить максимальное количество итераций
Логировать подозрительные циклы	Выводить сообщение, если цикл выполняется слишком долго

Вопрос 54.

Вспомогательные алгоритмы и подпрограммы

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

Основные понятия:

Понятие	Что значит	Пример
Подпрограмма	Именованный блок кода, который можно вызвать по имени	«Вычислить квадратный корень»
Вызов подпрограммы	Обращение к подпрограмме из другого места	«вызвать сортировку_массива»
Параметры (аргументы)	Данные, которые передаются в подпрограмму	Числа A и B для сложения
Возвращаемое значение	Результат работы подпрограммы	Сумма A+B
Локальные переменные	Переменные, которые видны только внутри подпрограммы	Временная переменная для обмена значений

Зачем нужны подпрограммы (преимущества):

Преимущество	Объяснение
Переиспользование кода	Один и тот же алгоритм можно использовать в разных местах
Упрощение отладки	Подпрограмму можно отлаживать отдельно
Сокрытие сложности	Основная программа становится короткой и понятной
Разделение работы	Разные люди могут писать разные подпрограммы
Тестирование по частям	Каждую подпрограмму можно протестировать независимо

Пример без подпрограмм (плохо):

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

Пример с подпрограммой (хорошо):

Создаётся подпрограмма «факториал». В трёх местах программы просто вызывается эта подпрограмма. Код факториала написан один раз. Если нужны изменения — меняем в одном месте.

Виды подпрограмм:

Вид	Что делает	Пример
Процедура	Выполняет действия, но ничего не возвращает	«Напечатать отчёт»
Функция	Вычисляет и возвращает результат	«Квадратный корень из X»

Сравнение процедуры и функции:

Характеристика	Процедура	Функция
Возвращает значение	Нет	Да
Используется как часть выражения	Нет	Да (например, в формуле)
Пример	«Отправить email»	«Рассчитать НДС»
Вызов	Как отдельная команда	Внутри вычислений

Пример использования вспомогательных алгоритмов в жизни:

Задача	Вспомогательные подпрограммы
Сборка автомобиля	Собрать двигатель, собрать кузов, установить колёса, покрасить
Приготовление обеда	Почистить картошку, сварить суп, пожарить котлеты, нарезать салат
Написание отчёта	Собрать данные, рассчитать показатели, построить графики, оформить

Рекурсия — особый вид подпрограмм:

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

Пример рекурсии (вычисление факториала):

Факториал 5 = 5 × факториал 4
Факториал 4 = 4 × факториал 3
Факториал 3 = 3 × факториал 2
Факториал 2 = 2 × факториал 1
Факториал 1 = 1 (базовый случай)

Правила хороших подпрограмм:

Правило	Что значит
Одна задача	Подпрограмма делает что-то одно
Небольшой размер	Не более 50–100 строк (обычно)
Понятное имя	Имя отражает, что делает подпрограмма
Минимум параметров	Не более 3–5 параметров
Документация	Кратко описано, что делает, что принимает, что возвращает

Вопрос 55.

Основные структуры данных

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

Основные структуры данных (сравнение):

Структура	Как устроена	Основные операции	Когда использовать
Массив	Элементы одного типа, расположенные в памяти последовательно	Обращение по индексу — быстро; вставка/удаление — медленно	Фиксированное количество элементов, частый доступ по индексу
Список (связный)	Элементы связаны ссылками (каждый знает следующий)	Вставка/удаление — быстро; поиск по значению — медленно	Частые вставки и удаления, не важен порядок
Стек	LIFO (последним пришёл — первым ушёл)	Добавление (push), извлечение (pop) — быстро	Отмена действий, проверка скобок, обход графов
Очередь	FIFO (первым пришёл — первым ушёл)	Добавление в конец, извлечение из начала — быстро	Обработка запросов, печать документов
Хеш-таблица	Ключ → значение (как словарь)	Поиск, вставка, удаление по ключу — очень быстро	Быстрый поиск по ключу (телефонная книга)
Дерево	Иерархическая структура (корень, ветви, листья)	Поиск, вставка, удаление — быстро	Иерархические данные (файловая система), поиск
Граф	Вершины и рёбра (связи)	Поиск пути, обход	Сети (дороги, соцсети, интернет)

Подробнее о каждой структуре:

Массив:

Элементы пронумерованы (индекс от 0 до N-1)
Доступ к любому элементу — мгновенно (по индексу)
Размер обычно фиксированный (нельзя добавить элемент, если массив полон)
Пример: список учеников в классе (пронумерованных по алфавиту)

Связный список:

Каждый элемент хранит данные и ссылку на следующий элемент
Чтобы найти 10-й элемент, нужно пройти с 1-го по 9-й
Легко добавить элемент в середину — нужно поменять только две ссылки
Пример: очередь в магазине (каждый помнит, кто за ним)

Стек:

Как стопка тарелок: последнюю поставили — первую взяли
Только две операции: положить (push) и взять (pop)
Пример: кнопка «Назад» в браузере, отмена (Ctrl+Z) в редакторе

Очередь:

Как очередь в поликлинике: кто первый пришёл — того первого обслуживают
Добавление — в конец, извлечение — из начала
Пример: очередь печати документов, обработка сообщений

Хеш-таблица (словарь):

Хранит пары «ключ — значение»
Поиск по ключу происходит почти мгновенно (даже в большой таблице)
Не помнит порядок добавления элементов
Пример: телефонная книга (по имени быстро найти номер)

Дерево:

Есть корневой элемент, у каждого элемента — один родитель и несколько детей
Нет циклов (нельзя вернуться наверх, кроме как через родителя)
Пример: файловая система (папки и файлы), родословное дерево

Граф:

Самый общий вид структуры данных
Вершины соединены рёбрами (могут быть направленными или нет)
Могут быть циклы (можно вернуться в вершину)
Пример: карта дорог (города — вершины, дороги — рёбра), социальная сеть (люди — вершины, дружба — рёбра)

Сравнение скорости операций (обобщённо):

Структура	Доступ по индексу/ключу	Поиск по значению	Вставка	Удаление
Массив	Очень быстро	Медленно	Медленно (сдвиг)	Медленно (сдвиг)
Связный список	Медленно (идти от начала)	Медленно	Быстро	Быстро
Стек	Только верхний	Нет	Быстро	Быстро
Очередь	Только первый/последний	Нет	Быстро	Быстро
Хеш-таблица	Очень быстро (по ключу)	Нет смысла	Очень быстро	Очень быстро
Дерево	Средне (по значению)	Средне	Средне	Средне

Как выбрать структуру данных (вопросы для решения):

Вопрос	Если ДА	Если НЕТ
Нужен быстрый доступ по номеру (индексу)?	Массив	Список или хеш-таблица
Часто вставляются и удаляются элементы?	Связный список	Массив
Данные обрабатываются в порядке LIFO (последним пришёл — первым ушёл)?	Стек	Очередь
Данные обрабатываются в порядке FIFO (первым пришёл — первым ушёл)?	Очередь	Стек
Нужен очень быстрый поиск по ключу (например, по имени)?	Хеш-таблица	Дерево или список
Данные имеют иерархическую структуру?	Дерево	Граф или список
Данные имеют сложные связи (дороги, соцсети)?	Граф	Дерево

Вопрос 56.

Понятие базы данных в программной системе

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

Основные понятия баз данных:

Понятие	Что значит	Пример
Данные	Информация, которая хранится	Имя пользователя, цена товара
База данных (БД)	Хранилище организованных данных	Список всех клиентов магазина
Система управления базами данных (СУБД)	Программа для работы с БД (добавление, поиск, удаление)	MySQL, PostgreSQL, Oracle
Таблица	Данные, организованные в строки и столбцы	Таблица «Пользователи»
Строка (запись)	Один объект в таблице	Иванов Иван, ivan@mail.ru
Столбец (поле)	Одна характеристика всех объектов	email, возраст, город
Ключ	Уникальный идентификатор строки	ID пользователя (1, 2, 3…)

Пример таблицы «Пользователи»:

ID	Имя	Email	Город
1	Иван	ivan@mail.ru	Москва
2	Мария	maria@mail.ru	СПб
3	Пётр	petr@mail.ru	Казань

Зачем нужна база данных (а не простой файл):

Возможность	Файл (Excel, CSV)	База данных
Поиск по 1 млн записей	Минуты	Секунды (доли секунды)
Поиск по нескольким таблицам	Сложно, вручную	Легко (JOIN)
Одновременный доступ 1000 пользователей	Нет (файл блокируется)	Да
Безопасность, разграничение прав	Минимальная	Развитая
Ограничения (возраст не может быть отрицательным)	Нет	Да
Резервное копирование и восстановление	Вручную	Автоматически

Типы баз данных (по модели данных):

Тип	Как хранит данные	Примеры	Когда использовать
Реляционные (SQL)	Таблицы со строками и столбцами, связи между таблицами	PostgreSQL, MySQL, Oracle, SQLite	Большинство бизнес-приложений (учёт, заказы, клиенты)
Документные (NoSQL)	Документы в формате JSON (гибкая структура)	MongoDB, CouchDB	Каталоги товаров, логи, контент
Ключ-значение	Пара «ключ → значение» (очень быстрый доступ по ключу)	Redis, Memcached, DynamoDB	Кэширование, сессии пользователей
Графовые	Вершины и рёбра (как графы в математике)	Neo4j, ArangoDB	Социальные сети, рекомендации, поиск путей
Колоночные	Данные хранятся по столбцам, а не по строкам	ClickHouse, Cassandra	Аналитика, большие данные, хранилища данных

Основные операции с базой данных (CRUD):

Операция	Английский	Что делает	Пример
Создание	Create	Добавить новую запись	Зарегистрировать нового пользователя
Чтение	Read	Найти и прочитать данные	Показать профиль пользователя
Обновление	Update	Изменить существующие данные	Сменить пароль
Удаление	Delete	Удалить запись	Удалить аккаунт пользователя

Где используются базы данных (примеры):

Система	Что хранит	Тип БД
Интернет-магазин	Товары, заказы, пользователи	Реляционная
Социальная сеть	Пользователи, друзья, посты, лайки	Графовая + реляционная
Банк	Счета, транзакции, клиенты	Реляционная (строгая надёжность)
Корзина товаров на сайте	Временные данные (сессия)	Ключ-значение (быстро)
Аналитика (отчёты)	Миллиарды записей	Колоночная
Система логирования	Логи серверов	Документная

Вопрос 57.

Проектирование базы данных для программного продукта

Проектирование базы данных — это процесс создания структуры БД: какие таблицы нужны, какие поля в них будут, как таблицы связаны между собой. Хорошо спроектированная БД — основа быстрой и надёжной работы программы. Плохая БД приводит к замедлению, ошибкам и дублированию данных.

Основные этапы проектирования БД:

Этап	Что делаем	Результат
1. Анализ требований	Выясняем, какие данные нужно хранить	Список сущностей (пользователи, товары, заказы)
2. Логическое проектирование	Определяем сущности, атрибуты, связи (без привязки к конкретной СУБД)	ER-диаграмма (сущность-связь)
3. Физическое проектирование	Выбираем типы данных, индексы, конкретную СУБД	Схема БД (CREATE TABLE …)
4. Оптимизация	Добавляем индексы, нормализуем или денормализуем	Быстрая и надёжная БД

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

Понятие	Что значит	Пример для интернет-магазина
Сущность	Объект, о котором храним данные	Пользователь, Товар, Заказ
Атрибут	Характеристика сущности	Имя, цена, дата заказа
Первичный ключ	Уникальный идентификатор записи	ID пользователя (1, 2, 3…)
Внешний ключ	Ссылка на запись в другой таблице	ID пользователя в таблице «Заказы»
Связь	Как таблицы связаны друг с другом	У пользователя может быть много заказов

Типы связей между таблицами:

Тип связи	Что значит	Пример
Один к одному	Одной записи в таблице А соответствует одна запись в таблице Б	У пользователя — один паспорт
Один ко многим	Одной записи в таблице А соответствует много записей в таблице Б	У пользователя — много заказов
Многие ко многим	Много записей в А соответствует много записей в Б	Товары и категории (товар может быть в нескольких категориях)

Пример структуры БД для интернет-магазина:

Таблица	Поля	Тип
Пользователи	ID (ключ), Имя, Email, Пароль, Город	Один ко многим с Заказами
Товары	ID (ключ), Название, Цена, Количество	Один ко многим с Заказами (через корзину)
Заказы	ID (ключ), ID_пользователя (внешний ключ), Дата, Сумма	Многие к одному с Пользователями
Заказы_Товары	ID_заказа, ID_товара, Количество	Связь многие ко многим

Что такое нормализация (приведение БД к правильному виду):

Нормализация — это процесс устранения дублирования данных и обеспечения их целостности.

Пример ненормализованной БД (плохо):

Пользователь	Товары (список через запятую)
Иван	Яблоки, Груши, Бананы
Мария	Яблоки, Апельсины

Проблемы:

Сложно искать: «Кто купил Груши?» (надо парсить строку)
Сложно добавлять: «Добавить товар Киви» (надо найти все строки)
Дублирование: «Яблоки» написано два раза

Пример нормализованной БД (хорошо):

Пользователи	Товары	Покупки (связь)
1 — Иван	1 — Яблоки	1,1
2 — Мария	2 — Груши	1,2
	3 — Бананы	1,3
	4 — Апельсины	2,1
		2,4

Преимущества нормализации:

Нет дублирования
Легко добавлять и удалять
Легко искать
Данные целостны

Когда нужны индексы (для ускорения поиска):

Ситуация	Нужен индекс?
Поиск по ID (первичному ключу)	Да (автоматически)
Поиск по полю, по которому часто ищут (Email)	Да
Сортировка по полю	Да (если сортируют часто)
Поле, которое редко используется в поиске	Нет
Маленькая таблица (до 1000 записей)	Не обязательно
Частые вставки и обновления	Осторожно (индексы замедляют вставку)

Что такое транзакция (группа операций как одно целое):

Транзакция — это последовательность операций, которая выполняется либо полностью, либо не выполняется вообще.

Пример транзакции (перевод денег):

Списать 100 рублей со счёта А
Зачислить 100 рублей на счёт Б

Если после шага 1 произошёл сбой, то шаг 2 не выполнится, и 100 рублей пропадут. Транзакция откатит шаг 1, и деньги вернутся на счёт А.

Свойства транзакций (ACID):

Свойство	Что значит
Атомарность	Все операции выполняются или все отменяются
Согласованность	После транзакции данные остаются корректными
Изоляция	Параллельные транзакции не мешают друг другу
Долговечность	После подтверждения данные не теряются

Вопрос 58.

Этапы создания пользовательского интерфейса

Создание пользовательского интерфейса (UI — User Interface) — это многоэтапный процесс, который начинается задолго до того, как дизайнер откроет Figma или Photoshop. Основная цель — сделать интерфейс понятным, удобным и приятным для пользователя. Хороший интерфейс не требует инструкции — пользователь интуитивно понимает, что делать.

Полный список этапов создания интерфейса (8 этапов с деталями):

Этап	Что делаем	Результат	Кто делает	Длительность
1. Исследование пользователей	Изучаем целевую аудиторию: кто они, чем занимаются, какие у них цели и ограничения	Персонажи (портреты пользователей), сценарии использования	UX-исследователь, аналитик	1-3 недели
2. Информационная архитектура	Определяем структуру: сколько экранов, как они связаны, где какие блоки	Карта сайта (sitemap), схема навигации	UX-дизайнер	2-5 дней
3. Прототипирование (Wireframes)	Создаём каркасы экранов (чёрно-белые, без цвета и шрифтов)	Набор wireframes (низкая детализация)	UX-дизайнер	1-2 недели
4. UI-дизайн (макеты)	Добавляем цвета, шрифты, тени, иконки, отступы, анимацию	Макеты высокой детализации в Figma	UI-дизайнер	2-4 недели
5. Интерактивный прототип	Связываем макеты ссылками, добавляем переходы, анимацию	Кликабельный прототип (можно тыкать)	UI/UX-дизайнер	3-7 дней
6. Юзабилити-тестирование	Даём пользователям потыкать прототип, наблюдаем, где они спотыкаются	Отчёт с проблемами и рекомендациями	UX-исследователь	1-2 недели
7. Передача разработчикам	Экспортируем ресурсы (иконки, картинки), готовим спецификации	Набор ресурсов, макеты с размерами и цветами	Дизайнер	2-5 дней
8. Контроль вёрстки	Проверяем, как разработчики сверстали интерфейс, даём правки	Свёрстанный интерфейс, соответствующий макетам	Дизайнер	В процессе разработки

Пример исследования пользователей (что выясняем):

Вопрос	Зачем	Пример ответа
Какой возраст пользователей?	Подбираем размер кнопок, шрифтов	50-65 лет (кнопки должны быть крупными)
Как часто они пользуются компьютером?	Определяем уровень сложности	Редко (интерфейс должен быть максимально простым)
Какая у них цель?	Понимаем, какие функции главные	Купить билет (кнопка покупки — самая заметная)
В каких условиях используют?	Учитываем отвлекающие факторы	В метро, одной рукой (кнопки крупные, снизу

Что такое Wireframe (пример описания):

Wireframe — это схематичное изображение экрана без цвета, шрифтов и картинок. Только блоки и их расположение.

Описание wireframe для экрана входа:

В верхней части — логотип (по центру)
Ниже — заголовок «Вход в аккаунт»
Ниже — поле «Email» (с иконкой конверта слева)
Ниже — поле «Пароль» (с иконкой замка слева)
Ниже — кнопка «Войти» (ширина на всю форму, зелёная)
Ниже — ссылка «Забыли пароль?» (по центру)
Ниже — ссылка «Зарегистрироваться» (по центру)

Как тестировать интерфейс (методы):

Метод	Как работает	Что выявляет
Наблюдение	Смотрим, как пользователь выполняет задачу (не подсказываем)	Где пользователь зависает, где ошибается
Опрос после теста	Спрашиваем: «Что было неудобно?»	Субъективные впечатления
A/B-тестирование	Показываем двум группам разные версии, сравниваем	Какая версия работает лучше
Тепловые карты	Смотрим, куда пользователь чаще кликает	Какие элементы привлекают внимание
Анализ времени выполнения	Засекаем, сколько времени на задачу	Насколько интерфейс эффективен

Типичные проблемы интерфейса, которые выявляет тестирование:

Проблема	Пример	Исправление
Кнопка не заметна	Белая кнопка на белом фоне	Сделать контрастной
Непонятная иконка	Иконка «шестерёнка» для настроек — понятно, а иконка «три точки» — нет	Добавить текст
Мелкий шрифт	Текст 8 пикселей на экране телефона	Увеличить до 14-16
Много шагов	10 шагов для регистрации	Сократить до 3-5
Нет обратной связи	Нажал кнопку — ничего не происходит	Добавить спиннер или сообщение

Вопрос 59.

Требования к пользовательскому интерфейсу

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

Группы требований к пользовательскому интерфейсу:

Группа	Что включает	Пример
Визуальные	Цвета, шрифты, отступы, выравнивание, контрастность	Кнопка «Купить» должна быть зелёной и заметной
Эргономические	Удобство, доступность, минимум движений	Кнопка подтверждения не рядом с кнопкой удаления
Поведенческие	Реакция на действия пользователя, обратная связь	При нажатии кнопка должна менять цвет
Технические	Скорость загрузки, адаптивность, совместимость	Интерфейс должен работать на всех браузерах
Инклюзивные	Доступность для людей с ограничениями	Поддержка экранных дикторов

Детальные требования к интерфейсу (по стандартам и лучшим практикам):

Визуальные требования:

Требование	Что значит	Пример
Контрастность	Текст должен легко читаться на фоне	Чёрный текст на белом фоне (контраст 21:1)
Единый стиль	Все кнопки выглядят одинаково	Все кнопки «Сохранить» одного цвета и размера
Иерархия	Главное — крупное и заметное, второстепенное — мелкое	Заголовок больше, чем текст под ним
Воздух (отступы)	Элементы не слипаются	Между кнопками 10 пикселей, а не 2
Цветовая гармония	Цвета не режут глаз, сочетаются друг с другом	Синий, белый, серый — спокойная гамма

Эргономические требования (удобство):

Требование	Что значит	Пример
Закон Фиттса	Чем ближе и крупнее цель, тем легче попасть	Корзина в правом верхнем углу (близко к курсору)
Правило 3 кликов	Любое действие — не более 3 кликов	Оплата заказа: Корзина → Оформить → Подтвердить
Правило «золотого сечения»	Важные элементы в определённых точках экрана	Главная кнопка в правом нижнем углу (для пальца)
Минимизация нагрузки на память	Не заставлять пользователя запоминать	Показывать список недавних документов
Обратная связь	Пользователь понимает, что происходит	«Загрузка…», «Сохранено», «Ошибка»

Поведенческие требования (как ведёт себя интерфейс):

Требование	Что значит	Пример
Прогнозируемость	Одинаковые действия — одинаковый результат	Кнопка «Назад» всегда ведёт на предыдущую страницу
Предотвращение ошибок	Интерфейс не даёт сделать ошибку	Кнопка «Удалить» спросит подтверждение
Восстановление после ошибок	Можно отменить действие	Кнопка «Отменить» (Ctrl+Z)
Сохранение состояния	Не теряются данные при случайном закрытии	Форма сохраняет введённый текст
Постоянство элементов	Знакомые элементы на знакомых местах	Меню всегда сверху, корзина справа

Технические требования:

Требование	Что значит	Пример
Адаптивность	Хорошо выглядит на любом экране	Телефон, планшет, компьютер
Кроссбраузерность	Работает во всех браузерах	Chrome, Firefox, Safari, Edge
Скорость загрузки	Интерфейс появляется быстро	Первый экран — менее 1 секунды
Доступность (Accessibility)	Для людей с ограничениями	Экранные дикторы, высокая контрастность
Интернационализация	Поддерживает разные языки и культуры	Русский, английский, дата в формате ДД.ММ.ГГГГ

Как проверить, соответствует ли интерфейс требованиям (методы):

Метод	Что проверяет	Инструменты
Экспертная оценка	Все требования (эксперт смотрит)	Чек-лист из 50+ пунктов
Юзабилити-тестирование	Удобство для пользователей	Запись экрана, наблюдение
A/B-тестирование	Какая версия лучше	Статистика конверсий
Автоматические проверки	Контрастность, размер шрифта, адаптивность	Lighthouse, WAVE
Опрос пользователей	Субъективная удовлетворённость	Google Forms

Вопрос 60.

Принципы удобства и эргономики интерфейса

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

10 главных принципов удобства интерфейса (по Якобу Нильсену):

Принцип	Что значит	Пример нарушения	Хорошее решение
1. Видимость состояния	Пользователь знает, что происходит	Нажал кнопку — ничего не изменилось	Кнопка стала неактивной, появился спиннер
2. Соответствие реальному миру	Используются понятные пользователю слова и образы	«Аутентификация не пройдена»	«Неверный логин или пароль»
3. Свобода и контроль	Пользователь может отменить действие	Нет кнопки «Назад»	Есть кнопка «Отменить»
4. Стандарты и единообразие	Одинаковые элементы выглядят одинаково	Кнопка «Сохранить» в одном месте зелёная, в другом — синяя	Все кнопки сохранения одного цвета
5. Предотвращение ошибок	Интерфейс не даёт сделать ошибку	Пользователь может удалить всё одним кликом	Спросить подтверждение перед удалением
6. Узнавание, а не припоминание	Пользователь видит варианты, а не вспоминает	Надо помнить точное название команды	Выпадающий список с вариантами
7. Гибкость и эффективность	Для опытных пользователей есть быстрые способы	Нет горячих клавиш	Ctrl+S, Ctrl+C, Ctrl+V
8. Эстетика и минимализм	Ничего лишнего, только нужное	Много рекламы, лишних кнопок	Только нужные элементы
9. Помощь в обнаружении ошибок	Сообщение подсказывает, как исправить	«Ошибка 500»	«Поле Email должно содержать @»
10. Помощь и документация	Если что-то непонятно, можно прочитать	Нет раздела «Помощь»	Инструкция, подсказки

Дополнительные принципы эргономики:

Принцип	Что значит	Пример
Закон Хика	Время выбора растёт с количеством вариантов	2 варианта лучше, чем 10 (да/нет вместо выбора из списка)
Закон Миллера	Человек удерживает в памяти 7±2 объекта	Не больше 7 пунктов в меню
Эффект близости	Близкие элементы воспринимаются как связанные	Группировать связанные поля формы
Эффект сходства	Одинаковые элементы воспринимаются как связанные	Все кнопки действий — одного цвета
Эффект ориентира	Первый и последний элемент запоминаются лучше	Самые важные пункты — в начало и конец меню
Принцип F-образного чтения	Пользователь сканирует экран буквой F	Важная информация — по левому краю

Принципы доступности (для людей с ограничениями):

Принцип	Для кого	Что значит	Пример
Текстовые альтернативы	Для незрячих (экранные дикторы)	У каждой картинки есть текстовое описание	`<img alt="Красное яблоко">`
Достаточный контраст	Для слабовидящих	Текст легко читается на фоне	Чёрный на белом, контраст 21:1
Навигация с клавиатуры	Для людей с нарушениями моторики	Можно управлять Tab, Enter, стрелками	Tab переключает поля, Enter — выбор
Достаточный размер	Для людей с нарушениями моторики	Кнопки достаточно крупные	40×40 пикселей (не 10×10)
Не только цвет	Для дальтоников	Информация передаётся не только цветом	«Красный» + «Значок ошибки»
Адаптивный размер шрифта	Для слабовидящих	Можно увеличить шрифт без поломки	Интерфейс «резиновый», а не фиксированный

Как измерить удобство интерфейса (метрики):

Метрика	Что измеряет	Как вычислить	Хорошее значение
Время выполнения задачи	Сколько секунд нужно, чтобы сделать действие	Засечь от начала до конца	< 30 секунд
Количество ошибок	Сколько раз пользователь ошибся	Посчитать	< 2 на задачу
Успешность выполнения	Какой процент пользователей выполнил задачу	Успешно / Всего × 100%	> 90%
Удовлетворённость (SUS)	Как пользователю нравится	Опросник из 10 вопросов	> 70 баллов
Обучаемость	Как быстро новичок становится эффективным	Время с первого раза до 5-го	< 5 повторений

Вопрос 61.

Прототипирование пользовательского интерфейса

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

Уровни прототипирования (от низкой детализации к высокой):

Уровень	Название	Что включает	Инструменты	Длительность
1	Бумажный прототип	Рисунки от руки, вырезанные элементы	Бумага, карандаш, ножницы	Часы-день
2	Цифровой каркас (Wireframe)	Схемы, блоки, без цвета и шрифтов	Balsamiq, Figma (базовая)	2-5 дней
3	Макет низкой детализации (Lo-Fi)	Схемы + логические связки (кликабельно)	Figma, Axure, Adobe XD	1-2 недели
4	Макет высокой детализации (Hi-Fi)	Цвета, шрифты, иконки, анимация, кликабельно	Figma, Sketch, Adobe XD	2-4 недели
5	Интерактивный прототип	Почти готовый интерфейс с логикой	Axure, ProtoPie, Framer	3-6 недель

Что даёт каждый уровень прототипирования:

Уровень	Плюсы	Минусы	Когда использовать
Бумажный	Быстро, дёшево, легко менять	Нельзя кликнуть, нереалистично	Самое начало, грубое согласование
Wireframe	Понятно расположение блоков	Нет визуала, трудно оценить эстетику	Утверждение структуры
Lo-Fi	Уже можно кликать, проверять логику	Нет цветов, скучный	Тестирование сценариев
Hi-Fi	Почти как готовый продукт	Долго делать, дорого менять	Тестирование визуала, передача разработчикам
Интерактивный	Полная симуляция	Очень дорого, долго	Сложные анимации, демо для инвесторов

Пример перехода от идеи к прототипу (процесс):

Этап	Действие	Пример для кнопки «Купить»
1	Бумага	Рисуем прямоугольник, пишем внутри «Купить», вырезаем
2	Wireframe	Прямоугольник 200×50, посередине текст «Купить»
3	Lo-Fi	Прямоугольник, по клику переходит на страницу оплаты
4	Hi-Fi	Зелёный прямоугольник, белый шрифт, тень, скруглённые углы
5	Интерактив	При нажатии появляется спиннер, затем переход с анимацией

Инструменты для прототипирования (сравнение):

Инструмент	Уровни	Цена	Сложность	Для кого
Бумага + карандаш	Бумажный	Бесплатно	Очень низкая	Все, быстрое начало
Balsamiq	Wireframe	Платная	Низкая	Проектировщики
Figma	Все уровни	Бесплатно (базовая)	Средняя	Самый популярный
Sketch	Hi-Fi	Платная (только Mac)	Средняя	Дизайнеры на Mac
Adobe XD	Все уровни	Платная (есть бесплатный план)	Средняя	Пользователи Adobe
Axure	Все уровни + сложная логика	Платная	Высокая	Крупные проекты
ProtoPie	Интерактивный	Платная	Высокая	Сложная анимация

Что должно быть в прототипе для передачи разработчикам:

Элемент	Что указываем	Пример
Размеры	Ширина, высота элементов	Кнопка 200×50 пикселей
Отступы	Расстояние между элементами	Отступ от края экрана 20 пикселей
Цвета	HEX-коды или названия	`#FF0000` (красный)
Шрифты	Название, размер, начертание	Roboto, 16 px, полужирный
Состояния	Обычное, при наведении, при нажатии	Кнопка: зелёная → тёмно-зелёная при наведении
Анимация	Длительность, тип, как меняется	0.3 сек, плавное появление
Логика переходов	При каком действии что происходит	Клик по «Вход» → открыть экран входа

Как тестировать прототип (методы):

Метод	Как работает	На каком уровне
Самостоятельная проверка	Дизайнер сам кликает и ищет нестыковки	Любой
Проверка с коллегами	Показываем коллегам, собираем мнения	Любой
Тестирование с пользователями	Приглашаем реальных пользователей, даём задачи	Lo-Fi, Hi-Fi
A/B-тестирование прототипов	Показываем два варианта, спрашиваем мнение	Hi-Fi
Проверка на доступность	Проверяем контрастность, шрифты, управление с клавиатуры	Hi-Fi

Вопрос 62.

Кодирование как этап разработки программного обеспечения

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

Место кодирования в общем процессе разработки:

Этап	До кодирования	Кодирование	После кодирования
Что делаем	Анализ требований, проектирование	Пишем код	Тестирование, внедрение, сопровождение
% времени (водопад)	35%	20%	45%
% времени (Agile)	15% (в каждом спринте)	40% (в каждом спринте)	45% (в каждом спринте)

Что входит в этап кодирования (не только написание кода):

Действие	Что делаем	Почему важно
Написание кода	Пишем функции, классы, модули по проекту	Основная работа
Написание юнит-тестов	Пишем тесты для проверки своего кода	Без тестов нельзя быть уверенным
Форматирование кода	Приводим код к единому стилю (отступы, пробелы)	Код читается легче
Комментирование	Добавляем пояснения к сложным местам	Через год сами поймём
Работа с Git	Делаем коммиты, создаём ветки, пушим	Контроль версий
Code review	Показываем код коллегам, они проверяют	Ошибки ловятся раньше
Интеграция	Объединяем свой код с общим репозиторием	Чтобы не было конфликтов
Запуск тестов в CI	Автоматическая проверка всех тестов	Убеждаемся, что ничего не сломали

Этапы кодирования одной задачи (сценарий):

Шаг	Действие	Время
1	Взять задачу из Jira (баг-трекера)	5 минут
2	Создать ветку от `develop`	1 минута
3	Переключиться на новую ветку	1 минута
4	Написать код (сама задача)	2 часа
5	Написать юнит-тесты	30 минут
6	Проверить код (локальный запуск)	15 минут
7	Сделать коммит с понятным сообщением	5 минут
8	Отправить ветку на сервер (push)	1 минута
9	Открыть Pull Request	5 минут
10	Ждать code review (коллеги смотрят)	от 1 часа до 1 дня
11	Исправить замечания (если есть)	переменная
12	Получить одобрение (approve)	1 минута
13	Влить (merge) ветку в develop	1 минута
14	Удалить ветку (локально и на сервере)	1 минута

Что делает код хорошим (критерии качества кода):

Критерий	Что значит	Пример нарушения
Читаемость	Код понятен другому разработчику	Переменные a, b, c вместо meaningful names
Простота	Нет лишней сложности	50 строк там, где можно 5
Модульность	Код разбит на маленькие функции	Одна функция на 500 строк
Тестируемость	К каждому блоку легко написать тест	Функция использует глобальные переменные
Эффективность	Код работает достаточно быстро	Цикл в цикле для 10 элементов
Документированность	Сложные места пояснены	Сложный алгоритм без комментариев
Отсутствие дублирования	Одна и та же логика не повторяется	Один и тот же расчёт в 5 местах

Что мешает писать хороший код (факторы, снижающие качество):

Фактор	Что происходит	Как бороться
Дедлайны («сделать вчера»)	Программист «забивает» на качество	Реалистичные сроки
«Потом починю»	Оставляем временный костыль, который становится постоянным	Рефакторить сразу
Непонятные требования	Программист додумывает за заказчика	Уточнять требования до кода
Отсутствие code review	Ошибки никто не проверяет	Внедрить обязательный code review
Устаревшая документация	Код пишут по старому, а надо по-новому	Обновлять документацию

Вопрос 63.

Требования к качеству программного кода

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

Основные требования к качеству кода (7 характеристик):

Характеристика	Что значит	Почему важно
Читаемость	Код понятен другому разработчику (или себе через год)	Меньше времени на понимание
Простота	Минимум лишних сложностей	Меньше ошибок
Модульность	Код разбит на маленькие, независимые части	Легко тестировать и менять
Отсутствие дублирования	Одна логика — в одном месте	Исправляем один раз — везде работает
Тестируемость	К каждой части можно написать тест	Уверенность в правильности
Эффективность	Код использует ресурсы разумно	Программа не тормозит
Безопасность	Код не содержит уязвимостей	Данные не украдут

Как измерить качество кода (метрики):

Метрика	Что измеряет	Как вычислить	Хорошее значение
Цикломатическая сложность	Сложность логики (количество путей)	Количество `if`, `for`, `while`	< 10 на функцию
Покрытие тестами	Какой процент кода проверен тестами	(Строки в тестах / Все строки) × 100%	> 70%
Комментарии	Код понятен без комментариев?	Субъективно	Комментарии объясняют «почему», а не «что»
Количество строк функции	Не слишком ли функция длинная?	Посчитать строки	< 50 строк (часто < 30)
Количество параметров	Не слишком ли много параметров?	Посчитать параметры	< 5 (часто < 3)
Глубина вложенности	Не слишком ли много вложенных if?	Посчитать уровень	< 4 уровня
Количество замечаний линтера	Нарушение стиля	Запустить линтер	0 критических замечаний

Что такое технический долг (плохой код как кредит):

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

Тип технического долга	Пример	Как быстро растёт	Как исправлять
Дублирование кода	Одна логика в 10 местах	Медленно	Выделить общую функцию
Сложные функции	Функция на 300 строк	Быстро	Разбить на маленькие
Отсутствие тестов	Ручное тестирование	Очень быстро	Написать тесты
Устаревшие зависимости	Старая библиотека, не обновляли	Скачкообразно	Обновить
«Костыли»	Временные решения, которые стали постоянными	Постоянно	Переписать нормально

Золотые правила написания хорошего кода (с примерами):

Правило	Плохо (нарушение)	Хорошо
Понятные имена	`a, b, c, x, y, z`	`price, quantity, total, userName`
Не использовать магические числа	`if x > 7`	`MAX_LOGIN_ATTEMPTS = 7`
Одна функция — одна задача	Функция и считает, и пишет в БД, и отправляет email	Разбить на 3 функции
Не повторяться (DRY)	Расчёт НДС в 5 местах	Вынести в функцию `calculateVAT()`
Комментировать «почему»	`x = x + 1 // увеличиваем x на 1`	`// Добавляем скидку, потому что постоянный клиент`
Избегать глубокой вложенности	`if (a) { if (b) { if (c) { ... } } }`	Ранний `return`

Вопрос 64.

Стандарты оформления программного кода

Стандарты оформления кода (code style) — это набор правил о том, как должны называться переменные, где ставить пробелы, как делать отступы, где писать фигурные скобки. Единый стандарт в команде делает код читаемым для всех. Без стандарта каждый пишет как хочет, и код превращается в «кашу», где трудно разобраться.

Зачем нужны стандарты оформления кода (4 причины):

Причина	Объяснение
Читаемость	Код выглядит одинаково, его легче читать и понимать
Упрощение code review	Проверяющий не отвлекается на стиль, только на логику
Снижение ошибок	Однообразный стиль помогает заметить опечатки
Быстрое вхождение новичков	Новый разработчик быстро привыкает к единому стилю

Основные элементы стандарта кода (что регулируется):

Элемент	Что регулирует	Пример
Именование	Как называть переменные, функции, классы	`userName` (camelCase) или `user_name` (snake_case)
Отступы	Сколько пробелов на один уровень вложенности	4 пробела (не табуляция)
Пробелы	Где ставить пробелы вокруг операторов	`a = b + c`, а не `a=b+c`
Длина строки	Максимальное количество символов в строке	Не более 79 (PEP 8) или 100-120 (другие стандарты)
Пустые строки	Когда разделять блоки кода пустой строкой	Между функциями 2 пустые строки
Комментарии	Как оформлять комментарии	`# Это комментарий` (с пробелом после `#`)
Импорты	В каком порядке подключать библиотеки	Сначала стандартные, потом сторонние, потом свои
Фигурные скобки	Где ставить открывающую скобку	На той же строке или на новой

Популярные стандарты кода для разных языков:

Язык	Стандарт	Особенность
Python	PEP 8	Отступы 4 пробела, snake_case для переменных
Java	Google Java Style	camelCase, фигурные скобки на той же строке
JavaScript	Airbnb Style Guide	Точки с запятой обязательны, пробелы вокруг скобок
C++	Google C++ Style Guide	Отступы 2 пробела, имена классов с большой буквы
C#	Microsoft .NET Coding Conventions	camelCase, `this.` для полей класса
Go	Effective Go	Очень строгий, gofmt автоматически форматирует
PHP	PSR-12	Отступы 4 пробела, camelCase для методов

Пример различий в стандартах (именование):

Элемент	Python (PEP 8)	Java (Google)	JavaScript (Airbnb)
Переменная	`user_name`	`userName`	`userName`
Константа	`MAX_SIZE`	`MAX_SIZE`	`MAX_SIZE`
Функция	`get_user_name()`	`getUserName()`	`getUserName()`
Класс	`UserAccount`	`UserAccount`	`UserAccount`
Приватное поле	`_internal`	`internal_`	`_internal`

Как внедрить стандарт в команде (пошагово):

Шаг	Действие	Инструменты
1	Выбрать стандарт (существующий или создать свой)	PEP 8, Google Style, Airbnb
2	Настроить автоматический форматтер	Black (Python), Prettier (JS), clang-format (C++)
3	Настроить линтер (проверку стиля)	Pylint, ESLint, Checkstyle
4	Добавить проверку стиля в CI (при каждом коммите)	GitHub Actions, GitLab CI
5	Настроить IDE, чтобы она форматировала автоматически	VS Code, PyCharm, IntelliJ
6	Провести обучение команды (1 час)	Демонстрация, разбор примеров

Автоматические инструменты для проверки и исправления стиля:

Инструмент	Язык	Что делает	Запуск
Black	Python	Автоматически форматирует код	`black my_file.py`
Pylint	Python	Проверяет стиль и находит проблемы	`pylint my_file.py`
ESLint	JavaScript	Проверяет стиль и потенциальные ошибки	`eslint my_file.js`
Prettier	JS, TS, CSS, JSON	Автоформатирование	`prettier --write .`
Checkstyle	Java	Проверка стиля	`checkstyle -c /sun_checks.xml MyFile.java`
clang-format	C, C++	Автоформатирование	`clang-format -i my_file.cpp`
gofmt	Go	Автоформатирование (встроен в язык)	`gofmt -w my_file.go`

Пример автоматического форматирования (что делает Black с Python-кодом):

Было (нарушает стандарт)	Стало (после Black)
`x=5`	`x = 5`
`if x==5: print(x)`	`if x == 5: print(x)`
`def f(): return x+1`	`def f(): return x + 1`
`{"a":1,"b":2}`	`{"a": 1, "b": 2}`

Что делать, если стандарт нарушен (уровни нарушений):

Уровень	Что значит	Действие
Критический	Нарушение делает код непонятным	Не пропустить код без исправления
Предупреждение	Нарушение стиля, но код читаем	Рекомендовать исправить
Информационное	Незначительное отклонение	Можно игнорировать

Вопрос 65.

Виды программной документации Дубл.

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

Классификация документации по ГОСТ 19.xxx (ЕСПД — Единая система программной документации):

ГОСТ 19.101-77 определяет следующие виды документов:

Код	Название документа	Содержание	Обязательность
19.101	Техническое задание (ТЗ)	Назначение, требования, сроки	Для госзаказа
19.102	Пояснительная записка	Обоснование выбора архитектуры, алгоритмов	Для госзаказа
19.103	Руководство программиста	Описание модулей, API, сборка	Для госзаказа
19.104	Руководство пользователя	Установка, запуск, использование	Для госзаказа
19.105	Описание языка	Синтаксис, семантика языка	Для языковых процессоров
19.106	Текст программы	Распечатка кода (редко)	По требованию
19.107	Программа и методика испытаний	Как тестировать, какие тесты	Для госзаказа

Современная классификация (по назначению и аудитории):

Категория	Для кого	Документы	Обязательность
Маркетинговая	Заказчик, инвесторы	Презентация, коммерческое предложение, брошюра	Для продажи
Контрактная	Заказчик, юристы	Техническое задание (ТЗ), контракт	Для любого коммерческого проекта
Техническая (внешняя)	Пользователи, администраторы	Руководство пользователя, руководство администратора	Почти всегда
Техническая (внутренняя)	Разработчики	Архитектурная документация, описание API, комментарии	Для крупных проектов
Процессная	Менеджеры, команда	План проекта, отчёты, протоколы встреч	Для управления

Какие документы нужны для разных типов проектов (матрица):

Тип проекта	ТЗ	Руководство пользователя	Руководство администратора	Архитектурная документация	Комментарии в коде
Студенческая работа	Да	Нет	Нет	Нет	Минимум
Мобильное приложение (своё)	Нет (или кратко)	Можно кратко (внутри приложения)	Нет	Нет	Да
Мобильное приложение (заказ)	Да	Да	Нет	Нет	Да
Сайт-визитка	Нет	Нет	Нет	Нет	Нет
Интернет-магазин (команда 5 чел)	Да	Да (для менеджеров)	Да (для хостинга)	Минимальная	Да
Корпоративная система (10+ чел)	Да	Да	Да	Да	Да
Open Source проект	Нет (README)	README + Wiki	README	README + диаграммы	Да (обязательно)

Что такое «живая документация» (документация, которая всегда актуальна):

Подход	Как работает	Примеры
Документация из кода	Генерация документации из комментариев	Javadoc, Doxygen, Sphinx
Документация как код	Документация в репозитории, обновляется с кодом	Markdown + Git, MkDocs
API-документация из спецификации	По спецификации генерируется и документация, и код	Swagger / OpenAPI
Тесты как документация	Тесты показывают, как использовать код	Тесты с примерами (pytest)

Чего не должно быть в хорошей документации:

Что не нужно	Почему	Пример нарушения
Устаревшая информация	Вредит больше, чем отсутствие	«Кнопка «Сохранить» слева» (а она справа)
Очевидные вещи	Засоряет документ	«Здесь вы видите окно программы»
Слишком много технических деталей	Пользователь не поймёт	«JSON-объект содержит поле id типа integer»
Отсутствие структуры	Невозможно найти нужное	100 страниц текста без оглавления
Размытые скриншоты	Непонятно, что на них	Скриншот 200×150 пикселей

Вопрос 66.

Пользовательская документация

Пользовательская документация — это документы, которые читает конечный пользователь программы. Она объясняет, как установить программу, как её запустить, как пользоваться основными функциями, как решать типовые проблемы. Хорошая пользовательская документация снижает нагрузку на техподдержку.

Основные виды пользовательской документации:

Вид	Что содержит	Для кого	Пример
README	Кратко: что за программа, как установить, как запустить	Все (разработчики, пользователи)	`README.md` на GitHub
Руководство пользователя	Полное описание всех функций, пошаговые инструкции	Конечные пользователи	PDF на 100 страниц
Быстрый старт (Quick Start)	Самые основные действия (3-5 шагов)	Новички	Карточка «Первые шаги»
Справка (Help)	Встроенная в программу помощь (F1)	Все пользователи	Окно помощи в приложении
FAQ (Частые вопросы)	Ответы на типовые проблемы	Пользователи, у которых проблемы	Раздел на сайте
Видеоуроки	Видео с действиями	Визуалы, ленивые читать	YouTube-канал продукта
Подсказки (Tooltips)	Краткие пояснения при наведении на элемент	Все пользователи	Всплывающее окно «Сохранить»
Интерактивные туры	Пошаговое обучение прямо в программе	Новички	Подсветка кнопок и стрелки

Структура руководства пользователя (классическая):

Раздел	Содержание	Пример
1. Введение	Назначение программы, для кого, основные возможности	«Программа предназначена для учёта товаров в магазине»
2. Системные требования	Какие компьютер, ОС, память нужны	Windows 10, 4 ГБ RAM, 100 МБ диска
3. Установка и запуск	Как установить, как запустить	«Запустите setup.exe, следуйте инструкции»
4. Обзор интерфейса	Скриншот с подписями: где кнопки, поля, меню	«1 — кнопка «Вход», 2 — поле логина»
5. Основные операции	Пошаговые инструкции	«Как добавить товар: нажмите + → введите название → сохранить»
6. Настройки	Изменение параметров	«Как сменить язык интерфейса»
7. Часто задаваемые вопросы (FAQ)	Типичные проблемы и их решения	«Что делать, если забыл пароль?»
8. Сообщения об ошибках	Список ошибок и их значения	«Ошибка 404 — файл не найден»
9. Глоссарий	Объяснение терминов	«API — способ общения программ»
10. Алфавитный указатель	Быстрый поиск терминов	«Кнопка — 15, Корзина — 23»

Требования к хорошему руководству пользователя (8 правил):

Правило	Что значит	Пример нарушения	Хорошее решение
Простой язык	Без технического жаргона	«Аутентификация не пройдена»	«Неверный логин или пароль»
Много скриншотов	Пользователь видит, что должно быть	Только текст, ни одной картинки	Скриншот каждого окна
Пошаговые инструкции	Нумерованные списки	Абзац текста без номеров	1. Сделай это. 2. Сделай то.
Выделение важного	Внимание, примечание, совет	Всё одинаковым шрифтом	Красное поле, жёлтая рамка
Оглавление	Можно быстро найти раздел	100 страниц без оглавления	Оглавление на первой странице
Алфавитный указатель	Поиск по терминам	Нет	«Корзина — стр. 45»
Актуальность	Соответствует последней версии	Написано про кнопку, которой нет	Обновлять при каждом релизе
Краткость	Не слишком длинно	10 страниц про запуск программы	1 страница про запуск

Онлайн-документация (современный подход):

Платформа	Особенность	Плюсы	Минусы
ReadTheDocs	Бесплатно для Open Source	Автоматическая сборка из Git	Требует настройки
GitHub Wiki	Встроенная вики в репозитории	Просто, бесплатно	Ограниченные возможности
Confluence	Корпоративная вики (от Atlassian)	Мощная, интеграция с Jira	Платная
MkDocs	Markdown → красивый HTML-сайт	Просто, быстро, бесплатно	Требуется хостинг
GitBook	Современный, красивые шаблоны	Удобный интерфейс	Платная (есть бесплатный план)
Notion	База знаний с любым контентом	Очень гибкий, простой	Не специализирован для документации

Как писать хорошие пошаговые инструкции (пример):

Плохая инструкция	Хорошая инструкция
«Чтобы добавить товар, перейдите в каталог, нажмите добавить и заполните форму»	1. Нажмите на кнопку «Каталог» (в левом меню) 2. Нажмите на кнопку «+ Добавить» (в правом верхнем углу) 3. Заполните поля: — Название товара (например, «Молоко») — Цена (только цифры) 4. Нажмите «Сохранить»

Вопрос 67.

Техническая документация

Техническая документация — это документы, которые описывают программу «под капотом»: архитектуру, модули, API, базы данных, алгоритмы. Её читают разработчики, архитекторы, тестировщики, системные администраторы. В отличие от пользовательской документации, техническая документация требует специальных знаний.

Основные виды технической документации:

Вид	Кто читает	Что содержит	Зачем
Архитектурная документация	Архитекторы, ведущие разработчики	Схема компонентов, связи, выбор технологий	Понять общую структуру
Документация по API	Разработчики (клиентов)	Эндпоинты, параметры, ответы, коды ошибок	Интеграция с другими системами
Документация по базе данных	Разработчики, DBA	ER-диаграммы, описание таблиц, индексов	Понимание структуры данных
Руководство программиста	Разработчики (сопровождающие)	Описание модулей, классов, функций, сборка	Сопровождение и доработка
Руководство администратора	Системные администраторы	Установка, настройка, бэкапы, мониторинг	Развёртывание и поддержка
Техническая спецификация	Разработчики, тестировщики	Детальное описание требований (SRS)	Разработка и тестирование
Инфраструктурная документация	DevOps, сисадмины	Серверы, сеть, CI/CD, мониторинг	Эксплуатация

Структура архитектурной документации (по стандарту Arc42):

Раздел	Что содержит	Пример
1. Введение и цели	Зачем этот документ, для кого	«Документ описывает архитектуру интернет-магазина»
2. Ограничения	Технические, бизнес-ограничения	«Должно работать в облаке, бюджет — 1000 $/мес»
3. Контекст системы	Как система взаимодействует с внешним миром	Пользователи, платёжная система, служба доставки
4. Обзор архитектуры	Схема компонентов и их связей	Фронтенд → Бэкенд → БД
5. Сценарии	Главные сценарии использования	Покупка товара, регистрация, поиск
6. Компоненты	Каждый компонент: назначение, интерфейс, зависимости	Модуль оплаты: принимает сумму, возвращает статус
7. Кросс-срезные концепции	Безопасность, логирование, кэширование	Все API используют HTTPS
8. Технологический стек	Какие технологии выбраны и почему	PostgreSQL (надёжность), Redis (кэш)

Структура руководства программиста (что нужно новичку в проекте):

Раздел	Что содержит	Зачем
1. Как собрать проект	Какие команды выполнить	`git clone`, `pip install -r requirements.txt`
2. Как запустить проект локально	Команды для запуска	`python main.py`
3. Структура проекта	Какие папки за что отвечают	`/src` — код, `/tests` — тесты
4. Описание модулей	Каждый модуль: назначение, зависимости	Модуль `auth` — авторизация, зависит от `db`
5. API (внутреннее)	Как вызывать функции в других модулях	`auth.login(username, password)`
6. Схема БД	Таблицы, поля, связи	`users` (id, name, email)
7. Настройка окружения	Переменные окружения, конфиги	`DATABASE_URL=postgresql://...`
8. Как запустить тесты	Команда для тестов	`pytest tests/`
9. Как отлаживать	Советы по отладке	Установка точек останова, логирование
10. Code style	Стандарты оформления	PEP 8

Структура руководства администратора (для системных администраторов):

Раздел	Что содержит	Пример
1. Системные требования	Какое оборудование нужно	4 ядра CPU, 8 ГБ RAM, 100 ГБ SSD
2. Установка	Как развернуть на сервере	Docker, apt-get, systemd
3. Настройка	Переменные окружения, конфигурационные файлы	`config.yml`
4. Запуск и остановка	Как запустить, перезапустить, остановить	`systemctl start myapp`
5. Резервное копирование	Как делать бэкапы, как восстанавливать	`pg_dump` каждую ночь
6. Мониторинг	Какие метрики смотреть, где	Prometheus, Grafana
7. Логирование	Где логи, как их читать, уровни	`/var/log/myapp/`
8. Обновление	Как обновить версию без простоя	Rolling update
9. Устранение неполадок	Типичные проблемы и их решения	«Не стартует — проверьте порт 8080»

Документация API (самая важная для интеграции):

Элемент	Что содержит	Пример
Описание	Что делает API	«API для управления корзиной интернет-магазина»
Эндпоинт	URL и метод	`POST /api/cart/add`
Параметры запроса	Что передать	`{ "product_id": 123, "quantity": 2 }`
Ответ	Что вернёт	`{ "status": "ok", "cart_total": 500 }`
Коды ошибок	Что значит ошибка	`400` — неверные параметры, `404` — товар не найден
Пример	Пример запроса и ответа	`curl -X POST https://...`

Инструменты для создания технической документации:

Инструмент	Для чего	Особенность
Javadoc	Документация из комментариев Java	Генерация HTML
Doxygen	Документация из комментариев (C++, C, Java, Python)	Много языков
Sphinx	Документация для Python	Использует reStructuredText
MkDocs	Документация на Markdown	Простой, красивый
Swagger (OpenAPI)	Документация REST API	Интерактивная (можно отправлять запросы)
PlantUML	UML-диаграммы из текста	Диаграммы как код
Draw.io / diagrams.net	Схемы, диаграммы	Бесплатно, онлайн

Вопрос 68.

Руководство пользователя

Руководство пользователя — это основной документ, который объясняет конечному пользователю, как пользоваться программой. Оно может быть в виде PDF, печатной книги, встроенной справки или веб-сайта. Хорошее руководство пользователя должно быть написано простым языком, содержать много скриншотов и пошаговых инструкций.

Требования к руководству пользователя (по стандарту ISO/IEC 26514):

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

Пример хорошего описания функции в руководстве пользователя:

«Как добавить товар в корзину:

На главной странице найдите нужный товар (можно использовать поиск в верхней части экрана).
Нажмите на кнопку «Купить» под картинкой товара.
После этого товар появится в корзине. Чтобы увидеть корзину, нажмите на иконку корзины в правом верхнем углу (она выглядит как тележка).
Если вы хотите изменить количество товара, нажмите на цифру рядом с товаром и введите новое число.

Примечание: Если товар закончился на складе, кнопка «Купить» будет серой и неактивной.»

Различия между руководством пользователя и другими документами:

Документ	Для кого	Объём	Стиль	Примеры
Руководство пользователя	Конечные пользователи	50-500 страниц	Простой, пошаговый	«Нажмите кнопку «Вход»»
Руководство администратора	Сисадмины	30-200 страниц	Технический	«Настройте переменную окружения DB_HOST»
README	Все (кратко)	1-5 страниц	Краткий, сухой	«Склонируйте репозиторий, запустите main.py»
FAQ	Пользователи с проблемами	5-20 вопросов	Вопрос-ответ	«Что делать, если забыл пароль?»
Видеоуроки	Визуалы	1-10 минут видео	Демонстрационный	«Смотрим, как оформить заказ»

Вопрос 69.

Руководство программиста

Краткая теория: Руководство программиста (иногда называют «техническое руководство» или «разработчик-документация») — это документ для разработчиков, которые будут сопровождать или дорабатывать программу. В отличие от руководства пользователя, оно описывает внутреннее устройство программы, а не то, как ей пользоваться.

Зачем нужно руководство программиста (4 причины):

Причина	Объяснение
Смена команды	Пришли новые разработчики — прочитали и быстро вошли в курс
Сопровождение через год	Автор забыл, как работает код, который сам написал
Передача проекта другому подрядчику	Новая команда понимает, куда смотреть
Большая команда	Распределение работы между модулями

Структура руководства программиста (основные разделы):

Раздел	Что содержит	Вопросы, на которые отвечает
1. Обзор системы	Назначение, архитектура, основные компоненты	«Из каких частей состоит система?»
2. Сборка и запуск	Как скомпилировать, собрать, запустить локально	«Как запустить проект у себя?»
3. Структура проекта	Папки, файлы, их назначение	«Где лежит модуль авторизации?»
4. Описание модулей	Каждый модуль: назначение, интерфейс, зависимости	«Что делает этот модуль? От чего зависит?»
5. Описание классов/функций	Ключевые классы, их методы, параметры	«Как вызвать функцию расчёта цены?»
6. Схема базы данных	ER-диаграмма, описание таблиц и полей	«Где хранится email пользователя?»
7. API	Внутренние и внешние API, параметры, ответы	«Как получить список товаров?»
8. Настройка окружения	Переменные окружения, конфигурационные файлы	«Как поменять порт сервера?»
9. Тестирование	Как запустить тесты, как написать новый тест	«Как проверить, что я ничего не сломал?»
10. Отладка	Инструменты, методы, логирование	«Как найти причину ошибки?»
11. Внесение изменений	GitFlow, правила code review	«Как добавить новую функцию?»

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

«Модуль cart (корзина) отвечает за управление корзиной покупок.

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

Зависимости:

Модуль db — для сохранения корзины в базу данных
Модуль auth — для получения ID текущего пользователя

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

add_item(user_id, product_id, quantity) — добавить товар в корзину
remove_item(user_id, product_id) — удалить товар из корзины
get_cart(user_id) — получить текущее содержимое корзины
clear_cart(user_id) — очистить корзину

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

Примечание: При добавлении товара проверяется, есть ли он на складе. Если товара нет, возвращается ошибка «Товар временно отсутствует».»

Кто пишет руководство программиста:

Роль	Что пишет	Почему
Разработчик	Описание своих модулей	Только он знает детали
Ведущий разработчик	Общую архитектуру, сборку	Он видит всю картину
Технический писатель	Редактирование, стандартизация	Профессионально оформляет
DevOps	Раздел про сборку и деплой	Он настраивал CI/CD

Альтернативы руководству программиста (современные подходы):

Подход	Как работает	Плюсы	Минусы
Самодокументируемый код	Понятные имена, небольшие функции, комментарии по делу	Всегда актуально	Требует дисциплины
Документация из комментариев	Javadoc, Doxygen генерируют HTML	Автоматически	Надо писать комментарии
Вики	Confluence, GitHub Wiki	Легко редактировать	Может устареть
Диаграммы как код	PlantUML, Mermaid (диаграммы в текстовом виде)	Хранятся в Git, версионируются	Требует инструментов

Вопрос 70.

Сопровождение программного обеспечения

Сопровождение ПО — это этап жизненного цикла, который начинается после передачи программы пользователям и длится до её полного отключения. Это самая длительная и дорогая фаза (до 70-80% от общих затрат на ПО). Сопровождение включает исправление ошибок, адаптацию к новым условиям, добавление новых функций и улучшение производительности.

Почему сопровождение такое дорогое (основные причины):

Причина	Объяснение
Долгий срок жизни	Программа может эксплуатироваться 10-20 лет
Накопление технического долга	Недоделки и костыли требуют исправлений
Изменение окружения	Выходят новые ОС, браузеры, версии БД
Рост нагрузки	Пользователей становится больше, чем планировали
Новые требования	Бизнес меняется, нужны новые функции

Четыре вида сопровождения (по ISO/IEC 12207):

Вид	Что значит	Пример	% от времени
Корректирующее	Исправление ошибок, найденных после релиза	«Упала кнопка «Купить» при нулевой цене»	20%
Адаптивное	Адаптация под новое окружение	«Обновили Windows — программа перестала работать»	25%
Совершенствующее	Добавление новых функций	«Заказчик попросил добавить скидочные купоны»	50%
Профилактическое	Рефакторинг, улучшение без изменения поведения	«Переписали старый модуль, чтобы он работал быстрее»	5%

Подробно о каждом виде сопровождения:

1. Корректирующее сопровождение (исправление ошибок):

Тип ошибок	Пример	Сложность	Приоритет
Критические (Blocker)	Программа не запускается	Средняя	Высший
Логические ошибки	Калькулятор неправильно считает	Высокая	Высокий
Ошибки интерфейса	Кнопка съехала влево	Низкая	Низкий
Ошибки производительности	Страница грузится 10 секунд	Высокая	Средний
Ошибки безопасности	Пароли хранятся в открытом виде	Высокая	Высший

2. Адаптивное сопровождение (подстройка под окружение):

Изменение окружения	Что нужно делать	Пример
Обновление ОС	Проверить совместимость, исправить ошибки	Windows 10 → Windows 11
Обновление СУБД	Обновить драйверы, исправить запросы	PostgreSQL 12 → 15
Обновление браузера	Исправить CSS/JS, устаревшие API	Chrome 100 → 120
Обновление железа	Новые процессоры, больше ядер	Оптимизировать под многопоточность
Изменение законов	Новые требования к хранению персональных данных	Добавить согласие на обработку данных

3. Совершенствующее сопровождение (новые функции):

Тип доработки	Пример	Отличие от новой разработки
Новая функция	Добавить кнопку «Поделиться»	Делается поверх существующей системы
Улучшение существующей	Ускорить поиск	Меняем код, не меняя интерфейс
Интеграция с новой системой	Подключить новый платёжный шлюз	Добавляем модуль
Улучшение интерфейса	Сделать адаптивную вёрстку	Меняем только внешний вид

4. Профилактическое сопровождение (рефакторинг):

Действие	Что значит	Пример
Рефакторинг	Переписываем код, не меняя поведение	Разбить большую функцию на маленькие
Обновление зависимостей	Поднять версии библиотек	Обновить устаревшую библиотеку
Улучшение тестов	Добавить недостающие тесты	Написать тесты для старого кода
Улучшение документации	Обновить устаревшие разделы	Дописать комментарии к сложным местам

Процесс сопровождения (как устроен):

Этап	Что делаем	Кто делает
1. Поступление запроса	Пользователь сообщает об ошибке или просит новую функцию	Пользователь, менеджер
2. Анализ запроса	Оцениваем сложность, приоритет, влияние на систему	Аналитик, разработчик
3. Планирование	Если запрос одобрен — включаем в план следующего релиза	Менеджер
4. Реализация	Пишем код, тесты, документацию	Разработчик
5. Тестирование	Проверяем, что исправили, и ничего не сломали	Тестировщик
6. Релиз	Выкатываем новую версию	DevOps
7. Мониторинг	Следим, не появились ли новые ошибки	Все

Типичные проблемы сопровождения и их решения:

Проблема	Проявление	Решение
Отсутствие документации	Непонятно, как устроен код	Документировать по ходу исправления
Нет тестов	Исправление одной ошибки порождает три новые	Писать тесты перед исправлением
Устаревшие технологии	Библиотека больше не поддерживается	Плановый рефакторинг (миграция)
Высокая связанность	Любое изменение затрагивает 10 модулей	Рефакторинг, снижение связанности
Текучесть команды	Нет знающих людей	Документация, парное программирование

Сравнение разработки и сопровождения (таблица):

Характеристика	Разработка новой версии	Сопровождение существующей
Длительность	Месяцы — годы	Годы — десятилетия
Риски	Высокие (новая технология)	Низкие (известная система)
Требования	Меняются (Agile)	Стабильные (бизнес-процессы)
Команда	Специалисты высокой квалификации	Поддержка (включая новичков)
Бюджет	20-30% от общего	70-80% от общего
Интерес	Создание нового	Рутина, исправление чужих ошибок

Вопрос 71.

Виды сопровождения программного обеспечения

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

Детальная таблица видов сопровождения (с примерами и инструментами):

Вид	Что делаем	Пример	Инструменты	Кто отвечает
Корректирующее	Исправляем ошибки	«При оформлении заказа падает ошибка 500»	Баг-трекер (Jira), отладчик (GDB)	Команда поддержки, разработчики
Адаптивное	Подстраиваем под новое окружение	«Обновили PostgreSQL с 11 на 14»	CI/CD, Docker, тестовые стенды	DevOps, разработчики
Совершенствующее	Добавляем новые функции	«Добавить кнопку экспорта в Excel»	Git (ветки), CI/CD, Jira	Разработчики, аналитики
Профилактическое	Улучшаем без изменения поведения	«Переписать старый модуль на новый фреймворк»	Рефакторинг, тесты, линтеры	Разработчики

Как организовать корректирующее сопровождение (процесс):

Шаг	Действие	Время
1	Пользователь сообщает об ошибке (через форму, email, телефон)	5 минут
2	Техподдержка проверяет: действительно ли ошибка	15 минут
3	Создаётся баг в Jira (с приоритетом, описанием, шагами)	10 минут
4	Разработчик берёт баг в работу	1 минута
5	Разработчик воспроизводит ошибку локально	30 минут — 2 часа
6	Исправляет ошибку	1 час — 2 дня
7	Пишет тест, который ловит эту ошибку	30 минут
8	Открывает Pull Request	5 минут
9	Code review, тестирование	2 часа — 1 день
10	Релиз (выкатка на сервер)	30 минут
11	Закрытие бага, уведомление пользователя	5 минут

Типы ошибок по срочности (слайды):

Приоритет	Название	Пример	Максимальное время исправления
P0	Blocker	Программа не запускается	1 час
P1	Critical	Не работает оплата	4 часа
P2	Major	Ошибка в отчёте (но отчёт можно обойти)	2 дня
P3	Minor	Неправильный цвет кнопки	1 неделя
P4	Trivial	Опечатка в подсказке	1 месяц (или не исправлять)

Как организовать адаптивное сопровождение (пример):

Событие	Действия	Кто делает
Выход новой версии Windows	Проверить программу на Windows 11	Тестировщик
Найдены проблемы (10 ошибок)	Завести баги, расставить приоритеты	Тестировщик
Исправление ошибок	Разработчики исправляют	Разработчики
Сборка под новую ОС	Настроить CI под Windows 11	DevOps
Релиз	Выпустить обновление	DevOps

Как организовать совершенствующее сопровождение (добавление новых функций):

Шаг	Действие	Особенность
1	Сбор требований на новую функцию	Общаться с пользователями
2	Оценка влияния на существующую систему	Не сломаем ли старое?
3	Проектирование (как вписать новую функцию в старую архитектуру)	Без рефакторинга всей системы
4	Реализация в отдельной ветке	Не мешать другим
5	Тестирование (функциональное + регрессионное)	Проверить, что старое работает
6	Релиз вместе с другими исправлениями	Обычно раз в месяц

Как организовать профилактическое сопровождение (рефакторинг):

Шаг	Действие	Риски
1	Анализ «запахов кода» (code smells)	Можно пропустить важное
2	Планирование рефакторинга (отдельная ветка)	Уходит время от новых функций
3	Изменение кода без изменения поведения	Легко сломать что-то неожиданное
4	Запуск всех тестов	Должно быть зелёное покрытие
5	Code review	Коллеги проверяют
6	Слияние	Не влиять на другие задачи

Кто отвечает за сопровождение (роли и обязанности):

Роль	Обязанности по сопровождению
Менеджер поддержки	Приоритизация запросов, общение с заказчиком
Техподдержка (1 линия)	Приём сообщений, первичная диагностика
Техподдержка (2 линия)	Воспроизведение ошибок, создание багов в Jira
Разработчик	Исправление ошибок, добавление функций
Тестировщик	Проверка исправлений, регрессионное тестирование
DevOps	Релизы, обновление окружения
Аналитик	Анализ новых требований (для совершенствующего)

Метрики сопровождения (как измерить эффективность):

Метрика	Что измеряет	Формула	Хорошее значение
MTTR (Mean Time To Repair)	Среднее время исправления	Сумма времени на все баги / количество багов	< 24 часа для критических
Количество багов на релиз	Качество кода	Подсчёт	< 10 критических в месяц
Удовлетворённость пользователей	Как пользователи оценивают поддержку	Опрос	> 4.5 из 5
Время реакции на заявку	Как быстро ответили	От заявки до первого ответа	< 1 часа (рабочее время)
Пропускная способность команды	Сколько багов/функций сделано за месяц	Подсчёт	Зависит от команды

Вопрос 72.

Модификация и обновление программного продукта

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

Виды обновлений по масштабу:

Тип	Что меняется	Как меняется номер версии	Пример
Минорное	Исправление ошибок, мелкие улучшения	1.0 → 1.1	Исправлен баг с ценой
Мажорное (крупное)	Новые функции, изменения интерфейса	1.9 → 2.0	Добавлен модуль отчетов
Патч (срочное)	Исправление критической ошибки	1.0.1 (третья цифра)	Исправлена уязвимость
Сервис-пак	Набор исправлений и улучшений	Windows SP1, SP2	Множество исправлений

Семантическое версионирование (SemVer — стандарт):

Формат: MAJOR.MINOR.PATCH

Компонент	Когда увеличивается	Пример
MAJOR	Несовместимые изменения API	2.0.0 (переход с 1.x.x на 2.x.x)
MINOR	Добавлена новая функция (обратно совместимо)	1.2.0 (добавлена новая функция, старые работают)
PATCH	Исправлены ошибки (обратно совместимо)	1.1.5 (исправлены баги)

Пример жизненного цикла версий:

Версия	Что изменилось	Тип
1.0.0	Первый релиз	—
1.0.1	Исправлен баг с авторизацией	Пэтч
1.1.0	Добавлена функция поиска	Минор
1.1.1	Исправлены мелкие ошибки	Пэтч
1.2.0	Добавлен экспорт в Excel	Минор
2.0.0	Переход на новую архитектуру (несовместимо)	Мажор

Стратегии обновления (как доставлять изменения пользователям):

Стратегия	Что значит	Плюсы	Минусы	Пример
Автоматическое	Программа сама скачивает и устанавливает обновления	Пользователь не думает, всегда свежая версия	Может сломаться без спроса	Chrome, Windows
Уведомление	Программа сообщает о новом обновлении, пользователь решает	Пользователь контролирует	Некоторые не обновляются годами	Игры в Steam
Принудительное	Без обновления программа не работает	100% актуальная версия	Злые пользователи	Некоторые банковские приложения
Ручное	Пользователь сам скачивает с сайта	Полный контроль	Многие не обновляются, старые версии с багами	Устаревшее ПО

Как обновляют серверные приложения (без остановки работы):

Метод	Что значит	Риски
Остановка и обновление	Останавливаем сервер, обновляем, запускаем	Время простоя (пользователи не могут работать)
Blue-Green развёртывание	Два идентичных сервера: «синий» работает, «зелёный» обновляем, потом переключаем	Дорого (два сервера)
Rolling update	Обновляем серверы по очереди (один перезапустили, другие работают)	Сложность, версии разные одновременно
Canary развёртывание	Сначала обновляем 1% серверов, проверяем, потом все	Долго, сложно

Что входит в релиз новой версии (пакет обновления):

Компонент	Что содержит	Зачем
Исполняемые файлы	Обновлённые .exe, .dll, .so	Сама программа
Миграции базы данных	Скрипты изменения структуры БД	Не потерять данные
Конфигурационные файлы	Новые настройки по умолчанию	Новые параметры
Документация	Обновлённое руководство	Пользователь знает о новом
Релизные заметки	Что нового, что исправлено	Пользователь понимает изменения

Релизные заметки (Release Notes) — пример содержания:

«Версия 2.1.0 (выпущена 15.06.2024)

Новые возможности:

Добавлен экспорт отчётов в Excel (спасибо Ивану за предложение)
Добавлена фильтрация товаров по цене
Улучшен поиск (стал на 30% быстрее)

Исправленные ошибки:

Исправлен баг с нулевой ценой товара
Исправлено падение при открытии корзины (спасибо пользователю Николаю за сообщение)
Устранена утечка памяти в модуле отчётов

Известные проблемы:

При большом количестве товаров (> 100 000) фильтрация работает медленно (исправим в следующей версии)»

Вопрос 73.

Оптимизация программного обеспечения

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

Когда нужна оптимизация (признаки):

Признак	Что значит	Что измерять
Программа тормозит	Долго реагирует на действия	Время отклика
Программа «жрёт» память	Занимает гигабайты оперативной памяти	Объём RAM
Программа нагружает CPU	Процессор работает на 100% постоянно	Загрузка CPU
Программа медленно загружается	Старт занимает минуты	Время запуска
Много жалоб пользователей	«Что-то у вас всё медленно»	Опросы, поддержка

Виды оптимизации (по чему оптимизируем):

Вид	Что улучшаем	Инструменты измерения	Пример
По скорости	Время выполнения операций	Профилировщик (cProfile, Py-Spy)	Сократить время поиска с 5 секунд до 0.5
По памяти	Объём оперативной памяти	Valgrind, heap profiler	Уменьшить потребление с 500 МБ до 50 МБ
По CPU	Загрузка процессора	top, htop, Activity Monitor	Снизить загрузку с 90% до 20%
По диску	Количество обращений к диску	iostat, perf	Уменьшить число чтений с диска
По сети	Объём передаваемых данных	Wireshark, Netmon	Сжать ответы API с 10 МБ до 1 МБ
По энергопотреблению	Сколько энергии тратит программа (мобильные устройства)	Battery profiler (Android)	Увеличить время работы от батареи

Три золотых правила оптимизации:

Правило	Что значит	Почему
Не оптимизируй преждевременно	Сначала сделай работающую версию, потом оптимизируй	Можно потратить время на то, что не нужно
Измеряй перед оптимизацией	Сначала измерь, где узкое место, затем оптимизируй	Без измерений оптимизируешь не то
Измеряй после оптимизации	Проверь, стало ли лучше (иногда становится хуже)	Ошибки в оптимизации

Типичные узкие места (что чаще всего тормозит):

№	Узкое место	Почему тормозит	Типичное улучшение
1	База данных (запросы)	Нет индексов, сложные JOIN, много запросов	Добавить индексы, оптимизировать запросы, кэшировать
2	Сеть (API)	Медленный интернет, большие объёмы данных	Сжимать ответы, уменьшить количество запросов
3	Диск (ввод-вывод)	Чтение/запись файлов медленнее памяти	Кэшировать, использовать память
4	Алгоритмы (сложность)	O(n²) вместо O(n log n)	Заменить алгоритм на более эффективный
5	Визуализация (интерфейс)	Перерисовка экрана слишком часто	Уменьшить перерисовки, виртуализация
6	Многопоточность	Блокировки (locks), ожидания (deadlock)	Уменьшить блокировки, асинхронный код

Алгоритмическая оптимизация (самая эффективная):

Сложность	Название	Пример	1 000 элементов	1 000 000 элементов
O(1)	Константная	Доступ по индексу	1 мс	1 мс
O(log n)	Логарифмическая	Бинарный поиск	10 мс	20 мс
O(n)	Линейная	Простой поиск	1 000 мс	1 000 000 мс
O(n log n)	Линейно-логарифмическая	Быстрая сортировка	10 000 мс	20 000 000 мс
O(n²)	Квадратичная	Пузырьковая сортировка	1 000 000 мс	10¹² мс (годы)

Профилирование — поиск узких мест (как делать):

Шаг	Действие	Что узнаём
1	Запустить программу под профилировщиком	Где программа проводит больше всего времени
2	Смотреть топ функций по времени	Какая функция самая медленная
3	Смотреть топ функций по количеству вызовов	Какая функция вызывается слишком часто
4	Смотреть использование памяти	Есть ли утечки, какие объекты занимают больше всего
5	Принять решение, что оптимизировать	Начинаем с самой нагруженной функции

Пример результата профилирования (текстовое описание):

«Профилирование показало, что 80% времени программа тратит на функцию search_products(). Внутри этой функции 70% времени уходит на базу данных, 30% — на обработку результатов. Оптимизация запроса к БД может дать наибольший эффект.»

Что делать после профилирования (стратегия):

Приоритет	Действие	Ожидаемый эффект
1	Оптимизировать самый медленный запрос к БД (добавить индекс)	Ускорение в 10-100 раз
2	Уменьшить количество запросов (объединить несколько в один)	Ускорение в 2-10 раз
3	Добавить кэш для часто запрашиваемых данных	Ускорение в 10-1000 раз для кэшируемых операций
4	Оптимизировать алгоритм (O(n²) → O(n log n))	Ускорение в 10-100 раз
5	Оптимизировать код на микроуровне (последнее, когда всё остальное сделано)	Ускорение в 1.1-2 раза

Типичные ошибки при оптимизации (чего делать не надо):

Ошибка	Что делают	Почему плохо
Ранняя оптимизация	Оптимизируют код до того, как написан работающий прототип	Тратят время на неважное
Оптимизация без измерений	«Кажется, это медленно, давай перепишем»	Может быть, это и не узкое место
Оптимизация читаемости	Код стал быстрым, но непонятным	Трудно поддерживать, много багов
Микро-оптимизация	Меняют `x + y` на `x - (-y)`	Выигрыш 0.0001%, код стал нечитаемым

Вопрос 74.

Надёжность программного обеспечения

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

Основные характеристики надёжности (по стандарту ISO 25010):

Характеристика	Что значит	Как измерить	Пример
Безотказность	Не падает при нормальной работе	Количество сбоев за час работы	0 сбоев за 1000 часов
Устойчивость к ошибкам	Не падает при некорректном вводе	Как программа реагирует на неверные данные	При пустом пароле — сообщение, а не падение
Восстанавливаемость	Может восстановиться после сбоя	Время восстановления (MTTR)	Восстановление за 15 минут
Доступность	Работает нужный процент времени	(Время работы) / (Общее время) × 100%	99.99% доступности
Зрелость	Как долго программа работает без изменений	Количество ошибок, найденных после релиза	5 ошибок за первый месяц

Количественные метрики надёжности:

Метрика	Что измеряет	Формула	Хорошее значение
MTBF (Mean Time Between Failures)	Среднее время между сбоями	Суммарное время работы / Количество сбоев	> 1000 часов
MTTR (Mean Time To Recovery)	Среднее время восстановления	Суммарное время простоя / Количество сбоев	< 30 минут
Доступность	Процент времени, когда система работает	MTBF / (MTBF + MTTR) × 100%	99.9% («три девятки»)
Интенсивность отказов (λ)	Количество отказов в единицу времени	Количество отказов / Время	< 0.001 в час
Вероятность безотказной работы	Шанс, что система не откажет за время t	exp(-λ × t)	> 0.999 за 100 часов

Уровни доступности (сколько времени можно не работать):

Доступность	«Девятки»	Время простоя в год	Для каких систем
99%	две девятки	3.65 дня (87.6 часа)	Внутренние системы
99.9%	три девятки	8.76 часа	Обычные сервисы
99.99%	четыре девятки	52.56 минуты	Платёжные системы
99.999%	пять девяток	5.26 минуты	Телефония, критическая инфраструктура
99.9999%	шесть девяток	31.5 секунды	Космос, АЭС

Факторы, влияющие на надёжность ПО:

Фактор	Как влияет	Что делать
Сложность кода	Чем сложнее, тем больше ошибок	Упрощать, разбивать на модули
Качество тестирования	Чем лучше тесты, тем надёжнее	Писать тесты, использовать TDD
Обработка ошибок	Если ошибки не обрабатываются — программа падает	Обрабатывать все возможные исключения
Нагрузка	Под нагрузкой могут проявляться скрытые ошибки	Нагрузочное тестирование
Внешние зависимости	Если БД упала — программа упала	Резервирование, retry-механизмы
Количество пользователей	С ростом числа пользователей растёт число ошибок	Масштабирование, нагрузочное тестирование

Способы повышения надёжности (основные):

Способ	Что значит	Пример
Резервирование (redundancy)	Дублирование критических компонентов	Два сервера БД (основной и реплика)
Автоматическое восстановление	При сбое система перезапускается сама	Supervisor, systemd, Kubernetes
Graceful degradation	При отказе части функций, остальные продолжают работать	Если не работает поиск, товары всё равно видны
Failover (переключение на резерв)	При сбое автоматически переходим на резервный сервер	Балансировщик переключает трафик
Heartbeat (контроль жизнеспособности)	Программа периодически сообщает «я жива»	Мониторинг, health check
Retry (повтор)	При временном сбое повторить операцию	Повтор запроса к БД через 1 секунду

Что такое отказоустойчивость (fault tolerance):

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

Примеры отказоустойчивых архитектур:

Архитектура	Что делает	Пример
Репликация БД	Несколько копий базы данных	Master-Slave (один пишет, много читают)
Кластеризация	Несколько серверов работают как один	Load balancer распределяет нагрузку
Sharding	Данные разбиты на части, каждая на своём сервере	Упадёт один шард — потеряется часть данных
Асинхронные очереди	Задачи ставятся в очередь, обрабатываются постепенно	Очередь RabbitMQ

Вопрос 75.

Производительность программного обеспечения

Производительность ПО — это скорость выполнения операций и способность обрабатывать определённый объём работы за единицу времени. Это одна из ключевых нефункциональных характеристик. Низкая производительность делает программу неудобной, даже если все функции работают правильно. Пользователь не будет ждать 10 секунд загрузки страницы.

Основные метрики производительности:

Метрика	Что измеряет	Как измерить	Хорошее значение
Время отклика (Response Time)	Время от отправки запроса до получения ответа	Засечь время	< 200 мс для API
Время загрузки страницы (Page Load Time)	Полная загрузка страницы в браузере	Chrome DevTools, Lighthouse	< 2 секунд
Пропускная способность (Throughput)	Количество операций в секунду	Количество запросов / время	> 1000 RPS
Задержка (Latency)	Время одного запроса (без обработки)	Время в сети	< 50 мс
TTFB (Time To First Byte)	Время до первого байта ответа	Засечь	< 100 мс
Время запуска (Startup Time)	Время от клика до готовности программы	Засечь	< 5 секунд

Факторы, влияющие на производительность:

Фактор	Как влияет	Что можно сделать
Алгоритмы	Плохой алгоритм (O(n²)) может быть очень медленным	Выбрать эффективный алгоритм (O(n log n))
База данных	Медленные запросы, отсутствие индексов	Добавить индексы, оптимизировать запросы
Сеть	Медленный интернет, большие объёмы данных	Сжимать данные, уменьшить количество запросов
Память	Нехватка памяти → подкачка на диск (очень медленно)	Увеличить память, оптимизировать использование
Диск (I/O)	Медленные операции чтения/записи	Использовать SSD, кэшировать в памяти
Многопоточность	Блокировки (locks), гонки	Уменьшить блокировки, использовать асинхронность
Визуализация	Частые перерисовки экрана	Виртуализация списков, отложенная загрузка

Методы улучшения производительности (от самых эффективных к наименее):

Метод	Что делает	Ожидаемое улучшение	Сложность
Кэширование	Храним часто используемые данные в быстрой памяти	10-1000 раз	Средняя
Асинхронность	Не ждём медленные операции, делаем их в фоне	2-10 раз	Средняя
Оптимизация БД	Индексы, нормализация, оптимизация запросов	10-100 раз	Средняя
Сжатие данных	Уменьшаем объём передаваемых данных	2-10 раз	Низкая
Оптимизация алгоритмов	Меняем O(n²) на O(n log n)	10-100 раз	Высокая
Микрооптимизации	Мелкие улучшения в коде	1.1-2 раза	Низкая

Что такое кэширование и как оно работает:

Тип кэша	Где хранится	Время доступа	Пример использования
Кэш в памяти (RAM)	Оперативная память	100 нс	Redis, Memcached
Кэш на диске	SSD/HDD	100 000 нс (в 1000 раз медленнее памяти)	Браузерный кэш
CDN (Content Delivery Network)	Серверы по всему миру	Зависит от географии	Статические файлы (картинки, CSS)
Кэш браузера	Жёсткий диск пользователя	100 000 нс	Картинки, CSS, JS

Пример эффекта от кэширования:

Ситуация	Время ответа	Ускорение
Без кэша (запрос к БД, сложный JOIN)	500 мс	1×
С кэшем (данные уже в памяти)	5 мс	100×

Что такое асинхронность и параллелизм:

Подход	Что значит	Когда использовать	Пример
Синхронный (последовательный)	Делаем A, ждём, делаем B, ждём	Простые сценарии	Чтение файла, потом его обработка
Асинхронный (неблокирующий)	Запустили A, не ждём, делаем B, когда A готов — обрабатываем	Операции ввода-вывода (сеть, диск)	Загружаем несколько картинок параллельно
Параллельный (многопоточный)	Несколько операций выполняются одновременно на разных ядрах CPU	Вычислительные задачи	Обработка большого массива данных по частям

Профилирование производительности (поиск узких мест):

Инструмент	Для чего	Что показывает
cProfile (Python)	Профилирование CPU	Какая функция сколько времени заняла
Py-Spy (Python)	Профилирование без остановки программы	График, где программа тратит время
Valgrind (C/C++)	Профилирование памяти, утечки	Где выделена память, где утечка
Chrome DevTools	Профилирование веб-приложений	Время загрузки, время рендеринга
VisualVM (Java)	Профилирование JVM	Память, потоки, CPU
Grafana + Prometheus	Мониторинг в реальном времени	Текущая нагрузка, тренды

Как интерпретировать результаты профилирования (пример):

Функция	Время (сек)	% от общего	Количество вызовов	Что делать
`get_products_from_db`	45.2	75%	100	Оптимизировать запрос, добавить индекс
`render_product_list`	10.1	17%	100	Виртуализация списка
`parse_user_input`	3.5	6%	10 000	Микрооптимизации (не критично)

Типичные ошибки при оптимизации производительности:

Ошибка	Пример	Правильно
Оптимизация без измерений	«Кажется, этот цикл медленный, перепишем»	Сначала измерить профилировщиком
Ранняя оптимизация	Оптимизируем код, пока программа ещё не написана	Сделать работающую версию, потом оптимизировать
Микрооптимизация главного узла	Меняем `x++` на `++x` (экономия 0.0001%), а БД не трогаем	Оптимизировать БД (может дать 1000%)
Оптимизация читаемости	Код стал быстрым, но непонятным	Оптимизировать только критичные места

Вопрос 76.

Безопасность программного обеспечения

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

Основные угрозы безопасности ПО:

Угроза	Что делает злоумышленник	Пример	Как защититься
Несанкционированный доступ	Получает доступ к данным, к которым не должен	Подбор пароля	Двухфакторная аутентификация
SQL-инъекция	Вставляет SQL-код в поле ввода, чтобы украсть данные	`' OR '1'='1` в поле входа	Параметризованные запросы
XSS (межсайтовый скриптинг)	Вставляет вредоносный JavaScript на страницу	`«<script>alert(1)</script>»` в комментарий	Экранирование вывода
CSRF (подделка запроса)	Заставляет пользователя выполнить действие без его ведома	Переход по ссылке «Сменить пароль»	CSRF-токены
Переполнение буфера	Пишет данные за пределами выделенной памяти	Длинная строка ломает программу	Контроль границ, безопасные языки
Подделка данных	Изменяет данные при передаче	Изменить цену товара в запросе	Шифрование, подписи
Отказ в обслуживании (DoS)	Перегружает сервер запросами, чтобы он упал	Тысячи запросов в секунду	Rate limiting, WAF
Перехват трафика	Слушает сеть, крадёт пароли	Wi-Fi в кафе	Шифрование (HTTPS)
Утечка данных	Ошибка в конфигурации раскрывает данные	S3-бакет с открытым доступом	Проверка конфигурации
Социальная инженерия	Обманывает человека, чтобы тот выдал пароль	Звонок от «техподдержки»	Обучение сотрудников

Три основных принципа безопасности (CIA Triad):

Принцип	Что значит	Пример нарушения	Защита
Конфиденциальность (Confidentiality)	Доступ к данным только у тех, у кого есть право	Пароль хранится в открытом виде	Шифрование, контроль доступа
Целостность (Integrity)	Данные не могут быть изменены без разрешения	Злоумышленник изменил цену товара	Контрольные суммы, подписи
Доступность (Availability)	Данные доступны, когда они нужны	DoS-атака, сервер упал	Резервирование, защита от DoS

Что такое аутентификация и авторизация (разница):

Понятие	Что значит	Пример	Ошибка
Аутентификация	Проверка, что пользователь — это тот, за кого себя выдаёт	Ввод логина и пароля	Слабая аутентификация (только пароль)
Авторизация	Проверка, есть ли у пользователя право на действие	Проверка, что пользователь — администратор	Ошибка: пользователь может видеть чужие заказы

Лучшие практики безопасности (что нужно делать обязательно):

Практика	Что значит	Пример
Шифрование в покое	Хранить данные в зашифрованном виде	Пароли хранить только хешированными (bcrypt)
Шифрование при передаче	Передавать данные только по зашифрованным каналам	HTTPS, TLS 1.3
Минимизация привилегий	Давать пользователю ровно столько прав, сколько нужно	Пользователь может читать свои заказы, но не чужие
Валидация ввода	Проверять все данные, которые приходят от пользователя	Не доверять полю «id», проверять, что это число
Экранирование вывода	Защищать от XSS	`«<script»` → `<script>`
Безопасная работа с БД	Использовать параметризованные запросы	`SELECT * FROM users WHERE id = $1`
Логирование действий	Записывать важные действия (логины, удаления)	Записать «Пользователь admin удалил запись №123»
Обновление зависимостей	Регулярно обновлять библиотеки, чтобы не было известных уязвимостей	Обновить библиотеку с уязвимостью CVE-2024-1234

Что такое уязвимость и как её ищут:

Этап	Что делают	Результат
1	Сканирование портов	Узнаём, какие сервисы работают
2	Автоматический сканер уязвимостей (Nessus, OpenVAS)	Список известных уязвимостей
3	Ручной пентест (этичный взлом)	Неизвестные уязвимости
4	Анализ кода (статический)	Поиск потенциальных проблем в коде
5	Анализ кода (динамический)	Запуск программы с тестами безопасности

Примеры известных уязвимостей (из реальной жизни):

Название	Что было	Как исправили
Heartbleed (2014)	Утечка памяти в OpenSSL	Обновить OpenSSL
Log4Shell (2021)	Уязвимость в библиотеке Log4j (Java)	Обновить Log4j
Spectre/Meltdown (2018)	Аппаратные уязвимости процессоров	Микрокод, патчи ОС
Spring4Shell (2022)	Уязвимость в Spring Framework (Java)	Обновить Spring

OWASP Top 10 (10 главных угроз для веб-приложений — актуальный список 2021):

№	Угроза	Краткое описание
1	Нарушение контроля доступа	Пользователь видит чужие данные
2	Криптографические ошибки	Пароли хранятся небезопасно
3	Инъекции (SQL, NoSQL, LDAP)	Злоумышленник вставляет вредоносный код
4	Небезопасная конфигурация	Стандартные пароли, лишние порты
5	Уязвимости аутентификации	Слабые пароли, сессии не защищены
6	Межсайтовый скриптинг (XSS)	Внедрение JavaScript на страницу
7	Уязвимости компонентов	Старые библиотеки с уязвимостями
8	Ошибки при логировании	Не логгируем важные действия
9	SSRF (Server-Side Request Forgery)	Сервер делает запросы туда, куда не надо
10	Подделка запросов (CSRF)	Пользователь выполняет действие без ведома

Что делать, если уязвимость найдена (процесс):

Шаг	Действие	Срок
1	Подтвердить уязвимость (воспроизвести)	1 час
2	Оценить критичность (Blocker/Critical/Major)	1 час
3	Найти исправление (патч, изменение кода)	1 день
4	Исправить в отдельной ветке (hotfix)	1 день
5	Протестировать исправление	1 день
6	Выпустить срочный релиз (патч)	1 час
7	Уведомить пользователей (если нужно)	1 час

Вопрос 77.

Защита информации в программных системах

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

Уровни защиты информации (4 уровня):

Уровень	Что защищает	Примеры мер
Законодательный	Правовые нормы	Закон «О персональных данных» (152-ФЗ)
Организационный	Процессы и людей	Договор о неразглашении, пропускная система
Аппаратный	Оборудование	Межсетевые экраны, HSM (аппаратное шифрование)
Программный	Программы и данные	Антивирус, шифрование, DLP-системы

Основные методы защиты информации:

Метод	Что делает	Пример	Эффективность
Идентификация	Пользователь называет себя	Ввод логина	Низкая
Аутентификация	Пользователь доказывает, что это он	Ввод пароля, отпечаток пальца	Средняя
Авторизация	Проверка прав	Пользователь может только читать	Высокая
Шифрование	Преобразование данных в нечитаемый вид	AES-256	Высокая
Контроль доступа	Ограничение, кто что может делать	Списки ACL	Средняя
Аудит (логирование)	Запись всех действий	Лог: «Пользователь X удалил файл Y»	Высокая
Резервное копирование	Восстановление после сбоя или атаки	Ежедневные бэкапы	Высокая
DLP (Data Loss Prevention)	Предотвращение утечки данных	Блокировка отправки файлов на почту	Средняя

Типы аутентификации (по факторам):

Фактор	Что используется	Пример	Безопасность	Удобство
То, что вы знаете	Пароль, PIN-код	Пароль «qwerty123»	Низкая	Высокое
То, что вы имеете	Физический объект	USB-токен, смарт-карта, телефон	Средняя	Среднее
То, что вы есть	Биометрия	Отпечаток пальца, лицо, радужка глаза	Высокая	Высокое

Что такое двухфакторная аутентификация (2FA):

Двухфакторная аутентификация — это комбинация двух разных факторов. Например:

Пароль (то, что знаете) + SMS-код (то, что имеете — телефон)
PIN-код (то, что знаете) + отпечаток пальца (то, что есть)

Шифрование (как работает):

Вид шифрования	Что значит	Пример	Когда использовать
Симметричное	Один ключ для шифрования и расшифровки	AES-256, DES, RC4	Хранение данных на диске
Асимметричное	Пара ключей: публичный (шифрует) и приватный (расшифровывает)	RSA, ECC	Передача данных, TLS/HTTPS
Хеширование	Одностороннее преобразование (нельзя расшифровать)	SHA-256, bcrypt	Хранение паролей

Что такое HSM (Hardware Security Module):

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

Где HSM применяется	Зачем
Банки	Для работы с банковскими картами (PIN)
Платёжные системы	Для шифрования транзакций
Государственные системы	Для ЭЦП (электронная подпись)
Крупные корпорации	Для хранения секретов (пароли, ключи)

Что такое DLP (Data Loss Prevention):

DLP — это система предотвращения утечек данных. Она контролирует, что пользователи копируют, отправляют, печатают.

Что контролирует DLP	Пример действия
Email	Отправить файл на личную почту → заблокировать
USB-накопители	Скопировать на флешку → заблокировать
Мессенджеры	Отправить скриншот в Telegram → заблокировать
Печать	Распечатать документ → заблокировать
Облачные хранилища	Загрузить в Google Drive → заблокировать

Законодательство в области защиты информации (Россия):

Закон	Что регулирует	Для кого
152-ФЗ «О персональных данных»	Сбор, хранение, обработка персональных данных	Любые компании с клиентами
187-ФЗ «О безопасности КИИ»	Защита критической информационной инфраструктуры	Банки, энергетика, транспорт
149-ФЗ «Об информации»	Общие принципы	Все
ГОСТ Р 57580	Безопасность информационных систем	Банки

Что нужно для соответствия 152-ФЗ (для интернет-магазина):

Требование	Что сделать
Политика обработки ПДн	Документ на сайте
Согласие на обработку	Галочка «Я согласен»
Хранение ПДн на территории РФ	Серверы в России
Защита ПДн (шифрование)	HTTPS, хеширование паролей
Уведомление об утечке	Сообщить в РКН в течение 24 часов

Вопрос 78.

Оценка качества программного обеспечения

Оценка качества ПО — это процесс определения степени соответствия программы установленным требованиям и ожиданиям пользователей. Качество многомерно: программа может быть функциональной, но неудобной; быстрой, но ненадёжной. Оценка качества проводится на протяжении всего жизненного цикла.

Модели качества (стандарты):

Стандарт	Что описывает	Когда использовать
ISO 25010	8 характеристик качества (функциональность, надёжность, производительность…)	Международный стандарт
ISO 9126	Устаревшая версия ISO 25010	Заменён на 25010
ГОСТ Р ИСО/МЭК 25010-2015	Российский аналог ISO 25010	Госзаказ
CMMI	Зрелость процессов разработки	Крупные компании
McCall	11 факторов качества (старая модель)	Образование, история

Модель качества ISO 25010 (8 характеристик с подхарактеристиками):

Характеристика	Подхарактеристики	Что проверяем
Функциональная пригодность	Полнота, правильность, уместность	Все ли функции работают правильно
Надёжность	Безотказность, готовность, восстанавливаемость	Не падает ли программа
Производительность	Время отклика, пропускная способность	Быстро ли работает
Удобство использования	Понятность, обучаемость, эстетика	Легко ли пользоваться
Безопасность	Конфиденциальность, целостность, неотказуемость	Защищены ли данные
Сопровождаемость	Модульность, повторяемость, анализируемость	Легко ли менять код
Совместимость	Сосуществование, взаимодействие	Работает ли с другими системами
Переносимость	Устанавливаемость, заменяемость	Работает ли на разных ОС

Методы оценки качества (как оценивать):

Метод	Что делает	Кто проводит	Результат
Тестирование	Проверка программы в действии	Тестировщики	Список найденных багов
Анализ кода	Статический анализ, code review	Разработчики, линтеры	Оценка качества кода
Измерение метрик	Сбор количественных показателей	Инструменты (SonarQube)	Цикломатическая сложность, покрытие тестами
Экспертная оценка	Приглашённые эксперты смотрят программу	Внешние эксперты	Отчёт с замечаниями
Опрос пользователей	Пользователи оценивают удобство	Маркетологи, UX	NPS, SUS
Сравнение с аналогами	Сравниваем с конкурентами	Аналитики	Отчёт о сравнении

Метрики качества (количественные показатели):

Метрика	Что измеряет	Формула	Хорошее значение
Плотность дефектов	Количество ошибок на размер кода	Ошибки / 1000 строк кода	< 1
Покрытие тестами	Какой % кода проверен тестами	Строки в тестах / Все строки × 100%	> 70%
Время между сбоями (MTBF)	Надёжность	Часы работы / Количество сбоев	> 1000 часов
Время исправления (MTTR)	Скорость реакции	Сумма времени простоя / Количество сбоев	< 24 часа
Индекс удобства (SUS)	Юзабилити	Опросник из 10 вопросов	> 70
Цикломатическая сложность	Сложность кода	Количество путей в функции	< 10
Процент дублирования	Повторы кода	Дублированные строки / Все строки × 100%	< 5%

Что такое статический анализ кода:

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

Тип проблем, которые находит статический анализ	Пример
Потенциальные ошибки	Переменная не инициализирована
Стиль кода	Отступы, пробелы, длина строки
Безопасность	Конкатенация в SQL (риск инъекции)
Дублирование кода	Один и тот же фрагмент в двух местах
Сложность	Функция слишком длинная или вложенная
Мёртвый код	Неиспользуемые переменные, функции

Инструменты для оценки качества:

Инструмент	Для чего	Что даёт
SonarQube	Статический анализ, качество кода	Оценка кода (A,B,C,D,E), список проблем
JaCoCo	Покрытие тестами (Java)	Процент покрытых строк
pytest-cov	Покрытие тестами (Python)	Отчёт в HTML
SUS опросник	Юзабилити	Оценка удобства от 0 до 100
Lighthouse	Производительность веб	Оценка от 0 до 100

Вопрос 79.

Критерии качества программного продукта

Критерии качества — это конкретные, измеримые требования, по которым можно определить, хороша программа или нет. Они конкретнее характеристик качества. Если характеристика — это «производительность», то критерий — «время загрузки страницы не более 2 секунд».

Критерии качества по ISO 25010 (с примерами измеримых требований):

Характеристика	Критерий (измеримое требование)	Как проверить	Хорошее значение
Функциональная пригодность	100% функций реализовано в соответствии с ТЗ	Прогнать тесты	100% тестов пройдено
Надёжность	Доступность 99.9%	Измерить простой за месяц	< 8.8 часов простоя в год
Производительность	Время загрузки главной страницы < 2 секунд	Измерить в Chrome DevTools	< 2 секунд
Удобство использования	90% пользователей выполняют задачу без подсказок	Юзабилити-тест	> 90%
Безопасность	Нет критических уязвимостей	Сканер уязвимостей	0 критических
Сопровождаемость	Покрытие тестами > 70%	JaCoCo, pytest-cov	> 70%
Совместимость	Работает в Chrome, Firefox, Safari	Прогнать тесты в разных браузерах	Все тесты пройдены
Переносимость	Устанавливается на Windows и Linux	Попробовать установить	Успешная установка

Как превратить характеристику в критерий (примеры):

Характеристика	Размытое требование (не критерий)	Конкретный критерий (измеримый)
Производительность	«Программа должна работать быстро»	«Время ответа API не более 200 мс при 1000 запросов в секунду»
Надёжность	«Программа не должна падать»	«MTBF > 1000 часов, доступность > 99.9%»
Безопасность	«Программа должна быть безопасной»	«Пароли хранятся в виде bcrypt-хешей, передача только по HTTPS»
Удобство	«Программа должна быть удобной»	«90% новых пользователей оформляют заказ с первой попытки за 3 минуты»

Приоритеты критериев (что важнее):

Приоритет	Критерий	Почему
Высший	Функциональная пригодность	Если функция не работает — всё остальное не важно
Высокий	Безопасность	Утечка данных может убить бизнес
Высокий	Надёжность	Если программа падает — ей нельзя доверять
Средний	Производительность	Медленно, но работает — лучше, чем не работает
Низкий	Удобство использования	Некрасиво, но работает — пользователи привыкнут
Низкий	Совместимость	Если не работает в Safari, скажут «откройте в Chrome»

Пример оценки программы по критериям (оценка от 1 до 5):

Критерий	Вес	Оценка	Взвешенная оценка
Все функции по ТЗ	5	5	25
Время ответа < 200 мс	3	4	12
Доступность 99.9%	4	3	12
Покрытие тестами > 70%	2	5	10
Нет критических уязвимостей	5	2	10
Итого	19		69 (из 95)

Вопрос 80.

Стандарты качества программного обеспечения

Стандарты качества — это официальные документы, которые описывают требования к процессам разработки, документации и самому программному продукту. Они помогают разным компаниям говорить на одном языке, упрощают госзаказ и аудит. Стандарты бывают международные (ISO/IEC), национальные (ГОСТ) и отраслевые.

Основные международные стандарты качества ПО:

Стандарт	Что описывает	Кто использует	Год принятия
ISO 25010	Характеристики качества продукта (8 штук)	Все (международный)	2011 (актуален)
ISO 12207	Процессы жизненного цикла ПО (основные, вспомогательные, организационные)	Разработчики, заказчики	1995 (обновляется)
ISO 9001	Система менеджмента качества (не только ПО)	Любые компании	1987 (обновляется)
CMMI	Зрелость процессов разработки (уровни 1-5)	Крупные компании (банки, аутсорс)	2002 (актуален)
ГОСТ 19.xxx (ЕСПД)	Программная документация (устаревший, но используется в госзаказе)	Госзаказ, оборонка	1970-1980 (устарел)
ГОСТ 34.xxx	Автоматизированные системы	Госзаказ	1990 (устарел)
IEEE 829	Документация тестирования	Крупные проекты	1998 (обновлён)
ISO 27001	Информационная безопасность	Любые компании	2005 (актуален)

Подробно об ISO 25010 (качество продукта):

Характеристика	Количество подхарактеристик	Основная идея
Функциональная пригодность	3	Программа делает то, что нужно
Надёжность	4	Программа не падает
Производительность	3	Программа работает быстро
Удобство использования	5	Программой легко пользоваться
Безопасность	4	Данные защищены
Сопровождаемость	4	Код легко менять
Совместимость	2	Работает с другими системами
Переносимость	3	Работает на разных ОС

Подробно об ISO 12207 (процессы ЖЦ):

Группа процессов	Процессы	Что делают
Основные	Приобретение, поставка, разработка, эксплуатация, сопровождение	Создание и использование ПО
Вспомогательные	Документирование, верификация, валидация, аудит	Обеспечение качества
Организационные	Управление проектом, управление инфраструктурой, обучение	Управление ресурсами

Уровни зрелости CMMI (от хаоса до оптимизации):

Уровень	Название	Что значит	Пример компании
1	Начальный (Initial)	Процессы непредсказуемы, хаос	Стартап, маленькая команда
2	Управляемый (Managed)	Процессы задокументированы, повторяемы	Средняя компания
3	Определённый (Defined)	Процессы стандартизированы для всей компании	Крупная компания
4	Количественно управляемый	Процессы измеряются статистически	Банк, аутсорсер
5	Оптимизирующий (Optimizing)	Постоянное улучшение процессов	Лидеры рынка

Российские стандарты (ГОСТ) — что осталось актуальным:

Стандарт	Что описывает	Актуален ли	Когда используют
ГОСТ 19.101-77	Виды документов	Формально да	Госзаказ (по требованию)
ГОСТ 19.201-78	Техническое задание	Формально да	Госзаказ
ГОСТ 34.601-90	Стадии создания АС	Формально да	Госзаказ
ГОСТ Р ИСО/МЭК 25010-2015	Качество ПО	Да (актуальный)	Все (добровольно)

Что такое сертификация по стандартам (зачем нужна):

Стандарт	Зачем сертифицироваться	Сложность	Стоимость
ISO 9001	Для доверия клиентов, участия в тендерах	Средняя	300-500 тыс. руб
CMMI	Для крупных заказчиков (банки, гос)	Высокая	От 1 млн руб
ISO 27001	Для работы с персональными данными	Высокая	500-800 тыс. руб
ГОСТ 19	Для госзаказа (обязательно)	Средняя	200-400 тыс. руб

Как выбрать стандарт для своего проекта:

Ситуация	Какой стандарт нужен
Своя разработка (не для госзаказа)	Никакой (использовать лучшие практики)
Участие в тендере (коммерческий)	ISO 9001 (часто требуется)
Госзаказ (Россия)	ГОСТ 19 или ГОСТ 34 (обязательно)
Крупный заказчик (банк)	CMMI (уровень 2-3)
Работа с персональными данными	ISO 27001 + 152-ФЗ
Международный контракт	ISO 12207 + ISO 25010

Вопрос 81.

Управление проектом разработки программного обеспечения

Управление проектом (Project Management) — это применение знаний, навыков, инструментов и методов для достижения целей проекта в рамках заданных ограничений (сроки, бюджет, качество, объём). Управление проектом включает планирование, организацию, контроль и мотивацию команды.

Основные ограничения проекта (треугольник проекта):

Ограничение	Что значит	Взаимосвязь
Объём (Scope)	Что должно быть сделано (функции, задачи)	Чем больше объём, тем больше сроки и бюджет
Сроки (Time)	Когда нужно закончить	Чем меньше сроки, тем меньше объём или больше бюджет
Бюджет (Cost)	Сколько денег можно потратить	Чем меньше бюджет, тем меньше объём или больше сроки
Качество (Quality)	Насколько хорошо сделано	Экономия на качестве снижает объём, но увеличивает риски

Управление проектом — основные области знаний (по PMBOK):

Область знаний	Что включает	Пример
Управление интеграцией	Связывает все процессы	Создание устава проекта, плана
Управление содержанием	Что входит в проект, а что нет	Требования, ТЗ
Управление сроками	Планирование и контроль времени	Диаграмма Ганта
Управление стоимостью	Бюджетирование, контроль затрат	Смета, отчёты
Управление качеством	Обеспечение качества, контроль	Планы тестирования
Управление ресурсами	Люди, оборудование	Распределение задач
Управление коммуникациями	Обмен информацией	Ежедневные встречи, отчёты
Управление рисками	Выявление и снижение рисков	Реестр рисков
Управление закупками	Привлечение подрядчиков	Тендеры, контракты
Управление стейкхолдерами	Работа с заинтересованными лицами	Регулярные встречи

Жизненный цикл проекта (фазы управления):

Фаза	Что делаем	Результат
Инициация	Определяем цели, зачем проект, кто заказчик	Устав проекта
Планирование	Составляем план, график, бюджет, риски	План управления проектом
Исполнение	Выполняем работы по плану	Продукт (промежуточный)
Мониторинг и контроль	Сравниваем факт с планом, корректируем	Отчёты, изменения
Завершение	Сдача продукта, закрытие контрактов	Акт приёмки

Документы управления проектом (основные):

Документ	Что содержит	Кто создаёт
Устав проекта	Цели, бюджет, сроки, ответственные	Спонсор, менеджер
План управления	Как будем управлять (сроками, рисками, качеством)	Менеджер
Расписание (Гант)	Задачи, сроки, зависимости	Менеджер
Реестр рисков	Что может пойти не так, вероятность, меры	Менеджер
Бюджет	Статьи расходов, плановые и фактические	Менеджер, бухгалтер
Отчёты о статусе	Что сделано, что в работе, проблемы	Менеджер (еженедельно)

Инструменты управления проектом (сравнение):

Инструмент	Для чего	Плюсы	Минусы
Jira	Управление задачами, Agile	Мощный, интеграция с Git	Сложный, дорогой
Trello	Простые доски (Kanban)	Простой, бесплатный	Мало функций
YouTrack	Баг-трекер, Agile	Быстрый, от JetBrains	Меньше интеграций
MS Project	Диаграммы Ганта, ресурсы	Профессиональный	Дорогой, только Windows
Asana	Управление задачами	Удобный интерфейс	Ограничения в бесплатной версии
Redmine	Open Source	Бесплатный	Старый интерфейс

Ключевые метрики управления проектом:

Метрика	Что измеряет	Формула	Хорошее значение
CPI (Cost Performance Index)	Эффективность бюджета	EV / AC	> 1 (меньше 1 — перерасход)
SPI (Schedule Performance Index)	Эффективность сроков	EV / PV	> 1 (меньше 1 — отставание)
Velocity (Agile)	Скорость команды (Story Points за спринт)	Сумма SP за спринт	Стабильна или растёт
Отклонение от графика	На сколько дней отстаём	План — Факт	< 5% от срока
Burn-down chart	Сколько осталось до конца спринта	График	Тенденция к нулю

Что такое EV, AC, PV (метод освоенного объёма):

Термин	Расшифровка	Что значит	Пример (за 1 месяц)
PV	Planned Value	Плановая стоимость работ по плану	Должны были сделать на 100 000 руб
EV	Earned Value	Освоенная стоимость (сколько сделали фактически)	Сделали на 80 000 руб
AC	Actual Cost	Фактические затраты	Потратили 90 000 руб

Выводы по метрикам:

EV (80) < PV (100) → отставание от графика
AC (90) > EV (80) → перерасход бюджета

Вопрос 82.

Распределение ролей в команде разработки ПО

Распределение ролей — это разделение ответственности между участниками команды. Каждая роль имеет свои задачи, зону ответственности и необходимые навыки. В маленьких командах один человек может совмещать несколько ролей. В крупных — каждая роль может быть представлена несколькими людьми.

Основные роли в команде разработки (таблица):

Роль	Зона ответственности	Типичные задачи	Необходимые навыки
Product Owner	Что делать (приоритеты)	Формирование бэклога, приёмка работы	Понимание бизнеса, коммуникация
Project Manager	Когда делать (сроки, бюджет)	Планирование, отчёты, риски	Организационные навыки
Team Lead	Как делать (технически)	Распределение задач, code review, менторство	Технические + лидерские
Аналитик (BA)	Сбор и формализация требований	Интервью, написание ТЗ, диаграммы	Аналитическое мышление
Архитектор	Структура системы	Выбор технологий, архитектурные решения	Глубокое техническое знание
Разработчик	Написание кода	Реализация функций, тесты, баги	Программирование
Тестировщик (QA)	Проверка качества	Тест-кейсы, ручное/автоматическое тестирование	Внимательность, скрупулёзность
DevOps	Инфраструктура, CI/CD	Серверы, сборка, деплой, мониторинг	Linux, сети, облака
Технический писатель	Документация	Руководства пользователя, админа, API	Письменная речь

Примеры распределения ролей для разных размеров команды:

Команда 3 человека (стартап):

Сотрудник	Основная роль	Совмещает
А	Разработчик (бэкенд)	DevOps, архитектор
Б	Разработчик (фронтенд)	Тестировщик
В	Product Owner	Аналитик, Project Manager

Команда 10 человек (средний проект):

Роль	Количество человек
Product Owner	1
Project Manager	1
Team Lead	1
Аналитик	1
Разработчики (бэкенд)	2
Разработчики (фронтенд)	2
Тестировщики	1
DevOps	1 (совмещает с администрированием)

Команда 50 человек (крупный проект):

Роль	Количество человек
Product Owner	2 (разные модули)
Project Manager	2
Team Lead	4 (по модулям)
Аналитики	5
Архитекторы	2
Разработчики	25
Тестировщики	8
DevOps	3
Технические писатели	2

Что такое RACI-матрица (распределение ответственности):

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

R — Responsible — Исполнитель — Кто делает работу
A — Accountable — Ответственный — Кто принимает решение, подписывает
C — Consulted — Консультируется — Кого спрашивают перед действием
I — Informed — Информируется — Кого ставят в известность

Пример RACI-матрицы для задачи «Внедрение новой функции»:

Задача	PM	PO	TL	Dev	QA	DevOps
Собрать требования	A	R	C	I	—	—
Согласовать бюджет	A	R	C	—	—	—
Спроектировать	C	I	R	C	I	C
Написать код	I	—	C	R	—	—
Протестировать	I	C	—	—	R	—
Выкатить на сервер	I	—	A	—	—	R

Вопрос 83.

Подготовка программного продукта к релизу

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

Этапы подготовки к релизу (чек-лист):

№	Этап	Что проверяем	Кто отвечает	Срок
1	Код-фриз (code freeze)	Запрет изменений, кроме критических	PM/TL	За 1-2 недели до релиза
2	Функциональное тестирование	Все функции работают по ТЗ	QA	За 1-2 недели
3	Регрессионное тестирование	Не сломали ли старое новым	QA	За 1 неделю
4	Нагрузочное тестирование	Выдерживает ли ожидаемую нагрузку	QA, DevOps	За 1 неделю
5	Тестирование безопасности	Нет критических уязвимостей	Security QA	За 1 неделю
6	Тестирование установки	Установка работает на целевых ОС	QA	За 3 дня
7	Сборка релизной версии	Создание установщика или контейнера	DevOps	За 1 день
8	Релизные заметки	Что нового, что исправлено	PM, техпис	За 2 дня
9	Обновление документации	Руководства соответствуют новой версии	Техпис	За 2 дня
10	Резервное копирование	Перед обновлением — бэкап данных	DevOps	За 1 час до релиза
11	Релиз	Выкладка пользователям	DevOps	В назначенное время
12	Мониторинг после релиза	Следим за ошибками, нагрузкой	DevOps, QA	24-48 часов

Что такое код-фриз (code freeze):

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

Тип код-фриза	Что можно менять	Когда используют
Мягкий	Исправления багов, мелкие правки	За 1 неделю до релиза
Жёсткий	Только критические баги (Blocker)	За 2-3 дня до релиза
Полный	Ничего (только в экстренных случаях)	За 1 день до релиза

Типы релизов (как выкладываем):

Тип	Что делаем	Риски	Когда использовать
Big Bang	Всё сразу, все пользователи	Высокие	Небольшая аудитория
Rolling	Постепенно (сначала 1%, потом 10%, потом 100%)	Низкие	Веб-сервисы
Canary	Сначала на тестовую группу, потом на всех	Низкие	Крупные системы
Blue-Green	Два окружения: синее работает, зелёное обновляем, потом переключаем	Очень низкие	Критичные системы
Feature Toggle	Релиз есть, но новая функция скрыта под флагом	Низкие	A/B-тестирование

Релизный чек-лист (для DevOps перед выкладкой):

№	Проверка	Статус
1	Все тесты (unit, integration, system) прошли	+
2	Все критические баги (P0, P1) исправлены	+
3	Регрессионные тесты пройдены	+
4	Нагрузочные тесты пройдены (при необходимости)	+
5	Документация обновлена	+
6	Релизные заметки написаны	+
7	Резервные копии созданы	+
8	План отката (rollback) готов	+
9	Команда оповещена о времени релиза	+
10	Мониторинг настроен после релиза	+

Что делать, если релиз пошёл не так (план отката):

Проблема	Действие	Время
Критический баг в новой версии (падения)	Откат на предыдущую версию	5-15 минут
Медленная работа после релиза	Отключить новые функции (feature toggle)	5 минут
Ошибка в данных (неправильно сохранились)	Восстановить из резервной копии	30-60 минут
Проблема только у части пользователей	Canary-релиз — откатить для всех	10 минут

Вопрос 84.

Подготовка программного продукта к внедрению

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

Этапы подготовки к внедрению (план внедрения):

№	Этап	Что делаем	Кто отвечает	Длительность
1	Планирование внедрения	Составляем график, назначаем ответственных	PM	1-2 дня
2	Подготовка инфраструктуры	Устанавливаем сервера, настраиваем сеть	DevOps, сисадмин	1-2 недели
3	Установка ПО	Ставим программу на серверы и ПК	DevOps, сисадмин	1-3 дня
4	Миграция данных	Переносим данные из старых систем	Разработчик, аналитик	1-5 дней
5	Обучение пользователей	Проводим тренинги, вебинары, раздаём инструкции	Техпис, менеджер	1-5 дней
6	Тестовый запуск (пилот)	Запускаем на ограниченной группе пользователей	QA, PM	1-7 дней
7	Исправление проблем	Правим ошибки, найденные в пилотной эксплуатации	Разработчики	1-5 дней
8	Промышленный запуск	Запуск для всех пользователей	DevOps, PM	1 день
9	Сопровождение после запуска	Помощь пользователям, исправление срочных багов	Техподдержка, разработчики	1-4 недели

Стратегии внедрения (как переходить со старой системы на новую):

Стратегия	Что делаем	Плюсы	Минусы	Когда использовать
Параллельная	Старая и новая системы работают одновременно	Безопасно (есть откат)	Дорого (две системы), двойная работа	Критичные системы (банки)
Поэтапная	Внедряем по частям (сначала один модуль, потом другой)	Управляемый риск, быстрая обратная связь	Долго	Большие системы
Революционная (Big Bang)	Переход в один момент	Быстро	Высокий риск	Небольшие системы
Пилотная	Сначала на одной группе, потом на всех	Тестирование на реальных данных	Долго	Все системы

Пример плана внедрения для интернет-магазина (поэтапная стратегия):

Этап	Что внедряем	Пользователи	Длительность
1	Каталог товаров (только просмотр)	Все	1 день
2	Корзина и оформление заказа	Тестовая группа (10%)	3 дня
3	Корзина и оформление заказа	Все	1 день
4	Личный кабинет и история заказов	Все	2 дня
5	Интеграция с учётной системой	Сотрудники склада	2 дня
6	Отчёты и аналитика	Менеджеры	2 дня

Подготовка пользователей к внедрению (чему учим):

Тип обучения	Формат	Длительность	Для кого
Очный тренинг	Групповое занятие с демонстрацией	1-2 дня	Ключевые пользователи
Веб-семинар	Онлайн-лекция с демонстрацией	2-4 часа	Все пользователи
Видеоуроки	Записанные короткие видео (3-5 минут)	По требованию	Все
Письменная инструкция	PDF или печатное руководство	Самостоятельно	Все
Подсказки в программе	Всплывающие подсказки при первом использовании	Постоянно	Все
Чат-бот поддержки	Ответы на частые вопросы	Постоянно	Все

Миграция данных (что нужно знать):

Этап миграции	Что делаем	Риски
Анализ старых данных	Смотрим, какие данные есть, в каком формате	Данные могут быть неполными
Очистка данных	Удаляем дубликаты, исправляем ошибки	Можно удалить нужное
Преобразование данных	Переводим в формат новой системы	Потеря данных при конвертации
Перенос данных	Загружаем в новую систему	Обрыв соединения, частичный перенос
Проверка	Сравниваем старые и новые данные (выборочно)	Не все ошибки найдены

Проверка после внедрения (что проверяем):

№	Что проверяем	Как проверяем	Приемлемый результат
1	Все функции работают	Прогнать smoke-тесты	100%
2	Данные не потеряны	Сравнить количество записей	100%
3	Новые данные сохраняются	Создать запись, найти её	100%
4	Производительность	Замерить время операций	Соответствует ТЗ
5	Пользователи могут работать	Наблюдение	Нет жалоб в первые часы

План отката (rollback) — на случай, если внедрение пошло не так:

№	Шаг	Время
1	Остановить новую систему	1 минута
2	Запустить старую систему	5 минут
3	Восстановить данные из резервной копии (созданной перед внедрением)	30-60 минут
4	Проверить, что старая система работает	10 минут
5	Сообщить пользователям о возврате к старой системе	5 минут

Вопрос 85.

Подготовка программного продукта к передаче заказчику (приёмка)

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

Этапы приёмки ПО заказчиком:

№	Этап	Что делаем	Кто участвует	Результат
1	Предварительная приёмка	Демонстрация всех функций заказчику	Разработчик, заказчик	Список замечаний
2	Устранение замечаний	Исправляем ошибки, найденные заказчиком	Разработчик	Исправленная версия
3	Приёмочное тестирование (UAT)	Заказчик сам тестирует по своему сценарию	Заказчик, QA	Акт тестирования
4	Согласование документации	Передаём все документы (ТЗ, руководства)	Менеджеры, техпис	Документы подписаны
5	Подписание акта приёмки	Официальное подтверждение	Заказчик, исполнитель	Подписанный акт
6	Передача исходного кода (если по договору)	Выгрузка кода в репозиторий заказчика	DevOps	Доступ к репозиторию

Что проверяет заказчик при приёмке (типовой чек-лист):

№	Что проверяем	Вопросы заказчика
1	Соответствие ТЗ	Все ли функции из ТЗ работают?
2	Полнота документации	Есть ли руководство пользователя? инструкция админа?
3	Удобство использования	Понятно ли, как пользоваться?
4	Производительность	Не тормозит ли программа?
5	Надёжность	Падает ли при нестандартных действиях?
6	Безопасность	Нет ли очевидных дыр?
7	Внешний вид	Так ли выглядит, как обсуждали?

Акт приёмки (структура документа):

Раздел	Содержание	Пример
1. Заголовок	Название документа, номер, дата	«Акт сдачи-приёмки работ №12 от 15.06.2024»
2. Стороны	Заказчик и Исполнитель	ООО «Ромашка» и ИП Иванов
3. Предмет	Какая работа принята	«Разработка программного продукта «Система учёта товаров»»
4. Соответствие ТЗ	Программа соответствует ТЗ	«Согласно Техническому заданию №5 от 01.02.2024»

Вопрос 86.

Понятие программного обеспечения и программного продукта

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

Определения:

Понятие	Определение	Пример
Программное обеспечение (ПО)	Совокупность программ, данных и документации, предназначенная для решения задач на компьютере	Операционная система Linux, драйвер принтера, библиотека функций
Программный продукт	ПО, готовое к поставке пользователю, обладающее определёнными потребительскими качествами	Microsoft Office, 1С:Бухгалтерия, Photoshop

Отличия программного продукта от ПО (таблица):

Характеристика	Программное обеспечение (ПО)	Программный продукт
Назначение	Для внутреннего использования или как часть другого продукта	Для продажи или массового распространения
Потребительские свойства	Не требуются (важна только функциональность)	Обязательны (удобство, надёжность, документация)
Поддержка	Может отсутствовать	Обязательна (техподдержка, обновления)
Лицензия	Любая (вплоть до отсутствия)	Чётко определена (пользователь знает свои права)
Документация	Минимальная (для разработчиков)	Полная (для пользователей и администраторов)
Пример	Библиотека для работы с JSON	Adobe Photoshop

Программный продукт как товар (особенности):

Особенность товара «программный продукт»	Объяснение	Последствия
Нематериальность	Нельзя потрогать, только результат работы	Сложно оценить качество до покупки
Неразрывность производства и потребления	Создаётся один раз, потребляется многократно	Огромная маржинальность при масштабировании
Изменчивость	Может обновляться, исправляться	Покупатель получает не финальный, а постоянно меняющийся продукт
Эффект масштаба	Копирование — бесплатно	Себестоимость одной копии стремится к нулю
Сетевой эффект	Ценность растёт с числом пользователей	Мессенджер бесполезен без других пользователей

Составляющие программного продукта (что входит в поставку):

Компонент	Что входит	Пример
Исполняемые файлы	.exe, .dll, .so, .jar	setup.exe
Данные	Базы данных, конфигурации, шаблоны	БД клиентов, настройки по умолчанию
Документация	Руководство пользователя, админа, API	PDF-файлы, встроенная справка
Лицензия	Текст лицензионного соглашения (EULA)	Лицензионный договор
Программа установки	Инсталлятор	setup.msi, install.sh
Обновления	Патчи, новые версии	service pack, точка-релиз

Классификация программных продуктов по способу распространения:

Тип	Что значит	Пример	Модель оплаты
Коробочный	Физический носитель (DVD, флешка) в упаковке	Windows (старые версии), игры в магазине	Единовременная покупка
Цифровая дистрибуция	Скачивание из интернета	Steam, App Store, Google Play	Покупка, подписка
SaaS (Software as a Service)	Использование через браузер, аренда	Google Docs, Figma, Salesforce	Ежемесячная/ежегодная подписка
Open Source	Свободное распространение с исходным кодом	Linux, Firefox, GIMP	Бесплатно (доход от поддержки)
Freemium	Базовая версия бесплатно, за расширенную — плата	Dropbox, Zoom, LinkedIn	Бесплатно + платные опции
Adware	Бесплатно, но с рекламой	Многие мобильные игры	Рекламодатели

Жизненный цикл программного продукта (как товара):

Этап	Что происходит	Маркетинговые задачи
Внедрение	Продукт выходит на рынок	Информирование, создание спроса
Рост	Растёт число пользователей	Расширение функционала, масштабирование
Зрелость	Рост замедляется, максимум пользователей	Удержание, улучшение качества, снижение цены
Спад	Пользователи уходят к конкурентам	Выпуск новой версии, вывод с рынка

Примеры успешных программных продуктов (что сделало их успешными):

Продукт	Успех благодаря	Модель
Windows	Лицензирование OEM (поставлялась с компьютерами)	Коробочная + OEM
Microsoft Office	Интеграция с Windows, формат .doc как стандарт	Коробочная → подписка (365)
Adobe Photoshop	Стал стандартом в индустрии (ниша профессионального дизайна)	Коробочная → подписка (Creative Cloud)
Slack	Удобство, интеграции, модель freemium	Freemium → подписка
Linux	Открытость, сообщество, бесплатность	Open Source

Вопрос 87.

Современные принципы разработки программного обеспечения

Современные принципы разработки ПО — это набор идей, практик и подходов, которые сформировались в ответ на неэффективность старых методов (каскадной модели). Главные принципы: гибкость, итеративность, постоянное тестирование, близость к заказчику, автоматизация. Эти принципы легли в основу Agile-манифеста и современных методологий.

Манифест Agile (2001 год) — 4 ценности:

№	Ценность	Что значит	Противоположность (не Agile)
1	Люди и взаимодействие важнее процессов и инструментов	Команда решает, а не регламент	Слепое следование стандартам без учёта контекста
2	Работающий продукт важнее исчерпывающей документации	Код, который работает, важнее 100-страничной документации	Сначала документ, потом код (водопад)
3	Сотрудничество с заказчиком важнее согласования контракта	Общение, а не бумаги	«Всё по ТЗ, даже если это неудобно»
4	Готовность к изменениям важнее следования плану	Меняем планы под реальность	Жёсткий план на год вперёд

12 принципов Agile (кратко):

№	Принцип	Смысл
1	Наивысший приоритет — удовлетворение заказчика	Делаем то, что нужно, а не то, что запланировали
2	Приветствуем изменения требований даже в конце разработки	Гибкость важнее жёсткости
3	Поставляем работающее ПО часто (от 2 недель до 2 месяцев)	Маленькие релизы лучше больших
4	Бизнес и разработчики работают вместе каждый день	Нет стены между заказчиком и командой
5	Работаем с мотивированными профессионалами	Доверие, а не контроль
6	Лицом к лицу — лучший способ передачи информации	Живое общение эффективнее документов
7	Работающее ПО — главный измеритель прогресса	Не отчёты, а работающий код
8	Устойчивый темп работы (не авралы)	Переработки снижают качество
9	Техническое совершенство улучшает гибкость	Чистый код легче менять
10	Простота — искусство не делать лишнего	Минимум ненужных функций
11	Самоорганизующиеся команды дают лучшие архитектуры	Команда сама решает, как делать
12	Регулярная рефлексия («ретроспектива») для улучшения	Каждые 2 недели — как стать лучше

Другие современные принципы (не из Agile, но важные):

Принцип	Что значит	Проявление
DRY (Don’t Repeat Yourself)	Не повторяй код	Общие функции в одном месте
KISS (Keep It Simple, Stupid)	Простота важнее навороченности	Не усложняй там, где можно просто
YAGNI (You Aren’t Gonna Need It)	Не делай то, что может не понадобиться	Не пишем код для «гипотетических» потребностей
Continuous Integration (CI)	Интегрируйся часто (каждый день)	Все коммиты в общую ветку ежедневно
Continuous Delivery (CD)	Всегда готов к релизу	Автоматические тесты и сборка
Test-Driven Development (TDD)	Сначала тест, потом код	Начинаем с написания падающего теста
Pair Programming	Два разработчика за одним компьютером	Один пишет, второй смотрит
Code Review	Проверка кода коллегами перед слиянием	Pull Request на GitHub

Сравнение традиционных и современных принципов:

Аспект	Традиционные принципы (1970-1990)	Современные принципы (2000+)
Планирование	Жёсткий план на весь проект	Гибкое планирование (спринты)
Документация	Подробная, обязательная	Минимальная, «живая»
Тестирование	В конце проекта	Постоянно (TDD, CI)
Изменения	Нежелательны, дороги	Приветствуются
Роль заказчика	В начале и в конце	В команде (Product Owner)
Релизы	Раз в год	Раз в 2 недели (или чаще)
Архитектура	Проектируется целиком в начале	Эволюционирует (рефакторинг)

Что изменилось в разработке за последние 20 лет (главные тренды):

Тренд	Что изменилось	Пример
Agile вместо Waterfall	Вместо жёсткого плана — короткие итерации	Scrum, Kanban
DevOps	Разработка и эксплуатация вместе	CI/CD, Docker, Kubernetes
Облачные технологии	Не нужно покупать серверы	AWS, Google Cloud, Azure
Микросервисы	Вместо монолита — сотни маленьких сервисов	Netflix, Amazon
Автоматизация тестирования	Тесты запускаются автоматически	GitHub Actions, Jenkins
Открытый код	Использование Open Source библиотек	npm, PyPI, Maven Central

Вопрос 88.

Жизненный цикл программного обеспечения Дубл.

Жизненный цикл ПО (ЖЦ ПО) — это период времени от возникновения идеи создания программы до полного прекращения её использования. Понимание ЖЦ помогает планировать ресурсы, управлять рисками и принимать решения о модернизации или замене системы. Вопрос уже рассматривался, здесь — углубление с акцентом на управленческие аспекты.

Фазы жизненного цикла (управленческий взгляд):

Фаза	Что происходит	Ключевые решения	Кто принимает
Инициация	Оценка бизнес-ценности, анализ рынка	Запускать или нет проект	Бизнес-спонсор
Разработка	Создание продукта	Выбор методологии, технологий	Руководитель проекта, архитектор
Внедрение	Передача пользователям	Стратегия внедрения (поэтапно или сразу)	Руководитель проекта, заказчик
Эксплуатация	Использование пользователями	Модернизация или замена	Бизнес-владелец
Вывод из эксплуатации	Отключение системы	Миграция данных, уведомление пользователей	Бизнес-владелец, IT-директор

Стандарты, описывающие ЖЦ (сравнение):

Стандарт	Что описывает	Для кого	Актуален ли
ISO/IEC 12207	Процессы ЖЦ (основные, вспомогательные, организационные)	Международные проекты	Да
ГОСТ 34.601-90	Стадии создания автоматизированных систем	Госзаказ РФ	Формально да
ГОСТ 19.102-77	Стадии разработки ПО (ЕСПД)	Госзаказ РФ	Устарел, но формально действует
IEEE 1074	Процессы ЖЦ (адаптирован под практику)	Крупные компании	Да

Процессы ISO 12207 (детально):

Группа	Процесс	Что делает
Основные	Приобретение	Заказчик покупает или заказывает ПО
	Поставка	Исполнитель передаёт ПО заказчику
	Разработка	Создание ПО
	Эксплуатация	Использование ПО пользователями
	Сопровождение	Поддержка и модификация
Вспомогательные	Документирование	Запись информации
	Верификация	Проверка соответствия требованиям
	Валидация	Проверка, что решает задачи пользователя
	Аудит	Проверка соответствия стандартам
Организационные	Управление проектом	Планирование, контроль
	Управление конфигурацией	Учёт версий
	Управление инфраструктурой	Обеспечение ресурсами
	Обучение	Повышение квалификации

Экономика жизненного цикла (распределение затрат):

Фаза	Процент затрат (классический проект)	Процент затрат (Agile-проект)
Анализ требований	10%	5% (в каждом спринте)
Проектирование	20%	10% (в каждом спринте)
Разработка (код)	25%	35% (в каждом спринте)
Тестирование	20%	25% (в каждом спринте)
Внедрение	5%	5%
Сопровождение (первые 3 года)	20%	20%
Итого (разработка + 3 года сопровождения)	100%	100%

Когда выводить ПО из эксплуатации (признаки устаревания):

Признак	Что значит	Что делать
Высокая стоимость сопровождения	> 80% бюджета уходит на поддержку	Рассмотреть замену
Устаревшие технологии	Язык/платформа больше не поддерживаются	Миграция
Несоответствие современным требованиям безопасности	Критические уязвимости, не подлежащие исправлению	Срочная замена
Потеря компетенций	Нет специалистов, которые могут поддерживать	Переписать на современном стеке
Появление более эффективного аналога	Конкурент делает лучше	Переход на готовое решение

Пример расчёта совокупной стоимости владения (TCO) за 10 лет:

Статья расходов	Год 1 (разработка)	Годы 2-10 (эксплуатация)	Итого
Разработка	2 000 000 руб	0	2 000 000 руб
Техподдержка	0	100 000 × 9 = 900 000	900 000 руб
Серверы и хостинг	60 000	60 000 × 9 = 540 000	600 000 руб
Обучение персонала	100 000	0	100 000 руб
Итого	2 160 000 руб	1 440 000 руб	3 600 000 руб

Вопрос 89.

Основные модели жизненного цикла ПО Дубл.

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

Подробное сравнение пяти моделей (добавлена Lean-модель):

Модель	Этапы	Плюсы	Минусы	Когда применять
Каскадная (Waterfall)	Анализ → Проект → Код → Тест → Внедрение	Простота, чёткие этапы	Ошибки дороги, нет гибкости	Стабильные требования, госзаказ, авиация
Итеративная	Циклы: анализ+проект+код+тест для части функционала	Заказчик видит прогресс	Требует хорошей архитектуры	Крупные проекты с уточняемыми требованиями
Спиральная (Spiral)	Риски → Разработка → План → повтор	Контроль рисков	Сложно, дорого	Высокорисковые проекты (космос, инновации)
Agile (Scrum, XP)	Спринты 1-4 недели, работающий продукт каждый спринт	Быстрая реакция на изменения	Минимум документации	Веб-сервисы, стартапы
Lean	Устранение потерь, быстрая доставка ценности	Минимум лишней работы	Требует дисциплины	Проекты с ограниченным бюджетом

Гибридные модели (сочетают лучшие черты):

Гибридная модель	Что сочетает	Пример применения
Water-Scrum-Fall	Каскад (требования, документация) + Scrum (разработка) + Каскад (внедрение)	Крупные компании с регуляторными требованиями
Scrum-ban	Scrum (спринты) + Kanban (визуализация потока, WIP limit)	Команды, где нужна гибкость и предсказуемость
SAFe (Scaled Agile Framework)	Agile для больших команд (50+ человек)	Крупные корпорации

SAFe (Scaled Agile Framework) — уровни:

Уровень	Что управляет	Длительность	Кто участвует
Портфель (Portfolio)	Стратегия, бюджет, направления развития	Кварталы-годы	Руководство
Программа (Program)	Крупный проект (ART — Agile Release Train)	10-12 недель	Менеджеры программ
Команда (Team)	Спринты (Scrum или Kanban)	1-2 недели	Команды разработки

Как выбрать модель (алгоритм для руководителя):

Вопрос	Если ДА	Если НЕТ
Требования стабильны и понятны с самого начала?	Каскад или V-Model	Agile, итеративная
Высокие риски (ошибка может стоить жизни или миллионов)?	Спиральная	Agile
Нужна быстрая реакция на рынок (стартап)?	Agile (Scrum, XP)	Каскад
Команда маленькая (до 10 человек)?	Agile	Каскад или SAFe
Есть жёсткие регуляторные требования (авиация, медицина, госзаказ)?	Каскад, V-Model	Agile (чистый)
Проект крупный (100+ человек, несколько лет)?	SAFe (Agile для крупных)	Чистый Scrum

Типичные ошибки при выборе модели:

Ошибка	Пример	Последствие	Как избежать
Слепое следование Agile без учёта контекста	Используем Scrum, но заказчик хочет подробный план на год	Конфликт, недовольство	Адаптировать под заказчика
Слепое следование каскаду в меняющемся окружении	Фиксируем ТЗ, через 3 месяца рынок изменился	Продукт никому не нужен	Выбрать Agile
«Клоунский гибрид»	Берём худшее из каскада и худшее из Agile	Хаос	Использовать проверенные гибриды

Вопрос 90.

Требования к программному обеспечению Дубл.

Требования к ПО — это описание того, что должна делать программа и какими свойствами обладать. Это основа всего проекта. Плохо собранные требования — причина 70% провалов проектов ПО. Вопрос уже рассматривался, здесь — углубление про уровни требований и их взаимосвязь.

Пирамида требований (от бизнеса до кода):

1.Бизнес-требования (Vision, Business Case)
2.Пользовательские требования (User Stories, Use Cases)
3.Функциональные требования (SRS)
4.Нефункциональные требования (NFR)
5.Технические требования (спецификации, протоколы)

Каждый уровень подробно:

Уровень	Что описывает	Пример	Для кого
Бизнес-требования	Какие бизнес-цели достигаются	«Увеличить онлайн-продажи на 30%»	Владельцы бизнеса
Пользовательские требования	Что пользователи могут делать	«Пользователь может добавить товар в корзину»	Пользователи, заказчик
Функциональные требования	Конкретные функции системы	«Система при нажатии «Купить» проверяет наличие товара на складе»	Аналитики, разработчики
Нефункциональные требования	Свойства качества	«Время ответа API < 200 мс»	Архитекторы, разработчики
Технические требования	Технологии, протоколы	«Использовать протокол HTTPS, TLS 1.3»	Разработчики, DevOps

Пример развёртывания требований (от бизнеса до кода):

Шаг	Уровень	Формулировка
1	Бизнес-требование	«Увеличить продажи через интернет-магазин»
2	Пользовательское требование	«Пользователь должен иметь возможность быстро оформить заказ в 1 клик»
3	Функциональное требование	«Система предоставляет кнопку «Быстрый заказ» на странице товара, которая автоматически заполняет данные из последнего заказа»
4	Нефункциональное требование	«Время оформления быстрого заказа не более 10 секунд»
5	Техническое требование	«Данные последнего заказа хранятся в cookie с именем last_order, время жизни 30 дней»

Классификация требований по происхождению (откуда берутся):

Источник	Что даёт	Пример	Приоритет
Заказчик	Бизнес-цели, ключевые функции	«Должен быть отчёт по продажам»	Высший
Пользователи	Удобство, эффективность	«Чтобы ввести дату, можно было выбрать из календаря»	Высокий
Регуляторы	Соответствие законам	«Хранить персональные данные на серверах в РФ»	Высший
Разработчики	Технические ограничения	«Использовать PostgreSQL 14+»	Средний
Конкуренты	Функции-аналоги	«Как у конкурента, тоже сделать быстрый поиск»	Низкий
Стейкхолдеры	Дополнительные требования	«Интеграция с нашей учётной системой»	Высокий

Что такое «заморозка требований» (requirements freeze):

Заморозка требований — это момент в проекте, после которого изменения требований либо запрещены, либо требуют отдельного согласования и дополнительной оплаты.

Тип заморозки	Когда наступает	Что можно менять
Мягкая заморозка	После утверждения ТЗ	Только изменения, не влияющие на сроки и бюджет
Жёсткая заморозка	Начало кодирования	Только критические ошибки
Полная заморозка	За 2 недели до релиза	Ничего

Типичные ошибки при работе с требованиями:

Ошибка	Пример	Последствие	Как избежать
Предположения вместо фактов	«Мы думали, вам нужен экспорт в Excel, а вы хотели CSV»	Переделка	Уточнять, прототипировать
Непроверяемые требования	«Программа должна быть удобной»	Непонятно, когда сдавать	Конкретизировать: «90% пользователей выполняют задачу за 2 минуты»
Золотое сечение	Требование выполняет только один пользователь, но на нём настаивают	Трата ресурсов на неважное	Оценить бизнес-ценность
Потеря источника	Не помним, кто попросил эту функцию	Непонятно, нужна ли она	Трассировка требований (матрица)

Вопрос 91.

Классификация требований к ПО Дубл.

Классификация требований — это их разделение на группы по определённым признакам. Основное деление — на функциональные и нефункциональные требования. Дополнительные классификации помогают управлять требованиями и приоритизировать их.

Основная классификация (функциональные vs нефункциональные):

Тип требований	Что описывает	Вопрос	Кто задаёт
Функциональные (FR)	Что система делает (функции)	«Что?»	Пользователь, заказчик
Нефункциональные (NFR)	Как система это делает (свойства)	«Как? Насколько?»	Архитектор, разработчик

Расширенная классификация (по стандарту ISO 25010):

Категория	Подкатегории	Пример
Функциональная пригодность	Полнота, правильность, уместность	100% функций из ТЗ реализованы
Надёжность	Безотказность, готовность, восстанавливаемость	Доступность 99.9%
Производительность	Время отклика, пропускная способность, использование ресурсов	1000 RPS, время < 200 мс
Удобство использования	Понятность, обучаемость, эстетика	90% пользователей выполняют задачу без подсказок
Безопасность	Конфиденциальность, целостность, неотказуемость	Пароли хешированы (bcrypt)
Совместимость	Сосуществование, взаимодействие	Работает с 1С версии 8.3+
Сопровождаемость	Модульность, повторяемость, анализируемость	Покрытие тестами > 70%
Переносимость	Устанавливаемость, заменяемость	Работает на Windows, Linux, macOS

Классификация по приоритету (MoSCoW):

Буква	Расшифровка	Что значит	Пример	% от общего числа
M	Must have	Обязательно, без этого система не имеет смысла	Авторизация, добавление в корзину	60%
S	Should have	Очень важно, но можно отложить на первый релиз? Нет	Восстановление пароля	20%
C	Could have	Приятно, но не критично	Рекомендации товаров	15%
W	Won’t have	Не делаем в этой версии (в следующей)	Интеграция с 1С	5%

Классификация по стабильности:

Тип	Что значит	Пример	Как часто меняются
Стабильные	Не меняются в течение проекта	Требования законодательства	Редко (годы)
Эволюционирующие	Меняются по мере понимания	Интерфейс, удобство	Часто (спринт к спринту)
Волатильные	Меняются быстро, под рынок	Маркетинговые функции (акции, скидки)	Очень часто

Классификация по происхождению:

Источник	Тип требований	Пример
Бизнес	Бизнес-требования, OKR	«Увеличить конверсию в покупку на 15%»
Пользователи	Пользовательские истории	«Как пользователь, я хочу видеть статус заказа»
Закон	Регуляторные требования	«Хранение персональных данных на территории РФ»
Технические	Технические ограничения	«Не использовать библиотеки GPL в коммерческом продукте»
Стандарты	Требования соответствия	«Документация по ГОСТ 19»

Классификация по способу проверки:

Тип	Как проверять	Пример	Инструменты
Автоматически проверяемые	Написать тест	«При вводе 2+2=4»	JUnit, pytest
Ручные проверяемые	Действие человека	«Кнопка «Купить» должна быть зелёной»	Ручное тестирование
Измеряемые	Измерить инструментом	«Время ответа < 200 мс»	JMeter, Lighthouse
Экспертные	Оценка эксперта	«Интерфейс должен быть современным»	Экспертная оценка

Вопрос 92.

Техническое задание на разработку программного обеспечения Дубл.

Юридическая сила ТЗ (почему важно):

Ситуация	Без ТЗ	С ТЗ
Заказчик говорит: «А я хотел, чтобы кнопка была красной»	Спор, переделка за счёт исполнителя	Смотрим ТЗ: «кнопка зелёная» → доплата за изменение
Заказчик добавляет новую функцию	Приходится делать бесплатно (или спорить)	«Это не в ТЗ, давайте дополнительное соглашение»
Исполнитель сделал не то	Доказать сложно	Акт приёмки сверяется с ТЗ
Срыв сроков	«Слово давали»	В ТЗ написаны сроки, есть ответственность

Кто и зачем подписывает ТЗ:

Подпись	Кто	Что подтверждает	Последствия подписи
Заказчик	Руководитель или уполномоченный	Согласен с требованиями, обязуется принять работу по этим критериям	Нельзя потом сказать «я не то имел в виду»
Исполнитель	Руководитель разработки	Берётся выполнить за указанные сроки и бюджет	Нельзя сказать «мы не знали, что так сложно»
Согласующие	Юрист, главный инженер (в крупных проектах)	Документ не противоречит законам и стандартам	Защита от претензий госорганов

Какие разделы ТЗ имеют юридическую силу в первую очередь:

Раздел	Почему важен	Что должно быть чётко
Цель разработки	Определяет, зачем проект	Измеримый бизнес-результат
Функциональные требования	Что должно работать	Конкретные функции, а не «удобный интерфейс»
Сроки и этапы	Контроль выполнения	Конкретные даты, а не «в течение месяца»
Порядок приёмки	Как принимают работу	Кто подписывает, сколько времени на проверку
Стоимость и порядок оплаты	Финансы	Сумма, аванс, этапы оплаты, штрафы
Ответственность сторон	Что за срыв сроков, некачественную работу	Штрафы, гарантийные обязательства

Типовые ошибки в ТЗ, которые приводят к спорам:

Ошибка	Как выглядит	Последствие	Как исправить
Расплывчатые формулировки	«Интерфейс должен быть интуитивно понятным»	Непонятно, когда считать готовым	«90% пользователей выполняют задачу за 1 минуту без подсказок»
Отсутствие приоритетов	Все функции помечены как «обязательные»	Спор, что важнее	MoSCoW (Must/Should/Could/Won’t)
Нет описания граничных случаев	«Пользователь вводит логин и пароль»	Что при пустом поле? Что при 1000 символов?	Описать обработку исключений
Нет порядка изменения ТЗ	Заказчик добавляет функции, разработчик делает	Бесконечная разработка	Пункт «Порядок изменений ТЗ»
ТЗ без подписей	Электронкой переслали, но не подписали	Не юридически значимо	Подписать сканы, приложить к договору

Пример плохой и хорошей формулировки в ТЗ:

Аспект	Плохо (спорно)	Хорошо (чётко)
Скорость	«Программа должна работать быстро»	«Время загрузки главной страницы не более 2 секунд при скорости интернета 10 Мбит/с»
Надёжность	«Программа не должна падать»	«Доступность 99.9% (не более 8.76 часов простоя в год). В случае падения — автоматический перезапуск менее чем за 1 минуту»
Безопасность	«Программа должна быть безопасной»	«Пароли хранятся в виде bcrypt-хешей. Передача данных только по HTTPS. Защита от SQL-инъекций»
Внешний вид	«Красивый дизайн»	«Скриншот макета (приложение 1). Цвета: #FFFFFF, #000000, #3366FF. Шрифт: Roboto 14px»

Вопрос 93.

Структура технического задания Дубл.

Структура ТЗ — это стандартный набор разделов, который обеспечивает полноту документа. ГОСТ 19.201-78 описывает структуру для госзаказа. В коммерческой практике используется адаптированная структура, но ключевые разделы сохраняются. Вопрос уже рассматривался, здесь — углубление о том, как адаптировать структуру под разные типы проектов.

Структура ТЗ по ГОСТ 19.201-78 (для госзаказа):

№	Раздел	Содержание
1	Введение	Наименование, область применения
2	Основания для разработки	Документ, на основании которого ведётся разработка
3	Назначение разработки	Функциональное и эксплуатационное назначение
4	Требования к программе	Функциональные, к надёжности, к информационной совместимости
5	Требования к программной документации	Состав документации
6	Технико-экономические показатели	Ожидаемая эффективность
7	Стадии и этапы разработки	Что и когда делаем
8	Порядок контроля и приёмки	Как принимают

Адаптированная структура ТЗ для коммерческой разработки (12 разделов):

№	Раздел	Что содержит	Обязательность
1	Цель разработки	Бизнес-задачи, которые решает продукт	Обязательно
2	Функциональные требования	Список функций с приоритетами (MoSCoW)	Обязательно
3	Нефункциональные требования	Производительность, безопасность, надёжность	Обязательно
4	Требования к интерфейсу	Внешний вид, сценарии, мобильная версия	Обязательно
5	Требования к документации	Руководства, инструкции	Обязательно
6	Состав проекта	Какие модули и компоненты входят	Обязательно
7	Технологический стек	Языки, фреймворки, базы данных	Обязательно
8	Этапы и сроки	Дорожная карта с датами	Обязательно
9	Порядок приёмки	Как проверяем, кто подписывает	Обязательно
10	Стоимость и порядок оплаты	Цена, аванс, этапы оплаты	Обязательно
11	Ответственность сторон	Штрафы, гарантии, форс-мажор	Обязательно
12	Порядок изменений ТЗ	Как вносить изменения, цена изменений	Рекомендуется

Как адаптировать структуру под тип проекта (примеры):

Тип проекта	Какие разделы усилить	Какие разделы сократить
Мобильное приложение	Требования к интерфейсу (адаптивность, жесты), требования к производительности (батарея)	Технико-экономические показатели
Веб-сервис (API)	Требования к API (Swagger/OpenAPI), требования к безопасности (JWT, OAuth), нагрузочное тестирование	Требования к интерфейсу (если нет UI)
Сайт-визитка	Требования к интерфейсу (дизайн), SEO-требования	Нефункциональные требования (минимально)
Корпоративная система (ERP, CRM)	Интеграционные требования, требования к безопасности, требования к аудиту, обучение пользователей	Технологический стек (заказчику не важно)
Госзаказ	Всё по ГОСТ 19, полная документация, порядок приёмки	Любые сокращения недопустимы

Пример оглавления ТЗ для интернет-магазина (коммерческая структура):

text

1. Цель разработки
   1.1. Бизнес-цели
   1.2. Целевая аудитория
   1.3. Ключевые показатели эффективности (KPI)

2. Функциональные требования
   2.1. Каталог товаров (FR-01...FR-15)
   2.2. Корзина и оформление заказа (FR-16...FR-25)
   2.3. Личный кабинет (FR-26...FR-35)
   2.4. Административная панель (FR-36...FR-50)

3. Нефункциональные требования
   3.1. Производительность (NFR-01...NFR-05)
   3.2. Безопасность (NFR-06...NFR-12)
   3.3. Надёжность (NFR-13...NFR-15)

4. Требования к интерфейсу
   4.1. Дизайн (ссылка на макет в Figma)
   4.2. Адаптивность (мобильная, планшетная версии)

5. Технологический стек
   5.1. Бэкенд: Python + Django
   5.2. Фронтенд: React
   5.3. База данных: PostgreSQL
   5.4. Хостинг: Yandex Cloud

6. Этапы и сроки
   6.1. Этап 1: Прототип (15.03.2025)
   6.2. Этап 2: MVP (15.05.2025)
   6.3. Этап 3: Полная версия (15.08.2025)

7. Порядок приёмки
   7.1. Критерии приёмки
   7.2. Процедура приёмочного тестирования (UAT)
   7.3. Акт приёмки

8. Порядок изменений ТЗ
   8.1. Инициация изменений
   8.2. Оценка стоимости и сроков
   8.3. Дополнительное соглашение

Приложение 1. Макеты интерфейса (Figma)
Приложение 2. Схема базы данных (ER-диаграмма)
Приложение 3. Глоссарий

Вопрос 94.

Порядок разработки и согласования технического задания

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

Полный процесс разработки и согласования ТЗ (8 этапов):

Этап	Что делаем	Кто участвует	Длительность	Результат
1. Сбор исходных данных	Интервью, анкетирование, изучение бизнес-процессов	Аналитик, заказчик	1-2 недели	Список требований (сырой)
2. Подготовка черновика ТЗ	Формализация требований, структурирование	Аналитик	1-2 недели	Черновик ТЗ (для внутреннего ревью)
3. Внутреннее ревью	Проверка полноты, реализуемости, оценка трудоёмкости	Архитектор, разработчики, QA	2-3 дня	Замечания к черновику
4. Передача заказчику	Отправка черновика заказчику	Менеджер	1 день	Черновик у заказчика
5. Согласование с заказчиком (итерации)	Обсуждение, уточнение, исправление замечаний	Аналитик, заказчик	2-4 недели	Уточнённые версии (v0.2, v0.3…)
6. Финальная версия	Учёт всех правок, проверка, согласование	Аналитик, заказчик	1-3 дня	Финальный черновик
7. Юридическая проверка	Соответствие законам, договору	Юрист	1-2 дня	Правки (если есть)
8. Подписание	Обе стороны подписывают ТЗ	Руководители	1 час	Подписанный ТЗ

Роли в процессе разработки ТЗ:

Роль	Обязанности	Что делает
Аналитик	Ведущий процесса, пишет ТЗ	Интервьюирует, структурирует, пишет, правит
Заказчик	Предоставляет требования, утверждает	Отвечает на вопросы, проверяет черновики, подписывает
Архитектор	Проверяет реализуемость, оценивает трудоёмкость	Читает черновик, говорит «это сложно, давайте проще»
Разработчик	Оценивает трудозатраты	Примерная оценка: функция X — 5 дней
QA	Проверяет проверяемость требований	«Это требование нельзя проверить, переформулируйте»
Менеджер	Управляет сроками и коммуникацией	Согласовывает встречи, следит за дедлайнами
Юрист	Проверяет юридическую чистоту	Нет ли противоречий с договором, законами

Типовые проблемы при согласовании ТЗ и их решения:

Проблема	Проявление	Решение
«Мы не знаем, чего хотим»	Заказчик не может сформулировать требования	Прототипирование, «давайте сделаем прототип, посмотрим»
«Сделайте как у них»	Сравнение с конкурентом без деталей	Попросить скриншоты, видео, конкретные сценарии
Бесконечные итерации	Заказчик правит бесконечно	Зафиксировать лимит итераций (например, 3 раунда)
«Это же очевидно!»	Заказчик не описывает очевидное (по его мнению)	Чек-лист «очевидных» вещей (авторизация, валидация)
Конфликтующие требования	Разные заказчики хотят разное	Вынести на встречу, голосование, назначить Product Owner

Как ускорить согласование ТЗ (советы):

Совет	Почему работает
Использовать прототипы	Заказчику легче «потрогать», чем читать
Фиксировать время на согласование	Дедлайн стимулирует
Ограничить количество правок	«Две итерации бесплатно, дальше — платно»
Привлекать одного Product Owner	Один голос вместо десяти
Использовать чек-листы	Не пропустить важное
Согласовывать по частям	Сначала функциональные требования, потом всё остальное

Что делать, если заказчик не подписывает ТЗ (крайние меры):

Ситуация	Действие
Заказчик тянет время	Письменно зафиксировать, что без ТЗ работа не начинается
Заказчик хочет начать без ТЗ	Подписать «ТЗ-минимум» (только ключевые функции)
Заказчик меняет требования после подписания	Дополнительное соглашение (деньги и время)
Спор о трактовке ТЗ	В ТЗ должен быть раздел «Термины и определения»

Вопрос 95.

Проектирование архитектуры программной системы

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

Архитектура отвечает на вопросы (4 ключевых):

Вопрос	Что значит	Пример ответа
Из каких частей состоит система?	Крупные компоненты, модули, сервисы	Фронтенд, бэкенд, база данных, очередь сообщений
Как эти части взаимодействуют?	Каналы связи, протоколы	HTTP API, WebSocket, очередь RabbitMQ
Где работают эти части?	Физическое размещение	В браузере пользователя, на сервере в облаке, на сервере БД
Какие технологии используются?	Языки, фреймворки, БД	React, Python, PostgreSQL, Redis

Процесс проектирования архитектуры (этапы):

Этап	Что делаем	Результат	Кто делает
1. Анализ требований	Собираем нефункциональные требования (масштабируемость, безопасность)	Список архитектурных требований	Архитектор, аналитик
2. Выбор архитектурного стиля	Монолит, микросервисы, клиент-сервер, событийно-ориентированный	Выбранный стиль	Архитектор
3. Разделение на компоненты	Определяем крупные компоненты и их обязанности	Диаграмма компонентов	Архитектор
4. Определение связей	Как компоненты общаются (синхронно, асинхронно)	Схема взаимодействия	Архитектор
5. Выбор технологического стека	Языки, фреймворки, БД, инфраструктура	Список технологий	Архитектор + команда
6. Проектирование данных	Схема БД, потоки данных	ER-диаграмма	Архитектор, DBA
7. Оценка и ревью	Проверка архитектуры, поиск рисков	Утверждённая архитектура	Команда, лиды

Архитектурные требования (что нужно учесть при проектировании):

Категория	Что нужно предусмотреть	Пример
Масштабируемость	Как расти: вертикально (больше ресурсов) или горизонтально (больше серверов)	Горизонтальное масштабирование через балансировщик
Производительность	Время отклика, пропускная способность	Кэширование, асинхронность
Доступность	Процент времени работы	Резервирование, отказоустойчивость
Безопасность	Защита данных, аутентификация	HTTPS, шифрование, изоляция
Сопровождаемость	Лёгкость внесения изменений	Модульность, документация
Тестируемость	Возможность тестировать части отдельно	Инверсия зависимостей, mock-объекты

Архитектурные риски (что может пойти не так):

Риск	Проявление	Как снизить
Выбор неподходящего стиля	Микросервисы для маленькой команды	Анализировать контекст, не гнаться за модой
Слишком сложная архитектура	10 компонентов для задачи «Калькулятор»	KISS, YAGNI
Слабое место (bottleneck)	Все сервисы зависят от одной БД	Резервирование, шардирование
Вендор-лок (vendor lock-in)	Привязались к конкретному облачному провайдеру	Использовать абстракции, контейнеризацию
Отсутствие документации	Архитектура только в голове архитектора	Документировать (диаграммы, ADR)

Что такое Architectural Decision Record (ADR):

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

Поле	Что содержит	Пример
Название	Краткое описание решения	«Выбор базы данных PostgreSQL»
Дата	Когда принято	15.06.2024
Статус	Предложено, принято, устарело	Принято
Контекст	Проблема, ограничения	Нужна ACID, реляционные данные, объём до 1 ТБ
Решение	Что выбрали и почему	PostgreSQL, потому что ACID, open source, знакомы команде
Альтернативы	Какие были варианты и почему не подошли	MySQL (нет полноценного JSON), MongoDB (нет ACID)
Последствия	Что меняется	Нужен специалист по PostgreSQL

Вопрос 96.

Понятие программного модуля

Программный модуль — это логически независимая, функционально законченная часть программы, имеющая чётко определённый интерфейс и скрывающая свою внутреннюю реализацию. Модули — это «кирпичики», из которых строится программа. Модульность — ключевое свойство хорошей архитектуры.

Свойства программного модуля (4 основных):

Свойство	Что значит	Пример
Функциональная законченность	Модуль делает что-то одно, законченное	Модуль «Авторизация» — только вход и регистрация
Скрытие внутренностей (инкапсуляция)	Другие модули не знают, как он работает внутри	Модуль «Платежи» скрывает алгоритм расчёта комиссии
Чёткий интерфейс	Есть понятный способ взаимодействия (входы и выходы)	Функция `calculateVAT(amount)` — понятно, что передать и что получим
Независимость	Модуль можно разрабатывать и тестировать отдельно	Тестируем модуль «Отчёты» без модуля «Авторизация»

Модуль vs Класс vs Компонент vs Сервис (сравнение):

Понятие	Размер	Что делает	Пример
Модуль	Средний	Логически законченная функция	Модуль «Корзина» (несколько классов)
Класс	Маленький	Одна сущность или ответственность	Класс `Cart`
Компонент	Крупный	Несколько модулей, решающих общую задачу	Компонент «Управление заказами»
Сервис	Крупный	Отдельно развёртываемая единица (в микросервисах)	Сервис «Оплата»

Критерии хорошего модуля (как проверить):

Критерий	Вопрос к модулю	Хорошо	Плохо
Единая ответственность	У модуля одна причина для изменения?	Да	Нет (делает и авторизацию, и платежи)
Слабая связанность	Модуль зависит от немногих других?	Да (1-2 зависимости)	Нет (10 зависимостей)
Сильная связность внутри	Внутри модуля всё логически связано?	Да	Нет (сборник утилит)
Понятный интерфейс	Понятно, как пользоваться?	Да	Нет (нужно знать внутренности)
Тестируемость	Можно протестировать без других модулей?	Да	Нет (требует всю систему)

Пример плохого и хорошего модуля:

Плохой модуль «Утилиты»	Хорошие модули
Функция `validateEmail()`	Модуль «Валидация»
Функция `sendEmail()`	Модуль «Уведомления»
Функция `formatDate()`	Модуль «Форматирование»
Функция `calculateDiscount()`	Модуль «Расчёт скидок»
Функция `logError()`	Модуль «Логирование»

Плохо потому что, изменение в логировании требует перетестировать всё, потому что всё в одном модуле. Изменение формата даты может сломать отправку email.

Вопрос 97.

Проектирование пользовательского интерфейса

Проектирование пользовательского интерфейса (UI — User Interface) — это процесс создания внешнего вида программы и способов взаимодействия пользователя с ней. Хороший интерфейс не требует инструкции — пользователь интуитивно понимает, что делать. Интерфейс должен быть удобным, понятным, эстетичным и доступным.

Основные этапы проектирования UI (детально):

Этап	Что делаем	Результат	Инструменты
1. Исследование пользователей	Изучаем целевую аудиторию: кто, какие задачи, в каких условиях	Персонажи, сценарии	Интервью, опросы
2. Информационная архитектура	Структура: какие экраны, как связаны, где какие блоки	Карта сайта, схема навигации	Balsamiq, Draw.io
3. Прототипирование (Wireframes)	Каркасы экранов (чёрно-белые, без дизайна)	Набор схем	Balsamiq, Figma
4. Визуальный дизайн (UI)	Цвета, шрифты, тени, отступы, иконки, анимация	Макеты высокой детализации	Figma, Sketch
5. Интерактивный прототип	Кликабельный прототип с переходами	Демо	Figma, Axure, ProtoPie
6. Тестирование с пользователями	Наблюдение за пользователями, которые выполняют задачи	Отчёт с проблемами	Zoom, UserTesting
7. Передача разработчикам	Спецификации, вырезанные ресурсы, гайдлайны	Набор ресурсов	Zeplin, Figma Dev Mode

Законы UX (пользовательского опыта) — кратко:

Закон	Что значит	Пример
Закон Фиттса	Чем крупнее и ближе цель, тем легче попасть	Корзина в правом верхнем углу (близко к курсору)
Закон Хика	Время выбора растёт с количеством вариантов	2 кнопки лучше, чем 10
Закон Миллера	Человек удерживает в памяти 7±2 объекта	Не более 7 пунктов в меню
Эффект близости	Близкие элементы воспринимаются как связанные	Группировать поля формы
Эффект последовательности	Первый и последний элементы запоминаются лучше	Самые важные — в начало и конец списка
Закон Якоба	Пользователи ожидают, что ваш сайт будет похож на другие	Не изобретайте велосипед — корзина справа сверху

Требования к хорошему UI (10 правил Нильсена):

№	Правило	Объяснение
1	Видимость состояния	Пользователь всегда знает, что происходит
2	Соответствие реальному миру	Понятные слова, образы
3	Свобода и контроль	Можно отменить действие
4	Стандарты и единообразие	Одинаковые элементы выглядят одинаково
5	Предотвращение ошибок	Не дать сделать ошибку
6	Узнавание, а не припоминание	Варианты под рукой, не надо вспоминать
7	Гибкость и эффективность	Горячие клавиши для опытных
8	Эстетика и минимализм	Ничего лишнего
9	Помощь в обнаружении ошибок	Подсказка, как исправить
10	Помощь и документация	Инструкция на крайний случай

UI для разных устройств (особенности):

Устройство	Размер экрана	Взаимодействие	Особенности
Десктоп	Большой (13-27″)	Мышь + клавиатура	Много информации, сложные сценарии
Планшет	Средний (7-12″)	Тач, палец, перо	Крупные элементы, учёт разных положений
Смартфон	Маленький (4-7″)	Тач, один палец	Крупные кнопки (44×44), контент снизу вверх
Смарт-часы	Очень маленький (1-2″)	Тач, голос, поворот	Минимум текста, простые действия

Пример плохого и хорошего UI (описание):

Плохой UI	Хороший UI
10 пунктов в меню	5 пунктов в меню
Белая кнопка на белом фоне	Контрастная кнопка
Текст 8px	Текст 16px
Нет обратной связи при нажатии	Кнопка меняет цвет при нажатии
Поле ввода без подписи	Поле ввода с подписью и примером
Ошибка «500 Internal Server Error»	Ошибка «Не удалось загрузить данные, попробуйте позже»

Вопрос 98.

Документирование программного обеспечения Дубл.

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

Зачем нужна документация (5 главных причин)

Причина	Объяснение	Пример из жизни
Обучение новых сотрудников	Новый разработчик или пользователь быстро входит в курс дела	Прочитал руководство программиста — через 2 дня уже делает задачи
Снижение нагрузки на поддержку	Пользователи сами находят ответы, не звонят в техподдержку	FAQ на сайте: 80% вопросов решаются без звонка
Юридическая защита	Зафиксированные требования — основа приёмки	«В ТЗ написано, что кнопка зелёная, а вы сделали красную»
Передача проекта другому подрядчику	Новая команда понимает, куда смотреть и как всё работает	Передали проект с документацией — запустили за месяц
Сопровождение через год	Автор забыл детали, документация напоминает	Через год читаешь свой комментарий и понимаешь, зачем так сделано

Классификация документации по аудитории

Аудитория	Виды документации	Язык	Формат	Пример фразы
Конечные пользователи	Руководство пользователя, быстрый старт, FAQ, подсказки в интерфейсе	Простой, без технического жаргона	PDF, встроенная справка, видео	«Нажмите кнопку «Вход», введите логин и пароль»
Администраторы	Руководство администратора, инструкция по установке, настройке, бэкапам, мониторингу	Технический, но без кода	PDF, Wiki, Confluence	«Установите Docker, выполните docker-compose up -d»
Разработчики	Архитектурная документация, описание API, комментарии в коде, ADR, руководство программиста	Технический, профессиональный	Wiki, Javadoc, Swagger, Markdown	«Класс User имеет методы login(), logout(), getProfile()»
Менеджеры / заказчик	ТЗ, SRS, план проекта, отчёты, презентации	Бизнесовый, управленческий	Word, Excel, PowerPoint	«Бюджет проекта — 5 миллионов рублей, срок — 6 месяцев»

Виды документации по времени создания

Вид	Когда создаётся	Кто пишет	Пример	Почему важно
Упреждающая	До начала разработки	Аналитик, архитектор	Техническое задание (ТЗ), архитектурная документация	Фиксирует договорённости, без неё непонятно, что делать
Сопутствующая	В процессе разработки	Разработчики, техпис	Комментарии в коде, API-документация (Swagger), ADR	Всегда актуальна, потому что создаётся вместе с кодом
Реактивная	После завершения разработки	Техпис, QA	Руководство пользователя, релизные заметки	Нужна для пользователей, но риск устаревания

Что такое «живая документация» (документация, которая не устаревает)

Подход	Как работает	Примеры инструментов	Эффективность	Почему не устаревает
Документация из кода	Комментарии в коде → автоматическая генерация HTML-документации	Javadoc (Java), Doxygen (C++, C, Java, Python), Sphinx (Python)	Высокая	Документация рядом с кодом, обновляется вместе с ним
Документация как код	Текстовые файлы в репозитории (Markdown, reStructuredText), версионируются через Git	MkDocs, Sphinx, GitBook, GitHub Wiki	Высокая	Хранится в Git, можно делать code review изменений
API из спецификации	Спецификация (OpenAPI) → автоматическая генерация и документации, и кода, и клиентских библиотек	Swagger/OpenAPI, Postman (документация из коллекции)	Очень высокая	Единый источник правды, код и документация генерируются из одного файла
Тесты как документация	Тесты показывают, как использовать код (хорошие названия тестов, BDD-сценарии)	pytest (с хорошими именами), Cucumber (BDD), JBehave	Средняя (требует дисциплины)	Тесты всегда актуальны, иначе они падают

Структура руководства пользователя (классическая, 10 разделов)

Раздел	Что содержит	Пример
1. Введение	Назначение программы, для кого она, основные возможности	«Программа предназначена для учёта товаров в розничном магазине»
2. Системные требования	Какие компьютер, ОС, память, диск, экран нужны	«Windows 10/11, 4 ГБ RAM, 100 МБ свободного места»
3. Установка и запуск	Как установить, как запустить в первый раз	«Скачайте setup.exe с сайта, запустите, следуйте инструкции мастера установки»
4. Обзор интерфейса	Скриншот с подписями всех элементов (меню, кнопки, поля)	«1 — кнопка «Вход», 2 — поле ввода логина, 3 — поле ввода пароля»
5. Основные операции (типовые задачи)	Пошаговые инструкции для самых частых действий	«Как добавить товар: нажмите + → введите название и цену → сохранить»
6. Настройки	Как изменить параметры под себя	«Как сменить язык интерфейса: настройки → язык → русский»
7. Часто задаваемые вопросы (FAQ)	Типичные проблемы и их решения	«Что делать, если забыл пароль? Нажмите «Забыли пароль», следуйте инструкции»
8. Сообщения об ошибках	Список ошибок, что они означают, что делать	«Ошибка 404 — страница не найдена. Проверьте адрес или вернитесь на главную»
9. Глоссарий	Объяснение терминов, которые могут быть непонятны	«API — способ общения программы с другими программами»
10. Алфавитный указатель	Быстрый поиск терминов по страницам	«Кнопка — 15, Корзина — 23, Оплата — 45, Скидка — 67»

Инструменты для создания документации (подробное сравнение)

Инструмент	Тип документации	Плюсы	Минусы	Цена	Для кого
Confluence	Корпоративная вики	Мощный, интеграция с Jira, шаблоны, комментарии, версионирование	Тяжёлый, медленный, платный	От $5/мес за пользователя	Крупные компании (Atlassian-экосистема)
GitHub Wiki	Простая вики в репозитории	Бесплатно, просто, хранится в Git	Базовые функции (нет поиска по всей вики, нет версионирования страниц)	Бесплатно	Open Source, маленькие проекты
MkDocs	Сайт документации из Markdown	Бесплатно, красивые темы, быстрый, версионируется в Git	Нужно настроить (Python, pip, конфиг), требует хостинга	Бесплатно (open source)	Техническая документация, API
ReadTheDocs	Хостинг для MkDocs/Sphinx	Бесплатно для Open Source, автосборка из Git, версионирование версий	Требует настройки, платный для приватных проектов	Бесплатно (open source) / платно (private)	Open Source проекты
Sphinx	Документация Python (и не только)	Очень мощный, перекрёстные ссылки, индексы, поддержка reStructuredText	Крутая кривая обучения, сложная настройка	Бесплатно (open source)	Крупные проекты (например, документация самого Python)
Swagger/OpenAPI	Документация REST API	Интерактивная (можно отправлять запросы), генерирует клиентский код	Требует аннотаций в коде или отдельного YAML-файла	Бесплатно (open source)	REST API
Javadoc	Документация Java из комментариев	Автоматическая генерация из кода, всегда актуальна	Только для Java, скучный внешний вид	Бесплатно	Java-проекты
Doxygen	Документация C++, C, Java, Python, и ещё 20+ языков	Поддерживает много языков, генерирует диаграммы	Сложный в настройке, громоздкий	Бесплатно (open source)	Крупные проекты на C++
Notion	База знаний	Красивый, интуитивно понятный, гибкий	Не специализирован для технической документации, нет версионирования	Бесплатно (базовый) / платно (команда)	Стартапы, маленькие команды
Google Docs	Текстовые документы	Простой, доступный, совместная работа в реальном времени	Неудобно для больших документов, нет версионирования для разработчиков	Бесплатно (до 15 ГБ) / платно	Пользовательская документация (PDF)

Чек-лист хорошей документации (что проверить перед публикацией)

№	Проверка	Вопрос себе	Пример нарушения	Как исправить
1	Актуальность	Соответствует ли документация последней версии программы?	Кнопка «Сохранить» слева (а на самом деле справа)	Обновлять документацию при каждом релизе
2	Полнота	Описаны ли все функции? Есть ли оглавление?	Про функцию «Поиск» ни слова	Добавить раздел, сделать оглавление
3	Понятность	Поймёт ли целевой читатель (не разработчик)?	«Для аутентификации используйте базовую авторизацию»	«Введите логин и пароль»
4	Наглядность	Есть ли скриншоты, схемы, примеры?	Только текст, ни одной картинки	Добавить скриншоты с подписями
5	Поиск	Можно ли быстро найти нужный раздел?	100 страниц без оглавления и указателя	Добавить оглавление, алфавитный указатель
6	Структура	Логично ли разбита на разделы?	Всё в одном файле, разделы не выделены	Разбить на главы, добавить подзаголовки
7	Орфография	Нет ли опечаток и грамматических ошибок?	«Прогамма выводит ошибку»	Проверить орфографию (Word, Grammarly)

Типичные ошибки в документации и их последствия

Ошибка	Как выглядит	Почему плохо	Последствие	Как исправить
Устаревшая информация	«Кнопка «Сохранить» находится в левом верхнем углу» (а её там уже нет)	Пользователь ищет кнопку, не находит, злится	Звонки в поддержку, негативные отзывы	Обновлять документацию при каждом релизе
Очевидные вещи	«Здесь вы видите главное окно программы. В главном окне есть меню. Меню содержит пункты…»	Засоряет документ, пользователь теряет внимание	Пользователь не читает дальше, пропускает важное	Писать только то, что не очевидно
Слишком технический язык	«В случае возникновения исключительной ситуации NullPointerException отображается модальное окно»	Пользователь не понимает	Игнорирует, звонит в поддержку	«Если программа не может найти данные, появляется окно с сообщением «Ошибка»»
Отсутствие структуры	100 страниц текста подряд, без оглавления, глав, нумерации страниц	Нельзя найти нужное	Пользователь бросает читать	Добавить оглавление, разбить на главы
Размытые скриншоты	Скриншот 200×150 пикселей, не видно, что на нём подписано	Бесполезен	Пользователь не понимает, о чём речь	Скриншот с хорошим разрешением, обрезать лишнее, подписи стрелками
Нет алфавитного указателя	В конце 100-страничного документа нет указателя	Нельзя быстро найти термин	Пользователь листает вручную	Добавить алфавитный указатель
Документация в одном экземпляре	Только PDF на сайте, нет встроенной справки	Пользователь вынужден переключаться между окнами	Неудобно, снижает эффективность	Встроенная справка (F1), подсказки в интерфейсе

Пример хорошей и плохой документации (сравнение)

Плохая документация (что не так):

«Наша программа очень удобная. Вы можете добавлять товары. Для этого нужно нажать на кнопку. Товары добавляются в корзину. Корзина находится в правом верхнем углу. Цена товара рассчитывается автоматически. Если у вас возникли проблемы, обратитесь в техподдержку.»

Анализ ошибок:

Нет структуры (всё сплошным текстом)
Непонятно, что за кнопка (не названа)
Нет пошаговых инструкций
Нет скриншотов
Нет разделения на задачи

Роли и ответственность в документировании

Роль	Что документирует	Как часто обновляет	Ответственность
Аналитик	Техническое задание (ТЗ), спецификация требований (SRS), use cases, диаграммы	По мере изменения требований	Требования зафиксированы и понятны
Архитектор	Архитектурная документация, ADR (Architectural Decision Records), диаграммы компонентов	При изменении архитектуры	Архитектура задокументирована и обоснована
Разработчик	Комментарии в коде, Javadoc/Doxygen, API-документация, руководство программиста	При каждом изменении кода	Код понятен другим разработчикам
Технический писатель	Руководство пользователя, руководство администратора, FAQ, релизные заметки	При каждом релизе	Пользователь может самостоятельно освоить продукт
QA (тестировщик)	Тест-кейсы, планы тестирования, отчёты о тестировании	При изменении функционала	Тесты воспроизводимы и понятны
DevOps	Инструкции по развёртыванию, настройке, мониторингу, бэкапам	При изменении инфраструктуры	Администратор может развернуть систему
Project Manager	План проекта, отчёты о статусе, протоколы встреч	Регулярно (еженедельно)	Команда и заказчик видят прогресс

Золотые правила документирования (памятка для разработчика и техписа)

Правило	Смысл	Пример нарушения	Как правильно
1. Пиши для человека, который будет поддерживать твой код через год	Представь, что ты ничего не помнишь	«// это цикл»	«// Обходим все товары в корзине, чтобы пересчитать общую сумму»
2. Не дублируй код в комментариях	Комментарий не должен повторять то, что и так видно	`x = x + 1 // увеличиваем x на 1`	Комментарий вообще не нужен (код очевиден)
3. Объясняй «почему», а не «что»	Код показывает «что», комментарий — «почему именно так»	`// сортируем массив`	`// Используем пузырьковую сортировку, потому что массив маленький (до 100 элементов), а код должен быть простым`
4. Обновляй документацию вместе с кодом	Устаревшая документация хуже, чем её отсутствие	Документация говорит «кнопка зелёная», а она синяя	При каждом изменении кода проверять и обновлять документацию
5. Используй автогенерацию там, где можно	Javadoc, Doxygen, Sphinx экономят время	Ручное написание HTML-документации	Комментарии в коде → генерация HTML
6. Проверяй документацию так же, как код	Code review для документации	Опечатки, устаревшие скриншоты	Включить документацию в pull request

Вопрос 99.

Тестирование программного обеспечения Дубл.

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

Стратегии тестирования (как выбирать подход):

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

Пирамида тестирования (рекомендуемое соотношение):

Уровень	% тестов	Время выполнения	Сложность поддержки	Что тестируем
Модульные (unit)	70%	Секунды	Низкая	Отдельные функции, классы
Интеграционные	20%	Минуты	Средняя	Взаимодействие модулей, БД
UI / End-to-End	10%	Десятки минут	Высокая	Полные сценарии пользователей

Уровни тестирования по объёму (детально):

Уровень	Что тестируем	Кто пишет	Длительность	Пример
Модульное (unit)	Одна функция	Разработчик	Секунды	`assert add(2,2) == 4`
Интеграционное	Два модуля вместе	Разработчик/QA	Секунды-минуты	БД + бизнес-логика
Системное	Вся программа	QA	Часы	Полный сценарий: регистрация → покупка
Приёмочное (UAT)	Решает ли бизнес-задачи	Заказчик	Дни	Бухгалтер проверяет отчёт

Метрики тестирования (как измерить качество тестирования):

Метрика	Что измеряет	Формула	Хорошее значение
Покрытие кода тестами	Какой % кода выполняется при тестах	Строки_в_тестах / Все_строки × 100%	> 70%
Плотность дефектов	Сколько ошибок на объём кода	Ошибки / 1000 строк кода	< 1
Эффективность тестов	Как много ошибок нашли тесты	Ошибки / Общее_число_ошибок_в_системе	> 80%
Автоматизированных тестов	Какой % тестов автоматизирован	Авто_тесты / Все_тесты × 100%	> 50% (для регрессии)
Время выполнения тестов	Как быстро проходят тесты	Измерить	< 10 минут (CI)

Что такое тест-кейс (правильный пример):

Поле	Значение
ID	TC-045
Название	Успешный вход с валидными учётными данными
Предусловие	Пользователь зарегистрирован, не авторизован
Шаги	1. Открыть страницу входа 2. Ввести логин «user@example.com» 3. Ввести пароль «123456» 4. Нажать кнопку «Войти»
Ожидаемый результат	Перенаправление на главную страницу, отображается приветствие «Здравствуйте, user»
Фактический результат	(Заполняется после выполнения)
Статус	Passed / Failed / Blocked
Приоритет	High

Вопрос 100.

Виды тестирования программных продуктов

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

Полная классификация видов тестирования:

1. По уровню тестирования (объёму):

Вид	Что тестируем	Кто проводит
Модульное (unit)	Отдельные функции, классы	Разработчик
Интеграционное	Взаимодействие модулей	Разработчик / QA
Системное	Вся программа целиком	QA
Приёмочное (UAT)	Решение бизнес-задач	Заказчик

2. По характеру тестирования:

Вид	Что проверяем	Инструменты	Пример
Функциональное	Работают ли функции по ТЗ	JUnit, pytest, Selenium	Кнопка «Купить» работает
Нагрузочное	Поведение под нагрузкой	JMeter, k6, Locust	1000 одновременных пользователей
Безопасности	Уязвимости, взлом	OWASP ZAP, Burp Suite	SQL-инъекции, XSS
Юзабилити	Удобство использования	Ручное тестирование, опросы	Понятна ли навигация
Регрессионное	Не сломались ли старые функции	Автоматические тесты (JUnit, Selenium)	После добавления скидок — проверка обычной покупки
Дымовое (smoke)	Запускается ли программа	Ручной запуск, простой скрипт	Не падает ли при старте

3. По способу выполнения:

Вид	Как выполняется	Плюсы	Минусы
Ручное	Человек выполняет шаги тест-кейса	Находит UI-ошибки, творческий подход	Долго, дорого, подвержено ошибкам
Автоматизированное	Скрипты выполняют тесты	Быстро, многократно, дёшево в долгосрочной перспективе	Не находит визуальные ошибки, требует поддержки

4. По знанию системы:

Вид	Что знает тестировщик	Что проверяет
Тестирование белого ящика (white box)	Знает код, архитектуру	Внутренние пути, граничные условия
Тестирование чёрного ящика (black box)	Не знает код, знает только требования	Соответствие требованиям, внешнее поведение
Тестирование серого ящика (grey box)	Знает частично	Тесты API, баз данных

5. По объекту тестирования:

Вид	Что тестируем	Пример
UI-тестирование	Графический интерфейс	Проверка расположения кнопок
API-тестирование	Программный интерфейс	POST /login возвращает 200 OK
БД-тестирование	Запросы, схемы, целостность	SELECT возвращает правильные данные
Мобильное тестирование	Приложения на iOS/Android	Жесты, повороты экрана, батарея
Встраиваемое тестирование	ПО на устройствах (микроволновки, авто)	Работа с железом, ограниченные ресурсы

6. По времени проведения:

Вид	Когда проводится	Цель
Alpha-тестирование	Внутри команды разработки	Найти баги до передачи заказчику
Beta-тестирование	Реальными пользователями (ограниченная группа)	Найти баги в реальных условиях
Приёмочное (UAT)	Перед подписанием акта приёмки	Заказчик подтверждает, что всё работает

Пример выбора видов тестирования для интернет-магазина:

Приоритет	Вид тестирования	Почему важен
1	Функциональное	Кнопка «Купить» должна работать
2	Нагрузочное	Не должно падать в чёрную пятницу
3	Безопасности	Данные карт не должны украсть
4	Юзабилити	Пользователь должен понять, как купить
5	Регрессионное	После обновления не сломать старое
6	Модульное (unit)	Для разработки

Вопрос 101.

Отладка программного обеспечения

Отладка (debugging) — это процесс поиска, анализа и исправления ошибок в программе. Тестирование обнаруживает наличие ошибки. Отладка находит её причину и устраняет. Отладка — это навык, который приходит с опытом. Хороший отладчик использует системный подход, а не «метод тыка».

Этапы отладки (полный цикл):

Этап	Что делаем	Вопросы	Пример
1. Воспроизведение	Находим способ стабильно воспроизвести ошибку	При каких условиях? Какие входные данные?	Ошибка появляется при вводе отрицательной цены
2. Локализация	Сужаем круг поиска до места в коде	В каком модуле? В какой функции? На какой строке?	Ошибка в функции `calculateTotal()`
3. Диагностика	Понимаем причину	Почему программа ведёт себя не так?	Переменная `discount` не инициализирована
4. Исправление	Вносим минимальное изменение	Что минимально изменить, чтобы исправить?	Присвоить `discount = 0` по умолчанию
5. Проверка	Убеждаемся, что ошибка исчезла и не появились новые	Запустить тест на эту ошибку, прогнать регрессию	Тест проходит, старые тесты зелёные
6. Фиксация	Коммит с понятным сообщением, обновление баг-трекера	Что написать в коммите? Закрыть баг?	`git commit -m "Исправлен баг #123: не инициализирована переменная discount"`

Методы отладки (как искать ошибку):

Метод	Как работает	Когда эффективен	Пример
Трассировка (printf debugging)	Выводим значения переменных в консоль или лог	Простые ошибки, нет отладчика	`print(f"x={x}, y={y}")`
Отладка с точками останова	Останавливаем программу, смотрим состояние	Сложные ошибки, когда есть отладчик	IDE (PyCharm, VS Code)
Пошаговое выполнение	Выполняем код по одной строке	Когда не понятно, в какой строке ошибка	Step Into, Step Over, Step Out
Наблюдение за переменными (watches)	Смотрим, как меняются переменные	Когда нужно отследить конкретную переменную	Добавили `total` в окно наблюдения
Бинарный поиск	Делим код пополам, проверяем половину	Код большой, ошибка не локализована	«Ошибка в первых 500 строках или во вторых?»
Git bisect	Git находит коммит, в котором появилась ошибка	Ошибка появилась недавно	`git bisect start; git bisect bad; git bisect good`
Утиная отладка	Объясняем ошибку утке (или коллеге)	Когда зашли в тупик	«Смотри, у меня есть функция, которая принимает цену и скидку… А, понял!»

Инструменты для отладки (по языкам):

Язык	Инструмент	Что умеет
Python	pdb, ipdb, PyCharm Debugger	Точки останова, пошаговое выполнение, просмотр переменных
Java	JDB, IntelliJ Debugger, Eclipse Debugger	Всё то же + профилирование
JavaScript	Chrome DevTools, VS Code Debugger	Отладка в браузере, работа с DOM, сеть
C/C++	GDB, LLDB, Visual Studio Debugger	Отладка низкого уровня, память, ассемблер
Веб	Chrome DevTools, React DevTools, Redux DevTools	Компоненты, состояние, сеть, производительность

Что такое логирование как инструмент отладки:

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

Уровень логирования	Когда использовать	Пример
DEBUG	Для отладки (только на тестовых стендах)	`DEBUG: user_id=123, action=login`
INFO	Информация о нормальной работе	`INFO: Пользователь 123 вошёл в систему`
WARNING	Что-то не так, но программа работает	`WARNING: Попытка входа с неверным паролем`
ERROR	Ошибка, но программа продолжает работу	`ERROR: Не удалось отправить email`
CRITICAL	Критическая ошибка, программа падает	`CRITICAL: База данных недоступна`

Типичные ошибки при отладке:

Ошибка	Что делают	Почему плохо	Как правильно
Исправление следствия, а не причины	Добавляют `try-except`, чтобы подавить ошибку	Ошибка появится снова в другом месте	Найти и исправить первопричину
Случайные изменения («метод тыка»)	Меняют код наугад, надеясь, что ошибка исчезнет	Трата времени, новые ошибки	Воспроизвести, локализовать, понять
Отладка без воспроизведения	Пытаются исправить ошибку, не повторив её	Непонятно, исправлено ли	Сначала стабильно воспроизвести
Слишком сложное исправление	Переписывают половину программы	Риск новых ошибок, трата времени	Минимальное изменение

Вопрос 102.

Сопровождение и развитие программного обеспечения

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

Виды сопровождения (повторение с новыми деталями):

Вид	% времени	Пример	Кто делает	Типичная сложность
Корректирующее	20%	Исправление бага в расчёте скидки	Разработчики	Низкая-средняя
Адаптивное	25%	Переход с PostgreSQL 11 на 15	DevOps, разработчики	Высокая
Совершенствующее	50%	Добавление экспорта в Excel	Разработчики, аналитики	Средняя-высокая
Профилактическое	5%	Рефакторинг старого модуля	Разработчики	Высокая

Процесс сопровождения (по шагам):

Шаг	Что делаем	Длительность	Кто отвечает
1	Поступление запроса (баг, идея, вопрос)	1 минута — 1 час	Техподдержка
2	Триаж (оценка)	Приоритет, сложность, ответственный	PM, лид
3	Планирование	Включение в спринт или отдельный хотфикс	PM
4	Разработка	Исправление, тесты	Разработчик, QA
5	Релиз	Выкатка на серверы или пользователям	DevOps
6	Мониторинг	Проверка, что всё работает, сбор обратной связи	QA, техподдержка

Что такое технический долг (сопроводительная часть):

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

Тип технического долга	Пример	Рост	Снижение
Дублирование кода	Одна логика в 10 местах	Медленный	Выделить общую функцию
Отсутствие тестов	Всё тестируется вручную	Быстрый	Писать тесты
Сложная архитектура	100 классов там, где нужно 10	Быстрый	Рефакторинг
Устаревшие зависимости	Используется библиотека 2015 года	Скачкообразный	Обновить
«Костыли»	Временное решение стало постоянным	Постоянный	Переписать нормально

Стратегии развития продукта (куда двигаться):

Стратегия	Что значит	Пример	Риски
Новые функции	Добавляем то, что просят пользователи	Экспорт в PDF, интеграция с CRM	Разрастание функционала
Улучшение существующего	Делаем быстрее, удобнее, стабильнее	Ускорить поиск в 2 раза	Не видно «снаружи»
Техническое переоснащение	Переписываем старые модули	Переход с устаревшего фреймворка на новый	Дорого, долго
Вывод устаревших функций	Убираем то, чем не пользуются	Отключить старую форму отчётов	Недовольство некоторых пользователей
Масштабирование	Готовим систему к росту	Переход с монолита на микросервисы	Сложность

Метрики сопровождения (как измерить эффективность):

Метрика	Что измеряет	Формула	Хорошее значение
MTTR (Mean Time To Repair)	Среднее время исправления ошибки	Суммарное время / Кол-во ошибок	< 24 часа для критических
MTBF (Mean Time Between Failures)	Среднее время между сбоями	Суммарное время работы / Кол-во сбоев	> 1000 часов
Коэффициент закрытых багов	Как быстро закрываем баги	Закрытые за месяц / Поступившие за месяц	> 80%
Удовлетворённость поддержкой	Оценка пользователей	Средняя оценка (1-5)	> 4.5
Технический долг	% времени на рефакторинг	Время на рефакторинг / Общее время	< 20%

Признаки, что продукт требует серьёзного развития или замены:

Признак	Что значит	Что делать
Рост технического долга	Всё сложнее добавлять функции	Провести рефакторинг (профилактическое сопровождение)
Устаревший стек	Технологии больше не поддерживаются	Миграция на современный стек
Новые потребности бизнеса	Программа не решает новые задачи	Добавление функций или новая версия
Высокая стоимость сопровождения	> 80% бюджета уходит на поддержку	Рассмотреть замену
Появление сильного конкурента	Рынок уходит	Крупное обновление или новый продукт

Финал жизненного цикла — вывод из эксплуатации (как правильно завершить):

Шаг	Что делаем	Зачем
1	Уведомление пользователей	Сообщить дату отключения	Чтобы пользователи подготовились
2	Миграция данных	Перенести данные в новую систему	Чтобы не потерять историю
3	Архивация	Сохранить резервную копию на случай	Если потребуется восстановить
4	Отключение	Остановить серверы, удалить приложения	Прекратить расходы на поддержку
5	Уничтожение данных	Безопасно удалить персональные данные	Выполнить требования 152-ФЗ

Engine07

Вопрос 1.

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

Вопрос 2.

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

1. По этапу жизненного цикла ПО:

2. По способу распространения:

3. По уровню интеграции:

4. По типу платформы:

5. По языку программирования:

6. По назначению (узкая специализация):

Вопрос 3.

Интегрированная среда разработки: назначение, состав, функции

Вопрос 4.

Компиляторы, интерпретаторы и трансляторы: различия

Вопрос 5.

Этапы создания программного продукта

Вопрос 6.

Жизненный цикл программного обеспечения

Вопрос 7.

Модели жизненного цикла программного обеспечения

Вопрос 8.

Понятие репозитория, коммита, ветки и слияния

Вопрос 9.

Работа с удалёнными репозиториями GitHub, GitLab, Bitbucket

Вопрос 10.

Виды ошибок в программном обеспечении

Вопрос 11.

Методы поиска и исправления ошибок в программе

Вопрос 12.

Тестирование программного обеспечения: понятие и цели

Вопрос 13.

Инструменты для тестирования программного обеспечения

Вопрос 14.

Документирование программного обеспечения

Вопрос 15.

Виды программной документации

Вопрос 16.

Требования к оформлению технической документации

Вопрос 17.

Назначение технического задания на разработку ПО

Вопрос 18.

Назначение технического задания на разработку ПО

Вопрос 19.

Пользовательская документация и руководство пользователя

Вопрос 20.

Совместная разработка программного обеспечения

Вопрос 21.

Роли участников команды разработки ПО

Вопрос 22.

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

Вопрос 23.

Средства разработки веб-приложений

Вопрос 24.

Основные требования к качеству программного обеспечения

Вопрос 25.

Понятие программного обеспечения

Вопрос 26.

Классификация программного обеспечения

Вопрос 27.

Понятие технологии разработки программного обеспечения

Вопрос 28.

Основные этапы разработки программного обеспечения

Вопрос 28.

Основные этапы разработки программного обеспечения

Вопрос 29.

Жизненный цикл программного обеспечения Дубл.

Вопрос 30.

Модели жизненного цикла программного обеспечения Дубл.

Вопрос 31.

Понятие требований к программному обеспечению

Вопрос 32.

Виды требований к программному обеспечению

Вопрос 33.

Функциональные требования к ПО

Вопрос 34.

Нефункциональные требования к ПО

Вопрос 35.

Методы сбора требований к программному обеспечению

Вопрос 36.