软件开发

一个开发生命周期(development life cycle)是从想法到完成、被维护的软件的一套阶段。它的存在是为了规划、管理和控制一个项目——按时、以好的质量构建正确的产品。

Why a life cycle is needed

考官关于"开发生命周期的用途"的清单:它把一个大项目分成可以规划和管理的阶段;它确保在设计和编码开始之前找到并确认需求;它把测试和文档内建进来,而不是留到最后;它让团队按里程碑跟踪进度并管理风险;它给客户定义好的评审节点。没有它,团队会先写代码,然后很晚才发现做错了东西。

Why there are different ones

没有单一的生命周期适合每个项目,所以存在几种开发生命周期(development life cycles)。选择取决于规模和复杂度、开始时需求(requirements)有多清晰、预期有多少变化、风险级别、团队,以及截止日期。

Common models

• 瀑布模型(Waterfall)——一个线性序列(分析 → 设计 → 编码 → 测试 → 维护),每个阶段在下一个之前完成。清晰且文档完善;适合稳定的需求,但不擅长应对项目中途的变化,而且客户直到最后才看到任何能工作的东西。
• 迭代模型(iterative model)——重复的趟数,每趟产出一个被评审和精炼的部分版本。更早发现问题;适合需求随时间被发现的情况,但更难估算。
• 快速应用开发(Rapid Application Development,RAD)——大量使用一个原型(prototype)和用户反馈。非常快的首次交付;适合变化的需求,但依赖用户的可用性并适合较小的系统。
• 敏捷(Agile)——短迭代("冲刺")、持续的协作和测试。灵活且适应性强,但需要一个投入的客户和一个熟练的团队。

原则、好处与缺点——按标准答案的列法。

例题。 一家公司必须率先推出一款新游戏机的网站,而设计会随着游戏机功能的公布而改变。说出最合适的生命周期并说明理由。

RAD。 网站的原型几天内就能做出并给用户看,并随需求变化而完善;网站规模小到适合原型驱动的方法,而交付速度是首要要求。瀑布模型会在任何页面做出之前就固定需求,并且直到最后才有交付。

The standard stages

每个阶段都有目的、产出和典型活动——"描述……阶段"的题目要的是其中两三条。

• analysis(分析)——找出程序必须做什么。活动:对现有系统的访谈、问卷和观察;可行性研究;确认需求规格说明,后面每个阶段都对照它检查。
• design(设计)——决定怎么做。产出:结构图(模块和参数)、每个模块的流程图或伪代码、标识符表和数据结构、屏幕和文件布局,以及现在就根据规格说明写好的测试计划——在任何代码存在之前。
• coding(编码,实现(implementation))——用高级语言按照设计逐个模块编写程序;每个模块写好就测试。
• testing(测试)——对照测试计划(正常、异常、极端和边界数据)运行程序并纠正发现的错误;随后是集成、α、β 和验收测试。
• maintenance(维护)——发布后,纠正故障,使程序适应新的硬件、软件或法律,并改进它(见下文)。

例题。 补全瀑布图 分析 → ? → ? → ? → 维护,并描述设计阶段发生什么。

缺少的阶段是设计、编码、测试。在设计阶段,需求被变成程序的规划:把问题分解成模块(结构图),每个模块的算法写成伪代码或流程图,选定数据结构和标识符,布置屏幕和文件,并根据规格说明写出测试计划。

Structure chart

一个结构图(structure chart)显示一个程序到模块(子程序(subroutines))的层次分解(hierarchical decomposition)以及它们之间传递的参数(parameters)。每个模块是一个矩形;线把调用者(上方)连到被调用者(下方);小箭头显示数据往下走、结果往上回。这个设计随后可被变成等价的伪代码(pseudocode)。

                CalculatePay
            /        |         \
       GetEmployee  CalculateBonus  CalculateTax
       Returns:     Takes: sales    Takes: gross
       employeeID   Returns: bonus  Returns: tax

它是一个设计阶段的工具,你可以从它读出过程签名。

考官会问的符号。 一个框是一个模块;一条线把调用者(上方)与它调用的模块(下方)连起来,按调用顺序从左到右读。尾部带空心圆的小箭头是数据耦合——向下传入模块的参数或向上返回的值;带实心圆的箭头是控制耦合,一个告诉调用者发生了什么的标志(通常是 BOOLEAN)。分支处的菱形表示选择:根据条件,只调用它下方模块中的一个。横扫各连线的弯曲箭头表示迭代:它下面的模块在循环中被反复调用。

例题。 四个模块定义为 PROCEDURE Main()、PROCEDURE ReadData(BYREF Count : INTEGER)、FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN 和 PROCEDURE Report(Total : INTEGER, Count : INTEGER)。Main 调用 ReadData,然后对读入的每个值调用一次 IsValid,最后调用 Report。描述这张结构图。

Main 在顶部;ReadData、IsValid 和 Report 在它下方一行,按调用顺序从左到右。ReadData 的连线上有一个向上的数据耦合 Count(BYREF 参数会传回来)。IsValid 的连线上有一个向下的数据耦合 Value 和一个向上的控制耦合(BOOLEAN 结果),这条连线上还有一个弯曲的迭代箭头,因为它对每个值都被调用。Report 的连线上有两个向下的数据耦合 Total 和 Count。反过来读,凡返回值的模块都是函数——它的头部需要 RETURNS 和返回类型。

State-transition diagram

一个状态转换图(state-transition diagram)显示一个系统可以处于的状态(states)以及在它们之间移动它的事件——适合自动售货机、交通灯、用户界面。状态转换图被用来记录一个算法或系统的行为。每个状态是一个圆;每个转换是一个用事件标注的箭头。

   coin inserted               item selected
[Idle] ──────────────→ [Awaiting selection] ──────────→ [Dispensing]

它使遗漏的转换容易被发现("如果在等待选择时投入第二枚硬币会怎样?")。

读图与画图。 每个转换标注为输入 | 输出(或条件 | 动作):发生了什么,然后系统在改变状态时做什么。题目会给一张当前状态、输入、输出、下一状态的表并要求画图,或者反过来——表中的每一行恰好是一个箭头。检查每个状态对每种可能出现的输入都有一个离开它的箭头,包括让状态保持不变的那些(绕回同一状态的箭头)。

例题。 一个水泵控制器有水泵关和水泵开两个状态。在水泵关时,输入检测到低水位产生输出启动水泵并转到水泵开;在水泵开时,检测到正常水位产生停止水泵并转到水泵关。其他任何输入都不改变状态。画出表格。

两行"无变化"在图上是自环箭头;漏掉它们会丢完整性的分。

• syntax error(语法错误)——破坏语言的语法(遗漏括号、拼错关键字)。在翻译时被捕获;在修正之前程序不会运行。
• run-time error(运行时错误)——在运行时发生(除以零、文件未找到、数组索引越界)。程序崩溃或抛出一个异常;通过添加检查来修正。
• logic error(逻辑错误)——程序运行但给出错误的结果(用 + 代替 -、一个差一的循环、条件顺序错误)。最难找到;唯一的迹象是错误的输出,所以用仔细的测试和追踪。

暴露和避免故障。 故障通过对照测试计划的测试、手工跟踪或跟踪表、与同事的走查,以及 IDE 的调试器(断点、单步执行、监视变量)被暴露。它们通过先设计后编码(结构图、伪代码)、带有意义的标识符和注释的模块化代码、对每个输入的验证、处理异常而不是让运行时错误使程序崩溃,以及 IDE 在输入时的动态语法检查被避免。

例题。 说出每种情况的错误类型及其表现。(a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) 在 y = "0" 时运行。(b) 同一行在 x = "12a" 时运行。(c) 写成 FOR i <- 1 TO 9 的循环处理一个十元素数组。(d) OUTPUT "Total: " Total 少了一个逗号。

(a) 运行时错误——除以零;这一行用这个数据执行时程序崩溃。(b) 运行时错误——字符串无法转换成数字。(c) 逻辑错误——程序能运行,但第十个元素从未被处理,所以输出错误。(d) 语法错误——该语句违反语言规则,在程序运行前就被翻译器报告。

例题。 纠正这段伪代码中的错误,它应当输出十个分数的平均值。

Total <- 0
FOR i <- 1 TO 10
    INPUT Mark
    Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average

除数应当是 10 而不是 9(逻辑错误);输出行在字符串和值之间需要一个逗号或 &(语法错误);Average 从未被声明为 REAL(语法或运行时错误,取决于语言)。要说明是哪一行以及改正后的行是什么:Average <- Total / 10。

• dry run(手工跟踪)——在纸上追踪代码,在一个表格里写下每个变量的值。
• walkthrough(走查)——对代码的一次团队评审。
• white-box testing(白盒测试)——从代码的内部结构设计,覆盖每条语句、分支和循环。
• black-box testing(黑盒测试)——只从规格说明设计:喂入输入,检查输出。
• integration testing(集成测试)——组合模块并测试它们之间的接口。
• alpha testing(α测试)——由开发者/内部在发布前;beta testing(β测试)——由有限的一组真实用户在他们自己的环境中。
• acceptance testing(验收测试)——由客户,以决定产品是否适合用途。
• stub(桩)——一个还不存在的模块的占位符,以便结构可以自顶向下地被测试。

何时用哪种方法。 手工跟踪和走查不需要计算机——手工跟踪是你用跟踪表(trace table)追踪算法;走查是作者逐行解释代码、同事寻找故障的会议,所以它还在团队中传播代码知识,并对照设计检查代码。白盒测试由能看到代码的人编写,目标是走遍每条路径;黑盒测试根据规格说明编写,只对照预期输出检查输入,所以用户或独立测试者也能做。集成测试在模块测试之后:单独通过的模块在它们之间传递的数据类型或顺序不对时仍会失败。α 测试在内部进行;β 测试把候选发布版交给一部分真实用户,他们从真实使用中报告故障;验收测试是客户在付款前对照需求检查成品。桩让自顶向下的测试在所有模块存在之前就能开始。

例题。 程序通过内部测试后,被交给一组用户在发布前试用。说出这种测试的名称,并说明接下来发生什么。

β 测试——真实用户在自己的环境中使用,报告开发者没发现的故障。故障被纠正后,客户对照需求进行验收测试,然后程序发布;正式使用中发现的故障之后由纠正性维护处理。

例题。 给出用走查测试程序的三个好处。

错误由没有写这段代码的人发现,他们读代码时没有先入之见;逻辑对照设计和规格说明检查,而不只对照测试数据;几个人学会了代码的工作方式,有助于日后维护;不需要测试数据或能用的计算机,所以可以早做。

一个测试策略(test strategy)是高层的方法——哪几种测试、谁做、何时,以及往前推进的标准。一个测试计划(test plan)是详细的测试清单——每个带输入数据、预期输出,以及一个记录实际输出的列。

各自包含什么。 测试策略说明在哪个阶段用哪些测试方法(程序员做模块测试,然后是集成、α、β、验收),每项由谁负责,需要什么测试数据,以及进入下一阶段的标准。测试计划列出各个测试:对每个测试,写明被测模块或功能、输入数据、选择该数据的理由(正常、异常、极端、边界)、预期结果、留给实际结果的空位,以及两者不同时怎么办。计划在设计阶段根据规格说明写成,这样它测的是程序应当做什么,而不是它碰巧做什么。

Choosing test data

对每个字段或条件,包含三种:

• normal data(正常数据)——有效范围内的典型值(对于分数 0–100:50、75)。
• abnormal data(异常数据)——应当被拒绝的值(-10、200、"abc")。
• extreme data(极端数据)——仍被接受的最大和最小值(0 和 100)。
• boundary data(边界数据)——在边缘的值,差一错误藏在那里(每个被接受的极端值和刚好在它外面被拒绝的值:0/-1、100/101)。

例题。 某字段接受 0 到 100 的考试分数。给出各类测试数据及其预期结果。正常数据:50 - 被接受,是范围内的典型值。异常数据:-10、200、"abc" - 全部被拒绝,因为超出范围或数据类型错误。极端数据:0 和 100 - 仍然被接受的最大值和最小值。边界数据:跨在每个边缘两侧的成对值 - 被拒绝的 -1 配上被接受的 0,以及被接受的 100 配上被拒绝的 101。每个值都必须写上它的预期结果,否则这份测试计划什么也证明不了。极端数据和边界数据是最常被混淆的一对:极端值处在范围之内且被接受,而边界测试永远是边缘两侧的一对值 - 那里正是差一错误藏身的地方。

例题。 一个部件的重量(精确到克)在目标 50 g 的 3 g 之内即合格,也就是 47 g 到 53 g(含)。写出这项检查的测试计划各行。

每一行都必须说明为什么选这个值和应当发生什么;光列一串数字不得分。

一个程序生命期成本的大部分在维护中。三种:

• perfective maintenance(完善性维护)——即使它能工作,也改进性能或功能(一个更快的查询、一个新选项)。
• adaptive maintenance(适应性维护)——在一个变化的环境中保持它工作(一个新 OS、一个新 API、一个法律变更)。
• corrective maintenance(纠正性维护)——修复使用中发现的漏洞。

一个程序在它一生中可能需要全部三种。

为什么需要每一种——标准答案列出的原因。 纠正性:发布后用户报告了故障,或在测试未覆盖的特定情况下发现输出不正确。适应性:操作系统、硬件或浏览器升级;法律或公司规定改变(税率、数据保护要求);程序必须与新的外部系统或文件格式配合。完善性:用户要求额外功能或更好的界面;程序被做得更快或占用更少内存;整理代码以便日后修改。

例题。 (a) 一个已发布的程序在某些情况下输出错误的值。(b) 运行程序的硬件被更换。(c) 顾客要求咖啡店的积分程序在顾客生日时发送消息。说出每种情况的维护类型。

(a) 纠正性——修复交付程序中的故障。(b) 适应性——修改程序以在新环境中运行。(c) 完善性——给一个已经能工作的程序增加功能。

当被要求添加一个功能或修复一个漏洞时:

1. 阅读现有代码,直到你理解算法和数据流。
2. 找出改动在哪里——哪个子程序、哪些行。
3. 让改动尽可能小——不要重写能工作的代码。
4. 更新相关部分——一个改动过的参数列表的每个调用者、使用一个改动过的数据结构的每个例程。
5. 测试新行为和旧行为(回归测试(regression testing)——检查你没弄坏任何东西)。
6. 记录改动。

清晰的注释、有意义的名称、分解的子程序和一张结构图使一个程序更容易被修改——这就是为什么设计工具即使在首次发布之后也重要。

分析一个不是你写的程序。 从标识符表和模块头开始:在读它的任何一行主体之前,它们已经告诉你每个模块接收什么、返回什么。然后用跟踪表对一个小输入追踪算法,记下每个输出值来自哪里。这之后再决定增强功能放在哪里——通常是从现有模块调用的一个新模块,这样能工作的代码被扰动得最少——并写出改动的伪代码和证明它的测试数据。

定义题按固定措辞给分。把这些记准,并且只给一个答案。

• 按原则、好处、缺点比较开发模型(瀑布、迭代、RAD),并知道程序开发生命周期的五个阶段及各自的产出。
• 按每种错误何时显现来区分语法、逻辑和运行时错误:翻译时、输出中、运行期间。
• 选择每一类测试数据——正常、异常、极端和边界——并给出每个值的理由和预期结果。
• 按为什么改动来区分各类维护(纠正性、适应性、完善性)。
• 在结构图上说出每个符号的名称:框、调用线、数据耦合、控制耦合、选择菱形、迭代箭头。从图中读出模块头时,记住函数有 RETURNS。

常见错误

• 只用名称描述生命周期的阶段("在设计阶段设计程序")。要说产出什么:结构图、伪代码、测试计划。
• 把错误的输出叫作"运行时错误"。如果程序运行到结束,那是逻辑错误。
• 把边界数据只给成极端值。得分需要边缘两侧的值。
• 把 α 测试和 β 测试当成一回事。α 由开发者在内部做;β 由外部真实用户做。
• 混淆适应性和完善性维护。适应性是对程序之外变化的响应;完善性是改进一个没人非改不可的程序。
• 结构图上模块随意排列。它们按调用顺序从左到右读,每个参数都需要它的箭头。