Software Development Process软件开发流程

Requirements.需求。 Users (students) need to add tasks with due dates, mark tasks complete, and sort by urgency. Constraint: must work on mobile.用户（学生）需要添加带截止日期的任务、标记任务为已完成并按紧迫性排序。约束：必须在手机上运行。

Analysis.分析。 Inputs: task name, subject, due date. Outputs: sorted task list. Data: each task stores {name, subject, due_date, done}. Edge case: two tasks on the same due date.输入：任务名称、学科、截止日期。输出：已排序的任务列表。数据：每个任务存储 {name, subject, due_date, done}。边缘情况：两个任务的截止日期相同。

Design.设计。 Produce a flowchart for "add task," pseudocode for "sort by due date," and a simple UML class sketch showing Task attributes and methods.为"添加任务"画流程图，为"按截止日期排序"写伪代码，并画出显示 Task 属性和方法的简单 UML 类草图。

Implementation.实现。 Write Python/JavaScript code following the design. Apply coding standards: meaningful names, inline comments, no magic numbers.按照设计编写 Python/JavaScript 代码。遵循编码规范：有意义的命名、内联注释、无魔法数字。

Testing.测试。 Test plan: normal case (add 3 tasks, verify sort), boundary case (task due today), error case (no tasks in list — display "no tasks").测试计划：正常情况（添加 3 个任务，验证排序），边界情况（今天截止的任务），错误情况（列表中无任务——显示"无任务"）。

Documentation/Deployment.文档/部署。 Write a README describing how to install and use the app. Deploy to the school server.编写描述如何安装和使用应用的 README。部署到学校服务器。

Maintenance.维护。 Users report that tasks with the same due date display in the wrong order — fix the sort comparator and increment the version number.用户报告截止日期相同的任务显示顺序不正确——修复排序比较器并更新版本号。

Functional requirements.功能性需求。

FR-1: The program shall accept exactly 5 numeric scores as input.
      -- 程序应接受恰好 5 个数字成绩作为输入。
FR-2: The program shall compute the arithmetic mean of the 5 scores.
      -- 程序应计算 5 个成绩的算术平均值。
FR-3: The program shall output a letter grade (A/B/C/D/F)
      based on the mean (A>=90, B>=80, C>=70, D>=60, F otherwise).
      -- 程序应根据平均值输出字母等级（A>=90, B>=80, C>=70, D>=60, 否则 F）。

Non-functional requirements.非功能性需求。

NFR-1: Scores outside [0, 100] shall trigger an error message, not a crash.
       -- 范围 [0, 100] 之外的成绩应触发错误消息，而非程序崩溃。
NFR-2: The program shall run in Python 3.8+ with no external libraries.
       -- 程序应在 Python 3.8+ 中运行，无需外部库。

Notice that every requirement is numbered (so test cases can reference them: "Test for FR-3, boundary case score=90") and testable.注意每个需求都有编号（以便测试用例可以引用它们："FR-3 的测试，边界情况 score=90"）且可测试。

1. Pseudocode.1. 伪代码。

INPUT username, password
IF username == "admin" AND password == "pass123" THEN
    OUTPUT "Login successful"
ELSE
    OUTPUT "Invalid credentials"
END IF
-- 以上：如果用户名为 "admin" 且密码为 "pass123"，输出"登录成功"，否则输出"无效凭据"。

2. Flowchart (text description).2. 流程图（文字描述）。

Oval "START" → Parallelogram "Input username, password" → Diamond "username='admin' AND password='pass123'?" → YES: Parallelogram "Output: Login successful" → Oval "END"; NO: Parallelogram "Output: Invalid credentials" → Oval "END".椭圆"开始"→ 平行四边形"输入用户名、密码"→ 菱形"username='admin' 且 password='pass123'？"→ 是：平行四边形"输出：登录成功"→ 椭圆"结束"；否：平行四边形"输出：无效凭据"→ 椭圆"结束"。

3. UML Class Diagram (intro level).3. UML 类图（入门级）。

+------------------+
|   LoginSystem    |   <-- class name 类名
+------------------+
| - username: str  |   <-- attributes (- means private)
| - password: str  |       属性（- 表示私有）
+------------------+
| + login(): bool  |   <-- methods (+ means public)
| + logout(): void |       方法（+ 表示公有）
+------------------+

The UML box shows what data the class stores (attributes) and what actions it can perform (methods). This is the design blueprint; the Python implementation follows from it.UML 盒子显示类存储哪些数据（属性）以及可以执行哪些操作（方法）。这是设计蓝图；Python 实现由此而来。

Original (bad) code.原始（糟糕的）代码。

x = float(input("enter: "))
y = (x*9/5)+32
if y>212:
  print("boiling")  # hot

Violations identified.识别的违规之处。

• Poor names: x, y. Magic number: 212. Useless comment: # hot just repeats what the print says. Inconsistent indentation (2 spaces, not 4).命名不佳：x、y。魔法数字：212。无用注释：# hot 只是重复了 print 的内容。缩进不一致（2 个空格，而非 4 个）。

Refactored (good) code.重构后（好的）代码。

BOILING_POINT_F = 212  # water boils at 212°F at sea level
                        # 水在海平面 212°F 沸腾

celsius = float(input("Enter temperature in Celsius: "))
fahrenheit = (celsius * 9 / 5) + 32

# Check if temperature exceeds boiling point (relevant for lab safety)
# 检查温度是否超过沸点（与实验室安全相关）
if fahrenheit > BOILING_POINT_F:
    print("Warning: above boiling point")

The refactored version has meaningful names, a named constant, a useful comment explaining the why, and consistent 4-space indentation. The logic is identical — only the readability changed.重构后的版本具有有意义的名称、命名常量、解释为什么的有用注释以及一致的 4 个空格缩进。逻辑完全相同——只有可读性发生了变化。

Note: boundary cases at the exact threshold values (90, 80, 70, 60) are critical — they test whether >= is correctly used instead of >. An off-by-one here is a logic error.注意：恰好在阈值（90、80、70、60）处的边界情况至关重要——它们测试是否正确使用 >= 而非 >。这里的差一错误是逻辑错误。

# grade_calculator.py — Dingrui Scholars Grade Tool, v1.0
# Author: student team | Last updated: 2026-01
# License: MIT
# 成绩计算工具 — 模块说明：根据百分制分数返回字母等级

def compute_grade(score: float) -> str:
    """
    Convert a numeric score (0-100) to a letter grade.
    将百分制分数（0-100）转换为字母等级。

    Parameters / 参数:
        score (float): numeric score, must be in [0, 100]
                       百分制分数，必须在 [0, 100] 范围内
    Returns / 返回:
        str: letter grade "A", "B", "C", "D", or "F"
             字母等级 "A", "B", "C", "D" 或 "F"
    Raises / 异常:
        ValueError: if score is outside [0, 100]
                    如果分数超出 [0, 100] 范围
    """
    # Validate input before processing (NFR-1)
    # 处理前验证输入（对应非功能性需求 NFR-1）
    if not (0 <= score <= 100):
        raise ValueError(f"Score {score} out of range [0, 100]")

    # Grade thresholds — defined as constants to avoid magic numbers
    # 成绩阈值——定义为常量以避免魔法数字
    A_THRESHOLD, B_THRESHOLD = 90, 80
    C_THRESHOLD, D_THRESHOLD = 70, 60

    if score >= A_THRESHOLD:
        return "A"
    elif score >= B_THRESHOLD:
        return "B"
    elif score >= C_THRESHOLD:
        return "C"
    elif score >= D_THRESHOLD:
        return "D"
    else:
        return "F"

The docstring (triple-quoted string) is the standard Python technical documentation format. Tools like Sphinx auto-generate HTML documentation from docstrings. The inline comments explain the why. The module header is the user-facing documentation for anyone reading the file.文档字符串（三引号字符串）是标准的 Python 技术文档格式。Sphinx 等工具从文档字符串自动生成 HTML 文档。内联注释解释为什么。模块头是面向任何阅读文件的人的用户文档。

# Day 1: Student A sets up the repository
# 第 1 天：学生 A 创建仓库
git init grade-calc
cd grade-calc
# 创建 grade_calculator.py 并编写初始函数
git add grade_calculator.py
git commit -m "Add compute_grade() function with A/B/C/D/F thresholds"
git push origin main

# Day 2: Student B clones and adds tests
# 第 2 天：学生 B 克隆并添加测试
git clone https://github.com/team/grade-calc
# 编写 test_grade_calculator.py 测试文件
git add test_grade_calculator.py
git commit -m "Add test plan: normal, boundary, and error cases for compute_grade()"
git push origin main

# Day 3: Student A fixes a boundary bug found by the tests
# 第 3 天：学生 A 修复测试发现的边界错误
# 将 'score > 90' 修正为 'score >= 90'（差一错误）
git add grade_calculator.py
git commit -m "Fix off-by-one: change > to >= for A threshold (fixes test TC-2)"
git push origin main

Each commit message is specific: it says what changed and why. This makes the project history readable — anyone can understand the change log without opening each file. The commit message "fixes test TC-2" links the code change to the test plan row, closing the requirements → design → implement → test → fix loop.每条提交消息都很具体：它说明了更改了什么以及为什么。这使项目历史可读——任何人都可以在不打开每个文件的情况下理解变更日志。提交消息"fixes test TC-2"将代码更改与测试计划行关联起来，形成需求 → 设计 → 实现 → 测试 → 修复的完整闭环。