设计方法（原型法、敏捷开发）

原型法和敏捷开发

[快速]原型法

就是按照客户写的demo。

分类
1. 抛弃型原型 - demo的需求客户确认后就抛弃。

a）探索性 - 为了确认需求；

b）实验型 - 为了确认规格说明是否可靠。

2. 进化型原型 - 先构造一个功能简单而且质量bugatti的模型作为核心，然后不断扩充修改，最后发展为最终系统。

优点：

1. 由于有用户的直接参与，系统更加贴近实际；

2. 系统开发循序渐进，反复修改，确保较好的用户满意度；

3. 开发周期短，费用相对少；

缺点：

1. 不适合大规模系统的开发；

2. 开发过程管理要求高，整个开发过程要经过“修改—评价—再修改”的多次反复；

3. 用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心；

4. 开发人员易将原型取代系统分析；

5. 缺乏规范化的文档资料

适用范围：

1. 用户需求不清，需求经常变化
2. 规模小，不太复杂
3. 用户界面

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷开发的核心思想

•以人为本
敏捷方法认为，人是软件开发中最重要的因素。敏捷开发的理念是充分的信任开发团队能够很好的完成任务，这是管理的中心主题。

•适应变化
传统的软件开发强调的是，足够清晰的需求，制定详细的文档，按照预定的计划逐一进行开发、测试。这样的方式在制定好计划之后拒绝变化，无法应对客户对需求的实时更改，后续的维护必将会付出巨大的代价。
而敏捷方法则是以最简的方式来迎接变化，客户在整个开发过程中都是参与者，开发团队能够在最短的时间内得到客户的反馈，不断适应需求的变更，从而使得最终的产品能够充分的符合客户的要求。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷开发 - XP极限编程

极限编程（eXtreme Programming）。

“Extreme”（极限）是指，对比传统的项目开发方式，XP强调把它列出的每个方法和思想做到极限、做到最好；其它XP所不提倡的，则一概忽略（如开发前期的整体设计等）。极限编程强调程序设计团队与业务专家之间的紧密协作、面对面的沟通（比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，更注重软件开发中人的作用。

核心价值观
•沟通（Communication）
开发人员和设计人员、设计人员和客户的沟通。
•简单（Simplicity）
开发前期的整体设计、兼容等直接忽略，专注于最小化解决方案。
•反馈（Feedback）
尽快获得用户的反馈。
•勇气（Courage）
拥抱变化。

12个实践原则
• 规划策略
以业务优先级和技术估计为基础，决定下一版本发布的范围。
• 结对编程
结对者是全职合作者，轮流执行键入和监视；这提供了持续的设计和代码评审。
• 测试先行
在编码开始之前，首先将测试写好，而后再进行编码，直至所有的测试都得以通过。
• 重构
改进软件的设计，重构帮助重新组织代码，重新清晰地体现结构和进一步改进设计。
• 简单设计
系统应设计得尽可能简单。
• 代码集体所有权
代码集体所有权强调的是整个团队，而非个人。
• 持续集成
持续集成的思想是任何时候只有一项任务完成，就集成新代码，构造系统并测试。
• 现场客户
客户是Team成员，在开发现场和开发人员一起工作。
• 小型发布
可以保证频繁地反馈和交流，保证客户有足够的依据调控开发过程，降低开发风险。
• 每周40小时工作制
XP要求项目团队人员每周工作时间不能超过40小时，否则反而会影响生产率。
• 编码规范
编码规范代替不必要的文档。类型包括：格式、代码结构、命名约定、错误处理、注释。
• 系统隐喻
系统隐喻是将整个系统联系起来的全局视图，每个迭代的隐喻都会演化扩展。

适用范围
XP适合规模小、进度紧、需求变化大、质量要求严的项目。它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求，XP在平衡短期和长期利益之间做了巧妙的选择。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷开发 - FDD特征驱动开发

8个实践原则
· 领域对象建模
构造类图。系统设计提供了一种整体框架，把对象分解为类，使得系统可以按照特征迭代增量地进行开发。
· 按照特征开发
用户眼中最小的、有用的功能进行开发并跟踪过程。
· 类（代码）拥有权
每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。
· 特征小组
特征分配给一个确定的开发者，一个特征的实现会涉及到多个类及其所有者，因此，特征的所有者（特征组长）需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别：特征小组的组长更像是教练而不是超级程序员。
· 审查
检查软件错误的复审方法，这是FDD确保软件设计和代码质量的一个关键技术。
· 定期构建
定期地取出已完成功能的代码，组成完整的可以运行的系统。可以使客户观察到系统开发的进度和实现的功能是否是需要的。
· 配置管理
最新版本的确认和历史追踪。
· 可视性进度报告
项目成员应该根据完成的工作向各级管理报告工作进度。

XP极限模式和FDD驱动模式的区别

· 隐寓和模型
XP是隐喻，即每个人（设计人员，开发人员、客户）都能讲出系统如何工作的。
FDD是模型，一个全面的领域对象模型，以便特征小组对每一组特征产生更好的设计。
· 开发团队
XP通常不超过10人；FDD的理想团队成员数在16~20人。
· 代码拥有权
XP任何人都拥有代码，任何人都可以在需要时添加或修改代码。
FDD整个开发团队拥有代码，类所有者与特征小组修改。
· 审查
XP利用双人结对编程来不断地在设计和代码层执行走查和非形式化审查。
FDD则提倡采用结构化的形式化审查技术。
· 测试
XP中的正确性是由运行单元和功能测试来定义的。
FDD中单元测试是“按照功能构建”过程的一个部分，由主程序员决定做什么更适合。
· 项目追踪
XP让项目经理决定项目追踪方法，鼓励减少数据搜集的工作量，鼓励使用大型图表。
FDD中的按特征追踪项目的方法，描述了工作量小、准确度量项目进度的手段，提供进度图表。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷开发 - Crystal水晶方法

透明水晶方法，适合于一个小团队来进行敏捷开发，人数在6人以下为宜。

七大体系特征
· 经常交付
项目主办者根据团队的工作进展获得重要反馈；用户有机会发现他们原来的需求是否是他们真正想要的，也有机会将观察结果反馈到开发当中。
· 反思改进
如果我们能够经常在迭代会中及时的反思和改进，技术难题应该是不会发生的，或者说发生了，也能够很快的找到解决方案去应对它。
· 渗透式交流
若其中一名成员提出问题，工作室内的其他成员可以选择关注或不关注的态度，可以加入到这个问题的讨论当中来，也可以继续忙自己的工作。
· 个人安全
个人安全指的是当您指出困扰您的问题时，您不用担心受到报复。个人安全非常重要，有了它，团队可以发现和改正自身的缺点。没有它，团队成员们知而不言，缺点则愈发严重以致于损害整个团队。个人安全是迈向信任的第一步。有了信任，团队协作才能真正的实施，开发效率也就会直线上升的。
· 焦点
所谓“焦点”，就是确定首先要做什么，然后安排时间，以平和的心态开展工作。
· 与专家用户建立方便的联系
与专家用户持续建立方便的联系能够给团队提供：对经常交付进行配置以及测试的地方，关于成品质量的快速反馈，关于设计理念的快速反馈，最新的（用户）需求。
· 配有自动测试（auto-test）、配置管理（git）和经常集成功能的技术环境（git）
自动测试：代码修改后自动测试，并反馈结果。提高效率。
配置管理：提交的代码可选择某个节点发布和还原。
经常集成：开发人员可以一天多次合入本地版本到服务器版本，加快发现错误。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷开发 - RUP统一软件开发过程

RUP（Rational Unified Process），统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。根据Rational的说法，RUP就好像一个在线的指导者，他可以为所有方面和层次的程序开发提供指导方针、模板以及事例支持。
六个特点
· 迭代式开发
迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。
· 管理需求
确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以证明是捕获功能性需求的有效方法。
· 基于组件的体系结构
组件使重用性成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
· 可视化建模
RUP往往和UML联系在一起，对软件系统建立可视化模型，帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化地对软件系统建模，获取有关体系结构和组件的结构和行为信息。
· 验证软件质量
在RUP中软件质量评估是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。
· 控制软件变更
RUP通过软件开发过程中的制造出的产品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。

、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、、

敏捷开发 - SCRUM迭代式增量软件开发过程

Scrum是一种灵活的软件管理过程，它可以帮助驾驭迭代、递增的软件开发过程，主要用于产品开发或工作管理。

Sprint（迭代）
Scrum的项目过程由一系列的Sprint组成
Sprint的长度一般控制在2~4周
通过固定的周期保持良好的节奏
产品的设计、开发、测试都在Sprint期间完成
Sprint结束时交付可以工作的软件
在Sprint过程中不允许发生变更

敏捷方法之极限编程(XP)和 Scrum区别
区别之一：迭代长度的不同
XP的一个Sprint的迭代长度大致为1~2周；
Scrum的迭代长度一般为 2~ 4周。
区别之二: 在迭代中, 是否允许修改需求
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现，则可以考虑用另外的需求将其替换，替换的原则是需求实现的时间量是相等的。
Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。
但Scrum在这点做得很灵活，可以不按照优先级别来做。Scrum这样处理的理由是：(1)如果优先问题的解决者，由于其它事情耽搁，那么整个进度就耽误了。(2)如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。
区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。
XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。

参考链接：

原型法

敏捷开发

设计方法（原型法、敏捷开发）相关推荐

软件测试用例设计方法-因果图法
边界值法是等价类划分法的补充,所以,它们是一对搭档. 那么,判定表法有没有它的搭档呢? 答案是,有的.那就是本篇文章分享的用例设计方法-- 因果图法 . 定义因果图法: 用来处理等价类划分和边界值考 ...
黑盒测试设计方法-正交试验法回顾(上)
黑盒测试设计方法-正交试验法回顾(上) 正交试验设计法是一种用来测试组合的黑盒测试设计方法.借助于数学工具,通过算法从全排列组合中选择出全部两两组合放到正交表中,然后依据得到的正交表就可以得出测试用例 ...
软件测试用例设计方法-场景法
从本篇文章开始,进入到测试用例设计方法的分享,第一个要分享的方法就是,场景法. 相信对测试有一定基础的你会感到奇怪:用例设计方法,不是应该从等价类划分法说起吗?为什么一上来就直接说场景法呢? 对,如果 ...
测试用例设计方法--正交试验法
这是一篇看了度娘文章的得出的,并且结合自己在写的一个测试用例,利用正交测试编写测试用例可以比较快速的覆盖,减少多的测试用例,以下是对文档的整理 1. 正交实验法法介绍正交试验设计(Orthogona ...
测试用例设计方法——因果图法
从用自然语言书写的程序规格说明的描述中找出因(输入条件)和果(输出或程序状态的改变),可以通过因果图转换为判定表. 因果图法即因果分析图,又叫特性要因图.石川图或鱼翅图,它是由日本东京大学教授石川馨提 ...
测试用例设计方法---流程图法
学习目标: 掌握流程图法的适用范围 1.什么是流程图法流程分析法主要是针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计. 2.流程图法设计测试用例步骤第一步:详细了解需求: 第二步:根 ...
06-测试用例设计方法-场景法
目录基本概念设计测试用例步骤测试用例设计案例基本概念场景法:通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法. 基本流:模拟用户正确的操作流程,验证软件的业务流程和主 ...
【测试入门】测试用例经典设计方法 —— 因果图法
01.因果图设计测试用例的步骤 1.分析需求阅读需求文档,如果User Case很复杂,尽量将它分解成若干个简单的部分.这样做的好处是,不必在一次处理过程中考虑所有的原因.没有固定的流程说明究竟分解 ...
测试用例设计方法---因果图法
学习目标掌握因果图法的核心掌握因果图的基本符号了解因果图的画法 1.什么是因果图法因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适用于检查程序输入条件的各种组合情况 ...
测试用例设计方法-因果图法
因果图法定义:因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况. 应用: 等价类划分法和边界值分析方法都是着重考虑输入条件,但没有考虑输 ...

设计方法（原型法、敏捷开发）

设计方法（原型法、敏捷开发）相关推荐

最新文章

热门文章