摘 要： 软件外包是近几年国内发展迅速的产业。一般是委托方担当系统的概要设计，中方担当详细设计、编程、单体测试以及集成测试。由于地域、语言、文化等差异，如何保证项目的质量，时常成为困扰企业的难题。在实际的面向中小企业统合管理系统项目的开发基础上，通过分析影响实际项目质量的主要因素，总结并提出了在不写详细设计文档的情况下，加强概要设计的复审，加强沟通环节以保证软件项目质量的一些观点。这种方式下开发的系统其品质得到了较好的控制并取得了客户的认可。
关键词： 软件外包； 项目质量； V模型； offshore; 瀑布模型； 概要设计； 详细设计

    软件外包就是企业为了专注核心竞争力和降低软件项目成本，将软件项目的全部或部分工作发包给提供服务的企业以完成软件需求的活动。一般是委托方与承包方不在同一场所工作。
    目前在国内,离岸软件外包（offshore）是一个发展迅速的行业,虽然软件的设计、制造、测试都已经流程化,并且运用软件工程来规范,但是由于语言、文化、地域等差异,使得软件开发的质量得不到保证。以下是在实际工作中总结出的为控制项目质量而需要着力解决的几个比较重要的方面。 
1 项目计划
    制作项目计划书，如表1所示。

    项目负责人在项目立项前就进度、人员配备、配置管理等各项活动进行计划，并形成文档。系统开发计划书由系统概要、开发体制、进度计划等构成。
    项目计划书是跨部门多人沟通的文档，它有助于项目负责人在项目启动前，将项目中应有的资源及风险做提前的部署与对应，并为项目的独立监查及质量跟踪提供依据。
2 沟通的管理
    项目计划阶段除了要将中方与日方的角色与职责明确定义外，双方的作业流程也要明确，特别是窗口的沟通体制要明确。目前对日外包项目比较多的是图1所示的沟通管理作业形式，中方的作业范围是从详细设计开始，编程、单元测试及集成测试。中方的BSE起到双方沟通的桥梁作用，沟通的方式可以采用电子邮件E-mail、电视会议、即时聊天工具、使用开发的管理工具等。由于外包开发的设计人员与编程人员不在同一地点，因此沟通的准确与及时就显得格外重要。项目组成员的所有疑问都应该使用QA表进行统一的管理，QA表中记录了本项目的所有开发人员所提出的疑问及待确认项目以及日方担当人员的回答内容；特别是对于共通的问题开发全体人员都要周知，这样有助于所有开发人员对项目整体的理解并且便于统一的管理。

3 影响项目质量的主要因素
    除了要做好上述的项目计划、做好沟通管理外，实际的项目经验是开发周期(是否过短)、所接收的客户设计书的质量、设计书的变更情况、业务的复杂度、开发人员的技术水平、项目负责人的管理能力、是否有新技术的风险、开发的规模(规模越大质量与成本的风险就越大)等各因素都直接影响到最终项目的质量与成本。影响项目质量的因素繁多并且很复杂，但比较重要的有以下几点：
    (1)日方的概要设计书的质量
    在软件的整个生命周期中，软件产品的质量首先取决于它的设计，设计质量控制在全面质量管理中也是非常重要的一个环节。据统计，设计错误占软件错误的63%,编码错误仅占37%[1]。在编程之前，进行概要设计的复审(即设计Review)很重要。
    是否变更很频繁,业务的描述是否详细,概要设计书的文档格式是否标准化。复杂的逻辑判断要尽量用图形或表格，尽量使用数学语言(A=B)表达。
    图2是针对已完成的6个项目(每个符号代表一个项目)，对影响项目的部分因素进行分析评价的结果。从中可以看到，日方设计书的质量、变更以及管理情况对项目的质量有较大的影响。

    (2)开发团队人员的配置也很重要。PL(项目负责人)、BSE以及SE的项目经验，BSE要对项目有整体的理解并与日方设计人员进行有效的沟通；SE对设计书复审、提QA并做集成测试；PG做代码编写及单元测试。从所做项目的质量分析结果来看，系统Bug的20%左右是设计书理解有误所引起的，因此加强沟通确认设计书也很重要。
4 实际项目的开发流程
    “瀑布模型(Waterfall Model)”是由温斯顿·罗伊斯(Winston Royce)于1970年提出的，直到20世纪80年代早期，它一直是唯一被广泛应用于软件开发领域。瀑布模型将将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等6个基本活动。
　    瀑布模型的特点是：简单，分阶段，阶段间存在因果关系，各阶段完成后都有评审，要求预先确定需求。适用的范围是易于完善定义且不易变更的软件系统[2]。本阶段的成果作为下一阶段的输入；对本阶段的工作进行评审，若本阶段的工作得到确认，则继续下阶段的工作。只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。通常它适用于需求分析做得比较好的系统，例如二次开发系统等。
    瀑布模型是开发模型，而V模型是测试模型，V模型[3](见图3)是最广为人知的测试模型。
    单元测试所检测的是代码的开发是否符合详细设计的要求。集成测试检测此前测试过的各组成部分是否能完好地结合到一起。系统测试检测已集成在一起的产品是否符合最终用户的需求。一般项目开发的过程顺序如表2所示。   

    面向中小企业综合管理系统的开发中，日方为节约开发成本、缩短开发周期，有些项目没有书写详细设计的时间，因此实际项目的开发过程如图4所示。框线内的部分是日方担当，其余部分由中方公司担当。此过程是分阶段同时并行作业的，即不是日方概要设计全部完成后再进行开发，而是在整体的数据库DB设计、整体的功能一览表、一部分业务功能的概要设计完成后就进行开发。在概要设计中要表达用户操作系统时的交互画面的设计，画面项目与数据库表中字段的对应关系以及所要实现的业务等要表达清楚。

    这样做的好处是：在开发的同时做下一阶段的概要设计，可缩短项目整体的周期，节约成本；另外在项目开发过程中，经常有概要设计的变更，概要设计频繁变更时，详细设计就要频繁地对应，实际的情况是最终很难保证两套设计文档与代码的一致，结果都是只能够维护一套文档。
    不利点是：由于缺少书写详细设计的环节，为了保证项目质量，就必须追加概要设计书的复审环节。同时，概要设计文档的书写格式也要规范化，具体的措施是:
    (1)在开发前，项目整体的共通要求必须要明确,包括交互界面的共通要求等。
    (2)用统一的概要设计的文档格式，画面项目与数据库项目的对应、业务功能的描述等要明确。
    (3)系统的命名规约、函数接口的命名方法以及共通函数等共通事项必须事先定义。
    (4)编码之前,必须要有SE的概要设计复审及QA确认环节。检查概要设计的漏点及错误等，并通过QA确认，在编码之前，将这些错误及不明确点解决掉。事实上，在开发过程中发生的许多概要设计的变更是由SE在概要设计复审以及在PG编程前发现的概要设计的误记或考虑不足以及设计错误。
    目前，实际开发的项目许多是采用图4所示的开发过程及图5所示的测试模型。经验证，项目整体的质量得到了较好的控制，并且已满足客户的要求。

    实践证明，面向中小企业开发的统合管理系统的项目中，不写详细设计，在开发的环节中增加概要设计的复审；同时，开发前统一定义好共通函数及接口、命名规范等同样能保证项目的质量。外包开发中，沟通环节(即QA确认)实施是否顺畅，对项目的质量影响较大。
参考文献
[1] 张海藩.软件工程导论（第三版）1.2.1[M].北京: 清华大学出版社,1998.
[2] 谭庆平，毛新军，董威.软件工程实践教程文献题目[M]. 北京：高等教育出版社,2009.
[3] GOLDSMITH R F. 软件测试:V模型，还是X模型[Z]. 开放软件测试研究，2003.