软件设计师——软件工程学习笔记
软件工程
一、软件工程基础知识
1. 软件的生存周期
（1）可行性分析与项目开发计划。这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有 可行性分析报告、项目开发计划。
（2）需求分析。该阶段的任务不是具体的解决问题，而是要确定软件系统要做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档主要是 软件需求说明书。
（3）概要设计。该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块层次结构是怎样的，调用关系是怎样的，每个模块的功能是什么。参与该阶段的人员有系统分析师、软件设计师。产生的文档主要是 概要设计说明书。
（4）详细设计。该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。参与该阶段的人员有软件设计师、程序员。产生的文档主要是 详细设计文档。
（5）编码。把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的 源程序 清单。
（6）测试。测试是保证软件质量的重要手段。参加测试的人员通常是另一部门（或单位）的软件设计师或系统分析师。产生的文档主要是 软件测试计划、测试用例、测试报告。
（7）维护。软件维护是软件生存周期中时间最长的阶段。软件已交付且正式投入使用后，便进入维护阶段。对软件进行修改的原因包括：①运行中发现隐含的错误而需要修改；②为了适应变化的（或变化后的）工作环境而修改；③需要对软件功能进行扩充、增强而进行的修改；④为将来软件维护活动做预先准备。
2. 软件过程
1．能力成熟度模型（CMM）
| 能力等级 | 特点 | 关键过程区域（KPAs） |
|---|---|---|
| 初始级 | 过程不可预测、缺乏控制，依赖个人能力。 | |
| 可重复级 | 基本项目管理能力建立，可跟踪成本、进度和功能。 | 需求管理、项目计划、项目跟踪与监督、配置管理、质量保证、子合同管理。 |
| 已定义级 | 过程标准化、文档化，组织级一致性增强。 | 同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程集点 |
| 定量管理级 | 过程可量化控制，质量与性能可预测。 | 定量过程管理、软件质量管理。 |
| 优化级 | 持续改进，缺陷预防与技术创新。 | 过程变更管理、技术变更管理、缺陷预防。 |
2．能力成熟度模型集成（CMMI）
CMMI提供了两种表示方法：阶段式模型和连续式模型。
（1）阶段式模型。结构类似于CMM，它关注组织的成熟度。CMMI-SE/SW/IPPD 1.1版本中有五个成熟度等级。
（2）连续式模型。关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（简称CL）。CMMI中包括六个过程域能力等级。
二、软件开发模型
1. 瀑布模型与V模型
瀑布模型
瀑布模型将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。如同瀑布流水逐级下落，如图所示。
以文档作为驱动、适合于软件需求很明确的软件项目，或者二次开发(需求稳定)
缺点：必须完整、正确和清晰地表达需要
V模型
瀑布模型的一个变体是V模型
V模型特点是增加了很多轮测试，并且这些测试贯穿于软件开发的各个阶段，不像其他模型都是软件开发完再测试，很大程度上保证了项目的准确性。V模型开发和测试级别对应如下图：
2. 演化模型（原型模型和螺旋模型）
演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。
原型
与瀑布模型相反，原型 针对的就是需求不明确的情况，首先快速构造一个功能模型，演示给用户看，并按用户要求及时修改，中间再通过不断的演示与用户沟通，最终设计出项目，就不会出现与用户要求不符合的情况，采用的是迭代的思想。不适合超大项目开发。
原型模型又根据使用目的的不同，分为探索型原型、实验型原型和演化型原型。
探索型原型用于快速验证需求或概念的可行性，通常出现在项目早期阶段。这类原型聚焦于核心功能或用户痛点的模拟，忽略细节实现，帮助团队明确方向。
实验型原型针对特定技术或设计假设进行验证，例如性能测试、算法可行性或新材料应用。通过可控实验收集数据，为决策提供依据。
演化型原型以迭代方式逐步完善，最终形成正式产品。每个版本在用户反馈和技术优化的基础上持续改进，常见于敏捷开发或MVP策略。
螺旋模型
螺旋模型将瀑布模型和演化模型结合起来，增加了风险分析，特别适用于庞大、复杂并且具有高风险的系统。
需要开发人员具有相当丰富的风险评估经验和专门知识。
3. 增量模型
增量模型：首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付，但由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品,而原型的构造一般是为了演示。
4. 喷泉模型
喷泉模型是以用户需求为动力、以对象为驱动的模型。适用于面向对象的开发方法，克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。
缺点：需要大量的开发人员，要求严格管理文档。
5.统一过程（UP）模型
统一过程（UP）模型是一种“用例和风险驱动，以架构为中心，迭代并增量”的开发过程，由UML方法和工具支持。
统一过程的典型代表是RUP，RUP是UP的商业扩展，完全兼容UP，比UP更完整、更详细。
6.敏捷方法
敏捷方法的总体目标是通过“尽可能早地、持续地对有价值的软件进行交付”使客户满意。适用于：适合小项目小团队，“小步快跑”的思想。
敏捷方法的核心思想主要有以下三点：
①敏捷方法是“适应性”而非“预设性”的。
②敏捷方法是以人为本，而不是以过程为本。
③迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。RUP相比，敏捷方法的周期可能更短。敏捷方法在几周或者几个月的时间内完成相对较小的功能，强调的是能尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，并且更加强调团队中的高度写作。
**敏捷软件开发宣言：**相对于过程和工具，更强调个人和交互；相对于严格的文档，更重视可工作的软件；相对于合同谈判，更注重与客户的合作；相对于遵循计划，更专注于对变化的响应。
常用的方法：极限编程（XP）、水晶法（Crystal）、并列争球法（Scrum）、自适应软件开发（ASD）、敏捷统一过程（AUP）。
极限编程（XP）
因为知道计划永远赶不上变化，XP 无需开发人员在软件开始初期做出很多的文档。XP提倡 测试先行，为了将以后出现bug的几率降到最低。
