hping算术题fengjiexu2000Neil,Xuokleihwcjudy
作者:TechExcel公司CEO兼首席软件架构师 周铁人 博士 在敏捷开发中最重要的原则之一就是使用燃尽图报表。基本上有两种类型的燃尽图报表；基于剩余时间的燃尽图，和基于剩余点数的燃尽图。基于剩余时间的燃尽图是一种比较流行的方式，它描绘了Sprint日常工作进度以及预计剩余工作时间。基于剩余时间的燃尽图具有以下优点：易于实践和推广；它真实反映了每个开发人员估计的剩余时间。对于一个有
敏捷开发中，Product Backlog 是否足以实现需求管理？ 敏捷方法指导团队将产品需求置于Product Backlog中管理，并按照优先级对每个产品需求进行必要的排列。在计划会(Planning Meeting)之前，由Product Owner从Product Backlog中挑选迭代周期准备开发的意向
敏捷已成为当今最被广泛接受，并被广泛实践的开发方法。有趣的是，敏捷方法的流行并不是因为它取代了其他开发方法，相反它与这些方法进行了更好地融合。现实中，众多敏捷项目的成功，也证明了敏捷将走向杂化的未来。 SpecDD是一个以需求为核心的混合敏捷开发方法。它旨在提供一个简单的框架，在一系列原则指导下能同时管理敏捷项目和传统项目。
近日获悉，TechExcel ServiceWise在Business-Software评选的TOP 10 -IT Service Management Software Vendors REVEALED.2011 Edition.（2011十大ITSM软件）活动中拔得头筹，获此殊荣；其它获评的厂商依此为 : FrontRange、BMC、CA、Numara、IBM、Epicor、EM
CustomerWise 在金融行业的应用 量身定制 随需而变 无需二次开发 以客户为中心的业务过程管理平台：各类金融项目或产品、全项目周期、业务处理全过程、全参与员工、全集成关联、全体系的协同管理。 报表（列表、分布表、趋势、生命时间、活动摘要、生产力等等）——（市场、渠道、客户、项目、业务、员工等）状况统计、考核数据、趋势控制等等。 客户管理平台：客户全生命周期管理（潜在、接洽、市场、业务、商务、合同）。 市场活动管理平台：（市场活动、产品、宣传等）资料管理、市场活动管理。 渠道（代理商、区域经理等）管理平台：资质、资料、权限、客户、业务状况等。 客户需求与投诉管理平台：为客户提供的交流和沟通、协同处理和反馈接口。 业务协同（工作）平台：支持其它平台协同工作的记录、关联、管理、统计 【作者：孙松涛】
ServiceWise提供的功能 量身定制 随需而变 无需二次开发 以客户满意度为核心的IT服务管理平台：根据SLA约定建立规范的服务标准，通过全IT服务业务和全过程的岗位职责定义、服务流程和时间节点管理，实现IT服务工作的高效优质，全面提升客户满意度。 报表（列表、分布表、趋势、SLA摘要、生命时间、员工生产力等等）——（事件、配置&资源、客户、服务、SLA、原因、员工等）状况统计、风险控制、客户分类整理、员工绩效考核、运营趋势分析、客户服务感受变化等。为业务运营、考核、服务报告等提供便捷的数据支持。 客户服务级别约定（SLA）管理：通过明确服务标准，管理客户服务期望，规范工程师服务内容、形式、过程、策略，稳步提升客户满意度。 服务台和事件管理流程：依据SLA标准，完成IT服务工作。时间节点管理、升级机制、满意度、原因分类管理，保障SLA实现，维持客户满意度的稳步提高。 待命管理流程：员工状态表达、支持服务台派单管理、实现人力资源状况统计。 巡检&人力和资源预约管理：可预见、预订工作，以及人力和资源的预约安排。 问题管理流程：事件管理出口（典型、重大、特殊、趋势、重复事件等交
以知识为核心的ALM之SpecDD篇 TechExcel周铁人 规范点驱动开发（Specification Driven Development，简称SpecDD）是一种全新的软件开发概念性框架，它贯穿于应用生命周期管理（Application Lifecycle Management，简称ALM）的各个阶段，支持各种成熟开发模型，旨在帮助开发团队提高项目质量，促进软件项目成功。 一、 SpecDD的概念 SpecDD概念性框架用规范点（Specification，以下简称Spec）来表述/定义产品或版本功能，并通过中央知识库与整个团队有效共享，使Spec成为贯穿ALM各阶段的要素，从需求分析到项目规划，从编码到QA测试（如图1所示），驱动整个开发流程。 Spec是SpecDD概念性框架中的最小单元。通常情况下，由来自各种渠道的客户需求和产品需求，结合以往积累的知识文档，可以提炼出多个Spec。它们可以是正规表达的新功能、功能增强或缺陷修复，并与对应的需求和知识相关联。Spec是高度结构化的，其树形结构准确地对应产品/版本功能树，以保证开发人员
近十多年以来，在国家十一五规划和高校“211工程”、“985工程”的推进下，高校的IT基础设施及信息化建设有了迅猛的发展，尤其是随着近年来国内掀起的数字校园建设的热潮，更是使得网络和各种应用系统已成为高校科研、教学、管理、生活服务等各方面业务开展的支撑平台和赖以运行的基础。然而，正是随着这股热潮的逐步开展，和网络基础设备和应用的增多，很多困惑和问题也随之而来。现今学校的各项活动越来越依赖于网络和信息化，IT服务部门（信息网络中心）承担的工作压力和服务要求越来越大，如何管理复杂的、高技术含量的IT基础设施与服务，为学校广大教职工和学生提供良好的IT服务支持？IT部门如何去应对灵活多变的IT服务需求，提高运维的灵活性和响应速度，迎接信息化带来的挑战？ 正如这些不断涌现的问题： · 高校IT投资大，如何快速转化为高校的业务价值？ · 师生抱怨多，服务请求无法及时传递和响应，没有统一的服务管理平台！ · 作为对外服务的信息中心，面对上万级用户，甚至多达几十个的应用系统，IT服务效率要求高！ · 传统维护工作量大、事情琐碎、难以量化和考核！ · 服务工作量大，质量却没有标准的依据去保证，无
SLA与服务规划 Service Wise产品交流会感受 在Service Wise产品交流会后，就 “事件管理”过程中的疑问有所思考，觉得与IT服务的“服务级别协议（SLA）管理” 有关，尤其是其中的“SLA定义”和“服务规划”。 也许在“事件管理”流程中需要重视并完善如下两项工作： （一）、 服务级别协议（SLA） 服务级别协议是IT服务提供方和被服务方之间就服务提供中关键的服务目标及双方的责任等有关细节问题而约定的协议。 对于每项服务（以及每类客户）的服务级别定义通常都包括以下数据点： 1) 分类定义：（在ITIL中称为服务目录）指一个需要被衡量、报告和持续提高的关键业务流程或功能。 2) 服务时间：应清楚地描述SLA执行的日期和时间及特殊的时间约定。 3) 服务责任：对服务需求详细说明的条款。 4) 服务级别指标：对服务供应方工作的考核方法，通常以百分比表达。 5) 计量公式：描述衡量服务的数学公式。 6) 测量间隔/报告周期：判断SLA是否被满足的测量周期
近日为了进一步熟悉我们的ServiceWise产品，更深入的学习了很多服务台相关的功能和知识,通过系统的亲自体会,对服务台也有了更进一步的认识，大致梳理了自己的思路，从服务台的价值角度来讲，总结有以下方面： 1、 职能定位 服务台的目标是通过保证有关的呼叫请求能够达到IT部门和进行一些支持性活动（从不同的流程）来支持约定的服务供应。可以理解为,它是客户与IT部门的“首次联系点”，帮助台提供的服务可被称为“服务的服务”。 在ITIL框架中，ITIL把IT管理活动归纳成10个核心流程和一项管理职能，服务台即被定义为管理职能。它与其它十大管理流程不同，没有严格定义的执行流程。服务台是连接用户和IT部门的一个信息交换平台，它能起到双向信息反馈的作用，并且与多个服务管理流程密切相关，为用户提供与问题、变更、服务级别、发布、配置、IT服务持续等管理流程的接口，它还是提供高效率的IT运营服务所不可或缺的关键环节。 2、 角色定位 在IT服务管理中，服务台可以理解为是一座企业和客户之间架设起的桥梁，或
待命管理（状态表达）的价值 ServiceWise应用模块介绍 员工状态数据，是对事件派发最重要的支持数据。从管理的角度说，其重要性明显高于用户资料、CMDB相关数据、甚至事件申报信息等。 待命管理把传统服务台摊牌工作的模式，转化为待命员工主动要工作的积极模式。 一、 待命管理原则 1、员工状态的自主表达 2、可以表达的状态设定（最简单的就是待命、非待命）——管理者根据企业需求制定，当然可以包括：待命、工作中、外出、就餐、稍息、请事（病）假、下班等等。 注：待命状态时间＋事件处理数量（工作量）＝员工的价值 二、 待命状态的企业价值 1、员工申请工作的意愿表达——主动工作的态度，展示着员工队伍的工作情绪状况。 2、有处于待命状态的员工——意味着企业能够有能力处理“突发事件”（IT服务行业的事件主要是突发事件，SLA基本上也是针对突发事件处理），实现维护承诺。 3、待命≠不工作（空闲、没事做、不做事）。处于待命状态，仍然可以进行那些能够随时停下，不是很紧迫的事项。当然，在这些事情被积压、或变得紧迫时，要取消待命状态，
统一管理术语、统一技术术语，是企业文化建设的重要环节，也是推广IT服务管理的必要基础。只有“语言统一”了，在组织内以及组织与外界的交流才能方便、有效，才能对目标认同。ITIL正是IT服务管理(ITSM)领域公认的“共同语言”。 如何掌握这门“共同语言”，并且在实践中应用它，帮助企业对IT系
现在很多客户，不管是发包方还是接包方，都会来问我们IT服务外包该怎么管，既要管人，又要管事，往往2个都没管好。先来分析下原因，为什么客户会有这样的困惑。对于发包方来说主要困惑是不知道怎么去管理这些外包服务商，也不知道怎么去量化这些服务，到底什么是好的服务，什么是不好的服务，服务要做到什么程度才算好的等。而对于接包方来说主要困惑是不知道派出去服务的人具体做了哪些事情，这些服务客户是否满意，怎样让客户接受并为作出的服务买单等。 让我们先来理理头绪。首先，IT服务外包究竟定义是什么？目前在定义上很混乱，我们挑比较权威的来说，美国著名的IT研究和咨询公司GARTNER按最终用户与IT服务提供商所使用的主要购买方法将IT服务市场分为：离散式服务和外包（即服务外包）。服务外包又分为：IT外包（ITO)和业务流程外包（BPO)。ITO可以包括产品支持与专业服务的组合，用于向客户提供IT基础设施、或企业应用服务、或同时提供这两方面的服务，从而确保客户在业务方面取得成功。ITO可以进一步细分成数据中心、桌面、网络与企业应用外包等。 既然弄清楚了I
我们内部IT目前服务目录的建设初具规模了，大家还比较认可，觉得现在提事件比以前简单了许多，也清楚的知道什么事情该什么事件解决了。 以前没上系统时，来什么活干什么事，没有明文的服务内容上的说法，后来IT逐渐的认识到了IT服务管理的问题，开始上了系统，让我们所有的人都在系统上提交，不在受理电话的了。可大家觉得太麻烦了，还要填写内容，有些问题总觉得写出来的内容，没有电话来的直接说的清楚，虽然大家有想法，但这是公司的规定只能这样执行。 后来学习了一点Itil，在服务级别管理中看了点服务目录的内容，心想，将事件分类用客户化的语言来表示就可以当做服务目录了。于是又开始在事件分类上下功夫，尽量用客户化的语言，并将事件分类与服务级别协议的指标相关联，实现了SLA的自动跟踪，可是这对于员工提交IT事件来说并没有多少改善，尽管我们做了很多事件模板、服务模板、相关的说明，因为用户说我不知道应该选哪个模板！ 去年ServiceWise升级了，在用户端有了专门的服务目录模块，仔细研究后发现功能不错，完全可解决目前服务目录呈现给客户的问题。这里先把功能说一下 1、在每个用户的自助服务端口内增加了服务目录模
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
