交通信息门户网站项目总体方案设计.doc

文档密级：文档状态： 草案 正式发布 正在修订版本记录：序号版本变更描述修订人审核/日期批准/日期1234567891011目 录1. 背景进入21世纪以来，我国交通问题越来越严重，交通部门传统的工作方式与交通安全、通畅的业务需要之间的矛盾日益显著。为了有效地对交通进行控制，掌握交通的第一手资料，市项目目前网站内容信息发布、人才招聘、GIS/GPS定位系统、流媒体播放系统、流量分析、邮件系统、短信资讯、网上支付接口等子系统，决心从交通监理工作入手，运用当今先进、成熟的计算机网络技术，以构架面向的自动监控网络为手段，对传统的交通保护方法进行改进，从而达到交通信息化、自动化和现代化的目标。构建一座交通部门与老百姓之间的互通桥梁。既保证交通部门内部协调的高效，信息的及时监控与管理，信息的高度共享，又为大众提供了方便、快捷的服务。项目交通信息门户网站项目就是在此背景下提出的。2. 概述2.1. 系统建设的总体目标以市交通信息系统建设总体框架为依据，根据交通管理的需求，在全市范围内建设交通信息网络体系、交通数据体系，建立高效开放的业务应用系统，为实现全市交通信息化、自动化和现代化目标提供技术支持和业务保障。2.2. 系统建设的原则l 先进性：采用业界成熟的先进技术，把握国际信息技术最新发展动态，将各种先进技术和产品有效地应用于系统设计。系统建设和开发的各项技术指标应符合国家和行业有关标准和技术规范。l 稳定性：系统应具有良好的稳定性，采用目前主流的开发工具，保证系统的可延展性，以更好地适应未来的发展和变化。可在网络交通下稳定支持500个以上用户的协同工作。l 实用性：提供方便灵活的操作界面和帮助支持；支持工作流程、用户界面、功能模块等的定制。l 兼容性：支持不同数据格式、不同来源的交通数据的管理、加工和共享。系统之间具有严格统一的调用接口，保证系统升级的灵活性和可扩充性。实现各层次之间的信息交互与远程查询。l 开放性：提供标准接口，便于第三方开发的系统的接入。l 可扩展性：系统结构、系统功能和系统应用具有可扩展性。具备对多种数据库的整合功能，以统一、透明的方式实现统一管理。l 安全性：具有完备的错误处理机制，具有访问日志、数据库的灾难恢复机制。具有防止黑客攻击、病毒感染、内部泄密事故等系统安全控制功能。2.3. 总体设计的基本任务1. 围绕市项目交通管理要求，制订交通基础数据的分类标准与质量控制体系。2. 以交通统计、交通质量监测、建设项目交通管理、交通监察、生态交通调查等数据为例，研究基础数据的分析、处理、加工、共享与服务的规范化处理体系。3. 根据项目各业务部门工作需求，为建设面向市交通管理业务流程的软件系统进行总体设计。4. 为建设覆盖全市的交通信息网络进行架构设计。5. 探索建立市交通信息安全和信息共享的保障机制。6. 建立交通门户。3. 实施计划科技对完成市项目信息系统总体设计方案的大概时间估计如3.1图所示。据我们对以往项目实施经验，我们认为项目的总体方案设计计划包含以下几个步骤：启动，需求调研与分析，总体方案设计。其中在需求调研启动阶段建议对参与业务需求调研的项目工作人员根据实际需要作适当的培训。3.1. 工作进度计划根据项目网站功能清单516.xls需求文件，通过大致分析。本系统至少需要8人历时6个月8个月的周期。具体时间需要在确认具体需求内容后才能评估。3.2. 任务分解（WBS）3.2.1. 需求调研需求调研的核心内容是调查系统设计的总体思路和项目的总体目标是否能够明确下来，是否得到各部门的认同，能否贯彻下去，实施难点和风险何在。需求调研的具体内容包括新旧系统下的以下指标： 系统的原有规模和今后可能的规模（目前设备状况、投资预算等），如目前设备的数量、型号、配置、分布、新系统中可利用情况、其它设施状况、通讯线路资源、今后可能的选择等； 目前和今后的项目相关人员结构、层次关系、职能划分、职责定位走向、项目相关人员的水平、数量、今后工作重点、参与项目程度、接管和维护项目成果方式、考核要求、各部门间的相互影响约束关系、对系统目标的认同程度和对自身业务和发展的影响程度等; 各项业务目前和今后的业务处理流程、业务功能、分布处理要求、对性能的要求、数据的来源、分布、数据的格式，目前系统的困惑、弊病和不方便业务人员的要点、扩展性要求、安全、备份及可靠性要求、维护方便性要求、其它今后的整合和改进的要求，理想的功能、模式等。 项目实施的风险、难点、资源状况、认知状况、连带问题、损益价值分析、可容忍的风险规避方法、相关投入可接受程度等；根据以上调研内容，结合贵单位企业发展的战略目标和新的IT系统规划目标，整理和确定新系统的需求。形成确认的市项目需求说明书、需求规格说明书。3.2.2. 设计标准制定按照市项目的规划，本次设计必须按照一定的规范执行，标准的制定先于设计的实现。标准按照“国家法规”、“地方法规”、“本地规范”，“本次设计规范”的顺序严格制，目前需要制定的规范如下：需求提供相关资料。3.2.3. 系统架构设计针对系统目标和业务需求，以经济、有效、可扩展、易维护、安全、可靠为设计原则，确定应用逻辑体系结构的以下要素： 主机的类型、角色作用、层次和分布，操作系统要求、主要业务处理流程分布; 网络的层次、分布、作用范围和规模、性能、网段划分等; 数据库的分布、不同数据内容的分类和分布、主从镜象或拷贝关系的确定、数据同步时间要求等； 应用业务处理的功能划分、层次划分、处理分布；如三层结构等； 各处理层次的接口标准、协议标准、所需中间件和相关要求等; 对存储设备的结构要求、分布要求、数据的分布和受控关系要求、故障接替可靠性解决方案要求、性能要求、远程备份要求、管理维护要求等; 日常数据的存储备份策略、带机带库的技术指标要求、设置分布、管理办法、使用频度、数据和介质的存放、保管、恢复和再用的策略等; 开发交通和测试交通的设计与模拟构造、设备和相应软件的指标要求、版本管理、发布流程、方式和处理分布; 根据设计内容，形成确认的系统总体架构设计说明书。3.2.4. 主机系统设计主机系统的选型分析和性能估算针对以上确定的应用逻辑体系结构方案对主机的要求，结合当今主流主机服务器厂商提供的产品特点和市项目长远发展意图，综合性能价格比、最大处理能力、扩展能力、相关系统软件及工具的支持资源保障和支持服务能力等综合要素，帮助市项目选择恰当厂商的主机服务器产品。针对选定的厂商从不同档次的主机服务器中分析评估实际需要的档次和处理能力。确定不同作用主机服务器所需的配置，相关软件，以及厂商和集成商应该代理的服务。最终设计选型还要保证系统性能的充分发挥和升级扩展余地。根据设计内容，形成确认的系统服务器/终端机部署方案设计。3.2.5. 存储系统设计各主机服务器型号档次确定后，为了统一管理、扩展、维护和备份，IT中心需要共享外置存储设备SAN系统。集成设计者将根据系统对SAN要求的各项指标，分析评估现有SAN产品的技术先进性、厂商资质、实力、成功案例、市场占有率、服务质量等，帮助市项目选择建议适当产品和档次。确定其资源配置，数据冗余保护级别，与系统互连的方案，和需要的厂商及代理服务，形成确认的存储系统设计说明书。3.2.6. 容灾系统设计数据容灾高可用性设计和故障应对策略针对以上确定的应用逻辑体系结构方案，找出单点故障重要关键设备，（如数据库服务器），在保证应用体系结构一致性的前提下，对单点故障关键设备利用其高可用备份技术，设计备份解决方案和故障维护切换接管方案。为了充分利用备份机资源，可能还需要设计并发共享访问数据库机制，提出对应用体系结构和应用编程方法的调整要求。为进一步提供系统高可用性，将根据不同的灾难级别和提出相应的数据容灾方案建议，并客观调查评估不同方案的容灾能力，抗风险能力、实施和维护代价及相关的收益（经济效益和社会效益），为市项目选择恰当的容灾方案提供咨询信息和相关建议方案。确定容灾方案思路后，帮助市项目设计具体实现方案，相关产品评估建议，所需设备和资源配置，相关技术指标要求和要点，以及实施方案和备份恢复策略建议等。形成确认的容灾系统设计说明书。3.2.7. 网络系统设计根据应用逻辑体系结构设计方案和以上所选各类设备的物理分布和连接关系，设计整个系统的网络架构，确定各环节所需网络设备性质和性能要求，帮助客户评估和选择适合的网络产品和有关厂商，列出配置，连接方案和建议的网段划分、IP规划等，分析评估各种产品的利弊特点，供市项目最终决策。形成确认的系统网络拓扑结构设计。3.2.8. 安全设计集成方案涉及到的各级服务器、网络系统、业务系统需要统一进行安全集成设计和安全风险评估，包括CA认证系统的设计和建设、VPN虚拟网段的划分、不同访问者的市项目按照业务和管理级别的授权、安全管理维护策略的设计、防病毒、防火墙、IDS监听等产品的评估选择和建议方案和配置。形成确认的系统安全体系设计。3.2.9. 系统软件平台设计系统软件指支撑应用软件高效运行和便于管理的与业务无关的通用软件。包括数据库、中间件、操作系统、开发工具、数据转换或抽取工具等;针对市项目的业务和应用系统目标和要求的综合因素，对此类系统软件每个产品需求目标客观分析同类产品的不同特点（如功能、性能、特点、兼容性、成熟性、易用性、扩展性、价格、服务、厂商实力、市场占有率、开发维护资源可选择灵活性等），提出综合分析评估意见，帮助市项目选择最佳产品和完整配置。避免市项目花冤枉钱或考虑不周影响项目进度或质量。最终形成系统软件平台部署方案。3.2.10. 应用系统设计应用软件按照市项目需求分为网站内容信息发布、人才招聘、GIS/GPS定位系统、流媒体播放系统、流量分析、邮件系统、短信资讯、网上支付接口、论坛等子系统平台分别进行设计，设计按照需求分析获得的成果，充分考虑实际的工作习惯和软件实现的难度，以及对设备的负荷能力，按照最优化的方案进行。具体的成果如下： 需求分析说明书 概要设计说明书 详细设计说明书 数据库设计说明书 数据库建库脚本 项目总体进度计划 项目质量管理说明书 项目配置管理说明书 项目风险管理说明书 项目成本分析说明书 项目测试计划说明书 项目缺陷跟踪分析报告说明书 项目总结报告说明书 项目源代码说明书 项目安装说明书 项目运维说明书 项目培训说明书3.2.11. 过渡方案设计新旧系统平滑过渡平稳切换方案的设计理论上的集成方案必须结合现实市项目系统的实际现状，新系统能否成功实施上线，很大程度上取决于新旧业务系统能否实现平稳过渡，平滑切换。科技在支持客户上线过程中积累了大量成功案例和实施经验和方法，我们愿意提供周密的设计和并且提出切实可行的平稳过渡、平滑切换实施方案。并提交数据迁移方案设计和系统过渡方案设计。3.2.12. 编制实施计划编制实施计划主要任务系统集成项目实施任务分解、子任务界定和实施顺序及阶段的划分。理想的系统方案必须以周密的项目实施计划和监控方法才能得以体现和落实。科技提出的系统集成方案有一整套集成实施和项目管理办法与之配套。其核心是项目管理和质量控制经典理论中倡导的，用SOW方法对整个项目分解的子任务进行详细描述和尽量严格的界定。规定了每个任务的实施步骤、验收标准和提交的文档，把整个描述界定过程看成是实施方案的完整设计过程，把各方面集成专家的经验汇总在实施方案中，成为指导集成实施的纲领性文件。科技可以为市项目提供完整的实施方案设计和监控服务，包含集成项目实施任务分解、子任务界定和实施顺序及阶段的划分和任务的监控等服务。并提交项目实施计划3.2.13. 编制项目概算系统资源规划和成本估算，以及实施过程中将出现的风险预估和防范措施。科技基于服务产品的角度来分析系统集成的特点，并进而对系统集成进行资源规划设计和成本估算分析。科技提出了技术资源规划、管理资源规划、信息资源规划方法，并将从工程的角度来进行系统集成任务实施成本的预算、概算。按照风险分析的方法，对规模、时间、资源、成本、技术等风险进行分析，同时提交项目投资概算和项目风险分析。3.3. 需求开发3.3.1. 理解需求范围通过项目领导和信息中心了解项目概况（包括项目背景，项目目标，项目业务战略），把握项目的业务需求框架范围。确定调查对象（包括组织机构、岗位、用户代表从岗位中挑选出人员）。3.3.2. 需求调研 制定需求调研计划需求调研将会涉及大量与客户各方面人员的沟通工作，有序协调客户各方面负责人员和具体的业务人员的工作时间安排，结合业务需求的各部分依赖关系，统筹规划，使需求调研工作有序进行，避免工作遗漏。 访谈并记录访谈过程一定要详细记录最终用户的访谈结果。 运用作者本人的已有知识猜测或提出一些假设，请客户协助使之逐渐接近现实； 与具有这方面专门知识的一个或几个“专家”的深谈是最主要的； 访谈需寻找事实，以便理解当前的操作和现有的交通；讨论改进，确定新系统的操作和交通；展望发展，有助于建立未来的需求。 资料收集 资料来源：Internet网、客户、相关书籍、已有软件系统。 资料种类：组织机构图、办事指南、规章制度(如ISO9001文档)、报表、单据、行业规范、国家国际标准等。 已有软件系统调研已有软件系统可能为客户正在使用的软件系统，准备使用本项目进行替换；也可能为与本项目相近的市场已有软件系统（通过Internet网或其他渠道获取）。 查看系统使用手册 使用已有软件系统 查看数据库结构说明书 确定已有软件系统的运行交通和系统架构、编程语言（B/S或C/S,J2EE等）、数据量、数据增量 确定已有软件系统的使用范围、使用情况、价格 确定已有软件系统是否需要进行数据移植，已有软件系统是否具有数据接口，数据的质量（数据的错误率是多少） 查看其他已有软件系统资料 对已有软件系统的不足（自己认为的和客户提出的）也要记录为新需求，但更重要的是，要看已有软件系统优秀的地方。 原型开发及演示需求调研是一个多途径重复交流的过程，参照对用户的初步访谈记录，理解用户意图，利用快速开发工具或脚本设计工具等设计、制作原型系统，工作重点放在表达出对用户需求的理解，不追求系统性能和可靠性。向客户演示此原型系统。原型的开发人员在原型制作完成后，与客户的业务使用人员一同操作原型系统，向客户讲解原型系统的功能和操作方式，征求客户适用人员的意见，确认我方对客户需求理解是否正确，可能的情况下在原型上修改并再次征求客户的意见。根据用户反馈修正对目标系统的需求理解和描述。将用户认可的原型所呈现的客户需求形成规格化需求描述形成需求调研报告。3.3.3. 需求分析 理解需求调研报告需求负责人组织项目组需求分析人员，仔细阅读先前形成的需求调研报告，区分需求中需要计算机系统实现部分和需要客户人员介入完成的部分，划分系统边界。 绘制系统关联图这种关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物质流。 确定需求的优先级别在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。 分析需求可行性应用分析方法来确定使用实例或单项需求实现的优先级别。以优先级为基础确定交付版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更，即需求要与计划保持同步更新。 为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。可使用PowerDesigner工具，参见“概要设计”。 创建数据字典数据字典是对系统乃至的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。 形成需求说明书3.3.4. 需求评审对客户需求规格化描述完成确认，形成系统设计开发基线。通过评审消除工作产品的缺陷而提高产品的质量，越早消除缺陷就越能降低开发成本。一般而言，需求评审需要项目组的项目经理、需求负责人、领域业务专家、QA参加。根据业务需求重要程度决定所采用的评审方式，例如：走查或凡根式审查。将评审时发现的缺陷记录为缺陷跟踪表，撰写评审报告，做出最终的评审结果。客户双方在重新修订需求说明书签字，最终形成需求基线。3.4. 系统设计科技所采用的概要设计方法，一是遵循传统的面向结构和过程分析与设计方法，二是新崛起的面向对象分析与设计方法，或者两种方法混合使用，并配套相应的软件开发流程。采用的概要设计工具主要选择PowerDesigner，PowerDesigner是基于UML规范的适用于面向对象技术的设计工具。3.4.1. 设计方法概要设计的任务就是要确定系统怎么做，主要根据需求分析所建立的模型，进行系统的总体设计、数据库设计、功能设计和界面设计。数据库设计是采用关系型数据库的设计方法，使用PowerDesigner工具。功能设计是采用面向对象技术的设计方法。采用UML标准建模语言，使用PowerDesigner工具。界面设计可采用描述。3.4.2. 应用模型设计应用模型设计主要是进行应用系统的应用模式与功能结构设计，以及进行应用系统的实现模型设计。 应用体系结构（应用模式）以结构图的方式，表述应用系统的实现框架，包括：主机布局、网络布局、数据库服务器分布、应用服务器分布、客户服务器分布等。然后对系统框架中的各个组成部分进行描述。 应用组成结构以一览表或功能结构图的方式，表述应用系统的组成元素（子系统、功能模块、子功能模块等）的划分，扼要说明每个组成元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。 关键实现技术对应用系统所涉及的实现技术进行描述，如：数据库技术、中间件技术、性能设计、应用安全设计。3.4.3. 数据库设计数据库设计一般分为概念设计、逻辑设计和物理设计三个阶段。 概念设计在数据库概念设计阶段，主要设计数据库的概念结构，建立数据库的每一幅用户视图。概念设计包括各子系统概念模型定义和全局概念模型设计。子系统概念模型定义包括：子系统下实体定义、相关实体属性定义、实体关系定义、继承关系定义、规则定义等;全局概念模型设计包括：生成全局概念数据模型、编辑全局概念数据字典。 逻辑设计在数据库逻辑设计阶段，主要建立数据库的数据模型和数据库的管理员视图。逻辑设计建立的逻辑数据模型是由概念数据模型生成，并加之相应的定义：视图定义、触发器定义、存储过程定义、扩展属性定义、新增表定义。 物理设计在数据库物理设计阶段，主要建立数据库的系统程序员视图。物理设计内容包括：数据库的性能规格和数据库的操作规格，其设计依据为：外部数据采集的日/月平均量与次数;数据输出的日/月平均量与次数;信息访问的日/月平均量与次数;内部数据处理的日/月平均量与次数;数据存储的日/月平均量。3.4.4. 功能模型设计PowerDesigner设计工具通过UML语言贯穿了各个阶段的连贯与一致性，UML描述语言是以静态和动态建模机制为基础。UML设计主要建立三大模型：用例模型、分析模型和构件模型。用例模型适用于需求分析阶段，分析模型适用于概要设计阶段，构件模型适用于系统实现阶段。用例模型主要建立用例图和活动图；分析模型主要建立时序图、类图；构件模型主要建立构件图和配置图。 用例图建立用例图是从用户的角度描述系统功能，并指出各功能的执行者。因此，用例图是由一系列的用例和执行者组成，而用例被定义成系统执行的一系列动作，动作的执行结果能被执行者观察到。 时序图建立时序图用来描述类之间动态的交互关系，着重体现类之间消息传递的时间顺序。时序图存在两个轴：水平轴表示不同的类，垂直轴表示时间，不同类的操作在相应时间段上产生激活关系，并由消息触发。一般情况，每个用例至少建立一个时序图。 类图建立在面向对象建模技术中，是用分类的方法将客观世界的实体映射为对象并归纳成类。在UML中，类与类之间的静态关系则是由类图表示。与数据模型不同，类图不仅显示了数据的结构，同时还描述了系统的行为。因此，类图技术是UML方法的核心，类图也是定义其它图的基础。4. 资金需求5. 人员配备5.1. 项目组织机构6. 资讯项目管理规范6.1. 计划管理6.1.1. 工作流程6.1.2. 计划编制 分工职责 进度计划应根据项目管理的需要采取分级方式进行编制。 根据项目工作小组对工程建设内容、功能及标准、建设工期等要求与约定事项，在顾问专家组的指导的协助下，编制并确定指导性的市项目设计总体计划。 开工前，设计工作小组依据合同约束和市项目设计总体计划要求，就所承建的项目内容编制并提交“工作方案”， 说明项目工作的步骤、方法、工作阶段划分、详细进度计划、人员安排、对应计划应提交的工作成果、进度与质量控制内容、需要相关各方协调与配合的事项等。 依据市项目设计总体计划和经审批确认的各设计工作小组提交的项目进度计划，并据此监控项目的进度执行情况。 编制要求 市项目设计总体计划1) 明确所覆盖的阶段和时间范围；2) 根据项目的合同要求，确定项目过程，划分阶段。一般情况下，可包括但不限于需求分析、数据准备、总体设计等阶段，并且阶段可以组合、迭代。3) 每个阶段和任务必须明确项目工作小组的具体负责人。 项目进度计划1) 明确所覆盖的阶段和时间范围；2) 计划中应该包括但不限于以下内容：“任务名称”、“参加人员”、“工时”、“开始时间”、“结束时间”、“提交工作产品”；3) 根据设计工作小组的工作方式，项目进度计划可以按项目阶段的不同，拆分为多个不同类型的计划。例如：开发计划、测试计划、实施计划、质量计划等；4) 根据项目的实际情况，进行阶段划分，并明确里程碑。5) 进度计划原则上应细化到不超过3天的任务项。 计划审批 项目工作小组组织相关各方进行计划的协商、协调、审查，确认无遗漏事项、确认计划满足项目总体进度目标要求，并可控、可行。 设计工作小组编制并提交的项目进度计划通过评审后，即为各方共同遵行的进度基准，必须执行。 设计工作小组编制并提交的项目进度计划评审未获通过，设计工作小组应根据评审意见修改。6.1.3. 计划实施 进度检查 设计工作小组、项目工作小组重点加强对项目里程碑的进度检查，并依据合同规定对延误进度的设计工作小组实施处罚。 同时设计工作小组应加强项目过程中的进度检查，及时发现进度偏差并加以控制。 项目工作小组根据需要在项目过程中不定期抽查进度情况，对此设计工作小组应积极配合，无条件提交中间过程工作成果及过程记录。 进度报告 设计工作小组应按周提交进度报告，按计划项列举说明实际开始时间、完成时间、延迟原因及改进措施。 设计工作小组还应在计划里程碑完成时对工作量、进度、质量等进行分析，并将分析结果作为进度报告提交给项目工作小组，必要时项目工作小组可进行检查认定。 项目工作小组汇总各设计工作小组提交的进度报告，检查更新项目进度控制表，并向项目工作小组和各项目相关方公布项目进度情况。 项目进度超过合同约定的时间点，应视为设计工作小组违约，事前与项目工作小组协商同意延迟的除外。 对项目过程中日常进度出现延迟的情况，设计工作小组应进行书面解释，并提出合理的解决办法并实施完成，否则按违约处理。 变更控制 项目过程中因进度偏差导致不能按期达到预定的里程碑的，设计工作小组应及时提出进度变更申请，说明变更原因，提出改进措施。 进度变更申请提交给项目工作小组，由项目工作小组组织相关方进行变更评估和审批。审批通过之后，由项目工作小组将变更影响公布给各相关方。 变更审批通过之后，设计工作小组应提交更新后的项目进度计划给项目工作小组，项目工作小组组织相关方再次进行评审； 变更发生之后，项目工作小组监督相关各方是否根据变更结果修改了各自的进度计划。6.2. 质量管理6.2.1. 工作流程6.2.2. 质量工作要求 设计工作小组 设计工作小组应按ISO9001质量管理体系规范要求，针对项目实施过程及交付结果进行质量规划、管理、控制。 设计工作小组必须提交正式的质量计划，明确质量控制点、控制内容、质量要求、检查记录要求，并经项目工作小组审核、批准。允许质量计划与进度计划合一。 设计工作小组在项目实施过程中应开展质量保证活动，并提交质量审核报告，对质量问题制定改进措施并有效执行。 设计工作小组应对所承担项目的工作成果质量负责，并在工作过程中按质量控制要求进行自检、互检和交验，未经检验或已经检验定为不合格的工作成果，不得提交项目工作小组或项目工作小组。 设计工作小组必须接受项目工作小组的质量监督检查，提供真实有效的相关质量活动记录、证据，无条件接受项目工作小组提出的质量问题整改要求，承担质量责任及因质量问题导致的进度延迟责任。 项目工作小组 项目工作小组应对项目建设过程提出质量要求、推进质量工作的开展，通过验收、评审、抽查等方式对各方工作情况进行质量监督、检查、确认，并对本方项目相关的工作成果质量负责。 设计工作小组有关可检测的阶段性工作完成后，在报项目工作小组验收和认可前，应先提交项目工作小组进行检查。 对有承接关系的分步工程，项目工作小组应组织相关方进行严格检测和检查，对不符合规定的分步工程不得接收。6.2.3. 质量计划 编制质量计划 设计工作小组在编制完成项目进度计划后，应编制质量计划，对质量控制活动进行安排，质量计划的格式与进度计划格式相同。 质量计划内容应包括：1) 对应进度计划安排质量活动的时间计划，如评审、验收等。2) 明确开展质量活动的机构及人员。3) 确定项目质量控制的关键点与特殊点及管理方法。4) 与质量活动相适应的检验、试验、测量、验证要求及判定准则（标准）。5) 工作程序，描述质量计划各阶段的执行与控制活动内容和工作流程，以及计划所遵循和引用的标准与规范6) 必要的质量控制手段、过程、服务、检验和试验程序。7) 质量记录及质量问题的追踪管理。 审批质量计划 项目负责人组织相关方对设计工作小组提交的“项目质量计划”进行审查，确认质量计划的有效、完整、可行。 审查通过的“质量计划”，项目设计工作小组应严格执行，审查未获通过，设计工作小组应根据审查意见修改“质量计划”。 质量计划的变更控制与进度计划相同。 实施质量计划 设计工作小组必须严格执行质量计划中规定的质量检查活动，并留有质量检查记录； 项目过程中发生质量缺陷或事故时，设计工作小组必须分析原因、分清责任、进行整改，并向项目负责人提交质量分析报告。 设计工作小组应定期组织具有资格的质量检查人员和质量审核员验证质量计划的实施效果，当项目质量控制中存在问题或隐患时，应提出解决措施。 对重复出现不合格的质量问题，设计工作小组应承担质量责任。 根据设计工作小组提交的质量计划，项目工作小组制定相应的质量监督计划，对项目的关键过程及工作成果进行质量检查，填写质量检查审核报告。 原则上在进行进度报告的同时应报告质量情况，包括按周提交质量周报，并在阶段里程碑结束时提交质量审核报告。质量周报格式与进度报告相同，质量审核报告见附录。6.2.4. 质量持续改进 改进方法 项目相关各方应及时分析和评价项目管理现状，识别质量持续改进区域，确定改进目标，实施选定的解决办法。 质量持续改进应按全面质量管理的方法进行。 改进措施 不合格控制应符合下列规定:1) 应按项目质量计划规定的程序严格控制不合格工作转入下道程序。2) 对验证中发现的不合格工作和过程，应按规定进行鉴别、记录、评价、隔离和处置。3) 应进行不合格评审。4) 不合格处置应根据不合格严重程度，按返工、改进或让步接收、降级使用、拒收或报废四种情况进行处理。构成等级质量事故的不合格，应按质量管理制度和合同规定进行处置。5) 对改进或返工后的工作，应按规定重新进行检验和试验，并应保存记录。6) 项目工作小组同意进行不合格让步接收时，设计工作小组应提出书面让步申请，项目工作小组记录不合格程度和返工情况，相关方签字确认让步接收协议和接收标准。7) 检验人员必须按规定保存不合格控制的记录。 纠正措施应符合下列规定：1) 对项目工作小组、监理单位（如果有）提出的质量问题，设计工作小组应分析原因，制定纠正措施。2) 对已发生或潜在的不合格信息，应分析并记录结果。3) 对检查发现的工程质量问题或项目相关报告提及的问题，应由项目工作小组组织有关人员判定不合格程度，责成设计工作小组制定纠正措施并监督执行。4) 对严重不合格或重大质量事故，必须实施纠正措施。5) 实施纠正措施的结果应由项目工作小组组织验证并记录;对严重不合格或等级质量事故的纠正措施和实施效果应验证，并知会相关方。6) 项目工作小组应定期评价纠正措施的有效性。 预防措施应符合下列规定：1) 项目工作小组应不定期组织召开质量分析会，对影响工程质量潜在原因，采取预防措施。2) 对可能出现的不合格，设计工作小组应制定防止再发生的措施并组织实施。3) 对质量通病应采取预防措施。4) 对潜在的严重不合格，应实施预防措施控制程序。5) 项目工作小组应定期评价预防措施的有效性。6.3. 风险管理市项目信息系统是一项复杂的系统工程，实施周期长影响面广，项目实施面临一系列的风险。我公司项目风险管理由4类过程组成： 风险识别：确认哪些风险有可能会影响项目进展，并记录每个风险所具有的特点。 风险对策：评估风险和风险之间的相互作用，以便评定项目可能的产出结果的范围。 风险跟踪：确定对风险的产生后对策进行选择的步骤及对危险作出应对的步骤。 风险控制：对项目进程中风险所产生的变化作出反应。6.3.1. 风险识别目的： 识别哪能些风险可能影响项目进展以及记录具体风险的各方面特征。步骤： 分析本项目特征和项目外部交通；根据以往类似项目上的经验积累，列举对本项目目标实现有重要影响的首要的7到10个项目风险；将项目风险按可能性大小排序，记录为书面的项目风险清单。 输出工作产品：项目风险清单时机与频率：在项目早期完成此项工作任务，在项目的每个阶段开始时，风险识别不是一次性行为，而应有规律地贯穿整个项目中。6.3.2. 风险对策目的： 风险对策涉及到对风险和风险之间相互作用的评估，用这个评估分析项目可能的输出。步骤： 将项目风险清单中列举的风险进行量化按风险发生可能性大小排序，按照下列选择制定风险对策： 避免 排除特定危胁往往靠排除危胁起源。项目管理队伍绝不可能排除所有风险，但特定的风险事件往往是可以排除的。 减缓 减少风险事件的预期资金投入来减低风险发生的概率（如为避免项目产出的产品报废而使用专利技术），以及减少风险事件的风险系数（如买投保），或两者双管齐下。 接受 接受一切后果。这种接受可以是积极的（如制定预防性计划来防备风险事件的发生），也可以是消极的（如某些工程运营超支则接受低于预期的利润）。输出工作产品：项目风险对策清单时机与频率：在项目早期完成此项工作任务，与风险识别一样，风险对策也不是一次性行为，而应有规律地贯穿整个项目中。6.3.3. 项目风险列表 组织风险 对该项目是否有足够的支持（包括管理人员、测试员、QA 和其他外部的相关各方）？ 这是否是该组织尝试过的最大项目？ 软件工程是否有明确定义的流程？需求记录和管理？ 资金风险 完成项目所需的资金是否到位？ 是否为培训和指导分配了资金？ 是否有预算限制使得系统必须以固定的成本交付，否则将被取消？ 成本估算是否准确？ 人员风险 是否可以获得足够的人员？ 他们是否具备合适的技能和经验？ 他们以前是否在一起工作过？ 他们是否相信项目会成功？ 是否可以找到用户代表来担任复审员？ 是否可以找到领域专家？ 时间风险 时间表制定得是否现实？ 是否可以为了满足时间表而对功能进行规模管理？ 对交付日期的要求有多严格？ 是否有时间“把工作做好”？ 业务风险 如果竞争对手抢先将产品推向市场怎么办？ 如果项目资金处于危险境地怎么办（换句话说，“如何确保有足够的资金”）？ 系统的预计价值是否大于预计成本？（务必要考虑货币的时间价值和资金的成本）。 如果无法同关键的供应商签定合同怎么办？ 规模风险 成功是否能够被评测？ 是否有关于如何评测成功的协议？ 需求是否相当稳定并得到了充分的了解？ 项目规模是固定不变还是在不断扩展？ 项目开发的时间范围是否太短、不够灵活？ 技术风险 技术是否已经过证明？ 重复使用目标是否合理？ 工件必须要使用一次后才能被重复使用。 构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。 需求中的事务量是否合理？ 事务比率的估计值是否可靠？这些估计是否过于乐观？ 数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据？ 是否有特殊或苛刻的技术需求（如要求项目团队处理他们不熟悉的问题）？ 成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术？ 对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需的接口或必须创建它们？ 是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障”）？ 系统的用户是否对正在开发的系统类型没有经验？ 应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加？ 是否存在对国家语言支持的需求？ 是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。 外部依赖性风险 该项目是否依赖于其他（平行的）开发项目？ 成功是否依赖于市售产品或外部开发的构件？ 成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下交付项目？6.3.4. 风险跟踪目的： 周期性根据对项目执行状态的判断和项目外部交通的评估，判断已识别风险的发生可能性，并积极采取措施降低风险发生的可能性。 步骤：每周复查项目风险清单；根据对项目执行状态，例如项目的时间进度、人员情绪、关键技术问题的解决等判断风险发生可能性；对于可能发生对项目目标影响重大的风险，上报给项目管理办公室；采取适当措施，例如调整项目计划、缩小项目范围、增加人员等，降低风险发生的可能性。 输出工作产品：风险跟踪表时机与频率：每周执行一次。6.3.5. 风险控制目的：当风险已经成为事实时，采取应对措施将损失降低到最小。 步骤：确认偶然性的风险事件已经发生；估计此风险发生对项目造成的影响；利用项目计划中的缓冲时间、资源，安排风险应对措施；备注：在项目计划中，应考虑一定比例的时间、资源用于应对项目风险的发生；当超出项目计划阶段性预留的缓冲，既对项目里程碑产生影响时，上报项目管理办公室。输出工作产品：风险应对措施时机与频率：在项目执行的整个周期内，风险发生时执行此工作任务。6.4. 问题管理6.4.1. 工作流程6.4.2. 问题收集 在项目建设过程中，项目相关各方均应建立问题收集、记录、跟踪、报告制度，防止问题沉积或不能及时获得解决。 承担解决问题的任何一方，应及时填写问题报告并提交给项目工作小组，说明已解决的问题及未解决的问题，对未解决的问题应说明原因； 项目工作小组、项目工作小组在实施项目过程监督、检查、验收等管理控制活动中发现的问题也应形成书面报告并提交项目工作小组统一对问题进行管理。 项目工作小组负责收集各方提交的问题报告，并整理形成问题跟踪记录。6.4.3. 问题处理 项目工作小组负责组织相关方协调处理项目过程中发现的所有问题，并跟踪问题的解决结果。 对解决项目问题存在争议的，应向项目协调组提交书面报告，由项目协调组进行相关各方的协调决策，一旦协商一致，项目各方应按协调决策意见执行。 经协调组协调无效的，协调组应向项目领导组提交书面报告，由项目领导组进行协商决策，一旦决策，项目各方应按协调决策意见执行。6.4.4. 问题跟踪 项目工作小组负责跟踪问题的处理情况，并有监督问题处理过程的义务； 问题处理完成之后，项目工作小组更新问题跟踪记录，并向各方通报问题关闭结果。7. 需求分析7.1. 功能需求7.1.1. 网站子系统7.1.1.1信息发布系统主要特性一、超强系统模型扩展功能项目CMS是不同于以往的CMS系统，他可以直接在后台通过新建表、自定义字段，然后组成新的系统模型。从而实现各种适合用户自己的系统。如下载系统、音乐系统、商城系统、产品库等等。并且此功能为数据量较大的网站进行数据部署(将信息量分配于不同的信息表)。并且无论是系统内置还是用户自定义的模型，每个模型都有自己的采集。如果会点程序，将能扩展更多更复杂的系统。此功能详细使用可参考使用文档。二、强大的信息采集功能本系统无论是内置的系统模型还是用户自定义的模型都有自己相应的采集。方便用户收集信息。使用简单：无需会任何程序，只需在相应的内容加上相应的标签即可。多重过滤：同一链接可设置不重复采集；设置采集关键字(不包含不采集)；内容字符替换；广告过滤；过滤相似信息；过滤标题相同信息；可设置采集前几条记录。采集区域更准确：整体页面区域正则信息链接区域正则支持页面编码转换：目前支持gb2312、big5、utf-8编码转换效率更高：采用分组采集与入库；支持多线程(节点)采集方便性：采集可选是否马上入库(特别对于挂机采，非常方便)；填写采集正则后可预览采集结果；复制、清空节点；入库可选择“选择式入库”与“全部入库式”；对采集的临时数据进行管理；其他特性：支持多列表采集；支持内容分页采集；支持远程保存图片/FLASH/附件，图片水印，只要定义的字段为img/flash/file均支持远程保存三、完善的会员系统系统可按会员的“会员组”、“有效期(包年/季/月)”、“点数”对会员进行分类。用户可后台增加/修改/删除会员组，会员组可设置会员级别、收藏夹数、每天最大下载数。这些分类均对系统的所有系统模型有效，如查看信息的权限控制、扣除点数；下载/在线观看信息的权限控制、扣除点数、每天下载数限制，可设置重复扣除点数间隔时间；用点数/预付款购买商城模型的商品等等。会员系统其他功能：用户注册、修改资料、购物车、收藏夹、查看状态、在线冲值、查询购买记录、查询下载记录、信息投稿、投稿增加积分后台点卡功能：支持批量添加点卡、可按有效期/点数冲值、批量赠送点数四、万能会员整合接口通过此接口可整合任何相同数据库的系统。配置非常容易，只需配置几个参数即可，并且支持会员组与点数的整合.五、模板全标签化只要会网页编辑软件(如Dreamweaver、Frontpage)即可制作各种出色的模板，只需在显示信息的地方加上相应的标签即可，无需任何程序代码。内置非常灵活的万能调用标签：能实现各式各样的效果，满足各种网站的需要，适应于所有模型。用户可后台直接自定义标签：拥有此功能，用户可以自己写函数，然后后台定义一个标签，模板就能解析他了。一般用于显示系统以外的数据，如：论坛数据、环保监测站中的实时显示数据等等。所有栏目都可以有自己的页面模板/列表模板、内容模板、JS模板与搜索模板公共模板变量：可将一些共用的模块放到公共变量，调用时只需加上变量标签即可，以后修改变量的值即可修改所有显