对日软件外包精.docx
《对日软件外包精.docx》由会员分享，可在线阅读，更多相关《对日软件外包精.docx（9页珍藏版）》请在冰豆网上搜索。
对日软件外包精
第1章对日软件外包
1.1对日软件外包的发展
全球应用软件外包市场近几年平均每年以29%的速度增长，2005年整个市场规
模将达到389亿美元。
目前全球的软件产值中，三分之一需要通过对外发包来完
成。
软件外包已经成为世界软件产业发展的一个重要趋势。
在这一趋势下，《振兴
软件产业行动纲要》提出，从2001年到2005年，中国软件出口要从年出口7亿美元
提升到50亿美元。
按照预定的目标,2004年国内软件企业将要完成的出口额将达到
35亿美元。
这对于中国软件企业而言的确是个不小的数字。
为了实现这一目标，有
关人士指出，中国企业应积极拓展对欧美软件外包业务，把软件外包做强做大。
但现在美国市场主要被印度垄断，欧洲市场被爱尔兰垄断，中国企业的核心竞争力需要较长时间的积累，而对日软件外包，我们则有优势。
在对美软件外包市场上，中国软件企业与印度软件企业的差距是明显的，从英文水平到签证难度，从法制制度的
不同到对知识产权认识程度的差异，中国软件企业要在对美软件外包市场赶上印度企业还需加以时日。
美国IT从业人员中印度和中国人员的比例是3：
1,中国软件企
业目前做的外包只占日本软件外包的2%多一点。
以英文为主导的软件外包市场正
在逐渐萎缩，并且在这个市场上我们和印度相比竞争优势不明显。
而对日软件外包市场相对印度来说，中国软件企业有地域优势和有限的语言优势，应当成为国内软件外包企业的发展导向。
1.2对日软件外包的现状
对日外包市场潜力巨大，据IDC统计数据,2005年日本IT外包市场规模为164
亿美元，而同年我国来自日本的软件发包量约为5.6亿美元，仅占日本IT外包市场的3.4%。
IDC预测2008年日本IT外包市场将达到23,363亿日元（约226亿美元,2010
年我国对日外包将近40亿美元，占比上升为17.7%。
由此可见我国对日软件外包未来的市场潜力巨大。
国内现有的对日软件外包企业，主要为面向日本资讯科技行业的客户提供外包软件开发服务，而该等客户其本身又是为日本客户或全球客户提供软件开发服务。
也就是一种工程转包性质的开发。
以我现在所在公司为例，从事过制造业项目、
CAD软件工具、证券金融软件、物流软件等等。
1.3对日软件外包的软件开发特点
由于外包客户也是多为软件公司或是大公司的软件开发部分，而且由于是外包软件开发，所以开发层次比较低，或者说不是一个完整意思上的软件开发过程。
根据个人在对日软件开发公司工作多年的经验，总结以下几点特点：
1.技术含量低，从事低层次工作。
通常，软件开发过程都要经历商业建模、需求分析、系统分析和设计、实现、测试和部署等核心流程。
然而，对日外包的开发流程被严格划分开来的，外包客户从
事商业建模、需求分析、系统分析和设计等高层次的工作，然后将设计书发包到国
内,而国内公司仅仅只是
严格依据客户的设计书，将其代码实现并通过单体测试就算完工。
所以，国内对日外包企业只是担当了实现、测试两个阶段的任务。
也有个别项目会担当些简单的设计任务。
2.工期短工作量大
由于国内劳动力相对日本国内廉价许多，许多日本IT企业将开发和测试环节移到中国国内，根据客户的功能设计书或详细设计书，完成开发及测试。
这样即可以降低软件开发成本，又不至于有太大的开发风险，因为设计是日本人自己完成的。
但是，
时常会发生因为客户的设计不合理或不详细或理解不同等等客观原因，无法按照原
来合同中规定的工数完成任务，所以常常要靠加班来争取时间。
3.品质要求咼
谁都想花钱买到好东西，软件外包也是一样，日本公司也想花钱买到更好的客户，具体体现就是提供优质的代码成果物。
然而，由于软件企业的流动性比较大，公司出
于成本考虑，常会雇佣一些经验不足的实习人员直接投入项目开发中，导致品质较低,
而为了弥补品质上问题，又需要用加班的方式来争取大量时间提高质量。
4.文档要求高
有些日本客户公司，实施了CMM3或更高级别的控制标准,同样也要求中国的外
包公司按照其标准实施，当然这样对于国内公司自身管理能力也是一种提高。
但是有些客户公司过于注重文档，而忽视了对于最更本的代码的重视程度。
第2章RUP
RUP是Rational统一过程（RationalUnifiedProcess的简称，它是Rational公司（现
归属IBM公司推出的一种软件过程产品。
从软件过程模式角度看,RUP又是一种典
型的软件过程模式，它以迭代增量式、架构为中心、用例驱动的软件开发方法、采用UML语言描述软件开发过程为主要特征，其中以用例驱动乃是贯穿软件开发始终的方法。
2.1RUP的特点
1.迭代式开发。
在软件开发的前期阶段完全并准确的掌握用户全部的需求几乎是不可能的。
实际上，经常遇到,需求在整个软件开发工程中会不断改变，从而使得软件项目难于管理
而产生较大风险。
而迭代的开发方式允许在每次迭代过程中需求有所变化，通过不
断细化来加深对问题的理解，最终实现完全满足用户需求的软件。
迭代式开发不仅可以降低项目的风险，而且使得软件开发过程具备较强的控制性。
2.管理需求。
完善用户需求是一个渐进的过程，开发人员在开发系统之初不可能完全详细的说明一个系统的真正需求。
RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例
和脚本的使用以被证明是捕获功能性需求的有效方法。
3.基于组件的体系结构。
组件使重用成为可能，系统可以由组件组成。
基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。
RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
4.可视化建模。
RUP和UML结合在一起，对软件系统建立可视化模型帮助人们提供管理软件
复杂性的能力。
RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。
5.验证软件质量。
在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。
6.控制软件变更。
迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱
之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。
RUP通过
软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。
2.2RUP的核心工作流
RUP中有9个核心工作流,分为6个核心过程工作流（CoreProcessWorkflows和3个核心支持工作流（CoreSupportingWorkflows。
尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。
9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
1.商业建模（BusinessModeling
描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2.需求（Requirements
描述系统应该做什么，并使开发人员和用户就这一描述达成共识。
为了达到该
目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决
问题的定义和范围。
3.分析和设计（Analysis&Design
将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。
分析设计的结果是一个设计模型和一个可选的分析模型。
设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化。
4.实现（Implementation
包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组所产生的结果，使其成为可执行的系统。
5.测试（Test
验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。
RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。
6.部署（Deployment
成功的生成版本并将软件分发给最终用户。
描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括:
软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。
7.配置和变更管理（Configuration&ChangeManagement
描绘了如何在多个成员组成的项目中控制大量的产物。
配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。
描述了如何管理并行开发、分布式开发、如何自动化创建工程。
同时也阐述了对产品修改原因、时间、人员保持审计记录。
8.项目管理（ProjectManagement
平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。
其目标包括：
为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9.环境（Environment
环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
环
境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
2.3RUP裁剪步骤
RUP是一个通用的过程模板，包含了很多开发指南、制品、开发过程所涉及到
的角色
说明，由于它非常庞大所以对具体的开发机构和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。
RUP就像一个元过程，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。
RUP裁剪可以分
为以下几步：
1确定本项目需要哪些工作流。
RUP的9个核心工作流并不总是需要的，可以
取舍。
2确定每个工作流需要哪些制品。
3确定4个阶段之间如何演进。
确定阶段间演进要以风险控制为原则，决定每个
阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度。
4确定每个阶段内的迭代计划。
规划RUP的4个阶段中每次迭代开发的内
5规划工作流内部结构。
工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。
最后规划工作流的内部结构，通常用活动图的形式给出。
第3章改进方案
虽然，对日软件外包工程往往不是一个完整的软件开发过程，只是其中一部分或几部分而已，但是并不妨碍RUP在对日外包项目中发挥强大的作用。
上一章节中，分析了如何根绝具体项目特性对RUP过程进行裁剪，以适应不同的软件项目。
本章节将依据裁剪步骤，结合现在公司的项目特点，细化制定适当的RUP开发过程。
.1确定工作流
对日软件外包，通常是根据客户的功能需求书或详细设计书，完成代码实现和测试。
所以只需要实现和测试两个工作流。
结合我公司现在从事项目的特点，简单阐
述一下各工作流。
1.实现
由于对日外包的特殊性，面对客户基本都是日本的IT企业,现阶段都处于较低层次，也就是只负责代码实现和测试，可能也会从事部分简单设计。
所以，根据客户的设计书完成符合要求的代码就是对日外包的主要工作任务。
所以实现工作流也是最重要的工作流。
而且，由于是根据日方的设计从事开发实现，所以除了实现本身的任务外，还有承前的工作要完成，比如:
理解设计书的要求，开发环境搭建，判断设计中可能存在的不合理性等。
而这些问题都可能直接影响到最后是否能顺利完成实现的工作任务。
2.测试
判断开发的代码是否能交付，也就是依靠测试用例了，我方只担任单体测试部分的任务，并将全部通过测试的代码和测试用例书作为成果物交付给日方。
如果，由于
单体测试内容不全面，而在结合测试中发现的问题，将作为Bug报告，再由担当者修正后提交。
以上讲的两个工作流，是现在多数对日外包公司承担的主要任务，当然也有部分
公司可能承接的项目是个完整的软件过程，涉及到9个工作流中的绝大多数，在此不作重点依次展
开。
其实各个项目，由自身特点可以制定出自己的RUP软件过程。
只要实用
就是最好。
3.2各工作流的职责和制品由于是委托开发，客户为了有效控制开发过程和质量，往往是通过各种文档来对项目进行管理和控制。
对日外包开发中，文档的分类比较繁多，规格要求也根据不同公司有不同的要求。
以下列举几种文档，在整个开发过程中起俄作用：
1.功能设计书用户提出委托开发要求，中方根据功能设计书，了解所开发项目的所有需求，并估计工数和项目报价，如果对方
客户对报价没有异议，就正常进入开发实施阶段。
开发小组成员开始一起研究功
能设计，解决理解和实现技术上的所有问题，尽可能避免因设计书理解不足，导致项目失败。
2.详细设计书结合实现技术的特点，通常，客户是不提供详细设计书，而是开发团队根据功能设计书，完成详细设计书，作为实现工作流的前期
成果物，交付日方Review确认，只有通过Review后才能进入到正式的开发实现阶段。
3.代码规约为加强代码具有良好的可读性，需要通过在开发前期就作好代
码规范的教育工作，规范的代码才能有效提交代码的品质。
4.开发环境构建步骤
说明书外包开发通常客户是将完整的项目拆分成多个相对独立的模块，分别发包
给一个或多个外包开发公司开发，所以需要提供详细完善的开发环境构建说明书，便于开发团队尽快熟悉环境完成开发任务。
5.代码代码程序当然是所有制品中最重要的，其质量直接影响到项目的成功与否。
由于是委托开发，全部都是根
据客户提供的功能设计书来完成代码开发的，所以往往可能因为设计书理解不
足，或设计书内容存在错误等外部因素影响代码的质量。
而一旦存在疑问时，就应该及时通过QA方式向日方确认。
最后在完成全部代码实现后，需要和日方一起
Review全部代码。
总之，项目成败就取决于代码的质量如何了。
6.代码目录结构
说明书此文档只是一个说明性的文档，用说明各个代码文件的目录结构，编译环
境的设置等相关具体内容。
方便客户拿到代码文件后能尽快确认代码的正确性。
6
7.测试用例书测试用例书也是整个开发过程中又一个关键，也是保证代码质
量的一种有效手段。
通常分为正常系和异常系两大类测试用例，判断程序的正常执行结果是否符合需求，是否具有一定的判错能力等。
与代码一样，测试用例书也是需要提交日方客户Review确认后，再能进入测试阶段的。
8.测试数据测试过程用到的所有数据，可能因为测试数据的局限性导致有些Bug没有被发现，那
就可以依据现有的测试数据内容判断测试是否全面而且有效了。
9.测试结果书依
据测试用例书，对最终的代码程序进行测试，并全部确认无误后，填写测试结果书提交给日方客户。
10.辅助工具报告为了保证代码的质量，通常还会使用一些自动化测试工具，对性能，漏洞，规范等方面进行测试，根据测试的结果报告，尽可能修正后，将最终的报告书也需要提交给日方客户。
3.34个阶段的划分RUP将
整个开发过程划分成初始、细化、构造、交付四个阶段。
每个阶段中都包含着多
个工作流，只是工作的重点不同，同时还包含着复数个迭代过程。
迭代次数和划分时间也许无法事先预计，但是可以大致规划，再根据具体情况，灵活变动修改的。
以下将以四个阶段为单位分别展开阐释。
1.初始初始阶段主要完成的任务
是：
掌握功能设计书，熟悉开发环境，估算项目工数和规模。
似乎初始阶段的任
务并不难，但是其估算结果的正确与否会影响到最后的实现情况。
所以需要全面
而准确的了解功能需求，才能避免过大的偏差。
初始阶段相对任务比较轻，一般一次迭代就能完成。
在此迭代过程中也可以尝试实现部分代码，了解具体的项目难度，以便准确的估算。
2.细化细化阶段主要任务是：
作成详细设计书和测试用例
书，并完成部分代码的实现。
详细设计书和具体实现方法是有密切联系的，所以
应该在写详细设计书的同时编写并测试通过部分代码，以验证设计的可行性。
而
现在多数项目中存在的问题是，大家并不能意识到迭代开发比如，详细设计时，
也会尝试调查，的重要性，还不能掌握迭代开发的手段规避和控制风险。
但是调查时候写的代码可能并不是最后要交付的代码，可以认为那是一定程度上的资源浪
费。
所以应该加强开发团队在细化阶段是，注重迭代开发，使得项目不断完
3.
善。
试。
大。
构造构造阶段主要任务是：
依据详细设计书完成全部代码实现，并通过测
这个阶段应该相对比较轻松，因为详细设计书已经基本确认，应该偏差不
但是也可能会出现一些未知因素导致代码实现过程不顺利。
所以，构造阶段
一般都被分为两个或以上次迭代。
我认为加强团队对于迭代的重要性意识很重
要，有必要让团队成员们都意识到迭代要进行到什么程度，要完成哪些任务等
等。
4.交付交付阶段顾名思义就是要完成整个项目的全部制品，提交给客户方。
这个阶段往往会发生很多返工的情况，因为开发团队可能应该经验不足等原因，首先无法通过项目管理者的审核关，而不得不修改甚至是返工。
首先，项目管理者对项目的审核是必要的，也是有利无弊的，但是应该考虑将审核分批前移，而不是全部只在交付阶段进行。
比如在四个阶段中分别设立审核阶段，这样就可以有效避免在交付阶段面临的返工风险。
实施、第4章实施、总结根据以上的分
1.对开
析，对现有的软件过程进行了改进和实施，具体从以下几个方面进行的。
发团队进行RUP相关知识的教育。
通过学习RUP,让大家认识到现有软件过程的不足导致交付延时等风险。
2.让大家意识到迭代过程对于整个软件开发过程的重
要性。
并尝试在实际项目中运用迭代方式，层层递进，逐步化解可能存在的风险问题。
3.引入checklist，让团队成员可以自我检查，提高项目质量。
4.引入自动
有测试
单元测试方式，加强开发与测试并行的理念。
每个迭代都有代码实现并都
结果，这样步步为营的开发方式，极大程度上保证了开发的质量。
通过以上改
进，现在项目开发更具可控性，也大大降低了开发中可能的风险。
可见一个合适
的软件过程是多么的重要。
8
升级会员 