公示截至时间：  2010年5月27日17时0分 

 联系人/联系方式：  采购人：成都房地产信息中心
联系人： 陈吉
电话：028-86279756
传真：028-86279538
集中采购机构：成都市政府采购服务中心
联系人：付博一、陈颖
联系电话：028-86271454、86770551
地址：成都市政府采购服务中心（成都市少城路25号少城大厦2楼）

成都市房产管理局OA系统软件开发项目技术、商务要求及投标人资格条件预公告

各潜在投标人：
    成都市政府采购服务中心受成都房地产信息中心的委托，拟对成都市房产管理局OA系统软件开发项目进行公开招标。为确保政府采购当事人的合法权益，现就该项目的商务、技术要求及投标人资格条件等广泛征求各方的询问和意见，如有异议，请于2010年5月27日下午17:00前以书面形式提出，详细的技术、商务、合格投标人条件、联系方式见附件。

附件：
成都市房产管理局OA系统软件开发项目技术、商务条件及投标人资格条件

1. 主要技术参数要求
1.1. 项目背景
当前成都市房产管理局的业务办理事务繁杂，各级领导及大量子业务部门间存在大量的信息交换和业务联合。为加强局内工作协调、办公效率、行政执行力，更好的提升我局的信息交互和处理能力，提高整体效率，更好的集中精力办公服务，需要建立一个操作效率高、信息处理能力强、功能完整、全面与各业务系统整合、适应性及扩展性优秀的办公系统平台。
实施办公自动化系统并不仅仅意味着简单的信息发布系统、信息共享、信息传递，还需要保证系统全面超越过去系统功能的同时，充分考虑使用者现有习惯，保障旧有系统历史数据能够无缝迁移，同时实现业务系统与办公系统的无缝整合，从而统筹信息管理、全面提升能力。
目前，我局现有的OA办公系统存在较多问题，不能满足现有办公需要。现有系统流程过于繁琐，操作过于复杂，系统稳定性差，办公平台功能单一，诸多问题对我局日常办公造成一定影响，针对这些问题，我局需一款全新的OA办公系统来优化提升日常工作效率。为领导决策和高效率办公提供信息服务；提高办公效率；减轻工作人员工作负担；节约办公经费。
系统除需要精细化实现当前办公需求外。还要嵌入OCR技术，实现各式原始档案的电子化管理。丰富资源，为全面内容管理提供基础。系统提供强大的查询和检索功能，建立基于内容搜索引擎的全文检索系统，将系统的所有内容（包含原始文档、附件）索引化，系统用户通过用关键词方式查询整个系统中任何其关心的内容而不需繁琐的人工查找。
通过在技术上的更新，最终实现我局的办公自动化、办公无纸化、资源信息化、决策科学化。
1.2. 项目目标
1、采用先进计算机技术和通信技术，构建成都市房产管理局的集成办公环境和公共信息服务平台；
2、提供可靠的、可追查的公文流转平台，有效的缩短公务处理的周期，加快公文流转过程，减少路耗、找人、等待等中间环节，保持公务处理渠道的畅通；
3、打破时空及地域限制，实现无纸化办公，远程办公、异地办公；
4、通过信息网络平台，提高信息统计和分析的水平，为领导提供准确、实时的预测和决策的辅助支持；
5、提供完善的信息交流机制，方便局属各部门、处室、科室、和员工之间日常办公及业务信息的交流和管理，实现业务办理互联互通，信息数据共享；
6、运用OCR技术实现各式原始公文文档的自动化读入、存储、管理，使无纸化办公成为可能，让工作人员从繁琐的录入工作中解放出来，真正实现了电子公文，并为全面内容管理提供基础。
7、运用全文检索系统科学高效地去管理系统中的所有信息，使它们在最短的时间内最大限度地发挥其价值，提供快捷的数据管理工具和强大的数据查询手段，通过快捷的数据管理工具，能快速帮助系统用户进行文档资料的整理和管理工作，强大的数据查询手段，使系统用户能很方便、及时地查到任何信息。
1.3. 项目主要内容
系统功能模块的划分，要遵循松耦合、易扩展的原则，将每一个功能模块高度封装，模块与模块间完全通过接口实现信息传递。通过现有模块接口可以轻松挂接新的功能模块，且可以达到“即插即用”的效果，即实现系统的易扩展性。
成都市房管局OA系统包含日常公文、督办工作、建议提案、信访处理、公告消息、会议通知、综合查询、统计报表、手机短消息等功能。此外，该系统将整合房管局现有的其它系统的信息，使之成为一个比较全面的综合管理工作平台。
为保证招标系统的实施进度符合采购人要求，且需求符合、运行稳定，建议供应商在已有OA系统平台上进行定制开发。
系统需求概述如下：请投标人深入理解需求，最好能在需求阐述中提供已有系统截图，来体现投标人对需求的理解程度。
1.3.1. 日常公文
日常公文主要包括两个方面：
1、日常公文处理意见的填写与管理。
2、日常公文处理流程的管理（即日常公文流转的管理）。
成都市房管局日常公文处理的流程包括：
（1）新建工作；
（2）拟办意见；
（3）领导批示；
（4）派件；
（5）办理；
（6）归档。
一份日常公文不一定要经历上述全部的步骤，日常公文在流转过程中，具体是由公文创建人员来确定日常公文后续应该作何处理及交由谁来负责处理。
说明：（1）文件在上述每个步骤都需要具有 “提交”和“抄送”功能。被“提交”的日常公文可以看作是文件正本，“提交”就是把文件正文传递给后续步骤的相关人员进行查阅和处理。被“抄送”的文件可以看作是文件的复印件，“抄送”就是把文件的副本传递给相关人员查阅及处理。不存在步骤，所有被抄送件同等级别。抄送件还可以再被抄送。
（2）确定流程后续处理人员：处理人员在处理完当前日常公文之后，公文需要发送回公文创建人员，由创建人员确定后续处理人员或后续处理部门。如果指定处理部门，日常公文将由该部门默认日常公文接收人员接收。且每个处理人员还可以自行制作多个接收人模板，可随时修改自己制作的模板。在文件归档步骤默认人员为文件创建人。
（3）在领导批示这一步骤，一个文件如果需要多位领导处理，那么在最后一位领导“提交”的之前，其它领导“提交”时，系统将自动“抄送”一份复件给相应的后续处理人员。后续处理人员即刻可以在“待处理工作”中查看到该复件并提前处理，而正文必须等到所有领导都“提交”后才能查阅、处理。
（4）归档只能由指定人员归档，一般是文件创建的文秘人员。
（5）后台管理人员可以根据文件编号查找出任意文件，并将其“提交”或“抄送”给任意步骤任意一个或多个人员，并可“撤销”或“恢复”工作。
（6）文件的附件办理人员在只有文件尚未提交前可删除附件，一旦“提交”后只有文件创建人员和后台管理员可删除附件，并留有删除记录。
（7）如果一个文件正文被“结束工作”而该文件尚有抄送件未处理时，该抄送件也自动被归档，但系统给抄送件拥有人自动发一个公告消息附带手机短信告知该文件已被归档。
（8）文件结束可以通过正常的“结束”和系统管理员“撤销工作”两个操作来结束。
1.3.2. 督办工作
督办工作流程及要求与日常公文流程及要求一致，请参考1.3.1日常公文。
1.3.3. 建议提案
建议提案流程及要求与日常公文流程及要求一致，请参考1.3.1日常公文。
1.3.4. 信访处理
信访处理流程及要求与日常公文流程及要求一致，请参考1.3.1日常公文。
1.3.5. 公告消息
1.3.5.1. 收件箱
用户对自己收到的消息进行管理。包括消息的查看、发送、转发、回复和删除。
1.3.5.2. 发件箱
用户对自已发送的消息进行管理。包含以下功能：消息的查看、发送、重发、接受状态查看、删除。
1.3.5.3. 草稿箱
草稿箱包含以下功能：消息的查看、发送和删除。
1.3.6. 会议通知
会议通知包括三个功能：
（1） 申请会议
（2） 编辑会议
（3） 会议的查询、查看
说明：
1、显示会议的列表。包括待召开会议、已召开会议列表。
2、可查看会议的详细信息。
3、待召开会议具有撤销功能，撤销会议可选择发通知给创建人与参会人员。
4、显示与所选会室有冲突的会议的列表。
5、可下载会议所附带的附件。
1.3.7. 公文查询
即根据所设置的多个条件组合查询办公工作及相关数据。包括：工作序号、标题、工作类型、当前办理人员、创建日期、归档日期、内容等要素。
1.3.8. 全文检索
基于OCR识别技术将公文附件，即公文的原件（如PDF文件、各种扫描件等）全部转化为字符，并为其建立分词索引。提供搜索引擎技术，当使用者查询内容时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈。
1.3.9. 文档OCR服务
将公文系统中各类原始附件通过OCR技术，经由扫描录入、图像处理、版面分析、识别、纵校、横校、版面还原等工序处理最终形成电子文档。处理后的内容为实现全文检索等内容服务提供基础。
结合全文索引系统对所有电子文档建立内容索引，便于用户对数据信息的查阅。
1.3.10. 数据迁移工作
新系统需无缝继承旧有系统数据，旧有系统数据需导入新系统并顺利承接使用。数据迁移工作包括：
1、分析与研究当前数据，与新建系统做比对，设计数据迁移过程中的不一致性并提出完善的解决方案；研究历史资料，分析特殊数据或历史问题的解决办法；选择数据迁移方法并设计数据备份、恢复策略、数据迁移和测试方案。
2、根据已确定的迁移设计方案开发具体的数据迁移工具软件。
3、据设计的数据迁移方案，建立一个模拟的数据迁移环境，它既能仿真实际环境又不影响实际数据，然后在数据模拟迁移环境中测试数据迁移的效果。数据模拟迁移前按备份策略备份模拟数据，以便数据迁移后能按恢复策略进行恢复测试。
4、根据设计的数据迁移测试方案测试数据模拟迁移，检查数据模拟迁移后数据和应用软件是否正常，包括：数据一致性测试、应用软件执行功能测试、性能测试、数据备份、恢复测试。
5、数据模拟迁移测试成功后，在正式实施数据迁移前做好完全数据备份。
6、按照数据迁移测试方案测试数据迁移效果，并对数据迁移后的数据库参数和性能进行调整，使之满足数据迁移后实际应用系统的需要。
7、完成Oracle数据库34个表，20GB的数据迁移到Oracle数据库工作，对旧有数据附件进行OCR扫描处理工作。
1.3.11. 系统集成需求
1.3.11.1. 权限整合
1、提供全局系统单点登录，即局内所有内部管理系统使用唯一的账号密码,帐户表统一且唯一存在OA系统中；
2、用户和权限管理通过OA后台配置,权限系统支持单用户授权和对多用户授权(比如以部门为单位授权,多用户可自定义);授权方式包括单个授权和多权限授权(角色方式)；
3、有在线用户列表,实时显示所有在线用户及用户所处的模块或页面；
4、实现真正意义的0客户端,客户端能兼容以IE为内核的主流浏览器的默认设置；
5、整合所有用户的登录日志和操作日志；
1.3.11.2. 各系统无缝接口
实现系统与局内各系统的无缝整合，包括数据整合、功能整合或操作整合等不同需求。成都市房产管理局需整合的已建及拟建系统包括：
与“成都市房产管理局固定资产管理系统”接口（功能及操作整合）。
与“成都市房产管理局人事管理系统”接口（数据整合）。
与“成都市房产管理局公众信息网（含政务大厅）”接口（功能及操作整合）。
1.3.12. 系统性能需求
系统注册人数在2500人左右，日常办公使用人数规模在1000人以上，日常同时在线人数在200-300人。系统需满足在线响应速度，及大规模存储的性能要求。
1.4. 通用技术要求
项目应满足以下通用技术要求，包括：
1.4.1. 技术规格要求
1、 系统服务器硬件平台应建立在较高性能的PC服务器或服务器群集上。为保障安全性，数据库管理系统和应用程序服务应建立在不同的服务器上。
2、 系统架构应采用多层架构及MVC设计模式。即除表现层、业务逻辑层、数据层外，提供数据模型、视图及控制器设计的Browser/Server模式；系统架构应充分考虑部署的灵活性，具备分布式部署的能力。
3、 系统采用Windows2003 server 作为应用程序服务的操作系统平台；系统采用Microsoft .NET Framework 3.5平台进行开发；系统采用Oracle企业版10.2.0.4作为数据库管理系统。
系统应保证在Windows 2000/XP客户端上的正常使用，浏览器建议采用IE6.0及以上版本。
4、 系统需要将消息发送接口发布为外部接口，用于其他系统（固定资产、公众信息网、人事）对相关人员进行消息发送；需要将日志管理服务的日志增加接口发布为外部接口，用于其他系统（固定资产、公众信息网、人事）进行日志信息的添加。
5、 系统需提供单点登录的权限认证体系；系统应对数据和应用的安全性作充分考虑，并提供完善的数据加密机制或接口以及日志跟踪与分析功能。
6、 系统的功能实现应具备事务特性，充分考虑网络状态的不确定性，提供完善的事务回滚机制。
7、 系统应保证在不使用浏览器插件的前提下，实现公文、报表的打印功能。
8、 系统应提供时间触发机制，以满足在特定时间点上的系统维修功能定制。
9、 实现系统与局内各系统的无缝整合，包括数据整合、功能整合或操作整合等不同需求。与“成都市房产管理局固定资产管理系统”接口（功能及操作整合）。与“成都市房产管理局人事管理系统”接口（数据整合）。与“成都市房产管理局公众信息网（含政务大厅）”接口（功能及操作整合）。
1.4.2. 开发进度要求
从签订合同之日起， 30 个日历日内完成需求调研、设计、开发、系统集成、系统测试、数据迁移、试运行并验收上线。
1.4.3. 质量保障要求
1、按照（1.5开发管理规范）内容所作要求提交文档。
2、在（1.4.2开发进度要求）的范围内，完成各阶段测试、联合调试及评审。
3、采取CMMI软件成熟度模型（3级及以上）对项目进行管理。
1.4.4. 服务要求
投标人需提出完善的售后服务措施，并满足如下要求：
1、提供本地7*24小时技术支持服务；
2、系统上线一年内，建立不少于3人的现场派驻技术支持队伍，包括技术工程师、硬件工程师及测试工程师。
3、其它招标文件要求的服务措施。
1.5. 开发管理规范
1.5.1. 项目计划
项目必须制定如下计划：
1、 整体计划及合理的阶段划分（包含招标要求的工作范围，及符合软件工程的阶段制定）。
2、 测试、评审、配置管理、质量保证、风险管理等方面的计划。
3、 详细的开发进度表。
1.5.2. 项目评审
1、项目必须按阶段进行评审：
2、“需求分析”和“系统设计”阶段必须经过评审，未按要求进行或评审未通过均不得进入下一阶段。评审必需得出书面结论并通过后才能进行下一阶段。
3、开发阶段完毕后由项目工作组组织预审。
1.5.3. 项目实施
1、需求开发
项目需在合同签署后5个工作日内完成需求开发并组织需求评审会。并按规定时间提交《需求开发说明书》，由甲方签字确认。
由甲方提出的需求变更需记录变更内容，并由甲方签字确认。
2、系统设计
项目必须进行概要设计和详细设计，并形成文档。
3、项目沟通
会议及重要的电子邮件、电话、口头沟通等要有记录，并及时向有关人员汇报和传达。
相关的报告、记录等要妥善保管。
4、配置管理
必须设专人进行配置管理工作。
配置管理范围包括与项目有关的所有文档（书面文档和电子文档）、软件（源代码、可执行程序）。
建立项目文档清单，标明文档名称、编号、状态。
建立软件版本控制制度，并严格执行。
1.5.4. 质量保障措施
1、测试
必须设专人进行测试工作。
测试必需经过功能测试、系统测试两个阶段。
测试还包括性能测试和压力测试。
以上测试工作必须形成测试报告。
2、质量检查
必须设专人进行质量检查工作，对整个项目过程中是否按规范执行进行检查和登记。检查结果定期汇报。
3、风险管理
项目必须进行风险管理。根据风险计划对风险进行跟踪，并每周更新。如发生风险，需及时汇报。
1.5.5. 产品及文档提交时间
1、《项目计划书》于合同签订后3个工作日内提交。
2、《需求开发说明书》于需求评审会前2个工作日内提交，并于评审会后2个工作日内提交修改后的《需求开发说明书》。
3、需求变更需填写《需求变更内容登记单》。
4、《概要设计说明书》和《详细设计说明书》于设计评审会前2个工作日内提交，并于评审会后2个工作日内提交修改后的《概要设计说明书》或《详细设计说明书》。
5、评审会后1个工作日内提交《评审会议结论》。
6、测试阶段完成后3个工作日内提交该阶段的《测试报告》。
7、质量检查、风险管理、配置管理等执行工作需有文档记录。在项目阶段完成时提交。
8、根据合同要求，阶段性的《用户使用手册》、可执行代码与源代码、《测试报告》于阶段性产品完成时提交。
9、《用户使用手册》、《项目总结报告》、可执行代码与源代码、《测试总结报告》，作为验收内容，于最终版本完成时提交。
1.6. 系统环境
本次涉及的系统环境介绍如下，投标人需要了解详细情况，可向采购人咨询。
1.6.1. 网络环境
房管局内网及Internet网络。
1.6.2. 硬件环境及拓扑结构
按照成都市房产管理局目前的网络状况，并且系统能够满足在成都市房产管理局外部访问的要求，系统的网络硬件拓扑结构图如下，其中由于数据库采用Oracle数据库，为了使系统能够稳定，快速的运行，在设计时将数据库服务器和WEB服务器分开。
 
硬件拓扑结构规划

1.6.3. 客户端
客户端使用Microsoft Windows操作系统，浏览器采用IE6及以上版本。
1.7. 付款方式
签订合同后10个工作日内，支付合同总金额40%的合同款；系统开发完成开始试运行10个工作日内，支付合同总金额30%的合同款；通过验收后10个工作日内，支付合同总金额25%的合同款；一年免费服务期结束后10个工作日内，支付合同总金额5%的合同款。
1.8. 质保和售后维护要求
1、系统从通过验收之日起，提供一年的免费服务，包括一般性需求调整和功能完善；
2、在系统使用的生命周期内，提供技术支持，包括系统接口和数据接口支持；
3、在系统使用周期内，积极协助第三方系统与本系统的集成。
1.9. 履约要求
采购人有权对供应商对1.4通用技术要求和1.5开发管理规范的遵守和执行情况进行验证、监督与检查。如发现未要求执行的现象，将视情节轻重，对投标人采取提醒、通报、根据合同条款进行经济处罚或终止合同等措施。

2.合格投标人应具备的条件
1) 在中华人民共和国境内注册，具有独立的法人资格，注册资金不低于人民币100万元；
2) 投标人应具有高新技术企业认定证书或软件企业认定证书；
3) 投标人注册登记地不在成都市的，则在成都市应有注册的分公司；
4) 遵守《中华人民共和国政府采购法》及其他相关的法律法规；
5) 本次招标不接受联合体投标。

3．联系方式
采购人：成都房地产信息中心
    联系人： 陈吉
    电话：028-86279756
    传真：028-86279538
集中采购机构：成都市政府采购服务中心
联系人：付博一、陈颖
联系电话：028-86271454、86770551
地址：成都市政府采购服务中心（成都市少城路25号少城大厦2楼）