软件工程作业

Posted 2020-10-07 周_奎良

1.什么是RUP ?

RUP（Rational Unified Process），统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。

瑞理统一过程（RUP）是Rational软件公司（Rational公司被IBM并购）创造的软件工程方法^[1]  。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。

最佳实践 六大经验

1.迭代开发： RUP的开发过程建立在一系列迭代之上，每次迭代都有一个固定的时间限制（例如四个星期），称为"时间盒"，每次迭代结束的时候都发布一个稳定的小版本，该版本是最终系统的子集。"时间盒"是迭代开发中的关键概念：它意味着迭代周期的期限是固定的，如果目标没有完成，则放弃本次迭代的需求，而不是延长迭代的时间。

2． 管理需求

3． 使用基于组件的构架

4． 可视建模

5． 持续的质量验证

6． 控制变更

2.什么xp?

极限编程（ExtremeProgramming，简称XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期与WardCunningham共事时，就一直共同探索着新的软件开发方法，希望能使软件开发更加简单而有效。Kent仔细地观察和分析了各种简化软件开发的前提条件、可能性以及面临的困难。1996年三月，Kent终于在为DaimlerChrysler所做的一个项目中引入了新的软件开发观念——XP。适用于小团队开发。

极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。

极限编程的有效实践

1、完整团队

XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

2、计划游戏

计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

3、客户测试

作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。

4、简单设计

团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

5、结对编程

所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

6、测试驱动开发

编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。

7、改进设计

随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。

8、持续集成

团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。

9、集体代码所有权

任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。

10、编码标准

系统中所有的代码看起来就好像是被单独一人编写的。

11、隐喻

将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。

12、可持续的速度

团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。

3.什么是敏捷过程？

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

开发宣言

个体和交互 胜过 过程和工具

可以工作的软件 胜过 面面俱到的文档

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值

 

敏捷开发的原则

1. 快速迭代

相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。

2. 让测试人员和开发者参与需求讨论

需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。 同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

3. 编写可测试的需求文档

开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。

4. 多沟通，尽量减少文档

任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。

团队要确保日常的交流，面对面沟通比邮件强得多。

5. 做好产品原型

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

6. 及早考虑测试

及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了