外包项目测试工作量评估指南(转)

1、目的

编写本指导书的目的旨在为我公司进行测试外包服务工作进行指导，帮助项目经理和相关人员编写测试方案、评估工作量、制定测试计划和测试策略等，以尽量减小项目工作量评估上的风险。

2、适用范围和对象

本指南的使用范围是对于测试外包服务项目前期做整体的测试方案时，需要对工作量进行评估的项目经理、测试专家参考的文档。

3、工作量评估原则

一个特定项目需要的工作量依赖于很多变量。包括：组织文化或者组织的“测试程度度”、被测试项目的软件复杂度、需要测试的范围、执行测试的个体的技能水平以及承担测试工作的测试组织的类型。不过，就算给出影响工作量的变量也不能真正反映出实际付出的工作量，因为每个项目都是不同的。

对于测试项目评估，在评估工作量时，从下面几点进行把握：

1、工作量评估是建立在商务沟通的基础之上的，客户比我们更了解系统；

2、工作量评估采用的任何方法都只是一个估计，所以风险因素是要考虑的；

3、工作量评估必须经过领导、专家组组成的小组的评审。

4、外包测试项目

根据外包测试项目主要有两种方式，一种是on-site，称为离岸外包，另一种是off-site是在公司内部做。不管是以那种方式，都需要对工作量进行全面的评估，而对于人力外包的项目则不需要工作量评估。由于IT系统项目实施是智力型密级行业，到目前为止，还没有一套科学有效、准确的评估方法，尤其是对于我们还不熟悉的行业，所以我们根据搜集到的资料以及我们的项目经验，整理出本文的几种方法，作为参考。

5、几种方法的对比

6、开发比例法

这个方法的基本前提是测试工作量依赖于开发周期/开发工作量。不管开发团队依据何种方式评估研发的工作量，我们测试团队可以根据研发团队的研发周期，确定大致的测试工作量。

通过下面的方式获得开发周期/开发工作量：

A. 通过商务沟通或技术沟通获得研发的进度表或研发周期；

B. 获得客户计划的整个项目的时间；

C. 根据研发工作量通过参考下面的表格估计工作量。

在评估需要的工作量以及相应的人员配置时，也要参考一下研发人员和测试人员的比例，如果测试团队在项目需求阶段就进入，则通过3：2、3：1等这样的比例估计需要投入的测试人员，这个比例没有一

定的约束，主要根据系统对错误的容忍度，例如，医疗设备系统或飞机控制系统不能容忍错误，而银行涉及到重大财产安全则应该也不能容忍大的错误存在。评估时，这也是需要考虑的一个方面。

注：灰色背景表示不进行测试测试。

如果公司没有被评估项目所属的行业的项目经验，则应该在所占百分比基础上增加5%~10%的风险工作量。

上面表格中前三行我们所做的系统验收测试活动为辅助验收测试活动，即有辅助客户完成验收测试。而后面只有两行则验收测试则可以作为一个独立的测试，客户参与人员很少，所以需要更多的工作量，可以根据客户的实际情况进行相应调整。

7、项目经验类比法

根据公司以前所做的相似项目，主要在项目性质，领域，规模上考虑，所积累的经验或历史数据来估算工作量。项目经验类比法估计结果的精确度取决于对历史项目我们所收集数据的完整性和准确度。因此，项目经验类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

主要从下面几个方面借鉴原项目情况：

1、项目所属的行业。不同的行业，在类比时要考虑差异性。有无行业经验是需要考虑的。该考虑要体现在工作量中，但是不能体现方案中。

2、项目的架构、规模、包括研发、测试工作量、代码行数等。这些数据对于评估可参考性比较强，注意项目实施中这些数据的收集。逐渐提高测试中的数据统计，提高我们测试能力的成熟度。

3、用户需求的数量。这个通过对比用户需求，大致估计系统特点、功能复杂程度，有无新技术应用等，这些数据可用于对比。

4、开展的测试活动。注意在原项目所进行的测试活动，与当前项目所进行的测试活动，再借鉴上面开发时间百分比法。

5、当时有无项目经验。原项目是否是新开拓的领域，则当时付出的工作量肯定会多一些，当前项目与原项目为同一个行业领域，则会减少一些工作量。

6、参与人员的情况。当前可参加到项目组人员情况与原项目人员情况进行对比。测试工程师以及业务分析师的项目经验是需要考虑的因素之一。

7、客户的情况，例如对系统质量要求、重视的程度。客户如果对质量很重视，实施质量管理规范，则可能对研发团队要求也高，这样系统交付质量可能会高一些；

8、项目系统使用对象。项目使用对象是需要考虑的，例如使用者对计算机的熟悉程度。系统是客户内部使用，还是面对Internet用户，这样对系统的安全性要求程度不同。

9、研发公司的情况。研发公司是否为知名公司，其研发能力的成熟度会高一些，对项目质量要求也可能高一些。该公司在行业中的做系统的名誉、口碑如何，也可以参考。

评估流程可参考如下：

1、在公司知识库中搜索相似项目，获得相似项目的信息；

2、把当前项目与相似项目进行对比，找出差异性，可参考上面对比数据；

3、对差异性进行分析，找出当前项目的特点；

4、对当前项目进行评估，没有的测试阶段评估方法可参考其他的评估方法；

5、最后统计出总的工作量，请相关的领导、项目经理、测试专家参与讨论，确定下最后的工作量。

8、WBS法

WBS（work breakdown structure）估算法。将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和统计得出项目或产品的测试工作量。

在工作拆分的原则应该是尽量把工作拆分为可以用小时或人/日度量、可以安排给一个测试工程师完成、且可以有交付物的工作。

在评估时，可以参考一下研发规模。例如代码行数（LOC）、等价的代码行数、功能点。

在评估中根据我们需要进行的测试活动，把每个测试活动进行拆分，同时把测试需求、测试用例、测试用例执行、轮次、缺陷修复等都进行拆分，评估每个活动需要的工作量。

这种评估的输入是需要客户的需求规格说明书的，且需要该文档描述用户需求比较详尽、全面，才能比较准确的评估所需要的工作量。对需求规格说明书中的功能需求和非功能需求进行分解，可以通过一条或多条测试需求来描述。

单元测试结果审核评估流程：

1、如果有系统详细设计说明书，则依据详细说明书中划分的模块，来计算划分的单元模块数量；如果没有该文档，是否可通过其他文档估算单元模块的数量；

2、确定单元测试审核中每个活动的工作量，例如，文档审核、测试用例审核，测试结果审查、缺陷报告审查、如果需要单元抽测，则需要单独计算工作量。

表2：单元测试结果审核评估表

产品集成测试评估流程：

1、把整个系统分解成子系统，确定每个子系统的接口数量。对于如何确定接口，主要根据子系统是否与其他子系统存在输入/输出数据而确定。

2、对每两个子系统之间有接口的子系统进行评估，需要构造多少测试用例覆盖接口，也要考虑接口之间的测试方案，如何构造测试数据，如何满足集成测试环境等。

3、需要考虑整个集成测试的所用的工作量，可以参考上面集成测试大约占整个测试的工作量的比例。

表3：集成测试工作量评估表

系统功能测试评估流程：

1、把整个系统中的各子系统分解成功能点，在各功能点上确定操作数量，确定功能点的口径，例如把下一个订单做一笔交易，做一次交易历史数据的查询作为一个功能点，即功能点应该是系统中独立的能够实现某个具体功能的一系列操作。在具体功能点中时，需要考虑功能点对应的操作数量，例如交易类型、查询中的升序、降序，都视作一个操作。把功能点和操作数量累计出来，形成一个功能点的需求数。

2、统计出所有的需求点后为整个系统中的功能需求总数。再考虑测试中具体的方案的工作量，是否考虑自动化测试、是否需要构造大量基础数据等。

3、需要考虑整个系统功能测试所用的工作量，可以参考上面系统测试大约占整个测试的工作量的比例。

表4：系统功能测试评估表

系统性能测试评估流程：

1、把整个系统中的性能需求点整理出来，注意我们性能测试包括的范围是功能测试之外的所有测试活动；

2、评估每个性能点需要的工时，形成整个系统性能测试的总工时。

表5：系统性能测试评估表

UAT测试评估流程：

1、在商务沟通阶段，尽量获得客户对UAT的期望，由客户来实施，还是我们协助来实施UAT测试；

2、根据客户希望我们测试团队所做的工作，确定大致的工作量。一般应该是我们协助进行UAT测试，大概需要几位测试工程师进行支持即可。根据客户期望的UAT时间，来确定我们测试团队所付出的工作量。

9、Delphi法

Delphi法是最流行的专家评估技术，在没有历史项目数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。

Delphi法的评估步骤是：

1、项目协调人向各测试专家和项目经理介绍项目规格和估计表格；

2、项目协调人召集小组会，各测试专家和项目经理讨论与规模相关的因素；

3、各测试专家匿名填写迭代表格；

4、项目协调人整理出一个估计总结，以迭代表的形式返回测试专家；

5、项目协调人召集小组会，讨论较大的估计差异；

6、测试专家复查估计总结并在迭代表上提交另一个匿名估计；

7、重复4-6，直到达到一个最低和最高估计的基本一致。

注:本文转自网络, https://www.wendangku.net/doc/983327750.html,/html/54/n-75154.html

软件项目风险评估报告

本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。 主要风险综述 任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。 软件管理将影响到软件的下列因素： 软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。 软件体系结构影响到软件的如下质量因素： 软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。 软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。 软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜

外包管理评估表格模板

1目的 明确本公司的外包过程及其控制方法，通过对外包过程的有效控制，使开发出的系统满足规定的要求。 2适用范围 本文件适用于系统的外包开发。 3职责及权限 1）项目经理负责对系统开发供方（外包方）的调查、评定和选择。 2）项目经理提出外包要求，并组织对外包要求的审核，确定后纳入外包合同。 3） 4 4.1 1） 等 2）由项目经理组织质量控制部、研发部对系统开发供方的质量管理体系、技术水平进行审核，并提出质量审核报告。 4.2合格系统开发供方的选择 1）项目经理提供《系统开发供方调查表》、质量审核报告及有关证明资料，组织有关人员或部门，对系统开发供方进行评定和选择。评定和选择依据是系统开发供方系统开发的能力，包括：开发经验、人员结构、设备资源、技术水平、质量保证能力、顾客满意程度等。 2）根据参加人员的评审意见，由项目经理填写《系统开发供方评定表》，参加者会签。 3）项目经理负责拟制《合格系统开发供方名单》，报主管VP审批。

4）《合格系统开发供方名单》是本公司选择系统开发供方的依据，经批准的《合格系统开发供方名单》为受控文件，由项目配置管理员负责发放并归档管理。 4.3合格系统开发供方的调整 4.3.1重新评定的时机 1）每个外包项目完成时都要对外包系统开发供方进行重新评定。 2）超过一年未合作的合格系统开发供方，有外包项目前重新评定审批。 4.3.2重新评定的方法 1） 《合 2）对一年内无外包项目的合格系统开发供方，当再次合作前，要重新对其进行调查评定审批，评定方法同上文，侧重于对供方调查资料有效性的跟踪和判定。 5外包过程控制 5.1外包项目过程控制 由项目经理按照外包合同的规定，对外包项目过程进行控制。 5.2外包系统验收 由项目经理按照外包合同规定的接收准则和方法，对外包系统进行验收，验收合格后由项目配

工作量评估方法完整版.完整版.docx

关于工作量评估方法 为能清楚阐明论点。先举两个例子。 大家一定都听说过“龟兔赛跑”的故事，故事里乌龟是正面人物，而兔子作为反面人物受人讥讽，其中的寓意教育人们做事要像乌龟一样有坚忍不拔的精神。如果换个角度分析这个故事。则会有不同的结论。兔子在整个赛跑过程中做了两件事，那就是赛跑和睡觉；乌龟则仅做了一件事，就是不停地赛跑。如果我们试把时间延长（即看看它们在赛后又做了什么），可以想象乌龟由于比赛的疲劳，而跑回家呼呼大睡了；兔子呢？由于比赛中同时也保养了精神，赛后可以做其它更多自己想做的事。由此，不难得出整个过程兔子的效率更高。另外，乌龟并不擅长跑步，却安排它去参加这场比赛，其效率必然极低，把这种现象映射到企业管理中去，也颇发人深思。 试看一个说明工作效率与工作饱和相矛盾的例子：某工厂的一位计算机技术人员，现场发生了微机故障，从他的办公室到达故障点的方式有两种选择，其一是步行，需要10分钟；其二是骑自行车，只需2分钟。我们设步行到现场的为甲，骑车到现场的为乙，最后统计：两人去处理同样的一个工作，甲用了30分钟，而乙只用了15分钟，（这里是假设两人故障的修复时间相同，但事实上甲这类人在故障修复中要花更多的时间）。乙在剩下的15分钟又可以做其它更多的事情，单从这点出发，甲与乙在工作成效上就不仅是1：2的差距了，而是1：N（即甲做一件事的时间，乙做了N件事）的差距。但在现实中，甲往往成了“工作量饱满、劳动模范”的象征；而乙却常常恰好相反，这是管理人员认识上的一大误区，长此下去必然带来管理上的一系列问题。 工作效率由员工的自身因素决定，但如何激励员工提高工作效率，目前仍是管理上的问题。首先是工作分配的合理化，它直接影响工作的效率，让乌龟去赛跑，显然是不合理，所以对工作的合理分配是提高效率的首要条件，这与管理人员的工作密不可分，要求管理人员不仅清楚了解管辖范围内的工作内容，而且要对被管理人的基本情况有清楚的认识。 工作分配合理后，那如何主动去提高每个员工的工作效率呢？竞争是个好方法，奖惩也是个好方法，另一种就是让员工自身有好的素质，拥有正确的人生观及世界观，提高效率便成为很自然的事。前两种方法是被动的，也是目前企业管理中普遍采用的方法，而第三种方法突出了“人自身的因素，希望通过发挥主观能动性来提高工作效率。因为当一个人具有一定知识水平（包括综合知识和技能知识），拥有正确的人生观及世界观，那么我们说，从主观上他会自觉主动地提高效率，从效率中求饱和，再从饱和中追求效率。这样看来采用这种方法，不仅仅能提高效率，而且同时无形中也解决了效率与饱和间的矛盾。 由此可见，通过主观能动性来提高效率，关键就是如何提高员工的综合素质问题，这个素质并非仅仅指的员工的技术知识水平，更重要的还包含道德修养、情操和理想等一些深层次东西。目前企业对员工的素质教育，仅仅是偏重于技能知识的教育，认为员工只要有好的技术和熟练的操作，便有了效率，这是远远不够的。因此，素质的提高在于两方面：①个人专业技能及社会知识要丰富，这是效率的基本前提；②同时应丰富其它的各类知识，如自然知识及人文知识等等。企业管理中在对提高员工素质方面应该投人更多，这样可以更快的从被动地提高工作效率转变为主动地提高工作效率。 以上谈了工作效率问题。现在再来看看工作量问题。评价一个人工作饱和度高不高（注意这里是针对同一个工作），答案就只有两种：低效率饱和度高；高效率饱和度低。可见效率与饱和度存在着矛盾。而“工作饱和”的含义应该是指员工的有效工作时间与规定的劳动时间相等或近似相等，这里的工作时问是指有效的工作时间，强调“有效”二字，“有效”就包含效率和成效的意思。这又体现了效率与饱和度有统一的一面。而在现实的管理工作中，管理人员常常忽略“有效”的重要性，虽然这种“忽略”往往并不是有意的，自然也就无法正确评价如何才算是工作饱和，于是便出现了“整天忙个不停的员工就一定是个好员工”的谬论。所以如何科学地去看待工作饱和度其实也是管理上的问题，它要求管理人员自身具有好的素质及高的效率，这样才谈得上被管理的人有好的素质及高的效率。

工作量考核方案

工作量考核方案 工 作 量 考 核 方 案 （拟定稿） 说明: 一.本包括考核制度和考核量表两部分。. 二.考核量表主要是测评教务处学生助理员的绩效，同时作为教 务处学生助理工作组工资发放的参考依据。 三.附考核流程图如下: 四、本制度每学期期末考试周前接受所有老师和教助意见并及时完 善，制度完善并施行前应专门召开集体会议，公开解释制度具体细节的构建理由和含义。最终解释权归教务处学生助理工作量评估小组。 五、本制度提交华中师范大学教务处学生助理工作组备案。

教务处学生助理考核制度 第一章 第一条总则考核的目的是通过客观评价教务助理的工作能力、态度，优化教务 处助理队伍，并客观合理地安置教务助理，做到人岗匹配，并以考 核结果为参考，发放教助的年终薪酬。 第二条本规定中使用的专业术语定义如下： (一)能力考核---------通过工作行为，观察、分析、评价教助具有的工作能力。 (二)态度考核---------通过对教助的工作努力情况和工作热情进行观察和评 价。 (三)业绩考核---------对教助分担的工作完成情况进行观察、分析和评价。(四)360度考核法----即全视角绩效考核法，通过不同的考核者（老师、同学、 其他教助等）从不同的角度来全方位考核教助工作情况。 (五)KPI法------------即关键业绩指标，选取一些关键的、与教助队伍目标实 现关系比较紧密的工作内容作为考核项目。 (六)考核者-------------老师、同学以及其他教助。 (七)被考核者----------2007－2008学年度教务助理。

(八)考核执行者--------教务助理工作组。 第三条考核原则 (一)考核标准尽可能量化； (二)考核标准的制定以教助管理条例为依据，按照教务 处的标准制定。 第四条每位教务助理一学期工资标准在400元左右浮动，教务助理最后所 得工资根据考评结果而定。 第五条考核方法是360度考核法,由教务助理所在办公室老师,其他办公室 教助（即同事）共同参与，实行打分制，考核表由教务助理所在办公室老师填写，同时参考其他办公室教助（即同事）意见，运用KPI法确定绩效考核标准。 第二章考核流程与实施 第一条教务助理工作组开会讨论确定最终考核制度； 第二条由教助工作量评估小组整理制度材料，交给教务 助理工作组审核， 最后上交教务助理管理老师审批； 第三条制度执行，由各办公室老师对本办公室教助进行 考核； 第四条由教助工作量评估小组进行汇总，按分数列出等级，确定薪酬；

项目风险评估报告

项目风险评估报告 第一章项目概况 一、项目建设单位概况。 *****项目是由 ***** 投资的新建项目，项目地点位于 ***** 。二、项目概况本项目工程的建设规模为 *******, 属新建项目。 **装置包括： **** 区、 ** 主车间、 ** 罐区、 ** 灌装、 ** 灌装；锅炉房规模为 **** 蒸汽锅炉；生活辅助设施包括：综合楼、宿舍楼、 ****、围墙及大门；生产辅助设施包括： *** 区、辅材库、备件库（含 ***库）、化学品库、机修间、循环水站、一次水池及堆场（煤堆场、灰渣堆场、**** 场等）；厂区工程包括：厂区工艺及热力外管、厂 区供电、照明及避雷、厂区给排水及消防管网。 初步设计已经批准。 第二章评估对象及目标 本项目风险评估的对象为******* 项目可能出现的经济、管理、 安全、环境等各方面风险。通过风险评估，确定风险等级，并针对各 风险因素（事件）编制应急预案，将各类风险降低到可以接受的水平。 第三章风险评估程序和评估方法 1.风险评估程序 根据已经批准的本项目的初步设计、公司规章制度、相似工程的 风险评估文件等相关要求，结合项目所在地的实际情况，确定本项目风险评估程序为： ◢1◣

（1）对项目初始风险进行评价，分别确定各风险因素和安全风险发生的 概率和损失值。 （2）分析各风险因素的影响程度，确定主要风险因素对施工安全和施工 成本的影响。 （3）根据评价结果制定相应的管理方案或措施。 2、风险评估方法 以集团批准的初步设计为主线，综合运用风险层次分析法、图表 法、模糊综合评估法等方法。 3、风险管理领导小组及工作职责 根据本项目工程特点，结合公司管理经验，成立专门的风险管理 领导小级。 （1）领导小组组 长： *** 副组长： ***** 组成员如下： *********** 。 （2）职责分工 组长：负责风险评估与管理工作的领导工作。制定各个施工阶段 风险评估工作实施细则。 副组长：根据组长制定的实施细则开展管理工作，并向组长负责。落实风险评估、风险监督管理、风险措施落实等。

软件工作量评估报告

XXXX软件成本评估 1. 概述 我们认真地阅读了软件的用户指南，与XXXX电脑部有关技术人员进行了深入的交流，并查看了软件的操作界面。在此基础上，我们对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。 2. 编码工作量估算 本次评估的软件有两个，分别是《X软赠券电脑发放管理系统》和《X软联销资源管理系统》。为了更准确的估算出软件的工作量，我们对每一个软件功能模块所需工作量给出了三个估计值，分别是：1）悲观工作量（Epi）：这是一个最保守的估计，可能在编程人员技术不熟练，对业务理解不够，或有其他影响其正常工作的因素存在的情况上发生。 2）正常工作量（Eni）：这是一个正常的程序员可能付出的工作量估计。 3）乐观工作量（Esi）：这种情况可能在程序员技术相当熟练，对业务相当了解，且以前可能有类似项目开发经验的情况下所需的工作量。

针对每一项功能模块，其最终的工作量估算值按以下公式计算：Ei = （Epi + 4 × Eni + Esi）/ 6 下面的表1是对X软赠券电脑发放管理系统的编码阶段的工作量估算，表2是对X软联销资源管理系统的编码阶段的工作量估算。 表1：X软赠券电脑发放管理系统的编码阶段工作量清单 表2：X软联销资源管理系统的编码阶段工作量清单

上述两个软件的编码阶段的工作量合计为： Ec = Ec1 + Ec2 = 151.67 + 1631.67 = 1783.34(人.小时) 3. 软件生命期工作量估算 为便于估算，我们假定《X软赠券电脑发放管理系统》和《X软联销资源管理系统》均按照瀑布模型开发。 瀑布模型将整个软件生命期划分为计划与需求、产品设计、详细设计、编码与单元测试、集成与测试、移交等六个阶段，各阶段所占工作量如表3所示。 表3：瀑布模型阶段分布百分比 根据上表，编码与单元测试阶段仅占全部工作量的24%，因此《X

软件开发实施项目工作量评估明细表

项目工作量统计表 项目名称：推进OA系统应用，强化业务整合 一、推进OA流程应用工作量 序号阶段工作内容人员 配备 人·日 1 项目准备现有系统配置情况检查 系统相关模块的基本数据情况检查 制定实施阶段计划，约定每个阶段的时长，准 确划分各阶段时间节点 预定培训实施期间培训日期安排 3 9 2 系统配置建立相关组织结构 建立相关角色 调整全局配置项 建立权限分配方案 2 12 3 流程调研落实需要上线的流程列表，这些流程主要包 括：党委发文流程、纪委发文流程、公司发文 流程、部门发文流程（报告、函、请示、通知）、 公司收文流程，以及：用印申请流程、出差申 请流程、会议管理流程等 培训流程图的标准画法 收集流程图，交流流程信息、修改流程图、流 程图定稿 4 36 4 设定流程建立流程，谁提交，谁批准，谁执行 建立流程表单，及相应说明 建立流程处理签 建立存档管理，配置相关归档目录 建立权限管理 5 85 5 模拟调试对所有流程进行模拟测试，特别是各个重要公 文流程，必须进行遍历测试 根据模拟测试发现的情况，对流程设置进行检 讨和调整 4 72 6 管理员培训对流程管理员进行培训，使其掌握流程异常情 况处理、流程微调技巧 2 8 7 用户培训根据项目实际整理培训资料 落实培训人员、场地、时间安排 三场用户培训，需用户积极配合协调 2 8 8 系统启用建立起与系统运行相适应的管理规章制度 发布正式启用系统的通知 系统检查与实施补充 问题收集、反馈、调整 2 12 9 项目收尾项目回顾 权限收回 2 2 合计244

二、新功能开发工作量 序号阶段工作内容人员 配备 人·日 1 需求调研、分析了解用户业务，获取用户对功能、性能等方面 的需求 4 20 2 需求确认用户方、开发方对需求进行审核确认 这些功能包括：安全认证、电子印章、规章制 度管理、业务整合 2 10 3 总体设计系统初步设计 2 10 4 总体设计评审用户方、开发方对总体设计审核确认 2 2 5 详细设计对系统功能、操作界面、处理逻辑、数据库、 代码体系等进行详细设计 2 20 6 详细设计评审开发组对详细设计方案审核确认 1 3 7 编程、单元测试编写程序、单元测试 系统管理（设置，备份还原） 操作人员管理及权限管理 2 24 安全认证 2 70 电子印章 2 64 规章制度管理 3 81 业务整合（初步） 2 20 业务整合（深入） 4 120 8 集成测试系统集成测试、系统测试，编程与测试可以交 叉进行 4 24 9 安装调试到用户现场安装调试开发好的系统，并与用户 一起试走业务流程，对系统进行功能确认测试 3 21 10 系统初始化将系统初始化；准备业务基础数据并录入系 统； 2 12 11 用户培训对用户操作人员、系统管理人员进行详细培训 1 4 12 项目跟踪与总 结 系统bug控制，操作指导 2 12 合计517 工作量总计：761人·日

工作量的评估方法

工作量的评估方法 1．软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式： 软件开发价格＝开发工作量×开发费用／人·月 1.1开发工作量 软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关： 软件开发工作量＝估算工作量经验值×风险系数×复用系数 1.1.1估算工作量经验值（以A来表示） 软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。 为了更好地规范估算方法，建议可按照国家标准“GB／T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 工作量的计算是按一个开发工作人员在一个月内（日历中的月，即包括国家规定的节假日）能完成的工作量为单位，也就是通常所讲的“人·月”。 特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各类软件测试的活动。 1.1.2风险系数（以σ来表示） 估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。因此： l≤风险系数≤1.5 根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“1.5”为极限值。当然这既要看企业的能力，也要看用户能接受的程度。 1.1.3复用系数（以τ来表示） 估算工作量经验值是软件企业承担一般项目来估算的，但如果软件企业已经采用“基于构件的开发方法”，并己建立起能够复用的构件库（核心资产库），或者已有一些软件产品，仅作二次开发，从而使软件开发工作量减少。因此： 0.25≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法（软件产品线）的经验数据，提高工作效率达到25%（最高值）。 1.2开发费用／人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用／人·月＝（P＋Q＋R）×S×τ 1.2.1P（人头费） 人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%－80%。 P＝B×1.476 国家规定的公积金7%，医疗保险金12%，养老金22%，失业金2%（即通常所说的四金），另外还有按工资总额计征的工伤保证金0.5%，生育保证金0.5%，残

常用的工作量评估方法

常用的工作量评估方法在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法： 1、Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。 2、开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试。？5-7%给组件和集成测试？18-20%给系统测试？10%给接收测试（或回归测试等） 3、类比法（经验值法或历史数据法） 根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：？在设计和实现阶段花费的时间？测试工作的规模，例如用户

需求的数量，页面数，功能点？数据样式，例如实体，字段的数量？屏幕或字段数量？测试对象的规模，例如KLOC 4、WBS（work breakdown structure）估算法 将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。 5、Delphi法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方…… Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格； 4、协调人整理出一个估计总结，以迭代表的形式返回专家； 5、协调人召集小组会，讨论较大的估计差异； 6、专家复查估计总结并在迭代表上提交另一个匿名估计； 7、重复4-6，直到达到一个最低和最高估计的一致。 6、PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E，和标准偏差SD 1．软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式：

如何评估测试工作量

场景一：合同前的工作量估算 场景描述： 软件开发网 （1）没有实施过CMMI2级 （2）合同未签，需要给客户报价 （3）有客户的概要需求，有类似的项目数据可供参考 （4）需要估计整个项目的总工作量，以便于估算总成本，给客户报价 软件开发网 估算步骤： （1）寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量； （2）进行WBS分解，力所能及地将整个项目的任务进行分解； （3）参考类似项目的数据，采用经验法估计WBS中每类活动的工作量； （4）汇总得到项目的总工作量； （5）与第（1）步的结果进行印证分析，根据分析结果，确定估计结果。 场景二：基于详细需求的经验估计 场景描述： （1）只有详细需求，没有历史数据 估算步骤： （1）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 （2）采用经验法估计每个活动的工作量； （3）汇总得到：每个阶段的工作量、项目的总工作量。 其他说明： 在该场景下，只使用了经验法，无法对结果进行印证，难以判断结果的合理性。 场景三：由编码估算整体 场景描述： （1）有类似项目的历史数据 （2）有编码活动的生产率数据 （3）有详细需求 （4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据软件开发网 估算步骤： （1）产品分解，将系统分为子系统，子系统分解为模块； （2）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要

识别出所有的交付物、项目管理活动、工程活动等。 （3）建立WBS分解中的活动与产品元素的映射关系，识别出WBS中哪些活动可以采用模型法估算； （4）估计产品元素的规模，可以采用代码行法或功能点法，并估计每个产品元素的复杂度、复用率等； （5）根据历史的编码阶段的生产率数据和产品元素的规模估计、复杂度、复用率等采用模型法计算每个产品元素的编码工作量； （6）根据历史的类似项目的数据及估算人的经验估计其他活动的工作量，可以采用经验法。（7）汇总得到：每个阶段的工作量、项目的总工作量。 其他说明： 在该场景下，混合使用了经验法与模型法，这2种方法互相补充，而不是互相印证。 场景四：由总体印证基于WBS的估计 场景描述： （1）有类似项目的历史数据 （2）有类似项目的全生命周期的生产率数据（含管理工作量） （3）有详细需求 （4）实施了CMMI2级，但是没有积累历史项目的工作量分布数据 估算步骤： （1）产品分解，将系统分为子系统，子系统分解为模块； （2）估计产品元素的规模，可以采用代码行法或功能点法； （3）累计出整个产品的总规模，并估计产品总体的复杂度、复用率等； （4）根据类似项目的全生命周期的生产率数据和产品的总规模、复杂度、复用率等采用模型法计算总的开发工作量； （5）WBS分解，将任务分解到一个人或者一个小团队可以执行的颗粒度；WBS分解时要识别出所有的交付物、项目管理活动、工程活动等。 （6）根据历史的类似项目的数据及估算人的经验估计所有活动的工作量，可以采用经验法。（7）汇总得到：每个阶段的工作量、项目的总工作量。 （8）与第（4）步得出的工作量进行比较印证，如果偏差不大，则以第（7）步的结果为准，如果偏差比较大，要仔细分析原因，可能的原因举例如下： 类似项目的生产率数据不适合本项目； WBS分解的颗粒度不够详细； 估算专家的经验不适合本项目； 具体任务的估计不合理； 针对原因，对估算的结果进行调整，使其趋向合理。 其他说明： 在该场景下，对于项目的总工作量有2个结果或者多个结果，这些结果可以互相印证，以发现估算过程中的不合理之处，是估计更加合理。

工程风险评估报告

建筑工程风险评估综合报告 1、建筑单位（或所有人），投资方（或责权人），承包人（或分包人）情况（对工程主要承包人要了解该公司的历史，对类似的工程曾经承建的经验如何，承包人及其工程关系方的资信情况等）； 该项主要了解被保险人的情况。工程保险可以由多个共同被保险人，上述各项可以作为共同被保险人或单独的被保险人。承包人作为最主要的被保险人，需了解其以往建筑类似工程的经验，据以判断其承包该项目的风险程度；承包人及其工程关系方的资信将直接影响到工程资金的到位，进而关系到工程的进度，所以必要加以了解。 2、建筑工程名称和地址： 该项主了解工程的内容及通过施工地点的描述，对该地区自然和人文情况有一个较为粗略的判断。比如在城市和在农村、在平原和在山区、在我国的南方或在北方等就有很大的区别。 3、工程本身的危险程度，工程性质及建筑高度； 该项主要通过被保险人对该工程的性质及其建筑高度的描述，协助保险人判断该工程技术的难易程度和风险大小，比如普通居民住宅和高层建筑、桥梁和普通道路、开挖水库和构筑堤坝等。 4、工地及临近地区的自然地理条件，周围环境，有无特别危险存在； 该项主要通过被保险人对工程自然条件的描述，估计可能发生的自然灾害或其它事故的可能性及预防措施，比如是否属于泻洪区、附近是否有水库及河流、是否地震裂带、是否容易发生风暴等。 5、工地有无现成建筑物或其它财产及其位置状态等； 该项主要了解施工范围内有无其他已存在的建筑物，如属被保险人所有或照管，则提醒其与工程一并投保；如不属于被保险人所有，则提醒其投保第三者责

任险，并估计可能造成的第责任险损失大小。注意如果涉及震动、移动及减弱支撑风险时（如打夯机、深挖地基等）要对现有状况做详细的调查。 6、第三者责任风险的大小； 该项可根据被保险人对第三者责任风险的要求程度及周围情况或可能发生的危险程度，保险人提出自已的保险建议（即赔偿限额、费率和免赔额的大小等承保条件）及被保险人应注意的事项；例如，地处城市闹市区的工程，可能发生的风险程度一般大大高于远离市区的空旷地带的工程。 7、储存物资的库场状况、位置及运输距离、方式等； 该项主要了解施工范围内或施工地点以外有无储存物资，如有，则提醒其加保，并列明存放地点；根据该物资的存放地点及方式，判断其可能发生损失程度。 8、巨灾的可能性，最大可能损失程度及工地现场管理和安全条件； 判断该工程发生巨灾的可能性及由此造成损失的最大可能程度，了解该工地现场的管理和安全条件，据以判断其应付自然灾害和意外事故，尤其是应付巨灾的能力。 9、施工季节、工期、试库期的长短、试车方式、保证期长短及其责任大小； 该项主要通过了解施工季节，第一可判断其工程的施工质量；第二根椐该地区的自然情况，可判断对施工的影响程度，了解工程试车期的性质、长短，如该工程试车期比一般工程长或包括热试车，则其风险加大故可作为加费的依据；了解工程合同中关于工程保证期的有关规定，根据被保险人的要求，决定选择何种保证期条款。 10、安装项目及机器设备情况； 如建筑工程中又包括安装工程，且安装工程在工程总造中所占比例不大（一般不高于工程总造价的20%），则可以将安装工程列入建筑工程中投保，否则，应另投保安装工程一切险。该条即针对上述情况所设计，主要了解安装工程中设

工作量的评估方法

羀工作量的评估方法 肄1．软件开发价格估算方法 袅软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便 于计算，给出一个计算公式： 膂软件开发价格＝开发工作量×开发费用／人·月 螇1.1开发工作量 莇软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关： 芄软件开发工作量＝估算工作量经验值×风险系数×复用系数 羂1.1.1估算工作量经验值（以A来表示） 螈软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法 实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。 蒅为了更好地规范估算方法，建议可按照国家标准“GB／T8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。 蚄工作量的计算是按一个开发工作人员在一个月内（日历中的月，即包括国家 规定的节假日）能完成的工作量为单位，也就是通常所讲的“人·月”。 蚃特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各 类软件测试的活动。 袀1.1.2风险系数（以σ来表示） 袇估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一 个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟 悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。因此： 肃l≤风险系数≤1.5 蒃根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“1.5”为极限值。当然这既要看企业的能力，也要看用户能接受 的程度。

XX项目专项风险评估报告

XXX标项目经理部 专项风险评估报告 一、事项概述 （一）基本情况 1.背景情况 2.实施模式 项目部设立了工程技术部、安全质量环保部、物资设备部、计划合同部、计划财务部、综合管理部和综合协调部共7个部门；根据业主要求和铁路施工管理模式的特点，充分考虑项目实际情况，项目部采用“大分部，小总部”的管理方式，按区段划分成立了4个现场管理架子队。 3.资金运作情况 本工程建设资金来自中国铁路总公司、福建省投入的资本金和银行贷款。项目部每期按照与业主签订合同单价与中水三局项目部结算。 （二）合同或协议的主要内容 1.标的：标段内所有工程 2.履行的方式： 3.期限：2013年12月1日至2015年12月1日，完工日期以业主批复实施性施工组织设计工期为准。 4.价款支付：在工程施工进行中按主合同相关规定进行结算 5.担保条款：乙方向甲方提交四千八百万银行履约保函或一千四百四十万元现金担保。若乙方承担部分项目发生影响甲方的纠纷和诉讼时，乙方不能及时妥善处理，甲方可无条件动用保函用于解决。 6.违约条款和生效条件：如乙方的违约行为导致工期延误、甲方经济损失等后果，乙方应承担违约责任，赔偿因此给甲方造成的经济

损失，甲方有权利从乙方应得价款中直接扣除；当发生下列严重违约情况是，甲方有权单方面将乙方所承担的施工任务部分或全部收回，与乙方解除合同并不承担责任： （1）乙方擅自将本合同全部或部分权利转让，或私自将合同的全部（部分）义务转移给他人； （2）未经甲方书面批准，私自将合同中约定的投入到本管段内的施工设备和资源撤离现场； （3）乙方在施工过程中，使用了不合格的材料或工程设备，工程质量达不到主合同要求又拒绝清除不合格工程或依合同修补缺陷仍达不到主合同要求的； （4）乙方未能按照施工计划及时完成约定的工作；关键线路工期滞后累计超过两个月的； （5）乙方在质保期内，未能对其施工管段内所存在的质量缺陷进行及时修复； （6）乙方已无力继续履约或表明不愿意继续履约； （7）乙方未能按照本合同约定履行自身义务且经甲方指出拒不改正； （8）乙方因故意或重大过失拖欠供货商、农民工工资，损害甲方及甲方所属集团公司声誉或扰乱甲方施工和/或办公现场秩序的； （9）乙方在施工期内，发生重大责任安全事故、环保事故等。 甲方的违约行为导致工期延误、乙方经济损失等后果，甲方应承担违约责任，赔偿因此给乙方造成的经济损失；当发生下列情况之一时，视为甲方严重违约，乙方根据主合同相关条款有权暂停施工或解除合同，所有费用由甲方承担： （1）甲方在业主资金支付到位的情况下，未能按合同约定支付乙方预付款或合同价款； （2）甲方无法继续履行或明确表示不履行或实质上已停止履行合

投资项目风险评估报告文本

《项目投资风险评定报告》是分析确定风险的过程，在国际投资领域中，为减少投资人的投资失误和风险，每一次投资活动都必须建立一套科学的，适应自己的投资活动特征的理论和方法。《项目投资风险评审报告》正是吸收了国际上投资项目分析评价的理论和方法，利用丰富的资料和数据，定性和定量相结合，对投资项目的风险进行全面的分析评价，采取相应的措施去减少、化解、规避风险的途径。 “高风险带来高收益”是投资行业尤其是风投领域奉行的一贯准则，最关键的是如何识别和预测风险，并将风险控制在自己可以接受的范围内。而可以接受的风险标准就是：是否是与预期收益相匹配，必要承受的风险。同时也只有精确的、可靠的、科学的风险预测分析结果，才能针对未来将可能出现的风险，提出防范的措施和解决的办法，避免可能带来的经济损失。 项目投资的风险是指在投资活动中投资者不希望的结果出现的潜在可能性，或者说投资失败的可能性。由于投资的对象大多是具有较高增长潜力的项目，从技术的研发、产品的试制与生产，到产品的销售要经历许多阶段，而投资风险存在于整个过程中，并来自于多个方面，所以风险投资的失败率极高。因此，对投资项目的风险进行客观的评估和分析，从而有效地规避风险，是风险投资能否成功的关键。 投资的风险主要包括技术风险、管理风险、市场风险、财务风险和环境风险等。由于风险投资过程是一种投资期限长、投资结果高度不确定的创新过程，投资主体很难获取关于整个投资过程的比较完整、准确的信息，即信息是不完全的。投资主体虽然对未来情况（如对某些定性评价指标）有所了解，但对如概率、可能的风险损失、投资收益变动等定量指标很难做出估计。项目的风险具有广泛的复杂性和系统性，如何准确识别所有风险，如何衡量各个风险影响程度，如何将各个风险指标系统的整合起来得出项目风险整体评价？这只能借助专家的意见和知识，并用定量指标和科学的计算模型进行评价。《项目投资风险评定报告》正是这种方法体系的集

风险评估表--工程项目版

QHSE管理体系文件 编号：UEW/x-xx-xx-xx 风险评估表 Risk Assessment Form 第1页共4页

Risk Assessment Form 附件 危害与环境因素评价准则 危害后果/环境影响的严重性（S）——参照表 危害/环境因素导致后果发生的可能性(L)——参照表

Risk Assessment Form 风险评估表 风险控制措施及实施期限

Risk Assessment Form 说明： 1-目的：认真贯彻落实国家、地方各级政府、相关主管部门颁发的有关安全生产、职业健康、消防和环保工作的方针、政策、法律、法规、标准、条例等，切实执行“安全第一、预防为主”的方针，确保工程项目安全有序的开展，特制订本“风险评估表”，作为工程项目安全生产管理的基本工具，用以持续、系统的识别工程项目实施过程中各项工作的危害因素，通过制定相应措施来消除和减少危害，降低和控制各种风险，确保施工人员在施工过程中安全、文明施工。 2-适用范围：此风险评估表适用于所有与本公司有合作关系的单位和个人（以下统称为承包方）。 3-承包方职责和工作内容：承包方负责人作为风险控制责任人，需从全局把握施工过程中的各种风险，通过定期和不定期组织施工人员集中讨论施工工作中的各种风险，制定应对措施以尽可能的消除和降低风险，做好记录同时将记录递交给我司管理人员备案，作为落实安全文明施工监督、检查、督促的依据。4-风险评估表更新周期：风险评估工作应融入施工工作中，贯穿施工工作始终，以周/月等施工计划为基础，根据现场实际施工进度，随施工工作内容的变化而逐步更新增补；如施工内容无变化则无需重复更新风险评估内容；当发生下述情形时，需增补风险评估内容： a)与工程项目相关的法律法规规章制度发生变化； b)任何与我司合作的新的承包方的进驻； c)施工工作内容或方式发生变化； d)同一项工作的施工人员发生变化； e)事故或事件发生后； 发生上述情形时，针对所需更新的内容需在规定时间内完成风险评估表的更新工作。 5-其他：承包方需遵守我司对工程项目的安全文明施工的管理规定，定期召开安全文明施工会议，充分利用好这一安全管理工具，管理人员要做到赏罚分明，尽可能的激发施工人员对安全施工的主动意识；同时要求各施工单位参加施工的全体人员参与此项工作。

软件项目工作量评估方法

工作量评估 1概述 我们认真地阅读了软件的相关需求文档和设计文档后，对软件的功能进行了归纳和整理，并根据以往的经验对每个功能模块所需的编码工作量进行估算，再进一步地以此为依据，推算出整个软件生命期的工作量。工作量推算后组织主要项目干系人和相关专家进行工作量评审。 2常见的估算方法 2.1Ad-hoc方法 这种方法下的测试工作量不基于任何确定的期限。工作一直继续直到达到一些由管理或市场人员预先定下的时间表。或者，一直到用完了预算的经费。这种情况普遍存在于非常不成熟的组织，并且时常有100%的错误差数。 2.2开发时间的百分比法Percentage of development time。 这个方法的基本前提是测试工作量依赖于开发时间/开发工作量。首先，开发工作量使用例如LOC或FP方法被估算出来，然后使用一些探索性的方法来限制测试的工作量。这种方法变化比较大而且通常基于以前的经验。 通常预留项目的总花费时间的35%给测试, 5-7%给组件和集成测试,18-20%给系统测试, 10%给接收测试（或回归测试等） 2.4类比法（经验值法或历史数据法） 根据以前或相似项目（主要在项目性质，领域，规模上有相似）所积累的经验或历史数据来估算工作量。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。需要收集以下相关的历史数据：在设计和实现阶段花费的时间，测试工作的规模，例如用户需求的数量，页面数，

功能点，数据样式，例如实体，字段的数量, 屏幕或字段数量,测试对象的规模，例如KLOC 2.5 WBS（work breakdown structure）估算法 将项目或产品分解为具体的工作，然后分别对各个工作进行时间估算，最终求和得出项目或产品的测试工作量/时间。 2.6 Delphi法 Delphi法是最流行的专家评估技术，在没有历史数据的情况下，这种方式可以减轻估算的偏差。Delphi法鼓励参加者就问题相互讨论。这个技术，要求有多种相关经验人的参与，互相说服对方。 Delphi法的步骤是：1、协调人向各专家提供项目规格和估计表格；2、协调人召集小组会各专家讨论与规模相关的因素；3、各专家匿名填写迭代表格；4、协调人整理出一个估计总结，以迭代表的形式返回专家；5、协调人召集小组会，讨论较大的估计差异；6、专家复查估计总结并在迭代表上提交另一个匿名估计；7、重复4-6，直到达到一个最低和最高估计的一致。 2.7 PERT估计法 PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计。Pert 估计可得到代码行的期望值E，和标准偏差SD 3.估算前准备 针对以上方法，我司综合了以上多种评估方法，总结出了适合我司的评估方法：