экзамен 1

Карточки
Бесплатно
Снежана Трофимова
Снежана Трофимова
•
45 карт
Для практиков
Понятные определения
Учите эффективно и запоминайте надолго
Просмотр
45 карт
Демо-обучение: 1 из 10
Последнее обновление: июль 2026
Демо-обучение
1/10
Термин / Вопрос
...
Перевод / Ответ
...
Пробел - переворот, клик по карточке - переворот. Ответ можно выбирать сразу.
← Не знаю
Легко →

Просмотр

Термин / Вопрос
1. Жизненный цикл ПО: этапы и основные модели разработки (каскадная, итерационная, спиральная).
Перевод / Ответ
Этапы: анализ требований, проектирование, разработка, тестирование, внедрение, сопровождение. Каскадная модель — последовательный переход между этапами без возврата. Итерационная — разработка циклами с получением рабочего фрагмента в конце каждой итерации. Спиральная — итерации с оценкой рисков на каждом витке перед переходом к следующему этапу.
Термин / Вопрос
2. Роль и цели моделирования в процессе разработки ПО.
Перевод / Ответ
Роль: выступает языком коммуникации между заказчиком и командой, позволяет визуализировать систему до написания кода. Цели: выявление противоречий в требованиях, упрощение сложной логики, планирование архитектуры, снижение рисков ошибок на поздних стадиях.
Термин / Вопрос
3. Стандарты моделирования: краткая характеристика и сравнение UML и IDEF.
Перевод / Ответ
UML (Unified Modeling Language) — стандарт для объектно-ориентированного моделирования ПО (диаграммы классов, последовательностей и др.). IDEF — семейство стандартов для функционального и процессного моделирования бизнеса (например, IDEF0 для функций). UML ориентирован на структуру и поведение ПО, IDEF — на бизнес-логику и потоки данных.
Термин / Вопрос
4. Инструментальные средства моделирования ПО (CASE-средства): классификация и назначение.
Перевод / Ответ
CASE-средства (Computer-Aided Software Engineering) — ПО для автоматизации проектирования. Классификация: по этапам жизненного цикла (анализ, проектирование), по типу моделей (UML-редакторы, ER-диаграммы), по степени интеграции (утилиты или платформы). Назначение: автоматизация диаграмм, генерация кода, контроль целостности моделей.
Термин / Вопрос
5. Использование принципов объектно-ориентированного программирования (ООП) при проектировании систем.
Перевод / Ответ
Принципы: инкапсуляция (скрытие деталей), наследование (создание новых классов на базе старых), полиморфизм (единый интерфейс для разных форм), абстракция (выделение существенных характеристик). Применение: создание модульных, расширяемых и легко поддерживаемых систем.
Термин / Вопрос
6. Структурный подход к моделированию программных систем: основные концепции.
Перевод / Ответ
Концепции: декомпозиция на функциональные блоки, описание потоков данных между ними, иерархическая организация. Инструменты: DFD (диаграммы потоков данных), SADT. Суть: система — набор функций, преобразующих входные данные в выходные.
Термин / Вопрос
7. Виды тестирования ПО и их взаимосвязь с моделью проекта.
Перевод / Ответ
Виды: модульное (компоненты), интеграционное (взаимодействие модулей), системное (вся система), приемочное (соответствие требованиям). Взаимосвязь: в каскадной модели тестирование — в конце, в итерационной — на каждой итерации, в Agile — непрерывно.
Термин / Вопрос
8. Оценка бюджета, ресурсов и рисков на этапе проектирования ПО.
Перевод / Ответ
Бюджет: оценка трудозатрат, лицензий, инфраструктуры. Ресурсы: подбор команды, оборудования. Риски: технические (неизвестная технология), организационные (текучка), внешние (изменение требований). Методы: экспертная оценка, аналогии, PERT.
Термин / Вопрос
9. Роль и структура проектной документации согласно ГОСТ.
Перевод / Ответ
Роль: фиксация требований, архитектуры, решений для передачи знаний и юридической защиты. Структура (по ГОСТ 34 и ЕСПД): техническое задание, пояснительная записка, описание программы, руководство пользователя, программа и методика испытаний.
Термин / Вопрос
10. Рефакторинг кода: цели, этапы и основные методы проведения.
Перевод / Ответ
Цели: улучшение читаемости и поддерживаемости без изменения функциональности. Этапы: подготовка тестов, выявление «запахов» кода, внесение изменений, проверка тестов. Методы: извлечение метода, переименование переменных, устранение дублирования, упрощение условий.
Термин / Вопрос
11. Роль Технического задания (ТЗ) при моделировании информационной системы.
Перевод / Ответ
Роль: основной документ, определяющий, что должна делать система. При моделировании: источник для построения моделей (диаграмм вариантов использования, ER-диаграмм), критерий приемки, основа для оценки соответствия готового продукта.
Термин / Вопрос
12. Инструментальные средства отладки ПО.
Перевод / Ответ
Средства: отладчики (GDB, Visual Studio Debugger) — пошаговое выполнение, просмотр переменных; профилировщики — поиск узких мест; логирование — запись событий. Назначение: локализация и исправление ошибок, анализ производительности.
Термин / Вопрос
13. Визуальное моделирование: преимущества и недостатки использования графических диаграмм.
Перевод / Ответ
Преимущества: наглядность, упрощение коммуникации, раннее выявление ошибок, документирование архитектуры. Недостатки: сложность поддержки актуальности при частых изменениях, риск излишней детализации, необходимость обучения работе с нотациями.
Термин / Вопрос
14. Обеспечение соответствия критериям качества ПО на этапе проектирования.
Перевод / Ответ
Методы: выбор подходящей архитектуры, применение стандартов кодирования, использование паттернов проектирования, проработка нефункциональных требований (производительность, безопасность), прототипирование для проверки гипотез.
Термин / Вопрос
15. Процесс управления изменениями (Change Management) в программном проекте.
Перевод / Ответ
Суть: контроль изменений в требованиях, коде, документации. Этапы: регистрация запроса, оценка влияния и стоимости, утверждение/отклонение, внедрение, проверка. Инструменты: Jira, Git.
Термин / Вопрос
16. Сравнительный анализ сред разработки (IDE) и их влияние на архитектуру ПО.
Перевод / Ответ
IDE (IntelliJ IDEA, VS Code, Eclipse) предоставляют автодополнение, рефакторинг, интеграцию с Git. Влияние: мощные IDE поощряют использование сложных фреймворков и паттернов, упрощают навигацию по большой кодовой базе, но могут создавать зависимость от инструментов и «скрывать» сложность кода за автоматизацией.
Термин / Вопрос
17. Этапы анализа требований к ПО.
Перевод / Ответ
Этапы: сбор (интервью, наблюдение), классификация (функциональные/нефункциональные), анализ на полноту и непротиворечивость, спецификация (формализация в ТЗ), валидация (проверка с заказчиком).
Термин / Вопрос
18. Архитектура ПО: понятие, типы и назначение.
Перевод / Ответ
Понятие: высокоуровневая структура системы, определяющая компоненты и их взаимодействие. Типы: монолитная, микросервисная, клиент-серверная, событийно-ориентированная. Назначение: обеспечение масштабируемости, надежности, удобства поддержки и соответствия бизнес-целям.
Термин / Вопрос
19. Методы верификации и валидации ПО.
Перевод / Ответ
Верификация («Делаем ли мы продукт правильно?») — проверка соответствия продукта документации (инспекции, статический анализ кода). Валидация («Делаем ли мы правильный продукт?») — проверка соответствия ожиданиям пользователя (тестирование, демонстрация заказчику).
Термин / Вопрос
20. Особенности моделирования при использовании гибких методологий (Agile/Scrum).
Перевод / Ответ
Особенности: модели создаются «точно в срок» и минимально необходимые; упор на User Stories и диаграммы вариантов использования; итеративное уточнение моделей; использование досок задач вместо детальной документации; активное вовлечение заказчика в обсуждение моделей.
Термин / Вопрос
21. Функциональное моделирование с использованием нотации IDEF0.
Перевод / Ответ
Суть: описание функций системы и их взаимосвязей. Элементы: блоки (функции), стрелки (входы, выходы, механизмы, управление). Применение: анализ бизнес-процессов, выявление границ системы, формализация того, «что делает» система, без привязки к программной реализации.
Термин / Вопрос
22. Понятие «технического долга» в разработке ПО и методы его минимизации.
Перевод / Ответ
Технический долг: накопленные упрощения, компромиссы и недоработки в коде, требующие исправления в будущем. Методы минимизации: код-ревью, рефакторинг в рамках спринтов, автоматизированное тестирование, соблюдение стандартов кодирования, выделение времени на «гигиену» кода.
Термин / Вопрос
23. Анализ пользовательских интерфейсов и их влияние на качество продукта.
Перевод / Ответ
Анализ: оценка удобства (юзабилити), интуитивности, доступности, скорости выполнения задач. Влияние: плохой UI снижает удовлетворенность пользователей и увеличивает количество обращений в поддержку; хороший UI повышает эффективность работы и лояльность.
Термин / Вопрос
24. Стандарты оформления кода (PEP 8) и их роль в поддержке систем.
Перевод / Ответ
PEP 8 (для Python) — рекомендации по стилю (отступы, именование, длина строк). Роль: обеспечивает единообразие кода, упрощает чтение и понимание кода новыми разработчиками, снижает количество ошибок из-за неверной интерпретации стиля.

Примеры карточек из колоды в таблице

Ниже можно быстро посмотреть карточки этой колоды в виде таблицы: термин, подсказку, пример и ответ. Используйте поиск, чтобы найти нужную карточку, или скройте ответы для самопроверки. Полный набор карточек доступен после входа в Memoro.

Термин / Вопрос Перевод / Ответ
1. Жизненный цикл ПО: этапы и основные модели разработки (каскадная, итерационная, спиральная). Этапы: анализ требований, проектирование, разработка, тестирование, внедрение, сопровождение. Каскадная модель — последовательный переход между этапами без возврата. Итерационная — разработка циклами с получением рабочего фрагмента в конце каждой итерации. Спиральная — итерации с оценкой рисков на каждом витке перед переходом к следующему этапу.
2. Роль и цели моделирования в процессе разработки ПО. Роль: выступает языком коммуникации между заказчиком и командой, позволяет визуализировать систему до написания кода. Цели: выявление противоречий в требованиях, упрощение сложной логики, планирование архитектуры, снижение рисков ошибок на поздних стадиях.
3. Стандарты моделирования: краткая характеристика и сравнение UML и IDEF. UML (Unified Modeling Language) — стандарт для объектно-ориентированного моделирования ПО (диаграммы классов, последовательностей и др.). IDEF — семейство стандартов для функционального и процессного моделирования бизнеса (например, IDEF0 для функций). UML ориентирован на структуру и поведение ПО, IDEF — на бизнес-логику и потоки данных.
4. Инструментальные средства моделирования ПО (CASE-средства): классификация и назначение. CASE-средства (Computer-Aided Software Engineering) — ПО для автоматизации проектирования. Классификация: по этапам жизненного цикла (анализ, проектирование), по типу моделей (UML-редакторы, ER-диаграммы), по степени интеграции (утилиты или платформы). Назначение: автоматизация диаграмм, генерация кода, контроль целостности моделей.
5. Использование принципов объектно-ориентированного программирования (ООП) при проектировании систем. Принципы: инкапсуляция (скрытие деталей), наследование (создание новых классов на базе старых), полиморфизм (единый интерфейс для разных форм), абстракция (выделение существенных характеристик). Применение: создание модульных, расширяемых и легко поддерживаемых систем.
6. Структурный подход к моделированию программных систем: основные концепции. Концепции: декомпозиция на функциональные блоки, описание потоков данных между ними, иерархическая организация. Инструменты: DFD (диаграммы потоков данных), SADT. Суть: система — набор функций, преобразующих входные данные в выходные.
7. Виды тестирования ПО и их взаимосвязь с моделью проекта. Виды: модульное (компоненты), интеграционное (взаимодействие модулей), системное (вся система), приемочное (соответствие требованиям). Взаимосвязь: в каскадной модели тестирование — в конце, в итерационной — на каждой итерации, в Agile — непрерывно.
8. Оценка бюджета, ресурсов и рисков на этапе проектирования ПО. Бюджет: оценка трудозатрат, лицензий, инфраструктуры. Ресурсы: подбор команды, оборудования. Риски: технические (неизвестная технология), организационные (текучка), внешние (изменение требований). Методы: экспертная оценка, аналогии, PERT.
9. Роль и структура проектной документации согласно ГОСТ. Роль: фиксация требований, архитектуры, решений для передачи знаний и юридической защиты. Структура (по ГОСТ 34 и ЕСПД): техническое задание, пояснительная записка, описание программы, руководство пользователя, программа и методика испытаний.
10. Рефакторинг кода: цели, этапы и основные методы проведения. Цели: улучшение читаемости и поддерживаемости без изменения функциональности. Этапы: подготовка тестов, выявление «запахов» кода, внесение изменений, проверка тестов. Методы: извлечение метода, переименование переменных, устранение дублирования, упрощение условий.
11. Роль Технического задания (ТЗ) при моделировании информационной системы. Роль: основной документ, определяющий, что должна делать система. При моделировании: источник для построения моделей (диаграмм вариантов использования, ER-диаграмм), критерий приемки, основа для оценки соответствия готового продукта.
12. Инструментальные средства отладки ПО. Средства: отладчики (GDB, Visual Studio Debugger) — пошаговое выполнение, просмотр переменных; профилировщики — поиск узких мест; логирование — запись событий. Назначение: локализация и исправление ошибок, анализ производительности.
13. Визуальное моделирование: преимущества и недостатки использования графических диаграмм. Преимущества: наглядность, упрощение коммуникации, раннее выявление ошибок, документирование архитектуры. Недостатки: сложность поддержки актуальности при частых изменениях, риск излишней детализации, необходимость обучения работе с нотациями.
14. Обеспечение соответствия критериям качества ПО на этапе проектирования. Методы: выбор подходящей архитектуры, применение стандартов кодирования, использование паттернов проектирования, проработка нефункциональных требований (производительность, безопасность), прототипирование для проверки гипотез.
15. Процесс управления изменениями (Change Management) в программном проекте. Суть: контроль изменений в требованиях, коде, документации. Этапы: регистрация запроса, оценка влияния и стоимости, утверждение/отклонение, внедрение, проверка. Инструменты: Jira, Git.
16. Сравнительный анализ сред разработки (IDE) и их влияние на архитектуру ПО. IDE (IntelliJ IDEA, VS Code, Eclipse) предоставляют автодополнение, рефакторинг, интеграцию с Git. Влияние: мощные IDE поощряют использование сложных фреймворков и паттернов, упрощают навигацию по большой кодовой базе, но могут создавать зависимость от инструментов и «скрывать» сложность кода за автоматизацией.
17. Этапы анализа требований к ПО. Этапы: сбор (интервью, наблюдение), классификация (функциональные/нефункциональные), анализ на полноту и непротиворечивость, спецификация (формализация в ТЗ), валидация (проверка с заказчиком).
18. Архитектура ПО: понятие, типы и назначение. Понятие: высокоуровневая структура системы, определяющая компоненты и их взаимодействие. Типы: монолитная, микросервисная, клиент-серверная, событийно-ориентированная. Назначение: обеспечение масштабируемости, надежности, удобства поддержки и соответствия бизнес-целям.
19. Методы верификации и валидации ПО. Верификация («Делаем ли мы продукт правильно?») — проверка соответствия продукта документации (инспекции, статический анализ кода). Валидация («Делаем ли мы правильный продукт?») — проверка соответствия ожиданиям пользователя (тестирование, демонстрация заказчику).
20. Особенности моделирования при использовании гибких методологий (Agile/Scrum). Особенности: модели создаются «точно в срок» и минимально необходимые; упор на User Stories и диаграммы вариантов использования; итеративное уточнение моделей; использование досок задач вместо детальной документации; активное вовлечение заказчика в обсуждение моделей.
21. Функциональное моделирование с использованием нотации IDEF0. Суть: описание функций системы и их взаимосвязей. Элементы: блоки (функции), стрелки (входы, выходы, механизмы, управление). Применение: анализ бизнес-процессов, выявление границ системы, формализация того, «что делает» система, без привязки к программной реализации.
22. Понятие «технического долга» в разработке ПО и методы его минимизации. Технический долг: накопленные упрощения, компромиссы и недоработки в коде, требующие исправления в будущем. Методы минимизации: код-ревью, рефакторинг в рамках спринтов, автоматизированное тестирование, соблюдение стандартов кодирования, выделение времени на «гигиену» кода.
23. Анализ пользовательских интерфейсов и их влияние на качество продукта. Анализ: оценка удобства (юзабилити), интуитивности, доступности, скорости выполнения задач. Влияние: плохой UI снижает удовлетворенность пользователей и увеличивает количество обращений в поддержку; хороший UI повышает эффективность работы и лояльность.
24. Стандарты оформления кода (PEP 8) и их роль в поддержке систем. PEP 8 (для Python) — рекомендации по стилю (отступы, именование, длина строк). Роль: обеспечивает единообразие кода, упрощает чтение и понимание кода новыми разработчиками, снижает количество ошибок из-за неверной интерпретации стиля.

Получите доступ ко всем картам

Зарегистрируйтесь бесплатно, чтобы открыть все 45 карт и начать учиться без ограничений.