疯狂五笔打字通项目开发计划.doc

疯狂五笔打字通项目开发计划
第一部分、引言
1.1编写目的
本计划编写目的是更清晰地理解<<疯狂五笔打字通>>要求，现在在日常生活中越来越多的人与计算机打交道了,如上网聊天及办公等等.他们也在从不同的角度努力的提高自己的汉字的输入速度,但是同样将要许多的人为此而感到苦劳,现在你不必为这些琐事而苦劳.<<疯狂五笔打字通>>将会给你带来一个全新的概念,帮助你在短短的时间里事办功倍,轻松的掌握五笔字型计算机汉字输入技术,我们专为大家准备了<<疯狂五笔打字通教程>>即使你没有五笔概念,也会轻松掌握五笔打字技术,该软件面向广大计算机爱好者.进一步明确项目需要做的工作，并为保证项目在范围和进度方面的要求提供可执行的依据，包含了范围、进度、人员安排在内的明确的计划和安排，以切实能保证项目能在控制中完成。
1.2 背景
说明：
A、 软件系统的名称： 疯狂五笔打字通
B、 任务提出者：3高05级北大青鸟班第1小组开发组
开发者：3高05级北大青鸟班第1小组开发组
本系统完成后是针对五笔爱好学习和提高产品，在市场上独立销售。
C、 本系统将是独立的系统，目前不与其他的系统或者操作系统提供特别的接口，所产生的输出都是独立的。
本系统将使用Access作为数据库存储系统
1.3定义
WBS——Work Breakdown Structure，工作分解结构，面向可交付成果的工作分解；
RAW——Responsibility Assignment Matrix，职责分配矩阵，描述在不同阶段和人员配备情况；
Critical Path——在NDG中描述项目的关键路线；
Milestone Chart——项目的里程碑图，标识项目的关键进程点；
受控文件——北大青鸟Aptech内部已经形成标准的规范性文件，在执行过程中做强制性的要求；
1.4参考资料
相关的文件包括：
A.<<五笔字型简明短训教程>>字根表;
B.<<五笔字型简明短训教程>>简码和词组
C.北大青鸟Aptech ACCP3.0《基于软件开发项目的毕业设计》；
第二部分、项目概述
2.1工作内容
为完成本项目，需要按照需求分析、设计、编码、测试等不同的阶段来进行，其中，本计划不考虑维护阶段所做的工作。
需求分析明确本项目所开发产品的特性，并对进行划分，并不同的功能组得到用户方的确认。
编码实现将按照软件产品设计所描述的内容，编写代码实现软件各部分的功能。
测试部分包括对实现过程中的错误的修改、功能的改进的一些活动，同时包括了各子系统、模块、功能点的组合。
以上的过程中，包含了不同阶段的文档输出工作，并且上一阶段的输出，通常作为下一阶段的输入而存在。
详细的工作包和任务的分配，请参考第二部分执行计划的工作内容。
2.2主要参加人员
本项目全职参与人员包括：
人员名称
主要职责或职务
成员技能说明
熊占洲
项目经理 程序员
项目的规划、指导，数据库的设计
廖阳
程序员
VB界面设计 文档 参与系统分析 PPT制作
杨智
程序员
软件工程师，参与VB编码和接口设计、系统连调
刘曜
程序员
测试的产品化工作 数据库构件初步工作
张家伟
程序员
测试的产品化工作、数据库构件初步工作
李文彪
程序员
数据库构件初步工作 参与系统分析
2.3产品
项目的最后的产品和可交付物包括最后完成的软件包、相关的文档、手册、宣传内容等，分别如下：
2.3.1程序
完成的软件系统:
最后完成的软件系统，其功能、模块和性能要求请参考文档《任务管理项目需求说明书》中关于产品特征的描述。
2.3.2文件
1、帮助文件
帮助文件提供用户对软件系统的操作指导，要求同时提供.DOC格式的电子文档。
2、培训资料
相关的培训的资料要求直接在软件中提供给用户（具体的格式，以.CHM的电子书教程）。
。
2.3.3服务
在产品到市场发行后，项目成员提供技术方面的咨询服务，这些服务属于维护阶段的一部分。
2.3.4非移交的产品
非移交的产品包括过程记录和过程文档，包括：
A、软件的源代码
程序的源代码不提供给用户。
B、安装程序工程
C、需求文档
A、 过程评审记录
可能发生的需求、设计、实现和验证阶段的评审记录、评审报告，都不提交给最终用户。
B、 设计和规划文档
包括产品设计、过程规划等方面的文档，不提供给最终用户。
C、 测试记录和测试报告
不同阶段的测试规划、测试记录、测试报告等文档，都由产品开发部门保留、归档。

以上非移交的产品，不得提供给其他的单位或者个人，或者用于其他的商业事务，详细的说明参考公司的保密和安全规定。
2.4验收标准
A、程序：
程序中应包含的功能如下：
1. 永久存储用户输入的任务的信息；
2. 任务调度和任务查找操作简易；
3. 任务的删除和更新；
4. 能够针对任务设置启动时间、终止时间、任务时间间隔；
5. 任务启动的提示多任务的启动提示；
6. 显示系统的时钟；
7. 任务启动时间、终止时间、任务启动时间间隔调整；
8. 在多用户环境下，允许不同的人管理自己的任务；

Access数据库应具备抵抗非法访问的特性。
B、服务
其他维护的要求按照维护阶段的内部约定进行。
2. 5完成项目的最迟期限
项目的系统测试的最后完成日期为2006-5-28日，然后在2009-5-26前，进行运行时测试、B测试、产品化工作，包括用户培训等服务活动的实施。
系统在2006-5-30起，正式投放市场使用。
3. 6本计划的批准者和批准日期
本计划的批准人为产品开发部门经理。
本计划的正式批准日期为2006-5-15日，实施日期为2006-5-16日。
第三部分、实施计划
3.1工作分解与人员分工
本项目的工作分解如下：

C3：项目首次会议：项目经理召开团队会议，进行早期的工作安排

设计阶段

项目计划

D1：项目开发计划，进行规划和总体安排
D2：项目计划的审核和发布

产品设计
D9：整理以上子系统的设计，编制系统详细设计
D5：模块设计：数据库的访问控制程序
D6：模块设计：任务的增删改查操作的设计
D3：针对需求提出计算机模型、逻辑设计、功能设计，形成概要设计文件
D4：对数据库进行规范化和对象设计，并形成数据库设计文件
D8：模块设计：任务调度程序界面及控制
D7：模块设计：主界面和D7相关的界面设计

C2：需求说明：识别需求，并形成需求说明文档
C1：需求调查：同用户接触，收集相关数据
概念阶段

I3：模块实现：设计和实现主界面和D7相关的窗体
I1：模块实现：编码实现数据库的访问控制程序
实施阶段

I2：模块实现：编码实现任务的增删改查操作

I4：模块实现：任务调度程序界面及控制

I5：数据库的创建及测试数据的输入

I13：B和运行时测试

I14：编写程序的帮助工程，编译和连接为系统的帮助文件
I16：软件打包和安装程序的测试
I15：制作软件的安装程序、安装界面

I11：组合以上的模块为系统，进行系统测试
I10：对以上模块之间的接口进行测试，并进行调试
I8：主界面和D7相关的窗体的单元测试和验证
I7：任务的增删改查操作的单元测试和验证
I6：数据库的访问控制程序的单元测试和验证

I9：任务调度程序界面及控制的单元测试和验证
I12：整理系统测试文档，进行功能调整和改进
I17：整理开发文档，编写用户操作手册

T1：收集记录、规划和设计文档，并进行文件的归档

收尾阶段

T4：安排后期维护人员，解散项目团队
T3：项目总结会议
T2：对B测试、运行测试等用户表示不满意的程序、界面、手册进行修订

（说明：
1、以上的工作，可以在更细的层次上进行分解，例如I7，可以分别为查询界面、增加的界面和删除的询问词的设计等，系统测试可以分解为测试平台的搭建、测试用例的编写、系统各功能点的测试、测试记录的填写、测试总结和总结报告等多个工作单元。
2、有关测试、工作分解的详细内容、文档规格，请参考ACCP3.0后续课程的描述；
3、以上的工作分解，不存在时间先后的次序。）

按照工作分解，职责分配如下：

人 员
工作包及说明
熊占洲
廖阳
杨智
李文彪
张家伟
刘曜
C1：需求调查
S
P
P

P
A
C2：编写需求说明和需求分析文档

P

P
A
C3：项目启动会议
S
P
P
P
P
P
D1：计划会议、项目专题讨论、编写项目计划
A
P
P
P

D2：项目计划的审核和分发执行
S

D3：系统的总体设计相关内容
S
A
P

P

D4：数据库设计相关内容
S
A

P
D5：模块设计：数据库的访问控制程序
S
A

P

D6：模块设计：任务的增删改查的操作
P
A
P
P

D7：模块设计：主界面和D7相关的界面设计
S
A

P

D8：模块设计：任务调度控制程序
P

A
P

D9：整理和编制详细设计，作为编码的依据
S
A
P

P
I1：模块实现：编码实现
S

I5：准备数据库和测试数据

P

P

A
I6：单元测试和调试：I1
P

A

I7：单元测试和调试：I2

P

A

I8：单元测试和调试：I3

P

A

I9：单元测试和调试：I4

P
A

I11：系统的组合和系统测试
A
P
P
P

I12：系统测试报告和反馈

P
P
P

A
I13：B和运行时测试

P
P
P
P
A
I14：帮助工程和帮助文件制作
P

P

A
I15：安装工程和安装配置

P

P

A
I17：编写用户操作指南

P

P
P
A

T1：文件归档

S

P
A
T2：程序、界面、手册的反馈和修订

P

P

A
T3：项目总结
A
P
P
P
P
P
T4：项目结束和团队解散
A

P —— 参与人员；A —— 负责人员；S —— 确认审核人员；

3.2接口人员
负责接口工作的人员及他们的职责，包括：
A、项目经理负责廖阳负责同用户的组织接口事务，包括变更和事务协调等；
系统分析员熊占洲负责用户的技术接口，包括一些技术方案的演示和确认；
产品专员廖阳负责同用户的人际接口，包括文档、资料和一些事务性的沟通。
B、 项目组长负责组织内部的接口，包括项目进度报告，资源协调等；
C、 项目组长负责处理同外部组织、专家评审方面的接口；
以上的接口事务，在上面的职责分配图中已经进行了表述。
3.3进度
最后的项目网络图如下：

完成项目至少需要的时间用红色的线表示，项目的完成线路（完整完成项目最少所需要的时间）为：
1 – 2 – 3 – 4 – 7 – 10- 13 – 14 –17 –21 – 24 – 25 –26 – 31 - 32 –33 – 34
对应的时间为：3+3 +2 +2 +3+3+2+2+3+3+4+2+4+1+1= 38（工作日）
预留20%作为整体浮动时间，实际需要的工作日为46。

在并行一些工作的条件下，项目预计完成的时间在两个月左右。
（说明：非关键路径活动所需要的时间，没有在项目网络图上标识。）

13
C3
D3
12
D1、D2
11
3
2
1
C1 3
Start

I5 3
D3 2

14
4

D4
D5 D6 D7 2 D8
C 2 2

9
8
7
6
5

D9 3

10

T2 2
31
I17
309

T3 4

32

29
17
15
14
I1 I2 I3 2 I4
18
16

I6 I7 I8 2 I9

I16

I15
22
21
20
19

I10 5
28
I14
27

T1 1
T4 1
34
END
33

I13 4
26
23

I12 3
I11 3

25
24

项目的开始日期为2003 – 9 – 1日，项目的里程碑（阶段点）时间：

明确了功能需求，并且正式准备开始项目的设计工作

产品的概要、详细设计完成

模块编码、单元测试和调试完成

系统调试结束、手册编写完毕

B、运行测试结束、产品发布

. . . .
9/8 9/18 10/8 10/20 11/2

3.4计算机系统支持
硬件环境：
CPU：PIII750或者更高频率
ROM：256或者更高内存支持
磁盘：8G
软件支持：
开发所用的操作系统：Windows 2000 Server SP1
开发工具：Visual Studio 6.0 SP4
数据库系统：MS Access
5．1 配置管理计划
配置管理所关心的问题涉及以下三点：
1、 仔细定义软件系统的交付物；
2、 严格控制对可交付物的变更；

3、 确保软件系统的可交付物与既定的或者经过核准修订的可交付物相一致。
北大青鸟Aptech所有的软件项目配置管理采用标准的表格模板，并遵循了标准：《计算机软件配置管理计划规范》(GB/T 12505-1990)，本部分加以引用。
本部分可以作为变更控制的依据。

计划名称
任务管理项目配置管理计划
项目名称
任务管理项目
开发单位
北大青鸟Aptech产品开发部
项目经理
张惠明

引言

目的

1、 明确“任务管理项目”产品开发的范围、特征；

2、 对由于用户后期提出的范围改变、在设计中没有考虑周全的特征或者性能指标、牵制性的改变等导致的变更申请，定义变更的控制程序；

3、 提供验收的标准和程序，确保可交付的产品符合用户既定的要求；

4、 提出资源和机构的支持要求；

定义

1、 WBS：工作分解结构；参考前面的说明；

2、 项目网络图：项目时间估算的活动时序图，参考以上的说明；

参考
资料
1、《任务管理项目章程》；
2、《任务管理项目需求说明》；
3、《任务管理项目概要设计》；
4、本计划的范围管理部分；
5、本计划的进度管理部分；
6、《计算机软件配置管理计划规范》(GB/T 12505-1990)

管理

机构

（不适用）

任务
相关机构、人员对配置管理的任务包括：
Q1：项目范围的提出；
Q2：项目范围的确定；
Q3：项目范围的更改；
Q4：更改后项目范围的核实和验证；
Q5：产品特征的过程管理；
Q6：可交付物的特征、性能验收对比；

人员
职责
说明
1、 由市场代表____高名君_____、项目开发方顾问组成员__张林、林夏、胡邻___组成配置管理委员会，实施配置管理程序；
2、 市场代表____高名君__负责进行产品范围的提出，提供必要的资料和数据、提出变更申请和对可交付物的验收评估；
3、 项目实施方 李明生 负责项目初期的资料收集、用户面谈、问题整理、并形成正式的需求文件；
4、 在计划实施阶段，所有的变更要求必须由市场代表____高名君_____进行提出或者认可，所有的变更必须经过变更控制委员会的讨论（正式或者非正式的沟通），并把变更意见及时传递给项目实施方。
5、 项目收尾阶段，由市场代表_____朱青_____、项目开发 张惠明 共同进行产品审核，并记录审核结果，传递给变更控制委员会。

管理计
划实现
（变更控制程序）
A：控制和实施阶段
1、 在突发事件的情况下项目经理可以对项目范围进行变更，并在事后把变更说明提交到变更控制委员会；
2、 范围变更通常牵涉到人员、费用、进度、风险和质量等多个方面，所有的变更都要求对这些方面的考虑和权衡，对于引起这些方面明显的变动，需要更改这些方面的设计，并且进行相关的记录；
3、 项目组其他成员可以对范围提出变更意见，但必须填写统一的《问题报告单》形成正式的变更请求；并鼓励每一个项目成员提出新方法、新工具以提高项目的开发进度，但严格控制在未经讨论的擅自变更，这些变更指WBS中未规定的事情；
4、 对于客户提出的变更，视变更影响的大小，首先须经变更控制委员会正式或者非正式的讨论，把最后的变更意见交由项目经理实施；
5、 WBS中对每一个消耗资源的活动都进行了定义，但并不表示WBS是不可更改的，所有经过变更都要求反映在WBS中，并且WBS所在的主文件以修改次数进行标识；
6、 范围基线的变更要严格控制，除非在不能挽救的情况下，范围基线不允许变更；范围基线变更必须经过变更控制委员会正式的会议；
7、 程序的变更、代码的更新所形成的软件的新的调试版本，以版本管理程序和源代码管理程序进行标识和记录，项目经理要确保当前使用的版本反应了最新的变更（附件中规定了版本和源代码记录的模版）；
8、 变更的内容、质量要求须同时遵循质量计划、质量标准的相关事项；
9、 用户手册、培训计划要求业务或对应功能相关的人员进行书写，并且按照进度计划中所规定的最后日期进行审核，所有的修订意见同时应通知变更控制委员会中实施方的成员；

B：概念和计划阶段
10、 在需求描述阶段，实施方把用户所要求进行开发和设计的内容清楚的理解并描述为文档，最终的正式范围说明需要经过包括变更控制委员会所有成员在内的正式评审，并作为后续工作的依据；

C：收尾阶段
11、 产品最后的验收依据是经过变更控制委员在计划阶段批准的范围说明，同时有效的是可能对产品特征明细或者未明细的正式合同，合同附件具有同等的效力；
12、 可能需要返工或者返修的可交付物需要用户的正式认可，同时在项目计划中加以说明；
13、 在用户接受产品并要求结束合同的同时，变更控制委员会对控制绩效进行总结，收集相关的文件、质量记录并进行归档，在这些工作完成后宣布解散委员会；

配置
管理
活动

配置
标识
文档：
《问题报告单》；
《版本清单》；
《源代码清单》；
《设计评审》；
《需求评审》
Microsoft Visual SourceSafe的版本标识；
程序：
需求评审；
设计评审；
项目中期评估；
项目验收评估；

配置
控制

1、 变更控制委员会在召开项目首次会议时进行组建；
2、 变更控制委员会只能在用户签署正式的产品接受文件后方可解散，变更控制委员会对产品维护阶段的问题不承担责任；
3、 变更控制委员会的成员可以增加，但在人员计划中必须做必要的变更，本计划的相关部分也需要修订；
4、 变更控制委员会有义务对产品的质量进行跟综和评价，有义务提出变更请求，以确保项目最后的产品符合使用者的要求；

配置状
态审查
1、 公司的直接项目领导负责配置委员会工作的审查；
2、 配置委员会负责产品的阶段性审查和评估，这些评估包括质量记录的抽样检查、产品性能特征的指标检查和相关受控文件的更改过程合法性检查；
3、 项目经理对产品实施过程进行控制，纠正和预防措施将是两个最常用的手段，并且在本项目中具有工作授权体系所有的责任，这些责任中最重要的是控制每一个工作包的开始时间点；

配置检查以及审核

配置检查和评审的权限只有公司最高领导层才能进行授权，在本项目中，所涉及的内容包括配置委员会的成立、解散需要经过公司最高领导层的正式批准。

公司最高领导层可以在项目阶段的任何时间进行配置检查和审核，并提出更改和提高的指令和建议，这些指令或建议必须执行或者认真考虑。
对供货单
位的控制
（本项目在项目启动阶段已经确定系统的绝大部分功能自己完成，牵涉的采购管理部分非常少，因而本部分的描述在此弱化，但相关的变发生后，本部分要求清晰的说明）

纪录
的收
集维

护和
保存

A、 软件调试版本的改变，要求填写《版本清单》，对半成品或者成品分别进行标识，源代码和版本都需要同时进行备份；
B、 所有的阶段性评审和最后的评审，都需要填写评审报告；
C、 单元测试要求填写《单元测试记录》，对存在的问题的反映填写《系统问题报告》，而对问题的改进所做的工作用《修改报告单》进行填写；
D、 组合测试和集成测试需要准备《测试计划》，测试完毕后形成《测试报告》。

公司具有相关的企业标准、工作规程，并在制定的同时参考ISO9001 2000的一些条款，关于质量记录的收集和维护同时要求遵循公司的规范和惯例。

备注
上述所提到的所有质量记录在附件中都有模版，这些模版都属于公司的受控文件。

5．2 质量管理计划
5．2．1、依据
A、质量政策
北大青鸟Aptach科技发展有限公司在软件产品设计和开发方面通过了ISO9001 2000的规范，同时制定了质量方针和质量目标：
质量方针：通过严格和规范的过程管理、文档化的流程开发，提高生产效率，为客户提供稳定、易用和符合要求的产品系列。
质量目标：在软件方面的年纯利润达到200万元，并以每年不低于40%的比率递增。
（以上质量方针和质量目标只是一个范例，并非北大青鸟Aptech公司事实上的质量目标。）
本项目同时遵循和贯彻公司的质量方针和质量目标。
B、范围说明

参考《任务管理项目需求说明》。
C、标准和规范
在质量方面，需要遵循的标准和规范包括：
A、《质量管理体系标准》（GB/T 19001-2000），2000-12-18，国家质量技术监督局；
B、《计算机软件产品开发文档编制指南》（GB/T 8567-88）,1988-7-1，国家质量技术监督局；
C、《计算机软件质量保证计划规范》(GB/T 12504-1990)，1990-11-15，国家质量技术监督局；
D、《北大青鸟Aptech公司质量手册》2002-5-1；北大青鸟Aptech
E、《北大青鸟Aptech公司程序文件》2002-5-1；北大青鸟Aptech
5．2．2 程序及过程
本部分规定本项目全面质量管理所规定的实施过程，在WBS中，所有的活动安排都是与质量保证相关的，因而也是WBS元素项的说明。

A、影响质量的因素
在本项目中，影响质量的因素可以用以下的鱼骨刺图（ISHKAWA逻辑图、因故分析图）来说明：
项目的意义
沟通
方法和技术
人员

产品的主要缺陷

进度控制
资源配置
测试和评估
变更

鱼骨刺图的子可以进行多层分解，下面只简要说明影响因素以及本项目在这方面的预防措施：
A、 人员：
人员的技能水平、工作习惯、合作往往会对项目的质量产生直接的影响；
本项目组的主要成员都具有计算机工程学士学位，并且至少具备三个以上的应用软件开发经验，主要的成员在以前的一个项目中有过成功的合作经验；
B、 方法和技术
本项目涉及的方法和技术包括关系数据库管理、查询管理、界面等应用技术，这些技术都是标准和成熟的技术，所选择的团对成员要求具有这方面的经验，以减少培训的支出和技术方面的风险；
C、 沟通
制定完备的沟通管理计划并执行，在下一节，你可以看到沟通计划、信息分发、绩效报告等方面的内容。
D、 项目的意义
项目取得成功所具有的意义、团队收益以及个人绩效的评估在项目的首次会议就需要明确，高昂的士气给项目带来的好处可以直接从质量方面体现。
E、 变更
变更的控制对该项目质量的影响是比较大的，这些变更包括进度、成本和产品特性方面的要求的变更，为防止不必要的变更，产品组与用户共同成立了变更控制委员会，所有不在需求文档中说明的要素，都需要通过变更控制委员会批准。
F、 测试和评估
尽管本项目不是一个大的项目，测试（检查）和评估依然分别分为四个部分，包括每个独立单元的测试、单元组合测试和集成的测试，在用户使用过程中还包括一些改进型的测试，以确保软件系统的满足使用的质量要求；评估包括需求、设计和最后的检验性评估，同时评估团的意见对质量的提高也具有莫大的好处。
G、 资源配置
资源包括设备资源和人员，在设备方面，公司确要保有足够的计算机用于开发和测试，除安排每个开发成员至少一台专用的计算机外，额外的测试的计算机要保证每人一台，共用网络打印机。
基于进度的考虑安排足够的成员加入开发组，并在用户对进度有更高要求的情况下增加项目成员。
H、 进度控制
进度对质量的影响大部分是由于赶工和快速跟进时对质量控制的弱化所造成的，项目经理应对此负直接的责任，在运用任何进度更新方法的同事，项目经理需要仔细权衡对质量带来的影响。
本项目为进度预留了充分的缓冲时间，这些时候为后续的测试、符合性检查提供了保证。

B、检查和评审
检查（测试）和评审是质量保证和质量提高的重要方法，它包括下面的过程：

需求说明
开始
需求评审
概要设计
详细设计
设计评审
Y
N
Y
N
子系统、模块实现
单元测试
子系统、模块组装
组合测试
打包和安装
集成测试
交付
总体评估
结束
中期评估
Y
N
Y
N
N
Y
Y
N
Y
N

图表说明：
1、 在WBS中以上各单元都有对应的工作包；
2、 中期评估和总体评估发现质量问题，并采取相应的纠正措施，可能会在它前面的任何阶段进行；
3、 测试包含多个反复循环的过程；

5．4媒体和版本控制
版本管理工具采用Microsoft Visual SourceSafe，并且要求记录每个调试版本的变更情况，项目经理确保当前使用的版本是最合适的版本。
产品在交付的时候，采用光盘的形式，并确保没有损坏。
5．5纪录的收集和维护
参考配置管理计划的相关项，并要求符合ISO9001 2000有关记录收集和维护的要求。

5．3 沟通计划
本项目在规模上属于小项目，在人员安排和沟通方面都比较清晰和明确。在上面的职责分配中做了每人所参与、负责、评议的详细说明。
5．3．1 项目成员
参加本项目的主要人员包括：
熊占洲
项目经理，曾经负责过七个以上的软件项目的管理工作，在本项目中，负责项目的规划、接口、协调及一部分代码工作。
廖阳
系统分析员，具有八年的行业经验，在本系统中负责项目的分析和设计，及一部分编码和测试的工作。
李文彪
软件工程师，有三年的C/S结构开发经验，对数据库技术、VB技术能够进行娴熟地应用，在本项目中负责数据库设计的一部分工作及原型代码的编写、界面设计等。
张家伟
测试工程师，有应用系统开发和设计的经验，接受过专门的测试培训，在本项目中，负责技术接口、组合测试、系统测试及质量保证的一些工作。
刘曜
产品工程师，负责文档编写、用户接口及沟通，安装和帮助原始文档的编写及整理及产品化相关的工作。
杨智
产品工程师，负责文档编写、用户接口及沟通，安装和帮助原始文档的编写及整理及产品化相关的工作。

编写人：廖阳(手写)
批准人：熊占洲 (写)
日 期：2003 – 9 – 8
20