软考中级软件设计师---系统开发基础

开发模型（+++++）

瀑布模型

• 每个阶段都有相应的产出，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改
• 适用于需求比较明确的项目

V模型

• 着重测试，不足依然是测试放在了编码之后

喷泉模型

• 每个阶段没有明确的界限，是面向对象的开发模式
• 具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期
• 开发过程中需要大量的开发人员，因此不利于项目的管理

原型化模型

• 沟通，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的

演化模型

• 演化模型主要针对事先不能完整定义需求的软件开发，用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现

螺旋模型

• 它是风险驱动的，但是，这也可能是它的一个弱点。除非软件开发人员具有丰富的风险评估经验和这方面专门的知识，否则将出现真正的风险；当项目实际正在走向灾难时，开发人员可能还认为一切正常

统一过程

• 统一过程（RUP/UP，Rational Unified Process）是一种以用例驱动、以架构为核心、迭代及增量的软件过程模型，由UML方法和工具支持，广泛应用于各类面向对象项目
• 具有初始阶段，细化阶段，构造阶段和移交阶段
• 每个阶段会进行多次迭代，构架提供了一种结构来指导迭代过程中的工作，而用例则确定了目标并驱动每次迭代的工作

敏捷方法

• 极限编程：XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式，用于费用控制严格的公司中的使用
• Cockburn的水晶系列方法：用最少纪律约束而仍能成功的方法，任何项目，无论大小、敏捷程度，其最重要的一项体系特征是每过几个月就向用户交付已测试的运行代码。如果你使用了此体系特征，你就会发现，“经常交付”的作用还是很让人吃惊的
• 开放式源码：开放式源码指的是开放源码界所用的一种运作方式，一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障（debug）的高度并行性，任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库
• Scrum： Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程，在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量
• FDD：FDD 也是一个迭代的开发模型。FDD的每一步都强调质量，不断地交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息。同敏捷方法一样，FDD 弱化了过程在软件开发中的地位。虽然 FDD 中也定义了开发的过程，不过一个几页纸就能完全描述的过程深受开发者的喜爱
• ASD：其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习

软件开发方式（+）

• 结构化方法（面向数据流）
  • 用户至上
  • 严格区分工作阶段，每阶段有任务和结果
  • 强调系统开发过程的整体性和全局性
  • 系统开发过程工程化，文档资料标准化
  • 自顶向下，逐步分解(求精)
• 原型法
• 面向对象方法
  • 更好的复用性
  • 关键在于建立一个全面、合理、统一的模型
  • 分析、设计、实现三个阶段，界限不明确
• 面向服务的方法

需求分析（+）

• 需求的任务
• 需求的过程
  • 问题识别
  • 分析与综合
  • 编制需求分析文档
  • 需求分析与评审
• 需求的分类
  • 功能需求
  • 非功能需求
  • 设计约束
• 应用的工具
  • 数据流图（DFD）
  • 数据字典（DD）
  • 判定表
  • 判定树

软件设计（++）

• 软件设计的任务与活动
• 模块设计原则
• 应用的工具
  • IPO图
  • PDL
  • PAD
  • 程序流程图
  • N/S盒图
• 内聚类型（高到低）：功能->顺序->通信->过程->(瞬时)时间->逻辑->偶然(巧合)
• 耦合类型（低到高）：非直接->数据->标记->控制->外部->公共->内容
• 软件设计要求高内聚，低耦合

软件测试与维护

黑盒测试

• 等价类划分法

  • 确定无效与有效等价类
  • 设计用例尽可能多的覆盖有效类，例如地区码和前缀都有效：123 666
  • 设计用例只覆盖一个无效类，例如地区码无效：asd
    

• 边界值分析法

  • 处理边界情况时最容易出错
  • 选取的测试数据应该恰好等于、稍小于或稍大于边界值

白盒测试用例（++++）

• 常用的白盒测试方法有逻辑覆盖、循环覆盖和路径测试
• 逻辑覆盖主要用测试数据运行被测程序对程序逻辑的覆盖程度，按覆盖程度从弱到强排序依次为：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖
  • 语句覆盖：每条语句（判断语句，条件语句等）都执行
  • 判定覆盖（分支覆盖）：不仅每个语句至少执行一次，而且每个判定的每种可能结果（分支）都至少执行一次。比语句强，真分支假分支都要覆盖。菱形框中为判定。判定覆盖包含语句覆盖
  • 条件覆盖：不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖不一定包含判定覆盖，而判定覆盖也不一定包含条件覆盖
  • 判定条件覆盖：同时满足判定覆盖和条件覆盖。它的含义是，选取足够的测试用例，使得判定表达式中每个条件的所有可能结果至少出现一次。而且每个判定本身的所有可能结果也至少出现一次
  • 条件组合覆盖：选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次
  • 路径覆盖：足够多的测试用例，覆盖全部可能路径，最强的覆盖
• 循环覆盖：执行足够多的测试用例，使得循环中的每个条件都得到验证
• 基本路径覆盖：在程序控制流图的基础上通过分析控制流图的环路复杂性，导出基本可执行路径集合，从而设计测试用例

McCabe复杂度计算（+++）

• 也叫环路复杂度

• 该图左边和右边都是V(G) = 5

• 计算有向图G的环路复杂度公式为：V(G) = m - n + 2

  • 说明：m是G中的有向边数，n是G中的节点数

• 或者V(G) = 封闭区间数 + 1

• 例题：右边的图考试没有，需要自己画。B D
  

软件维护类型（++++）

• 可维护性因素决定
  • 可理解性
  • 可测试性
  • 可修改性
• 软件维护类型
  • 改正性维护 25%：改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷
  • 适应性维护 20%：在软件使用过程中数据环境发生变化或处理环境发生变化时修改软件以适应这种变化
  • 预防性维护 5%：为了提高软件的可维护性、可靠性等，事先采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试
  • 完善性维护 50%：在用户和数据处理人员使用软件过程中提出改进现有功能，增加新的功能，以及改善总体性能的要求后，修改软件以把这些要求纳入到软件之中

软件质量保证（+）

• 功能性：适合性，准确性，互操作性，安全保密性
• 可靠性：成熟性，容错性，易恢复性
• 易用性：易理解性，易学性，易操作性，吸引性
• 效率：时间特性，资源利用性
• 维护性：易分析性，易改变性，稳定性，易测试性
• 可移植性：适应性，易安装性，共存性，易替换性

软件过程改进（++）

• 软件成熟度模型（CMMI）

项目管理基础

Gant图与Pert图（++++）

• PEAT图不能很好表示各任务的并行情况

• GANTT则不能表示各任务的依赖关系

• 关键路径法（CPM）：

  • 前导图法（PDM）：
    
  • ES：最早开始时间(Earliest Start)
  • EF：最早结束时间(Earliest Finish)
  • LF：最晚结束时间(Latest Finish)
  • ES：最晚开始时间(Latest Start)
  • 总时差（松弛时间）：在不耽误总工期的前提下，该活动的机动时间。活动的总时差等于该活动最迟完成时间与最早完成时间之差，或该活动最迟开始时间与最早开始时间之差
  • 求关键路径，就是求工期最长的那条路
  • 关键路径上的活动为关键活动，关键活动没有自由时长，也就是没有总时差

风险管理（+++）

• 风险曝光度 = 风险出现概率 × 可能造成的损失
• 风险的发生是不确定的