软件设计师中级总结（软件工程篇）

软件工程

1. 敏捷方法中，重构可以简化构件的设计而无需改变其功能或行为

2. 软件生存周期模型

   • 瀑布模型，适合于软件需求明确的软件项目

   • 演化模型，适合于对软件需求缺乏准确认识的情况

3. 软件开发的各个阶段

   可行性分析：判断软件是否应该做

   需求分析：确定软件要完成的功能及非功能要求

   概要设计：将需求转化为软件的模块设计，确定模块之间的调用关系（数据设计和接口设计）

   详细设计：将模块进行细化，得到详细的数据结构和算法

   编码：根据详细设计进行代码的编写，得到可以运行的软件，并进行单元测试

   测试：设计测试用例发现错误

   运行维护：根据需求变化或硬件变化对应用程序进行修改

4. 统一过程（UP）模型

   是一种以用例和风险为驱动、以架构为中心、迭代并且增量的开发过程，由UML方法和工具支持。

   • 初启阶段：专注于项目的初创活动
   • 精化阶段：理解了最初的领域范围之后，进行需求分析和架构演进
   • 构建阶段：关注系统的构建，产生实现模型
   • 移交阶段：关注于软件提交方面的工作，产生软件增量
   • 产生阶段：运行软件并监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求

   开发过程中有多次迭代，每次迭代包含：

   • 计划
   • 分析
   • 设计
   • 构造
   • 集成
   • 测试
   • 内部和外部发布

   每个迭代有五个核心工作流：

   • 需求工作流：捕获系统应该做什么
   • 分析工作流：精化和结构化需求
   • 设计工作流：在系统结构内实现需求
   • 实现工作流：构造软件
   • 测试工作流：验证是否如期望那样工作

5. 软件工程的基本要素包括：方法、工具和过程

6. 信息系统开发方法

   • 结构化方法：适用于开发在系统规模不大且不复杂，需求变化也不大的软件
   • 原型化方法：适用于开发用户需求不清晰且经常变化的软件
   • 面向对象方法

7. RUP应用了角色、活动、制品和工作流四种模型元素

   角色：“谁做”

   制品：“做什么”

   活动：“怎么做”

   工作流：“什么时候做”

8. 甘特图：是一种简单的水平条形图，以日历为基准描述项目任务。甘特图能够清晰的描述每个任务从何时开始，到何时结束，以及任务之间的并行关系。但它不能清晰的反映出各任务的依赖关系。

   PERT图：是一个有向图，图中的箭头表示任务，它可以表示完成该任务的时间，途中的节点表示流入节点的任务的结束，并开始流出结点任务。PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系。但是不能清晰地描述各个任务之间的并行关系。

9. 结构化设计：根据系统的数据流图进行设计，模块体现为函数、过程及子程序

   面向对象设计：基于面向对象的基本概念进行，模块体现为类、对象和构建等

10. 敏捷过程开发：

    • 极限编程XP：激发开发人员创造性，使得管理负担最小的一组技术
    • 水晶法Crystal：每一个不同的项目都需要一套不同的策略、约定和方法论
    • 并列争球法Scrum：使用迭代的方法，其中把每30天一次的迭代成为一个冲刺，并按需求的优先级来实现产品
    • 自适应软件开发ASD：多个自治组织和自治小组并行地递增实现产品，并通过简短的日常情况会议进行协调

11. 软件成本估算模型：

    • Putnam：动态多变量软件成本进度模型
    • COCOMO：用三个不同层次的模型来反映不同程度的复杂性
      • 基本模型：一个静态单变量模型，它用一个以已估算出来的源代码行数（LOC）为自变量的函数来计算软件开发工作量。
      • 中级模型：在用LOC为自变量的函数计算软件开发工作量的基础上，再用设计产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
      • 详细模型：在中级模型的基础上，还要考虑对软件工程过程中分析、设计等各步骤的影响。

12. 目前常用的项目估算方法：

    • 专家判断方法：该方法受到专家经验和主观性等方面的影响；
    • 算法方法：根据某个计算模型来估算项目开发成本，如启发式方法COCOMO模型，但这些模型中的参数难以确定
    • 机器学习方法：根据过去的项目开发数据，建立分类模型，预测新项目的开发成本，但这类方法难以定义训练数据的特征以及定义数据对象之间的相似性。

    但结合多种方法，仍不能得到精确的估算结果

13. 软件需求

    • 功能需求：是所开发的软件必须具备什么样的功能
    • 非功能需求：是指产品必须具备的属性和品质，如可靠性、性能、响应时间、扩展性等
    • 设计约束：是对解决方案的一些约束说明

14. 软件风险一般包含两个特性：

    • 不确定性：指风险可能发生，也可能不发生
    • 损失：当风险确实发生时，会引起的不希望的后果和损失

15. 风险预测从以下两个方面进行评估

    • 风险发生的可能性大小
    • 风险发生所产生的后果是否严重

16. 风险分析：

    • 风险识别：试图系统化地确定对项目计划（估算、进度、资源分配的威胁）
    • 风险预测：又称为风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生时所产生的后果
    • 风险评估：根据风险及其发生的概率和产生的影响预测是否影响参考水平值，定义风险参照水准
    • 风险控制：辅助项目组建立处理风险的策略，有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划

17. 软件项目的风险：

    • 项目风险：涉及到各种形式的预算、进度、人员、资源以及和客户相关的问题
    • 技术风险：涉及到潜在的设计、实现、对接、测试即维护问题
    • 业务风险：建立一个无人想要的优秀产品的风险、失去预算或人员承诺的风险等
    • 商业风险：市场风险、策略风险、管理风险和预算风险

18. 在进行风险管理时，根据风险的优先级来确定风险控制策略，而优先级是根据风险暴露来确定的。

    风险暴露：是一种量化风险影响的指标，等于风险影响乘以风险概率；风险影响是当风险发生时造成的损失。

19. 软件开发各阶段产物

    • 可行性分析：可行性研究报告
    • 需求分析：数据流图、数据字典、需求规格说明书、用例图、测试设计文档等
    • c概要设计：架构图、时序图、ER图、接口文档、概要设计说明书
    • 详细设计：详细设计说明书
    • 编码：源代码
    • 测试：测试计划、测试分析报告
    • 运行维护：程序维护手册

20. COCOMO Ⅱ方法：成本估算时，COCOMO Ⅱ方法以规模作为成本的主要因素，考虑多个成本驱动因子。该方法包括三个阶段性模型，即应用组装模型、早期设计阶段模型和体系结构阶段模型。

    在模型层次结构中有三种不同规模估算选择，即：对象点、功能点和代码行

21. Wolverton模型，基于一个成本矩阵，定义不同的软件类型（如控制、输入、输出等）和难易（容易和困难）的成本，基于此计算软件开发的成本。

22. CMM(Capability Maturity Model) 能力成熟度模型：

    • 一级：初始级。过程无序、进度、预算、功能和质量等方面不可预测；
    • 二级：可重复级。达到该级的软件公司过程已制度化，有纪律，可重复；
    • 三级：已定义级。即过程实现标准化；
    • 四级：已管理级。达到该级的软件公司已实现过程的定量化；
    • 五级：优化级。达到该级的软件公司过程可自发地不断改进；

23. 易用性：

    易理解性

    易学性

    易操作性

24. 软件变更控制是变更管理的重要内容，要有效进行变更控制，需要借助配置数据库和基线的概念。配置数据库一般包括开发库、受控库和产品库。

25. 软件过程模型可以帮助开发团队理解开发过程，形成对开发中的活动、资源和约束的共同理解，可以根据具体情况对一个过程进行裁剪等。

    • 瀑布模型：从一种非常高层的角度描述了软件开发过程中进行的活动，并且提出了要求开发人员经过的时间序列。该模型适用于项目开始时需求已确定的情况。关键词：需求明确
    • V模型：是瀑布模型的变种。它说明测试活动是如何与分析和设计相联系的。
    • 喷泉模型：典型的面向对象生命周期模型，是一种以用户需求为动力，以对象作为驱动的模型。”喷泉“一次体现了迭代和无间隙特性。迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统；无间隙是指在开发活动之间不存在明显的边界。关键词：面向对象
    • 增量模型（演化模型）：一种非整体开发的模型，该模型具有较大的灵活性，适合于软件需求不明确的一种模型。把软件产品作为一些列增量构件来设计、编码、集成和测试。使用该模型开发产品，一般是尽快构造出可运行的产品，然后再该产品的基础上再增加需要的新的构建，使产品更趋于完善。关键词：快速构造核心产品
    • 原型模型：允许开发人员快速地构造整个系统或系统的一部分以理解或澄清问题。原型的用途是获知用户的真正需求，因此原型模型可以有效地引发系统需求。关键词：需求不明确
    • 螺旋模型：把开发活动和风险管理结合起来，以将风险减到最小并控制风险。关键词：风险分析。

26. 软件过程改进框架

    • 过程改进基础设施
    • 过程改进线路图
    • 软件过程评估方法
    • 软件过程改进计划

27. CMMI是SEI将已有的几个CMM模型结合在一起，使之构成集成模型，即成熟度模型，该模型支持阶段性过程改进和连续性过程改进。

28. 软件复杂性的主要参数：

    • 规模：即总共的指令数，或源程序行数
    • 难度：通常由程序中出现的操作数的数目所决定的量来表示
    • 结构：通产用于程序结构有关的度量来表示
    • 智能度：即算法的难易程度

29. McCabe度量法是一种基于程序控制流的复杂性度量方法，又称为环路度量，

    它认为程序的复杂性很大程度上取决于控制的复杂性。

    单一的顺序程序结构最为简单，循环和选择所构成的环路越多，程序就越复杂。

    计算公式：$V(g)=m-n+2$

    $m$为图中的边数，$n$为图中的顶点数

30. 结对编程存在一个非正式的代码审查过程，可以获得更高的代码质量。据统计，结对编程的编码速度与传统的单人编码相当。

31. 软件质量特性

    • 功能性：指与功能及其指定的性质有关的一组软件质量
    • 可靠性：指衡量在规定的一段时间内和规定条件下维护性能水平的一组软件质量
    • 可维护性：指与软件维护的难易程度相关的一组软件属性
    • 易使用性：指与使用难易程度及规定或隐含用户对使用方式所做的评价相关的属

32. 模块评审

    主要包括以下方面的评审：

    • 控制流结构：规定了处理模块与处理模块之间的流程关系。检查处理模块之间的控制转移关系（调用关系）。
    • 数据流结构：规定了数据模块是如何被处理模块进行加工的流程关系。
    • 模块结构与功能结构之间的对应关系：包括功能结构与控制流结构的对应关系、功能结构与数据流结构的对应关系、每个模块的定义（包括功能、输入与输出数据）。

33. 容错技术：是对某些无法避开的差错，使其影响减至最小的技术。通常冗余技术分为四类：

    • 结构冗余
    • 信息冗余
    • 时间冗余
    • 冗余附加技术：指为实现其他类型冗余技术所需要的资源和技

34. 冗余附加技术

    • 在屏蔽硬件错误的容错技术中，冗余附加技术包括：

      关键程序和数据的冗余存储及调用，检测、表决、切换、重构、纠错和复算的实现

    • 在屏蔽软件错误的容错技术中，冗余附加技术包括：

      冗余备份程序的存储及调用；实现错误检测和错误恢复的程序；实现容错软件所需的固化程序

35. 软件配置管理 SCM主要内容：

    • 版本管理

    • 配置支持

    • 变更支持

    • 过程支持

    • 团队支持

    • 变化报告

    • 审计支持

36. ISO/IEC 软件质量模型

    • 功能性

      子特性：适应性、准确性、互用性、依从性、安全性

    • 可靠性

      子特性：成熟性、容错性、易恢复性

    • 易使用性

      子特性：易理解性、易学性、易操作性

    • 效率

      子特性：时间特性、资源特性

    • 可维护性

      子特性：易分析性、易改变性、稳定性、易测试性

    • 可移植性

      子特性：适应性、易安装性、一致性、易替换性

37. CMMI的成熟度等级

    • 初始级：软件过程是无序的，甚至是混乱的
    • 已管理级：建立了基本的项目管理过程来跟踪费用、进度和软件的功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验
    • 已定义级：已被软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件
    • 量化管理级：分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理活动有一个作出结论的客观依据，能够在定量的范围内预测性能
    • 优化管理级：过程的量化反馈和先进的新思想、促使过程持续不断改进。有能力识别软件过程中的薄弱环节，并有足够的手段改进它们，防止缺陷的产生

38. CMMI的能力等级

    • CL0：不完整级
    • CL1：已执行级
    • CL2：已管理级
    • CL3：已定义级
    • CL4：量化管理级
    • CL5：优化级

39. McCall 软件质量模型

    • 运行方面：正确性、可靠性、效率、完整性、实用性
    • 修正方面：维护性、测试性、灵活性
    • 转移方面：维护性、移植性、复用性、共运行性

40. 极限编程

    是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方式

    • 四大价值观：沟通、简单性、反馈和勇气
    • 五大原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作
    • 十二个最佳实践
      • 计划游戏（快速制定计划、随着细节的不断变化而完善）
      • 小型发布（系统的设计要能够尽可能早的交付）
      • 隐喻（找到合适的比喻传达信息）
      • 简单设计（只处理当前的需求，使设计保持简单）
      • 测试先行（先写测试代码，然后再编写程序）
      • 重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）
      • 结对编程
      • 集体代码所有制
      • 持续集成（可以按日甚至按小时为客户提供可运行版本）
      • 每周工作40个小时
      • 现场客户
      • 编码标准

41. 用于系统开发人员与项目管理人员在项目期内进行沟通的文档主要由系统开发计划，包括工作任务分解表、PERT图、甘特图和恶预算分配表等。

42. 程序的三种基本控制结构是顺序结构、选择结构和重复结构。

43. 高质量文档的特性：

    • 针对性：文档编制应考虑读者
    • 精确性：文档的行文应该十分确切，不能出现多义性的描述
    • 完整性：任何文档都应当是完整的、独立的，应该自成体系
    • 灵活性：各个不同软件项目，其规模和复杂程度有着许多实际差别，不能一律看待
    • 可追溯性：在一个项目各开发阶段之间提供的文档必定存在着可追溯的关系

44. 软件评审包括：

    • 设计质量评审
    • 程序质量评审
    • 运行环境评审

    评审的主要目标是为了发现软件中的错误

45. 可维护性的复审：

    • 在开发阶段：保证软件具有可维护的特点
    • 在系统分析阶段的复审过程中：应该指出软件的可移植性问题，以及可能影响软件维护的系统界面
    • 在系统设计阶段的复审期间：应该从容易修改、模块化和功能独立的目的出发，评价软件的结构和过程
    • 在系统实施阶段的复审期间：代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素

46. 对软件系统进行评价时，需要从信息系统的组成部分、评价对象和经济学角度出发进行综合考虑，以建立起一套指标体系理论架构。

    • 从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求（人）、系统质量和技术条件（机）这两条线索构造指标
    • 从信息评价对象出发，对于用户方来说，他们所关心的是用户需求和运行质量；对开发方而言，他们所关心的是系统质量和技术水平。系统外部环境则主要通过社会效益指标来反映
    • 从经济学角度出发，分别按系统成本、系统效益和财务指标等三条线索建立指标

47. 逆向工程从源代码得到软件系统的规格说明和设计信息，属于软件维护阶段行为

48. 六大设计原则

    • 单一职责原则

      一个类应该只负责一项职责

    • 接口隔离原则

      要为每个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口，供所有依赖它的类去调用

    • 依赖倒转原则

      高层模块不应该依赖低层模块，两者应依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象；中心思想是面向接口编程

    • 里氏替换原则

      引用基类的地方必须能透明的使用其子类的对象

    • 开闭原则

      当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求

    • 迪米特原则

      又叫最少知道原则，即一个类对自己依赖的类知道的越少越好

49. 软件测试方法

    可以分为静态测试和动态测试

    • 静态测试：是指被测试程序不在程序上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
    • 动态测试：指通过运行程序发现错误。包括白盒测试和黑盒测试。

50. 白盒测试

    又称为逻辑覆盖法，因为要以程序（模块）内部的逻辑结构为基础来设计测试用例，主要用于单元测试。测试的关键也是如何选择高效的测试用例。

    原则：

    • 对程序模块的所有独立的执行路径至少测试一次
    • 对所有逻辑判定，取“真”与取“假”的两种情况都至少测试一次
    • 检查程序的内部数据结构，保证其结构的有效性
    • 在循环的边界和运行界限内执行循环体

    主要方法：

    • 程序结构分析
    • 逻辑覆盖
      • 语句覆盖
      • 判定覆盖
      • 条件覆盖
      • 判定/条件覆盖
      • 条件组合覆盖
    • 基本路径测试
      • McCade方法

51. 黑盒测试

    也称为功能测试，在不完全考虑软件内部结构和特性的情况下，测试软件外部特性。

    黑盒测试试图发现以下类型的错误：

    • 功能错误或遗漏
    • 界面错误
    • 数据结构或外部数据库访问错误
    • 性能错误
    • 初始化和终止错误

    黑盒技术设计测试用例的方法有：

    • 等价类划分方法
    • 边界值分析方法
    • 错误推测方法
    • 因果图方法
    • 判定表驱动分析方法
    • 正交实验设计方法
    • 功能图分析方法

52. 灰盒测试

    介于黑盒和白盒之间，是一种综合测试的方法，它将白盒测试和黑盒测试结合在一起，构成一种无缝测试技术。

    灰盒测试是基于程序运行时的外部表现，又结合程序内部逻辑结构来设计测试用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。

    灰盒测试旨在验证软件满足外部指标以及软件的所有通道或路径都进行了检验。

53. 风险管理

    • 风险评估
      • 风险识别
      • 风险分析
      • 风险优先级排序
    • 风险控制
      • 风险管理规划
      • 风险处理
      • 风险监控