项目管理系统在线考试系统.docx

项目管理系统在线考试系统.docx

《项目管理系统在线考试系统.docx》由会员分享，可在线阅读，更多相关《项目管理系统在线考试系统.docx（28页珍藏版）》请在冰豆网上搜索。

项目管理系统在线考试系统

HUBEIUNIVERSITYOFAUTOMOTIVETECHNOLOGY

在线考试系统案例分析

目录：

1、导言3

2、项目概述3

3、项目任务围4

4、项目目标5

5、项目组织结构5

6、项目生存期5

7、时间计划7

8、项目成本估算7

9、质量管理计划7

10、配置管理计划12

11、项目风险计划17

12、度量计划18

13、项目沟通与评审20

1、导言

现在，计算机硬件技术的发展已经达到了相当高的水平。

但是，远程教育软件的开发目前还处于起步阶段，随着这项技术的不断深入发展，就要求有更好、更完善的软件系统应用到远程教育当中去，这就给软件设计人员提出了更高的设计要求。

远程教育包括很多环节，例如教学系统、答疑系统和考试系统等等。

其中很重要的一个环节就是在线考试系统，同时它也是最难实现的环节。

在我国，虽然远程教育已经蓬勃地发展起来，但是目前学校与社会上的各种考试大都采用传统的考试方式，在此方式下，组织一次考试至少要经过五个步骤，即人工出题、考生考试、人工阅卷、成绩评估和试卷分析。

显然，随着考试类型的不断增加及考试要求的不断提高，教师的工作量将会越来越大，并且其工作将是一件十分烦琐和非常容易出错的事情，可以说传统的考试方式已经不能适应现代考试的需要。

随着计算机应用的迅猛发展，网络应用不断扩大，如远程教育和虚拟大学的出现等等，且这些应用正逐步深入到千家万户。

人们迫切要求利用这些技术来进行在线考试，以减轻教师的工作负担及提高工作效率，与此同时也提高了考试的质量，从而使考试更趋于公证、客观，更加激发学生的学习兴趣。

例如目前许多国际著名的计算机公司所举办的各种认证考试绝大部分采用这种方式。

在线考试是现阶段研究开发的一个热点。

它是建立在国际互联网上的应用系统，客户端的配置可以极为简单，使考试不受地域的局限。

一个完备的在线考试系统可以使用户在网上学习过后及时检验自己的学习效果，已发现自己的不足，

使得学习效率得到很大提高。

在线考试系统中题目的生成、试卷的提交、成绩的批阅等都可以在网络上自动完成。

只要形成一套成熟的题库就可以实现考试的自动化。

这样一来，教师所要做的只是精心设计题目、维护题库，而不是组织考试，从而大大减轻了教师的负担，这表明其经济性是相当可观的。

为了适应新形势的发展，我进行了这一系统的初步设计工作，也可以说是做一个初步的探索，希望它能够在各类考试中发挥高效、便捷的作用,把老师从繁重的工作中解脱出来！

2、概述

在线考试系统主要功能包括学生管理、试卷管理、教师管理、学生在线考试等等。

在线考试系统是对学校考试方式的优化和改进，是基于INTERNET环境的综合考试系统，方便教师学生进行考试和查询。

目的是适应大环境的发展和方便信息的交流，充分利用学校资源，提高工作效率，系统具有标准化、分布式存储和检索、易用易维护开放等特点。

3、项目任务围

本文主要考虑的是高校部的在线考试系统，所以因其特殊性并不对所有人开放。

系统主要用户可以分为两类：

一种是学生用户，一种是教师用户。

其中学生用户能使用的功能有：

在线考试，成绩查询，修改信息等。

教师用户使用的功能有：

在线出题，修改成绩，修改试题，成绩查询等

任务分布见图一

图一、任务分布图

4、项目目标

目前电化教育已经越来越普及，各地的学校纷纷建设自己的校园网，但是好多学校在投巨资建设校园网之后。

未能高效的利用校园网的资源。

在线考试系统提供了有效利用校园网，实现考试的无纸化。

本软件产品可以达到以下目标。

1、提高考试效率，减少纸的使用

2、节省开支

3、考试过程的清晰化

4、符合学校的标准和规则

5、项目组织结构

由于该项目在实施过程中需要涉及不同组织的各方面人员，而各组织之间的利益、任务和职责也不尽相同，因此明确定义项目组织结构和各自职责可保证项目的顺利进行。

市场部：

负责项目的相关商务活动，负责与甲方交流商定。

负责产品的说明。

项目管理：

负责项目的组织和规划、负责项目计划制定和维护

软件开发：

负责项目的软件开发、配合产品的验收等相关活动

质量保证：

负责项目过程和产品规的制定、过程评审和产品审计

配置管理：

负责项目的配置管理活动、负责软件产品的提交

角色映射表

项目管理组

软件开发组

质量保证组

配置管理组

负责人

王红

磊

王伟

王明

组成人

1

1

1

1

6、项目生存期

根据该项目的特点并结合公司已有的软件生存期模型定义，本项目生存期采用增量模型如图：

生存期中的各阶段定义如下：

项目规划阶段

阶段目标：

根据合同和初步的需求分析确定项目的规模、时间和资源需求。

输入：

合同文本、SOW

过程：

项目规划，计划确认

输出：

项目计划

需求分析阶段

阶段目标：

确定客户需求

输入：

项目计划，SOW

过程：

需求获取，需求分析

输出：

原型系统，需求规格

设计阶段

阶段目标：

总体系统结构设计

输入：

原型系统，需求规格

过程：

总体设计

输出：

系统设计说明书，数据库结构定义

增量1实现

阶段目标：

实现系统的旧书回收功能

输入：

系统设计说明书、数据库定义结构

过程：

详细设计，编码，代码走查，代码评审，单元测试

输出：

详细设计说明书，源代码，可运行版本-1

增量2实现

阶段目标：

实现旧书再利用功能

输入：

系统设计说明书、数据库结构定义

过程：

详细设计，编码，代码走查，代码评审，单元测试

输出：

详细设计说明书，源代码，可运行版本-2

7、时间计划

项目进度计划甘特图如图所示见图2

8、项目成本估算

现金流图见图3

9、质量管理计划

文档目的

能够保证完成《在线考试系统》质量

文档围

【描述本质量管理计划涵盖的计划围。

本文档将定义可交付物的质量标准和检验标准】。

参考

《软件向管理案例教程》第二版万江立新编著

项目背景

通过在线考试，以减轻教师的工作负担及提高工作效率，与此同时也提高了考试的质量，从而使考试更趋于公证、客观，更加激发学生的学习兴趣。

项目结构

【描述项目质量管理团队成员组成，绘制组织结构图】。

【实施小项目时，项目经理负责保证质量。

通常，可以指定一位质量监督员协助项目经理】。

【实施大的项目时，可成立质量保证小组，指定人员担任专职的质量经理。

质量保证小组成员包括客户和第三方人员】。

质量管理

【可参照下表，描述在项目各生命周期阶段所需递交的交付物】。

序号

交付物

交付时间

负责人

1

软件规划

2016.7.20

磊

2

需求开发

2016.7.20

王明

3

设计

2016.7.20

王红

4

通用功能

2016.7.21

磊，王明

5

在线考试管理

2016.8.1

才

6

成绩查询

2016.8.3

才

7

试卷信息管理

2016.8.11

王红，磊

【描述项目质量控制过程中采用的评审方式。

如：

定期质量评审是对项目前一阶段的工作质量进行总结和评审，形成如下评审报告】：

项目评审

项目质量评审报告

项目名称

在线考试系统

质量经理

磊

时间2016

项目阶段描述

检查容

检查结果

项目按规流程执行情况

合格

项目文档情况

充分

系统设计与需求的符合性

符合

技术实现方法的合理性、可行性、用户认同性

统一

项目进度情况

顺利

人员安排情况

合理

资源保证情况

优秀

对外协作情况

优秀

问题列表

序号

问题描述

带来的风险及影响

严重程度

解决办法、期限

2

不准确

是项目不符合现实

30%

1

5

不合格有漏洞

有篡改入侵

60%

3

11

不合格有漏洞

有篡改入侵

60%

2

16

不合格有漏洞

有篡改入侵

60%

1

24

不合格有漏洞

有篡改入侵

60%

3

30

不合格有漏洞

有篡改入侵

60%

2

36

不合格有漏洞

有篡改入侵

60%

2

45

不合格有漏洞

有篡改入侵

60%

3

4

其它意见和建议

无

各质量检查点

【列举项目的质量检查点和初步时间计划，如】：

检查点

日期

项目计划阶段

2016.7.20

需求调研阶段

2016.7.20

需求分析阶段

2016.7.20

概要设计阶段

2016.7.20

详细设计阶段

2016.7.21-2016.8.11

编码/单元测试阶段

2016.8.11-2016.8.12

集成测试阶段

2016.8.13-2016.8.15

系统测试阶段

2016.8.16-2016.8.19

工程实施阶段

2016.8.19-2016.8.22

参与人员和要求

【无特殊要求，具体要求视情况而定】。

项目计划阶段检查清单

检查容

检查时间

完成情况

负责人

项目规模

2016.7.19

通过

磊

时间计划

2016.7.19

通过

磊

项目需求

2016.7.20

通过

王明

需求调研阶段检查清单

检查容

检查时间

完成情况

负责人

资源需求

2016.7.20

通过

才

计划设置

2016.7.20

通过

才

需求分析阶段检查清单

检查容

检查时间

完成情况

负责人

项目计划

2016.7.21

通过

磊，王明

sow

2016.7.21

通过

王明

设计阶段检查清单

检查容

检查时间

完成情况

负责人

总体实现

2016.8.11

通过

磊，王明

2016.8.22

通过

磊

开发阶段检查清单

检查容

检查时间

完成情况

负责人

系统设计说明书

2016.7.21

王红

数据库结构定义

2016.7.25

王明

集成测试阶段检查清单

检查容

检查时间

完成情况

负责人

测试计划

2016.8.12

王伟

测试案例

2016.8.12-2016.8.22

王伟，磊

系统测试阶段检查清单

检查容

检查时间

完成情况

负责人

集成测试

2016.8.12

王伟

系统测试

2016.8.20

王伟，磊

工程实施阶段检查清单

检查容

检查时间

完成情况

负责人

系统软件包

2016.8.22

王红

验收

2016.8.23

王磊

质量检查和确认技术

审计产品一览表

项

审计对象

审计阶段

参照标准

1

软件项目计划

计划结束

企业质量体系

2

软件配置管理计划

计划结束

企业质量体系

3

软件质量保证计划

计划结束

企业质量体系

4

总体设计文档

设计结束

企业质量体系和项计划

5

详细设计文档

设计结束

企业质量体系和项计划

6

数据库表和编码规

设计结束

企业质量体系和项计划

7

产品代码

每个阶段实施结束

企业质量体系和项计划

8

测试报告

测试结束

企业质量体系和项计划

9

测试计划

设计结束

企业质量体系和项计划

10

用户文档

测试结束

企业质量体系和项计划

10、配置管理计划

软件项目配置管理计划案例

项目案例为《在线考试系统》，该项目的配置管理计划如下：

10.1引言

主要功能：

实现通过机房在线考试。

其他功能：

实现对考试试卷的管理，教师的管理，学生成绩的管理，考试课程的管理，查看考试试卷等功能。

10.2组织及职责

配置管理的角色和职责见表1。

表1：

配置管理角色职责表

角色

人员

职责和工作围

配置管理者

磊

（1）制定《配置管理计划》

（2）创建和维护配置库

SCCB负责人

王明

（1）审批《配置管理计划》

（2）审批重大的变更

SCCB成员

磊（项目经理），王伟（质量保证人员），王明（配置管理者）

审批某些配置项或基线的变更

10.3配置管理环境

由于本项目属于中小型项目，工期也不很长，而且项目组人员对VisualSourceSafe也比较熟悉，所以采用VisualSourceSafe作为配置管理工具。

10.3.1配置库目录结构

表2：

配置库的目录结构

序号

容

说明

路径

1

TCM

技术合同管理

$\prj-School\TCM

2

RM

需求管理

$\prj-School\RM

3

SPP

软件项目规划

$\prj-School\SPP

4

SPTO

软件项目跟踪与管理

$\prj-School\SPTO

5

SCM

软件配置管理

$\prj-School\SCM

6

SQA

软件质量保证

$\prj-School\SQA

7

SPE

软件产品工程

设计

$\prj-School\SPE\DESIGN

8

源代码

$\prj-School\SPE\SOURCE

9

目标代码

$\prj-School\SPE\BUILD

10

测试

$\prj-School\SPE\TEST

11

发布

$\prj-School\SPE\RELEASE

10.3.2用户及权限

表3：

配置库的用户权限

类别

人员

权限说明

配置管理者

王明

负责项目配置管理，拥有所有资源权限

项目经理

磊

访问、读

质量保证人员

王伟

访问、读

开发人员

磊，王明，王伟等

访问、读

高层管理

磊

访问、读

10.4配置管理活动

10.4.1配置项标志

10.4.2主要配置项

表4：

配置项列表

类型

主要配置项

标识符

预计正式发表时间

技术合同

《合同》

QTD-School-TCM-Contract-V1.0

2016-8-11

SOW

QTD-School-TCM-SOW-V1.0

2016-8-11

计划

《项目计划》

QTD-School-SPP-PP-V1.0

2016-8-11

《质量保证计划》

QTD-School-SPP-SQA-V1.0

2016-7-24

《配置管理计划》

QTD-School-SPP-SCM-V1.0

2016-7-24

需求

《需求规格说明书》

QTD-School-RM-SRS-V1.0

2016-8-1

用户DEMO

QTD-School-RM-Demo-V1.0

2016-8-1

设计

《总体设计说明书》

QTD-School-Design-HL-V1.0

2016-8-2

《数据库设计》

QTD-School-Design-DB-V1.0

2016-8-2

《详细设计说明书》

QTD-School-Design-LL-V1.0

2016-8-5

《设计术语及规》

QTD-School-Design-STD-V1.0

2016-8-2

编程

源程序

QTD-School-Code-ModuleName-V1.0

2016-8-2

编码规则

QTD-School-Code-STD-V1.0

2016-8-2

测试

《测试计划》

QTD-School-Test-Plan-V1.0

2016-8-3

《测试用例》

QTD-School-Test-Case-V1.0

2016-8-3

《测试报告》

QTD-School-Test-Report-V1.0

2016-8-4

提交

运行产品

QTD-School-Product-Exe-V1.0

2016-8-14

《验收报告》

QTD-School-Product-Report-V1.0

2016-8-16

《用户手册》

QTD-School-Product-Manual-V1.0

2016-8-16

10.4.3项目基线

在VisualSourceSafe中基线由LABLE标志，字母必须为大写。

基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。

表5

基线名称/标识符

基线包含的主要配置项

预计建立时间

需求

《需求规格说明书》、用户DEMO

2016-7-20

总体设计

《总体设计说明书》、《数据库设计》

2016-7-20

项目实现

软件源代码、编码规则

2016-8-11

系统测试

《测试用例》、《测试报告》

2016-8-15

10.4.4配置项的版本管理

配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：

主干分支、私有分支、小组分支、集成分支。

让它们分别对应4类工作空间。

这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。

在变更发生时，应及时做好基线的推进。

对配置项的版本管理在不同分支具有不同的策略：

（1）主干分支

系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。

（2）私有分支

如果多个开发工程师维护一个配置项时建议建立自己的私有分支。

配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。

（3）小组分支

如果出现小组共同开发一配置项，该分支可视为项目组部分组的私有空间，存放代码开发过程中的版本分支，由项目组部控制。

（4）集成分支

集成测试时在主干分支的特定版本（由LABLE标志清晰）上建立集成分支，测试工作在集成分支上完成。

私有分支和小组分支均为可选，必要时建立。

10.4.5命名规

本项目配置项命名规由5个字段组成，从左到右依次为：

公司、项目、类型、编号和版本号，如图1所示。

这些字段用一横线（-）分隔。

图1：

配置项命名规

10.4.6变更管理

变更管理的流程是：

（1）由请求者提交变更请求，SCCB会召开复审会议对变更请求进行复审，以确定该请否为有效请求。

典型的变更请求管理有需求变更管理、缺陷追踪等。

（2）配置管理者收到基线修改请求后，在配置库中生成与此配置项相关的波及关系表。

（3）配置管理者将基线波及关系表提交给SCCB，由SCCB确定是否需要修改，如果需要修改，SCCB应根据波及关系表，确定需要修改的具体文件，并在波及分析表中标志出来。

（4）配置管理者按照出库程序从配置库中取出需要修改的文件。

（5）项目人员将修改后的文件提交给配置管理者。

（6）配置管理者将修改后的配置项按入库程序放入配置库。

（7）配置管理者按SCCB标识出的修改文件，由波及关系表生成基线变更记录表，并按入库程序放入配置库。

10.4.7配置状态统计

利用配置状态统计，可以记录和跟踪配置项的改变。

状态统计可用于评估项目风险，在开发过程中跟踪更改，并且提供统计数据以确保所有必需的更改已被执行。

为跟踪工作产品基线，配置管理者需手机下列信息：

●基线类型●工作产品名称

●配置项名称/标识符●版本号

●更改日期/时间●更改请求列表

●需要更改的配置项●当前状态

●当前状态发生日期

项目组每周提交配置项清单及其当前版本。

配置管理人员每半个月提交变更请求的状态统计。

11、项目风险计划

下图是本项目的风险计划清单表

1、规模度量

排序

输入

风险事件

可能性

影响

风险值

风险应对措施

1

客户的SOW

需求不明确，增加需求，导致需求延迟

%70

%50

%35

1、采取加班的方法

2、修改计划去掉一些任务

3、与客户商量时间长一些

2

合同

进度要求紧，合同金额有限

%30

%50

%15

可以请一些实习的学生做一些辅助工作，可以加快进度

3

历史项目信息

开发人员对测试工作不重视

%30

%40

%12

1、强制性要求每段代码保留测试单元，由SQA检查

2、加入专业的测试人员

4

WBS

供货商、外包商的质量问题

%20

%50

%10

多选择几个可以作为备份的外包商和供应商

5

历史项目信息

开发人员的流动

%15

%60

%9

1、注意项目团队的沟通，及时了解开发人员的动态

2、控制好项目过程中的文档

3、从其他项目组借调人员

4、从外部招聘有过此类开发经验的人员

表1：

项目规模的度量指标

12.度量计划

根据企业的质量策略和项目的特点制定本项目度量计划，主要目的是为本项目的控制提供实际数据，以及将来其它项目提供估算依据，表1给出项目规模的度量指标，表2是项目的时间度量指标，表3是需求变更度量指标。

任务名称

规模度量单位

计划

实际

需求规格说明书

文本页数

 26

 28

总体设计说明书

HLD页数

 13

 15

系统测试计划

文本页数

 20

 21

详细设计说明书

DLD页数

 38

 40

单元测试计划

文本页数

 15

16 

源程序

LOC行数

 1800

 1900

单元测试报告

文本页数

 15

 16

系统测试报告

文本页数

 16

 18

总计

文本页数

 92

 99

HLD页数

 13

 15

DLD行数

 38

 40

LOC行数

 1800

 1900

二、时间度量

表2：

时间度量指标

各阶段名称

计划时间（小时）

实际时间（小时）

管理

 64

 70

需求分析

 10

 12

需求检查

 20

 25

总体设计

 30

 32

测试计划

 48

 50

总体设计检查

 5

 6

详细设计

 25

 30

详细设计复核

 3

 5

详细设计检查

 5

 6

单元测试计划

 2

 3

编写源程序

 432

 450

代码复核

 2

 3

代码检查

 3

 4

单元测试

 2

 3

集成测试

 3

 4

系统测试

 4

 6

验收

 1

 2

合计

 659

 711

三、需求变更度量统计表

表3：

需求变更度量指标

变更请求

请求时间

变更请求者

变更容

批准否（Y?

N）

批准时间

需求规格版本

13、质量沟通与评审

项目交流计划分为如下几类：

1、每日的沟通交流

2、定期的评审

3、阶段的评审

4、事件问题的交流

评审类别

评审周期

评审要点

相关人员

日例会

每天5:

00

1、随意交流

2、共享经验

3、工作进度交流

4、资源协调

5、第二天工作安排

项目所有相关人员

阶段评审

每周五5:

00

1、本周计划执行情况

2、本周依旧未解决问题汇总

3、下周计划

项目所有相关人员

事件评审

出现48小时未能解决的问题时

1、事件的性质

2、讨论解决

项目所有相关人员