软件过程开发方法(RUP、AP、MP、HP)收藏

软件开发一个复杂的活动, 它包含了需求调研, 系统设计, 开发, 部署, 维护等活动.  而且现有规范和流程目的并不是让你去完成文档,  而是通过这些文档, 让软件的质量更能得到保证。组成软件开发和系统演化的活动有着各种模型(软件生存周期，软件开发模型，软件过程)，但是典型地都包含了以下的过程或活动：分析、设计、实现、确认(测试验收)、产品化、维护。

软件开发方法的一般要求：当提出一种软件开发方法时，应该考虑许多因素，包括：

①     覆盖开发全过程，并且便于在各阶段间的过渡；

②     便于在开发各阶段中有关人员之间的通信；

③     支持有效的解决问题的技术

④     支持系统设计和开发的各种不同途径

⑤     在开发过程中支持软件正确性的校验和验证；

⑥     便于在系统需求中列入设计、实际和性能的约束；

⑦     支持设计师和其他技术人员的智力劳动；

⑧     在系统的整个生存周期都支持它的演化；

⑨受自动化工具的支持。

一个项目的成功与否跟人员、技术、资源、测试、架构、需求、领导、组织等因素有关系。把以上内容我们划分为生命周期、人员、方法、工件、组织。而我们的软件过程就针对这些方面讨论解决方案，目前的有Rup、AP、MP、HP、CMMI、Psp、Tsp等。这里将介绍一些方法的思想与指导原则。

一、软件过程模型

    分类：

1.惯例过程模型。

　　2.瀑布模型(又叫作生命周期模型)。

　　3.增量过程模型: 包括 增量模型、RAD模型。

　　4.演化过程模型: 包括 原型开发模型、螺旋模型、协同开发模型。

　　5.专用过程模型: 包括 基于构件的开发模型、形式化方法模型、面向方面的软件开发模型。

过程模型图：

二、常见软件过程开发方法（Rup、AP、MP、HP）

1、RUP

RUP（Rational Unified Process，统一软件开发过程，统一软件过程)是一个面向对象且基于网络的程序开发方法论。以用例驱动、架构为中心、迭代增量开发方法。

主要内容：

1）六大经验：迭代式开发、管理需求、基于组件的体系结构、可视化建模、验证软件质量、控制软件变更。

2）统一软件开发过程RUP的二维开发模型

RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图：

3）开发过程中的各个阶段和里程碑

　　RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

　　（1）． 初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。 初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

　　（2）． 细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。 细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

　　（3）． 构造阶段

　　在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。 构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

　　（4）． 交付阶段

交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

4）RUP的核心工作流(Core Workflows)

　　RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

　　（1）． 商业建模(Business Modeling)

　　商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

　　（2）． 需求(Requirements)

　　需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

　　（3）． 分析和设计(Analysis & Design)

　　分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

　　（4）． 实现(Implementation)

　　实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

　　（5）． 测试(Test)

　　测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确　认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

　　（6）． 部署(Deployment)

　　部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

　　（7）． 配置和变更管理(Configuration & Change Management)

配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

　　（8）． 项目管理(Project Management)

　　软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

　　（9）． 环境(Environment)

　　环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

5）RUP的十大要素

　　（1）. 开发前景

　　（2.） 达成计划

　　（3.） 标识和减小风险

　　（4）. 分配和跟踪任务。。

　　（5）. 检查商业理由

　　（6.） 设计组件构架

　　（7）. 对产品进行增量式的构建和测试

　　（8）. 验证和评价结果

　　（9）. 管理和控制变化

　　（10）. 提供用户支持

　　让我们逐一的审视这些要素，看一看它们什么地方适合ＲＵＰ，找出它们能够成为十大要素的理由。

　　（1）. 开发一个前景

　　有一个清晰的前景是开发一个满足涉众真正需求的产品的关键。 前景抓住了ＲＵＰ需求流程的要点：分析问题，理解涉众需求，定义系统，当需求变化时管理需求。 前景给更详细的技术需求提供了一个高层的、有时候是合同式的基础。正像这个术语隐含的那样，它是软件项目的一个清晰的、通常是高层的视图，能被过程中任何决策者或者实施者借用。它捕获了非常高层的需求和设计约束，让前景的读者能理解将要开发的系统。它还提供了项目审批流程的输入，因此就与商业理由密切相关。最后，由于前景构成了“项目是什么？”和“为什么要进行这个项目？”，所以可以把前景作为验证将来决策的方式之一。 对前景的陈述应该能回答以下问题，需要的话这些问题还可以分成更小、更详细的问题： ? 关键术语是什么？（词汇表） ? 我们尝试解决的问题是什么？（问题陈述） ? 涉众是谁？用户是谁？他们各自的需求是什么？ ? 产品的特性是什么？ ? 功能性需求是什么？（Ｕｓｅ Ｃａｓｅｓ） ? 非功能性需求是什么？ ? 设计约束是什么？

　　（2）. 达成计划

　　“产品的质量只会和产品的计划一样好。” (2) 在ＲＵＰ中，软件开发计划（ＳＤＰ）综合了管理项目所需的各种信息，也许会包括一些在先启阶段开发的单独的内容。SDP必须在整个项目中被维护和更新。 ＳＤＰ定义了项目时间表（包括项目计划和迭代计划）和资源需求（资源和工具），可以根据项目进度表来跟踪项目进展。同时也指导了其他过程内容（原文：process components）的计划：项目组织、需求管理计划、配置管理计划、问题解决计划、QA计划、测试计划、评估计划以及产品验收计划。

　　在较简单的项目中，对这些计划的陈述可能只有一两句话。比如，配置管理计划可以简单的这样陈述：每天结束时，项目目录的内容将会被压缩成ZIP包，拷贝到一个ZIP磁盘中，加上日期和版本标签，放到中央档案柜中。 软件开发计划的格式远远没有计划活动本身以及驱动这些活动的思想重要。正如Dwight D.Eisenhower所说：“plan什么也不是，planning才是一切。” “达成计划”—和列表中第3、4、5、8条一起—抓住了RUP中项目管理流程的要点。项目管理流程包括以下活动：构思项目、评估项目规模和风险、监测与控制项目、计划和评估每个迭代和阶段。

　　（3）. 标识和减小风险

　　RUP的要点之一是在项目早期就标识并处理最大的风险。项目组标识的每一个风险都应该有一个相应的缓解或解决计划。风险列表应该既作为项目活动的计划工具，又作为确定迭代的基础。

　　（4）. 分配和跟踪任务

　　有一点在任何项目中都是重要的，即连续的分析来源于正在进行的活动和进化的产品的客观数据。在RUP中，定期的项目状态评估提供了讲述、交流和解决管理问题、技术问题以及项目风险的机制。团队一旦发现了这些障碍物（篱笆），他们就把所有这些问题都指定一个负责人，并指定解决日期。进度应该定期跟踪，如有必要，更新应该被发布。（原文：updates should be issued as necessary。） 这些项目“快照”突出了需要引起管理注意的问题。随着时间的变化/虽然周期可能会变化（原文：While the period may vary。），定期的评估使经理能捕获项目的历史，并且消除任何限制进度的障碍或瓶颈。

　　（5）. 检查商业理由

　　商业理由从商业的角度提供了必要的信息，以决定一个项目是否值得投资。商业理由还可以帮助开发一个实现项目前景所需的经济计划。它提供了进行项目的理由，并建立经济约束。当项目继续时，分析人员用商业理由来正确的估算投资回报率(ROI，即return on investment)。 商业理由应该给项目创建一个简短但是引人注目的理由，而不是深入研究问题的细节，以使所有项目成员容易理解和记住它。在关键里程碑处，经理应该回顾商业理由，计算实际的花费、预计的回报，决定项目是否继续进行。

　　（6）. 设计组件构架

　　在RUP中，件系统的构架是指一个系统关键部件的组织或结构，部件之间通过接口交互，而部件是由一些更小的部件和接口组成的。即主要的部分是什么？他们又是怎样结合在一起的？ RUP提供了一种设计、开发、验证构架的很系统的方法。在分析和设计流程中包括以下步骤：定义候选构架、精化构架、分析行为（用例分析）、设计组件。 要陈述和讨论软件构架，你必须先创建一个构架表示方式，以便描述构架的重要方面。在RUP中，构架表示由软件构架文档捕获，它给构架提供了多个视图。每个视图都描述了某一组涉众所关心的正在进行的系统的某个方面。涉众有最终用户、设计人员、经理、系统工程师、系统管理员，等等。这个文档使系统构架师和其他项目组成员能就与构架相关的重大决策进行有效的交流。

　　（7）. 对产品进行增量式的构建和测试

　　在RUP中实现和测试流程的要点是在整个项目生命周期中增量的编码、构建、测试系统组件，在先启之后每个迭代结束时生成可执行版本。在精化阶段后期，已经有了一个可用于评估的构架原型；如有必 要，它可以包括一个用户界面原型。然后，在构建阶段的每次迭代中，组件不断的被集成到可执行、经过测试的版本中，不断地向最终产品进化。动态及时的配置管理和复审活动也是这个基本过程元素（原文：essential process element）的关键。

　　（8）. 验证和评价结果

　　顾名思义，RUP的迭代评估捕获了迭代的结果。评估决定了迭代满足评价标准的程度，还包括学到的教训和实施的过程改进。 根据项目的规模和风险以及迭代的特点，评估可以是对演示及其结果的一条简单的纪录，也可能是一个完整的、正式的测试复审记录。 这儿的关键是既关注过程问题又关注产品问题。越早发现问题，就越没有问题。（原文：The sooner you fall behind, the more time you will have to catch up.）

　　（9）. 管理和控制变化

　　RUP的配置和变更管理流程的要点是当变化发生时管理和控制项目的规模，并且贯穿整个生命周期。其目的是考虑所有的涉众需求，尽可能的满足，同时仍能及时的交付合格的产品。 用户拿到产品的第一个原型后（往往在这之前就会要求变更），他们会要求变更。重要的是，变更的提出和管理过程始终保持一致。 在RUP中，变更请求通常用于记录和跟踪缺陷和增强功能的要求，或者对产品提出的任何其他类型的变更请求。变更请求提供了相应的手段来评估一个变更的潜在影响，同时记录就这些变更所作出的决策。他们也帮助确保所有的项目组成员都能理解变更的潜在影响。

　　（10）. 提供用户支持

在RUP中，部署流程的要点是包装和交付产品，同时交付有助于最终用户学习、使用和维护产品的任何必要的材料。 项目组至少要给用户提供一个用户指南（也许是通过联机帮助的方式提供），可能还有一个安装指南和版本发布说明。 根据产品的复杂度，用户也许还需要相应的培训材料。最后，通过一个材料清单（BOM表，即Bill of Materials）清楚地记录应该和产品一起交付哪些材料。 关于需求 有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢？他们不重要吗？我会告诉他我为什么没有把它们包括进来。有时，我会问一个项目组（特别是内部项目的项目组）：“你们的需求是什么？”，而得到的回答却是：“我们的确没有什么需求。” 刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢？当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演化。 因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢？”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前景”）中列出的问题进行了沟通，需求也自然而然的流动着（原文：and the requirements just flow naturally.）。 也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。

RUP的生命周期模型与传统的瀑布模型、演化模型、螺旋模型、喷泉模型不同的是在先启、精化、构建、产品化阶段每个过程可以有迭代和增量，而迭代以里程碑确定，在具体的过程中工作流程的侧重点是不同的，还有就是各个工作流程是可以并行的，提高开发效率。方法上采用用例驱动；人员上有相关角色和个体的划分，对于产品，主要是要以架构为中心，设计出具有高重用性、安全性、可扩展性等的系统。

2、AP

敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。但敏捷开发并不是一种创新，敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。然而，我们不得不面对的现实却是，敏捷中模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。

敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。

主要内容：

1）  敏捷是“一个”过程
敏捷不是一个过程，是一类过程的统称，它们有一个共性，就是符合敏捷宣言，遵循敏捷的原则。
敏捷宣言如下：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
由价值观引出的12条敏捷原则：
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
工作的软件是首要的进度度量标准。
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
不断地关注优秀的技能和好的设计会增强敏捷能力。
简单——使未完成的工作最大化的艺术——是根本的。
最好的构架、需求和设计出自于自组织的团队。
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
建立敏捷联盟的17位大师所创立的敏捷方法包括：极限编程，Scrum，特征驱动开发，动态系统开发方法，自适应软件开发，水晶方法，实用编程方法。这些方法统称为敏捷方法。
其实每个人都可以从敏捷宣言和原则出发，明确问题，找出一些解决方法，形成自己的过程。
2）敏捷开发的设计原则

关于敏捷开发的设计原则：

单一职责原则SRP：Single Responsibility Principle

开放封闭原则OCP：Open－Close Principle

Liskov替换原则LSP：Liskov Substitution Principle

依赖倒置原则DIP：Dependency Invertion Principle

接口隔离原则ISP：Interface Separate Principle

关于包的设计原则：

重用发布等价原则REP：Reuse Equivalence Principle

共同重用原则CRP：Common Resue Principle

共同封闭原则CCP：Common Close Principle

无环依赖原则ADP：Acyclic Dependency Principle

稳定依赖原则SDP：Stabilization Dependency Principle

稳定性度量公式：I＝Ce/(Ca+Ce) (I:不稳定度，Ce:输入耦合度，Ca：输出耦合度)

I取值范围在【0，1】，I＝0表示具有最大稳定度；iI＝1标识具有最大不稳定度

稳定抽象原则SAP：Stabilization Abstract Principle

AP主要有XP流派，当然还有很多的流派，包括极限编程，SCRUM,动态系统开发，特征驱动开发等，但是这里主要探讨的是XP，AP中有4个思想，12条原则，主要在开发中强调人员的重要性和可操作性软件的重要性，在方法上我们强调简单，在人员上强调人员和交互高于环境和工具，产品上强调最早交付，迭代欢迎需求的变化，直到项目后期依旧欢迎需求的变更，最大化的包含需求为客户提高竞争力。所以在AP中，由于是方法学家提出来的，所以是比较激进的，适合小型的项目开发，以及在资源等有要求的情况下快速开发。

Extreme Programming（XP，极限编程） 是一种轻量级的软件开发方法，它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。XP强调用户满意，开发人员可以对需求的变化作出快速的反应。XP强调team work。项目管理者，用户，开发人员都处于同一个项目中，他们之间的关系不是对立的，而是互相协作的，具有共同的目标：提交正确的软件。XP强调4个因素：

交流(communication)，XP要求程序员之间以及和用户之间有大量而迅速的交流

简单（simplicity），XP要求设计和实现简单和干净

反馈（feedback）通过测试得到反馈，尽快提交软件并根据反馈修改

勇气（courage）。勇敢的面对需求和技术上的变化

XP特别适用于需求经常改变的领域，客户可能并系统的功能并没有清晰的认识，可能系统的需求经常需要变动。

XP也适用于风险比较高的项目，当开发人员面对一个新的领域或技术时，XP可以帮助减低风险

XP适用于小的项目（人员上），人员在2-12人之间，XP不适用于人员太多的项目，事实上，在需求经常变化或风险比较高的项目中，少量而有效的XP开发人员效率要远远高于大量的开发人员。

3、MP

MP主要是微软依靠自己的开发经验建立的软件过程，作为全球最大、最成功的软件公司，MP有自己的体系。当然在人员上主要摒弃了传统的项目经理职务，取而代之的是产品经理和程序经理，这里我要说明的是这个举措是相当的好，可以使得项目经理的职责细化，使得任务明确，产品经理对外满足用户需求而程序经理对内组织团队开发。方法上：Mp采用每日编译，和AP中的持续集成是一样的，需求是提出远景范围文档，提出远期和近期的目标，而且把整个生命周期划分为5个阶段。当然MP主要提出均衡三角形的模型，使得人员、进

度、功能&性能三者达到平衡。

微软过程原则：

1） 制定计划时兼顾未来不确定因素

2） 通过有效的风险管理减少不确定因素的影响

3） 经常生成过渡性的版本并快速测试来提高产品的稳定性及可测性

4） 快速循环递进的开发过程

5） 从产品特性和成本控制出发创造性地工作

6） 创建确定的进度表

7） 使用小型项目组并发完成工作，并设置多个同步

8） 将大型项目分解成多个可管理的单元，以便更快地发布产品

9） 用产品的前景目标和概要说明指导项目开发工作-先基线后冻结

10）避免产品走形

11）使用原型验证概念，进行开发前的测试

12） 零缺陷概念

13） 非责难式的里程碑评审会

微软开发产品的每个生命周期分五个阶段

1） 构想阶段

2） 计划阶段

3） 开发阶段

4） 稳定阶段

5） 发布阶段

4、HP和谐软件过程

在新的发展阶段继续全面快速地发展IT，必须坚持以和谐软件过程为指导，和谐软件过程是软件工程在中国的新发展，是对软件生命周期、软件项目管理、系统架构、系统分析的重要指导方针，是企业进行信息化建设的重大战略思想。和谐软件过程第一次科学地回答了什么是软件、如何保证并提高软件品质、如何展开软件工程各环节等软件基本问题，认为品质低下不是软件、操作不便不是软件、非人性化不是软件、存在较多bug不是软件、效率低下（研发效率和运行效率）不是软件、业务错乱不是软件、团队不稳不是软件、管理混乱不是软件、难以扩展和维护不是软件、不能共享软件成果不肯共担软件责任不是软件、研发维护过于繁琐不是软件等实际问题。

和谐软件过程，是立足中国当前基本国情和行业发展背景，是在总结我国实践经验和借鉴国外发展经验基础上，为适应新的软件发展要求提出来的。进入新世纪新阶段，我国软件行业发展呈现出了一系列新的阶段性特征，主要是：企业对软件需求与日俱增，同时软件研发不规范、漏洞多、性能差，技术思想大多依靠外国，自主创新能力不强，长期形成的需求误解、返工率高、效率低下、系统不稳定等问题尚未根本改变；从业人员的收入水平参差不齐、加班福利得不到根本保障，客户、企业、员工三者利益冲突此伏彼起，要想统筹兼顾各方面利益难度加大。

行业软件建设发展不平衡，企业霸占市场，信息化建设的难以分割性，导致公开招标不可能，因而只能漫天要价议标；IT从业人员的与日俱增，导致企业可以选择职员范围更广，因而员工的薪资待遇得不到合理的价位保证；另一方面，IT企业的迅速扩建，导致IT从业人员有了更多的选择，通过频繁的跳槽来快速提升薪资待遇成为有实力一族的经验技巧，从而使得企业的项目风险与日俱增；企业的速增，客户也有了更多的选择，一些新项目或者老项目改造扩建等，通过恶意招标使得企业利润大幅降低；在企业利润得不到保证时，加班成了家常便饭，得不到加班补贴，使得降低软件品质成为了一线职员的自救措施，软件品质得不到保障又反过来影响了公司的业务业绩形象，从而进一步影响了员工的薪资福利；同时更多人对信息技术的掌握，以及对软件要求、软件文化需求、薪资待遇、职业规划日趋旺盛，企业、员工的选择性、多变性、差异性明显增强，对企业信息化建设提出了更高要求；软件活力显著增强，同时社会结构、公司项目组织形式、社会利益格局发生深刻变化，软件工程、系统架构和项目管理面临诸多新课题；对外开放日益扩大，同时面临的国际竞争日趋激烈，欧美国家的语言压力长期存在，可以预见和难以预见的风险与困难将不断增多，统筹国内发展和对外开放要求更高。

我们要强调认清国内软件行业的基本国情，不是要妄自菲薄、自甘落后，也不是要脱离实际、急于求成，更不能闭门自锁，而是要坚持把它作为推进改革、谋划发展的根本依据。我们必须始终保持清醒的头脑，立足当前情况这个最大的实际，科学分析我国全面参与软件全球化的新机遇新挑战，全面认识软件工业化、信息化、城镇化、市场化、国际化深入发展的新形势新任务，深刻把握我国软件发展面临的新课题新矛盾，更加自觉地走和谐软件道路，奋力开拓中国特色软件工程更为广阔的发展前景。

和谐软件过程，第一要义是平衡，核心是以人为本，基本要求是涉众共同承担软件义务共享软件成果，根本指导思想与实施方法是简易法则，实践要求是全面协调。

必须坚持把平衡作为和谐软件工程的第一要义。平衡，对于整个软件生命周期，具有决定性意义。和谐的目的在于永续，平衡是永续的根本保证。平衡，包括了各方利益（软件权利和软件义务）的平衡，对于员工则更体现了工作绩效与薪资待遇的平衡，例如加班必须给予补贴，这直接体现了劳动法第44条和民法通则的补偿原则，是和谐软件过程对自然法原则的应用，也是牛顿力学的受力平衡与热平衡、心理平衡等自然法则在和谐软件过程中的具体应用。我们要牢牢把握好平衡这个中心，坚持聚精会神搞信息化建设、一心一意做项目，不断解放和发展软件生产力。更好地实施软件兴国策略、软件强国战略，着力把握软件发展规律、创新软件发展理念、转变软件研发模式、破解软件难题，提高软件品质和软件效益，实现又好又快地永续研发软件。努力实现以人为本、涉众共同承担软件义务共享软件成果，实现各方面的有机统一、员工企业客户团结和睦的和谐发展，实现通过维护软件平衡、发展员工和企业、提升客户竞争力。

和谐软件过程必须坚持简易法则。简易的目的在于务实、实用，在于提高效率、政通人和。乾以易知，坤以简能；易则易知，简则易从；易知则有亲，易从则有功；有亲则可久，有功则可大；可久则贤人之德，可大则贤人之业；易简而天下之理得矣；天下之理得，而成位乎其中矣。系统架构、项目研发不能舍近求远、舍简求繁，不能以为了骗取高额的项目费而故意采用繁琐的方法，骗取较多的工时；也不能以本来就有简易快速的方法、成熟的技术方案可以借鉴参考，却故意采用其他方法；当现有方法或者新技术不足以提高效率甚者会影响效率时，是否存在重复设计时，我们务必考虑如何优化，使之可以多块好省地进行。务必坚持信息向上集中、服务向下延伸为基本理念，以信息集成化为原则，不要不断建立一个又一个的信息孤岛。软件至简，不教而用！

和谐软件过程必须始终坚持以人为本。软件最终是给人用过的，研发过程也离不开人的积极努力，全心全意为客户创造最好的软件是和谐软件过程的根本宗旨，企业和员工的一切奋斗和工作都是为了服务客户。要始终把实现好、维护好、升级发展好最广泛客户的软件需求作为企业和员工一切工作的出发点和落脚点，尊重客户、员工的主体地位，发挥员工的首创精神，保障员工的各项权益，走利益共赢的软件道路，促进三者的全面发展，做到软件为了人、研发依靠人、软件成果由人共享(企业即企业法人)。

和谐软件过程必须坚持全面协调。要按照软件需求进行系统总体分析和系统架构，全面做好需求调研、设计、研发、测试、上线实施、配置管理、数据库DBA、网络管理，各个环节、各个方面相协调，促进客户与企业、绩效与薪资福利相协调。

和谐软件过程必须坚持统筹兼顾。要正确认识和妥善处理软件研发过程中的各项重大关系，务必统筹兼顾利益、质量、时间、成本、范围、员工与企业和客户和谐永续地发展、国内创新发展和借鉴吸取国外成功优秀经验、实行软件对外开放政策，统筹员工、企业与客户的关系，统筹员工利益和企业利益、企业利益和客户利益、公司业绩和软件品质，充分调动各方面积极性。统筹三方利益、把握软件品质大局，树立世界眼光，加强战略思维，善于从国际形势发展变化和充分借鉴祖国传统哲学中各类有效经验，把握发展机遇、应对风险挑战，营造良好的软件开发环境。既要总揽全局、统筹规划，又要抓住牵动全局的主要工作、事关多方利益的突出问题，着力推进、重点突破。

深入贯彻落实和谐软件过程，要求我们始终坚持“平衡、简易、统筹”的基本观点和方法。软件过程的基本政策路线是企业、员工、客户的生命线，是实现和谐永续研发的根本保证。以平衡为第一要义是软件过程得以正常开展的基本前提，是员工、企业、客户基本要求得以实现的根本要求；简易法则是展开具体工作之本，是实现员工、企业、客户利益最大化的现实基础；总结、吸收和创新是不断提高工作效率、提高各方利益的活力源泉。要坚持把以促进利益平衡、以简易法则提高效率、保证软件品质三个基本点统一于共享软件成果共担软件义务之中，不断促进和发展具有中国特色的和谐软件过程的伟大实践之中，任何时候都决不能动摇。

深入贯彻落实和谐软件过程，要求我们继续深化改善软件过程。要把改善创新精神贯彻到软件工程的各个环节，毫不动摇地坚持改善方向，提高改善决策的科学性，增强改善措施的协调性。要完善和谐的软件权力义务体制，推进各方面体制改善创新，加快重要过程和关键环节的改善步伐，全面提高开放总结反思吸收借鉴创新水平，着力构建充满活力、富有效率、更加开放、有利于软件研发的体制机制，为发展中国特色软件事业提供强大动力和体制保障。要坚持把改善各方权力义务平衡作为正确处理改善研发过程和发展稳定团队的结合点，使改善始终得到多方软件人民的拥护和支持。

深入贯彻落实和谐软件过程，要求我们切实加强和改进团队建设。企业要站在完成为客户提高工作效率使命的高度，要把提高软件项目系统架构能力、保持和提高软件品质能力，体现到项目管理、系统分析、促进软件过程的和谐上来，要落实到引领软件过程发展进步、担任起创新的重要使命，要更好地代表和实现最广大软件人民的根本利益上来，使软件工程的各项工作更加符合和谐软件过程的要求，为和谐软件过程提供可靠的体制和组织保障。

和谐软件过程，在思想理念和实践方法上，要充分借鉴中国先秦诸子百家中法家、儒家、兵家、道家、医家、史家、墨家、纵横家、易家等一切优秀的思想理念和有效的方法论，尤其是法家的变通和效率思想、儒家的人性关怀、墨家的人才观、纵横家的心理学谈判技巧解释沟通、兵家的灵活创新、医家的防范思想和整体辩证观念、道家全面协调和谐永续思想、史家的反思总结借鉴方法论、和易经（远胜于西方所谓的系统工程）的系统观念，是由工作在软件一线的客户代表、企业领导、系统分析师、系统架构师、项目经理、高级程序员根据实践经验、教训和理论的不断反思总结所得出的，具有很强的理论基础和切实的实际可操作可行性。同时和谐软件过程在吸收借鉴方面始终坚持泰山不让土壤、河海不择细流、王者不却众庶、有容乃大、海纳百川的博大胸怀与思想境界以及不期修古、不法常可、论世之事、因为之备的方法论。和谐软件过程虽然是软件工程在中国发展的新发展、新成果，但是和谐软件过程同样很强调应当根据不同文化、不同信仰的民族特点、国家国情来做出裁减和调整。

深入贯彻落实和谐软件过程，要求我们积极构建和谐的软件文化。和谐软件过程是中国特色软件工程的本质属性，和谐软件过程是软件工程在中国发展的新成果，是和党的科学发展是内在统一的，也是党所一贯主张的自主创新理念和自主知识产权在软件工程中的应用。没有和谐软件过程就没有软件工程，没有和谐软件过程也不可能持续永续地研发出具备完美软件品质的软件产品。实施和谐软件过程是贯穿于中国特色软件工程全过程的长期历史任务，是在软件研发的基础上正确处理各种软件矛盾的历史过程和社会结果。要通过发展不断促进增加各方利益、不断改善人的软件生活，又要通过软件研发保障软件公平正义、不断促进过程和谐。实现软件过程的公平正义是涉众的一贯主张，是中国软件事业走向世界并引领世界软件产业发展方向的重大任务。在软件过程中要始终按照民主法治、公平正义、诚信友爱、充满活力、安定有序、员工企业客户和谐相处的总要求和共同建设、共同享有的原则，着力解决三方最关心、最直接、最现实的利益问题，努力形成软件人民各尽其能、各得其所而又和谐相处的局面，为发展软件提供良好的软件文化环境。

全体IT从业人员、所有软件人民要全面把握和谐软件过程的科学内涵和精神实质，增强贯彻落实和谐软件过程的自觉性和坚定性，着力转变不适应不符合和谐软件过程的思想观念，着力解决影响和制约和谐软件过程的突出问题，把软件社会的发展积极性引导到和谐过程上来，把和谐软件过程贯彻落实到软件工程的各个方面。

总之，我们要不断坚持和谐软件过程，根据软件、行业、人文等各类因素，不断地落实和深化和谐软件过程的理念，不断反思总结吸收借鉴改善创新，把党所一贯主张的自主创新、自主知识产权要求通过和谐软件过程真正得到体现，使中国软件能够赶上并超过美国甚至领先世界。

 和谐软件过程是以人为核心，坚持“平衡、简易、统筹”的基本观点和方法。软件过程的基本政策路线是企业、员工、客户的生命线，是实现和谐永续研发的根本保证。以平衡为第一要义是软件过程得以正常开展的基本前提，是员工、企业、客户基本要求得以实现的根本要求；简易法则是展开具体工作之本，是实现员工、企业、客户利益最大化的现实基础；总结、吸收和创新是不断提高工作效率、提高各方利益的活力源泉。要坚持把以促进利益平衡、以简易法则提高效率、保证软件品质三个基本点统一于共享软件成果共担软件义务之中。

总结：软件过程方法没有最好的方法，只有最适合的方法。由于每个公司文化和项目背景不同，最适合公司文化和项目特点的方法就是最佳、最好的开法。