экзамен 1

Decks
Free
Снежана Трофимова
Снежана Трофимова
•
45 cards
For practitioners
Clear definitions
Learn effectively and remember long-term
View
45 cards
Demo training: 1 of 10
Last updated: July 2026
Try to remember the answer yourself. If necessary, open the hint, then click on the card to see the answer. Click ✓ if you answered correctly, or × if you made a mistake. The full version is available after .
Demo: Flashcards
1/10
Term / Question
...
Translation / Answer
...
Space - flip, click on the card - flip. You can choose the answer immediately.
← Don't know
Easy →

More features available after registration

Customize your learning, track progress and memory statistics, use different testing methods and spaced repetition. Create private decks just for yourself or share them with others, study ready-made decks and courses. And a daily five-minute warmup and trainers will help activate your attention and memory before studying or working.

Demo: Testing
1/10
Term / Question
...
Translation / Answer
...
Space - flip, click on the card - flip. You can choose the answer immediately.
← Don't know
Easy →

View

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

Examples of flashcards from the deck in a table

Below you can quickly view flashcards in this deck as a table: term, hint, example and answer. Use search to find the card you need, or hide answers for self-testing. The full set of flashcards is available after logging into Memoro.

Term / Question Translation / Answer
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) — рекомендации по стилю (отступы, именование, длина строк). Роль: обеспечивает единообразие кода, упрощает чтение и понимание кода новыми разработчиками, снижает количество ошибок из-за неверной интерпретации стиля.

Get access to all cards

Register for free to unlock all 45 cards and start learning without limits.