Билет 1. Понятие инструментальных средств разработки программного обеспечения
Инструментальные средства разработки программного обеспечения (ПО) — это специализированные программные продукты, которые используются программистами и разработчиками для создания, отладки, тестирования, анализа и сопровождения других программ. Они автоматизируют рутинные операции, повышают производительность труда и качество конечного продукта. Простыми словами, это «инструменты», с помощью которых создается программное обеспечение (как молоток и пила для столяра).
Билет 2. Классификация инструментальных средств разработки ПО
ИСР можно классифицировать по нескольким критериям:
А) По назначению (функциональности):
Редакторы кода (с подсветкой синтаксиса, автодополнением).
Компиляторы и интерпретаторы (переводят код в машинный).
Средства отладки (Debuggers) — для поиска ошибок.
Профилировщики — для анализа производительности.
Системы сборки (Make, Gradle) — автоматизируют сборку проекта.
Средства тестирования (JUnit, Selenium).
Системы контроля версий (Git, SVN).
Б) По уровню интеграции:
Локальные средства (отдельные редакторы, компиляторы).
Интегрированные среды разработки (IDE) — объединяют большинство инструментов в одном окне.
Средства для платформ (под конкретную ОС: Windows, Linux) или кроссплатформенные.
В) По модели распространения:
Проприетарные (платные: IntelliJ IDEA Ultimate, Visual Studio).
Свободные / Open Source (VS Code, Eclipse, NetBeans).
Билет 3. Интегрированная среда разработки (IDE): назначение, состав, основные функции
Назначение IDE: Обеспечить комфортную и эффективную работу программиста, собрав всё необходимое в одном месте («всё включено»), чтобы не переключаться между разными программами.
Состав (типичные компоненты):
Редактор исходного кода (с подсветкой, подсказками).
Компилятор или интерпретатор.
Отладчик (Debugger) — для пошагового выполнения и просмотра переменных.
Средства автоматизации сборки (кнопка «Run/Build»).
Основные функции:
Редактирование (умный ввод кода, рефакторинг).
Компиляция / интерпретация и компоновка.
Запуск программы в среде.
Отладка (точки остановки, просмотр стека вызовов).
Навигация по проекту (быстрый переход к классам, методам).
Интеграция с системами контроля версий (Git).
Подсветка синтаксиса и статический анализ ошибок «на лету».
Билет 4. Компиляторы, интерпретаторы и трансляторы: назначение и различия
Общее: Все они переводят код, понятный человеку (исходный), в машинный код (или байт-код), который может выполнить компьютер.
Транслятор — это общее понятие для любой программы, переводящей код с одного языка на другой. Компиляторы и интерпретаторы — это частные случаи трансляторов.
Компилятор:
Назначение: переводит всю программу целиком в исполняемый файл (.exe, .bin) до начала запуска.
Различия: работает «в один этап» → создает отдельный файл, который можно запускать без исходного кода. Программа работает быстрее, но компиляция может быть долгой. (Примеры: C, C++, Rust, Go).
Интерпретатор:
Назначение: переводит и выполняет код построчно, прямо во время работы программы.
Различия: не создает отдельный исполняемый файл. Программа запускается сразу, но работает медленнее (каждая строка переводится «на лету»). Легче находить ошибки. (Примеры: Python, JavaScript, PHP, Ruby).
Билет 5. Этапы создания программного продукта (классический водопад)
Анализ требований: Сбор того, что хочет заказчик. Составление ТЗ.
Проектирование: Создание архитектуры, выбор технологий, проектирование базы данных и интерфейсов.
Тестирование: Проверка на ошибки, тестирование соответствия требованиям.
Внедрение: Установка продукта на серверы или компьютеры пользователя, переход в эксплуатацию.
Сопровождение: Исправление найденных после запуска ошибок, доработка под новые нужды.
Билет 6. Жизненный цикл программного обеспечения (ЖЦ ПО)
Жизненный цикл ПО — это период времени, который начинается с момента принятия решения о разработке ПО и заканчивается в момент его полного изъятия из эксплуатации.
Основные этапы ЖЦ (по стандарту ISO 12207):
Загрузка (инициализация) — идея и закупка.
Проектирование и разработка — создание кода.
Эксплуатация и сопровождение — использование программы пользователями + исправление ошибок и небольшие обновления.
Вывод из эксплуатации — отключение и замена на новую систему.
Модели ЖЦ: Каскадная (водопад), Итеративная, Гибкая (Scrum, Agile, Kanban).
Билет 7. Понятие репозитория, коммита, ветки и слияния (Git)
Репозиторий — это хранилище кода проекта (папка со специальной скрытой папкой .git). Git отслеживает все изменения внутри репозитория.
Коммит (Commit) — это «слепок» (фиксация) состояния всех файлов в конкретный момент времени. Похож на сохранение игры (save point). Каждый коммит имеет уникальный хэш и сообщение от разработчика.
Ветка (Branch) — это независимая линия разработки. Позволяет нескольким программистам работать над разными задачами (например, новая функция или исправление ошибки) одновременно, не мешая друг другу в основной ветке (обычно main или master).
Слияние (Merge) — это процесс объединения изменений из одной ветки в другую (например, добавление готовой функции из ветки feature в основную ветку main).
Билет 8. Работа с удалёнными репозиториями GitHub, GitLab, Bitbucket
Это веб-сервисы (хостинги) для хранения Git-репозиториев в облаке. Они позволяют команде работать с одним кодом из разных точек мира.
Основные действия при работе (команды Git):
Клонирование (Clone): Скопировать удалённый репозиторий к себе на компьютер (git clone <url>).
Fetch / Pull: Забрать свежие изменения от коллег с сервера.
git pull = fetch (узнать что нового) + merge (применить к своему коду).
Push: Отправить свои новые коммиты (изменения) на удалённый сервер (git push).
Различия сервисов (небольшие):
GitHub — самый популярный для опенсорса, крупное сообщество.
GitLab — часто используют компании на своих серверах, есть встроенный CI/CD (автотесты и деплой).
Bitbucket — популярен среди команд, использующих Jira и другие продукты Atlassian.
Билет 9. Виды ошибок в программном обеспечении
По времени обнаружения и природе:
А) По этапу возникновения/обнаружения:
Синтаксические ошибки: Нарушение правил грамматики языка (пропущена ;, скобка). Ловятся компилятором или редактором кода. Программа не запустится.
Ошибки времени выполнения (Runtime Errors): Программа запустилась, но во время работы упала (деление на ноль, обращение к несуществующему файлу). Пример: ZeroDivisionError.
Логические ошибки: Программа работает и не падает, но выдает неправильный результат (например, 2+2=5). Самые опасные и трудно ищемые.
Ошибки ввода-вывода — не так прочитали файл или отправили данные.
Ошибки интерфейса — кнопка не нажимается, данные с экрана ввели не туда.
Билет 10. Методы поиска и исправления ошибок в программе
Поиск (отладка / debugging):
Ручное тестирование — запуск программы и проверка на разных входных данных.
Использование отладчика (debugger) — пошаговое выполнение кода, просмотр значений переменных, точки остановки (breakpoints).
Логирование (logging) — вывод в консоль или файл промежуточных значений переменных и сообщений о состоянии программы.
Анализ стека вызовов (stack trace) — изучение цепочки вызовов функций в момент падения.
Написание юнит-тестов — автоматическая проверка каждого маленького блока кода.
Рецензирование кода (code review) — проверка кода другим разработчиком.
Статические анализаторы кода — инструменты, которые ищут потенциальные ошибки без запуска программы (SonarQube, ESLint, Pylint).
Исправление:
Воспроизвести ошибку — убедиться, что она возникает стабильно.
Локализовать место — найти строку/функцию, где ошибка проявляется.
Понять причину — почему это происходит.
Исправить код — внести минимальные изменения.
Протестировать заново — убедиться, что ошибка исчезла и не появилась новая (регрессия).
Билет 11. Тестирование программного обеспечения: понятие и целиПонятие: Тестирование ПО — это процесс проверки соответствия программы заявленным требованиям путём наблюдения за её работой в контролируемых условиях. Цели тестирования (по Мейерсу): Найти ошибки — основная цель (успешный тест — тот, который нашёл ошибку). Убедиться, что программа работает правильно — подтверждение соответствия требованиям. Повысить уверенность в качестве — снижение рисков. Предотвратить регресс — убедиться, что новые изменения не сломали старую функциональность. Оценить надёжность и производительность.Билет 12. Инструменты для тестирования программного обеспечения
1. Для модульного тестирования (Unit testing):
JUnit (Java), pytest (Python), Jest (JavaScript), NUnit (.NET).
Cypress — современный инструмент для E2E-тестирования веба.
3. Для нагрузочного тестирования:
JMeter, LoadRunner, Gatling.
4. Для управления тестированием (баг-трекинга):
Jira, YouTrack, Trello, Redmine.
5. Инструменты CI/CD (непрерывная интеграция):
Jenkins, GitLab CI/CD, GitHub Actions — запускают автотесты при каждом коммите.
6. Статические анализаторы:
SonarQube, ESLint, Checkstyle, Pylint.
Билет 13. Документирование программного обеспечения
Понятие: Документирование ПО — это процесс создания текстовых материалов, описывающих различные аспекты программы: архитектуру, установку, использование, API, процесс разработки.
Цели документирования:
Обеспечить понимание программы между участниками команды.
Упростить сопровождение и развитие ПО.
Помочь пользователям работать с программой.
Зафиксировать требования и принятые решения.
Виды документации (по назначению):
Техническая (для разработчиков, администраторов).
Пользовательская (для конечных пользователей).
Процессная (планы, отчёты, ТЗ).
Билет 14. Виды программной документации
1. Техническая документация (для разработчиков и админов):
Техническое задание (ТЗ).
Архитектурная документация (диаграммы, описание компонентов).
Спецификация API (Swagger/OpenAPI, REST-документация).
Инструкция по развёртыванию (деплою) и настройке.
Документация по сборке и конфигурации.
Описание базы данных (ER-диаграммы, схема).
Код-комментарии и автогенерируемая документация (JavaDoc, Doxygen, Sphinx).
2. Пользовательская документация (для пользователей):
Руководство пользователя (User manual).
Краткое руководство (Quick start).
FAQ (частые вопросы и ответы).
Руководство администратора.
3. Процессная и управленческая документация:
План проекта, график работ.
Отчёты об ошибках, тест-планы, протоколы тестирования.
Соглашения по стилю кода (Code conventions).
Билет 15. Требования к оформлению технической документации
Основные требования (часто по ГОСТ 19.xxx — ЕСПД, или ISO/IEC):
Полнота — документ должен описывать все необходимые аспекты без пропусков.
Точность и однозначность — каждое утверждение можно понять только одним способом (без «обычно», «как правило», если нет чётких условий).
Актуальность — документация должна соответствовать текущей версии ПО.
Структурированность — деление на разделы, подразделы, нумерация, оглавление.
Читаемость — чёткий язык, краткие предложения, терминология без разночтений.
Единообразие — оформление по единому шаблону (шрифты, отступы, стиль кода).
Наличие иллюстраций — схемы, диаграммы, скриншоты для сложных моментов.
Контроль версий — каждый документ должен иметь дату создания, автора, номер версии и историю изменений.
Билет 16. Назначение технического задания (ТЗ) на разработку ПО
Техническое задание (ТЗ) — это основной документ, который определяет требования к разрабатываемому программному продукту.
Назначение ТЗ:
Единое понимание — согласовать ожидания между заказчиком и разработчиком.
Основа для проектирования — от ТЗ отталкиваются архитекторы и программисты.
Юридическая значимость — в договорной разработке ТЗ является приложением к договору; по нему принимается работа.
Критерий приёмки — готовность продукта проверяется на соответствие ТЗ.
Базис для изменений — любое новое требование в ходе разработки должно менять ТЗ.
Билет 17. Структура технического задания (типовые разделы)
Введение (наименование, область применения, краткая характеристика).
Основания для разработки (документ-основание, утвердивший орган).
Назначение разработки (зачем нужен продукт, проблемы, которые решает).
Требования к программе:
Требования к функциональным характеристикам (что должна делать программа — перечень функций).
Требования к надёжности.
Условия эксплуатации (ОС, железо, сеть).
Требования к составу и параметрам технических средств.
Требования к информационной и программной совместимости (с чем взаимодействует).
Требования к маркировке, упаковке (если дистрибутив).
Требования к защите информации (если нужно).
Требования к программной документации (состав документов).
Порядок контроля и приёмки (как будут принимать, кто, какие тесты).
Приложения (макеты экранов, форматы данных, протоколы).
Билет 18. Пользовательская документация и руководство пользователя
Пользовательская документация — это совокупность документов, предназначенных для конечных пользователей ПО (не программистов). Она объясняет, как установить, настроить и использовать программу для достижения целей пользователя.
Руководство пользователя (User Manual) — основной документ пользовательской документации.
Что обычно включает руководство пользователя:
Введение — о программе, её возможностях, кому предназначена.
Установка и настройка — как поставить, как ввести лицензию, какие настройки задать.
Быстрый старт (Quick Start) — основные действия, чтобы начать работать за 5 минут.
Описание интерфейса — главное окно, меню, панели инструментов, горячие клавиши.
Пошаговые инструкции — как выполнить типовые задачи (создать отчёт, добавить клиента, распечатать).
Описание сообщений об ошибках — что означают сообщения, как их исправить.
FAQ (Часто задаваемые вопросы) — ответы на популярные проблемы.
Глоссарий — объяснение специфических терминов.
Алфавитный указатель — чтобы быстро найти нужный раздел.
Требования к руководству пользователя:
Понятный непрофессионалу язык (без терминов «компилятор», «интерфейс» — либо с пояснением).
Много скриншотов и примеров.
Чёткая структура с оглавлением.
Логика «по действию» (что пользователь хочет сделать), а не «по кнопкам».
Билет 19. Совместная разработка программного обеспечения
Совместная разработка (коллаборативная разработка) — это процесс создания ПО, в котором участвуют несколько разработчиков (или команд), работающих над одной кодовой базой одновременно, часто географически удалённо.
Ключевые принципы:
Использование систем контроля версий (Git, SVN) — чтобы изменения не конфликтовали.
Code review — проверка кода коллегами перед слиянием.
Разделение на задачи (через баг-трекеры: Jira, Trello).
Соглашение о стиле кода и архитектурные стандарты.
Регулярная интеграция (CI/CD) — чтобы «интеграционный ад» не случился в конце проекта.
Инструменты для совместной разработки:
Git + GitHub / GitLab / Bitbucket.
Мессенджеры (Slack, Discord, Telegram) и видеосвязь.
Системы управления задачами (см. ниже).
Документация в вики (Confluence, Notion, Wiki).
Билет 20. Роли участников команды разработки ПО
Типичные роли (могут совмещаться в небольших командах):
Заказчик / Product Owner (PO) — владелец продукта. Ставит цели, определяет требования, расставляет приоритеты. Отвечает за «что делать».
Менеджер проекта (Project Manager, PM) — планирует сроки, управляет ресурсами, коммуницирует с заказчиком, снимает блокеры.
Аналитик (Business Analyst, System Analyst) — переводит пожелания заказчика в чёткие технические требования, прорабатывает логику работы, создаёт ТЗ и user stories.
Архитектор ПО (Software Architect) — проектирует высокоуровневую структуру системы, выбирает технологии, решает, как система будет работать внутри (её «скелет»).
Разработчик / Программист (Developer) — непосредственно пишет код.
Backend-разработчик — серверная часть, базы данных, API.
Frontend-разработчик — интерфейс, то, что видит пользователь.
Администратор баз данных (DBA) — проектирует и оптимизирует БД.
Технический писатель (Technical Writer) — создаёт документацию (руководства пользователя, API-документацию).
Билет 21. Системы управления задачами в разработке ПО
Определение: Система управления задачами (Task Tracker, Issue Tracker, Bug Tracker) — это программный инструмент для создания, назначения, отслеживания статуса и приоритета задач в процессе разработки.
Основные функции:
Создание задачи (тикета) с заголовком, описанием, приоритетом, исполнителем.
Назначение статусов (Открыта → В работе → На проверке → Готово).
Прикрепление файлов, комментариев, связей между задачами.
Планирование спринтов (итераций) и оценка времени.
Доски с колонками (Kanban / Scrum).
Отчёты и диаграммы (бёрндаун, скорость команды).
Популярные инструменты:
Jira — стандарт для крупных команд (Scrum, Kanban).
Trello — простые доски, подходит для малых проектов.
YouTrack от JetBrains — гибкая система с мощным поиском.
Redmine — бесплатная, настраиваемая.
Asana, ClickUp — более универсальные для любых задач.
API: REST (через HTTP), GraphQL, WebSockets (для чатов).
Вспомогательные средства (DevOps для веба):
Контейнеризация: Docker.
CI/CD: GitLab CI, GitHub Actions, Jenkins.
Сервера и хостинг: Nginx, Apache, AWS, Heroku, Vercel (для фронта).
Билет 23. Основные требования к качеству программного обеспечения
Качество ПО оценивается по множеству характеристик. Ключевые (по стандарту ISO 25010):
Функциональная пригодность (Functional Suitability) — программа делает то, что обещано (точность, полнота функций).
Надёжность (Reliability) — работает без сбоев, устойчива к ошибкам, есть восстановление после сбоев.
Производительность и эффективность (Performance Efficiency) — быстрая реакция, мало потребляет ресурсов (памяти, CPU).
Удобство использования (Usability) — понятный интерфейс, лёгкость обучения, защита от ошибок пользователя.
Безопасность (Security) — защита от несанкционированного доступа, утечек данных.
Совместимость (Compatibility) — работает с другим ПО и оборудованием.
Сопровождаемость (Maintainability) — код легко читать, модифицировать, тестировать (это про «чистый код»).
Переносимость (Portability) — легко установить на разные ОС и окружения (Windows, Linux, Mac).
Билет 24. Понятие программного обеспечения
Программное обеспечение (ПО, Software) — это совокупность программ, правил и сопутствующей документации, позволяющая использовать компьютер для решения определённых задач.
Простыми словами: это невидимая часть компьютера (в отличие от «железа» — Hardware), которая управляет всеми процессами.
Три компонента ПО (расширенное определение):
Исполняемые программы — код, который процессор выполняет.
Данные — файлы, базы данных, конфигурации.
Документация — руководства, инструкции, описание архитектуры.
Билет 25. Классификация программного обеспечения
По назначению (основная классификация):
Системное ПО (System Software):
Операционные системы (Windows, Linux, macOS, Android, iOS).
Драйверы устройств.
Утилиты (антивирусы, архиваторы, средства дефрагментации).
Серверное ПО (веб-серверы, СУБД).
Прикладное ПО (Application Software):
Общего назначения: текстовые редакторы (Word), таблицы (Excel), браузеры (Chrome), графические редакторы (Photoshop).
Специального назначения: бухгалтерские системы (1С), CAD-системы (AutoCAD), медицинские информационные системы.
Игры.
Веб-приложения и мобильные приложения.
Инструментальное ПО (Development Tools):
IDE (среды разработки — VS Code, IntelliJ IDEA).
Компиляторы, интерпретаторы.
Системы контроля версий (Git).
Средства тестирования, профилировщики.
Это как раз то, о чём мы говорим в вашем проекте.
По лицензии:
Проприетарное (платное, закрытый код).
Свободное / Open Source (исходный код открыт, можно менять).
Условно-бесплатное (Shareware), Freeware (бесплатно, но код закрыт).
Билет 26. Понятие технологии разработки программного обеспечения
Технология разработки ПО — это совокупность методов, инструментов, процессов и правил, которые используются для создания программного продукта. Это не про язык программирования, а про как вы работаете от идеи до готовой программы.
Что включает технология разработки:
Модель жизненного цикла (Waterfall, Agile, Scrum, Kanban).
Методологии (например, гибкая разработка, экстремальное программирование, DevOps).
Тестирование — поиск и исправление ошибок, проверка соответствия ТЗ.
Внедрение — установка на серверы или компьютеры пользователей, переход в эксплуатацию.
Сопровождение — исправление ошибок, обнаруженных после запуска, небольшие доработки.
В гибких методологиях (Agile, Scrum) этапы не следуют строго один за другим, а повторяются маленькими итерациями (спринтами по 1-4 недели), каждая из которых включает все этапы — от требований до тестирования и рабочего кусочка продукта.
Билет 28. Жизненный цикл программного обеспечения
Жизненный цикл ПО (ЖЦ) — это период времени от возникновения идеи о создании программы до её полного вывода из эксплуатации (когда ею перестают пользоваться).
Проектирование и разработка (Development) — создание кода и тестирование.
Эксплуатация (Operation) — использование программы пользователями.
Сопровождение (Maintenance) — исправление ошибок, доработки под новые нужды.
Вывод из эксплуатации (Retirement) — отключение, замена на новую систему.
Модели ЖЦ:
Водопад (Waterfall) — фазы идут строго по очереди, возвраты назад сложны.
Итеративная (Iterative) — продукт строится постепенно, от простого к сложному.
Гибкая (Agile / Scrum) — короткие итерации, частые изменения требований.
Билет 29. Модели жизненного цикла программного обеспечения
Модель ЖЦ ПО — это абстрактное описание того, как устроен процесс разработки: в каком порядке выполняются этапы, можно ли возвращаться назад, как часто поставляется результат заказчику.
Основные типы моделей:
Каскадная (Waterfall) — последовательное выполнение этапов (классика).
Итеративная (Iterative) — разработка циклами, каждый цикл добавляет новую функциональность.
Спиральная (Spiral) — риск-ориентированная, каждый виток — анализ рисков и прототип.
V-образная (V-Model) — каскад с параллельным тестированием на каждом уровне.
Билет 30. Каскадная модель разработки ПО (Waterfall)
Суть: Этапы выполняются строго последовательно. Переход на следующий этап возможен только после полного завершения предыдущего. Возврат назад — крайне сложен (и дорог).
Схема: Требования → Проектирование → Реализация → Тестирование → Внедрение → Сопровождение
Плюсы:
Простота понимания и управления.
Чёткая документация на каждом этапе.
Легко оценивать сроки и бюджет (всё фиксировано).
Минусы:
Нельзя вернуться назад, если ошибка найдена поздно.
Заказчик видит результат только в конце.
Плохо подходит для проектов с изменяющимися требованиями.
Когда применяется: Проекты с чёткими, неизменными требованиями (например, системы управления ракетами, медицинские приборы, расчётные задачи, где ошибка недопустима).
Билет 31. Гибкие методологии разработки программного обеспечения (Agile)
Суть: Гибкие методологии (Agile) — это подход, основанный на итеративной разработке, когда продукт создаётся маленькими частями (итерациями по 1–4 недели), а требования могут меняться даже на поздних этапах.
Манифест Agile (4 ценности):
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования контракта.
Готовность к изменениям важнее следования плану.
Основные Agile-методологии:
Scrum:
Роли: Scrum-мастер, Product Owner, команда разработки.
Артефакты: Product Backlog (список требований), Sprint Backlog (задачи на итерацию).
Билет 32. Понятие требований к программному обеспечению
Требование к ПО — это конкретное, измеримое, проверяемое описание того, что система должна делать (функция) или какими свойствами обладать (качество, ограничение).
Требования отвечают на вопрос: «Что система должна делать, чтобы решить проблему пользователя?»
Важно: Ошибочные или неполные требования — самая частая причина провала проектов (около 40–60% ошибок закладываются именно на этапе требований).
Билет 33. Виды требований к программному обеспечению
По классификации IEEE 830 и ISO/IEC 25010:
Функциональные требования (Functional Requirements) — что система ДЕЛАЕТ (конкретные действия, реакции).
Нефункциональные требования (Non-Functional Requirements) — какими СВОЙСТВАМИ обладает (скорость, безопасность, удобство).
Ограничения (Constraints) — рамки проекта (бюджет, сроки, обязательная технология, законодательство).
Также выделяют:
Пользовательские требования — высокоуровневые, на языке пользователя.
Системные требования — детализированные для разработчиков.
Бизнес-требования — цели организации, ради которых затевается проект.
Билет 34. Функциональные требования к ПО
Определение: Описывают, какие действия и задачи должна выполнять система в ответ на определённые входные данные или условия.
Примеры:
«Система должна позволять пользователю создавать учётную запись, указав имя, email и пароль».
«При нажатии кнопки «Сохранить» данные должны записываться в базу данных».
«После ввода неверного пароля три раза подряд система должна блокировать учётную запись на 15 минут».
«Поиск должен возвращать все товары, соответствующие ключевому слову, отсортированные по цене».
Характеристики хорошего функционального требования: Конкретность, проверяемость (можно написать тест), однозначность.
Билет 35. Нефункциональные требования к ПО
Определение: Описывают качества и ограничения системы — как она работает, а не что делает.
Основные категории (по ISO 25010):
Производительность — время отклика (<0.5 сек), количество одновременных пользователей (1000).
Надёжность — время безотказной работы (99.9%), восстановление после сбоя.
Безопасность — шифрование данных, двухфакторная аутентификация.
Удобство использования (Usability) — новый пользователь должен освоиться за 10 минут.
Масштабируемость — добавление серверов при росте нагрузки.
Сопровождаемость — модульность, наличие комментариев в коде.
Переносимость — работа на Windows, Linux и Mac.
Пример: «Система должна обрабатывать 1000 запросов в секунду с задержкой не более 200 мс».
Билет 36. Методы сбора требований к программному обеспечению
Интервью — беседа с заказчиками и будущими пользователями по заранее подготовленным вопросам.
Анкетирование — массовый сбор информации через опросы (хорошо для большого числа пользователей).
Наблюдение — анализ того, как пользователи сейчас работают (без системы).
Анализ документов — изучение существующих регламентов, инструкций, отчётов.
Мозговой штурм — групповая генерация идей.
Создание прототипов — быстрый набросок интерфейса, чтобы пользователь «пощупал» и уточнил пожелания.
Анализ историй (User Stories) — описание задач пользователя короткими фразами: «Как <роль>, я хочу <действие>, чтобы <ценность>».
Use Cases (варианты использования) — формальное описание сценариев работы.
Билет 37. Анализ требований к программному обеспечению
Анализ требований — это этап, на котором собранная информация проверяется, структурируется, выявляются противоречия и пропуски.
Цели анализа:
Устранить неоднозначности — каждое требование должно иметь одно толкование.
Выявить конфликты — например, «очень дешёво» и «очень надёжно».
Определить приоритеты (MoSCoW: Must have, Should have, Could have, Won’t have).
Проверить реалистичность — возможно ли это в срок и бюджет.
Обнаружить скрытые требования — то, что заказчик считает «очевидным», а разработчик — нет.
Результат анализа: Проверенный и согласованный список требований, готовый к документированию.
Билет 38. Документирование требований
Документирование требований — это процесс фиксации проанализированных требований в письменном виде в формализованном или полуформализованном документе.
SRS (Software Requirements Specification) — международный аналог ТЗ по стандарту IEEE 830.
User Stories + Acceptance Criteria — в гибких методологиях (Agile): короткие карточки с критериями приёмки.
Use Case Diagram + Descriptions — диаграммы вариантов использования (UML).
Backlog — список задач и требований в Jira / Trello.
Принципы хорошего документирования: Полнота, непротиворечивость, нумерация (для отслеживания изменений), понятность всем сторонам.
Билет 39. Техническое задание на разработку программного продукта
Техническое задание (ТЗ) — это официальный документ, который полностью определяет требования к разрабатываемой программе и служит основой для проектирования, реализации, приёмки и всей юридической ответственности по контракту.
Назначение ТЗ:
Согласовать ожидания заказчика и разработчика.
Является юридическим приложением к договору.
Служит критерием приёмки (если сделано не по ТЗ — работа не принята).
Базис для оценки сроков и бюджета.
Билет 40. Структура технического задания
Введение — наименование системы, область применения, краткое описание.
Основания для разработки — документ-основание (приказ, договор), утвердивший орган.
Назначение разработки — функциональное (для каких задач) и эксплуатационное (кто будет использовать).
Требования к программе:
Требования к функциональным характеристикам (что делает — конкретные функции).
Требования к надёжности (время безотказной работы, восстановление).
Условия эксплуатации (ОС, железо, температура, сеть).
Требования к совместимости (с каким ПО и железом работает).
Требования к информационной безопасности.
Требования к эргономике и удобству использования.
Требования к программной документации — состав документов (руководство пользователя, руководство администратора, описание API).
Технико-экономические показатели — примерная стоимость, трудоёмкость, эффект от внедрения.
Стадии и этапы разработки — план-график (проектирование, кодирование, тестирование, даты контрольных точек).
Порядок контроля и приёмки — кто принимает, какие тесты проводятся, какой протокол подписывается.
Приложения — схемы данных, макеты экранов, форматы обмена, примеры расчётов.
Билет 41. Назначение спецификации требований (SRS — Software Requirements Specification)
Спецификация требований (SRS) — это формальный документ, который детально описывает все функциональные и нефункциональные требования к разрабатываемой программной системе.
Назначение SRS:
Единый источник истины — все участники проекта (заказчик, аналитики, разработчики, тестировщики) работают по одному документу.
Устранение неоднозначности — требования формулируются чётко, без вариантов толкования («скорость должна быть высокой» → «время отклика не более 0.5 секунды»).
Основа для оценки — по SRS оцениваются сроки, стоимость, ресурсы.
Базис для тестирования — тест-кейсы и критерии приёмки пишутся на основе SRS (каждое требование должно быть проверяемым).
Юридическая защита — при передаче проекта заказчику проверяется соответствие SRS.
Управление изменениями — любое новое требование официально меняет SRS, а не вносится «на словах».
Отличие от ТЗ: SRS — это международный стандарт (IEEE 830), более формализованный. В России часто используют ТЗ (ГОСТ), но суть та же.
Билет 42. Проектирование программного обеспечения
Проектирование ПО — это этап разработки, следующий за анализом требований, на котором определяется архитектура, структура и внутреннее устройство будущей программы до того, как начнётся написание кода.
Что делают на этапе проектирования:
Определяют основные компоненты системы и их взаимодействие.
Выбирают архитектурный стиль (клиент-сервер, микросервисы и т.д.).
Проектируют базы данных (схемы, таблицы, связи).
Определяют интерфейсы между модулями (API).
Выбирают технологии и языки программирования.
Разрабатывают алгоритмы для ключевых функций.
Билет 43. Основные принципы проектирования ПО
Базовые принципы хорошего проектирования:
Принцип единственной ответственности (Single Responsibility) — каждый модуль/класс должен иметь только одну причину для изменения (решает только одну задачу).
Принцип открытости/закрытости (Open/Closed) — сущности должны быть открыты для расширения, но закрыты для изменения (новую функциональность добавляем новым кодом, не переписывая старый).
Принцип подстановки Лисков (Liskov Substitution) — объекты наследников должны заменять объекты родителя без нарушения логики.
Принцип разделения интерфейсов (Interface Segregation) — не нужно заставлять класс реализовывать методы, которые он не использует (большие интерфейсы лучше разбивать на маленькие).
Принцип инверсии зависимостей (Dependency Inversion) — зависимости должны быть от абстракций (интерфейсов), а не от конкретных классов (модули высокого уровня не зависят от модулей низкого уровня).
Билет 44. Архитектура программного обеспечения
Архитектура ПО — это фундаментальная организация системы, выраженная в её компонентах, их отношениях друг с другом и с внешней средой, а также принципах, определяющих её проектирование и эволюцию.
Простыми словами: Архитектура — это «скелет» программы, её крупные блоки и то, как они общаются между собой.
Что определяет архитектура:
Из каких крупных частей состоит система (клиент, сервер, БД).
Как эти части распределены по компьютерам/серверам.
Как они взаимодействуют (сетевые протоколы, очереди сообщений).
Какие технологии используются для связи (REST, WebSockets, gRPC).
Билет 45. Виды архитектуры программного обеспечения
Основные архитектурные стили:
Монолитная (Monolithic) — все компоненты собраны в одну программу, работающую на одном сервере.
Модульная (Modular) — монолит, но внутри разбит на независимые модули.
Клиент-серверная (Client-Server) — выделены клиентская и серверная части.
Многоуровневая (N-tier / Layered) — вертикальное разделение на слои (уровни), каждый слой решает свой класс задач.
Микросервисная (Microservices) — система разбита на множество маленьких независимых сервисов, каждый работает в своём процессе.
Потоковая (Pipe-and-Filter) — данные проходят через последовательные обработчики (UNIX-конвейеры).
Одноранговая (Peer-to-Peer, P2P) — все узлы равноправны (торренты, блокчейн).
Билет 46. Модульная архитектура программного обеспечения
Модульная архитектура — это подход, при котором программа разбивается на относительно независимые, слабо связанные части — модули, каждый из которых отвечает за конкретную подзадачу.
Основные идеи:
Каждый модуль имеет чётко определённую границу и интерфейс (API для взаимодействия).
Модули можно разрабатывать, тестировать и изменять независимо (при условии сохранения интерфейса).
Один модуль можно переиспользовать в разных проектах.
Пример: Модуль авторизации (логин/пароль), модуль работы с базой данных, модуль отправки email, модуль расчёта скидок.
Преимущества:
Упрощается разработка (модули можно делить между программистами).
Легче тестировать (модульные тесты).
Упрощается сопровождение (изменили модуль — не сломали всё остальное).
Повышается переиспользование кода.
Билет 47. Клиент-серверная архитектура
Клиент-серверная архитектура — это модель взаимодействия, в которой система разделена на две части: клиент (инициирует запросы) и сервер (обрабатывает запросы и возвращает ответы).
Клиент:
Запрашивает сервисы (данные, вычисления).
Отвечает за интерфейс пользователя (UI).
Может быть «тонким» (веб-браузер — весь функционал на сервере) или «толстым» (настольное приложение, много логики на клиенте).
Сервер:
Всегда ждёт запросов.
Обрабатывает бизнес-логику, работает с БД.
Может обслуживать множество клиентов одновременно.
Онлайн-игры (игровой клиент — клиент, игровой сервер).
Плюсы: Централизованное управление данными, безопасность (логика на сервере), масштабируемость. Минусы: Сервер — единая точка отказа, требуется сетевое соединение.
Билет 48. Многоуровневая архитектура программного обеспечения
Многоуровневая архитектура — это развитие клиент-серверной модели, где система разделена на логические слои (уровни), каждый из которых решает свой тип задач. Уровни могут быть физически на разных машинах или на одной.
Классическая трёхуровневая архитектура (3-tier):
Уровень представления (Presentation Tier / UI) — интерфейс, то, что видит пользователь (веб-страницы, мобильное приложение). Только ввод/вывод.
Уровень бизнес-логики (Business Logic Tier / Application Tier / Middle Tier) — основные вычисления, правила, алгоритмы. Здесь работает сервер приложений.
Уровень данных (Data Tier) — хранение информации (база данных, файловое хранилище).
Разделение ответственности (можно менять один слой без переписывания других).
Безопасность (клиент не имеет прямого доступа к БД).
Масштабируемость (можно увеличивать мощность сервера бизнес-логики отдельно от БД).
Возможность использовать разные технологии на разных уровнях (например, Java на бизнес-уровне, PostgreSQL на уровне данных).
Билет 49. Понятие программного модуля
Программный модуль — это функционально законченный фрагмент программы, который имеет чётко определённые входные и выходные данные, может быть скомпилирован отдельно и предназначен для использования в составе более крупной системы.
Характеристики модуля:
Размер — обычно от нескольких десятков до нескольких сотен строк кода.
Интерфейс — чётко описанные входы и выходы (как с ним взаимодействовать).
Реализация (тело) — скрыта от других модулей (инкапсуляция).
Единая цель — решает одну конкретную подзадачу.
Примеры модулей:
Модуль шифрования данных (вход: открытый текст, выход: зашифрованные данные).
Модуль проверки email на валидность.
Модуль расчёта корзины интернет-магазина.
В языках программирования аналогами модулей служат: функции, классы, пространства имён (namespace), пакеты (package), библиотеки.
Билет 50. Связность и сцепление программных модулей
1. Связность (Cohesion) — показывает, насколько элементы внутри одного модуля связаны друг с другом и работают на одну цель.
Высокая связность (хорошо) — модуль решает одну чёткую задачу, все его внутренние элементы нужны только для этого.
Низкая связность (плохо) — модуль делает много разных, слабо связанных вещей (например, «Модуль всего»).
2. Сцепление (Coupling) — показывает, насколько сильно модули зависят друг от друга.
Низкое сцепление (хорошо) — модули почти независимы; изменение одного редко требует изменения других.
Высокое сцепление (плохо) — модули сильно связаны; изменение одного ломает многие другие.
Виды сцепления (от лучшего к худшему):
По данным (идеал) → По структурам данных → По управлению → По общей области → По содержимому (худшее).
Билет 51. Декомпозиция программной системы
Декомпозиция — это процесс разбиения сложной программной системы на более мелкие, простые и понятные части (модули, компоненты, подсистемы) для упрощения разработки, понимания и сопровождения.
Цели декомпозиции:
Снизить сложность (большую задачу разбить на маленькие).
Распараллелить работу (разные модули делают разные программисты).
Билет 52. Алгоритмизация в разработке программного обеспечения
Алгоритмизация — это процесс разработки алгоритмов решения задач, который предшествует написанию кода. Это этап, на котором придумывается последовательность действий, приводящая от входных данных к нужному результату, без привязки к конкретному языку программирования.
Место алгоритмизации в разработке: Проблема → Постановка задачи → Алгоритмизация (придумываем алгоритм) → Кодирование (пишем код на языке) → Тестирование.
Что даёт алгоритмизация:
Понимание сути задачи (можно обсуждать алгоритм с другими без кода).
Возможность оценить сложность и производительность (число шагов, память).
Базу для разных реализаций (один алгоритм — на Java, C++, Python).
Способы описания алгоритмов:
Словесный (на русском языке).
Блок-схема (графические символы).
Псевдокод (смесь языка и естественного языка).
На реальном языке программирования.
Билет 53. Понятие алгоритма
Алгоритм — это конечная, точная, детерминированная (однозначная) последовательность действий (команд), которая преобразует исходные данные (вход) в требуемый результат (выход) за конечное число шагов.
Свойства алгоритма (классические):
Дискретность — разбит на отдельные законченные шаги (действия).
Детерминированность (определённость) — каждая команда выполняется однозначно, без вариантов.
Результативность (конечность) — за конечное число шагов приводит к результату.
Массовость — применим к любому множеству входных данных из заданной области (не для одного конкретного числа, а для всех).
Понятность — команды понятны исполнителю (человеку или компьютеру).
Пример алгоритма: Алгоритм заваривания чая.
Вскипятить воду.
Положить заварку в чашку.
Залить кипятком.
Подождать 3 минуты.
Вынуть пакетик.
(Результат — чай готов).
Билет 54. Свойства алгоритма
Дискретность — алгоритм разбит на отдельные, законченные шаги (действия, команды). Каждый шаг выполняется строго последовательно.
Детерминированность (определённость, однозначность) — для каждого возможного набора входных данных траектория выполнения алгоритма задана однозначно. Не может быть двух вариантов толкования одной команды.
Результативность (конечность) — алгоритм должен завершать свою работу за конечное число шагов и выдавать результат. «Бесконечный алгоритм» — это не алгоритм.
Массовость — алгоритм применим не к одному конкретному набору данных, а ко всем задачам определённого класса (например, алгоритм сложения двух чисел работает для любых чисел).
Понятность — команды алгоритма должны быть понятны исполнителю (человеку или компьютеру). Нет неопределённостей вроде «сделай что-нибудь хорошее».
Билет 55. Способы записи алгоритмов
Словесный (естественно-языковой) — описание алгоритма на русском (или другом естественном) языке. Хорош для понимания на начальном этапе, но может быть неоднозначным.Пример: «Взять два числа, сложить их, результат записать в память».
Графический (блок-схемы) — описание с помощью геометрических фигур (блоков), соединённых стрелками. Нагляден, показывает поток управления. Самый популярный для обучения.
Псевдокод — формальный язык, похожий на язык программирования, но без строгих синтаксических правил. Понятен и человеку, и разработчику перед написанием реального кода.
Программный код — запись алгоритма на конкретном языке программирования (C++, Python, Java). Это конечная цель алгоритмизации — код, который выполнит компьютер.
Билет 56. Блок-схемы алгоритмов
Блок-схема — это графический способ представления алгоритма с помощью стандартных геометрических фигур (блоков), каждая из которых обозначает определённое действие. Блоки соединяются стрелками (линиями потока), показывающими порядок выполнения.
Основные элементы (ГОСТ 19.701-90):
Фигура
Название
Назначение
Овал
Терминатор (Начало/Конец)
Начало и конец алгоритма
Прямоугольник
Процесс
Выполнение действия (вычисление, присваивание)
Ромб
Решение (условие)
Ветвление (да/нет)
Параллелограмм
Ввод/Вывод
Ввод данных с клавиатуры или вывод на экран
Шестиугольник
Предопределённый процесс
Вызов вспомогательного алгоритма (подпрограммы)
Маленький кружок
Соединитель
Разрыв линии (для больших схем)
Стрелка
Линия потока
Указывает порядок выполнения блоков
Правила построения:
Схема читается сверху вниз, слева направо.
На схеме должен быть ровно один блок «Начало» и один блок «Конец».
Линии не должны пересекаться без необходимости.
В ромбе (условии) всегда два выхода: «Да» и «Нет».
Билет 57. Линейные алгоритмы
Линейный алгоритм — это алгоритм, в котором все команды (блоки) выполняются строго последовательно, одна за другой, без пропусков, повторений и ветвлений. Поток управления идёт по прямой линии.
Характерные черты:
Нет условий (ромбов).
Нет циклов.
Каждый блок выполняется ровно один раз.
Билет 58. Разветвляющиеся алгоритмы
Разветвляющийся алгоритм — это алгоритм, в котором в зависимости от выполнения некоторого условия (истина/ложь) выбирается один из нескольких возможных путей (ветвей) выполнения.
Полное разветвление (if-else):
Если условие истинно → выполняется одна ветка.
Если условие ложно → выполняется другая ветка.
Затем обе ветки сходятся.
Неполное разветвление (if без else):
Если условие истинно → выполняется действие.
Если условие ложно → действие пропускается, идём дальше.
Билет 59. Циклические алгоритмы
Циклический алгоритм — это алгоритм, в котором некоторая последовательность команд (тело цикла) выполняется многократно, пока соблюдается заданное условие (или заданное количество раз).
Три типа циклов:
Цикл с предусловием (while) — сначала проверяем условие. Если истинно — выполняем тело цикла, затем снова проверяем. Если ложно — выходим. Тело может не выполниться ни разу.
Цикл с постусловием (do-while) — сначала выполняем тело цикла, затем проверяем условие. Если условие истинно — повторяем. Тело выполнится хотя бы один раз.
Цикл со счётчиком (for) — выполняется строго заданное количество раз (от начального до конечного значения с шагом).
Обязательные элементы цикла:
Инициализация — начальные значения переменных.
Проверка условия — когда продолжать/останавливать.
Изменение параметра — чтобы условие когда-нибудь стало ложным (иначе — бесконечный цикл).
Тело цикла — повторяющиеся действия.
Билет 60. Вспомогательные алгоритмы и подпрограммы
Вспомогательный алгоритм — это алгоритм, который решает некоторую подзадачу и может быть вызван из основного алгоритма (или из другого вспомогательного) многократно.
Подпрограмма — это программная реализация вспомогательного алгоритма. В разных языках называется: функция, процедура, метод, подпрограмма.
Зачем нужны:
Избежать дублирования кода (DRY — Don’t Repeat Yourself).
Упростить основной алгоритм — разбить сложную задачу на простые шаги.
Повторное использование — написали один раз, используем во многих местах.
Упрощение тестирования — каждую подпрограмму можно проверить отдельно.
Билет 61. Основные структуры данных
Структура данных — это способ организации и хранения данных в памяти компьютера, который определяет, как данные связаны между собой и какие операции над ними возможны.
Простейшие (примитивные):
Целые числа (int)
Вещественные числа (float, double)
Символы (char)
Логический тип (bool)
Составные (классические):
Структура
Описание
Пример
Массив (Array)
Набор однотипных элементов, расположенных в памяти последовательно, доступ по индексу
[10, 20, 30, 40]
Список (List / Linked List)
Элементы связаны указателями; можно вставлять/удалять в середине
Связный список
Стек (Stack)
LIFO (Last In — First Out). Последний пришёл — первый ушёл
Стопка тарелок
Очередь (Queue)
FIFO (First In — First Out). Первый пришёл — первый ушёл
Очередь в магазине
Хеш-таблица (Hash Map / Dictionary)
Хранение пар «ключ → значение». Быстрый поиск по ключу
Телефонная книга: имя → номер
Множество (Set)
Набор уникальных элементов (без повторений)
{1, 2, 3}
Дерево (Tree)
Иерархическая структура с корнем и ветвями
Файловая система
Граф (Graph)
Вершины и рёбра между ними (связи)
Карта дорог, социальная сеть
Билет 62. Понятие базы данных в программной системе
База данных (БД) — это организованная структура, предназначенная для хранения, изменения и обработки взаимосвязанной информации в программной системе. База данных обеспечивает долговременное хранение данных (даже после выключения программы).
Роль БД в программной системе:
Хранилище данных — все данные, которые должны сохраниться между сеансами работы (пользователи, товары, заказы, статьи).
Централизованный доступ — многие клиенты (пользователи) могут работать с одними и теми же данными одновременно.
Безопасность и контроль — разграничение прав доступа, резервное копирование.
Типы БД:
Реляционные (SQL) — данные в таблицах, связанных ключами (MySQL, PostgreSQL, Oracle).
Система управления базами данных (СУБД) — это программное обеспечение, которое управляет БД (выполняет запросы, обеспечивает целостность, резервное копирование). Примеры: MySQL, PostgreSQL, Microsoft SQL Server, SQLite.
Билет 63. Проектирование базы данных для программного продукта
Проектирование БД — это процесс создания логической и физической структуры базы данных для конкретного программного продукта на основе требований к хранению данных.
Определение атрибутов (свойств) — у «Пользователя»: имя, email, пароль.
Определение связей между сущностями (один-ко-многим, многие-ко-многим).
Логическое проектирование:
Построение логической модели (ER-диаграмма).
Приведение к нормальным формам (избавление от дублирования, противоречий).
Определение первичных и внешних ключей.
Физическое проектирование:
Выбор конкретной СУБД (PostgreSQL, MySQL и т.д.).
Создание таблиц, индексов (для ускорения поиска).
Настройка типов данных и ограничений (NOT NULL, UNIQUE).
Пример (интернет-магазин):
Сущности: Пользователи, Товары, Заказы.
Связи: Один пользователь может иметь много заказов (1:N). Один заказ может содержать много товаров (M:N → нужна связующая таблица Заказы_Товары).
Нормальные формы (ключевая концепция):
1НФ — нет повторяющихся групп, все значения атомарны.
2НФ — нет частичных зависимостей от составного ключа.
3НФ — нет транзитивных зависимостей (неключевые поля не зависят от других неключевых).
Билет 64. Этапы создания пользовательского интерфейса
Пользовательский интерфейс (UI, User Interface) — это совокупность средств, с помощью которых пользователь взаимодействует с программой (экранные формы, кнопки, меню, поля ввода).
Основные этапы создания UI:
Анализ требований и исследование пользователей:
Кто будет пользоваться? (возраст, IT-грамотность).
Какие задачи решает? (user stories, сценарии использования).
Изучение конкурентов и лучших практик.
Проектирование структуры (информационная архитектура):
Карта сайта / экранов (из каких страниц/окон состоит).
Навигация (как пользователь перемещается между экранами).
Не обязательно с графикой — только структура.
Создание прототипов (от низкой до высокой детализации):
Wireframes (низкая детализация) — схема расположения блоков, без цветов и шрифтов.
Mockups (средняя детализация) — статичные макеты с цветами, типографикой.
Интерактивный прототип — кликабельная модель (Figma, Adobe XD) для тестирования.
Дизайн (визуальное оформление):
Выбор цветовой схемы, шрифтов, иконок.
Разработка компонентов (кнопки, поля ввода, карточки).
Обеспечение единого стиля (UI Kit, Design System).
Разработка (верстка / frontend-кодирование):
HTML/CSS/JavaScript (для веба) или Swift/Kotlin (для мобильных).
Реализация адаптивности (для разных размеров экранов).
Привязка интерфейса к бизнес-логике (обработка нажатий, отправка данных).
Тестирование интерфейса (Usability Testing):
Проверка на реальных пользователях (выполняют задачи, исследователь наблюдает).
Сбор обратной связи (что непонятно, что раздражает).
Исправление ошибок и итерации.
Сопровождение и обновление:
Исправление багов, найденных после запуска.
Добавление новых функций.
Анализ метрик (куда пользователи не кликают, где бросают).
Билет 65. Требования к пользовательскому интерфейсу
Пользовательский интерфейс (UI) должен соответствовать ряду требований, чтобы программа была удобной и эффективной.
Интуитивность — пользователь должен понимать, как взаимодействовать с интерфейсом, без длительного изучения инструкции (или с минимальной подсказкой).
Предсказуемость — одинаковые действия должны приводить к одинаковым результатам; элементы управления ведут себя стандартно (кнопка «Сохранить» не удаляет файл).
Обратная связь — на любое действие пользователя система должна отвечать (визуально или звуково): кнопка нажалась, идёт загрузка, данные сохранены.
Единообразие (стиль) — одинаковые элементы (кнопки, поля ввода) выглядят и ведут себя одинаково на всех экранах.
Защита от ошибок пользователя — подтверждение опасных действий («Вы уверены, что хотите удалить?»), блокировка некорректного ввода.
Эффективность — частая задача должна решаться за минимальное количество действий (горячие клавиши, шаблоны, автозаполнение).
Адаптивность — интерфейс должен корректно отображаться на разных устройствах (компьютер, планшет, телефон) и разрешениях экрана.
Доступность — интерфейс должен быть usable для людей с ограниченными возможностями (контрастность, поддержка экранных дикторов, управление с клавиатуры).
Билет 66. Принципы удобства и эргономики интерфейса
Эргономика интерфейса — это наука о том, как сделать взаимодействие человека с программой комфортным, безопасным и продуктивным.
Основные принципы:
Принцип «8 золотых правил» (Бен Шнейдерман):
Стремитесь к единообразию.
Используйте сочетания клавиш для опытных пользователей.
Обеспечьте информативную обратную связь.
Проектируйте диалог так, чтобы он имел завершение (шаги понятны).
Предотвращайте ошибки.
Разрешайте легко отменять действия (undo/redo).
Дайте пользователю чувство контроля (не «компьютер решает», а «пользователь управляет»).
Снижайте нагрузку на память (не заставляйте запоминать информацию с предыдущего экрана — показывайте её).
Закон Фиттса: Время достижения цели (курсором) зависит от расстояния до цели и размера цели. Крупные элементы (кнопки) в зоне досягаемости — хорошо.
Принцип близости (Гештальт): Связанные элементы должны располагаться рядом (например, кнопки «Сохранить» и «Отмена» — вместе).
Минимизация когнитивной нагрузки: Не заставляйте пользователя думать о том, как выполнить действие. Интерфейс должен подсказывать (серые подсказки в полях ввода, понятные иконки).
Правило трёх кликов: Любое важное действие должно быть доступно не более чем за 3 клика мыши.
Прототипирование — это процесс создания упрощённой, рабочей модели будущего интерфейса (прототипа) для проверки идей, сценариев и удобства использования до начала полноценной разработки.
Уровни прототипов:
Низкая детализация (Low-fidelity, Wireframes):
Серые схемы без цвета, шрифтов, деталей.
Прямоугольниками обозначены блоки.
Быстро, дёшево, легко менять.
Цель: проверить структуру и навигацию.
Средняя детализация (Mid-fidelity, Mockups):
Добавлены цвета, типографика, иконки.
Но нет интерактивности (статичные картинки).
Цель: утверждение визуального стиля.
Высокая детализация (High-fidelity, интерактивный прототип):
Полностью рабочий (кликабельный) макет.
Переходы между экранами, анимация.
Максимально похож на готовое приложение.
Цель: тестирование с пользователями.
Инструменты для прототипирования: Figma, Sketch, Adobe XD, Axure, Balsamiq (для низкой детализации).
Билет 68. Кодирование как этап разработки программного обеспечения
Кодирование (написание кода, реализация) — это этап жизненного цикла ПО, на котором создаётся исполняемый программный код на основе проектной документации, алгоритмов и архитектуры, разработанных на предыдущих этапах.
Место этапа кодирования: Требования → Проектирование → Кодирование → Тестирование → Внедрение
Что происходит на этапе кодирования:
Программисты пишут код на выбранных языках программирования.
Создаются модули, классы, функции согласно архитектуре.
Интегрируются сторонние библиотеки и фреймворки.
Проводится первичное тестирование (модульное, самим разработчиком).
Оформляется код в соответствии со стандартами.
Результат: Исходный код программы, который затем компилируется (или интерпретируется) и тестируется.
Билет 69. Требования к качеству программного кода
Качественный код — это не просто работающий код, а код, который легко читать, поддерживать и развивать.
Основные требования:
Читаемость (Readability) — код должен быть понятен другому разработчику (или вам самому через полгода). Понятные имена переменных, комментарии где нужно.
Сопровождаемость (Maintainability) — легко исправлять ошибки и добавлять новые функции без страха всё сломать.
Надёжность (Reliability) — код работает стабильно, обрабатывает ошибки (файл не найден, сеть отвалилась), не падает.
Эффективность (Performance) — код не тратит лишнюю память и процессорное время (нет лишних циклов, медленных операций там, где не надо).
Тестируемость (Testability) — код можно легко покрыть модульными тестами (отсутствие глобальных состояний, зависимостей, которые нельзя подменить).
Безопасность (Security) — код защищён от типовых уязвимостей (SQL-инъекции, межсайтовый скриптинг, переполнение буфера).
Документированность — для сложных участков есть комментарии; для API — формальная документация.
Билет 70. Стандарты оформления программного кода
Стандарт оформления кода — это набор правил (соглашений) о том, как писать код: отступы, имена переменных, расположение скобок, длина строки и т.д.
Зачем нужны:
Единообразие — вся команда пишет в одном стиле, легче читать чужой код.
Снижение количества ошибок (например, спутывание переменной l (L) и 1 (единица) — в шрифтах без засечек).
Упрощение код-ревью (рецензент не отвлекается на стиль, только на логику).
Примеры правил (для языка C#/Java):
Имена классов: PascalCase (MyClass).
Имена методов: camelCase (calculateSum) или PascalCase (в зависимости от языка).
Имена констант: UPPER_SNAKE_CASE (MAX_COUNT).
Отступы: 4 пробела (или табуляция — но кто-то её не любит).
Скобка открывающая: на той же строке или на новой (спорят веками).
Популярные стандарты и инструменты:
Google Java Style Guide, PEP 8 (Python), Airbnb JavaScript Style Guide.
Автоматические форматтеры: Prettier (JS), Black (Python), clang-format (C/C++).
По назначению документация делится на три большие категории:
Техническая документация — для разработчиков, администраторов, архитекторов. (API, архитектура, развёртывание).
Пользовательская документация — для конечных пользователей. (Руководство пользователя, инструкции).
Процессная и управленческая документация — для менеджеров и заказчика. (ТЗ, планы, отчёты, тест-планы).
Билет 72. Пользовательская документация
Пользовательская документация — это документы, которые объясняют, как установить, настроить и использовать программный продукт конечному пользователю (не программисту). Пишется понятным языком, без технического жаргона (или с пояснениями).
Состав пользовательской документации:
Руководство пользователя (основной документ).
Краткое руководство (Quick Start) — на 2–5 страниц.
FAQ (частые вопросы и ответы).
Руководство администратора (если пользователь может быть администратором системы).
Встроенная справка (Help — в самой программе по F1).
Требования к пользовательской документации:
Язык — простой, без сложных терминов (или с глоссарием).
Много скриншотов и примеров.
Пошаговые инструкции (сделай раз, сделай два).
Логика «по задачам» (как отправить письмо), а не «по кнопкам» (описание каждой кнопки).
Билет 73. Техническая документация
Техническая документация — это документы, предназначенные для специалистов, которые разрабатывают, сопровождают или разворачивают ПО: программистов, архитекторов, DevOps, системных администраторов.
Архитектурная документация — диаграммы компонентов, описание взаимодействия.
Спецификация API (Swagger / OpenAPI, описание REST-эндпоинтов, параметров).
Документация по базам данных (ER-диаграммы, схема таблиц).
Руководство по развёртыванию (Deployment Guide) — как установить, настроить сервер.
Руководство по сборке (Build Guide) — как скомпилировать проект из исходников.
Руководство программиста (см. ниже).
Билет 74. Руководство пользователя
Руководство пользователя (User Manual) — это основной документ из состава пользовательской документации. Он предназначен для конечного пользователя, который работает с программой в повседневной деятельности.
Структура типового руководства пользователя:
Введение — о программе, её возможностях, системе требований.
Установка и запуск — как установить, как войти.
Быстрый старт — за 5 минут сделать что-то полезное.
Описание интерфейса — главное окно, панели инструментов, меню (с иллюстрациями).
Пошаговые инструкции по выполнению основных задач:
Как создать новый документ.
Как сохранить.
Как распечатать и т.д.
Справочная информация (горячие клавиши, форматы файлов).
Сообщения об ошибках — что означает каждое сообщение и что делать.
FAQ — частые проблемы и их решение.
Алфавитный указатель — для быстрого поиска.
Билет 75. Руководство программиста
Руководство программиста (Developer’s Guide, Programmer’s Manual) — это технический документ, предназначенный для разработчиков, которые будут поддерживать, модифицировать или дорабатывать существующую программу (или подключаться к её API).
Что содержит руководство программиста:
Общее описание архитектуры — из каких модулей/компонентов состоит система, как они связаны.
Структура проекта — как организованы папки, пакеты, пространства имён.