软件过程(Software Procedure)是指软件生存周期所涉及的一系列相关过程。过程是活动的集合；活动是任务的集合；任务要起着把输入进行加工然后输出的作用。活动的执行可以是顺序的、重复的、并行的、嵌套的或者是有条件地引发的。

软件过程可概括为三类：基本过程类、支持过程类和组织过程类。基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。组织过程类包括基础设施过程、改进过程以及培训过程。

软件过程主要针对软件生产和管理进行研究。为了获得满足工程目标的软件，不仅涉及工程开发，而且还涉及工程支持和工程管理。对于一个特定的项目，可以通过剪裁过程定义所需的活动和任务，并可使活动并发执行。与软件有关的单位，根据需要和目标，可采用不同的过程、活动和任务。

2. 为什么我们需要一个软件过程？
有效的软件过程可以提高组织的生产能力：
■理解软件开发的基本原则，可以帮我们做出明智的决定；
■可以标准化你的工作，提高软件的可重用性和Team间的协作；
■我们所采用的这种机制本身是不断提高的，我们可以跟上潮流，使自己不断接收新的，最好的软件开发经验；

有效的软件过程可以改善我们对软件的维护：
■有效地定义如何管理需求变更，在未来的版本中恰当分配变更部分，使之平滑过渡；
■首先在具体操作和相关支持中定义如何平滑地改造软件，并且这种具体操作和支持是可实施的；不可实施的软件过程将很快被束之高阁；

为什么要采用软件过程？归根结蒂，形势所逼！

3. 实施软件过程的必要条件
CMM(Capability Maturity Modeling)作出了明确的定义(由The Software Engineering Institute提出 http://www.sei.cmu.edu )

4. 五个成熟等级
第一级：初始级
在初始级，企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。处于这一等级的企业，成功与否在很大程度上决定于有杰出的项目经理与经验丰富的开发团队。因此，能否雇请到及保有能干的员工成了关键问题。项目成功与否非常不确定。虽然产品一般来说是可用的，但是往往有超经费与不能按期完成的问题。

第二级：可重复级
在这一级，建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于过往的项目的经验来计划与管理新的项目。企业实行了基本的管理控制。符合实际的项目承诺是基于以往项目以及新项目的具体要求而作出的。项目经理不断监视成本、进度和产品功能，及时发现及解决问题以便实现所作的各项承诺。
通过具体地实施这一级的各个关键过程领域的要求，企业实现了过程的规范化、稳定化。因而，曾经取得过的成功成为可重复达到的目标。

第三级：定义级
在这一级，有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时，这些过程是集成到一个协调的整体。这就称为企业的标准软件过程。
　这些标准的过程是用于帮助管理人员与一般成员工作得更有效率。如果有适当的需要，也可以加以修改。在这个把过程标准化的努力当中，企业开发出有效的软件工程的各种实践活动。
　同时，一个在整个企业内施行的培训方案将确保工作人员与管理人员都具备他们所需要的知识与技能。
　非常重要的一点是，项目小组要根据该项目的特点去改编企业的标准软件过程来制订出为本项目而定义的过程。
　一个定义得很清楚的过程应当包括：准备妥当的判据，输入，完成工作的标准和步骤，审核的方法，输出和完成的判据。因为过程被定义得很清楚，因此管理层就能对所有项目的技术过程有透彻的了解。

第四级：定量管理级
在这一级，企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案，要对所有项目的重要的过程活动进行生产率和质量的度量。软件产品因此具有可预期的高质量。
　一个企业范围的数据库被用于收集与分析来自各项目的过程的数据。这些度量建立起了一个评价项目的过程与产品的定量的依据。项目小组可以通过缩小他们的效能表现的偏差使之处于可接受的定量界限之内，从而达到对过程与产品进行控制的目的。
　因为过程是稳定的和经过度量，所以在有意外情况发生时，企业能够很快辨别出特殊的原因并加以处理

第五级：（不断）优化级
在这个等级，整个企业将会把重点放在对过程进行不断的优化。企业会采取主动去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。整个企业都致力于探索最佳软件工程实践的创新。
　项目小组分析引起缺陷的原因，对过程进行评鉴与改进，以便预防已发生的缺陷再度发生。同时，也把从中学到的经验教训传授给其他项目。
　降低浪费与消耗也是这个等级的一个重点。
　处于这一等级的企业的软件过程能力可被归纳为不断的改进与优化。它们以两种形式进行。一种是逐渐地提升现存过程，另一种是对技术与方法的创新。虽然在其他的能力成熟度等级之中，这些活动也可能发生，但是在优化级，技术与过程的改进是作为常规的工作一样，有计划地在管理之下实行的。

5. 关键过程领域
第一级：初始级（Level1: Initial）（无关键过程区域）

第二级：可重复级
■需求管理（Requirements Management）
需求管理的目的是建立和维护用户和软件项目间的关于该软件如何实现用户需求的共识。
需求管理包括：
a. 建立和维护分配该给软件项目的需求的基线。
b.核查该软件项目的计划，活动和正在开发中的产品以确保它们是与分配该给软件项目的需求一致。

■软件项目计划（Software Project Planning）
软件计划的目的是建立合理的计划用作软件开发与软件项目控制。
软件计划包含：
a.选择一种软件生命周期
b.建立一个开发工作的分解构造
c.对与开发工作有关的、重要的计划参数进行估计。
d.识别软件项目的风险。
e.作出必要的承诺。
f.制订软件开发工作的计划。

■软件项目控制（Software Project Control）
软件项目控制的目的是为软件项目的过程提供足够的能见度，从而可以在执行过程中发生对计划的严重偏离时能够采取适当的更正行动。
软件项目控制包括：
a.追踪软件项目的进展与表现，从而与所作的估计、承诺和计划作出对比。
b.追踪软件项目的风险。
c.在发生对计划的严重偏离时采取更正行动。

■软件获取管理（Software Acuisition Management）
软件获取管理的目的是有效地管理从软件项目外部来源获取软件。
软件获取管理包括：
a.找出软件项目对取得外部软件的需要。
b.识别和选择供应者。
c.与供应者达成协议。
d.处理与供应者之间的关系。
e.收取软件项目所需的外部软件。
f.安排对所取得的外部软件的维护与支持。

■软件质量保证（Software Quality Assurance）
软件质量确保的目的是为了客观地核实软件项目的实施行动与开发中的产品遵从于对应的需求、过程描述、标准及规程。
软件质量确保包括：
a.客观地核实软件项目的实施行动与开发中的产品遵从于对应的需求、过程描述、标准及规程。
b.找出及记录所发现的不一致的问题。
c.向项目成员与经理提供反馈。
d.确保那些不符的问题得到处理。

■软件组配管理（Software Configuration Management）
软件结构配置管理(SCM)的目的是贯穿软件生命周期，建立和维持软件项目的产品完整性。
软件结构配置管理包括：
a.确定开发中的软件产品在某一特定时刻的结构配置。
b.控制结构配置的组份的变更。
c.从结构配置库中去制作开发的软件产品。
d.贯穿软件生命周期，维持维软件产品基线的完整性。

第三级：定义级
■企业对过程的重视（Organization Process Focus）
企业对过程的重视的目的是建立和维护对企业的软件过程的理解和协调企业的件工程过程的改进活动。
企业对过程的重视包括：
a.评估企业和项目的软件过程。
b.建立起一个计划去改进软件过程。
c.对建立、维护、改进和使用整个企业内共有的软件过程的活动进行协调。

■企业过程定义（Organization Process Definition）
企业过程定义的目的是建立与维护一套可用的软件过程资源去改进整个企业的程过程效果及为企业的积累性的长期收益提供一个坚实的基础。
企业过程定义所建立的软件过程资源包括：
a.一套企业的标准软件工程过程。
b.对每一种经审核批准用于工程项目的软件生命周期模型的描述。
c.关于如何剪裁企业标准的软件过程以适应具体项目需要的原则和指导方针。
d.企业的软件测量结果数据库。
e.企业的与软件过程有关的文件资料库。

■企业的培训方案（Organization Training Program）
企业的培训计划的目的是增进工作人员的技能和知识，使他们能实质地和高效地担当其软件角色。
企业的培训计划包含：
a.找出什么是企业的软件培训需要。
b.取得与提供所需的培训。

■集成化的软件管理（Integrated Software Management）
集成软件管理的目的是把软件工程与管理集成为一个连贯涵接的、详细定义了、基于企业标准软件过程而剪裁出来的软件过程。
集成软件管理包括：
a.使用企业的软件过程财富，并对之作出贡献。
b.基于企业标准软件过程而剪裁出详细定义了的软件过程。
c.积极主动地使用这个定义了的软件过程。
d.积极主动地对软件的风险进行管理。

■软件产品工程（Software product Engineering）
软件产品工程的目的是始终如一地执行明确定义了的、集成了所有软件项目的术活动的工程过程，去实质地和高效率地制造正确的、稳定的软件开发产品。
软件产品工程包含：
a.按照项目的软件过程，执行工程的各项任务去规定，设计，制造，递交，和维护软件。
b.检验与证实软件产品满足其产品技术需求。

■项目间的协调（Project Interface Coordination）
项目界面协调的目的是确保软件工程人员主动地与企业内的其他功能部门交流协调和合作，以便更好地满足客户的需求。这些功能部门包括技术的功能(例如，系统测试)，支持功能(例如，记录)，和组上的功能(例如，培训和合同)。
项目界面协调牵涉到经埋与员工，其内容包含：
a. 与项目内其他功能部门一道处理系统要求，计划，目标，困难问题和风险。
b. 确定与维持对其他涉及项目的功能部门的承诺。
c. 辨明、跟踪和解决项目内功能间配合的行动与问题。

■交换审核（Peer Reviews）
交互审核的目的是尽早地和有效地从开发中的软件产品中除去缺陷。一个重要的必然结果是对软件过程和开发中的软件产品有一个更好的理解，从能够预防缺陷产生。
交互审核是由软件写作者的同事使用既定的办法去对开发中的软件产品进行检查来找出缺陷与需要作出更改的地方。
交互审核办法的例子包括：检查，结构化走通和积极审核。

第四级：定量管理级（Level4: Quatitative Management）
■企业软件资产共通性（Organization Software Asset Commonality）
企业软件资源共通性的目的是找出企业软件产品之间的共通性，以便在成本，量和生命周期等方面取得收益。
企业软件资源共通性包含：
a. 与企业的其他功能部门合作去定义出共同软件资源的技术要求，从而使项目与企业的战略经营目标保持一致。
b. 建立与维护一套能用于各个项目的开发与产品维护的共同软件资源。
c. 协调对企业内所有项目的共同软件资源的部署，以便取得在成本、质量和生命周期等方面的得益。

■企业过程表现（Organization Process Performance）
企业过程效能的目的是建立和维护用于重要的过程和产品特性的测量、数据与分折技术，去支持对企业与项目的软件过程进行运用统计学方法的管理。
企业过程效能包括：
a. 定义出表征企业软件过程效能的各种测量项目和与之关联的过程效能模型。
b. 从各个软件项目收集这些过程效能的测量结果。
c. 使用这些测量数据来表征企业的标准软件过程。
d. 使用这些测量数据来为整个企业建立软件过程效能模型。

■统计法过程管理（Statistical Process Management）
统计法的过程管理的目的是使所选择到的所有次级过程稳定化及透彻掌握它们的能力，从而达到统计法意义上的产品质量及过程效能的目标。
统计法的过程管理包括：
a. 建立产品质量及过程效能的目标。
b. 选择项目的设定过程中的一些次级过程来进行运用统计法的管理。
c. 找出、测量和分析那些（被选中的）次过程的关键产品和过程的属性持征。
d. 确定每个次过程的关键的属性特征的自然界限。
e. 使得（选中的）次过程成为可预测的。
f. 测量与分析（选中的）次过程的过程效能。
g. 把产品质量和过程效能的测量结果与所定的目标进行比对以便确定相关过程的能力。

第五级：（不断）优化级（Level: Optimizing）
■缺陷预防（Defect Prevention）
缺陷预防的目的是找出缺陷和其他问题产生的共同原因。采取行动去预防它们再次发生，或者采取措施去克服那些产生不及格的过程效能的原因。
缺陷预防包括：
a. 分析过去产生的缺陷和其他的问题。
b. 采取特定的行动来预防那些类型的缺陷与问题在将来再次出现。
c. 采取持定的改进行动去纠正那些产生不及迅程格效能的共同原因。

■企业过程与技术创新（Organization Process and Technology Innovation）
企业过程与技术创新的目的是找出那些能够在一定程度上改进企业的软件过程而有助于达到企业改进软件过程的目标的过程与技术上的改进。
企业过程与技术创新包括：
a. 建立和维护企业的定量法的软件过程改进目标。
b. 收集与评价软件过程改进的建议。
c. 找出与评价潜在的软件过程和技术的创新。
d. 选择在全企业展开改革与创新的候选项目。

■企业改进开展（Organization Improvement Deployment）
企业改进的开展的目的是通过把改进转变为一种系统性的行为方式去持续地和计量地改进企业的软件过程。
企业改进的开展包括：
a. 评价软件过程改进的候选项目。
b. 选择要进行开展的软件改进项目。
c. 开展改进。
d. 测量改进的效果。

从整体来说软件能力成熟度级别从低到高的变化代表了企业的生产活动由高风险低效率到高质量、高生产率的进展。
这儿要注意的一点是每个能力成熟级别的关键过程区域是累加到上一级去的，例如在第三级时就要满足所有第二级与第三级的关键过程领域的目标。
如果要用简单的一句话来表达从一级到高一级所需要的努力的话，我们可以有：
　从一级到二级的转化：规范化过程
　从二级到三级的转化：标准化、稳定的过程
　从三级到四级的转化：可预测的过程
　从四级到五级的转化：继续不断地改进过程

      XP实际上是一种经历过很多实践考验的一种软件开发的方法，它诞生了大概有5 年，它已经被成功的应用在许多大型的公司，如：Bayeris che Landesbank，Credit Swis s Life，DaimlerChrysler，First Union National Bank　Ford Motor Company and UBS.XP 的成功得益于它对客户满意度的特别强调，XP 是以开发符合客户需要的软件为目标而产生的一种方法论，XP 使开发者能够更有效的响应客户的需求变化，哪怕在软件生命周期的后期。

　　同时，XP 也很强调团队合作。团队包括：项目经理，客户，开发者。他们团结在一起来保证高质量的软件。XP 其实是一种保证成功的团队开发的简单而有效的方法。

　　XP 强调四种价值：交流，简易，回馈，勇气。XP 程序员之间紧密的相互交流，XP 程序员也和客户紧密的交流。他们总是保持他们的设计简单明了。项目一开始，XP 就强调通过对软件的不断测试来获得反馈，程序员尽可能早的把软件交给客户，并实现客户对软件需求提出的变化，有了这些基础，XP 程序员就可以自信的面对需求和软件技术的变化。

　　XP 是与众不同的，它有点象快步的舞蹈。XP 开发过程包括许多的小卡片，独立的看，这些小卡片没有什么意义，但是当它们组合在一起，一幅完整的美丽的图片就可以看见，XP方法有别于传统软件开发，它是软件开发的一种新的重要的发展。它改变了我们开发程序的传统思维方式。下面我们将介绍它带给我们那些改变。
 
　　XP属于轻量开发方法中较有影响的一种方法。轻量开发方法是相对于传统的重量开发方法而言。简单地理解，“量”的轻重是指用于软件过程管理和控制的、除程序量以外的“文档量”的多少。XP等轻量开发方法认识到，在当前很多情况下，按传统观念建立的大量文档，一方面需要消耗大量开发资源，同时却已失去帮助“预见、管理、决策和控制的依据”的作用。因此必须重新审视开发环节，去除臃肿累赘，轻装上阵。

一、XP的核心思想

      从长远看，早期发现错误以及降低复杂度可以节约成本。极限编程强调我们将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。通常，通过一个个短小的迭代周期，我们就可以获得一个个阶段性的进展，并且可以及时形成一个版本供用户参考，以便及时对用户可能的需求变更作出响应。

二、XP的十二种方法

      规划策略(The Planning Game)；
      结对编程(Pair programming)
      测试(Testing)
      重构(Refractoring)
      简单设计(Simple Design)
      代码集体所有权(Collective Code Ownership)
      持续集成(Continuous Integration)
      现场客户(On-site Customer)
      小型发布（Small Release）
      每周40小时工作制（40-hour Week）
      编码规范（Code Standards）
      系统隐喻（System Metaphor）

三、XP的四个核心价值

      极限编程中有四个核心价值是我们在开发中必须注意的：沟通（Communication）、简单（Simplicity）、反馈（Feedback）和勇气（Courage）。

　　XP用“沟通、简单、反馈和勇气”来减轻开发压力和包袱；无论是术语命名、专著叙述内容和方式、过程要求，都可以从中感受到轻松愉快和主动奋发的态度和气氛。这是一种帮助理解和更容易激发人的潜力的手段。XP用自己的实践，在一定范围内成功地打破了软件工程“必须重量”才能成功的传统观念。

　　XP精神可以启发我们如何学习和对待快速变化、多样的开发技术。成功学习XP的关键，是用“沟通、简单、反馈和勇气”的态度来对待XP；轻松愉快地来感受XP的实践思想；自己认真实践后，通过对真实反馈的分析，来决定XP对自己的价值；有勇气接受它，或改进它。

四、XP 带给我们的变化

　　通过软件工程设计的简单而优美的软件并不比那些设计复杂而难以维护的软件有价值。这是真的吗？XP认为事实并非如此。

　　一个典型的项目花在人力上的金钱是花在硬件上的时间的20 倍，这意味着一个项目每年要花200 万美元在程序员身上，而仅仅花10 万美元在电脑设备上。很多聪明的程序员说：“我们如此聪明，发现一种方法可以节省20%的硬件开销”，然后他们使得源程序大而且难懂和难以维护，他们会说：“但是我们节省了20%或者2 万美元每年，很大的节省”。反之，如果我们写我们的程序简单而且容易扩展，我们将至少节省10%的人力开销，一笔更大的节省，这是你客户一定会注意到的一些事情。

　　另外一个对客户来说很重要的问题就是程序的BUGS 。XP 不只是强调测试，而且要求正确的测试。测试必须是能自动进行的，以便为程序和客户提供一个安全的环境。在编码的所有阶段，我们不断增加测试用例。当找到bug 时，我们就添加新的测试，一个紧密的安全网就这样产生了。同一个BUG 不出现两次，这些一定会引起用户的注意。你的客户必须注意的另外一件事情：XP 开发者拥抱需求变化。XP 使我们能够接受需求的变化。

　　一般情况下，客户只有在系统被开发完成以后能真正去体会它。XP 却不一样，它通过加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。在XP 中，你的客户应该明确的知道这一点。

　　XP开发过程的大多的革命是在软件开发的方法上，代码质量的重要程度超出人们一般所认为的。仅仅因为我们的客户不能明白我们的源代码并不意味着我们可以不努力去管理代码的质量。

五、我们什么时候用XP

　　XP方法的产生是因为难以管理的需求变化，从一开始你的客户并不是很完全的知道他们要的系统是怎么样的，你可能面对的系统的功能一个月变化多次。在大多数软件开发环境中不断变化的需求是唯一的不变，这个时候应用XP 就可以取得别的方法不可能取得的成功。XP 方法的建立同时也是为了解决软件开发项目中的风险问题。假如你的客户在特定的时间内，需要一个相当难开发的系统，而且对于你的项目组来说，这个系统是一个新的挑战（从来没有做过），那风险就更大了，如果这个系统对于整个软件行业来说都是新的挑战，那么它的风险就更大了，采用XP 将可以减少风险，增加成功的可能。

　　XP方法是为小团体开发建立的，在2-10 个人之间。假如你的团体恰好合适，你就不需要用其他的软件工程方法了，就用XP ，但是要注意你不能将XP 方法应用于大团体的开发项目中。我们应该注意，在需求一惯呈动态变化或者高具有高风险的项目中，你就会发现XP 方法在小团体的开发中的作用要远远高于在大团体的开发。

　　XP方法需要一个扩展的开发团体，XP 团体不仅仅包括开发者，经理、客户也是其中的一员，所有的工作一环扣一环，问问题，商讨方法和日程，增加功能测试，这些问题的解决不仅仅涉及到软件的开发者。

　　另一个需要是可测试性，你必须能增加自动的单元测试和功能测试，然而在你进行这个需求的时候，你会发现有许多的问题很难测试，这需要充分发挥你的测试的经验和智慧，而且你有时还要改变你的设计以便它可以更容易的进行测试。记住：那儿有需求，那儿就应该有测试的方法。

　　在XP方法的好处的清单上，最后一条是生产力。在同样的合作环境下，XP 项目都一致的表现出比使用其他方法高的多的生产力。但这从来不是XP 方法学的真正目标。XP 真实追求的目标是：在规定的时间生产出满足客户需要的软件。假如对于你的开发来说，这是很重要的方面，你就可以选择XP 了。

六、极限编程的有效实践

1、完整团队

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

2、计划游戏

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

3、客户测试

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

4、简单设计

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

5、结对编程

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

6、测试驱动开发

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

7、改进设计

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

8、持续集成

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

9、集体代码所有权

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

10、编码标准

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

11、隐喻

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

12、可持续的速度

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

技术预研过程域是 SPP 模型的重要组成部分。本规范阐述了技术预研的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。

1 介绍

       在产品开发过程中，技术问题可能会层出不穷。如果一点技术障碍都没有遇到，要么是开发人员的技术水平实在太高了，要么是项目的技术含量实在太低了，这类情况比较少见。

一般说来，在设计或实现阶段遇到了技术障碍，才去攻克问题，其代价通常比较高。因为其他人的工作可能会被阻塞，已经投入的不少资源将被闲置。最糟糕的是，如果此技术障碍无法攻克，不得已要改变技术方案、重新设计系统，那么不仅浪费了人力、财力、时间，处理不好还会使开发队伍陷入混乱状态。

       所以开展技术预研工作至少有两大好处：

²        帮助开发人员更好地进行需求开发、系统设计和程序设计。

²        防止开发进程被技术障碍打断，导致大量的相关工作被阻塞。

技术预研的流程如下图 所示。

制定计划－－开展技术预研－－撰写预研报告－－工作成果介绍技术评审…
图 技术预研流程

   2.1 目的

   l         提前发现并解决开发过程中将会遇到的技术障碍。

   2.2 角色与职责

   l         项目经理或技术负责人识别项目中的技术难题，指定技术预研人员攻克该问题。

   2.3 启动准则

   l         项目中的技术难题已经识别。

   l         技术预研人员已经指定。

   2.4 输入

   l         一些用户需求文档和技术方案文档

   2.5 主要步骤

   [Step1] 制定计划

   l         技术预研人员制定《技术预研计划》，主要内容包括：

   ²        确定技术预研的内容和目标。

   ²        确定应递交的工作成果。

   ²        分配任务，制定进度表。

   l         项目经理或技术负责人审批该计划，如果该计划被批准，则转向 [Step2] 。

   [Step2] 开展技术预研

   l         技术预研人员按照计划开展技术预研工作。

   [Step3] 撰写技术预研报告

   l         在预研任务结束时，技术预研人员撰写《技术预研报告》。

   [ 后续活动 ]

   l         技术预研人员向相关人员介绍工作成果。

   l         项目经理或技术负责人视具体情况决定是否对该预研成果进行技术评审。

      2.6 输出

   l         《技术预研报告》

      2.7 结束准则

   l         指定的预研任务已经完成，《技术预研报告》已经产生。

      2.8 度量

   l         技术预研人员统计工作量和工作成果的规模，汇报给项目经理。

3 实施建议

   l         技术预研不同于真正地开发产品，投入人员与时间相对比较少。一个项目可以有多次技术预研，由项目经理或技术负责人视具体情况而定。

   l         对技术预研过程中产生的所有有价值的文档进行配置管理。