软件工程

软件工程概述

软件工程基本原理

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

软件生存周期

• 可行性分析与项目开发计划
• 需求分析
• 概要设计
• 详细设计
• 编码
• 测试
• 维护

软件过程

能力成熟度模型(CMM):

• 初始级（Initial）杂乱无章，甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式的核心人物的作用。
• 可重复级（Repeatable）可跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
• 已定义级（Defined） 软件过程已经文档化，标准化，并综合成整个软件开发组织的标准软件过程。所有软件项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
• 已管理级（Managed）制定了软件过程和产品质量的详细度量标准。软件过程的铲平质量都被开发组织的成员理解和控制。
• 优化级（Optimized）加强了定量分析，通过来自过程的反馈和来自观念、新技术的反馈使过程不断持续地改进

软件过程模型

瀑布模型

以文档驱动的，适合软件开发过程很明确的软件项目的模型。

增量模型

优点：

• 第一个可交付版本所需要的成本和时间很少。
• 开发由增量表示的小系统所承担的风险不大。
• 由于很快发布了第一个版本，因此可以减少用户的需求变更。
• 运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。

缺点：

• 如果没有对用户的变更要求进行规划，你吧么产生的初始增量可能会造成后来增量的不稳定。
• 如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。
• 管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

原型模型

原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，采用该方法。

螺旋模型

结合了瀑布模型和演化模型，分为如下4个工作步骤：

• 制定计划。
• 风险分析。
• 实施工程。
• 用户评估。

螺旋模型强调风险分析，适用于庞大，复杂且具有高风险的系统。

喷泉模型

是一种以用户需求为动力，已对象作为驱动的模型，适合于面向对象的开发方法，具有迭代性和无间隙性。
优点：

• 各个阶段没有明显的界限，开发人员可以同步进行，提高软件的开发效率，节省时间。

缺点：

• 各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目管理。
• 要求严格管理文档，使得审核的难度加大。

基于构建的开发模型

具有多螺旋模型的特点，它本质上是演化模型，需要以迭代的方式构建软件。其不同之处在于基于构建的开发模型采用预先打包的软件构建开发应用系统。

统一过程（UP）模型

是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。

4个技术阶段：

• 起始阶段。
• 精化阶段。
• 构建阶段。
• 移交阶段。

敏捷方法

• 极限编程（XP）
  四大价值观：沟通、简单性、反馈和勇气。
  5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
• 水晶法（Crystal）
• 并列争求法（Scrum）
• 自适应软件开发（ASD）

需求分析

软件需求

• 功能需求。（要做什么，何时做在何时一级如何修改或升级）
• 性能需求。（存储容量限制、执行速度、响应时间及吞吐量）
• 用户或人的因素。（用户使用计算机的熟练程度，用户错误操作的可能性）
• 环境需求。（外设、接口、地点、分布、湿度、磁场、系统、网络、数据库）
• 界面需求。
• 文档需求。
• 数据需求。（输入输出数据的格式、接受发送数据的频率、数据的准确性和精度）
• 资源使用需求。
• 安全保密要求。
• 可靠性要求。
• 软件陈本消耗和开发进度。
• 其它非功能性需求。（开发模式、维护性、验收标准…）

软件需求说明书

• 数据描述
• 数据流图
• 数据字典描述
• 胸接口描述
• 内部接口说明
• 系统的功能描述
• 处理说明
• 系统设计的限制
• 系统的性能描述
• 性能参数
• 对系统进行测试的种类

系统设计

怎么做？

概要设计

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

详细设计

• 算法设计
• 模块内的数据结构设计
• 数据库物理机构设计
• 其它设计
• 评审

系统测试

系统测试的目的

系统测试是为了发现错误而执行程序的过程。

系统测试的基本原则

• 应尽早并不断地进行测试。
• 测试工作应该避免由原软件的人或小组承担。
• 要根据系统功能确定预期输出结果。
• 既要包含有效、合理的输入条件，也要包含不合理、失效的输入条件
• 在测试程序时，不仅要检验程序员是否做了该做的事，还要检验程序是否做了不该做的事
• 严格按照测试计划进行
• 妥善保存测试计划，测试用例
• 测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便

单元测试

也成模块测试，侧重于模块中的内部处理逻辑和数据结构。

测试内容：

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

集成测试

把模块按系统设计说明书的要求组合起来进行测试。

• 自顶向下的集成测试
• 自底向上的集成测试
• 回归测试
• 冒烟测试

确认测试

确认测试始于集成测试的结束，那是就已经测试完单个构建。

系统测试

各种集成测试和确认测试。

测试web应用

质量维度

• 内容
• 功能
• 结构
• 可用性
• 导航性
• 性能
• 兼容性
• 安全性

黑盒测试

• 等价类划分
• 边界值分析
• 错误推测
• 因果图

白盒测试

• 语句覆盖（SC）
  被测程序的每个语句至少执行一次。
• 判定覆盖 （DC）
  每个判定的每种结果至少执行一次
• 条件覆盖 （CC）
  每个条件的结果至少执行一次
• 判定/条件覆盖（CDC）
  同时满足判定覆盖和条件覆盖
• 条件组合覆盖（MCC）
  判定中所有可能的条件组合
• 路径覆盖

调试方法

• 试探法
• 回溯法
• 对分查找法
• 归纳法
• 演绎法

运行和维护知识

系统转换

• 直接转换
• 并行转换
• 分段转换

系统可维护性的评价指标

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

软件维护

• 正确性维护
• 适应性维护
• 完善性维护
• 预防性维护

系统评价

• 立项评价
• 中期评价
• 结束评价

软件项目管理

软件项目管理设计的范围

1、人员

• 项目管理人员（项目经理）
• 高级管理人员
• 开发人员
• 客户
• 最终用户

2、产品（软件环境）

• 项目环境
• 信息目标
• 功能和性能

3、过程
选择过程模型

4、项目

• 明确目标及过程
• 保持动力
• 跟踪进展
• 作出明智的决策
• 进行时候分析

软件项目估算

COCOMO估算模型
基本COCOMO模型
E = a(L)^b
D = cE^d
E表示工作量，单位时人月；D表示开发时间，单位是月；L是项目的源代码估计值，单位是千行；a、b、c、d是常数

中级COCOMO模型
E = a(L^b)EAF
EAF是工作量调节因子

Putnam估算模型

进度管理

进度管理的基本原则：

• 划分
• 相互依赖性
• 时间分配
• 工作量确认
• 确定责任
• 明确输出结果
• 确定里程碑

进度安排：
Gantt图
PERT图

软件质量

由质量保证、质量规划和质量控制三部分组成