软件工程II（COMP319）课程笔记 - lecture_week1_001.pdf¶

1. 课程基础信息¶

1.1 课程标识与授课方¶

课程名称：Software Engineering II（软件工程II）
课程代码：COMP319
学年：2024-2025
授课教师：Sebastian Coope，邮箱为coopes@liverpool.ac.uk
所属机构：© University of Liverpool（利物浦大学）

1.2 课程交付方式¶

课程采用“课堂授课+在线资源+辅导研讨”结合的交付模式，具体包括： - Lectures（授课）：包含校内课堂授课及问答环节（On campus lecture and Q&A）、在线录制课程（Online recorded lectures） - Tutorial/Seminars（辅导研讨）：每周1小时，用于深化课程内容理解与实践指导

1.3 工具安装要求¶

为支持课程实践，建议在个人设备上安装以下工具： - 开发工具：用于Java开发的Eclipse（最新版本即可，EE版本也适用）、带有Aspect J开发工具的Eclipse（下载链接：https://download.eclipse.org/tools/ajdt/410/dev/update/） - 版本控制：需准备代码托管资源，如GitHub账号

1.4 课程材料及用途¶

课程提供的学习资源涵盖理论与实践所需，各材料用途明确，具体如下： - Lecture notes（课堂讲义）：核心知识点梳理，用于课堂内容复习与课后巩固 - Selected papers（精选论文）：培养研究论文分析能力，对应课程“Review and analyses research papers in software engineering”的目标 - Past exam papers and model answers（过往试卷及标准答案）：熟悉考试题型与答题标准，助力80%占比的书面考试备考 - Tutorial sheets（辅导材料）：深化知识点应用，匹配每周1小时辅导研讨环节的实践需求

2. 课程考核与目标¶

2.1 考核结构¶

课程成绩由两部分构成，具体占比及考试范围如下： - 书面考试（Written examination）：占比80%，考试内容基于课堂授课内容（Material delivered in lectures）和辅导研讨覆盖的知识点（Work covered in tutorials） - 面向对象模式设计编程作业（OO pattern design programming assignment）：占比20%，重点考察OO设计与编程实践能力

2.2 课程目标¶

课程核心目标是介绍软件工程进阶主题，培养学生分析软件工程领域研究论文的能力，具体聚焦两个方向： - 掌握通用研究文献的阅读与理解方法（How to read and understand research in general） - 学习如何及时产出更高质量的软件（How to produce better software in a timely manner）

2.3 推荐书籍¶

课程无指定唯一教材（因内容基于研究与进阶主题），但推荐以下参考书籍，供深化学习使用： - 《Java Design Pattern Essentials》，ISBN 0956575803 - 《Learning Agile: Understanding Scrum, XP, Lean, and Kanban》，ISBN 978-1449331924 - 《Actors: A Model of Concurrent Computation in Distributed Systems》，ISBN 978-0262511414

3. 课程核心内容框架¶

3.1 课程主题范围¶

课程涵盖软件工程多个关键进阶领域，核心主题构成如下：软件危机（Software engineering crisis）、软件成本估算与项目管理（Software cost estimation and project management）、面向对象设计模式（OO design patterns）、极限编程与敏捷（XP and Agile）、并发与Actor模型（Concurrency and the Actor model）、依赖图与程序切片（Dependency graphs and program slicing）

3.2 软件工程的复杂性特征¶

软件工程具有高度复杂性，主要体现在三个维度，具体表现为： - 多平台适配：需兼容iPhone、Android、PC、Linux、HTML5等多种终端与系统平台 - 多架构模型：涉及独立应用（Standalone）、客户端-服务器（client-server）、对等网络（peer-to-peer）等多种架构设计 - 高难度问题与大规模体量：需解决AI、神经网络等复杂技术问题，且软件规模庞大（如Linux内核代码量超1000万行）

4. 软件危机与失败分析¶

4.1 软件危机与失败分类¶

软件危机表现为多种形式的项目失败，按严重程度可分为两类，典型案例与特征如下： - 灾难性失败（Catastrophic）：典型案例为阿丽亚娜5号（Ariane 5）火箭事故，因软件变量溢出导致火箭坠毁，直接损失达70亿美元 - 慢性失败（Chronic failures）：常见表现包括项目进度与预算超支（project overruns）、功能缺陷（functionality problems）、性能不佳（poor performance）、代码质量低且结构混乱（Low quality code, poorly structured）

4.2 软件危机期的解决方案¶

1965-1985年为软件危机期，针对该时期项目失败问题，研究领域形成了针对性解决方案：形式化方法通过数学逻辑减少需求与代码的不一致性，高级语言提升开发效率，OO方法改善代码可维护性，分别对应解决“功能缺陷”“进度超支”“代码混乱”等慢性失败问题

4.3 软件项目失败的常见形式¶

从项目全生命周期看，软件项目失败主要包括以下场景，覆盖从交付到维护的多个环节：项目未完成（Project incomplete）、项目超预算（Project over budget）、项目存在大量漏洞（Project is buggy）、项目超进度计划（Project over time schedule）、项目未完全交付需求功能（Project does not fully deliver what is required）、代码库难以维护（Code base is unsupportable）、代码跨平台适配性差（Code doesn’t port well between platforms）

4.4 近年软件失败案例（2023-2024）¶

2023年特斯拉（Tesla）事故：使用Autopilot功能的车辆发生多起高关注度碰撞事件，Autopilot未能识别障碍物，导致17起致命事故（其中11起发生在2022年5月后）及5起严重受伤事件（来源：《华盛顿邮报》）
2023年辉瑞（Pfizer）疫苗分发问题：因软件故障，辉瑞新冠疫苗在多个国家的分发延迟，故障导致疫苗追踪功能异常，引发对疫苗安全性和有效性的担忧
2024年7月微软Azure平台问题：Crowdstrike发布的更新导致Windows电脑出现蓝屏故障，影响范围覆盖全球，受波及行业包括航空公司、医疗中心（如NHS）、电视台、铁路、银行，且该事件并非网络攻击导致

4.5 理论开发场景下的产品质量差异¶

不同开发条件会直接影响最终产品质量，两个典型理论场景对比如下，反映需求与团队能力的关键作用： - 场景1：需求规格不完善（部分功能缺失或错误），但测试完全基于规格开发、开发团队技能高且采用最佳OO技术、测试修复至所有用例通过——最终产品虽能通过测试，但会因需求规格缺陷导致无法满足实际用户需求 - 场景2：需求规格完美（完整且正确），测试完全基于规格开发、开发团队技能低但完成所有功能、测试修复至所有用例通过——最终产品虽功能完整，但会因代码质量差导致可维护性低

4.6 AI生成内容的局限性案例¶

CNET Money使用AI引擎撰写复利相关文章时出现表述误导，文中提到“若将10,000美元存入年利率3%的储蓄账户，第一年年底将获得10,300美元”（实际应为“获得300美元利息，本息合计10,300美元”），反映出AI语言模型在精确表述与逻辑严谨性上的局限性

4.7 语言模型的核心局限¶

以GPT-3为代表的语言模型并不理解其所生成文本的含义，而是通过统计技术，基于训练数据中的模式生成内容，这一特性导致其在需要精确逻辑、计算或专业知识的场景中可能出现错误

5. 软件项目评估与统计分析（基于Standish CHAOS报告）¶

5.1 Standish CHAOS报告核心数据¶

Standish CHAOS报告（美国，全称为Comprehensive Human Appraisal for Originating Software）是软件项目评估的重要参考，其核心数据覆盖投入、成本与完成情况： - 整体投入：软件开发生命周期总支出达2500亿美元 - 项目平均成本：大型企业项目平均成本232.2万美元，中型企业133.1万美元，小型企业43.4万美元 - 项目完成情况：31%的项目在完成前被取消；52.7%的项目成本达原估算的189%；仅16.2%的项目按时按预算完成（大型企业该比例仅为9%）

5.2 项目结果分类标准¶

根据Standish报告，软件项目结果分为三类，各类别定义明确： - 成功项目（Type 1 Successful）：按时、按预算完成，且交付所有需求功能 - 有挑战项目（Type 2 Challenged）：进度或预算超支，且功能交付不完整 - 未完成项目（Type 3 Incomplete）：项目被取消

5.3 项目超支与成功的关键因素¶

项目超支的主要原因（按占比排序）：需求未完全明确（51%）、规划与估算不当（48%）、组织采用新技术（45%）、缺乏项目管理方法（42%）、团队资深人员不足（42%）、软硬件供应商表现差（42%）、其他性能问题（42%）
项目成功的关键因素（按影响程度排序）：用户参与（15.9%）、管理层支持（13.9%）、需求明确表述（13.0%）、合理规划（9.6%）、预期现实（8.2%）、小型项目里程碑（7%）、人员胜任（7.2%）、明确所有权（5.3%）、清晰愿景与目标（2.9%）

5.4 项目取消/失败的具体原因（按占比）¶

软件项目取消或失败的原因及对应占比清晰，需求与管理相关因素占比最高：需求不完整（13.1%）、缺乏用户参与（12.4%）、资源不足（10.6%）、预期不现实（9.9%）、缺乏管理层支持（9.3%）、需求与规格变更（8.7%）、缺乏规划（8.1%）、项目需求消失（7.5%）、缺乏IT管理（6.2%）、技术素养不足（4.3%）

5.5 对Standish CHAOS报告的批判性讨论¶

5.5.1 报告的争议点¶

罗伯特·格拉斯（Robert Glass）提出疑问：Standish报告是否仅聚焦“负面新闻”，未全面反映软件项目实际情况？
核心争议在于“软件危机的范围界定”：现代生活中软件系统的实际应用规模庞大，但报告未明确其评估的“软件项目”是否覆盖所有类型，也未提供日常软件系统性能的对比数据

5.5.2 报告的方法论缺陷¶

失败与超支的定义模糊：未明确“功能缺失比例”（如1/20功能未完成是否算失败）、“时间超支幅度”（如超期1周是否算超支），导致不同场景下的评估标准不统一
项目失败的归因模糊：未清晰区分“项目交付失败”与“估算技术失败”，无法确定问题根源是执行层面还是规划层面
分类与数据问题：项目分类不完整（仅区分“按时按预算完成”与其他情况）、原始数据未公开（无法验证样本代表性）、失败衡量指标单一（仅通过“估算值与实际值的比值（f/a）”衡量）

5.5.3 企业估算策略对报告数据的影响¶

企业在估算时可能采取三种策略，直接影响Standish报告中的“成功率”数据： - 低估算（乐观策略）：低估时间与资源，可能导致项目超支、进度延误（EQF低） - 高估算（保守策略）：高估时间与资源，可能导致资源浪费，但Standish成功率高（EQF低） - 精准估算（平衡策略）：基于充分调研与设计，EQF高，资源利用率与成功率均衡

6. 《The Rise and Fall of the Chaos Report Figures》核心观点与案例¶

6.1 报告的核心结论¶

该文献（作者J. Laurenz Eveleens与Chris Verhoef）对Standish CHAOS报告的“项目成功/失败数据”提出质疑，认为仅通过“是否按时按预算完成”衡量项目成败存在局限性，需结合估算质量因子（EQF） 与估算偏差（Bias） 综合评估，否则数据无实际意义

6.2 三个组织的项目评估案例对比¶

6.2.1 组织1（行业领先水平）¶

项目规模：2年内开展140个项目
核心数据：估算值与实际值的中位数比值（f/a）为1.0（估算精准度高），EQF约为8.5（接近“非常好”标准）
管理措施：聘请独立顾问支持预测流程，确保估算客观性
Standish标准下的成功率：59%（低于报告平均水平，但结合EQF可知其估算体系完善，成功率低可能因项目复杂度高）

6.2.2 组织X（保守型估算策略）¶

估算特征：时间维度f/a普遍>1（正偏差），即估算时间长于实际所需
项目结果：多数项目存在预算盈余（资源未充分利用）
管理策略：采用Standish标准衡量项目成功，鼓励项目经理“高估”时间与资源，降低超支风险
核心数据：平均EQF仅为0.43（估算准确性极低），但Standish标准下的成功率达67%（数据看似优秀，实则因估算保守导致）

6.2.3 Landmark Graphics（乐观型估算策略）¶

估算特征：估算值普遍低于实际值（低估项目难度）
项目结果：Standish标准下的成功率仅为6.8%（看似失败率极高）
核心数据：EQF为2.3（估算准确性较低，但优于组织X）
结论：该组织的“低成功率”并非完全因项目执行问题，而是源于乐观的估算策略，需结合EQF与偏差综合判断

6.3 关键启示¶

仅依赖Standish CHAOS报告的“成功率”数据无法真实反映组织的项目管理能力，需同步分析EQF（估算准确性）与Bias（估算方向）；不同组织的估算策略（保守/乐观）会显著影响“成功率”数据，对比时需先统一评估基准

7. 项目估算质量评估（EQF与偏差）¶

7.1 估算质量因子（EQF）¶

7.1.1 定义与计算公式¶

EQF（Estimation Quality Factor，估算质量因子）用于量化项目估算的准确性，核心逻辑是“通过偏差率的平均值倒数衡量精准度”，且偏差计算需取估算值与实际值的绝对值（|Estimate - Actual|），避免正负偏差抵消导致结果失真。计算公式为： 1. 计算每个估算值与实际值的绝对偏差：Deviation = |Estimate - Actual| 2. 计算每个估算的偏差率：Deviation Rate = Deviation / Actual 3. 计算平均偏差率：Average Deviation Rate = (Sum of Deviation Rates) / Number of Estimates 4. 计算EQF：EQF = 1 / Average Deviation Rate

7.1.2 示例计算¶

某项目实际完成时间为14周，5次估算值分别为20、10、15、12、12周，计算过程如下： 1. 绝对偏差分别为：6（|20-14|）、4（|10-14|）、1（|15-14|）、2（|12-14|）、2（|12-14|） 2. 偏差率分别为：6/14≈0.429、4/14≈0.286、1/14≈0.071、2/14≈0.143、2/14≈0.143 3. 平均偏差率：(0.429+0.286+0.071+0.143+0.143)/5≈0.214 4. EQF：1 / 0.214≈4.67

7.1.3 评估标准与局限性¶

评估标准：EQF得分越高，估算准确性越好；EQF>10被视为“非常好”（平均偏差率<10%）
补充内容：EQF（Estimation Quality Factor）评估标准中，“EQF> 10” 的完整表述为 “EQF > 10 is considered very good（v.good）”，其对应的数学逻辑为 “EQF > 10 → 平均偏差率 < 10%”，推导过程为 “由 EQF = 1 / 平均偏差率可知，当 EQF > 10 时，1 / 平均偏差率 > 10 → 平均偏差率 < 0.1（即 10%）”
局限性：仅衡量“偏差大小”，无法反映“偏差方向”（即估算偏乐观还是偏悲观）

7.2 估算偏差（Bias）¶

7.2.1 定义与计算公式¶

偏差（Bias）用于衡量估算的“方向性”，即估算值整体高于还是低于实际值。计算公式为： 1. 计算估算平均值：Mean(Estimator) = (Sum of Estimates) / Number of Estimates 2. 计算偏差：Bias = Mean(Estimator) - Actual Value 3. 计算偏差百分比（标准化）：Bias Percentage = (Mean(Estimator) - Actual Value) / Actual Value × 100%

7.2.2 示例计算¶

沿用上述14周项目案例，5次估算值平均为(20+10+15+12+12)/5=13.8周： 1. 偏差：13.8 - 14 = -0.2周 2. 偏差百分比：(-0.2 / 14)×100%≈-1.43% 3. 结果解读：负偏差表示估算整体偏乐观（估算值略低于实际值），但偏差幅度小，估算方向较客观

7.2.3 偏差的含义与影响因素¶

大幅负偏差：可能因项目实际复杂度高于预期、项目中途变更需求、需求规格不完善导致
大幅正偏差：可能因基于过往低估经验而高估项目、项目经理因管理层压力过度规避风险导致
影响偏差的核心因素：估算时间（早期估算难度高，易出现偏差）、管理层压力（可能迫使团队低估）、开发人员经验（经验不足者易极端乐观/悲观）、设计详细程度（详细设计可降低偏差）、需求规格质量（规格越清晰，偏差越小）

7.3 估算质量的动态变化（Boem’s Cone of Uncertainty）¶

Boem的“不确定性圆锥模型”显示，项目估算的准确性随项目推进逐步提升，各阶段偏差范围明确： - 项目定义初期（Product Definition）：估算偏差范围最大（0.6x-1.6x，x为实际值） - 需求规格确定后（Product Requirements Specification）：偏差范围缩小（0.8x-1.25x） - 详细设计完成后（Detailed Design）：偏差范围进一步缩小（0.85x-1.15x） - 软件验收阶段（Accepted Software）：偏差范围最小（0.9x-1.1x），此时软件功能与质量已明确，估算准确性最高 - 核心启示：尽早明确需求与设计，可降低估算不确定性

7.4 项目成功的多元定义¶

项目成功并非仅由“按时按预算”决定，还需结合以下维度综合判断： - 上下文因素：企业规模（大型企业项目复杂度高，成功标准更宽松）、项目成本类型（固定成本/可变成本） - 组织文化：销售驱动型企业可能更关注“按时交付”（即使超支），开发驱动型企业更关注“质量与可维护性” - 估算与开发能力：估算技能（EQF高低）、开发团队技能（影响实际执行效率）

8. 软件工程研究与实验设计¶

8.1 研究数据的批判性分析原则¶

在分析软件工程研究数据（如项目成功率、方法有效性）时，需警惕“标题数据”，核心验证维度包括： - 结果成因（What is the cause of the result?）：区分“因果关系”与“相关关系”，避免误将巧合归因于特定方法 - 样本量（What is the sample size?）：样本量过小可能导致结果随机性强，不具备代表性 - 结果随机性（Could the result occur randomly?）：需通过统计检验判断结果是否由偶然因素导致 - 实验对结果的影响（Does doing the experiment effect the outcome?）：避免“霍桑效应”（参与者因知道被观察而改变行为）

8.2 实验设计示例：结对编程有效性测试¶

8.2.1 实验目标¶

验证“结对编程（pair programming）”是否比“单人编程”更能提升代码质量（如降低漏洞数量）、提高开发效率（如缩短完成时间）

8.2.2 核心实验要素¶

自变量：编程模式（结对编程/单人编程）
因变量：代码漏洞密度（漏洞数/千行代码）、开发完成时间（小时）、代码可维护性评分（基于行业标准）
控制变量：项目难度、开发人员技能水平、开发工具、需求规格（确保两组实验条件一致）
零假设（Null Hypothesis）：结对编程与单人编程在代码质量、开发效率、可维护性上无显著差异（实验需通过数据验证是否拒绝该假设）

8.3 统计分析中的典型悖论案例（警惕数据误导）¶

8.3.1 低出生体重悖论（Low Birth Weight Paradox）¶

核心定义：低出生体重指婴儿出生体重低于特定标准；婴儿死亡率指婴儿出生后一年内的死亡比例
悖论表现：孕期吸烟母亲所生的低出生体重婴儿，其死亡率低于非吸烟母亲所生的低出生体重婴儿
警示意义：单一维度数据（如低出生体重婴儿死亡率）可能掩盖其他关键变量（如吸烟母亲的其他健康因素、医疗干预措施），需多维度分析至

8.3.2 哈佛大学性别偏差数据悖论¶

整体数据误导：哈佛大学整体录取数据显示，男性申请录取率（44%，8442人申请）高于女性（35%，4321人申请），看似存在性别偏差
细分数据真相：按院系拆分后，多数院系女性录取率高于或接近男性（如院系A：男性录取率62%，女性82%；院系B：男性63%，女性68%），整体偏差源于“女性更倾向申请竞争激烈、录取率低的院系”
软件研究关联：对比软件团队/公司绩效时，不可仅看“项目成功率”等原始数据，需明确“绩效衡量标准”（如漏洞率、可维护性）与“代码规模计算方式”（如功能点、千行代码），避免因“维度缺失”导致误判。例如团队A“项目成功率80%”但代码漏洞率高，团队B“成功率70%”但质量更优，需综合多维度评估

8.4 软件工程研究的核心问题¶

对比软件团队/公司绩效时，需明确三个关键问题，避免数据解读偏差： - 原始数据是否足够？（如仅看项目成功率，还是包含EQF、偏差等细节） - 绩效衡量标准是否统一？（如代码规模按“行数”还是“功能点”计算，质量按“漏洞数”还是“用户满意度”衡量） - 样本是否具有可比性？（如团队技能水平、项目复杂度是否一致）

9. 软件工程定义与发展历史¶

9.1 软件工程的权威定义¶

9.1.1 通用工程定义延伸¶

美国工程师专业发展委员会（American Engineers' Council for Professional Development）将工程定义为“将科学原理创造性地应用于设计或开发结构、机器、设备或制造流程的过程”，延伸至软件工程则为“将科学原理创造性地应用于设计或开发软件系统的过程”

9.1.2 北约科学委员会定义¶

北约科学委员会（NATO Science Committee）的Fritz Bauer定义：“建立并应用合理的工程原则，以经济地获得在真实机器上可靠且高效运行的软件”，该定义强调“工程原则”“经济性”“可靠性”三大核心要素

9.2 软件工程发展三阶段¶

软件工程发展分为三个关键阶段，各阶段特征与研究重点明确： - 1945-1965年：开创期（Pioneer stage）：软件工程概念初步形成，聚焦基础软件技术（如汇编语言、早期高级语言）的探索与应用 - 1965-1985年：软件危机期（Software crisis）：因软件规模扩大、复杂度提升，出现大量项目失败，研究重点转向“解决危机”，包括形式化方法（Formal methods）、高级语言（high level languages）、面向对象方法（OO methods） - 1985年至今：无“银弹”期（No software silver bullet）：认识到软件工程无单一“万能解决方案”，研究聚焦方法论与调试技术（Methodology and debugging），如敏捷开发、测试驱动开发等

9.3 通用工程原则与软件工程活动对应¶

9.3.1 通用工程五大原则¶

通用工程的核心流程可概括为五个环节，每个环节均有明确目标： 1. 规格说明（Specification）：明确“产品需实现什么功能”（What should it do?）及“如何规范描述需求”（How to specify?） 2. 设计（Design）：确定“产品如何实现功能”（How should it do it?），输出技术方案 3. 制造/实现（Manufacture/Implementation）：将设计方案转化为实际产品 4. 质量控制（Quality control）：通过测试、分析确保产品符合规格要求 5. 修改/优化（Modify/enhance）：修复产品缺陷，提升性能或功能

9.3.2 软件工程活动对应¶

软件工程活动完全遵循通用工程原则，具体对应如下： 1. 需求分析（Requirements analysis）：对应“规格说明”，明确软件功能与约束 2. 软件设计与实现：对应“设计+制造”，包含设计模式应用、Actor模型构建、面向方面编程（AOP,，Aspect-Oriented Programming）等技术 3. 软件测试与分析：对应“质量控制”，包括程序切片（Program slicing）等分析方法 4. 软件管理：贯穿全流程，涵盖进度规划（Scheduling）、质量保证（Quality assurance）、工作流管理（Work flow） 5. 软件维护与优化：对应“修改/优化”，修复漏洞、迭代功能

10. 软件工程未来趋势与课程核心总结¶

10.1 未来发展核心趋势¶

当前软件工程发展的核心趋势聚焦“敏捷（Agile）”体系，具体包括六大方向，旨在提升开发效率与质量： 1. 测试驱动开发（Test driven development）：以测试用例指导开发，提前发现缺陷 2. 软件工具高效应用：借助自动化工具提升开发、测试、部署效率 3. 编程语言优化：使用更安全、高效的编程语言（如Rust、Go）降低开发难度 4. 增量开发（Incremental development）：分阶段交付功能，快速响应用户反馈 5. SCRUM框架落地：通过迭代、冲刺（Sprint）管理提升团队协作效率 6. 估算与项目管理能力提升：优化EQF计算方法，降低项目超支风险

10.2 课程核心总结¶

实验设计复杂性：软件工程实验受多种变量影响（如团队技能、项目复杂度），设计时需严格控制变量，避免结果失真
方法有效性的相对性：软件工程领域无“绝对最优方法”，某方法的有效性需结合具体场景（如项目规模、团队结构）判断，证据常存在差异
研究数据的批判性思维：阅读研究论文时，不可直接采信“标题结果”，需验证数据来源、样本代表性、统计方法的科学性，警惕数据误导（如辛普森悖论）