---

1. Понятия требований, классификация.
Требование — это условие или возможность, которыми должна обладать система, чтобы удовлетворить потребности заказчика или пользователя.
Классификация:
По уровню абстракции: Бизнес-требования, требования пользователя, функциональные требования, нефункциональные требования.
По типу: Функциональные (что система делает), Нефункциональные (как система работает: производительность, безопасность, надежность).
По источнику: Внутренние (от разработчиков), Внешние (от заказчика, регуляторов).

2. Уровни требований.
Бизнес-требования: Высокоуровневые цели организации (зачем нужен проект?).
Требования пользователя: Задачи, которые пользователи должны решать с помощью системы (user stories, use cases).
Функциональные требования: Конкретные функции системы, обрабатывающие входные данные и выдающие результат.
Нефункциональные требования: Ограничения и характеристики качества (скорость, безопасность, совместимость).

3. Методологии и стандарты, регламентирующие работу с требованиями.
IEEE 830: Стандарт на спецификацию программных требований (SRS).
ISO/IEC 25010: Модель качества программного обеспечения.
BABOK (Business Analysis Body of Knowledge): Свод знаний по бизнес-анализу.
Agile/Scrum: Работа с требованиями через бэклог продукта и пользовательские истории.
RUP (Rational Unified Process): Использование UML и прецедентов.

4. Современные принципы и методы разработки программных приложений.
KISS (Keep It Simple, Stupid): Простота кода.
DRY (Don’t Repeat Yourself): Избегание дублирования кода.
SOLID: Принципы объектно-ориентированного проектирования.
Agile/DevOps: Итеративная разработка, непрерывная интеграция и доставка.
TDD (Test-Driven Development): Разработка через тестирование.

5. Методы организации работы в команде разработчиков.
Scrum: Спринты, роли (Scrum Master, Product Owner), артефакты (бэклог).
Kanban: Визуализация потока работ, ограничение WIP (work in progress).
Waterfall (Каскадная модель): Последовательное выполнение этапов.
Pair Programming: Парное программирование.
Code Review: Проверка кода коллегами.

6. Системы контроля версий.
ПО для отслеживания изменений в исходном коде.
Централизованные: SVN (Subversion).
Распределенные: Git (наиболее популярный), Mercurial.
Функции: Ветвление (branching), слияние (merging), откат изменений, история коммитов.
Платформы: GitHub, GitLab, Bitbucket.

7. Основные подходы к интегрированию программных модулей.
Big Bang Integration: Все модули собираются сразу (рискованно).
Инкрементальная интеграция: Постепенное добавление модулей.
Сверху вниз: От главного модуля к подчиненным (используются заглушки).
Снизу вверх: От низкоуровневых модулей к главным (используются драйверы).
Непрерывная интеграция (CI): Автоматическая сборка и тестирование при каждом коммите.

8. Стандарты кодирования.
Набор правил оформления кода для повышения читаемости и поддержки.
Именование переменных: camelCase, snake_case, PascalCase.
Комментирование: Документирование классов, методов, сложной логики.
Структура кода: Отступы, длина строк, размер методов.
Примеры: PEP 8 (Python), Google Java Style Guide, PSR (PHP).

9. Описание требований: унифицированный язык моделирования - краткий словарь.
UML (Unified Modeling Language) — визуальный язык для спецификации, визуализации, конструирования и документирования артефактов программных систем.
Диаграмма классов: Структура системы.
Диаграмма вариантов использования: Функциональность с точки зрения пользователя.
Диаграмма последовательности: Взаимодействие объектов во времени.
Диаграмма деятельности: Алгоритмы и бизнес-процессы.

10. Диаграммы UML.
Основные типы:
Структурные: Классов, Объектов, Компонентов, Развертывания, Пакетов.
Поведенческие: Вариантов использования, Деятельности, Состояний, Последовательности, Коммуникации, Времени.

11. Описание и оформление требований (спецификация).
SRS (Software Requirements Specification) — документ, содержащий:
Введение (цели, область применения).
Общее описание (перспектива системы, функции пользователя).
Конкретные требования (функциональные, интерфейсные, производительность, ограничения).
Приложения (глоссарий, модели данных).

12. Анализ требований и стратегии выбора решения.
Анализ: Выявление противоречий, неполноты, двусмысленности.
Стратегии выбора:
Buy vs Build: Покупка готового решения vs собственная разработка.
Outsourcing: Передача разработки внешней компании.
Open Source: Использование открытых решений.
Критерии: стоимость, время, риски, поддержка, масштабируемость.

13. Цели и задачи, и виды тестирования.
Цель: Обнаружение дефектов, подтверждение соответствия требованиям.
Виды:
По уровню: Модульное, Интеграционное, Системное, Приемочное.
По методу: Черный ящик (без знания кода), Белый ящик (с знанием кода), Серый ящик.
По типу: Функциональное, Нефункциональное (нагрузка, безопасность), Регрессионное.

14. Стандарты качества программной документации.
ISO/IEC 26514: Требования к документации пользователя.
ГОСТ 19.701-90: ЕСПД. Схема алгоритма.
ГОСТ 34.602-89: ТЗ на создание АС.
Критерии качества: Полнота, точность, ясность, непротиворечивость, актуальность.

15. Меры и метрики.
Мера: Количественная характеристика (например, количество строк кода).
Метрика: Интерпретация меры для оценки качества (например, плотность дефектов на 1000 строк кода).
Примеры: Cyclomatic Complexity (цикломатическая сложность), Code Coverage (покрытие кода тестами), Lead Time (время выполнения задачи).

16. Тестовое покрытие.
Процент кода или требований, проверенных тестами.
Покрытие операторов: Выполнена ли каждая строка кода.
Покрытие ветвей: Пройдены ли все условия if/else.
Покрытие путей: Пройдены ли все возможные маршруты выполнения.
Цель: Обычно 80-90% покрытия считается хорошим показателем.

17. Тестовый сценарий.
Последовательность действий для проверки конкретной функции.
Структура:
ID сценария.
Название.
Предусловия.
Шаги выполнения.
Ожидаемый результат.
Фактический результат.
Статус (Passed/Failed).

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

19. Анализ спецификаций.
Проверка документа требований на:
Полноту: Все ли требования учтены.
Непротиворечивость: Нет ли конфликтов между требованиями.
Однозначность: Каждое требование имеет только одну трактовку.
Проверяемость: Можно ли написать тест для каждого требования.
Трассируемость: Связь требований с дизайном и тестами.

20. Верификация и аттестация программного обеспечения.
Верификация: «Мы делаем продукт правильно?» (соответствие техническим спецификациям, стандартам кодирования).
Валидация (Аттестация): «Мы делаем правильный продукт?» (соответствие потребностям пользователя).
Аттестация: Официальное подтверждение соответствия ПО установленным требованиям (часто государственными органами).

21. Жизненный цикл программного обеспечения. Краткая характеристика каждого этапа.
Анализ требований: Сбор и документирование требований.
Проектирование: Архитектура, дизайн БД, интерфейсов.
Реализация (Кодирование): Написание кода.
Тестирование: Поиск и исправление дефектов.
Внедрение: Установка у пользователя, обучение.
Сопровождение: Исправление ошибок, обновления, поддержка.

22. Разработка пользовательских интерфейсов. Типы пользовательских интерфейсов и этапы их разработки.
Типы: CLI (командная строка), GUI (графический), Web UI, Mobile UI, Voice UI.
Этапы:
Исследование пользователей (persona, user journey).
Прототипирование (wireframes, mockups).
Дизайн (UI kit, цвета, шрифты).
Верстка и реализация.
Usability-тестирование.

23. Техническое задание. Разделы, входящие в техническое задание.
Согласно ГОСТ 34.602-89:
Общие сведения.
Назначение и цели создания.
Характеристика объектов автоматизации.
Требования к системе (функции, надежность, эргономика).
Состав и содержание работ по созданию системы.
Порядок контроля и приемки.
Требования к составу и содержанию работ по подготовке объекта автоматизации.
Требования к документированию.

24. Использование языка UML при проектировании сложных программных систем.
UML позволяет:
Визуализировать архитектуру системы.
Документировать структуру и поведение.
Генерировать код (forward engineering) и восстанавливать диаграммы из кода (reverse engineering).
Обеспечивать единое понимание проекта всеми участниками команды.

25. Диаграмма вариантов использования, ее назначение. Правила построения диаграммы вариантов использования.
Назначение: Описание функциональных требований с точки зрения актеров (пользователей).
Элементы:
Актер: Роль пользователя.
Прецедент (Use Case): Овальная фигура, описывающая действие.
Связи: Association (актер-прецедент), Include (обязательное включение), Extend (расширение), Generalization (наследование).
Правила: Каждый прецедент должен иметь имя, активного инициатора, четкие границы системы.

26. Понятие класса и объекта. Атрибут и операция.
Класс: Шаблон или чертеж, описывающий структуру и поведение объектов.
Объект: Экземпляр класса, существующий в памяти во время выполнения программы.
Атрибут: Данные (свойства) объекта (например, name, age).
Операция (Метод): Действие, которое может выполнять объект (например, calculateSalary()).

27. Диаграмма потоков данных. Основное назначение.
DFD (Data Flow Diagram) показывает, как данные перемещаются через систему.
Элементы:
1) Процесс (круг/прямоугольник со скругленными углами).
2) Поток данных (стрелка).
3) Хранилище данных (две параллельные линии).
4) Внешний субъект (квадрат).
5) Назначение: Анализ функциональности системы без привязки к технологии реализации.

28. Основные принципы структурной методологии. Особенности структурных программ. Цели структурного программирования.
Принципы:
1) Нисходящее проектирование (разбиение на подзадачи).
2) Модульность.
3) Использование трех базовых структур: следование, ветвление, цикл.
Цели: Повышение читаемости, упрощение отладки, снижение сложности.
Особенности: Отсутствие goto, четкая иерархия функций.

29. Модульное программирование (определение). Цели модульного программирования. Достоинства модульного программирования.
Определение: Разделение программы на независимые модули (файлы, библиотеки).
Цели: Упрощение разработки, повторное использование кода.
Достоинства:
1) Изоляция ошибок.
2) Возможность параллельной разработки.
3) Легкость тестирования отдельных частей.
4) Упрощение поддержки.

30. Объектно-ориентированное программирование. Основные понятия.
Объект: Экземпляр класса.
Свойство: Данные объекта.
Метод: Функция объекта.
Событие: Сигнал о изменении состояния.
Класс: Тип объекта.
Методы ООП:
Декомпозиция: Разбиение системы на объекты.
Абстрактные типы данных: Сокрытие реализации.
Пересылка сообщений: Взаимодействие объектов через вызов методов.

31. Надежность программного изделия. Работоспособность программного изделия. Основные количественные показатели надежности.
Надежность: Способность выполнять функции в заданных условиях.
Работоспособность: Состояние, при котором ПО выполняет основные функции.
Показатели:
MTBF (Mean Time Between Failures) — среднее время наработки на отказ.
MTTR (Mean Time To Repair) — среднее время восстановления.
Вероятность безотказной работы.

32. Определение тестирования и отладки. Особенности и объекты тестирования. Автономное и комплексное тестирование.
Тестирование: Процесс выполнения ПО с целью нахождения ошибок.
Отладка: Процесс поиска и исправления найденных ошибок.
Объекты тестирования: Код, документация, интерфейс, БД.
Автономное (модульное): Тестирование отдельных функций/классов.
Комплексное (интеграционное): Тестирование взаимодействия модулей.

33. Управление разработкой программных средств. Средства управления проектами. Основная цель управления жизненным циклом.
Цель: Обеспечение сдачи проекта в срок, в рамках бюджета и с требуемым качеством.
Средства: Jira, Trello, Asana, Microsoft Project.
Задачи: Планирование, оценка рисков, контроль ресурсов, коммуникация.

34. Инструментальные средства разработки программ. CASE-средства. Интегрированные среды.
IDE (Integrated Development Environment): VS Code, IntelliJ IDEA, PyCharm (редактор, компилятор, отладчик).
CASE-средства (Computer-Aided Software Engineering): Enterprise Architect, Visual Paradigm (для моделирования UML, DFD).
Системы сборки: Maven, Gradle, Make.

35. Оценка качества программного обеспечения. Методы оценки свойств.
Модель ISO 25010: Функциональная пригодность, производительность, совместимость, usability, надежность, безопасность, сопровождаемость, переносимость.
Методы: Статический анализ кода (SonarQube), динамическое тестирование, экспертная оценка, метрики кода.

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