ITSM项目需求分析说明书.docx
- 文档编号:23207588
- 上传时间:2023-05-15
- 格式:DOCX
- 页数:25
- 大小:847.34KB
ITSM项目需求分析说明书.docx
《ITSM项目需求分析说明书.docx》由会员分享,可在线阅读,更多相关《ITSM项目需求分析说明书.docx(25页珍藏版)》请在冰豆网上搜索。
ITSM项目需求分析说明书
ITSM需求分析说明书
文件状态:
[√]草稿
[]正式发布
[]正在修改
文件标识:
当前版本:
作者:
黄美雄
完成日期:
2013-3-15
版本历史
版本/状态
作者
起止日期
备注
1.0.0
黄美雄
2013-3-15
1.引言
其实ITSM并不是一个新概念,那么为什么现在才开始引起人们的注意呢?
事实是,以前客户在进行IT系统的建设时更多的关注业务,IT跟着业务跑,例如金融客户忙于Core-banking、Internet-Banking等业务,电信客户关注的是计费系统、BOSS等,制造客户上ERP系统等,而目前企业信息化建设已初具规模,业务系统基本已告一段落,而下一步关注的重点则从技术转向管理,如何能让这些系统更好运行起来,如何提高管理效率。
国家信息化评测中心的胡建生副主任对此非常关切,“目前国内企业每年IT投入达近万亿元,如何将以前的、现在的以及未来的IT投入有效的管理起来,落实有效益的信息化,这是我们目前最关心的问题。
事实上,在信息化建设初期,也确实发现了很多问题,造成IT投资浪费。
因此以效能为导向推动企业信息化建设,加强对IT基础设施的管理是我们目前的工作重点。
而ITSM正是基于这样一种理念。
2项目背景
项目现状
随着高校信息化建设的不断深入,校园网不断延伸和拓展。
一方面,学校教学、科研和管理等工作对校园网的依赖程度不断增加,另一方面,校园网的自身复杂程度也不断增加。
传统的高校IT管理方式己经不能满足高校信息化发展的要求,高校IT管理面临新的挑战。
高校IT管理必须在服务理念、服务方式、管理手段等方面进行相应的变革和创新以适应高校信息化发展的新要求。
在目前的人工管理状态下,存在着对人为操作的严重依赖,服务质量难以监控,需要一套先进可靠的管理系统,避免给IT系统带来更多的运行维护管理风险。
❑没有合理的服务级别评估机制,导致项目运维时无法实现服务承诺。
❑开展运维时无法评估服务级别所需资源和成本,投入与收益难以量化。
❑服务质量不稳定。
更多原因是现场服务标准不够明确,服务质量大多依赖于个人的技能和知识水平、态度。
❑服务管理不细致,导致服务质量影响信息系统运维目标难以达成。
上述的管理风险常常困扰信息化深入推进时,因此需要进一步提升IT服务管理的科学性、规范性、标准化,为高速发展的业务经营提供有力的支撑。
IT服务管理所倡导的标准化方法和流程,为我们提供了解决高校IT管理存在问题的较好的思路。
ITIL是关于IT服务管理流程的最佳实践,可以为高校信息化管理和保障工作提供良好的理论依据和技术保证,使其更加规范和有序。
什么是ITSM
基于不同的出发点和侧重点,人们提出了各种各样的有关IT服务管理的定义。
国际IT领域的权威研究机构加特纳(Gartner)认为,ITSM是一套通过服务级别协议(SLA)来保证IT服务质量的协同流程,它融合了系统管理、网络管理、系统开发管理等管理活动和变更管理、资产管理、问题管理等许多流程的理论和实践。
而ITSM领域的国际权威组织itSMF(国际IT服务管理论坛)则认为ITSM是一种以流程为导向、以客户为中心的方法,它通过整合IT服务与组织业务,提高组织IT服务提供和服务支持的能力及其水平。
什么是ITIL
ITIL即IT基础架构库(InformationTechnologyInfrastructureLibrary,ITIL,信息技术基础架构库)由英国政府部门CCTA(CentralComputingandTelecommunicationsAgency)在20世纪80年代末制订,现由英国商务部OGC(OfficeofGovernmentCommerce)负责管理,主要适用于IT服务管理(ITSM)。
ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范,企业的IT部门和最终用户可以根据自己的能力和需求定义自己所要求的不同服务水平,参考ITIL来规划和制定其IT基础架构及服务管理,从而确保IT服务管理能为企业的业务运作提供更好的支持。
对企业来说,实施ITIL的最大意义在于把IT与业务紧密地结合起来了,从而让企业的IT投资回报最大化。
ITIL包括了一系列适用于所有IT组织的最佳实践--无论这些组织的规模如何,以及使用的是什么技术。
事实上,这15年来的发展,ITIL在全球,尤其是欧美地区一直是如火如荼。
它已经被全球近20,000多家在不同领域和行业领先的组织不同程度上所使用。
需要强调的一点是:
ITIL不是一个正式标准,而是目前普遍实行的"事实"上的标准。
传统IT管理和ITSM的比较
3功能需求
整体需求
3.1.1系统架构
为了将现有技术资源中的各类要素进行科学地组织管理,以达到合理调配人力资源、有效管理信息化设备、提高运维管理工作水平的目标,提供一套高效专业的ITSM平台工具。
我们采用了如下图所示的架构:
从体系架构层面上,系统分为用户交互层、业务管理流程层、基础架构层,每个层着力解决各自关注的问题,各层之间又总体协调统一,形成一套完整的体系架构。
3.1.2系统总体用例图
3.1服务台门户
服务台是以客户为中心,并由技术专家、业务骨干以及协调能力强的人员构成。
在客户与IT服务提供者之间建立了一个集中的单一联系点,不仅处理事件和问题,而且还为其它活动(变更请求、排班、作业管理等)提供联系的纽带。
服务台热线通过集中的、自动化的、灵活和透明的IT服务管理,能够极大地提高企业IT服务团队的生产效能,监视服务流程,加快服务交付,改善最终用户满意度,进而显著降低IT基础设施管理成本,实现IT服务价值的最大化。
目标:
●在客户、用户、IT服务和第三方支持组织之间的日复一日的重要的联络点
●为所有呼叫提供一个重要的中心联络点
●使正常操作服务更易恢复,在议定的服务优先级里对客户的业务影响最小
●生成供交流和分析的报告
●为组织提供价值
客户期望:
●解决IT服务相关问题,并借助IT服务来提高员工工作效率
●技术能力高
●响应快速,联系方便
●乐于提供帮助
●主动联系并提供服务
3.2.1用例图
3.2知识库管理
呼叫管理和问题管理中出现的每一事件个问题进行归类整理,对出现的各个事件按部门、类型、处理难易度、解决时间等进行化类区分,并存入知识库,这一块内容非常有助于日后运维人员在碰到类似情况时,有很大的参考价值。
添加、删除、修改、查询知道库,可以从呼叫、问题管理的解决方案直接添加,在各管理页面可以方便的查看知识库。
3.2.1用例图
3.2.2活动图
3.3事件管理
事件管理(IncidentManagement)是IT运维中最基本的活动,可以说IT运维部门的职责就是处理各类事件。
事件管理的目标是尽可能快地解决突发事件或意外事件,使之恢复到正常的服务操作,并使突发事件或意外事件对业务操作的负面影响减到最小。
从而确保维持服务质量和可用性的最高水平。
对于不同规模的公司,所需要的事件管理流程也是不相同的。
对于一个中小型的企业,IT人员只有几个人,这时候就不需要很复杂的事件处理流程,只需要实现“请求-指派-处理-确认”的基本过程即可。
对于一个大型的企业或者专业的IT服务公司,则需要组建专门的IT服务受理和监督机构、多级IT技术支持团队,和与之适应的较为复杂完善的事件跟踪流
目标
●尽快将服务恢复成正常状态
●将对业务的负面影响降至最低
●确保服务质量和可用性满足SLA
突发事件的解决与恢复
●通过知识库搜索已知故障、事件的解决方法
●根据经验、培训知识、专业技能提出解决办法
●通过咨询相应专家获取解决方法
●测试解决方法的效果
●将有价值的方法和经验更新到知识库
●产生变更请求通过变更管理流程获取解决方案
●通过问题管理找到突发事件的根本原因,并采取最终的解决方案
主要动作:
检测记录;分类和初始支持;诊断分析;解决恢复;突发事件关闭;负责、监控、跟踪和沟通
3.3.1用例图
3.3.2活动图
中小型企业突发事件处理流程
大型企业或IT服务公司的多级IT事件处理流程
3.2
3.3
3.3.1
3.3.2
3.3.3事件管理流程图
3.4问题管理
问题管理(ProblemManagement),是指通过调查和分析IT基础构架的薄弱环节,查明事故原因,由此制定解决方案和防止事故再次发生的具体措施。
分析事件存在的问题和原因,再从根本上解决问题。
根据呼叫信息、与用户反映来对某个问题进行分析与处理。
问题管理与事件管理的不同之处是:
突发事件管理目标是迅速恢复服务;问题管理目标是诊断出根本原因。
如何避免突发事件的产生?
如何才能减少突发事件的数量?
我能从被动变主动吗?
假如我不能回答客户问题,我怎样才能找出解决方案,谁能帮我呢?
关键字
问题:
根本原因未知的一个或一类突发事件
已知错误(KnownErrors):
根本原因已知的突发事件和问题;已有折中或彻底的解决方案;没有实施变更永久的解决方案;可以根据业务需要要提出变更请求。
主动预防:
在事故发生之前发现和解决可能导致事故发生的问题
问题控制:
注重将问题转化成已知错误找出问题并调查根源,其目标是通过确定问题根源并采取应急措施来把问题转化为已知错误
错误控制:
监控并控制已知错误并提出变更请求(RFC):
错误控制注重于通过变更管理过程在结构上解决已知错误
目标
●稳固IT服务
●将突发事件减到最少
●找出突发事件产生的根本原因
●避免相关突发事件或问题的再次发生
主动式问题管理的职责
●确定趋势和潜在的问题源(通过审查突发事件和问题分析)
●提出RFC,防止问题再次发生
●防止问题在多个系统上复制
问题管理经理职责:
●制定和维护问题控制流程
●审查问题控制流程的效率和有效性
●生成管理信息
●建立并管理问题支持小组
●为支持工作分配资源
●监控错误控制的有效性,并提出改进建议
●开发并维护问题及错误控制系统
●审查主动式问题管理活动的效率和有效性
输入:
突发事件的详细信息、配置信息、规避措施
输出:
已知错误、变更请求、更新包括规避措施和解答问题的记录、管理信息的提交
3.4.1用例图
3.4.2活动图
3.4
3.4.1
3.4.2
3.4.3问题管理流程图
3.5变更管理
变更管理是要确保在IT服务变动的过程中能够有标准的方法,以有效的控制变更,降低或消除因为变更对业务运营所造成的影响与问题。
它的目的并不是限制变更的发生,而是为了确保变更的有序进行。
变更:
经授权在基准上所做的添加、修改或删除,变体现工程,更体现结果。
变更十二个的原因:
新的业务和需要;新的政策或法规;新的产品和服务;软硬件的升级;提高客户满意度;减少对业务的影响;提高工作效率;提高变更质量;降低费用;新的系统配置;响应客户需求;解决某个难题
目的:
在当前或新的IT服务中,在可接收的风险范围内,高效地实施已获批准的变更。
在最小风险范围内,高效经济地实施变更
变更经理主要职责:
●变更经理将于发起人合作,接受,记录所有RFC并为其指定优先级
●拒绝任何完全不切合实际的RFC
●将所有的RFC列入CAB会议的议事日程,在会议前发布议程,并将所有的RFC转给变更顾问委员会(CAB)成员,以便其在会议前有所考虑.
●确定哪些人参加哪些会议,依据RFC的性质谁将收到哪些特定的RFC,变更内容,以及参加人员的专业领域
●针对所有紧急RFC,召集紧急会议
●主持所有的变更顾问委员会和紧急委员会会议.
●结束完成的RFC
●定期生成准确的管理报告
变更顾问委员会人员主要的职责:
●审查所有提交的RFC
●考虑各种可能出现的风险
●在决策制定中的成员应对下述工作提出建议:
授权、确定影响、确定优先级、确定资源、发布
●参加变更顾问委员会/紧急委员会(CAB/EC)
●参与制定所有变更的进度表
●建立相互的支持
关键字
●RFCs:
用于记录对任何配置项发出的变更请求的详细信息表格
●CAB(ChangeAdvisoryBoard):
变更管理委员会
●EC(EmergencyCommittee):
应急委员会
●FSC(ForwardScheduleofChanges):
变更进度计划表
●PSA(projectedserviceavailability)预计服务可用性
●变更进度表(包括所有批准实施的变更详细信息以及变更计划执行日期的时间表)
3.5.1用例图
3.5.2活动图
变更流程说明:
首先设置相关审批人,再申请相关的变更信息,经过审批流程设置的人员来进行审批,如果审批不通过再回到申请人,申请人修改后从新提交、如果全部申批通过后可以开始实施,分配相关的实施人员去处理。
处理完后再申请通知CMDB更新资产信息配置信息,结束
Ø变更审批:
一个变更要经过相关的人员来审批才能进行实施变更,由于变更会引起成本、影响范围、技术等问题考虑,所以一个变更需求要根据审批流程来走。
Ø变更实施:
当审批完成后才能进行实施。
3.5
3.5.1
3.5.2
3.5.3变更管理流程图
3.6报表管理
报表是记录服务台各项工作过程和结果、承载各项运营管理数据,以及向公司相关部门传递业务数据和业务动态的重要载体。
报表中的内容和数据一方面是客服中心各项工作的体现,另一方面也可为公司提供用于市场决策的数据支持和内容依据。
因而,对客服中心的各类报表实施有效管理,形成工作报表从制作、审阅、报送到归档整理的良好工作流程,已成为客服中心运营管理中非常重要的一环。
3.6.1用例图
3.7用户及权限管理
以用户为中心,为了确保用户安全可靠的访问相应的功能和信息,统一用户及权限管理系统包含了统一用户管理(UUM)子模块来对注册的用户进行管理。
统一用户及权限管理系统在用户组之间定义操作权限,定义用户可以访问哪些数据、哪些应用,支持用户的单点登录。
3.7.1用例图
3.8基础设置
系统基本信息的设置包括流程管理/业务规则管理,数据字典/常用分类管理,基本设置/日志管理,SLA管理及其他管理
3.8.1用例图
3.8.2流程管理
布署流程:
将已定义好的流程文件打成zip格式压缩包,选择流程压缩文件上传,布署成功后显示最新版的流程定义信息
查询流程:
显示所有最新版本的流程定义信息
看流程图:
调出选中流程定义的流程图并显示
申请实例:
申请开始一个新的流程实例,去到流程开始的表单页面
跟踪流程:
显示指定流程实例的流程图,以及该实例目前所处状态位置
列出任务:
列出可由当前用户处理的所有任务
指派任务:
动态指派任务到某个组或具体某个用户
接受任务:
当前用户接受某个任务
完成任务:
当前用户执行某个活动,并完成任务,自动进入下一步任务
用户管理:
系统的身份认证需关联到工作流的身份认证
流程历史:
显示所有的流程历史
系统流程:
突发事件流程,问题管理流程,变更管理流程,知识库管理流程
3.8.3业务规则管理
通过业务规则页面编辑器,产生相应的业务规则(文件)
用户在执行相关业务操作时,执行相应业务规则
3.8.4自定义过滤器
3.8.5编辑扩展字段
3.8.6服务级别管理
服务级别管理(SLM)帮助企业IT部门与内外部的用户签定了完全量化的服务级别协议(SLA)。
实现对IT服务质量的规划/定义,监控和变更的管理。
用户可以根据协议对IT服务进行量化评价。
而IT部门也将能有条不紊地处理各种业务问题,实现让业务部门满意,以更快速度/更好的服务质量响应IT服务需求,确保客户需要的IT服务得到持续的维护和改进。
1.根据请求规则(不是SLA规则),保存Request时匹配出该请求所对应的"服务机构"?
1.1服务台工程师可以修改请求的"服务机构"(用户不可以)
2.根据请求用户得到"被服务机构"
3.根据"服务机构"和"被服务机构"得到唯一的SLA
4.取出"服务机构"的服务时间,节假日等
5.根据"请求的属性"匹配SLA下的Sla规则(非请求规则),计算"最迟响应时间"和"最迟完成时间"等
3.9辅助工具
辅助用户更好地使用系统,系统小工具包括系统公告,系统短消息,邮件系统,短信系统等
3.9.1用例图
4应用需求
4.1可配置性(Configurable)
●流程可配置:
基于工作流程引擎
●规则可配置:
基于业务规则引擎
●权限可配置:
基于JAAS/RBAC权限控制
●系统可配置:
基于JMX管理系统属性
●界面可配置:
基于W3C标准/RIA技术,用户自定义(Style,View,Filter,…)
●报表可配置:
可自定义报表
●语言可配置:
基于一体式国际化解决方案
4.2可伸缩性(Scalability)
伸缩性(Scalable)强调的是性能、容量方面的可扩展。
对于软件服务应用的可伸缩性,理想的情况是:
随着代理/用户数的增大,无需调整系统架构,而仅需增加/增强相应的硬件设备(应用服务器、数据库服务器)即可。
实现可伸缩性的最简单的方式是“Scaleup”,即垂直扩展或者向上扩展,也就是增强硬件设备。
这种方式几乎是任何应用架构普遍适用的,但是通常都会面临高成本的问题。
通常强调的应用架构具有可伸缩性,一般指的是实现“Scaleout”,水平扩展或者向外扩
展,即系统强大的功能和计算能力是建立在大量普通PC或服务器基础上的,而不是依赖于单个的强大的大型服务器。
(横向伸缩Scaleout,纵向伸缩Scaleup)
●存储层:
集群文件系统、S3等
●数据库:
分布式数据库,支持多个数据中心,可以透明在线为你的应用增加新服务器
●应用层:
SOA架构,分布式计算,并行计算,分布式缓存
●Web层:
负载平衡
4.3可扩展性(Extensible)
●分析设计:
OOAD,DDD,IOC/DI,AOP
●脚本技术:
提供脚本编程,面向开发人员/测试人员提供OpenAPI
●插件系统:
支持OSGI标准
4.4可用性/易用性
●界面:
简洁朴素,风格统一,操作提示,错误提示,
●功能:
有效性验证,稳定可靠,计算正确性
4.5兼容性/移值性
●客户端:
(客户端,浏览器,手机WAP)遵循W3C标准,能在各种主流浏览器运行,如IE,Firefox,Chrome
●数据库:
主流数据库,分布式数据库,如(MySQL/Oracle/NoSQL)
●应用服务器:
Apache+Tomcat/Jboss/WebLogic
●操作系统:
Linux/Unix/Windows
4.6安全性(Security)
在系统的使用和推广过程中,系统的安全性备受关注。
我们从应用、数据、网络三个方面来实现和满足系统的安全性需求。
●网络:
对于完全基于Internet的系统来说,网络安全非常重要,重点考虑用户数据在网络中的安全传输,保证数据的完整性和保密性。
防黑客攻击策略:
过滤器验证防DOS攻击
●数据:
对于系统的数据来说,数据隔离与数据库连接的安全都是必须要做到的,这是多代理模式中数据安全的基础。
数据不但需要安全的存储环境,还需要严格的保密机制,对于代理的敏感业务数据进行加密是提高数据保密性的一个可行的技术手段。
采用数据自动/手工/定期备份,日志备份/日志恢复保证数据安全性。
●应用:
对于系统的应用而言,需要重点构建系统的身份认证、权限管理、日志记录,确保用户身份的真实性和控制用户操作的权限。
应用安全是整个系统的最重要的安全控制。
4.7性能(Performance)
高性能无论是对于客户体验,还是降低成本,都是至关重要的。
在尚未实现伸缩性之前,
优化和提升系统性能,也是提升系统客户规模/容量的主要方法。
4.8底层监控
对各种底层监控提供接口支持
●网络监控
●服务器监控
●数据库监控
●应用程序监控
●终端用户监控
4文档需求
在产品开发生命周期中所需要准备的文档:
《项目总体需求》
《项目总体架构设计》
《项目总体开发计划》
《项目迭代开发计划》
《配置管理计划》
《部署安装指南》
《总体测试计划》
《质量保证计划》
《风险管理计划》
《用户使用手册》
《编码规范》
《UI设计参考与指南》
项目架构原型
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ITSM 项目 需求 分析 说明书