Ch 2. 软件开发的过程
本章讲述软件产品的主要构成部分和几种常见的软件开发生命周期模式。
软件产品的组成部分
- 可交付物（Deliverables）：在软件行业，用于描述制造出来并交付给客户的产品或服务。
软件产品的投入
- 客户需求：编写软件的目的是满足一些人的需求，这些人通常被称为客户。必须准确地了解客户的需求，才能开发出满足这些需求的软件。
- 产品说明书：客户需求只是一些零散的原始资料，产品说明书综合这些信息并指明没有提出但应该实现的需求，真正定义了软件产品是什么、有哪些功能等。
- 严格的产品说明书应该是尽早锁定的，没有极特殊的情况，产品说明书应该在软件开发的早期就不再变更。这样的好处是开发小组的每个成员都知道他们在做且将要做的事情是什么。
- 进度追踪：软件开发是一个复杂的过程，需要对进度进行追踪，以确保软件能够按时交付。常见的形式包括甘特图、里程碑、用项目管理软件追踪等。
- 设计文档：设计文档是软件的蓝图，对软件如何规划组织、代码如何编写等进行了详细的描述。
- 测试文档：测试员必须描写自己的测试计划、测试用例、测试报告等。测试文档是软件质量保证的重要组成部分。
软件光盘或最终的程序只是组成软件产品的一部分。软件产品的投入远不止这些。
软件项目成员
- 项目经理（或者程序经理、监制人员）：负责整个项目的管理，包括进度追踪、资源分配、风险管理等。
- 架构师（或者系统工程师）：负责软件的整体设计，包括软件的组织结构、模块划分、接口设计等。通常与程序员关系紧密。
- 程序员：负责编写软件代码，实现设计文档中的内容。
- 质量保证团队（或者测试团队）：负责确保软件质量，包括编写测试计划、测试用例、测试报告等。
- 技术作家（或者文档编写人员）：负责编写软件的用户手册、技术文档等。
- 构建团队（或者部署团队）：负责将软件部署到用户的计算机上。
软件开发生命周期模式
以下四种为常见的软件开发生命周期模式，其他模式都或多或少是这些模式的变体。
大爆炸模式
一大堆人力和资金聚在一起，然后混沌地开发软件——Boom！
最后，你可能得到优秀的软件产品，当然更可能的是得到一堆垃圾。
- 优点是简单而直接，主要时间用于开发和编写代码；缺点是没有明确的计划，在最终交付前，没有人知道最终能产出什么样的软件。
- 这种情况下测试通常没有容身之地，有也是等到接近交付才开始。往好的说，测试员手里已经有了最好的产品说明书——软件本身；往坏的说，测试员所能做到的，也就是发现缺陷并报告给客户而已。
- 更有可能的是，开发人员嫌弃测试员的工作妨碍了交付，而测试员又反过来指责开发人员的代码质量低下。测试工作越深入，软件缺陷就越多，而争吵也就越激烈。
所以，避免在这种情况下承担测试员的工作！
边写边改模式
软件开发人员在编写代码的同时不断修改产品说明书，这种模式通常会导致软件质量低下。虽然如此，边写边改至少相较大爆炸模式而言对产品需求有多少考虑。
- 由于开头没有计划和文档编制，整个团队能够快速进入开发阶段，从而迅速展现成果。但这种模式的缺点是软件质量低下，因为没有明确的产品说明书，软件的功能和性能都无法得到保证。
- 这种模式下，测试员必须清醒地认识到，和程序员一样，他们也将陷入无止境的循环往复中。每天都会有新的软件版本，而新版本到来时，上个版本的测试工作很可能还没有完成。但无论怎么样，至少团队考虑到了测试工作。
- 这种模式是软件开发的入门，但不是长久之计。
瀑布模型
软件开发生命周期的经典模型，包括需求分析、设计、编码、测试、部署等阶段。
- 每个阶段都是线性的，即上一个阶段完全完成后才能进入下一个阶段。
- 每个阶段的工作互不交叉，每个阶段的工作人员也不同。
这也意味着没有回头路。如果在某个阶段发现了问题，那么只能回到上一个阶段重新开始。
- 瀑布模式非常强调软件的定义，设计与编码同等甚至更重要。
- 该模式的目标是在软件开发开始之前彻底解决所有未知问题并明确细节，以确保软件开发的顺利进行。
- 然而我们都知道，计划永远赶不上变化。当我们还停滞在反复斟酌定义时，也许用户的需求已经悄然改变。这也正是它的缺点。
从测试的角度看，这种模式前期完成的详尽的文档和设计对测试工作是非常有利的。无需额外的思量，测试员只需按照产品说明书中的要求进行测试即可。
然而，测试工作通常在软件开发的最后阶段才开始，这样一来，软件缺陷的修复成本就会大大增加。
螺旋模型
软件开发生命周期的一种变体，将软件开发过程分为多个小的瀑布模型，每个小瀑布模型称为一个螺旋。
- 每个螺旋包括多个阶段，包括计划、风险分析、工程开发、评审和测试等。
- 从测试的角度来说，该模式运行软件测试员在项目开发早期就能够参与进来，不仅能更好地了解产品，还能尽早地发现缺陷——测试员的测试一直都在进行。
小测验
说出程序员在开始编写代码之前要完成哪些任务。
在被认为较好的软件开发生命周期模式中，程序员在开始编写代码之前应该至少完成以下任务：
- 需求分析
- 架构 / 概要设计
- 详细设计
- 部分其他设计文档
- 产品说明书
- 进度追踪计划
- 测试计划
正式并被锁定、不能修改的产品说明书有何缺点？
产品说明书一旦被锁定，就不能再修改。过于严格的过程缺少对变更（来自客户或市场）的灵活性和弹性 。
大爆炸模式的最大优点是什么？
尽管大爆炸模式有很多缺点，但它的优点是简单而直接，主要时间用于开发和编写代码。
采用边写边改模式时，如何得知软件的发布时间？
当最终有机会对所有功能进行测试，且发现软件缺陷越来越少时，就可以确定软件的发布时间。
然而这个想法仍然过于主观，这也导致它实质上没有真正的退出标准。
瀑布模式为什么不好用？
瀑布模式的缺点在于整个流程是完全线性的。当发现此前某个阶段存在问题时，只能回到该阶段重新开始，期间的工作都将付之东流。
程序员为什么最喜欢螺旋模式？
螺旋模式解决了其他模式中存在的问题，同时有一些好的突破。团队在迭代中一边推进软件进度、一边保障软件质量，这对程序员来说是非常有利的。
同时，能够尽早地发现缺陷，也能够为项目节省时间和金钱。