小语种翻译软件服务投标方案（技术方案）

小语种翻译软件服务投标方案

目录

第一章需求理解...................................4

1.1.对用户需求理解透彻，明确系统的建设要求和目

标...........................................4

1.2.系统建设目标.............................5

1.3.建设要求响应.............................6

第二章技术方案.................................31

2.1.产品技术先进，性能稳定、升级扩展性强，技术

方案科学、合理、详尽，可行性强...............31

2.2.总则...................................35

2.3.立项管理...............................36

2.4.需求分析...............................37

2.5.项目计划和监控.........................38

2.6.小语种翻译软件系统设计.................39

2.7.小语种翻译软件系统实现.................40

2.8.系统测试和用户测试.....................41

2.9.试运行.................................42

2.10.系统验收...............................44

2.11.系统上线...............................45

第三章合作开发管理.............................47

3.1.立项分析报告...........................48

3.2.单元测试用例...........................81

3.3.试运行计划.............................93

3.4.数据迁移计划...........................96

3.5.试运行报告...........................100

3.6.系统验收报告.........................102

3.7.系统上线计划.........................103

3.8.系统验收评估报告.......................107

第四章技术指标...............................109

4.1.第四章“技术服务需求”第三部分“技术指标”

中，有▲标记11项逐条响应..................109

4.2.系统需求响应..........................111

4.3.翻译性能优化——▲语种数量.............116

4.4.翻译性能优化——▲翻译质量.............116

4.5.翻译性能优化——▲翻译速度.............116

4.6.翻译性能优化——▲并发要求.............117

4.7.翻译系统扩展——▲语种数量.............117

4.8.翻译系统扩展——▲翻译质量.............117

4.9.翻译系统扩展——▲翻译速度.............117

4.10.翻译系统扩展——▲并发要求...........118

第五章文本内容分析——▲言论抽取...............119

5.1.文本内容分析——▲引语归因.............119

5.2.框架扩展性——▲以API封装知识资源建设系统

各功能模块，提供所有算法可配置接口及并行任务监

控、调度接口...............................119

5.3.运维服务...............................119

5.4.性能扩展性——#节点数线性增加，加速比随之增

加.........................................120

5.5.算法扩展性——#知识资源建设算法预留扩展接

口，可进行二次开发.........................120

第六章服务、实施方案详尽，完全满足系统需求中的运维

服务方案.......................................121

6.1.项目组织机构...........................122

6.2.服务原则...............................123

6.3.热线支持服务...........................124

6.4.现场支持服务...........................125

6.5.售后服务流程...........................127

6.6.项目实施过程管理.......................133

6.7.项目质量控制...........................136

第七章拟派实施人员汇总表格式...................145

7.1.拟派实施人员表.........................145

7.2.拟派实施人员表格式.....................148

7.3.计算机学科硕士以上学历人员名册.........150

7.4.项目人员资质...........................157

第一章需求理解

1.1.对用户需求理解透彻，明确系统的建设要求和目标

1.1需求理解

机器翻译是使用计算机自动进行语言翻译的技术，它可

以在高效的实现不同语言之间自动转换的同时，基本达到人

类翻译的质量。机器翻译高效、高质量的翻译能够打破语言

屏障，使得对海量实时数据的跨语言处理成为可能。目前系

统已支持中文->英文、法文->英文、阿拉伯文->英文、德文

->英文、西班牙文->英文、葡萄牙文->英文、日文->英文、

俄文->英文、英文->中文共9个语言对的翻译，尚无文本内

容分析能力。

1.2.系统建设目标

本项目的目标是提升已有的翻译系统的翻译质量、扩展

翻译系统所支持的语言对、以及新增对英文新闻文本的内容

分析功能。

服务商需在规定的时限内完成相关工作，按照本项目系

统升级完善、调整优化的需求，完成系统性能升级以及新增

服务开发工作。确保优化后系统以及新增系统满足业务处理

功能和性能需求。保证系统安全、稳定运行。

1.3.建设要求响应

专门术语：

SQLSERVER:系统服务器所使用的数据库关系系统

(DBMS)。

SQL:一种用于访问查询数据库的语言

事务流：数据进入模块后可能有多种路径进行处理。

主键：数据库表中的关键域。值互不相同。

外部主键：数据库表中与其他表主键关联的域。

ROLLBACK:数据库的错误恢复机制。

缩写：

系统：若未特别指出，统指本小语种翻译软件。

SQL:StructuredQueryLanguage(结构化查询语言)。

ATM:AsynchronousTransferMode(异步传输模式)。

UML:统一建模语言、是一套用来设计软件蓝图的标准

建模语言，是一种从软件分析、设计到编写程序规范的标准

化建模语言。

UDP:UserDatagramProtocol是无连接的传输层协

议

分布式代理：可隐藏服务器ip,减少服务器的危险；

服务器代理：可验证用户数据的正确性，以及安全性，

进行处理

三级代理：减轻服务器压力，可实现智能作弊系统!

标准、条件和约定

本项目遵从以下标准：

GB/T13702-1992计算机软件分类与代码

GB/T20918-2007信息技术

GB/T19003-2008软件工程

GB/T5538-1995软件工程标准分类法

GB/T9386-2008计算机富安居测试文档编制

GB/T9385-2008计算机软件需求规格说明

系统开发严格按照软件工程的方法进行组织，系统的开

发过程按照需求分析、系统分析与设计要求、系统编码、系

统测试几个过程有序推进。下表所示系统开发流程图，采用

原型及迭代方式开发，根据用户需求持续改进，直到最终用

户确认满意。

开发流程总述

如下图示流程定义了我公司内部的软件开发过程，以指

导和规范软件项目中开发过程的定义和相应的实施。

该过程可划分为一系列子过程，包括：软件需求分析、

设计、编码、测试、验收、维护，每个子过程又由一系列任

务和活动组成，如设计过程又可分为结构设计和详细设计。

但是在实际开发项目中，情况仍然会是千变万化的，因此我

们也并不是一成不变的死板执行一个僵化的工作流程，我们

的原则是在一个规范流程的指导和约束下，根据具体工程项

目的实际要求，为每一个项目评估并制定真正能够最好的满

足该项目要求的开发流程。

开始

《软件雷求规格说明书》(初码)

《系统测试计划(》《系统测试率例)

软件需求分析(初稿)

《用户手肝)(枫要》

m测表一

N:改进

《献件需求规格说明书》

同行评审(系统测试计划》《系统测试案例)

通过《个人评审记录》

《评审报告》

《结构设计说明书》(初稿》

《集成测试计划)《集成测试案例)

《初稿)

结构设计《用户于册)(初稿)

《迫测表一)

N:改进

《结构设计说明书5》

《集成测试计划)《集成测达案例》

评审通过《个人评审记录)

评审报告)

《详细设计说明书》(初稿)

《单元测试计划)《单元测试案例》

《初稿)

详细设计《用户手册)(饰改稿)

《迫测表一)

N,改进(详细设计说明书》

《单元测试计划》《单元测试案例》

《用户手册》(修改稿)

评审通过《个人评审记录》

评审报告》

算代码、潭代码文件清单

《单元测试报告)(经过审批)

辅码《软件问圆状态登记表》

《软件问题报告单

《集成工作单》

《集成测试工作单)

《集成测试报告)(经过审批》

集成测试《软件闩题状态登记表》

《软件问题报告单)

成的软件系信

《系统测试报告》(经过审批)

(软件问题状态登记表》

《软件问题报告单》

《系统管理员使用说明书》(经过审批)

系统测试(安装于册》(经过申批)

《用户手册》(经过审壮

软件系统(系统测试通

验收测试报告

《软件问翻报告单》

《软件间豳状杏登记表》

验收验收报告

可交付产品

(软件需求规格说明书》(升级版)

《客户需求登记表》

(客户需求统计表》

(设计说明书》(升级版)

维护《软件问题报告单》

(软件间丽状杏登记表》

(软件维护实施计划》

作护后的软件系线

结束

在应用系统软件开发项目中，我们仍将遵循这一思想，

这一点将在随后的项目开发实施计划部分有具体的体现，在

这里和下面的相关章节中，我们仍将围绕着这个完整的开发

流程来分析说明，以此来阐明我们对项目开发的完整过程管

理思想和相关实践。下面我们对这个软件开发工作流程进行

简要地分解说明。

软件需求分析

(1)概述

由于应用系统与众多相关应用软件需要进行交互，因此

需要先对这些应用系统进行分别梳理，充分做好需求调研工

作，编写经项目单位认可并评审通过的《系统需求规格说明

书》。

软件需求分析是按照项目定义的软件开发过程，根据系

统分配给软件的需求(见《系统需求规格说明书》),进行

软件质量特性规格说明的过程。该过程包括进一步明确软件

运行环境，明确对软件的功能、性能和数据要求，以及软件

与硬件、软件与软件之间的接口要求等，并对软件需求进行

验证和文档化，即完成对软件需求的分析与规格定义。

本元素在整个过程中的位置如下图所示：

系统软件需结构设

图示：软件需求分析在软件开发过程中的位置

(2)入口准则和出口准则

1)入口准则

要素判断准则

客户需求

已由CCB批准为基线

(《系统需求规

已进入配置库

格说明书》)

2)出口准则

要素判断准则

已经过审查

软件需求规

已批准为基线

格说明书

已进入配置库

系统测试计划已经过审查

系统测试案已获得批准

例已进入配置库

用户手册(概

已编写

要)

追溯表一已填写

(3)评审

评审《软件需求规格说明书》,具体评审过程见《评审

程序文件》,对软件需求的评审准则包括：

●系统需求和系统设计的可追溯性；

●与系统需求的一致性；

●内部一致性；

●可测试性；

●软件设计的可行性；

●运作和维护的可行性。

对软件需求中的问题，与系统工程组或客户一起确定和

审查，根据审查结果对软件需求进行适当的修改，必要时按

基线变更控制的要求对客户需求进行相应的修改。对软件需

求规格说明书进行同行评审。审查、批准软件需求规格说明

书。

将软件需求规格说明书置于配置管理之下。

(4)工作产品

●《软件需求规格说明书》

●《系统测试计划》

●《系统测试案例》

●《用户手册》

●《追溯表》

(5)职责

●项目经理：负责组建软件需求分析组；确定是否需要

对有关人员进行培训；负责软件需求规格说明书的审

查和批准。

●软件需求分析组：软件需求分析的主要承担者，负责

完成本过程元素要求产生的所有工作产品。

●系统测试负责人：负责组织软件系统测试组对软件需

求进行分析，审查软件需求的可测试性；参与软件需

求规格说明书的审查和批准。

●质量保证人员：参与工作产品的审查，统计缺陷，并

对软件需求分析过程进行审计。

●系统开发组：配合处理涉及客户需求的软件需求问题。

●客户：必要时参与软件需求规格说明书的审查和批准。

结构设计

(1)概述

结构设计是指按照《软件需求规格说明书》,设计软件

系统的体系结构，即模块结构，定义每个模块的主要功能和

模块之间的联系(即接口),并确定软件系统的数据体系结

构。

本元素在整个过程中的位置如下图所示：

软件结详

图示：软件需求分析在软件开发过程中的位置图

(2)入口准则和出口准则

1)入口准则

要素判断准则

软件需求规格说经过审查

明书审查获得批准

进入配置库

2)出口准则

要素判断准则

结构设计说明书经过审查

集成测试计划审查获得批准

集成测试案例进入配置库

用户手册(初稿)

已完善

追溯表一

(3)评审

●对《结构设计说明书》和《集成测试计划》进行同行

评审。

●对结构设计中的问题，与软件需求分析人员一起确定

和审查，并对结构设计进行适当的更改。

●审查、批准《结构设计说明书》,必要时，对其进行

设计评审。

●将《结构设计说明书》、《集成测试计划》和《集成

测试案例》置于配置管理之下。

(4)工作产品

●《结构设计说明书》

●《集成测试计划》

●《集成测试案例》

●《用户手册》

●《追溯表》

(5)职责

1)项目经理

负责选择合适的设计人员，组建结构设计工作组；负责

《结构设计说明书》和《集成测试计划》的审查和批准。

2)结构设计人员

结构设计阶段工作的主要承担者，负责完成本过程元素

产生的所有工作产品。

3)系统分析员

配合处理涉及软件需求的问题。

4)系统开发负责人

负责组织系统工程组对结构设计进行分析，审查结构设

计的可测试性；负责协调处理涉及软件需求的问题；参与《结

构设计说明书》和《集成测试计划》的审查和批准。

5)软件测试负责人

负责组织软件测试组对结构设计进行分析，审查结构设

计的可测试性；参与《结构设计说明书》和《集成测试计划》

的审查和批准。

详细设计

(1)概述

详细设计是根据《结构设计说明书》进行模块设计，将

结构设计所获得的模块按照单元、程序、规程的顺序逐步细

化。详细定义各个单元的数据结构、程序的实现算法以及程

序、单元、模块之间的接口等，作为以后编码工作的依据。

本元素在整个过程中的位置如下图所示：

结构设详细设8编码

图示：详细设计在软件开发过程中的位置

(2)入口准则和出口准则

1)入口准则

要素判断准则

结构设计说明书经过审查

审查获得批准

进入配置库

2)出口准则

要素判断准则

详细设计说明书经过审查

审查获得批准

进入配置库

(3)评审

对《详细设计说明书》和《单元测试计划》可进行走查

或(和)同行评审；

对详细设计中的问题，与结构设计人员一起确定和审

查，并对详细设计做出适当的更改；

审查、批准《详细设计说明书》,必要时，对其进行设

计评审；

将《详细设计说明书》和《单元测试计划》置于配置管

理之下。

(4)工作产品

●《详细设计说明书》

●《单元测试计划》

●《单元测试案例》

●《用户手册》

●《追溯表》

(5)职责

1)项目经理

负责选择合适的设计人员，组建详细设计组；负责《详

细设计说明书》和《单元测试计划》的审查和批准。

2)详细设计人员

详细设计阶段工作的主要承担者。负责完成本过程元素

产生的所有工作产品。

3)系统分析员

配合处理涉及软件需求的问题。

4)系统开发负责人

负责组织系统工程组对详细设计进行分析，审查详细设

计的可测试性；负责协调处理涉及软件需求的问题；参与《详

细设计说明书》和《单元测试计划》的审查和批准。

5)软件测试负责人

负责组织软件测试组对详细设计进行分析，审查详细设

计的可测试性；参与《详细设计说明书》和《单元测试计划》

的审查和批准。

编码

(1)概述

编码阶段主要完成的工作是根据详细设计说明书编写

程序源代码，包括必要的数据文件，并进行单元测试，单元

测试的内容包括模块内程序的逻辑、功能、参数传递、变量

引用、出错处理等方面。

本元素在整个过程中的位置如下图所示：

详细设编集成

图示：编码阶段在软件开发过程中的位置

(2)入口准则和出口准则

1)入口准则

要素判断准则

详细设计说明书经过审查

单元测试计划获得批准

进入配置库

2)出口准则

要素判断准则

源代码文件源代码文件获得批准

源代码文件清单源代码文件进入配置库

的源代码区

单元测试报告提交测试负责人

软件问题报告单提交问题管理渠道

(3)评审

对源代码文件进行同行评审，主要的方法为对照详细设

计说明书对代码进行查阅，也可根据编程者的经验或程序的

难度、重要程度，选择走查评审方式，但目的都是发现程序

存在的问题。

(4)工作产品

●源代码文件

●《单元测试报告》

●《软件问题报告单》

●《软件问题状态登记表》

(5)职责

1)项目经理

建立编码组、测试组或相应岗位，并进行必要的培训；

跟踪进度和问题解决状态；对提交的源代码进行批准(或指

定负责人进行批准工作)。

2)程序员

编写程序代码；测试程序代码；修改程序代码；提交工

作产品，批准后将其导入配置区的源码库。

3)单元测试人员

测试源代码；提交测试报告和软件问题报告单。

4)评审人员

对指定源代码文件进行阅读，发现缺陷和问题，填写评

审报告。

模块集成测试

(1)概述

集成测试阶段主要完成的工作是集成和集成测试。集成

是参考结构设计说明书并根据详细说明书中规定的系统集

成方案将不同的经测试的程序单元进行构造，并逐步构造成

一个完整的软件产品的过程；集成测试则是在集成完成之

后，对各单元、模块之间接口的正确性和集成后功能的正确

性进行验证。

对于大型软件，集成测试可以采取分步进行的方法，可

以先对各子系统进行集成测试，然后在子系统之间进行集成

测试。

本元素在整个过程中的位置如下图所示：

编码集系

图示：集成测试在软件开发过程中的位置

(2)入口准则和出口准则

1)入口准则

要素判断准则

结构设计说明书经过审查

详细设计说明书获得批准

集成测试计划进入配置库

源代码文件

2)出口准则

要素判断准则

集成的软件系统获得批准

(完整的源代码和目进入配置库

标代码)

集成测试报告提交集成测试负责

人

软件问题报告单已进入软件问题管

理流程

(3)审查阶段

核查集成状态和结果，并进行批准；

批准后，将目标程序和程序清单进入目标代码库。

(4)工作产品

●集成后的系统目标代码(包括文件清单),及相应的

源代码(包括文件清单)

●集成测试报告

●《软件问题报告单》

●《软件问题状态登记表》

●《集成工作单》

●《集成测试工作单》

(5)职责

●项目经理：建立集成组、集成测试组或相应岗位，并

进行必要的培训；跟踪进度和问题解决状态；对集成

后的系统目标码进行批准(或指定负责人进行批准工

作)。

●集成负责人员：负责集成过程的实施。

●集成人员：负责环境构建，集成的过程操作，并将集

成后的目标代码提交批准。

●程序员、设计人员：修改源码或设计，解决集成过程

中出现的与源码有关的问题。

●测试人员：测试系统目标码，将测试报告和软件问题

报告单提交测试负责人。

系统测试

(1)概述

系统测试的主要任务是从系统需求的角度对系统运行

的正确性和性能进行验证。系统测试的依据为系统测试计

划。

本元素在整个过程中的位置如下图所示：

集成系验收

图示：系统测试在软件开发过程中的位置

(2)入口准则和出口准则

1)入口准则

要素判断准则

系统需求经过审查

系统的目标代码获得批准

系统测试计划进入配置库

用户手册编写完成

2)出口准则

要素判断准则

系统测试报告获得批准

软件问题报告单

(3)工作产品

●《系统测试报告》

●《软件问题报告单》

●《软件问题状态登记表》

(4)职责

●项目经理：负责建立系统测试组或相关的岗位，并进

行必要的培训；跟踪进度和问题解决状态；对最终的

目标代码进行批准(或指定负责人进行批准工作)。

●程序员、设计人员：修改源码或设计，解决集成过程

中出现的与源码有关的问题。

●测试人员：测试系统目标码，将测试报告提交测试负

责人，将软件问题报告单提交问题管理渠道。

验收

(1)概述

验收阶段主要由验收测试、验收测试问题改正和验收三

部分组成：

验收测试的主要目的是验证所开发的系统在用户的使

用环境下(或模拟的使用环境下)是否满足系统需求，从用

户的角度验证整个系统运行的正确性。

验收测试问题改正是对验收测试中发现的差异性问题

进行修改。

验收则是在验收测试的基础上，依据项目合同或项目任

务书对项目的完成情况进行综合评价。

本元素在整个过程中的位置如下图所示：

系统验维护

图示：验收在软件开发过程中的位置

验收的三个组成部分视项目立项类型和客户的要求选

择执行。

(2)入口准则和出口准则

1)入口准则

要素判断准则

验收测试计划(有验验收测试前完成评

收测试要求的项目)审。

测试(系统测试、集已完成

成测试、单元测试)

2)出口准则

要素判断准则

验收测试报告已提交

验收测试问题报告单已关闭

验收报告已提交

(3)工作产品

●验收测试报告

●《软件问题报告单》

●《软件问题状态登记表》

●验收报告

●可交付产品

(4)职责

●验收测试组：负责验收测试的各项活动。

●开发组人员：负责验收测试中发现问题的改正和测试

辅助。

●项目管理人员：负责指派验收测试责任和完成测试规

程；确保测试质量和进程；确保组间协调。

●验收组：具体进行验收。

●CCB:批准运行基线。

维护

(1)概述

维护期是指：软件产品/系统验收后，进入软件运行/系

统维护阶段，直至软件产品下一个版本的发布或系统维护期

终止；

本元素在整个软件开发过程中的位置如下图所示：

验收维护

图示：维护在软件开发过程中的位置

(2)入口准则和出口准则

1)入口准则

要素判断准则

软件产品/系统已验收

2)出口准则

要素判断准则

软件产品已退役

合同约定的维护期限已到期

合同约定的维护范围已超出，须另签协议

(3)工作产品

●《软件需求规格说明书》

●《客户需求登记表》

●《客户需求统计表》

●《设计说明书》

●《软件问题报告单》

●《软件问题状态登记表》

●《软件维护实施计划》

●维护后的软件系统

(4)职责

维护负责人：制定软件维护实施计划，确认维护类型、

需求范围，分配维护任务，追踪任务的完成情况及其他项目

管理工作。软件维护人员：负责进行软件维护任务的执行。

QA人员：负责协助维护负责人根据实际情况剪裁标准流

程。

第二章技术方案

2.1.产品技术先进，性能稳定、升级扩展性强，技术方案

科学、合理、详尽，可行性强

一、为用户带来准确的翻译及发音

用户小语种翻译过程中会经常遇到不认识的单词短语，

将其复制到小语种翻译软件当中可以进行小语种翻译互译

功能，还可以点击发音，通过读法和理解进行学习小语种，

更加适合用户的学习状态。准确的小语种读法和详细的解析

是用户学习路上所需要的，这也是对于用户需求的满足。

二、帮用户拓展相关联单词和短语

小语种翻译软件的开发为用户带了单词的词汇量提升，

用户可以在小语种翻译软件客户端进行相对应的单词短语

学习，在学习的过程成长。每当用户通过小语种翻译单词短

语之后，系统可以为用户搜索到相关联的单词短语，帮助用

户加深在学习英语时候的应用，让用户可以更好地进行单词

短语在生活中的使用。

三、手机在线翻译，快速且便捷

智能手机现在我们生活中大部分都是出门都会携带的

一款便捷性设备，用户随时随地可以使用小语种翻译软件，

手机上操作可以充分得利用翻译软件的优势功能巩固单词

短语。打好英语基础义不容辞，小语种翻译软件具备的快捷

性让用户更青睐于使用。

在学习英语的道路上是需要不断积累的，小语种翻译软

件的开发是学习路上的一个“好老师”,帮助用户解决在学

习上面所面临的难题，帮助用户巩固英语的知识基础。我们

的移动互联网时代中，运用手机客户端能够为用户带来诸多

的便利事项，新颖有创意的小语种翻译软件开发可以吸引更

多用户的眼光

S101开始

选择待翻译的词语

S102

检测翻译数据库内N

是否存在翻译条目

S103

Y

将包含有翻译条目信息的代码块替换

原与待翻译的词语相对应的代码块

结束

背景技术：

软件开发时，要使它能同时应对世界不同地区和国家的

访问，并针对不同地区和国家的访问，提供相应的、符合来

访者阅读习惯的页面或数据，就需要为软件实现国际化。目

前在现有的为软件实现国际化的技术中，要求程序员将需要

国际化的词语的翻译部分写入配置文件中，因此，则必须要

求程序员具备较高的语言翻译能力。

技术实现要素：

为了使语言翻译能力较弱的程序员也能顺利地对软件

实现国际化，本申请提供了用于软件开发的自动翻译方法及

用于软件开发的自动翻译系统。

本申请由以下技术方案实现的：

用于软件开发的自动翻译方法，包括以下步骤：

选择待翻译的词语；

检测翻译数据库内是否存在与待翻译的词语相对应的

翻译条目，如果是，则将包含有翻译条目信息的代码块替换

原与待翻译的词语相对应的代码块。

如上所述的用于软件开发的自动翻译方法，如果检测到

翻译数据库内不存在与待翻译的词语相对应的翻译条目，则

调用翻译云服务器将待翻译的词语翻译成指定语言生成翻

译结果；

接收翻译云服务器反馈的翻译结果；

弹出翻译结果并请求确认信息；

如果接收到翻译结果确认信息，则将翻译结果存储于翻

译数据库内形成新的翻译条目。

本申请还公开了用于软件开发的自动翻译系统，包括：

选择模块，其用于选择待翻译的词语；

翻译检测模块，其用于检测翻译数据库内是否存在与待

翻译的词语相对应的翻译条目；

代码替换模块，其用于将包含有翻译条目信息的代码块

替换原与待翻译的词语相对应的代码块。

如上所述的用于软件开发的自动翻译系统，包括：

调用模块，其用于在所述翻译检测模块检测到翻译数据

库内不存在与待翻译的词语相对应的翻译条目时调用翻译

云服务器将待翻译的词语翻译成指定语言生成翻译结果；

接收模块，其用于接收翻译云服务器反馈的翻译结果；

请求确认模块，其用于弹出翻译结果并请求确认信息；

存储模块，其用于在接收到翻译结果确认信息时将翻译

结果存储于翻译数据库内形成新的翻译条目。

2.2.总则

为规范本小语种翻译软件服务项目软件开发的管理工

作，特制定本制度。本制度适用于公司软件研发与管理。

软件开发遵循项目管理和软件工程的基本原则。项目管

理涉及立项管理、项目计划和监控、配置管理、合作开发管

理和结项管理。软件工程涉及需求管理、系统设计、系统实

现、系统测试、用户接受测试、试运行、系统验收、系统上

线和数据迁移。

除特别指定，本制度中项目组包括业务组(或需求提出

组)、IT组(可能包括网络管理员和合作开发商)。

2.3.立项管理

提出开发需求的信息技术部门参与公司层面立项，进行

立项的技术可行性分析，编写《立项分析报告》(附件一),

开展前期筹备工作。《立项分析报告》应明确项目的范围和

边界。

应用系统主要使用部门将《立项分析报告》上交公司总

裁室进行立项审批，以保证系统项目与公司整体策略相一

致。

2.4.需求分析

立项后业务组对用户需求进行汇总整理，出具《业务需

求说明书》(附件二),并确保《业务需求说明书》中包含

了所有的业务需求。经系统使用部门审批确认，作为业务需

求基线。

IT组在获得《业务需求说明书》后，提出技术需求和解

决方案，并对系统进行定义，出具《系统需求规格说明书》

(附件三)。《系统需求规格说明书》需详细列出业务对系

统的要求(界面、输入、输出、管理功能、安全需求、运作

模式、关键指标(KPI)等)。《系统需求规格说明书》需要

由业务组提交给相关业务流程负责人确认。

对于合作开发的项目，当业务需求发生变更时，业务组

应提交《需求变更申请》(附件四),IT组组长审批后交给

合作开发商实施。

项目组应对需求变更影响到的文档及时更新。

2.5.项目计划和监控

软件开发采用项目形式进行管理。项目经理负责整个项

目的计划、组织、领导和控制。

需求分析过程中，项目经理组织制定详细的《项目计划

书》(附件五),包括具体任务描述和项目进度表等。

在项目的各个阶段，业务组组长和IT组组长需配合项

目经理制定阶段性项目计划。业务组组长和IT组组长需配

合项目经理对项目计划执行情况进行监控，确保项目按计划

完成。

项目计划需要变更时，项目经理填写《项目计划变更说

明》(附件六),并提交公司主管领导审批，通过审批后，

交给业务组组长和IT组组长执行。

2.6.小语种翻译软件系统设计

系统设计应分为概要设计和详细设计，系统设计要遵循

完备性、一致性、扩展性、可靠性、安全性、可维护性等原

则。

在系统设计阶段中，用户应充分参与，确保系统设计能

满足系统需求。

项目组进行详细设计，出具《设计说明书》(附件七)

和《单元测试用例》(附件八)。《设计说明书》中需要定

义系统输入输出说明和接口设计说明。公司主管领导组织相

关人员对概要设计进行评审，出具《设计评审报告》(附件

九)。业务组组长和IT组组长应参加此评审并对评审意见

签字确认。

设计评审均以《业务需求说明书》和《系统需求规格说

明书》为依据，确保系统设计满足全部需求。

对已确认通过的系统设计进行修改需获得管理部门、业

务组组长和IT组组长的审批后方可进行。

对系统设计的修改的文档须由文档管理人员进行归档

管理。

2.7.小语种翻译软件系统实现

项目组根据《设计说明书》制定系统实现计划，并提交

项目经理对计划可行性进行审批。

系统实现包括程序编码、单元测试和集成测试。

项目组保证开发、测试和生产环境独立，为各环境建立

访问权限控制机制，并明确项目成员的职责分工。对开发环

境、测试环境与生产环境在物理或逻辑方面应该做到隔离；

如果环境的分隔是通过逻辑形式实现的，应定期检查网络设

置。项目组对已授权访问生产环境的人员进行详细记录，并

对该记录进行定期检查，确保只有经授权的人员才能访问到

生产环境。

项目组进行单元测试和集成测试，测试人员签字确认测

试结果。

2.8.系统测试和用户测试

项目组制定《系统/用户测试计划》(附件十),并提

交项目经理对计划可行性进行审批。

《系统/用户测试计划》必须定义测试标准，并明确各

种测试的测试步骤和需要的系统设置要求。

项目组向数据拥有部门申请获取测试用业务数据的使

用权，对获取的数据进行严格的访问控制，确保只有相关项

目人员才能访问及使用。

项目组负责测试数据准备，测试用数据要足够模拟生产

环境中的实际数据。对已评定为敏感信息的数据进行敏感性

处理和保护。

IT组或合作开发商建立测试环境进行系统测试。在系统

测试中对新系统内部各模块之间的接口和与其他系统的接

口进行充分测试。出具《系统测试报告》(附件十一),测

试人员签字确认测试结果。

系统测试通过后，IT组配合业务组建立用户测试环境，

业务组根据用户测试用例进行用户测试，出具《用户测试报

告》(附件十一),业务组组长和IT组组长应在用户测试

报告中签字确认。

项目组完成系统帮助文档(其中包括《用户操作手册》

和《安装维护手册》)。凡涉及应用系统的变更，应对系统

帮助文档及时更新。

2.9.试运行

系统主要使用部门根据项目规模及影响决定试运行策

略。

项目组制定《试运行计划》(附件十二),并制定试运

行验收指标，上报公司主管领导审批。《试运行计划》中应

包含问题应对机制，明确问题沟通渠道和职责分工。

项目组联合试运行单位进行相关系统部署工作，准备培

训资料，对相关用户和信息技术人员进行培训。用户培训的

完成度应为实施后评估的指标之一。

项目组根据《试运行计划》进行系统转换和数据迁移。

系统转换前，检查系统环境，确保运行环境能满足新应用系

统的需要。系统转换时必须详细记录原系统中的重要参数、

设置等系统信息，并填写试运行报告相关内容。系统参数、

设置的转换工作作为系统上线的验收的评估指标之一。

数据迁移前，应制定详细的《数据迁移计划》(附件十

三),《数据迁移计划》中应包含迁移方案、测试方案、数

据定义，新旧数据对照表、迁移时间、回退计划等信息。数

据迁移计划需经项目经理和主管领导签字审批。

数据迁移后，项目组对数据迁移的完整性和准确性作出

检查，出具《数据迁移报告》(附件十四),其中包括数据

来源、转换前状态、转换后状态，数据迁移负责人、对完整

性检查情况、对准确性检查情况等内容。各相关部门验收转

换结果后在该报告上签字确认。

系统转换和数据迁移由试运行单位业务部门和公司主

管领导共同监督并进行验收。

系统转换和数据迁移验收通过后，正式启动试运行。在

试运行过程中，试运行单位办公室把系统运行情况(系统资

源使用，反应速度等)记录到试运行报告中。必要时，项目

组应根据系统运行情况对应用系统进行优化。

试运行达到试运行计划规定的终止条件时，项目组编写

《试运行报告》(附件十五)。此报告应由项目组和试运行

单位签字确认，并提交公司主管领导审阅。公司主管领导审

阅试运行结果，决定试运行结束或延期。

2.10.系统验收

系统主要使用部门及信息技术部门联合组成独立系统

验收小组，也可授权原项目组作为验收小组。验收小组从功

能需求及技术需求层面对系统进行综合评估。

验收小组应根据验收情况整理形成《系统验收报告》(附

件十六)提交系统主要使用部门和信息技术部门审阅。

系统主要使用部门和信息技术部门负责人根据系统测

试、试运行情况签署验收意见。

2.11.系统上线

系统上线应遵循稳妥、可控、安全的原则。

通常情况下，系统上线包含数据迁移工作。

项目组制定《系统上线计划》(附件十七),上报公司

主管领导审批。在上线计划得到批准后才能开始部署上线工

作。

《系统上线计划》内容应包括但不限于：

部署方式和资源分配(包括人力资源及服务器资源);

上线工作时间表；

上线操作步骤以及问题处理步骤；

项目阶段性里程碑和成果汇报(项目执行状态的审阅、

进度安排等);

数据迁移的需求和实施计划；

完整可行的应急预案和“回退”计划；

用户培训计划(包括：培训计划、培训手册、培训考核

等);

公司下发的系统标准参数配置。

上线单位在上线初期需加强日常运行状态监控，出现问

题时应及时处理，对重大问题应启动紧急预案。

在完成上线后要填写《系统验收评估报告》(附件十八),

上报公司项目组汇总整理。《系统验收评估报告》内容包括：

数据准确性、系统性能及稳定性、接口问题、权限问题、业

务操作影响度、问题处理情况、备份、批处理等。

上线单位管理层要对《系统验收评估报告》进行审批签

字。

公司主管领导批准结项后，业务组和IT组将整理的文

档提交各自部门统一管理。

第三章合作开发管理

合作开发商的选择应遵循公司相关规定，合作商资质认

定参见第三方管理制度。

合作开发商必须遵循公司《软件开发管理制度》。

项目经理同合作开发商明确规定项目变更的范围和处

理方式，重点关注需求和设计变更。

项目经理负责监控合作开发商的项目管理及软件开发

活动。合作开发商应按计划定期向项目经理报告进展状态，

并提交阶段性成果文档。发生重大问题时，合作开发商需及

时向项目经理汇报。

IT组组长派专人监控合作开发商的质量保证过程。

项目组同合作开发商商定验收的标准和方法。

以上各要求需要在开发合同中明确。

3.1.立项分析报告

文件状态：文件标识：ProjectName-

[√]草稿当前版本：X.Y

[]正式发作者：

布

完成日期：Year-Month-Day

[]正在修

改

版本历史

版本/状态作者参与者起止日期备注

小语种翻译软件服务项目

项目介绍

1.1.项目目的

1.2.提示：用简练的语言说明本项目“是什么”,

“实现什么目的”。描述简练且清晰。

1.3.项目背景

1.4.提示：阐述项目背景，重点说明“为什么”

会产生本项目。

1.5.(1)公司的短期、长期发展战略；

1.6.(2)业务需求及发展趋势；

1.7.(3)技术状况及发展趋势；

1.8.(4)特殊的业务需求等。

1.9.项目范围

1.10.提示：根据对现有需求的了解来确定项目基

本范围，说明本系统“应当包含的内容”和“不包含的

内容”。

1.11.项目计划

1.12.项目团队

1.13.提示：说明项目团队的角色、知识技能要求、

建议人选、人数、工作时间，如下表所示。

知识技能要建议人选、人

角色工作时间

求数

项目经理

需求开发人

员

系统设计人

员

编程人员

测试人员

质量保证人

员

配置管理人

员

服务与维护

人员

成本估计

内容成本(人民币)备注

人力资源

软硬件资源

差旅费

会议费

接待费

进度表

提示：制定项目开发的进度表(建议给出项目里程碑计划)。

例如：

编号里程碑名称预计结束时间备注

需求调研完成

项目计划完成

需求分析完成

概要设计完成

详细设计完成

实现完成

集成测试完成

系统测试完成

用户验收测试

完成

试运行结束

项目验收

总结

提示：给出清晰的建议结论，便于上级领导决策。

业务需求说明书

文件状态：文件标|ProjectName-

[√]草稿识：

[]正式发当前版X.Y

布本：

[]正在修作

改者：

完成日Year-Month-Day

期：

版本历史

版本/状态作者参与者起止日期备注

1概述

1.1业务调研人员名单

【可选】

职能部门姓名主管联系电话备注

序

号

1.2业务范围

此处描写总体业务的概要分类并。

1.3业务目标

从高层或商务利益的角度提出本业务系统的期望目标，

以及评价标准。

1.4相关文档

说明：列出本文档的所有参考文献(可以是非正式出版

物),包括现有规范、标准、批文、引用到的文件、资料等。

1.5业务词汇表

说明：列出本文档的所引用的专属领域词汇、术语等，

以便于业务需求的提供者和接收者是建立在一致的业务理

解基础之上的。

2组织结构及业务

2.1业务相关组织结构、人员组织结构

说明：如果客户岗位设置复杂可分别设置，业务组织结

构和人员组织结构

2.2组织机构描述

2.3角色职责

说明：将业务涉及的具体人员进行一定程度的分类和抽

象，描述该抽象角色的操作职责。

2.4管理综述

【可选】

说明：主要描述该业务的管理特点和管理模式。例如：

典型按库存生产模式。生产计划以年度销售计划为指

导，并综合考虑设备能力、生产天数、库存、历史销售记录。

采购计划的制订以生产计划为依据。

2.5现有业务流程清单

【可选】

说明：现有业务流程需要考虑，很多新的业务是在已有

业务流程基础上进行重组的。

流程编号流程名称责任部门辅助部门

3业务流程及业务处理描述

说明：针对每一项具体的目标业务，描述具体的业务流

程，以及相关业务的具体描述。

3.1具体业务流程(系统名称+编号)

对于具体业务流程的命名有规范，对具体流程进行编

号，便于形成需求矩阵，同时形成需求的管理和跟踪。

3.1.1业务流程

3.1.2业务描述

说明：描述具体的业务流程。

3.1.3相关业务对象

说明：业务对象：业务流程中涉及的单据、报表等。

业务对象使用部门对应电子档案编号

3.1.4业务规则及关键算法

说明：描述业务环节关键算法体系。

4假定和约束

说明：列出进行本软件开发工作的假定和约束，例如开

发期限等。

4.1运行环境约束

4.2设计约束

【可选】

说明：开发过程中必须使用的软件语言、软件进程需求、

主要开发工具、核心技术、第三方产品等。

4.3产品应当遵循的标准或规范

【可选】

说明：阐述本产品应当遵循什么标准、规范或业务规则，

违反标准、规范或业务规则的产品通常不太可能被接受。

5其他

5.1目前核心问题和困难

5.2业务对项目实施的需求和期望

【可选】

5.3其他未尽事宜

系统需求规格说明书

文件状态：文件标ProjectName-

[√]草稿识：

[]正式发当前版X.Y

布本：

[]正在修作

改

者：

完成日Year-Month-Day

期：

版本历史

版本/状态作者参与者起止日期备注

1引言

1.1目的

例如：规定系统的边界和目标，描述系统的功能性需求和非

功能性需求。

1.2读者对象及阅读建议

说明：指明本文档面向的读者群，及相应的阅读意见。

1.3文档范围

【可选】

说明：对本文的范围做阐述，本文档改动时，受到影响的范

围，例如，本文引用到的用例模型，系统原型，系统测试用

例等文档。

1.4参考文档

说明：列出本文档的所有参考文献(可以是非正式出版物),

包括计划任务书、合同、批文、引用到的文件、资料及软件

开发标准等。

1.5术语与缩写解释

说明：列出本文件中用到的专门术语的定义和缩写词的原词

组，并给予解释，以便于所有读者达成共识。

2综合描述

2.1系统背景

【可选】

说明：介绍系统的预期效果、历史原因。

2.2问题说明

【可选】

提供一段说明，总结此项目需要解决的问题。可以采用以下

格式：

问题是[对问题进行说明]

影响[问题影响的干系人]

问题的后果[该问题会导致什么后果]

成功的解决方案[应列出成功解决方案的一些主要优

点]

2.3系统范围

说明：阐述本项目“适用的业务领域”和“不适用的业务领

域”,本产品“应当包含的内容”和“不包含的内容”。说

清楚系统范围的好处是：(1)有助于判断什么是需求，什

么不是需求；(2)可以将开发精力集中在产品范围之内；

(3)有助于控制需求的变更。

完整而准确的定义本产品的干系人；

明确本产品所影响到的部门和业务；

用图表或者文字描述产品的范围，概要的定义产品的功能。

2.4干系人与用户说明

【可选】

2.4.1用户环境

【接口配置】

(1)接口基础信息配置

说明：接口基础信息的配置项目，描述配置的方式。

(2)接口运行参数配置

说明：接口运行参数的配置方式和步骤。

【其他配置[可选]】

说明：外围系统或相关模块的配置。

3.2.1.4通信接口

【可选】

说明：指定各种通信接口。例如，局部网络的协议等等。

3.2.2其他非功能性需求

说明：下表中的各种需求，可根据实际情况进行选择其中的

一种或者几种进行描述，在表的后面是各种需求的详细解

释。

名称详细要求

静态数值需

求

动态数值需

求

精度

时间特性要

求

可用性

可靠性

可维护性

安全性

可移植性

可扩展性

兼容性

3.2.2.1静态数值需求

说明：支持的终端数；支持并行操作的用户数。

3.2.2.2动态数值需求

说明：欲处理的事务和任务的数量，以及在正常情况下

和峰值工作条件下一定时间周期中处理的数据总量。

3.2.2.3精度

说明：对该软件的输入、输出数据精度的要求，可能包

括传输过程中的精度。

3.2.2.4时间特性要求

说明：对于该软件的时间特性要求，如对：

a.响应时间；

b.更新处理时间；

c.数据的转换和传送时间；

d.解题时间等要求。

3.2.2.5数据管理要求

【可选】

说明：需要管理的文卷和记录的个数、表和文卷的大小

规模，要按可预见的增长对数据及其分量的存储要求做出估

算。

3.2.2.6可用性

指出普通用户和高级用户要高效地执行特定操作所需的培

训时间，指出典型任务的可评测任务次数或根据用户已知或

喜欢的其他系统确定新系统的可用性需求

性能

3.2.2.7可靠性

指出可用时间百分比(xx.xx%)、使用小时数、维护访

问权、降级模式操作等。平均故障间隔时间(MTBF)。平均

修复时间(MTTR)一系统在发生故障后可以暂停运行的时

间。指出系统输出要求具备的精密度(分辨率)和精确度(按

照某一已知的标准)。

3.2.3文档需求

说明：主要是在线用户手册与帮助系统，也包括其他的

文档

3.2.4第三方产品

【可选】

说明：使用到的第三方产品相关的使用许可、使用限

制、接口标准。

3.3数据字典

说明：把相关的数据抽取出来统一维护，在其他章节如

有类似信息描述，则关联到数据字典的相关部分并加辅助说

明，如：引用到的字段等。

4补充资料

【可选】

4.1待确定的问题列表

【可选】

需求标题

1

调查方式

调查人

调查对象

时间、地

点

需求信息

记录

需求变更申请

记录号：

项类型：开发项目

目：

项目负责变更申请人：

人：

申请部门：申请日期：

变更内容

变更的内说明变更的内容及变更的理由，

容如果变更为业务组提出，则业务组填写；

及其理由如果变更为为信息技术组提出，则信息技术组填写；

变更的系说明变更所涉及的工作产品及其当前版本，

统及版本如果变更为业务组提出，则业务组填写；

如果变更为为信息技术组提出，则信息技术组填写；

对业务及分析需求变更引起的业务变更、业务接口的变更，

其接口的业务组填写

影响

业务负责同意不同意

人意见：

签字日期：

变更