软考软件设计师-软件工程基础知识

自己整理的, 难免会有错误!!!

5.1 软件工程概述

基本的要素:方法,工具和过程

5.1.2 软件工程基本原理

用分阶段的生命周期计划严格管理
坚持进行阶段评审
实现严格的产品控制
采用现代程序设计艺术
结果应能清楚地审查
开发小组的人员应少而精
承认不断改进软件工程实践的必要性

5.1.3 软件生存周期

可信性分析与项目开发计划
需求分析
概要设计
1. 设计软件的结构, 明确软件由哪些模块组成, 层次结构, 相互之间如何调用,模块的功能
详细设计
1. 对每个模块的功能进行具体的描述, 把功能转换为精确的,结构化的过程描述
编码
测试
维护

5.1.4 软件过程

能力成熟度模型(CMM)

目的: 提高一种评价软件承接能力的方法, 同时帮助软件组织改进其软件过程
是软件组织进化阶段的描述, 可以帮助软件组织能较容易地确定当前的成熟度和软件过程执行的薄弱的环节, 从而来形成改进策略
共有5个成熟度级别
- 初始级
  - 杂乱无章, 软件依赖个人
- 可重复级
  - 有基本的项目管理过程和实践来跟踪项目费用,进度和功能特性
- 已定义级
  - 管理和工程均已文档化,标准化, 并综合成整个软件开发组织的标准
- 已管理级
  - 制定了软件过程和产品质量的详细度量标准
- 优化级
  - 加强了定量分析, 通过过程质量反馈和来自新观念和新技术的反馈使过程能不断持续地改进

能力成熟度模型集成(CMMI)

是若干过程模型的综合和改进

阶段式模型

5个成熟度等级
- 初始的
  - 过程不可预测
- 已管理的
  - 过程为项目服务
- 已定义的
  - 过程为组织服务
- 定量管理的
  - 过程已度量和控制
- 优化的
  - 集中于过程改进

连续式模型

6个过程能力等级
- CL0(未完成)
- CL1(已执行)
- CL2(已管理)
- CL3(已定义级的)
- CL4(定量管理的)
- CL5(优化的)

5.2 软件过程模型

是软件开发全部过程,活动和任务的结构框架

5.2.1 瀑布模型

结构化的典型代表
优点:
- 容易理解, 管理成本低
- 强调开发的阶段性早期计划及需求调查和产品测试
缺点:
- 客户需要完整的提出要求, 不能中途修改
- 项目结束时, 需要进行大量的测试和集成工作
- 直到项目结束前, 都不能演示系统的能力
- 对于风险的控制能力较弱, 从而会导致项目延期, 开发超出预算
- 难以适应变化的需求

v模型

瀑布模型的变体
强调了测试应该贯穿开发的始终
特点
- 多种测试
- 需求和验收测试有对应的关系

5.2.2 增量模型

融合了瀑布模型的基本成分和原型模型的迭代特征
无需等到整个系统开发完成就可以使用
优先级高德服务先交付, 这样最重要的服务接受最多的测试
优点:
- 瀑布模型的所有的优点
- 第一个版本所需的成本(时间,金钱)很少
- 开发者承担的风险不大
- 可以减少用户的需求的变更
缺点:
- 无法进行好的模块划分

5.2.3 演化模型

逐步开发出完整的系统

1. 原型模型

适用于需求不明确的情况
强调构造一个简易的系统
原型是预期系统的一个可执行版本, 反映了系统性质的一个选定的子集
目的:定义软件的总体目标, 标识需求范围, 快速制定原型开发的计划, 确定原型德目标和范围
可以分为3个种类
- 探索型
  - 弄清目标的要求, 确定希望的特性
- 实验型
  - 验证方案或算法的合理性
- 演化型
  - 通过对原型德多次改进, 逐步将原型演化成最终的目标

2. 螺旋模型

瀑布模型和演化模型的结合
特点:引入了其他模型不具备的风险分析,使软件在无法排出重大风险时有机会停止,以减少损失
每个周期的任务
- 制定计划
- 风险分析
- 实施工程
- 用户评估
强调风险分析, 使得开发人员对每个演化层出现的风险有所了解, 从而做相应的反映
适用于庞大, 复杂且高风险的系统

5.2.4 喷泉模型

面向对象的代表, 是面向对象的模型
更好的复用性
阶段间没用明确的界限
优点:
- 提高软件项目的开发的效率
- 节省开发的时间
缺点:
- 需要维护大量的文档, 使得审核难度加大

5.2.5 基于构建的开发模型

本质是演化模型, 需要以迭代的方式来构建模型, 不同在于采用预先打包的软件构建开发应用系统
领域工程的目的:构建领域模型, 领域基准系统结构和可复用构件库
应用系统工程的目的:使用可复用的构建组装应用系统

5.2.8 敏捷方法

只适用于小系统, 不适用于大的项目

1. 极限编程(XP)

4大价值观: 沟通, 简单性, 反馈和勇气
5个原则:快速反馈, 简单性假设, 逐步修改, 提倡更改和优质工作
12个实践: 没用
近螺旋式的开发方法,将复杂的开发过程分解为一个个小的相对来说简单的过程
开发人员和客户可以知道开发的进度,变化,待解决的问题和潜在的困难
主要解决了代码质量低, 不能解决编码的速度
承担了共同代码拥有和共同对系统负责
承担了非正式的代码审查过程

2. 水晶法

每一个不同的项目都拥有一套不同的策略, 约定和方法论

3. 并列争求法

每30天是一个冲刺, 并按照需求的优先级来实现该产品. 多个自治小组并行的递增实现该产品

4. 自适应软件开发

有一个使命做指导
特征被视为客户价值的关键点

5. 敏捷统一过程(AUP)

采用“大型连续”, “小型迭代”的方式

建模
实现
测试
部署
配置和项目管理
环境管理

5.3 需求分析

是用户对目标软件系统在功能, 行为, 性能, 设计约束等方面的期望

具体的内容

功能需求
性能需求: 技术性指标
用户和人的因素: 用户的类型
环境需求: 使用软件的环境, 包括硬件和软件
界面需求
文档需求: 写哪些文档, 文档针对的用户
数据需求: 数据的输入和输出的格式
资源使用需求: 内存, 数据等资源
安全保密需求
可靠性要求: 系统是否检测并隔离错误
软件成本消耗与开发进度需求
其他非功能性要求

5.3.3 需求工程

需求获取

与客户交流

需求分析与协商

对需求组织分类, 分析需求之间的关系

系统建模

使用合适的工具和符号系统地描述需求

2种分析方法
- 面向数据流的结构化分析方法(SA)
- 面向对象的分析方法(OOA)

需求规约

是分析任务的最终产物, 通过完整的信息描述, 详细的功能和行为描述等给出目标软件的各种需求

引言
信息描述
功能描述
行为描述
验收标准
参考书目
附录

需求验收

目的: 检测需求功能的正确性, 完整性和清晰性, 检查是否符合用户的意愿

需求管理

5.4 系统设计

常用的两种设计方法:

面向数据流的结构化设计方法(SD)
面向对象的分析方法(OOD)

5.4.1 概要设计

设计软件系统总体结构
数据结构及数据库设计
编写概要设计文档
评审

结构化方法

结构化方法的知道思想是自顶而下, 逐层分解,适用于数据处理领域的问题, 不适合解决大规模,特别负责的项目,难以适应需求变化

jackson方法

以数据结构为驱动, 适用于小规模的项目, 适用于时序性特点较强的系统

结构化设计中要遵守的规则

模块大小要适中
模块扇入和扇出要合理
1. 扇出表示直接调用下级模块的个数, 扇入同理
深度和宽度要适当
1. 深度表示模块的层数

模块的内聚

功能内聚:完成一个单一功能, 各个部分协同工作
顺序内聚:处理元素相关, 必须顺序执行
通讯内聚:处理元素集中在一个数据结构的区域上
过程内聚:处理元素相关, 而且必须按照特定的次序执行
瞬时内聚:所包含的任务必须在同一时间间隔内执行
逻辑内聚:完成逻辑上相关的一组任务
偶然内聚(巧合内聚):完成一组没有关系或松散关系的任务

结构化设计

体系结构设计:定义软件的主要结构
数据设计:基于实体联系图确定软件涉及的文件系统结构及数据库表结构
接口设计:描述用户界面,软件和其他硬件设备,其他软件系统及使用的人员的外部接口, 以及各个构建直接的内部接口
过程设计:确定软件各个组成部分内的算法和内部数据结构, 并选定某种过程的表达形式来描述各种算法

5.5 系统测试

目的:发现隐藏的错误

5.5.2 传统软件的测试策略

先单元测试, 后集成测试

1. 单元测试

测试的内容:

模块接口
局部数据结构
重要的执行路径
出错处理
边界条件

测试的过程:

驱动测试
1. 主程序接受子程序的数据
桩测试
1. 代替测试模块中所调用的子模块, 目的: 检验入口, 输出调用和返回的信息

2. 集成测试

集成的两个方法:

非增量集成: 一次性集成完毕
增量集成: 逐个集成

测试的方法:

自顶而下的集成测试
1. 从主控模块开始, 沿着控制层逐步向下
自底而上集成测试
1. 从原子模块开始构造和测试(无需使用桩测试)
回归测试
冒烟测试
1. 用于检测是否有明显的漏洞

3. 确认测试

阿尔法测试和贝塔测试

4. 系统测试

恢复测试
安全性测试
压力测试:在极限值得情况
性能测试
部署测试

5.5.3 测试面向对象软件

1. 单元测试

测试一个类

2. 集成测试

基于线程测试
基于使用测试

5.5.5 测试方法

静态测试

人工测试
计算机辅助测试

动态测试

黑盒测试
1. 等价类划分
2. 边界值分析
3. 错误推断
4. 因果图
白盒测试
1. 逻辑覆盖
  1. 语句覆盖
  2. 判定覆盖
  3. 条件覆盖
  4. 判定/条件覆盖
  5. 条件组合覆盖
  6. 路径覆盖
2. 循环覆盖
3. 基本路径覆盖

5.6 运行和维护知识

5.6.2 系统维护概述

系统可维护性概念

系统的可维护性定义为维护人员理解, 改正, 改动和改进这个软件的难以程度

评价指标

可理解性
可测试性
可修改性

系统维护的内容及类型

硬件维护
软件维护
1. 正确性维护: 程序无错误
2. 适应性维护: 系统升级等
3. 完善性维护: 功能的添加
4. 预防性维护: 以后可能会需要维护的内容
数据维护

5.7 软件项目管理

5.7.2 软件项目估算

基本COCOMO 估算方法

E=a(L)bE=a(L)^bE=a(L)b

D=cEdD=cE^dD=cEd

E:工作量,人月,D:开发时间,月, L:项目的源代码行估计值, 不包括注释和文档,abcd为常数

COCOMOII模型

以规模作为成本的主要因素, 考虑了多个成本驱动因子.

应用组装模型
早期阶段设计模型
体系结构阶段模型

5.7.3 进度管理

gantt图

能描述每个任务从何开始,到何结束, 进度的进展情况以及各个任务之间的并行性

不能反映任务之间的依赖关系
PERT图

上述的优点+可以反映依赖关系

5.7.6 风险管理

项目风险
技术风险
商业风险

风险预测

风险显露度:

RE=P∗CRE = P*CRE=P∗C

p:风险发生的概率, c:风险发生时带来的项目成本

5.8 软件质量

功能性
1. 适应性
2. 准确性
3. 互用性
4. 依从性
5. 安全性
可靠性
1. 成熟性
2. 容错性
3. 易恢复性
易使用性
1. 易理解性
2. 易学性
3. 易操作性
效率
1. 时间特性
2. 资源特性
可维护性
1. 易分析性
2. 易改变性
3. 稳定性
4. 易测试性
可移植性
1. 适应性
2. 易安装性
3. 一致性
4. 易替换性

软件的质量属性

可靠性, 可用性, 可维护性

可靠性

指一个系统对于给定的时间间隔内, 在给定条件下无失效运作的概率

MTTF/(1+MTTF) MTTF为平均无故障时间

可用性

指一个系统在给定的时间上, 能按照规格说明正常运作的概率

MTBF/(1+MTBF) MTBF为平均失效间隔时间

可维护性

指一个系统对于给定的时间间隔内, 在给定条件下,使用规定的过程和资源完成维护的活动

1/(1+MTTR) MTTR是平均修复时间

McCabe度量法

V(G)=边−点+2V(G) = 边-点+2V(G)=边−点+2

软件配置管理

包括版本控制, 变更控制, 过程支持