软件设计师——软件工程学习笔记

软件工程

一、软件工程基础知识

1. 软件的生存周期

（1）可行性分析与项目开发计划。这个阶段主要确定软件的开发目标及其可行性。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档有 可行性分析报告、项目开发计划。
（2）需求分析。该阶段的任务不是具体的解决问题，而是要确定软件系统要做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。参与该阶段的人员有用户、项目负责人、系统分析师。产生的文档主要是 软件需求说明书。
（3）概要设计。该阶段开发人员把确定的各项功能需求转换成需要的体系结构。概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块层次结构是怎样的，调用关系是怎样的，每个模块的功能是什么。参与该阶段的人员有系统分析师、软件设计师。产生的文档主要是 概要设计说明书。
（4）详细设计。该阶段的主要任务是对每个模块的功能进一步详细、具体的描述。参与该阶段的人员有软件设计师、程序员。产生的文档主要是 详细设计文档。
（5）编码。把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的 源程序 清单。
（6）测试。测试是保证软件质量的重要手段。参加测试的人员通常是另一部门（或单位）的软件设计师或系统分析师。产生的文档主要是 软件测试计划、测试用例、测试报告。
（7）维护。软件维护是软件生存周期中时间最长的阶段。软件已交付且正式投入使用后，便进入维护阶段。对软件进行修改的原因包括：①运行中发现隐含的错误而需要修改；②为了适应变化的（或变化后的）工作环境而修改；③需要对软件功能进行扩充、增强而进行的修改；④为将来软件维护活动做预先准备。

2. 软件过程

1．能力成熟度模型（CMM）

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的几率降到最低。

三、软件开发方法

四、需求分析

一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。

需求分析阶段的产物：软件需求规格说明书（SRS）

1. 结构化的需求分析

结构化特点：自顶向下，逐步分解。
面向数据三大模型：功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图)以及数据字典

2. 需求分类

3. 需求分析工具

数据流图（DFD）

DFD的基本图形元素：外部实体、加工、数据存储、数据流。

层次结构：顶层图、0层图、底层图、父图、子图。
DFD的审查

（1）一致性：父图与子图平衡、数据守恒、具备数据存储、输出不能与输入同名。
（2）完整性：奇迹（无入有出）、黑洞（有入无出）、灰洞（无法出）。

数据字典（DD）

数据字典有以下4类条目：数据流、数据项、数据存储和基本加工。(源点和终点不再系统之内，不在字典中说明)

逻辑描述方法

常用的加工逻辑描述方法有结构化语言、判定表和判定树3种。

1. 结构化语言采用接近自然语言的格式，但通过限制词汇和句式确保逻辑清晰。通常分为顺序、选择（IF-THEN-ELSE）和循环（WHILE-DO）三种结构，适合描述具有明确步骤或分支的业务规则。
2. 判定表通过表格形式列举所有条件组合及对应动作，适用于条件复杂且存在多分支的场景。表格分为条件桩（条件列表）、动作桩（动作列表）和规则（条件与动作的映射）。
3. 判定树以树形结构展示条件与动作的层级关系，直观呈现逻辑分支路径。节点表示条件，分支表示条件取值，叶子节点表示动作，适合可视化复杂决策过程。