北京软件外包公司用于评估软件出价模型的框架

北京软件外包公司评估软件出价通用与专用模型的问题对于我们的评估框架很重要，因为评估活动明显地受到正在验证的项目的影响。因此，我们借此机会解释差异。图1所示的通用模型。1是一个简化和理想化的模型。它不包括特定组织可能认为影响价格的所有因素。例如，在一些组织中，一些客户被给予优惠条款（可能被模拟为影响利润水平的因素），但是我们没有在我们的通用模型中包含这样一个因素。此外，为了简单起见，我们假设我们有一个单一的应急分配（总结如果项目遇到计划外问题所需的成本）与需要应急资金的概率相关联。然而，在实践中，应急评估可能要复杂得多：

一家公司可能会识别出各自具有其发生概率的不同应急风险。在这种情况下，必须分别评估每种风险的应急（即预期损失）。

一些应急风险是持续时间相关的，而不是与成本相关的。在这种情况下，持续时间滑差必须根据客户定义的惩罚结构转换为成本。•如果应急风险与成本相关，成本是由于额外的工作人员努力的结果，这也可能导致运输延误和额外的罚金。

因此，专门的模型需要比我们的通用模型更详细地模拟应急。

应该注意的是，通用模型和任何专用模型都可以（并且应该）被实现为参数化模型。对于参数化模型，输入值表示为变量，可根据需要进行更改。

.其他评估程序

在本节中，我们描述了与投标模式有一些相关性的两种实用评估方法。使用一种方法（涉及几个不同的程序）来评估软件度量程序。软件度量程序提供有关软件开发过程的信息。他们难以评估，因为他们没有明确的经济利益。它们类似于我们的招标模式，意在允许管理人员改进其相关软件流程的管理和控制。他们还需要软件工程师和管理人员不广泛的测量和数据分析知识。

另一种方法用于评估软件开发的系统动力学模型。系统动力学模型是具有许多相关元素的系统模型，其中模型元素之间存在反馈链接。实质上，它们是时间依赖的影响图模型，允许模型元素之间的循环关系。像我们的招标模式一样，模型中包含的要素通常基于专家意见。

软件测量程序评估

北京软件外包公司研究了评估软件测量方案的问题。最初，Berry开发了一种在组织和外部环境方面对指标计划进行评估的工具[2]  。  [7]。最近他考虑了评估测量计划与利益相关者之间关系 的问题[3]。他设计了一个焦点小组的基于网络的调查问卷，在这个焦点小组中，有一些利益相关方被要求在支持能力成熟度模型（CMM）关键流程区域（KPA）“项目跟踪和监督”的背景下，对指标计划做出主张， 。由此产生的调查问卷已经提供给指标计划用户，当他们的答案分析时，Berry和Vanderbroek能够识别和排列多个流程改进机会。在随后的一篇论文中，Berry和Vanderbroek [4]对其评估过程进行了评估。

最近的论文提出了招标模型评估的两个重要问题：

1。与目标评估类似的过程可能是评估模型用户对专业出价模型绩效观点的可能机制。

2。本身应该评估任何评估过程。因此，我们需要准备评估我们评估我们的通用投标模式的方式。

系统动力学模型评估

讨论了使用系统动力学模型来模拟软件开发。他们的初始模型是基于五个不同软件组织的项目经理的实地研究。根据文献综述，初步模型得到了改进。然后，在三个组织的软件项目经理进行了一系列密集的访谈后，对修订后的模型进行了评估和评估（其中只有一个对初始模型作出了贡献）。因此，他们的软件开发模式是一个专家意见模型。此外，它是一个半专业模式，因为Abdel-Hamid和Madnick说“我们目前的成果仅限于遵循传统瀑布生命周期的项目”。

北京软件外包公司的模式与我们的招标模式有一些相似之处。它是一个以专家意见为基础的模型，被表示为影响图。但是，它有一些主要的区别。该模型比我们的招标模式复杂得多（“包含一百个因果关系”）。此外，链接比招标模式中的链接复杂得多。该模型具有可以与项目中使用的值进行比较的各种数值输出（例如，人工日的项目成本估计）。这意味着该模型提供了可以与项目实际相比较的输出。

北京软件外包公司使用以下评估程序：

1。确定面部有效性。这涉及向项目经理介绍模型，并确认他们认为该模型是对软件项目动态的准确表示。

2。确认模型准确复制参考模式。他们检查了该模型复制了各种参考模型的行为（例如90％完整综合征）。

3。在极端条件下调查模型行为。他们检查了该模型在极端条件或极端政策下是否合理。

4。进行案例研究。他们模拟了一个不参与模型开发的组织进行的项目。他们确认模型产出与实际项目措施接近。

这个评估过程与我们设想的评估过程有一些相似之处（第3节）。步骤1类似于确认模型满足其要求，但不具有北京软件外包公司的评估的严格性[3]。步骤2相当于根据定义的出价方案检查出价模式。步骤3对于我们的模型是不必要的，因为它是一个更简单的模型，不涉及可能破坏价值观的反馈机制，也不对可能接近零或无穷大的变量进行分析。步骤4与我们的模型无关，因为我们的模型没有提供可以与实际值进行比较的输出。

局限性

这两个评估过程的主要限制是没有可以判断个人评估的外部参考模型或理想的评估过程。因此，不可能决定评估活动是否足够。因此，我们意识到我们需要制定一个评估框架，以便有一些客观的方法来决定需要哪些评估行动来正确评估我们的模型。在第5节中，我们考虑两个可能的评估框架，并将其扩展到为我们的招标模式提供评估框架。

5.模型评估框架

在本节中，我们描述了两个可能与评估软件出价模型问题相关的评估框架：

1。北京软件外包公司模型评估标准（[5]，第28章）。这是适用于评估成本模型的标准列表。虽然我们已经指出，我们的模式与成本模型不一样，但是我们的一些勃姆斯标准可能适合我们的投标模式。

2。北京软件外包公司了解概念模型质量的框架。虽然他们主要关注需求模型，但我们的投标模式可以被认为是概念模型的形式。主要区别是需求模型是软件开发周期的一个阶段，而我们的投标模式是我们模型开发过程的终点。

北京软件公司确定了一个标准清单，他建议将“有助于评估软件成本模型对实际估计目的的效用”。这些标准及其说明如表所示。