目录
历年真题考情：本章节每年单项选择考13分左右，下文案例、论文也会有涉及，在系统架构设计师中本章节绝对是重点中的重点。
主要学习软件工程、需求工程、系统分析与设计、净室软件工程、基于构件的软件工程、软件项目管理等内容。很少涉及超纲题。
一、软件工程定义
1.1 软件开发生命周期
软件定义时期：包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标具体可分成问题定义、可行性研究、需求分析等。
软件开发时期：就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。
软件运行和维护：就是把软件产品移交给用户使用。
1.2 软件系统的文档
软件系统的文档可以分为用户文档和系统文档两类，用户文档主要描述系统功能和使用方法，并不关系这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。
1.3 软件工程过程
软件工程过程是指为获得软件产品包括以下4个方面活动：
1.P(Plan)--软件规格说明。规定软件的功能及其运行时的限制。
2.D(Do)--软件开发。开发出满足规格说明的软件。
3.C(Check)--软件确认。确认开发的软件能够满足用户的需求。
4.A(Action)--软件演进。软件在运行过程中不断改进以满足客户新的需求。
1.4 软件系统工具
通常可以按软件过程活动将软件工具分为：
软件开发工具：需求分析工具、设计工具、编码与排错工具、测试工具等。
软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择
1.5 软件设计
软件设计四个活动：数据设计、架构(体系结构)设计、人机界面(接口)设计和过程设计。
二、软件过程模型
软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个全过程称为软件的生命周期。软件生命周期描述了软件从生到死的全过程。
为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型被称为软件过程模型，有时也称之为软件生命周期模型。
2.1 瀑布模型
瀑布模型(SDLC)是一个经典的软件生命周期模型，是结构化开发方法使用的软件过程模型。
瀑布模型特点是因果关系紧密相连：
(1)前一个阶段工作的输出结果，是后一个阶段工作的输入。
(2)利用这一输入，实施该项活动应完成的工作内容。
(3)给出该项活动的工作成果，作为输出传给下一项开发活动。
(4)对该项活动的实施工作成果进行评审。若其工作成果得到确认，则继续进行下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件。
瀑布模型缺点是需求难以一次确定、变更的代价高、结果难以预见、各阶段工作不能并行。
2.2 原型模型
原型模型（Prototype Model）又称快速原型，第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。解决了瀑布模型需求难以一次确定、结果难以预见的缺点。原型模型有原型开发和目标软件开发两个阶段。
原型模型特点：
(1)实际可行。
(2)具有最终系统的基本特征。
(3)构造方便、快速，造价低。
(4)对用户的需求是动态响应、逐步纳入的。
原型模型后续也发生了一些演变，按照原型的作用不同，出现了抛弃型原型和演化性原型。抛弃型原型是将原型作为需求确认的手段，在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发。演化性原型是在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。原型的概念也被后续出现的过程模型采纳，如螺旋模型和敏捷方法。
2.3 螺旋模型
螺旋模型（Spiral Model）是在快速原型的基础上结合瀑布模型扩展而成。把整个软件开发流程分成多个阶段，每一个阶段都由目标设定、风险分析、开发和有效性验证、评审 4 部分组成。支持大型软件开发（庞大而复杂、高风险），适用于面向规格说明、面向过程和面向对象的软件开发方法，强调其他模型忽视的风险分析。
2.4 增量模型
增量模型（Incremental Model）是一种非整体开发的模型，它融合了瀑布模型的基本成分和原型实现的迭代特征。首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。
增量模型特点：
(1)非整体开发：增量模型不是一次性地完成整个软件开发，而是将软件划分为多个增量，逐步开发。
(2)搭积木的开发思想：每个增量都可以看作是一个独立的模块，通过组合这些模块来构建完整的软件产品。
(3)迭代开发：增量模型采用迭代的方式进行开发，每个增量都是对前一个增量的扩展和完善。
(4)可交付的增量：每个增量完成后，都可以作为一个可交付的产品版本，供用户使用和评估。
2.5 喷泉模型
喷泉模型（Fountain Model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。使开发过程具有迭代性和无间隙性。
2.5 基于构件的开发模型
基于构件的开发模型CBSD，利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
2.6 形式化方法模型
形式化方法模型，建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。
2.7 敏捷模型
敏捷模型（Agile Model）属于敏捷方法的模型。
开发宣言：个体和交互 胜过 过程和工具、可以工作的软件 胜过 面面俱到的文档、客户合作 胜过 合同谈判、响应变化 胜过 遵循计划。
敏捷方法区别于其他方法的两个特点：
(1)是“适应性”而非“预设性”。
(2)是“面向人的”而非“面向过程的。
敏捷方法的核心思想：
(1)敏捷方法是适应型，而非可预测型拥抱变化，适应变化。
(2)敏捷方法是以人为本，而非以过程为本。发挥人的特性。
(3)迭代增量式的开发过程。以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。
敏捷模型的主要敏捷方法：
(1)极限编程（XP）：高效、低风险、测试先行（先写测试代码，再编写程序）。
(2)水晶系列方法：不同的项目，采用不同的策略。
(3)并列争球法（Scrum）：该方法侧重于项目管理。Scrum 包括一系列实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。在 Scrum 中，使用产品 Backlog来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表。根据 Backlog 的内容，将整个开发过程分为若干个短的迭代周期（Sprint），在 Sprint 中，Scrum 团队从产品Backlog 中挑选最高优先级的需求组成 Sprint Backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。当所有 Sprint 结束时，团队提交最终的软件产品。
(4)特征驱动开发方法：该方法会将开发人员分类，分为指挥者（首席程序员）、类程序员等。
2.8 统一过程模型
统一过程模型(RUP)，描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP 类似个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
2.8.1 RUP的生命周期
RUP 软件开发生命周期是一个二维的软件开发模型，RUP 中有9个核心工作流。
(1)业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
(2)需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
(3)分析与设计：把需求分析的结果转化为分析与设计模型。
(4)实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
(5)测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
(6)部署：打包、分发、安装软件，升级旧系统;培训用户及销售人员，并提供技术支持。
(7)配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
(8)项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
(9)环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
RUP 把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段如下：
(1)初始阶段：定义最终产品视图和业务模型，并确定系统范围。
(2)细化阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
(3)构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
(4)移交阶段：把产品提交给用户使用。
RUP 中定义了如下一些核心概念，理解这些概念对于理解RUP 很有帮助。
(1)角色：Who 的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，如体系结构师、设计人员、实现人员、测试员和配置管理人员等，并对每一个角色的工作和职责都做了详尽的说明。
(2)活动: How 的问题。活动是一个有明确目的的独立工作单元。
(3)制品：What的问题。制品是活动生成、创建或修改的一段信息。
(4)工作流:：When 的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
2.8.2 RUP的特点
(1)用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的。
(2)以体系结构为中心：包括系统的总体组织和全局控制、通信协议等。是一个多维的结构会采用多个视图来描述。在典型的4+1视图模型中：
分析人员和测试人员关心的是系统的行为，会侧重于用例视图。
最终用户关心的是系统的功能，会侧重于逻辑视图。
程序员关心的是系统的配置、装配等问题，会侧重于实现视图。
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图。
系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。
(3)迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程;每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。
三、能力成熟度模型
3.1 软件能力成熟度模型
软件能力成熟度模型（Capability Maturity Model for Software，CMM）。CMM 是一个概念模型，模型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。
| 能力等级 | 特点 | 关键点 |
|---|---|---|
| 初始级(Initial) | 软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。 | 完全依赖个人的努力和英雄式核心人物的作用 |
| 可重复级(Repeatable) | 建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。 | 软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪与监督、软件项目策划、软件需求管理 |
| 已定义级(Defined) | 管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来发和维护软件。 | 同行评审、组间协调、软件产品工程、集成软件管理、培训大纲组织过程定义、组织过程集点 |
| 已管理级(Managed) | 制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。 | 软件质量管理和定量过程管理 |
| 优化级(Optimized) | 加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。 | 过程更改管理、技术改革管理和缺陷预防 |
3.2 软件能力成熟度模型集成
软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）。CMMI 是在 CMM 的基础上发展而来的。CMMI 提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成 5 个成熟度等级：初始级、已管理级、已定义级、量化管理级、优化级。量化管理级与已定义级的区别是对过程性能的可预测。
| 能力等级 | 特点 | 关键点 |
|---|---|---|
| 初始级 | 过程随意且混乱的 | 成功依赖于组织内人员的能力与英雄主义 |
| 已管理级 | 过程为项目服务 | 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 |
| 已定义级 | 过程为组织服务 | 需求开发、技术解决方案、产品集成、验证、确认组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 |
| 定量管理 | 过程已度量和控制 | 组织过程性能、定量项目管理 |
| 优化级 | 过程改进和优化 | 组织级改革与实施、因果分析和解决方案 |
原文链接：https://blog.csdn.net/g984160547/article/details/140095679
扫一扫
2209
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
