软件开发

一个开发生命周期(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)——短迭代("冲刺")、持续的协作和测试。灵活且适应性强,但需要一个投入的客户和一个熟练的团队。

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

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

State-transition diagram

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

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

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

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

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

一个测试策略(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。每个值都必须写上它的预期结果,否则这份测试计划什么也证明不了。极端数据和边界数据是最常被混淆的一对:极端值处在范围之内且被接受,而边界测试永远是边缘两侧的一对值 - 那里正是差一错误藏身的地方。

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

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

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

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

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

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

• 比较开发模型(瀑布、迭代、RAD)并知道程序开发生命周期的各阶段。
• 区分语法、逻辑和运行时错误以及每个如何被发现。
• 选择三种测试数据——正常、边界和错误——并为陈述的范围给出每种的一个例子。
• 区分各类维护(纠正性、适应性、完善性)。