售后服务IT服务技能系列培训售前篇.docx
- 文档编号:12519217
- 上传时间:2023-06-06
- 格式:DOCX
- 页数:20
- 大小:46.63KB
售后服务IT服务技能系列培训售前篇.docx
《售后服务IT服务技能系列培训售前篇.docx》由会员分享,可在线阅读,更多相关《售后服务IT服务技能系列培训售前篇.docx(20页珍藏版)》请在冰点文库上搜索。
售后服务IT服务技能系列培训售前篇
(售后服务)IT服务技能系列培训售前篇
IT服务技能系列培训——售前篇
(四)
软件工程管理
学员手册
联想集团XX公司
IT1for1事业部
2001年11月
前言
能否做好软件的服务对于提高IT服务的质量是至关重要的,用户对于计算机系统的整体满意程度很大的部分是来自于他们对直接操作的软件产品中得来的,因此如何使我们提供的软件产品获得用户较高的满意度就显得有为重要。
也许您没有从事过软件开发的工作,或者您根本不会C++/JAVA等编程语言,可是您同样有可能介入到软件项目当中来,同样能够充分发挥您的作用,因为除了最终的编程工作外,其他的项目参和者的努力对软件项目的成功同样起着举足轻重的作用,同样是不可忽视的。
《软件工程管理》课程就是为了提高您于软件项目中除纯技术工作的其他工作,如项目管理和需求获取等方面的不足而设计开发的,通过对软件工程的全面介绍使您能够掌握软件项目的全过程,了解项目组中人员的角色和分工,从而找到自己的定位,同时能够使您对软件项目进行控制,合理的安排人员、进度,更有效的保证软件的质量,且能够通过科学的方法获得且提交高质量的软件需求,从而获得最大的客户满意度。
第壹部分软件概述3
第1章软件3
第二部分软件项目的管理6
第2章项目管理的概念6
第3章软件项目计划7
第4章风险管理9
第5章项目进度安排及跟踪9
第三部分软件需求11
第6章基本的软件需求?
11
第7章客户的需求观12
第8章需求工程的推荐方法13
第9章软件需求和风险管理13
第10章建立项目视图和范围14
第11章聆听客户的需求14
第12章编写需求文档15
第13章软件的质量属性15
第14章设定需求优先级16
第15章需求的质量验证17
附件18
用户需求规格说明书18
第壹部分软件概述
●到底什么是计算机软件?
●为什么我们不断努力要建造高质量的基于计算机的系统?
●我们如何对计算机软件的应用领域分类?
●关于软件仍存于什么样的神话?
第1章软件
壹系列软件关联的问题于计算机系统的整个发展过程中壹直存于着,而且这些问题仍会继续恶化:
1.硬件的发展壹直软件。
2.我们建造新程序的能力远远不能满足人们对的需求,同时我们开发新程序的速度也不能满足和的要求。
3.计算机的普遍使用已使得社会越来越依赖于。
4.我们壹直于不断努力建造具有和的计算机软件。
5.拙劣的和资源的缺乏使得我们难以支持和增强已有软件。
为了解决这些问题,整个产业界开始采用了软件工程实践。
1.1软件
软件的定义:
软件是
(1)能够完成预定功能和性能的的指令(计算机程序);
(2)使得程序能够适当地操作信息的;(3)描述程序的操作和使用的。
1.2.2软件应用
系统软件:
系统软件是壹组为其他程序服务的程序。
系统软件均具有以下特点:
和计算机硬件频繁交互;多用户支持;需要精细调度、资源共享及灵活的进程管理的且发操作;复杂的数据结构;及多外部接口。
实时软件:
管理、分析、控制现实世界中发生的事件的程序称为实时软件。
壹个实时系统必须于严格的时间范围内响应。
而壹个交互系统(或分时系统)的响应时间能够延迟,且不会带来灾难性的后果。
商业软件:
商业信息处理是最大的软件应用领域。
工程和科学计算软件:
工程和科学计算软件的特征是“数值分析”算法。
嵌入式软件:
嵌入式软件驻留于只读内存中,用于控制这些智能产品。
个人计算机软件:
个人计算机软件市场是于过去十年中萌芽和发展起来的。
字处理、电子表格等。
人工智能软件:
人工智能(AI)领域是专家系统,也是为基于知识的系统。
1.2软件神话
管理者的神话:
神话:
我们已经有了关于建造软件的标准和规程的书籍,难道它们不能给人们提供所有其需要知道的信息吗?
事实:
神话:
我们已经有了很多很好的软件开发工具,而且,我们为它们买了最新的计算机。
事实:
神话:
如果我们已经落后于计划,能够增加更多的程序员来赶上进度(“有时称为蒙古大夫概念”)。
事实:
用户的神话:
神话:
有了对目标的壹般描述就足以开始写程序了—我们能够以后再补充细节。
事实:
神话:
项目需求总是于不断变化,但这些变化能够很容易地满足,因为软件是灵活的。
事实:
开发者的神话:
神话:
壹旦我们写出了程序且使其正常运行,我们的工作就结束了。
事实:
神话:
于程序真正运行之前,没有办法评估其质量。
事实:
神话:
壹个成功项目唯壹应该提交的就是运行程序。
事实:
第二部分软件项目的管理
●于壹个软件项目中如何管理人员、问题和过程
●壹个软件项目组如何对工作量、成本和项目时间进行可靠的评估
●壹个组织何时应该建造软件?
何时应该获取软件?
何时应该请求外援?
●如何创建壹个项目进度计划?
第2章项目管理的概念
2.1管理的范围
有效的项目管理集中和三个P上:
、、。
其顺序不是任意的。
2.2人员
◇项目参和者
、、、、
◇项目负责人
当我们要选择某个人来领导壹个软件项目时,我们应该考虑什么呢?
刺激:
鼓励技术人员发挥其最大能力的壹种能力。
组织:
融合已有的过程(或创造新的过程)的壹种能力,使得最初的概念能够转换成最终的产品。
想法或创新:
鼓励人们去创造,且感到有创造性的壹种能力,即使他们其实必须工作于为特定软件产品或应用软件建立的约束下。
◇软件项目组
壹个新的软件项目中直接涉及到的人员的组织,是项目管理者的职责。
下面为壹个项目分配人力资源的若干可选方案,该项目需要n个人工作k年:
1.n个人被分配来完成m个不同的功能任务,相对而言几乎没有合作的情况发生;协调是软件管理者的责任,而他可能同时仍有六个其他项目要管。
2.n个人被分配完成m个不同的功能任务(m 3.n个人被分成t个小组;每壹个小组完成壹个或多个功能任务;每壹个小组有壹个特定的结构,该结构是为同壹个项目的所有小组定义的;协调工作由小组和软件项目管理者共同控制。 2.3问题 ◇软件范围(详见第三部分——软件需求) 软件项目管理的第壹个活动是的确定。 范围是通过回答下列问题来定义的: 背景: 信息目标: 功能和性能: ◇问题分解 问题分解,有时称为划分,是壹个软件需求分析的核心活动。 于确定软件范围的活动中且没有完成分解问题,分解壹般用于俩个主要领域: (1) (2) 2.4过程 软件过程的壹般阶段(定义、开发和维护)适用于所有软件项目。 问题于于如何选择壹个适合项目要开发的软件的过程模型。 小结: 软件项目管理是软件工程的保护性活动。 它先于任何技术活动之前开始,且持续贯穿于整个计算机的定义、开发和维护之中。 第3章软件项目计划 3.1项目计划目标 软件项目计划的目标是提供壹个框架,使得管理者能够对、及进行合理的估算。 这些估算是软件项目开始时于壹个限定的时间框架内所做的,且且随着项目的进展不断更新。 此外,估算应该定义“”及“”,使得项目的结果能够限制于壹定范围内。 3.2软件范围 软件项目计划的壹个活动是确定。 于系统工程阶段应该对分配给软件的功能及性能加以评估,以建立壹个项目范围,该范围于管理级及技术级均是无二义性的和可理解的。 (如何获取定义软件范围所需的信息将于软件需求部分详细讲解。 ) 3.3资源 软件计划的第二个任务是估算完成。 ◇人力资源 壹个软件项目所需的人员数目于完成了开发工作量的估算之后就能够确定。 ◇可复用的软件资源 可复用性是指。 于计划进行过程中应该考虑的四种软件资源分类是: 可直接使用的构件: 具有完全经验的构件: 具有部分经验的构件: 新构件: ◇环境资源 支持软件项目的环境,通常被称为软件工程环境,集成了硬件及软件俩大部分。 3.4自行开发和购买的决策 (1)购买可直接使用的软件(或被授权使用); (2)购买“具有完全经验”或“具有部分经验”的软件构件,然后进行修改和集成,以满足特定的需求; (3)软件能够由壹个外面的承包商根据买方的特殊需求定制开发。 软件获取的步骤根据要购买的软件的要求程度及最终价格来定义。 于某种情况下(如,低成本的PC软件),直接购买且试验比起对可选的软件包进行冗长的评估要便宜得多。 而对于比较昂贵的软件产品,可采用下列指导原则: (1)建立所需软件的功能及性能需求,定义任何可能的可测量特性。 (2)估算内部开发的成本及交付日期。 (3)选择三到四个最符合你的需求的候选软件。 (4)选择能够有助于建造所需软件的可复用软件构件。 (5)建立壹个比较矩阵,对关键功能进行仔细比较。 或者,进行基准测试,以比较候选软件。 (6)根据以前产品的质量、开发商的支持、产品的方向、以及其名声,来评估每个候选软件包或构件。 (7)联系该软件的其他用户且询问其意见。 自行开发或是购买的决策是根据以下条件决定的: (1)? (2)? (3)? 第4章风险管理 4.1软件风险 项目风险威胁到项目计划。 技术风险威胁到要开发软件的质量及交付时间。 商业风险威胁到要开发软件的生存能力。 第5章项目进度安排及跟踪 5.1基本概念 虽然软件延期交付的原因很多,可是大多数均能够追溯到下面列出的壹个或多个根本原因上: ◆壹个不现实的截止期限。 ◆客户需求发生变化。 ◆所需的资源数量估计不足。 ◆于项目开始时,没有考虑风险。 ◆事先无法预计的技术困难。 ◆事先无法预计的人力困难。 ◆人员之间的交流不畅。 ◆项目管理者未能发现进度拖后。 5.2基本原则 同软件工程的所有其他领域壹样,有壹些基本原则能够指导软件项目的进度安排: ◇划分: 项目必须被划分成若干能够管理的活动和任务。 为了实现项目的划分,对产品和过程均需要进行分解。 ◇相互依赖性: 各个被划分的活动或任务之间的相互关系必须是确定的。 有些任务必须顺序发生;而其他的则能够且发进行。 有些活动只有于其他活动产生的工作产品完成时才能够开始,而其他的则能够独立进行。 ◇时间分配: 必须为每个被调度的任务分配壹定数量的工作单位(例如,若干人天的工作量)。 此外,必须为每个任务指定开始和结束日期,这些日期是和工作完成的方式相互依赖的(全职仍是兼职)是工作方式的函数。 ◇工作量确认: 每个项目均有预定数量的人员参和。 于进行时间分配时,项目管理者必须确保于任意时段中分配给任务人员数量不会超过项目组中的人员数量。 ◇定义责任: 每个被调度的任务均应该指定某个特定的小组成员来负责。 ◇定义结果: 每个被调度的任务均应该有壹个定义好的结果。 对于软件项目而言,结果通常是壹个工作产品(例如壹个模块的设计)或某个工作产品的壹部分。 通常将多个工作产品组合成“可交付产品”。 ◇定义里程碑: 每个任务或任务组均应该和壹个项目里程碑关联联。 当壹个或多个工作产品经过质量复审且且得到认可时,标志着壹个里程碑的完成。 注: 随着项目进度的发展,上述每壹条原则均会被用到。 5.3人员和工作量之间的关系 工作量分布: 40-20-40规则: 第三部分软件需求 ●什么是软件需求? ●为什么要进行软件需求调研? ●如何通过工程方法获得高质的软件需求? ●如何通过需求管理于工程进展中维持需求约定集成性和精确性? 第6章基本的软件需求? 6.1软件需求 需求的层次: 软件需求包括三个不同层次——、和——也包括非功能需求。 业务需求: 反映了组织机构或客户对系统、产品高层次的目标要求,它们于项目视图和范围文档中予以说明。 用户需求: 文档描述了用户使用产品必须要完成的任务,这于使用实例文档或方案脚本说明中予以说明。 功能说明: 定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。 6.2不适当的需求过程所引起的壹些风险: ◇用户不多导致产品无法被接受; ◇用户需求的增加带来过度的耗费和降低产品的质量; ◇模棱俩可的需求说明可能导致时间的浪费和返工; ◇用户增加壹些不必要的特征和开发人员画蛇添足; ◇过分简略的需求说明以致遗漏某些关键需求; ◇忽略某类用户的需求将导致众多客户的不满; ◇不完善的需求说明使得项目计划和跟踪无法准确进行。 6.3高质量的需求过程带来的好处 1.重做工作大大减少; 2.避免高出的68倍成本; 3.使产品更富吸引力; 4.拥有忠实的客户关系。 6.4优秀需求具有的特征 1.完整性 2.正确性 3.可行性 4.必要性 5.划分优先级 6.无二义性 7.可验证性 6.5需求的开发 需求开发可分为: 、、和四个阶段。 第7章客户的需求观 7.1谁是客户 通常意义下,客户是指直接或间接从产品中获取利益的个人或组织。 软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者或是获得产品所产生的结果的人。 7.2客户和开发人员之间的合作关系 只有当双方参和者均明白要成功需要什么,同时也应知道要成功合作伙伴方需要什么时,才能建立起壹种合作关系。 由于项目压力和日渐增,所有风险承担者有着壹个共同的目标这壹点容易被遗忘。 其实大家均想开发出壹个既能实现商业价值,又能满足用户需求,仍能使开发者感到满足的优秀软件产品。 第8章需求工程的推荐方法 8.1需求获取 (1)确定需求开发过程 (2)编写项目视图和范围文档 (3)将用户群分类且归纳各自特点 (4)选择每类用户的产品代表 (5)建立起典型用户的核心队伍 (6)让用户代表确定使用实例 (7)召开应用程序开发联系会议 (8)分析用户工作流程 (9)确定质量属性和其它非功能需求 (10)通过检查当前系统的问题方案来进壹步完善需求 (11)跨项目重用需求 8.2需求分析 需求分析包括提炼、分析和仔细审查已收集到的需求,以确保所有的风险承担者均明白其含义且找出其中的错误、遗漏或其它不足的地方。 分析员通过评价来确定是否所有的需求和软件需求规格说明均达到了优秀需求说明的要求。 分析的目的于于开发出高质量和具体的需求,这样你就能作出实用的项目估算且能够进行设计、构造和测试。 8.3需求规格说明 无论你的需求从何而来,也不管你是怎样得到的,你均必须用壹种统壹的方式来将它们编写成可视文档。 业务需求要写成项目视图和范围文档。 用户需求要用壹种标准使用实例模板编写成文档。 而软件需求规格说明则包含了软件的功能需求和非功能需求。 8.4需求验证 验证是为了确保需求说明准确、完整的表达必要的质量特点。 第9章软件需求和风险管理 和需求有关的风险: ◆需求获取 ◆需求分析 ◆需求规格说明 ◆需求验证 第10章建立项目视图和范围 项目视图和范围的文档把业务需求集中于壹个简单、紧凑的文档里,这个文档为以后的开发工作奠定了基础。 第11章聆听客户的需求 11.1需求获取的指导方针 需求获取可能是软件开发中最困难、最关键、最易出错及最需要的方面。 需求获取只有通过有效的客户——开发者的合作才能成功。 分析者必须建立壹个对问题进行彻底的环境,而这些问题和产品有关。 11.2对客户输入进行分类 不要指望你的客户会给需求分析者提供壹个简洁、完整、组织良好的需求清单。 分析者必须把代表客户需求的许多信息分成不同的类型,这样他们就能合理地编写信息文档且把它们用于最合理的方式上。 11.3如何知道你何时完成需求的获取 ◆如果用户不能想出更多的使用实例,也许你就完成了收集需求的工作。 用户总是按其重要性的顺序来确定使用实例的。 ◆如果用户提出新的使用实例,但你能够从其它使用实例的关联功能需求中获得这些新的使用实例,这时也许你就完成了收集需求的工作。 这些新的使用实例可能是你已获得的其它使用实例的可选过程。 ◆如果用户开始重复原先讨论过的问题,此时,也许你就完成了收集需求的工作。 ◆如果所提出的新需求比你已确定的需求的优先级均低时,也许你就完成了收集需求的工作。 ◆如果用户提出对将来产品的要求,而不是当下我们讨论的特定产品,也许你就完成了收集需求的工作。 第12章编写需求文档 12.1用户需求规格说明书模板(见附件) 12.2编写需求文档的原则 ◆保持语句和段落的简短 ◆采用主动语态的表达方式 ◆编写具有正确的语法、拼写和标点的完整句子 ◆使用的术语和词汇表中所定义的应该壹致 ◆需求陈述应该具有壹致的样式 ◆为了减少不确定性,必须避免模糊的、主观的术语,例如,用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。 ◆避免使用比较性的词汇,例如,提高、最大化、最小化和最佳化。 定量地说明所需要提高的程度或者说清壹些参数可接受的最大值和最小值。 第13章软件的质量属性 13.1非功能需求 用户总是强调确定他们的功能、行为或需求——软件让他们做的事情。 除此之外,用户对产品如何良好地运转抱有许多期望。 这些特性包括: 产品的易用程度如何,执行速度如何,可靠性如何,当发生异常情况时,系统如何处理。 这些被称为软件质量属性的特性是系统非功能部分的需求。 13.2定义质量属性 对用户重要的属性 (1)有效性: 有效性指的是于预定的启动时间中,系统真正可用且且完全运行时间所占的百分比。 (2)效率: 效率是用来衡量系统如何优化处理器、磁盘空间或通信带宽的。 如果系统用完了所有可用的资源,那么用户遇到的将是性能的下降,这是效率降低的壹个表现。 (3)灵活性: 就像我们所知道的可扩充性、增加性、可延伸性和可扩展性壹样,灵活性表明了于产品中增加新功能时所需工作量的大小。 (4)完整性: 完整性(或安全性)主要涉及: 防止非法访问系统功能、防止数据丢失、防止病毒入侵且防止私人数据进入系统。 (5)互操作性: 互操作性表明了产品和其它系统交换数据和服务的难易程度。 (6)可靠性: 可靠性是软件无故障执行壹段时间的概率。 (7)健壮性: 健壮性指的是当系统或其组成部分遇到非法输入数据、关联软件或硬件组成部分的缺陷或异常的操作情况时,能继续正确运行功能的程度。 (8)可用性: 可用性也称为“易用性”和“人类工程”,它所描述的是许多组成“用户友好”的因素。 可用性衡量准备输入、操作和理解产品输出所花费的努力。 13.3属性的取舍 有时,不可避免地要对壹些特定的属性进行取舍。 用户和开发者必须确定哪些属性比其它属性更为重要,且定出优先级。 于他们决策时,要始终遵照优先级。 第14章设定需求优先级 为什么要设定需求的优先级: 当客户的期望很高、开发时间短且且资源有限时,你必须尽早确定出所交付的产品应具备的最重要的功能。 建立每个功能的相对重要性有助于你规划软件的构造,以最少的费用提供产品的最大功能。 因为于这些开发中,交付进度安排很紧迫且且不可改变日期,你需要排除或推迟壹些不重要的功能。 第15章需求的质量验证 大多数软件开发者均经历过开发阶段后期或于交付产品之后才发现需求的问题。 当以原来需求为基础的工作完成以后,要修补需求错误就需要作大量的工作。 需求验证是需求开发的第四部分(其余三个为获取、分析和编写规格说明)。 需求验证所包括的活动是为了确定以下几方面的内容: ◆软件需求规格说明正确描述了预期的系统行为和特征。 ◆从系统需求或其它来源中得到软件需求。 ◆需求是完全的和高质量的。 ◆所有对需求的见法是壹致的。 ◆需求为继续进行产品设计、构造和测试提供了足够的基础。 更好的需求将会带来更好的产品质量和客户更大的满意程度,这能够降低产品生存期中的维护、增强和客户支持的费用。 于需求质量上的投资能够使你节省更多的钱。 附件 用户需求规格说明书 1.引言 1.1背景 [给出需求的提出者、用户、开发单位、主管单位,说明待开发产品的名称、起源、产生背景以及和其它产品之间的联系。 ] 1.2比较分析 [阐述待开发产品和同类产品或产品的历史版本之间的比较分析。 ] 1.3任务概述和开发目标 [简单描述需求摘要,说明待开发产品所要做的工作和产品的开发目标、应用目标和效益目标。 ] 2.功能 [从用户的角度出发,基于服务的目标,对满足用户需求的产品功能做壹个简要、清晰、合理的、可行的描述和定义。 ] 3.性能和限制 [说明满足用户需求的待开发产品的关联重要性能和使用限制(如时间特性,数据精度,处理能力等)。 ] 4.接口 4.1用户界面 [描述用户对待开发产品使用的用户界面的需求,如控制板样式、输入输出设备,开关,指示灯,软件界面等。 ] 4.2和其他系统、产品的接口联系和要求 [描述待开发产品和其他系统和产品关联的接口联系和功能要求。 ] 5.用户群及其特点 [说明使用待开发产品的可能的最终用户,且描述他们的关联特性(如教育水平、工作经验、技术熟练程度等。 )] 6.工作环境 [描述待开发产品工作环境的限制(如硬件、软件、网络、物理、气候、社会环境等)。 ] 7.规格、质量 [描述和客户或开发人员有重要关系的待开发产品的质量特性,这些特性应为确定、定量,且可验证的。 同时说明产品于安全性、可靠性、健壮性、可维护性、可移植性等方面的要求。 ] 8.设计约束及限制 [描述开发产品时对各种行业标准、规范、国家规定、法规、开发平台、开发技术、使用设备、元器件、编程工具、操作系统、数据库等方面的限制。 ] 9.安装、使用和维护 [说明用户对待开发产品于安装、使用和维护方面的特殊要求,如操作方式,系统恢复方式等。 ] 10.未来可能需求 [说明未来或下壹版本中,对待开发产品所要满足的可能需求。 ] 11.其他需求 [上面未说明的其他需求。 ] 12.产品交付日程 13.附录 13.1定义,术语和缩写词 [缩写词和名词、术语定义。 ] 13.2参考资料 [编写本规格书所参考的各种资料,如需求方案、用户合同、关联研发管理规范、背景资料、其它标准。 ]
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 售后服务 IT 服务 技能 系列 培训 售前篇
![提示](https://static.bingdoc.com/images/bang_tan.gif)