软件工程笔记

P15 软件危机

• 软件开发进度难以预测：拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。
• 软件开发成本难以控制：投资一再追加，令人难于置信。
• 用户对产品功能难以满足：开发人员和用户之间很难沟通、矛盾很难统一。
• 软件产品质量无法保证：系统中的错误难以消除。
• 软件产品难以维护：软件产品本质上是开发人员的代码化的逻辑思维活动，他人难以替代。
• 软件缺少适当的文档资料：文档资料是软件必不可少的重要组成部分

在软件开发中要遵循如下几点准则：

• 不要依赖于一两个天才人物的灵感和个人能力来研发产品，而是要提高团队整体研发能力，采用适合于本公司或项目组的技术和工具；
• 依赖合理的组织架构、绩效体系和人力资源管理制度、持续优化改进的开发过程和方法来完成软件产品的研发和企业的管理；
• 重视卓越的产品开发管理流程，让企业的商业目标决定采用的开发过程，让开发过程决定软件产品的质量；通过软件开发过程的建立及持续改进，确保让不同的人做好同样的事；让项目及产品的成功得以重复的保证。

“软件工程”是在1968年召开的一个讨论“软件危机”问题的会议上首次提出的。主要是解决如下两个问题：（提升为了一个工程层面的问题）

• 如何开发软件，以满足不断增长，日趋复杂的需求;
• 如何维护数量不断膨胀的软件产品。

瀑布模型：各个环节严格评审验证，顺序完成软件的开发工作。（对立面）（P25流程图）

2020年，教育部颁布的《普通高等学校本科专业目录（2020年版）》，软件工程专业为工学门类专业。

• 软件能力成熟度模型的英文全名是Capability MaturityModel for Software，缩写为SW_CMM，简称CMM；1993年推出第一版。
• CMMI（Capability Maturity Model Integration）是一套包括多个学科、可扩充的模型系列，其前身主要包括4个成熟度模型（称CMMI的源模型），它们分别是：面向软件开发的SW-CMM、面向系统工程的SE-CMM、面向产品集成的IPD-CMM以及涉及外购协作的SS-CMM；2000年推出第一版，现用的是2018年的2.0 版本。

IEEE定义对软件的定义如下： 软件是计算机程序、规程以及可能的相关文档和运行计算机系统需要的数据。 软件包含计算机程序、规程、文档和软件系统运行所必需的数据四个部分。

Fred Brooks教授，北卡罗莱纳大学教授认为： 软件具有复杂性、一致性、可变性和不可见性等固有的内在特性，是造成软件开发困难的根本原因。

VUCA（乌卡）四个字母分别是动荡性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity）。

Scrum

• Scrum的迭代长度一般为 2~ 4周，成员8人左右
• Scrum一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。
• User Story可以不严格按照优先级别来实现，要考虑实现的业务价值
• Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者“自觉保证”

‼️ 4个正式事件，用于检视与适应：

• Sprint计划会议（1-8h）
• 每日Scrum站会（15m）
• Sprint评审会议(1-4h)(邀请客户参与 展示产品增量)
• Sprint回顾会议(1-4h)(总结成败经验 缺陷优势总结 以防下次冲刺中重复遇到问题)

‼️ 角色

• 产品负责人（PO），职责是将开发团队开发的产品价值最大化，负责管理产品待办列表，并 对其清晰地表达、对其进行排序，确保团队对产品待办列表项有足够深的了解。
• 开发团队，负责在每个Sprint结束时交付潜在可发布并且“完成”产品的增量；是自组织的，是 跨职能的，每个成员可以有特长和专注的领域。（不需要领导驱动）
• Scrum Master，对团队而言是一位服务型领导，保证大家能顺利进行冲刺，实现价值的最大化，并与其他Scrum Master一起工作。

需求决定项目成败

代码管理系统

• 中央总控模式，SVN、TFVC、VSS等，在服务器端保留一份拷贝。适用于
  • 大型项目代码库；
  • 权限管控比较严格，可以到文件级别；
  • 比较难于合并的文件类型，比如：二进制文件等。
• 分布式模式，微软Git、GitHub、GitLab等，每个开发人员在本地克隆一个完整的拷贝。适用于：
  • 小型或模块级的项目；
  • 基于开源代码的；
  • 分布式团队；
  • 跨平台工作的团队；
  • 新领域的代码库；

使用Scrum（例如：站会、可视信息管理——即面板、Scrum of Scrum）的敏捷团队的典型监视实践会产生以下信息：

• 任务看板显示正在执行的工作状态，特别是分配给冲刺的任务和待办事项列表项。
  • 在DevOps Server中是通过任务看板和积压工作看板两个样式来显示的。
• 燃尽图显示每个冲刺中剩余的故事点数，并且表明发布的所有工作通常由几个冲刺组成。
• 每天更新冲刺（迭代）燃尽图，指示完成冲刺工作所需的时间。（站会前后完成更新）
• 墙上和/或数字屏幕上的视觉信息，指示团队绩效、文化和任务的当前状态。
  • 使用DevOps Server的仪表板来实现。

CFD显示了平均交付周期和在制品（在开发积压项）是如何随时间变化的。累积流程图还指示进行中的工f作以及完成工作项目的速度与将项目添加到团队项目的速度。

软件测试

按测试特性分类

• 白盒测试：测试人员直接在软件的源程序上进行测试、修改、复测。要求测试工程师对软件的内部结构及逻辑有深入的了解，并掌握写成该源程序的语言。分为：语句测试；分支测试；路径测试；条件测试；目测。
• 灰盒测试：介于白、黑两者之间，是两者的结合。测试工程师对软件 程序结构有一定了解，但了解的程度又不需要达到白盒测试的深度。
• 黑盒测试：测试人员不必深入了解软件的内部设计，只是从一个终端用户的角度，根据产品说明书的指标，从外部测试软件的各项功能及性能。黑盒测试主要是功能测试。

按照开发过程分类

• 单元测试、集成测试、系统测试、用户验收测试及回归测试。
• 回归测试一般是在缺陷修改之后执行，保证原缺陷不在重现，并且缺陷的修改不影响其他功能。

按测试要求分类

• 基本功能测试（Smoke test）：只对软件的关键功能做测试，而不必卷入细致的测试，不必面面俱到。
• 全面测试（Sanity test）：不仅对软件关键功能测试，还要覆盖软件的全部功能，是回归测试的主要组成部分。
• 基准测试（Benchmark test）：对指定的一个或一组程序及数据在不同的计算机上执行测试，以测定其在标准情况下、特定配置下的工作性能，并将其执行速度、完成需时等加以比较。

功能测试

等价区间测试，把输入空间划分几个“等价区间”，在每个区间中只需要测试一个典型值即可；边界值测试；随机测试；状态转换测试；流程测试等。

非功能测试

安装/卸载测试；使用性测试；恢复测试；兼容性测试；安全测试；性能测试；强度/压力测试；容量测试；任意测试等。