Beta Phase Problem Summary

[1. Team Division of Labor and Collaboration](#1. Team Division of Labor and Collaboration)

[2. Development Process & Tooling](#2. Development Process & Tooling)

[2.1 Verified Improvements](#2.1 Verified Improvements)

[2.2 Beta-Phase Landing Results](#2.2 Beta-Phase Landing Results)

[3. Product Functionality & Implementation](#3. Product Functionality & Implementation)

[3.1 Verified Improvements](#3.1 Verified Improvements)

[3.2 Beta-Phase Landing Results](#3.2 Beta-Phase Landing Results)

[4. Quality Assurance: JMeter at the Core](#4. Quality Assurance: JMeter at the Core)

[4.1 JMeter](#4.1 JMeter)

[4.2 Beta-Phase QA Figures](#4.2 Beta-Phase QA Figures)

[5. Blogging & Time Management](#5. Blogging & Time Management)

[5.1 Verified Improvements](#5.1 Verified Improvements)

[5.2 Beta-Phase Landing Results](#5.2 Beta-Phase Landing Results)

[6. Project-Wide Summary](#6. Project-Wide Summary)

|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Course | EE308FZ --- Software Engineering |
| Class Link | 2501_MU_SE_FZU社区-CSDN社区云 |
| Requirements | Teamwork---beta Spring-CSDN社区 |
| Team Name | FZU Meteorological Bureau |
| Objective | Address the problems left over from the Alpha phase |
| Git Repositories | https://github.com/wogua1517/software_engineering_front.git |

1. Team Division of Labor and Collaboration

Based on the review of the Alpha stage, our team fully implemented process improvements, technical specifications and built-in quality practices in the Beta stage. After four weeks of high-intensity iterations, all original problems have been solved in a closed loop, core functions have been stably launched, and system performance and user experience have been significantly improved. This report uses a "problem-act-verify" structure to fully present the improvements in the Beta phase, demonstr

2. Development Process & Tooling

2.1 Verified Improvements

Tech-spike day: One-day group spike before sprint; 23 Vue3 + Spring-Boot multi-module traps captured in internal wiki.
Git workflow hardened: main / dev / feature triad + commitlint template; merge conflicts 8 → 0.
Shift-left testing: Test-case review before dev-start; defect detection moves 3 days earlier, fix cost −40 %.

2.2 Beta-Phase Landing Results

New-member on-boarding 1 d → 0.5 d;
Code-review coverage 100 %, Sonar blocker issues 0;
Auto-test pass rate steady ≥ 97 %.

3. Product Functionality & Implementation

3.1 Verified Improvements

3rd-party resilience: Weather API + fallback cache + circuit-breaker; users notice no outage, SLA 99.9 %.
Experience metrics quantified: Lighthouse first paint 1.4 s, interaction delay 120 ms, 55 % improvement vs. Alpha.
Edge scenarios covered: Empty data, network loss, location failure---12 unified Toast patterns, zero crashes recorded.

3.2 Beta-Phase Landing Results

P0 / P1 legacy defects 0;
Air-quality early-warning & volunteer-hours certification added, PO acceptance passed first time;
Mobile UI walk-through on 6 mainstream devices, issues 0.

4. Quality Assurance: JMeter at the Core

4.1 JMeter

We standardized on Apache JMeter for both load and functional testing:

Open-source & extensible---custom weather-api sampler plug-in written in 2 h;
GUI + CLI---engineers script in GUI, CI calls non-GUI mode, results auto-export to InfluxDB + Grafana;
Distributed load---one controller + three slaves simulates 5 k concurrent users on a single 4-core note-book.

4.2 Beta-Phase QA Figures

65 test scripts, 820 assertions, 0 false positives;
95-th percentile response time 380 ms (target ≤ 500 ms);
Peak throughput 1 250 req/s @ CPU < 70 %, memory < 65 %;
Memory-leak 4-h soak test---heap growth < 2 %, no GC pause > 200 ms;
JMeter + Jenkins pipeline gates merge: performance regression > 5 % = build fail.

5. Blogging & Time Management

5.1 Verified Improvements

Log-as-code: PR template enforces link to "daily sprint log"; no post-sprint catch-up accepted.
Estimate double-lock: Dev estimate → tech-lead review; >20 % delta triggers retrospective.
Doc-sync gate: Function merged only after interface, test, deploy docs updated; no doc, no merge.

5.2 Beta-Phase Landing Results

Blog real-time update rate 100 %, zero last-minute rush;
Task actual vs. estimate median deviation 8 %;
Doc / code version mismatch 0.

6. Project-Wide Summary

6.1 Technical summary

The beta phase is delivered data-driven: all alpha issues are closed loop with quantifiable metrics; JMeter implements 5k concurrent stress tests, 95% response times ≤380ms, and embeds CI as performance gate control. The development process is fully strengthened - Git conflicts are zeroed, newcomer onboarding time is halved, and automated test coverage is 100%. The product functions not only fix defects, but also update high-value modules such as air warning and volunteer duration certification, and have zero problems with UI acceptance on all platforms, with an SLA of 99.9%.

6.2 Team perception

We have moved from "doing and making mistakes" to "doing and measuring". Role boundaries are clear but flexibility is retained ("Owner + 20% flex"), interface contracts ensure zero friction for collaboration, and physical + digital signage leaves risks unhidden. What's more, documentation, logs, and estimates are no longer remediated after the fact, but are reviewed together with code. This delivers not just a system, but a set of reusable, trustworthy, and truly production-oriented engineering habits.