软件工程
软件工程
软件工程的基本要素：方法、工具、过程。
生命周期
信息系统的生命周期：
| 系统规划 | 初步调查、分析系统目标、子系统组成、 拟实施方案、可行性研究、制定系统建设方案 |
可行性研究报告、系统设计任务书 |
| 系统分析 | 业务流程分析、数据与数据流程分 析、软件需求分析、网络需求分析 |
系统需求规格说明书、软件需求规格说明书、 确认测试计划、系统测试计划、初步的用户手册 |
| 系统设汁 | 软件架构设计、软件概要设计、 详细设计、网络设计 |
架构设计文档、概要设计说明书、 详细设计说明书、程序规格说明书、 概要测试计划、详细测试计划、 各类设计图 |
| 系统实现 | 设备采购测试、软件编码、 软件单元/集成/系统测试、综合布线 |
源码、单元测试、集成测试报告、操作手册 |
| 系统运行和维护阶段 |
成熟度模型
CMM 能力成熟模型
| 能力等级 | 特 点 | 关键过程区域 |
|---|---|---|
| 初始级 (Initial) |
软件过程的特点是杂乱无章，有时甚至 很混乱，几乎没有明确定义的步骤，项 目的成功完全依赖个人的努力和英雄式 核心人物的作用。 | |
| 可重复级 (Repeatable) |
建立了基本的项目管理过程和实践来跟 踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功 。 | 软件配置管理、软件质量保证、 软件子合同管理、软件项目跟踪 与监督、软件项目策划、软件需 求管理 |
| 已定义 (Defined) |
管理和工程两方面的软件过程已经文档 化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程 来发和维护软件。 | 同行评审、组间协调、软件产品 工程、集成软件管理、培训大纲、 组织过程定义、组织过程集点 |
| 已管理 (Managed) |
制定了软件过程和产品质量的详细度量标准。对软件过程和产品质量有定量的理解和控制。 | 软件质量管理和定量过程管理 |
| 优化级 (Optimized) |
加强了定量分析，通过来自过程质量反 馈和来自新观念、新技术的反馈使过程 能不断持续地改进。 | 过程更改管理、技术改革管理和 缺陷预防 |
CMMI
能力成熟度模型集成CMMI是若干过程模型的综合和改进，不仅仅软件，而是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。
| 能力等级 | 特点 | 关键过程区域 | |
|---|---|---|---|
| 初始级 | 过程不可预测且缺乏控制 | 组织的成功依赖于组织内人员的个人 | |
| 已管理级 | 过程为项目服务 | 在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需 | 有目标、有过程。 可重复 |
| 已定义级 | 过程为组织服务 | 在这一等级，企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化 | 标准化、制度化、文档化 |
| 定量管理 | 过程已度量和控制 | 组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别3级与4级的关键区别在于对过程性能的可预测。组织级改革与实施、因果分析和解决方案 | 量化、可预测 |
| 优化级 | 集中于过程改进和优化 |
DCMM
数据管理能力成熟度评估模型
【DCMM的8个核心能力域】定义了数据战略、数据治理、数据架构、数据应用、数据安全、数据质量、数据标准和数据生存周期等。
| 成熟度等级 | 描述 |
|---|---|
| 优化级【L5】 | 数据被认为是组织生存和发展的基础，相关管理流程能实时优化， 能在行业内进行最佳实践分享 |
| 量化管理级【L4 | 数据被认为是获取竞争优势的重要资源，数据管理的效率能量化分析和监控 |
| 稳健级【L3】 | 数据当作绩效目标的重要资产，在组织层面制订了标准化管理流程，促进数据管理规范化 |
| 受管理级【L2】 | 组织意识到数据是资产，根据管理策略的要求制订管理流程，有 相关人初步管理 |
| 初始级【L1】 | 数据需求管理是项目级体现，没有统一管理流程，被动式管理 |
软件开发模型
瀑布模型
【特点】
严格区分阶段，每个阶段因果关系紧密相连 （上一阶段的输出作为下一阶段的输入）
只适合需求明确的项目
瀑布模型是一个线性顺序模型，支持直线开发。它假设当线性序列完成之后就能交付一个完善的系统，并没有考虑软件的演化特征。其优点是强调开发的阶段性、早期计划及需求调查和产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做什么，有利于项目管理。
【缺点】
- 软件需求的完整性、正确性等很难确定
- 瀑布模型是一个严格串行化的过程模型，很长时间才能看到结果。 需求或设计中的错误往往只有到了项目后期才能够被发现
- 瀑布模型要求每个阶段一次性完全解决该阶段工作，这不现实。
演化模型、原型模型
原型模型主要有以下两个阶段。
原型开发阶段。
目标软件开发阶段。
从原型是否实现功能来分，可分为水平原型和垂直原型两种。
- 水平原型也称为行为 原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是 功能的导航，但并未真实实现功能。水平原型主要用在界面上；
- 垂直原型也称为结构化 原型，实现了部分功能。垂直原型主要用在复杂的算法实现上。
从原型的最终结果来分，出现了抛弃型原型和演化型原型。
- 抛弃型原型是将原型作为需求确认的手段，在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发。
- 演化性原型是在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。原型的概念也被后续出现的过程模型采纳，如螺旋模型和敏捷方法。
特点：
原型法可以使系统开发的周期缩短、成本和风险降低、速度加快，获得较高的综合开发效益。
原型法是以用户为中心来开发系统的，用户参与的程度大大提高，开发的系统符合用户的需求，因而增加了用户的满意度，提高了系统开发的成功率。
由于用户参与了系统开发的全过程，对系统的功能和结构容易理解和接受，有利于系统的移交，有利于系统的运行与维护。
要有一定的开发环境和工具支持、管理水平要求高。
由以上的分析可以看出，原型法的优点主要在于能更有效地确认用户需求。从直观上来看，原型法适用于那些需求不明确的系统开发。
对于分析层面难度大、技术层面难度不大的系统，适合于原型法开发。
V模型
单元测试对应详细设计。也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；
集成测试对应概要设计。在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；
系统测试对应需求分析，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。
验收测试与用户需求对应，是非设计流程。
W 模型
W模型增加了软件各开发阶段中应同步进行的验证和确认活动
W模型由两个V字型模型组成，分别代表测试与开发过程。W模型中测试与开发对应关系如下：
螺旋模型
螺旋模型 （Spiral Model）是在快速原型的基础上扩展而成。 将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。
螺旋模型沿着螺线进行若干次迭代，每次迭代都包括制订计划（目标设定）、风险分析、实施过程和客户评估4 个方面的工作
螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。
快速应用开发 RAD
RAD 模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发 （ 瀑布模型 + 构件 ）
RAD 的开发流程：业务建模， 数据建模、过程建模、应用生成、测试与交付。
RAD 也具有以下局限性：
（1）并非所有应用都适合RAD 。RAD对模块化要求比较高，如果有哪一项功能不能被模块化，那么 RAD 所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则 RAD 也有可能不能奏效。
（2）开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致RAD项目失败。
（3）RAD 只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统要与现有系统有较高的互操作性时，就不适合使用RAD 。
增量模型
首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。
特点：
- 不是从系统整体角度规划各个模块，因此不利于模块划分。
- 难点在于如何将客户需求划分为多个增量。
- 与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示。
喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程
智能模型
智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在一起
基于构件的开发模型CBSD
利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
ＲＵＰ统一过程模型
ＲUP是基于构件的，在为软件系统建模时，ＲUP 使用的是UML
RUP描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。RUP类似一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。
RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，如下：
业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
分析与设计：把需求分析的结果转化为分析与设计模型。
实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
测试：检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
（非核心工作流）
配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
RUP把软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段如下。
构思阶段（初始/初启阶段）：定义最终产品视图和业务模型、确定系统范围。
细化阶段（精化阶段）：设计及确定体系架构、制定工作计划及资源要求。
构造阶段：开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试。
移交阶段：确保软件对最终用户是可用的，进行β测试，制作产品发布版本。
RUP的特点：
- 用例驱动：需求分析、设计、实现和测试等活动都是用例驱动的。
- 以体系结构为中心：包括系统的总体组织和全局控制、通信协议等。是一个多维的结构，会采用多个视图来描述。 也就是典型的4+1视图模型中：
- 迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程；每次迭代是在己完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。
4 + 1 视图
敏捷模型
极限编程（ XP）
4大价值观：沟通【加强面对面沟通】、简单【不过度设计】、反馈【及时反馈】 、勇气【接受变更的勇气】
功用驱动开发方法（FDD）
FDD 定义了6种关键的项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。根据项目大小，部分角色可以重复。
编程开发人员分成两类：首席程序员和“类”程序员。
FDD 有5个核心过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建。其中，计划特征开发根据构造出的特征列表、特征间的依赖关系进行计划，设计出包含特征设计和特征构建过程组成的多次迭代。
水晶系列方法
其目的是发展一种提倡“机动性的”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践。
探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。
并列争球 （ SCRUM ）
ASD方法： 其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。
动态系统开发方法(DSDM ： 倡导以业务为核心。
开放式源码：程序开发人员在地域上分布很广【其他方法强调集中办公】。
逆向工程
实现级：包括程序的抽象语法树、符号表、过程的设计表示。
结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型、部署图、状态图。
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。
- 重构/重组（restructuring）。重构是指在【同一抽象级别】上转换系统描述形式。
- 设计恢复（design recovery）。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息
- 逆向工程（reverse engineering）：逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。
- 正向工程（forward engineering）。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。
- 再工程/重构工程（Re-engineering）。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。
