软件工程笔记

软件工程

软件工程概念

软件工程定义：①把系统化的、规范的、可度量的途径 应用于软件开发、运行和维护的过程，也就是把工程 化应用于软件中；②研究①中提到的途径。

1.历史方面

2.经济方面

3.维护方面

3.1传统生命周期模型（需求阶段-分析/规格说明阶段-设计-实现-交付后维护-退役）

3.2维护的传统和现代观点（安装——在任何时候进行的纠错性、完善性或适应性活动）

3.3交付后维护的重要性

4.需求·分析·设计方面

5.团队编程方面

6.为什么没有计划阶段

6.1计划活动：开始对需求和分析阶段进行初步计划，签署规格说明后制定软件项目管理计划，实施中监督ampm的执行计划

6.2计划活动贯穿软件生命周期始终，不存在独立的计划阶段

7.为什么没有测试阶段

7.1测试活动贯穿于整个软件生命周期始终，不存在单独的测试计划

8.为什么没有文档阶段

8.1文档必须始终是最新的

8.2文档伴随着构建软件产品的所有其他开发和维护活动进行

9.面向对象范型

9.1传统或结构化范性不适合开发大型软件——不同时面向属性和操作

9.2面向对象范型将属性和操作看作同样重要

9.3传统范性和面向对象范性比较：信息隐藏·职责驱动设计·维护和开发的影响（分析和设计阶段工作存在巨大不同——初期确定对象）

9.4面向对象范型的优点：交付后维护很安全·更容易开发·设计良好的对象是独立的单元（现实封装/职责驱动/消息通信）·便于理解和修改·降低了软件复杂度并提高了重用

软件生命周期模型

1.理论上的软件开发：线性·从零开始

2.实践中的软件开发：瀑布模型-带反馈环的线性生命周期模型

3.基本的软件开发过程是迭代的

4.工作流：全部五个工作流都在软件的生命周期进行着，但一般一个工作流占主导地位，整个周期都伴随着计划和文档

5.迭代递增模型的额优点：有很多检查软件产品是否正确的机会·早期可以确定结构的健壮性·较早减轻风险·可以试验开始的工作版本决定做什么改变·每个递增都是一个瀑布式的小项目

6.其他生命周期模型

6.1编码-修补生命周期模型：没有设计·没有规格说明——难以维护

6.2瀑布生命周期模型：反馈环·文档驱动——文档不够直接

6.3快速原型开发生命周期模型：线性模型·快速

6.4开源生命周期模型：建立一个开源初始版本·业余时间自愿参与开发·纠正完善适应性维护

6.5敏捷过程：不强调分析和设计·相应需求变化·站会·对需求模糊且易变的小型软件有效

6.6同步-稳定生命周期模型

6.7螺旋生命周期模型：快速原型模型+每个阶段风险分析·开发和维护没有区别·仅适用于大型内部软件开发

6.8决定模型的标准：管理水平·技术水平·产品特性——建议混合搭配生命周期模型

软件过程

1.统一过程

1.1统一过程是一种自适应的方法学，并不是构建产品的一系列步骤，需要根据具体开发情况进行修改

1.2模型是一系列uml图表，反映了待开发的软件产品的各个方面·uml是建模语言

1.3统一过程的四个递增标记为：开始·细化·构建·转换阶段

1.4工作流·技术 VS 阶段·业务

2.面向对象范型本质上是一种迭代和递增方法

3.需求流·确定客户的需求：应用领域·业务模型·约束条件/输出是被客户理解的自然语言

4.分析流·分析和提炼需求·建立用户需求到软件功能的初步映射：输出是精准的完成的语言/规格说明文档（不含有不精确的表达）+软件项目管理计划（成本估算·工期估算·可交付成果·里程碑·预算）

5.设计流·细化分析流直至结果可以被程序员实现

5.1.传统设计：结构设计·把产品分解成模块/详细设计·设计每个模块的数据结构和算法

5.2面向对象设计：在分析流期间提取类·在设计流期间设计类的细节

6.实现流·用选好的语言实现目标软件

7.测试流：每个开发和维护成员和质量保证小组/可追踪性/评审/单元·集成·产品·验收测试

8.交付后维护：修改测试·回归测试

9.退役：硬件/文档缺失/功能大变

10.开始阶段·明确产品是否经济上可行：问题域/业务模型/范围/用例/风险/测试流开始

11.细化阶段·细化前一阶段工作

12.构建阶段·产生第一个可工作版本

13.转换阶段·确保客户的需求得到切实满足

14.改进软件过程

14.1能力成熟度模型：初始/可重复/定义/管理/最优

14.2 iso 9000

评审流程图个人作业

技术评审

1.w模型：评审-测试

2.度量：代价·缺陷密度·错误检测率·错误检测效率

需求陈述例子

1.系统总体目标+工作环境+所有类型的用户对系统的使用

2.工作环境：要求/时间/费用/原有系统

3.用户需求：类型+使用需求

选题——问题反馈

1.选题内容：

1.1.业务背景——业务目标及其流程

1.2.系统目标——解决实际问题

1.3.可行性——技术·经济·法律/社会

1.4.优先级——约束条件

需求

1.需求流概述

1.1理解应用域——构建初始业务模型——得到用户反馈来的带需求

1.2理解应用域·正确的术语：建立术语表

1.3业务模型：对组织的业务过程的描述·访谈·用例

1.4用例是软件产品本身和软件产品用户（参与者）间的交互模型——参与者：用例使用者·用例发起者·在用例中起关键作用的某个人·外部系统·相关设备 eg:不与软件产品交互，有代理人

1.5初始需求·基于初始业务模型提出初始需求：分为功能性和非功能性需求

2.传统的需求阶段：需求获取·需求分析·快速原型的构建·试用快速原型

传统分析

1.非形式化规格说明文档：自然语言不是描述产品需求的好方法

2.结构化系统分析

2.1画数据流图（dfd：层次化数据流图）+ 数据字典——符号·描述·叙述（域/数据/操作）

2.2决定哪部分和如何计算机化·确定数据流细节·定义处理逻辑·数据存储·物理资源·输入输出规格·确定规模·硬件要求

3.dfd数据流图举例

3.1系统逻辑模型+功能级数据流图+细化功能数据流图：信息连续性及输入输出相同

3.2系统逻辑模型：用户+系统+输入输出

3.3功能级数据流图：用户矩形·功能圆形·虚线上下层联系外部信息·矩形数据的源点终点·圆形变换数据的处理·平行线变换数据的处理·箭头数据流+同时++或

4.er实体-关系模型：实体+联系+属性

5.动态建模：为每个类构造状态图

传统分析：功能建模（数据流图+数据字典）+数据建模（实体联系图）+行为建模（状态转换图）

数据流图建模举例：

注意事项：

1.加工处理要有编号

2.数据流不能重名：可以+前/后

3.数据流图不能有控制流·不反映出错处理

4.加工处理必须有输入输出

5.数据流出了数据存储可以不命名其余必须命名

动态建模对每个类的状态转换图举例：

一个矩形内上状态下操作+箭头上加事件+初始状态黑点+一个总状态从他起始从他终结

面向对象分析

1.传统结构化方法vs面向对象的方法

1.1传统：事务被处理的过程·中小规模软件项目开发

1.2面向对象：对象件协作完成某项事务·大规模软件项目开发

2.面向对象的分析：识别对象·找出协作关系·确定属性·定义操作

3.软件的可维护性：需求分析清晰易读·设计结构层次清晰独立性强·编码规则风格sp通用性高·测试充分·文档正确易读

4.类：实体类·边界类·控制类

4.1实体类：模拟长期存在的信息

4.2边界类：模拟软件和参与者交互行为·通常与输入输出有关

4.3控制类：模拟复杂的计算和算法

5.建模：功能建模·类建模·动态建模

5.1功能建模：所有用例的场景

5.2类建模：类图/确定实体类和属性·确定实体类之间的关系和交互

5.3动态建模：状态图

6.类建模

6.1从用例和场景到处类 或 crc卡片·有领域知识/名词抽取·无领域知识

6.2crc 分别是class·responsibility·collaboration/类的名字·功能·协作的类

计划与估算

1.两种类型：计划贯穿整个项目·规格说明完成后制定的详细计划

2.产品规模的度量

2.1代码行Kdsi：源代码只是软件工作的小部分·不同语言·注释定义等·必须等产品完成

2.2文件·数据流·处理：中等规模数据处理产品的成本估算

2.3功能点：基于输入输出查询主文件接口的数量

2.4cocomo模型

3.成本估算技术

3.1专家类比判断法：Delphi技术

3.2自下而上的方法：分解成小成本估算·过程级成本

3.3算法成本估算模型：利用度量结果作为模型的输入来计算成本和工期

4.cocomo模型：用代码行估计规模·评估开发模式·计算额定工作量·工作量乘以15个软件开发成本系数

5.软件项目管理计划的组成：要做的工作·要用的资源·为软件开发付出的钱

5.1资源：人·硬件·支撑软件

5.2工作类别：活动（特定阶段·开始和结束日期·生成工作产品）·任务（活动包含一组任务）

6.里程碑·评审（团队成员·管理者·客户）·基线

7.工作包：工作产品·所需人员·工期·资源·负责人姓名·验收标准

项目计划

1.项目进度安排

1.1从前往后·从后往前

1.2任务·人员·时间分配与进度相协调

1.3重视关键任务合理利用机动时间

1.4充分利用并行处理方式缩短进度

2.工具-甘特图·任务网络图

2.1甘特图：能简单动态反映开发进展·难以反映逻辑关系

2.2标注时间参数的项目网络图：最早开始/结束最晚开始/结束

3.责任矩阵

3.1a责任人·p参与者·r评审者·i提供输入者·s签字确认者

4.风险管理

4.1项目·风险类型·影响值·风险因素·发生概率·影响·监控方法·应急计划·估算资源

软件测试

1.测试的目的：程序测试是为了发现错误而执行程序的过程

2.类型

2.1基于执行的测试-基于测试用例

2.2基于非执行的测试-书面规格文档·设计文档·源代码

3.软件质量

3.1软件满足其规格说明的程度

3.2质量必须从一开始就具备

3.3软件质量保证sqa小组

3.4开发团队和sqa小组必须有管理上的独立性

4.基于非执行的测试

4.1不应检查自己的工作·群体协同

4.2走查：问题清单/未理解·认为不正确

5.审查：概述·准备·审查·修改·跟踪

6.应当测试什么：正确性·实用性·可靠性·健壮性·性能

7.正确性难以证明·成本太高/正确性证明有时非常重要

8.当产品被废弃时停止测试

测试用例评审：

1.正确性：是否存在错误

2.有效性：是否有利于发现软件的错误和缺陷

3.系统性：是否进行多角度·多层次的测试

4.可管理：易组织·可评估·可复用

测试用例：

1.测试用例编号·用例标题·测试模块·测试输入条件·测试步骤·期望输出结果·其他说明

软件-黑盒测试

1.接口·功能需求的有效性·信息阈

2.划分等价类法

2.1划分输入输出数据等价类·合理/不合理

2.2等价类设计测试方案

3.边界值分析法

3.1输入域的边界·稍小于稍大于

3.2考虑输出等价类边界值易发现错误·找边界困难

3.3建议联合使用等价划分·边界值分析法

4.错误推测法：特殊的容易出错的情况

5.因果图

5.1考虑输入条件的组合·判定表

软件-白盒测试

1.特点：关注软件内部逻辑结构·测试逻辑通路·检查断点·覆盖程度

2.测试已知程序的数据结构和算法

3.白盒测试无法做到穷尽测试，不要使用全称量词

4.逻辑覆盖：语句覆盖·条件覆盖·判定覆盖·条件组合覆盖·判定条件覆盖

5.基本路径测试

5.1计算程序流图的环路复杂度（边数-结点数+2）·每条路径至少执行一次·加入原来没有测试过的至少一个语句·设计测试用例

6.循环测试

6.1关注循环体结构的正确性·对循环变量运用类似边界值测试的方法验证

6.2四种：简单·嵌套·连接·非结构

设计

1.传统设计：

1.1.结构设计·详细设计·设计测试

1.2.结构设计：输入-规格说明·输出-模块分解

1.3.详细设计：每个模块特定的算法和数据结构 2.面向操作设计：

2.1变换

1数据流分析dfa

2dfd关键点

3每一种产品都是将输入转化为输出

4将产品分解为三个模块，直至每个模块具有高内聚性

2.2事务

1.dfa不适合事务处理

2.调度/事务中心

2.3.功能内聚：一个模块只执行一个操作或者只达到单一目标·可重用易于维护

2.4.表示详细设计的两种形式：表·伪代码pdl

3.面向数据设计：

3.1基本原则：产品的结构必须和数据的结构一致

4.面向对象设计：

4.1目标：根据ooa过程中提取的类来设计产品

4.2步骤：完成类图（属性·方法）/执行详细设计（每个方法）

5.oo软件开发-喷泉模型

6.设计流：分析工作流制品被迭代和递增知道程序员能够实现

6.1包括：实现语言·重用·可移植性

7.设计的度量：内聚·耦合·故障统计

结构化程序设计sp

1.定义：如果程序仅仅通过顺序·选择·循环进行连接且每个代码快只有一个入口和出口，则这个程序是结构化的

2.尽量少使用goto而且总是向前使用

3.过程设计的工具：流程图·盒图·pad图·判定表·判定树·pdl伪代码

4.程序流程图：直观易学·不易表示数据结构

5.盒图：控制结构和作用域明显·不能转移控制·易表示层次结构

6.pad图：结构化的控制结构·表现逻辑易懂·可描绘数据结构

7.判定表：简洁无歧义·无法表示顺序重复

8.判定树：直观·分支次序决定简洁程度

9.pdl过程设计语言

9.1外语法：严格的关键字-内语法：表示实际操作和条件

9.2可注释·不如图直观·过分关注细节

面向数据流的方法

1.启发规则

1.1提高模块独立性

1.2模块规模适中

1.3深度宽度扇入扇出适当

1.4作用域在控制域内

1.5降低接口复杂度

1.6单入单出避免内容耦合

1.7模块功能可预测

2.描绘软件结构的工具：层次图·hipo图·结构图

结构化设计方案

1.面向数据流的设计方法

1.1面向数据流的sa和sd

1.1sd方法与dfa结合/数据流图-软件模块结构

1.2修改和细化dfd图·映射优化sc图

2.面向数据结构的设计方案

2.1变换·事务·综合

实现

1.编程语言的选择

2良好的编程实践

2.1使用一致且有意义的变量名字 2.3使用参数

2.4增加可读性

2.5嵌套if语句

3.编码规范：使维护更容易

4.代码重用

5.集成

6.驱动程序与桩模块

6.1自顶向下的集成：错误隔离·设计故障发现早

6.2自底向上的集成：彻底测试·故障隔离

6.3三明治集成

6.4实现然后集成

7.面向对象的集成：三明治·对象自底向上·其他自顶向下

8.实现流：实现目标软件

交付后维护

1.通过验收测试后对产品任何部件包括文档的任何更改

2.维护的必要性：纠正性维护·完善性维护·适应性维护

2.1纠正性维护通过缺陷报告和源代码·不引入回归错误修复

3.缺陷报告

4.确保可维护性

5.面向对象的维护

4.1可维护性高原因：独立单元组成·封装·信息隐藏·消息传递

4.2三大障碍：继承·多态和动态绑定

6.逆向工程

7.交付后维护的case工具

8.交付后维护的度量