《软件工程课堂笔记精简版ppt课件》由会员分享，可在线阅读，更多相关《软件工程课堂笔记精简版ppt课件（16页珍藏版）》请在金锄头文库上搜索。
1、CH01 软件和软件工程软件和软件工程1.软软件件的的特特点点：软件是设计开发的，而不是传统意义上生产制造的；软件不会磨损，但是会退化；多数软件仍是根据实际顾客需求定制的；在软件设计中，大规模的复用才刚刚开始。2.IEEE对软软件件工工程程的的定定义义：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件；上述方法的研究。3.软件工程层次图：工具-方法-过程-质量关注点4.通用软件工程过程框架软件工程过程框架包括5个活动：沟通；策划；建模；构建；部署。5. 软件神话：它实际上是误导了管理者和从业人员对软件开发的态度，从而引发了严重的问题。管理神话：管理神话：神
2、话：我们已经有了一本写满软件开发标准和规程的宝典。它无所不包，囊括了我们可能问到的任何 问题。现实：这本宝典也许的确已经存在，但不能保证它已在实际中采用、反映了软件工程的现状、可以适 应不同应用环境、在缩短交付时间的同时还关注保证产品的质量等等。神话：如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度。现实：新人加入一个软件项目后，原有开发人员必须牺牲本来的开发时间对新人进行培训，减少了应 用于高效开发的时间。神话：如果我将一个软件外包给另一家公司，则我可以完全放手不管。现实：如果开发团队不了解如何在内部管理和控制软件项目，那在外包项目中都会遇到困难。客户神话：客户神话：神话：有了
3、对项目目标的大概了解，便足以开始编写程序，可以在之后的项目开发过程中逐步充实细 节。现实：虽然通常难以得到综合全面且稳定不变的需求描述，但对项目目标模糊不清的描述将为项目实 施带来灾难，只有客户和开发人员之间保持持续有效的沟通才能得到清晰的需求描述。神话：虽然项目需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。现实：软件需求的变更引入时机不同，变更造成的影响也不同，如提出的较早，则费用影响较小，但 随着时间的推移，变更的代价也迅速增加，因为资源已经分配，设计框架已经建立，此时变更可能会 引起剧变，需要添加额外的资源或修改主要设计架构。从业者神话：从业者神话：神话：当我们完成程序并
4、将其交付使用之后，我们的任务就完成了。现实：软件首次交付顾客使用之后花费的工作更多。神话：对于一个成功的软件项目，可执行程序是惟一可交付的成果。现实：软件配置包括很多内容，可执行程序只是其中之一。各种工作产品（如模型、文档、计划）是成功实施软件工程的基础，为软件技术支持提供了指导。神话：软件工程将导致我们产生大量无用文档，并因此降低工作效率。现实：软件工程并非以创建文档为目的，而是为了保证软件产品的开发质量。CH02 过程模型过程模型1. 瀑布模型瀑布模型 经过的活动：沟通：项目启动、需求获取。策划：项目估算、进度计划、项目跟踪。建模：分析、设计。构建：编码、测试。部署：交付、支持、反馈。优优
5、缺缺点点：它提供了一个模板，使得分析、设计、编码、测试与维护工作可以在该模板的指导下有序地展开，避免了软件开发、维护过程中的随意状态。对于需求确定、变更相对较少的项目，线性顺序模型仍然是一种可以考虑采取的过程模型。采用这种模型，曾经成功地进行过许多大型软件工程的开发。存在问题：（为什么瀑布模型有时候会失效？）实际项目很少严格遵守该顺序。客户通常难以清楚描述所有需求。只有到项目接近尾声时，才有可执行程序。3. 增量模型：增量模型：经过的活动经过的活动：第一个增量模型往往是核心部分的产品，它实现了软件的基本需求，但很多已经明晰或者尚不明晰的补充特性还没有发布。每个增量的开发可用瀑布或快速原型模型。
6、和原型模型不一样的是，增量模型虽然也具有“迭代”特征，但是每一个增量都发布一个可操作的产品，不妨称之为“产品扩充迭代”。它的早期产品是最终产品的可拆卸版本，每一个版本都能够提供给用户实际使用。优缺点优缺点：优点：能在较短时间内向用户提交可完成部分工作的产品。用户有较充裕的时间学习和适应新产品。易于保证核心功能正确。可以基于早期版本来获取需求。项目完全失败的风险小。可以为那些创新的功能开拓市场。规避了资源缺乏的风险。缺点：把用户需求转化为功能递增的不同版本可能比较难。以确定所有版本共需的公用模块。存在问题：如果你的客户要求你在一个不可能完成的时间提交产品，向他建议只提交一个或几个增量，此后再提交
7、软件的其他增量。增量和原型的比较：任何增量的处理流程均可结合原型实现；增量模型与原型相同，本质上都是迭代的；增量模型强调每个增量都是可操作的；早期的增量是整体的一部分，而原型最终要被抛弃。4. 原型开发：原型开发：经过的活动： 沟通快速策划建模快速设计构建原型部署交付及反馈(组成一个圆圈)优缺点优缺点：优点：用户能够感受到实际系统；开发者能很快建造出一些东西。存在问题：开发者没有考虑整体软件质量和长期的可维护性；开发者往往在实现过程中采用折中的手段。客户提出了一些基本功能，但未详细定义输入、处理和输出需求；开发人员可能对开发运行环境、算法效率、 操作系统的兼容性和人机交互等情况不确定。这些情况
8、下，采用原型开发。对于要求把一个粗糙的原型系统变为工作产品的压力，建议尽量抵制。这样做的结果往往是产品质量受到损害。5. 螺旋模型螺旋模型经过的活动：（五个关键词形成一个螺旋）沟通。策划：项目估算、制定进度计划、风险分析；建模：分析、设计。构建：编码、测试。部署：交付、反馈。优优缺缺点点：随着过程进展演化，开发者和客户能够更好地理解和对待每个演化级别上的风险，适合于大型系统及软件的开发。使用原型实现作为降低风险的机制，并在开发的任意阶段均可使用原型实现。更真实的反映了现实世界。如应用得当，能在风险变成问题之前降低它。模型的成功依赖于风险评估的专门技术。是一个较新的模型，功效的确定尚需若干年时间
9、。存在问题：很难说服客户演进的方法是可控的。依赖大量的风险评估专家保证成功，如果风险没被发现，会发生问题。6.协协同同开开发发模模型型：定义一系列事件，触发软件工作活动、动作或者任务的状态转换。更适合于client/server应用。定义一个过程网络活动代替一个事件的序列。7.各种模型的比较各种模型的比较：8.统一过程统一过程（UPUnified Process）：宗旨：用例驱动，以架构为核心，迭代并且增量。统一过程的阶段：起始阶段包括客户沟通和策划活动。细化阶段包括沟通和通用过程模型的建模活动。构建阶段与通用软件过程中的构建活动相同。转换阶段包括通用构建活动的后期阶段以及通用部署（交付和反馈
10、）活动的第一部分。生产阶段与通用过程的部署活动一致。5个过程并非顺序进行，而是阶段性并发进行。例题：以下情况下应该采用什么过程模型？例题：以下情况下应该采用什么过程模型？（1）客户不太清楚待开发的系统需要提供什么服务。答：原型（2）开发团队了解待开发软件的相关领域知识，尽管此系统庞大，但其较已经开发的系统差异并不大。答：瀑布（3）软件的功能是把读入的浮点数开平方，所得到的结果应该精确到小数点后4位。答：瀑布（4）开发一个已发布软件的新版本，公司规定了严格的完成期限，并对外公布。答：增量（5）汽车防锁死刹车控制系统。答：螺旋（6）大学记账系统，准备替换一个已存在的系统。答：瀑布（7）一个位于火车
11、站的交互式火车车次查询系统。答：原型CH03 敏捷开发敏捷开发1.敏敏捷捷的的概概念念：它是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进的开发软件。特别适用于web应用开发。2.敏捷原则敏捷原则：通过尽早、持续交付有价值的软件来使客户满意。即使在开发后期，也欢迎需求变更。经常交付可工作软件。业务人员和开发人员必须在一起。围绕受激励的个人构建项目。最有效的信息传递方法是面对面交谈。3.敏敏捷捷的的特特点点：工作软件是进度的首要度量标准。提倡可持续的开发速度。不断关注优秀的技能和设计。简单是必要的。好的架构、需求和设计出于自组织团队。定期反省，并相应调
12、整自己的行为。允许项目团队调整并合理安排任务；理解敏捷开发方法的易变性并制定计划；精简并维持最基本的工作产品；强调增量交付策略；快速向用户提供适应产品和运行环境的可运行软件。4.极限编程极限编程 XP（eXtreme Programming）为实施XP的全部工作定义了五个有重要意义的要素：沟通、简明、反馈、鼓励和尊重。策划：建立一系列描述待开发软件必要特征与功能的“故事”评估每一个故事（即优先级），并给出以开发周数为度量单位的成本客户和XP团队共同决定如何把故事分组并置于将要开发的下一个发行版本中（下一个软件增量）形成关于一个发布版本的基本承诺在第一个版本发布之后，XP团队计算项目的速度。对待
13、开发的故事排序方法：所有选定故事在几周内尽快实现；具有最高权值的故事移到进度表前面先实现；高风险故事将首先实现。项目速度：第一个发行版本中实现的客户故事个数。用于后续发行版本的发布日期和进度安排，调整软件发型内容和最终交付日期。设计严格遵循KIS(Keepitsimple)原则鼓励使用CRC卡，CRC（类-责任-协作者）卡确定和组织与当前软件增量相关的面向对象的类。在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现并评估设计原型（被称为Spike解决方案)鼓励“重构”，重构是以不改变代码外部行为（如函数的输入输出）而改进内部结构（如函数实现方法）的方式来修改软件系统的过程。重构实
14、质就是在编码完成之后改进代码设计。编码在编码之前，确定检测本次发布的所有故事的单元测试鼓励结对编程，这提供了实时解决问题和实时保证质量的机制。连续集成策略，有助于避免兼容性和接口问题。测试每天进行测试“验收测试”由客户确定，根据本次软件发布中所实现的用户故事而确定。5.工业极限编程工业极限编程 IXP是XP的一种有机进化。更大的包容性、扩大用户角色、升级技术实践。6.其其他他敏敏捷捷过过程程模模型型：自适应软件开发（ASD）。Scrum。精益开发（LeanDevelopment）。动态系统开发方法（DSDM）。特征驱动开发FDD。水晶开发（CristalClear）。CH04/05/06 需求
15、工程需求工程1. 需需求求工工程程过过程程（RERequirement Engineering）通过执行7个活动来实现：起始、导出、精化、协商、规格说明、确认、管理。起始阶段的工作：确认共同利益者（直接或间接地从正在开发的系统中获益的人）、识别多种观点、协同合作、Q&A会议P68.2.CRC（类类-责责任任-协协作作者者）建建模模，提供了一个简单方法，用于识别和组织与系统或产品需求相关的类。CRC模型实际上是表示类的标准索引卡片的集合。3.创建分析模型时应该遵循的经验原则创建分析模型时应该遵循的经验原则：模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。需求模型的每个元素都应能
16、增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入理解。关于基础结构和其他非功能的模型应推延到设计阶段再考虑。最小化整个系统内的联系。确认需求模型为所有利益相关者都带来价值。尽可能保持模型简洁。4.给类分配职责时建议一下给类分配职责时建议一下5个指导原则：个指导原则：只能系统应分布在所有类中以求最佳地满足问题的需求。每个职责的说明应尽可能具有普遍性。信息和与之相关的行为应放在同一类中。某个事物的信息应局限于一个雷中而不要分布在多个类中。适合时，职责应由相关类共享。5.数据流图DFGData Flow DiagramCH07 设计概念设计概念0.抽象：抽象：过程抽象是指具有明确和有限
17、功能的指令序列；数据抽象是描述数据对象的冠名数据集合。部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。1.模块化模块化：将系统划分为相对独立但又有所关联的多个部分。按照设计原则将系统划分为若干个较小的模块：相互独立但又相互关联。实际上是系统分解和抽象的过程。模块是相对独立的程序体是数据说明、可执行语句等程序对象的集合。单独命名的，并且可以通过名字来访问例如：类、过程、函数、子程序、宏等。模块化就是把程序划分成独立命名且可直接访问的模块，各个模块完成一个子功能，这些模块集成起来构成一个整体，完成指定功能。对于一个给定的系统，合适的模块数量是多少？结论：适度的模块化模块数增
18、加时，模块间的关系也随之增加，接口和集成的工作量也随之增加。结论：寻找最佳模块化程度平衡点。模块化设计的好处：模块化设计（以及由其产生的程序）使开发工作更易于规划；可以定义和交付软件增量；更容易实施变更；能够有效的开展测试和调试；可以进行长期维护而没有严重的副作用。2.信息隐蔽信息隐蔽每个模块都尽量对其他模块隐藏自己的内部实现细节：模块内部的数据和过程不允许其它不需要这些信息的模块使用。定义和实施对模块的过程细节和局部数据结构的存取限制。典型的信息隐藏：面向对象的访问控制符。信息隐藏是实现抽象/模块化机制的基本支撑。信息隐蔽的目的：将数据结构和处理过程的细节隐蔽在模块接口之后。用户不需要了解模
19、块内部的具体细节。3.功能独立功能独立：功能独立是模块化、抽象概念和信息隐藏的直接结果。功能独立的表现：内聚度与耦合度内聚(cohesion)：一个模块内部各个元素彼此结合的紧密程度尽量高耦合(coupling)：模块之间相互关联的程度尽量低功能独立的好处：易开发，易维护和测试，减少错误扩散，易复用。4.重重构构：为简化设计而进行的重组。使用这样一种方式改变软件系统的过程：不改变代码设计的外部行为而是改变其内部结构。5.接接口口设设计计的的 3 个个重重要要元元素素：用户界面(UI)。和其他系统、设备、网络或其他的信息生产者或使用者的外部接口。各种设计构件之间的内部接口.。接口定义：是类、构件
20、或其他分类的外部可见的（公共的）操作说明，而没有内部结构的规格说明。包括：一组描述类的部分行为的操作和提供操作的访问方法。6.组织良好的设计类的四个特征：完整性与充分性、原始性、高内聚性、低耦合性。CH08 体系结构设计体系结构设计1.体体系系结结构构概概念念：系统的一个或多个结构，它包括软件构件、这些构件对外可见的属性以及它们之间的相互关系。2.体体系系结结构构风风格格：1)以数据为中心的体系结构适用于可重用构件库、大型数据库、搜索引擎等。2)数据流体系结构3)调用和返回体系结构适用于分组交换网络中或给予活动者的系统中。4) 面向对象体系结构5)层次体系结构3.使用数据流进行体系结构映射使用
21、数据流进行体系结构映射：1)变换型数据处理。2)事务型数据处理。3)混合型数据处理。4.变换映射变换映射是一组设计步骤，可以将具有变换流特征的DFD映射为某个特定的体系结构风格。CH09 构件级设计构件级设计1.构构件件的的概概念念：OMG统一建模语言规范的定义：系统中模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口。构件包括一组协作的类，也可以包含一个单独的类。设计构件的细构件的细化：不断补充类的全部属性和操作。2.设计基于类的构件1)基本设计原则基本设计原则(基于类)：开开闭闭原原则则OCP：模块应该对外延具有开放性，对修改具有封闭性，即不应把变更写入代码，从而不必进入代码
22、内部修改。Liskov 替换原则替换原则ISP：子类可以替换它们的基类。用在有继承时判断有无滥用继承。依赖倒置原则依赖倒置原则DIP：依赖于抽象，而非具体实现接口分离原则接口分离原则ISP：多个用户专用接口比一个通用接口要好。降低接口间的耦合度。2)内聚性内聚性：一个模块（构件）内部各成分之间相互关联程度的度量。级别排序：功能内聚功能内聚：一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据。分层内聚分层内聚：高层能访问低层的服务，但低层不能访问高层的服务。通信内聚通信内聚：访问相同数据的所有操作被定义在一个类中。3)耦合性耦合性：构件之间联系的紧密程度，面向对象：类间联系的紧密
23、程度。级别排序： 内内容容耦耦合合：包括(1)一个模块直接访问另一个模块的内部数据，如GOTO跳转；(2)一个模块不通过正常入口转到另一模块内部；(3)两个模块有一部分程序代码重迭(只可能出现在汇编语言程序中)；(4)一个模块有多个入口。共用耦合共用耦合（公共耦合）：大量构件都要使用同一个全局变量。控制耦合控制耦合：一个模块通过传送开关、标志、名字等控制信息，控制选择另一模块的功能。标记耦合标记耦合：类B被声明为类A某一操作中的一个参数类型。数据耦合数据耦合：操作需要传递长串的数据参数。例程调用耦合例程调用耦合：一个操作调用另一个操作。类型使用耦合类型使用耦合：构件A中使用了在构件B中定义的一
24、个数据类型。包含或者导入耦合包含或者导入耦合：构件A引入或者包含一个构件B的包(java)或者内容(C语言)时。外部耦合外部耦合：两个构件共享数据格式，通信协议或设备接口。程序设计语言（程序设计语言（PDL）也成为结构化语言或伪代码。基本的PDL语法应该包括多种构造：构建定义、接口描述、数据声明、块结构、条件结构、重复结构和I/O结构。CH14 软件测试策略软件测试策略1.测试策略测试策略（4个阶段与开发阶段的对应关系，围成一个螺旋）(单元测试-编码)-（集成测试-设计）-（确认测试-需求）-（系统测试-系统工程）2.什么时候完成测试完成测试：1)永远不能完成，测试的工作只会从软件工程师身上转
25、移到最终用户身上。用户每次运行程序时，程序就在经受测试。2)当时间或资金不够时，测试就结束了。3)利用统计建模和软件可靠性理论，建立以执行时间为函数的软件故障模型。3.集集成成测测试试1)一次性组装测试2)深度组装测试/增值组装测试：自顶向下&自底向上3)混合增值组装测试4)回回归归测测试试：重新执行已进行测试的某个子集，以确保变更没有传播不期望的副作用。只针对关键模块。关键模块的特征：涉及几个软件需求；在程序的模块结构中位于较高层次；较复杂、较易发生错误；有明确定义的性能要求。5) 冒冒烟烟测测试试的好处：降低集成风险；提高最终产品的质量；简化错误的诊断和修正；易于评估进展状况。4.测测试试
26、和和测测试试（会区分）测试是由一个用户在开发环境下进行的测试，也可以是公司内部用户在模拟实际操作环境下进行的测试。测试在受控环境下进行。测试是由软件的多个用户在实际使用环境下进行的测试。测试在一个或多个最终用户场所进行，与测试不同，开发者通常不在场。5.系系统统测测试试的概念：将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。6.独立测试组（ITG）的作用是为了避免开发人员进行测试所引发的固有问题。独立测试可以消除利益冲突。CH15/16 测试传统的测试传统
27、的/面向对象的应用系统面向对象的应用系统1.白盒测试白盒测试：把测试对象看做一个透明盒子，测试人员了解程序的内部结构。2.基基本本路路径径测测试试：程序环路复杂性：环路复杂度=最少独立路径数=域的数量。环复杂性V(G)=P+1，其中P为包含在流图G中的简单判定结点数。3.黑黑盒盒测测试试：把测试对象看做一个黑盒子，测试人员不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。主要发现以下错误：不正确或遗漏的功能；接口错误；数据结构或外部数据库访问错误；行为或性能错误；初始化和终止错误。1)等等价价类类划划分分：把所有可能的输入数据，即程序的输入域划
28、分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例。2)等等价价类类划划分分有有2种种情情况况：有效等价类：对程序的规格说明来说是合理的，有意义的输入数据构成的集合。无效等价类：对程序的规格说明来说是不合理的，无意义的输入数据构成的集合。3)边边界界值值分分析析：一种黑盒测试方法，对等价类划分的补充。大量的错误是发生在输入或输出范围的边界上，所以采取边界值分析。4.类级的划分测试类级的划分测试基于状态划分就是根据它们改变类状态的能力对类操作进行分类；基于属性划分就是根据它们所使用的属性对类操作进行分类。CH18/19 项目管理项目管理1.管理涉及范围管理涉及范围：4P：人员，产品
29、，过程，项目。利益相关者利益相关者：高级管理者，项目技术管理者，开发人员，客户，最终用户。软软件件团团队队类类型型：封封闭闭范范型型（难以创新）、随随机机范范型型（松散）、开开放放范范型型（适合复杂问题）、同同步步式式范范型型（组员各自解决问题的一部分）。2.W5HH原则原则：WHY、WHAT、WHE、WHO、WHERE、HOW、HOWMUCH。3.了解LOC（面向规模的度量）、FP（面向功能的度量）及其LOC&FP相互调和相互调和。4.测量量质量量：软件质量的事后度量，包括正确性、可正确性、可维护性、完整性、可使用性性、完整性、可使用性。1)正确性的度量是KLOC的差错数；2)可维护性的度量
30、必须采取间接度量，通过平均变更等待时间MTTC来度量；3)完整性度量一个系统抗拒对它的安全性攻击的能力，完整性=1-危险性*(1-安全性)，其中危险性是特定类型的攻击将在一给定时间内发生的概率，安全性是排除特定类型攻击的概率；4)可使用性依据 4 个特征进行度量：为学习系统所需要的体力上和智力上的技能；为达到适度有效使用系统所需要的时间；当软件被某些人适度有效使用时所度量的在生产率方面的净增值；用户角度对系统的主观评价。5.缺缺陷陷排排除除效效率率：DRE=E/(E+D)，其中E是软件交付给最终用户前发现的错误数；D是交付后发现的错误数。CH20 软件项目估算软件项目估算软件规模估算：软件规模
31、估算：如果采用直接的方法，规模可以用代码行（LOC）来测量；如果采用间接的方法，规模可以用功能点（FP）来表示。不同估算之间差别大的原因不同估算之间差别大的原因：（1）计划人员没有充分理解或是误解了项目范围。（2）在基于问题的估算技术中所使用的生产率数据不适合本应用系统，过时了，或者是误用了。COCOMOII 模型模型构造性成本模型构造性成本模型CH21 项目进度安排项目进度安排1.软件项目进度安排的基本指导原则：指导原则：划分；相互依赖性；时间分配；工作量确认；确定责任；明确输出结果；确定里程碑。2.人员与工作量之间的关系人员与工作量之间的关系：通过在略微延长的时间内使用较少的人员，可以实现
32、同样的目标。3.进度计划评估及评审技术（PERT）和关关键键路路径径方方法法（CPM）就是两种可以用于软件开发的项目进度安排方法。4.项目跟踪项目跟踪可以通过以下方法实现：定期举行项目状态会议；评估在软件工程过程中所进行的所有评审的结果；判断正式的项目里程碑是否在预定日期内完成；比较项目表中列出的各项任务的实际开始日期与计划日期；与开发人员进行非正式会谈，获取他们对项目进展及可能出现的问题的客观评估；通过挣值分析来定量的评估项目进展。5.挣值、获得值分析挣值、获得值分析EVA：计算：工作预计成本BCW：每项工作任务的预计工作量。所计划的工作的预计成本BCWS：计划按指定时间完成的每项工作任务的
33、预计工作量之和。完成预算BAC：BCW的总量，是项目总工作量的估计。计划值EV=BCWS/BAC。所完成工作的预计成本BCWP：已经按指定时间完成的工作任务的预计工作量之和。所完成工作的实际成本ACWP：已经完成的工作任务的实际工作量之和。完成的百分比EV=BCWS/BAC。进度性能指标SPI=BCWP/BCWS进度偏差SV=BCWP-BCWS成本性能指标CPI=BCWP/ACWP成本偏差CV=BCWP-ACWPCH22 风险风险定义定义：具有负面后果、人们不希望发生的事件。两两个个特特征征：1不确定性：可能发生，也可能不发生。事件发生的概率称为风险概率，当概率为1时，风险变成了必然发生的问题
34、，不再称为风险。2损失：具有负面后果，是不希望发生的事与风险有关的损失称为风险影响应对策略应对策略：主动-被动风险类型风险类型：项目风险项目风险：威胁到项目计划(拖延项目进度和增加成本)预算、进度、人员、资源、利益相关方、需求技术风险技术风险：威胁到软件的质量及交付时间设计、实现、接口、验证和维护商业风险商业风险：威胁到软件的生存能力市场、策略、销售、管理、预算已知风险：通过仔细评估项目计划、开发项目的商业及技术环境、以及其他可靠的信息来源之后可以发现的风险可预测风险：能够从过去项目的经验中推断出来不可预测风险：可能会出现，但很难事先识别出它们来风险显露度：风险显露度：RE=P*CP为风险发生概率，C为风险发生时带来的项目成本条件-转化-结果（CTC）可按如下方式对这个一般条件进行求精：子条件1：某些可复用构件是由第三方开发的，没有内部设计标准相关资料。子条件2：构件接口的设计标准尚未确定，有可能和某些现有的软件可复用构件不一致。子条件3：某些可复用构件是采用不支持目标环境的语言开发的。风险缓解、监测和管理计划RMMM计划
