软件工程介绍
1．软件工程：研究一个包含一系列方法和工具的框架，同时研究软件产生，发展，应用，维护等过程中的理论，方法和工具
2. Software
l 指令的集合，通过执行这些指令可以满足预期的特征，功能和性能要求
l 数据结构，使得程序可以充分利用信息
l 描述程序操作和使用的文档
3. 遗留软件
l 调整来满足新的计算环境或技术的需要
l 改善来实现新的业务需求
l 扩展使得它能和其它更加现代的系统或数据库进行交互
l 重新架构使得它在新的网络环境中可实施
过程综述
- IEEE定义：软件工程是将系统化的，规范的，可量化的方法应用于软件的开发，运行和维护，即将工程化的方法应用于软件。同时也是对以上所说方法的研究。
- 软件工程层次化技术：
质量关注点（目的）–过程（约束，框架）—方法（指导，保证）–工具（手段）
- 框架活动
沟通—策划—建模（需求分析和设计）—构建（编码和测试）—部署
- CMMI能力成熟度模型集成，使用两种方式描述过程元模型
l 作为一个连续的模型，每个过程域都根据特定的目标和实践要求进行严格的评估
l 作为一个阶段性模型，定义五个成熟度等级，达到等级需要达到相应的目标
- 过程模式
提供一个模板，一种描述软件过程中重要特征的一致性方法。
过程模型
- 瀑布模型—经典生命周期模型
沟通—策划—建模—构建—部署
- 增量过程模型
第一个增量往往是核心产品，满足了基本需求
- RAD模型—快速应用开发
是瀑布模型的高速变体，侧重于短暂开发周期的增量软件过程模型
- 演化过程模型—原型开发
原型是为定义需求服务的
5. 演化过程模型—螺旋模型
原型迭代性质+瀑布模型的系统性和可控制性。采用循环方式逐步加深系统定义和实现深度同时降低风险，确定一系列里程碑确保共利益者都支持解决方案
- 演化过程模型—协同开发模型
定义一系列事件，这些事件将触发SE活动、动作或者任务的状态转换
7．专用过程模型
基于构件的开发—商品化成品软件构件。形式化方法模型—生成计算机软件形式化的数学规格说明。AOSD面向方面的软件开发。
- 统一模型过程
一种用例驱动，以架构为核心，迭代并且增量的软件过程。起始—细化—构建—转换—生产
敏捷开发
- 敏捷理念
l 让客户满意和软件尽早发布
l 小而高度自主的项目团队
l 非正式的方法
l 最小化软件工程产品以及整体精简开发
- 敏捷概念（Agility）
l 有效的响应变化
l 共同利益者之间有效的沟通
l 把客户拉入团队
l 组织一个队伍，使得该队伍为目前执行的任务所用
- 敏捷过程
l 由客户描述的需求驱动
l 识别出计划是短期的
l 迭代的开发软件，重点强调构建行为
l 交付多个软件增量
l 适应随时发生的变化
4．极限编程
l XP策划
l XP设计
l XP编程
l XP测试
- 自适应软件开发
l 思考—启动软件项目并完成自适应循环计划
l 协作—协作，信任
l 学习—开始开发构件时，重点是完成循环的方向学习尽可能多的东西
- 动态系统开发方法
l 可行性研究
l 业务研究
l 功能模型迭代
l 设计和构件迭代
l 实现
- 特征驱动开发
l 强调定义特征（特征是用户可以方便描述的小块的可发布的功能）
l 创建特征列表并且执行特征导向的计划
l 设计和构建在FDD中是融合在一起的
系统工程
1.Elements of a computer-based system
l Software
l Hardware
l People
l Database
l Documentation
l Procedures
2.系统架构
l 数据架构：为业务或业务功能的信息需求提供了框架
l 应用架构：包含那些为某些业务目的而在数据架构范围内进行转换的系统要素
l 技术基础设施：为数据架构和应用架构提供基础
需求工程
起始—导出—精化—协商—规格说明—确认—需求管理
构建分析模型
需求分析
l 产生软件操作特征的规格说明
l 指明软件和其他系统元素的接口
l 建立软件必须满足的约束
域分析
识别，分析和详细说明来自某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的。
l 定义要分析的领域
l 收集该领域应用有代表性的样本
l 分析样本中的每个应用
l 为对象开发分析模型
数据建模
l 独立于过程地检查数据对象
l 专注于数据领域
l 创建一个在客户的抽象层次上的模型
l 指示出数据对象如何相互关联
数据对象
几乎任何必须被软件理解的复合信息的表示。复合信息是指具有若干不同特征或属性的事物
l 对象的每个实例必须能够被唯一的识别
l 每个数据对象在系统中都是不可缺少的，即不访问对象实例系统功能无法实现
l 每个数据对象都由数据项形式的属性来描述
关系
l 必须被系统记住的一个事实，而且不能被计算，也不能被推导得出
l 可以存在一个关系的多个实例
l 对象可以以多种不同方式相关联
CRC模型
职责：类封装的属性和操作（类所知道的或能做的任何事）
协作：那些提供完成某个职责所需要的信息的类（协作意味着信息请求或者动作请求）
实体类：模型和业务类，从问题说明中直接提取出来的，这些类一般代表保存在数据库中的和贯穿应用程序的事物。
边界类：用于创建用户可见的和交互的接口，被设计成负责管理实体对象对用户的不同方式
控制类：管理工作单元，包括管理实体类的创建和更新等。
系统状态
l State—一组刻画在既定时间系统行为的可观察的特征
l State transition—从一个状态到另一个状态的转移
l Event—导致系统表现出可预测行为形式的发生
l Action—作为一个状态转移的结果发生的过程
设计工程
质量指导原则
l 设计应展示出以下数据结构：（已经使用可识别的体系结构或模式创建，由展示出良好设计特征的构件构成，能够以演化的方式实现）
l 设计应该模式化
l 设计应该包含数据、体系结构，接口和构件的清楚表示
l 设计应导出数据结构，这些数据结构适用于要实现的类
l 设计应导出显示独立功能特征的构件
l 设计应导出接口，这些接口降低了构件之间以及构件与外部环境连接的复杂性
l 设计的导出应根据软件需求分析过程中获取的信息采用可重复使用的方法进行
基本概念
l 抽象—过程抽象，数据抽象
l 体系结构—软件的整体结构
l 模式—一个经过验证的解决方案的本质的表达
l 模块化— 数据和功能的划分
l 隐藏—每个模块对其他所有模块都隐藏自己的设计决策
l 功能独立—专一功能和低耦合
l 求精—逐步细化所有的抽象
l 重构—一种重新组织的技术，可以简化构件的设计或代码而无需改变其功能和行为
软件结构
l 结构模型—将体系结构表示为程序构件的一个有组织的集合
l 框架模型—可以提高设计抽象级别
l 动态模型—强调程序体系结构的行为方面，指明结构或系统配置作为外部事件的函数将如何变化
l 过程模型—注重系统必须提供的业务设计或技术流程设计
l 功能模型—可以用来表示系统的功能层次结构
消息隐藏
l 无意间引入错误并传播到软件其他部分的可能性很小
l 限制了局部设计决定对全局的影响
l 强调通过控制接口进行交互
l 不鼓励使用全局数据
l 导致封装—高质量的设计的一个属性
l 为了设计出高质量的软件
重构
一种重新组织的技术，可以简化构件的设计或代码而无需改变其功能和行为。
重构时需要检查以下方面：
l 冗余性
l 未使用的设计元素
l 低效或者不必须的设计算法
l 拙劣或者不恰当的数据结构
l 以及其他设计不足，修改这些不足以获得更好的设计
设计模式元素
l 数据设计元素（数据结构，数据库架构）
l 体系结构设计元素（应用域，分析类，模式和类型）
l 接口设计元素（用户界面，和其他系统设备的外部接口，各种设计构件之间的内部接口）
l 构件级设计元素
l 部署级设计元素
体系结构设计
体系结构是一种表达，使得软件工程师能够
l 分析设计在满足规定需求方面的有效性
l 在设计变更相对容易的阶段，考虑体系结构可能的选择方案
l 降低与软件构造相关联的风险
体系结构风格
l 以数据为中心的体系结构
l 数据流体系结构
l 调用返回体系结构
l 面向对象体系结构
l 层次体系结构
体系结构模式
l 并发性—很多应用系统必须以一种模拟并行的方式来操作多个任务
l 持久性—如果数据从创建它的进程执行以来一直存在，则该数据是持久性存在的数据
l 分布性—系统或系统中构件在一个分布的环境中相互通信的方式（实体间连接方式，实体间通信）
构件级设计
构件：系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现，并暴露一系列的接口。
设计原则
l 开关原则：模块应该是对外延具有开放性，对修改具有关闭性
l 替换原则：子类可以替换他们的基类
l 依赖倒置原则：依赖于抽象而非具体实现
l 接口分离原则：多个用户专用接口比一个通用接口要好
l 发布复用等价性原则：复用的粒度就是发布的粒度
l 共同封装原则：一同变更的类应该合在一起
l 共同复用原则：不能一起复用的类不能被分到一组
内聚性
构件的专诚性，意味着构件或者类只封装那些相互关系密切，以及与构件或类自身有密切关系的属性和操作。
l 功能内聚
l 分层内聚
l 通信内聚
l 顺序内聚
l 过程内聚
l 暂时内聚
l 实用内聚
耦合
类之间彼此联系程度的一种定性度量
l 内容耦合
l 共用耦合
l 控制耦合
l 印记耦合
l 数据耦合
l 例程调用耦合
l 类型使用耦合
l 包含或导入耦合
l 外部耦合
软件测试策略
测试是交付最终用户之前带着特定查找错误的意图来演习程序的过程
策略：
l 单元测试：测试接口，局部数据结构，边界条件，独立路径，错误处理路径
l 集成测试：一步到位，增量集成
l 确认测试
l 系统测试
OOT策略
类的测试等价于单元测试（测试类内部的操作，检查类的状态行为）
三种不同的策略集成测试：
l 基于线程的测试—集成响应系统的一个输入或事件所需的一组类
l 基于使用的测试—集成响应一个使用用例的所需的一组类
l 簇测试—集成显示一个协作所需的一组类
冒烟测试
常用的集成方法，是时间关键性项目的步进机制，让软件团队频繁地对项目进行评估
l 将已经转换成代码的软件构件集成为一个build
l 设计一系列测试以暴露影响build正确地完成其功能的错误
l 每天该build与其他builds及整个软件产品集成起来进行冒烟测试
调试策略：蛮力法，回溯法，原因排除法
测试战术
可测试性
l 可操作性—运行的越好，越能有效的测试
l 可观察性—你所看见的就是你所测试的
l 可控制性—对软件控制的越好，测试越能被自动执行和再现
l 可分解性—通过控制测试的范围，能够更快地分解问题，完成更灵巧的再测试
l 简单性—减少复杂的构架和逻辑来简化测试
l 稳定性—变更越少，对测试的破坏越小
l 易理解性—对设计的理解
白盒测试
计算环复杂性：简单决策数+1 或者 封闭区域数+1. 环复杂性越高，出错的可能性越大
项目管理
管理因素
l 人员—成功项目最重要因素
l 产品—要构造的软件
l 过程—为了完成软件构造的一组框架活动和软件工程任务
l 项目—实现产品所需要的所有工作
MOI model
l 激励—通过推或拉鼓励技术人员发挥最大才能的一种能力
l 组织—形成能够将最初概念转换成最终产品的现有过程的能力
l 思想和创新—即使必须在特定软件产品或应用的约束下工作，也能鼓励人们去创造并让人感到有创造性的一种能力
组织范型
l 封闭式范型—按照传统的权利层次来组织团队
l 随机式范型—松散地组织团队，团队工作依赖于团队成员个人的主动性
l 开放式范型—试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性方式来组织团队
l 同步式范型—依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没什么主动交流
过程和项目度量
过程度量
l 质量相关的—关注于工作产品和交付物的度量
l 生产率相关的—与花费的工作量有关的工作产品的生产
l 统计的软件质量保证数据—错误分类与分析
l 缺陷使效率受损—过程中的错误从一个行为传播到另一个行为
l 数据重用—生产的组件的数目和它们的重用程度
项目度量
通过进行为了避免拖延和减轻潜在的问题与风险所必需的调整来减少开发花费的时间
l 输入—工作完成需要的资源的度量
l 输出—在软件工程过程中创造的可交付物或工作产品的度量
l 结果—度量可以表明可交付物的效力
面向规模的度量
l 每千行代码的错误数
l 每千行代码的缺陷数
l 每千行代码的成本
l 每千行代码的文档页数
l 每人月的错误数
l 每个检查小时的错误数
l 每人月千代码行
l 每页文档的成本
面向功能的度量
l 每个功能点的错误数
l 每个功能点的缺陷数
l 每个功能点的成本
l 每个功能点的文档页数
l 每人月的功能点数
面向对象的度量
l 场景脚本的数量（用例）
l 关键类的数量，问题域的核心
l 支持类的数量（实现系统需要的但是与问题域并不直接相关）
l 每个关键类的平均支持类的数量（分析类）
l 子系统的数量，子系统是实现某个功能的类的集合
测量质量
l 正确性—程序完成所要求的功能的程度
l 可维护性—遇到错误时程序能够被修改的容易程度，环境发生变化时程序能够适应的容易程度
l 完整性—测量一个系统对安全性攻击的抵抗能力
l 可用性—程序容易使用的程度
缺陷排除率：DRE=E/(E+D) 接近1为好
E—软件交付给最终用户之前发现的错误数， D-软件交付给最终用户之后发现的缺陷数
软件项目估算
项目计划的总目标就是为了控制，跟踪和监视一个复杂的技术项目建立切实可行的战略
估算技术
l 过去类似的项目经验
l 传统估算技术（任务细目和工作量估算，规模估算）
l 经验模型
l 自动工具
项目进度安排
安排原则
l 划分—必须将项目划分为多个可以管理的活动
l 相互依赖性—明确任务之间的依赖关系
l 时间分配—每个安排了进度计划的任务必须分配一定数量的工作单位
l 工作量确认—每个项目都有预定的人员参与
l 确认责任—每个安排了进度计划的任务应该指定特定的成员来负责
l 明确结果—每个安排了进度计划的任务都应该有个明确的输出结果
l 确定里程碑—每个任务或任务组都应该与一个项目里程碑相关联
风险管理
风险识别
l 产品规模—与要开发或者要修改的软件的总体规模相关的风险
l 商业影响—与管理者或者市场所施加的约束相关的风险
l 客户特性—与客户素质以及开发者和客户定期沟通的能力相关的风险
l 过程定义—与软件工程定义的程度以及该过程被开发组织遵守的程度相关的风险
l 开发环境—与用来开发产品的工具可获得性及质量相关的风险
l 开发技术—与待开发软件的复杂性及系统所包含技术的新奇性相关的风险
l 人员才干及经验—与软件工程师的总体技术水平及项目经验相关的风险
风险因素
l 性能风险—产品能够满足需求且符合其使用目的的不确定程度
l 成本风险—能够维持项目预算的不确定程度
l 支持风险—开发出的软件易于纠错、修改及升级的不确定程度
l 进度风险—那个维持项目进度且按时交付产品的不确定程度
质量管理
软件质量：遵循清楚陈述的功能和性能的要求，明确的记录开发标准，所有专业开发的软件预期的隐性的特征
软件可靠性：可靠性简单测量，平均失效间隔时间。
软件可用性：某个给定时间点上程序能够按照需求执行的效率。
变更管理
基线（baseline）
已经通过正式评审和批准的规格说明或产品，他可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能改变它
扫一扫
866
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
