科研项目申请评估协同系统模型研究_CSCW

科研项目申请评估协同系统模型研究*
葛锋，鲁东明
（浙江大学网络中心杭州310027 gefeng001@）
（浙江大学人工智能研究所杭州310027 ldm@）
[摘要]
在深入了解科研项目申报与管理流程的基础上，我们研究并制定了合理的科研项目申请评估计算机辅助协同工作模型。

它主要是通过Internet网络，实现网上对科研项目的管理和申请。

同时，项目管理者还可邀请有关专家通过网络对项目申请者进行评估。

通过该模型，开发了浙江大学科研管理系统，该系统已在浙江大学投入试用。

更改模型中的角色，还可成为其他的三角色协同工作模型，如老师、家长、学生共同操作的作业管理系统等。

[关键字]
CSCW，协同系统，文档管理，多用户接口
1. 前言
计算机支持的协同工作作为一门新兴的跨学科，具有广阔前景的研究和应用领域，在国际上受到极大的重视。

从学术上看，计算机网络、协同工作、多媒体技术是目前计算机领域研究与应用的热点，本系统结合科研项目申报与管理这一实际领域，提出新的协同工作模型、多媒体文档管理技术、网络通信与同步控制技术，并进行集成应用。

从实际应用的角度看，教科网的建设已初具规模，为基于网络的远程科研项目申报与管理提供了基础，本系统的实施与成果，将充分利用教科网基础，支持科研项目从申报、评审、管理、评估与结题等整个过程，提高科研项目管理的效率，具有十分重要的实用意义。

与本项目密切相关的协同工作技术是当前国际上研究与应用的重点。

CSCW自1984年提出以来，不断得到发展并成为计算机应用的主流技术之一，已渗透到办公、教学、设计、研究、军事、创作等众多不同领域。

以Internet为代表的远程网络发展，又将CSCW带入到更为广阔的研究与应用领域，表现出其在计算机应用领域更大的潜力。

多媒体文档协同编著是其中一项典型应用，国外在这方面有了许多研究，开发了一些有用的原型系统；从国内情况看，清华、中科院、浙江大学已从事展开这方面的研究工作，并在设计、文档著作等领域得到应用。

如浙江大学研制开发的基于Internet的多媒体协同编著系统，基于Internet和分级权限管理，同时支持同步和异步两种协同编著模式，提供以RSA和DES相结合的数据传输加密功能，系统达到C1及安全级别。

目前，科研项目的管理文档已进入计算机，但整个科研项目从申请、评审、实施、评估到总结的各阶段仍以纸质手工的形式进行，管理人员、申请者与评审专家具有很大的工作量，没有充分运用Internet/Intranet带来的网络通信与协同的便利。

本模型将充分运用计算机网络和CSCW以及多媒体文档技术，使项目管理人员与申请者、评审专家之间可以方便地协调工作，减少工作量、缩短流程周期，大大提高整体工作效率。

*本项目得到国防科技预研跨行业基金项目98J15.4.4JW0408及浙江省自然科学基金No699038资助
作者简介：葛锋，男，1976年出生，计算机应用硕士
鲁东明，男，1968年出生，浙江大学校网办副主任，副教授
定稿日期：2000年10月18日
2、科研项目申请评估协同模型
科研项目申请评估协同模型是科研项目申请评估协同系统的核心与基础。

研究科研项目申请评估协同模型的主要目标是描述时间上分离、空间上分散而在项目的申报与评定上又相互依赖的项目管理员与多个申请者和多个评审专家之间的交互方式、协作机制以及项目申请与评估的控制、管理和协调等。

我们将首先讨论协同模型的特征，然后分析、定义系统的基本元素，这些基本元素都是科研项目申请评估协同系统抽象出来的基本功能单元，最后以这些基本元素为基础详细论述系统的整体结构模型。

2.1协同模型的特征
协同模型的实质表现在模拟自然合作的工作环境、对共享工作对象进行的符合习惯和逻辑的多用户操纵、群体行为的组织这三个方面。

具体来讲，协同模型特征主要体现在以下几个方面：
●交互。

交互根据所要求的响应时间可分为同步与异步。

同步交互常体现在如会议系统中，
而通过网络电子新闻、电子邮件进行的交互可称为异步交互。

●协调。

协调是对多个个人的工作进行调整、平滑、衔接和集成，以使其完成一个更大的
目标。

在基于计算机的协同工作系统中，就是要对一组通过计算机执行的一项群体活动的应用代理之间的相互依赖和交互进行管理。

●分布。

协同系统中，存在工作对象、接口和用户的分布性。

这里的分布性不同于传统的
分布式系统中的分布，它是一种显式的分布，强调分布的可感知。

而传统分布式系统则强调隐式的分布。

●角色支持。

如同自然合作当中一样，协同系统中的用户因其分工不同而具有不同的角色。

●感知。

协同系统中感知的含义主要包含以下两个方面中：a)模拟的协同工作环境为用户
提供面对面的真实现场感；b)在对公共工作对象的操纵过程中，一个用户的标识和动作过程或结果能被其他用户看到。

●可视化。

可视化特征即公共工作对象在协同用户间的展示问题。

协同系统的多用户接口
通过对用户操纵的传播来支持共享的程度被称为接口耦合。

2.2 科研项目申请评估协同系统基本元素
我们从科研项目申请评估协同系统中抽象出它的一些基本元素，这些基本元素都代表科研项目申请评估协同系统中的一些基本功能单元。

以下将针对这些基本元素进行详细说明。

●系统用户对象
系统用户对象用来描述系统用户的权限、属性，可由以下文法表示：
〈系统用户对象〉：：=〈用户类别〉〈用户属性〉
〈用户类别〉：：=〈项目管理员〉|〈申请者〉|〈评审专家〉
〈用户属性〉：：=〈帐号，口令，姓名，性别，出生年月，院系，研究方向，简介〉
●申请书对象
描述项目申请书的格式，可由以下文法表示：
〈申请书对象〉：：=〈封面〉〈申请表格〉{〈申请书页面〉}
〈封面〉：：=〈项目名称,申请人,学科范围,申请时间,申报学校〉
〈申请表格〉：：=〈项目名称，项目类型，成果形式，意义…….〉
〈申请书页面〉：：=〈页名，页内容〉
●评论书对象
描述对申请书的评论所产生的评论书格式，可由以下文法表示：
<评论书对象〉::=<封面><评论表格>{<评论书页面>}<评分表格>
<封面〉：：=〈项目名称,申请人,学科范围,申请时间,申报学校〉
<评论表格〉：：=<申请表格>〈评论内容〉
<评论书页面>::=<申请书页面><评论页内容>
<评论页内容>::={<评论单元>}
<评论单元>::=<评论单元位置><评论单元内容>
<评论单元位置>::=<开始位置,结束位置>
<评分表格>::=<先进性评分,创造性评分,迫切性评分,学术价值评分,经济、社会效益评分,研究者研究能力评分,研究目标是否明确评分,研究方法和路线是否合理可行评分,必要的物质条件评分,推广应用前景评分>
●消息对象
描述项目管理员向申请者或专家所发消息的格式，可由以下文法表示：
<消息对象>::=<消息类别><消息编号, 消息接收者帐号, 消息名称, 消息相连的内容, 是否新消息, 相关项目代号, 相关申请书编号>
<消息类别>::=<公布项目>|<修改申请>|<邀请评论>|<同意申请>|<否决申请>
2.3科研项目申请评估协同系统中的角色机制
在协同学理论中，有一个重要的原理就是：没有一个工作组中的每一个成员都具有相同的权利与职责。

对于本系统也是这样的。

项目申请评估系统中的每个角色都应具有不同的职责与权利，也既是说担任一定的社会角色。

在本系统中，我们定义了三种角色模型：项目管理员、申请者和评审专家。

项目管理员是科研项目的管理者，其权限包括：向申请者公布项目；邀请有关专家对项目申请书进行评论；根据专家对申请书的评论，对申请者的申请进行总评价，从而要求申请者修改申请或认可、否决申请者的申请。

申请者是科研项目的“应聘”者，在项目管理员公布项目后，申请者即可填写填写申请书进行申请。

评审专家是申请者的申请书的评定者，在项目管理员邀请评论后，专家即可对被要求评论的申请书进行评定。

2.4、科研项目申请评估协同系统中的消息机制
如何表示项目管理员向申请者公布项目、向专家邀请评论？一种办法是为申请者复制一份申请表格，为专家复制一份需要评论的申请书，但申请者不想申请、专家不想评论呢？这种办法不仅浪费大量宝贵的服务器存储空间，而且效率不高。

为此，本系统采用消息机制，当项目管理员要向申请者公布项目时，只需向他发送公布项目消息；而当项目管理员邀请专家进行评论时，同样只需向该专家发送邀请评论消息。

只有在申请者、专家接受消息时，才会复制相应的申请表格或申请书，同时删除该消息。

使用消息机制可大大减少网络流量，合理利用服务器资源。

消息对象的结构如下：
Struct MyMessage
{
long MessageNo;//消息编号
CString ReceiverAccounts;//消息接收者帐号
BYTE MessageId;//消息类型
CString MessageName;//消息名称
CString MessageText;//消息内容
CString ItemId;//消息相关的项目
long RequisitionNo;//消息相关的申请书编号
}
其中，消息类型指以下五种消息：公布项目；邀请评论；修改申请；同意申请；否决申请。

2.5 科研项目申请评估协同系统的过程模型
项目的申请和评定过程，大概可以分为以下三个阶段：一是项目公布阶段；一是申请者填写、修改申请书阶段；一是申请书的评定阶段。

具体地说，先是项目管理员公布项目的基本信息、具体要求；然后申请者就可以从项目管理处领取申请书表格进行填写、提交，项目管理员阅览申请书并根据专家的意见要求申请者对申请书进行修改；最后项目管理员对申请者的申请作出决定。

参照以上过程，可总结出本系统的过程模型如图1所示：
图1 项目申请评估协同系统过程模型
2.6 科研项目申请评估协同系统的整体模型
前面描述了本系统的基本元素以及角色机制、过程模型，在讲述系统的逻辑模型之前，我们先定义系统的五个基本元素空间ES(Element Space)，这四个ES及它们之间的相互关系可描述申请评估协同系统所提供的一个整体上的项目申请评估环境。

①申请书模板、评论书模版对象空间：每一个项目对应唯一的申请书模板和评论书模板。

当申请者要申请项目时，系统从该空间把申请书模板复制到申请书空间；当评审专家要评审申请书时，系统从该空间把评论书模板复制到评论书空间。

②申请书对象空间：申请者的工作空间，申请书的填写、修改都在此完成。

③评论书对象空间：评审专家的工作空间，在此完成申请书的评论工作。

④项目管理员空间：项目管理员的工作空间，在此完成项目公布、申请书评定工作。

⑤消息对象空间：项目管理员，申请者，评审专家之间的联系空间。

这五个系统元素空间有它们相互依托的关系，图2就是它们之间的一个多层次关系图。

形式地，我们可以对该系统模型定义如下：
设A = {A1 }为项目管理员的集合；B = {B1，B2，…B m}为申请者的集合；S = {S1，S2，S n}为评审专家的集合；M = {M1,M2,…M p}为消息对象的集合。

可用图3来表示本系统的整体模型。

整个工作由项目管理员公布项目开始，在申请折和评审专家的参与下结束，其目标是完成项目的申请工作。

图2 科研项目申请评估协同系统元素空间层次关系图
图3 系统逻辑模型的三层结构
3、系统关键技术的设计
协同应用系统协助多个协同工作者共同完成某一项工作，其协作过程的模式直接影响到系统的可用性。

因此，如何提供一种比较自然的，接近用户实际需求的协同工作模式是协同系统所应解决的关键问题，这在上节已经得到解决。

在设计过程中，如何实现文档的组织管理、文档的协同控制、多用户接口等关键技术，这是所有协同系统的关键，关系到系统的功能和效率。

就本系统而言，我们要解决好以下问题：
3.1科研项目的文档组织管理
如何设计一个有效、简洁的文档组织，使用户能一目了然，也是一个较为重要的问题，图4显示了本系统的文档组织管理。

●申请者简历目录
该目录包含了在本系统上由系统操作员创建的所有申请者的详细介绍。

●专家简历目录
本系统上由系统操作员创建的所有评审专家的详细介绍。

图4 科研项目申请评估协同系统的文党组织结构
●EZSR目录
该目录是项目目录，指明其下的所有申请书都是属于这个项目的，即这些都是申请这一项目的申请书。

●申请书1目录
指明申请书的格式，如浙江省教育委员会科研项目，其格式为：封面，申请表格，本项目的研究意义及国内外同类研究工作现状，主要研究内容、目标、方案和进度及拟解决的关键问题，与本项目有关的工作条件(包括研究工作基础、实验条件等)，预期成果形式、去向和效益，经费预算（单位：万元），院（系）推荐意见，校推荐意见。

●评论书2目录
指明它是其父目录申请书1的评论书，其下的内容是评论书的格式。

3.2、文档的协同控制
对于项目的申请与评估协同系统，应该遵循严格的异步方式。

在申请者没有提交申请书前，项目管理员不应该能看到其申请书，同样，评审专家在没有提交评论书前，项目管理员和申请者也不可能看到他的评论书。

另外，要严格控制各个角色的权限，例如：申请者不能修改申请书的即定格式；专家不能修改评论书的格式和申请者的申请书内容，只能对原申请书的内容进行评论；项目管理员不能修改申请书、评论书的内容；提交后的申请书、评论书不可再作修改，只有在项目管理员发出修改申请要求后才能再次修改；申请者只能看到与自己相关的内容。

定义以下结构：
●申请书结构
Struct Requisitions
{
long RequisitionNo; //申请书编号
CString ItemId; //申请书所属项目
CString ApplicantAccounts;//申请者帐号
CByteArray RequisitionContents;//申请表格内容
bool IsSubmission;//申请书是否已提交
bool IsNew;//若申请书已提交，则项目管理员是否已浏览过
}
通过申请者帐号只显示相关申请者的申请书；当IsSubmission=true时，项目管理员可看到该申请书，申请者不可再修改申请书。

●申请书的页结构
Struct RequisitionsPage
{
long RequisitionNo; //对应的申请书编号
long PageHandle; //该页的编号
CString PageTitle; //该页的标题
CByteArray PageContent;//该页的内容
long PageBkColor; //该页的背景颜色
}
通过申请书编号可查找到它对应的申请页。

●评论书的结构
Struct Comments
{
long CommentNo; //评论书编号
long ReQuisitionNo;//对应的申请书编号
CString SpecialistAccounts;//该评论书的评审专家的帐号
CByteArray CommentContents;//申请表格的评论内容
bool IsSubmission;//评论书是否已提交
bool IsNew; //若评论书已提交，项目管理员是否浏览过
}
通过申请书编号可获得对应的评论书文档。

若已提交，则项目管理员、相应的申请者可在相应的申请书下看到该文档。

●评论书的页结构
Struct PageComments
{
long CommentNo;//对应的评论书编号
long PageHandle;//评论页的编号
CString PageTitle;//评论页标题
CByteArray PageContent;//评论页内容
long PageBkColor；//评论页的背景色
}
评论页内容的存储格式为：〈对应申请页内容〉+{〈评论单元开始位置，评论单元结束
位置，评论单元内容〉}。

4、具体系统实现
在制定了上述模型的基础上，我们根据浙江省科委、浙江大学的具体需要，利用该模型
开发了浙江大学科研管理系统，该系统采用Visual C++ 6.0作为开发平台，整体上采用三
层结构的客户机/服务器结构。

共分为四个模块：系统管理员端模块、项目管理员端模块、
申请者端模块和专家端模块。

该系统已在浙江大学试运行。

[参考文献]
[1] James D.Palmer and N.Ann Fields,Computer-Supported Cooperative Work,Computer,May
1994,Pp15-17.
[2] David Crow, Sara Parsowith and G.Bowden Wise, the Evolution of CSCW-Past,Present and Future Developments, SIGCHI Bulletin Vol.29 No.2,April 1997.
[3] Makris,L,etc.,Teleworks:A CSCW application for remote medical diagnosis support and teleconsultation,IEEE Transactions on Information Technology in Biomedicine Vol.2 No.2 Jun 1998
Pp62-73.
[4] /;
[5] /current/feature.htm;
[6] 王国意、徐光佑，“CSCW支撑平台的结构模型”，《计算机科学报》1997、8。

[7] 鲍红伟、鲁东明，“协同编著系统ZU_CoEditor的研究与开发”，第一次全国CSCW学术会议，北京1998
月12月，Pp141-144。

[8] 张信成、史美林，“Web协同出版体系”，第一次全国CSCW学术会议，北京1998月12月。

[9] 鲁东明、鲍红伟，“多媒体文档协同编著系统关键技术研究”通讯学报 1999.9 Vol.20 No.9
[10] 李向阳、鲁东明、潘云鹤，“计算机支持多用户协同编著模型”通信学报。