大型平台技术架构与设计规范_第1页
大型平台技术架构与设计规范_第2页
大型平台技术架构与设计规范_第3页
大型平台技术架构与设计规范_第4页
大型平台技术架构与设计规范_第5页
已阅读5页,还剩144页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

大型平台技术架构与设计规范大型平台技术架构与设计规范/大型平台技术架构与设计规范XX股份有限公司内部门户网站采购项目技术建议书2013年3月

目录1 XX公司简介 11.1 基本情况 11.2 业务范围 11.3 资质和荣誉 11.4 技术实力 21.5 主要客户 32 需求的理解 42.1 系统名称 42.2 建设目标分析 42.3 系统建设原则 52.3.1 兼容开放性原则 52.3.2 先进性和灵活性原则 52.3.3 实用性原则 52.3.4 高效性原则 52.3.5 可扩展性原则 62.3.6 可靠性的原则 62.3.7 安全性原则 62.3.8 经济性原则 62.4 系统需求分析 62.4.1 总体业务架构 62.4.2 业务流程说明 72.4.3 非功能性需求 103 总体架构设计 123.1 设计原则 123.2 体系架构 123.3 逻辑架构 133.4 应用架构 143.4.1 整体功能框架 153.5 数据架构 163.5.1 逻辑数据架构 163.5.2 数据层次划分 173.5.3 数据容量估算 173.6 技术架构 183.6.1 J2EE分层设计 183.6.2 逻辑技术架构 193.7 备份及恢复 193.7.1 备份目标 193.7.2 备份的范围及流程 203.7.3 恢复的范围及流程 203.7.4 备份及恢复的分类 213.7.5 日常备份及恢复的方式 213.7.6 日常备份及恢复的周期 223.8 系统安全 223.8.1 安全需求 223.8.2 安全系统设计原则 233.8.3 系统安全架构 243.8.4 安全策略 254 系统部署说明 304.1 整体部署架构 304.2 网络架构 304.2.1 网络拓扑结构 304.2.2 总体网络需求 314.2.3 网络流量分析 314.3 软硬件配置建议 324.3.1 软件配置建议 324.3.2 硬件配置建议 325 概要设计说明 335.1 网站管理 335.2 栏目管理 335.3 信息采编 345.4 在线调查 365.5 财务速递 365.6 统计分析 365.7 系统管理 376 项目实施方案 386.1 项目实施方法 386.1.1 项目前期准备 386.1.2 业务需求调研 386.1.3 信息调研 396.1.4 系统基础架构规划 396.1.5 应用方案设计 406.1.6 系统开发和实施 406.1.7 变更管理流程 416.1.8 测试和验收 416.2 项目实施计划 426.2.1 实施范围 426.2.2 实施计划 426.2.3 项目各阶段提交文档 436.3 项目资源计划 446.3.1 项目组织架构 446.3.2 项目角色职责 456.3.3 用户方人员要求 456.3.4 项目核心人员简历 466.4 项目管理方案 466.4.1 项目管理思路 476.4.2 项目管理框架 476.4.3 项目管理内容 486.4.4 项目计划及过程控制 696.4.5 软件开发活动管理 756.4.6 项目培训 796.5 项目测试方案 806.5.1 测试目标及需求 806.5.2 约束性条件 806.5.3 测试方法及策略 816.5.4 测试范围 816.5.5 测试资源 816.5.6 测试管理方式 826.5.7 测试交付物 826.5.8 测试及开发的约定 836.5.9 测试风险管理 856.6 项目验收方案 866.6.1 验收目的 866.6.2 验收对象 866.6.3 项目验收的前提条件: 866.6.4 验收方法 876.6.5 验收步骤 876.6.6 验收依据 876.6.7 验收内容 886.6.8 验收结论 886.6.9 项目交接 897 售后服务体系 907.1 售后服务服务目标 907.2 售后服务服务原则 907.3 售后服务方式 907.4 售后服务支持流程 937.5 售后服务内容 938 相关应用案例 958.1 门户网站案例截图 958.2 公司其它成功案例清单 999 相关附件 1009.1 项目开发和管理工具 1009.2 人员简历表 100XX公司简介基本情况XX公司是XX的直属局级单位,XX技术开发中心(对内称:XX软件开发中心)是XX公司全资子公司。XX技术开发中心承担XX主要业务系统、管理信息系统以及总行支付科技司的其他软件项目开发;承担所开发的软件以及XX有关应用软件的测试工作;负责所开发的项目的管理维护和推广工作;承担XX分行等所委托的应用系统的开发;跟踪、研究国外金融电子化技术的最新成果,积极在XX内部推广应用。业务范围XX公司目前主要职责是承担XX软件开发、系统集成、网络建设及运行维护、测试、技术培训、技术支持、信息安全、标准化服务以及组织金融技术暨设备展览、出版发行《金融电子化》杂志、数据备份中心,开展信息化交流和有关宣传。秉承立足人行、服务金融、面向社会的宗旨,经过20年的开拓建设,发展成为集软件开发、系统测试、系统集成、数据中心运营及备份、网络建设、信息安全、技术支持、科技培训、标准化、科技信息交流及金融信息化宣传等服务于一体,技术实力雄厚、信誉度高、管理规范、服务完备的国家金融系统信息化龙头企业。以XX软件开发、金融系统测评、灾难数据中心、中国国际金融展、金融电子化杂志社等多个主营服务平台为依托,服务领域遍及XX、银监会、政府部门、金融机构和财政税务等各个领域。资质和荣誉软件企业认定证书高新技术企业证书国家信息安全测评授权培训机构资质证书国家信息安全测评信息安全服务资质证书ISO9001-2011证书计算机信息系统集成企业(二级)资质证书获得国家高技术产业发展项目专项支持2008年至2009年,获软件著作权共20项荣获了10多项XX科技发展进步奖XX颁发的国家征信系统、央行金融统计监测系统等系统建设全国先进集体技术实力XX技术策略和金融行业技术标准制定的参及者建立具有国际先进水平的金融信息化服务“五个能力体系”:建立了以国际CMMI最高五级标准为基础的软件开发过程管理体系;基于CNAS(国家认可委)标准规范建立了国际化的测试质量保障体系;基本建立以ITIL、ISO2000为标准要求的IT服务管理体系;初步建立以ISO27000为标准的信息安全管理体系;初步形成以美PMBOK标准规范为要求的,符合XX科技特点的项目管理知识体系。系中国承担全国性大型金融信息化项目最多的IT服务提供者。承担XX及金融系统重大信息化建设项目任务,开发建设了中国企业、个人征信系统、国家货币金银管理系统、财税库行横向联网系统、联网核查公民身份信息系统、人民币账户管理系统、金融统计监测系统、国库会计数据集中核算系统、人民币跨境支付信息管理系统等二十多个大型业务应用系统和管理信息系统,荣获了多项XX科技发展进步奖。拥有2万多平方米的现代化大型软件开发基地、上千平方米的国家A级数据机房,设立“XX同城灾备中心”和“中小金融机构灾备外包服务中心”,建有XX网络安全运维中心、面向XX业的技术支持中心,并全面承担着银监会系统运维工作。系国内信息化价值链最完备的综合信息服务商。形成集软件开发、数据备份、系统检测、标准化、网络安全、集成运维等为一体的全方位、多渠道的高端IT服务平台。为200余家金融机构提供了完备、快捷、优质、高效的信息化服务,服务领域遍及XX、银监会、政府部门、金融机构和财政税务等各个领域,赢得了合作伙伴和客户的高度赞誉。主办亚太地区规模最大、规格最高、在国内极具影响力的国际高端展览平台:中国国际金融(XX)技术暨设备展和中国国际金融服务展示展览主要客户XX公司的主要客户涵盖XX总行及各分支行、国有XX、股份制XX、城市商业XX、外资XX、等各类金融机构。通过十多年不懈的努力,XX公司及各个层面的客户建立了紧密的合作关系。国有XX(中国XX、农业XX、工商XX等)股份制XX(中信、光大、华夏、兴业XX等)城市商业XX(南京XX、上海XX、宁波XX等)外资XX(东亚XX、渣打XX、汇丰XX等)需求的理解系统名称本系统的名称为:XX股份有限公司内部门户网站,以下简称门户网站。建设目标分析通过门户网站的建设,实现XX内部各级部门之间办公信息的收集及处理、流动及共享;建立起以工作流引擎为核心的业务流程处理,以公告、论坛、即时通讯和邮件为基础的多渠道信息共享,提供考勤、人事、个人门户、日程安排等个性化的自助式服务,以提高办公效率和提升公司的信息化水平。门户网站建设主要目的是构建门户基础架构,同时能够及已有的应用系统集成,实现原有业务的不间断运行,该网站为XX内部网站,使用者为XX内部员工。内网网站必须满足以下目标:系统能够建设成为单一信息化工作平台,成为XX未来发展的基准Web工作平台,实现统一的信息展现。实现对办公系统、邮件系统以及各业务系统的集成,通过单点登录技术,使系统成为员工工作的门户入口。系统能够建设成为统一的信息整合平台。将XX现有的应用系统、数据资源进行整合,打破信息孤岛,为领导提供决策支持。及时、准确、客观地反映市场变化和主要客户的情况,并为XX提供决策支持,降低决策风险。系统可灵活定制、扩展。要实现网站的各栏目及子栏目的增减,同时栏目的内容也可灵活增减。另外系统可提供通用的接口,可根据业务需要,在未来及某单位新建的业务系统有效集成。业务系统维护实现分布管理,非集中管理。由于系统信息发布内容来自XX多个部门及分支机构,不同部门及分支机构维护各自发布的信息,所以系统应能够实现分布管理,由各个部门及分支机构自己管理各自负责的信息。实现用户的统一管理、权限的统一管理、用户的统一认证。实现统一的信息展现,展现的信息包括集成系统的统一待办事宜、公告信息、数据、图标等。业务系统维护形象直观、操作简便,无需专门的技术人员。由于业务系统信息经常发生变化和变化的信息需要及时发布出去,需让XX员工掌握,所以系统维护必须形象直观、操作简便,无需专门的技术人员。实现针对用户常用功能定制小应用。除上述目标外,该系统从设计方面,应兼顾稳定性、操作性、扩展性、先进性、可维护性、安全性等重要原则,在稳定、安全的基础上可以随着业务的发展逐步扩展。系统建设原则兼容开放性原则能够兼容主流的服务器和操作系统;能兼容现有的办公PC环境。先进性和灵活性原则采用目前主流的先进的技术、方法,满足系统不断增加和调整的业务需求;通过修改流程的相关配置文件实现流程的发布或更新,缩减系统改造周期。实用性原则系统应具有良好的用户界面,操作简单方便。充分考虑录入人员特点,使数据处理工作简单、方便、快捷,业务流程清晰,符合常规业务处理习惯;对于常用的信息查询操作,系统提供灵活多样的查询和统计检索方式,满足不同层次的用户需求。高效性原则系统应保证响应速度,并满足系统在用户量和信息量不断增加的需求。可扩展性原则所选用的系统软硬件平台具有良好的可扩充能力,支持系统规模的扩大和业务范围的扩展,能够满足今后业务发展的需要。在不更改系统整体架构的前提下,方便的支持系统扩充。可靠性的原则系统具备容错能力,并有相关的容灾、数据备份及恢复方案。安全性原则系统必须建立在成熟稳定的硬件环境和应用软件基础上,通过完善的备份恢复策略、安全控制机制、运行管理监控和故障处理手段来保障系统的安全、稳定。经济性原则综合考虑系统的性能、价格、实施和服务,保证系统具有较高的性价比。充分利用各种技术保护投资。系统需求分析总体业务架构依据XX内部门户网站的需求,系统分为网站管理、栏目管理、信息采编、信息审批流程、统计分析、在线调查、专题管理、通讯录、金融动态、财务速递、电子公告以及系统管理以及对外接口等功能。下图为门户网站总体业务架构分析:2-4-1总体业务处理流程图业务流程说明网站管理:超级管理员可以对网站设置进行管理。首页展现:系统预设几种首页框架结构和主题配色方案,由超级管理员选择,应用于所有终端用户的首页显示。超级管理员可以指定在进行信息采编时附件文件的大小、格式。如果及IBMPortal集成,采用虚拟门户技术,可以实现子站点的创建和管理。栏目管理:栏目管理采用分级管理,超级管理员可以进行全站所有栏目增、删、改、授权、排序操作;超级管理员指定各一级栏目的栏目管理员、栏目的业务类别,栏目管理员可以维护本一级栏目下的所有子栏目(增删改、排序),各栏目管理员还可以定义每个栏目的展现风格。栏目内信息发布的权限限制到人员。在进行栏目展现设置时,系统预设几种栏目展现框架结构,由各栏目管理员自主选择自己栏目的展现结构,配色方案自动及首页配色相一致,应用于所有终端用户的显示。信息采编:可进行信息的录入、编辑、发布。由于信息具有多样性的特点,需要在信息采编过程中提供充分的系统支持,方便操作。单篇文档的录入、编辑、预览、修改、删除、撤销发布。批量文档的删除、引用、移动。支持多种格式的文档采集,包括WORD文档、EXCEL表格、PDF文档、HTML页面。可直接在后台选择需要录入的源文档,将源文档导入到系统中;也可以从源文档中直接拷贝段落、文字、表格等部分内容。可视化编辑。实现类似word编辑器功能,支持文字大小、字体、颜色、加粗等、段落的间距、位置等格式修改,支持图片、视频、音频、表格及一些特殊对象的插入,支持各种文档内容、对象的混排,保持所见即所得的编辑效果,可对编辑文档进行预览。、支持文档附件上传、下载,对附件的文件格式可进行控制。由超级管理员指定上传文件大小、格式。除普通类型文档外,还应支持链接类型文档,这种文档具有标题,但具体内容为空,仅指向一个指定链接地址,在发布后的页面上体现为:在点击该类文档标题后,直接跳转至指定链接。可直接将某篇文章置顶、推荐可跟踪单篇文章的点击次数,便于今后统计。设定所发文章的用户访问范围:公开访问;机构部门、角色、个人。针对每篇文章,信息发布人可设置开通评论或者不开通。信息审批流程:审核流程非必选,由用户自己决定。审核采用多级审核,由信息发布人在信息审核人的范围内选定审批人员,接到申请的审核人可以直接审核通过发布,也可以再上报给其他人审批,或者退回让拟稿人重新拟稿。统计分析:可以对不同栏目的文档进行统计,按用户或组织(中心和部门)统计工作量,生成相应的统计图表(饼状图、柱状图等)并支持结果导出。在线调查:调查问卷模块主要包括设计发布问卷、回答问卷、数据统计等功能。该模块同时适用于网络答题和网络投票。主要功能包括:新增问卷、设计问卷、发布问卷、结束问卷、查询问卷、浏览问卷、查看问卷结果、删除问卷、打印问卷、导出问卷。专题管理:包括专题栏目创建、专题内容采编、专题实现模板的可视化设计,允许用户在重大营销活动或其他专项活动时,快速建立一个属于自己的专题,并根据事件的特征设计专题页面的显示布局,以及在布局中添加相应的资源块,在资源块中添加相应的文章和图片等,从而发布到内网上。通讯录:提供通讯录管理以及查询功能,在进行查询时,可以按照姓名、拼音首字母、拼音全拼、部门等方式进行查询,查询结果包括:姓名、部门、单位电话、手机、邮箱等内容。金融动态:由办公室人员从各种信息渠道采集、加工的每日财经资讯和金融市场讯息。为员工提供金融行业的形势分析及热点、看点信息。此栏目可以通过栏目管理创建。财务速递:主要以图表的方式展现全行财务信息,包括:个人存款余额、对公存款余额及增长率、比年初、比上月、比上日的汇总情况,点击可查看其详细情况,按照部门、分行、支行进行排序并统计。电子公告:电子公告管理模块提供给公告管理员用于发布公告。在公告发布范围内的用户可以查看公告。还可以及OA等其它系统集成,显示相关系统的公告信息。系统管理系统管理提供给管理员使用,设置有机构及部门管理、用户管理、角色管理、参数设置、栏目管理、日志管理、数据字典管理等功能。综上,通过对门户网站主要业务处理的分析及归纳,提取共性需求,引入架构管控的思路,搭建门户网站;通过配置方式实现通用需求,从而让门户网站随需而变和可持续发展,达到降低成本、缩短开发周期和提高软件质量的目的;并辅以通讯录、财务速递、电子公告等公共服务应用,将员工的日常事务、管理及业务活动等有机地结合起来;通过底层基础框架,构建统一的综合办公桌面,实现统一的工作平台。非功能性需求系统性能要求系统的查询子系统针对单一条精确查询数据时间应小于2秒,支持100个用户同时查询同一信息;数据记录数大于1万时,信息检索时间应小于3秒。系统初期能够支持100人的并发访问,在将来能够扩展到支持500人的并发访问。数据存储期系统数据联机存储5年,超过5年的采用脱机存储。系统容量要求数据空间的需求按照每人年1G计算能满足未来5年的数据需求。系统冗余要求系统应提供备份支持。系统备份和恢复要求系统应提供数据备份及恢复方案。系统应能在灾难发生时,在24小时内恢复。信息安全要求系统应根据《XX信息系统信息安全等级保护标准规范》三级要求进行建设。界面设计要求系统页面应简洁美观;功能操作简便且衔接自然;各子系统风格色调一致。用户帮助要求用户登录系统后,系统应能给出关于系统的有关帮助说明。系统交付后,提供详细的用户手册。兼容性要求系统应兼容XX现有办公电脑和软件环境。总体架构设计设计原则总体架构在着重考虑实施要求的同时,需要为后续阶段进行规划,以保证项目最终能够达到目标架构的设计;总体架构设计架构时充分考虑及现有系统或网络基础设施的兼容,充分利用已有成果,避免重复开发和建设。总体架构设计过程中应遵守相关的IT管理规程,保证最终的系统可以顺利的部署并移交给运行维护部门。体系架构图3-2系统体系架构采用业界最为流行的SOA(面向服务的架构)框架,遵循统一技术路线,架构设计注重层间的松耦合及层内的高内聚,通过对业务的抽象、映射实现业务对象组件化和统一的服务调用,充分考虑了系统的可扩展性、可复用性、可配置性,降低开发和维护成本使得系统能够随需而变,快速灵活满足业务变化的需要。逻辑架构根据对业务需求的整体分析及梳理,XX内部门户网站系统的整体逻辑架构采用纵向分层方式分为数据层、服务层、应用层和用户层。如下图所示:图3-3系统逻辑架构图应用架构图3-4应用架构系统的应用架构可以划分为三个层次,分别是组件层、服务层及应用层,其中组件层是系统业务对象的组件化抽象和最低粒度的组装,服务是对相关业务组件的集成及更高粒度的封装,服务面向具体的业务应用;提供标准的调用接口供具体的业务应用直接调用;应用层包括了本系统业务及管理层面需要实现的具体应用。整体功能框架图3-4-1整体功能框架系统整体功能包括7大模块,分别是网站管理、栏目管理、信息采编、在线调查、财务速递、统计分析、系统管理。数据架构逻辑数据架构图3-5-1逻辑数据架构系统逻辑数据架构是对系统业务对象的逻辑分类,本系统涉及的逻辑数据对象包括业务数据、字典数据、管理类数据、定义类数据。数据层次划分图3-5-2数据层次系统的数据层次可以划分为数据源层、缓冲层、基础层、应用层。数据源层是系统的原始数据,包括字典数据、管理类数据和定义类数据;缓冲层做为对数据库数据处理的有效补充,减少对数据库的直接操作请求,负责对字典数据、部分管理类数据和部分定义类数据进行内存的缓存存储,依据各个子系统的性能和业务的综合考虑来确定是否需要将数据库数据缓存到缓存层中;缓存层的数据在对应来源数据变更时实时更新。基础数据层保留所有提交的历史业务数据,包括表单数据和流程流转的实例数据。应用层为面向各功能模块提供统一的接口视图。数据容量估算按照数据空间的需求为0.2G每人年,且系统要满足未来5年的需求1年数据按1000用户计算为200G5年后=200G*5=1T技术架构J2EE分层设计图3-6-1架构分层设计图本系统软件架构设计采用松耦合、分层设计的原则,主要分为UI(UserInterface)层、服务层、业务处理层、数据访问层。UI层指用户界面,是用户访问本系统的入口。UI层主要采用JSF/Flex框架来实现。服务层是本系统提供对外业务服务的功能。该层将服务接口和实现分离,实现松耦合。同时,服务层主要采用IService接口来实现。业务处理层是指公共业务处理组件,主要用来处理服务层所共有的业务处理规则、流程等内容。业务处理层采用普通的Java对象来实现。数据访问层是指提供对数据库数据访问的接口,被业务处理层或服务层直接调用。数据访问层主要通过系统技术平台的SQLExecutor和Mybatis来实现。公共组件指按照规范统一实现的公共组件,包括用户管理、组织机构管理、权限管理、日志管理等模块。事务处理指事务的处理机制,事务开始于服务层,采用数据库的事务管理器对服务层的相关服务进行事务控制处理。逻辑技术架构图3-6-2逻辑技术架构设计图系统逻辑技术架构包括四个层次:分别是用户层、访问控制层、应用服务层和数据存储层。访问控制层包括了网络的物理隔离设备及Web服务器,是系统访问和请求转发的第一层。应用服务层是业务处理中心,负责对用户提交的操作请求进行业务处理。数据存储层包括共享存储设备、数据库和相应的数据备份设备。备份及恢复备份目标备份及恢复的目标在于:保证对数据的及时有效恢复。最低程度地降低数据丢失。尽量提高数据备份过程的效率。备份的范围及流程备份的范围按备份的内容分,备份的范围主要包括:应用程序及配置系统元数据业务数据按备份的系统分,备份的范围主要包括:数据库Web服务器应用服务器备份的流程备份通常在备份策略制定后,对备份系统和工具进行配置,由工具定期自动完成,只是在特定情况下(系统升级、迁移等)由手工完成。应定期检查备份日志,以确保备份按照预定设置正确完成。备份管理的流程如下图所示:恢复的范围及流程(一)恢复的范围恢复的范围主要包括:对给定时间点能对系统数据库进行完整的数据恢复将Web服务器恢复到最新状态将应用服务器恢复到最新状态。(二)恢复的流程恢复工作并不是日常进行,而是在故障和灾难发生时进行。因此,应持续监视系统情况,选择恢复时机。恢复的执行通常由人工干预完成,完成后应形成日志记录存档待查。恢复管理的流程如下图所示:备份及恢复的分类备份任务按内容分类包括:对应用程序和配置的备份。对数据的备份,既可以分别备份不同的内容,又可以同时备份所有的内容。在各种备份的内容中,操作系统和应用程序及配置发生变化的频率很低,数据变化的频率很高,因此建议对不同的内容分开备份,这样可以减少备份的时间,方便恢复操作。备份任务按工作进行的周期分类包括:日常备份硬件升级更换的备份增加节点的备份用户定制备份等在各种周期的备份中,日常备份最为重要。在各种备份的内容中,数据是核心内容。因此,备份策略的核心是日常数据备份。日常备份及恢复的方式日常数据备份的方式通常可分为增量备份、全备份和完全备份。增量备份增量备份是指对所选定的对象,在前一次备份的基础上只对变化的部分进行备份,恢复时则需要一个全备份和此后的每次的增量备份才能对所选定的对象进行恢复。全备份全备份是指对所选定对象进行完整备份。恢复时,仅依靠这一个备份就能对所选定的对象进行恢复。通常,这里说的全备份意味着不是对整个系统,而是对系统中特定的一部分对象进行备份。完全备份完全备份是指对一个系统中的所有对象进行完整备份。恢复时,仅依靠这一个备份就可以整个系统或系统中的指定的对象进行恢复。异地备份将数据在异地产生一份可用的副本,灾难发生时,能在24小时内异地恢复系统。在本系统中,通常采用增量备份、全备份、异地备份相结合的方式进行备份,并对数据进行异地备份处理。日常备份及恢复的周期业务数据每天进行全备份。对于应用程序及配置的备份,建议在有变动时每月做一次全备份,在没有变动时无需备份,这样当操作系统或程序被损坏时,能够将操作系统或程序恢复到最新状态。在灾难发生时,使用异地备份进行恢复,确保系统运行。系统安全安全需求门户网站的安全管理应坚持安全及效率平衡的原则,方便操作、便于管理。系统存储和处理的信息重要而敏感,系统应在网络、数据、系统访问等方面提供充分的安全保障,建立多层次的安全保障体系,包括授权/认证机制、存取权限及执行控制、口令保护机制等多种安全保障机制,作好系统内权限分级管理,提供从数据库、文件集合、单个文件等不同的安全保证。1.用户认证用户登录门户网站时,系统对用户登录机器账号、密码信息进行验证,验证通过后方可允许系统用户登录系统。2.数据安全门户网站数据存储安全的目标是保证数据存放时的可靠性、完整性、保密性。为此,系统应采取以下措施:(1)业务数据无论是数据库或者文件形式保存的,均应采取完备的用户权限策略避免非法访问。(2)系统应保证数据存储的高度可靠性,应采用高可靠服务器来存储数据,防止数据损坏和丢失。(3)应采用可靠技术手段保证后台数据的安全性,确保非系统用户无法访问到系统后台数据。(4)系统应提供完整和方便的数据备份策略,保证数据损坏时及时恢复。系统数据备份策略应支持以磁盘介质方式备份指定工作日的业务数据和日志,并提供自动备份功能。备份数据应以加密形式存储。3.运维安全应用系统设计应支持服务器故障备份及切换等冗余技术。各节点不应具有故障单点,具有足够的设备容错能力,可用性指标应大于99.9%。当正在运行的系统出现故障,备份系统可接替故障设备并恢复正常的业务处理。若系统发生灾难时,应能在24小时内在异地恢复系统。安全系统设计原则最小影响安全方案的建设应当尽可能小地影响系统和网络的正常运行,不能对网络和业务运行产生显著影响,特别是不能造成业务系统性能明显下降、网络拥塞、服务中断、目标系统数据的破坏和泄露等问题。整体性系统安全方案所涉及的范围和内容应当尽可能地整体、全面,应当包括安全涉及的各个层面,避免由于遗漏而造成未来的安全隐患。标准性和规范性安全方案的设计和具体实施应当依据国内和国外的相关标准、规范以及理论模型,避免杂乱无章、无序建设。先进性安全方案的设计起点要高,应当采用成熟、先进、高效的软硬件平台和技术,保证安全系统具有长久的生命力。易用性系统的安全措施最终要由人来完成,如果安全措施过于复杂,对操作人员的技术要求过高,反而可能造成安全隐患,因此易用性也是非常重要的一个原则。系统安全架构通过对安全需求的分析,保障系统安全需要从应用和信息安全、基础架构安全以及整体安全管理三个层面出发,系统安全架构示意图如下:图3-8-3系统安全架构信息及应用安全是系统安全保障的核心,直接保障系统信息的可靠性、完整性、机密性、抗抵赖性和真实性以及应用系统自身安全,主要由应用系统自身或及应用系统耦合性较强的专用安全系统或安全技术来实现。基础架构安全是保障系统所运行的系统环境、网络和客户端的安全,起到为系统提供运行环境保障的辅助安全作用,主要由及应用系统没有关系的通用安全系统或通用安全技术实现。基础架构的安全是信息及应用安全的基础。安全管理为信息及应用安全、基础架构安全提供安全配置指导,并提供严格、规范的安全管理体系,以形成系统正式运行后的安全管理规章制度,主要由各种安全规范、安全规章制度等组成。安全策略信息数据安全策略数据存储安全所有的数据和文件的操作必须是使用经过授权的系统功能进行操作,否则不能进行访问。数据存储可靠系统应保证数据存储的高度可靠性,应采用高可靠服务器来存储数据,防止数据损坏和丢失。采用专门的备份服务器对数据进行备份,既实现增量备份,也实现全备份。SSL传输安全Web服务器端可以启动SSL传输配置,如有必要,可以要求客户端连接时使用SSL协议。应用安全策略身份认证系统采用有效账号、密码方式确保登录用户的合法性用户第一次登录系统时必须修改系统已赋予的初始密码,否则不予登录系统应通过设置密码有效期(可配置)强制用户对密码进行定期更改连续失败登录多次后应锁定账号。连续失败登陆次数可配置用户密码要求加密后存储,加密算法可应采用MD5用户登录时,输入的密码加密后传输。图3-8-4-2-1认证过程访问控制系统设计一套具有较强可扩展性的权限管理,需要建立用户、角色和权限等数据库表,并且建立相互之间的关系,具体实现如下:说明:用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户要拥有对某种资源的权限,必须通过角色去关联。角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限权限指用户根据角色获得对程序某些功能和数据的操作,例如对某个模块的操作、或者对某个模块中某时间、机构数据的查询、修改和删除功能。3-8-4-2-2访问控制图说明:用户登录时,首先验证是否为合法用户,只有合法用户才允许访问系统;验证通过后,从用户权限表获取用户的功能权限,进入相应的功能模块,在功能模块中再判断用户的数据权限,如读/写数据权限,查看某个时间段数据权限等等。为方便用户设置数据权限,数据权限采用和功能权限一致的控制方式,即权限分配到用户组(即角色)。一般情况下可通过功能权限控制用户对功能模块的访问。服务器端证书可以使用服务器端数字证书方式,实现对来源方的认证。系统审计跟踪系统实时记录用户操作日志,建立完备的审计跟踪机制,便于日常管理、故障处理和事后稽查。用户涉及到对信息数据的操作均要记录审计日志,审计日志记录的需求如下:1. 系统重要操作(如更改口令等)必须自动记入审计日志,审计日志应统一纳入业务数据保存期限管理;2. 对于系统运行过程和异常情况,必须自动记录审计日志;3. 对系统功能操作记录操作时间、操作人所在IP、操作内容等;4.对任务动作操作记录发起人、发起时间、中间经办人、经办时间、任务状态。运行监测使用运维监控系统提供的重要业务处理状态的监测功能,用户可以查看业务的当前处理状态,以便可以及时发现异常业务,并进行相应的处理。信息过滤只处理约定格式的文件,拒绝处理规定格式之外的任何文件和信息,以杜绝某些节点产生的信息垃圾或不良行为,对这些信息不做任何处理和响应。在程序中应检查通过人机接口输入或通过通信接口接收的数据格式或长度是否符合系统设定要求,防止恶意攻击,过滤数据中的危险代码。备份及恢复提供专用备份服务器,提供自动备份调度程序,按照备份策略自动备份到备份机磁盘介质上,备份策略如下:类型备份内容备份频度备份类型保留时间备份周期数据库服务器数据库系统主要配置文件和参数三个月全备份三个月每季度最后一天22:00数据库中的所有数据日全备份一个月每日22:00数据库归档日志日增量一个月每日22:00应用服务器应用系统半年全备份半年每半年最后一天22:00应用日志月全备份一个月每月最后一天22:00非结构化文件周全备份近两周每周最后一天22:00系统提供异地备份支持,备份介质场外存放,每天定时将备份数据传送到备份场地。有相应的经过完整测试和演练的灾难恢复预案。提供详细的系统恢复手册,手册包括:恢复内容清单;恢复操作步骤。运维安全应用系统设计支持服务器备份等冗余技术。各节点不应具有故障单点,具有足够的设备容错能力,可用性指标应大于99.9%。当正在运行的系统出现故障,备份系统可接替故障设备并恢复正常的业务处理。系统部署说明整体部署架构图4-1整体部署架构说明:系统包含2台服务器,一台为主服务器,另一台是服务器备机。用户访问主服务器进行相应的业务操作及管理主服务器及主服务器备机之间互为备份每台服务器上均部署web服务器,应用服务器,数据库服务器备份的数据通过局域网传输到备份机上网络架构网络拓扑结构内部门户网站在XX局域网内,及其他网络隔离。用户只可通过局域网访问系统。总体网络结构如下图:图4-2-1网络拓扑图总体网络需求系统部署在现有的局域网内。网络流量分析通过对数据流向的分析,系统中用户的网络流量分析过程和网络带宽要求如以下:计算公式:估算网络流量=用户的上传/下载附件产生的流量=1000(1000用户)*5(5个文档)*2048KB(每个文档含2M的附件)*80%(80%的业务)/(1.6小时*60*60)=(100*5*2048*0.8)/(1.6*60*60)=1422KB/s=11376Kbps实际网络流量=网络流量/(1-20%)=11376Kbps/0.8=14220Kbps软硬件配置建议软件配置建议系统软件配置建议序号软件类别软件功能产品推荐是否需采购备注1数据库软件管理和存储数据OracleG11不需要2应用服务器支持应用包运行Tomcat7.0.34或WebLogic不需要3Web服务器支持请求分发ApacheHttpServer2.4.3不需要4操作系统基础环境Windows2003不需要硬件配置建议硬件配置建议序号产品名称及产品型号及标准配置描述数量1主服务器4个CPU;16G内存,1T硬盘,2个千兆网口。12主服务器备份机及主服务器配置相当即可。1总计概要设计说明如下部分是对总体设计中比较关键的技术专题进行概要设计说明。图5整体功能框架系统整体功能包括7大模块,分别是网站管理、栏目管理、信息采编、在线调查、财务速递、统计分析、系统管理。网站管理超级管理员可以对网站设置进行管理。首页展现:系统预设几种首页框架结构和主题配色方案,由超级管理员选择,应用于所有终端用户的首页显示。超级管理员可以指定在进行信息采编时附件文件的大小、格式。栏目管理栏目指用于信息发布并可在前台网站子系统展示的栏目。超级管理员可在栏目管理模块中操作所有的栏目,部门管理员可在栏目管理模块中操作本处室所负责的栏目。选择添加新栏目导航,系统展示页面如下图所示:信息采编信息采编模块提供对文章的管理功能。可以编辑文章类信息和下载类信息。下图为信息采编管理主界面。信息采编的主要功能包括:单篇文档的录入、编辑、预览、修改、删除、撤销发布。批量文档的删除、引用、移动。支持多种格式的文档采集,包括WORD文档、EXCEL表格、PDF文档、HTML页面。可直接在后台选择需要录入的源文档,将源文档导入到系统中;也可以从源文档中直接拷贝段落、文字、表格等部分内容。可视化编辑。实现类似word编辑器功能,支持文字大小、字体、颜色、加粗等、段落的间距、位置等格式修改,支持图片、视频、音频、表格及一些特殊对象的插入,支持各种文档内容、对象的混排,保持所见即所得的编辑效果,可对编辑文档进行预览。、支持文档附件上传、下载,对附件的文件格式可进行控制。由超级管理员指定上传文件大小、格式。除普通类型文档外,还支持链接类型文档,这种文档具有标题,但具体内容为空,仅指向一个指定链接地址,在发布后的页面上体现为:在点击该类文档标题后,直接跳转至指定链接。可直接将某篇文章置顶、推荐可跟踪单篇文章的点击次数,便于今后统计。在线调查提供给调查发布人和调查参及人使用,调查问卷业务主要包括设计发布问卷、回答问卷、数据统计等功能,且适用于网络答题和网络投票。主要功能包括:新增问卷、设计问卷、发布问卷、结束问卷、查询问卷、浏览问卷、查看问卷结果、删除问卷、打印问卷。具体说明如下:编辑问卷——调查发布人设计问卷,设计问卷主题、发布范围、结束时间、题型、题目等内容。发布问卷——调查发布人可将编辑好的问卷发布,问卷发布后,调查参及人即可参及调查,回答问卷。结束问卷——调查发布人可以结束某个问卷,让该调查不可再被回答。当问卷设计的结束时间到达时,问卷也将自动被结束。查询问卷——调查发布人可按结束时间或问卷主题模糊查询问卷。查看问卷——调查发布人可以查看问卷调查的详细统计结果,可以选择通过图形(饼形、柱形等)或数据查看问卷的每一项统计结果(包括主观题的汇总)。回答问卷——调查参及人可以根据题目提交答案。回答问卷的过程中可以进行重置答案的操作。财务速递以图表的方式展现全行财务信息,包括:个人存款余额、对公存款余额及增长率、比年初、比上月、比上日的汇总情况,点击可查看其详细情况,按照部门、分行、支行进行排序并统计。统计分析可以对不同栏目的文档进行统计,按用户或组织(中心和部门)统计工作量,生成相应的统计图表(饼状图、柱状图等)并支持结果导出。系统管理系统管理员可使用系统管理子系统系统管理主要包括以下部分,部门管理、用户管理、角色管理、栏目管理、数据字典、部门属性维护。其中,超级系统管理员可以操作系统管理的所有模块;机构管理员可以操作部门管理、用户管理、角色管理;部门管理员可以操作用户管理、角色管理、栏目管理、部门属性维护。项目实施方案项目实施方法项目前期准备在前期阶段,项目的决策者和参及者需要明确项目的目标、确定整个项目的工作范围、作初步的项目计划和风险分析,确定项目组的组织结构。这是项目的起始阶段,为以后的工作做好铺垫。包括的工作主要有:–项目启动会议–确认项目范围和主要目标–确认项目阶段性验收及总体验收标准–确认项目实施计划–确定各项目小组的成员及各自的工作职责–确定各项目小组的阶段性工作目标业务需求调研针对业务用户,通过对这些用户的调研,确定各种类型用户对系统的业务分析需求,达成对系统的目标和范围的一致理解,并提供未来基于系统管理应用的建设蓝图和规划。在业务需求发现阶段,主要完成以下工作:客户访谈:定义业务需求访谈模板,访谈客户业务部门高层,了解客户的业务策略、现状、方向、管理模式等。客户交流:及客户有关方面的业务人员进行充分细致的交流,通过对业务流程、数据、组织结构和环境等各方面的了解,进行客户需求的整理。确定各个业务系统的讲解人,由讲解人填写介绍文档。双方讨论确定讲解时间、地点和参及人员,并根据确定的计划进行源业务系统介绍。确定需求范围和优先级:该工作需要确定项目需求范围内的多方面的内容,包括解决各个业务需求、问题的可能性,需求实现的可能性、现状和未来发展之间的差距、各项需求的优先次序、重要的数据分类。在给客户的提交件中包含项目定义、环境评估、业务定义、方案选择和业务原因、建议方案等内容。业务需求发现阶段重要的因数包括:找出业务机会、衡量尺度和可能的问题将解决方案很好地及业务目标相联系业务人员和技术人员的有力协作通过学习和培训不断提高信息调研在了解业务需求的基础上,对IT基础设计、网络、相关系统及数据来源和使用对象和使用的业务价值进行深入的调查,进而进行业务需求的功能分析和定义,确定系统的功能和规模。为确保本项目后续阶段和服务的实施以及最终项目目标的实现,业务需求的功能规格说明在本项服务结束时应得到客户的最终书面确认。系统基础架构规划在进行业务需求发现的同时,IT人员可以同步进行系统基础架构规划工作,由于在系统建议方案中需要应用新技术和独特的体系结构,对基础架构规划是非常重要的。这一阶段的目的是规划IT基础架构,保证在分步实施系统的过程中,不至变动整体架构。同时,通过对现阶段IT架构和能力的分析,提出分步实施的IT方案。该阶段的工作可以保证按照客户的预期,根据客户的发展、需要和资金情况,保证长期项目的顺利实现。进行系统基础架构规划,需要收集包括技术标准、现阶段IT架构、应用情况、组织结构等方面的客户信息。通过及未来的架构进行对比,确定技术、网络和技能等方面存在的差距,作为规划系统建设和相关支持工作的基本依据。由XX公司负责对项目进行整体体系架构设计。并对系统进行科学的容量规划,提供整个系统在较长时期内的数据管理、良性扩展、系统安全和运维管理,保证对管理信息应用的支持能力。依据客户确认完成的《业务需求说明书》,进行系统设计及整合等细化规划。完成系统总体设计工作,包括系统对外接口进行规划和设计。设计系统中数据采集、数据处理、前端应用等几个模块之间的逻辑关系。设计系统的运行维护策略,确保系统的安全性和可靠性。应用方案设计项目建设需要考虑以后的发展规划,该阶段的工作对于客户进行评估决策相当重要。在方案概要阶段已经初步确定项目的方案和范围,在此之上,通过应用方案设计,将方案的实施策略进一步落实,作为以后分步实施的基础。在此阶段将分析客户现阶段业务功能、业务流程、IT情况等各个方面,制定相应的系统实施方案,包括软硬件配置部署、测试方案、培训和系统配置策略,推广策略等等。这些工作为准确评估项目提供重要依据。系统开发和实施此项服务将基于上一阶段的成果(各种说明书和设计文档),进行全面开发和实施工作,并完成单元测试。主要工作内容:物理数据库开发和实施栏目管理开发和实施信息采编开发和实施在线调查开发和实施财务速递开发和实施统计分析开发和实施OA集成开发和实施邮件集成开发和实施准备开发和测试用数据计划和执行单元测试变更管理流程图6-1-7变更管理流程根据项目实际特点,由用户方项目负责人及实施方项目相关人员共同成立“需求管理组”负责对项目需求跟踪、管理、评审和审批。原则上在本项目中发生的所有需求变更必需得到“需求管理组”的评审及审批才能落实到实施层面。在本项目中用户方项目负责人是需求变更的发起提交的唯一出口,变更发起方发起变更后提交给需求管理组进行评审及复核,需求管理组审批通过后再转交给项目组实施团队测试和验收本阶段将进行系统集成测试、用户测试和验收,系统上线运行、对相关用户进行培训,将整个系统移交给客户。主要工作内容:进行集成测试(功能及流程)进行系统测试(非功能性测试)进行用户测试和验收部署生产系统系统培训项目实施计划实施范围构建门户基础架构,同时及OA系统、邮件系统集成。实施计划项目从需求分析到整体上线,大致需要3个月。其中,需求分析10个工作日;设备加电、安装及部署需5个工作日;参数调整及定制开发50个工作日;软硬件集成、单元测试15个工作日。项目实施进度表:实施阶段开始时间结束时间系统分析设计T0T0+10软件开发建设T0+11T0+60安装部署T0+61T0+65集成测试T0+66T0+80系统培训T0+81T0+82试运行2013-06-012013-06-30注:T0为项目开始日期总体看,项目任务重、时间紧、工期短,我们认为通过设置阶段性的任务及目标,通过迭代开发,使得系统建设能够渐进明细。同时我们认为项目顺利的实施有赖于双方良好的沟通和紧密的配合,有赖于双方领导的大力支持,也有赖于一些客观条件,如软硬件的采购、设备及软件的按时到位、及时安装、开发环境及场地准备情况。图6-2-2实施计划项目各阶段提交文档项目阶段提交件项目启动《项目开发计划》《变更控制计划》《软件验收计划》需求分析《需求分析说明书》《项目配置管理方案》总体设计《总体架构设计》概要设计《系统概要设计说明书》《数据库设计说明书》《设计和开发规范》详细设计《系统详细设计说明书》编码及单元测试《系统集成测试计划》集成测试《集成测试报告》《用户操作手册》《系统源码》业务测试《业务测试报告》《系统上线方案》《系统安装维护手册》《系统管理员手册》《培训教材》上线试运行《系统试运行报告》《系统验收报告》项目资源计划项目组织架构图6-3-1项目组织架构项目角色职责编号团队名称主要任务G01项目领导小组检查项目进度、风险,协调资源G02项目经理负责项目管理的具体执行,制定具体的项目时间计划和实施计划,管理项目里程碑,管理项目资源。负责向项目领导小组汇报项目进展。G03顾问专家团队对项目的执行方向、策略等提供指导。G04业务需求团队信息及业务调研业务对象分析逻辑模块设计数据映射设计G05平台开发团队总体体系结构设计概要、详细设计容量规划开发测试(UT)G06应用开发团队栏目管理开发和实施信息采编开发和实施在线调查开发和实施财务速递开发和实施统计分析开发和实施OA集成开发和实施邮件集成开发和实施G07测试团队测试计划及组织测试用例设计集成测试执行系统测试执行用户接收测试用户方人员要求项目管理人员要求需要用户方项目分管领导参及项目指导小组的工作,并指定专职的项目经理进入项目实施工作,负责各种会议、演示、汇报等沟通工作的开展,对项目需求分析、需求确认、各种交付物的组织验收,共同对项目的实施过程进行控制和跟踪。参及人员的要求人员职责要求备注项目经理需要指定全职项目经理参及到项目管理当中专职人员1名科技人员负责配合实施方完成信息调研,熟悉内部IT建设,能够解决实施现场出现的技术问题专职人员1名系统维护管理员要求具有系统管理的经验,负责整个系统的管理及移交后的运行维护非专职技术人员1名测试人员了解本系统建设的业务及IT要求,有一定的系统测试技能非专职技术人员2-3名阶段性参加业务人员系统未来的使用人员,对业务规则和业务流程非常熟悉,了解业务流程,能够完成用户接受测试(UAT)工作。业务部门的业务人员2-4名项目核心人员简历详见《附件9.2人员简历表》。项目管理方案如何利用好项目中各个资源,协调和各个组织机构的关系,顺利完成项目任务,需要一套项目管理方案来指导和管理本项目的建设。项目管理方案,一方面需要参考和借鉴国内外先进、科学的项目管理理念,制定本项目相应的项目管理制度、管理规范,另一方面借鉴用户方的项目管理经验和我公司多年积累的项目管理方法论来指导本项目的实施管理,确保本项目健康实施、少走弯路,降低风险、节省成本,在规定的时间内完成项目建设任务。我公司依据ISO/CMMI4质量控制体系、以及项目管理知识体系(PMBOK),利用我公司多年在综合管理、范围管理、需求管理、进度管理、沟通管理、项目文档管理、项目团队管理、风险管理和质量管理等项目管理领域以及项目管理工具等方面积累的经验,提出本项目实施时采用的项目管理方法和措施。项目管理思路本项目的成功实施不光依靠先进、成熟的信息技术,强有力的领导支持和经验丰富的开发实施团队,更需要一套质量控制和项目管理方法,我们公司在本项目中的项目管理指导思路是:1.服从业主对本项目建设的统一项目管理和协调;2.本项目管理规范符合XX的相关管理规范;3.组建稳定、有力的项目执行组织;4.充分重视项目工程中可能遇到的问题,合理规避项目风险;5.在项目实施过程中强化项目工程质量保证。项目管理框架我公司项目管理以ISO/CMMI质量控制体系、项目管理知识体系(PMBOK)、以及软件工程项目管理规范为指导,利用我公司多年综合管理、范围管理、需求管理、进度管理、沟通管理、项目文档管理、项目团队管理、风险管理和质量管理等项目管理领域积累的经验,以XX公司项目管理工具为基础,结合其他项目工具,以成熟稳定的项目组织团队作保障,结合项目开发特点对整个项目过程进行管理。如下图:图6-4-2项目管理框架如图的项目管理框架,以XX的项目管理相关标准为指导,基于成熟的项目管理工具,进行综合的项目管理,包括计划制定、关键路径分析、计划实施、变更控制、配置管理等,并从组织上给以有力保障。项目管理内容根据本项目的要求和我公司多年实施应用系统开发项目的质量控制和项目管理经验,总结出了如下项目管理内容。项目进度管理在门户网站项目开发管理中实施以下的项目进度管理方案,并结合项目进度及时向用户报审项目文档。项目进度跟踪在项目的实施过程中,还要对项目的实施情况进行跟踪,确保项目的实施符合计划的要求。跟踪的方法可分为正式跟踪和非正式跟踪。正规跟踪就是通过定期召开项目进展情况汇报会、提交项目阶段进度报告等,使项目利益相关者了解项目的执行情况。根据进展报告,及会者讨论项目遇到的问题,分析并找出问题的原因,研究和确定应对方案和预防措施,为控制项目提供依据。我们将在工程建设期间于每周终了日内,以合理的、用户可以理解的方式,向用户提供书面的项目阶段进度报告。内容包括但不限于:项目进度及计划执行、已完成的工作内容、有无遇到的困难和障碍、本项目的预期效果、人员配置、有无项目变更及/或变更情况、或其它及本项目有关的用户应该知道的情况或用户要求知道的情况。如有重大的问题或重要的变更发生,我们将在当日内向用户做出书面报告;也保证在合理的时间内回复用户在其它时间内提出的及本项目相关的询问。项目任务进度的度量:首先把每项工作分解到工期在一周以内,每周末进行进度评估,我们采取工时提交原则,即提交工作任务的完成工时。项目进度跟踪的工具可以使用MSPROJECT。项目进度信息采集的方式:项目周报、项目例会、阶段性评审。1.项目周报:就是项目实施小组每周向项目经理提交每周的工作汇报,包括存在问题。2.项目例会:就是项目组定期举行工作会议,分析项目状态,落实下一步工作,其中包括对现有的问题进行讨论并解决。3.阶段性评审:就是在项目的阶段最后,召开项目小组相关成员等人员对项目的阶段工作进行评审,评审内容包括项目进度、交付物的质量、阶段里程碑、项目中的重大问题、项目风险等。项目进度分析项目进度的分析是对项目当前执行进度及计划编制进度的比对。可以进行偏差分析,对项目费用支出、项目WBS任务分解工作完成情况、项目人员投入情况等几个方面比较,从而得出项目执行状态是否正常。项目费用分析方面,通常基于在项目管理中常用的“挣值法”。挣值法实际上是一种分析目标实施及目标期望之间差异的方法,故又常被称为偏差分析法。挣值法通过测量和已完成的工作的预算费用及已完成工作的实际费用和计划工作的预算费用得到有关计划实施的进度和费用偏差,而达到判断项目预算和进度计划执行情况的目的。项目进度控制项目进度计划只是根据预测而对未来做出的安排,由于在编制计划时预测会有偏差,在计划执行过程中可能会发生或大或小的偏差,这就要求项目经理及其他管理人员对计划做出调整,减少及计划不符的偏差,以使预定目标按时和在预算范围内得以实现。项目进度计划的控制就是要经常对每项工作进度进行监督,然后,对那些出现“偏差”的工作采取必要措施,以保证项目按照原定计划进度执行,使预定目标按时和在预算范围内实现。项目进度计划本项目的应用系统建设,我们规划项目建设的前期准备、需求调研及设计、开发及单元测试、集成测试及联调、单项验收和整体初验、应用系统试运行及总体竣工验收、系统技术支持及运行维护七个阶段,进行项目的建设,对每个阶段计划、任务、配置资源、完成标志、阶段成果等进行详细说明。项目变更控制软件项目的实施特点就是渐进明细,项目实施的过程中变更是客观存在的。项目发生变更时,如果管理不当,对项目执行的负面影响很大。直接的影响会包括项目延期、成本增加等,所以变更管理在整个项目的管理中处于重要位置,直接对各方的沟通和项目成败有非常大的影响。应用系统承建商在变更管理方面要配合总集成商、和用户对项目过程中的变更进行有效的记录、跟踪、协调和管理。大型复杂项目的变更往往会导致项目建设目标的偏离,造成投资的浪费和成本的不可控。因此对于项目的变更要严格控制,尤其对于重大变更必须由项目各方都参加的联席会议评审通过,对于重大的技术变更,必须由专家委员会评审通过。并经过用户和的签批认可。项目变更管理主要是控制影响项目变更的因素,并有效控制变更的影响。如下将针对项目实施过程中发生变更的处理流程进行说明:1、提交变更请求:首先由应用系统开发商提出项目变更请求,提交给用户方。2、技术评审:用户接收到项目变更请求后进行技术评审,审阅范围变更的技术影响和初步的成本影响。并确定是否为重大变更;3、专家委员会评审:如果变更为重大技术变更,必须组织专家委员会的专家技术评审。专家评审结果是业务决策的基础;4、总体变更管理委员会评审:如果为重大变更,用户方要通知变更影响的相关各方,参加变更管理委员会组织的变更评审会议;联席会议评审的入口条件为用户的技术评审结论和专家委员会的评审结论。总体变更管理委员会决定是否同意变更执行;5、变更执行实施:如果总体变更管理委员会通过评审,将变更交给执行方执行和实施变更,并同时通知相关的受影响方;6、变更备案:变更由归档备案。涉及相关文档:项目的变更管理要结合项目管理信息系统的变更管理工具,变更的提交、评审、跟踪、实施以及变更相关配置文档的修订更改等都需要记录。相关的文档包括:1、《项目变更申请表》2、《项目变更评审报告》3、《项目变更通知单》4、《项目变更跟踪表》项目配置管理为了使系统实施方的产出物能够得到有序完成的管理,整个工程应该有统一的项目配置管理策略。配置管理计划用户委派的配置管理机构,要制定详实的配置管理计划,报送用户单位审批和备案,并按照计划遵照执行。应用系统承建商在项目立项时,由项目经理主持、质量管理任务组具体负责起草配置管理计划并报质量经理和项目经理审批,项目经理在审批后及时向项目全体成员传达计划内容,并监督配置管理计划的执行,全体成员应积极配合配置管理人员执行配置管理计划。获得项目组审批通过的配置管理计划要报送用户、监理单位备案。配置管理活动配置管理活动主要包括定义基线、定义受控配置项两部分:1.定义基线基线既是前一阶段工作的成果,又是下一阶段工作的依据。为此,必须有严格的手段控制基线的确认、标识和更改,其要点为:经过联合评审确认需求基线后,设计人员在进行系统的设计时,必须严格按照需求分析文档所规定的范围进行。项目阶段性计划和详细计划经部门经理和项目经理签字确认后,各小组按既定的进度要求制定周计划,在例会上经相关经理批准后确定实施。严格执行项目领导小组制定的阶段时间表,每周例会总结计划实施和完成情况;计划完成不好的,找出原因,制定具体措施,争取把失去的时间补回来。配置管理基线包括:(1)需求基线:需求分析基线是指经过联合评审确认的《需求规格说明书》中说明的有关事项,具体包括:业务需求分析中的业务流程图(功能需求)、非功能需求描述(可用性、安全性、可维护性、可移植性等)、系统运行平台(硬件平台、网络平台、操作系统平台、数据库平台等)。(2)功能基线:功能基线主要是指经过联合评审确认的“工程设计方案”中的各项规格说明,包括《技术方案》、代码手册、逻辑设计和物理设计等内容。(3)产品基线:在软件测试阶段结束时,经过正式评审和批准的软件产品和全部配置项的规格说明。(4)其他基线:如项目计划。在需求分析阶段,若存在不确定的用户需求,要将其划为“暂时未明确”(不列入基线),或标识“搁置”。严格执行变更规程,在变更申请、变更审批、变更实施、变更确认和变更传递过程中的各步骤都有跟踪监控处理,涉及基线变更的,要经项目领导小组审核确定并由项目经理签字后才能修改。对计划的变更,分为两个层次,一是阶段性计划的变更,由项目领导小组召开相关人员参加的会议进行讨论后确定,确定变更后报项目领导小组审批确认。确认后由项目经理及时部署相关修改措施,保证项目能按新的计划正常完成。二是详细计划的变更,在不影响阶段性计划的前提下,由相关经理确认后修改,并及时布置相关的修改措施。项目中的开发规范确定之后,项目全体开发人员在开发过程中要严格遵守,对其变更要严格执行变更规程。2.定义受控配置项总集成商定义整个工程级别的受控制的配置项,更多的体现在共性任务配置项、影响整个工程集成的配置项。应用软件开发商定义受其项目管理的配置项。配置项类型主要包括:(1)开发阶段所产生的各类技术文档和管理文档配置项受控的文档配置项包括:开发各个阶段所产生的各类技术文档、管理类文档以及规范类文档的正式版本。(2)软件产品配置项为本项目所产生的软件产品及其相关部件,包括:应用源代码、公用组件源代码,后台的数据库表结构和数据库SQL脚本、数据字典等,一旦提交,即要对其整个过程进行监控。定义配置项的标识及状态跟踪方法。(3)硬件设备资源配置项受控的硬件设备资源配置项包括在项目开发过程中的所有硬件设备如:PC机,服务器,网络设备,打印设备等开发必备设备。(4)软件设备资源配置项受控的软件设备资源配置项包括在项目开发过程中所使用的所有的软件设备,如:操作系统,数据库管理系统,开发工具软件和开发中所使用的各类应用软件和防病毒软件。项目安全管理根据信息安全技术信息系统安全等级保护基本要求,在本项目的建设过程的各个阶段应该加强安全等级保护意识,将安全等级保护制度作为项目的一个重点。具体各阶段的安全保护方法如下所示:1.系统设计及开发阶段本阶段安全管理制度要求包括:(1)确保开发环境及实际运行环境物理分开,开发人员和测试人员分离,测试数据和测试结果受到控制;(2)制定软件开发管理制度,明确说明开发过程的控制方法和人员行为准则;(3)制定代码编写安全规范,要求开发人员参照规范编写代码;(4)确保提供软件设计的相关文档和使用指南,并由专人负责保管;(5)确保对程序资源库的修改、更新、发布进行授权和批准。2.工程实施阶段本阶段安全管理制度要求包括:(1)指定或授权专门的部门或人员负责工程实施过程的管理;(2)制定详细的工程实施方案控制实施过程,并要求工程实施单位能正式地执行安全工程过程;(3)制定工程实施方面的管理制度,明确说明实施过程的控制方法和人员行为准则。3.测试验收阶段本阶段安全管理制度要求包括:(1)在测试验收前根据设计方案或合同要求等制订测试验收方案,在测试验收过程中应详细记录测试验收结果,并形成测试验收报告;(2)对系统测试验收的控制方法和人员行为准则进行书面规定;(3)指定或授权专门的部门负责系统测试验收的管理,并按照管理规定的要求完成系统测试验收工作;(4)组织相关部门和相关人员对系统测试验收报告进行审定,并签字确认。4.系统交付(总体竣工验收)阶段本阶段安全管理制度要求包括:(1)制定详细的系统交付清单,并根据交付清单对所交接的设备、软件和文档等进行清点;(2)对负责系统运行维护的技术人员进行相应的技能培训;(3)确保提供系统建设过程中的文档和指导用户进行系统运行维护的文档;(4)对系统交付的控制方法和人员行为准则进行书面规定;(5)指定或授权专门的部门负责系统交付的管理工作,并按照管理规定的要求完成系统交付工作。项目需求管理需求管理就是软件开发项目中的范围管理,需求管理是整个软件开发项目的源头,软件开发项目的估算、计划、开发、测试、集成、试运行以及后续的跟踪控制,验证和确认等各项工作都是跟需求密切相关的。因此为了保证项目的进度、质量和成本目标的顺利实现,保证项目计划的严肃性和可执行性;为了保证软件系统最终开发的成果正是及需求提出者的期望值相符,所以项目的中需求管理工作至关重要。需求管理工作是需求全生命周期的管理,从用户原始需求的提出,到最终形成系统后,用户对需求实现情况的验证形成闭环流程。因此我们需要跟踪和了解到需求状态的演变过程。大型的项目软件生命周期模型较为复杂,一个需求的实现会经过用户调研、需求分析、设计、开发和测试、试运行和验收多个环节,在这个过程中需要建立需求跟踪机制,以确认需求和中间阶段产生的交付成果的一致性。另外变更管理是需求管理的另外一个重点,需求在经过评审确认后需要基线并受到控制,当出现需求变更的时候必须进行相应的需求影响分析以确认对需求变更的处理方式,当变更工作量影响较大的时候还需要调整并重新基线项目计划。获取需求获得需求的方式可以有多种多样:电话询问、现场考察、聆听用户讲解、阅读用户编制的相关文件(如招标书),我们可以通过以下两类技术手段来达到:GET(获取)和PUSH(引导、反馈、激发)相互结合的方式来得到我们真正的需求,而这两个过程都是必须交互进行的,一般我们可以筛选非常有经验(包括谈判技巧、深厚的业务和技术背景、勤奋努力)的项目成员担任需求工程师,其工作职责主要是界定项目的范围和需求变更管理,通过我们编制的各类模板文档来实现需求变更的控制。一般来讲IT集成需求包含三个不同的层次:业务需求、用户需求和功能需求,也包括非功能需求。业务需求反映了组织机构或用户对系统、应用高层次的目标要求,它们在项目视图及范围文档中予以说明;用户需求文档描述了应用必须要完成的任务,这在使用实例文档或方案脚本说明中予以说明;功能需求定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求,必须具备一定的业务背景和技术背景,能从三个不同的层次发掘客户的需求。需求管理获取需求后下一阶段的工作就是对需求分析、消化和评审,基线制定、需求说明书制定,这里我们主要集中在需求分析和编写需求说明书两方面来分析。一、需求分析1.建立需求关联图需求关联图是用于定义系统及系统外部实体间的界限和接口的简单模型,同时它也明确了通过接口的信息流和数据流,通过关联图,对用户需求的约定和确认以及项目变更控制会员会的评审都是非常关键的。2.创建开发原型创建用户接口原型可以在如下应用如下情况:如果开发人员或用户不能确定需求时,开发一个用户接口原型,这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参及者能更好地相互理解所要解决的问题。通过开发原形,用户和集成商都可以相互了解业务,发掘潜在的信息,避免用户需求的不必要变更。3.可行性分析分析需求可行性在允许的成本、性能要求下,分析每项需求实施的可行性,明确及每项需求实现相联系的风险,包括及其它需求的冲突,对外界因素的依赖和技术障碍,这个主要用于内部评审和制定技术线路提供依据。4.确定需求优先级确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时,在特定的版本中加入每一项变更,并在那个版本计划中作出需要的变更。5.为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明,它们能提供不同的信息及关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。6.编写数据字典在需求阶段,很难使团队的思路一致,建立一个合适的机制是完全必要的,这就是数据字典,数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项以确保用户及项目组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。二、需求说明书编写需求规格说明书的内容,根据我们实施项目经验,有以下一些主要要素:1.根据项目需求规格说明模版,编写项目需求要点:约定、法律法规、需求分类、技术限制、采用的技术和工具等,及项目干系人特别是用户进行沟通,然后讨论,可以采用头脑风暴法和德尔菲方法来讨论,确定说明书大纲。2.附加文档的管理,通过附加文档来跟踪用户的新的需求和需求变更,建立一个配套的文档集合,随时跟踪需求,保证项目团体步调统一,需要准备这些文件:《需求(或功能)变更申请书》、《需求(或功能)变更规格书》、《需求清单一览表》等。关于需求变更,参见项目变更控制章节。3.编写需求说明书的时候,可能还会遇到一些解决不了的需求,我们也一定用专门的章节要罗列出来,防止漏项,同时也利于我们在做实施计划的时候来采取何种措施,采购其他设备、投入相关人力或其他办法等。需求变更管理需求变更是因为需求发生变化。根据软件工程思想,需求说明书一般要经过评审,如果在需求说明书经过评审以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更。一、实施需求变更原则实施需求变更管理需要遵循以下六大原则1.建立需求基线,需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参及评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。2.制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。3.成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,应该包括用户和应用系统开发商的决策人员在内。4.需求变更一定要先申请然后再评估,最后经过及变更大小相当级别的评审确认。5.需求变更后,受影响的项目计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。6.妥善保存变更产生的相关文档。二、需求变更应对措施需求变更控制一般要经过变更申请、变更评估、决策、回复这四大步骤。如果变更被接受,还要增加实施变更和验证两个步骤,有时还会有取消变更的步骤。针对变更控制流程,在实际工作中总结出了如下几点策略:1.排序分批实现每个需求的重要性是不同的。由于资源或技术条件的限制,排出个优先级来,优先级高的需求先实现,优先级低的需求在一下版式本实现。2.相互协作在讨论需求时,及用户相互理解、相互协作,对能解决的问题尽量解决。对不能达成一致意见的问题,仔细分析原因,积极提出可行的替代方案。3.充分交流需求变更管理的过程很大程度上就是用户及开发人员的交流过程。学会认真听取用户的要求、考虑和设想,并加以分析和整理。同时,应该向用户说明,进入设计阶段以后,再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。4.

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论