ТРПО

1. Информационная система. Понятие и этапы развития.
Информационная система (ИС) — это совокупность технических, программных и информационных средств, а также персонала, предназначенная для сбора, хранения, обработки и выдачи информации в интересах пользователя. Этапы развития: 1) ручная обработка данных (до 1960-х); 2) механизированная обработка (перфокарты, ЭВМ первых поколений); 3) автоматизированные системы управления (АСУ) 1970-80-х; 4) появление персональных компьютеров и децентрализованных ИС; 5) сетевые и корпоративные ИС (ERP, CRM); 6) современные облачные и распределённые ИС.
2. Жизненный цикл ПО. Стадии жизненного цикла.
Жизненный цикл ПО (ЖЦ ПО) — период времени от момента принятия решения о создании ПО до его полного изъятия из эксплуатации. Основные стадии по ГОСТ 12.207: замысел (анализ требований), разработка (проектирование, кодирование, тестирование), эксплуатация и сопровождение, вывод из эксплуатации. Часто выделяют также стадии: анализ требований, проектирование, реализация, тестирование, внедрение, сопровождение.
3. Модели жизненного цикла.
Модель ЖЦ — структура, определяющая последовательность выполнения процессов, действий и задач на протяжении ЖЦ. Основные модели: каскадная (Waterfall) — последовательное выполнение этапов; итерационная — повторяющиеся циклы разработки; спиральная — упор на анализ рисков; V-образная — параллельное сопоставление разработки и тестирования; инкрементная — поэтапная поставка функциональности; Agile-модели (гибкие, итеративно-инкрементные).
4. Стандартизация. Уровни стандартов.
Стандартизация — деятельность по установлению правил и характеристик для многократного использования, направленная на упорядочение процессов разработки ПО. Уровни стандартов: международные (ISO/IEC), государственные/национальные (ГОСТ Р), отраслевые (ОСТ), стандарты предприятия (СТП), стандарты де-факто (принятые практикой, например, стандарты консорциумов). Чем выше уровень — тем шире область действия стандарта.
5. Требования к ПО по классификации К. Вигерса.
Карл Вигерс делит требования на три уровня: бизнес-требования (цели и задачи организации), требования пользователей (задачи, которые пользователь решает с помощью системы, часто в форме вариантов использования), функциональные требования (конкретные функции системы). Отдельно выделяются нефункциональные требования (атрибуты качества: производительность, надёжность, безопасность) и бизнес-правила, ограничения.
6. Требования к ПО по классификации ГОСТ.
По ГОСТ 19.201-78 (ТЗ на разработку) и ГОСТ 34 требования делятся на: требования к системе в целом, требования к функциям (задачам), требования к видам обеспечения (техническому, программному, информационному, лингвистическому, организационному, метрологическому). Также выделяются требования к сохранности информации, безопасности, эксплуатации.
7. Требования к ПО по классификации RUP.
В Rational Unified Process используется модель FURPS+: Functionality (функциональность), Usability (удобство использования), Reliability (надёжность), Performance (производительность), Supportability (сопровождаемость), плюс дополнительные категории («+»): design constraints, implementation requirements, interface requirements, physical requirements.
8. Требования к ПО по классификации SWEBOK.
SWEBOK (Software Engineering Body of Knowledge) выделяет требования: функциональные, нефункциональные (качественные атрибуты), требования, связанные с предметной областью, и системные требования. Раздел SWEBOK «Software Requirements» описывает процессы: выявление требований (elicitation), анализ, спецификацию, верификацию требований.
9. Принцип разработки YAGNI.
YAGNI («You Aren't Gonna Need It» — «Вам это не понадобится») — принцип, согласно которому не следует реализовывать функциональность, пока в ней нет реальной необходимости. Цель — избежать избыточной сложности кода и лишних затрат времени на разработку «на будущее», которая может никогда не понадобиться.
10. Принцип разработки DRY.
DRY («Don't Repeat Yourself» — «Не повторяйся») — принцип, требующий, чтобы каждая часть знания/логики в системе была представлена единственным, однозначным способом. Достигается через вынесение повторяющегося кода в функции, классы, модули — это упрощает сопровождение и снижает риск ошибок при изменениях.
11. Принцип разработки KISS.
KISS («Keep It Simple, Stupid» — «Делай проще») — принцип, гласящий, что системы работают лучше всего, если они остаются простыми, а не усложняются без необходимости. Простота облегчает понимание, тестирование и сопровождение кода.
12. Принцип разработки BDUF.
BDUF («Big Design Up Front» — «Большое проектирование заранее») — подход, при котором детальное проектирование системы выполняется полностью до начала кодирования. Характерен для каскадной модели; противопоставляется гибким подходам, где проектирование ведётся итеративно и эволюционно.
13. Принцип разработки SOLID.
SOLID — пять принципов объектно-ориентированного проектирования: S — Single Responsibility (единственная ответственность класса); O — Open/Closed (открытость для расширения, закрытость для изменения); L — Liskov Substitution (подставимость подклассов вместо базового класса); I — Interface Segregation (разделение интерфейсов); D — Dependency Inversion (инверсия зависимостей — зависимость от абстракций, а не от конкретных реализаций).
14. Метод разработки Waterfall.
Каскадная («водопадная») модель предполагает строго последовательное выполнение этапов: анализ требований → проектирование → реализация → тестирование → внедрение → сопровождение, без возврата к предыдущим этапам. Подходит для проектов со стабильными, чётко определёнными требованиями; минус — сложность внесения изменений и позднее обнаружение ошибок.
15. Метод разработки Spiral.
Спиральная модель (Б. Боэм) сочетает элементы каскадной модели с итеративной разработкой прототипов. Каждый виток спирали включает: определение целей, анализ и оценку рисков, разработку и тестирование, планирование следующей итерации. Особый акцент — на анализе и снижении рисков на каждом витке.
16. Метод разработки V-Model.
V-образная модель — расширение каскадной, где каждому этапу разработки соответствует свой этап тестирования (верификации), образуя букву «V». Левая ветвь — анализ требований, проектирование, программирование; правая ветвь — модульное, интеграционное, системное и приёмочное тестирование, соответствующие левым этапам.
17. Метод разработки Incremental.
Инкрементная модель предполагает разбиение системы на функциональные части (инкременты), которые разрабатываются и поставляются последовательно, каждая добавляет новую функциональность к уже работающей системе. Позволяет раньше получать работающий продукт и учитывать обратную связь.
18. Метод разработки RAD.
RAD (Rapid Application Development) — метод быстрой разработки приложений с упором на активное вовлечение пользователей, использование прототипирования, CASE-средств и повторно используемых компонентов. Цель — сократить сроки разработки при сохранении качества за счёт итеративного создания и уточнения прототипов.
19. Метод разработки Agile.
Agile — семейство гибких итеративно-инкрементных методологий (Scrum, Kanban, XP и др.), основанных на принципах «Agile-манифеста»: люди и взаимодействие важнее процессов; работающий продукт важнее документации; сотрудничество с заказчиком важнее контрактных обязательств; готовность к изменениям важнее следования плану. Разработка ведётся короткими итерациями (спринтами) с постоянной обратной связью.
20. Модели организации разработки.
Выделяют разные организационные модели команд: иерархическая (директивная) — с чёткой субординацией; демократическая — равноправное распределение ответственности; матричная — сотрудники подчиняются одновременно функциональному и проектному руководителю; распределённая (аутсорсинг, оффшор-разработка); Agile-команды (кросс-функциональные, самоорганизующиеся).
21. Роли в команде разработки.
Типичные роли: руководитель проекта (Project Manager), аналитик (Business/System Analyst), архитектор ПО, разработчики (Developers), тестировщики (QA/Testers), UX/UI-дизайнер, DevOps-инженер, технический писатель. В Scrum отдельно выделяют Product Owner, Scrum Master и команду разработки.
22. Системы контроля версий: понятие и разновидности.
Система контроля версий (VCS) — инструмент для отслеживания изменений в файлах проекта и управления историей этих изменений. Разновидности: локальные (хранят историю на одном компьютере), централизованные (единый сервер, например SVN, CVS), распределённые (каждый разработчик хранит полную копию репозитория — Git, Mercurial).
23. Система контроля версий Git.
Git — распределённая система контроля версий, созданная Линусом Торвальдсом. Основные понятия: репозиторий, коммит, ветка (branch), слияние (merge), удалённый репозиторий (remote), pull/push. Особенности: высокая скорость работы, поддержка нелинейной разработки через ветвление, целостность истории за счёт хэширования (SHA-1), возможность работы без постоянного подключения к серверу.
24. Техническое задание.
Техническое задание (ТЗ) — документ, определяющий назначение, цели, требования, состав и условия разработки программного продукта. Структура по ГОСТ 19.201-78 включает разделы: введение, основания для разработки, назначение разработки, требования к программе, требования к программной документации, стадии и этапы разработки, порядок контроля и приёмки.
25. UML диаграмма вариантов использования.
Диаграмма Use Case (вариантов использования) описывает функциональность системы с точки зрения пользователя (актора). Элементы: акторы (действующие лица), варианты использования (сценарии взаимодействия с системой), связи «include», «extend», обобщение. Используется на этапе анализа требований для описания того, что система должна делать.
26. UML диаграмма последовательности.
Диаграмма последовательности (Sequence Diagram) отображает взаимодействие объектов во времени — последовательность обмена сообщениями между объектами при выполнении конкретного сценария. Элементы: объекты (с линиями жизни), сообщения (синхронные, асинхронные), фрагменты взаимодействия (alt, loop, opt).
27. UML диаграмма деятельности.
Диаграмма деятельности (Activity Diagram) моделирует поток управления или данных, описывая последовательность действий (activity) в бизнес-процессе или алгоритме. Включает узлы действий, точки принятия решений (decision), развилки/слияния параллельных потоков (fork/join), начальный и конечный узлы.
28. UML диаграмма классов.
Диаграмма классов (Class Diagram) — статическая диаграмма, отображающая структуру системы через классы, их атрибуты, методы и отношения между ними (ассоциация, агрегация, композиция, наследование, реализация). Используется при объектно-ориентированном проектировании как основа для написания кода.
29. Понятие и процессы обеспечения качества ПО.
Обеспечение качества ПО (SQA — Software Quality Assurance) — систематическая деятельность по контролю соответствия процессов и продукта установленным требованиям и стандартам. Процессы включают: планирование качества, контроль качества (QC — проверка результатов работы), верификацию и валидацию, аудит процессов, управление дефектами.
30. Тестирование ПО. Классификация методов тестирования.
Тестирование — процесс проверки соответствия ПО заявленным требованиям и выявления дефектов. Классификация: по уровню доступа к коду (белый, серый, чёрный ящик); по уровню детализации (модульное, интеграционное, системное, приёмочное); по признаку исполнения (ручное, автоматизированное); по объекту проверки (функциональное, нефункциональное).
31. Тестирование производительности ПО.
Тестирование производительности (Performance Testing) проверяет скорость, отклик, устойчивость и масштабируемость системы под различной нагрузкой. Виды: нагрузочное (Load Testing), стресс-тестирование (Stress Testing) — работа на пределе/сверх нормы, тестирование стабильности (Soak/Endurance Testing), тестирование пиковых нагрузок (Spike Testing).
32. Ручное и автоматизированное тестирование.
Ручное тестирование выполняется тестировщиком без использования специальных инструментов автоматизации — подходит для исследовательского тестирования, юзабилити, разовых проверок. Автоматизированное тестирование использует специальные скрипты/фреймворки (Selenium, JUnit и др.) для выполнения повторяющихся тестов — эффективно для регрессионного тестирования, экономит время при частых прогонах.
33. Тестирование «белого» и «черного ящика».
Тестирование «белого ящика» (White-box) основано на анализе внутренней структуры и логики кода (покрытие ветвей, путей, условий). Тестирование «чёрного ящика» (Black-box) проверяет функциональность системы без знания её внутреннего устройства, ориентируясь только на входные/выходные данные и требования. Существует также «серый ящик» (Grey-box), сочетающий оба подхода.
34. Функциональное и нефункциональное тестирование.
Функциональное тестирование проверяет, что система выполняет заявленные функции согласно требованиям (что делает система). Нефункциональное тестирование проверяет качественные атрибуты — производительность, безопасность, удобство использования, надёжность, совместимость (как система это делает).
35. Модульное тестирование.
Модульное (юнит) тестирование проверяет отдельные, минимальные, изолированные части кода (функции, методы, классы) на корректность работы. Обычно выполняется разработчиками с использованием фреймворков (JUnit, NUnit, pytest) и выявляет ошибки на самом раннем этапе.
36. Интеграционное тестирование.
Интеграционное тестирование проверяет корректность взаимодействия между отдельными модулями/компонентами системы после их объединения. Подходы: «снизу вверх», «сверху вниз», «большой взрыв» (Big Bang — одновременная интеграция всех модулей).
37. Системное тестирование.
Системное тестирование проверяет полностью собранную систему в целом на соответствие всем функциональным и нефункциональным требованиям в среде, приближенной к реальной эксплуатации. Проводится после интеграционного тестирования, перед приёмочным.
38. Регрессионное тестирование.
Регрессионное тестирование проводится после внесения изменений в код (исправления ошибок, добавления функций) для проверки того, что ранее работавшая функциональность не была нарушена. Часто автоматизируется из-за необходимости частого повторения.
39. Приемочное тестирование.
Приёмочное тестирование (Acceptance Testing) — финальный этап проверки, определяющий, готова ли система к передаче заказчику/пользователям. Виды: альфа-тестирование (внутри организации-разработчика), бета-тестирование (реальными пользователями), UAT (User Acceptance Testing — приёмка заказчиком по критериям договора).
40. Тестовый сценарий.
Тестовый сценарий (Test Case) — документ, описывающий конкретные шаги, входные данные, условия выполнения и ожидаемый результат для проверки определённой функции системы. Обычно включает: идентификатор, предусловия, шаги выполнения, ожидаемый и фактический результат, статус (пройден/не пройден).
41. Отладка. Методы ручной отладки.
Отладка (debugging) — процесс поиска и устранения ошибок (дефектов) в программе. Методы ручной отладки: отладка методом «трассировки» кода на бумаге/в уме, вставка отладочной печати (print/log-выводов), метод «грубой силы» (анализ дампов, логов), метод индукции и дедукции — анализ симптомов ошибки от частного к общему и наоборот.
42. Логические методы проведения отладки.
Логические методы отладки основаны на рассуждении, а не на переборе: метод индукции (от частных симптомов к общей причине), метод дедукции (выдвижение гипотез и их последовательное исключение), метод обратного прослеживания (анализ пути выполнения от точки ошибки назад к её источнику), метод тестирования гипотез.
43. Диаграмма Ганта.
Диаграмма Ганта — инструмент планирования проекта в виде горизонтальной ленточной диаграммы, где по горизонтали отображается временная шкала, а по вертикали — список задач с указанием их длительности, сроков начала/окончания и взаимозависимостей. Используется для визуализации графика работ и контроля прогресса проекта.
44. Матрица ответственности. Реестр рисков проекта.
Матрица ответственности (например, RACI — Responsible, Accountable, Consulted, Informed) распределяет роли участников проекта по каждой задаче: кто исполняет, кто утверждает, с кем консультируются, кого информируют. Реестр рисков — документ, фиксирующий выявленные риски проекта, их вероятность, влияние, приоритет и планируемые меры реагирования.
45. Бюджетная смета программного проекта.
Бюджетная смета — документ, определяющий плановые затраты на реализацию проекта: расходы на оплату труда команды, оборудование и лицензии ПО, накладные расходы, резерв на риски. Составляется на основе оценки трудозатрат (например, методами экспертной оценки, аналогий, COCOMO) и используется для контроля исполнения бюджета.
46. Рефакторинг исходного кода программы.
Рефакторинг — процесс улучшения внутренней структуры кода без изменения его внешнего (наблюдаемого) поведения. Цели: повышение читаемости, упрощение сопровождения, устранение дублирования и «запахов кода» (code smells). Проводится небольшими безопасными шагами, часто в сочетании с модульными тестами для контроля отсутствия регрессий.
47. Проблемы унаследованного программного кода.
Унаследованный код (legacy code) — старый код, часто без документации, тестов и понимания у текущей команды, но продолжающий использоваться в продакшене. Проблемы: сложность внесения изменений из-за отсутствия тестового покрытия, устаревшие технологии/зависимости, высокая связанность компонентов, риск появления новых ошибок при доработке, нехватка знаний об исходной логике.
48. Автоматизированные средства составления программной документации.
Это инструменты, автоматически генерирующие документацию из исходного кода на основе комментариев в специальном формате: Javadoc (Java), Doxygen (C/C++, многоязычный), Sphinx (Python), JSDoc (JavaScript), XML-документация в .NET. Позволяют поддерживать документацию актуальной синхронно с изменениями кода.