Worked Solutions · AP CSP-Feeder · US / ON / BC / AB Styles完整答案解析 · AP CSP 衔接 · 美 / 安 / 卑 / 阿省风格
A software team is creating flowcharts, pseudocode, and UML diagrams to plan their program structure before writing any code. Which SDLC phase are they in?一个软件团队在编写任何代码之前，正在创建流程图、伪代码和 UML 图来规划程序结构。他们处于 SDLC 的哪个阶段？
The Design phase is where the team converts requirements into concrete blueprints using tools such as flowcharts, pseudocode, UML class diagrams, and wireframes. No code is written yet. CSTA 3B-AP-17 states "processes could include agile, spiral, or waterfall" and names design as a distinct phase preceding implementation.设计阶段是团队将需求转化为具体蓝图的阶段，使用流程图、伪代码、UML 类图和线框图等工具。此时还未编写任何代码。CSTA 3B-AP-17 指出"过程可包括敏捷、螺旋或瀑布"，并将设计列为实现前的独立阶段。
Classify each requirement for a school portal app as Functional (F) or Non-functional (NF).将学校门户应用的每个需求分类为功能性（F）或非功能性（NF）。
1. F -- "allow students to view grades" describes what the system must do (a user action).1. F -- "允许学生查看成绩"描述系统必须做什么（用户操作）。
2. NF -- "load in under 3 seconds" describes how the system must perform (a performance constraint).2. NF -- "3 秒内加载"描述系统如何执行（性能约束）。
3. F -- "allow teachers to post due dates" describes what the system must do.3. F -- "允许教师发布截止日期"描述系统必须做什么。
4. NF -- "store passwords in encrypted form" describes a security quality constraint, not a user-visible action.4. NF -- "以加密形式存储密码"描述安全质量约束，而非用户可见的操作。
A functional requirement describes what the system must do (a specific user-visible action or output); a non-functional requirement describes how the system must perform (a quality constraint such as speed, security, or accessibility). AP CSP CRD-2.A and Ontario ICS3U B4.1 both require capturing both types before design begins.功能性需求描述系统必须做什么（特定的用户可见操作或输出）；非功能性需求描述系统如何执行（速度、安全性或无障碍性等质量约束）。AP CSP CRD-2.A 和安大略 ICS3U B4.1 都要求在设计开始前捕获两种类型。
Questions about the validate_login pseudocode and UML class diagrams.关于 validate_login 伪代码和 UML 类图的问题。
Input: username and password (two string parameters passed to the function). Output: the strings "Access granted" or "Access denied" (printed to the user) and a Boolean return value (True or False).输入：username 和 password（传递给函数的两个字符串参数）。输出：字符串 "Access granted" 或 "Access denied"（打印给用户）以及布尔返回值（True 或 False）。
Top section: class name (e.g., LoginSystem). Middle section: attributes -- the data the object stores (e.g., - username: str, - password: str). Bottom section: methods -- the operations the object can perform (e.g., + login(): bool, + logout(): void).顶部：类名（例如 LoginSystem）。中部：属性--对象存储的数据（例如 - username: str、- password: str）。底部：方法--对象可执行的操作（例如 + login(): bool、+ logout(): void）。
The UML class diagram is best suited for showing attributes and methods, because its three-section box format is specifically designed to organize class name, data fields (attributes), and operations (methods) in one visual structure.UML 类图最适合显示属性和方法，因为其三节盒子格式专门设计用于在一个视觉结构中组织类名、数据字段（属性）和操作（方法）。
Identify three coding standard violations in the temperature code and rewrite it.识别温度代码中的三个编码规范违规并重写。
x does not describe what it stores. Standard: meaningful names (BC CP11; CSE1120). Should be something like temperature_celsius.命名不佳：变量 x 没有描述其存储的内容。规范：有意义的命名（BC CP11；CSE1120）。应命名为 temperature_celsius 之类。37 is hard-coded with no explanation. Standard: no magic numbers -- replace with a named constant. Should be FEVER_THRESHOLD = 37 defined at the top.魔法数字：37 被硬编码且没有说明。规范：无魔法数字--用命名常量替换。应在顶部定义 FEVER_THRESHOLD = 37。# high just repeats the word "fever" printed below -- it says what the code does, not why. Standard: comments should explain the why. A better comment: # 37C is the clinical normal upper limit.无用注释：# high 只是重复了下面打印的"fever"--它说明代码做什么，而非为什么。规范：注释应解释原因。更好的注释：# 37C 是临床正常体温上限。(Also acceptable: inconsistent indentation -- 2 spaces instead of 4.)（也可接受：缩进不一致--2 个空格而非 4 个。）
FEVER_THRESHOLD = 37 # 37 degrees C is the clinical normal upper limit
# 37 摄氏度是临床正常体温上限
temperature_celsius = float(input("Enter temperature in Celsius: "))
if temperature_celsius > FEVER_THRESHOLD:
print("fever")
else:
print("normal")
Classify three error scenarios as Syntax, Logic, or Runtime.将三种错误场景分类为语法、逻辑或运行时错误。
The code is syntactically valid Python -- the interpreter can parse it with no errors. The problem only manifests when the program executes the line print(scores[5]) at runtime: the list scores has indices 0, 1, 2 (three elements), so index 5 does not exist. Python raises an IndexError at that exact moment of execution, not during parsing. This is why runtime errors cannot be caught by a parser or compiler -- the index is only known at runtime.该代码是语法上有效的 Python--解释器可以无错误地解析它。问题只在程序运行时执行 print(scores[5]) 行时才显现：列表 scores 的索引为 0、1、2（三个元素），所以索引 5 不存在。Python 在执行的那一刻引发 IndexError，而非解析时。这就是为什么运行时错误无法被解析器或编译器捕获--索引只有在运行时才可知。
The function definition def add(a, b) is missing the required colon (:) at the end. Python's parser will immediately raise a SyntaxError when it reads this line, before any code runs. The fix: def add(a, b):.函数定义 def add(a, b) 末尾缺少必需的冒号（:）。Python 的解析器在读取这一行时会立即引发 SyntaxError，在任何代码运行之前。修复：def add(a, b):。
The program runs without crashing (no syntax error, no exception) but produces the wrong answer -- that is the definition of a logic error. The condition if score > 90 uses a strict greater-than, so a score of exactly 90 falls through to the next branch and outputs "B" instead of "A". The algorithm is flawed, not the syntax or execution environment. The fix is to use if score >= 90 (greater-than-or-equal). This is a classic off-by-one boundary condition error, which BC CP11 and ICS3U B4.4 specifically name as a logic error.程序运行不崩溃（无语法错误，无异常），但产生错误答案--这就是逻辑错误的定义。条件 if score > 90 使用严格大于，所以恰好 90 分落入下一个分支并输出"B"而非"A"。算法有缺陷，而非语法或执行环境。修复是使用 if score >= 90（大于或等于）。这是一个经典的差一边界条件错误，BC CP11 和 ICS3U B4.4 将其明确命名为逻辑错误。
Team Alpha: library management system, fixed requirements. Team Beta: social study-group app, new features every two weeks.阿尔法团队：图书馆管理系统，需求固定。贝塔团队：社交学习小组应用，每两周有新功能需求。
Waterfall is more appropriate for Team Alpha. The requirements are fixed and well-understood, so the team can plan all seven SDLC phases in advance without expecting changes. Waterfall's sequential phase structure produces a predictable schedule and budget, which is ideal when requirements are stable.瀑布模型更适合阿尔法团队。需求固定且已明确，所以团队可以提前规划所有七个 SDLC 阶段而不预期变化。瀑布的顺序阶段结构产生可预测的进度和预算，这在需求稳定时是理想的。
Agile is more appropriate for Team Beta. One specific advantage: agile uses short two-week sprints, so the team can incorporate new user feature requests between sprints without scrapping months of prior work. In Team Beta's case, the menu of features changes every two weeks -- agile is built for exactly this kind of iterative, user-driven development.敏捷更适合贝塔团队。一个具体优点：敏捷使用两周短冲刺，所以团队可以在冲刺之间整合新的用户功能请求，而不需要废弃数月的先前工作。在贝塔团队的情况下，功能菜单每两周变化--敏捷正是为这种迭代、用户驱动的开发而构建的。
A key disadvantage of waterfall compared to agile: changes to requirements are expensive and difficult after a phase is complete, because waterfall assumes each phase is finished before the next begins. In agile, requirements can evolve each sprint.与敏捷相比，瀑布的一个主要缺点：阶段完成后，需求变更代价高昂且困难，因为瀑布假设每个阶段在下一个阶段开始前完成。在敏捷中，需求可以每次冲刺都演进。
Test plan for describe_temp(celsius): Freezing/Cold/Comfortable/Hot thresholds at 0, 15, 30.describe_temp(celsius) 的测试计划：阈值分别在 0、15、30 处产生 Freezing/Cold/Comfortable/Hot。
| Scenario场景 | Input输入 | Expected output预期输出 | Type类型 |
|---|---|---|---|
| Normal -- comfortable day正常 -- 舒适的一天 | 22 | ComfortableComfortable | Normal正常 |
| Normal -- freezing day正常 -- 冰冻的一天 | -10 | FreezingFreezing | Normal正常 |
| Exact boundary -- Freezing/Cold threshold精确边界 -- Freezing/Cold 阈值 | 0 | FreezingFreezing | Boundary边界 |
| Very large value (no upper limit)非常大的值（无上限） | 1000 | HotHot | Edge边缘 |
(Accept any valid boundary case at a threshold: 0, 15, or 30. Accept any reasonable edge case: very large number, very negative number, non-integer float.)（接受任何在阈值处的有效边界情况：0、15 或 30。接受任何合理的边缘情况：非常大的数字、非常负的数字、非整数浮点数。）
Error type: Logic error. The program runs without crashing but produces the wrong answer, so it is not a syntax or runtime error. The boundary condition the programmer got wrong is the condition for "Freezing": the code uses IF celsius < 0 (strict less-than), which means an input of exactly 0 falls into the "Cold" branch (0 < 15). The fix is to change the condition to IF celsius <= 0 or to restructure the thresholds so that 0 maps to "Freezing". This is a classic off-by-one boundary logic error.错误类型：逻辑错误。程序运行不崩溃但产生错误答案，所以不是语法或运行时错误。程序员出错的边界条件是"Freezing"的条件：代码使用 IF celsius < 0（严格小于），这意味着恰好 0 的输入落入"Cold"分支（0 < 15）。修复是将条件改为 IF celsius <= 0 或重构阈值使 0 映射到"Freezing"。这是一个经典的差一边界逻辑错误。
Write a docstring for convert_grade, name three maintenance types with examples, and classify a docstring's documentation type.为 convert_grade 编写文档字符串，命名三种维护类型并举例，以及分类文档字符串的文档类型。
def convert_grade(score):
"""
Convert a numeric score (0-100) to a letter grade.
将百分制分数（0-100）转换为字母等级。
Parameters / 参数:
score (float): numeric score, must be in [0, 100]
Returns / 返回:
str: letter grade "A", "B", "C", "D", or "F"
Raises / 异常:
ValueError: if score is outside [0, 100]
"""
> instead of >= for the C threshold and fixes it.纠正性维护 -- 修复用户报告的错误。例子：用户报告 70 分返回"D"而非"C"；程序员发现 C 阈值检查使用 > 而非 >= 并修复。A Python docstring is technical documentation. Its intended audience is developers who maintain or use the function in their own code -- they read the docstring to understand what the function does, what parameters it expects, and what exceptions it can raise, without needing to read the implementation. (It is not user documentation, which is for end users in plain language, nor inline comment, which appears inside the function body.)Python 文档字符串是技术文档。其目标受众是维护或在自己代码中使用该函数的开发人员--他们阅读文档字符串以了解函数的功能、期望的参数以及可能引发的异常，而无需阅读实现。（它不是面向最终用户的用户文档，也不是出现在函数体内的内联注释。）
Function f(l) sums positive numbers in a list. Identify four problems, rewrite it properly, and name two code review quality checks.函数 f(l) 对列表中的正数求和。识别四个问题，正确重写它，并命名两个代码审查质量检查。
f says nothing about what the function does. Standard: meaningful names. Should be something like sum_positive.函数命名不佳：f 没有说明函数的功能。规范：有意义的命名。应命名为 sum_positive 之类。l is ambiguous (looks like the digit 1 in some fonts) and does not describe the data. Standard: meaningful names. Should be numbers or values.参数命名不佳：l 有歧义（在某些字体中看起来像数字 1）且不描述数据。规范：有意义的命名。应命名为 numbers 或 values。t and i (where i is not an index counter but an element value) are unclear. Standard: meaningful names. t should be total; i should be num or value.变量命名不佳：t 和 i（其中 i 不是索引计数器而是元素值）不清晰。规范：有意义的命名。t 应命名为 total；i 应命名为 num 或 value。# add just describes what the return statement does (obvious from the code). Standard: comments explain the why, not the what. More importantly, no docstring is present -- for a function shared with others, a docstring is required to document the parameter type, return type, and purpose.无用注释和缺少文档字符串：# add 只是描述 return 语句做什么（从代码中已明显可见）。规范：注释解释为什么而非是什么。更重要的是，没有文档字符串--对于与他人共享的函数，需要文档字符串来记录参数类型、返回类型和目的。
POSITIVE_THRESHOLD = 0 # values must be strictly above this to be included
# 值必须严格大于此阈值才能包含在内
def sum_positive(numbers):
"""
Return the sum of all positive numbers in a list.
返回列表中所有正数的总和。
Parameters / 参数:
numbers (list): a list of numeric values
Returns / 返回:
float or int: the sum of all values greater than zero
"""
total = 0
for num in numbers:
if num > POSITIVE_THRESHOLD:
total = total + num
return total
Any two of: (1) variable/function naming clarity, (2) comment quality (explaining why, not what), (3) presence and accuracy of documentation (docstring), (4) edge case handling, (5) absence of dead code, (6) consistent indentation and style.以下任意两个：(1) 变量/函数命名清晰度，(2) 注释质量（解释为什么而非是什么），(3) 文档的存在和准确性（文档字符串），(4) 边缘情况处理，(5) 没有死代码，(6) 一致的缩进和风格。
POSITIVE_THRESHOLD = 0) here might seem excessive for a value of 0, but it demonstrates the principle: if someone later wants to change the threshold (e.g., "count only values above 5"), they change one line at the top, not every if-statement inside the loop. This is the key benefit of named constants -- single point of change. CSTA 3B-AP-23 specifically says "evaluate key qualities through a code review" -- the reviewer is asking "would another developer understand this in six months?" That is the standard your refactoring should meet.在这里使用命名常量（POSITIVE_THRESHOLD = 0）对于值 0 可能看起来过于繁琐，但它展示了原则：如果以后有人想要更改阈值（例如，"只计算大于 5 的值"），他们只需更改顶部的一行，而不是循环内的每个 if 语句。这是命名常量的关键好处--单一更改点。CSTA 3B-AP-23 特别指出"通过代码审查评估关键质量"--审查员在问"六个月后另一个开发人员能理解这个吗？"这是你的重构应该满足的标准。Locker assignment system: student inputs name, gets a locker number, locker marked taken. No lockers available = error message.储物柜分配系统：学生输入姓名，获得储物柜编号，储物柜标记为已占用。无可用储物柜 = 错误信息。
FR-1: The system shall accept a student name as input and output an available
locker number, then mark that locker as taken.
-- 系统应接受学生姓名作为输入，输出一个可用储物柜编号，然后将该储物柜标记为已占用。
FR-2: If no lockers are available, the system shall output the message
"No lockers available" instead of a locker number.
-- 若无可用储物柜，系统应输出"无可用储物柜"而非储物柜编号。
NFR-1: The system shall assign a locker in under 1 second for any input.
-- 系统应在 1 秒内为任意输入分配储物柜。
FUNCTION assign_locker(name)
IF LENGTH(lockers) == 0 THEN
OUTPUT "No lockers available"
RETURN -1
END IF
locker_num = lockers[0]
REMOVE lockers[0] FROM lockers
OUTPUT name + " assigned locker " + locker_num
RETURN locker_num
END FUNCTION
+---------------------------+
| LockerSystem | <-- class name
+---------------------------+
| - available_lockers: list | <-- attributes
| - assignments: dict |
+---------------------------+
| + assign_locker(name:str) | <-- methods
| + release_locker(num:int) |
+---------------------------+
Password strength checker: check_strength(pwd) returns "Strong" if len(pwd) >= 8 and pwd contains at least one digit, else "Weak".密码强度检查器：check_strength(pwd) 若 len(pwd) >= 8 且 pwd 包含至少一个数字则返回"Strong"，否则返回"Weak"。
| Scenario场景 | Input (pwd)输入 | Expected output预期输出 | Type类型 |
|---|---|---|---|
| 10 chars, has digit10 个字符，含数字 | abcdefgh12 | StrongStrong | Normal (strong)正常（强） |
| 5 chars, no digit5 个字符，无数字 | hello | WeakWeak | Normal (weak)正常（弱） |
| Exactly 8 chars, 1 digit恰好 8 个字符，1 个数字 | abcdefg1 | StrongStrong | Boundary边界 |
| Empty string空字符串 | "" | WeakWeak | Edge边缘 |
git add password_checker.py
git commit -m "Fix off-by-one: change > 8 to >= 8 for length check (fixes Strong boundary)"
git push origin main
Branches allow Anika and Ben to work on separate copies of the codebase simultaneously. Without branches, if both push to the same file at the same time, one person's changes will overwrite the other's. Branches isolate each developer's work until it is reviewed and ready to merge.分支允许阿妮卡和本同时在代码库的独立副本上工作。没有分支，如果两人同时推送到同一文件，一个人的更改会覆盖另一个人的。分支隔离每个开发人员的工作，直到它被审查并准备好合并。
len(pwd) > 8 (strict greater-than) instead of len(pwd) >= 8. This is why the commit message says "Fix off-by-one" -- an off-by-one in the boundary condition is a logic error, and the boundary test case is what reveals it. ICS4U B1.7 and BC CP11 both require version control -- Git's commit history provides an audit trail of who fixed what and why.边界测试用例（恰好 8 个字符，1 个数字）是这里最重要的测试--它正是能够捕获阿妮卡发现的错误的测试。密码"abcdefg1"（8 个字符，1 个数字）应该是"Strong"，但有问题的实现可能使用 len(pwd) > 8（严格大于）而非 len(pwd) >= 8。这就是为什么提交消息说"Fix off-by-one"--边界条件中的差一是逻辑错误，边界测试用例揭示了它。ICS4U B1.7 和 BC CP11 都要求版本控制--Git 的提交历史提供了谁修复了什么以及为什么的审计跟踪。Cafeteria menu voting app: students vote from 5 options; app announces winner at end of day. Agile, two-week sprints, Git collaboration.食堂菜单投票应用：学生从 5 个选项中投票；应用在一天结束时宣布获胜者。敏捷，两周冲刺，Git 协作。
Error type: Runtime error (specifically an IndexError). The program crashes when it tries to access a specific index to determine the winner, but that index does not exist or is ambiguous in a tie situation -- this only happens at execution time, not at parse time, making it a runtime error.错误类型：运行时错误（具体是 IndexError）。程序尝试访问特定索引来确定获胜者时崩溃，但在平局情况下该索引不存在或有歧义--这只在执行时发生，而非解析时，使其成为运行时错误。
SDLC phase where it should have been caught: Testing. A test case where two food items receive identical votes (e.g., Pizza = 5, Salad = 5) would have triggered the crash and revealed the missing tie-handling logic before deployment.本应捕获该故障的 SDLC 阶段：测试。一个两个食品获得相同票数（例如，披萨 = 5，沙拉 = 5）的测试用例会触发崩溃，并在部署前揭示缺失的平局处理逻辑。
Specific test case: Scenario = "Tie between two options"; Input = Pizza votes: 5, Salad votes: 5, all others: 0; Expected output = either the app announces both as co-winners or prompts for a runoff; Actual output (buggy) = IndexError crash. Type = Boundary / Error.具体测试用例：场景 = "两个选项平局"；输入 = 披萨投票：5，沙拉投票：5，其他：0；预期输出 = 应用宣布两者并列或提示决胜；实际输出（有缺陷）= IndexError 崩溃。类型 = 边界/错误。
Agile is a better fit because the cafeteria menu changes each term, meaning the list of vote options will change frequently; agile's two-week sprint cycle allows the team to update the option list at the start of each term without redesigning the entire system from scratch the way waterfall would require.敏捷更适合，因为食堂菜单每学期变化，这意味着投票选项列表会频繁更改；敏捷的两周冲刺周期允许团队在每学期开始时更新选项列表，而不需要像瀑布那样从头重新设计整个系统。