软件工程导论 地毯级知识点梳理笔记
基于《软件工程导论（第六版）》张海藩 牟永敏 编著
软件工程导论学习辅导pdf：
链接：https://pan.baidu.com/s/1QH2dRKYnm9gZOtiIzna9rA
提取码：pp7w
（本文也有幕布版本 想要的评论一下就好）
（备考的时候一个字一个字码出来的 整理不易 转载请注明来源并评论）
本文包括课本中知识点梳理及配套学习辅导整理
目录：
（点击↑跳转）
-
小圆制作
-
概论
-
根本目标：确定怎样具体实现所要求的系统 得出对目标系统的精确描述
-
详细设计基本上决定了目标代码的质量
-
结构程序设计是详细设计的逻辑基础
-
衡量程序质量：逻辑 性能 易阅读理解
-
-
结构程序设计
-
基本控制结构：顺序 选择 （if then else) 循环 （do while）（流程图怎么画？
-
理论上最基本的控制结构：顺序 循环（do while)
-
结构程序设计的经典定义：顺序 选择 循环 一个入口一个出口
-
经典的结构程序设计：顺序 +if then else +do while
-
结构程序设计的广义定义；尽量使用goto语句 最好在检测出错误时才使用goto语句 且总是应该使用前向goto语句
-
扩展的结构程序设计 do case. do until
-
修正的结构程序设计 leave/break(受限制的前向goto)
-
-
-
-
-
-
-
-
-
-
人机界面设计
-
设计问题
-
系统响应时间：长度（要适中） and 易变性（要小）
-
用户帮助设施：集成的or附加的
-
出错信息处理：
-
命令交互：
-
-
设计过程
-
用户界面设计是一个迭代的过程创建设计模型 实现设计模型 用户试用评估 根据用户意见修改
-
工具：用户界面工具箱 用户界面开发系统
-
评估：一旦建立起用户界面原型就必须对他进行评估（评估可以正式也可以非正式）
-
评估周期：
-
评估标准：
-
-
设计指南
-
一般交互指南：全局性 忽略将产生较大风险
-
信息显示指南：
-
数据输入指南：
-
-
-
过程设计的工具
-
描述程序处理过程的工具
-
图形 表格 语言
-
工具的基本要求：提供对设计无歧义的描述（指明…控制流程 处理功能 数据组织 等……的实现细节 ）编码阶段能把对设计的描述翻译成程序代码
-
程序流程图（程序框图）
-
历史最悠久使用最广泛 用的最混乱
-
优点
-
直观 便于初学者掌握
-
-
缺点
-
不是逐步求精的好工具 程序员过早考虑控制流程 而不去考虑程序全局结构
-
箭头代表控制流 可以不顾结构程序设计 随意转移控制
-
不易表示数据结构
-
-
符号/画法
-
-
盒图（Ｎ-Ｓ图）
-
不违背结构程序设计精神（盒图没有箭头不允许随意转移控制）
-
特点
-
功能域明确 一眼就能看出来
-
不可能任意转移控制
-
很容易确定局部和全程数据的作用域
-
容易表现嵌套关系 容易表示模块的层次结构
-
-
画法
-
-
问题分析图（PAD图）
-
二维树形结构 每个控制语句都有图形符号对应 转换成对应的高级语言比较容易
-
面向高级程序设计语言
-
-
优点
-
设计出来的一定是结构化程序
-
程序结构清晰 左边竖线 主线 第一层结构 每增加一个层次 向右延伸一条竖线 竖线总条数就是程序层次数
-
转换成高级语言源程序可以用软件工具自动完成 省去人工编码 提高可靠性和软件生产率
-
既可用于表示程序逻辑 又可用于表示数据结构
-
自顶向下 逐步求精/def
-
-
-
判定表
-
包含多重嵌套选择时用
-
清晰的表达复杂的条件组合和应做的动作之间的关系
-
四个部分：左上 条件。左下 动作。右上 条件组合。右下 动作。右半部分每一列实质上是一条规则 规定了与特定条件组合相对应的动作
-
T F 空白 ❌
-
简洁无歧义的描述处理规则
-
把判定表与卡诺图或布尔代数结合 可对判定表校验或化简
-
不适于通用设计工具
-
没法清晰的表示顺序和重复
-
多余两个值时简洁程度下降
-
-
-
判定树常用的系统分析和设计的工具
-
优点
-
清晰的表达复杂的条件组合和应做的动作之间的关系
-
形式简单 不需说明 一眼就可看出含义 易于掌握使用
-
-
比判定表直观 简洁性不如判定表
-
同一个值重复写多遍 越接近树的叶端重复次数越多
-
分枝的次序对最终画出的判定树的简洁程度有较大影响
-
-
过程设计语言（PDL）伪码
-
正文形式表示数据和处理过程
-
关键字外部语法：严格 内部语法：灵活自由
-
特点：
-
关键字的固定语法，结构化控制结构、数据说明和模块化特点 为了程序清晰和可读性好，所有可能嵌套使用的控制结构的头和尾都有关键字 例如if...fi/endif
-
自然语言的自由语法 描述处理特点
-
数据说明的手段 （既包括简单数据结构又包括复杂的数据结构）
-
模块定义和调用技术，应该提供各种接口描述模式
-
-
优点：
-
可作为注释直接插在源程序中间 促使设计人员修改代码同时修改PDL 有利于保持文档和程序的一致性 提高了文档质量
-
可使用普通的正文编辑程序和文字处理系统 方便的书写编辑
-
已经有自动处理PDL的程序存在 可以自动由PDL生成程序代码
-
-
缺点：不如图形工具形象直观 描述复杂的条件组合与动作间的对应关系时 不如判定表清晰简单
-
-
-
面向数据结构的设计方法Jackson方法和Warnier方法是最著名的两个面向数据结构设计的方法
-
计算机软件的本质是信息处理系统
-
定义：根据数据结构设计程序处理过程
-
最终目标：对程序处理过程的描述
-
最适合于在详细设计阶段使用 设计每个模块的处理过程
-
Jackson图
-
顺序 选择 重复
-
优点
-
便于表示层次结构 自顶向下分解有力工具
-
直观 可读性好
-
既能表示数据结构也能表示程序结构
-
-
缺点
-
选择条件和循环条件 结束条件不能直接在图上表示出来
-
不容易直接把图翻译成程序
-
框间连线为斜线不易在打印机上输出
-
-
-
改进的Jackson图
-
顺序 选择 可选 重复
-
对层次方框图的精化 一个方框不代表一个模块 只代表几个语句
-
表现组成关系
-
-
-
Jackson方法
-
五个步骤
-
三种结构对应的伪码
-
一个例子
-
设计简单的数据处理系统时比较方便
-
-
-
程序复杂程度的定量度量
-
价值：
-
复杂程度乘以从常数可以估算软件中错误的数量以及软件开发的工作量
-
定量度量可以比较两个不同设计或者不同算法的优劣
-
复杂程度可以作为作为模块规模的精确限度
-
-
McCabe方法
-
流图（程序图）
-
流图实际上是退化了的程序流程图 仅仅描绘程序的控制流程 完全不表现对数据的具体操作以及分支或循环的具体条件
-
圆：结点 一个结点代表一个语句
-
箭头线：边 代表控制流
-
一条边必须终止于一个结点 即使这个结点不代表任何语句
-
任何方法表示的过程设计结果 都可以翻译成流图
-
过程设计包含复合条件 应该把复合条件分解为简单条件
-
-
环形复杂度V（G）
-
-
环形复杂度用途
-
取决于程序结构的复杂程度
-
是对测试难度的一种定量度量
-
对软件最终可靠性给出预测
-
小于等于10为宜 10是模块规模一个更科学更精确的上限
-
-
-
-
-
Halstead方法
-
-
-
其他
-
过程设计可以在数据设计 体系结构 接口设计完成之后进行
-
过程设计是详细设计阶段应该完成的主要工作
-
层次结构——可以采用面向数据结构的设计方法完成过程设计
-
-
小圆制作
-
概论
-
实现=编码+测试
-
程序的质量主要取决于：软件设计的质量
-
程序设计语言的风格也将对...产生深远影响
-
测试的目的：在软件投入生产之性运行之前，尽可能多地发现软件中的错误
-
保证软件质量的关键步骤：软件测试
-
软件测试横跨的两个阶段：1、编码 单元测试 （同一个人）2、综合测试（专门测试人员）
-
测试阶段最困难的工作：调试
-
调试的目的：诊断并改正错误
-
（调试的任务：设法确定错误的位置并改正它）
-
通常由程序编写者进行调试
-
-
编码
-
选择程序设计语言
-
高级语言一般优于汇编语言 高级语言应：
-
有理想的模块化机制
-
可读性好的控制结构和数据结构
-
编译程序能尽可能多的发现程序中的错误
-
拥有良好的独立编译机制
-
-
使用标准：
-
系统用户的要求
-
可以使用的编译程序
-
可以得到的软件工具
-
工程规模
-
程序员的知识
-
软件可移植性要求
-
软件的应用领域
-
-
-
-
编码风格代码逻辑简明清晰 易读易懂是好程序的一个重要标准
-
程序内部的文档恰当的标志符 、 适当的注解、 程序的视觉组织
-
数据说明
-
语句构造
-
输入输出
-
效率
-
处理机时间和存储容量
-
三条原则
-
需求分析阶段确定效率要求
-
效率靠好的设计提高
-
效率和简单程度一致 不应牺牲清晰性和可读性提高效率
-
-
程序运行时间源程序效率直接由详细设计阶段确定的算法效率决定
-
存储器效率
-
输入输出效率
-
-
-
-
软件测试基础测试阶段的目标不等于测试的目标
-
测试阶段根本目标：
-
尽可能多的发现并排除软件中潜藏的错误 最终把一个高质量的软件系统交给用户使用
-
-
软件测试的目标：
-
1 测试是为了发现程序中的错误而执行程序的过程
-
2 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
-
3 成功的测试是发现了至今为止尚未发现的错误的测试
-
-
测试的定义：
-
为了发现程序中的错误而执行程序的过程
-
（测试的根本任务：保证软件的质量）
-
-
测试绝不能证明程序是正确的
-
测试只能查找出程序中的错误 不能证明程序中没有错误
-
软件测试准则：
-
所有测试都应追溯到用户需求用户角度；最严重的错误：导致不能满足用户需求的错误
-
应该远在测试之前就制定出测试计划需求模型后测试计划 设计模型后详细设计 编码之前对所有测试工作规划设计
-
Pareto原理应用到软件测试中pareto原理：80%错误可能20%模块产生
-
从小规模测试开始逐步进行大规模测试单个程序模块➡️集成的模块簇➡️整个系统
-
穷举测试是不可能的定义：把程序中所有可能的路径都执行一遍
-
应该由独立的第三方从事测试工作最佳效果：最大可能性发现错误的测试 软件工程师通常模块测试
-
-
测试方法：黑盒测试 白盒测试
-
黑盒测试（功能测试）
-
程序➡️黑盒子 不考虑内部结构处理过程 在程序接口测试 能否按规格说明书 能否接受输入产生输出 能否保持外部信息完整
-
-
白盒测试（结构测试）
-
程序➡️透明的白盒子 知道结构处理算法 按内部逻辑测试程序 检测是否按预定要求工作
-
-
-
测试步骤：
-
模块测试（单元测试）发现编码和详细设计阶段的错误
-
子系统测试（集成测试）主要问题：模块间互相协调和通信/////着重测试：模块的接口
-
系统测试（集成测试）发现设计和编码的错误 提供系统需求说明书中指定的功能 动态特性也符合要求（既可发现软件设计中的错误，也能发现需求说明中的错误）
-
验收测试（确认测试）发现系统需求说明书的错误////用户积极参与（测试内容与系统测试基本类似 但是是在用户积极参与下进行的）
-
平行运行同时运行新系统与旧系统 以便比较两个系统的处理结果 有四个具体目的
-
-
测试的根本任务：保证软件的质量
-
测试阶段的信息流
-
输入信息：①软件配置：需求说明书 设计说明书 源程序清单 ②测试配置：测试计划和测试方案
-
实际上测试配置是软件配置的一个子集
-
-
-
-
单元测试
-
单元测试检测模块
-
单元测试、编码 属于同一阶段
-
分类
-
计算机测试 人工测试
-
-
单元测试主要白盒测试 各个模块并行测试
-
测试重点
-
模块接口
-
局部数据结构
-
重要的执行通路：选择最有代表性、最有可能发现错误的执行通路进行测试
-
出错处理通路
-
边界条件：刚好小于、刚好等于、刚好大于
-
-
代码审查（审查小组4人构成：发现错误而不是改正错误）
-
比计算机测试优越的是：一次审查会上可以发现许多错误而计算机测试错误是一个一个的发现并改正的，采用代码审查可以减少系统验证的工作量代码审查并不是全比计算机测试优越
-
-
计算机测试
-
驱动程序：“主程序” 接收测试数据 将数据传送给被测试的模块 印出结果
-
存根程序：“虚拟子程序” 接收被测试的模块调用的模块 它使用被他代替的模块的接口 可能做出少量操作 印出对入口的检验或操作结果 并且把控制归还给调用他的模块
-
存根程序和驱动程序代表开销 为了减小开销可以渐增式测试
-
-
代码审查与计算机测试 相互补充 相辅相成
-
-
集成测试（子系统、系统）
-
定义：测试和组装软件的系统化技术
-
非渐增式测试：先分别测试每个模块，再把所有模块按设计放在一起组合所需要的程序
-
渐增式测试（普遍采用）（同时完成单元测试与集成测试）
-
两种集成策略：
-
自顶向下
-
深度优先
-
宽度优先
-
需要存根程序
-
模块结合进软件的具体过程：
-
①主控制模块测试 借助存根程序
-
②每次用一个实际模块代替一个存根程序（新结合进来的模块往往需要新的存根程序）
-
③在结合近一个新模块的同时进行测试
-
④为了保证加入模块没有引入新错误，回归测试（全部或部分重复以前做过的测试）
-
-
优点：
-
①不需要测试驱动程序
-
②能在早期对主要的控制或关键的抉择进行检验（关键的抉择在上层）早期发现上层模块的接口错误
-
③若深度优先可以早期实现并验证一个完整的功能，增强开发人员和用户双方的信心
-
-
缺点：
-
①早期不能充分展开人力
-
②需要存根程序 与此联系的测试困难
-
③低层关键模块的错误发现晚
-
-
-
自底向上
-
需要驱动程序
-
步骤：
-
①底层模块结合成实现某个特定软件子功能的族
-
②写一个驱动程序 协调输入输出
-
③对由模块组成的子功能族进行测试
-
④去掉驱动程序，自下向上移动，把子功能族组合起来形成更大的子功能族
-
-
优缺点：与自顶向上相反
-
-
-
两种集成策略的比较
-
混合策略
-
改进的自顶向下（基本自顶向下 早期自底向上检测关键模块）
-
优点 ➕测试早期发现关键模块的错误
-
缺点 ➕测试关键模块时需要驱动程序
-
-
混合法（上层自顶向上 下层自顶向下）
-
兼具自顶向下和自底向上的优缺点
-
关键模块多时是最好的折衷方法
-
-
-
回归测试
-
是指重新执行已经做过的测试的某个子集，以保证每当一个新的模块结合进来时没有带来非预期的副作用
-
用于保证由于调试或其他原因引起的变化 不会导致非预期的软件行为或额外错误的测试活动
-
通过：
-
人工
-
捕获回放工具
-
-
回归测试集（子集）
-
检测全部功能的代表性测试用例
-
可能受修改影响的软件功能的附加测试
-
针对被修改过的软件充分的测试
-
-
-
-
确认测试（验收测试）
-
目标
-
验证软件的有效性
-
-
验证：软件正确的实现了某个特定要求
-
确认：软件确实满足了用户需求
-
软件有效性：软件的功能和性能如用户期待
-
软件需求规格说明书 准确描述用户合理期望 是有效性的标准 确认测试的基础
-
确认测试的范围：用户 培训用户 黑盒测试 测试计划包括种类及进度安排 测试过程检测软件是否与需求一致
-
两种可能结果：一致/有差距
-
-
软件配置复查
-
目的：保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节 已经编好目录
-
检验使用手册的完整性和正确性
-
-
为许多用户开发的软件：alpha和beta
-
alpha测试：开发者场所 开发者指导 开发者记录问题 受控环境进行
-
beta测试：客户场所 真实应用 用户记录问题 用户定期报告给开发者 开发者修改 发布最终产品
-
-
-
白盒测试（包括逻辑覆盖和控制结构测试）
-
测试阶段关键的技术问题：设计测试方案
-
测试方案：测试目的 输入数据 预期结果
-
测试用例：输入数据 预期结果
-
最困难的问题：设计输入数据
-
设计测试方案的基本目标：确定一组最有可能发现某个或某类错误的测试数据
-
逻辑覆盖：
-
语句覆盖
-
每个语句至少一次
-
覆盖率低
-
只关心判定表达式的值 不关心条件
-
-
判定覆盖（分支覆盖）
-
每种判定结果至少一次
-
覆盖程度不高
-
-
条件覆盖
-
判定表达式每个条件都取可能的结果
-
不一定比判定覆盖强
-
-
判定/条件覆盖
-
同时满足判定覆盖和条件覆盖
-
判定表达式中每个条件都取到可能的值 判定表达式也取到可能的结果
-
-
条件组合覆盖
-
每个条件的各种组合至少一次
-
一定满足 判定覆盖 条件覆盖 判定/条件覆盖 很强但也不是最强的
-
不一定使每条路径都执行一次
-
-
点覆盖
-
至少经过流图中每个结点一次
-
点覆盖标准=语句覆盖标准
-
-
边覆盖
-
至少经过流图中每条边一次
-
边覆盖=判定覆盖
-
-
路径覆盖（最强）
-
每条可能路径至少执行一次
-
-
-
-
-
-
-
控制结构测试
-
基本路径测试
-
①根据过程设计结果画出流图
-
②计算环形复杂度
-
③确定线性独立路径的基本集合？独立路径数目=环形复杂度
-
④设计可强制执行基本集合中每条路径的测试用例
-
-
条件测试
-
优点：①容易度量条件的测试覆盖率②程序内条件的测试覆盖率可指导附件测试的设计
-
目的：检测逻辑条件错误+其他错误（如果一个测试策略对检测条件错误有效 那么对检测其他错误也有效）
-
错误类型
-
条件测试策略：
-
分支测试（最简单 真分支假分支以及每个条件都至少执行一次）
-
域测试（一个关系表达式执行3、4个测试，E1大于小于等于E2,N个变量的表达式需要2的n次方次测试）布尔变量 算符 括弧错
-
BRO测试：布尔变量和关系算符值出现一次且没有公共变量 发现分支错或关系算符错
-
-
-
循环测试：专注于测试循环结构的有效性
-
简单循环 嵌套循环 串接循环
-
-
-
-
-
黑盒测试与白盒测试互补。发现白盒测试不易发现的错误
-
力图发现错误：
-
白盒测试-早期 黑盒测试-后期
-
满足什么标准的测试用例？
-
减少测试用例的总数
-
是否存在某些类型的错误 不仅仅与特定测试相关的错误
-
-
等价划分
-
一个理想的测试用例能独自发现一类错误
-
不需要设计测试数据来暴露编译程序肯定能发现的错误
-
有效等价类：一个新的测试方案 尽可能多地覆盖，直到所有的有效等价类都被覆盖
-
无效等价类：一个新的测试方案 只覆盖一个无效等价类 直到所有无效等价类都被覆盖
-
-
边界值分析
-
总是联合使用等价类划分和边界值分析
-
将测试边界情况作为重要目标，测试数据 刚好等于 刚刚小于 刚刚大于 边界值
-
-
错误推测
-
组合效应 凭经验
-
基本想法：列举出程序中最有可能有错误和最有可能发生错误的特殊情况 并根据他们选择测试方案
-
-
-
-
-
-
-
-
-
-
调试
-
调试是在错误发现之后排除错误的过程
-
分析 直觉 运气
-
目的：确定错误的原因和位置 并改正错误 因此调试也称为纠错
-
调试过程
-
调试不是测试 总发生在测试之后
-
-
调试途径
-
蛮干法：插入打印语句 / 运行部分程序
-
回溯法（调试小程序时有效）：从发现症状的地方 沿控制流往回追踪
-
原因排除法：
-
对分查找法 （注入正确值 缩小出错范围）
-
归纳法（个别到一般）
-
演绎法（所有可能的原因挨个排除）
-
-
-
-
软件可靠性
-
测试阶段根本目标：消除错误 保证软件可靠性
-
提高质量和可靠性的技术：避开错误/容错技术
-
软件可靠性
-
给定的时间间隔内按照规格说明书的规定成功运行的概率
-
可靠性随时间间隔增加而减少
-
保证可靠性的主要手段是软件测试
-
-
软件可用性
-
给定的时间点按照规格说明书规定成功运行的概率
-
-
一个是时刻一个是时间间隔
-
系统的稳态可用性
-
平均无故障时间MEET估算方法
-
基本假定
-
估算平均无故障时间
-
-
估计错误总数的方法：
-
植入错误法
-
分别测试法
-
-
-
-
-
-
-
小圆制作
-
概述
-
管理：
-
软件项目管理：先于任何技术活动之前开始 贯穿于整个生命周期
-
-
软件规模
-
代码行技术
-
L=(a+4m+b)/6
-
代码行数LOC。 千行代码数KLOC。
-
优点
-
代码—所有软件都有 容易计算
-
有历史数据参考时！估算数值比较准确
-
-
缺点
-
源程序只是软件配置的一个成分 用它的规模代表软件规模不太合理
-
不同语言需要的代码行数不同
-
不适于非过程性语言
-
-
-
功能点技术
-
依据 信息域特性 和 软件复杂性功能点技术（为了克服行代码技术的缺点）(功能点数和编程语言无关）（但有相当大主观因素） 的评估结果 估算软件规模
-
单位 功能点FP
-
信息域特性
-
5: 输入项数 输出项数 查询数 主文件数 外部接口数
-
输入项数：不同于查询 查询不计入输入项数
-
输出项数：例如 报表和出错信息 报表内的数据项不单独计数
-
查询数：联机输入 联机输出某种即时响应
-
主文件数：逻辑主文件的数目
-
外部接口数：机器可读的全部接口数
-
-
估算功能点的步骤：
-
计算🧮未调整的功能点数UFP每个信息域特性分配功能点数 1到5 乘积加和
-
计算技术复杂性因子TCF14种技术因素 1到5 DI TCF 0.65到1.35 TCF=0.65+0.01DI
-
计算功能点数FPFP=UFP*TCF
-
-
-
-
工作量
-
工作量是软件规模FP或KLOC的函数
-
单位。人月pm
-
没有一个估算模型可以适用于所有类型的软件和开发环境
-
静态单变量模型公式？
-
必须根据当前项目的特点选择适用的估算模型
-
-
动态多变量模型（软件方程式）公式？
-
把工作量看作 软件规模和开发时间 的函数
-
开发统一软件 LOC固定时 延长项目持续时间 可降低工作量
-
-
COCOMO2模型（构造性成本模型）是COMOCO的修订版
-
系统应用组成模型构建原型
-
早期设计模型体系结构设计
-
后体系结构模型完成体系结构设计之后的软件开发
-
适用不同类型项目/同一项目不同开发阶段
-
-
-
-
-
进度计划
-
管理人员应高度关注关键任务的进展情况
-
进度安排表 详细进度表 进度结构图
-
项目管理者的目标：
-
定义一个适用于当前项目的任务集合（工作任务 里程碑 可交付的产品） 识别出关键任务 跟踪关键任务的进展 保证能及时发现拖延进度的情况 采取措施予以解决
-
-
估算开发时间
-
软件开发时间与从事开发工作的人数之间不是简单的反比关系
-
T的方程
-
不能以人力换时间的办法无限制地缩短开发时间
-
小组规模扩大 个人生产率下降 不成反比 原因？
-
增加通信开销
-
新成员一开始不仅不是生产力 还要在学习期间花费其他组员的时间
-
-
Brooks规律：向一个已经延期的项目增加人力只会让他更延期
-
Boehm 项目开发时间最多可以减少到正常的75%
-
通信路径数目—人数 项目组结构 p(p-1)/2. p-1
-
-
Gantt图（甘特图）
-
历史悠久 应用广泛
-
水平横线代表任务 线长度代表任务持续时间
-
优点：
-
形象描绘任务分解 子任务开始和结束时间
-
直观简明 容易掌握 容易绘制
-
-
缺点
-
不能显示描绘依赖关系
-
关键部分不明确 难于判定主攻和主控
-
潜力部分及潜力大小不明确 造成潜力浪费
-
-
-
工程网络
-
常用图形工具 描绘任务分解 开始时间 结束时间 还能显式描绘各个作业彼此间依赖关系 系统分析和系统设计有力工具
-
箭头：作业（既消耗资源又持续时间）
-
圆圈：事件（仅是时间点 不消耗时间和资源）
-
虚线箭头：虚拟作业（显式表示作业间依赖关系）（不消耗时间和资源）
-
-
-
估算工程进度
-
最早时刻EET（右上角 从前往后加找最大值）。
-
最迟时刻LET（左上角 从后往前减找最小值）。
-
工程网络算法以及画法
-
-
关键路径
-
用粗线箭头表示
-
一个项目活动图中可以有多个 并行的关键路径
-
如果希望缩短工期 往关键路径中加资源才有效果
-
关键路径上的关键时间必须准时发生 关键作业实际持续时间不能超过估计持续时间 否则工程就不能准时结束
-
推迟关键路径上的任务会延迟整个项目的原因？
-
-
机动时间（不在关键路径上的作业有一定的机动余地）
-
LET结束-EET开始-持续时间
-
价值
-
不在关键路径上的任务不能决定完成任务所需最短时间 可以适当延迟 但也不能延迟时间过久 否则整个项目都会被推迟 机动时间给出了完成这个任务的时间范围
-
仔细考虑机动时间 可以安排既省时间又不影响最终竣工时间的进度表
-
-
工程网络：显式表示依赖关系。甘特图：更简单直观。 同时使用 取长补短
-
-
-
人员组织
-
民主制程序员组
-
n(n-1)/2
-
人数少 适合技术难度高 成员经验丰富
-
一个名义组长 一同完成任务
-
优点： 对发现错误持积极态度 充分民主 高凝聚力 学术气氛浓厚 有利于攻克技术难关
-
缺点：如果多数成员技术水平不高经验缺乏 没有明确权威指导 缺乏必要协调 可能导致失败
-
-
主程序员组可能造成小组成员不愿意发现错误的心理
-
主程序员 后备程序员 编程秘书 其他程序员
-
开发人员缺乏经验。 事务性工作多。 多渠道通信浪费时间这三种情况考虑使用主程序猿组
-
-
现代程序员组
-
主程序员➡️技术负责人+行政负责人
-
-
-
质量保证
-
软件质量软件与明确地和隐含得定义的需求相一致的程度 软件与 明确的叙述的功能和性能需求 文档中明确描述的开发标准 以及任何专业开发的软件产品都应该具有的 隐含特征相一致的程度
-
软件需求是度量软件质量的基础 与需求不一致就是质量不高
-
指定的开发标准定义了一组指导软件开发的准则 与准则不一致就是质量不高
-
如果只能满足明确描述的需求但没满足隐含虚无 软件质量仍然值得怀疑
-
影响软件质量的主要因素
-
产品运行正确性 健壮性 效率 完整性 可用性 风险
-
产品修改可理解性 可维修性 灵活性 可测试性
-
产品转移可移植性 可再用性 互运行性
-
-
-
软件质量保证措施基于非执行的测试（ 复审/评审） 基于执行的测试（软件测试）。 程序正确性证明 软件工程师 SQA小组
-
复审：编码之前文档质量
-
基于执行的测试：保证软件质量的最后一道防线
-
程序正确性证明：数学方法检验是否与说明一致
-
技术复审的必要性：较早发现错误 防止错误传播到软件过程的后续阶段
-
技术复审
-
走查 仅仅标记错误 不用改正
-
审查比走查正规 比走查步骤多。 经济有效
-
-
-
-
-
软件配置管理SCM整个生命周期内管理变化的一组活动 专门用来管理变化的软件质量保证活动
-
用来：标示变化 控制变化 确保适当的实现了变化 向需要知道这类信息的人报告变化
-
从项目启动时开始 持续到软件退役后再结束
-
目标：使变化更正确 更容易被适用 在必须变化时减少花费的工作量
-
软件配置
-
软件配置项SCI
-
计算机程序（源代码和可执行程序）
-
描述计算机程序的文档（技术人员或用户使用）
-
数据（程序内包含的或在程序外的）
-
-
保证配置项 正确+一致
-
基线通过了正式复审的软件配置项
-
作用：有助于人们在不妨碍合理变化的前提下控制变化
-
定义：已经通过了正式复审的规格说明或中间产品 可以作为进一步开发的基础 只有通过正式的变化控制过程才能改变它
-
-
-
软件配置管理过程
-
主要任务：控制变化
-
标示软件配置中的对象（基本对象 聚集对象）
-
版本控制
-
变化控制
-
配置审计
-
状态报告
-
-
-
-
能力成熟度模型CMM
-
基本思想：由于问题是管理不当引起的 所以新软件技术的运用不会自动提高软件生产率和质量
-
作用：提高软件生产率和质量的关键是改进对软件过程的管理 有助于软件开发机构建立一个有规律的成熟的软件过程
-
1级 初始级无序 混乱 只看个人工作能力
-
2级 可重复级建立了基本的项目管理过程 有经验的项目可以成功 策划跟踪稳定
-
3级 已定义级定义了完整的软件过程 软件过程文档化和标准化 可追溯
-
4级 已管理级定量的了解和控制软件过程和软件产品
-
5级 优化级可以使用定量信息来不断改进和优化
-
-
