一种软件开发过程的工作量评估模型

外包管理评估表格模板

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外包系统验收 由项目经理按照外包合同规定的接收准则和方法，对外包系统进行验收，验收合格后由项目配

2020软件开发项目预算表格.docx

研发项目工作量估算项目名称项目编号项目组长 ( 经理)预计开始时间预计结束时间估算人估算日期 里程碑工作描述 工作量估算（人 . 天） 小计最小工作量最可能工作量最大工作量估算结果 软件开 0发计划 项目管理配置管理计划00软件测试计划0 质量保证计划0 需求调查0 需求分析需求分析00编制需求分析文档0 体系结构设计0 系统设计数据模型设计0 0系统原型设计0 模块详细设计0 模块名 功能点10 功能点200称 功能点30 项目开发 功能点10模块名 功能点200称 功能点30准备测试用例0 系统集成测试0 系统测试测试结果修改00用户验收测试0 试运行 / 联测试报告0 试 0一年维护 培训 人力成本0 工作量总计（人. 0#NAME? 天）（元） 交通费用 其它投入估算评审 / 会务费 （元）差旅费用 其它费用 成本预估（元）#NAME? 批准：复核：拟制： 以下由立项 评审组组长 填写： 评审结果 备注： 1、工作量 的预估采用 专家意见法 预估，专家 数量不得少 核定工作量（人. 月） 人力成本（元） 其它投入合计（元） 成本合计（元） 评审组长签字 /日期

2、人力成 本估算以公 司上年度平 均薪酬W （含社会保 险、各种补 贴）作为基 3、估算结 果的计算公 式：（最小 工作量 +4× 最可能工作 量+最大工4、 核定工作量 是指项目全 过程的 工作量； 5、本表格 是项目立项 评审的组成 部分，存档 预算表（总表） 项目名 称：项目编号： 起始时 间：完工时间： 回款计 回款项目金额（元）时间回款条件划： 项目概述 合计390,000.00—— 首款117,000.002008.6.15 二期款117,000.002008.12.31一期稳定运行 117,000.002009.12.31全部运行稳定 三期款并验收 尾款39,000.002010.12.31质保一年支出项 数量单价（元）金额（元）备注目 合计——83,909.28 1.已 发生 费用——0.00 2. 人力 成本57,139.28 1、项 目经理154227.8335,085.82 2、其 他角色 等28677.1122,053.46 3、其 他角色 等0.00 3. 设备 成本0.00 1、TCL 笔记本 等0.00 2、移 动硬盘 等0.00

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

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

软件开发报价和报价材料模板的计算方法

软件开发报价的计算方法 1．软件开发价格估算方法软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式： 软件开发价格＝开发工作量× 开发费用／人·月 1.1 开发工作量软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关：软件开发工作量＝估算工作量经验值× 风险系数× 复用系数 1.1.1 估算工作量经验值（以A 来表示）软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。 1.1.2 风险系数（以σ 来表示）估算工作量经验值亦会存在较大风险，造成软件危机的因素很多，这也是一个方面的因素。特别当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉，而且用户又无法或不能完整明白地表达他们的真实的需求，从而造成软件企业需要不断地完善需求获取，修改设计等各项工作。因此： l ≤风险系数≤1.5 根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“ 1.5 ”为极限值。当然这既要看企业的能力，也要看用户能接受的程度。 1.1.3 复用系数（以τ 来表示）估算工作量经验值是软件企业承担一般项目来估算的，但如果软件企业已经采用“基于构件的开发方法” ，并己建立起能够复用的构件库（核心资产库），或者已有一些软件产品，仅作二次开发，从而使软件开发工作量减少。因此： 0.25 ≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法（软件产品线）的经验数据，提高工作效率达到25%（最高值）。 1.2 开发费用／人·月软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用／人·月＝（P＋Q＋R）× S× τ 1.2.1 P （人头费）人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%－80%。 P ＝B × 1.476 国家规定的公积金7%，医疗保险金12%，养老金22%，失业金2%（即通常所说的四金），另外还有按工资总额计征的工伤保证金0.5%，生育保证金0.5%，残疾基金 1.6%，工会基金2%，累计为47.6%。 B 为平均工资，即企业支付给员工的工资、奖金、物质奖励等多项总和，除以企业员工数，分摊到每个月。 1.2.2 Q （办公费）办公费包括企业办公房屋租赁费和物业管理费、通信费、办公消耗品、水电空调费、设备折旧、差旅费，另外也包括企业对员工的在职培训所支付的费用，其总量在软件企业中的商务成本占20%－30%。 Q ＝B／3 此处办公费用按商务成本的25%计算。 1.2.3 R （国家税收和企业利润）由于国家实施发展软件产业的优惠政策，故不单独列出计算，但软件企业仍需承担缴纳国家税收的义务，可一并与企业利润一起考虑。另外，软件企业的员工不可能全年满负荷地工作，即使一年十二个月都安排工作，但也需抽出时间进行在职培训和提职的岗前培训。据我们的了解，软件企业的员工一

软件评估报告

德米萨ERP评估报告

目录 1 评估描述 (3) 1.1评估目标 (3) 1.2软件供应商简介 (3) 2项目可用性 (4) 2.1业务单据基本流程 (4) 2.2操作性 (4) 2.3交互功能 (4) 2.4定制化 (4) 3软件成本 (5)

1 评估描述 1.1评估目标 公司新项目需求，Iphone二手手机翻新销售项目，为了能使用符合业务流程的软件ERP应用功能，考察了德米萨进销存旗舰版ERP套件，主要评估业务上是否够正常处理Iphone项目的业务流程。 1.2软件供应商简介 上海德米萨信息科技有限公司（上海幻仙石软件有限公司）是经中华人民共和国工业和信息化部以及上海市经济和信息化委员会评定和审核的双软企业，是国家重点支持的软件企业。公司按照国际先进管理模式和制度组建，公司创始团队最早于2002年从事政府机构软件定制开发与服务，从2007年起专注企业管理软件的研究与开发，陆续推出“德米萨”系列智能办公管理软件，并于2009年起开始正式面市销售，迄今已积累各行各业大量客户群。公司拥有一支具备国际化视野和多年实战经验的团队，集合了一批世界上优秀的技术人才和资深的企业管理专家以及信息安全专家，公司高层领导及骨干员工均从事软件行业十余年，公司成立以来，一直专注于企业管理软件的开发和服务，在中国企业信息化的浪潮下，德米萨信息科技逐渐走向成熟，规模日趋壮大。公司高层管理人员及骨干员工均有多年从事政府机构、事业单位及大型企业管理软件研发、实施等从业经历，具有丰富的管理咨询和技术服务经验，近90%的员工从事软件开发、系统集成、应用维护、技术咨询和信息安全工作。

软件开发工作量估算和报价

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

l≤风险系数≤ 根据我们对软件企业的了解，超过估算工作量经验值的一半，已是不可接受，所以我们确定“”为极限值。当然这既要看企业的能力，也要看用户能接受的程度。 估算工作量经验值是软件企业承担一般项目来估算的，但如果软件企业已经采用“基于构件的开发方法”，并己建立起能够复用的构件库（核心资产库），或者已有一些软件产品，仅作二次开发，从而使软件开发工作量减少。因此： ≤复用系数≤1 根据国内外软件企业在实施基于构件开发方法（软件产品线）的经验数据，提高工作效率达到25%（最高值）。 开发费用／人·月 软件企业的商务成本、国家税收、企业利润、管理成本和质量成本。均可摊分到各个软件开发人员头上。 开发费用／人·月＝（P＋Q＋R）×S×τ 人头费主要是员工的工资、奖金和国家规定的各项按人计算的费用。其总量在软件企业中的商务成本占70%－80%。 P＝B× 国家规定的公积金7%，医疗保险金12%，养老金22%，失业金2%（即通常所说的四金），另外还有按工资总额计征的工伤保证金%，生育保证金%，残疾基金%，工会基金2%，累计为%。B为平均工资，即企业支付给员工的工资、奖金、物质奖励等多项总和，除以企业员工数，分摊到每个月。

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

项目工作量统计表 项目名称：推进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人·日

软件工作量评估报告

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

常用的工作量评估方法

常用的工作量评估方法在测试项目管理中或编写测试计划时，经常需要对某个测试工作进行工作量的预算，很多时候都是凭个人的工作经验进行估算的，如能结合一些常规的估算方法，有助于估算的精确度。 以下是网上找到的一些常规的估算测试工作量的方法： 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．软件开发价格估算方法 软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式：

外包管理评估表

外包管理评估表 Company number：【0089WT-8898YT-W8CCB-BUUT-202108】

1目的 明确本公司的外包过程及其控制方法，通过对外包过程的有效控制，使开发出的系统满足规定的要求。 2适用范围 本文件适用于系统的外包开发。 3职责及权限 1）项目经理负责对系统开发供方（外包方）的调查、评定和选择。 2）项目经理提出外包要求，并组织对外包要求的审核，确定后纳入外包合同。 3）项目经理实施对外包过程的控制，并组织在项目结束时对外包供方的评估。 4对系统开发供方的控制 对系统开发供方的调查 1）由项目经理组织对系统开发供方进行如下内容的调查，并填写《系统开发供方调查表》、收集证明材料。 ·开发经验 包括：开发的系统清单，应用行业，系统规模，软硬件平台，开发工具 ·人员结构 包括：开发过程所需各种人员的数量及人员经历。 ·设备资源 包括：可提供开发的设备情况。 ·实施效果 包括：顾客对其提供的系统系统的满意程度 ·角色成员访谈 访谈对象包括：公司技术负责人、项目负责人、测试负责人等

对公司技术负责人，访谈问题如：如何组织系统开发过程如何组织系统质量 保证过程等 对项目负责人，访谈问题如：如何进行项目计划和计划跟踪等 对测试负责人，访谈问题如：如何组织测试过程等 2）由项目经理组织质量控制部、研发部对系统开发供方的质量管理体系、技术水 平进行审核，并提出质量审核报告。 合格系统开发供方的选择 1）项目经理提供《系统开发供方调查表》、质量审核报告及有关证明资料，组织有关人员或部门，对系统开发供方进行评定和选择。评定和选择依据是系统开发供方系统开发的能力，包括：开发经验、人员结构、设备资源、技术水平、质量保证能力、顾客满意程度等。 2）根据参加人员的评审意见，由项目经理填写《系统开发供方评定表》，参加者会签。 3）项目经理负责拟制《合格系统开发供方名单》，报主管VP审批。 4）《合格系统开发供方名单》是本公司选择系统开发供方的依据，经批准的《合格系统开发供方名单》为受控文件，由项目配置管理员负责发放并归档管理。 合格系统开发供方的调整 4.3.1重新评定的时机 1）每个外包项目完成时都要对外包系统开发供方进行重新评定。 2）超过一年未合作的合格系统开发供方，有外包项目前重新评定审批。 4.3.2重新评定的方法 1）外包项目完成后，应从以下方面重新评定该项目的外包供方。 A.项目经理组织对外包系统供方进行评估，填写《外包系统供方评估表》。 评估内容包括 ·外包系统产品的可维护性 ·外包系统产品的文档质量 ·外包系统供方的组织管理能力

软件项目工作量评估方法

工作量评估 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.估算前准备 针对以上方法，我司综合了以上多种评估方法，总结出了适合我司的评估方法： 1）对工作进行WBS分解，尽量将任务分配到半天为工作单位的粒度，分解时需要考虑deadline、技术难点、需求变更风险等等因素。 2）尽量寻找和本项目相近项目做参考，参考历史相近项目的实际工作量和