主要点:
- 软件模型:特点、场合、相互之间过程
- 增量
- 螺旋
- 统一过程 RUP,组成内容,与其他相比的区别(与螺旋、瀑布模型相比较)
- 敏捷过程:
- 线性的顺序过程。执行完上一个阶段,才能开启下一个阶段。
- 文档驱动。每个阶段都以上一阶段的文档为基础。
- 严格的阶段评审制度。
原型/演化模型
内容:见图
特征:
- 交互性好。每一次都快速开发出原型与客户沟通。
- 应对可变需求。通过循环迭代开发,可以不断完善需求并探索可行性。
增量模型
特征:
- 融合瀑布模型和原型模型,交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”。
- 每一个增量均发布一个可操作产品。
- 有一定的抗风险能力。
- 人手分配灵活。
缺点:
-
螺旋模型
解读:螺旋模型一圈一个周期,通过迭代直至客户满意。
一个周期: 制定计划:确定软件目标、实施方案和计划,明确各种限制条件。
- 风险分析:评价方案,识别、消除风险。
- 实施工程:开发、验证产品。
- 客户评估:与客户联系展示产品,收集建议,准备下一周期的迭代。
特征:
- 风险驱动,不断通过风险分析来完善软件模型。
- 不断循环迭代演进的过程。
- 极强的抗风险能力。
喷泉模型
内容:面向对象的分析设计方法。
特征:
- 自底向上,迭代演化。
- 无缝衔接、复用、并行、集成。
RAD模型
特征:
- 强调极短的开发周期,瀑布模型的高速变体。
- 系统拆分为各个模块,每个模块由不同团队负责,最后统一集成部署。
优点:
- 对用户需求的响应高。
- 人员分配灵活。
缺点:
- 新加入的组件可能会破坏之前的组件。
- 软件的体系结构必须是开放的。
- 仍然无法应对需求不稳定、常变更的情况(瀑布模型)。
- 要有足够的技术能力协调各个增量。
统一过程RUP
含义:Rational Unified Process,由 Rational 公司提出的统一过程模型。
组成部分
横轴分 4 个阶段,纵轴分 9 个流程。
迭代且增量:
- 从纵轴画一条线下来,对应一次迭代。与横轴的交点表示本次迭代属于哪个阶段,与纵轴里图像的交点表示本次迭代中需要进行的流程,图像的高低比例表示流程的重要程度。
- 要求每次迭代都要处理一组用例(用例驱动),达成工件的一个增量(迭代目标)。
- 一个阶段可以有多次迭代,是否有下一次迭代取决于上一次迭代的效果。
纵轴9个工作流程
流程 | 内容 | 涉及角色 | 产生工件 |
---|---|---|---|
业务建模 | 在原本最先的需求分析之前,RUP增加了一步业务建模的流程,这个其实是对之后需求的一种领域选择和超前规划,往往需要跨专业领域的知识。例如支付宝的业务建模就是第三方支付。 | ||
需求 | 需求工程 | 系统分析员、用户界面设计员、需求复审员 | 用例模型、用户界面原型 |
分析设计 | 需求 -> 系统设计 | 架构师、架构复审员、数据库设计员、设计复审员 | 设计模型(设计类+描述) |
实现 | 以构件的形式实现类和对象并测试。将构建集成到可执行的系统中。 | 代码开发员、集成员、代码复审员 | 实施模型(模型元素、子系统) |
测试 | 验证产品功能、性能 | 测试设计员、测试员 | 测试模型(测试用例、过程、构建)、测试结果 |
** | 发布产品(自定义安装、市售、互联网使用) | 部署经理、技术文档编写员、课程开发员 | 产品第一个版本、文档培训资料 |
配置和变更管理 | 管理系统的演化 | 配置经理、集成员、变更控制经理 | 配置管理计划、变更请求 |
项目管理 | 平衡竞争目标、管理风险等 | 项目经理、项目复审员 | 迭代计划、风险管理计划、风险评估文档 |
环境 | 提供开发环境 | 工具专家 | 工具指南、工具 |
关键点:业务建模
本质是需求的构建方法。
原理:描述如何拟定客户组织的前景,并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色和职责。
横轴4个阶段
阶段 | 目标 | 结束里程碑 | 评审标准 |
---|---|---|---|
先启 | 建立业务用例,确定项目的边界。 | 生命周期目标里程碑 | 成本估算达成一致、开发流程达成一致。 |
精化 | 建立稳定的架构, 编制项目计划, 淘汰项目中最高风险的元素。 |
生命周期架构里程碑 | 需求和前景稳定、架构稳定、处理完预期风险。 |
构建 | 所有构件和应用程序功能被开发并集成为产品, 所有功能被详尽测试。 |
最初操作性能里程碑 | 实际消耗可接受、产品发布版本稳定成熟。 |
产品化 | 将软件产品交付个用户群体。 | 产品发布里程碑 | 用户是否满意。 |
VS 螺旋模型
优点:
用于指导需求不明确、不稳定的项目开发时更具有可操作性。
相同点:
- 都是迭代且增量。每个阶段结束都交付一次产品,RUP 在每个阶段的结束交付,螺旋模型在每一次循环(一圈)交付。
- 每次迭代都进行了风险分析。
不同点:
- RUP 在每次迭代过程中对 9 个活动流程的侧重点不同,而螺旋模型每次迭代并未说明活动流程的侧重点。
- RUP 明确给出了每个阶段要交付的增量的要求,即四个阶段的里程碑,而螺旋模型没有给出每次迭代后交付的增量的要求。
- RUP 对每次迭代的 9 个活动流程支持并行化,而螺旋模型并不支持。
总结:RUP 的二维生命周期结构对“迭代”意义的体现比螺旋模型更深刻、具体、详尽、全面,更具可操作性。
VS 增量模型
优点:
- 更能适应需求的变化。
- 极大降低了需求不明确带来的风险。
- 将成本风险进一步降低为获得一次增量所需的费用。
敏捷过程
Agile Process,AP
流派:SCRUM,极限编程XP等
敏捷软件开发宣言:4 条价值观 + 12 条原则。
4条价值观
更认同左边,但不否认右边的价值。
敏捷 | VS | 普通 |
---|---|---|
个体和交互 | 胜过 | 过程和工具 |
可以工作的软件 | 胜过 | 面面俱到的文档 |
客户合作 | 胜过 | 合同谈判 |
响应变化 | 胜过 | 遵循计划 |
- Individual and interaction over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contact negotiation
- Responding to change over following a plan
极限编程XP
eXtreme Programming
14 项实践技术
最佳实践:
- 结对编程:两个开发人员在同一台电脑上共同编写代码,进行同级评审。
- 持续集成:一天多次集成,避免了一次系统集成,保持团队的开发效率。
- 简单设计:考虑当下的最优状态,不过多考虑未来。
-
SCRUM
SCRUM 是一种包含预定义角色和一系列实践过程的框架,也是一种迭代且增量的过程。
角色
猪:全身心投入项目开发。
- Product Owner:更新 project backlog 并按优先级排序。
- Scrum Master:领导团队,保证 SCRUM 过程。
- Scrum Team:开发者和设计者。
- 鸡:利益先关者。参与冲刺评审、计划、提供反馈。
- 用户
- 客户
- 老板
- 提供商
SCRUM过程
- 确定总体的 Product Backlog,按照优先级排序。
- 建立体系结构并分解 Product Backlog 为多个 Sprint backlog 并分给指定小组。
- 划分小组分配 Sprint backlog
- 多次 Sprint 完成每一个 Sprint Backlog 的任务。
- 将工件组装、测试,形成最终的可交付的产品。
注:Sprint 是冲刺的意思,一般用 2-4 周的时间完成,包括开发、打包,评审、调整。
- Sprint 是经验性过程。
-
5个会议
1、评估会议
内容:Project Owner 介绍每一个 story 的详细用例,评估每一个用例的工作量,将评估结果加入 Product Backlog
-
2、Sprint计划会议
内容:明确 Sprint 时间表和任务,选择迭代周期。
-
3、Daily Meeting每日会议
内容:更新 Sprint Backlog 上的任务状态。
交付物:最新的 Sprint Backlog,最新的工作进展。
4、评审会议
内容:演示并评审本次 Sprint 的结果,根据评审结果更新 Product Backlog
-
5、回顾会议
内容:回过 Sprint 过程,吸收过程经验。
- 交付物:本次 Sprint 过程中的经验和改进之处。
3个过程特点
- 确定性过程:可明确描述的、可预测的过程,因而可重复(Repeatable)执行并能产生预期的结果,并能通过科学理论对其最优化。
- 经验性过程:SCRUM 将开发中的分析、设计、实施视为一个 Sprint 黑箱,认为应加强黑箱内部的混沌性,使项目组工作在混沌的边沿,充分发挥人的创造力。
VS 螺旋模型
不同点:
- SCRUM 有增量而螺旋模型没有。SCRUM 采用 Sprint 黑箱——经验性过程发挥人的创造力。
- SCRUM 使用 Daily Meeting, Burn down, Review Meeting 进行迭代评估,而螺旋模型只产生增量。
- SCRUM 通过 Sprint 控制迭代进度和时间,并且 Sprint 过程可以并行,而螺旋模型没有进度控制,且串行。