软件开发工时分配（软件开发工时费）
本篇文章给大家谈谈软件开发工时分配，以及软件开发工时费对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、软件各阶段人员、时间比例
- 2、软件开发项目进度表包含那些内容
- 3、软件测试花费的工时与软件开发的工时一般大概是什么比例？
- 4、软件行业中人力资源分配详解？
- 5、一个软件项目如何评估工作量和成本?
- 6、软件开发怎么计价的？
软件各阶段人员、时间比例
因项目和团队配置人员素质而异。下面只是个大概的：1）人员：一个项目的人员分配是不代表工作量分配的，因为涉及到项目共用和占用时间长度的问题。假如是个增量开发且3个月可完成一个版本的项目，成员 11人。项目管理 1（多项目共用）
架构 1
需求分析 2（多阶段共用，假设参与设计和编码阶段）
概要和详细设计 4 （2人共用）
编码 3（2人共用）
测试 2
配置 1(多个项目共用)
DBA 1(多个项目共用) 2）时间大致分布：
计划阶段占2%~3%；
需求分析占10%~25%;
软件设计占20%~25%;
编码占15%~20%；
测试占30%~40%
仅供参考。
软件开发项目进度表包含那些内容
一是参考其它项目.
另一个现在的可参考项目是安装 Microsoft Office Project 2003, 内有好几个相关模板.
供参:
项目启动 6 工作日
组建工作组 6 工作日
定义工作组角色 2 工作日
确定所需技能 2 工作日
确定资源 2 工作日
将角色赋予资源 2 工作日
工作组成立 0 工作日
构想 44 工作日
定义初步的商业需求(持续性工作) 29 工作日
风险管理 1 工作日
定义项目结构 9 工作日
定义跟踪项目的步骤 5 工作日
定义解决问题的步骤 4 工作日
定义跟踪问题的步骤 3 工作日
定义控制变更的步骤 4 工作日
定义责任和期望 2 工作日
项目结构确定完毕 0 工作日
研究和收集设想 25 工作日
进行初步的用户访问 2 工作日
定义使用场合 10 工作日
制定初步的用户描述 5 工作日
制定初步的构想说明 1 工作日
确立设计目标 8 工作日
制定初步的解决方案概念 5 工作日
制定初步的项目范围 19 工作日
定义关键的成功因素 2 工作日
定义衡量成功的标准 1 工作日
定义主要的可交付结果(初步) 3 工作日
起草构想/范围 3 工作日
审阅构想/范围 2 工作日
更新构想/范围 3 工作日
缓冲时间 4 工作日
进行里程碑检查 1 工作日
构想得到批准 0 工作日
规划 59 工作日
更新风险评估 1 工作日
进行用户访问 10 工作日
创建功能描述 31 工作日
制定功能描述: 第 0 批 5 工作日
制定功能描述: 第 1 批 5 工作日
制定功能描述: 第 2 批 5 工作日
制定功能描述: 第 n 批 5 工作日
功能描述基准 0 工作日
开发计划 28.25 工作日
创建开发计划 28 工作日
进行概念性设计 10 工作日
进行逻辑设计 15 工作日
进行物理设计 19 工作日
制定开发日程 5 工作日
测试计划 35 工作日
制定测试计划 30 工作日
制定测试日程 5 工作日
用户培训计划 36 工作日
制定用户培训计划 30 工作日
制定用户培训日程 6 工作日
后勤计划 48 工作日
制定后勤计划 43 工作日
进行基础设施分析 15 工作日
制定安全计划 2 工作日
制定部署计划 27 工作日
定购组件 15 工作日
后勤计划完成 0 工作日
创建后勤日程 7 工作日
产品管理计划 18 工作日
制定产品管理计划 14 工作日
制定产品管理日程 5 工作日
程序管理计划 41 工作日
创建程序管理计划 21 工作日
创建程序管理日程 20 工作日
建立项目计划基准 0 工作日
合并项目计划 11 工作日
审阅合并计划 4 工作日
创建合并日程 2 工作日
缓冲时间 4 工作日
确定交货日期 0 工作日
构想/范围冻结 0 工作日
进行里程碑检查 1 工作日
项目计划得到批准 0 工作日
开发 81 工作日
更新风险评估 1 工作日
提供开发所需的设备/检验概念是否达到 0 工作日
建立开发环境/实验室 5 工作日
内部发布 #1 24 工作日
开发目标组件 9 工作日
测试单个组件 5 工作日
测试组装为整体的应用程序 6 工作日
开发增强性能的材料 4 工作日
测试和审查材料 3 工作日
制定分发步骤 9 工作日
创建分发产品 2 工作日
分发给合适的对象 1 工作日
缓冲时间 8 工作日
内部发布 #1 结束 0 工作日
审阅来自内部发布的结果 2 工作日
进行发布后的审阅 1 工作日
内部发布 #n 24 工作日
开发目标组件 10 工作日
测试单个组件 4 工作日
测试组装为整体的应用程序 5 工作日
开发增强性能的材料 4 工作日
测试和审查材料 3 工作日
制定分发步骤 3 工作日
创建分发产品 4 工作日
缓冲时间 6 工作日
分发给合适的对象 1 工作日
内部发布 #n 结束 1 工作日
审阅来自内部发布的结果 2 工作日
功能说明冻结 1 工作日
最后的特性开发 10 工作日
最后的后勤开发 9 工作日
最后的性能支持开发 5 工作日
特性开发结束 0 工作日
更新计划和日程 13 工作日
更新开发计划 4 工作日
更新测试计划 3 工作日
更新后勤计划 13 工作日
更新程序管理计划 3 工作日
更新产品管理计划 3 工作日
更新用户培训计划 6 工作日
缓冲时间 3 工作日
进行里程碑检查 2 工作日
项目范围规划完成 1 工作日
稳定 73 工作日
更新风险评估 1 工作日
发布测试版 1 32 工作日
制定测试版计划 3 工作日
征寻和选择用户 2 工作日
准备测试版产品包 8 工作日
开始测试 0 工作日
提供测试支持 8 工作日
收集用户反馈 7 工作日
结束测试支持 0 工作日
修补缺陷 10 工作日
结束测试 0 工作日
发布测试版 n 1 工作日
修补缺陷 10 工作日
收集错误 1 工作日
改正高优先级的错误 10 工作日
发布无错误版 0 工作日
进行最后的错误分类 5 工作日
发布版候选 1 7 工作日
进行工作组评估 2 工作日
客户/用户评估 2 工作日
支持评估 3 工作日
发布版候选 n 6 工作日
黄金发布版 0 工作日
发布 1 工作日
项目后检查 2 工作日
软件开发:
-------------------------
项目范围规划 3.5 工作日
确定项目范围 4 工时
获得项目所需资金 1 工作日
定义预备资源 1 工作日
获得核心资源 1 工作日
项目范围规划完成 0 工作日
分析/软件需求 14 工作日
行为需求分析 5 工作日
起草初步的软件规范 3 工作日
制定初步预算 2 工作日
工作组共同审阅软件规范/预算 4 工时
根据反馈修改软件规范 1 工作日
确定交付期限 1 工作日
获得开展后续工作的批准(概念、期限和预算) 4 工时
获得所需资源 1 工作日
分析工作完成 0 工作日
设计 14.5 工作日
审阅初步的软件规范 2 工作日
制定功能规范 5 工作日
根据功能规范开发原型 4 工作日
审阅功能规范 2 工作日
根据反馈修改功能规范 1 工作日
获得开展后续工作的批准 4 工时
设计工作完成 0 工作日
开发 21.75 工作日
审阅功能规范 1 工作日
确定模块化/分层设计参数 1 工作日
分派任务给开发人员 1 工作日
编写代码 15 工作日
开发人员测试(初步调试) 15 工作日
开发工作完毕 0 工作日
测试 48.75 工作日
根据产品规范制定单元测试计划 4 工作日
根据产品规范制定整体测试计划 4 工作日
单元测试 15 工作日
审阅模块化代码 5 工作日
测试组件模块是否符合产品规范 2 工作日
找出不符合产品规范的异常情况 3 工作日
修改代码 3 工作日
重新测试经过修改的代码 2 工作日
单元测试完成 0 工作日
整体测试 12 工作日
测试模块集成情况 5 工作日
找出不符合规范的异常情况 2 工作日
修改代码 3 工作日
重新测试经过修改的代码 2 工作日
整体测试完成 0 工作日
培训 45.75 工作日
制定针对最终用户的培训规范 3 工作日
制定针对产品技术支持人员的培训规范 3 工作日
确定培训方法(基于计算机的培训、教室授课等) 2 工作日
编写培训材料 3 周工时
研究培训材料的可用性 4 工作日
对培训材料进行最后处理 3 工作日
制定培训机制 2 工作日
培训材料完成 0 工作日
文档 30.5 工作日
制定“帮助”规范 1 工作日
开发“帮助”系统 3 周工时
审阅“帮助”文档 3 工作日
根据反馈修改“帮助”文档 2 工作日
制定用户手册规范 2 工作日
编写用户手册 3 周工时
审阅所有的用户文档 2 工作日
根据反馈修改用户文档 2 工作日
文档完成 0 工作日
试生产 70.25 工作日
确定测试群体 1 工作日
确定软件分发机制 1 工作日
安装/部署软件 1 工作日
获得用户反馈 1 周工时
评估测试信息 1 工作日
试生产工作完成 0 工作日
部署 5 工作日
确定最终部署策略 1 工作日
确定部署方法 1 工作日
获得部署所需资源 1 工作日
培训技术支持人员 1 工作日
部署软件 1 工作日
部署工作完成 0 工作日
实施工作结束后的回顾 3 工作日
将经验教训记录存档 1 工作日
分发给工作组成员 1 工作日
建立软件维护小组 1 工作日
回顾完成 0 工作日
软件开发模板结束 0 工作日
软件测试花费的工时与软件开发的工时一般大概是什么比例？
我认为测试花费的工时大于开发的工时。随着国外测试技术的引进和国内企业的不断努力，国人的测试技术在不断完善，步入规范。尽早测试，也就是说从需求就开始测试了，知道最后的验收测试，贯穿项目的整个流程。至于楼主要说出具体的比例，那就不同的公司不一样的比例了，我觉得微软应该大于1，毕竟好多测试规程都是出自微软。
公司自用的网站编辑发布系统，有大有小，看你想怎么测，测试忌讳没完没了，要懂得停止，时间就是成本。
软件行业中人力资源分配详解？
组织结构管理 - 对组织结构及政策信息进行管理交流
作为my SAP HR的核心部分，组织结构管理提供了整个系统的完整框架。你可以根据组织结构、企业结构和人事结构，给每位员工在系统中准确定位。通过简单易用的图形工具，你可以对所有的组织结构，包括组织单元、职位、职务、工作任务、工作地点等进行维护。由组织结构确定的职位之间的汇报关系，是SAP设计"工作流"的主要依据。
结合使用my SAP HR员工发展组件，您可以对员工的业务技能和职位要求做出比较，然后准确找出职员的不能胜任之处，从而在my SAP HR培训和商务事件管理组件中生成相应的培训措施。在组织结构模式中,可以有效地管理企业的空缺职位。这对制订人员编制计划和招聘过程都至关重要。在招聘过程中，关于空缺职位的详细资料会立刻通过my SAP HR招聘组件反映出来。My SAP HR的组织结构管理组件同您的财务系统相结合，形成了my SAP HR人事成本核算应用程序的基础。My SAP HR人事成本核算程序是一项灵活的计划和管理工具。它使您能够预测所有涉及员工和组织结构的事件对成本的影响，并以此为基础制订决策，改变公司的政策。如果使用my SAP HR的薪酬管理组件，并依据组织结构制订预算计划，那么，您的组织结构模式将会成为可靠的制订计划的基础。
时间管理 - 简化有效的时间管理策略，提供方便的跟踪、记录和评估
my SAP HR时间管理系统为企业提供时间及员工出缺勤管理的功能，包括时间数据的收集、分析、为工资计算及休假管理提供数据支持等。使用工作流，my SAP HR时间管理系统可以大大提高工作效率、简化工作流程；能自动计算加班费用，进行休假管理、轮班计划、计算生产奖励，以及劳动成本分配等。
my SAP HR时间分析管理可以自动对收集的时间数据进行处理，计算出缺勤时间、加班时间、休假时间。将收集的时间数据与公司政策、合同及其他规定作比较，分析过程中的任何错误会通过E-Mail通知相关人员，得到及时修正。
轮班计划
利用my SAP HR 轮班计划的创新功能，您可以更有效地制订轮班计划，如在计划过程中公司又提出新的特殊要求；或者需要更快、更有效地对个人要求做出反应。看一下自动计划表格，您就可以对某个特定时刻的人力资源情况有个整体的了解。您可以制订一天或几天或当前的轮班计划，直接获得所有相关的时间数据，如雇员的缺勤记录，工作时间选择等。精确的评估工具在您制订计划的过程中会提供如下功能：如对超时或时间安排的改变进行提前警告。这些信息还可以防止工作时间超过法律规定。
记录工作时间
采用my SAP HR时间管理组件，您可以方便地管理员工的时间。无论时间数据管理员是通过集中式、分散式，或通过互联网软件的自助组件输入数据，都一样方便快捷。输入外部时间记录组件的数据通过一个专门接口传送到my SAP HR系统。有了这种链接，您不仅能记录雇员的时间数据，还能记录如自助餐厅和服务站的数据。
适合每位用户
利用my SAP HR 时间管理组件，您可以为每一用户群定制初始存取界面。这种功能适用于那些需要输入个人数据的员工，也适用为雇员执行这些任务的生产主管。我们的解决方案为适当的人提供了适当的工具，支持时间数据管理员有效完成工作。
优化性能
my SAP HR时间管理组件符合所有的法律规定、某些行业协议和公司的内部政策。例如，你可以选择制订员工的时间安排结构，检查工作时间规定，自动定义奖金和加班工资类型。
激励性工资
利用激励工资组件，你可以管理、记录并且修改某个或某些雇员的计件工资或奖励工资数据。并轻松地把数据从SAP后勤模块传送到SAP的人力资源模块。
工资核算 - 对工资核算的全过程进行自动化、流水型的处理
薪资计算要求尽可能高的精确度和灵活性。My SAP HR薪资计算组件凭借其可靠、灵活优质的性能，在用户中获得了良好的声誉。无论您的公司在何地开展业务，my SAP HR薪资计算组件针对不同国家设计的版本都能符合该国现行法律规定和某些协议规定，且能适应这些地区内法律法规的不断变更。使用my SAP HR薪资计算组件，薪资计算过程就按预先设置的程序以流水线方式进行。除此之外，它把多种复杂的因素都考虑在内，例如时间数据的评估，部分薪酬计算，扣发工资数额或公司的债务等。您还可以用高性能的工具独立处理公司的特殊要求。该应用程序有无限的核算能力，您可以轻松而准确地考虑特定核算期间的特殊规定。为满足公司国际化业务需要，我们对产品设计做了重大改进，增加了按标准格式设计的多种货币计量功能。系统能存储和换算多种货币的币值，这意味着客户从一开始就具有支持欧元的能力。
一个软件项目如何评估工作量和成本?
软件开发成本估算过程可进一步细分为软件规模估算、工作量估算、成本估算和确定软件开发成本等四个过程。
其中成本估算需要对直接人力成本、间接人力成本、间接非人力成本及直接非人力成本分别进行估算。
国家标准《GB/T 36964-2018 软件工程 软件开发成本度量规范》中建议的软件开发成本估算基本流程如下图所示：
国家准中的四个估算过程，层层递进，逐步细化，最终达到科学、一致的成本估算。
一、软件规模估算
通常情况下，规模估算是软件成本估算过程的起点。
估算规模是后续计算软件项目的工作量、成本和进度的主要输入，是项目范围管理的关键，因此，在条件允许的情况下，应首先进行规模估算。
在规模估算过程中，需要注意以下情况：
在规模估算开始前，应根据可行性研究报告或类似文档明确项目需求及系统边界。项目需求除包含最基本的业务需求外，还应进行初步的子系统/模块划分，并对每一子系统或模块的基本用户需求进行说明，以保证可以根据项目需求进行规模预估。
依据项目特点和需求详细程度不同，通常估算人员在选择估算方法时应采用纳入国际标准的功能点方法进行功能规模估算，在适用IFPUG或NESMA方法时，可以根据需求的粒度和管理需要，选择预估功能点方法、估算功能点方法或者详细功能点方法。
若当前的项目需求极其模糊或不确定，可不进行规模估算，而直接采用类比法或类推法估算工作量和成本。
二、工作量估算
在完成规模估算后，应当开展工作量估算工作，若当前项目未开展规模估算，也可直接启动工作量估算工作。
工作量估算时，可采用方程法、类比法、类推法、功能点法：
方程法：即基于基准数据建立参数模型，通过输入各项参数，确定估算值。
类比法：即将待估算项目的部分属性与类似的一组基准数据进行比对，进而确定估算值。
类推法：即将待估算项目的部分属性与高度类似的一个或几个已完成项目的数据进行比对，并进行适当调整后确定估算值。
功能点法：从用户视角出发，通过量化系统功能来度量软件的规模，这种度量主要基于系统的逻辑设计。功能点规模度量方法在国际上的应用已经比较广泛，并且已经取代代码行成为最主流的软件规模度量方法。
在开展工作量估算的过程中，需要注意以下情况：
当需求极其模糊或不确定时，如果此时具有高度类似的历史项目，则可直接采用类推法，充分利用历史项目数据来粗略估算工作量。
当需求极其模糊或不确定时，如果此时具有与本项目部分属性类似的一组基准数据，则可直接采用类比法，充分利用基准数据来粗略估算工作量。
对于规模估算已经开展的项目，可采用方程法，通过输入各项参数，确定待估算项目的工作量。若客户或高层对项目的工期有明确的要求时，在采用方程法估算工作量时，工期要求有可能是方程的参数之一。
为追求估算的准确性，建议在条件允许的情况下，可采用两种估算方法，对估算结果进行交叉验证，若估算结果差别不大，可直接使用两种估算结果的平均值或以某种估算结果为准，若差别较大，需进行差异分析。
工作量的估算结果宜为一个范围而不是单一的值。
三、成本估算
在获得了工作量估算结果后，可采用科学的方法进行成本估算。
在成本估算过程中，应需要注意的情况：
类比法和类推法，同样适用于需求极其模糊或不确定时的成本估算；
间接成本是否与工作量估算结果相关取决于间接成本分摊计算方式。在绝大多数组织，项目周期越长，项目组成员越多，其分摊的间接成本就越高，此时项目的间接成本与工作量估算结果直接相关；
直接非人力成本通常与工作量估算结果无关，宜单独分项测算；
成本估算结果，也通常为一个范围，而不是单一的值。
四、确定软件开发成本
在《软件工程 软件开发成本度量规范》中，将软件开发成本分为四类，主要是为便于对成本构成（即哪些成本属于开发成本，哪些不属于开发成本）进行清晰界定。
而在实际确定软件开发成本时，通常并不是分别测定四类成本，加和后获得总成本，而是通常采用以下两种方式确定总成本：
根据人力成本费率及工作量估算直接人力成本和间接成本之和，再加上直接非人力成本，获得总成本；
根据规模综合单价和软件规模，测算出直接人力成本和间接成本之和，再加上直接非人力成本，获得总成本。
在进行软件的规模、工作量、成本估算时应遵循以下原则：
在规模估算时,应根据项目特点和需求的详细程度选择合适的估算方法；
充分利用基准数据,采用方程法、类比法或类推法,对工作量和成本进行估算；
工作量和成本的估算结果宜为一个范围值；
在进行成本估算时,如有明确的工期要求,应充分考虑工期对项目成本的影响,可以根据项目实际情况以及工期对项目的影响程度,对成本的估算结果进行调整；
成本估算过程中宜采用不同的方法分别估算并进行交叉验证。如果不同方法的估算结果产生较大差异,可采用专家评审方法确定估算结果,也可使用较简单的加权平均方法；
在软件项目的不同场景下(如预算、招投标、项目计划和变更管理等)采用国家标准时,相关要求见国家标准中附录A。
除了上述主要原则外，我们还需注意在使用基准数据时：
对于委托方和第三方，建议使用或参考软件行业基准数据进行估算。估算模型的调整因子的增减或取值有可能随着行业基准数据的变化而变化。
对于开发方，在引入行业基准数据的基础上，可逐步建立组织级基准数据库，以提高估算精度。组织级基准数据定义应与行业基准数据定义保持一致，以便于与行业基准数据进行比对分析，并持续提升组织能力。
软件开发怎么计价的？
软件开发怎么计价的
软件开发如何计算工时，如何报价软件系统定制开发报价的计算方法，软件开发工时费用标准
1.软件开发做软件((致电手。叽l58--ll33--4744))价格估算方法
软件开发价格与工作量、商务成本、国家税收和企业利润等项有关。为了便于计算，给出一个计算公式：
软件开发价格 = 开发工作量 × 开发费用/人·月
1.1开发做软件((致电手。叽l58--ll33--4744))工作量
软件开发工作量与估算工作量经验值、风险系数和复用系数等项有关：
软件开发工作量 = 估算工作量经验值 × 风险系数 × 复用系数
1.1.1估算工作量经验值(以A来表示)
软什开发工作量的计算，曾有人提出以源代码行或功能点来计算，这些方法实施起来均有不少难度。目前国际上仍旧按以往经验的方式加以计算，国内各软件企业也是采用经验的方式加以估算工作量。
为了更好地规范估算方法，建议可按照国家标准“GB/T 8566-2001软件生存周期过程”所规定的软件开发过程的各项活动来计算工作量。
工作量的计算是按一个开发工作人员在一个月内(日历中的月，即包括国家规定的节假日)能完成的工作量为单位，也就是通常所讲的“人·月”。
特别要提醒的是软件开发过程中既包括了通常所讲的软件开发，也应包括各类软件测试的活动。
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(国家税收和企业利润)
由于国家实施发展软件产业的优惠政策，故不单独列出计算，但软件企业仍需承担缴纳国家税收的义务，可一并与企业利润一起考虑。
另外，软件企业的员工不可能全年满负荷地工作，即使一年十二个月都安排工作，但也需抽出时间进行在职培训和提职的岗前培训。据我们的了解，软件企业的员工一年能有10个月到
11个月的工作也是正常的。
R = B/3
此处为我们的建议方案，各软件企业可视情况加以变更。
1.2.4 S(管理系数)
通常每个机构的管理人员都会有一定的比例，参考一些机构的做法，按每十个软件人员配备两个管理人员即管理成本：
1 ≤ S ≤ 1.2
1.2.5 T(优质系数)
提高软件质量，必然有所开支，即质量成本，对于不同的软件企业来说，其质量成本不尽相同。
软件企业与其他企业一样，也有诚信和品牌等诸多因素，从而增加企业的开支。
目前我们可以按通过 ISO9000质量体系认证和CMM或CMMI的认证来确定，分别取值1.05、1.1、1.15、1.2。
今后建议可对软件企业的资质分为四级。由软件行业协会根据CMMI的认证、品牌、诚信程度等各种因素加以确定。此体系建设还有待进一步探索。
据此，我们综合上述各点：
开发费用/人·月 =(B × 1.476 + B/3 + B/3)× l.2 × T
= B ×(1.476 + 2/3)× 1.2 × T
= B × 2 .575 × T
= B × λ
当T=1.05时，λ=2.7
当T=1.2时，λ=3.09
因此，2.7 ≤ λ ≤ 3.09
对于承接国外软件外包业务，一方面员工的工资较高，另外工作的安排也较难满负荷工作，用此建议R=B/2。因此
开发费用/人·月 = B(1.476 + 1/3 + 1/2)× 1.2 × T
= B × 2.767 × T
= B × λ
当T=1.05时，λ=2.906
当T=1.2时，λ=3.32
因此，2.9 ≤ λ ≤ 3.32
结论：
软件开发价格 = A × σ × τ × B × λ
A：估算工作量经验值
B：软件企业的平均工资/人·月
Q：风险系数l ≤ Q ≤ 1.5
T：复用系数0.25 ≤ τ ≤ 1
λ：综合系数2.7 ≤ λ ≤ 3.09
2. 软件(系统)维护收费价格估算方法
在完成信心工程项目的系统集成和应用软件开发，并交付用户正式运行的一年内，对软件(系统)实行免费维护服务一年。
在正式运行一年后，软件企业应与用户签定软件(系统)维护合同。该合同属技术转让合同，也可属技术开发合同。
根据不同的用户要求，可分四种级别进行软件(系统)维护。
2.1 A级
软件企业派出技术人员常驻用户，解决日常运行中发生的问题。
2.1.1 U(系统建设投资额)
用户需要软件企业维护的系统，该系统建设的投资额。如用户只需要软件企业维护其所开发的应用软件，U就是该应用软件开发费;如用户需要软件企业维护整个系统，包括计算机硬件、软件、网络和应用软件，则U就是该信息工程项目的总投资额。
2.1.2 N(技术人员数)
软件企业派出N个技术人员，常驻用户，因此：
软件(系统)维护费/年 = U × 15% 或 B × λ × N × 12
B、λ参见1.
2.2 B级
软件企业每周七天，每天24小时(即7×24小时)响应，2小时到现场，且每天派技术人员到现场进行软件(系统)性能调试，使之运行处于良好状态。
软件(系统)维护费/年 = U × 10%
2.3 C级
软件企业7×24小时响应，2小时到场。
软件(系统)维护费/年=U × 5%
2.4 D级
用户的信息工程系统或应用软件发生问题，由原承担的软件企业派人维护。
2.4.1 B’
这种维护方式要求软件企业需要保存所有的技术档案，更需要软件企业抽出专人来不断熟悉和全面掌握该软件(系统)的各项技术细节。因此，软件企业的这项支出必然要在维护费用收入中得到回报。
以1.1.3节中的B 作为参数，将其人·月单位改为人·天，以B’表示。
2.4.2 τ’
软件企业如果采用基于构件开发方法，并建立起构件库，则会大大提高软件维护的效率。另外，如果有多家用户运行的系统大致类似，也可有所提高效率。
以1.1.3节中的τ 作为参数，以τ’来表示。因此：
软件(系统)维护费/次=B’ × τ’× n
此次n表示所需要的人·天数。τ’的取值是0.2 ≤ τ’≤ 1。
3. 系统集成价格的估算方法
将整个系统所涉及到的设备、软件、网络整和起来，并能正常地运行，其运行的结果能达到用户建立该系统的目标。这就是系统集成的含义。因此，可以理解为单纯的设备采购和供应并不涉及系统集成，以及单纯的应用软件开发也并不涉及系统集成。
系统集成费应与整个系统的规模、整个系统的复杂程度等项有关。
系统规模往往与系统建设费用密切相关。为了简便计算，以系统建设费用(以U来表示)为参考坐标。复杂程度(以α来表示)可分四种级别来区分。
系统集成费 = U × α × T
T参见1.2.5节
3.1 A级
整个系统涉及到计算机硬件、软件、局域网络，且体系结构在三层次以下(含三层次)。
5% ≤ α ≤ 8%
3.2 B级
整个系统涉及到计算机硬件、软件、局域网络、互联网，且体系结构在三层以上(含三层次)。
7% ≤ α ≤ 10%
3.3 C级
整个系统涉及到计算机硬件、软件、局域网络、互联网以及多种网络接口。
8% ≤ α ≤ 12%
3.4 D级
整个系统涉及到计算机硬件、软件、网络、通信以及各种数据采集设备接口或者与用主系统有接口。
10% ≤ α ≤ 15%
4. 系统解决方案费用估算方法
根据用户所提出的初步需求，软件企业根据以往的经验为之提供整个系统建设的方案，包括需购买的计算机硬件、软件、网络设备和应用软件开发的大体设想、费用估算、进度初步安排、信息化所涉及到的规章制度的一些规划，有时还会涉及信息中心的建设等等。这就是系统解决方案所要完成的工作。
目前国内市场对于系统解决方案是一种智力劳动成果的认识不足，以及国内多数招标公司并不熟悉信息技术，从而更加使得系统解决方案收费变得困难。因此，目前的收费处于过渡阶段。
系统解决方案费用与整个系统的规模、复杂程度等项有关。
系统规模往往与系统建设费用密切相关，为了简便计算，以系统建设的总投资(以U来表示)为参考坐标。
复杂程度就是用户的功能、性能要求复杂性、信息接口的类型和数量有关，以β来表示。
解决方案费用=U × β × T
T参见 1.2.5节
关于β我们参照第3节所列各级。
A级： 0.7% ≤ β ≤ 1.2%
B级： 1% ≤ β ≤ 1.8%
C级： 1.5% ≤ β ≤ 2.2%
D级： 2% ≤ β ≤ 3%
软件开发工时分配的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件开发工时费、软件开发工时分配的信息别忘了在本站进行查找喔。
