CMM中的需求管理与需求开发
CMM与CMMI比较
1、 CMMI阶段式的基本结构从CMM演变而来，但是CMMI的结构更加的形式化和精致，也更加的复杂，尤其为了保证连续式和阶段式的同一性，更加增加了结构的理解难度。
2、 CMMI强调了对需求的管理，有两个过程域说明对需求的控制：需求管理REQM、需求开发RD。
而在CMM中只有一个关键过程域：需求管理RM以及软件产品工程SPE中的一个实践来说明对需求的管理和控制。
3、 CMMI加强了对工程过程的重视，提供了更加细致的要求和指导，而CMM 中却只有一个关键过程域SPE来进行要求和指导。
4、 CMMI强调了度量，并且从项目的早期就已经进行了度量，在阶段式中CMMI二级有一个过程域：度量和分析；而在CMM中没有专门的要求和指导，度量和分析的要求分布在每个关键过程域中。
5、 CMMI比CMM更加强调了对风险的管理，在CMM中风险只是“项目策划”和“集成软件管理”中的一个活动，而在CMMI中风险管理作为一个单独的过程域。
6、 CMM中的一个关键过程域“组间协调”IC在CMMI中地位下降，只是作为“集成化项目管理”IPM中的一个目标。
7、 CMM中的关键过程域“同行评审”PR，在CMMI中得到了更高的抽象；对应CMMI的“验证”VER，说明了对产品进行相应的QC活动。
（同行评审本身就是一种QC活动）8、 CMMI的共同特性中，没有了度量（ME），这些度量内容被组织起来形成了一个支持过程“度量和分析”。
具体理由如下：度量和分析本身应用的复杂性和它执行的高成本。
在原来的CMM中每个KPA均有单独的度量要求，容易造成“过度度量”，也没有形成对组织级的、统一的度量体系的指导和要求，造成实施中的困难。
例如在CMM中如果一个组织达到了CMM三级，由于各个KPA均要求了度量（ME），实际上已经建立了全组织过程的测量，这和CMM的等级划分思想是有着冲突的。
CMMI改进了这个方面，要求组织从组织级的统一要求出发建立度量体系。
这样的想法也符合过程改进理论的思想；这样组织在实施过程中可以选择必要的过程进行测量，而不是全部过程的测量，从这个意义上，CMMI比CMM降低了对度量的要求和实施难度，但是更加具有全局性和可实施性。
CMMI学写参考笔记范文
1、CMMI基本介绍1.1、起因和缘由工程环境和过程更加复杂，独立的CMM面对更加复杂化的要求不能适应了。
针对分段工作的弊端（重复返工），工作更加集成化，这样需要集成化的专业知识，也需要集成化的过程。
多种模型的衍生，造成了理解和培训上的困难。
同时多种衍生模型的实践提供了必要的信息和信心，可以建立这样集成的能力程度模型1.2、目标成本效益：减少理解和培训上的成本；改进模型：统一模型利于统筹进行分析和计划；避免封闭的过程改进：过程按照学科单独进行，没有顾及整体效益；交流：跨越部门学科的过程带来更多的交流，从而利于紧密的、有效的、精简的、继承的过程，对过程改进有全局效益统一模型的过程改进（不仅仅是软件过程能力）提供更大的适应性和扩充性，减少冲突和冗余1.3、CMMI框架结构的基本思想CMMI的框架结构基于对对过程和过程改进理论的深刻认识公共性的基础：项目管理和过程管理适用于任何学科如果进行适当的抽象，则工程过程可以直接应用于任何工程形式支持过程对不同学科提供不同的实现，但是目标和实践可以保持不变模型结构思路：根据信息的不同作用进行分类，划分为十二种构件整个模型由此十二种构件组成，并且具备一定的结构每个构件由一个或者多个资料组成整个模型汇编数了千个小的资料模型的不同表示法，就是通过构件的不同结构来体现模型结构的优点：模型由数千个小的资料组成，不同表示法共同使用这些资料这样来确保两种表示法的“等价性”模型通过十二种构件来组织，建立了一个公共的框架容纳未来的内容所有小资料均归属于不同得构件，模型的改进可以通过小资料的改进来实现2、CMMI的构件CMMI建立了一个自动、可扩展的框架，其中可以放入模型集成构件、培训资料、评估资料，确保在已定义规则下可以将更多学科加入该框架。
公共性是完全可以理解的，过程管理和项目管理可以应用于人和学科CMMI具有多个模型，每个模型通过汇编数千个小资料（构件），这些资料存放在数据库中便于统一引用。
CMM CMMI的探讨
SW-CMM/CMMI的探讨一、引言中国进入WTO后，软件企业的国际化进程也随之加快，CMM/CMMI认证在国内的软件企业相当流行，软件企业都希望借此改进研发的开发过程，随着一些大型软件企业完成CMM认证，也为相当多的中小软件企业带来了希望。
那么CMMI 相对于人们熟悉的SW-CMM 有些什么异同？其变化的原因是什么？SW-CMM 到CMMI 的过渡是势在必行的吗？针对这些问题，本文将SW-CMM 与CMMI 从多个方面和不同的层次进行了对比，剖析了其演变的原因，探讨了其发展前景，并对于企业从SW-CMM 到CMMI 的过渡提出了切实可行的建议。
二、CMM概述1．SW-CMM的产生和发展SW-CMM（Software Capability Maturity Model,下称CMM）是由美国卡内基·梅隆（Carnegie-Mellon University）的软件工程所（Software Engineering Institute，下称SEI）提出的一套对软件过程的管理、改进和评估的模式和方法。
CMM最早被应用于美国国防部，用于评估承接军事项目的软件企业的能力。
由于这些军事项目投资巨大，需要一种科学的评估办法对软件企业进行评审，这是CMM最早期的应用。
1991年，SEI正式提出了CMM1.0版本，并应用于商业软件行业中，取得了巨大的成功。
1993年，SEI根据以往的经验，并且广泛听取了行业专家的意见，推出了CMM1.1，这就是我们现在广泛使用的版本。
十几年来，CMM的改进工作一直在持续进行着，按照SEI的计划，CMM 重复级.0版本将于1997年推出，然后经讨论和修改，于1999年发布CMM2.0。
但此版本因为美国国防部的要求而推迟发布。
2．CMM的基本概念过程（Process）：为实现给定目标所执行的一系列操作步骤。
软件过程（Software Process）：指人们用于开发和维护软件及相关产品的一系列活动、方法、实践和革新。
CMMI体系介绍
CMMI体系介绍
质量控制中心：董宝国 2011年4月
大纲
1 行业背景
2 MMI前世今生 3 CMMI基本框架
4
CMMI过程改进成果与经验
5
CMMI改进规划
6
问题交流
一 行业背景
截止2009年末，世界CMM/CMMI认证企业数量
CMM/CMMI认证数量
882, 16% 1200, 22%
09年度
进度偏差 成本偏差
某公司实施CMMI3过程改进三年数据对比
7% 3%
10年度
四 CMMI 改进经验分享-最佳实践
1. 建立组织资产库
1. 体系文件库（项目规范及模板文件） 2. 度量数据库（公司执行历史项目的数据汇总分析） 3. 风险库（成功的和失败的风险教训） 4. 经验库（历史项目文档；优秀样例；培训教材库；知识库） 2. 项目分类管理 3. 项目管理过程可视化、数据化，拒绝“讲故事”，用数据说话。 4. 项目绩效考核 5. 挣值管理 6. 代码走查、原型+用例描述需求…………
三 CMMI基本框架
1. CMMI的表现形式 2. CMMI的成熟度等级 3. CMMI的架构介绍 4. CMMI的评估方法
三 CMMI基本框架－表现形式
CMMI的两种表现形式： 阶段式Staged：用成熟度级别 连续式Continuous：用能力级别
CMMI的两种级别： Capability levels：用于衡量每个过程域的过程改进 Maturity levels：用于衡量整个组织的过程能力和组织成熟度
四 CMMI 改进经验分享
成功项目4个要素
清晰预算 需求明确 进度要求 交付质量 采纳变更
第3章CMM的体系结构
第3章CMM的体系结构CMM（成熟度模型）是由美国国防部的软件工程研究所（SEI）开发的一种评估和改进软件开发组织能力的方法。
CMM采用五个不同的成熟度级别来评估一个软件开发组织的能力水平，以帮助其提高软件开发过程的质量和效率。
CMM的体系结构主要包括五个级别、过程领域和过程目标。
CMM的五个成熟度级别从最低到最高分别是：初始级、重复级、定义级、管理级和优化级。
每个级别都描述了一个软件开发组织在软件开发和管理上的不同水平。
初始级是指组织没有明确的过程，重复级是指组织已经开始重复使用一些成功的过程，定义级是指组织已经定义了一个标准的软件开发过程，管理级是指组织已经能够根据指标进行管理和持续改进，而优化级是指组织不断优化其软件开发过程以适应变化的需求。
CMM的过程领域是指软件开发过程中的六个关键领域，包括需求管理、项目计划和追踪、软件子系统实现、软件测试、集成与确认以及软件交付和维护。
这些领域是软件开发过程中最常见的问题和挑战，CMM通过评估每个领域的能力来指导组织改进其软件开发过程。
每个过程领域都有一组过程目标，这些目标描述了组织在该领域内所应遵循的最佳实践。
例如，在需求管理领域，过程目标包括了确保需求得到理解和文档化、确保需求的变更得到适当的管理和追踪、确保需求的验证等。
组织可以根据这些过程目标评估其软件开发过程的能力，并制定相应的改进计划。
CMM的体系结构使得软件开发组织能够系统地评估和改进其软件开发过程的能力。
通过逐步提高成熟度级别、改进过程领域和实现过程目标，组织可以逐渐提高软件开发的质量、效率和可靠性，从而提高业务竞争力。
虽然CMM在软件行业的影响力逐渐减弱，被一些更现代的方法和框架所取代，但其体系结构仍然具有指导意义。
例如，CMM的五个成熟度级别为其他评估模型（如CMMI）的发展提供了基础，CMM的过程领域和过程目标也为其他方法（如敏捷开发）提供了参考。
综上所述，CMM的体系结构包括五个成熟度级别、过程领域和过程目标。
基于CMM中需求管理活动的应用研究
ｗ ｅｐｏ ｏ ｏ ｓ ｍ ｒ’ ｑｉ ｍ ｎ ａ ｉ ｔ ｂ ｄｒｓ ｄｂ ｅｓｆ ａｅｐｏ ｃ．ｔｓ ｈ ａｉ ｆ ｌ ｎ ｇ ｒ ａ ｒ ｃｔ ｆ ｕｔ ｅｓ ｒ ｕｒ ｅｔ ｔ ｔ ｓｏ ｅａｄｅｓ ｙｔ ｏ ｒ ｒ ｅｔＩ ｉｔｅｂｓ ｒ ａ ｉ ｊ ｃ ｏ ｅ ｅ ｓｈ ｅ ｈ ｗ ｔ ｊ ｓｏ ｐ ｎ ｎ
Ｔ ｅ ｐ ｒ ｏ ｅ ｏ ｅ ｕ ｒｍｅ ｔ ｍａ ａ ｅ ｎ ｓ ｔ ｓａ ｌ ｈ ａ ｃ ｍｍｏ ｎ ｅ ｓａ ｄ ｎ ｅ ｗ ｅ ｕ ｔｍｅｓ ａ ｄ ｔ ｏｔ ｈ ｕ ｐ ｓ ｆｒ ｑ ｉ ｅ ｎｓ ｎ ｇ ｍｅ ｔｉ ｏ ｅ ｔ ｉ ｏ ｂ ｓ ｎ ｕ ｄ ｒ ｔ ｉ ｇ ｂ ｔ ｅ ｎ ｃ ｓｏ ｒ ｎ ｎ ｈｅｓ ｆ－
Ａｂ ｔａ ｔ ｏ ｏ ｎ ｈ ｔ ｄ ｃｉｎｏ ＭＭ ｎ ｗ ｅ ｇ ，ｈ ｒｃ ｓ ｓｃ ｍｉｇｔ ｈ ｔｇ ｆａ ｐｙｎ ＭＭ ｏ ｓｒ ｃ ：Ｆ Ｕ ｗｉｇｔｅｉ ｒ ｕ ｔ ｆＣ ｎ ｏ ｏ ｋ ｏ ｌｄ ｅ ｔｅ ｐｏ ｅｓｉ ｏ ｎ ｏｔｅｓａ ｅｏ ｐ ｌｉｇ Ｃ ｔ
了软件组织实施 Ｃ Ｍ需求管理中应改进的措施 ． Ｍ
关键词 ：Ｃ ＭＭ； 软件过程 ； 能力成熟度模型 ； 可重复级 ； 求管 理 需 中图分类 号：Ｔ ３ １５ Ｐ １． 文献标识码 ： Ａ 文章编号 ：０ ８２ ９ （０ ６ ０ ・０ ３０ １０ －３５ ２ ０ ）２０ ６ — ５
关键过程域 （ Ｐ ， Ｋ Ａ） 是在客户和解决客户需求 的软件项 目之 间建立对 客户需求 的共 同理解 ， 是计划 和管理
软件的基础． 在通过探讨需 求管理在 实践应用 中所要涉及 的任务 和如何实施的方法 ， 分析了软件组 织的 软
件过程现状 ， 提出了他们在实施需求管理关键 过程域 中存 在 的问题． 同时根据 Ｓ Ｉ Ｅ 制订 的 ＭＱ问卷 ， 探讨
CMM介绍与关键过程域说明
CMM介绍与关键过程域说明CMM（Capability Maturity Model）是一种用于管理和评估组织软件开发能力的框架，旨在帮助组织提高其软件开发过程的成熟度，从而提高软件质量和效率。
CMM通过一系列定义明确的关键过程域来描述一个成熟的软件开发组织的特征和实践。
以下是关于CMM和关键过程域的详细介绍。
CMM是由美国软件工程研究所（SEI）于1980年代末开发的。
它最初是为了衡量美国国防部软件供应商的能力而设计的。
CMM在软件工程领域的可行性和实用性被广泛认可，并在全球范围内被广泛采用。
CMM的主要目标是帮助组织改进其软件开发过程的效率和质量，并推动软件工程实践的采用。
CMM采用了一个阶梯式模型，包括五个不同的成熟度级别，从初始级别到最高级别分别是：初始级别、可重复级别、已定义级别、已管理级别和优化级别。
每个级别都有一组关键过程域，这些关键过程域是用于衡量和评估组织软件开发能力的基础。
下面是对每个成熟度级别和相关关键过程域的详细说明：1. 初始级别（Level 1 - Initial）在初始级别，组织的软件开发过程是不可预测的，不受控制的。
该级别缺乏组织和过程的可见性和管理。
没有明确的目标和计划，开发活动主要靠个别开发人员的技能和经验来完成。
2. 可重复级别（Level 2 - Repeatable）在可重复级别，组织开始建立一些基本的项目管理和过程管理能力。
关键过程域包括需求管理、配置管理、项目计划和追踪、软件质量保证等。
目标是确保软件开发过程的可重复性和可控性。
3. 已定义级别（Level 3 - Defined）在已定义级别，组织建立了一套标准化的软件开发过程，并且这些过程已经在组织范围内得到了共享和理解。
关键过程域包括需求开发、软件设计、软件构建、软件测试等。
目标是确保软件开发过程的一致性和稳定性。
4. 已管理级别（Level 4 - Managed）在已管理级别，组织通过定量的管理和度量，对软件开发过程进行管理和优化。
CMM(CMMI)基础知识介绍
第5级
◆ 特征 （1） 整个组织特别关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生，不 断地提高他们的过程处理能力。 （2） 加强定量分析，通过来自过程的质量反馈和吸收新观念，新科技，使软件过程不断地得到 改进。 （3） 根据软件过程的效果，进行成本 / 利润分析，从成功的软件过程中吸取经验，加以总结。 把最好的创新成绩迅速向全组织转移，对失败的案例，由软件过程小组进行分析以找出原因。 （4） 组织能找出过程的不足并预先改进，把失败的教训告知全组织以防止重复以前的错误。 （5） 对软件过程的评价和对标准软件过程的改进，都在全组织推广。 过程 不断地系统地改进软件过程。 理解并消除产生问题的公共根源，在任何一个系统中都可找到：由于随机变化造成重复工作、 进而导致时间浪费。为了防止浪费人力可能导致的系统变化，要消除“公共”的无效率根源”， 防止浪费发生。尽管所有级别都存在这些问题，但这是第5级的焦点。 ◆ 人员 整个组织都存在自觉的强烈的团队意识。 （2） 每个人都致力于过程改进，人们不再以达到里程碑式的成就而满足，而力求减少错误率。 ◆ 技术
CMM2级的关键过程域是8个，目标20个， 承诺9个，能力25个，活动62个，度量6个， 验证19个。
CMM等级及特点
12
CMM过程的可视性
5 输入
输出
4 输入
3 输入
2 输入 1 输入
13
输出 输出 输出 输出
1．6 CMM1．1的等级及其特征
第1级 ◆ 特征
（1） 软件过程的特点是杂乱无章，有时甚至是混乱，几乎没有定义过程 的规则或步骤。 （2） 过分的承诺。常作出良好的承诺：如“按照软件工程方式，有序的 工程步骤来做”；或达到高目标的许诺。实际上却出现一系列问题。 （3） 遇到危机就放弃院计划过程，反复编码和测试。 （4） 成功完全依赖个人努力和杰出的专业人才，取决于超常的管理人员 和杰出有效的软件开发人员。具体的表现和成果都源自于或者说决定于个 人的能力和他们先前的经验、知识以及他们的进取心和积极程度。 （5） 能力只是个人的特性，而不是开发组织的特性。依靠着个人的品质 或承受着巨大压力；或找窍门取得成果。但此类人一旦离去，组织的稳定 作用也随之消失。 （6） 软件过程是不可确定的和不可预见的。软件能力成熟度处于一级的 软件组织其软件过程在实际工作过程中经常被改变（过程是随意的）。这 类组织也在开发产品，但其成果是步稳定的，不可预见的不可重复的。也 就是说，软件的计划、预算、功能和产品的质量都是不可确定的和不可预 见的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：
市场营销
用户需求
管理层
需求开发
需求管理
市场
营销
管理层项目环境
项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理
在CMMI 中，需求管理的目标定义为：
a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：
软件需求的复用
需求管理的原则和方法
a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的
c. 只要需求变化了，需求变更的影响就必须被评估
d. 需求必须分优先级
e. 需求一定要分类管理
需求管理的主要工作：
特定目标和特定实践
特定目标
●管理需求
管理需求并识别需求与项目计划和工作产品之间的差
异。
●SP 1.1 取得需求理解
●SP 1.2 取得需求承诺
●SP 1.3 管理需求变更
●SP 1.4 维护需求的双向追溯性
●SP 1.5 识别项目工作与需求间的差异
REQM特定目标的关系
SP 1.1 取得需求理解
SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者
l 识别出需求的接受标准：
a. Clearly and properly stated得到清晰和恰当的定义
b. Complete完整的
c. Consistent with each other相互一致的
d. Uniquely identified得到唯一标识的
e. Appropriate to implement适宜实现
f. Verifiable (testable)可以验证（测试）
g. Traceable可追溯
l 分析需求，确保符合已建立的准则。
l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺
SP1.2 取得项目成员对需求的承诺。
●评估需求对现有承诺的影响。
需求变更或新需求发生时，评估它们对项目成员的影
响。
●协商并记录承诺。
在项目成员对需求或需求改变承诺之前，对现有承诺
的改变应先进行协商。
●承诺的时间点：
a. 需求刚建立时
b. 需求变更时
产出物
●需求影响评估
●需求和需求变更承诺的纪录
●项目组成员工作任务书
SP 1.3 管理需求变更
SP 1.3 当需求在项目执行期间逐渐开发时，管理
需求的变更。
●在项目执行期间，造成需求变更的原因很多：
a. 需要改变
b. 工作进行中产生新需求
●提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。
对项目
开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。
如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
配置变更委员会CCB
●CCB是授权进行正式基线变更的机构
✓例如客户需求、设计基线。
●职能：
✓确保变更被分类以及被评估
✓评审和批准变更
✓确保只有被批准的变更得到实施
✓决定需要实施的变更的优先级
●变更控制活动必须在整个项目中具有可视性
●CCB成员可能包括：项目经理，配置管理员，质量保证人员，开发人员代表，
客户代表。
需求变更的阶段
●提交
●评估
●审批
●实施
●验证
●关闭
产出物
●需求变更申请表
●需求变更汇总表
SP 1.4 维护需求的双向追溯性
●维护需求与项目计划和工作产品间的双向追溯性。
●产出物：
需求跟踪矩阵
需求跟踪矩阵的主要作用
RTM的作用
A、验证需求的可实现性、可测试性
B、进行需求变更的影响分析
C、维护阶段，管理需求的变更
需求跟踪矩阵分为：纵向跟踪和横向跟踪
应该建立哪些需求跟踪矩阵？
●在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM
SP1.4无法通过。
●对于纵向跟踪矩阵：
必需的：
✓客户需求与产品需求的跟踪
✓产品需求与测试用例的跟踪
✓100%的接口需求
✓全局性需求
✓核心需求
并非必需的：
✓性能需求
✓不影响系统架构的功能需求
需求跟踪矩阵由谁来建立？
●有多个角色参与建立RTM：
a. 需求开发人员
b. 设计人员
c. 测试用例的编写人员
d. PPQA
RTM是否纳入基线管理？
●RTM要纳入基线管理。
●纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一
起申请，很少单独申请变更RTM，除非RTM有错误。
●如何简化RTM的工作？
●由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所
以建立和维护RTM的工作量还是比较大、比较烦琐。
对于变化频繁的项目，更是如此。
在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通
过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……
等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：
r1-t1,r1-t2等等。
需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。
如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就
●是比较大。
要简化，就要平衡管理的投入与产出。
●当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样
RTM的作用就打了折扣，还是一个平衡问题。
SP1.5 确认项目工作和需求间的差异
主要活动：
●评审项目计划、活动和工作产品是否与需求和需求变更相符。
●识别差异来源及其理由。
●当需求基线有变动时，识别有关计划和工作产品所需的变更。
●启动纠正措施。
识别差距的时机？
●评审时
●变更时
●日常工作中
识别出的不一致问题要有记录，并跟踪问题的关闭需求管理我们需要客户方如何做。
●了解乙方需求变更流程，并与乙方就此流程达成一致
●指定专人负责需求变更
●内部形成一个需求变更流程
●针对内部提交的需求变更，在提交乙方之前横向分析对业务的影响
●在提交乙方之前，内部达成一致意见
●需求变更必将导致乙方开发成本增加，为保证项目成功，必要时追加合同资
金。