软件工程方法论杂记

软件开发过程是随着开发技术的演化而随之改进的。从早期的瀑布式（Waterfall）的开发模型到后来出现的螺旋式的迭代（Spiral）开发，以致最近开始兴起的敏捷软件开发（Agile），他们展示出了在不同的时代软件产业对于开发过程的不同的认识，以及对于不同类型项目的理解方法。

软件工程方法论

轻量级的开发过程没有对大量正式文档的要求。著名的轻量级开发方法包括极限编程（XP）和敏捷过程（Agile Processes）。

重量级方法呈现的是一种“防御型”的姿态。在应用“重量级方法”的软件组织中，由于软件项目经理不参与或者很少参与程序设计，无法从细节上把握项目进度，因而会对项目产生“恐惧感”，不得不要求程序员不断撰写很多“软件开发文档”。

轻量级方法则呈现“进攻型”的姿态，这一点从XP方法特别强调的四个准则—“沟通、简单、反馈和勇气”上有所体现。目前有一些人认为，“重量级方法”适合于大型的软件团队（数十人以上）使用，而“轻量级方法”适合小型的软件团队（几人、十几人）使用。当然，关于 重量级方法和 轻量级方法的优劣存在很多争论，而各种方法也在不断进化中。

重量级方法强调以开发过程为中心，而不是以人为中心。

-----------------------------------------------------------------------------------------------

统一软件开发过程（RUP，Rational Unified Process）

RUP最重要的它有三大特点：1）软件开发是一个迭代过程，2）软件开发是由Use Case驱动的，3）软件开发是以架构设计（Architectural Design）为中心的。

-----------------------------------------------------------------------------------------------

极限编程（eXtreme Programming,XP）

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

极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。XP的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、 也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是 更加现实更加有效的方法。

核心實踐源自被廣泛接受的最佳實踐，並且被推向極至：

• 开发人员和客户之间的交互是有益的。因此，一个极限编程的小组从理论上要求需要一个软件使用者在身边，这个使用者制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答（实际工作中，这个角色是由客户代理商完成的）.
• 如果学习是好的，那么就把它做到底：这样减少了开发和回馈周期的长度，测试也能更早完成。
• 简单的代码更可能工作。所以极限编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码，这样或多或少降低了代码的复杂性和重复性。
• 如果简单的代码是好的，那么把变得复杂的代码改写成简单的。
• 代码评审是好的。因此，极限编程的程序设计师以两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出的时候就被人评审了。
• 测试代码是好的。因此，在极限编程中，测试用例在实际代码之前就被写出来了。代码只有在通过测试的时候才被认为完成了。（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的，实时的，被预先编好的自动化测试方式来保证它的确有作用。参看测试驱动的开发。

• 一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为Rational统一过程更适合大的团队。然而，极限编程在一些超过100人的开发小组中获得成功。并不是极限编程不能够推广到更大的团队，而是很少有更大的团队来试著用它。极限编程的人员也拒绝去随便推测这个问题。

-----------------------------------------------------------------------------------------------

敏捷软件开发宣言
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动  高于 流程和工具
工作的软件  高于 详尽的文档
客户合作  高于 合同谈判
响应变化  高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。

敏捷宣言遵循的原则
我们遵循以下原则：
我们最重要的目标，是通过持续不断地
及早交付有价值的软件使客户满意。

欣然面对需求变化，即使在开发后期也一样。
为了客户的竞争优势，敏捷过程掌控变化。

经常地交付可工作的软件，
相隔几星期或一两个月，倾向于采取较短的周期。

业务人员和开发人员必须相互合作，
项目中的每一天都不例外。

激发个体的斗志，以他们为核心搭建项目。
提供所需的环境和支援，辅以信任，从而达成目标。

不论团队内外，传递信息效果最好效率也最高的方式是
面对面的交谈。

可工作的软件是进度的首要度量标准。

敏捷过程倡导可持续开发。
责任人、开发人员和用户要能够共同维持其步调稳定延续。

坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

以简洁为本，它是极力减少不必要工作量的艺术。

最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效，
并依此调整自身的举止表现。

参考：

软件工程

CMM

极限编程

敏捷软件开发宣言

敏捷宣言遵循的原则
Scrum敏捷项目管理