Курсовая работа на тему «Первая глава дипломной работы: литературный обзор, анализ рынка, аналоги и выбор средств разработки с акцентом на тестирование производительности» — скачать бесплатно

Содержание

1. 1 Литературный обзор
2. 1.1 Анализ рынка
3. 1.2 Поиск аналогов
4. 1.3 Выбор средств разработки
5. Выводы по главе

Введение

Настоящая глава выполняет функцию «опорной рамы» для последующих разделов дипломной работы: фиксирует терминологию, очерчивает состояние рынка и технологического ландшафта, сопоставляет существующие решения и обосновывает выбор средств разработки. Отдельный акцент сделан на тестировании производительности (нагрузочном, стрессовом, ресурсном) как на обязательной процедуре перед вводом решения в опытную эксплуатацию. На практике именно производительность становится тем узким горлышком, которое не видно на демонстрации и прототипе, но проявляется в реальной среде, где есть пиковые нагрузки, конкуренция за ресурсы, ограничения сетевой инфраструктуры, «шум» соседних сервисов и непредсказуемый профиль запросов. Поэтому литературный обзор и рыночный анализ в данной главе намеренно «приземлены»: приводятся наблюдаемые тенденции, реальные российские источники и актуальные для промышленной эксплуатации подходы.

Глава 1

Литературный обзор в рамках разработки программного решения целесообразно строить не как перечень определений, а как последовательность вопросов, на которые проект обязан ответить до этапа опытной эксплуатации. Первый вопрос — что именно считается работоспособностью системы. Второй — чем измеряется качество: временем отклика, пропускной способностью, устойчивостью к деградации, затратами ресурсов. Третий — в каких условиях решение будет жить: в корпоративной сети, в облаке, в контуре с регуляторными ограничениями, с требованием к импортозамещению. В российской практике границы между «работает» и «можно запускать в опыт» часто проходят по линии производительности. Функциональные тесты обычно обнаруживают ошибки логики и интерфейса. Но если система на пике начинает отвечать не за секунды, а за десятки секунд — пользователь перестает различать причину. Он видит тишину. Отсюда и практическая ценность предварительного тестирования производительности: оно переводит разговор из области ощущений в область измерений. В отечественных стандартах и руководствах к качеству ПО акцент на измеряемость присутствует давно. В ГОСТ 19.301-79 закреплена структура программной документации, в которой испытания и их описание рассматриваются как обязательный элемент жизненного цикла (пусть и в «классической» терминологии). ГОСТ 34.601-90, ориентированный на автоматизированные системы, формализует стадии создания и ввода в действие; опытная эксплуатация там выступает отдельной стадией, а значит, все критические риски — включая производительность — должны быть сняты до нее либо в ее раннем контуре при контролируемых условиях. Наконец, серия ISO/IEC 25010 (в РФ используется как ГОСТ Р ИСО/МЭК 25010) фиксирует модель качества ПО, в которой производительность и эффективность использования ресурсов — самостоятельные характеристики (performance efficiency), не «подхарактеристика удобства», не «вторичное свойство», а полноценный критерий. При этом литература и отраслевые отчеты последних лет смещают фокус: производительность перестала быть только задачей «потом оптимизируем». Современная архитектура — микросервисы, события, контейнеры — требует закладывать наблюдаемость и возможность нагрузочного тестирования заранее. Иначе система превращается в оркестр без партитуры: каждый инструмент играет свое, но общий темп никто не контролирует. В инженерной традиции нагрузочное тестирование часто описывается тройкой целей: (1) оценить пропускную способность при типовом профиле, (2) найти точки деградации, (3) подтвердить соблюдение SLA/SLI. На уровне методов применяются: нагрузочные испытания (load testing), стресс-тесты (stress testing), тестирование стабильности/выносливости (soak/endurance), тестирование всплесков (spike), а также профилирование и тестирование на утечки ресурсов. Важно, что сами по себе «красивые графики» не являются результатом — результатом является инженерное решение: изменение схемы кэширования, оптимизация запросов к БД, корректировка пула соединений, пересмотр границ транзакций, выбор протокола взаимодействия, лимиты очередей, таймауты. Нормативные и методические документы российской практики прямо указывают на необходимость испытаний в предэксплуатационных фазах. Так, в методических материалах ФСТЭК России по защите информации (в контуре ГИС и ИСПДн) испытания и контрольные проверки выступают обязательным элементом ввода, а вопросы устойчивости и корректности функционирования в заданных условиях формально встраиваются в процедуру приемки. Даже если документ направлен на безопасность, вывод для производительности простой: «испытания» — не факультативная часть. С учетом того, что в этой дипломной работе далее предполагается проектирование и реализация программного решения (контекст и предмет будут уточнены в последующих главах), в настоящей главе литературный обзор строится вокруг трех прикладных блоков: анализ рынка (что востребовано и где появляются требования), поиск аналогов (что уже существует и какие архитектурные решения доминируют), выбор средств разработки (какими инструментами рационально обеспечить качество, включая производительность). 1.1 Анализ рынка Рынок разработки и внедрения ПО в РФ в 2022–2024 гг. переживает двойную перестройку: технологическую и институциональную. С одной стороны, усиливается спрос на отечественные продукты, платформы и инфраструктуру. С другой — заказчики, особенно в корпоративном и государственном сегменте, стали более жестко формулировать требования к надежности и устойчивости, поскольку «замена» больше не воспринимается как эксперимент ради эксперимента: ошибка в производительности быстро превращается в простой процесса. Для фиксации контекста целесообразно опираться на публичные отчеты и статистику российских институтов развития и аналитических центров. В частности, НИУ ВШЭ в серии «Индикаторы цифровой экономики» регулярно публикует сведения о цифровизации организаций, структуре ИКТ-расходов, проникновении облаков, ERP/CRM и иных классов решений. Эти данные полезны не точностью «до копейки», а тем, что показывают: цифровые системы перестали быть локальными, они стали инфраструктурой бизнеса. Когда система становится инфраструктурой, производительность становится политикой — внутри организации, а не частным делом разработчика. Минцифры России и связанные с ним инициативы (включая ведение реестра российского ПО) отражают еще одну сторону рынка: растет количество отечественных решений, но одновременно растут требования к их промышленной зрелости. Пользователь «переезжает» не в лабораторию, а в рабочий контур: у него есть пиковые часы, отчётные периоды, интеграции со смежными системами. Поэтому на уровне рынка повышается ценность методологий, позволяющих доказуемо подтвердить производительность. Отдельный пласт — облачная и контейнерная инфраструктура. Рост использования контейнеризации, Kubernetes-подобных оркестраторов, сервисных сеток и CI/CD приводит к тому, что производительность начинает зависеть не только от кода приложения, но и от конфигурации платформы: лимитов CPU/RAM, политик autoscaling, сетевых параметров, хранения. На этом фоне нагрузочные испытания превращаются в «тестирование системы как целого», а не модуля. Нельзя игнорировать и практику импортозамещения в инфраструктуре данных: переход на отечественные СУБД и платформы (PostgreSQL-семейство в разных поставках, отечественные решения класса «enterprise», прикладные платформы). Любая миграция данных или платформы изменяет профиль производительности. Иногда неожиданно. Индексы ведут себя иначе, планы выполнения запросов отличаются, параметры по умолчанию иная. На уровне рынка это создает спрос на услуги и инструменты бенчмаркинга, профилирования и нагрузочного моделирования. Спрос на подтвержденную производительность усиливается и из-за изменения пользовательских привычек. Мобильные каналы, ожидание «почти мгновенного» ответа, а также рост интеграций через API делают задержки более заметными. В классической форме «оператор подождет» уже не работает: запрос уходит в цепочку сервисов, и в каждом звене задержка суммируется. Поэтому требования к латентности и стабильности становятся частью требований к функционалу. Для иллюстрации логики взаимосвязи этапов разработки и стоимости исправлений производительности ниже приведена условная диаграмма. Она не является статистическим измерением рынка, а используется как инженерная модель: чем позже обнаружено узкое место, тем дороже его устранение. Диаграмма 1 — Условная оценка относительных затрат на исправление дефектов производительности по стадиям жизненного цикла (в относительных единицах) Стадия: Проектирование Разработка Интеграция Предпрод (стенд) Опытная эксплуатация Промышленная эксплуатация Затраты (отн. ед.): 1 2 4 7 12 20 В тексте данная диаграмма интерпретируется так: на этапе проектирования дефект производительности часто устраняется архитектурным решением (например, отказом от синхронных цепочек вызовов в пользу очереди), что обходится сравнительно дешево. На этапе разработки исправление уже затрагивает код и тесты. На интеграции подключаются внешние зависимости и начинается «плата за сложность». На предпрод-стенде выявляются эффекты реальной конфигурации, и исправление может потребовать изменения схемы развертывания. В опытной эксплуатации цена возрастает резко: система уже контактирует с реальными пользователями, а «окно» для правок узкое. В промышленной эксплуатации дефекты производительности превращаются в инциденты с репутационными и финансовыми последствиями. С рыночной точки зрения это означает следующее. Заказчик покупает не только функциональность. Он покупает предсказуемость. И если предсказуемость не подтверждена испытаниями до опытной эксплуатации, проект попадает в область рисков, которые трудно объяснить, но легко почувствовать. 1.2 Поиск аналогов Поиск аналогов в дипломной работе имеет две цели. Первая — понять, какие архитектурные и продуктовые решения уже применяются в рассматриваемом классе систем (информационные системы, веб-сервисы, прикладные платформы — конкретизация определяется темой диплома). Вторая — выявить «типовые» подходы к обеспечению производительности и к нагрузочным испытаниям. В российском контуре удобной отправной точкой является Единый реестр российского программного обеспечения (реестр Минцифры России). Он дает не столько рейтинг качества, сколько карту рынка: какие классы решений представлены, кто является правообладателем, какие продукты активно продвигаются. Оттуда можно выделить аналоги по функциональному назначению и по технологическому стеку. Если рассматривать типовой класс корпоративных информационных систем (документооборот, управление заявками, сервис-деск, CRM/ERP-подсистемы, отраслевые порталы), то среди распространенных аналогов обычно встречаются: - платформенные решения, которые «тащат» на себе значительную часть логики (low-code/rapid development) и требуют особого внимания к производительности платформы; - классические веб-приложения на распространенных стэках (Java/.NET/Python/Node.js), где производительность зависит от архитектуры сервиса и СУБД; - микросервисные решения, где ключевой проблемой становится распределенная латентность и наблюдаемость; - решения на базе отечественных СУБД/платформ, где важна проверка соответствия заявленным характеристикам в конкретной конфигурации. Поиск аналогов следует вести по нескольким осям. Ось 1. Функциональная. Что система делает: учет, маршрутизация, хранение, аналитика, интеграция. Ось 2. Нефункциональная. Какие заявлены SLA (время ответа, доступность), какие объемы данных, сколько пользователей, какой профиль нагрузки. Ось 3. Технологическая. Архитектура (монолит/микросервисы), протоколы (REST/gRPC), хранение (реляционное/документное/очереди), окружение (on-prem/облако). Ось 4. Эксплуатационная зрелость. Наличие механизмов мониторинга, логирования, трассировки, возможности проводить нагрузочные испытания на стенде, готовность к масштабированию. Практика показывает, что аналог, демонстрирующий устойчивую работу, почти всегда имеет два признака. Первый — ограничения и квоты оформлены явно (лимиты запросов, размеры пакетов, таймауты). Второй — есть инструменты наблюдаемости, позволяющие связать метрики производительности с причинами (метрики приложений, БД, очередей, инфраструктуры). Особый интерес представляют аналоги, у которых опубликованы кейсы внедрения. В России такие кейсы встречаются у крупных поставщиков, интеграторов и разработчиков, а также в отраслевых СМИ. Даже если в кейсе мало «сырой» техники, там обычно есть косвенные показатели: масштаб пользователей, количество операций, объем данных, требования к времени реакции. Это помогает сформировать целевую модель нагрузки. Важный вывод из анализа аналогов для дипломной работы формулируется так: если аналог в маркетинговых материалах обещает «быстро», но не раскрывает методику подтверждения производительности, то риск переносится на проект внедрения. В инженерном смысле это означает необходимость планировать собственные испытания до опытной эксплуатации и готовить стенд, близкий к боевому. 1.3 Выбор средств разработки Выбор средств разработки должен отвечать не только задаче «на чем написать», но и задаче «как доказать, что написанное выдержит нагрузку». Поэтому критерии выбора целесообразно разделить на три группы: технологические (язык, фреймворк, СУБД), инженерные (тестирование, CI/CD, наблюдаемость) и организационные (поддержка, компетенции команды, соответствие требованиям импортозамещения и лицензирования). 1) Технологический стек приложения. В рамках типовых дипломных проектов, связанных с веб-приложениями и информационными системами, на российском рынке распространены следующие стеки: - Java/Kotlin (Spring) — сильная экосистема, зрелые инструменты профилирования и нагрузочного тестирования, высокая предсказуемость поведения под нагрузкой при грамотной настройке JVM. - C# (.NET) — высокая производительность веб-стека, развитая диагностика, удобная интеграция с корпоративной средой. - Python (Django/FastAPI) — высокая скорость разработки, но повышенное внимание к асинхронности и внешним узким местам; для тяжелых нагрузок часто требуется архитектурная декомпозиция. - Node.js — естественная модель для I/O-нагрузок, но требует дисциплины в CPU-bound операциях. Выбор конкретного языка в дипломной работе должен быть связан с требованиями к профилю нагрузки. Если доминируют операции ввода-вывода (БД, сеть) — важна эффективность обработки параллельных запросов и правильная настройка пула соединений. Если есть тяжелые вычисления — важны многопоточность и профилирование CPU. 2) Хранилище данных. Для большинства корпоративных задач реляционная СУБД остается базовым выбором. В российском контуре PostgreSQL и его отечественные поставки широко применяются, но важно помнить: производительность определяется не названием, а конфигурацией. Для дипломного проекта существенны: - индексация и планы запросов; - настройки памяти и параллельности; - стратегия миграций; - контроль блокировок и транзакций; - организация бэкапов и репликации (если моделируется). 3) Средства тестирования производительности. Так как глава акцентирует важность испытаний перед опытной эксплуатацией, средства нагрузочного тестирования должны быть включены в набор инструментов разработки наравне с системой контроля версий. Наиболее распространенные инструменты: - Apache JMeter — де-факто стандарт для многих организаций, удобен для HTTP(S), JDBC, очередей; позволяет моделировать различные профили нагрузки. - Yandex.Tank — инструмент, развиваемый в российской инженерной среде, удобен для воспроизведения нагрузок и интеграции с мониторингом; часто применяется в практиках нагрузочного тестирования. - k6 — современный инструмент для тестирования API, удобен в CI/CD, сценарии на JavaScript. В дипломной работе важно обосновать выбор не «популярностью», а пригодностью к задачам: - возможность параметризовать сценарии, отражающие реальный профиль пользователя; - поддержка распределенной генерации нагрузки (если нужно); - сбор метрик и формирование отчета, пригодного для приемки; - воспроизводимость (одинаковые сценарии дают сопоставимые результаты). 4) Наблюдаемость и диагностика. Проверка производительности без метрик превращается в гадание по шуму вентиляторов. Поэтому средства мониторинга и логирования следует выбирать заранее: - Prometheus + Grafana (или отечественные аналоги и сборки) для метрик; - централизованное логирование (например, стек на базе Elasticsearch/OpenSearch или иные решения); - распределенная трассировка (Jaeger/Tempo) для микросервисов. Даже в дипломной работе, где инфраструктура может быть упрощена, полезно внедрить минимум наблюдаемости: метрики времени ответа, RPS, ошибок, загрузки CPU/RAM, задержек БД. Иначе невозможно корректно интерпретировать результаты нагрузочного теста. 5) Контур испытаний перед опытной эксплуатацией. Практическая рекомендация, вытекающая из обзора, звучит строго: перед вводом в опытную эксплуатацию должны быть проведены испытания производительности на стенде, максимально приближенном к эксплуатационному по конфигурации и данным (в допустимых пределах). Важно обеспечить: - сопоставимые лимиты ресурсов; - приближенный к реальности профиль данных (объемы, распределения); - воспроизведение типовых и пиковых сценариев; - фиксирование критериев приемки: например, 95-й перцентиль времени ответа не хуже заданного значения при определенной нагрузке. Если испытания провести «после» или «по ходу опыта», то опытная эксплуатация превращается в тестовую среду на живых пользователях. Это методологически слабая позиция и организационно конфликтная: пользователи ожидают проверку гипотез, а получают деградацию процессов. Выводы по главе В первой главе выполнен обзор подходов к обеспечению качества программных решений с акцентом на производительность и испытания перед опытной эксплуатацией. Показано, что нормативная логика (ГОСТы, стадийность создания систем) и практическая логика рынка сходятся: опытная эксплуатация является этапом, где риск должен быть управляемым, а не «внезапным». Проведен анализ рынка на основе российских источников и выявлено усиление спроса на промышленно зрелые решения и подтверждение их характеристик. Выполнен поиск аналогов и выделены признаки эксплуатационной зрелости (ограничения, наблюдаемость, методика тестов). Обоснован выбор средств разработки и тестирования, где нагрузочные испытания, мониторинг и воспроизводимость сценариев рассматриваются как равноправные элементы процесса разработки, а не как постфактум-активность. Таким образом, уже на уровне первой главы формируется практический каркас дальнейшей работы: проектирование и реализация должны сопровождаться планом производительных испытаний, а критерии приемки должны быть сформулированы до опытной эксплуатации и подтверждены измерениями.