软考-软件设计师-软件工程

软考-软件设计师-软件工程

基本要素

方法，工具，过程

模块划分的阶段

• 需求分析：确定软件要完成的功能和非功能性的要求
• 概要设计：将需求转化为模块的划分，确定模块之间的调用关系
• 详细设计：设计算法和数据结构，数据库的物理设计
• 编码：coding

CMM和CMMI

CMM

初始级

杂乱无章

可重复级

基本的功能， 可跟踪，可复用

已定义级

软件过程均已文档化，标准化，已是标准软件过程

已管理级

软件过程和产品的质量有质量度量标准，组织的成员都理解了

优化级

可用新观念，技术来不断改进

CMMI

阶段式模型（不常考）

• 初始的：过程不可预测且缺乏控制
• 已管理的：过程为项目服务
• 已定义的：过程为组织服务
• 定量管理：过程可度量和控制
• 优化的：集中于过程的改进

连续式模型

未完成的

未得到所有目标

已执行的

可将输入转化为输出

已管理的

集中于已管理的过程的制度化

已定义级的

集中于已定义的过程的制度化

定量管理的

集中于可定量管理的过程的制度化

优化的

可不断的改变功效

白盒测试

仅用于通过考试

语句覆盖

每个语句（方框）均执行一次

判定覆盖

每个判定（菱形）的真假均执行一次

条件覆盖

每个判定（菱形）中的每个条件（A and B 的 A 和 B）的真假均执行一次

判定／条件覆盖

每个判定（菱形）中的每个条件（A and B 的 A 和 B）的真假均执行一次， 同时，每个判定（菱形）的真假均执行一次

条件组合覆盖

每个判定中的每个条件的各种可能值的组合都至少出现一次

路径覆盖

测试所有可能的路径(一个箭头可能多次执行)

简单路径: 路径中不包含重复的路径

系统可维护性指标

系统可维护性指标:可理解性, 可测试性, 可修改性

可维护性在整个开发中都需要考虑的

软件测试

软件文档:用户文档和系统文档

用户文档展现功能, 系统文档展现功能的实现

软件文档

开发文档非常重要

高质量的文档可提高开发的质量

文档是软件的一部分, 文档的编制在软件开发中占有突出的地位, 高质量的文档对产品有重要的意义

特性

• 精确
• 清晰
• 完整
• 灵活
• 可追溯

系统维护

软件维护

正确性维护

修bug

适应性维护

适应环境（硬件环境， 运行环境，市场环境）的变化， 添加新的技术等

完善性维护

扩充功能， 改善性能等

需要更改开发文档

预防性维护

改善可维护性和可靠性，增加预防性的功能

软件需求

功能性需求

软件必需拥有的功能

非功能性需求

软件的品质：可靠性，性能，响应时间等

设计约束

对解决方案的一些约束性说明

软件评审

目标

发现软件中的错误

软件质量评审的具体的内容

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

软件评审的具体的内容

• 软件的规格说明是否符合用户的要求
• 评审可靠性
• 评审保密措施实现的情况
• 评审操作特性实施的情况
• 性能
• 是否具有可修改性
• 可测试性
• 复用性

软件的复审

系统设计阶段

从容易修改，模块化和功能独立的目的出发

系统实施阶段

代码复审应该强调编码风格和内部说明文档两个影响可维护性的因素出发

软件的质量属性

可靠性（正常运行）

在给定时间的间隔内，在给定的条件下无失效运作的概率

$mttf/(1+mttf)$ ，$mttf$ 是平均无故障时间

可用性（两次失效的间隔）

在给定的时间内，一个系统能够的按照规格说明正确运作的概率

$mtbf/(1+mtbf)$,$mtbf$是平均失效的间隔时间

记忆方法：可用的视频有很多（很多 tb 的视频）

可维护性（生效的时候修复的时间）

在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成修复的概率

$1/(1+mttr)$, $mttr$ 为平均修复时间

软件项目估算

cocomo 估算模型

基本cocomo 模型

一个静态单变量模型

中级 cocomo 模型

一个静态多变量模型，以基本的cocomo模型为基础，考虑了其它的15种影响工作的因素，使估算更合理

详细cocomo模型

在中级的基础上，考虑了需求分析，软件设计的成本驱动等的影响

cocomoii 模型

三个阶段

1. 应用组装模型（对象点）
2. 早期设计阶段模型（功能点）
3. 体系结构阶段模型（代码行）

甘特图

可以清晰的描述每个任务从做何时开始，到何时结束，任务的进展情况和并行性。

不能反映出各任务的依赖关系，难以确认关键所在，不能反映有潜力的部分

风险管理

风险的类型

风险的特性：不确定性和损失

项目风险

会拖延项目的进度和增加项目的成本

预算，进度，人员，资源，项目的规模和结构不确定性等影响

技术风险

威胁要开发的软件的质量和交付时间

设计，接口，验证，维护，前沿技术等影响

商业风险

威胁软件的生存能力，通常还会危害项目或产品

风险识别

主要：回避风险，必要的时候进行控制

注意：无法完全避免风险，只能将损失降到最小

风险预测的两个方面：风险发生的可能性或概率，风险所产生的后果

###　风险的类型(考的少)

• 产品规模
• 商业规模
• 客户特性
• 过程定义
• 开发环境
• 开发技术
• 人员才干及经验

风险显露度

可用于评定优先级

$RE=P\ast C$

p是发生的概率， c是带来的项目成本

一种对风险评估很有用的技术是定义风险参照水准

风险的本质，范围和时间可能会影响风险所产生的后果

风险控制

目地：辅助项目组建立处理风险的策略

有效的策略应考虑风险避免，风险监控，风险管理及意外事件计划

风险避免是最好的控制风险的策略

风险监控的目地

• 评估预测的风险是否真的发生了
• 保证实施了正确的缓解步骤
• 收集能够用于今后风险评测的信息

软件质量模型

功能性

适合性
准确性
互用性
依从性
安全性

效率

时间特性
资源特性

可靠性

成熟性
容错性
易恢复性

可维护性

易分析性
易改变性
稳定性
易测试性

易使用性

易理解性
易学性
易操作性

可移植性

适应性
易安装性
一致性
易替换性

软件工具

软件开发工具

• 需求分析工具
• 设计工具
• 编码与排错工具
• 测试工具

软件维护工具

• 版本控制工具
• 文档分析工具
• 开发信息库工具
• 逆向工程工具
• 再工程工具

软件开发项目管理

系统人员 和 项目人员 的沟通

• 系统开发计划
• 系统开发月报
• 系统开发总结报告

软件配置管理

• 变更标识
• 变更控制
• 版本控制