停车证招标技术要求
来源：广州软件开发 编辑：广州软件外包公司 日期：2018-09-01
需求分析
1.业务需求
1.1.建设原则：
先进性和实用性
系统的设计既要在相当长的时间内保证其先进性，还应本着实用的原则，在实用的基础上追求先进性，使系统操作方便，便于实现信息资源共享，易于维护管理，具容性。
高可靠性和稳定性
系统运行稳定可靠，应具有过负荷控制能力。考虑系统在平时和峰值情况下，安全可靠运行的设备和数据备份机制，确保不死机，没有数据丢失。系统应支持无间断服务。
可扩展性和互连性
系统规模及模块要易于扩展，可以方便地进行设备扩充和适应工程的变化，以及灵活地进行软件版本的更新、升级和与其它软件系统整合提供便利。
易管理性
系统基础业务逻辑层实现“集中认证、分级授权”的权限管理机制，支持分布式应用管理模式。
安全性和保密性
在系统方案设计需考虑到系统的信息安全性和保密性的要求。应有完整的、统一的用户权限管理机制，防止非法访问、越级访问和非法操作，同时提供安全日志的功能。
规范性
系统开发严格遵照国家软件工程规范并参照CMM规范进行，严格根据开发进度提供有关开发文档。
1.2.技术要求
采用B/S结构，使用相当于Ajax技术高页面响应速度。
该系统必须采用J2EE规范的体系结构。
支持Oracle 、SQL Server等大型关系数据库。
采用通用的开发工具。
流程管理必须符合国际工作流管理组织WfMC的流程模型。
严格按照国家ISO9001软件开发标准进行管理，系统开源及提供开发设计部分注释清晰的JAVA源代码，提供详实的技术文档资料。包括：《需求分析说明》《系统概要设计》《用户手册》《详细设计说明书》《数据库设计说明书》《测试报告》等。
总体结构，符合电子政务系统规范。
1.3.功能要求
1.3.1
停车场基础信息管理
1.3.2
停车场运行信息管理
1.3.3
停车场全区分布管理
1.3.4
停车场统计分析
1.3.5 技术架构数据流图
①、浏览器通过HTTP以Form提交和请求参数提交的方式首先经过平台的编码过滤器和安全认证器，然后将数据采集到控制逻辑器Action中,Action将界面数据包装为Dto后调用Dao进行数
据查询或调用业务服务组件BizService进行业务处理后将查询结果集或业务处理返回结果序列化为,系统集成开发平台,JSON对象通过HttpSerletResponse返回给浏览器客户端。
②、Action将界面采集的数据组装为DTO对象后调用试图服务ViewService。特别强调：一般情况下，我们不走这条线。只有在系统的业务服务组件要同时支持各种异构客户端接入的时候，出
于接口统一的因素，我们才需要考虑浏览器客户端是否要走这条线路。注意：并不是说有异构客户
端接入时浏览器客户端就必须走这条路，而是如果为了要和其它客户端保持统一的接入口时才需要在Action调用视图服务。因为调用视图服务和其它异构客户端保持一致接口是需要付出性能代价的，具体情况得根据实际项目而定。
③、Action将界面采集的数据组装为DTO对象后调用业务服务组件BizService进行业务处理，并将处理结果以DTO对象返回给Action。
④、针对一些非事务类的查询操作，为了简化DAO编程，我们可以在Action中将界面采集的查询条件包装为DTO对象后直接调用非事务类DAO查询接口g4Reader，并将结果集以DTO、JavaBean、ArrayList等类型的数据对象返回给Action。
⑤、业务服务组件BizService将相关业务数据组装为DTO对象或者JavaBean后调用事务类
DAO访问接口g4Dao进行数据查询、数据持久化和存储过程调用操作。
⑦、数据访问接口将DTO对象、JavaBean交给DAO实现将其映射为相应的SQL语句向数据库
发出请求，并将数据库返回的结果集映射为DTO、JavaBean、等数据类型对象返回给数据访问接口调用端。
使用Soap协议调用视图服务组件，以系列化的XML资料格式进行数据交互。
应用性能要求
1.4.1系统处理能力
单表处理能力>=1000万条记录，最大可扩展到5000万条左右；
系统响应速度：数据录入界面刷新的响应时间3秒以内、数据存储的响应时间3秒以内、简单查询的响应时间5秒以内、大数据量的数据分析的响应时间初次响应时间在30秒左右；并发访问能力，支持不少于200
应用性能要求
1.4.1系统处理能力
单表处理能力>=1000万条记录，最大可扩展到5000万条左右；
系统响应速度：数据录入界面刷新的响应时间3秒以内、数据存储的响应时间3秒以内、简单查询的响应时间5秒以内、大数据量的数据分析的响应时间初次响应时间在30秒左右；
并发访问能力，支持不少于200个用户的并发连接。
1.4.2可靠性要求
1.平台支持7*24小时不间断服务。
2.系统故障修复时间不得超过2小时。
1.4.3安全性要求
1.应用系统安全：包括针对本系统的渗透测试、系统及信息安全应急演练。
2.数据安全：对系统内数据的全生命周期安全管理，尤其是隐私保护安全管理。
3.业务管理安全：包括业务安全风险评估以及用户管理。
1.4.4可扩展性要求
本系统的可扩展性要求包括以下几个方面：
（1）数据扩展要求
要求系统数据可更根据标准规范体系同步扩展，实现数据的动态的定义。
（2）功能扩展要求
要求系统采用面向服务的开发技术，并采用组件化、构件化技术开发插件，系统的服务层必须提供一致的接口规范。这样使得需要优化某一系统功能时只需在原来的接口规范基础上，改进组件内部的设计，以提供功能更为强大的组件。当需要增加新的功能时，通过开发包含新功能的插件，经通过简单的配置就可以集成到系统中。系统还需提供有二次开发接口，具备通过二次开发来增强系统的功能。
（3）业务扩展要求
要求系统分析通过定制来实现，对需要分析的数据和分析方式等信息与系统程序之间并没有紧密绑定，它是通过读取或传输数据流、分析模型来实现。因此，当系统需要改变分析内容，新增或者删除某个分析功能对系统本身没有影响。本系统要求采用这种平台框架，对数据分析进行定制，应用与设计无关，所以很容易扩展新的分析手段。
要求系统对外提供服务方式包括数据交换、订阅/发布、远程数据访问和WebService等多种方式。尤其是通过建立基于WebService的数据交换接口，能够定制出针对不同对象的不同种类、格式不同内容的数据服务，实现服务的可扩展。
1.4.5易用性要求
1.应用设计应充分考虑各个用户类和特性，提供适合各级操作人员的便捷操作界面，各应用系统应具有统一的用户访问入口和统一的用户权限管理，实现用户操作的单点登录以及所见即所得。
2.对于数据采集工具等应用必须提供数据归集人员易于操作的图形化操作界面。
1.4.6集成性要求
1.4.6.1采用面向服务和基于总线的架构进行设计。
1.4.6.2采用Web服务、消息服务、门户服务和数据访问等多层次、全方位的应用系统接入技术实现应用系统的集成。
1.4.7版本控制要求
应对所有的需求文档、设计文档及源代码等重要资料进行版本管理，用户可以追溯资料的任一版本及其修改过程。
1.4.8接口监管需求
1.4.8.1日志管理
要求对以下几类日志进行监控：
系统日志
记录系统日常的信息，包括系统状态等。
操作日志
记录所有操作的信息，包括操作名称，操作用户，操作时间，操作结果等。
查询日志
记录所有查询的信息，包括查询的数据项，查询用户信息，查询结果等。
出错异常日志
记录所有异常、出错信息，包括数据传输异常，消息传递异常，查询异常等。
数据传输日志
记录所有数据传输信息，包括各种数据的传输时间，数据来源，数据目的地，数据大小等。
记录所有消息传递日志，包括系统和信用服务数据库的消息传递信息等。
1.4.8.2流量控制
要求对数据提供方的信息交换流量进行控制，保证网络通畅和系统稳定运行。
1.4.8.3统计分析
要求对数据交换情况进行统计，可以按不同的类别分别出统计报表。
1.4.9授权访问需求
对于本系统而言，确保系统访问者身份的合法性是一个重要的问题。系统用户身份认证是应用级安全体系的关键和基础，根据本系统特点，要求采取基于PKI/CA系统为基础的用户数字证书的身份信息认证技术，实现严格的双向身份认证。
1.4.10安全建设需求
1.4.10.1应用系统安全
系统安全机制要支持集中和分散用户及安全管理。每个用户可以承担多个角色，而且每个角色都可以控制菜单、页面、操作和数据访问等多个权限列表。
系统还应具备较强的系统安全性和灾难恢复能力，系统具有安全审计功能。
在不影响系统运行的前提下，模拟黑客可能使用的攻击技术和弱点扫描，对本系统的安全做深入的探测，发现系统脆弱环节，服务期内对系统进行不少于2次的计划渗透测试任务，提交《渗透测试方案》、《渗透测试报告》；
建立针对本系统的应急管理体系，制定应急预案、运作机制、管理体系架构及相关指导文件，建立应急小组，进行信息安全应急演练并提交《应急演练评价指标集》、《应急演练过程记录》、《信息系统突发事件应急预案演练计划》、《信息系统突发事件应急预案演练总结报告》。
1.4.10.2业务管理安全
合法登录后，支持可配置的自动超时登录无效设置。
平台系统必须支持基于PKI数据证书的身份认证，能够调用安全服务，提供与安全服务之间的交互接口。
从业务安全的角度分析和处置信息系统在正常生产过程中存在的业务安全风险，服务期内对本业务系统进行不少于2次的计划抽样业务安全评估，提交《系统业务安全评估报告》；
用户安全：包括用户管理、权限管理、系统审计、日志管理，基于CA的登录认证功能完成CA与SSL实施。广州公共资源交易中心招标文件 项目编号： CZ2015-1270
二、项目总体实施要求
2项目实施需求
2.1.1实施方面的需求
本项目要求开发团队应驻广州市民政局殡管处完成开发或实施任务，要求投标人提出项目建设的组织方式、工作机制建议，并设计工作流程和实施方案。项目建设不得被转包。
投标人应结合自身的项目管理制度和经验，根据本项目的实际情况，在软件工程各个控制阶段提出针对性的管理方法。以下内容主要是对项目实施过程的一些通用要求。
（1）本项目应按软件工程规范要求进行数据库设计、详细设计。
（2）投标人应在合同规定的工期内完成所规定的系统建设任务。
（3）采购单位及采购单位所委托的监理单位，有权对整个项目实施的全过程进行监督检查。投标人必须给予积极支持和配合，不得以任何理由回避采购单位或监理单位的检查监督。
（4）系统开发工作应严格遵照国家软件工程规范和普遍使用的相关行业标准，如：ISO 9000、CMM等，并根据开发进度及时提供有关开发文档。
（5）投标人必须将整个系统建设划分为多个阶段进行，以保证系统建设的质量和进度得到有效的控制，其中至少包括：项目启动阶段、需求阶段、详细设计阶段、编码阶段、测试阶段、现场实施阶段、确认测试、试运行阶段、系统验收阶段、系统正式运行阶段（维护阶段）等。
（6）投标人必须建立完善的项目管理机制，以保证项目建设能按期进行。至少包括：事前计划，计划跟踪、进度控制和监督，需求管理，配置管理机制，产品质量评审，沟通协调。
事前计划：要求投标人在项目各个阶段开始前必须先向监理单位提供下一阶段的具体工作计划，在取得监理单位同意之后，方能进入下一阶段的工作。
计划跟踪、进度控制和监督：要求投标人对项目的总体计划和各阶段的具体工作计划进行跟踪报告，建立进度报告机制。投标人须向采购单位和监理单位每周提供《项目周状态报告》，报告上一周按计划已经完成的工作、未能完成的工作及原因、下周计划的工作；每月提供《项目月状态报告》，报告上月所处的阶段状态、按计划已经完成的工作、未能完成的工作及原因、与《软件项目计划》偏离度及是否需要调整项目计划、下月计划的工作；每个阶段结束后5个工作日提供《项目阶段总结报告》，报告阶段按计划已经完成的工作、未能完成的工作及原因、与《项目总体计划》偏离度及是否需要调整项目计划、；
在系统完成终验后一年软件系统免费保修期内承建方要提供一名可以修改源代码的程序员作为维护人员进行现场维护及保修,此期间该维护员要常驻采购方指定的工作场所,并非才出现故障时才到场。该维护人员按照制定的维护制度对系统进行
，对系统存在的BUG以及需要完善的地方进行修改；
2.2项目变更需求
（1）项目变更控制程序
本项目可能会因为对项目的实施前提、项目范围、进程安排、阶段性标准、交付物、价格或付款条件等条款的变更的原因，要求进行本项目的变更。本程序的制定是为了检查所有的变更请求，决定哪些需要实施、哪些需要推延、哪些需要否决。在得到招、投标双方的认可后，进度和成本将相应地做出调整。一个有效的变更控制程序对于避免项目延期和超支是必要的。
如双方需进行项目变更，则需遵守以下申请程序：
（2）提出变更
变更申请方需首先填写《项目变更申请》。《项目变更申请》需提交至由招标方和投标人项目领导小组人员组成的变更管理小组。变更管理小组成员的资格将由双方有关人员做出书面规定。变更管理小组将就《项目变更申请》的技术可行性以及对整个项目的影响做出评估。经过批准的《项目变更申请》将转给投标人，未被批准的将被退还给变更申请方。
（3）变更程度
重大变更是指引发投标人项目工作量增加的总和，且其增加的工作量不少于10个人日的变更。
一般变更是指引发投标人项目工作量增加的总和，且其增加的工作量少于10个人日的变更。
（4）变更内容
业务需求变更
技术方案变更
硬件、运行环境变更
（5）对项目变更申请的处理
投标人将在接到《项目变更申请》的5天内编写相应的《项目变更建议书》。《项目变更建议书》就《项目变更申请》中所提出的修改对整个项目的影响做出以下几方面的说明：
基本修改：功能的增改和删除；测试项目：测试和重新测试的修改；
系统性能：确认修改项目对系统性能的影响以及增加或改装其它机器是否必要；
其它材料：列出所有其它有关材料、进度：项目进展情况、提交件的进展速度和协议的终止日期；
费用：确认此修改引起的相关费用的调整；
（6）对项目变更建议书的确认
对于重大变更，相关《项目变更建议书》需由双方项目经理以书面形式提出，由招标方和投标人项目领导小组人员组成评审小组批准。
对于一般变更，相关《项目变更建议书》需由双方项目经理以书面形式确认。
如双方确认的变更内容与原合同条款的规定不符，则双方授权代表将在此变更申请的基础上另行签订补充合同，补充合同未阐明事宜仍按原合同条款执行。若与原合同有冲突时，以补充合同为准。
（7）重大变更处理流程
变更申请方提出《项目变更申请》。
变更管理小组将就《项目变更申请》的技术可行性等做出评估。
投标人以书面形式接受《项目变更申请》，并于5天内给出《项目变更建议书》，提交所需费用和实施计划等内容。
变更管理小组讨论《项目变更建议书》并给出评审意见（若为一般变更，《项目变更建议书》由双方项目经理以书面形式确认）。
投标人实施变更工作。
（8）变更责任
当发生变更时，若从签署合同后的累积变更所增加的工作量不超过0.5个人月的，投标人可以免费修改。累积增加工作量超过0.5个人月的，双方另行签订协议处理。
2.3项目实施计划
本项目由采购人统一组织开发与部署。为顺利完成项目的需求分析、设计开发与部署和部署实施等工作，需加强项目的组织和管理，采购人成立项目推进小组，统筹和协调各方工作开展。投标方需组织稳定的、经验丰富的项目团队来完成项目的开发与部署和实施工作，项目团队要接受项目推进小组的统一领导。
计划的工作、下一阶段存在的风险。
需求管理：要求投标人在需求阶段开始时，建立有效的需求管理制度，对需求的调研、需求的确认、需求的变更、需求的跟踪等相关工作进行有效的管理，保证能完全真实地反映采购单位的所有需求，而且所有需求能得到正确地实现。
配置管理：要求投标人在软件系统的整个生命周期中，对各阶段的产出物（包括纸质文档）建立配置管理机制，保证各产出物属于当前最新版本，确保上一版本出现的问题在下一版本得到改正。
产品质量评审：要求投标人在软件系统的整个生命周期中，对重要产出物建立评审机制，规定各类产出物参与评审的人员类型和评审通过准则，评审必须以会议的形式进行，形成评审会议纪要和《评审报告》。各产出物的评审报告必须提供给投标人和监理单位，在投标人同意评审通过之后，该产出物才能作为下一步工作的依据和指导。
沟通协调：要求投标人在和采购单位的工作交往中，建立良好的有效的机制，保证采购单位随时掌握项目的进展情况，也使投标人在工作中的重大问题和困难能得到快速的有效的解决，比如：建立定期例会制度，由投标人报告当前项目进度并提出遇到的无法处理的困难，重大问题由采购单位协调解决，并提出对下一步工作的总体要求，每次例会必须形成《会议纪要》并抄送相关各方；建立文档管理制度，保证合作双方的各种文件信息良好流通，并得到充分的共享。
承建方应负责完成系统的实施与部署工作，实施与部署产生的费用，包含在项目总价中。实施与部署所需要的软硬件、网络环境由建设方提供。
2.1.2技术支持服务需求
对投标人的要求：
系统试运行期间专人在现场指导使用人员的操作；
现场排除系统试运行过程中出现的软件故障；
提供热线电话，接受用户的随时咨询；
应技术人员的要求，随时讲解系统的结构及设计。
设立维护热线，为用户提供7x24的技术咨询服务；
提供7x24的故障处理服务，需要时必须保障2
相关阅读
广州软件开发公司业务咨询卢先生 手机18998818351 售后服务热线：020-22076940