软件工程思维脑图思维导图
U354455870
2023-12-28
软件工程
软件开发
课程重点
软件工程选课重点知识点讲解
树图思维导图提供《软件工程思维脑图》在线思维导图免费制作，点击“编辑”按钮，可对《软件工程思维脑图》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：f8a13ba9d911df7fc543dbd5f4c7615a
思维导图大纲
相关思维导图模版
软件工程思维导图模板大纲
第一章 软件与软件工程
软件
定义：各种不同功能的程序（系统程序，应用程序，用户自编程序）称为软件
特点：1. 软件常随时态的发展而变化；
2. 提高软件的开发效率非常重要；
3. 协同合作是软件开发的关键；
4. 软件必须有效地支持它的相关用户；
5. 软件开发过程可理解为具有一种文化背景的
人替代具有另一种文化背景的人创造产品。
分类：1、基于功能不同；2、根据软件服务对象的不同；3、按照软件产品的规模的不同；4、根据工作的方式的不同。
软件危机
出现原因： 1忽视软件开发前期的需求分析
2开发过程缺乏统一的、规范化的方法指导
3文档资料不齐全或不准确
4 忽视与用户之间、开发组成员之间的交流
5忽视代码测试的重要性
6不重视维护或因各种原因造成维护工作的困难
7开发人员对开发背景认识不充分,缺乏经验
8没有完善的质量保证体系支撑
主要表现：（1）开发出来的软件产品不能满足用户的需求
（2）相比越来越廉价的硬件，软件代价过高
（3）软件质量难以保证，难以发挥硬件潜能
（4）难以准确估计软件开发以及维护的费用和周期
（5）难以控制开发风险和开发速度赶不上市场变化
（6）软件产品维护修改苦困难，集成遗留系统更困难
（7）软件文档不完备，文档内容与软件产品不符合
软件工程
软件工程三要素：过程，方法，工具
基本目标：
（1）用分阶段的生命周期计划严格管理；
（2）坚持进行阶段评审；
（3）实行严格的产品控制；
（4）采用现代程序设计技术；
（5）软件工程结果应能背清楚的审查；
（6）开发小组的人员应该少而精；
（7）承认不断改进软件工程实践的必要性。
基本原则：取得较好的软件性能；
开发出高质量的软件；
付出较低的开发成本；
需要较低的维护费用；
能按时完成开发工作;
软件开发方法
结构化方法
面向数据结构方法
面向对象方法
形式化方法
问题分析法
可视化开发方法
软件工程工具
定义：软件工程的工具对软件工程中的过程和方法提供自动的或半自动的支持。
3种分类标准：
按照功能划分
按照支持的过程划分
按照支持的范围划分
第二章 软件过程与模型
软件过程
定义：软件从概念的形成直到软件的退役是一个过程，也称为软件的生命周期，通常把这个过程称为软件过程。
软件生命周期
定义：从设计该产品的构想开始，到软件需求的确定、软件设计、软件实现、产品测试与验收、投入使用以及产品版本的不断更新与维护，到最终该产品被市场淘汰的全过程。
六大子过程
可行性研究、需求分析、软件设计、软件编码、软件测试、软件维护
软件过程模型
定义：常见的软件开发模型有很多种，主要有瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、基于组件的开发模型、统一软件开发过程模型以及敏捷模型与极限编程。
瀑布模型
定义：线性的开发模型，具有不可回溯性。开发人员必须等前一阶段的任务完成后，才能开始进行后一阶段的工作，并且前一阶段的输出往往就是后一阶段的输入。由于其不可回溯性，如果在软件生命周期的后期发现并要改正前期的错误，那么需要付出很高的代价。传统的瀑布模型是文档驱动的。
优点：过程模型简单，执行容易
缺点：无法适应变更。
适用于的开发项目
1、在软件开发的过程中，需求不发生或发生很少变化，并且开发人员可以一次性获取到全部需求。
2、软件开发人员具有丰富的经验，对软件应用领域很熟悉。
3、软件项目的风险较低。瀑布模型不具有完善的风险控制机制。
快速原型模型
定义：快速建立一个能反映用户主要需求的原型系统用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……反反复复地改进，直到原型系统满足用户的要求。
本质：“快速”。开发人员应该尽可能快地建造出一个原型系统，以加速软件开发过程，节约软件开发成本。
目的：获知用户的真正需求，一旦需求确定了，原型将被抛弃
优点：有助于获取和理解用户需求；
尽早发现软件中存在的错误；
支持项目需求的动态变化。
缺点：不能支持风险分析；
开发者为了使一个原型快速运行起来，往
往在实现过程中采用折衷的手段。
适用于的开发项目
已有产品或产品的原型，只需客户化的工程项目；
简单而熟悉的行业或领域；
有快速原型开发工具；
进行产品移植或升级开发者在不了解的应用领域开发；
客户不清楚其所开发的软件项目的最终目标。
增量模型
定义：把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。
根据增量的方式和形式的不同，分为：
1、基于瀑布模型的渐增模型
2、基于原型的快速原型模型
优点：当产品不能在限定时间完成时，提供了先推出核心产品的途径。
逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品。
当需求变更时，需要重新完成的分析和文档数量比较少。
在开发过程中更容易得到客户对于已完成的开发工作的反馈意见。
更快速地交付和部署有用的软件给客户成为可能。
人员分配灵活，刚开始不需投入大量人力资源。
缺点：软件体系结构必须是开放的。
模型本身是自相矛盾的。整体——独立构件。
不同的构件并行进行有可能加快工程进度，有时无法集成到一起。
整个过程是不可见的。管理人员需要定期交付成果来掌握进度。
随着新的增量的添加，系统结构趋向于降级。
螺旋模型
定义：
一种用于风险较大的大型软件项目开发的过程模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了这两种模型忽略了的风险分析。它把开发过程分为制定计划、风险分析、实施工程和客户评估四种活动。
适用于的开发项目
适应于风险较大的大型软件项目的开发。它的优点是将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。但是这种模型的控制和管理较为复杂，可操作性不强，对项目管理人员的要求较高。
基本思想：
迭代地进行软件产品开发;
需求获取、设计、编码和测试活动之间会有大量重叠;
如果需求的任何阶段出现缺陷，会使该需求返回到前面的阶段;
开发人员能够在任何时候演示当时产品所具有的功能;
可以降低在项目后期发现重大缺陷的风险。
优点：有助于获取用户需求，加强对需求的理解。
尽早发现软件中的错误。
支持需求的动态变化。
支持风险分析，可降低或者消除软件开发风险。
适合于需求动态变化，难以确定开发风险的系统。
缺点：螺旋模型开发的成败，很大程度上依赖于风险评估的成败。
需要开发人员具有相当丰富的风险评估经验和专门知识。
通常使用的场合：
需求不能完全确定，同时又存在技术、资金或开发时间等风险因素的大型开发项目。
喷泉模型
定义：
典型的面向对象生命周期模型。在面向对象的方法中，分析模型和设计模型采用相同的符号标示体系，各阶段之间没有明显的界限，而且常常重复、迭代地进行。喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。
优点：
该模型的各个阶段没有明显界限，开发人员可以同步进行开发。
多次反复地增加或明确目标系统，降低了错误的可能性。
缺点：
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，不利于项目的管理。
要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
基于组件的开发模型
在确定需求之后，开发人员开始从现有的组件库中筛选合适的组件，并对组件功能进行分析。
在对组件分析之后，开发人员可能适当修改需求来适应现有组件，也可能修改组件或寻找新的组件。
组件筛选完成之后，开发人员需要根据需求设计或使用现有的成熟开发框架复用这些组件，一些无法利用现有组件的地方，则需要进行单独的开发，新开发的组件在经历时间考验之后也会加入到组件库中。
最后将所有组件集成在一起，进行系统测试。
敏捷过程与极限编程
敏捷开发
定义：一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员之间充分的交流与沟通以及合理的机制来有效地响应变化。
敏捷软件开发宣言四个价值观
(1) 个体与交互高于过程和工具；
(2) 可运行软件高于详尽的文档；
(3) 与客户协作高于合同谈判；
(4) 对变更及时响应高于遵循计划。
极限编程
定义：一种实践性较强的规范化的软件开发方法，它强调用户需求和团队工作。利用极限编程方法进行软件开发实践的工程师，即使在开发周期的末期，也可以很快地响应用户需求。
相互作用和相互影响的规则和实践。
在项目计划阶段，需要建立合理和简洁的用户故事。
在设计系统的体系架构时，可以采用CRC（Class，Responsibility，Collaboration）卡促使团队成员共同努力。
在代码编写阶段，为了保证代码的质量，可以采用结对编程以及在编码之前构造测试用例等措施。
在代码测试方面，开发人员有责任向用户证明代码的正确性，而不是由用户来查找代码的缺陷。合理的测试用例及较高的测试覆盖率是极限编程项目测试所追求的目标。
几种模型之间的关系
瀑布模型与RUP模型之间的关系
都是动态模型，瀑布模型中有RUP模型，反过来，RUP模型中也有瀑布模型。
瀑布模型与增量模型之间的关系
在开发每个模块时，通常都是采用瀑布模型，从分析、设计、编码和测试这几个阶段进行开发。所以，增量模型中有瀑布模型，即宏观上是增量模型，微观上是瀑布模型。
瀑布模型与快速原型模型之间的关系
快速原型模型不但包含了迭代模型的思想，且包含了瀑布模型的思想。
瀑布模型与螺旋模型之间的关系
螺旋模型每一次顺时针方向旋转，相当于顺时针方向迭代一次，都是走完一次瀑布模型，这就是瀑布模型与螺旋模型之间的关系。
选择软件过程模型
在选择软件过程模型时需要考虑六点
1. 符合软件自身的特性，如规模、成本和复杂性等；
2. 满足软件开发进度的要求；
3. 对软件开发的风险进行预防和控制；
4. 具有计算机辅助工具的支持；
5. 与用户和软件开发人员的知识和技能相匹配；
6. 有利于软件开发的管理和控制。
第三章 可行性研究与项目开发计划
项目立项
项目发起
项目发起人或单位为寻求他人的支持，要以书面材料的形式递交给项目的支持者和领导，使其明白项目的必要性和可行性。
项目论证
可行性研究过程。可行性研究就是指在项目进行开发之前，根据项目发起文件和实际情况，对该项目是否能在特定的资源、时间等制约条件下完成做出评估，并且确定它是否值得去开发。
项目审核
经过可行性研究后，还需要报告主管领导或单位，以获得项目的进一步审核，并得到他们的支持。
项目立项
通过可行性研究和主管部门批准后，将其列入项目计划的过程。
可行性研究
目的：不是解决问题，而是确定问题是否值得去解决。
任务：针对具体的问题用最小的代价、在尽可能短的时间内确定问题是否能解决。
技术可行性
主要研究待开发的系统的功能、性能和限制条件，确定现有技术能否实现有关的解决方案，在现有的资源条件下实现新系统的技术风险有多大。
评估技术可行性时，需要考虑以下情况：了解当前最先进技术，分析相关技术的发展是否支持新系统；确定资源的有效性，如新系统的软硬件资源是否具备，开发项目的人员在技术和时间上是否可行等；分析项目的开发的技术风险，即能在给定的资源和时间等条件下，设计并实现系统的功能和性能等。
操作可行性
对开发系统在一个给定的工作环境中能否运行或运行好坏程度的衡量。操作可行性研究决定在当前的政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等环境下，系统的操作是否可行。
考虑系统是否能够真正解决问题；系统安装后是否有足够的人力资源运行系统；用户对新系统是否抵触或者操作是否可行等。
操作可行性往往最容易被忽视或被低估，或者认为它一定是可行的。
经济可行性
成本--效益分析：是可行性研究的重要内容，它用于评估基于项目的经济合理性，给出项目开发的成本论证，并将估算的成本与预期的利润进行对比。
效益包括直接效益、可见的间接效益、不可见的效益。
可行性研究的步骤
1、明确系统目标
2、分析研究现行系统
3、设计出新系统的高层逻辑模型
4、获得比较可行的解决方案
5、撰写可行性研究报告
制定项目开发计划
1、项目概述
说明项目的各项主要工作：
1、软件的功能和性能；
2、为完成项目应具备的条件；
3、甲方和乙方应承担的工作、完成期限和其他4、限制条件；
5、应交付的软件名称，所使用的开发语言及存储形式；
6、应交付的文档。
2 、实施计划
任务的划分，各项任务的责任人；说明项目开发进度，按阶段应完成的任务，用图表说明每项任务的开始时间和完成时间；说明项目的预算，各阶段的费用支出预算等。
3、人员组织及分工
开发该项目所需人员的类型、组成结构和数量等。
4、交付期限
项目应交付的日期等。
第四章 软件需求分析
需求分析
需求分析的任务
“系统必须做什么?”，具体来讲：功能需求、性能需求、可靠性和可用性需求、 出错处理需求、接口需求、约束条件、逆向需求、将来可能提出的要求。
1. 确定系统的运行环境和要求
系统运行时的硬件环境和要求，软件环境要求
2. 确定系统的功能性需求和非功能性需求
功能需求
软件系统的最基本的需求表述，包括对系统应该提供的服务，如何对输入做出反应，以及系统在特定条件下的行为描述。在某些情况下，功能需求还必须明确系统不应该做什么，这取决于开发的软件类型、软件未来的用户、以及开发的系统类型。
非功能性需求
包括对系统提出的性能需求、可靠性和可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准等。性能需求指定系统必须满足的定时约束或容量约束，一般包括速度（响应时间）、信息量速率（吞吐量、处理时间）和存储容量等。
3. 进行有效的需求沟通
开发人员和用户之间要进行充分有效的沟通，有效的需求分析通常都具有一定的难度，这一方面是由于交流 障碍所引起的，另一方面是由于用户通常对需求的陈述不完备、不准确和不全面，并且还可能在不断的变化。所以开发人员不仅需要在用户的帮助下抽象现有的需求，还需要挖掘隐藏的需求。
4. 需求分析过程中应遵守的原则
首先，需求分析是一个过程，它应该贯穿于系统的整个生命周期中，而不是仅仅属于软件生命周期早期的一项工作。
其次，需求分析是一个迭代的过程。由于市场环境的易变性以及用户本身对于新系统要求的模糊性，需求往往很难一步到位。通常情况下，需求是随着项目的深入而不断变化的。所以需求分析的过程本身是一个迭代的过程。
此外，为了方便评审和后续的设计，需求的表述应该具体、清晰，并且是可测量的、可实现的。最好能够对需求进行适当的量化。比如：系统的响应时间应该低于0.5秒；系统同一时刻最多能支持30000个用户等。
5. 需求分析的两个任务
需求分析的建模阶段
在充分了解需求的基础上，要建立起系统的分析模型。
需求分析的描述阶段
就是把需求文档化，用软件需求规格说明书的方式把需求表达出来。
6. 软件需求规格说明书
是需求分析阶段的输出，它全面、清晰地描述了用户需求；是开发人员进行后续软件设计的重要依据。
软件需求规格说明书应该具有清晰性、无二义性、一致性和准确性等特点。
需求分析的步骤
1、需求获取
正 式 访 谈
系统分析员提出事先准备好的问题
非正式访谈
提出一些用户可以自由回答的开放性问题，让被访者说出自己的想法
调查表
当需要访问大量人员时，用调查表访问。
情景分析法
访谈时如果能用一个类似的案例进行交流效果会更好。
2、分析建模
为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。
为了从不同角度描述或理解软件系统，就需要不同的模型。常用的建模方法有数据流图、实体关系图、状态转换图、控制流图、用例图、类图、对象图等。
模型的作用
1、在建模过程中了解系统。
2、通过抽象降低复杂性。
3、有助于回忆所有的细节。
4、有助于开发小组间的交流。
5、有助于与用户的交流。
6、为系统的维护提供文档。
3、需求描述
对于一般软件系统，需求阶段只需要输出软件需求文档就可以了对于复杂的软件系统，需求阶段会产生3个文档:
系统定义文档（用户需求报告）
系统需求文档（系统需求规格说明书）
软件需求文档（软件需求规格说明书）
软件需求规格：说明书是需求分析阶段的输出，它全面、清晰地描述了用户需求；是开发人员进行后续软件设计的重要依据。 软件需求规格说明书应该具有清晰性、无二义性、一致性和准确性等特点。
4、需求验证
验证以上需求分析的成果。为了提高软件开发的质量，降低软件开发的成本，必须对需求的正确性进行严格的验证，确保需求的一致性、完整性、现实性、有效性。确保设计与实现过程中的需求可回溯性，便于进行需求变更管理
需求管理
为了更好的进行需求分析并记录需求结果，需要进行需求管理。需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。可用于：
获取、组织和记录系统需求；
使客户和项目团队在系统变更需求上达成并保持一致。
需求管理的关键在于维护需求的明确阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工件之间的可追踪性。
结构化分析概述
定义：一种考虑数据和处理的需求分析方法被称作结构化分析方法它基于“分解”和“抽象”的基本思想，逐步建立目标系统的逻辑模型，进而描绘出满足用户要求的软件系统。
“分解”是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解为若干个小问题，然后再分别解决。
“抽象”是用最本质的属性，表示一个软件系统的方法。
结构化分析的具体步骤
1、建立当前系统的“具体模型”
系统的“具体模型”就是现实环境的忠实写照，这样的表达与当前系统完全对应，因此用户容易理解。
2、抽象出当前系统的逻辑模型
分析系统的“具体模型”，抽象出其本质的因素，排除次要因素，获得当前系统的“逻辑模型”。
3、建立目标系统的逻辑模型
分析目标系统与当前系统逻辑上的差别，从而进一步明确目标系统“做什么”，建立目标系统的“逻辑模型”。
4、为了对目标系统进行完整的描述还需要考虑人机界面和其他一些问题
结构化分析方法
结构化分析围绕着“数据字典”有3种不同的图
数据流图
指出当数据在软件系统中移动时怎样被变换，以及描绘变换数据流的功能和子功能，用于功能建模。
实体-关系图
描绘数据对象之间的关系，用于数据建模。
状态转换图
指明了作为外部事件结果的系统行为，用于行为建模。
功能建模
定义：思想就是用抽象模型的概念，按照软件内部数据传递和变换的关系，自顶向下逐层分解，直到找到满足功能要求的可实现的软件为止。功能模型用数据流图来描述。
数据流图
定义：简称DFD图）就是采用图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
外部实体：表示数据的源点或终点，它是系统之外的实体，可以是人、物或者其他系统。
矩形或矩形体
数据流：表示数据流的流动方向。数据流可以从加工流向加工，从加工流向文件，从文件流向加工。
箭头
数据存储：表示输入或输出文件。这些文件可以是计算机系统中的外部或者内部文件，也可以是表、账单等。
数据存储符号
加工 :描述了输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理后变成了输出数据。
圆角矩形或椭圆形
数据流图的层次结构
数据流图中的4种成分：首先考虑数据的源点和终点，然后考虑需要做哪些处理，处理结果存储在哪里，数据整个流向是怎样的。一旦把4种成分确定了就可以画出数据流图了。
画数据流图的步骤
1、先画顶层数据流图，确定输入输出
顶层流图只包含一个加工，用以表示被开发的系统，然后考虑该系统有哪些输入数据、输出数据流。向用户了解“系统从外界接受什么数据”，“系统向外界送出什么数据等信息”。
2、画系统内部，即画下层数据流图
不再分解的加工称为基本加工。一般将层号从0开始编号，采用自顶向下，由外向内的原则。画0层数据流图时，分解顶层流图的系统为若干子系统，决定每个子系统间的数据接口和活动关系。
确定数据流的方法：用户把若干数据当作一个单位来处理（这些数据一起到达、一起处理）时，可以把这些数据看成一个数据流
确定数据存储的方法：对于一些以后某个时间要使用的数据，可以组织成为一个数据存储来表示。
对数据流图和加工编号
顶层图只有一张，图中的加工也只有一个，所以不必为其编号。
0层图只有一张，图中的加工号分别是0.1、0.2、…或者1,2。
子图就是父图中被分解的加工号。
子图中的加工号、圆点和序号组成，如：1.1,1.2,1.3等等。
结构化分析方法
根据结构化需求分析采用的“自顶向下，由外到内，逐层分解”的思想，开发人员要先画出系统顶层的数据流图，然后再逐层画出低层的数据流图。顶层的数据流图要定义系统范围，并描述系统与外界的数据联系，它是对系统架构的高度概括和抽象。底层的数据流图是对系统某个部分的精细描述。
数据建模
数据建模的思想是在较高的抽象层次（概念层）上对数据库结构进行建模。数据模型用实体关系图来描述。
数据模型
是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，反映了用户的现实环境，而且与在软件系统中的实现方法无关。
包含3种相互关联的信息：数据对象（实体）、数据对象的属性及数据对象彼此间相互连接的关系。
复合信息
是指具有一系列不同性质或属性的事物。
数据对象
对软件必须理解的复合信息的抽象。可以是由一组属性来定义的实体。如：外部实体、事物、行为、事件、角色、单位、地点或结构等。仅有单个值的事物(例如：宽度)不是数据对象。
数据对象彼此间是有关联的。
数据对象只封装了数据，没有给出施加于数据上的操作。这是与面向对象中的“类”或“对象”的区别。
属性
定义了数据对象的性质。
通常把一个或多个属性定义为“标识符”。当希望找到数据对象的一个实例时，用标识符属性作为“关键字”来建立索引。
关系
一对一联系(1∶1)
一对多联系(1∶N)
多对多联系(M∶N)
ER图中包含
实体(即数据对象)，用矩形框表示
关系，用连接相关实体的菱形框表示
属性，用椭圆形或圆角矩形表示
并用直线把实体(或关系)与其属性连接起来。
行为建模
状态
状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。
初态：用实心圆表示
终态：用一对同心圆(内圆为实心圆)表示
中间状态：用圆角矩形表示，分成上、中、下3部分。
上面部分——为状态的名称；
中间部分——为状态变量的名字和值；
下面部分——是活动表。
带箭头的连线：称为状态转换，箭头指明了转换方向
在一张状态图中只能有一个初态，而终态则可以没有，也可以有多个
事件
事件就是引起系统做动作或（和）转换状态的控制信息。
状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式。
如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。
层次方框图
层次方框图：用树形结构的一系列多层次的矩形框描绘数据的层次结构。
树形结构的顶层是一个单独的矩形框，它代表完整的数据结构；
其余各层矩形框代表这个数据的子集
最底层的各个框代表组成这个数据的实际数据元素(不能再分割的元素)。
Warier（瓦尼尔）图
Warier（瓦尼尔）图：和层次方框图类似，Warnier图也用树形结构描绘信息，这种图形工具比层次方框图提供了更丰富的描绘手段。
特点：Warnier图可以表明信息的逻辑组织，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。
数据字典
数据流的描述
数据流名称：产生的原因和结果
数据流来源：数据流来自何方
数据流去向：去向何处
数据流组成：数据结构
数据流通量：数据量、流通量。
数据元素的描述
数据元素名称
数据元素类型：数字（离散值、连续值），文字（编码类型）
数据元素长度
数据元素取值范围
相关的数据元素及数据结构
数据存储的描述
数据存储名：存放的是什么数据
输入数据
输出数据
数据文件组成：数据结构
存储方式：顺序、直接、关键码
存取频率
处理的描述
处理名称
处理编号：反映处理的层次
简要描述：加工逻辑及功能简述
输入数据流
输出数据流
加工逻辑：加工程序、加工顺序
数据的定义方法
数据字典中的定义就是对数据自顶向下的分解
数据元素组成数据的方式有下述几种基本类型：
顺序：即以确定次序连接两个或多个分量。
选择：即从两个或多个可能的元素中选取一个。
重复：即把指定的分量重复零次或多次。
可选：即一个分量是可有可无的（重复0次或1次）
软件需求的正确性验证
正确性应从4个方面进行
一致性 所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
完整性 需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
现实性 指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
有效性 必须证明需求是正确有效的，确实能解决用户面对的问题。
正确的验证方法
验证需求的一致性
人工技术审查；
形式化的描述软件需求的方法；
验证需求的现实性
仿真或性能模拟技术
验证需求的完整性和有效性
开发原型系统；
需求验证内容
有效性检查－－指功能需求是否符合用户所提出的需求。
一致性检查－－系统功能描述及约束是否一致。
完备性检查－－是否包含所有系统用户的需求和约束
可检验性检查－－能否设计出一组验证方法，确定了检验的标准。
第五章 结构化设计
软件设计的基本概念
软件设计的意义和目标
软件设计在软件开发过程中处于核心地位，它是保证质量的关键步骤 。
软件设计原则
使用基本的设计概念：模块化，抽象，逐步求精，信息隐蔽，自顶向下等。
结构化软件设计方法
软件结构图
软件结构图是系统的模块层次结构，反映了整个系统的功能实现，即将来程序的控制层次体系。
它表示的是软件元素之间的关系，比如调用关系、存储关系与嵌套关系。
结构图应注意的事项
①同名字的模块在结构图中仅出现一次
②调用关系只能从上到下。
③不严格表示模块的调用次序，习惯上从左到右。有时为了减少连线的交叉，适当地调整同一层模块左右位置，以保持结构图的清晰性。
面向数据流的设计方法
数据流分为两种
变换型数据流
输入数据、变换中心、输出数据
事务型数据流
事务中心、接收数据、处理路径
Jackson图
顺序结构
选择结构
重复结构
Jackson图的优点
便于表示层次结构，而且是对结构进行自顶向下分解的有力工具
形象直观可读性好
既能表示数据结构也能表示程序结构（因为结构程序设计也只使用上述3种基本结构）
Jackson图的缺点
用这种图形工具表示选择或重复结构时，选择条件不能直接在图上表示出来，影响了图的表达能力，也不易直接把图翻译成程序。此外框线间的线为斜线，不易在行式打印机上输出。
Jackson图和层次图区别
层次图中的一个方框通常代表一个模块，Jackson图中一个方框只代表几条语句
层次图表现的是调用关系，Jackson图表现的是组成关系
Jackson结构程序设计方法的步骤
分析并确定输入数据和输出数据的逻辑结构，并用Jackson图描绘这些数据结构
找出输入数据结构和输出数据结构中有对应关系的数据单元
结构化软件设计的工具
流程图
顺序型、
选择型、
先判定型循环（WHILE-DO）、
后判定型循环（DO-WHILE）
多分支选择型
程序流程图的主要优点
和缺点
优点：采用简单规范的符号，画法简单
结构清晰，逻辑性强
便于描述，容易理解
缺点：不利于逐步求精的设计
图中可用箭头随意地对控制进行转移，与结构化程序设计精神相悖
不易于表示系统中所含的数据结构
当目标系统比较复杂时，流程图会变得很繁杂、不清晰
盒图（N-S图）
特点：不允许随意的控制转移，有利于严格的结构化程序设计
可以很方便地确定一个特定控制结构的作用域，以及局部数据和全局数据的作用域
可以很方便地表示嵌套关系以及模块之间的层次关系
PAD图
主要特点：表示的程序结构的执行顺序是自最左边的竖线的上端开始，自上而下，自左向右
表示的程序片断结构清晰、层次分明
支持自顶向下、逐步求精的设计方法
只能用于结构化的程序设计
不仅可以表示程序逻辑，还能表示数据结构
判定表
判定表用于表示程序的静态逻辑
判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系
在判定表中的条件部分给出所有的分支判断的列表，动作部分给出相应的处理。
判定表的组成
左上部列出所有条件
左下部是所有可能做的动作
右上部是表示各种条件组合的一个矩阵
右下部是和每种条件组合相对应的动作
判定表右半部实质上是一条规则,规定了与特定条件组合相对应的动作.
建立判定表的步骤
列出与一个具体过程(或模块)有关的所有处理
列出过程执行期间的所有条件(或所有判断)。
将特定条件取值组合与特定的处理相匹配,消去不可能发生的条件取值组合。
将右部每一纵列规定为一个处理规则,即对于某一条件取值组合将有什么动作。
判定树
判定树也是用来表达加工逻辑的一种工具
判定树是判定表的图形化表示，是判定表的变种。
过程设计语言
PDL
PDL是一种用于描述功能模块的算法设计和加工细节的语言。称为设计程序语言。它是一种伪码。
伪码
数据库结构设计
概念结构
描述系统最基础的数据结构
逻辑结构
提供比较接近数据库内部构造的逻辑描述
物理结构
数据库的物理数据模型
人机界面设计
由软件工程师创建的设计模型
由人机工程师（或软件工程师）创建的用户模型
终端用户对未来系统的假想
系统实现后得到的系统映象
第六章 软件实现
编程语言
编程语言的发展与分类
机器语言和汇编语言、高级语言
编程语言的理论标准
1）有理想的模块化机制；
2）可读性好的控制结构和数据结构；
3）便于调试和提高软件可靠性；
4）编译程序发现程序错误的能力强；
5）有良好的独立编译机制。
编程语言简介
Java：纯面向对象，垃圾自动回收功能，跨平台特性
C语言：面向过程，执行效率非常高
C++：面向对象，部署方便，执行效率高
Python:完全面向对象的语言
编码风格
好程序的标准
能够满足用户的使用要求；可靠性高；可读性强；可修改性强；易移植、可重用等。
编程的基本原则
源程序文档要清晰易读
数据说明要简洁标准
语句构造简单直接
采用人性化输入和输出格式
程序运行注重性能和功能效率
其他
效率
1）程序运行时间
源程序的效率直接由详细设计阶段确定的算法的效率决定，但是，程序的风格也能对程序的执行速度和存储器要求产生影响。
2）存储器效率
使用能保持功能域的结构化控制结构，是提高效率的好办法。提高存储器效率的关键是程序的简单化。
3）输入输出效率
操作员能够十分方便、简单地录入输入数据，或者能够十分直观、一目了然地了解输出信息，则可以说面向人的输入／输出，也是高效的。
第七章 软件测试与维护
软件测试的基本概念
目的
是为了检测出软件存在错误
不同立场出发，存在两种完全不同的测试目的
1.从用户的角度 希望测试出软件暴露软件的错误和缺陷，再来考虑是否接受这个软件
2.从软件开发的角度出发
希望软件实现用户的要求，确立人们对软件质量的信心
杀虫剂现象
软件中存在的缺陷数量与发现的故障数目成正比
软件测试原则
1.完全测试是不可能的
2.测试中有风险存在
3.软件测试只能表明缺陷的存在，而不能证明
产品已经没有缺陷
4.软件产品中所存在的错误数与已发现的错误
数成正比
5.要避免软件测试的杀虫剂现象
6.在设计测试用例时，应包括输入数据和预期
的输出结果两个部分
7.要集中测试容易出错或错误较多的模块
8.应该长期保留所有的测试用例
9.使开发人员和测试人员分立
10.测试工作应该尽早开始
软件测试分类
按开发阶段
按测试实施组织
按测试技术
按测试内容
软件测试过程（自底向上）
1.制定测试计划
2.编制测试大纲
3要设计和生成测试用例
4实施测试
5生成软件问题的报告。
软件测试模型
Ⅴ模型
描述了基本的开发过程和测试行为
W模型
W模型强调“测试伴随着整个软件开发周期”。测试的对象不仅仅是程序，需求、功能和设计同样要测试。
H模型
H模型将测试活动完全独立出来，形成一个完全独立的流程;
测试用例
测试工作的指导，是软件测试的必须准守的准则，更是软件测试质量稳定的根本保障
什么是测试用例？
测试用例，英文Test Case，缩写为TC/指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。测试用例设计的好坏直接决定了测试的效果和结果，所以在软件测试活动中最关键的步骤就是设计有效的测试用例。测试用例可以针对黑盒测试设计用例，也可以针对白盒测试设计用例。
测试
静态测试
常用形式为审查与走查
静态测试一般能解决80%的软件错误
动态测试
技术有黑盒测试、白盒测试
黑盒测试
优点：
有针对性地找问题，并且定位问题更准确；
黑盒测试可以证明产品是否达到用户要求的功能，是否符合用户的工作要求；
能重复执行相同的操作，测试中最枯燥的部分可由自动化完成
缺点：
需要充分了解产品用到的技术，测试人员需要具有较多的经验；
在测试过程中很多是手工操作；
测试人员需要负责大量的文档：
等价类划分
有效等价类：输入的是有效的数值
无效等价类：输入的是非法的数值
边值分析法
软件测试所包含的边界条件：数字、字符、位置、质量、大小、速度、方位、尺寸、空间
对应的边界值：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满
错误推测法
列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图法
一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
决策表
分析和表达多逻辑条件下执行不同操作的情况的工具。在所有的黑盒测试方法中，基于决策表（也称为判定表）的测试是最为严格、最具有逻辑性的测试方法。
黑盒测试选择
在任何情况下都必须选择边界值分析方法
必要时用等价类划分法补充一些测试用例
用错误推测法再追加一些测试用例
如果程序的功能说明中含有输入条件的组合情况，则可选用因果图法和决策表法
白盒测试
代码检查法
代码检查法包括桌面检查、代码审查和走查。
代码检查应该在编译和动态测试之前进行。
代码检查法可以使用测试软件进行自动化测试或人工测试 。
静态结构分析法
以图的形式表现程序的内部结构
对代码机械性的、程式化的特性进行分析
程序插桩技术
向源程序中添加一些语句，实现对程序语句的执行、变量的变化等情况进行检查。
逻辑覆盖法
语句覆盖
又称行覆盖，段覆盖，基本块覆盖，这是最常用也是最常见的一种覆盖方式，就是根据每个执行语句是否被执行，即要求设计若干个测试用例，使得程序中每个语句都能被执行了并且被测试了。
判定覆盖
判定覆盖又叫做分支覆盖，是设计足够多的测试用例，使得程序中的每一个判断至少获得一次“真”和一次“假”，即使得程序流程图中的每一个真假分支至少被执行一次。分支（判定）覆盖具有比语句覆盖更强的测试能力。
条件覆盖
条件覆盖就是设计若干个测试用例，运行被测程序使得程序中每个判断的每个条件的可能取值至少执行一次。条件覆盖并不比判定覆盖强，两者关注点不同。
条件判定覆盖
条件/判定组合覆盖是通过设计足够多的测试用例，使得运行这些测试用例后，要使每个判断中每个条件的可能取值至少满足一次（一次真，一次假），也使得程序中的每一个判断至少获得一次“真”和一次“假”。条件/判定组合覆盖的测试用例一定也符合条件覆盖和判定覆盖。
条件组合覆盖
每个判定的所有可能的条件取值都至少出现一次。
路径覆盖
每一条可能的路径都被走过
基本路径法
独立路径
环路复杂度
计算方法
①流图中区域的数量对应于环路的复杂度
②给定流图G的环路复杂度V(G)，定义为V(G)=E-N+2，其中E是流图中边的数量，N是流图中结点的数量
③给定流图G的环路复杂度V(G)，定义为V(G)=P+1，其中P是流图G中判定结点的数量
软件测试的一般步骤
单元测试：着重测试每个单独的模块，以确保它作为一个单元来说功能是正确的
集成测试：把模块装配（即集成）在一起形成完整的软件包，在装配的同时进行测试
确认测试：测试在需求分析阶段确定下来的确认标准
系统测试：验证所有系统元素是否都能正常配合
单元测试
定义：单元测试又称模块测试，是针对软件设计的最小单位-----程序模块，进行正确性检验的测试工作。
内容：侧重于模块的内部处理逻辑和数据结构。
方法：在进行单元测试时，被测试的单元本身不是独立的程序，需要为其开发驱动模块（也称驱动程序）和桩模块（也称存根程序）。 驱动模块是用来模拟待测试模块的上级模块。
桩模块是用来模拟待测模块工作过程中所调用的模块。
集成测试
定义：集成测试是对软件系统进行测试，主要用来揭露设计阶段产生的错误。它就是把模块按照设计要求组装起来的同时进行测试，主要目标是发现与接口有关的问题。
分析：集成测试分析直接指导集成测试用例的设计，在整个集成测试过程中占据最关键的地位。
集成测试策略 模块组装成软件系统的两种方法：
1、非增量式集成：先分别测试每个模块，再将所有模块按照设计要求放在一起结合成所要的程序。
采用一步到位的方法进行测试。先将单元测试的所有模块集合到一起，然后将整个程序作为一个整体进行测试，运行这种方式构造的程序，通常会遇到许多错误，而且很难确定错误的位置，错误的维护也十分困难，常常在改正一个错误的同时，又引入一个新的错误。所以新旧错误混杂在一起很难定位。
2、增量式集成：将下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完后再将下一个应测试的模块结合起来进行测试 。
自顶向下增量式集成测试
Stepl：以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代
Step2：依据所选的集成策略(深度优先或广度优先)每次只替代一个桩模块;
Step3：每集成一个模块立即测试一遍;
Step4：只有每组测试完成后，才着手替换下一个桩模块;
优点：①可以及早地发现和修复模块结构图中主要控制点存在的问题
②能较早地验证功能的可行性
③最多只需要一个驱动模块
缺点：需要开发和维护大量的桩模块。
自底向上增量式集成测试
测试步骤:
1、为最底层模块开发驱动模块，对最底层模块进行并行测试
2、用实际模块替换驱动模块，与其已被测试过的直属子模块集成为一个子系统
3、为新形成的子系统开发驱动模块，对该子系统进行测试
4、若该子系统已对应为主控模块，即最高层模块，则结束集成，否则转到步骤2)
优点 ：①、大大减少了桩模块的开发
②先对底层模块进行测试，减少了回归测试成本
③在集成的早期实现对底层模块的并行测试
缺点：①需要大量的驱动模块
②主要控制点存在的问题要到集成后期才能修复，需要花费较大成本
三明治集成测试
将自顶向下测试与自底向上测试两种模式有机结合起来，采用并行的自顶向下、自底向上集成方式形成。
确认测试
定义：又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
1、通过检验和提供客观证据，验证软件是否满足特定预期用途的需求
2、依据软件需求规格说明书
3、确认测试主要是验证软件是否在“做正确的事”
系统测试
定义：系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
目的：在于通过与系统的需求定义做比较，发现软件与系统的定义不符合或者与之矛盾的地方。
测试范围可分为
测试范围可分为功能测试、性能测试、压力测试、容量测试、安全性测试、图形用户界面测试、可用性测试、安装测试、配置测试、异常测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试。
准备工作
收集各种软件说明书，作为系统测试的参考
仔细阅读软件测试计划，最好制定单独的系统测试计划，作为系统测试的根据，并收集已编好的测试用例
如果没有现成的系统测试用例，则需要做大量工作来编写测试用例
功能测试
不管软件内部是如何实现的，只是根据需求规格说明书和测试需求列表，验证产品的功能是否符合需求规格。
主要检验以下几个方面：
①功能是否全部实现，有没有遗漏
②功能是否满足用户需求和系统设计的隐藏需求
③能否正确地接受输入，并给出正确结果
性能测试
测试软件系统在实际的集成系统中运行性能。
性能测试的目的是度量系统相对于预定义目标的差距。
性能测试一般要有专门的工具支持，必要情况下，还要自己开发专门的接口工具。
可能要考虑的方面
系统反应时间
系统吞吐量
CPU时间片使用情况
缓存使用情况
内存使用情况
I/O使用情况
安全测试
目的：是验证系统的保护机制是否能够在实际的环境中抵御非法入侵，恶意攻击等非法行为。
测试人员常常扮演系统攻击者的角色，然后尝试各种方案入侵系统
系统设计者的目的是要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息价值
安全测试机制的性能和安全机制本身一样重要
GUI测试
GUI 测试包含两方面内容：一是界面实现与界面设计是否吻合；二是界面功能是否正确。
验收测试
验收测试是以用户为主的测试。由用户参加设计测试用例，使用生产中的实际数据进行测试
在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
在软件系统测试结束以及软件配置审查之后开始，应由用户、测试人员、软件开发人员和质量保证人员一起参与，目的是确保软件准备就绪
应交付的文档有
确认测试分析报告
最终的用户手册和操作手册
项目开发总结报告。
内容：验收测试主要包括配置复审、合法性检查、文档检查、软件一致性检查、软件功能和性能测试与测试结果评审。
1、配置复审
保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。
2、合法性检查
检查开发者在开发软件时使用的开发工具是否合法。
3、软件文档检查
文档应该满足完备性、正确性、简明性、可追踪性、自说明性、规范性等要求。
4、软件代码测试
包括源代码的一般性检查和软件一致性检查两方面的内容。
5、软件功能和性能测试
不仅是检测软件的整体行为表现，也是对软件开发和设计的再确认。
6、测试结果交付内容
测试结束后，由测试组写软件测试报告，并将测试报告与全部测试材料一并交给用户代表。
α测试
由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
β测试
由软件的最终用户在一个或多个客户场所进行。 这些用户返回有关错误给开发者。
测试时，开发者通常不在测试现场，因而β测试是在开发者无法控制的环境下进行的软件现场应用。
回归测试
定义：指软件系统被修改或扩充后重新进行的测试，以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
软件调试
调试
调试活动由两部分组成：①确定程序中可疑错误的确切性质和位置。②对程序(设计、编码)进行修改，排除这个错误
调试是在测试发现错误之后排除错误的过程。 调试途径：①蛮干法 ②回溯法③原因排除法（对分查找法、归纳法、演绎法）
调试过程的结果：
找到了问题的原因并把问题改正和排除掉了
没找出问题的原因
软件维护
什么是软件维护？
在软件产品交付给用户之后，为了改正软件测试阶段未发现的缺陷，改进软件产品的性能，补充软件产品的新功能等，所进行的修改软件的过程。
软件维护的过程
1、建立维护机构
2、用户提出维护申请并提交维护申请报告
3、维护人员确认维护类型并实施相应的维护工作
4、整理维护记录并对维护工作进行评审
5、对维护工作进行评价
软件维护分类
纠错性维护：为了识别并纠正软件产品中所潜藏的错误，改正软件性能上的缺陷所进行的维护
适应性维护：为了使软件产品适应软硬件环境的变更而进行的维护
完善性维护：软件维护的主要部分，针对用户对软件产品所提出的新需求所进行的维护
预防性维护：为以后进一步维护软件打下了良好的基础
影响软件可维护性的因素
可理解性
可测试
可修改性
软件维护的副作用主要有3类
修改代码的副作用：每次对代码的修改都有可能产生新的错误
修改数据的副作用：数据结构被改动时有新的错误产生的现象
修改文档的副作用：在软件产品的内容更改之后没有对文档进行相应的更新而为以后的工作带来不便的情况
查看更多
相似思维导图模版
首页
我的文件
我的团队
个人中心