招投标管理系统的设计与实现设计分析报告

1、招投标治理系统的设计与实现 设计报告蒋和平S1410w0659 软件2班第1章 背景以及国内外研究现状1.1系统开发背景招投标是指在市场经济条件下进行大宗物资的买卖、工程建设项目的发包与承包，以及服务项目的采购与提供时，所采纳的一种交易方式。由于招标投标具有公平、公正的特征以及“竞争、优化”的功能，在现今社会中得到了广泛的应用。为了规范招标投标的行为，促进公平竞争，中华人民共和国招标投标法自2000年1月1日起正式实施。规定基础设施、公用事业、使用国有资金投资和国家融资的项目以及与之有关的重要设备、材料等采购行为，达到一定规模标准的，必须进行招标、公示。随着招投标业务在各个行业的推广，招投标业

2、务复杂度日渐提高，标准的招投标业务包括了招标打算治理、招标过程治理、合同执行治理、招标效果分析、招标统计分析决策支持、成本治理等业务。随着招标业务处理流程和涉及文件治理复杂程度的提高，传统的手工招投标治理存在招标过程公正性缺失、过程细节混乱、文档和合同文件易丢失、招标效果和统计分析能力缺失等问题。通过对当前不同行业中招投标治理业务流程的分析和研究发觉，不同行业关于招投标治理存在的问题和异同性要求要紧包括:1、业务处理流程复杂现有的招投标治理包括了招标打算、招标公告、竞标、材料提交、标的审核、合同签订、合同执行流程和招标企业评价等相关流程。同时，针对不同级不的招标过程其流程也存在一定的差异，同时

3、竞标的过程也由于事务的复杂度而不同。招投标流程的复杂和竞标业务的差异性使得招投标业务治理过程复杂，手工的治理模式往往会存在治理混乱、投标公正性无法保证和文档治理困难等问题。2、招标模式种类繁多关于招投标治理，依据招投标物品和项目的类不不同，招标环节中的竞标过程包括了不同的模式。通过对市场上招投标业务的分析和抽象，我们提取出了竞价招投标治理、谈判招投标治理和直接招投标治理等三种模式。关于有用性较强的招投标治理系统，需要对以上不同的招标种类和模式进行抽象分析，使得招投标系统支持多种不同的招投标模式。3、招标过程公正性问题在企事业单位的招投标治理过程中，现有的手工治理模式往往会由于人为的因素导致标的

4、过早暴露、评标人联合受贿等公正性缺失等问题。因此，在招投标的治理过程中如何保证招标过程的公正性是当前招投标治理系统的首要任务。4、合同执行治理复杂目前，现有的招投标治理模式其招标过程和合同执行过程是分开的，这种情况往往会造成项目治理混乱的问题。因此，如何实现招标和合同执行的同步治理是目前招标治理和项目实施过程中的难点和重点。5、参标企业信用评级困难手工的招投标治理难以对参标企业的信用等级进行分析，往往会由于信用问题导致项目实施的失败。因此，如何结合招投标治理系统对参与竞标的企业进行信用等级分析和治理也是招投标治理系统的关键。6、招标材料归档工作繁重在招投标业务治理过程中，包括了招标企业资质文件

5、、标书文件、标书审核和评审文件等。因此，在整个业务处理流程中，包括了各类申请和审核报表、企业情况表等。目前的手工处理治理差不多上通过人工整理、收集和归档，往往会导致资料丢失和难以进行查找等问题。7、招标统计、分析能力欠缺目前，关于企事业单位来讲每年的招投标业务数量逐渐增多，从而使得招投标业务数据量增多。每年如何对招投标数据和文档进行归类和数据分析成为每年相关部门年底工作的重点。现有的手工处理模式，要紧针对数据进行表格处理，往往会导致数据结果不够准确，同时不能提供良好的汇总和分析功能。随着高新计算机技术的进展，企业间的竞争日趋激烈，要保持企业的竞争力就必须有高效的企业治理，因此企业治理的信息化就

6、变的不可或缺。招投标信息治理系统是企业信息化的一部分，它的内容关于提高企业采购治理水平和企业决策分析能力都至关重要。首先，招投标治理的信息化解决了企业招标过程中的不公平性问题，通过招标流程的信息化减少了整体流程中的人为因素阻碍，使得企业设备采购、基建招标和原材料产品招标等过程更加透明、公开和公正;其次，通过招投标治理系统提供了快捷、方便的信息查询功能，解决了传统治理方式中效率低、保密性差和文件易丢失、难以留档等关键问题;同时，招投标系统为企业领导层和统计部门提供了良好的信息汇总统计和决策分析等功能。这些优点能够极大地提高招标信息治理的效率，也是企业的科学化、正规化治理，与世界接轨的重要条件。因

7、此，开发如此一套治理软件成为专门有必要的情况。1.2国内外研究状况自从2000年国家颁发招标投标法和国家推行企事业单位信息化以来，针关于招投标的业务治理系统在各个行业逐渐进展起来，其中包括了地区级政府的招投标治理、水利、建筑等各个行业的招投标治理、高等院校的招投标治理系统等。早期的招投标治理采纳了传统的C/S架构，不利于企业申报和招标信息的公开。近年来，随着基于JZEE和.NET软件技术的进展，基于B/S架构的招投标治理系统成为当前各企事业单位招投标治理的首选。随着国内政府企业信息化建设的推进，政府推出了电子政务建设的方案，将政府要紧的处理业务包括各类审核、审批业务通过基于web的方式提供给企

8、业和个人用户。目前，在各企事业单位形成了各自的信息化系统，能够专门好的处理各自单位的信息化问题，包括业务流程处理、信息公告以及各类电子资源的存储。在各个单位信息化的同时，由于缺少职能部门间相关业务交流和处理，导致了“信息孤岛”和业务协调能力欠缺。关于各个地区政府来讲，政府的招投标治理系统一般作为电子政务系统中的核心模块，它与政府的电子政务系统共享统一的门户信息、治理人员信息以及专家领域信息。水利、建筑行业的招投标治理存在着行业建设背景等方面的要求，因此关于企业资质、在建工程、工程技术信息人员等方面具有专门的要求。因此，传统的招投标治理系统中的企业信息要求往往达不到其具体要求。另外，针对高等院校

9、的招投标治理，要紧是设备、施工和成品等方面的招标要求，与上述政府和水利建设等行业的招投标治理也存在较大的差异。同时，上述不同行业针对招投标过程来讲，其跟踪、汇总和决策支持等方面要求也存在着较大的差异。因此，如何规范和抽象投标治理流程和相应过程、文档信息和汇总信息成为当前招投标治理的关键研究问题。本文将在分析以上招投标治理的系统的基础之上，对招标流程、资源等治理进行抽线提出统一的模型，从而建立一套适合于各个领域的招投标治理系统。1.3系统需要解决的要紧问题招投标治理信息系统面向的行业、用户和企事业单位等涉众种类繁多，因此通过信息化系统对招投标业务流程进行分析、设计和实现，将会存在着业务流程繁杂、

10、招投标种类众多、业务流程操纵困难等问题。目前，市场上已有的招投标治理系统往往只会针对某个行业或部门，没有成熟的招投标模式的抽象，因此缺少成熟的系统进行分析和参考。因此，在针对招投标业务进行需求分析、设计和实现的过程中，本文需要解决好以下要紧的几个问题:1、招投标业务流程的梳理在招投标业务的整体处理流程中，包括了招标项目的审核审批、招标公告公布、资格预审流程、招标开标流程、评标流程治理、定标流程治理和签约流程治理等业务处理流程。同时在评标和签约过程中又包括一些相关的子流程，因此在系统的需求分析、设计和实现过程中需要对其采纳面向对象的思想进行分析，通过UML的动态模型对业务流程进行建模，建立易于理

11、解的招标流程动态模型。关于动态流程的治理，采纳基于工作流引擎的思想进行实现，通过工作流引擎对整体业务流程进行定义、跟踪和治理。2、招标过程的抽象通过对招投标过程治理进行分析，发觉招投标过程中由于行业背景的不同，其过程将存在专门大的差异。某些招标过程只是一般的办公用品的采买，因此其评标过程较为简单;然而某些招标过程需要进行竞价完成。因此，为了能够更好的支持各类招标过程，本文将针对各个行业的招投标过程进行抽象分类，要紧包括竞价招标、谈判招标和直接招标等。3、招标企业信用问题在招投标治理的过程中，如何分析和确定企业的信用等级和资质是招标治理中的核心问题。因此，在招投标系统的设计和实现过程中，需要支持

12、企业的履约评级和考核从而解决企业的信用分析问题。4、评标过程中的公正性问题关于招投标业务来讲，其治理中的核心问题是如何保证招投标整体过程中的公正性问题，包括投标文件的保密性、专家审核的公正性等。因此，在系统的分析、设计和实现过程中，考虑采纳专家信用评估、资料文件分角色权限维护和随机抽取专家等机制来实现招投标治理的公正性。5、数据、标书等文档的归档治理问题招投标业务治理的过程中包括了企业申请文档、标书和合同打算等相关重要材料。同时，以上材料又同相应的招标项目具有相应的关联性，每次招标项目包括大量需要存档的文档。关于传统的手工治理方式，以上文档的治理和归档通过手工的方式，容易造成文档丢失和泄密等问

13、题。因此，在系统的分析和设计过程中，需要对投标文档和资料进行分类归档处理。6、项目统计分析和决策支持问题关于企事业单位来讲每年的招投标项目将会成百上千，因此如何对每年的招投标数据进行统计分析将是系统中的重点和难点。传统的手工统计方法，容易导致统计结果的错误性，因此在设计过程中通过专门的统计分析功能能够简化统计决策分析工作并提高统计分析结果的正确性。1.4本设计的要紧工作和组织结构1.4.1本设计的要紧工作本文首先针对招投标业务治理进行需求分析，包括各种不同行业或者企事业单位对招投标业务的共性和差异性需求要求。同时，针对传统的招投标业务治理中存在的业务流程处理复杂、数据易丢失、公正性缺失等问题，

14、采纳Java语言在Eclipse软件开发平台上，基于多层的nEE软件体系架构，采纳了基于B/s的软件架构，同时针对复杂的流程采纳工作流引擎进行设计设计和实现了一套通用的招投标综合业务治理系统。通过系统的分析、设计和实现为不同行业中的企事业单位提供了统一的业务解决方案。本系统以网络工作平台的方式，服务于建设单位、企业、政府监管部门三类用户。实现从招标公告公布、资审报名、资格预审、投标、评定标到签约的全程招投标工作治理。本文的要紧工作要紧包括以下几个方面:第一，招投标业务处理流程复杂，本文对以上复杂的招投标流程通过面向对象的思想和UML建模语言进行了建模分析和梳理。通过用例分析对系统功能进行分解处

15、理，关于复杂的业务处理流程建立静态模型和动态模型。在静态模型的基础上，对要紧实体的数据库进行设计;最后，通过传统的基于多层的JZEE模型对系统进行开发和实现。第二，针对招标企业的信用问题，系统在设计过程中增加了招标履约考核治理模块，针关于标书中的不同时期的目的进行采纳了可考核性指标进行评估和分析。通过关于完成标的情况建立企业的信用等级，同时建立招投标企业的信息库达到关于招标履行的可控性。第三，招投标的业务流程较为复杂，其中包括了项目审核、招标公告、格预审流程、招标开标流程、评标流程治理、定标流程治理和签约流程治理等业务处理流程。因此在业务系统的分析和架构设计过程中，系统通过基于工作流引擎的流程

16、处理模块，实现对招投标业务的建模分析、状态跟踪和业务操纵。第四，针对招投标治理中的核心公正性问题，为了达到整体业务的处理公平和公开，系统设计实现过程中通过流程审核分配以及专家信用评估和随机抽取审核专家的方式达到了招投标过程中的公正性。第五，针对招投标业务数据的统计分析和决策问题，为了达到企业招投标业务的统计和易查询性，系统在设计过程中增加了各类不同的招投标业务查询和统计功能。同时，针对不同的功能为其提供了优秀的数据展现方式，从而达到为企业决策者进行服务的目的。1.4.2本设计报告的组织结构第1章分析了招投标业务及其信息治理系统的背景和国内外的进展现状，简要阐述了本文所需要解决的要紧问题，最后指

17、明了本文的要紧工作。第2章对招投标业务治理流程的需求进行了分析，梳理和整理了招投标治理的详细业务流程，通过业务流程图阐述了其详细的业务流程。同时，该章也提出了系统的目标和需要解决的问题。第3章论述了系统的技术架构和功能架构，讲明了差不多的系统逻辑架构设计;针对招投标治理业务处理流程繁多的问题，提出了整体系统的功能结构设计。第4章，在面向对象分析基础上，对系统的建模设计进行了详细的描述;关于招投标治理的业务流程进行了分析和设计，最后给出了系统的数据库设计。第5章介绍了系统业务流程的要紧功能实现和其中的关键技术，包括招标企业申请审核、招标公开、各个招标业务流程的实现和专家库治理模块等。是结束语，对

18、本文所作的工作和下一步要解决的问题进行了总结。第2章需求分析2.1系统概述针对不同企事业单位，其招投标治理工作要紧是针对不同项目、资源和采购等业务的相关申请、招投标和跟踪审核等相关业务的日常工作。其业务包括了一系列的复杂业务审核审批、合同履行评审等相关流程组成，要紧包括了项目的立项申请审批、招标公告公布、资格预审流程、招标开标流程、评标流程治理、定标流程治理和签约流程治理等业务处理流程。同时，在评标和签约过程中又包括一些相关的子流程，包括了大量信息、资源治理和报表输出打印以及企业信用评估和招投标业务公平性保证等相关辅助业务。另外，在某个项目申请、审核和招投标业务处理结束后，需要业务人员对相关材

19、料进行归档处理，而现有的处理方式多采纳纸质文件收集和人工处理的模式。然而，手上和纸质文件处理模式往往会造成工作量大、资源白费、信息收集丢失和不准确等弊端，因此开发一套针对现有不同行业招投标业务的治理信息系统成为迫切的需要。本文将针对不同行业招投标治理业务进行需求分析，然后结合面向对象的思想和基于UML的建模方法，完成系统的需求分析、设计和实现。通过以上的业务场景需求分析，系统将需要解决的要紧问题包括企业信息库和企业信用档案维护、专家信息库维护、招投标公正性确定、中标企业履约考核、项目信息统计和招投标流程维护等。尤其针对招投标流程治理，又包括了招标打算和流程制定、资格审查报名流程、预审流程、投标

20、开标流程、评标流程、定标流程和签约流程等多项复杂流程。因此，为了能够有效对招投标信息进行维护，本文将每次的招投标业务抽象成项目来进行治理。通过项目治理能够有效的定义操纵其整体流程，并能够有效的定义该次招投标业务中的相关企业、数据和招投标文件等，同时能够专门方便的对其进行查询和统计。其思想是在每次招投标项目开始前，将其当作项目首先进行信息初始化，包括了流程设置、投标数据和信息存放地址、专家信息维护和企业信息维护等。在接下来的招投标治理中，将所有相关于本次投标的信息通过项目治理的方式来进行维护，从而实现信息的有效组织和维护。其中，用户权限及公共数据治理为整个系统的基础模块，用户治理要紧是对系统的用

21、户进行添加、删除以及用户信息的修改等;权限治理是由治理员对系统用户进行权限分配。公共数据维护是由系统治理员对生活调查中需要填写数据的数据字典以及某些公共数据进行维护。企业信息库维护和建立包括了企业申请、监管单位审批和企业信息维护等相关功能。关于招标项目治理，系统的设计过程中将其看做项目进行治理，包括了项目启动、维护和考核等相关流程。同时，关于其流程治理通过基于工作流引擎的思想进行设计和实现，同时能够对其进行状态跟踪和查询。为了实现对企业的资信进行评估考核，系统中建立各个时期标的履约考核，通过考核结果对企业的信用等级进行评估，为招标过程提供决策参考。同时，为了能够实现招投标过程的公正性，在评标过

22、程中专家通过随机抽取的方式进行确定。招投标文件归档治理是将每次招投标的相关文件进行归档存储，包括了标书、招标公告和相关合同书等，将不同的资源进行分类归档。数据分析模块要紧是针对某个时期内所有的招投标文件进行统计分析，包括招标信息明细查询、统计报表等。在系统的治理过程中，除了以上业务处理模块意外还需要包括报表打印模块将各类不同的数据报表进行输出，包括Excel输出、表格输出和统计报表输出等。在系统的需求分析过程中，本文采纳统一开发过程的思想进行软件设计与开发，系统的功能性需求描述工具要紧是用例模型 (UseCase)，立即系统的功能性需求分解到每一个需求分析用例中去。统一开发过程的最大优点是采纳

23、按照角色(A以or)对业务需求进行分析从而识不用例模型 (UseCase)中的方法，通过以上方法能够直观的建立起系统的需求分析模型，而且通过多次迭代处理幸免需求分析过程中存在的漏项问题。在统一开发过程的分析方法中，我们为了能够清晰的描述系统用例及其层次结果，本文通过包图对业务需求的各个模块进行分析处理。在系统的需求分析过程中，本文引入了包图对不同业务的用例进行分模块处理和分析。如图2一1所示，从系统的总体功能性需求来看本文的招投标治理系统系统能够划分为以下几个包图:用户和权限治理、公共数据维护治理、数据报表治理、招标项目治理、企业信息审核维护治理、专家信息治理、项目资源治理、投标履约治理、招标

24、流程治理、专家抽审治理、企业信用维护治理和信息统计分析治理等。图2-1 系统功能包图通过面向对象的分析方法，结合基于统一建模语言(UML)的建模方法对不同系统模块中的需求进行用例分析和建模。本文接下来对系统需求的核心用例模块包括企业信息申请和审核治理模块、招标项目流程治理、专家信息治理维护、履约考核治理、信用档案治理等模块进行用例建模分析和描述。2.2系统目标和解决的问题结合不同行业和企事业单位招投标业务的需求和分析，本文在设计和实现招投标治理系统的过程中需要达到以下几方面的要求:1、招投标业务处理流程复杂，本文对以上复杂的招投标流程通过面向对象的思想和UML建模语言进行了建模分析和梳理。通过

25、用例分析对系统功能进行分解处理，关于复杂的业务处理流程建立静态模型和动态模型。在静态模型的基础上，对要紧实体的数据库进行设计;最后，通过传统的基于多层的JZEE模型对系统进行开发和实现。2、针对招标企业的信用问题，系统在设计过程中增加了招标履约考核治理模块，针关于标书中的不同时期的目的进行采纳了可考核性指标进行评估和分析。通过关于完成标的情况建立企业的信用等级，同时建立招投标企业的信息库达到关于招标履行的可控性。3、招投标的业务流程较为复杂，其中包括了项目审核、招标公告、格预审流程、招标开标流程、评标流程治理、定标流程治理和签约流程治理等业务处理流程。因此，在业务系统的分析和架构设计过程中如何

26、实现业务流程的定义和操纵将关系到系统实现的成败。本文在系统的设计和实现过程中通过基于工作流引擎的流程处理模块，实现对招投标业务的建模分析、状态跟踪和业务操纵，从而达到有效的流程定义和业务处理。4、针对招投标治理中的核心公正性问题，为了达到整体业务的处理公平和公开，系统设计实现过程中通过流程审核分配以及专家信用评估和随机抽取审核专家的方式达到了招投标过程中的公正性。5、针对招投标业务数据的统计分析和决策问题，为了达到企业招投标业务的统计和易查询性，系统在设计过程中增加了各类不同的招投标业务查询和统计功能。同时，针对不同的功能为其提供了优秀的数据展现方式，从而达到为企业决策者进行服务的目的。2.3

27、功能需求分析招投标治理作为企事业单位的信息化治理核心模块，关系着其运营和生产，良好的招投标治理将会促进企事业单位的高效运作和良好形象。本文接下来将对招投标治理信息系统中的企业信息申请和审核治理模块、招标项目流程治理、专家信息治理维护、履约考核治理、信用档案治理进行详细的需求分析和描述。2.3.1企业信息治理在招投标业务分析和处理中，参标企业的信息维护是其中的核心业务模块，因为参标企业的活动贯穿着招标活动的始末，企业的信用和资质将会阻碍其是否能够通过初步的审核。关于招投标信息治理来讲，企业的信息治理包括了复杂的审核和审批流程，其中包括了企业的差不多信息备案、监管单位审核、企业首次填报、监管单位首

28、次填报审批、企业信息修改、修改信息审核等相关业务流程，其相关的业务处理流程和涉众人群如图2一2所示。图2一2企业信息治理业务流程图FigureZ一 2SystemPaekagediagram通过对上述企业信息业务治理流程的分析，企业信息治理模块中还包括了企业信息检索和查询以及报表生成打印等相关功能。通过对上述业务需求的分析，企业信息治理模块要紧包括了各类参标企业单位和相关监管单位两种角色。如图2一3所示，本文给出了该部分业务的核心用例图和关键用例的用例描述。图2一3企业信息治理用例图FigureZ一 3SystemPaekagediagram关于招投标信息来讲，企业的相关信息的维护关系着企业是

29、否具备相应的资质进行招投标操作，因此如何完成企业相关信息的填报和资质审查是本文系统设计和实现的关键。同时，企业关于相关信息进行修改时，也需要相关部门进行审核，因此针对企业的信息维护和填报的用例描述如表2一1所示。企业维护人员在登录招投标治理系统后，将依次对差不多信息、资质信息、人员构成信息、企业资产构成信息、设备信息和在建工程信息以及代表工程信息进行相应的维护。用例标识Model_Enterprise_01用例名称企业修改相关信息创建时刻2011-6-5参与者企业维护人员用例描述维护企业信息前置条件企业维护人员登录系统后置条件记录信息修改的次数监管部门将对修改的信息进行相应审核差不多事件流治理

30、员登录系统查看企业相应信息添加、修改或删除企业的相关信息，包括差不多信息、人员信息、矿产信息等。扩展事件流在企业的某个在建工程需要转为相关企业的代表性工程时，将其转化为代表性工程备注企业关于相关的信息进行修改时，需要进行相应的登记：在企业信息进行修改后需要通过审核以确保企业信息的真实性。 表2一1企业人员进行企业信息维护用例讲明2.3.2招标项目流程治理通过对招投标治理系统业务流程的需求分析，本文在分析和设计过程中将某个业务的招投标过程看作一整体的项目来进行治理。将整体的业务看做从发起、初始化数据到投标报名、专家审核、签定合同看作是项目的整体周期，通过工作流模型对其定义。在需求分析时期，需要对

31、其相关的业务流程进行分析和定义。通过对其业务的需求进行分析，其要紧的涉众角色包括了建设单位、投标单位和工程监管单位，整体的业务流程包括了招标项目定义、标段信息定义、招标公告公布、项目申请开始、资格审查报名、资格预审、招标开标、评标治理、定标治理和签订合同;整体的流程如图2一4所示:图2一4招投标项目流程图从上图能够发觉，在招标项目流程治理的整体业务流程中，所有的涉众角色中建设单位是关键的业务核心角色，因此接下来的描述中将针对建设单位的用例进行建模分析和描述，其业务用例图如图2一5所示:图2一5招投标用例图通过对招投标业务流程的业务需求进行分析，关于招投标治理信息系统来讲其最关键的业务处理为流程

32、的需求的梳理和治理。通过对招投标业务的需求分析，本文梳理得到招投标项目流程依次为项目信息创建和维护、标段信息创建和维护、招标公告公布、资格审查报名、资格预审时期、投标开标时期、评标时期、定标时期和签约时期。其整体的业务流程为顺序的关系，业务流程的处理过程包括了投标单位、建设单位和监管单位三个要紧的涉众人群。尤其在“资格预审”和“评标”流程环节中，需要相关的专家组进行招标投票和打分评审。因此，在业务系统的设计过程中还包括了相关专家等涉众人群。关于某个招投标项目来讲，在资格预审和评标的处理时期，需要相关专家进行登录评审。因此，在项目的创建和标段创建过程中，相关建设单位还需要设定相应的条件对专家组进

33、行自动选取，从而幸免人为选择因素从而提高了整体招投标治理流程中的公正和公平性。如表2一2，本文给出了专家条件设置和筛选用例的详细讲明:用例标识Model_WorkFlow_ExpertSelection用例名称选择评审专家创建时刻2015-1-11参与者建设治理单位用例描述治理员设定相关的专家筛选条件前置条件差不多对相关招标项目进行差不多维护完成相关项目的标段维护后置条件通过筛选条件自动生成评审专家为相关专家生成登录名和密码差不多事件流治理员登录系统查看相关项目信息设定评标和资格审查日期新建抽签关联相关的项目和标段，设定专家人数选择专家组类型进行专家组抽签确定专家组抽签，定签扩展事件流在专家组

34、确定以后，相关监督单位能够对专家抽签结果进行修改和取消备注专家组的选择与相关专家的信息，属性和专家的信用相关联，整体采纳动态淘汰制从而确保专家评审的公正性。表2一2选择评审专家用例讲明2.3.3专家信息治理通过以上的业务流程分析，本文得出相关专家信息的维护关系到招投标治理系统的成败，尤其是针对招标项目流程中的资格审查和评标时期，专家选择的公正性和权威性关系到招标最终的成败。因此，在招投标治理信息系统的设计和实现山东人学硕十学位论文过程中，需要建立相应的专家库信息及其维护模块，通过该模块支持整体的专家组筛选和确定，从而确保招投标业务的有效运转而提高招投标项目的成功几率。关于专家信息的维护涉众角色

35、为相关的监管单位来进行维护，相关的要紧功能包括了专家差不多信息维护、专家培训信息维护、专家现场考核、专家日常考核、专家单位信息维护、专家信息统计等相关功能，其用例图如图2一6所示:图2一6专家治理用例图2.3.4履约考核治理关于招投标治理系统来讲，招投标业务流程治理中最关键的部分为跟踪和确定某个时期内中标企业的履职情况，包括了完成进度、工作简报和履约评级等相关内容。通过相应的建设进度跟踪，能够及时跟踪和发觉招标项目建设过程中存则的各种问题。该部分相关的要紧涉众角色包括了建设单位和中标单位，其中中标单位需要定期填写简报，而建设单位需要定期的对相关工作内容进行审核和评价，及时列出某个时期内评价不合

36、格的单位。因此，关于履约考核最要紧的涉众角色为相关建设单位，如图2一7，给出了中标单位履约考核的相关要紧用例及其分析和描述:图2一7履约考核用例图2.3.5信用档案治理通过上述的招投标治理业务的分析，我们发觉招标单位、单位核心成员和评审专家的信用将关系着招投标业务的公平性甚至阻碍到整个招标项目最终的成败。因此，在系统业务分析、设计和实现过程中，需要增加关于以上三类要紧成员的信用档案维护和治理。其中，对招标单位来讲，其相关的中标项目的评价将会自动转入其信用档案;单位核心成员的信用等级也与上述中标项目的履约结果相关，其中评审专家的信用等级由相关监管单位的维护人员审核确定后确定其相关的信用阻碍。关于

37、信用档案治理，要紧包括了企业信用档案维护、个人信用档案维护、企业信用等级维护、专家信用档案维护和相关的要紧查询统计功能，其要紧的用例如下图2一8所示:图2一8信用档案治理用例图2.4系统非功能性需求关于业务信息治理系统来讲，除了业务功能相关需求以外还包括了系统运行、维护等相关方面的非功能性需求。相对一于功能性需求，非功能性需求不仅仅关乎软件产品的使用和性能，同时还在某种程度上阻碍到软件的功能性需求。假如事先缺乏专门好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。关于招投标治理系统来讲，本文的的非功能性需求要紧包括:适用性要求，可靠性要求，性

38、能要求，可支持性要求，下面分不对各项要求进行分析。1.适用性要求适用性要求系统用户学习和操作的简单，依照要求能够延伸出如此四点模糊的需求:l)指明为了使用户能够完成一般日常工作所需要的培训时刻，而且需要以那些从未接触过计算机的新手以及一般用户和高级用户的术语来描述。系统用户涉及到相关部门的使用人员、公司项目治理人员、评审专家等，系统使用培训对他们来讲周期专门短或者不需培训，而日常治理人员大部分属于计算机一般用户甚至是新手，那个地点所讲的培训时刻要紧指针对这类用户。关于新手用户来讲，系统应当满足培训时刻小于等于半天，否则将是不可同意的。2)指明典型终端用户可能的典型任务或事务的可度量任务时刻。关

39、于日常治理人员登录系统，从系统供能界面输入相关信息需要的时刻，这因此会受到技术实现中性能问题的阻碍(网络传输速度、网络容量、RAM和CPU能力，它们共同决定了系统的响应时刻)，然而任务性能时刻也更加受到系统适用性的阻碍。2.可靠性要求没人喜爱错误、缺陷、系统故障和数据丢失，当系统出现故障和用户出现错误的操作后是否支持恢复，当用户在使用过程中遇到错误的时候是否能够立即定位问题，当业务场景和逻辑发生变化的时候系统是否支持，当网络不稳定或使用中异常中断的情况下系统是否都有相应的容错措施，这些都包含于可靠性要求中。需求中需要特不提到这些现象，显示系统到底以哪种用户能接收的程度运转。(l)可用性(ava

40、ilability)。系统关于一个使用时刻的指定百分比必须是可用的。关于客房子系统来讲，系统必须7*24小时正常使用，而餐饮子系统也必须在进餐的高峰时段确保稳定。(2)平均故障间隔时刻和平均修复时刻(MTBF和MTTR)。同意系统出故障后不运转的时刻，比如要求90%的系统故障要在5分钟内修复，99.9%的系统故障要在一小时内修复，这就要求在系统运行过程中需要稳定的技术支持团队，达到故障修复周期的最小化。(3)准确性(accuracy)。产生数字输出的系统要求有多高的精确度。比如数以“万”为单位，统计时精确到小数点后面几位，才能让学位报盘是不超过国家规定的字段长度。(4)每类错误。通常分为微小的

41、错误、显著的错误和关键的错误三类。如数据的完全丢失或者系统的关键性模块不能使用。3.性能要求，通常包括以下几个方面:(l)事务的响应时刻:平均值、最大值。(2)吞吐量:每秒事务数。(3)容量:系统可容纳的客户总数或事务数。(4)退化模式:系统被降级时，可同意的运转模式。这些都应量化地体现在系统需求文档中。4.可支持性要求可支持性是指为了升级或修复，软件被修改的能力。对某些应用领域，以后可能的升级是可预测的，因此需求能够规定维护小组的简单升级以及复杂升级的“响应时刻”。第3章系统设计关于系统的研究开发，在完成整体的需求分析之后将进入系统的设计时期，基于RUP的软件设计要紧包括了系统概要设计和系统

42、的详细设计两时期的工作。系统的概要设计时期将要紧关注整体宏观上和系统实现的技术框架设计。概要设计要紧完成系统的需求分析到设计的转化，同时分时期设计实现系统的整体架构，使得系统架构能够为系统的进一步开发和运行服务。在概要设计的过程中，将采纳由粗到细的原则，通过定性和定量的分析和分解，同时采纳UML建模方法完成其设计。因此，本章将针对系统的概要设计要紧是系统的软件架构设计、权限治理设计和差不多的功能设计部分进行详细的描述。3.1系统技术架构3.1.1软件架构设计系统的软件架构设计是指将软件需求转化为数据结构和软件的系统结构以及划分系统功能模块设计。系统的技术架构，其任务是以系统需求分析的结果为依据

43、，充分考虑系统的特点及用户的要求，为系统选择合适的开发平台，同时选择合适的方式构建系统。该时期注重宏观上和框架上的设计，包括是否采纳客户端和服务器端分离的多层结构以及客户端和服务器端所采纳的技术等。针对招投标治理系统用户角色多、部门多和分布地域广泛的特点，整体招投标治理系统的架构设计本文选择采纳基于JZEE的多层架构设计，同时采纳了B/S的整体软件设计。客户端技术采纳扫瞄器进行实现，客户端与服务器之间采纳了HttP协议进行通信，同时为了能够实现相应的客户端与服务器端的异步通信，在具体的界面实现部分采纳了Ajax技术进行实现。在各个层中分不采纳了成熟的开源框架，层与层中间采纳统一的接口。通过统一

44、的接口设计实现了层与层之间的松藕合。同时，鉴于系统采纳分层松藕合的架构设计，使得系统框架的可扩展性得到增强系统容易实现对业务请求的扩展。 JZEE(Java2Platrorm，Ente印 riseEdition)是sUN公司推出的一种全新的概念模型，使用了一个多层分布式应用程序体系。应用程序的逻辑依照事实上现的不同功能被封装到组件中，组成JZEE应用程序的大量应用程序组件依照其所属的层被安装到不同的机器中。关于JZEE的系统架构来讲，要紧包括基于EJB的重量型架构设计和“spring+struts+Hibemate”的开源轻量型架构设计。关于基于开源框架来讲，目前己经逐渐成为研究和开发的热点同

45、时得到了专门大的进展。目前，相关于EJB来讲，关于表现层逐步出现了struts等相关框架，业务逻辑操纵和面向切面操纵的框架为SPring，而数据持久层框架为Hibemate。然而，相关于其余的轻量级框架来讲，“spring+Struts+Hibernate”已成为Java开发的主流框架体系。因此，在本文招投标治理系统开发过程中，也使用了“spring+struts+Hibernate”的三驾马车式的框架结构(如图3一1所示)，通过轻量级的架构设计节约了学习和开发时刻，同时满足了分层架构设计的要求。图3一l基于SSH的JZEE架构 JZEE平台提供的那个多层结构的分布式应用程序模型具有重用组件的

46、能力、基于扩展标记语言(XML)的数据交换、统一的安全模式和灵活的事物操纵;使开发者不仅能够比往常更快的发表对市场的新的解决方案，而且其独立于平台、基于组件的JZEE解决方案不再受任何提供商的产品和应用程序编程界面的限制。提供商和买主都能够选择最合适于其商业应用和所需技术的产品和组件。通过采纳基于JZEE的软件平台进行设计，整体系统的软件结构采纳了分层的思想，系统软件结构的整体设计按照MVC(Model，View，Control)的架构设计思想，将招投标治理系统的整体软件框架分为显示层、操纵层、业务逻辑层和数据持久层和数据库层等多层进行设计。以下对整体的分层结构图如图3一2所示，分不进行详细的

47、描述:1表现层，要紧包括基于扫瞄器技术的B/S端的页面显示和基于 JasperReP0rt的各种不同样式和类型的数据报表显示部分。关于界面的描述和分析技术，在B/s端要紧采纳了JsP和基于struts的页面标签库进行描述。同时，为了能够实现界面数据的异步请求和显示，本文在某些模块的数据显示部分采纳了基于Ajax的异步数据请求和显示技术。该部分要紧通过扫瞄器中内置的XnllHrtp协议和对象进行异步的数据请求和数据猎取，在对页面进行显示的过程中结合JavaseriPt对相应的界面Html元素进行操纵和显示。在报表数据的显示过程中，设计时期充分采纳了基于模型驱动的开发技术，将报表的显示划分为模型描

48、述、界面治理器和业务数据接口三部分组成。模型要紧是指报表界面中的各种显示元素;界面治理器要紧包括解析器、布局治理和事件处理三部分;业务数据接口是结合具体的业务数据处理猎取需要展示和存入报表的具体数据。在报表的显示过程中，通过业务数据模块猎取业务数据，由界面治理器结合数据和界面描述文件猎取最终绘制的数据报表和各类格式的图表。基于StrutS的操纵层设计，该部分的核心功能是同意和操纵从客户端发送过来的各类不同的请求，并通过运行时猎取的具体的XML配置文件信息，将请求转发到不同的业务逻辑处理类进行处理。同时，将处理猎取后的数据转发给相应的显示模块进行显示。3.基于SPring中间件的业务逻辑层，包括

49、SPring处理组件和各种功能服务型组件.业务逻辑层的设计包括相应的数据GURD的业务操作类、实体对象类和SPring框架封装类。其中，SPring为业务逻辑的有效开发提供了合理的封装类，能够实现面向切面的有效操作。同时，该框架采纳了分层的架构设计，能够合理的与MVC的架构进行整合。考虑到其业务过程治理为一完整流程治理过程，为了能够更好的进行订单跟踪和结果分析，我们在整体的架构设计中加入了基于JBPM的工作流引擎。工作流引擎通过访问流程数据库获得业务流程信息，操纵业务逻辑的流转。工作流引擎的引入将业务逻辑和流程逻辑分离，同意用户灵活的设计与公布新的流程。关于整个业务流程中订单治理采纳工作流引擎

50、进行治理和分析，实现了整体业务流程的有效操纵和跟踪。数据持久层，包括OR映射和数据库操作两层，通过基于 ORMaPPing框架的Hibemate，封装对数据库的持久化操作，提供可由业务层调用的接口，这也是Spring系列架构中 SPringORM所支持的。同时，通过oR映射完成了业务数据与数据库中的关系表的映射，使得整体设计脱离了对具体类型的数据库(如oracle，Mysql，MSSQL)的依靠。数据库层，要紧是具体的对数据进行存储的数据关系关联表，包括了不同实体数据的表格、各类业务关系的存储表等。本文中结合招投标治理系统的业务需求，采纳了Mysql数据库进行数据的具体存储。图3一2系统软件架

51、构3.1.2系统权限设置设计关于业务治理系统来讲，如何实现用户请求资源的有效操纵和分配是其关键的业务功能，本文所述招投标治理系统所涉及的相关业务人员涉众角色众多。因此，在系统的设计过程中，为了能够确保访问资源的有效操纵，本文设计和实现了相应的基于用户角色的访问操纵模型也确实是 RoleBasedAeeessControl(RBAC)。首先系统治理员通过“用户一用户组一角色一资源”多层模式来设置用户权限，为每个角色维护其资源的访问权限，而每个用户组被指派一个或多个角色，如此用户既具有了所指派角色的资源权限。依照用户请求的URL推断是否在该用户的资源权限表中，若无权限则返回客户端给用户提示。结合基

52、于角色的权限操纵模型，本文所述招投标信息治理系统的相关访问操纵治理模块描述如表3一1所示。操作名称操作方法系统资源治理创建资源、维护资源、删除资源用户角色治理创建角色、维护角色、删除角色、分配资源用户组治理创建用户组、维护用户组用户治理创建用户、维护用户、删除用户表3一1权限操作模式表相应的访问操纵组件中，资源的访问权通过系统用户角色来划分，同时将角色和相应的用户组关联，确定不同用户组所包含的角色。而用户组是系统中相关人员和用户的组合，按照一定的组织结构来进行分配。用户(usERS)是对数据对象进行操作的主体，能够是人、机器设备、计算机网络或其他任何有权力的代理.所有能够独立访问信息系统中数据

53、或用数据表示的其他资源的主体的全体，构成用户组。组(GROUP)是对用户的包含结构，一类拥有相同权限的用户，比如同一部门下的职工，或者同一类型的学生等。用户将不直接与角色 (ROLES)进行关联，而是将用户进行组包装后，有组与角色进行关联。角色 (ROLES)表示组织或部门中的工作或者职务，是一定数量权限的集合.将角色引入到权限治理中解除了用户和权限之间的直接绑定，建立了用户与访问权限之间的联系.一个部门中角色的全体构成角色集合。角色将于权限(Permission)进行关联，确定角色享有的权限。许可(Permissions)和权限(Permission)，许可描述了角色对计算机资源的访问和操作

54、所具有的权限，其反映的是授权的结果。比如授予某个角色对计算机资源有读的权限，则代表了一个许可的存在，那个许可表示角色猎取了对计算机资源的读许可。针对操作来讲，其描述的是许可和操作之间的一种关联关系，而这层关系则表示了某一角色对某一操作所具有的权限及权限状态。用户组分配 (UserAssignment)是用户到组的映射，表示某一用户所划归的组，用户与组是多对多关系，即某一用户能够划归一个或多个组，相同的某一组也可包含不同的用户。组角色分配 (GroupAssigliment)是组到角色的映射，表示一个组所具有的角色，组与角色也是多对多关系，即一个组能够具有一个或多个角色，相同的某一角色也可分配给

55、不同组。角色权限分配 (PermissionAssignlne叫，角色权限分配是角色到权限的映射，表示一个角色所拥有的权限，角色与权限是多对多的关系，即一个角色能够拥有多个权限，同样，一个权限也能够分配给不同的角色。本系统将RBAC模型中的权限集规定为对页面资源的访问权限。依照资源、角色、用户三级治理的机制，灵活的为用户指定角色，为角色指定可访问的资源，从而使用户的权限成为可配置的。3.1.3系统网络应用拓扑结构设计针对招投标治理系统来讲，要紧的涉众人员包括了招标单位内部相关治理人员、审核人员、投标的相关建设单位和工程监理单位等。关于招投标治理来讲，整体系统设计采纳了基于扫瞄器和互联网设计的B

56、/S架构，应用服务器和相关数据库服务器通过防火墙进行相应的安全操纵。系统用户通过Http协议对系统进行访问、请求，系统整体的网络拓扑结构设计如图3一3所示:图3一3系统网络结构设计3.2系统功能架构在业务信息软件系统设计的过程中，开发人员在功能设计和开发过程中将会依据业务功能之间的关联关系，通过分解协调的方法进行划分模块和功能子系统的方法进行软件开发。所谓分解确实是将系统划分为不同的业务功能模块，各个模块之间尽量减少其藕合性，同时在模块内部尽量实现高内聚性。如此，通过划分模块的方式，即有利于整体业务的分解开发，同时通过不同模块之间的协调实现整体系统的业务需求。在系统开发的过程中，本文采纳了上述

57、分解划分的业务分解方法，同时在整体的划分过程中遵循以下相关原则:1、单个模块内部具有高内聚性，同时具有相对独立的功能。业务模块的划分，必须使得单个模块内的业务之间具有专门好的内聚性。同时，各个模块间尽量减少相应的藕合，从而较少了模块间开发的相互阻碍。从而，整体的开发有利于进行业务分工，同时保证了软件产品的开发效率和代码质量。2、业务模块之间数据的祸合性尽量要小。在业务模块的设计过程中，应该尽量采纳接口的方式，从而减少各个业务模块之间的数据依靠性，从而实现了系统的结构更加松藕合。3、业务模块的划分同时应该尽量减少数据的冗余性。也确实是讲，在系统业务的数据划分总应尽量减少数据的重复性，应尽量使得关

58、于相关业务的数据的处理在某个业务模块中进行。4、业务模块的划分同时应该考虑系统的分时期实现的阻碍。关于大型的业务处理系统来讲，系统的实现会被划分到多个迭代过程来完成，因此在业务模块划分的过程中应尽量适应分时刻实现的过程。5、业务模块的划分应该同时考虑的各种系统资源的充分使用，包括各种网络和硬件资源。在对系统业务功能进行模块划分的过程中，我们需要尽量多的考虑现有设备资源的搭配，使得各种设备资源和信息资源能够合理分布和充分使用。通过合理应用，从而减少了系统对网络资源的过分依靠，同时又能够减少数据的输入和输出以及数据通信所带来的通信设备压力。关于业务治理系统来讲，业务模块划分的方法要紧包括:功能划分

59、(按业务处理功能划分)、顺序划分、数据拟和、过程划分、时刻划分、环境划分。按功能划分是目前最常用的一种划分方法。按业务处理顺序划分要依据业务流程分析的结果，这种划分方式在一些时刻和处理过程顺序特不强的系统中常常采纳。关于招投标治理信息系统来讲，本文提供了结合现有中间件包括struts、SPring在内的基于功能组件和业务组件相结合的集成化的信息治理系统解决方案。通过该方案为招投标信息治理的各个问题包括企业信息治理、业务流程治理、专家信息治理等提出了合理有效的解决方案。同时，系统的整体功能架构设计中加入了各种公共的业务组件，包括了短信提醒组件、邮件通知组件和权限治理组件等。整个系统的功能结构分为

60、框架层、公共服务层和业务处理层，其整体的功能结构设计如图3一4所示。图3一4系统功能结构1、企业信息治理子系统企业信息治理要紧指的是所有的参标企业对自己单位的差不多信息、人员、资质、设备资产等信息进行治理维护。其中的核心是企业的备案注册和首次填报。假如没有在系统里注册的企业用户，第一次进入系统需要备案。每个企业只同意备案一个用户。由招标办对企业注册信息进行审核。当企业备案成功后并不意味着能够参与投标，因为备案的信息量专门少，不能为企业的投标活动提供依据，因此企业需要详细地填报自己的信息，包括资质、资信、代表工程等。企业首次填报之后，必须由招标办对其输入的信息进行审批，只有审批通过后的企业才能进