考纲
一、概述
软件定义
开发维护用具
三要素
方法+工具+过程
生命周期
每个阶段解决什么问题
采用的方法手段
二、软件过程
软件过程是什么
经典的生命周期模型
特点
优、缺点
给出问题描述，要知道选择什么模式进行产品开发比较合适
（简单了解）软件过程模式
行为准则、过程原则
如何看待要素、需求变化
采取什么态度、手段解决问题
三、可行性研究
（重点）可行性研究
任务、目的、本质
判断问题是否存在可行的解
技术、经济、操作、法律、开发方案的可行性研究
可行性报告、分析结论
系统流程图不作要求不用看
成本效益分析
注意货币时间价值，以后获得的收益和现在的投入成本不能直接比较，要换算
四、需求分析
需求分析
什么是需求
为什么要进行需求分析，解决什么问题
需求要满足的特征
需求的分类
哪些是功能性
哪些是非功能性
在分析阶段，创建分析模型
三个角度
图形工具
数据流图
概念、定义、画法，每一层呈现的内容
数据字典功能
五、总体设计
完成什么工作
设计过程、设计步骤有哪些
设计原理
抽象，逐层细化，信息隐藏，局部化，模块独立性（耦合、内聚的类型划分）
启发式规则
面向数据流的设计方法
数据流—>软件结构图
描述映射步骤，如何转换
软件体系结构风格不用看
六、详细设计
过程设计工具
特点
优、缺点
人机界面设计
需要考虑哪些问题、因素
（响应时间、输入输出方式、操作方式、出错处理、用户的人文方面考虑等等）
程序复杂程度的定量度量
环形复杂度，涉及到流图画法
注意：流图——判定节点（单一条件判断只画一个判定节点，如果这个判定节点里是多个复合条件的判定语句，要拆分成多个判定节点）
七、实现
编码：编码风格（易读易懂）···
测试
测试的基础
测试的目的
什么是好的测试
测试用例的概念和设计
测试分类
单元测试
集成测试
自顶向上、自底向上、三明治集成的步骤
能根据模块层次结构图画出模块集成顺序
不同集成策略的好处
确认测试
具体测试方法
白盒
分类
逻辑覆盖测试：每种覆盖标准的含义
控制结构测试：基本路径测试法的步骤
黑盒
等价类划分
软件可靠性：计算
八、软件维护
掌握概念
什么是软件维护
影响软件维护的因素
如何提高软件产品的可维护性
软件再工程过程：了解一下几个环节即可
九、软件项目管理
成本与工作量估算
软件规模估算的两种方法：代码行技术、功能点技术
进度计划
甘特图：优缺点
工程网络图：画法、计算
人员组织
人员组织机构有哪几种，适合什么类型的项目
人员选择考虑因素
软件项目配置管理
什么是软件配置管理
什么是软件配置
什么是基线，基线的作用
十、面向对象
用例的需求建模
面向对象分析
1、概述
软件定义：软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合
程序是按事先设计的功能和性能要求执行的指令序列
数据是使程序能正常操作信息的数据结构
文档是与程序开发、维护和使用有关的图文材料
开发维护用具
三要素
方法+工具+过程
软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。
软件工具是指为了支援软件人员的开发和维护活动而使用的软件。例如项目估算工具、需求分析工具、设计工具、编程和调试工具、测试工具和维护工具等。使用了软件工具后可以大大提高软件的生产率和质量。
软件工程的过程则将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。
软件工程过程通常包含四种基本的过程活动：
P (Plan):软件规格说明。规定软件的功能及其运行的限制；
D (Do):软件开发。产生满足规格说明的软件；
C (Check):软件确认。确认软件能够完成客户提出的要求；
A (Action):软件演进。为满足客户的变更要求，软件必须在使用的过程中演进。
生命周期
每个阶段解决什么问题
采用的方法手段
概括地说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干个阶段。
软件定义时期
问题定义阶段：界定问题的范围，确切地定义问题；
可行性研究阶段：研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法；
需求分析阶段：确定目标系统必须具备哪些功能；还要估计完成该项工程所需要的资源和成本，制定工程进度表。
软件开发时期
具体设计和实现在前一个时期定义的软件。
总体设计阶段：设计出实现目标系统的几种可能的方案，权衡利弊推荐一最佳方案，并制定实现最佳方案的详细计划，以及设计软件的体系结构；
详细设计阶段：设计出程序的详细规格说明；
编码和单元测试阶段：写出正确的、容易理解、容易维护的程序模块；
综合测试阶段：通过各种类型的测试使软件达到预定的要求。集成测试/验收测试/现场测试/平行运行
运行维护时期
维护阶段的关键任务是：**通过各种必要的维护活动使软件系统持久地满足用户的需要。**通常的4种维护活动：
改正性维护：诊断和改正使用过程中发现的软件错误；
适应性维护：修改软件以适应环境的变化；
完善性维护：根据用户需要改进或扩充软件使之更完善；
预防性维护：修改软件从而为将来的维护活动做好准备。
2、软件过程（软件生命周期）
软件过程是什么
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
ISO 9000对过程的定义: 使用资源将输入转化为输出的活动所构成的系统。
经典的生命周期模型
特点
优、缺点
给出问题描述，要知道选择什么模式进行产品开发比较合适
瀑布模型
特点：
阶段间具有顺序性和依赖性
必须等前一阶段的工作完成之后，才能开始后一阶段的工作
前一阶段的输出文档就是后一阶段的输入文档
推迟实现的观点
清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现
质量保证的观点
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误
优缺点
优点
可强迫开发人员采用规范的方法（例如，结构化技术）严格地规定了每个阶段必须提交的文档
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型
缺点
只能通过文档了解产品，不经过实践的需求是不切实际的
“由文档驱动”的这个事实也是瀑布模型的一个主要缺点,这可能导致最终开发出的软件产品不能真正满足用户的需要
仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品
将本来非线性的软件开发过程人为地加以线性化，不符合实际中的软件开发情况
软件开发耗时长，可运行版本要等到项目后期才能得到，一旦在后期发现错误，付出的代价将是巨大的
问题描述和适用情形
描述
按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开
以文档（计划）驱动
适用情形
需求是预知的
软件实现方法是成熟的
项目周期较短
V模型
问题描述和适用情形
描述
与瀑布模型关注文档和工作产品不同，V模型的关注点是软件开发各阶段的活动以及正确性，因此V模型是以活动驱动的。
瀑布模型的改进，强调测试活动与分析和设计之间的关联
单元测试和集成测试－>校验程序设计
系统测试－>校验（verify）系统设计
验收测试－>确认（validate）需求
适用情形
特点
V模型的本质是对瀑布模型的需求获取活动进行改造，进一步明确了设计环节和测试环节。将原型模型和瀑布模型结合，有助于需求的定义和确认。
优缺点
优点
本质是把瀑布模型中一些隐含的迭代过程明确出来，使开发活动和验证活动的相关性 更加明显
V模型使抽象等级的概念也更明显：所有从需求到实现部分的活动关注的是建立更多 的系统详细表述，而所有从实现到交付运行的活动关注的是对系统的验证和确认
缺点
和瀑布模型一样，都是对软件开发过程过于简单、理想化的抽象，对需求变化的适应性差
原型/快速原型模型
问题描述和适用情形
描述：所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
适用情形
需求多变（开发人员能快速获取需求）
陌生领域开发
特点
关键因素：建立模型的速度
优缺点
优点
克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险这种模型适合预先不 能确切定义需求的软件系统的开发
不带反馈环的，软件产品的开发基本上是线性顺序进行的
有助于需求的定义和确认
可以考虑结合瀑布模型，二者互补性强
用快速原型做为需求分析的一种技术，用于收集客户的真实需求 然后把客户满意了的原型再作为瀑布模型的输入，从而达到优势互补
缺点
所选用的开发技术不一定符合主流的发展
快速建立起来的系统结构加上连续的修改可能会导致产品质量的低下
原型不可能像最终产品一样面面俱到
使用前提是有一个展示性的原型
演化模型（阶段式开发之渐增式开发）
描述
增量模型把软件产品作为一系列的增量构件
第一个增量构件往往实现软件的基本需求，提供最核心的功能
优点
适用于人员配备不充裕、不能在软件项目期限之前实现一个完全版本的软件的情况
能有计划地管理技术风险
每个增量都发布了一个高质量的可操作的版本，用户能在较短时间内使用上部分功能
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新的软件可能给客户带来的冲击
难点
软件体系结构必须是开放的，使得每个新的增量构件能够无缝地集成到现有的软件体 系结构中，增加了设计阶段的投入
本身具有矛盾性，一方面要求开发人员把软件看作一个整体，另一方面要求开发人员把软件看作构件序列，且构件间彼此独立。需要开发人员协调这一矛盾
螺旋模型（阶段式开发之迭代式开发）
描述和适用情形
螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险，理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型（重点：控制风险）
螺旋模型沿着螺线旋转， 在四个象限上分别表达 四个任务区域，即：
制定计划──确定软件 目标，选定实施方案， 弄清项目开发的限制；
风险分析──分析所选 方案，考虑如何识别和 消除风险；
实施工程──实施软件 开发；
客户评估──评价开发 工作，提出修正建议， 并计划下一个阶段的任 务；
优缺点
优点
对瀑布模型的发展，由客户对阶段性产品做出评审，这对保证软件产品质量十分有利
引入风险分析等活动，增强测试活动的确定性
最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视
难点
主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解
只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增 加成本
对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟
特点
喷泉模型
“喷泉”体现了面向对象软件开发过程迭代和无缝的特性，以面对对象的软件开发方法为基础，以用户需求为动力，以对象来驱动的模型
注意
为避免使用喷泉模型开发软件时开发过程过于无序，应该把一个线形过程作为总目标
面向对象范型本身要求经常对开发活动进行迭代或求精
（简单了解）软件过程模式
行为准则、过程原则
如何看待要素、需求变化
采取什么态度、手段解决问题
统一软件开发（RUP）
方法
用例及用例驱动
以架构为中心
在面向对象的分析设计中采用UML进行可视化建模
面向对象的设计与构件实现
敏捷过程（XP）
敏捷过程的价值观（适合小型的、快速变化的软件开发）
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
极限编程（敏捷过程中最富盛名的一个）
特点：
对变化和不确定性反应更快速、更敏捷
快速的同时保持可持续的开发速度（极限的含义是指把最好的开发实践运用到极致，并不是指极限的快交付）
微软过程（MP）
3、可行性研究
（重点）可行性研究
任务、目的、本质
根本任务：对以后的行动方针提出建议
目的：用最小的代价，在尽可能短的时间内确定问题是否能够解决（判断项目是否值得开发）
实质：就是一次压缩、简化了的系统分析和设计的过程
判断问题是否存在可行的解
如果问题没有可行的解，建议停止项目
如果问题值得解，推荐一个较好的解决方案，并制定一个初步的计划
技术、经济、操作、法律、开发方案的可行性研究
技术可行性：使用现有的技术能否实现这个系统。（研发、资源、技术、工具）
经济可行性：进行成本∕效益分析。从经济角度判断系统开发是否“合算”。（成本、效益）
操作可行性：系统的操作方式在这个用户组织内是否行得通。（操作方式、用户）
法律可行性：确定系统开发可能导致的任何侵权、妨碍和责任。（侵权、版权、责任）
开发方案的选择性研究：提出并评价实现系统的各种开发方案，并推荐较优方案。
可行性报告、分析结论
系统流程图不作要求不用看
成本效益分析
注意货币时间价值，以后获得的收益和现在的投入成本不能直接比较，要换算
First Step
估计开发成本、运行费用和新系统将带来的经济效益
成本估计：软件开发成本主要表现为人力消耗（乘以平均工资得到开发费用）
代码行技术
任务分解技术
自动估计成本技术
运行费用：取决于系统的操作费用和维护费用
经济效益：使用新系统而增加的收入+新系统可以节省的运行费用
在进行成本/效益分析时一律假设生命周期为5年
货币的时间价值
i-年利率；P-现在存入的钱数；n-年数
n年后可以获得的钱数：
F = P(1+i)^n反之，如果年后能收入元，这些钱的现在价值为：
P = F/(1+i)^n
投资回收期
使累计的经济效益=最初投资所需的时间
投资回收越短，就能越快获得利润，这项工程就越值得投资
投资回收率
投资回收率>年利率，才考虑开发问题
纯收入
在整个生存周期之内系统的累计经济效益（折合成现在值）与投资之差
4、需求分析
需求分析
什么是需求
开发中以需求为主要目标
需求是检验交付的产品是否合格的主要依据
就是系统的特征，或对系统为达到某个目标所能做的事情的一个描述
是对问题信息和系统行为、特性、设计及制造约束的描述的集合
为什么要进行需求分析，解决什么问题
需求的重要性
在需求过程中会产生很多错误（疏忽、不一致、二义性）
许多错误并没有在早期被发现
这样的错误是能够在产生的初期被检查出来的
如果没有及时检查出来这些错误，软件费用会直线上升
需求分析的任务：借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统 “做什么” 的问题
必须理解并描述问题的信息域，根据这条准则应该建立数据模型
必须定义软件应完成的功能，这条准则要求建立功能模型
必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型
必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节
确定对系统的综合要求
分析系统的数据要求
导出系统的逻辑模型：数据流图、ER图、状态转换图、数据字典
修正系统的开发计划
需求要满足的特征
正确性：要确保需求的表达中没有引入错误
一致性：确保没有互相冲突、矛盾的需求；确保没有不确定的需求
完整性：如果需求描述了所有可能的状态，以及状态的变化、输入、过程和约束，那 么这组需求就是完整的
现实性：确保客户要求系统做的事真的能做到
实用性：确保需求和要解决的问题有直接关系
可检验性：必须能写出测试来说明需求已被满足
可回溯性：保证每个系统功能都能追溯到一组要求它的需求；确保很容易找到处理系 统特定方面的某一组需求
需求的分类
哪些是功能性
系统与环境间的交互——描述系统必须支持的功能和过程的系统需求
eg.声明系统必须提供一些验证系统用户身份的工具
哪些是非功能性（非功能需求必须依附于功能需求而存在）
客户给出的具体约束、指标——描述操作环境和性能目标的系统需求 eg.声明验证过程必须在4秒内完成
应该考虑到的非功能需求
性能：实时性、资源利用、硬件配置限制、精确度
可靠性：有效性、完整性
安全/保密性
运行限制：使用频度、运行期限、控制方式（如本地或远程）、 对操作员的要求
物理限制：系统的规模等限制
用户界面友好性：易用性
在分析阶段，创建分析模型
软件需求分析阶段的工作，可以分为以下4个方面：对问题的识别（需求提取）、分析与综合（需求分析与协商）、编写需求分析文档、需求分析评审（需求确认）
三个角度
行为模型：这个概念包括系统的所有过程层面的内容。
功能模型：描述数据的功能转换。有两种方式：
数据被认为在功能处理元素间流动，如数据流图（DFD）
领域实体被建模成对象，通过事件触发相应的服务来处理数据元 素，如面向对象方法
动态模型：描述与时间有关的变化
结构模型（静态模型）：描述系统的实体结构
图形工具
数据流图
概念、定义、画法，每一层呈现的内容
概念：描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）
画法：
首先建立顶层的数据流图（基本系统模型），其中只含有一个代表目标软件系统整体处理功能的转换。根据软件系统与外部环境的关系确定顶层数据流图中的外部实体以及它们与软件系统之间的数据流。
画系统的内部：将顶层图中的处理分解成若干个处理，并用数据流将这些处理连接起来，使得顶层图中的输入数据流经一连串的加工处理后变换成顶层图中的输出数据流。这张图称为1层数据流图。又称为系统功能级数据流图。
画处理的内部：把每一个处理看作一个小系统，该处理的输入输出数据流看成小系统的输入输出数据流，于是可以用画1层图同样的方法画出每个处理的DFD子图。
对第3步分解出来的DFD子图中的每个处理重复第3步的分解，直至图中尚未分解的处理都足够简单为止。到此得到了一套分层的数据流图。
加工（每个加工至少要有一个输入和输出数据流）
命名：动＋宾
文件
如果加工要读文件，则数据流的方向是从文件到加工
如果加工要写文件，则数据流的方向是从加工到文件
如果加工既要读文件又要写文件，则数据流的方向是双向的
数据字典功能
是对数据流图中包含的所有元素的定义的集合
数据词典与数据流图共同构成系统的逻辑模型
数据字典应该由对下列4类元素的定义组成
数据流：数据结构在系统内传播的路径
数据流分量(即数据元素)：数据处理中最小的，不可再分的单位，它直接反映事物的某一特征。
数据存储
处理
5、总体设计
完成什么工作
软件设计的本质
软件设计是软件开发过程中承前启后的工作，它依据软件需求规格说明书建立软件设计方案，作为下一步程序编码的依据
是在软件开发中形成质量的地方：设计提供了可用于质量评估的软件表示
是将需求准确转换为完整的软件产品或系统的唯一办法
设计过程、设计步骤有哪些
设计过程：
系统设计阶段：确定系统的具体实现方案
结构设计阶段：确定软件结构
设计步骤：
设想供选择的方案：数据流图作出发点
选取合理的方案：at least 3——低、中、高成本
推荐最佳方案——>进入结构设计阶段
功能分解
设计软件结构：
层次图or结构图
直接从数据流图映射出软件结构
设计数据库
数据结构的设计从某种意义上讲是设计活动中最重要的一个
制定测试计划
书写文档
系统说明、用户手册、测试计划、详细的实现计划、数据库设计 结果
审查和复审
设计原理
抽象，逐层细化，信息隐藏，局部化，模块独立性（耦合、内聚的类型划分）
模块化
程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集 成起来构成一个整体，可以完成指定的功能满足用户的需求
抽象
抽出事物的本质特性而暂时不考虑它们的细节
过程抽象、数据抽象
逐步求精
逐步求精可视为一种自顶向下的设计策略
信息隐藏和局部化
信息隐藏：模块应该设计成其中包含的信息（过程和数据）对不需要这些信息的其他 模块来说是不可访问的
局部化：把一些关系密切的软件元素物理地放得彼此靠近 。隐藏的是模块的实现细 节
模块独立性
每个模块完成一个相对独立的子功能，并且和其他模块之间的关系很简单。 它是模块化、抽象、信息隐藏和局部化概念的直接结果
耦合：衡量不同模块彼此间互相依赖（连接）的紧密程度
耦合强弱取决于接口复杂程度
耦合度越高，模块独立性越差——追求松散耦合
类别
非直接耦合：无直接联系——独立性最强
数据耦合：通过简单数据参数来交换输入输出——低耦合
标记耦合：一组模块通过参数表传递记录信息
控制耦合
如果一个模块通过传送开关、标志、名字等控制信息控制另一模块——中等耦合度
实质：在单一接口上选择多功能模块中的某项功能
意味着：A必须知道B内部的一些逻辑关系，降低了模块的独立性
外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构
若不可避免，尽量集中
公共耦合：若一组模块都访问同一个公共数据环境危险，慎用
内容耦合：耦合度最高，现代高级语言基本上不允许出现内容耦合
针对耦合的设计指导原则
尽量使用数据耦合
少用控制和特征耦合
限制外部耦合和公共耦合
完全不用内容耦合
降低耦合的方法
根据问题特点，选择适当的耦合类型
降低模块接口的复杂性
把模块的通信信息放在缓冲区中
减少公共区，使之局部化
输入输出应局限在少数模块，不要分散在全系统
内聚：衡量一个模块内部各个元素彼此结合的紧密程度
内聚度越高，模块独立性越强
类别
偶然内聚：模块内各部分无联系or联系很松散——内聚程度最低
逻辑内聚：千变万化，把几种相关的功能组合在一起，每次调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能（eg:错误处理类模块）
时间内聚：要求所有功能必须在同一时间段内执行 过程内聚：“程序流程图的一部分”，把流程图中的某一部分划出组成模块
过程内聚：“程序流程图的一部分”。使用流程图做为工具设计程序时，把流程图中的某一部分划出组成模块，就得到过程内聚模块。
通信内聚：数据是联系的纽带，使用了相同的输入数据，或产生了相同的输出数据
顺序内聚：接近单一，一个模块内的处理元素和同一个功能密切 相关，而且这些处理必须顺序执行，根据数据流图划分模块时，通常得到顺序内聚的模块
功能内聚：只做一件事，所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的模块化
启发式规则
改进软件结构提高模块独立性，力求降低耦合提高内聚
模块规模应该适中
深度、宽度、扇出和扇入都应适当
模块的作用域应该在控制域之内
作用域：受该模块内一个判定影响的所有模块的集合
控制域：这个模块本身以及所有直接或间接从属于它的模块的集合
力争降低模块接口的复杂程度
设计单入口单出口的模块
模块功能应该可以预测 ，避免对模块施加过多限制
面向数据流的设计方法：把信息流映射成软件结构，数据流类型决定映射方法
数据流—>软件结构图
描述映射步骤，如何转换
信息流分类
变换流
信息沿输入通路进入系统，同时由外部形式变换成内部形式，进入系统的信息通过变换中心，经加工处理以后再沿输出通路变换成外部形式离开软件系统
结构图：输入+变换中心+输出
事务流
数据沿输入通路到达一个处理T，这个处理根据输入数据的类型在若干个动作序列中选出一个来执行，处理T称为事务中心
面向数据流的设计方法的基本过程：
研究、分析和审查数据流图；
根据数据流图决定问题的类型；
由数据流图推导出系统的初始结构图；
根据启发规则对结构进行细化；
修改和补充数据字典；
制定测试计划。
软件体系结构风格不用看
6、详细设计
过程设计工具
表达过程规格说明的工具叫做详细设计工具：图形工具、表格工具、语言工具
特点
优、缺点
程序流程图
优点
用箭头表示控制流，因此程序员不受任何约束
缺点
本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构
不易表示数据结构
盒图（N-S图）
特点
功能域（即某个特定控制结构的作用域）明确，可以从盒图上一眼就看出来
不可能任意转移控制
很容易确定局部和全程数据的作用域
很容易表现嵌套关系，也可以表示模块的层次结构
PAD图（Problem Analysis Diagram）
优点
使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序
PAD图所描绘的程序结构十分清晰
用PAD图表现程序逻辑，易读、易懂、易记
容易将PAD图转换成高级语言源程序，这种转换可用软件工具自动完成
既可用于表示程序逻辑，也可用于描绘数据结构
PAD图的符号支持自顶向下、逐步求精方法的使用
判定表
特点
当算法中包含多重嵌套的条件选择时，使用判定表能够清晰地表示复杂的条件组合与 应做的动作之间的对应关系。
判定表用于表示程序的静态逻辑
在判定表中的条件部分给出所有的两分支判断的列表，动作部分给出相应的处理
要求将程序流程图中的多分支判断都改成两分支判断
优点
能简洁、无二义性地描述所有的处理规则
缺点
判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此不能成为一种通用的设计工具
判定树
判定树是判定表的变种
优点
形式简单，比判定表更直观
缺点
简洁性不如判定表
画判定树时分枝的次序可能对最终画出的判定树的简洁程度有较大影响
过程设计语言（PDL）
特点
用正文形式表示数据和处理过程的设计工具，被称为伪代码
PDL具有严格的关键字外部语法，用于定义控制结构和数据结构
PDL表示实际操作和条件的内部语法通常又是灵活自由的，可以适应各种工程项目的需要
优点
可以作为注释直接插在源程序中间。这样做能促使维护人员在修改程序代码的同时也相应地修改PDL注释，因此有助于保持文档和程序的一致性，提高了文档的质量
可以使用普通的正文编辑程序或文字处理系统，很方便地完成PDL的书写和编辑工作
已经有自动处理程序存在，而且可以自动由PDL生成程序代码
缺点
不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单
人机界面设计
需要考虑哪些问题、因素
（响应时间、输入输出方式、操作方式、出错处理、用户的人文方面考虑等等）
用户、任务和环境分析及建模
两种途径
从实际出发
研究系统现有的规格说明
目标：定义任务并对任务进行分类
逐步求精
面对对象的观点
界面设计
一般问题
系统响应时间：长度、可变性
用户帮助设施：分为集成的和附加的两类
出错信息处理
信息应该用用户可以理解的术语描述问题
信息应该提供有助于从错误中恢复的建设性意见
信息应该指出错误可能导致哪些负面后果
信息应该伴随着听觉上或视觉上的提示
信息不能带有指责色彩
命令方式：命令行、窗口命令
程序复杂程度的定量度量
环形复杂度，涉及到流图画法（McCabe方法）
注意：流图——判定节点（单一条件判断只画一个判定节点，如果这个判定节点里是多个复合条件的判定语句，要拆分成多个判定节点）
环形复杂度计算方法（程序控制分为顺序、选择、循环三种基本结构）
流图中的区域数等于环形复杂度。
流图G的环形复杂度V(G)＝E-N+2，其中，E是流图中边的条数，N是结点数。
流图G的环形复杂度V(G)＝P+1，其中，P是流图中判断的数目。
7、实现
编码：编码风格
好程序的编码风格逻辑简明清晰、易读易懂：
程序的内部文档
标识符的命名
程序的注解：序言性注释、功能性注释
视觉组织
数据说明
数据说明的次序应当规范化
说明语句中变量安排有序化
使用注释说明复杂数据结构
语句构造：简单、直接
输入／输出方法
效率问题：指程序的运行速度及程序占用的存储空间
测试
测试的基础：测试是程序的执行过程
测试的目的：发现错误
什么是好的测试：一个好的测试用例在于能发现至今未发现的错误，一个成功的测试是发现了至今未发现的错误的测试
测试用例的概念和设计
所有测试都应该能追溯到用户需求。 应该远在测试开始之前就制定出测试计划 。 测试发现的错误中的80％很可能是由程序中20％的模块造成的。 应该从“小规模”测试开始，逐步进行“大规模”测试。 穷举测试是不可能的。 为达到最佳的测试效果，应该由独立的第三方从事测试工作。
测试分类
单元测试
测试重点
模块接口
局部数据结构
重要的执行通路
出错处理通路
边界条件
软件常在它的边界上失效
采用一些边界条件，非常可能发现软件的错误
代码审查
查出30%到70%的逻辑设计错误和编码错误
计算机测试
不可避免：编写 驱动程序（driver）&& 存根程序（stub）
驱动程序：主程序，接收测试数据，传给被测试的主模块，印出有关结果
存根程序：虚拟子程序or桩模块，代替所有被测试的模块所调用的模块， 做最少量的数据操作，印出对入口的检验或操作结果，把控制归还给调用它的模块
可采用渐增式测试方法，在集成测试中同时完成对单一模块的详尽测试
模块内聚度高，可简化单元测试过程
集成测试
非渐增式测试：先分别测试每个模块，再一次性把所有模块按设计要求放在一起结合成所要的程序。
渐增式测试：把下一个要测试的模块同已测试好的那些模块结合起来进行测试，依次类推，每次增加一个模块。这种方法实质上同时完成单元测试和集成测试。
自顶向上、自底向上、三明治集成的步骤（分类：一次性集成、自顶向下集成、自底向上集成、三明治集成）
能根据模块层次结构图画出模块集成顺序
不同集成策略的好处
自顶向下集成
从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来
深度优先or宽度优先
优点
自顶向下的结合策略能够在测试的早期对主要的控制或关键的抉择进行检验
自顶向下测试不需要驱动程序
选择深度优先的结合方法，可以在早期实现软件的一个完整的功能并且验证这个功能
缺点
为了充分地测试软件系统的较高层次，需要在较低层次上的处理
可能需要很多存根程序
自底向上集成
从“原子”模块（即在软件结构最低层的模块）开始组装和测试，不需要存根程序
适用于
当底层有许多组件是有多种用途的公用例程而经常被其他组件调用时
当设计是面向对象的或当系统由大量孤立的复用的组件组成时
优点
不需要编写存根程序
测试驱动程序的数目较少
底层模块往往承担主要的计算和输入、输出任务，更容易出错， 该方式可以在早期发现这类错误
底层模块可以并行测试
缺点
对顶层组件测试进行得晚，会推迟主要错误的发现
程序在最后一个模块加入时才具有整体形象
三明治集成
自顶向下策略+自底向上策略
KEY：选取结构图某一层为基准层（目标层）
选取不同的层次为基准层，则整个集成测试的活动情况相应会有很大不同
优点
允许在测试的早期进行集成测试
结合了自顶向下和自底向上测试的优点，在测试的最开始就对控制和公用程序进行测试
缺点
在集成之前没有彻底地测试单独的组件
选择BCDE层作为基准层：
选择FGHIJK层作为基准层：
回归测试
重新执行已经做过的测试的某个子集，以保证由于调试或其他原因引起的变化，不会 导致非预期的软件行为或额外错误
回归测试集（已执行过的测试用例的子集）
检测软件全部功能的代表性测试用例
专门针对可能受修改影响的软件功能的附加测试
针对被修改过的软件成分的测试回归测试
确认测试
目标：验证软件的有效性
如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的
有效性标准/确认测试的基础：需求阶段产生的需求规格说明书或类似文档
确认测试以用户为主
Validation：确认指为了保证软件确实满足了用户需求而进行的一系列活动
Verification：验证指为了保证软件正确地实现了某个特定要求的一系列活动
确认测试的范围
保证软件能满足所有的功能要求
能达到每个性能要求
文档资料是准确而完整的
保证软件能满足其他的预定的要求
软件配置复查
目的：保证软件配置的所有成分都齐全，质量符合要求，文档与程序完全一致，具有完成软件维护所必须的细节，而且已经编好目录。
Alpha测试：用户在开发者的场所
Beta测试：开发者不在测试现场
具体测试方法
白盒
分类
逻辑覆盖测试：每种覆盖标准的含义（逻辑覆盖是以程序内部的逻辑结构为基础设计测试用例的技术）
语句覆盖：设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。
判定覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判定的取真分支和取假分支至少经历一次
条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判定中的每个条件的可能取值至少执行一次
判定/条件覆盖：选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果
条件组合覆盖：设计足够的测试用例，运行被测程序，使得每个判定中条件的所有可能组合至少出现一次
点覆盖：使得程序执行路径至少经过流图的每个结点一次，由于流图的每个结点与一条或多条语句相对应，点覆盖标准和语句覆盖标准是相同的。
边覆盖：使得程序执行路径至少经过流图中每条边一次，与判定覆盖一致
路径覆盖：程序的每条可能路径都至少执行一次(如果程序图中有环，则要求每个环至 少经过一次)
控制结构测试：基本路径测试法的步骤
基本路径测试 步骤
根据过程设计结果画出相应的流图
计算流图的环形复杂度
确定线性独立路径的基本集合
设计可强制执行基本集合中每条路径的测试用例（某些独立路径不能以独立的方式测试）
条件测试
循环测试
黑盒
等价类划分
等价划分（一个理想的测试用例能够独自发现一类错误）
有效等价类：是指对于程序的规格说明来说，那些合理的、有意义的输入数据构成的集合。
无效等价类：是指对于程序的规格说明来说，那些不合理的、无意义的输入数据构成的集合。
例子：
描述：假设有一个把数字串转变成整数的函数。 被处理的数字串是右对齐的，即如果数字串比6个字符短，则在它的左边补空格。如果数字串是负的，则负号和最高位数字紧相邻(负号在最高位数字左边一位)。
有效输入的等价类： (1)1~6个数字字符组成的数字串(最高位数字不是零)； (2)最高位数字是零的数字串； (3)最高位数字左邻是负号的数字串；
无效输入的等价类： (4)空字符串(全是空格)； (5)左部填充的字符既不是零也不是空格； (6)最高位数字右面由数字和空格混合组成； (7)最高位数字右面由数字和其他字符混合组成； (8)负号与最高位数字之间有空格；
合法输出的等价类： (9)在计算机能表示的最小负整数和零之间的负整数； (10)零； (11)在零和计算机能表示的最大正整数之间的正整数； 非法输出的等价类： (12)比计算机能表示的最小负整数还小的负整数； (13)比计算机能表示的最大正整数还大的正整数。
设计出下述测试方案： (1)1～6个数字组成的数字串，输出是合法的正整数 输入：‘ 1’ 预期的输出：1 (2)最高位数字是零的数字串，输出是合法的正整数 输入：‘000001’ 预期的输出：1 (3)负号与最高位数字紧相邻,输出合法的负整数 输入：‘-00001’ 预期的输出：-1
(4)最高位数字是零，输出也是零 输入：‘000000’ 预期的输出：0 (5)太小的负整数 输入：‘-47561’ 预期的输出：“错误——无效输入” (6)太大的正整数 输入：‘132767’ 预期的输出：“错误——无效输入”
(7)空字符串。 输入：‘ ’ 预期的输出：“错误——没有数字” (8)字符串左部字符既不是零也不是空格 输入：‘XXXXX1’ 预期的输出：“错误——填充错” (9)最高位数字后面有空格。 输入：‘ 1 2’ 预期的输出：“错误——无效输入”
(10)最高位数字后面有其他字符 输入：‘ 1XX2’ 预期的输出：“错误——无效输入” (11)负号和最高位数字之间有空格 输入：‘ - 12’ 预期的输出：“错误——负号位置错”
白盒测试优缺点
优点：
迫使测试人员去仔细思考软件的实现； 可以检测代码中的每条分支和路径； 揭示隐藏在代码中的错误； 对代码的测试比较彻底。
缺点：
昂贵； 无法检测源代码中遗漏的路径和数据敏感性错误； 不验证规格说明的正确性。
黑盒测试优缺点
优点：
对于较大的代码单元（子系统或系统级），黑盒测试比白盒测试效率要高； 测试人员不需要了解实现的细节，包括特定的编程语言； 测试人员和编码人员是彼此独立的； 从用户的视角进行测试，很容易被理解和接受； 有助于暴露任何规格不一致或有歧义的问题； 测试用例可以在规格说明完成后马上做出来。
缺点：
只有一小部分可能的输入被测试到，要测试每个可能的输入流几乎是不可能的； 若没有清晰和简明的规格说明，测试用例很难设计； 会有很多程序路径没被测试到； 不能直接针对特定程序（模块）测试，这些程序可能很复杂（因此可能隐藏更多的问题）。
软件可靠性：计算
如果在一段时间内，软件系统故障停机时间分别为td1, td2，…，正常运行时间分别为tu1, tu2….,则系统的稳态可用性为：
A_s = \frac {T_{up} }{(T_{up} + T_{down})}
其中：
T_{up}=\sum_{i=1}^nt_{ui},T_{down}=\sum_{i=1}^nt_{di}引入系统平均无故障时间MTTF和平均维修时间MTTR，则前式可以变成：
A_s = \frac {MTTF }{(MTTF + MTTR)}平均维修时间MTTR是修复一个故障平均需要用的时间(技术水平、熟悉程度、可维护性) 平均无故障时间MTTF是系统按规格说明书规定成功地运行的平均时间(潜伏的错误的数目)
估算平均无故障时间（MTTF）
8、软件维护
掌握概念
什么是软件维护：就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
影响软件维护的因素
决定软件可维护性的因素 可理解性 可测试性 可修改性 可重用性 可移植性
如何提高软件产品的可维护性
建立完整、准确的开发文档
采用先进的开发工具和技术
在软件开发的各个评审环节中注重可维护性
软件再工程过程：了解一下几个环节即可
库存目录分析
文档重构
逆向工程
代码重构
数据重构
正向工程
9、软件项目管理
成本与工作量估算
软件工作量估算是预测构造一个软件系统所需的总工作量的过程。工作量估算从软件规模的估算入手。
软件规模估算的两种方法：代码行技术、功能点技术
代码行技术
功能点技术（功能点（FP）和对象点是这种估算中常用的指标，用系统的功能数量来衡量其规模。）
输入项数：用户向软件输入的项数。这些输入给软件提供面向应用的数据。输入不同于查询，后者单独计数，不计入输入项数中。 输出项数：软件向用户输出的项数。它们向用户提供面向应用的信息，例如，报表和出错信息等。报表内的数据项不单独计数。 查询数：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应，即一对儿“请求－响应” 。 主文件数：逻辑主文件（即数据的一个逻辑组合，它可能是大型数据库的一部分或是一个独立的文件）的数目。 外部接口数：机器可读的全部接口（例如，磁盘或磁带上的数据文件）的数量，用这些接口把信息传送给另一个系统。
由各项的计数同与其对应的复杂度权重计算加权和，此为未经调整的功能点计数（UFP）。
使用代码行或功能点方法，估算出乐观值a、悲观值b、最可能值m； 计算期望值S = (a + 4m + b) / 6；
进度计划
甘特图：优缺点
优点
形象描绘任务分解情况和每个子任务的开始和结束时间
是进度计划和进度管理的有力工具
直观简明，容易掌握，容易绘制
缺点
不能显式地描绘各项作业彼此间的依赖关系
进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象
计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费
工程网络图：画法、计算
活动的四个参数： 前置条件(Precursor)：活动开始前必须发生的事件。 持续时间(Duration)：完成活动所需的时间。 最终期限(Due Date)：日期，活动必须在此之前完成。 结束点(Endpoint)：通常是活动对应的里程碑或可交付成果。
PERT图中：
对于某事件，箭头进入表示此作业结束，箭头离开表示此作业的开始；实线箭头表示具体存在的作业；虚线箭头表示虚拟作业，只为了表示作业之间的依赖关系。
关键路径**（CPM，Critical Path Method）：从起点到终点，可以有许多条路径，我们把耗时最长的路径称作关键路径。关键路径耗时等于整个工程的耗时，因此，要想缩短工程时间，就必须找出关键路径，并研究如何减少关键路径的耗时。**
机动时间＝(LET)结束 －(EET)开始－持续时间 机动时间＝可用时间－持续时间 机动时间＝作业最晚开始时间－最早开始时间 机动时间＝作业最晚结束时间－最早结束时间
优点
描绘任务分解情况以及每项活动／作业的开始时间和结束时间
显式地描绘各个作业彼此间的依赖关系
人员组织
人员组织机构有哪几种，适合什么类型的项目
人员组织机构种类
民主制程序员组：规模2-8人，充分民主，高度凝聚力，通信平行
主程序员组：专业化和层次性，所有通信由一两个人进行
集中式制度（主程序员组）
简单、重复的问题
模块化程度高的问题
大项目
周期固定、较短的项目
分散式（民主制程序员组）
复杂、创新的问题
模块化程度低的问题
小项目
周期长的项目
人员选择考虑因素
主程序员：既是成功的管理员，又是高度熟练的程序员，要负责体系结构和其他关键复杂部分的设计，协调其他成员，复查其他成员的工作，对每行代码负责。 后备程序员：主程序员的“替补”，要和主程序员一样能干。 编程秘书：负责完成与项目有关的全部事务性工作，例如，维护项目资料库、文档，甚至源码的编译、链接、运行等。
软件项目配置管理
什么是软件配置管理：软件配置管理是软件系统发展过程中管理和控制变化的规范。
什么是软件配置：
软件配置项（Software Configuration Item） ：为了配置管理而作为单独实体处理的一个工作产品或一段软件，简称SCI。即软件过程输出的全部计算机程序、文档、数据。
什么是基线，基线的作用
定义：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。基线就是通过了正式复审的软件配置项。
作用：它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它
软件配置管理主要有5项任务
标识、版本控制、变化控制、配置审计、配置状态报告
10、面对对象
用例的需求建模
面向对象分析
面对对象的定义：面向对象=对象+类+继承+通过消息进行通信
对象的定义：
对象是具有相同状态的一组操作的集合。
对象是对问题域中某个东西的抽象，这种抽象反映了系统保存有关这个东西的信息或与它交互的能力。也就是说，对象是对属性值和操作的封装。
对象∷=(ID，MS，DS，MI)。其中，ID是对象的标识或名字，MS是对象中的操作集合，DS是对象的数据结构，MI是对象受理的消息名集合（即对外接口）。
习题
人是软件项目成功的重要因素。如果你将作为项目经理负责一个软件项目的开发，那么你要如何组建你的项目团队，在这一过程中有哪些需要考虑的因素？
人员组织方式的选取：民主制还是集中制
人员的选取：考虑成员的能力、经验、性格等要素
人数的选择：过多人员会造成开发效率的下降
团队凝聚力的培养
其他
请解释说明何为软件配置管理？
软件配置管理是软件系统发展过程中管理和控制变化的规范；是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性、控制这些特性的变更、记录和报告变更的过程和状态，并验证它们与需求是否一致。
软件配置管理的必要性和重要性？
软件项目开发过程中会产生大量的中间产品及这些产品的多个版本，数量很大且易被修改和发生变化，通过软件配置管理可以有效地管理这些产品以及它们之间的关系；
软件开发中会发生各种变化，如果不对这些变化进行管理就会将软件项目带入混乱。配置管理可以表示变化、控制变化、保证变化被适当地实现，并向相关人员报告这种变化。
产品各部件的版本问题。软件产品由很多部件组成，每个部件有自己的多个版本，最终向用户提交的产品可能是众多部件的某一个特定的版本组合，并且可以面向不同的用户群体发布不同的产品版本。因此需要配置管理对软件产品部件的各个版本进行有效标识、记录和管理。
多人团队中，每个开发人员希望以一种独立的、不受他人干扰的方式进行工作；而各个开发人员的开发成果又需要快速、方便地进行集成，这种既独立又联系的方式需要借助配置管理技术进行有效支持。
软件配置管理是否和软件维护一样？为什么？
不一样；软件配置管理和软件维护的区别是：软件配置管理是一组追踪和控制活动，在软件项目启动时就开始，并一直持续到软件被淘汰后才终止；软件维护是一组软件工程活动，发生于软件交付给用户并投入运行之后。
参与讨论
(Participate in the discussion)
参与讨论