在××拟定的版本合并计划初稿上，结合项目经理与相关部门的部门经理以及各小组负责人和骨干技术人员的历次讨论，我们认为完整的版本合并工作按照工作流程，可以划分以下几个阶段：

1、  需求收集整理阶段：

           东北分公司收集和整理所有本地化修改工作，按照约定的交付格式组织成文，发回杭州总公司HIS3产品组；此项工作是整个版本合并工作的基础，这项工作完成质量直接决定整个版本合并工作是否能够按计划完成以及版本合并后的程序质量。

           此阶段的参与组织为：东北分公司沈阳研发分部、杭州总公司HIS3产品组。在执行过程中，以东北分公司沈阳研发分布为主导，杭州总公司HIS3产品组配合。

           注意，为了相关人员统一认知，HIS3产品组和东北分公司沈阳研发分部需要就此次版本合并的需求交换文件确定一个标准格式。

2、  需求二次分析阶段：

           杭州总公司HIS3产品组根据东北分公司发回的文件，逐条分析和确定新的业务解决方案。在确定新业务解决方案的时候，如果需要变更东北版本的原解决方案，需要征求东北分公司相关人员的意见并取得一致意见，无论变更东北版本还是杭州版本的原解决方案，如果新的业务解决方案会导致UI的变化，尤其是操作习惯的变化，必须通知和取得医院对最终解决方案的认可；否则，需考虑分模式实现。

           此阶段的参与组织为：杭州总公司HIS3产品组和东北分公司沈阳研发分部共同确定业务解决方案，前者为此项工作的主导，后者配合前者完成工作。杭州总公司工程服务部和东北分公司技术服务部分别完成相关医院沟通解释工作。

           注意，为了便于HIS3产品组工作开展，我们需要在公司搭建吉大一和吉大二的模拟环境，用于东北本地修改的效果演示。

3、  系统二次设计阶段：

           杭州总公司HIS3设计组根据上一阶段HIS3产品组的工作输出，针对各个需求的最终业务解决方案逐个确定版本合并的技术解决方案（确定界面层、中间层和数据库层的设计和资源变更填写，对于需要采用全新的技术解决方案的事务，需产生设计变更说明书），并估算每个任务的大致工作量和确定开发负责人。

           此阶段的参与组织为：杭州总公司HIS3设计组、东北分公司沈阳研发分部。在执行过程中，以东北分公司沈阳研发分布为主导，杭州总公司HIS3产品组配合。

           注意，从这个阶段开始，为了保证数据库的版本统一，需搭建东北分公司的本地开发环境。

4、  代码二次实现阶段：

           二次实现阶段完成具体事务的代码合并工作，包括界面层、中间层和数据库层。根据HIS3设计组给出的每个事务的技术解决方案和开发负责人，每个开发人员领取自己的任务并负责完成代码实现和开发自测，并按照HIS3项目组的事务填写规范填写测试说明。

           此阶段的参与组织为：杭州总公司HIS3开发组、东北分公司沈阳研发分部、杭州总公司HIS3设计组。由于工作的特殊性，为了方便沟通交流，我们建议此阶段东北技术人员来总公司。

           注意：此次版本合并以杭州版本作为基础，即尽量把东北分公司的代码实现合并到杭州版本中来。

5、  系统测试阶段：

           作为HIS3产品质量保证的关键环节，在版本合并过程中，我们依然需要借助需求验证和需求测试两项活动。

           此阶段的参与组织为：杭州总公司HIS3产品组，杭州总公司HIS3测试组。HIS3产品组按照业务解决方案验证需求的实现完整性和准确性，HIS3测试组按照项目组的测试规范组织日常测试，除了保证的完整性和准确性，还需加强稳定性和性能的测试。

           注意：此次版本合并过程中，对于变更原业务解决方案和技术解决方案的需求，都是测试的重点。作为一个重要的工作成果，我们将建立新的测试环境系统和测试工作制度。

6、  版本发布阶段：

           作为版本合并及之后的一个重要流程控制点，HIS3的所有客户程序都需要接受HIS3测试组的回归测试和统一发布。我们很明确的要求，版本合并的最后阶段，HIS3测试组需要完成所有重点客户的合并后版本的测试。在测试的过程中，测试人员需要根据业务解决方案的要求而不是开发人员的描述进行测试。测试组需要更新和完善HIS3的测试用例，重点是完成吉大一和吉大二的测试用例。

           同时，我们需要确定合并后程序针对所有HIS3客户的资源配置设置，这项工作由HIS3产品组完成。并建立和归档每家医院的资源配置登记资料。

           此阶段的参与组织为：杭州总公司HIS3测试组，杭州总公司HIS3产品组。

           注意：作为此阶段工作结束的标志，我们将生成每一家HIS3客户的合并后版本的系统升级文件。配套的版本发布机制将建立起来。

7、  医院程序升级阶段：

           此阶段是版本合并的最终阶段，阶段的工作成果取决于三个因素，前期医院沟通情况、版本合并持续时间和版本合并制品质量。版本发布准备的医院升级材料的详细程度会对现场工程人员的升级工作起到关键作用。

           此阶段的参与组织为：工程服务部，东北分公司技术部。HIS3产品组和HIS3测试组做配合。

版本合并工作量估算：

         由于东北分公司目前没有准确的记录文件可以帮助项目组评估合并工作的工作量，所以我们只能采用杭州总公司从07-09年的现有客户历史数据来作为参考。

         基于URTracker的客户统计数据，我们目前有记录的需求总数为2400，以绿城、协和和昆山进行平均，我们认为按照吉大一和吉大二的医院规模和上线系统，东北的本地化修改需求数应该在800条左右。

         按照3年来计算，每年杭州总公司能够完成的需求平均数大概也在800左右。

         以设计开发一体化的模式为标准，以具体开发阶段的资源消耗为依据，按照20人开发队伍来计算，杭州总公司的每条需求平均下来大概需要的开发时间为（20×12/800= 0.3人月）。

         考虑到人员熟练程度，东北分公司开发人员按照0.7的系统来算，我们认为投入具体代码开发的有效人数经折算应该在30人左右。

         对于估算中的需合并的800条东北本地修改，考虑到部分需求的代码只需合并而不用新开发，我们按照0.7的系数来计算，有效任务数应该在560，因此工作量的估算大约是：560 *0.3/30=5.6个月。

         注意：以上在计算每个事务的平均耗时的时候，我们没有计算产品和测试的耗时，否则给出的版本合并工作所需的时间基本上是乘以2。

版本合并的进度安排：

         根据URTracker关于HIS3REQ的全部事务各阶段平均停留工作时间的统计数据，我们以新提交、待分析和待验证作为HIS3产品组的平均停留时间（不考虑待补充），给出的统计数据为10D6H27M + 16D6H28M + 2D5H32M = 28.8D，以待设计作为HIS3设计组的平均停留时间（不考虑重设计），给出的统计数据为11D4H31M，以待实现作为HIS3开发组的平均停留时间（不考虑重实现），给出的统计时间为17D4H33M，以待测试作为HIS3测试组的平均停留时间，给出的平均统计时间为2D6H43M。以工作组耗时比例来计算，取整后大致是：

         HIS3产品组：29 / （29 + 11 + 17 + 2）= 49%

         HIS3设计组：11/ （29 + 11 + 17 + 2）= 18%      （项目组今年开始有此设计状态的）

         HIS3开发组：17/ （29 + 11 + 17 + 2）= 29%

         HIS3测试组：2/ （29 + 11 + 17 + 2）= 4%

         以上的数据平均我们觉得还是比较符合软件工程理论的。对于版本合并的计划安排，我们希望是在需求收集整理阶段结束后再行估算，如果能够在二次需求分析结束再行估算的话，给出的工作量估算数据应该更为准确。项目组目前无法提供有意义的进度计划表。

版本合并的存在问题：

1、  东北分公司的组织结构关系尚未明确。

2、  东北分公司开发人员的心态不稳定，严重影响了工作的开展。

3、  版本合并后，分公司和总公司需要在一个统一的计划安排下进行工作，意味着版本的发布将按照总公司的要求来，而不再是分公司的自由发布模式，需要分公司严格执行这个制度。

4、  版本合并后，分公司和总公司需要在一个相同的配置库上进行工作，两地项目组成员使用的辅助开发工具库也需要统一。这意味着合并版本后东北分公司开发人员需要频繁进行远程代码迁入迁出，以及远程操纵辅助开发工具（我们的辅助开发工具是2层的，也没有升级为BS的计划），因此公司有必要加强网络硬件投入，确保分公司开发人员的工作便利。

5、  版本合并之后，对于分公司与总公司之间的研发工作配合，目前有两种方案，一是采用系统负责制（确定每个HIS3的子系统由哪方整体承担），一种是任务负责制（确定每条HIS3的Urtracker事务具体由哪个开发人员承担）。两种方案各有利弊，尚未确定具体采用哪种方案。

6、  如果版本合并持续的时间确实如工作量估算所列，代码合并阶段两边的开发需要保持业务解决方案和技术解决方案的一致性，即总公司必须介入分公司的需求和开发工作，分公司开发人员必须按照总公司的要求来维护程序，否则差异代码就没有一个中止点了。

版本合并的风险说明：

1、  此次版本合并工作，不能采用08年架构升级的工作方法，所以持续时间时间会更长，如果不能很好的控制这段时间之内的两地工作任务安排，合并工作会有失控的可能。

2、  据了解，东北分公司技术无法准确的统计本地化修改情况，现有的工作量和时间安排都是基于杭州总公司历年URTracker数据的分析进行估算的。

3、  由于东北分公司本月开始实施东丰医院，开发人员反馈无法保证本地化修改汇总文件的编写。而杭州总公司11月份需要完成南通市一医院和如东人民医院的上线工作，如果上线不是很顺利，对于版本合并工作所需的资源也会造成影响。

4、  如果版本合并完成后，东北分公司不能严格按照项目统一管理的流程和制度开展工作，版本合并将毫无意义。

5、  如果东北分公司开发人员不能保证提交的本地化修改说明的质量，后期的工作质量无法有效保障。