软件工程
软件危机
软件危机具体表现为：（进成功质维文）
进度难预测
成本难控制
功能难满足
质量难保证
软件难维护
文档资料缺
软件工程定义
IEEE
将系统化、严格约束的、可量化的方法应用于软件开发、运行和维护
Fritz Bauer
建立并使用完善的工程化原则 以较经济的手段在实际机器上有效运行的可靠软件的一系列方法
软件过程模型
瀑布模型
特点：因果关系紧密项链 进行审查和确认 有利于人员的组织管理 有利于软件开发方法和工具的研究
缺点：
（1）软件需求完整性、正确性难确定
（2）严格串行化模型 需要相当长时间才能获取看得见系统 ，需求变更将会带来巨大损失
（3）基本原则是每个阶段一次性完全解决该阶段工作，实际上是不现实
原型化模型（快速原型）
两个阶段：
原型开发阶段
目标软件开发阶段
原型作用不同：
抛弃型原型 （需求确认手段）
演化性原型
螺旋模型
在快速原型基础上扩展
每个阶段分为四部分：
（1）目标设定
（2）风险分析
（3）开发和有效性验证
（4）评审
特点：支持大型软件开发 适用于面向规格说明、面向过程和面向对象的软件开发方法，也适用于几种开发方法组合
敏捷模型
适应性的 而非预设性
面向人的 而非面向过程的
强调开发中相关人员之间的信息交流，提倡面对面交流，面对面交流低于文档成本。
按照高内聚、低耦合的原则将项目分成小组
敏捷方法核心思想：
（1）适应型
（2）以人为本
（3）迭代增量式的开发（原型开发思想为基础）
主要敏捷方法：
（1）极限编程 XP
基础、价值观：交流、朴素、反馈和勇气
（2）水晶序列方法 （以人为中心）
（3）Scrum 侧重项目管理 （有效率开发软件）
（4）FDD（特征驱动开发方法）（三要素：人、过程和技术）
关键项目角色：项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。
过程：开发整体对象模型、构造特征列表、计划特征开发、特征设计、特征构建
统一过程模型 RUP
重量级过程 二维的软件开发模型
9个核心工作流：
（1）业务建模（2）需求（3）分析与设计（4）实现（5）测试（6）部署（7）配置与变更管理（8）项目管理（9）环境
一个循环4阶段：（交出细狗）
初始阶段：定义最终产品视图和业务模型 确定系统范围
细化阶段：设计确定系统体系结构 指定工作计划和资源要求
构造阶段：构造产品并继续演进需求直至提交
移交阶段：产品提交用户
（角色 活动 制品 工作流）
特点：用例驱动、体系结构为中心（多方面）、迭代和增量
软件能力成熟度模型CMMI
用于指导软件开发过程的改进和进行软件开发能力的评估
5个成熟度等级：
（1）L1初始级
过程随意且混乱 成功依赖组织人员能力与英雄主义 经常超出预算和成本
（2）L2已管理级
确保策划、文档化、执行、监督和控制项目级的过程
（3）L3已定义级
能根据自身定义标准流程，并且制度化，同时企业开始进行项目积累，企业资产的收集
（4）L4量化管理级（与L3区别是性能的可预测）
建立了产品质量、服务质量以及过程性能的定量目标
（5）L5优化级
关注于通过增量式与创新式过程与技术改进，不断改进过程性能，能对组织级绩效进行关注
软件需求
业务需求
组织机构或客户对系统、产品高层次的目标要求
用户需求
用户使用产品必须要完成的任务
用户对软件产品的期望
两者构成额用户原始需求文档的内容
功能需求
开发人员必须实现的软件功能
需求工程活动
（1）需求获取
（2）需求分析
（3）形成需求规格（需求文档化）
（4）需求确认与验证
（5）需求管理
需求获取
用户、开发者之间为了定义新系统而进行的交流。
需求获取是获得系统必要的特征，是获得用户能接受、系统必须满足的约束。
常见方法：用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法、头脑风暴法
软件需求文档应该精确描述要交付的产品 这是一个基本原则，严格控制软件项目
需求追踪
（1）正向跟踪
检查《产品需求规格说明书》中的每个需求是否能在后继工作成果中找到对应点
（2）逆向跟踪
检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》找到出处
正向跟踪和逆向跟踪合称为“双向跟踪”
需求跟踪矩阵保存了需求与后继工作成果的对应关系
使用配置管理工具实现需求跟踪
结构化方法SASD
面向功能的软件开发方法或面向数据流的软件开发方法
结构化开发方法提出了一组提高软件结构合理性的准则
针对软件生存周期各个不同阶段有（1）结构化分析SA（2）结构化设计（SD）（3）结构化编程（SP）
数据流图DFD
也称为过程建模和功能建模方法
核心是数据流
以图形方式刻画和表示一个具体业务中数据处理过程和数据流
由4中基本元素组成：数据流、处理/加工、数据存储和外部项
数据流：用一个箭头描述数据的流向 箭头上标注的内容可以是信息说明或数据项
处理：表示对数据的加工和转换，用矩形框表示，指向处理的数据流为该处理的输入数据，离开处理的数据流为该处理的输出数据。
数据存储：表示用数据库形式（或者文件形式存储的数据），对其进行的存取分别指向或离开数据存储的箭头表示。
外部项：也称为数据源或者数据终点。描述系统数据的提供者或者数据的使用者。用圆角框或者平行四边形框表示。
建立DFD图的目的是描述系统的功能需求
建模过程和步骤：
（1）明确目标 确定系统范围
（2）建立顶层DFD图
（3）构建第一层DFD分解图
（4）开发DFD层次结构图
（5）检查确认DFD图
顶层图被逐渐细化
数据字典
用户可以访问的记录数据库和应用程序元数据的目录。目的是对数据流程图中的各个元素做出详细的说明。数据字典是对描述数据的信息集合，是对系统中使用的所有数据元素定义的集合。
数据字典是对系统中使用所有数据元素定义的集合
最重要的作用是作为分析阶段中的工具。给数据流图上每个元素加以定义和说明。数据流图上所有元素的定义和解释的文字集合就是数据字典。
各部分描述：
（1）数据项：图中数据块数据项说明。不可再分的数据单位。若干数据项构成一个数据结构
（2）数据结构：反映数据之间的组合关系
（3）数据流：是数据结构在系统内传输的路径。
（4）数据存储：数据流图中数据块的数据存储特性说明。数据流的来源和去向之一。
（5）处理过程：功能块的说明。
结构化设计SD
面向数据流的方法 以数据流图和数据字典等文档作为基础
耦合
从低到高
非直接耦合：两个模块之间没有直接关系
数据耦合：一组模块借助参数表传递简单数据
标记耦合：一组模块通过参数表传递记录复杂数据（数据结构）
控制耦合：模块之间传递的信息中包含用于控制模块内部逻辑的信息
通信耦合：一组模块共用了一组输入信息，或者它们的输出需要整合以形成完整数据，即共享了输入或输出。
公共耦合：多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
内容耦合：一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块内部；两个模块有一部分程序代码重叠；一个模块有多个入口等
聚合
从高到低
功能内聚：完成单一功能，各个部分协同工作，缺一不可
顺序内聚：处理元素相关，必须顺序执行
通信内聚：所有处理元素集中在一个数据结构区域上
过程内聚：处理元素相关，必须按特定次序执行
时间内聚：必须在同一时间间隔内执行
逻辑内聚：逻辑上相关的一组任务
偶然内聚：一组没有关系或松散关系的任务
Last updated