软件工程课程笔记
软件
●与计算机系统操作有关的程序、规程、规则及任何与之有关的文档和数据
●软件=程序+数据+文档
程序设计语言的发展
●机器语言
●汇编语言
●高级语言
●面向问题的4GL
文档
●标准化
●规范化
开发过程
●依赖于开发人员的专业素养，脑力劳动，开发成本、进度很难估计，不可预料因素较多，
产品的不可见性，错误不可能完全剔除
使用过程
●大量维护投入（纠错、完善、适应）
逻辑特性
●不会磨损，但会老化
变更与错误影响范围具有扩大的效应
软件分类（基于开发过程）：CASE工具软件、个人计算机软件、人工智能软件、事务处理软件、科学与工程计算机软件、嵌入式软件、系统软件、实时软件
软件危机的表现
●软件越来越复杂，规模越来越庞大
●但是单纯增加人力，并不能提高生产力
●随着人员的增加，组织、管理、协调成长突出问题
软件危机的产生原因
●需求定义不完整、不精确，用户参与少
●没有挖掘用户愿望
●缺乏发型项目开发经验和项目组织经验
●缺乏有力的方法学和工具支持
●软件产品的特殊性：复杂，开发过程不可见，进度难以估计
开发模型：
瀑布型模型
原型模型
螺旋模型
基于4GL技术的模型
变换模型
敏捷开发
组合模型
CASE工具及环境
软件工具：单一，不兼容
CASE：集成，协同
第3讲软件项目管理
对软件项目开发过程中所涉及的过程、人员、产品、成本和进度等要素进行度量、分析、规划、组织和控制的过程，以确保软件项目按照预订的成本、进度、质量要求顺利完成开发任务。
●过程管理
过程定义和剪裁
软件项目计划
软件度量
软件项目的跟踪和监督
风险管理
●人员管理
软件项目团队
纪律和激励机制
●产品管理
软件需求管理
软件质量保证
软件配置管理
软件度量（Metrics）是指对软件产品、软件开发过程或者资源的简单属性的定量描述
●产品：软件开发过程中所发生的各种文档和程序
●过程：与软件开发有关的各种活动，如软件设计等
●资源：软件开发过程中所需支持，如人员、费用等
注意点
●定量描述，而不是定性描述
●简单属性无需参照其它属性便可直接获得定量描述。
软件测量（Measure）是对软件产品、软件开发过程和资源复杂属性的定量描述，它是简单属性度量值的函数，软件测量用于事后或实时状态，如软件可靠性
●注意点
定量描述，而不是定性描述
复杂属性，不可直接获得、需要参照其它属性的度量值
估算（Estimation）对软件产品、软件开发过程和资源复杂度属性的定量描述，它是简单属性度量值的函数，软件估算用于事前，如软件开发成本
●注意点
定量描述，而不是定性描述
复杂度，不可直接获得、需要参照其它属性的度量值
事前状态
可采用经验公式，可参考历史资料和数据。
估算的结果一般用于签订合同、立项、指定
工作计划等
用软件代码行数来表示软件项目规模
生产率P=L/E（KLOC/人.月）L：代码量E：软件项目工作量
平均成本C=S/L（每千行代码成本）S：软件项目的总开销
文档与代码比D=Pd/L（每千行代码页数）Pd：软件项目的文档页数
代码出错率EQR=Ne/L（每千行代码错误数）Ne：软件项目的代码缺陷数
成本估算是双方签订合同的主要依据：另一方面，涉及因素多，难以精确估计
常用的估算方法
参照和依据已完成项目的历史数据
将大项目分解为小项目
将项目按照软件生命周期分解
根据经验估算公式
组合使用以上各方法
CoCoMo模型
●CoCoMo是Boehm于1981年提出的构造性成本模型（Constructive Cost Model），用于
对软件开发项目的规模、成本、进度等方面进行估算
●基本CoCoMo模型
系统开发的初期，估算整个系统的工作量（包括维护）和软件开发和维护所需的时间●中间CoCoMo模型
估算各个子系统的工作量和开发时间
●详细CoCoMo模型
估算独立的软构件，如各个子系统的各个模块的工作量和开发时间
Putnam估计模型
Putnam于1978年提出了发型项目、动态多变量估计模型。
L——源程序代码行数L=CKEtd
td——技术常数
E——工作量
软件质量至关重要，质量不高的软件会带来严重、甚至灾难性的后果
不同的人对质量的理解与要求是不同的
软件质量：软件产品满足规定的和隐含的与需求有关的全部特征和特性。
●软件质量依赖于软件内部特性及其组合；
●必须加强对软件质量的管理和监控；
●必须在开发过程中能够可视化所开发软件的质量。
质量要素：面向管理者的软件质量
质量要素的评价准则：面向技术、决定产品质量的软件属性
软件质量的度量：可以量化度量的软件属性及度量方法
1987年HP提出的FURPS软件质量要素：功能性、可用性、可靠性、性能、可支持性1985年IOS建议的软件质量模型：
高层软件质量需求评价准则SQRC
中层软件质量设计准则SQDC
底层软件质量度量评价准则SQMC
质量度量应该在软件开发过程中持续不断地进行。
软件复杂度：
●理解程序的难度
●纠错、维护程序的难度
●向他人解释程序的难度
●按指定方法修改程序的难度
●根据设计文档编写程序的工作量
●执行程序时需要资源的程度
需求分析：
●需求分析的任务
●获取需求的方法
●需求建模与分析
●需求规格说明及评审
软件需求：是指用户对目标软件在功能、行为、性能、设计约束等方面的需求
需求的分类
●功能性需求：业务功能及操作对象
●非功能性需求：性能约束等
●其它约束：开发、运行环境等
需求分析与软件过程：
系统工程→需求分析（需求质量保证，需求获取验证方法）[系统架构，开发计划修订]→需求规格说明书→评审→软件设计
其它文档：
需求定义；
用户使用手册；
系统架构设计；
开发设计。
需求规格说明书的主要内容：
●分类逐项描述每一项需求
●建立需求规格说明与用户需求之间的对应关系
●注意：
1.描述方法要与建模方法相对应
2.可以多种描述方法相结合
3.描述的抽象层次要一致
4.描述一定是精确、准确
需求规格说明书
●引言
需求规格说明书的目的
软件产品的作用范围
定义、同义词和缩略词
参考文献
需求规格说明书概览
●一般性描述
产品与其环境之间的关系
产品功能
用户特征
限制与约束
假设与前提条件
●需求描述
功能需求N：引言、输入、处理、输出●外部界面需求N
用户界面
硬件界面
软件界面
●性能需求N
●设计需求N
标准化约束
硬件约束
………
●属性
可用性
可靠性
安全性
可移植性
………
●其它需求
数据库需求
用户操作需求
用户场地需求
………需求评审内容
正确性
无歧义性
完备性
可验证性
一致性
可理解性
可追踪性
需求分析小结：
明确需求的概念与任务、过程、方法问题的抽象与抽象层次
成果：软件需求规格说明书。