1.5 软件外包的一般流程概述
软件外包是一种软件开发项目的活动，因此按照软件工程的一般规律，一个软件项目通常要经历需求分析、设计、编码、测试、交付、维护等一系列的阶段，伴随这个软件生命周期的还有商务活动、项目管理和质量保证活动、信息安全管理的相关管理工作。
下面将概要讲述软件项目的开发周期及相关的活动。
1.5.1 项目接洽
软件外包项目的需求，来自开发组织之外，因此，项目的需求和来源是项目启动的原始依据。当一个企业根据自己的生产和经营情况，需要应用IT技术进行信息处理，或对原有的信息处理系统进行升级改造时，就产生了软件需求。如果要将软件开发任务发包给外包的专业软件开发公司完成，则内部的信息管理部门应做好了必要的准备工作，如软件需求的大致内容、目标范围、可行性分析报告、费用预算等，经过了高层管理者的批准，才能发布招标信息，进行发包工作。
一般来说，企业发包软件采用两种方式发布软件外包信息，一种是通过媒体发布招标信息，另一种是直接在有良好合作关系的软件公司范围内选择合适的开发商。
软件开发商一般通过市场公开信息，收集到有软件需求的企业，通过销售人员与技术人员的配合，与发包方进行项目接洽。如果是长期合作的客户发来软件需求，一般通过已有的项目负责人先行进行接洽，弄清基本需求后，在公司内经过研究，符合公司的经营策略，能够胜任此项工作，则组织合适的人员参与项目初步调研，形成软件需求分析报告和可行性报告。
项目接洽属于商务活动的范围，但是与技术相关性很大，因为洽谈项目必须就软件的功能、开发技术、开发环境进行商谈，这是软件外包项目的特点所致。因此营销人员在软件项目洽谈中，必须具备一定的IT应用技术基础和一定程度的解决方案咨询能力，完全脱离软件技术的销售，难以达到理想的效果。
曾经有过不懂IT技术的销售人员，到客户现场后，满口答应可以为客户提供满意的解决方案，但是回公司后，经过与技术人员沟通，发现不完全具备开发客户需求的软件的能力，结果再跟客户沟通时，就非常被动了。此种情况下，也会发生销售人员与技术人员之间的矛盾，销售人员对销售业绩负责，而技术人员对实现的结果负责，如果二者没有相互紧密地合作，则难以达到配合默契的程度。
1.5.2 需求分析与报价
当销售人员或者项目负责人，与客户方面就项目进行了洽谈，被接受作为候选的开发商后，技术人员可以到客户现场进行较详细的项目需求调研。调研的内容，既要作为将来项目开发的范围也要作为预算的依据。在软件外包协议没有签订之前，需求分析的结果，主要用于对工作量和技术要求的分析，并以此作为项目费用预算的依据。
目前软件项目的报价单位，基本上以工作量为主，也就是根据需求和项目范围，采取多种方法来评估工作量，工作量的单位是人月，即一个人干一个月的工作量级。根据技术难度和市场价格，确定一个人月单价，软件外包项目的总预算即为预估的总人月数乘以人月单价。
有很多专著对软件项目的报价进行了论述。但是，无论何种方法，都存在各自的优点和缺陷。因为软件项目是人的脑力劳动，技术含量很高，劳动成果的表现形式虽然是程序代码，但是各阶段的成果还是因人而异的，而且水平和质量相差很大，即使是相同质量的结果，劳动效率也有差异。所以要准确评估软件项目的费用，是一件比较困难的事情。
1.5.3 项目启动与项目管理
项目启动不是一个项目的开工仪式，而是项目开始阶段的一系列活动。项目启动本身属于项目管理的范畴。但是由于项目启动的重要性，因此将它单独阐述一下。
项目启动包含的主要活动如下。
（1）由项目的承担组织高层管理者宣布项目经理及其职责，并以文件的方式正式任命与发布。
（2）由项目经理编写项目章程，该章程将项目的背景、目标、项目组织结构及成员、主要角色职责、项目范围及相关条件和约束、项目总体计划（预计开始日期、预计结束日期）、项目风险及其对策等做出明确说明。项目章程作为下一阶段管理过程的依据，为整个项目定下了总体框架。
（3）正式的项目启动会议和仪式。
项目管理包含了项目从启动到结尾全部内容的管理过程，是为了使软件项目能够按照预定的成本、进度和质量顺利完成，而对人员、产品、过程和项目进行分析、监控和管理的活动。项目管理活动贯穿整个项目进行的过程。项目管理的内容主要包含如下几个方面：人员的组织与管理、软件度量、软件项目计划、风险管理、软件质量保证、软件过程能力评估、软件配置管理等内容。
1.5.4 组织开发团队
软件项目的开发，最重要的是人的因素。开发团队中人员的素质、技术水平、组织的文化、团队合作的状况、人员稳定性和积极性等都是关乎项目成败的重要因素。现代的软件多数都是规模庞大和复杂的，由一个或几个软件技术精英单独在短时间内完成的可能性已经很小了，因此一般情况下，软件开发需要由人数较多的团队来完成。
软件开发团队是一定数量的个体成员组成的集体，包括组织内的成员、客户相关人员、供应商和其他与项目有关的人员。团队的含义就由若干人员组成，承担一个共同的目标，在项目经理的领导下，为实现项目目标而努力工作的群体。
组织和管理开发团队，是项目管理的主要工作，并且始终贯穿于整个项目生命周期。人员是项目的最活跃因素，也是最关键因素，因此如何组建开发团队，是项目经理和高层首先要考虑的问题。
组织开发团队的首要任务，就是在组织内选用相关的人员，对于有一定规模的项目（50人月以上），参与的人员包括项目管理人员、技术开发人员、质量保证人员、其他辅助人员（如国际软件外包项目的翻译人员、专用设备的维护人员）。
在项目生命周期内，各个阶段所需要的人员角色和数量是不同的，因此在项目团队组中，人员是陆续有进有出的。有的人员工作不是全职而是兼职的。这些动态变化的状况，应该在项目计划中有预先的准备和规划。
根据项目的要求组建开发团队时，要做好团队人员计划，即项目人力资源配置计划，明确各类人员的角色和职责、进出项目的日期。该计划需要项目经理进行管理和维护，根据项目的进展、项目内容的变更或项目团队出现的各种情况，不断进行计划的调整，保证项目的顺利进行。
项目团队的管理，在人文方面，还要注意团队文化建设，一个良好的团队文化，可以促进项目的内部沟通和合作，便于技术交流和问题的及时反馈。文化建设从根本上来讲是团队管理者的思想。不同的管理者有不同的做事理念和风格。虽然管理者的管理风格各不相同，但是以人为本是管理好团队的根本原则，尊重每一位团队成员，鼓励任何成就，承担管理者的责任而不是推卸责任，将对团队建设起到非常良好的作用。
1.5.5 软件工程活动
软件工程活动是项目启动后，进行项目开发的过程中一系列的活动。软件工程作为一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科，已经发展了几十年。但是软件工程一直以来始终缺乏一个统一的定义，很多学者、组织机构都分别给出了自己认可的定义。下面分别概述一下这些软件工程的定义。
IEEE在软件工程术语汇编中的定义：软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件，同时对这些方法进行研究。
ISO 9000对软件工程的定义：软件工程是输入转化为输出的一组彼此相关的资源和活动。
《计算机科学技术百科全书》中的定义：软件工程是应用计算机科学、数学、逻辑学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本和改进算法。其中，计算机科学、数学用于构建模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。
目前社会上比较认可的一种定义认为：软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最后的技术方法结合起来。
软件工程的内涵，就是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。从软件开发的观点看，它就是使用适当的资源（包括人员、软硬件资源、时间等），为开发软件进行的一组开发活动，在活动结束时输入（即拥有的需求）转化为输出（最终符合用户需求的软件产品）。
软件开发过程作为一个工程，大致有3个阶段。
（1）定义阶段：可行性研究、初步项目计划、需求分析；
（2）开发阶段：概要设计、详细设计、实现（编码）、测试；
（3）运行和维护阶段：运行、维护、废弃。
遵循以上软件工程定义和思想，在实际工作中，产生了很多开发策略和模式。这些模式从不同的角度或者实际情况出发，为避免项目风险、降低开发成本，采取了不同的开发步骤。常用的开发方法有以下几种。
1．瀑布模型
瀑布模型（Waterfall Model）是在1970年由温斯顿·罗伊斯（W. Royce）提出的软件开发模型，是最早的计算机软件开发方法。该模型给出了固定的顺序，将软件开发活动从上一个阶段向下一个阶段逐级过渡，如同流水下泄像瀑布一样。它强调严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。每个步骤的成果物作为衡量进度的方法，如需求规格书、设计文档、测试计划和代码审阅等。瀑布式开发的主要问题是它严格分级，导致开发自由度降低，项目早期做出的承诺导致对后期需求的变化难以调整。瀑布式方法在需求不明并且项目进行过程中可能变化的情况下基本是不行的。
瀑布模型如图1.4所示。
图1-4 软件开发的瀑布模型
2．快速原型模型
快速原型模型（Rapid Prototype Model）的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
快速原型法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件的原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。
3．迭代式开发也被称作迭代增量式开发（Incremental Model）或迭代进化式开发
这是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。在该模型中，开发工作类似建造一个大厦，软件被一步一步建造起来。软件被作为一系列的增量构建来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成，增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断看到所开发的软件，从而降低开发风险。
具体操作上，迭代式开发每次只设计和实现产品的一部分，每次设计和实现的一个阶段叫作一个迭代。迭代开发时，将开发工作组织为一系列短小的、固定长度（如3周）的小项目，被称为一系列的迭代，每一次迭代都包括了需求分析、设计、实现与测试，如图1.5所示。
图1-5 迭代增量模型
采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。
迭代开发的优点是可以降低风险，得到早期用户反馈，持续地测试和集成，适于需求变更，提高了软件复用性。
但是，增量迭代模型也存在以下缺陷。
（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化，防范风险能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改的模型方式，从而使软件过程的控制失去整体性。
4．螺旋开发模型
螺旋开发（Spiral Model）模型产生于1988年，由Barry Boehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型刚开始开发规模很小，当项目被定义得更好、更稳定时，逐渐展开。其核心就在于不需要在刚开始的时候就把所有事情都定义得非常清楚。先轻松上阵，定义最重要的功能，实现后，听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到满意的最终产品。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。这个过程大致包括以下几方面。
（1）制订计划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险。
（3）实施工程：实施软件开发和验证。
（4）客户评估：评价开发工作，提出修正建议，制订下一步计划。
螺旋模型的示意图如图1.6所示。
图1-6 软件开发的螺旋模型
5．敏捷软件开发
敏捷软件开发又称敏捷开发，是从20世纪90年代开始逐渐引起广泛关注的新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”式开发，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需要变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷开发强调如下几点。
（1）人和交互重于过程和工具。
（2）可以工作的软件重于求全而完备的文档。
（3）客户协作重于合同谈判。
（4）随时应对变化重于循规蹈矩。
以上内容最为重要的是人员彼此信任，人少但是精干，可以面对面沟通。
敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作，按短迭代周期工作，每次迭代交付一些成果，关注业务优先级，检查与调整。
敏捷方法中要考虑的重要因素是人员的规模。随着项目规模的增长，面对面的沟通就愈加困难，因此，敏捷方法更适用于较小的队伍，40人以下的人员比较合适。大规模的敏捷软件开发尚处于积极研究的领域。
在国际软件外包项目中，比较常见的是瀑布型开发。这是因为通过离岸方式的外包开发，沟通是最大的问题，由于难以即时、面对面地与客户或上游设计人员沟通，因此书面的、正规文档沟通方式成为国际软件外包沟通的主要形式，而这样的沟通形式，客观上就迫使软件开发局限于瀑布式的工作过程。
即使采用瀑布式的开发，也常常为了项目的顺利进行，需要在岸保留一定的BSE（Bridge Senior Engineer）与客户或发包商进行密切地接触，保持沟通的畅通。
1.5.6 软件质量保证活动
软件项目是否成功，取决于4个方面的因素，即在约定的时间内、按预算的成本、完成了规定的软件功能范围开发，并达到了预定的质量标准。
在以上4个评判标准中，时间、成本和功能，是比较容易进行量化跟踪和监控的。但是对于质量的评判，则比较困难，有些质量问题是直接可以通过软件外观看到的，而更多的、影响软件运行效能的问题，则很难直接观察出来。例如，同样编出了相同功能的软件代码，但是由于处理方法和算法的不同，执行效率会有很大差异。我们在这里所探讨的软件质量，主要是指对于实现既定功能有影响的质量问题，如程序算法错误、未处理异常情况、未进行计算机资源回收等直接影响软件系统功能的质量问题，属于程序逻辑方面的错误。至于软件算法效率方面，需要开发人员个人技能的提高和组织。
按照ISO 9000的定义，质量是一组由固有特性满足需求的程度。通俗地说，就是软件与文档中规定或描述的标准之间符合的程度。影响软件质量的主要因素，从管理的角度来度量，可以分为3类，即正确性（包括完整性、可用性、效率等）、可理解性（包括可维修性、可测试性等）和可移植性（包括可复用性、可移植运行性等）。
为了达到这些质量标准，在开发过程中，应该按照规定的质量保证程序，进行产品的生产活动。一定规律的活动，就会产生一定质量水平的产品。就是说，质量的结果，很大程度上取决于生产活动的规则和技术水平。如果把产品质量看作是生产活动的结果，那么，要提高产品质量，就必须改进或改善生产活动本身的规则。这就是质量保证活动的基本原则。例如，生产出了一个有缺陷的产品，如果要改进产品的质量，是对生产出来的产品做质量上的改进，对其缺陷进行修复，还是对生产这个产品的过程进行改进呢？如果要对产品逐一进行修复，那么从这个生产过程中出来的产品，将会连续不断地出现类似的质量问题，产出的量越大，要修复的产品缺陷也越多，无法从根本上消除产品的质量问题，进而提高产品的质量。如果对产品的生产过程进行分析和改进，那么，改进后的生产过程，将会避免产生产品缺陷的某个活动中的问题，从而杜绝通过这一活动过程产生质量问题的关键因素。不断改进生产过程，从而保证产品质量，使得一个组织的生产过程的质量趋于稳定，这就是质量保证体系追求的目标，也是质量保证活动的重点工作。
在软件外包行业中，目前比较通行的质量保证体系及其认证，当属“能力成熟度模型”（Capability Maturity Model，CMM）。CMM是美国卡内基·梅隆大学软件研究所（SEI）在美国国防部的资助下所做的一个项目的成果。1987年，在SEI的技术报告中，把软件能力成熟度模型（CMM）作为评价国防部合同承包方过程成熟度的方法论；1991年，SEI发布了1.0版软件CMM（SW-CMM）。
CMM自1987年开始实施认证，现在已经成为软件业权威的评估认证体系。CMM包括了5个等级，共计18个过程域，52个目标和300多个关键实践活动。
在软件外包发包中，对于很多较大项目的招标，都要求承包方具有CMM的认证，当然，认证的等级有所不同。国际大型软件公司的项目发包，有的要求承包方达到CMM5级的最高等级。也有的对承包方的质量保证体系进行实地考察和评估，满足发包方的要求后，才能作为软件外包提供商，承接项目。
1.5.7 项目交付与验收
软件外包的结果，是承包方向发包方提交开发完成的成果物。软件项目的成果物包括项目从开始到结束一系列过程中产生的各种需要提交的内容，包括各种技术文档、代码、测试文档和测试结果，还有客户提供的临时使用的设备等。
当项目到了结尾阶段，需要交付的成果分为两部分。
一部分是开发方需要自行保留的，包括从项目开始到结束的全部资料，既有项目管理方面的文档，也有项目工程方面的文档和代码，还有项目支持方面的相关文档及项目总结报告等内容。这部分成果物，应作为开发方的财产，进行完整的备份，纳入公司财富管理库中保存。历史信息和经验教训信息，也应该一并做好总结，移存到经验知识库里。
另一部分则是需要提交给客户的成果物，包括项目分析、设计、使用和维护等方面的文档，以及程序代码和相关的手册。还要包括提供给客户的附属设备、配套的使用环境资料。
项目的验收，是指客户方要按照合同的要求，逐项检查成果物是否达到了要求，是否符合质量标准，以及是否满足性能要求等工作。项目验收要检验成果物和附属的文档资料是否完整，对于今后的系统升级或维护，要有完整的系统资料说明。除了提交的可见成果物，有的验收过程还包括对服务性工作的检验。例如，对客户的系统使用培训，为客户提供的维护是否及时、有效等。
对客户方面的验收，最终需要客户出具正式的项目接受和验收文档。
在国际软件外包项目中，很多情况下，项目组的工作通过网络直接连接在客户的服务器上，或直接连接在存放在客户端的开发环境上。绝大多数的工作成果，如代码和技术文档，都是随时保存在客户服务器上，因此客户也会随时得到成果物，也有即时测试和验收的。这种情况，往往验收工作比较简单，当项目开发完毕，验收也很快就结束了。