软件工程基础知识
1.软件工程概述:
1.1 计算机软件
- 软件危机:软件开发和维护中遇到的各种问题。
- 软件工程目的:提高软件生产效率,提高软件质量,降低软件成本。
- 计算机软件:程序+文档
- 计算机软件分类:
- 系统软件:一整套服务于其他程序的程序,如OS
- 应用软件:解决特定业务需要的独立应用程序,如APP
- 工程/科学软件:常常带有“数值计算”特征,如CAD
- 嵌入式软件:存在于某个产品或系统中,如汽车仪表盘
- 产品线软件:为多个不同用户使用特定功能。
- Web应用:以网络为中心的软件
- 人工智能软件:利用非数值计算解决复杂问题
- 开放计算
- 网络资源
- 开源软件
1.2 软件工程基本原理
- 用分阶段的生命周期计划严格管理
- 坚持进行阶段评审
- 实现严格的产品控制(主要是实行基准配置管理)
- 采用现代程序设计技术
- 结果应能清楚的审查
- 开发小组人员应少而精
- 承认不断改进软件工程实践的必要性
1.3 软件生命周期
- 可行性分析与项目开发计划:(确定软件的开发目标及其可行性),产生可行性分析报告和项目开发计划
- 需求分析:(准确的确定软件需要做什么)产生软件需求说明书
- 概要设计:(设计软件的结构,明确软件由那些模块构成),产生概要设计说明书
- 详细设计:(对每个模块完成的功能进行具体描述,把功能描述转化为精确的,结构化的过程描述),产生详细设计文档
- 编码:(编码实现),产生源程序清单
- 测试:(保证软件质量,产生软件测试计划,测试用例和软件测试报告
- 维护:(生命周期最长)
1.4 软件过程
软件开发中遵循的路线图(一系列可预测的步骤)称为软件过程。过程是活动的集合,活动是任务的集合。
-
能力成熟度模型(CMM):对软件组织进化阶段的描述
- 初始级:软件过程杂乱无章,没有明确定义步骤,项目依赖于英雄核心人物
- 可重复级:建立了基本项目过程和实践,有必要的过程准则来重复以前同类项目的成功
- 已定义级:管理和工程已经文档化,标准化
- 已管理级:制定了软件过程和产品质量的详细度量标准
- 优化级:最高级别
-
能力成熟度模型集成(CMMI):若干个过程模型的综合和改进
- 阶段式模型:类似CMM,关注组织成熟度
- 连续式模型:关注每个过程域的能力,过程域能力分为6个等级
2. 软件过程模型
也叫软件开发模型,是软件开发全部过程,活动和任务的结构框架
-
瀑布模型:将生命周期中各个活动规定为依线性顺序连接的若干阶段的模型。以文档为驱动,适合于软件需求很明确的软件项目。 V模型:瀑布模型的变体,提供了一种将验证确认活动应用于早期软件过程的方法。
-
增量模型:将需求分段为一系列增量产品,每一增量可以分别开发。第一增量往往是核心产品。强调每一个增量均发布一个用户可操作的产品。
-
演化模型
- 原型模型:适用于用户需求不清,需求经常发生变化的情况。适用于系统规模不是很大也不太复杂的情况。 原型开始于沟通,是预期系统的一个可执行版本,不必满足目标软件的所有约束。
- 螺旋模型:结合瀑布模型和演化模型。强调风险分析。适合于庞大复杂具有高风险的系统。
-
喷泉模型:以用户需求为动力,以对象为驱动,适合于面向对象开发方法。具有迭代性(开发活动常常需要重复多次来完善)和无间隙性(开发活动之间不存在明显边界)。要求严格管理文档,审核难度大,需要大量开发人员。
-
基于构件的开发模型:利用预先包装的构件来构造应用系统。本质是是演化模型。
-
形式化方法模型:建立在严格数学基础上的软件开发方法。
-
统一过程模型:用例和风险驱动,以架构为中心,迭代并增量的开发过程。由UML方法和工具支持。
- 起始阶段:生命周期目标
- 精化阶段:生命周期框架
- 构建阶段:初始运作功能
- 移交阶段:产品发布
-
敏捷方法:尽可能早的持续的对有价值的软件的交付。
- 极限编程(XP):一种轻量级,高效,低风险,柔性,可预测,科学的软件开发方式
- 水晶法:认为每个不同的项目都需要不同的策略和方法论,认为人对软件质量有重要影响。
- 并列争求法:使用迭代方法
- 自适应软件开发:用使命作为指导,重做与做同样关键
- 敏捷统一过程:在大型上连续在小型上迭代
3. 需求分析
3.1 软件需求
进行需求获取之前,首先要明确需要获取什么,也就是需求包含那些内容。
- 功能需求:系统需要做什么
- 性能需求:技术指标
- 用户或人的因素:考虑用户类型
- 环境需求:考虑未来软件应用的环境,包括硬件和软件环境
- 界面需求
- 文档需求
- 数据需求
- 资源使用需求
- 安全保密要求
- 可靠性要求
- 软件成本消耗与开发进度需求
- 其他非功能性需求
3.2 需求分析原则
- 必须能够表示和理解问题的信息域
- 必须能定义软件将完成的任务
- 必须能表示软件的行为
- 必须划分描述数据,功能和行为的模型
- 分析过程从要素信息移向细节信息
3.3 需求工程
需求工程是一个不断反复的需求定义,文档记录,需求演进的过程,并最终在验证的基础上冻结需求。
- 需求获取
- 需求分析与协商
- 系统建模
- 需求规约:(是分析任务的最终产物)
- 需求验证
- 需求管理:(每个需求被赋予唯一标识,建立跟踪表)
4. 系统设计
4.1 概要设计
- 设计软件体系总体结构
- 数据结构及数据库设计
- 编写概要设计文档
- 评审
4.2 详细设计
- 对每个模块进行详细算法设计
- 模块内数据结构设计
- 确定数据库物理结构
- 其他设计(代码,界面,输入输出等)
- 编写详细设计说明书
- 评审
5. 系统测试
5.1 系统测试与调试
- 系统测试的意义:系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误的测试。
- 系统测试的目的:测试的目的是希望以最少人力物力和时间发现潜在的错误和缺陷。
- 系统测试的原则
- 应尽早并不断的进行测试
- 测试工作避免由原开发软件小组担任
- 测试用例应该由合理的数据+不合理的数据组成
- 测试方案要与预期结果对比
- 避免测试随意性
- 保存测试用例,文档等。为维护提供方便
- 精心设计测试用例
- 测试过程(基本上与开发过程平行进行)
- 制定测试计划
- 编制测试大纲
- 设计测试用例
- 进行测试
- 生成测试报告
5.2 传统软件的测试策略
-
单元测试:侧重于模块中的内部逻辑和数据结构,一般用白盒测试,可以多模块同时进行。测试内容包括模块接口,局部数据结构,执行路径,出错处理和边界条件,测试过程(模块不是独立运行的程序,对每个模块测试时需要开发两种模块:驱动模块+桩模块)
-
集成测试:把模块按系统设计说明书组合起来进行测试。其目标是利用已通过单元测试的构件建立设计中描述的程序结构。 测试方法(非增量集成+增量集成),以下是一些增量集成策略
- 自顶向下集成测试:从主控模块开始,沿着控制层逐步向下,以深度或广度的方式,将从属模块集成到结构中。
- 自底向上集成策略:从原子模块开始进行构造和测试。(没必要使用桩模块 ,因为从属模块总是存在的)
- 回归测试:从新测试已经测试过的某些子集,以确保变更没有传播不期望的副作用。
- 冒烟测试:使软件团队频繁的对项目进行评估。
-
确认测试:在进行确认测试时,不同平台方式软件之间的差别已经消失,测试集中于用户可见的动作和用户可识别的系统输出。 【确认测试准则,配置评审(确保文档资料完善齐全),α测试于β测试(期待查找到似乎只有最终用户才能发现的错误)】
-
系统测试:将软件,硬件,外设,网络等结合在一起进行的各种集成测试和确认测试。目的是通过与系统的需求相比较,发现开发的系统是否满足用户期望。包括【恢复测试,安全性测试,压力测试,性能测试,部署测试】
5.3 测试面向对象软件
- 单元测试:封装的类是单元测试的重点,类中包含的操作是最小的可测试单元。
- 集成测试:【基于线程的测试,基于使用的测试】
5.4 测试Web应用
- 质量维度
- WebApp测试策略
5.5 测试方法
在软件测试工程中,应该定义软件测试模板,即将特定的测试方法和测试用例设计放在一系列测试步骤中。
- 静态测试:被测试程序不在机器上运行【人工检测(代码检查,结构分析等)+计算机辅助静态分析(逻辑,结构)】
- 动态测试:通过运行程序发现错误。
- 黑盒测试:也叫功能测试,不考虑软件内部结构和特性,测试软件外部特性。常用黑盒测试技术:
- 等价类划分
- 边界值分析
- 错误推测
- 因果图
- 白盒测试:也叫结构测试,根据程序内部结构和逻辑来设计测试用例,对程序的路径和过程进行测试,检查是否满足设计需求。常用白盒测试技术:
- 逻辑覆盖
- 循环覆盖
- 基本路径测试
- 黑盒测试:也叫功能测试,不考虑软件内部结构和特性,测试软件外部特性。常用黑盒测试技术:
5.6 调试
调试发生在测试之后,其任务是根据测试时发现的错误找出原因和具体位置进行改正。调试由开发者本人进行。
- 调试过程(困难)
- 调试方法【试探法(简单程序),回溯法(小型程序),对分查找法(缩小错误范围),归纳法(从测试所暴露的问题出发),演绎法】
6.运行和维护
6.1 系统转换
- 直接转换:立即启用新系统,中止旧系统运行。(适用于处理过程不太复杂,数据不太重要的场合)
- 并行转换:新旧系统并行运行一段时间,经过时间考验后新系统正式替代旧系统。(安全可靠但费用工作量大)
- 分段转换:上述两种方法的结合(要求子系统有一定独立性以实现逐步转换)
6.2 系统维护概述
软件维护是软件生命周期最后一个阶段,不属于系统开发过程。
- 系统可维护性概念:【可维护性评价指标(可理解性+可测试性+可修改性),维护与软件文档(可维护性的决定因素),软件文档的修改】
- 系统维护内容及类型:【硬件维护,软件维护,数据维护(包括代码维护)】
- 系统维护管理和步骤
6.3 系统评价
- 系统评价概述:【立项评价+中期评价+结项评价】
- 系统评价指标:
- 从信息系统的组成部分出发(人+系统)
- 从信息系统的评价对象出发
- 从经济学角度出发
7. 软件项目管理
7.1 软件项目管理范围
有效的软件项目管理集中在4P,即人员,产品,过程,项目。
- 人员:【项目管理人员+高级管理人员+开发人员+客户+最终用户】
- 产品:定义项目范围
- 过程:进行过程控制
- 项目:【明确目标及过程,保持动力,跟踪进展,做出明确决策,进行事后分析】
7.2 软件项目估算
基于已经完成的类似项目估算+基于分解技术进行估算+基于经验估算模型
加粗样式1. 成本估算方法;
1. 自顶向下估算法
2. 自底向上估算法
3. 差别估算法
4. 其他估算法(专家估算法,类推估算法,算式估算法)
2. COCOMO估算模型【E表示工作量(人月),D表示开发时间(月),L源代码行估计值(千行,不包括注释及文档),其他字母为常数,EAF(工作调节因子)】
1. 基本COCOMO模型:静态单变量模型,用于对整个软件系统进行估算。E = aL^b ,D = cE^d
2. 中级COCOMO模型:静态多变量模型,软件系统模型=系统+部件。E=aL^bEAF
3. 详细COCOMO模型软件系统=系统+子系统+模块
3. COCOMOII模型:【应用组装模型+早期设计阶段模型+体系结构阶段模型】
4. Putnam估算模型:动态多变量模型
7.3 进度管理
- 进度管理基本原则:【划分+相互依赖+时间分配+工作量确认+明确责任+明确输出结果+明确里程碑】
- 进度安排:
- Gantt图(不能反映依赖关系,项目关键)
- PERT图(不能反映任务之间并行关系)
7.4 软件项目的组织
- 组织结构的模式:(项目划分模式,职能划分模式,矩阵模式)
- 程序设计小组组织方式:【主程序员制小组,民主制小组(组内通信路径多),层次式小组】
7.5 软件配置管理
使变更带来的错误达到最小,并有效提高生产力。管理软件生命周期中变更的活动。
- 基线:软件生命周期中各阶段的一个特定点。作用是使各开发阶段工作划分更明确,便于检查阶段成果
- 软件配置项SCI:(动态的概念)配置管理的基本单位,修改已经成为基线的软件配置项必须严格审查。
- 版本控制:一系列SCI的组合
- 变更控制
7.6 风险管理
软件风险一般包括两个特性:不确定性和损失。技术风险威胁到开发软件的质量和交付时间,商业风险威胁到软件的生存能力。
- 风险识别
- 风险预测
- 风险评估
- 风险控制
8.软件质量
8.1 软件质量特性
- ISO/IEC 9126软件质量模型
- Mc Call软件质量模型
8.2 软件质量保证
- 软件必须满足用户需求,与用户需求不一致的软件没有质量可言
- 软件应遵循规定开发标准原则
- 软件满足某些隐性需求(可理解性,可维护性等)
8.3 软件评审
- 设计质量的评审
- 程序质量的评审
8.4 软件容错技术
实现容错的主要手段是冗余。冗余是指对于实现系统规定功能是多余的那部分资源。
- 结构冗余:【静态冗余,动态冗余,混合冗余】
- 信息冗余
- 时间冗余
- 冗余附加技术
9. 软件度量
9.1 软件度量的分类
- 面向规模的度量:常用代码行度量(依赖于具体语言)
- 面向功能的度量
9.2 软件复杂性度量
一般包括规模,难度,结构,智能度。包括程序复杂性和文档复杂性,一般体现在程序复杂性。
- 程序复杂性度量原则
- McCabe度量法:基于程序控制流的程序复杂性度量方法。
10. 软件工具与软件开发环境
10.1 软件工具
- 软件开发工具
- 软件维护工具
- 软件管理和软件支持工具
10.2 软件开发环境
由软件工具集和环境集构成