软件方法论--课程笔记（整理中）
目录
C1：概览Introduction
（1）软件的4个特性
（2）软件产品的2种类型
（3）软件过程的4个活动过程
（4）软件的6个质量特性
C2：软件过程Software Processes
（1）软件过程的模型
（2）改进
C3：敏捷开发Agile Software Development
（1）敏捷开发vs传统开发
（2）敏捷宣言的4句话
（3）敏捷方法适用的情况
（4）极限编程（eXtreme Processing）
（5）Planning Poker
（6）重构Refactoring
（7）结对编程
（8）Scrum
（9）燃尽图（Burndown Chart）
C1：概览Introduction
（1）软件的4个特性
一致性（Conformity）：软件必须符合严格的规格和要求，包括与其他组件的接口和环境的连接，避免因为不一致导致无法复用或开发问题。
不可见性（Invisibility）：软件没有物理属性，项目进展无法直观查看，开发者只能通过文档和代码进行间接管理，增加了项目管理的难度。
复杂性（Complexity）：软件系统由大量相互作用的组件构成，包括并发调用、状态转换、数据耦合等，复杂性增加了缺陷隐藏的可能，且难以发现。
演化性（Changeability）：软件是最容易修改的系统部分，但也因此面临更高的更改难度，尤其当复杂性和一致性要求较高时，修改变得极其困难。
（2）软件产品的2种类型
- 通用产品（Generic Products）：如PC软件（如Photoshop），这些产品面向广泛市场，规范由开发者决定，软件更改由开发者控制。
- 定制产品（Customized Products）：如航空交通控制软件，专门为某个客户定制，客户拥有软件的需求规范，软件更改由客户决定。
（3）软件过程的4个活动过程
- 软件规格（Software Specification）：定义软件功能和操作约束。
- 软件开发（Software Development）：软件的设计与编程实现。
- 软件验证（Software Validation）：确保软件符合客户需求。
- 软件演化（Software Evolution）：软件根据市场需求和客户要求进行修改和更新。
其中，软件验证过程包含Verification和Validation，目的是确保系统符合规范和客户需求。包含3种测试类型：
组件测试Component Testing: 测试单个组件。
系统测试System Testing: 测试整个系统，重点关注优先程度高的功能。
客户测试Customer Testing: 用实际客户的数据来测试系统。
（4）软件的6个质量特性
根据ISO 9126，软件的质量特性包括：
- 功能性（Functionality）：软件是否具备所需功能。
- 可靠性（Reliability）：软件的可靠性和稳定性。
- 可用性（Usability）：软件是否易于使用。
- 效率（Efficiency）：软件的性能和资源使用。
- 可维护性（Maintainability）：软件是否容易修改和更新。
- 可移植性（Portability）：软件是否容易转移到不同的环境中。
C2：软件过程Software Processes
（1）软件过程的模型
模型核心主要分为“计划驱动”和“敏捷”两类。计划驱动，即所有活动在开始时就已规划好。敏捷，即增量开发和灵活性，能够轻松适应变更。
①瀑布模型：从需求收集到维护的顺序阶段。适用于需求稳定且易于理解的系统，但在开发开始后处理变更方面存在困难。
②原型模型：通过创建原型来帮助需求收集、设计验证和探索系统特性。适用于早期用户反馈的收集，但可能无法完全代表最终系统。
③增量模型：开发分阶段进行，每个版本提供部分功能。该模型更容易适应变更，并允许更早的用户反馈，但如果管理不当，可能导致系统结构退化。
（2）改进
目标：提升质量、降低成本并提高软件过程效率。
过程：
- 测量：跟踪现有过程的度量指标。
- 分析：识别弱点和瓶颈。
- 改变：实施改进并评估其效果
改进方法：
过程成熟度：专注于完善项目管理和软件工程实践。
敏捷方法：专注于迭代开发和灵活应对客户需求。
能力成熟度模型（CMM）：评估和改进软件过程成熟度的框架。
C3：敏捷开发Agile Software Development
（1）敏捷开发vs传统开发
开发目标、需求变化与响应速度、交付与反馈、开发文档与沟通、迭代与增量方式5个角度。
①开发目标：
- 传统开发（瀑布模型）：需求定义、系统设计、实施与单元测试等各阶段按顺序进行，注重文档驱动和计划驱动，开发过程中较少的灵活性，项目过程控制较为严格。
- 敏捷开发：强调迭代式开发，要求软件在多个版本或增量中逐步演进，频繁交付并根据反馈进行调整。这与传统开发模式不同，敏捷开发侧重于快速交付和适应性，而传统方法则注重稳定的需求定义和严格的过程控制。
②需求变化与响应速度
- 敏捷开发的目标：敏捷开发应对快速变化的业务需求。在当今快速变化的市场环境中，软件需求不断变化，敏捷开发通过迭代式更新和反馈机制，使软件能够更快速地反映这些变化。
- 传统方法的问题：传统的计划驱动开发（如瀑布模型）无法很好应对快速变化的需求，因为它依赖于一次性的需求定义和设计，一旦需求变化，需要重做大量的工作。
③交付与反馈的频繁性
- 敏捷方法的变更：敏捷开发强调频繁交付小的可用增量，每个增量版本都经过利益相关者的评估和反馈。这种方式相比传统的“一次性交付”模式，在开发过程中能够及时发现问题并进行调整，避免了大规模错误的积累。
- 传统方法的对比：传统开发则更倾向于在开发周期的后期进行系统测试和交付，需求变更和反馈的响应较慢，开发过程中发现问题的代价较高。
④开发文档与沟通
- 敏捷开发的变更：敏捷方法对文档要求较少，强调工作代码的交付。这种减少文档的做法可以加速开发进程，让团队成员专注于实际代码的实现与功能的交付。
- 传统方法的文档驱动：与敏捷方法相比，传统方法通常需要大量的文档编写，以确保项目按计划执行。文档的繁复增加了开发的时间和成本，也可能导致沟通不畅，影响开发效率。
⑤迭代与增量的方式
- 敏捷开发：通过不断的迭代和增量交付，开发过程是动态的，资源配置和工作内容是随时根据实际需求进行调整的。这种方式更容易适应需求变化，特别是对于不确定性较高的项目。
- 计划驱动开发：则更多依赖于提前的计划和估算，项目的进度和资源配置较为固定，一旦发生需求变化，可能导致项目延期或超出预算。
选择敏捷方法后，开发过程中对需求的快速响应、交付周期的短频、团队的高协作性以及文档和计划的简化是主要的变更。这些变化能够显著提高项目的灵活性和适应性，但也可能带来一些实际的挑战，比如需求频繁变动时的成本控制、团队的协调和沟通等问题。
（2）敏捷宣言的4句话
- 个人和互动高于过程和工具
- 工作软件高于全面的文档
- 客户协作高于合同谈判
- 响应变化高于遵循计划
（3）敏捷方法适用的情况
- 敏捷方法适用于小型或中型软件产品的开发，尤其是在客户能够积极参与开发过程中且外部规则较少的情况下。
（4）极限编程（eXtreme Processing）
- 极限编程是一种强调迭代开发的敏捷方法，提出了诸如“测试优先开发”、“重构”等开发实践，强调通过频繁的交付和用户的直接反馈来快速适应需求变化。
（5）Planning Poker
- Planning Poker是一种基于共识的估算和计划技术。它帮助团队成员对任务进行时间或工作量估算，通过一轮轮的讨论和选择卡片，最终达成一致。
（6）重构Refactoring
①重构在做什么：重构是对现有代码进行优化和修改的过程，目的是提高代码的结构和可读性，而不改变其外部行为。
②重构的目的是什么：重构是一种持续改进代码的实践，目的是使代码保持简洁、可维护，同时避免过度设计，减少重复代码，并提高系统的灵活性和扩展性。
③重构怎么做：通过逐步修改和优化代码，如提取函数、简化条件语句、删除重复代码、调整类和方法的职责等，确保每次修改后系统仍然能够正常运行，并且每次修改的范围都尽可能小，以降低引入错误的风险。
（7）结对编程
①结对编程是什么：是程序员成对地在同一台计算机上共同开发代码。
②结对编程的优点：
共同拥有：团队成员之间共享知识。
非正式审查：代码由多人进行审查。
鼓励重构：提升代码质量。
效率：研究表明，结对编程可能比独立工作更高效。
（8）Scrum
①scrum是什么：是一种轻量级框架，用于解决复杂问题并交付高价值产品。
②scrum的特点：简单易懂，但难以掌握；不是一个过程，而是应用各种技术的框架。
③scrum角色：
- 产品负责人（Product Owner）：定义和优先排序产品特性和需求，确保与业务需求对齐。
- 开发团队（Development Team）：一个自组织的团队，负责软件开发。
- Scrum Master：促进Scrum过程，确保遵守流程并清除障碍。
④scrum组件：
• 产品待办事项（Product Backlog）：产品所需的特性和任务清单。
• Sprint待办事项（Sprint Backlog）：当前Sprint计划的产品待办事项子集。
• 潜在可交付的产品增量（Potentially Shippable Product Increment）：一个Sprint的最终、完成的输出。
⑤scrum事件（会议）：
- Sprint规划（Sprint Planning）：定义Sprint中要做的工作以及如何工作。
- 每日Scrum（Daily Scrum）：一个15分钟的会议，团队讨论已完成的工作、第二天的计划以及识别任何障碍。
- Sprint评审（Sprint Review）：Sprint结束时举行，检查完成的工作并在必要时调整产品待办事项。
- Sprint回顾（Sprint Retrospective）：在Sprint评审后的反思会议，团队识别下一Sprint的改进措施。
⑤scrum和XP（极限编程）对比：
• Scrum：专注于自组织，并可以与XP或看板（Kanban）等额外框架进行定制。
• XP：强调工程实践，并为任务制定严格的优先顺序。
（9）燃尽图（Burndown Chart）
①燃尽图是什么：是可视化剩余工作量与时间的关系，帮助团队追踪进度、预测项目是否按时完成。是一种广泛使用的项目管理工具，尤其在敏捷开发和敏捷框架中非常常见，虽然在Scrum中使用得最为普遍。虽然它在Scrum中被广泛使用，作为跟踪Sprint进度的工具，但在其他敏捷方法，如极限编程（XP）、看板（Kanban）等中，也可以使用燃尽图来追踪进度。
。。。。。