软件分包基础知识.doc

软件分包基础知识

Hjli-软件分包的策略
分包的原因：一般，是由于工期限制，从而决定了在既有资源的情况下项目不能如期完成，因此要考虑分包。
分包的总体策略：
将跟自己主业无关的业务分包；将自己的不擅长的业务分包；将附加值低的业务分包；将会对自己业务造成负面影响的业务分包。
分包的时机：在规划阶段，做好WBS及活动网络图后，分析得出关键路径；分析关键路径上哪些必须自己做，哪些可以分包出去；
分包考虑的原则：
1、非关键路径上的活动，每一个都可以分包出去；
2、关键路径上的活动，要进一步分析；首先看分包出去会不会对自己企业的核心技术、核心机密造成影响，若无影响则可以分包出去；其次分析待分包出去的活动会不会对以后的项目造成影响，若无也可以分包出去。

如何进行软件分包即软件子合同管理
如何进行软件分包即软件子合同管理
开始是比较好的办法。在软件能力成熟度模型中，定义了软件子合同管理要达到的目标，定义了实施所须的承诺（Commitment）和能力（Ability），定义了进行软件子合同管理应该有的活动，国内已有不少书籍或资料对此进行了翻译与介绍，这里就不再赘述了。但是，就像SEI对软件能力成熟度模型其他的关键过程域的描述一样，只是给出了“应该作什么（What）”，而对“应该如何做（How）”这一关键的、大家都关心的问题毫无解释，很多想实施CMM的企业和组织都感到无从下手。我们参考了一些国外的资料，结合具体的实践经验，提出了一个框架性的描述。由于篇幅所限，这里只列出软件能力成熟度模型中软件子合同管理13个活动（Activity）的具体操作办法及其相应产品（PRODUCT）：
活动1：按照文档化的规范定义和规划子合同工作 任务： 确定需求
·        建立专门技术小组确定产品模型
·        确定资金来源、资金类型及其有效期限
·        确定开发的最后期限
·        从技术角度出发安排开发进度
·        对要进行的工作做书面定义
·        将开发所涉及的需求及需要的支持知会制定合同的有关官员
·        RFP开发
·        具体开发目标的分析及汇总
·        控制可资利用的开发资源，使其服务于相应的开发队伍
·        对于需求分析及可能的实施方案进行最后评估，最终制定开发策略。
·        对项目经理汇报开发计划，以获得技术批准。
·        对制定合同的有关官员汇报开发计划，、以获得最终批准。
成果：
·        目标分析
·        开发计划
·        评估方案
活动2：按照文档化的规范根据承包商完成工作的能力选择承包商 任务：
·        根据评估方案对开发计划书进行评估
·        依照评估方案汇总评估结果
·        涉及审计、协商、方案选择时，给予决策人员所需的支持。
·        进行商务谈判 选择订约方
成果：
·        签订合同
活动3：与承包商之间的协议作为管理子合同的基础 任务：
·        引述工作描述(SOW)，监督合同各方履行合同义务。
·        分析评估合同条款的进一步解释说明。
·        为决策者提供恰当贴切的阐释说明。
成果：
·        合同条款的解释说明.
活动4：评审和批准文档化的承包商软件开发计划
任务：
·        审查分析SDP的初始方案
·        给出修改建议
·        更新SDP方案
·        批准更新后的SDP方案
成果：
·        获得批准的SDP方案
活动5：将软件开发计划用于跟踪软件活动和通信状态
任务：
·        开发进度报告、备忘录、开发任务清单等等
·        将SDP方案同时及开发情况进行分析比较。
成果：
·        最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
·        通过审批的开发进度报告、备忘录等。（有可能未获通过）
活动6：按照文档化的规范判定对承包商的工作陈述、子合同条款、条件以及其他约定的更改。
任务：
·        对需要进行的修改和需要做出的变动进行审查验证。
·        同合同签订方进行协商。
·        批准实施修改。
成果：
·        合同的修改
活动7：双方的管理者一起执行定期的状态或协调评审
任务：
·        定期审查开发状况/合作情况
成果：
·        最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
·        通过审批的开发进度报告、备忘录等。（有可能未获通过）
·        审查结果归档。
活动8：承包商参与定期技术评审和交流
任务：
·        从技术角度定期审查开发状况
成果：
·        最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
·        通过审批的开发进度报告、备忘录等。（有可能未获通过）
·        审查结果归档。
活动9：按照文档化的规范在所选择的里程碑处进行正式评审，评价承包商的软件工程完成情况与结果
任务：
·        进行定期的、正式的工程开发审查。
成果：
·        最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
·        审查结果归档。
活动10：软件质量保证组按照文档化的规范监控承包商的软件质量保证活动
任务：
·        从软件质量保证法（SQA）出发进行质量验证。
成果：
·        软件质量保证评估报告。 最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
活动11：软件配置管理组按照文档化的规范监控承包商的软件配置管理活动
任务：
·        从软件配置管理（SCM）角度出发进行配置管理验证。
成果：
·        软件配置管理评估报告。
·        最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
活动12：按照文档化的规范进行验收测试
任务：
·        产品验收
成果：
·        最新的开发任务清单，指明已完成的、开发中的及尚未进行的开发任务。
·        通过验收的软件产品。（有可能未获通过）
·        产品评估报告。
活动13：定期评价承包商的性能，并与承包商一起评审评价工作
任务：
·        评估分析合约方的开发表现。
成果：
回馈、评价

如何进行信息技术外包管理？
项目建议书是外包管理中最重要的文档，它既是企业选择外包业务的依据，也是企业选择外包服务商的依据，还是续后的监控、协调和管理外包过程的依据。

　　制订项目建议书首先要定义企业信息技术需求，并据此对所需的硬件、软件、服务、成本与时间等提出要求，这些要求必须是可以量化和测度的。

　　外包项目建议书大纲

　　一旦外包项目建议书制订出来，就要设法通知和鼓励外包服务商投标和相互竞争，要对外包服务商的标书进行评估，要平衡外包服务质量与外包成本，进而选择相对理想的外包服务方案，与一个或多个外包服务商签署外包合同。

　　外包合同也是外包管理最重要的文档之一，是控制外包服务商进而降低外包风险的主要杠杆。

　　围绕外包合同管理，主要涉及选择外包服务商、制定外包合同、签署外包合同、更新或终止外包合同等事项。

　　签署外包合同之后，企业信息技术部门的主要任务就转变为监测、评估和控制外包服务，协调最终用户和外包服务商之间的关系，保证外包服务到位，确保本企业的利益不受损害。

　　外包服务监控

（1）外包管理组织建设

　　企业与外包服务商之间的整合问题。整合可能发生在企业与外包服务商之间的界面、双方的信息技术部门乃至业务单元之间、双方的人员之间、双方的系统之间等多个层面。整合议题包括外包服务的规划、时间表的制定、管理结构、管理控制机制、管理技能、人际关系、交流和争议解决程序等。

　　外包双方的人员交流是一个敏感的问题。根据合同，企业信息技术部门的一些工作人员需要调配到外包服务商处工作，但具体哪些人员应调配出去、哪些人员应留下来、哪些人员应终止聘用合同，对于企业来说是一个相当伤脑筋的事情。对此，企业要通过充分的交流和适当的激励政策，劝说一些关键人物到外包服务商处而不是竞争对手那里工作，同时将最需要的人才留在企业内部。

　　对于留下来做外包管理的人员而言，主动学习和积累外包管理知识与经验并从而提升自己的管理能力是非常重要和必要的。外包管理人员需要掌握协调、沟通、技术、财务、运作、合同管理、妥善解决争端等诸多方面的技能，与外包服务商的高层决策人物建立良好的私人关系，学习和熟练运用原则性与灵活性相结合的管理方法，善于把握外包的信息技术服务的方向。

　　（2）外包服务过程管理

　　作为一个独立运行的企业，外包服务商的行为必然是受利益最大化原则驱使的，这就不可避免地会与企业的利益发生冲突，为此，必须加强日常的面对面的交流，随时校正外包服务商偏离合同的行为，为双方的利益寻求一个平衡点。

　　监督、协调和控制外包服务商的行为需要高超的管理艺术，一方面要严格坚持合同条款，另一方面又要提供足够的灵活性并自始至终强调合作。事实上，作为合同条款起点的企业信息技术服务要求是不断变化的，企业信息技术的外部环境特别是信息技术本身也是不断变化的，对外包服务商的性能要求还是不断变化的，企业必须考虑到这些不确定性因素，并及时与外包服务商和企业内部的信息服务用户包括企业的高层决策者进行沟通，力争在发展中解决问题，维护企业的利益。

　　合作是外包服务管理过程的主题，合作的前提是积极而充分的交流。合作有积极合作与消极合作之分。积极合作是通过与外包服务商共享企业理念、提供激励、与外包服务商建立良好的私人关系、协助外包服务商建立信誉等途径而实现的，消极合作则是通过经济和法律制裁来实现的。企业应尽可能谋求积极的合作，同时建立双方认同的争议解决机制，妥善解决可能出现的争执。

　　（3）与外包服务商建立合作伙伴关系

　　企业与外包服务商之间的关系粗略地可以分为两种类型，一种是市场关系即双方的合作主要建立在外包合同的基础上，另一种是合作伙伴关系即双方的合作建立在相互信任和资源整合的基础上。与外包服务商建立合作伙伴关系有利有弊，有利的地方在于通过更紧密的合作企业能够获得某种形式的竞争优势，不利的地方在于更多的交流与整合提高了合作的成本，所以，建立合作伙伴关系的必要前提是由此获得的利益必须高于成本和风险。

　　合作伙伴关系一般建立这样的基础上：相互依赖、彼此信任、长期合作的理念、平等交流的意愿、风险共担的意识、良好的信誉、可量化的性能测度标准、协商解决问题的机制、协同工作的过程等。

　　合作伙伴关系要经得起时间的考验，不要简单地与外包服务商建立合作伙伴关系，要平衡回报、风险和成本，要培养双方的信任，然后再考虑合作伙伴关系。如果环境发生了显著变化，合作伙伴关系已经不能够带来竞争优势甚或成为负担，要果断地改变彼此的关系。

分包的控制与管理

软件分包的财务处理
有关软件分包进来的发票该入什么科目？
2011-12-30 12:16 提问者： tsrzhaozy | 浏览次数：88次
我单位是软件服务的公司，我们有个项目，其中的部分分包出去了，我给客户开的是软件服务费发票，那么我分包的那家公司也给我开的是软件服务费，那么想问一下我进来的这部分软件服务费该确认成本了还是确认成费用，请高手指点。我来帮他解答 输入内容已经达到长度限制还能输入 9999 字插入图片删除图片插入地图删除地图插入视频视频地图不登录也可以回答
参考资料：提交回答取消
2011-12-30 12:45 满意回答 进来的这部分软件服务费当然确认成本了。追问那具体的分录怎么做？我以前都是走的销售费用。
回答借：主营业务成本—外包部份（或外包服务费）
贷：银行存款或现金
追问这部分能直接确认成成本吗？是地税的服务费发票，但是如果那样的话，是不是我应该给客户开的就是增值税发票了？有点糊涂。请指教。
回答软件服务开的是地税发*票，不能开增值税发*票。
追问那我以前的都走的是销售费用，您说能修改吗？
回答可能调整
借：主营业务成本
贷：销售费用
追问是直接把销售费用转到主营业务成本里了，还是说先把销售费用冲红然后把对应的金额借：主营业务成本了？
回答两者都可以。

参考--关于外包的一些讨论
外包的利弊
外包的优点：能获得组织没有的技能或技术：公司在技术 方面领先，一般不会考虑外包；n
在经济不景气时，解雇供应商或合同工，可 以增加员工的工作安全感只要条件充分，可以马上启动项目有可能缩短项目的整个进度：
n
供应商可以提供可以提供可重用的部件软件库，或花费精 力开发这些重用软件库。
n供应商能投入更多的开发人员，而起他们的开发人员比自 己的人员肯主动超时工作
n
供应商可能比你有更多的经验：需要一份高质量的需求说明，这对合同有利减少功能蔓延：供应商对成本的变化非常敏感可以联合一位信誉良好的供应商来完成项目
n
有可能以较低的费用来完成项目
n
如果天真的认为供应商的员工资源比较便宜，可以降低成 本时，需要参考外包的弊端
当与供应商合同终止时，供应商会带走项目的一些关键技术。
n
供应商选定的为你工作的员工表现比预期的差
n
在项目中途，供应商可能用其他项目的人员来代替当前项 目的员工，让你的项目承担巨大的风险
n
与许多公司相比，供应商的人员变动更加频繁，如果关键 员工离开，会对项目造成消极影响
n
你对供应商员工的活动的直接控制权比你预料的要小得多。
n
供应商可以获得某些有关你项目和公司得比较敏感得“内部”信息，而这些信息只能由本公司员工知道。

如何签订外包合同
制定和分发需求方案
需求方案的完整性和收到的投标建议书的完整性之间有 着直接的联系
n谈到供应商的工作质量，你要求什么，就能得到什么， 但是一定要在需求方案中提出要求！
n
代码缺陷（KLOC中的缺陷数）
n
交付日期（完整交付所有工作的日期）
n
切勿由于创造性的想法而牺牲质量
n
需求方案分发给供应商之前要首先得到组织的一致同意
n
项目小组的评审
n
可能会涉及到：开发、出版物、测试、财务和质量保证
n
首要原则：重要的事情一定要写下来！
采取激励机制
n合同：规定日期，系统测试缺陷数，交付顾客使用后发 现的缺陷数等等
n奖金：提前完成，缺陷小于数％对应与相应的奖金数
n罚款：每个月不能按时交付代码，缺陷大于数％对于相 应的罚款
n
为高质量设定高额的奖金（30％）是合算的：
修复客户的缺陷n
安抚顾客的不满n
延期交货造成的损失n
所有的合同都应该有包括惩罚机制在内的金钱激励机制
供应商制定和提交建议书
建议书中应该有一个明确的项目进度计划，包括
要从事的活动
每项活动的负责人
每项活动的相关性（前导活动）n
每项活动的计划开始和终止日期n
合同要求交付的产品和交付日期n
项目进度计划后的设想
值得注意的其他责任n
评审产品说明、出版物内容计划、质量计划、测试 计划和测试脚本等项目文档n
参与执行设计审查n
评审产品说明等控制文档的更改n
处理测试阶段出现的问题n
合同经费使用计划
n
以特定里程碑的完成为基础，明确对供应商的费用支付 方式：预付比例，阶段付款比例等等

选择供应商
选择供应商n
管理方面的考虑n
技术方面的考虑n
一般方面的考虑n
经验：n
在评估供应商的建议书时不要自以为是，有疑虑的 地方要询问供应商n
最低标价并不是选择最佳供应商的必要条件n
组成委员会，制定评估表
协商、签订和执行合同
详细定义产品的验收标准n
在工作说明中事先说明产品售出之后的维护问题n
维护时间的长短：一年？项目结束？n
客户发现问题时，谁来鉴定并确认是否来自供应商的 那部分产品？n
修复供应商产品缺陷时，供应商应该在费用上面负什 么责任，你公司应负什么责任？
为了维护其产品，供应商要使用那些硬件、软件和工 具？由谁负责购买和维护这些设备？
管理外包风险
考虑距离因素n
沟通：语言问题n
时差：良好的通信网络n
出差：出差的时间和费用n
供应商国家的特征：政治经济条件，专利，版权，知识产权 法等等。n
预计并计划问题的升级n
与供应商意见不同时，合同中应该列出算法解决问题的过程 和方式，避免出现僵持状态。n
定期度量执行情况n
每周跟踪供应商的工作进展和存在的问题n
记录会议内容并确认n
签订合同需要考虑的其他问题[1]
对项目失去可视性n
定期进度评估
n
专门技术流出公司n
外包的产品是否为公司的商业核心n
松懈士气n
给本公司的开发人员增加了危机感：没有开发能力n
对进一步开发失去控制n
开发人员不愿意去读供应商的源代码n
合同上的限制
损害公司的机密信息n
明确知识产权n
更换供应商n
供应商表现不佳n
定期监控，防止事态恶化n
供应商破产等因素n
分发原来的供应商的工作给其他的供应商
雇用合同工的常见问题
工作规则n
加快让其了解组织的工作规则n
建议：在正常情况下，不允许其在不受监督时自由出入办公地点n
完全融入集体n
和正式员工遵守同样的规则n
定期跟踪其工作进展n
让其清楚知道谁在领导他们n
在需要时，提供各种培训和教育，但是过多的培训会降低 他们的生产率n
奖金n
尽早发现不胜任的合同工n
不要二次雇用不胜任的合同工（建立数据库）