一、软件与软件工程概述

1. 软件的组成与演化

软件的构成

• Software(软件) 通常由 computer programs(计算机程序)、data structures(数据结构)、software description information(软件描述信息) 组成，或者说由 set of programs(程序集合)、documentation(文档) 和 configuration of data(数据配置) 三部分所构成。
• 在企业实际开发中，软件的documentation(文档) 除了包括需求规格、设计文档外，还会包含对系统安装、使用、维护等多种描述信息。

软件工程的目的

• The application of engineering techniques to software development
• 将系统化和规范化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。

软件与硬件的区别

• 软件是被开发的，硬件是被制造的。
• 软件会退化，硬件会磨损。
• 软件是定制的，硬件是由部件组装而成的。

软件退化与变更

• Deteriorate(退化/老化)：软件在不断迭代更新或进行功能添加、结构修改时，往往会引入新的错误或导致结构复杂度上升。因此，在变更时需要适度 constrain(约束)。
• 同时，软件也必须变更才能适应新技术、新商业需求、以及与其他系统或数据库协作的需要。这种“需求牵引”的变更也成为软件发展的常态。

软件开发中的误区

• Management myths(管理误区)：很多人认为在项目陷入进度问题时“加人就可以提升效率”，但其实会因为沟通与培训等成本的增加导致效率降低。正确做法是在项目的早期做好资源规划，并在后期需要时谨慎评估增员带来的收益和影响。

---

2. 软件工程的层次与过程改进

软件工程的四个层次

• Tools(工具)：比如代码编辑器、构建工具、集成开发环境、版本管理工具等，为开发活动提供便利。
• Methods(方法)：包括需求获取、建模、设计、编码规范、测试方法等；工具往往是对这些方法的技术支撑。
• Process model(过程模型)：定义何时、如何、由谁来完成哪些活动，并输出什么产物。
• A quality focus(对质量的关注)：指导所有层次与阶段，以确保软件满足功能和非功能需求，并具有良好的可维护性、可扩展性等。

sw-CMM(capability maturity model)(软件能力成熟度模型)

• Initial(初始级)：过程无序，成功主要依赖个人能力
• Repeatable(可重复级)：可在类似项目中复用某些经验
• Defined(已定义级)：过程已被文档化、标准化并在全组织推广
• Managed(已管理级)：通过度量来监控并管理质量与过程
• Optimized(优化级)：持续改进、主动引入最佳实践

---

二、软件过程与敏捷方法

1. 通用过程框架 (generic process framework)

主要活动

• Communicating(沟通)：在项目早期及过程中，通过会议、访谈、群组讨论等方式明确需求、传递信息。
• Planning(计划)：包括甘特图或Scrum backlog等计划制订，估算资源与成本。
• Modelling(建模)：包含 analysis of requirements(需求分析) 与 design(设计)，通过需求建模、系统建模等方式使抽象变得可视化。
• Construction(构造)：包含 code generation(代码生成) 与 testing(测试)，是将设计转化为可执行的软件并验证其质量的核心阶段。
• Deploy(部署)：将软件在目标环境中运行并提供 feedback report(反馈报告)，可根据反馈进行修正或优化。

贯穿始终的活动 (umbrella activity)

• Quality assurance(质量保证)：包括评审、度量、改进等机制。
• Configuration management(配置管理)：对需求、代码、文档、环境等进行版本控制和变更跟踪。
• Project tracking(项目跟踪)：使用进度表、燃尽图等手段确保项目如期进行。
• Risk management(风险管理)：识别并跟踪风险，如需求变更风险、技术风险、人员流失风险等。
• Technical reviews(技术评审)：在各里程碑对需求、设计、代码等进行评审，早期发现并纠正缺陷。

Process flow(过程流)

• Linear process(线性过程)：如瀑布模型，从需求到部署一次性流动。
• Iterative process(迭代过程)：进行多次迭代，每次都交付一个部分可用的成果。
• Evolutionary(演化式过程)：持续演进，快速原型和迭代示例，逐步完善。
• Parallel(并行过程)：并行处理不同子系统或模块，以加快整体进度并减少等待时间。

2. 常见过程模型

（1）Waterfall model(瀑布模型)

• 线性顺序：需求分析 → 设计 → 实现 → 测试 → 部署与维护。
• 使用这种过程模型要求客户的需求需要明确定义并且相对稳定。
• 缺点是线性开发很难，只有在项目接近尾声才能得到可执行的程序。

（2）Incremental model(增量模型)

• 将系统需求拆分为多个增量，每个增量都能提供可运行的软件功能。
• 与 iterative process(迭代过程) 对应，在每次增量交付后根据反馈进一步修正下一增量需求。

（3）RAD(rapid application development)model(快速应用开发模型)

• 适合对市场或者业务需求响应速度要求很高的场景。
• 借助强大的原型工具和丰富人力资源，快速完成功能并进行用户评估。

（4）Prototyping model(原型模型)

• 客户需求不明确时使用：客户需求不明确时先构建一个“原型”供客户交互体验，通过客户反馈不断修正需求，减少主观猜测带来的风险。
• 原型可能被持续演化成正式产品，也可能仅作为最终系统的参考。

（5）Spiral model(螺旋模型)

• 兼具迭代特性与风险分析，每一环都要进行目标设定、风险分析、开发与验证及规划下一环。
• 与 evolutionary(演化式过程) 对应，适合复杂、需求多变且技术风险大的项目。

3. Unified process model(统一过程模型)

• 包含以下 phase(阶段)：
  1. Inception(初始阶段)：确认项目愿景和范围，初步估算成本和进度
  2. Elaboration(细化/阐述阶段)：解决高风险，完善需求模型和架构模型
  3. Construction(构造阶段)：开发完成大部分功能，并进行多次迭代测试
  4. Transition(移交/过渡阶段)：部署到生产环境，用户验收与性能优化
  5. Production(生产/维护阶段)：对软件进行持续修复、优化和更新

以迭代和增量方式进行，支持在开发过程中不断修正和完善。

4. 敏捷方法

核心原则

• Manifesto for agile(敏捷宣言) 强调：
  • Individuals and interactions over processes and tools（个体和互动高于流程和工具）
  • Working software over comprehensive documentation（可工作的软件高于冗长文档）
  • Customer collaboration over contract negotiation（客户协作高于合同谈判）
  • Responding to change over following a plan（响应变化高于遵循计划）

常见敏捷模型

• Agile XP(extreme programming)(极限编程)：侧重结对编程、持续集成、小步前进、频繁发布。
• Scrum(敏捷框架)：以短迭代(sprint)、每日站会(daily stand-up meeting)、产品待办列表(product backlog)等方式进行进度推进。
• ASD(adaptive software development)(自适应软件开发)：包含 speculation(推测)、collaboration(协作)、learning and adapt(学习与适应)，鼓励在快速变化的环境中动态应对。

Scrum 与 Agile XP 的区别

• Scrum 特点：
  • 工作被分割成 packets(小包任务)；每次迭代称为sprint(冲刺)
  • 测试和文档与构建产品同步进行
  • 每日站会上只说明“昨天做了什么、今天计划做什么、有什么阻碍”，不深入探讨阻碍的原因
  • 在 time-box(时间盒) 限定的时间内向客户demos(演示)，并根据反馈更新backlog(待办项)
• Extreme Programming(XP) 更强调：
  • Pair programming(结对编程)：两人一起编写和审阅代码
  • Refactoring(重构)：不断优化代码的内部结构
  • User stories(用户故事)：从用户角度描述需求
  • 规划游戏、持续集成、测试驱动开发（TDD）等具体实践。

Extreme Programming(XP) 的构成

• XP planning(规划)：以 user stories(用户故事) 作为需求单元，通过“规划扑克”等形式对工作量进行预估。
• XP designing(设计)：
  • 遵循 KIS(keep it simple)(保持简单) 原则，避免过度设计。
  • 使用 CRC(class-responsibility-collaborator)(类-职责-协作者) 识别并记录类的职责分工。
  • 不断 refactoring(重构)，保持代码清晰和可维护。
• XP coding(编码)：核心实践是 pair programming(结对编程)；在实际中，也可能是轮换制的结对或进行代码走查。
• XP testing(测试)：鼓励测试驱动开发(TDD)，先写测试再写功能代码，每次提交前都要跑测试。

---

三、需求工程与建模

1. 需求类型与获取

需求分类

• Functional requirements(功能需求)：系统“做什么”，涵盖 capabilities(功能能力)、dynamic behavior(动态行为)、data manipulation(数据处理)。
• Non-functional requirements(非功能需求)：系统“如何做”，关注性能、可靠性、可维护性、安全性、可移植性等方面的约束或限制。

需求工程七步

1. Inception(初始)：确定初步项目视图和主要利益相关者
2. Elicitation(获取)：常用Elicitation techniques（问卷调查、面谈、专题讨论会等），first step is identifying the stakeholder(识别利益相关者)
3. Elaboration(细化)：在初步需求的基础上进行分析和细化
4. Negotiation(协商)：平衡成本、进度和范围之间的冲突
5. Specification(规格说明)：描述了 function(功能)、performance(性能)、constraints(约束)
6. Validation(验证)：通过评审、原型、测试用例等来确认需求正确性
7. Requirements management(需求管理)：使用 traceability table(可追踪表) 跟踪需求随时间和变更的演化

8. QFD(quality function deployment)(质量功能展开)

   • 通过对需求进行normal(普通)、expected(期望)、exciting(兴奋)的划分，区分哪些是“必须有”与“惊喜值”功能，对需求优先级进行更精细的决策。

2. 需求分析与建模

需求分析的目标

• 明确软件在功能和非功能方面的要求；确定软件对外的接口关系，以及需要满足的各种业务和技术约束。

需求建模的作用

• 把客户的想法或业务需求可视化、结构化地表达出来
• 为软件设计阶段提供信息，能较容易地转化为软件的架构和接口。
• 在开发完成后，需求模型也可用来评估软件质量或进行需求追踪。

常见需求模型

• Scenario-based model(基于场景的建模)：
  • 三步：分析stakeholder(利益相关者) → 绘制use-case diagram(UML用例图) → 写use-case specification(用例规格说明)。
  • Use-case specification 一般包含参与者、用例说明、前置条件、后置条件、输入/输出数据、事件流（基本流+异常流）。
  • UML activity diagram(UML活动图) 往往是Scenario-based model必需的可视化工具。
• Class-modeling(类建模)：
  • 使用 CRC(class-responsibility-collaborator)(类-职责-协作者) 分析类的职责与协作关系。
  • 在 UML class diagram(UML类图) 中，需关注 aggregation(聚合)、polymorphic(多态)、inheritance(继承) 等关键概念。
• 面向数据流的建模：
  • DFD(data flow diagram)(数据流图) 用于描述系统数据的输入、输出、存储和处理流程，说明系统如何转换并输出数据。
• 行为建模：
  • Sequence diagram(顺序图) 展示参与者和对象之间的消息流。
  • UML state diagram(UML状态图) 则用来展示对象在不同状态之间的转换和条件。

---

四、软件设计

1. 设计模型

• Design model(设计模型) 通常包含：

  • Data/class design(数据/类设计)
  • Architectural design(架构设计)
  • Interface design(接口设计)
  • Component-level design(组件级设计)

• 高质量设计模型需 implements all requirements in the analysis model(实现分析模型中的全部需求)，并 provides a complete picture of the software(提供对软件的完整描述)。

2. 设计关键概念

• Modularity(模块化)

  • 将系统分解为若干易于理解和管理的模块，以提高可维护性和可扩展性。
  • 需要在模块数量和复杂度之间做平衡，保证沟通和开发成本最优。

• Refinement(精炼)

  • 又称 elaboration(细化)。从抽象概念层层细化到具体实现，逐步增加细节。

• Refactoring(重构)

  • 在不改变对外行为的前提下，优化代码或架构的内部结构，如替换低效的数据结构或算法。
  • 是持续提升代码质量、降低维护成本的重要手段。

• Deployment elements(部署要素)

  • 指明软件功能或子系统在物理计算环境（如服务器、容器、云平台）中的分布与依赖关系。

• Architectural design(架构设计)

  • 依赖 architectural styles(架构风格)；每种风格都包含 set of component(组件集合)、constraint(约束) 和 semantic model(语义模型)。
  • 常见风格有分层架构、事件驱动架构、微服务架构等。

• Component-level design(组件级设计)

  • A component(组件) 包含一个或多个协作完成特定功能的类/模块，也可能是一个可复用的服务/微服务。

3. 面向对象设计原则

• OCP(open-closed principle)(开闭原则)

  • 对扩展开放、对修改封闭。举例：在主类方法中使用接口作为参数类型，当需要新增功能时只需新建一个实现该接口的新类，而无需修改原有主类。

• SRP(single responsibility principle)(单一职责原则)

  • 每个类或模块只负责一项职责，功能单一、聚焦，可降低耦合度、提高可维护性。

• LSP、DIP、ISP

  • LSP(liskov substitution principle)(里氏替换原则)：子类必须能替换父类且行为一致。
  • DIP(dependency inversion principle)(依赖倒置原则)：高层模块不依赖低层模块，而共同依赖抽象；接口或抽象不依赖具体实现。
  • ISP(interface segregation principle)(接口隔离原则)：使用多个专门的接口，而不使用一个冗长臃肿的接口。

4. 内聚与耦合

• Cohesion(内聚性)

  • 模块内部属性和操作间相互关联的程度，高内聚常被视为好设计。例如 functional cohesion(功能内聚)、layer cohesion(层次内聚)、communicational cohesion(通信内聚) 等。

• Coupling(耦合性)

  • 模块之间依赖程度。耦合度越低越好。
  • 常见优劣顺序：data(数据耦合) < stamp(标记耦合) < common(公共耦合) < control(控制耦合) < content(内容耦合)。

---

五、测试与质量保证

1. 测试概述

测试原则

• 一个 good test(好测试) 应该 have a high probability of finding an error(有高概率发现缺陷)、is not redundant(不冗余)，且 not too simple or too complex(恰到好处)。

测试类型

• Unit test(单元测试)：针对最小单元(函数/类)，需要 driver(驱动程序) 和 stub(桩程序) 来模拟外部依赖或被依赖模块。（因为被测模块不是独立的程序，所以不能直接运行，需要搭建脚手架）
• Integration test(集成测试)：验证模块或子系统之间的接口和协同工作。
• Validation test(验证测试)：从需求角度验证系统是否实现了所需功能（含非功能需求）。
• System test(系统测试)：在真实或接近真实的环境里，对整个系统进行端到端测试。

2. 白盒测试与黑盒测试

White-box testing(白盒测试)

• 又称 structural testing(结构测试)，基于代码逻辑和实现来设计测试用例。
• Basic path testing(基本路径测试)：确保每条语句至少被执行一次。
• Control structure testing(控制结构测试)：针对分支、循环等进行测试。
• Cyclomatic complexity(环路复杂度)：
  • 域的个数(包括最外层的区域)
  • E−N+2 (E为边数，N为节点数)
  • 判断节点数 + 2（根据图表中的分类点使用）

Black-box testing(黑盒测试)

• 从用户或外部视角测试软件输入与输出，不考虑内部实现。
• Equivalence partitioning(等价类划分)：把输入域分成有效和无效等价类，每个类中仅需选择代表性数据测试。

•  有效等价类是指输入的某些值集合在功能上是合理的、有效的，并且系统应该能够正常处理这些输入。
• 无效等价类是指输入的某些值集合在功能上是不合理的、无效的，并且系统应能够正确地处理这些输入（通常是拒绝或提示错误）。

• Boundary value analysis(边界值分析)：着重测试上下边界，最易出现错误的临界值地带。

白盒测试与黑盒测试的区别

• White-box：白盒测试是从程序内部结构和逻辑触发，设计测试用例，对程序的路径和过程进行测试。
• Black-box：黑盒测试是从用户角度出发，测试数据的输入和输出关系，不考虑程序内部结构和特性。

3. 面向对象测试

• OO testing method(面向对象测试方法) 大体分为：
  • at class level(类级)：测试单个类的正确性
  • at inter-class level(类间级)：测试多个类协同工作时的交互情况
• 或者OO unit testing 与 OO integration testing 的方式来执行。
• Cluster Testing (簇测试) 是 面向对象集成测试（OO Integration Testing） 的一种具体方法：将相关类按协同关系分组，作为一个测试簇来验证它们之间的交互和集成。

4. Regression testing(回归测试)

• 当软件代码更新后，需进行回归测试(regression testing)，防止新功能或修复导致旧功能出现回归问题。
• 回归的意思就是回到软件领域。

---

六、用户体验设计

Golden rules(金色法则)

• Put the user in control(把控制权交给用户)：提供撤销、恢复、可配置等功能，让用户感觉软件“为他们服务”。
• Reduce the user’s memory load(减轻用户记忆负担)：使用可视化引导、尽量自动化流程、不要让用户频繁输入难记信息。
• Maintain consistency(保持界面一致)：在同一系统或不同模块中，操作流程和视觉效果一致，减少用户学习负担。