5. 业务流程分析p83
流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系，明确每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。
业务流程分析的步骤可以总结如下：
(1)通过调查掌握基本情况。
(2)描述现有业务流程—绘制业务流程图。
(3)确认现有业务流程。
(4)对业务流程进行分析—知识和经验支持。
(5)发现问题提出解决方案。
(6)提出优化后的业务流程。
6. 业务流程再造(Business Process Reengineering,BPR)的概念
BPR是指对企业的业务流程进行根本的再思考和彻底的再设计，从而使企业的关键绩效指标，如成本、质量、服务、效率等，获得巨大的提高。
企业流程再造(BPR)应遵循以下原则：
·有一个明确的、具有启发性的目标，即共同远景。
·充分考虑顾客的价值。
·必须服从统一指挥。
·充分做好横向及纵向沟通。
·认识流程再造的两大要素—信息技术/信息系统和人员组织管理。
·树立典范、逐步推进，充分利用变革的涟漪效应。
流程再造方法一般有两大类：全新设计法(Clean Sheet Approach)和系统改造法(SystematicRedesign)，前者遵循“推倒重来”的主张，从根本上抛弃旧流程，零起点设计新流程；后者继承逐步改善的思想即BPI的思想，辨析理解现有流程，在现有流程的基础上，系统渐进地创造新流程。
7. 数据流图DFD p87
结构化分析方法是一种面向数据流的软件分析方法，适合于开发一些数据处理类型的软件的需求分析的方法。
采用数据流图的方式进行数据流程分析一般应遵循以下原则：
·明确系统边界。
·在总体上遵循自顶向下逐层分解的原则
·在局部上遵循由外向里的原则
步骤:
1.识别系统的输入和输出
2.绘制系统内部数据流
3.对复杂加工进行分解
4.对草图进行检查和合理布局
5.和用户交流
6.检查、修改、完善
注意事项：
1.数据流图上所有图形符号只限于4种基本图形元素
2.顶层数据流图必须包括4种基本元素，缺一不可
3.顶层数据流图上的数据流必须封闭在外部实体之间
4.每个加工至少有一个输入数据流和一个输出数据流。一个加工的输出数据流只由它的输
入数据流确定
5.数据流必须经过加工，即必须进入加工或从加工中流出
6.在数据流图中，需按层给加工编号。编号表明改加工处在那一层，以及上下层的父图与
子图的对应关系。
7.规定任何一个数据流子图必须与它上一层的一个加工对应，二者的输入数据流和输出数
据流必须一致。（子图和父图平衡）（考察重点）
8.可以在数据流图中加入物质流，帮助用户理解数据流图
9.图上每个元素都必须有名字
10.数据流图中不可夹带控制流
8 数据字典p87
数据字典项目描述内容举例
1．数据元素
数据元素是最小的数据组成单位，也就是不可再分的数据单位
2.数据结构
数据结构的描述重点是数据之间的组合关系，即说明这个数据结构包括哪些成分。一个数据结构可以
包括若干个数据元素或(和)数据结构。这些成分中有三种特殊情况：
·任选项：这是可以出现也可以省略的项，用“［〕”表示，如［曾用名〕是任选项。
·必选项：在两个或多个数据项中，必须出现其中的一个称为必选项。“｛｝”。
·重复项：即可以多次出现的数据项。
3.数据流
·数据流的来源。·数据流的去处。·数据流的组成。·数据流的流通量。·高峰时的流通量。
4.数据存储
5.外部实体
6.处理(加工)
（对）9. 软件需求说明书（SRS）
软件需求说明书是需求分析阶段的成果，代表用户和开发人员对软件系统的共同的理解。是软件项目后期开发和维护的基础。软件需求说明书不仅是系统测试和用户文档的基础，也是所以子系统项目规划、编码、设计的基础。在文档中需要把用户得功能需求和非功能需求进行详细的记录和准确的描述，包括数据流图和数据字典。要尽可能的完整的描述系统预期的
外部行为，和用户的可视化的行为。除了设计和实现上的限制，不应该描述：设计、构造、测试和工程管理上的细节问题、对算法的详细描述。
方式：
用好的结构化和自然语言编写文本型文档
建立图形化模型，这些模型可以描述转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。
编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求
系统设计
§1. 总体结构设计
总体结构设计又叫概要设计、概要结构设计，p94
任务：是将系统划分为模块，决定每个模块的功能，决定每个模块之间的调用关系，以及决定模块的界面。
模块是组成系统的基本单位，它的特点是可以组合、分解和更换。一个模块应具备以下4个要素：·输入和输出·处理功能·内部数据·程序代码。
模块独立性是指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他模块接口是简单的。模块独立性的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。
1.内聚
顺序内聚有的文献叫信息内聚，一个模块各个单元使用的是同一个数据结构。
2.耦合
耦合性由低到高
非直接耦合数据耦合标记耦合控制耦合外部耦合公共耦合内容耦合
模块独立性由强到弱
条件：
尽量使用数据耦合，少用控制耦合，限制使用公共耦合，完全不用内容耦合。
3. 设计原则p93
①分解——协调原则
②自顶向下的原则
③信息隐蔽、抽象的原则
④一致性原则。
⑤明确性原则。
⑥模块之间的藕合尽可能小，模块内部组合要尽可能紧凑。
⑦模块的扇入系数和扇出系数要合理。
⑧模块的规模适当
4. 子系统划分的原则
·子系统要具有相对独立性
·子系统之间数据的依赖性尽量小
·子系统划分的结果应使数据冗余较小
·子系统的设置应考虑今后管理发展的需要
·子系统的划分应便于系统分阶段实现
·子系统的划分应考虑到各类资源的充分利用
5.子系统结构设计
过程中必须考虑以下几个问题：
·每个子系统如何划分成多个模块。
·如何确定子系统之间、模块之间传送的数据及其调用关系。
·如何评价并改进模块结构的质量。
·如何从数据流图导出模块结构图。
注意的问题：
。模块具有较强的独立性，即内聚性强，耦合性弱
。模块之间的连接只能存在上、下级之间的调用关系，不能有同级之间的横向关系
。整个系统呈树状结构，不允许有网状结构或交叉调用关系出现
。所有模块都必须严格地分类编码并建立归档文件
模块结构图
一个系统的模块结构图一般有两种标准形式，变换型模块结构和事务型模块结构
§2 详细设计
1代码设计
编码问题的关键在于分类。在实际分类时必须遵循如下几点：
·必须保证有足够的容量，以包括规定范围内的所有对象。
·按属性系统化。
·分类要有一定的柔性，不至于在出现变更时破坏分类的结构。
·注意本分类系统与外系统、已有系统的协调。
常用的分类方法概括起来有两种，一种是线分类方法，一种是面分类方法
2.输出设计
·确定输出内容。·选择输出设备与介质。·确定输出格式
3输入设计
原则：
·最小量原则·简单性原则·早检验原则·少转换原则
内容：
·确定输入数据内容·输入方式设计·输入格式设计·校对方式设计
校对方式有人工校对，二次键入校对(同一批数据两次键入)和数据平衡校对。
4处理过程设计
5数据存储设计
6用户界面设计
7安全控制设计
§3 软件测试p106
1.基本原则：
·应尽早并不断地进行测试
·测试工作应该避免由原开发软件的人或小组承担
·设计测试方案的时候，不仅要确定输入数据，而且要根据系统功能确定预期输出结果·在设计测试实例时，不仅要设计有效合理的输入条件，也要包含不合理、失效的输入条件。·在测试程序时，不仅要检验程序是否做了该做的事，还要检测程序是否做了不该做的事·严格按照测试计划来进行，避免测试的随意性。
·妥善保存测试计划、测试例子，作为软件文档的组成部分，为维护提供方便。
2测试过程
(1)拟定测试计划(2)编制测试大纲(3)根据测试大纲(4)实施测试。(5)生成测试报告
3.测试方法
软件测试方法分人工测试和机器测试
人工测试：人工测试指的是采用人工方式进行测试，目的是通过对程序静态结构的检查，找出编译时不能发现的经验表明，组织良好的人工测试可以发现程序中30%-70％的编码和逻辑设计错误。其内容包括检查代码和设计是否一致，检查代码逻辑表达是否正确和完整，检查代码结构是否合理等。
·个人复查·抽查·会审
机器测试
机器测试分为黑盒测试和白盒测试两种。
①黑盒测试也称为功能测试。
进行黑盒测试主要是为了发现以下几类错误：
·是否有错误的功能或遗漏的功能？
·界面是否有误？输入是否能够正确接收？输出是否正确？
·是否有数据结构或外部数据库访问错误？
·性能是否能够接受？
·是否有初始化或终止性错误？
测试：等价类划分边界值分析错误测试因果图
②白盒测试也称为结构测试。
其原则是：
·程序模块中的所有独立路径至少执行一次。
·在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
·每个循环都应在边界条件和一般条件下各执行一次。
·测试程序内部数据结构的有效性等。
测试：（由弱到强）
语句覆盖判断覆盖条件覆盖判断/条件覆盖组合条件覆盖路径覆盖
3.测试步骤
见笔记测试图
(1)单元测试。
单元测试也称为模块测试。检查模块是否实现了详细设计说明书中规定的功能和算法。发现编程和详细设计中产生的错误。单元测试计划应该在详细设计阶段制定。单元测试主要从模块的以下五个特征进行检查：模块接口；局部数据结构；重要的执行路径；出错处理；边界条件。
(2)组装测试。
组装测试也称为集成测试。主要发现设计阶段产生的错误。集成测试的计划应该在概要设计阶段制定或总体设计阶段制定。
集成方式：非增殖式和增殖式
增殖式：自顶向下集成；自底向上集成；混合增殖式方式；衍变的自顶向下的增殖方式；自底向上-自顶向下的增殖方式
见图集成测试
(3)确认测试
确认测试的任务就是进一步检查软件的功能和性能是否与用户要求的一样。系统方案说明书描述了用户对软件的要求，所以是软件有效性验证的标准，也是确认测试的基础。通常采用黑盒测试的方法。
·有效性测试
·软件配置审查
·验收测试测试：开发者在现场进行指导测试：在用户环境下测试
(4)系统测试
系统测试是根据系统方案说明书来设计测试例子的，常见的系统测试主要有以下内容：·恢复测试：·安全性测试·强度测试·性能测试·可靠性测试·安装测试
4调试
·试探法·回溯法·对分查找法·归纳法·演绎法
§3 软件的运行与维护（上午试题中比重较大）
1. 软件维护
占生命周期的60%-80%
（对）系统维护主要包括硬件设备的维护、应用软件的维护和数据的维护
（对）系统的可维护性的评价指标·可理解性·可测试性·可修改性
（对，比例和含义）软件维护的内容一般有以下几个方面：
·正确性维护（改正性维护）17%-21％
·适应性维护18%-25％
·完善性维护50%-60％
·预防性维护4% 把今天的方法学用于昨天的系统，以满足明天的需要。
影响系统维护工作量的因素：系统规模，程序设计语言，系统年龄，数据库技术的应用，先进的软件开发技术
2.程序修改
步骤：分析和理解程序；
修改程序；代码副作用数据副作用文档副作用
重新验证程序
3.再工程
（对）再工程是对现有软件系统的重新开发过程，包括逆向工程（反向工程）、新需求的考虑（软件重构）和正向工程三个步骤。
再工程的基础是系统理解
4.软件重构
软件重构是对源代码、数据进行修改，使其易于修改和维护，以适应将来的变更。（代码、数据）
软件重构并不修改软件体系结构，而是关注模块的细节
5.逆向工程
（对）可以抽取出的信息（层次由低到高，完整性由高到低）：过程的设计表示；程序和数据结构信息；数据和控制流模型；实体关系模型
6.系统评价
（对）广义的信息系统评价分成立项评价、中期评价和结项评价。
系统评价的指标一、系统质量二、技术水平三、运行质量四、用户需求五、系统成本六、系统效益七、财务评价
7.运行管理
对于审计内容可以在3个层次上设定：·语句审计·特权审计·对象审计
绝大多数信息系统的文档要在相应的信息系统淘汰3-5年后才能销毁。
8.文档管理
·文档管理的制度化。·文档要标准化、规范化·文档管理的人员保证·维护文档的一致性·维持文档的可追踪性
§4 构建与软件复用
1.软件复用（辅导242）
软件复用是使用已有的软件产品(如设计、代码、文档等)来开发新的软件系统的过程。
软件复用的形式大体可分为垂直式复用和水平式复用两种。
水平式复用是复用不同应用论域中的软件元素，例如数据结构、排序算法、人机界面构件等。标准函数库是一种典型的、原始的水平式复用机制。
垂直式复用是在一类具有较多公共性的应用论域之间复用软件构件。由于在两个截然不同的应用论域之间进行软件复用潜力不大，所以垂直式复用受到广泛关注。
垂直式复用活动的关键点在于论域分析:根据应用论域的特征和相似性，预测软件构件的可复用性。一旦根据论域分析确认了软件构件的可复用价值，即可进行软件构件的开发，并对具有可复用价值的软件构件进行一般化处理，使它们能够适应新的类似的应用论域。然后将软件构件和它们的文档存入可复用构件库，成为可供未来开发项目使用的可复用资源。
软件复用的范围不仅涉及源程序代码。项目计划、成本估计、体系结构、需求模型和规格说明、设计、源程序代码、用户文档和技术文档、用户界面、数据结构和测试用例。
两个组织：
REBOOT环境（基于软件技术的重用）：为复用开发和利用复用进行开发原则：未来复用者的需求就是对可复用构件的信心，开发者的倾向是抵制复用
推荐文档：测试信息和复用者文档
STARS（可适应可靠的复用技术）关注过程、体系结构和复用三者的集成。
认为：软件生产线开发的软件周期应该包括过程驱动、软件体系结构、领域工程、可复用构件库这4个概念。
2.软件复用过程
系统的软件复用由可复用资产的开发、管理、支持和复用4个过程组成
领域工程和应用系统工程
实施系统复用需要遵循的原则：
·需要顶层管理领导，并需要有长期回收的经费支持。
·为了渐进地推行系统的复用，需要规划和调节系统的体系结构、开发过程、组织结构，并以小规模的先行项目为典型示范，而后再铺开。
·为了复用，先规划体系结构及其逐步实施的过程。
·过渡到明确的复用组织机构，将可复用构件的创建工作与复用工作(即利用可复用构件开发应用系统的工作)分离开，并且提供明确的支持职能。
·在真实的环境中，进行可复用构件的创建和改进工作。
·要将应用系统和可重用构件作为一个经济核算的产品整体进行管理，应当注重公用构件在应用系统及其子系统领域中的高盈利作用。
·要认识到单独的对象技术或者单独的构件技术都是不够的。
·采用竞赛和更换负责人的办法，进行开发单位的文化建设和演变。
·对基础设施、复用教育、技巧培训，要投资和持续地改进。
·要采用度量方法测量复用过程，并要优化复用程序。
3. 构件技术
可复用构件库的组织方式有枚举分类、关键词分类、多面分类、超文本组织法和可复用构件的3C模型。
软件构件的复用的步骤可分为检索与提取构件、理解与评价构件、修改构件和构件的合成。其中构件的合成又分为基于功能的合成技术和基于数据的合成技术。
构件标准的三个主要流派：OMG的CORBA、Microsoft的COM/DCOM和Sun的EJB/J2EE
构件系统应当为复用者提供简便灵活的使用“门面”(facade)
§5软件开发环境
软件开发环境应该包括工具集成、界面集成和方法集成
软件开发环境可由环境机制和工具集构成
按功能划分，环境机制又可分为环境信息库、过程控制和消息服务、用户界面规范。
软件开发环境具有集成性、开发性、可裁减性、数据格式一致性、风格统一的用户界面等特性。
ICASE(集成的软件开发环境)信息库的功能：
数据完整性；信息共享；数据-工具集成；数据-数据集成；方法学实施；文档标准化
§6 软件体系结构
1.软件体系结构（软件架构、软件构架）为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。（元素==构件）
软件体系结构位于需求分析之后，软件设计之前。
软件体系结构也是项目干系人进行交流的手段，明确了软件系统实现的约束条件，决定了开发和维护组织的组织结构。
软件体系结构对软件的质量起制约作用。通过研究软件体系结构，就可以预测软件的质量。
2. 软件体系结构建模
结构模型框架模型动态模型过程模型功能模型
4+1模型：
3. 软件体系结构风格
1）分层系统
应用软件业务软件中间件系统软件应用最多的：网络通信协议
2）客户/服务器
§7 软件过程改进
1. CMM模型
描述和分析软件过程能力的发展程度，确定软件过程成熟程度的分级标准。
等级1一初始级
关键过程域：无
等级2—可重复级
关键过程域(KPI)：需求管理、软件项目计划、软件项目跟踪与监控、软件子合同管理、软件配置保证、软件质量保证
等级3—已定义级
关键过程域：【管理】集成软件管理、组际协调、【组织】组织过程焦点、组织过程定义、培训大纲、【工程】软件产品工程、同行专家评审
等级4—已定量管理级
关键过程域：【管理】定量过程管理、【工程】软件质量管理
等级5—优化级
关键过程域：【组织】技术变更管理、过程变更管理、【工程】缺陷预防
CMMI:2001年发布，
5个分级：
CMM是作为评估标准出现的，所以要求的是必要的实践，这样才能保证评估的标准。CMMI 是作为改进模型出现的，罗列了较多的最佳实践，以利于过程的改进。
2.PSP个体软件过程Personal Software Process
可用于控制、管理和改进个人工作方式的自我持续改进的过程，是一个包括软件开发表格、指南和开发规程的框架。PSP能够说明个体软件过程的原则；帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。
3.TSP团队软件过程（Team Software Process,简称TSP）
管理仍然是开发软件项目成败的关键。迄今为止，学术界和产业界公认CMM是当前最好的软件过程，但应着重指出的是：单纯实施能力成熟度模型CMM，永远不能真正做到能力成熟度的升级，而需要将实施CMM与实施PSP和实施TSP有机地结合起来，才能达到软件过程持续改善的效果
实施需具备的条件
首先需要有高层主管和各级管理人员的支持，以取得必要的资源，这是实施TSP必须具备的物质基础；软件过程的改善需要全体有关人员的积极参与，他们不仅需要有改革的热情和明确的目标，而且需要对当前过程有很好的了解；任何过程改革都有一定的风险，都有一个实践、改革、评审直至完善的循环往复、持续改善的过程，不可能一蹴而就；项目组的开发人员需要经过PSP的培训，使之具备自我改善的能力；整个开发单位的能力成熟度在总体上应处于CMM二级以上。
4.CMM/PSP/TSP三者的关系
5.软件过程评估标准
标准号为ISO/IEC 15504,名称为软件过程评估(software process assessment,SPA)
软件过程评估标准包含9个部分：部分1：概念和引导指南(参考件)；部分2：过程和过程能力的参考模型(标准件) 部分3：进行评估(标准件) 部分4.进行评估的指南(参考件) 部分5：评估模型和指示器指导(参考件) 部分6:评估人员资格指南(参考件) 部分7：过程改进指南(参考件) 部分8：供应者过程能力评定指南(参考件) 部分9：词汇表(标准件)
见表8.5（p193）
NPLF
.过程评估环境
过程改进环境
过程能力评定环境
与CMMl．1有一些重要差别
·参考模型与CMM不同，它明确给出过程维，其中所包括的过程都必须实施，否则，就表明未按良好的软件工程开展基本活动，也就谈不上有什么软件过程能力，所以在这种情况下软件过程能力是零级；仅当实施了过程维的各个过程，才能通过过程能力维的过程属性，分
析评定软件过程能力等级。而CMM则没有定义类似过程维的过程。
·ISO/IEC T8 15504所确定的评估对象是过程维的各个过程，给出这些过程的能力等级；而CMM 1.1的应用对象是项目或组织，而不是过程，给出一个项目或一个组织的整体软件过程成熟度等级。
·软件过程评估标准有一个明确意图，就是作为ISO 9000族标准的一个支持标准，因此，其内容与ISO 9000标准相互协调；而CMM 1.1没有这些考虑。
·软件过程评估标准，特别是其第二部分，直接对准ISO/IEC 12207-1995K信息技术软件生存周期过程》，并在此基础上作了必要的补充和扩展，而CMMl.1没有这样考虑。(不过应当指出，从CMM2.0版本的草案看，ISO/IEC 12207-1995所描述的软件生存周期过程在CMM2.0中都有适当的阐述，见表8.8)。
ISO/IEC 12207信息技术—软件生存周期过程，
主要生存期过程：包括获取、供应、开发、运行和维护
支持生存周期过程包括文档编制、配置管理、质量保证、验证、确认、联合评审、审核和问题解决
组织的生存周期过程：包括管理、基础设施、改进和培训。