构造性成本模型

构建性成型模型（建设性成本模型）是一种算法成本模型，用于软件开发以估算成本和工作量。 在数学函数的帮助下，显示了某些软件指标与项目成本之间的联系。

几个公司特定的参数流入计算，这决定了实施一个软件项目需要多少人月或人年。 此外，可以估算项目的总持续时间。

• 模型的主要成本驱动因素是项目的交付源指令 (DSI)。
• 开发阶段从开始产品设计开始，到完成产品集成和验收测试结束。 其他阶段费用另行确定。
• 一个构造性形成本模型人月 - English Staff Month (SM) - 包括 152 个工作小时（19 个工作日，每个工作日 8 个工作小时），一个人年包括 12 个人月。 人月将假期和病假时间考虑在内。
• 构建性模型假设开发人员和客户都进行了良好的管理，并假设非生产时间保持在最低限度。
• 构建性模型假设需求规格说明在需求阶段之后没有发生任何根本性的变化。 规范中的重大更改还需要更改工作量估算。

KDSI中要交付的代码行数（1000（K）个交付的源代码指令）必须确定为计算的依据。 只有作为产品的一部分移交给客户的软件才称为已交付。 此定义不包括为支持软件或测试编写的代码。 这个大小的估计取决于很多因素（例如编程语言），并且不在结构生成本模型中。源指令对应于开发人员编写的可执行计算机指令。 除了注释之外，该定义还排除了生成的代码。 说明在很大程度上仍然基于当时常见的打孔卡。 这就是 Boehm 在他的作品中将指令定义为 Card Images 的方式。

然后，您必须决定是否要从事简单（“有机模式”）、中等难度（“半独立”）或复杂（“嵌入式”）项目。 这些项目模式是构造性成型模型81中的中心点，代表了不同工作领域中工作流程的差异。 项目模式的选择会显着影响计算结果——计算公式保持不变，只是系数发生变化。

有机模式对应于中小型软件项目。 参与该项目的大部分员工已经在该公司拥有丰富的类似项目经验以及所使用的软件和硬件。 这确保了较低的通信开销，因为相关人员已经对要创建的产品有了准确的想法。规范和接口没有严格记录，这意味着这方面的谈判可以更快地结束，并由此产生额外的努力（不经济规模）保持低成为。 有机模式的其他特点是稳定的开发环境，新技术很少，对新创新的需求最小，时间压力小。

半分离模式适用于规模和复杂性介于有机模式和嵌入式模式之间的项目。 这些是中型项目（50 到 300 KDSI），其参与者在此类系统的开发方面已经具有中等程度的经验，或者团队由经验丰富和缺乏经验的同事组成，或者团队仅在子领域有经验. 这种模式对应的项目更加复杂，需要更加完善的交互套路和灵活的接口。

嵌入式模式的特点是其紧凑、不灵活的结构和准则。 这也是和其他两种模式xxx的区别，更宽松的引导模式，主要针对安全相关的项目（如F飞行辅助系统、银行系统），因此在规范和接口的变化方面非常不灵活。 此外，嵌入式模式的项目通常是新开发的项目，以前的项目很少或没有可比性。 因此，这些项目的特点是它们从相对较长的分析和设计阶段开始。 这些阶段完成后，将指派尽可能多的开发人员并行实施和测试系统。 在这里，中间项目的测试工作已经与有机模式下的大型项目相对应。

然后，以人-月为单位的工作量 PM 计算为系数 m 乘以度量数的 n 次幂。

P M = m ⋅ K D S I n

简单：P M = 2.4 ⋅ K D S I 1.05

• 中间：P M = 3 .0 ⋅ K D S I 1 .12
• 复数：P M = 3.6 ⋅ K D S I 1.20
• 示例：在 100 KDSI 时，简单项目的人月约为下午 300 点，中级项目的人月约为下午 500 点，复杂项目的人月约为下午 900 点。

但是，不能为了更快地完成产品而将人月除以任意数量的人。 以带孩子足月为例子——这不能用九名妇女缩短到一个月。 某些流程必须按顺序进行，参与项目的人员越多，沟通方面的投入就越多。

构造性成型模型谈到 TDEV，开发时间。 然后根据复杂性类型计算开发时间 TDEV（以月为单位）：

• 简单：T D E V = 2.5 ⋅ P M 0.38
• 中间：T D E V = 2.5 ⋅ P M 0.35
• 复数：T D E V = 2.5 ⋅ P M 0.32
• 对于具有 100 KDSI 的简单项目，构造性模型估算得出 PM = 302 个月，TDEV = 21.9 个月。

• 对于具有 100 KDSI 的中型项目，构造性能模型估计提供 PM = 521 个月和 TDEV = 22.3 个月。
• 对于具有 100 KDSI 的复杂项目，构造性模型估算得出 PM = 904 个月和 TDEV = 22.1 个月。

在TDEV的构建性模型计算中，最短持续时间为八个月。

扩展的结构生成本模型方法（中间结构生成本模型）考虑了其他所谓的成本驱动因素，这些因素会减少或增加计算的基值。 这些都是基于在大公司中衡量过的许多经验。 这些因素包括：

• 所交付系统的可靠性 - 错误只是小事还是会危及人身安全？
• 需要创建的数据库有多大？
• I/O 处理和数据结构有多复杂？
• 系统交付结果需要多快？
• 系统需要多少内存？
• 您预计系统必须多久调整一次以适应外部框架条件？ 这里的范围从每年一次到每月一次不等。
• 团队因素 - 团队成员在分析、使用的编程语言、软件工具和特定硬件方面有哪些经验？
• 时间安排有多紧？

以下计算作为这些因素对结果影响程度的示例：

复数，128 KDSI，对应1216 PM（根据构造性形成本模型计算）。

解释：将各个因素相乘形成“总因素”，再乘以基础努力值。公式：调整值=基础值*（可靠性*复杂性*存储要求*工具使用*进度）

然而，这些数值只是粗略的经验值，每个公司都必须通过监控成本和分析以前的项目来确定自己的因素。