软件方法论--课程笔记(整理中)
目录
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)等中,也可以使用燃尽图来追踪进度。
。。。。。