自考软件工程思维导图02333
2021-05-28 14:01:17 15 举报AI智能生成
自考软件工程思维导图02333是一款专为自考软件工程专业的学习者设计的思维导图工具。它以清晰、直观的方式展示了软件工程的各个关键概念和知识点，帮助学习者更好地理解和记忆这些内容。此外，该思维导图还包含了大量的实例和练习题，可以帮助学习者通过实践来巩固和应用所学知识。总的来说，自考软件工程思维导图02333是一款非常实用的学习工具，无论你是正在准备自考软件工程考试，还是想要提升自己的软件工程技能，都可以从中获益。
作者其他创作
大纲/内容
软件工程
第一章 绪论
软件工程概念的提出与发展
软件危机
软件生产率、软件质量远远满足不了社会发展的需求，成为社会、经济发展的制约因素。
目的
倡导以工程的原理、原则和方法进行软件开发，以期解决出现的“软件危机”
含义
将科学理论和知识应用于实践的科学
定义
是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究的学科
发展时期
20世纪60年代末到80年代初
主要成果
瀑布模型
过程式语言
开发方法
开发一些支持工具
主要特征
前期主要研究系统实现技术，后期则开始关注软件质量和软件工程管理
20世纪80年代
围绕对软件工程过程的支持，开展了一系列有关软件生产技术，特别是软件复用技术和软件生产管理的研究和实践
提出了《软件生存周期过程》等一系列软件工程标准
开展了计算机辅助软件工程的研究和实践
面向对象语言
面向对象软件开发方法
工程管理方面，开展了一系列过程改进项目
软件开发的本质
计算机软件
指计算机系统中的程序及其文档
程序是计算机任务的处理对象和处理规则的描述
文档是为了理解程序所需的阐述性资料
软件是对一个特定问题域的抽象，是被开发出来的一个逻辑实体，不是一种有形的物理部件
本质
不同抽象层术语之间的“映射”，以及不同抽象层处理逻辑之间的“映射”
两个方面问题
如何实现这样的映射
两大技术
一是过程方向，即求解软件的开发逻辑
二是过程途径，即求解软件的开发手段
如何管理这样的映射
软件系统模型
概念模型
软件模型
设计模型
实现模型
部署模型
小结
软件开发的基本途径
基本途径为问题建模，常见的建模手段有：结构化方法、面向对象方法以及诸多面向数据结构方法等。
系统建模
运用所掌握的知识，通过抽象，给出该系统的一个结构-系统模型。
模型
待建模系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节
第二章 软件需求与软件需求规约
需求与需求获取
需求定义
需求是有关一个“要予构造”的陈述，描述了一个产品/系统应该具有的功能、性能和其他性质
单一一个需求具有5个基本性质
必要的，该需求是用户所要求的
无歧义的，该需求只能用一种方式解释，如何保险证无歧义的用到需求复审
可测的，该需求是可进行测试的
可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段
可测量的，该需求是可测量的
需求分类
功能需求
功能需求规约了系统或系统构件必须执行的功能
非功能需求
性能需求
性能需求规约了一个系统或系统构件在性能方面必须具有的一些特性
外部接口需求
规约了系统或系统构件必须与交互的用户、硬件、软件或数据库元素，其中也可能规约交互格式、时间或其他因素
设计约束
限制了软件系统或软件系统构件的设计方案的范围
质量属性需求
规约了软件产品所具有的一个性质必须达到其质量方面一个所期望的水平
功能需求与非功能需求的关系
功能需求是整个需求的主体
非功能需求可做用于一个或多个功能需求
需求发现技术
初始需求发现常用技术
自悟
交谈
观察
小组会
提炼
实际应用中需要注意3点
依据需求工程人员的技能和产品、合同的实际情况，往往需要“组合”地使用这些技术来开发初始需求
在任意特意的环境中，在实施上述任何一项技术时，还都可以辅以诸如原型构造等其他方法
执行需求发现这项活动的人，其技能水平将对这项活动的成功具有重大影响
需求规约
是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型
4个基本特性
重要性和稳定性
可修改的
完整性
没有被遗漏的需求
一致性
不存在互斥的需求
3种表达风格
非形式化的需求规约
半形式化的需求规约
形式化的需求规约
作用
需求规约是软件开发组织和用户之间的一份事实上的技术合同书，是产品功能及其环境的体现
对于项目的其余大多数工作，需求规约是一个管理控制点
对于产品/系统的设计，需求规约是一个正式的、受控的起始点
需求规约是创建产品验收测试计划和用户指南的基础。即基于需求规约一般还会产出另外两个文档-初始测试计划和用户系统操作描述
第三章 结构化方法
结构化需求分析
基本术语
数据流
数据定义为客观事物的一种表示，把信息定义为具有特定语义的数据。数据是信息的载体。数据流是数据的流动
加工
数据的变化单元，即它接受输入的数据，对其进行处理，并产生输出
数据存储
数据的静态结构
数据源和数据谭
数据源是数据流的起点；数据谭是数据流的归宿地
系统功能模型表示
一种表达功能模型的工具，即数据流图，简称DFD图
使用DFD图表达功能模型时注意的3个问题
在DFD图中，数据流起到连接其他实体的作用，及数据流可以从一个加工流向另一个加工；可以从数据源流向加工，或从加工流向数据谭；可以从加工流向数据存储，或从数据存储流向加工。在应用中，数据流和数据存储一般需要给出标识，而对流入或流出数据存储的数据流，在语义比较清晰的情况下，一般可以和不给出它们的标识
加工之间可以有多个数据流，这些数据流之间可以没有任何直接关系，数据流图也不表明它们的先后次序。
对于一个比较大的软件系统，为了避免由于采用一张DFD图来描述系统功能而出现的层次不清、难以理解的情况，往往需要采用多层次的数据流图。
建模过程
建立系统环境图，确定系统语境
自顶向下，逐步求精，建立系统的层次数据流图
定义数据字典
定义其中包含了的所有数据流和数据存储的数据结构，有3种基本结构，分别为顺序结构、选择结构、重复结构
描述加工
目标为依据系统的数据流图，给出其中每一个加工的小说明
3种表达工具
结构化自然语言
一个加工的输入数据和输出数据之间的逻辑关系比较简单
判定表
一个加工的输入数据和输出数据之间的逻辑关系比较复杂
判定树
应用中注意的问题
一个加工必须既有输入又有输出
必须准确地定义数据流和数据存储
必须准确地描述每一个叶加工，说明输入数据流与输出数据流之间的逻辑关系
需求验证
为什么需要需求验证
软件系统中15%的错误起源于错误的需求
结构化设计
结构化设计分为总体设计和详细设计
总体设计
两个基本概念
模块：既指软件中具有特定标识的独立成分
模块调用：指模块之间的一种使用关系
模块结构图两种基本类型
变换型数据流图
具有较明显的输入部分和变换（或称主加工）部分之间的界面、变换部分和输出部分之间界面的数据流图，称为变换型数据流图
数据变换是这一数据处理模型的核心
事务性数据流图
数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列（称为一个事务）中选一个出来执行，这类数据流图称为事务性数据流图
设计步骤
如何将需求分析所得到的系统DFD图映射为设计层面上的模块和模块调用
在分类DFD的基础上，基于自顶向下、功能分解的原则，定义了两种不同的“映射”，即变化设计和事物设计
基本步骤
首先将系统的DFD图首先转化为初始的模块结构图
再基于“高内聚低耦合”这一软件设计原理，通过模块化，将初始的模块结构图转换为最终的、可供详细设计使用的模块结构图（MSD）
3个阶段
初始设计
在对给定的数据流图进行复审和精化的基础上，将其转换为初始的模块结构图
变化设计步骤
第1步：设计准备--复审并精化系统模型
第2步：确定输入、变换、输出这三部分之间的边界
第3步：第一级分解--系统模块结构图顶层和第一层的设计，变换型数据流图所对应的软件结构有一个主模块以及有它控制的三个部分组成。
主模块位于顶层，一般以所建系统的名字为其命名
输入模块
变换模块
输出模块
第4步：第二级分解--自顶向下，逐步求精，为每一个输入模块、输出模块和变换模块设计它们的从属模块
输入模块细化，一般可以把它分解为“一个输入模块和一个变换模块”
变化模块细化，没有通用方法，依据情况进行分解
输出模块细化，如果输出模块不是一个物理输出，通常分解为两个下属模块：一个将得到的数据向输出形式进行转换，另一个是将转换后的数据进行输出
事物设计步骤
第2步：确定事务处理中心
第3步：第一级分解--系统模块结构图顶层和第一层设计
第4步：第二级分解--自顶向下，逐步求精
精化设计
依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口
复审阶段
对前两个阶段所得到得高层软件结构进行复审，必要时还可能需要对该软件结构做一些精化工作，这对软件的一些性质，特别是对软件质量的提高将产生非常大的影响
模块化及启发式规则
精化设计的目标
基于模块\"高内聚低耦合\"的原则，提高模块的独立性
模块化
模块是执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成。一部分是接口，另一部分是模块体
结构化软件设计是一种典型的模块化方法，即把一个待开发的软件分解成若干简单的、具有高内聚低耦合的模块，这一过程称为模块化。模块化是系统设计基本原理/原则之一。
耦合
指不同模块之间相互依赖的程度的度量
耦合类型
内容耦合
当一个模块直接修改或操作另一个模块的数据，或一个模块不通过正常入口而转入到另一个模块。内容耦合是最高程度的耦合
公共耦合
两个或两个以上的模块共同引用一个全局数据项
控制耦合
一个模块通过接口向另一个模块传递一个控制信号，接受信号的模块依据信号值进行适当的动作
标记耦合
若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和C之间存在一个标记耦合
数据耦合
模块之间通过参数来传递数据，是最低的一种耦合形式
原则
如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，尽量避免使用内容耦合
内聚
指一个模块内部各成分之间相互关联程度的度量，应尽量使每个模块都具有高内聚，这样可以使模块的各个成分都和该模块的功能直接相关
内聚类型
偶然内聚
如果一个模块的各成分之间基本不存在任何关系，则称为偶然内聚
逻辑内聚
几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚
时间内聚
如果一个模块完成的功能必须在同一时间内执行，但这些功能只是因为时间因素关联在一起，则称为时间内聚
过程内聚
如果一个模块内部的处理成分是相关的，而且这些处理必须特定的次序执行，则称为过程内聚
通信内聚
如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚
顺序内聚
如果一个模块的各个成分和同一功能密切相关，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚
功能内聚
最理想的内聚是功能内聚，模块的所有的成分对于完成单一的功能都是基本的。功能内聚的模块对完成其功能而言是充分必要的。
启发式规则
改进软件结构，提高模块独立性。针对系统的初始模块结构图，在认真审查分析的基础上，通过模块分解或合并，改进软件结构，力求降低耦合，提高内聚，提高模块的独立性
力求模块规模适中
力求深度、宽度、扇出、扇入适中
深度
表示其控制的层数
深度往往能粗略地标志一个系统的规模和复杂度
宽度
指同一层次上模块总数的最大值
宽度越大系统越复杂，而对宽度影响最大的因素是模块的扇出
扇入
模块的扇入表明有多少个上级模块直接调用它
设计得和好的软件结构，通常顶层模块扇出比较大，中层模块扇出比较小，底层模块具有较大的扇入
扇出
一个模块直接控制的下级模块的数目
尽力使模块的作用域在其控制域之内。模块的控制域是指这个模块的本身以及所有直接或间接从属它的模块的集合。模块的作用域是指受该模块内一个判定所影响的所有模块的集合
尽力降低模接口的复杂度
力求模块功能可以预测
精化系统初始模块结构图使软件设计人员的一种创造性活动
详细设计
任务
给出软件模块结构中各个模块的内部过程描述，也就是模块内部的算法设计
目标
将总体设计阶段所产生的系统高层结构映射为以这些术语所表达的低层结构，也是系统的最终结构
详细设计工具
程序流程图
3种基本控制结构
顺序
选择
循环
盒图(N-S)图
PAD图
类程序设计语言
第四章 面向对象UML
UML是统一建模语言
面向对象方法是一种根据客体之间的关系来建造系统模型的系统化方法
UML引入了8个术语，类与对象、接口、协作、用况、主动类、构件、制品、节点
为了增强对客体语义的表达，UML还引入一些特定的机制，多重性、限定符等
为了描述事物之间的相互依赖和相互作用，即为了表达各类事物之间的关系，UML给了4个术语，关联、泛化、实现、依赖
两类术语统称模型化概念
UML术语表
表达客观事物的术语
类与对象
类是一组具有相同属性、操作、关系和语义的对象的描述
对象是类的一个实例
可见性
+公有的
#受保护的
-私有的
~包内的
类在建模中的主要用途
模型化问题域中的概念（词汇）
建立系统的职责分布模型
模型化建模中使用的基类类型
接口
接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务
协作
协作是一个交互，涉及交互的三要素：交互各方、交互方式、交互内容
用况
用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果
主动类
主动类是一种至少具有一个进程或线程的类。主动类能够启动系统的控制活动，并且，其对象的行为通常是与其他元素行为并发的
构件
构件是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现
制品
制品是系统中包含物理信息的、可替代的物理部件
节点
节点是运行时存在的物理元素
表达关系的术语
关联
关联是类目之间的一个结构关系，是对一组具有相同结构、相同链的描述
一个关联只连接了两个类目，称为二元关联，如果一个关联连接n个类目，称为N元类目
关联名
关联可以有一个名字，用于描述该关联的一定内涵
导航
对于一个给定的类目，可以找到与之关联的另一个类目，这就是导航
角色
角色是关联一端的类目对另一端类目的一种呈现
多重性
类中对象参与一个关联的数目
聚合
表达的是一种整体/部分关系
组合
关联类
泛化
泛化是一般性类目(超类或父类)和它的较为特殊类目(子类)之间的一种关系
细化
细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约
依赖
依赖是一种使用关系，用于描述一个类目使用另一个类目的信息和服务
关联、泛化和细化都是一类特定的依赖
UML的模型表达格式
UML图形化工具分两类
结构图
用于表达系统或系统成分的静态结构模型
行为图
用于表达系统或系统成分的动态结构模型
UML通过图形化工具，支持建模人员从不同抽象层和不同视角来创建模型
类图
类图是可视化表达系统结构模型的工具，通常包含类、接口、关联、泛化和依赖
用况图
USE CASE图支持系统功能的建模，交互图支持系统交互的建模，状态图支持系统生存周期的建模
用况图通常包含6个模型元素，它们是主题、用况、参与者、关联、泛化、依赖
主题
主题是由一组用况所描述的一个类，矩形就是一个主题。在主题中所包含的用况描述了该主题的完整行为
用况表达了参与者使用系统的一种方式
参与者
参与者表达了一组高内聚的角色
关联、泛化与依赖
关联是操作者和用况之间的唯一关系
状态图
强调了从一个状态到另一状态的控制流
UML把状态分成3类，初态、终态和通常状态
顺序图
表达交互行为的顺序图，就应该有能力表达交互各方、交互方式以及交互内容
消息
消息用于表达交互内容的术语
异步消息用枝形箭头线表示
同步用实心三角箭头表示
同步消息回复用枝形箭头虚线表示
对象生命线
对象生命线用于表示一个对象在一个特定时间段中的存在
聚焦控制
聚焦控制用于表达一个对象执行一个动作的时间段
第五章 面向对象方法RUP
软件开发方法学的3部分组成
用于表达基本信息的术语
用于组织基本信息的表达格式
在不同抽象层之间进行映射的过程指导
RUP的特点
突出特点
是一种以用况为驱动的、以体系结构为中心的迭代、增量式开发
迭代、增量式开发
4个开发阶段
初始阶段
获得与特定用况和平台无关的系统体系结构轮廓
精化阶段
通过捕获并描述系统的大部分需求（一些关键的用况）
构造阶段
通过演化，形成最终的系统体系结构基线，开发完整的系统
移交阶段
确保有一个实在的产品发布给用户群。
核心工作流
需求获取
RUP采用use case技术来获取需求。其目标是：使用UML中的用况、参与者以及依赖等术语来抽象客观实际问题，形成系统的需求获取模型
列出候选目标
收取特征
理解系统语境
捕获系统功能需求
创建系统用况模型的活动
P133
需求分析
为了支持系统分析，RUP引入了的术语
分析类
分析包
用况细化
实体类
边界类
控制类
分析工作流
P146
用况模型和分析模型
用况模型
使用客户语言来描述
给出的是系统对外的视图
使用用况予以结构化，但给出的是外部视角下的系统结构
可以作为客户和开发者之间关于“系统应该做什么、不应该做什么的契约”
在需求之间可能存在一些冗余、不一致和冲突等问题
捕获的是系统功能，包括在体系结构方面具有意义的功能
定义了一些进一步需要在分析模型中予以分析的用况
分析模型
使用开发者语言来描述
给出的是系统对内的视图
使用衍型类予以结构化，但给出的是内部视角下的系统结构
可以作为开发者理解系统如何勾画、如何设计和如何实现的基础
在需求之间不应再存在冗余、不一致和冲突等问题
给出的是细化的系统功能，包括在体系结构方面觉有意义的功能
定义了用况模型中每一个用况的细化
设计
RUP设计层4个术语
设计类
用况细化[设计]
设计模型中的一个协作
协作工具
交互图
正文事件流
设计子系统
主要结果
系统的设计模型，它尽量保持该系统具有分析模型的结构，并作为系统实现的输入
设计模型和分析模型的比较
P166
设计阶段的活动
RUP的实现和测试
RUP的测试
内部测试
中间测试
最终测试
总结
RUP和UML的关系
UML作为一种可视化建模语言，给出了表达事物和事物之间关系的基本术语，给出了多种模型的表达工具
RUP利用这些术语定义了需求获取层、系统分析层、设计层、实现层，并给出了实现各层模型之间映射的基本活动以及相关的指导
第六章 软件测试
软件测试目标与软件测试过程模型
软件测试与软件调试对比，7个不同点
测试从一个侧面证明程序员的失败，调试是为了证明程序员的正确
测试以已知条件开始，使用预先定义的程序且有预知的结果，不可预见的仅是程序是否通过测试。调试一般是以不可知的内部条件开始，除统计性调试外，结果是不可预见的
测试是有计划的，并且进行测试设计。调试是不受时间约束的。
测试是一个发现错误、改正错误、重新测试的过程。调试是一个推理过程
测试的执行是有规程的。调试的执行往往要求程序员进行必要推理
测试经常是由独立的测试组在不了解软件设计的条件下完成的。调试必须由了解详细设计的程序员完成
大多数测试的执行和设计可由工具支持。调试时，程序员能利用的工具主要是调试器。
软件测试是一个有序的过程
测试设计
测试执行
测试结果
软件测试技术
两大类
白盒测试技术，又称为结构测试技术，典型的是路径测试技术。白盒测试技术依据的是程序的逻辑结构
黑盒测试技术，又称为功能测试技术，包括事务流程技术、状态测试技术、定义域测试技术等。黑盒测试技术依据的是软件行为描述
测试用例
为了发现程序中的故障而专门设计的一组数据或脚本
路径测试技术
路径覆盖。执行所有可能穿过程序控制流程的路径
语句覆盖。至少执行程序中所有语句一次。
分支覆盖。至少将程序中每一个分支执行一次
条件覆盖与条件组合覆盖。
条件覆盖指每个判定中的所有可能的条件取值至少执行一次。
条件组合覆盖指的是设计足够的测试用例，使每个判定中的所有可能的条件取值至少执行一次
测试覆盖的强度
语句覆盖≤分支覆盖≤条件组合覆盖≤路径覆盖
基于事务流的测试技术
基于事务流的测试技术是一种功能测试技术
其他功能测试技术简述
等价类划分
建立等价类表
为有效等价类设计测试用例
未无效等价类至少设计一个测试用例
边界值分析
因果图生成测试用例
用过软件规格说明书的分析，找出一个模块的原因（即输入条件或输入条件的等价类）和结果（即输出条件），并给每个原因和结果赋予一个标识符。
分析原因与结果之间以及原因与原因之间对应的关系，并画出因果图。
在因果图上标识出一些特定的约束或限制条件。
把因果图转化为判定表
把判定表的每一列拿出来作为依据，设计测试用例。
软件测试步骤
合理的测试序列
单元测试>集成测试>有效性测试和系统测试
单元测试
主要校验软件设计的最小单元--模块，该测试以详细设计文档为指导。单元测试往往采用白盒测试技术
由于模块不是一个独立程序，必须为每个模块单元测试开发驱动模块和承接模块
驱动模块模拟“主程序”接受测试用例的数据
承接模块代替被测试模块的下属模块
集成测试
软件组装的一个系统化技术，其目标是发现与接口有关的错误
有效性测试
目标是发现软件实现的功能与需求规格说明书不一致的错误
第七章 软件生存周期过程与管理
软件生存周期过程概述
软件生存周期分为3类
基本过程
基本过程指那些与软件生产直接相关的活动集
分为5个过程
获取过程
供应过程
开发过程
运行过程
维护过程
支持过程
支持过程是指有关各方按他们的目标所从事的一系类相关支持活动集。
分为8个过程
文档过程
配置管理过程
质量保证过程
验证过程
确认过程
联合评审过程
审计过程
问题解决过程
组织过程
组织过程指那些与软件生产组织有关的活动集
分为4个过程
管理过程
基础设施过程
培训过程
改进过程
ISO/IEC 12207-2002
ISO/IEC 12207-2008
过程描述
软件验证过程
意图
证实一个过程或项目的每一个软件工作产品/服务是否正确反应了规约的需求
验证是通过提供的客观证据，证实规约的需求是否得以满足的
软件确认过程
证实所期望使用的软件工作产品是否满足其需求
确认软件产品是否满足其期望的使用
测试软件产品是否适合已选择的目标环境
剪裁
成功实施剪裁过程的结果
为达到一个生存周期模型的意图和结果，定义了经修改的生存周期过程
软件生存周期模型
瀑布模型将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作。形如瀑布流水，最终得到软件产品
这一模型规定了各开发阶段的活动，并且自上而下具有相互衔接的固定顺序；还规定了每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段
各开发阶段的活动
系统需求
软件需求
编码
测试
运行
演化模型
螺旋模型
增量模型
是一种非整体开发模型。软件在该模型中是“逐渐”被开发出来的，软件开发出一部分，就向用户展示一部分，可让用户及早看到部分软件，及早发现问题。或者先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。瀑布模型是一种整体开发模型。在开发过程中，用户看不到软件是什么样子，只有开发完成后，整个软件才全部展现在用户面前。这时如果用户发现有不满意的地方，为时已晚。增量模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。
优点
能在较短的时间内向用户提供一些已完成的且有用的工作产品。
逐步增加的产品功能使用户有充足时间学习适应新产品。 使用增量模型应注意：在把每个新的构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
允许增量投资，即在项目开始时可以仅对一个或两个增量投资
缺点
喷泉模型
过程规划与管理
选择适合项目的生存周期模型的步骤
标识开发项目可用的SLCM。其中应考虑组织中可用的支持SLCM的管理系统和工具
在所期望的最终系统和开发环境中，标识那些会影响SLCM选择的属性
标识为选择生存周期模型所需要的任何约束，包括外部的或是内部的
基于以往的经验和组织能力，评估第一部所选择的那几个SLCM
选择最能满足项目属性和约束的SLCM
过程管理计划是项目管理计划的主体
过程管理计划是项目管理计划的主体，还可能存在一些对支持生存周期过程具有重要作用的其他计划
软件工程管理计划
软件配置管理计划
软件质量保证计划
软件验证和确定计划
软件度量计划
软件生存周期过程的监控
进展与进度的跟踪
质量数据趋势的检查
设计、编码和测试计划复审记录和动作的检查
变更要求和测试异常报告趋势的检查
关键资源的有效使用
与项目成员的交谈
第八章 集成化能力成熟度模型（CMMI）
3个CMM组合成一个过程改进框架
软件能力成熟模型 SW-CMM
系统工程能力模型 SECM
集成产品开发能力成熟度模型 IPD-CMM
CMMI的模型部件
CMMI是一个有关产品和服务的过程改善的成熟度模型，目的是改进组织的过程性能和成熟度，并改进这一程序的结果
CMMI的等级
能力等级
过程能力指遵循一个过程可达到的预期结果的程度
由一组适当的专用目标及其相关的专用实践，以及一个公共目标以及一些相关的共用实践组合的
6个能力等级
0 未完成级
1 已执行级
2 已管理级
3 已定义级
4 已定量管理级
5 持续优化级
成熟度等级
希望改善其开发过程和维护过程的组织提供了另外一个种过程改善路径，即成熟度等级。该路径可使组织通过关注一组过程域，不断改善一组相关的过程域
成熟度等级是由预先定义的一个过程域集以其相关的一些专用实践和共用实践组成
5个成熟等级
1 初始级
成熟度1级的组织，通常表现为一种倾向，即当遇到风险时，不守承诺，放弃过程，并且不能复制他们的成功经验
改进业务的3个质量支撑点
受训人员
规程和方法
工具
0 条评论
下一页
