实践中的增量计划
未经允许，严禁转载本栏目内容
本文经许可转载自软件工程专家网www.21cmm.com，
未经CSDN许可，请勿随便转载，谢谢合作[url=http://www.21cmm.com/prelogin.asp?page=/bbs/index.asp?Type=D][/url]
随着系统新的增量在原增量已实现了的函数的基础上的精心设计，整体目标和约束上的增量式开发将逐步成长为系统。这就是说，一个增量中新的函数将插入预先定义结构的早期增量，而且应满足需求一致的子规范。这种函数分配过程是引用透明性在增量式开发计划中的实际应用。因此，对增量函数的逻辑分配是基于函数间的相互关系，本身函数从属性将依赖增量内容的定义。例如，在数据库系统中，增加数据的函数通常先于删除数据的函数。在统计系统中，悼念和输入的函数通常先于分析数据和报告结果的函数。
在一个函数依赖的系统框架项目中，大规模的管理和技术因素同样影响增量计划。
用户需求
用户希望某些系统功能在系统完成之前能够操作使用，这些功能一般安排在早期的增量计划中。
明确需求
迭代开发方法背后的共同的动机是基于这样的事实：在项目的开始，需求很少能确切地建立。利用增量式开发，用户通过对可执行增量的直接操作，提供一个待扩展系统的反馈，相对清晰的需求以两种方式影响增量计划。易变的需求实现于早期的增量，这样容易澄清。另一种方式，当影响需求的问题确定下来后，不稳定需求可能计划为稍后实现。例如，如果用户接口没有较好地建立，这种方法是早期增量的理想选择(有人会说，用户接口总是系统中最易变的，应该在早期增量中实现)。另一方面，通过一致的研究决定的需求或许安排在后期增量中。
操作使用概率
功能使用分布是顶层净室软件规范的一部分。系统功能期望的使用概率是由历史数据和用户估计提供建立的。期望使用概率高的系统功能在系统中得到普遍地使用，因此对测试有益。由于增量是逐步累积的，早期增量中设计的功能，在新的增量进入测试过程时，每次都需测试。因此，期望得到用户的频繁使用的系统功能应计划在早期增量中，低使用率的一些功能或许认为是可选的，如果时间允许，应计划在最后增量中实现。
可靠性管理
渐渐地，客房关注形式化的软件可靠性需求。Poore、Mills和Mutchler(1993)描述了基于高层设计的子系统可靠性需求的增量式计划的途径。给定一个整修系统可靠性需求和子系统间的转移概率，每个子系统的可靠性需求将被计算出来。高可靠性需求的子系统对整个系统的可靠性影响很大，应计划在早期的增量中。
系统工程
控制迭代在硬件设计中是一个关键的工程理论。最小机器通常在最早迭代中构造出，然后重复迭代直到完整机器被制造出为止，软件的增量式开发完全与标准硬件设计途径一样。嵌入软件的机器必须在硬件工程师和软件工程师间协调一致地工作，增量式开发是这种协调的理想构架。例如，机器在使用前必须通电。因此，系统启动软件应在嵌入式软件项目的早期增量函数中实现。
技术挑战
新颖的或特别复杂的组件或许对进度是一种冒险，甚至是对项目生存能力的一种冒险。如果这种工作安排在早期的增量中，这种实践将支持已存在的计划或者建议去修改计划。如果不仅项目本身是新颖复杂的，其复杂性体现在小组的实践中，那么应该对小组的工作和进度灵活性尽早做出评估。
重用的影响与作用
净室过程强调其经济性是通过项目中组件的重用来体现的，并在系统中设计可多处使用的“共同服务”组件。当已存在的组件标识为潜在可重用时，要在新系统中为使用而剪裁、删节、开发新组件，开发小组必须评估其相对效果。如果评估赞成重用，小组希望在早期的增量中包含这些组件，证实他们所期望的性能。新的“共同服务”组件同样期望安排在早期的增量中。因为“共同服务”组件在系统中多处使用，它们相对其他单个固定组件对系统的可靠性影响更大。因为已存在的对象或许是可重用组件，在增量开发计划中对象开发合理性通常与组件可重用的合理性相一致。
