IT服务技能系列培训售前篇.docx

IT服务技能系列培训——售前篇
（四）

软件工程管理

学员手册

联想集团有限公司
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<n），建立非正式的“小组”；指定一个专门的小组负责人；小组之间的协调由软件管理者负责。
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参考资料
［编写本规格书所参考的各种资料，如需求报告、用户合同、相关研发管理规范、背景资料、其它标准。］