软件工程学习.doc

1、绪论0.1 软件工程的背景从定义上说，软件工程是一门工程学，因此它和其它工程学科有一系列相同的职责。一个相同的特征是都必须有一个彻底说明要做什么东西的过程，及需求分析；但另外，软件项目受制于非常频繁的变更0.2 软件工程的活动 定义要使用的软件开发过程 管理项目的开发活动 表述想要的软件产品 设计产品 产品实现，即编程 测试产品的单独模块 产品集成并做整体测试 产品维护软件工程涉及 4P，即 People (人),Process ( 过程), Project ( 项目 ), Product (产品)软件开发工作的产品不仅仅包含目标代码和源代码。文档、测试结果和生产率的度量也是。0.3 过程瀑布

2、过程、迭代过程、增量过程、螺旋过程、0.4 项目(Project)项目是为了生产所需要的工件应该采取的一组活动的集合。它包括和客户交流、撰写文档、设计、编码和对产品做测试。0.5 人员 (People)软件项目中涉及到人与人之间的交互作用对于项目的成功与否有着深切的影响。人员问题影响项目的另一个因素与项目的风险承担者有关。0.6 产品 (Product)软件过程各阶段的输出都是产品。第一章：过程1.1 区分各种开发的过程，指出各自的优缺点 瀑布过程模型：概念分析，分析，设计，实现(编码)，单元测试，集成，系统集成，维护；易于控制文档 迭代过程模型：不断重复的瀑布过程被称为迭代模型；能够在每次迭

3、代中都收集到过程中产生各种度量。 螺旋过程模型：该过程需要经历多次需求分析/设计/实现/测试这组顺序活动。这样做的主要原因是基于规避风险的需要；缺点：每次都要保持文档的一致性。 增量过程模型：在迭代过程模型基础上，每次迭代只是前一次的基础上增加少量功能。 统一软件开发过程(面向对象开发过程 )1.2 量化定义软件的质量1.3 理解所需要的文档第二章：项目管理2.1 项目管理简介2.1.1 项目管理的含义项目管理是指在有限的时间和资金内管理产品的生产过程。因为需要人力资源，所以项目管理不仅涉及到技术和组织方面的技能，而且涉及到管理人员的艺术。2.1.2 项目管理的要素 结构(涉及到组织元素) 管

4、理过程(参与人员的职责和监督 ) 开发过程(方法、工具、语言、文档和支持 ) 进度(开展工作各部分的时间安排 )2.1.3 主要变量：成本、性能、质量和进度2.1.4 项目管理过程的典型路线图1. 了解项目内容、范围和期限2. 确定开发过程(方法、工具、语言、文档和支持 )3. 设定组织结构4. 明确管理过程(各参与人员的职责 )5. 制定时间表(工作各部分的时间安排 )6. 制定人力计划7. 风险管理8. 确定要生产的文档9. 开始执行项目2.2 管理项目人员2.2.1 专业精神2.2.2 人员管理的重要性开发软件需要的首要因素是人员2.2.3 企业的视角2.2.4 管理层的视角2.2.5

5、工程师的视角2.3 组织人员的选择2.3.1 沟通管理2.3.2 职责结构的选择2.3.3 项目人员的来源2.4 识别和规避风险2.4.1 风险定义风险就是在项目过程中有可能发生的某些意外事情，而且在最糟的情况下将对项目产生巨大的负面影响甚至导致失败。风险有两种类型 能够避免或则绕开的风险(“被消除”) ，比如项目领导离开公司 不能避免的风险，比如没法做的事情识别第二类风险可以在项目浪费资源之前就终止它。2.4.2 风险管理概论 识别(心态：设法持续的识别风险 ) 规避计划 划分优先级 消除或者减弱风险2.4.3 风险识别2.4.4 风险规避风险规避是指减轻甚至消除风险的过程。有两种方法：一时

6、改变项目的需求，这样引起风险的问题就不再存在；第二种方法是通过技术开发解决这个问题。2.5 选择开发工具和支持2.5.1 过程方法：可选的方法有瀑布、螺旋、统一和增量2.5.2 工具2.5.3 抉择：开发还是购买2.5.4 语言选择2.5.5 文档2.5.6 支持服务一个项目需要众多人的支持，包括系统管理员、网络管理员、数据库管理员、秘书等等。项目经理需要确保能够获得这些人员的服务。2.6 创建时间表：概要的计划1. 标出必须关注的里程碑 通常包括交付日期2. 基于上述内容引入所需要的里程碑 例如：在交付之前做好系统测试3 列出第 1 次迭代 通常应该在功能上保持简单 好处：磨练自身的开发过程

7、4. 列出识别和规避风险的任务 从项目启动就开始5. 标出中期附近还没有分配任务的时间(例如，周)6. 完成时间表第三章 需求分析(一)本章讨论对于软件需求的整体分析。3.1.1 需求分析的含义要建造某个事物，必须首先了解这个“事物”是什么样子。了解并用文档描述这个事物的过程被称为“需求分析” 。需求通常表达应用是用来做什么的；需求分析的输出是一份文档，通常被称为需求规格说明书或者软件需求规格说明书(SRS)。3.1.2 C 需求和 D 需求将需求分为两个层次，第一层记录了客户的需要和要求，使用他们明白的语言进行描述。这个结果被称为“客户需求”或者“C 需求” 。C 需求的首要读者是客户群体，

8、其次是开发人员。第二层需求则按明确的、有组织的形式来记录。他们被称为“开发人员需求”或者“D 需求” 。D 需求的首要读者是开发人员，其次是客户群体。3.1.3 为什么必须书写需求没有这样的文档，小组无法真正了解需要完成的目标是什么，无法正确地检查产品，无法正确地测试产品，无法跟踪生产效率，无法获得足够的实践数据，无法估计下一项工作的规模和工作量，更无法满足客户的要求。3.1.4 典型的需求分析过程路线图1.识别“客户”2.访谈“客户代表” 识别需要和要求 使用工具帮助表达 绘制 GUI 草图 确定硬件环境3. 用标准文档格式撰写 C 需求4. 检查 C 需求（当客户批准后）5. 构建 D 需

9、求3.1.5 需求分析的挑战和益处使开发人员和客户将要开发的应用取得理解并达成一致。含有缺陷的需求将导致项目代价增加 20 到 50 倍。3.2 与客户交流3.2.1 需求的来源人是需求的唯一来源3.2.2 识别风险承担者对于项目的成果承担风险和享有利益的人被称做风险承担者。因此，它们是应用的“客户”：使用该软件的人，公司的业主，应用开发人员 etc.3.3 描述客户(C)需求3.3.2 用例需求通常可以被看成是应用和应用的外部代理(例如用户)之间的交互。用用例图可以描述。3.3.3 数据流图(为与客户沟通所用 )某些需求可以是很自然地描述为进程元素之间的数据流。在数据流图中，节点表示进程单元

10、，用圆形或者矩形表示。节点之间的箭头代表数据流，箭头上标注数据的类型。数据存储用一对水平的平行线表示，平行线之间是数据储存的名字，代表数据存放的位置。外部代理用矩形表示。3.3.4 状态变迁图（为与客户沟通所用）对于事件驱动型的应用，采用状态变迁图来描述是非常有效的。 （自动机和 Petri 网的变形）3.3.5 草拟用户界面的其它接口客户通常在看到应用的图形界面（GUI）时才能够想象这个应用未来的样子，所以帮助客户描述应用的一个好办法就是开发 GUI 的草稿。3.3.6 C 需求表述总结和指南1/2 如果需求涉及到用户和应用软件之间的交互，则通过用例进行描述1. 给用例命名。2. 识别用例的

11、“主角” 。 （外部的使用角色通常是一个人）3. 描述用户和应用的活动系列 尽量减少分支 使用通用的形式2/2 如果需求涉及到进程元素，并需要获得输入并产生输出，则使用数据流图进行描述。1. 识别进程元素（通常是概要的）：使用圆形或者矩形表示2. 识别数据的来源和去向：使用位于一对平行线之间的名称来表示3. 在进程之间标识数据的流向，说明每个数据的类型 若需要涉及到应用软件的全部状态（或者部分状态）1. 识别状态 （每个状态通常都是一个动词的被动形式）：使用圆角的矩形来表示。2. 用特殊的箭头标识初始状态3. 识别引起状态变迁的事件（指模块外部发生的事情）：使用带有标识的箭头来表示它4. 识别

12、子状态：使用嵌套的矩形表示。3.4 应用于 C 需求的方法论、工具和网络有大量的方法论可以用于表述需求。这里仅给出关于其中一部分方法论的总结。 结构化分析给数据流和功能分解定义了正式的形式。特别是结构化分析和设计技术是处理体系规格的一种系统方法。结构化分析方法主要是从系统功能的角度来观察应用软件，这个功能视图最终将被分层的详细功能所实现； 实时系统可以通过状态变迁图得到有效的描述。3.5 快速原型、可行性研究和概念证明3.5.1 “快速原型”是对目标软件的部分实现，通常会涉及到重要的图形用户界面（GUI）部分。建立快速原型能够有效地获取客户的需求，并且识别和规避部分项目的风险。增进对客户真实需

13、求的充分理解能够省去因需求误会导致的昂贵的返工费用，并可提前消除未来可能引发的障碍。 （原型越详细，客户的需求就越容易被理解） 。3.5.2 可行性研究有些时候我们根本无法确定客户所提出的需求是否能够真正实现。换句话说，项目都存在一个整体风险，而不是若干集中于某些特定需求的风险。而且，如果这个风险成为现实的话，那么这个项目就变的不可行不值得开发。在这种情况下，就必须对项目进行可行性研究第四章 需求分析(二)4.1 详细 D 需求简介4.1.1 详细 D 需求的含义软件工程师基于一个基础来进行软件设计和实现，这个基础就是由详细需求构成的。它们也称为“细节需求” 、 “功能规格说明” 、 “面向开

14、发人员的需求”或者“D 需求” 。D 需求是一个系统所必须的详细属性和功能的完整列表，它描述了最终的需求细节。其中的每条需求都进行了编号、标识，并且在开发过程中始终保持跟踪。D 需求是从 C 需求扩展而来的，与 C 需求保持一致。4.1.2 D 需求分析的典型路线图 选择 D 需求的组织方式 根据用例生成序列图 3a. 从 C 需求中和客户处获得 D 需求 3b. 概述测试计划 3c. 核查 交由客户确认4.2 D 需求的类型1. 功能性需求 应用软件的功能2. 非功能性需求2.1 性能 速度 能力（通信速率） 储存占用 a. 内存，b. 硬盘2.2 可靠性和易用性2.3 出错性2.4 接口需

15、求应用软件与客户如何交互与其它应用如何接口2.5 限制 精确性 工具和语言限制 设计限制 采用标准 使用的硬件平台3. 反面需求反面需求说明软件不应该去做那些事情。从理论上说，反面需求应该有无数条，我们选择那些可以反面说明真正的需求，以及能够消除可能存在的误解的反面需求。4.3 D 需求的预期属性我们已知遗漏需求可能对项目造成巨大的影响。为了确保细节得到足够的覆盖，这里我们介绍 D 需求应该具备的属性。特别要注意， D 需求应该保持整体完整性和一致性。每一条需求都应该能够追溯到设计和实现，能够测试它们的正确性，而且按照恰当的优先顺序来实现这些需求。在实施质量评审时，我们将对需求的这些属性进行评

16、审和检查。4.3.1 跟踪功能性需求把需求隐射到相关的设计和实现模块中的能力称之为“可追塑性” 。实现这种映射的方法之一是将每条功能性需求对应到目标语言的具体函数中。随着项目的发展，需求文档需要与设计和实现部分保持一致。有些时候为了满足一条需求做出的修改可能会影响到其它需求的实现。正是因为这种多对多的关系非常难以管理，所以我们要设法在需求和函数之间一一映射。4.3.1.2 跟踪非功能性需求（可以是性能要求）上述讨论关注的是功能性需求。设计阶段的目标之一是把每一条非功能性需求对应到单独的设计元素中。对于性能需求，需要去测试速度最慢的处理单元。为了确认非功能性需求，需要把每条需求和一份测试计划联系

17、起来，并最好是在撰写需求的时候进行这个工作。4.3.2 可测试性和清晰性一条需求必须能够通过测试加以验证，表明该需求得到了正确的实现。只有当一个 D需求描述的清晰而且没有二义性，我们才能肯定它是否被正确地实现4.3.3 优先级通常很难按照进度实现应用软件计划的预算的全部需求。如果进度、成本预算和质量水平都不能变动的话，惟一选择就是改变产品的能力，即：削减预计实现的部分需求。选择那些需求进行削减的过程是有计划地进行的。其中的一种技术就是划分详细需求的优先级别。但是通常区分所有需求的优先级往往会很浪费时间，所以，很多组织把需求分为三个类别（有时是四个）：“基本的” 、 “希望的”和“可选的” 。首

18、先我们要确保项目实现“基本的”需求。需求的优先级会影响到设计，因为希望的和可选的需求通常暗示了应用软件发展的方向。4.3.4 完整性我们尽力想要使每一条详细需求保持独立，但是在现实中这是不可能的，因为一个需求常常要提到其它需求。一个需求集合的完整性是指该集合中不存在会对集合中所叙述的需求造成危害的遗漏情况。4.3.5 出错条件对于每一条需求，我们都要思考如果它在错误的环境下实现时会发生什么事情。良好的需求分析应该能够正确处理“非法”输入。4.3.6 一致性一组 D 需求是一致的，指的是它们之间没有矛盾冲突。但是随着 D 需求的数量的增长，保持它的一致性将会变得越来越困难。可以按照面向对象的方式

19、来组织需求避免不一致性，面向对象的方式把 D 需求划分为若干类。4.3.7 总结详细需求的撰写过程撰写一条详细需求（1）1.把需求归类于功能性或者非功能性的 IEEE SRS 提示了大部分非功能性需求 选择组织功能性需求的方法2. 详细的控制规模 一条功能性需求基本对应于类中的一个方法 过大：难以管理 过小：不值得单独跟踪3.尽量保持可追溯性 确保适于跟踪至设计和实现4. 使之可被测试 草拟测试要点，用于确认需求得到满足撰写一条详细需求（2）5. 确保需求含义清晰、不模糊 意图不会被误解6. 划定需求的优先级 例如：最高（“最基本的” ） ；最低（“可选的” ） ；中等（“希望的” ）7. 检

20、查需求集合的完整性 对每条需求，确保其它必要的相关需求都已经包括在集合之中8. 包含出错条件 说明非正常情况的具体特征 包括关键位置的编程错误9. 检查一致性 确保每条需求不会对其它任何需求的任何方面造成矛盾备注：1 关于需求的组织方法在开始撰写 D 需求之前就必须确定下来2 评估一条需求是否可追溯就是构想该需求的设计并且想象设计如何能够满足这条需求。如果这条需求直接对应类中的一个方法，那么这种追溯性的评估最为简单。3 它有助于在撰写需求的同时概括描述该需求的测试要点。这样不仅能够使需求的含义更加清晰，而且还可以检查需求是否可测试4 很多需求依赖于特定的数据，因此我们需要指出当输入数据错误或者

21、不一致的情况下这条需求应该如何处理。对于关键需求，还应该包括由于低劣的设计和编程引起的错误4.4 序列图序列图是对控制流的一种图形化表示方法，对于表示用例的执行步骤尤其有用。并且序列图除了可以用于进行需求分析，如本章所描述，还可以通过更详细的形式来用于设计。序列图要求我们用对象的角度进行思考。在序列图中，每个所涉及的对象的生命周期都分别用一条垂直的实线来表示，实线的顶端标有对象的名称和它所属的类的名称。对象之间的每次交互则通过一条带有箭头的水平线来表示，这条带箭头的线把呼叫服务的对象和提供服务的对象连接起来。 （操作：表示由箭头线起点的对象发起并由箭头线终点的对象承担的工作。通常操作在设计阶段

22、都会转化为一个具体的函数）在需求分析阶段，序列图只是用于识别关键的类。4.4 组织 D 需求的方式4.5.1 组织详细需求的重要性随着需求的增长，未经组织的需求将会无法管理4.5.2 组织详细需求的方法主要来说，D 需求可以按照下面的几种方法进行组织： 根据“特性” （希望外界可以觉察到的服务，往往通过刺激反应这两方面来定义） 。这种方法就是通常所认为的按照“需求”进行组织的方式也就是说，需求根据应用软件可感知的特性来进行组织。不过请注意，这种组织方式并没有真正提供任何系统的组织方式，因为它允许应用软件某个部分的特性跳到另一个完全不同的部分的特性。组织详细需求的途径： 根据“模式” （比如：雷达系统可能有训练、正常和紧急三种模式） 根据“用例” （有时也称做“场景” ） 。这种方法是统一软件过程推荐的需求组织方式。 根据“类” 。这是一种面向对象的分类方法，使用这种组织方式，我们可以把需求划分成各个类。 根据“功能的分层结构” （即：把应用软件分解成一组高层的功能集合，继而又把它们分解成为子功能集合，以此类推） 。这种方法就是传统地给详细需求按顺