上午题-11-软件工程
[toc]
能力模型
CMM(能力成熟度模型)
- 初始级——软件过程的特点是杂乱无章,有时甚至很混乱,几乎没有明确定义的步骤,项目的成功完全依赖个人的努力和英雄式核心人物的作用
- 可重复级——建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性
- 已定义级——管理和工程两方面的软件过程已经文档化、标准化
- 已管理级——制定了软件过程和产品质量的详细度量标准
- 优化级——加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进
CMMI(能力成熟度集成模型)
阶段式模型
关注组织的成熟度
- 初始的——过程不可预测且缺乏控制
- 已管理的——过程为项目服务
- 已定义的——过程为组织服务
- 定量管理的——过程已度量和控制
- 优化的——集中于过程改进
连续式模型
关注每个过程域的能力
- CL0(未完成的):过程域未执行或未得到CL1中定义的所有目标
- CL1(已执行的):其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品
- CL2(已管理的):其共性目标集中于已管理的过程的制度化
- CL3(已定义级的):其共性目标集中于已定义的过程的制度化
- CL4(定量管理的):其共性目标集中于可定量管理过程的制度化
- CL5(优化的):使用量化(统计学)手段改变和优化过程域
开发模型
瀑布模型(需求明确)
适合开发需求明确的,需求大致固定不会随意变更的系统。
一个变体是V模型,特点在于质量保证活动和沟通
增量模型(快速构建)
拥有瀑布模型的所有优点,特点在于快速构造可运行的产品
另外的优点:
- 第一个可交付版本所需要的成本和时间很少
- 开发由增量表示的小系统所承担的风险不大
- 可以减少用户需求的变更
- 运行增量投资,即在项目开始时,可以仅对一个或两个增量投资
不足之处:
- 如果没有对用户的变更要求进行规划,那么产生的初始增量可能会造成后来增量的不稳定
- 如果不像早期思考的那样稳定和完整,那么一些增量可能需要重新开发,重新发布:管理发生的成本、进度和配置的复杂性可能会超出组织的能力
演化(迭代)模型
演化模型是迭代的过程模型,使得软件开发人员能够逐步开发出更完整的软件版本。
适用于:
- 对软件需求缺乏准确认识的情况
典型的演化模型有原型模型和螺旋模型
原型模型
适合需求模糊且系统规模不大
螺旋模型
特点是加入了风险分析,支持用户需求的动态变化
适合大规模高风险的,需求变化的系统
每个螺旋周期的步骤:
- 制定计划
- 风险分析
- 实施工程
- 用户评估
喷泉模型
一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法
喷泉模型使开发过程具有迭代性和无间隙性
各个阶段没有明显的界线
优点:
- 提高软件项目的开发效率,节省开发时间
缺点:
- 不利于项目的管理
统一过程(UP)模型
是一种”用例和风险驱动,以架构为中心,迭代并且增量“的开发过程
敏捷开发
总体目标是“尽可能早地、持续地对有价值的软件的交付”
极限编程(XP)
水晶法和并列争求法
自适应软件开发
敏捷统一过程(AUP)
开发过程
需求分析
概要设计(模块、接口、数据结构、数据库)
详细设计(数据机构、算法、数据库)
测试
单元测试
检测模块接口、局部数据结构、重要的执行路径、出错处理、边界条件
驱动模块
桩模块:被调模块
集成测试
自顶向下集成不需要驱动模块,自底向上不需要桩模块
- 自顶向下集成测试
- 自底向上集成测试
- 回归测试
- 冒烟测试
测试方法
黑盒测试
- 等价类划分
- 边界值分析
- 错误推测
- 因果图
McCabe度量法
环路复杂度计算:
- 闭合区域数量+1
- 边-节点+2
白盒测试
语句覆盖<判定覆盖<条件覆盖<判定/条件覆盖<条件组合覆盖<路径覆盖
维护
系统可维护性评估指标
- 可理解性
- 可测试性
- 可修改性
软件维护
- 正确性维护
- 适应性维护
- 完善性维护
- 预防性维护
可靠性、可用性、可维护性
COCOMO模型
基本——静态单变量
中级——静态多变量
COMCOMOII
对象点、功能点、代码行
应用组装模型使用的是对象点
早期设计阶段模型使用的是功能点
图
Gantt图
Gantt图不能清晰地反映出各任务之间的依赖关系
PERT图
软件配置管理
风险
软件风险包含两个特性:
- 不确定性
- 损失
ISOIEC
- 功能性(包含安全性)
- 可靠性(易恢复性、成熟性、容错性)
- 易使用性(易理解性、易学性、易操作性)
- 效率
- 可维护性(易分析性、易测试性)
- 可移植性
容错技术
软件工具
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Torch's blog!