第一篇：软件安全知识范文
软件工程考核知识点-第8章-软件维护
第8章 软件维护
软件投入使用后就进入软件维护阶段。维护阶段是软件生存周期中时间最长的一个阶段，所花费的精力和费用也是最多的一个阶段。 8.1软件维护的内容
软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。
1.校正性维护
在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现，因此必然有一部分隐含的错误被带到维护阶段来。这些隐含的错误在某些特定的使用环境下会暴露出来。为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。校正性维护占整个维护工作的20%左右。
2.适应性维护
随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也在不断发生变化。为了使应用软件适应这种而修改软件的过程称为适应性维护。这种维护活动占整个维护活动的25%。
3.完善性维护
在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。这是因为用户的业务会发生变化，组织机构也会发生变化。为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的50%。
4.预防性维护
为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。这是为以后进一步的运行和维护打好基础，占整个维护工作的4%。 8.2 维护的特点
8.2.1非结构化维护和结构化维护
软件的开发过程对软件的维护过程有较大的影响。若不采用软件过程的方法开发软件，则软件只有程序而无文档，维护工作非常难，这就是一种非结构化的维护。若采用软件工程的方法开发软件，则各阶段都有相应的文档，这容易进行维护工作，这是一种结构化的维护。 1.非结构化维护
因为只有源程序，而文档很少或没有文档，维护活动只能从阅读、理解、分析源程序开始。这是软件工程时代以前进行维护的情况。 2.结构化维护
用软件工程思想开发的软件具有各阶段的文档，这对于理解和掌握软件功能、性能、系统结构、数据结构、系统接口和设计约束有很大作用。这种维护对减少精力、减少花费、提高软件维护效率有很大的作用。 8.2.2维护的困难性
软件维护的困难性是由于软件需求分析和开发方法的缺陷。软件生存周期中的开发阶段没有严格而又科学的管理和规划，就会引起软件运行时的维护困难。表现在以下几个方面： 1.读懂别人的程序是困难的。 2.文档的不一致性。
由于开发过程中文档管理不严所造成的，在开发过程中经常会出现修改程序却遗忘了修改与其相关的文档，使得文档前后不一致。 3.软件开发和软件维护在人员和时间上的差异
由于维护阶段持续时间很长，正在运行的软件可能是十几、二十年前开发的，开发工具、方法、技术与当前的工具、方法、技术差异很大，这又是维护困难的另一因素。 4.软件维护不是一项吸引人的事
由于维护工作的困难性，维护工作经常遭受挫折，而且很难出成果，不像软件开发工作那样吸引人。
8.2.3软件维护的费用
软件维护的费用在总费用中的比重是不断增加的。七十年代占35%~40%，八十年代上升到40%~60%，九十年代上升到70%~80%。软件维护费用不断上升，这只是软件维护有形的代价，无形的代价是要占用更多的资源，并在维护时对软件的改动，引入了潜在的故障，从而降低了软件的质量。用于软件维护工作的活动可分为生产性活动和非生产性活动两种。生产性活动包括分析评价、修改设计和编写程序代码等。非生产性活动包括理解程序代码功能、解释数据结构接口特点和设计约束。
维护活动总的工作两由下式表示：M=P+K×exp(C-D)
其中：M表示维护工作的总工作量;
P表示生产性活动工作量;
K表示经验常数;
C表示复杂性程度;
D表示维护人员对软件的熟悉程度;
上式表明，若C越大，D越小，那么维护工作量将成指数增加;C增加表示软件因未用软件工程方法开发，从而使得软件为非结构化设计，文档缺少，程序复杂性高。D表示维护人员不是原来的开发人员，对软件熟悉程度低，重新理解软件花费很多时间。 8.3维护任务的实施 8.3.1维护的组织
为了有效地进行软件维护，应事先开始组织工作，建立维护机构。这种维护机构通常以维护小组形式出现。维护小组分为临时维护小组和长期维护小组。 8.3.2维护的流程
软件维护的流程如下：
(1)制定维护申请报告。
(2)审查申请报告并批准。
(3)进行维护并做详细记录。
(4)复审。 1.制定维护申请报告
所有软件维护申请报告应按照规定的方式提出。该报告也称为软件问题报告。它是维护阶段的一种文档，由申请维护的用户填写。维护申请报告是一种由用户产生的文档，在软件维护组织内部还要制定一份软件修改报告，该报告是维护阶段的另一种文档。
提出维护申请报告之后，由维护机构来评审维护请求。评审工作很重要，通过评审回答要不要维护，从而可以避免盲目的维护。 2.维护过程
一个维护申请提出之后，经评审需要维护则按下列过程实施维护：
(1)首先确定要进行维护的类型。
(2)对校正性维护从评价错误的严重性开始。
(3)对适应性维护和完善性维护。
(4)实施维护任务。不管维护类型如何，大体上要开展相同的技术工作。这些工作包括修改软件设计、必要的代码修改、单元测试、集成测试、确认测试以及复审。每种维护类型的侧重点不一样。
(5)“救火”维护。在发生重大问题时，需要立即解决的问题。
3.维护的复审
在维护任务完成后，要对维护任务进行复审。 8.3.3维护技术
有两类维护技术，它们是面向维护的技术和维护支援技术。
1.面向维护的技术
面向维护的技术涉及软件开发的所有阶段。
2.维护支援技术
维护支援技术包括下列方面的技术：
.信息收集;
.错误原因分析;
.维护方案评价;
.软件分析与理解;
.代码与文档修改;
.修改后的确认;
.远距离的维护; 8.3.4维护的副作用 维护的目的是为了延长软件的寿命并让创造更多的价值，经过一段时间的维护，软件中的错误减少了，功能增强了。但修改软件会造成软件的错误，这种因修改软件而造成的错误或其他不希望出现的情况称为维护的副作用。
维护的副作用有编码副作用、数据副作用、文档副作用三种。
1.编码副作用
在使用程序设计语言修改源代码时可能引入错误。
2.数据副作用
在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件错误。
3.文档副作用
对数据流、软件结构、模块逻辑或任何其他有关特性进行修改时，必须对相关技术文档进行相应修改，否则会导致文档与程序功能不匹配、缺省条件改变、新错误信息不正确等错误，使文档不能反映软件当前的状态。
【大 中
8.4 软件可维护性
软件的维护是十分困难的，为了使软件能易于维护，必须考虑使软件具有可维护性。 8.4.1可维护性定义
软件可维护性的定义：软件能够被理解、校正、适应及增强功能的容易程度。
软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性，也是用户十分关心的几个问题。
软件的可维护性是软件开发阶段的关键目标。影响软件可维护性的因素较多，设计、编码及测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。软件可维护性可用下面七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。对于不同类型的维护,这七种特性的侧重点也是不相同。 8.4.2可维护性的度量
目前有若干对软件可维护性进行综合度量的方法，但要对可维护性作出定量度量还是困难的。还没有一种方法能够使用计算机对软件的可维护性进行综合性的定量评价。
下面是度量一个可维护的软件的七种特性时常采用的方法，即质量检查表、质量测试、质量标准。
质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。
质量测试与质量标准则用于定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准去度量不同的质量特性。 8.4.3提高可维护性的方法
从下面五个方面来阐述如何提高软件的可维护性：
1.建立明确的软件质量目标
如果要程序满足可维护性七个特性的全部要求，那么要付出很大的代价，甚至是不现实的，但有些可维护性是相互促进的，因此要明确软件所追求的质量目标。
2.使用先进的软件开发技术和工具 利用先进的软件开发技术能大大提高软件质量和减少软件费用。面向对象的软件开发方法就是一个非常实用而强有力的软件开发方法，用面向对象方法开发出来的软件系统，稳定性好，比较容易修改，比较容易理解，易于测试和调试，因此，可维护性好。
3.建立明确的质量保证
质量保证是指为提高软件质量所做的各种检查工作。质量保证检查是非常有效的方法，不仅在软件开发的各阶段中得到了广泛应用，而且在软件维护中也是一个非常主要的工具。为了保证可维护性，以下四类检查是非常有用的：
(1)在检查点进行检查。
(2)验收检查。
(3)周期性的维护检查。 (4)对软件包的检查。
4.选择可维护的语言
程序设计语言的选择对维护影响很大。低级语言很难掌握，很难理解，因而很难维护。一般来说，高级语言比低级语言更容易理解，第四代语言更容易理解，容易编程，程序容易修改，改进了可维护性。
5.改进程序的文档
程序文档是对程序功能、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。程序文档对提高程序的可阅读性有重要作用。为了维护程序，人们必须阅读和理解程序文档。
一、名词解释
1.校正性维护
2.适应性维护 3.完善性维护
4.预防性维护
5.软件可维护性 6.软件维护的副作用
二、填空题
1.维护阶段是软件生存周期中时间最长的阶段，也是花费精力和费用________的阶段。 2.在软件交付使用后，由于在软件开发过程中产生的错误没有完全彻底在开发阶段发现，必然有一部分隐含错误带到_________阶段。
3.采用手工方法开发软件只有程序而无文档，维护困难，这是一种___________维护。 4.软件维护费用增加的主要原因是维护的_________非常低。 5.软件维护工作的活动分为生产性活动和__________活动。
6.所有软件维护申请报告要按规定方式提出，该报告也称_________报告。
7.有两类维护技术：在开发阶段使用来减少错误，提高软件可维护性的面向维护技术;在维护阶段用来提高维护的效率和质量的_______技术。
三、选择题
1.在生存周期中，时间长、费用高、困难大的阶段是( )。 A.需求分析 B.编码 C.测试 D.维护 2.为适应软硬件环境变化而修改软件的过程是( )。
A.校正性维护 B.适应性维护 C.完善性维护 D.预防性维护 3.软件维护困难的主要原因是( )。
A.费用低 B.人员少 C.开发方法的缺陷 D.维护难 4.软件维护费用高的主要原因是( )。
A.生产率高 B.生产率低 C.人员多 D.人员少 5.维护阶段的文档是( )。
A.软件需求说明 B.操作手册 C.软件问题报告 D.测试分析报告 6.产生软件维护的副作用，是指( )。
A.开发时的错误 B.隐含的错误 C.因修改软件而造成的错误 D.运行时误操作 7.维护中，因误删除一个标识符而引起的错误是( )副作用。 A.文档 B.数据 C.编码 D.设计 8.可维护性的特性中相互促进的是( )。
A.可理解性和可测试性 B.效率和可移植性 C.效率和可修改性 D.效率和结构好 9.可维护性的特性中，相互矛盾的是( )。
A.可修改性和可理解性
B.可测试性和可理解性 C.效率和可修改性 D.可理解性和可读性
四、简答题
1.软件维护有哪些类型? 2.软件维护的特点是什么? 3.软件维护的流程是什么? 4.软维护的副作用有哪些?
5.可维护性度量的质量特性有哪些? 6.提高可维护性有哪些方法? 参考答案
二、填空题
1.最多 2.维护 3.非结构化 4.生产率 5.非生产性 6.软件问题 7.维护支援
三、选择题
1.D 2.B 3.C 4.B 5.C 6.C 7.C 8.A 9.C
第二篇：软件工程知识点
1．什么是软件危机，它有哪些典型表现？答：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。
软件危机典型表现：对软件开发成本和进度的估计常常很不准确。用户对“已完成的”软件系统不满意的现象经常发生。软件产品的质量往往靠不住。软件常常是不可维护的。软件通常没有适当的文档资料。软件成本在计算机系统总成本中所占的比例逐年上升。软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势.
产生软件危机的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。管理和控制软件开发过程相当困难。软件是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。目前相当多的软件专业人员对软件开发和维护还有不省糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这是使软件问题发展成软件危机的主要原因.
2.简述产生软件危机的原因和解决的思路:答：软件危机产生的原因一方面与软件本身的特点有关，另一方面，是与已有软件开发、维护的方法不正确有密切关系.
解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。即采用工程化的原则和方法组织软件开发是摆脱软件危机的一个主要出路.
3.什么是软件工程？它有哪些本质特性?答：软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它. 软件工程本质特性：
1、软件工程关注于大型程序的构造；
2、软件工程的中心课题是控制复杂性；
3、软件经常变化；
4、开发软件的效率非常重要；
5、和谐地合作是开发软件的关键；
6、软件必须有效地支持它的用户；
7、在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品.
4.软件工程是如何用来消除软件危机的？软件工程是从技术和管理两个方面来研究如何更好地开发和维护计算机软件，从源头上消除软件危机. 5.软件工程的目的是什么？为高质量的软件开发提供一个科学的体系框架.
6.什么是软件工程方法学？软件工程是一种什么样的技术？包括哪三大要素？分为哪三个分支？软件工程方法学就是指在软件生命周期全过程中使用的一整套管理和开发技术方法的集合。目前，使用最广泛的软件工程方法学分别是传统方法学和面向对象方法学.
软件工程作为一种层次化的技术，有方法、工具和过程三大要素，并由于其涉及学科内容的极为广泛，而分为三个分支：软件开发技术、软件项目管理技术、软件质量管理技术.
7.什么是软件生命周期？什么是软件生命周期模型？软件如同自然界任何事物一样，都有其孕育、诞生、成长、成熟、衰亡的生存过程。软件的这一过程，称为软件生命周期.
软件生命周期模型也称软件开发过程模型，是为了解决产业环境中的实际问题，而提出的开发策略。是反映整个软件生命期中，系统开发、运行、维护等实施活动的一种结构框架.
8.试比较瀑布模型、快速原型模型、增量模型和螺旋模型的优缺点，说明它们各自的适用范围.1．瀑布模型:瀑布模型广为人知和历史悠久，其优势是规范及文档驱动的方法。但问题是，往往不能够真正满足用户的需求..适用于传统软件工程领域的结构化开发..2．原型模型:是为了克服瀑布模型的缺点而提出来的。通过快速构建一个在机器上可运行的原型系统，让用户试用原型，并收集反馈意见的办法，来获取用户真实的需求..3．螺旋模型:螺旋模型适用于大型软件项目，比起之前的其它模型而言，有其一定的优越性，但这些优越性并不是绝对的。主要体现在对开发人员的风险评估经验和专门知识的要求较高。如果项目风险较大，而开发人员的水平较低，不能准确的识别和分析风险，则势必造成重大损失..4．增量模型:具有在软件开发早期阶段使投资获得明显回报和交易维护的优点，但是要求软件具有开放的结构.
9. 软件过程(Software Procedure)是指软件生存周期所涉及的一系列相关过程.
10.软件测试用例就是指导你对软件执行操作，帮助你证明软件功能或发现软件缺陷的一种说明. 11.单元测试——是最小粒度的测试，以测试某个功能或代码块.单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试.
12.人机界面设计的三条“黄金规则”:1.置用户于控制之下.2.减少用户记忆负担.3.保持界面一致. 13.jackson图:jackson结构化程序设计使用的图。什么是HIPO图：它是表示软件系统结构的工具。HIPO图以模块分解的层次性以及模块内部输入、处理、输出三大基本部分为基础建立的.它既可以描述软件总的模块层次结构--H图(层次图)，又可以描述每个模块输入/输出数据、处理功能及模块调用的详细情况--IPO图.
14.试说明Jackson方法是一种怎么样的程序设计方法。它有哪些工作步骤:Jackson方法是以数据结构(data structure)为基础设计每个模块的处理过程，将数据结构转化成程序结构。具体工作步骤有：第1步：用Jackson图描述 IO 的数据结构;第2步：在两个图中指出有直接因果关系、可以同时处理的单元;第3步：将数据结构映射到程序结构;第4步：列出所有操作条件，并分配到上幅程序结构图中;第5步：用Pseudocode 表示程序.
15.简述结构化设计的特点:1.自顶向下、逐步求精.2.具有单入、单出的控制结构.
第三篇：软件工程知识点总结
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。是一门指导软件系统开发的工程学科，它以计算机理论及其他学科为指导，采用工程化的概念、原理、技术和方法进行软件的开发和维护，把经实践证明的学科的管理措施与最先进的技术方法结合起来，目标是以较少的投资获取高质量的软件。 内容：方法与技术、工具与环境、管理技术、标准与规范。 领域：软件需求分析、软件设计、软件构造、测试和维护。 难题 1.复杂性 2.不可见性 3.易变性 4.服从性 5.非连续性
计算机科学中与实践相关的部分，都和数据以及其他学科发生关系。软件工程和人的行为、现实社会的需求息息相关。
发展史：1.生产作坊方式2.面向对象的方法3.软件过程工程4.软件复用和基于构件的开发 学生做到：1.研发出符合客户需求的软件 2.通过一定的软件流程，在预计的时间内发布足够好的软件 3.通过数据和其他方式展现所开发的软件是可以维护和继续发展。
单元测试(好标准)：1.在最基本的功能/参数上验证程序正确性;2.由最熟悉代码的人写;3.测试后，机器状态保持不变;4.要快;5.产生可重复、一致的结果;6.独立性;7.覆盖所有代码路径;8.集成到自动测试的框架中;9.和产品代码一起保存和维护。
回归测试：模块出现退步，从正常退化到不正常状态，为了验证新改进的代码的正确性。 个人开发：计划：估计时间(开发)：.需求分析.生成设计文档.设计复审.代码规范.具体设计.具体编码.代码复审.测试;记录用时;测试报告;计算工作量;事后总结;提出改进计划 个人在团队中：1.通过交流实验等方法理解问题、需求或任务2.提出多种解决办法3.与相关角色交流解决问题的提案，决定一个可行方案4.执行5.和其他角色合作，测试实现方案，修复缺陷6.对结果负责
代码规范：代码风格规范：1.缩进2.行宽3.括号4.断行与空白行5.分行6.命名7.下划线8.大小写9.注释
代码设计规范：1.函数2.goto3.错误处理4.处理C++中的类 代码复审目的：1.找出错误代码2.发现逻辑错误3.发现算法错误4.发现潜在错误5.发现可能需要改进的地方6.传授经验
代码复审步骤：1.代码成功编译2.程序员必须测试过代码3.程序与提出新的代码，差异分析4.可选择面对面复审，独立复审5.面对面复审中，开发者控制流程，讲述修改的前因后果，复审者有权打断叙述提出自己意见7.开发者负责所有问题得到满意解答8.达成一致意见 复审后：1.改正明显的错误2.对无法解决的错误，记录下来3.把所有错误记在“我常犯的错误”表中，作为以后自我复审的第一步
结对编程好处：1.在开发层次，提供更好的设计质量和代码质量，解决问题能力强2.对开发人员，结对更有信心3.在企业管理层上，更有效的交流相互学习传递经验，高投入产出比 如何结对编程：1.驾驶员：写设计文档，进行编码和单元测试2.领航员：审阅文档、编码;考虑单元测试的覆盖率;思考是否需要重构;帮解决技术问题3.不断轮换角色，不连续一小时，领航员控制时间4.主动参与5.只有水平差距，没有级别差距6.设置好结对编程环境 团队模式：1.主治医师2.明星3.社区4.业余剧团5.秘密团队6.特工7.交响乐团8.爵士乐 开发方法： 统一流程(RUP)业务建模.需求.分析和设计.实现.测试.部署.配置和变更管理.项目管理.环境. 敏捷开发原则：1.尽早并持续交付有价值的软件满足需求2.欢迎需求的变化3.经常发布可用软件，间隔较短4.业务员与开发人员共同工作5.以有进取心的人为核心6.面对面交流7.可用软件是衡量项目进展的主要指标8.可持续发展9.不断关注技术和设计10.保持简明 敏捷流程：1.找出完成产品所需要做的事2.决定当前冲刺需要解决的事3.冲刺 软件需求：1.获取和引导需求2.分析和定义需求3.验证需求4.在软件产品的生命周期中管理需求(功能性需求.开发过程需求.非功能性需求.综合需求) 需求获取方法：用户调查1.焦点小组2.深入面谈3.卡片分类4.调查问卷5.用户日志研究6.人类学调查7.眼动跟踪研究8.快速原型调研9.a/b测试
利益相关者：用户：直接使用软件的人;客户：购买软件的人;市场分析师：代表典型用户的需求;监管机构：符合行业和政策规定;软件工程师：需求阶段重要角色
项目经理PM：对项目流程负责，正确的协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目按计划结项。管事也管人，不一定做具体工作。 应对风险：1.进一步研究2.接受3.规避4.转移5.降低6.制定应急计划
PM能力：1.观察、理解和快速学习2.分析管理能力3.专业能力4.自省能力
典型用户：名字.年龄.收入.代表的用户在市场上的比例和重要性.典型场景.环境.生活情况.知识层次/能力.偏好
功能说明书 1.定义好相关概念2.规范好一些假设3.避免误解，界定边界条件4.描述主流用户5.一些好的功能会有副作用6.服务质量说明 功能驱动设计：1.构造总体模型2.构造功能列表3.制定开发计划4.功能设计阶段5.实现具体功能
用户体验：1.用户第一印象2.从用户角度考虑问题3.软件服务始终要记住用户的选择4.短期刺激和长期影响5.不让用户犯简单错误6.用户体验和质量7.情感设计 评价标准：1.尽快提供可感触的反馈2.系统界面符合用户的现实惯例3.用户有控制权4.一致性和标准化5.适合各种类型的用户6.帮助用户识别、诊断并修复错误7.有提示和帮助文档 测试方法：1.单元测试2.代码覆盖率测试3.构建验证测试4.验收测试5.探索式测试6.回归测试7.场景/集成/系统测试8.伙伴测试9.效能测试10.压力测试11.内/外部公开测试
黑箱：把软件系统当作一个黑箱，无法了解或使用系统的内部结构及知识。从软件的行为而不是从内部结构出发来设计测试。 白箱：设计者可以看到软件系统的内部结构，并使用软件的内部结构和知识来选择测试数据及具体的测试方法。
软件质量：1.程序的质量2.软件工程的质量(开发过程可见性、风险控制、软件内部模块、开发成本控制、内部质量指标完成情况)
如何衡量：CMMI理论：一级初始级(企业项目目标实现)，二级管理级(对项目流程审查，保证成功)，三明确级(对管理体系制度化保障完成)，四量化管理级(数字化管理，流程的稳定性)，五级优化级(充分利用信息资料，主动改善流程)
如何衡量：1.软件CC后DCR的数量2.用户的好评3.在CC后发现bug的数量4.文档完整性和准确性5.修复bug平均时间6.单位开发量出现最大bug数量7.测试用例的覆盖率8.模块的复杂程度9.代码的行数10.文档的数量和复杂程度11.有多少代码重复12.平均每天构建失败的次数13.实现了多少功能点14.软件能运行多久，平均初次错误时间，无故障时间 会诊：1.开发者提交参加会诊的bug和修改方案2.会议决定是否同意修改方案3.执行
IT创新：1.灵光一闪，创新及随其后2.大家都喜欢创新3.好的想法会赢4.创新者都是一马当先5.要成为领域的专家6.技术是创新的关键7.成功的团队更能创新
团队合作阶段：1.萌芽阶段2.磨合阶段3.规范阶段4.创造阶段5.团队的效能曲线和假团队 职业道德：1.行为与公众利益一致2.以客户和雇主利益最大化的方式做事3.确保自己的产品以及修改满足专业标准4.具备完整独立的专业判断5.软件项目的经理和领导人应提倡并亲自采用复合道德规范的方法来管理软件的开发和维护6.保证职业的诚信和荣誉7.公平对待同侪，并予以支持和帮助。
需求分析：四方面：对问题的识别、分析与综合、制定规格说明书、评审;三原则：必须能够表达和理解问题的数据域和功能域;必须按自顶向下、逐步分解的方式对问题进行分解和不断细化;要给出系统的逻辑视图和物理视图。
第四篇：软件工程知识点总结
7.1软件的定义及特点
软件( Software)是计算机系统中与硬件相互依存的另一部分，它是包括程序(Program) ，数据(Data)及其相关文档( Document)的完整集合。
三个特点：
(1)软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性; (2)软件的生产与硬件不同，在它的开发过程中没有明显的制造过程; (3)在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。
7.2软件危机及其表现
软件危机(softward crisis)是指在计算机软件的开发和维护中所遇到的一系列严重问题。这些问题绝不仅仅是“不能正常运行的”软件才具有，实际上几乎所有软件都不同程度地存在这些问题。
具体地说，软件危机主要有下述一些表现。
(1)对软件开发成本和进度的估计常常很不准确。
(2)用户对“已完成的”软件系统不满意的现象经常发生。
(3)软件产品的质量往往靠不住。
(4)软件常常是不可维护的。
(5)软件通常没有适当的文档资料。
(6)软件成本在计算机系统总成本中所占的比例逐年上升。
7.3软件工程及三要素
软件工程：软件工程是采用工程的概念、原理、技术和方法来指导软件开发和维护的工程学科，以工程化的原理和方法来解决软件问题。
软件工程的特性：
(1) 软件工程关注于大型程序的构造 (2) 软件工程的中心课题是控制复杂性 (3) 软件经常变化
(4) 开发软件的效率非常重要 (5) 和谐地合作是开发软件的关键 (6) 软件必须有效地支持它的用户
(7) 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人
软件工程方法学包含3个要素：方法、工具和过程。
7.4软件生命周期
软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和 测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审 查、形成文档以供交流或备查，以提高软件的质量。
每个阶段的任务如下
问题定义阶段：该阶段的关键任务是要明确：要解决的问题是什么? 可性行研究阶段：该阶段的关键任务是要明确：做不做? 需求分析阶段：该阶段的关键任务是要明确：做什么?
概要设计(总体设计)阶段：该阶段的关键任务是要明确：怎么做? 详细设计阶段：该阶段的关键任务是要明确：具体做法。
编码和单元测试阶段：该阶段的关键任务是：编码和单元测试。
综合测试阶段：该阶段的关键任务是通过各种类型的测试(及调试)使软件达到预定的要求。 软件维护阶段：该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的要求。
7.4.1瀑布模型
瀑布模型有以下优点
1)为项目提供了按阶段划分的检查点。
2)当前一阶段完成后，您只需要去关注后续阶段。 3)可在迭代模型中应用瀑布模型。
4)它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
瀑布模型有以下缺点
1)各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2)由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 4)瀑布模型的突出缺点是不适应用户需求的变化。
“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行，用户常常难以清楚地给出所有需求，用户必须有耐心，等到系统开发完成。
7.4.2 原型模型—快速原型模型
在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型(可运行的软件)，然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。 优点：
(1)开发人员和用户在“原型”上达成一致。这样一来，可以减少设计中的错误和开发中的风险，也减少了对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 (2)缩短了开发周期，加快了工程进度。 (3)降低成本。
尽早发现需求，揭示风险 缺点：
⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。
⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。
⑶开发过程不便于管理。
7.4.3螺旋模型
螺旋模型的优点： (1)对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
(2)减少了过多测试或测试不足 (3)维护和开发之间并没有本质区别 螺旋模型的缺点：
(1)风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大
(2)主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险
(3)随着迭代次数的增加，工作量加大，软件开发成本增加
7.4.4增量模型
增量模型优点：
(1)在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。
(2)整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。 (3)逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。 (4)采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。 增量模型的缺点：
(1)在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。
(2)开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。 (3)多个构件并行开发，具有无法集成的风险。
7.4.5喷泉模型
主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征。 喷泉模型的优点
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
喷泉模型的缺点
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
其特点如下：
(1)开发过程有分析、系统设计、软件设计和实现4个阶段。 (2)各阶段相互重叠，它反映了软件过程并行性的特点。 (3)以分析为基础，资源消耗成塔型。
(4)反映了软件过程迭代性的自然特性，从高层返回低层无资源消耗。 (5)强调增量开发，整个过程是一个迭代的逐步提炼的过程。
7.4.6构件组装模型
构件组装模型导致软件复用，而可复用性给软件工程师提供了大量的可见的益处。软件开发不
用一切从零开始，开发过程就是一个组装构件的过程，维护的过程就是对构件升级、替换和扩充的过程，大大提高了软件的开发效率。构件模型允许多个项目同时开发，降低了费用，提高了可维护性。
构件模型也存在一些缺点，如：由于存在多种构件标准，缺乏通用的构件组装结构标准，如果自行定义会引入较大的风险;构件可重用性和软件系统高效性之间不易协调;如果过分依赖构件，构件质量会影响最终的产品质量。
7.4.7 RUP RUP是由Rational公司的Booch、Jacobson、Rumbaugh提出的软件过程模型，也称RUP(Rational Unified Process)。RUP重复一系列周期，每个周期由一个交付给用户的产品结束。
每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流(需求、分析、设计、实现、测试)分别迭代。 模型见下图：
1.4个阶段
初始阶段：进行问题定义，确定目标，评估其可行性，降低关键风险。 细化阶段：制定项目计划、配置各类资源、建立系统架构(包括各类视图)。 构造阶段：开发整个产品，并确保产品可移交给用户。 移交阶段：产品发布、安装、用户培训。
在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。
不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上;在构造阶段，重点转移到详细设计、实现和测试上。
2.9个工作流
RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。
商业建模：深入了解使用目标系统的机构及其商业运作，评估目标系统对使用它的机构的影响。 需求：捕获客户的需求，并且使开发人员和用户达成对需求描述的共识。 分析和设计：把需求分析的结果转化成分析模型与设计模型。 实现：把设计模型转换成实现成果。
测试：检查个子系统的交互与集成，验证所有需求是否都被正确地实现了，识别，确认缺陷并确保在软件部署之前消除缺陷。
部署：成功地生成目标系统的可运行版本，并把软件移交给最终用户。
配置和变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性。
软件项目管理：提供项目管理框架，为软件开发项目制定计划，人员配备，执行和监控等方面的实用准则，并为风险管理提供框架。
环境：向软件开发机构提供软件开发环境，包括过程管理和工具支持。
7.5 UML UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具。 UML由以下5类图来定义： 第1类：用例图
第2类：静态图(包括类图、对象图和包图) 第3类：行为图(包括状态图和活动图) 第4类：交互图(包括时序图和协作图) 第5类：实现图(包括组件图和配置图)
第一类是用例图：从用户角度描述系统功能，并指出各功能的操作者。
第二类是静态图：包括类图，对象图，包图。类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等也包括类的内部结构(类的属性和动作)。
第三类是行为图：描述系统的动态模型和组成对象之间的交互关系，其中状态图描述类的对象所有可能的状态，以及事件发生时的状态的转移条件，通常，状态图为类图的补充，在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且状态发生改变的类画状态图，活动图描述满足用例要求所要进行的活动以及活动的约束关系，有利于识别并行的活动。
第四类是交互图：描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系，他强调对象之间消息发送的顺序。
第五类是实现图：其中构建图描述代码部件的物理结构和各部件之间的依赖关系，一个部件可能是一个资源代码部件，一个二进制部件或者一个可执行部件。它包含逻辑类和实际类的有关信息。部件图有利于分析和理解部件间的相互影响程度。
下面分别描述9个图。
7.5.1 类图
类图展示了一组类、接口和协作及它们间的关系，在建模中所建立的最常见的图就是类图。用类图说明系统的静态设计视图，包含主动类的类图——专注于系统的静态进程视图。系统可有多个类图，单个类图仅表达了系统的一个方面。要在高层给出类的主要职责，在低层给出类的属性和操作。
7.5.2对象图
对象图展示了一组对象及它们间的关系。用对象图说明类图中所反应的事物实例的数据结构和静态快照。对象图表达了系统的静态设计视图或静态过程视图，除了现实和原型的方面的因素外，它与类图作用是相同的。
7.5.3用例图
用例图展现了一组用例、参与者以及它们间的关系。可以用用例图描述系统的静态使用情况。在对系统行为组织和建模方面，用例图的是相当重要的。
用例(use case)：从用户的观点对系统行为的一个描述。 用来从用户的观察角度收集系统需求。
用例图表达系统的外部事物(参与者)与系统的交互，它表达了系统的功能，即系统所提供的服务。
整个软件项目的开发可以采用Use Case 驱动的方式进行。
7.5.4交互图
交互图展现了按一定的目的进行的一种交互，它由在一个上下文中的一组对象及它们间交互的信息组成。交互图也可用于描述一个用例的行为。顺序图和协作图都是交互图，顺序图和协作图可以相互转换。
顺序图和协作图都是交互图，它们既是等价的，又是有区别的。
顺序图和协作图都能等价的表现系统运行中对象通过消息发生的交互行为。
顺序图表示了时间的消息序列，便于分析交互的时序，但没有表示静态对象关系，顺序图可以有效地帮助人们观察系统的顺序行为。
协作图着重表示一个协作中的对象之间的联系和消息。
7.5.5顺序图
展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。用顺序图说明系统的动态视图。
7.5.6协作图
展现了一组对象，这组对象间的连接以及这组对象收发的消息。它强调收发消息的对象的结构组织，按组织结构对控制流建模。
协作图显示某组对象为了由一个用例描述的一个系统事件而与另一组对象进行协
作的交互图。
协作图只对相互间有交互作用的对象和这些对象间的关系建模，而忽略了其他对象
和关联。
协作图中包括如下元素：1.对象(Object)、2.链(Link)和3.消息(Message)。
协作图的用途：
如果按组织对控制流建模，应该选择使用协作图。协作图强调交互中实例间的结构关系以及所传送的消息。协作图对复杂的迭代和分支的可视化以及对多并发控制流的可视化要比时序图好。
协作图有别于时序图的两点特性： (1)协作图有路径 (2)协作图有顺序号
7.5.7状态图
展示了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态间的转移。一个状态图描述了一个状态机，用状态图说明系统的动态视图。它对于接口、类或协作的行为建模尤为重要，可用它描述用例实例的生命周期。 在任一给定的时刻，一个对象总是处于某一特定的状态。
状态图主要表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作。
7.5.8活动图
活动图是一种特殊的状态图，描述需要做的活动、执行这些活动的顺序(多为并行的)以及工作流(完成工作所需要的步骤)。它对于系统的功能建模特别重要，强调对象间的控制流程。
活动图实质上是一种流程图，只不过表现的是从一个活动到另一个活动的控制流。活动图描述活动的序列，并且支持对带条件的行为和并发行为表达。
7.5.9时序图
在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。
顺序图表达的正是这种基于时间的动态交互。重点是完成某个行为的对象类和这些对象类之间所传递的消息的时间顺序。
7.5.10构件图
构件图展现了一组构件之间的组织和依赖，用于对原代码、可执行的发布、物理数据库和可调整的系统建模。
组件图代表系统的一个物理实现块，代表逻辑模型元素如类、接口的物理打包。
7.5.11部署图
部署图展现了对运行时处理节点以及其中构件的配署。它描述系统硬件的物理拓扑结构(包括网络布局和构件在网络上的位置)，以及在此结构上执行的软件(即运行时软构件在节点中的分布情况)。用部署图说明系统结构的静态部署视图，即说明分布、交付和安装的物理系统
7.5.12区别
1.以描述系统状态转移为主的状态图和活动图
状态图：用来描述对象，子系统，系统的生命周期。通过状态图可以了解一个对象所能达到的所有状态，以及对象收到的事件对对象状态的影响。
活动图：显示动作及其结果。着重描述操作(方法)实现中所完成的工作以及用例实例或对象中的活动，它是状态图的一个变种。
状态图与活动图的区别：活动图主要描述动作及对象状态改变的结果。状态图主要描述的是事件对对象状态的影响。
2.以描述系统系统对象通讯和交互为主的协作图和序列图
序列图：描述对象是如何交互的。重点放在消息序列上，描述消息在对象间是如何收发的。
协作图：描述协作对象的交互与链接。
协作图和序列图的区别：协作图和序列图都是描述对象交互的，但是序列图强调的是时间，协作图强调的空间。
7.6需求分析与用例建模
7.6.1需求分析的任务
需求分析的基本任务不是确定系统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。---- 准确地回答“系统必须做什么?”。
需求分析的步骤： 需求获取 分析建模 文档编写 需求验证
7.6.2类图
类(Class)、对象(Object)和它们之间的关系是面向对象技术中最基本的元素。类图技术是OO方法的核心。
类图标加上它们之间的关系就构成了类图。
类图用于对系统静态设计视图建模。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。
类图中可以包含接口，包，关系等建模元素，也可以包含对象，链等实例。
类图典型的应用在下面三类建模： (1)对系统的词汇建模 (2)对简单协作建模
(3)对逻辑数据库模式建模
类图通常包含下述内容：类、接口、协作、依赖、泛化和关联关系。
关系(Relationship)是事物间的关系。在类的关系中，最常用的4种分别为： 依赖(Dependency)：它表示类之间的使用关系 泛化(Generalization)：它表示类之间的一般和特殊的关系; 关联(Association)：它表示对象之间的结构关系 实现(Realization)：它是规格说明和其实现之间的关系。
类主要包含以下几个部分
(1)名称(Name)名称是每个类所必有的构成，用于和其他类相区分。 (2)属性(Attribute)类的一个组成部分描述了类所代表事物的属性 (3)操作(Operation)操作是对类的对象所能做的事务的抽象
类在UML中由专门的图符表达，是分成3个分隔区的矩形,顶端为类的名字，中间存放类的属性、属性的类型和值，第3个分隔区放操作、操作的参数表和返回类型，如下图：
7.6.3用例图
在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。
用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。
用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。 让用户参与前期的系统分析与设计。
用例图的组成： 用例(Use Case) 参与者(Actor) 关系(Relationship)
1.什么是参与者
参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。 参与者可能是人、另外一个系统、时间的流逝等。
UML中，参与者用“人形”图标来表示，名字写在图标的下方。
参与者
2.什么是用例
用例(use case)一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作(功能)。
参与者和用例分别描述了“谁来做?”和“做什么?”这两个问题。 每个用例都必须有一个惟一的名字以区别于其他用例。 用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。 3.用例间、用例与参与者的关系
(1)泛化关系(Generalization)：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化：
(2)包含关系(Include)一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。
(3)扩展关系(Extend)：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。
(4)关联关系：关联关系表示参与者与用例之间的通信。
4.用例间的关系
(1)泛化关系
当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。
用例可以被特别列举为一个或多个子用例，这被称做用例泛化。 (2)包含关系
包含是指基本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例──多个用例的公共用例。
(3)扩展关系
将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事件流中的判定点。
扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：
a.表明用例的某一部分是可选的系统行为(这样，您就可以将模型中的可选行为和必选行为分开);
b.表明只在特定条件(如例外条件)下才执行的分支流;
5.用例之间的关系
包含用例与扩展用例的区别
①相对于基础用例，扩展用例是可选的，而包含用例则不是。
②如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。 ③扩展用例的执行需要满足某种条件，而包含用例不需要。 ④扩展用例的执行会改变基础用例的行为，而包含用例不会。
6.识别用例的方法：
①参与者希望系统提供什么功能;
②系统是否存储和检索信息;如果是，这个行为由哪个参与者触发; ③当系统改变状态时，是否通知参与者;
④是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。
7.6.4活动图
1.什么是活动图
活动图是UML中描述系统动态行为的图之一，是描述系统或业务的一序列活动构成的控制流，它描述了系统从一种活动转换到另一种活动的整个过程。
2.活动图用途
活动图用于对系统的动态行为建模。
活动图常用来描述业务或软件系统的活动轨迹，描述了系统的活动控制流程。我们常用活动图对业务过程、工作流和用例实现进行建模。
活动图主要应用对两个方面建模：一是在业务分析阶段，对工作流程进行建模;二是在系统分析和设计阶段，对操作流程进行建模。
7.6.5面向对象分析建立的3类模型
对象模型、动态模型、功能模型
对象模型
对象模型表示了静态的、结构化的系统数据性质，描述了系统的静态结构，它是从客观世界实体的对象关系角度来描述，表现了对象的相互关系。该模型主要关心系统中对象的结构、属性和操作，它是分析阶段三个模型的核心，是其他两个模型的框架。[2]
⒈对象和类 ⑴对象。
对象建模的目的就是描述对象。 ⑵ 类。
通过将对象抽象成类，我们可以使问题抽象化，抽象增强了模型的归纳能力。 ⑶ 属性。
属性指的是类中对象所具有的性质(数据值)。 ⑷ 操作和方法。
操作是类中对象所使用的一种功能或变换。类中的各对象可以共享操作，每个操作都有一个目标对象作为其隐含参数。
方法是类的操作的实现步骤。 ⒉关联和链
关联是建立类之间关系的一种手段，而链则是建立对象之间关系的一种手段。 ⑴ 关联和链的含义。
链表示对象间的物理与概念联结，关联表示类之间的一种关系，链是关联的实例，关联是链的抽象。
⑵ 角色。
角色说明类在关联中的作用，它位于关联的端点。 ⑶ 受限关联。
受限关联由两个类及一个限定词组成，限定词是一种特定的属性，用来有效的减少关联的重数，限定词在关联的终端对象集中说明。
限定提高了语义的精确性，增强了查询能力，在现实世界中，常常出现限定词。 ⑷ 关联的多重性。
关联的多重性是指类中有多少个对象与关联的类的一个对象相关。重数常描述为“一”或“多”。 ⒊类的层次结构 ⑴ 聚集关系。
聚集是一种“整体-部分”关系。在这种关系中，有整体类和部分类之分。聚集最重要的性质是传递性，也具有逆对称性。
聚集可以有不同层次，可以把不同分类聚集起来得到一颗简单的聚集树，聚集树是一种简单表示，比画很多线来将部分类联系起来简单得多，对象模型应该容易地反映各级层次。
⑵一般化关系。
一般化关系是在保留对象差异的同时共享对象相似性的一种高度抽象方式。它是“一般---具体”的关系。一般化类称为你类，具体类又能称为子类，各子类继承了父类的性质，而各子类的一些共同性质和操作又归纳到你类中。因此，一般化关系和继承是同时存在的。一般化关系的符号表示是在类关联的连线上加一个小三角形。
⒋对象模型
⑴模板。模板是类、关联、一般化结构的逻辑组成。 ⑵对象模型。
对象模型是由一个或若干个模板组成。模板将模型分为若干个便于管理的子块，在整个对象模型和类及关联的构造块之间，模板提供了一种集成的中间单元，模板中的类名及关联名是唯一的
动态模型
动态模型是与时间和变化有关的系统性质。该模型描述了系统的控制结构，它表示了瞬间的、
行为化的系统控制
性质，它关心的是系统的控制，操作的执行顺序，它表示从对象的事件和状态的角度出发，表现了对象的相互行为。
该模型描述的系统属性是触发事件、事件序列、状态、事件与状态的组织。使用状态图作为描述工具。它涉及到事件、状态、操作等重要概念。
⒈事件
事件是指定时刻发生的某件事。
⒉状态
状态是对象属性值的抽象。对象的属性值按照影响对象显著行为的性质将其归并到一个状态中去。状态指明了对象对输入事件的响应。
⒊状态图
状态图是一个标准的计算机概念，他是有限自动机的图形表示，这里把状态图作为建立动态模型的图形工具。
状态图反映了状态与事件的关系。当接收一事件时，下一状态就取决于当前状态和所接收的该事件，由该事件引起的状态变化称为转换。
状态图是一种图，用结点表示状态，结点用圆圈表示;圆圈内有状态名，用箭头连线表示状态的转换，上面标记事件名，箭头方向表示转换的方向。
功能模型
功能模型描述了系统的所有计算。功能模型指出发生了什么，动态模型确定什么时候发生，而对象模型确定发生的客体。功能模型表明一个计算如何从输入值得到输出值，它不考虑计算的次序。功能模型由多张数据流图组成。数据流图用来表示从源对象到目标对象的数据值的流向，它不包含控制信息，控制信息在动态模型中表示，同时数据流图也不表示对象中值的组织，值的组织在对象模型中表示。
数据流图中包含有处理、数据流、动作对象和数据存储对象。 ⒈处理
数据流图中的处理用来改变数据值。最低层处理是纯粹的函数，一张完整的数据流图是一个高层处理。
⒉数据流
数据流图中的数据流将对象的输出与处理、处理与对象的输入、处理与处理联系起来。在一个计算机中，用数据流来表示一中间数据值，数据流不能改变数据值。
⒊动作对象
动作对象是一种主动对象，它通过生成或者使用数据值来驱动数据流图。
⒋数据存储对象
数据流图中的数据存储是被动对象，它用来存储数据。它与动作对象不一样，数据存储本身不产生任何操作，它只响应存储和访问的要求。
7.7设计阶段
7.7.1详细设计
详细设计阶段的根本目标是确定怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
详细设计的目标: 设计出的处理过程应该尽可能简明易懂。 详细设计的任务：
(1) 为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程性描述;
(2) 确定每一模块使用的数据结构;为以后的编写程序做好充分的准备。 (3) 确定模块接口的细节。
7.7.2总体设计
1.面向对象设计
面向对象设计的准则：优秀设计就是使得系统在其整个生命周期中的总开销最小的设计, 其主要特点就是容易维护。
面向对象设计(OOD，Object-Oriented Design)是面向对象分析到实现的一个桥梁。面向对象分析是将用户需求经过分析后，建立问题域精确模型的过程;而面向对象设计则根据面向对象分析得到的需求模型，建立求解域模型的过程。即分析必须搞清楚系统“做什么”，而设计必须搞清楚系统“怎么做”，从分析到设计不是传统方法的转换，而是平滑(无缝)过渡，而求解域模型是系统实现的依据。
静态结构设计： 类设计 包设计 接口设计
动态结构设计(行为和交互建模)： 对象如何进行交互的
2.GUI (图形用户界面)设计概述
对于用户来说，一个友好的界面是至关重要的。
用户界面(User Interface)的设计质量直接影响用户对软件产品的评价，从而影响软件产品的竞争力和使用寿命，因此，对人机界面的设计必须给予足够的重视。
良好的GUI设计原则
1、关注用户及其任务，而不是技术
2、首先考虑功能，其次才是表现
3、与用户对任务的看法保持一致
4、设计要符合常见情况
5、不要分散用户对他们目标的注意力
6、促进学习，从外(用户)到里(设计人员)思考，而不是相反。
7、传递信息，而不仅仅是数据
8、设计应满足响应需求
9、通过用户试用发现错误，然后修复它
3.数据库设计
设计原则：
每一个类成为一个数据库表。 关系映射：
(1)一对多的关系映射为数据库表的主外键关联(1方的主键加入n方成为外键)
(2)一对一的关系映射为数据库表的主外键关联(1方的主键加入另一方成为外键)
(3)多对多的关系映射：产生第三张表，将两个多方的主键加入其中成为外键，两个外键的组合成为主键。
利用数据库三范式检查表，从而考察领域类图的分析是否合理，消除冗余数据。 检查数据是否能够反映用例视图的需要;进一步与用户再次确认使用的数据。
7.8注释
夹在程序中的注释是程序员与日后的程序读者之间通信的重要手段。注释决不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3到1/2，甚至更多。
注释分为两类：序言性注释和功能性注释。
1.序言性注释
通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。
序言性注释包括： 程序标题;
有关本模块功能和目的的说明; 主要算法;
接口说明：包括调用形式，参数描述，子程序清单;
有关数据描述：重要的变量及其用途，约束或限制条件，以及其它有关信息; 模块位置：在哪一个源文件中，或隶属于哪一个软件包;
开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。
2.功能性注释
功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样，而不要解释下面怎么做。
要点：
描述一段程序，而不是每一个语句; 用缩进和空行，使程序与注释容易区别;
7.9软件测试
软件测试的定义：软件测试是使用人工和自动手段来运行或测试某个系统的过程，其目的在于检测被测试软件系统是否满足规定的需要，或是弄清楚被测系统的预期结果与实际结果之间的差别。
黑盒测试：仅需要知道被测试对象的输入和预期输出，不需要了解代码实现的细节。测试方法
主要分为两类：功能层面的测试方法和函数层面的测试方法(边界值测试、等价类测试、基于决策表测试)。侧重于系统业务流程的梳理，是基于动态业务过程设计测试用例。
白盒测试：是针对程序代码展开的测试，分为静态测试和动态测试：关注对象包括源代码和程序结构。静态白盒测试的方法是代码检查。静态测试不需要运行程序和设计测试用例，侧重于源代码的检查和优化，直接查看源代码和执行代码，直接定位代码中的缺陷。动态测试侧重于程序结构的测试。
测试用例的定义：测试用例是一组测试输入，执行条件和预期结果。目的是要满足一个特定的目标。如果执行一条特定的程序路径或者检验是否符合一个特定的需求的用例。测试用例：输入+输出+测试环境测试环境包括：硬件环境，软件环境，网络环境，历史数据。
测试用例分为两个阶段：测试用例分析阶段，测试用例设计阶段。
7.9.1测试和调试的区别
1、目的不同
软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是一种排除过程，是编码活动的一部分。
2、任务不同
既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。
而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如:解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有一些启发式的方法，它是一种比较依赖开发人员经验的活动。
3、指导原则和方法不同
软件侧试是一种有规律的活动，有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。例如使用归纳法、演绎法、回溯法等。
软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。
4、操作者
因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员.
7.9.2软件维护
软件维护活动类型总起来大概有四种：纠错性维护(校正性维护)、适应性维护、完善性维护或增强、预防性维护或再工程。
改正性维护
改正性维护是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。这方面的维护工作量要占整个维护工作量的17%～21%。所发现的错误有的不太重要，不影响系统的正常运行，其维护工作可随时进行：而有的错误非常重要，甚至影响整个系统的正常运行，其维护工作必须制定计划，进行修改，并且要进行复查和控制。
适应性维护
适应性维护是指使用软件适应信息技术变化和管理需求变化而进行的修改。这方面的维护工作量占整个维护工作量的18%～25%。由于计算机硬件价格的不断下降，各类系统软件屡出不穷，人们常常为改善系统硬件环境和运行环境而产生系统更新换代的需求;企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。这些因素都将导致适应性维护工作的产生。进行这方面的维护工作也要像系统开发一样，有计划、有步骤地进行。
完善性维护
完善性维护是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。这些功能对完善系统功能是非常必要的。另外，还包括对处理效率和编写程序的改进，这方面的维护占整个维护工作的50%～60%，比重较大.也是关系到系统开发质量的重要方面。这方面的维护除了要有计划、有步骤地完成外.还要注意将相关的文档资料加入到前面相应的文档中去。
预防性维护
预防性维护为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。例如将专用报表功能改成通用报表生成功能，以适应将来报表格式的变化。这方面的维护工作量占整个维护工作量的4%左右。
第一章
1.软件有哪些种类?
答：1.按功能特征进行划分：
(1)系统软件(2)支撑软件(3)应用软件
2.按规模大小进行划分
微型、小型、大型、甚大型、极大型
4.结合自己的亲身经历，谈谈软件工具在软件开发过程中的作用。
使软件开发更加模式化，工程化，从而提高软件开发的效率和封装性。
第二章
2.软件瀑布模型为什么要划分阶段?各个阶段的任务是什么?
在软件开发早期，开发只是被简单地分成编写代码和修改代码两个阶段。往往在拿到项目后立刻编写程序，然后调试通过后直接交付给用户使用。如果应用中出现错误，或者有新的要求，都需要重新修改代码。这种小作坊式的软件开发方法有明显的弊端，如缺乏统的项目规划、不太重视需求的获取和分析、对软件的测试和维护考虑不周等，这些都会导致软件项目的失败。
概念阶段：计划、需求分析
开发阶段：设计、编码、测试
维护阶段：运行维护
3.举例说明哪些项目的开发适用于原型模型或螺旋模型，哪些不适于采用这两种模型。
螺旋模型适合于大型软件的开发，应该说它是最为实际的方法，它吸收了软件工程“演化”的概念，使得开发人员和客户对每个演化层出现的风险有所了解，继而做出应有的反应。
不适用:小型软件。
原型般是指对某种产品进行模拟的初始版本或者原始模型，在工程领域中具有广泛应用。
不适用:大型软件项目;含有对于计算量大、逻辑性较强的程序模块：
第三章
1.可行性研究的任务是什么?
可行性研究的任务是以最小的代价在尽可能短的时间内确定问题是否能够解决。简单的说，可行性研究的最终结果是决定项目y做还是小做”而不是“如何做”。 2.项目开发计划有哪些内容?
引言(目的、背景、参考文献、术语);项目概述(功能、条件、运行环境、产品、程序、文档、服务、验收标准、实施计划、工作任务分解、进度、预算、人员)
第四章
1.什么是需求工程?需求工程包括哪些活动?
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的 门学科。它通过合适的工具和记号系统地描述待开发系统，及其行为特征和相关约束，形成需求文档;并对用户不断变化的需求演进给予支持。
一个良好的需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。
2.需求工程过程包括哪些主要活动? 需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。 3.有哪两种主要的需求分析模型?它们的主要思想是什么?
答：面向对象分析模型，结构化分析模型。前者是采用面向对象的思想进行软件需求分析的建模过程，而后者模型的核心是DD，它是设计各种数据对象的总和。他们的模型分别起到了描述数据模型，功能模型与行为模型的作用。
4.需求规格说明书的主要作用是什么?应该包括哪些主要内容? 作用：
(1)作为用户方和开发方之间的合同，为双方相互了解提供基础。
(2)反映问题的结构，作为系统设计和编码的依据。
(3)作为测试和验收目标系统的依据。 内容：
用户可以通过需求规格说明书检查需求描述是否满足原来的期望。设计人员根据软件需求规格说明书的描述了解所需开发软件的功能和性能，以及开发软件时必须满足的约束，将其作为软件设计的依据。测试人员根据软件需求规格说明书中对产品的描述，设计测试计划、测试用例和测试过程。产品发布人员根据软件需求规格说明和用户界面设计编写用户手册和帮助信息
第五章
2.简述数据流图分解时的注意事项。
•上层可分解得快些(即分解成子数据处理个数多些)，这是因为上层是综合性描述，对可读性的影(即分解成的子数据处理个数多些)，这是因为上层是综合性描述，对可读性的影响小。而下层应分解得慢性。
•在不影响可读性的前提下，应适当多分解成几部分，以减少分解层数。 3.数据字典的作用是什么?它有哪些基本内容? •分解应自然，概念上要合理、清晰。
作用：数据字典作为分析阶段的工具，有助于改进分析人员和用户.间的通信，进而消除很多的误解，同时也有助于改进不同开发人员之间的通信;. 内容:数据字典的内容主要是对数据流图中的数据项、数据流、加工逻辑、数据存储和外部实体
第六章
1.什么是面向对象方法?与传统软件开发方法相比，面向对象方法有什么优点? 是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法。 优点：
1.符合人们对问题的认识习惯
2.增强问题域与最终软件系统之间的衔接
3.易于维护和复用
4.易于开发大型软件产品
2.什么是模型?在软件开发过程中为什么需要建立模型?
在软件开发过程中，建立软件模型具有十分重要的作用，主要体现在以下几个方面：
有助于问题的简化，通过抽象降低复杂性;
有助于和其他开发小组成员，各种用户以及系统相关者进行交流;
有助于维护人员了解软件设计的思路和细节，为以后的维护和升级提供了文档。
第七章
1.面向对象分析包括哪些活动?应该建立哪些类型的模型?
面向对象分析OOA模型的过程包括理解用例模型、识别分析类、定义交互行为、建立分析类图、评审分析模型5个活动组成。
目标是建立一个符合问题域、满足用户需求的OOA模型。
2.什么是实体类、边界类和控制类?为什么将分析类划分成这3种类型?
实体类：用于描述必须存储的信息，同时描述相关的行为。实体类代表拟建系统中的核心信息。在RUP的有关文档中对实体类的解释为：“实体类是用于对必须存储的信息和相关行为建模的类。 边界类：在系统与外界之间，为它们交换各种信息与事件。边界类处理软件系统的输入和输出。在RUP的有关文档中对边界类的解释为：边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。
控制类：与业务过程相关，它们控制整个业务的流程和执行次序。在RUP的有关文档中对控制类的解释为：控制类用于对一个或几个用例所持有的控制行为进行建模。
控制类对象可以和边界对象交互，也可以和实体对象交互，但不能和用例的参与者直接进行交互。
第八章
1.什么是软件设计?它的目标和任务是什么?
<1>软件设计：在需求分析的基础上通过抽象和分解将系统分解成模块，确定系统功能的实现。即把软件需求转换为软件包表示的过程。
<2>目标：软件设计的最终目标是产生一个设计规约，该规约包括体系结构、描述数据、接口和构件的设计模型。
软件设计的任务，就是把分析阶段产生的软件需求规格说明转换为用适当手段表示的软件设计文档。
2.完成良好的软件设计应遵循哪些原则?
模块化与模块独立性;抽象与逐步求精;信息隐藏。 3.如何理解模块独立性?用什么指标来衡量模块独立性?
<1>模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而和软件系统中其他的模块的接口是简单的。
<2>一般采用两个准则度量模块独立性，即模块的内聚性和模块间的耦合性 4.说明软件设计阶段的任务和过程 软件设计分两步完成，即总体设计与详细设计。第个阶段是总体设计，即概要设计或初步设计。这、阶段主要确定实现目标系统的总体思想和设计框架，确定程序由哪些模块组成，以及模块与模块之间的关系，最后提出概要设计说明书。第二个阶段是详细设计，即过程设计或构件级设计，其任务是通过对结构表示进行细化，确定各个软件构件的详细数据结构和算法，产生描述各个软件构件的详细设计文档。
5.试说明软件体系结构在软件设计阶段中的重要性。
良好的体系结构设计是决定软件系统成功的重要因素。软件体系结构设计的好坏往往会成为一个系统设计成败的关键。通常，软件体系结构涉及软件的总体组织、全局控制、数据存取及子系统之间的通信协议等。
6.简述面向对象设计阶段要做的工作。
OOD主要包括三个方面的工作：系统体系结构设计、用例实现方案设计和用户界面设计。
第十一章
1.简述程序设计语言的基本特征及分类。
基本特征包括心理特性，工程特性和技术特性三个方面。语言的的—心理特性对人机通信的质量有主要的影响;语言的工程特性对软件开发成功与否有重要的影响，此外语言的技术特性也会影响软件设计的质量
•按程序设计语言的历史发展过程，计算机语言可分为机器语言、汇编语言、高级程序设计语言。
•按与机器的依赖程度，可分为低级、中级和高级语言。
•按应用范围，可分为通用语言与专用语言两大类，通用语言义可细分为系统程序设计语言、科学计算语言、事务处理语言和实时控制语言等。
•按程序的设计方法，可分为命令性语言和作用性语言。
•按语言的成分，可以分成顺序语言、并行语言和实时语言等。
•按语言的组成方法，可以分成汇集式语言和可扩充语言。 2.为了具有良好的程序设计风格，应该注意哪些方面的问题?
要形成良好的程序设计风格，应从源程序文档化、数据说明、语句构造、输入输出和追求效率几个方面加以注意。
3.什么是软件测试?软件I则试的原则有哪些?
软件测试是按照特定的规则，发现缺陷而执行程序的过程。
一个好的测试用例是指尽可能找到迄今为止尚未发现缺陷的用例。 一个成功的测试是指揭示了迄今为止尚未发现缺陷的测试。 软件测试的原则：
(l)所有的测试都应该能追溯到用户需求。
(Z)应该在测试之前就制定出测试计划。
(3)Pareto原理可应用于软件测试。
(4)测试应从“小规模”开始，逐步转向“大规模”
(S)穷举测试是不可能的。
(6)既要做通过性测试，又要做失效性测试。
(D为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
第十四章
1.为什么说软件维护是不可避免的?
因为软件的开发过程中，一般很难检测到所有的错误，其次软件在应用过程中需要随用户新的要求或运行环境的变化而进行软件的修改或纠正软件开发过程未发现的错误，增强、改进和完善软件的功能和性能，以适应软件的发展，延长软件的寿命，软件的维护是不可避免的。 2.什么是软件再工程?软件再工程的主要活动有哪些?
指在逆向工程所获信息的基础上修改重构已有的系统，产生的―个新版本，或者说利用这些信息修改或重构软件系统的工作。
它定义了6为活动r即库存目录分析、文档重构、逆向工程、代码重构、数据重构、正向工程。 3.软件调试与软件测试有什么区别?
1、目的不同
软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务。调试的目的是为了证明程序的正确，因此它必须不断地挤除错误.它们的出发点不一样“前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是-种排除过程，是编码活动的部分•
2、任务不同
既然软件测试属于质量保证活动，因此它贯穿十整个计发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。
而调试是编码活动的部分，因此有编码就有调试它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有些启发式的方法，它是.种比较依赖开发人员经验的活动。
3、指导原则和方法不同
软件侧试是种有规律的活动，有一系列软件软件测试的原则.其中主要是制U侧试计划，然后严格执行。其次是种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件个应该做的事情。调试所遵循的规律主要是些启发式规则，是”个推理过程。例如使用归纳法、演绎法、回溯法等。
软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。
4、操作者
因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员•
5、操作环境、配置、工具不同
调试在开发的编码环境下进行。如果编码使用解释型语言，则可以进行人机交互式调试，设里断点、单步调试等。如果编码使用编译型语言，也可以设置断点、显示调试变量值等。而软件测试是在软件测试环境下进行，直接运行开发完成的程序，可能不再需要一些开发时的驱动程序、动态链接库等.使用不同的工具，环境配置也不同。
简答题，
1.什么是软件工程?请分析软件工程的目标是什么?
答案：软件工程是：1将系统化的、规范的、可度量的方法应用于软件的升发、运行和维护过程，也就是说将工程化应用于软件开发和管理之中;2对1中所选方法的研究”
软件工程旨在开发满足用户需要、及时交付、不超过预算和无故障的软件，其主要目标如下: a)实现预期的软件功能，达到较好的软件性能，满足用户的需求。
b)增强软件过程的可见性和可控性，保证软件的质量。
c)提高所开发软件的可维护性，降低维护费用。
d)提高软件开发生产率，及时交付使用。
e)合理预算开发成本，付出较低的开发费用。
3.根据相关的法律，对于侵犯软件著作权的行为，根据情节应当给予什么处罚?
对于侵犯软件著作权的行为，要根据情况承担停止侵害、消除影响、赔礼道歉、赔偿损失等民事责任;损害社会公共利益的，由著作权行政管理部门责令停止侵权行为，没收违法所得，没收、销毁侵权复制品，并处罚款;情节严重的，著作权行政管理部门可以没收用子制作侵权复制品的材料、工具、设备等;触犯刑律的，依法追究刑事责任。
4根据你的理解，列举出职业化软件工程师要注意的三个主要问题，请给出理由。 没有唯一答案。
1)不遵守标准和规范：职业化的重要特征是遵守行业标准，不能肆意按照自己的想象来发挥。自从人们认识到软件危机以来，总结软件开发的失败教训和成功经验，并把它们总结成为最佳实践，进而形成标准，要充分利用这些最佳实践和标准来指导软件过程。任何闭门造车、想当然的行为都是不被提倡的，注定要走弯路。
2)对待计划不严肃：软件工程强调计划性，计划的内容包括;设备资源、进度安排、人力资源、任务分配等等。在项目的进行中要跟踪计划执行情况，记录计划执行过程中的偏差，对任何变更都要经过评审和批准才能付诸行动。
3)不主动与人沟通：软件不可见的特性，需要软件工程师进行大量书面的、口头的或面对面的沟通，沟通的目的是为了使相关的人员了解项目的进展、遇到的问题、应用的技术、采用的方法。 5.软件工程为什么要强调规范化和文档化?. 软件工程强调规范化和文档化。规范化的目的是使众多的开发者遵守相同的规范，使软件生产摆脱个人生产方式，进入标准化、工程化的生产方式。文档化是将软件的设计思想、设计过程和实现过程完整地记录下来，以便于后人的使用和维护，在开发过程中各类相关人员借助于文档进行交流和沟通。另外，在开发过程中产生的各类文档使得软件的生产过程由不可见变为可见，便于管理
者对软件生产进度和开发过程进行管理。在用户最终验收时可以通过对提交的文档进行技术审查和管理审查，保证软件的质量。
6.请简单说明结构化分析的主要步骤。
根据用户的需求画出初始的数据流程图，写出数据字典和初始的加工处理说明(lPO图)，实体关系图。以初始数据流程图为基础，从数据流程图的输出端开始回溯。在对数据流程图进行回溯的过程中可能会发现丢失的处理和数据，应将数据流程图补充完善。对软件性能指标、接口定义、设计和实现的约束条件等逐一进行分析。系统分析人员与用户起对需求分析的结果进行复查。根据细化的需求修订开发计划。编写需求规格说明书和初始的用户手册，测试人员开始编写功能测试用的测试数据。
7.设计类的属性时必须要定义是哪两项?
设计类的属性时必须要定义的内容：
1)属性的类型：设计属性时必须要根据开发语言确定每个属性的数据类型•如果数据类型不够，设计人员可以利用已有的数据类型定义新的数据类型。
2)属性的可见性。在设计属性时要确定公有属性、私有属性、受保护属性。活动图反映系统中从一个活动到另一个活动的流程，强调对象间的控制流程。活动图特别适合描述工作流和并行处理过程。具体地说活动图可以描述一个操作过程中需要完成的活动;描述一个对象内部的工作;描述如何执行组相关的动作，以及这些动作如何影响它们周围的对象;说明个业务活动中角色、工作流、组织和对象是如何工作的。
顺序图用于描述一组交互对象间的交互方式，它表示完成某项行为的对象和这些对象之间传递消息的时间顺序。
8面向对象的分析通常要建立三个模型， 请问三个模型的作用?
a)功能模型：表达系统的详细需求，为软件的进一步分析和设计打下基础。在面向对
象方法中，由用例图和场景描述组成。
b)对象模型：表示静态的、结构化的系统“数据”性质。描述现实世界中实体的对象以及它们之间的关系，表示目标系统的静态数据结构。在面向对象方法中，类图是构件对象模型的核心上具。
c)动态模型：描述系统的动态结构和对象之间的交互，表示瞬时的、行为化的系统的“控制”特性。面向对象方法中，常用状态图、顺序图、合作图、活动图构件系统的动态模型。
9.面向对象的设计活动中，有构架师、用例工程师和构件师参加，他们每个角色的职责是什么?
构架设计的目的是要勾画出系统的总体结构，这项工作由经验丰富的构架设计师主持完成。该活动以用例模型、分析模型为输入，生成物理构架、子系统及其接口、概要的设计类(即设计阶段定义的类)。
根据分析阶段产生的高层类图和交互图，由用例设计师研究已有的类，将它们分配到相应的用例中。检查每个用例的功能，这些功能依靠当前的类能否实现，同时检查每个用例的.特殊需求是否有合适的类来实现。细化每个用例的类图，描述实现用例的类及其类之间的相互关系，其中的通用类和关键类可用粗线框区分，这些类将作为项目经理检查项目时的重点。
经过前面两个活动，构架设计师已经将系统的构架建立起来，用例设计师按照用例的功能将每个类分配给相应的用例。现在要由构件工程师详细设计每个类的属性、方法和关系。 10.提高程序可读性有哪些招数?对你来讲比较灵验的是哪些?
a)源程序文件头说明，函数应有函数头说明，内容包括：程序标题;有关该模块功能和目的说明;主要算法说明;接O说明，包括调用形式、参数描述、子程序清单、有关数据的说明。
b)主要变量(结构、联合、类或对象)的定义能够反映其内在含义。 c)变量定义最规范化，说明的先后次序固定。
d)处理过程的每个阶段和典型算法前都有相关注释说明。
三、简答题：
2、什么是软件工程?包括哪些内容?
答: 软件工程：用科学知识和技术原理来定义、开发、维护软件的一门学科。 软件工程的内容：
1)软件开发技术：软件开发方法、软件开发过程、软件开发工具和环境。 2)软件开发管理：软件管理学、软件经济学、软件心理学。
软件工程的目标:是成功的建造一个大型软件系统，所谓成功是要达到以下几个目标：①付出较 低的开发成本;②面到要求的软件功能;③取得较好的软件性能;④开发的软件易于 移植;⑤需要较低的维护费用;⑥能按时完成开发任务，及时交付使用;⑦开发的软 件可靠性高; 软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工 程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、 确认以及维护等活动。
软件工程的框架可概括为：①目标、②过程和③原则。
软件工程的原则：是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。 基本原理：⑴用分阶段的生命周期计划严格管理;⑵坚持进行阶段评审;⑶实行严格的产品控制; ⑷采用现代程序设计技术;⑸结果应能清楚地审查;⑹开发小组的人员应该少而精; ⑺承认不断改进软件工程实践的必要性;(工程化的方法开发软件基本原理)
软件工程方法学：软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工 程学科。
软件工程方法学包括：①传统方法学(结构化范型)和②面向对象方法学。
面向对象的要点: ①把对象作为融合了数据及在数据上的操作行为的统一的软件构件。②把所 有对象都划分成类。③按子类与父类的关系,把类组成一个层次结构。④对象彼此之 间仅能通过传递消息互相联系。
软件工程方法学三要素是：①方法;②工具;③过程。
3、 软件生命周期由哪三个时期组成，又划分为哪8个阶段?
答：软件生存周期：一个软件从提出开发要求开始直到该软件报废为止的整个时期。软件生命周期是
由：⑴软件定义时期;⑵软件开发时期;⑶软件维护时期三个时期组成的。又划分为：①问题定义、②可行性研究、③需求分析、④总体设计、⑤详细设计、⑥编码和单元测试、⑦综合测试、⑧维护八个阶段。
1、问题的定义及规划 此阶段是软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。
2、需求分析 在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段，这一阶段做得好，将为整个软件开发项目的成功打下良好的基础。"唯一不变的是变化本身。"，同样需
求也是在整个软件开发过程中不断变化和深入的，因此我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。
3、软件设计 此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计，数据库设计等等。软件设计一般分为总体设计和详细设计。好的软件设计将为软件程序编写打下良好的基础。
4、程序编码 此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一，符合标准的编写规范。以保证程序的可读性，易维护性，提高程序的运行效率。
5、软件测试 在软件设计完成后要经过严密的测试，以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。
6、运行维护 软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后，由于多方面的原因，软件不能继续适应用户的要求。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。
4、 什么是白盒测试法?什么是黑盒测试法?
答：白盒测试：所谓白盒测试就是在知道产品内部工作过程或程序内部结构和处理过程的前提下,检
验产品内部动作是否按照规格说明书的规定正常进行或按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按照预定要求正确工作的测试方法.因此白盒测试又称为结构测试或逻辑测试。
从覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准：⑴语句覆盖;⑵判定覆盖;⑶条件覆盖;⑷判定/条件覆盖;⑸条件组合覆盖;⑹点覆盖;⑺边覆盖;⑻路径覆盖。 黑盒测试：所谓黑盒测试是指在完全不考虑程序的内部结构和处理过程的前提下,在程序接口进行的测试,它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接受输入数据产生正确的输出信息,并且保持外部信息的完整性.因此,又称为功能测试。特点：等价类划分、边界值分析、因果图、错误推测。
优点 1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了 2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因 缺点 1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不
是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。
5、 什么是集成测试?非渐增式和渐增式有什么区别?渐增式如何组装模块?
答：将模块组合起来成为一个完整的系统对其进行测试。非渐增式是将模块先进行单元测试然后组装
在一起进行测试。渐增式是逐个将未测试的模块组装到已经测试过的模块上去进行集成测试，每加入一个就测试一次。非渐增式需要桩模块和驱动模块、非渐增式开始可以并行测试、渐增式可以及时的发现接口错误，非渐增式很难发现接口发现错误、渐增式开始不能并行测试、渐增式测试比较彻底。渐增式组装模块有自顶向下和自底向上两种组装方式。
6、 什么是确认测试?该阶段有那些工作?
答：调试的目的是发现错误的位置并改正错误。简单调试、演绎调试、递归调试、回溯调试。
7、 面向对象方法学与传统方法学有何区别?
答：面向对象方法学注重的是软件的重用性，而传统的方法学则在这一问题解决上不理想。面向对象
方法学和传统的方法学在问题分析上的切入点不同。面向对象里面，系统是长出来的，传统的方法学里面，系统是放进去的。传统方法：⑴结构化开发方法，注重的是系统功能，自顶向下，从大到小的功能分解，从DFD到MSD，
往往系统需求变化最大就是功能，一段较长的时间内，商业的流程可能已经发生了很大的变化，这样基于功能和过程的方法显然难以维护的，代码重用率可想而知，而商业过程中的数据可能变化不会很大，⑵信息工程法，注重的是数据，事件流->信息流，(资金流，物流)->数据流，数据的输入和转化输出，数据流程图，状态转化图，事件顺序图，过程依赖图，两者都是由事件驱动.面向的是问题，是为了要解决某一个具体问题，其观察事物的方法不是本体客体本身，而是对本体客体相互作用过程抽象，转化成逻辑模型。面向对象方法学：其切入点是客观世界的主体和客体，通过封装实现了信息交流的安全，抽象和继承使得事物的一完整表述和容易修改新的变化，聚合，关联反映事物间的相互作用和关系，通过关联类管理，这样把事物和事物间的关系分开.减少了复杂度，便于维护，大大提高了代码重用率。
8、 软件开发模型有几种?各有什么特点? 软件生存周期模型：是描述软件开发过程中各种活动如何执行的模型。(模型：是为了理解事物而 对事物做出一种抽象，它忽略不必要的细节，它也是事物的一种抽象形式、一个规划、一个程式。) 主要模型：①瀑布模型;②增量模型;③螺旋模型;④喷泉模型;⑤变换模型;⑥基于知识的模 型等
瀑布模型：①它提供了一个摸板，这个摸板使分析、设计、编码、测试和支持的方法可以在该摸 板下有一个共同的指导;②虽然有不少缺陷但比在软件开发中随意的状态要好得多。 快速原型模型：①开发速度快，质量有保证。②对信息系统特别有效。
增量模型：①人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人
力实现下一个增量。②当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。③具有一定的市场。
螺旋模型：①对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好
地对待和理解每一个演化级别上的风险。②对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标;减少了过多测试或测试不足所带来的风险。
9、 可行性研究：⑴系统流程图;⑵数据流程图;
系统流程图：系统流程图是概括地描绘物理系统的传统工具。基本思想是用图形符号以黑盒子形
式描绘组成系统的每个部件。其表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。
数据流程图：简称DFD,是描述数据处理过程的工具。数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程，是一种功能模型。作用：它以图形的方式描绘数据在系统中流动和处理的过程,反映系统必须完成的逻辑功能。基本符号有四种：→,箭头,表示数据流;○,圆或椭圆,表示加工; =,双杠,表示数据存储;□,方框,表示数据的源点或终点。
可行性研究的任务： (1)经济可行性。确定待开发系统是否值得投资开发。(2)技术可行性。对待
开发的系统进行功能、性能和限制条件的分析，确定在现有资源的条件下技术风险有多大，系统是否能实现。 (3)法律可行性。确认待开发系统可能会涉及的任何侵犯、妨碍、责任等问题。(4)抉择。对系统开发的不同方案进行比较评估。
10、 什么是字据字典?其作用是什么?它有哪些条目?
字据字典：简称DD，就是用来定义数据流图中的各个成分具体含义的，它以一种准确的、无二义性 的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。
作 用：⑴为系统的分析设计及维护提供了有关元素的一致的定义和详细的描述.⑵为分析人员查找
数据流图中有关名字的详细定义而服务的.⑶它和数据流图共同构成了系统的逻辑模型,是需求规格说明书的主要组成部分.
条 目：数据流、数据项、数据存储、基本加工。
11、 需求分析的任务是什么? 答: 需求分析是指：开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈 述转化为完整的需求定义，再由需求定义转换到相应的形式主义功能规约(需求规格说明)的过程。 需求分析的主要任务：⑴正确地确定对系统综合要求,充分理解和表达用户的需求。⑵通过结构分
析的方法对系统进行分解,以确定软件系统的主要成分或软件系统的构成。⑶是对以上已进行的两项工作进行描述,以形成需求文档。⑷编写用户手册;⑸编写验收计划;⑹修正可行性研究阶段所制订的软件项目开发计划。
12、结构化分析方法：结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系， 自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。
主要工具：数据流图、数据词典、结构化英语、判定表和判定树。 3种模型：①数据模型、②功能模型和③行为模型。
验证软件需求：⑴一致性;⑵完整性;⑶现实性;⑷有效性;
结构化分析方法步骤： ①了解当前系统的工作流程,获得当前系统的物理模型。②抽象出当前系 统的逻辑模型。③建立上标系统的逻辑模型。④作进一步补充和优化。
结构化程序设计基本要点：⑴采用自顶向下、逐步求精的程序设计方法;⑵使用三种基本程序控 制结构构造程序(①顺序方式;②选择方式;③循环方式;)。⑶主程序员组的组织形式。
13、总体设计过程由两个主要阶段组成：①系统设计阶段，确定系统的具体实现方案;②结构设计阶段， 确定软件结构。
模块：软件系统的层次结构正是模块化的具体体现。将整个软件划分成若干单独命名和可编址的部分，称之为模块。 模块化：就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集 成起来构成一个整体，可以完成指定的功能满足用户的需求。模块是构成程序的基本构件。
模块化的根据：把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。这就是模块化的根据。
14、衡量模块独立性的两个标准是什么?它们各表示什么含义? 两个定性的度量标准：耦合与内聚性。
耦合：是模块之间的相对独立性(互相连接的紧密程度)的度量。模块之间的连接越紧密，联系越多， 耦合性就越高，而其模块独立性就越弱。按耦合度从低到高依次有7种耦合方式：①非直接耦
合(独立运行);②数据耦合(用参数表传递简单数据);③标记耦合(传递数据结构或者一部分);④控制耦合(传递的信息包括控制模块的信息);⑤外部耦合(模块与软件之外的环境有关);⑥公共耦合(多个模块引用同一全局的数据区);⑦内容耦合(访问内部数据，代码重叠或者多个入口)。
内聚：是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量。一个模块内部各个元素
之间的联系越紧密，则它的内聚性就越高。按内聚度从低到高依次有7种内聚种类： ①偶然内聚(模块完成的多个任务，任务之间的关系松散);②逻辑内聚(模块完成逻辑相关的一组任务);③瞬时内聚(模块的所有任务必须在同一时间间隔内执行);④过程内聚(模块的处理元素相关而且按照特定的次序执行);⑤通信内聚(模块的所有元素集中在一个数据结构区域上);⑥顺序内聚(模块的处理元素相关，必须顺序执行);⑦功能内聚(模块完成单一的功能，各个部分协调工作，而且不可缺少)
耦合和内聚的关系：一般说来，在系统中各模块的内聚越大，则模块间的耦合越小。但这种关系并不
是绝对的。耦合小使得模块间尽可能相对独立，从而各模块可以单独开发和维护。内聚大使得模块的可理解性和维护性大大增强。因此，在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚。
15、Jackson方法的步骤： (1)实体动作分析：从问题的描述中，提取软件系统要产生和运用的实体，以及
现实世界作用于实体上的动作。(2)实体结构分析：把作用于实体的动作或由实体执行的动作，按时间发生的先后次序排序，构成进程，并用一个层状的Jackson结构图表示。(3)定义初始模型：把实体和动作表示成一个进程模型，定
义模型与现实世界的联系。(4)功能描述：说明与已定义的动作相对应的功能，为已定义的动作加入功能函数。(5)决定系统时间特性：对进程加入时间因素，对进程调度特性进行评价和说明。(6)实现：设计组成系统的硬件和软件，实现系统的原型。
16、测试阶段的信息流：这个阶段的输入信息有两类： (1)软件配置，包括需求说明书、设计说明书和源 程序清单等;
(2)测试配置，包括测试计划和测试方案。
自顶向下集成：从主控制模块开始，沿着程序的控制
层次向下移动，逐渐把各个模块结合起来。在把附属于主控制模块的那些模块组装到程序结构中去时，或者使用深度优先的策略，或者使用宽度优先的策略。
深度优先的结合方法先组装在软件结构的一条主控制通路上的所有模块。选择一条主控制通路取决于应用的特点，并且有很大任意
性。而宽度优先的结合方法是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。
集成测试的策略：当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。
17、 决定软件可维护性的因素：⑴可理解性;⑵可测试性;⑶可修改性;⑷可移植性;⑸可重用性;
软件维护:是指在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程.软件维护 是软件生命周期的最后一个阶段,也是持续时间最长代价最大的一个阶段。 软件的可维护性可以定义为:维护人员理解,改正和改动软件的难易程度。
18、 对象：是对现实世界实体的正确抽象，它是由描述内部状态表示静态属性的数据，以及可以对这些数 据施加的操作，封装在一起所构成的统一体。对象之间通过传递消息互相联系，以模拟现实世界中不同事物彼此之间的联系。
对象的特点：①以数据为中心;②对象是主动的;③实现了数据封装;④本质上具有并行性;⑤模块 工程规模：此系统中应包含接受模块和信息处理与输出模块。 可能的解决方案及其评价 从三方面研究每种解决方法的可行性：
(1).技术可行性 使用现在的技术完全可以实现该系统
(2).经济可行性 这个系统的开发成本不高，节省的经济资源以及经济消息能够超过该系统的开发成本 (3).操作可行性 该教学事务管理系统在校院的各个办公室都可以实现，操作人员为在校师生，所以不存在技术、能力问题。 推荐行动方针 通过从技术，经济，可操作三方面的研究，分析的出结论，此系统是可行的。 16.构成E-R图的基本要素是实体型、属性和联系，其表示方法为：
· 实体型(Entity)：用矩形表示，矩形框内写明实体名;比如学生张三丰、学生李寻欢都是实体。如果是弱实体的话，在矩形外面再套实线矩形。
· 属性(Attribute)：用椭圆形表示，并用无向边将其与相应的实体连接起来;比如学生的姓名、学号、性别、都是属性。如果是多值属性的话，再椭圆形外面再套实线椭圆。如果是派生属性则用虚线椭圆表示。
· 联系(Relationship)：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型(1 : 1，1 : n或m : n)。 比如老师给学生授课存在授课关系，学生选课存在选课关系。如果是弱实体的联系则在菱形外面再套菱形。(猜考画图，或25题) 第一章 软件工程介绍 软件的特性
1. 软件是设计开发的，而不是传统意义上的生产制造的。 2. 软件不会“磨损”。 3. 虽然整个工业向着基于构件的构造模式发展，然而大多数软件扔是根据实际的顾客需
求定制的。 计算机软件的七大分类：系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。
遗留系统发生系统演化的原因：1.软件需要修改其适应性，从而满足新的计算环境或者技术的需求;2.软件必须根据新的业务需求进行升级;3.软件必须扩展以具有与更多现代系统和数据库的协作能力;4.软件架构必须进行改建以适应多样化的网络环境。 软件神话：管理者，用户，从业者 软件的定义：程序、数据和文档。
软件工程的目的就是为开发高质量的软件产品提供一个工程框架。 第二章 过程综述
软件工程的三个要素：工具，过程，方法。
通用软件过程框架：沟通，策划，建模，构建，部署。
能力成熟度模型：第0级，不完全级;第1级，已执行级;第2级，已管理级;第三级，已定义级;第4级，已定量管理级;第5级，优化级。
第三章 过程模型
简述惯例框架包含的主要活动：沟通、策划、建模、构建、部署。 简述瀑布模型所包含的主要框架活动：策划、建模、构建、部署。
简述瀑布模型在实际运用中所面临的问题(缺点)：“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行;用户常常难以清楚地给出所有需求;用户必须有耐心，等到系统开发完成。
演化过程模型产生的背景：业务和产品需求经常变化、严格的交付时间、了解了核心产品和系统需求后没有定义产品或系统扩展的细节问题
简述基于原型开发模型的软件开发过程：在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型(可运行的软件)，然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。 沟通-》快速策划-》建模快速设计-》构建模型-》部署交付品及反馈
简述原型开发的缺点：1.为了使原型尽快的工作，没有考虑软件的总体质量和长期的可
维护性。2.为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。3.开发过程不便于管理 统一过程的三个特点：用例驱动，以架构为核心，迭代并增量
简述统一过程(UP)的5个阶段的主要内容：起始，细化，构建，转换和生产 螺旋模型强调了其他模型均忽略了的(风险分析)
横切关注点的定义：一个信用卡处理系统的核心关注点是借贷/存入处理，而系统级的关注点则是日志、事务完整性、授权、安全及性能问题等许多关注点，我们叫它横切关注点 第四章 敏捷视角下的过程
软件工程的敏捷理念强调4个关键问题：1.具有控制力的自我组织团队对所开展工作的重要性;2.团队成员之间、开
发参与者与客户之间的交流与合作;3.对“变更代表机遇”的认识;4.以及强调快速软件交付以让客户满意。
简述极限编程(XP)过程模型所包含的4个主要框架活动：策划，设计，编码，测试 第五章 系统工程
计算机系统的6个系统要素：软件，硬件，人员，数据库，文档，规程
Hatley-Pirbhai建模方法：用户界面，输入，系统功能和控制，输出，维护和自检 系统环境图(System Context Diagram)的表示方法(实例) 第六章 需求工程
需求工程的过程：起始，导出，精化，协商，规格说明，确认和管理
在项目(起始)阶段，软件工程师会询问一些似乎与项目无直接关系的问题，目的是对
问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效果建立基本的谅解。
为什么导出需求这么困难：范围问题，理解问题，易变问题。 用例的定义：讲述了能表达主题场景的故事：最终用户如何在一特定环境下和系统交互
在需求工程的导出阶段，三个主要的需求收集活动是：主持人会议、QFD和用户场景开发 第七章 构建分析模型
分析模型在系统描述和设计模型之间建立桥梁。
分析模型必须实现的目标：1。描述客户需要什么;2。为软件设计奠定基础;3。定义在软件完成后可以被确认的一组需求。
分析模型的所有元素都可以直接跟踪到设计模型。
分析模型的4个元素：基于场景的元素，面向信息流的元素，基于类的元素，行为元素 UML泳道图是活动图的一种变形，可以让建模人员表示用例所描述的活动流，同时指示哪个参与者或分析类对活动矩形所描述的活动负责。
UML状态图为每个类表现活动状态和导致这些活动状态变化的事件 UML顺序图说明事件如何引发一个对象到另一个对象的转移
简述CRC建模的内容：CRC提供了一个简单方法，可以识别和组织与系统或产品需求相关的类。 使用UML类图来举例说明组合和聚合之间的区别 使用UML类图举例说明关联和依赖之间的区别
系统分析的经验原则(1) 系统开发是面向客户的，应从客户的角度考虑。
(2) 诸如系统开发生命周期之类的产品更新换代机构应该在所有的信息系统开发项目中建立起来。
(3) 信息系统开发的过程并不是一个顺序的过程，它允许步骤的重叠和倒转等。 (4) 如果系统的成功可能性受到很大限制时，应取消整个项目。 (5) 文档材料是系统开发生命周期中重要的可递交成果，应加以重视 第八章 设计工程
简述良好设计的三个特征：1。设计必须实现所有包含在分析模型中的明确需求，而且必须满足客户期望的所有隐含需求;2。对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可理解的指南;3。设计必须提供软件的全貌，从实现的角度说明数据域、功能域和行为域。 设计模型包含的四种元素是什么：数据/类设计、体系结构设计、接口设计、构建级设计
软件体系结构的定义：软件的整体结构和这种结构为系统提供概念上完整性的方式 模块应该详细说明且精心设计以求在某个模块中包含的信息不被不需要这些信息的其他模块访问
重构的定义：是使用这样一种方式改变软件系统的过程：不改变代码设计的外部行为而是改进其内部结构
举例说明逐步求精
框架和设计模式之间的区别：框架能使应用程序的开发简单，价格低廉，但是开发框架不
是一件容易的事。它是一个需要领域和设计经验的反复过程。设计模式可以简化这个过程，因为它提供了对过去经验的抽象。框架能高度抽象同一领域内的问题，进而降低开发难度和强度。因此，在软件开发过程中把框架和模式配合起来使用，可以极大地提高软件的重用。框架是软件，而设计模式是软件的知识 第九章 进行体系结构设计
简述软件体系结构的作用：1。软件体系结构的表示有助于对计算机系统开发感兴趣的各方(共利益者)开发交流;2。体系结构突出了早期设计决策，这些决策对随后的所有软件工程工作有深远的影响，同时对系统作为一个可运行实体的最后成功有重要作用。3。体系结构“构建了一个相对小的，易于理解的模型，该模型描述了系统如何构成以及其构建如何一起工作”
软件体系结构的典型分类：以数据为中心，数据流体系结构，调用和返回体系结构，面向对象体系结构，层次体系结构(以图例来说明)
体系结构环境图所包含的要素，以图例来说明 第十二章 软件测试策略
简述软件测试策略的螺旋模型：单元测试，集成测试，确认测试，系统测试
简述单元测试中驱动程序和桩程序的作用：驱动程序只是一个“主程序”，它接收测试用例数据，将这些数据传递给(将要测试的)构件并打印相关结果。桩程序的作用是替换那些从属于将要测试的构件或被其调用的构件。 集成测试的两种方式：一步到位和增量集成
试以图例描述自顶向下集成测试方法的过程 简述确认测试的两种主要方法：α测试和β测试 系统测试的主要方法：恢复测试，安全测试，压力测试，性能测试 三种调试方法：蛮力法，回溯法，原因排除法 第十三章 测试战术
好的测试所具有的特性：1。好的测试具有较高的发现错误的可能性;2。好的测试是不冗余的;3。好的测试应该是“最佳品种”4。好的测试应该既不太简单也不太复杂。
黑盒测试的定义：所谓黑盒测试是指在完全不考虑程序的内部结构和处理过程的前提下,在程序接
口进行的测试,它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接受输入数据产生正确的输出信息,并且保持外部信息的完整性.因此,又称为功能测试。
白盒测试的定义：所谓白盒测试就是在知道产品内部工作过程或程序内部结构和处理过程的前提下, 检验产品内部动作是否按照规格说明书的规定正常进行或按照程序内部的逻辑测试程序,检验程序中的每条通路是否都能按照预定要求正确工作的测试方法.因此白盒测试又称为结构测试或逻辑测试。 基本路径测试的环复杂度计算方法和独立路径集合的识别V(G)=E-N+2;其中E为流图
的边数，N为流图的结点数。 控制结构测试的3个主要方法：条件测试，数据流测试，循环测试 黑盒测试的两个主要方法：等价类划分，边界值分析 类级可应用的测试方法：随机测试，划分测试 面向对象的类级划分测试的主要方法：基于状态划分，基于属性划分，基于类别划分
以图例说明从行为模型导出测试用例 第十四章 产品度量
软件度量为产品内部属性的质量评估提供了一种(定量)方法，从而可以是软件工程师在产品开发出来之前进行质量评估
软件测量的5个主要活动：公式化，收集，分析，解释，反馈
面向目标的软件测量(GQM范型)的内容：1。确定特定过程活动的明确的测量目标或将要评估的产品特性;2。定义一组必须回答的问题以达到目标;3。确定被良好公式化的度量以帮助回答这些问题
有效软件度量的属性1。简单的和可计算的2。在经验上和直觉上有说服力3。一致的和客观的4。单位和量纲的使用是一致的。5。编程语言的独立性6。高质量反馈的有效机制
第五篇：软件工程导论知识总结范文
软件工程导论 第一章:软件工程学概论
1. 软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
2. 概括的说，软件危机包括两方面问题：如何开发软件已满足日益增长的需求;如何维护数量不断膨胀的已有软件。 3. 软件危机的典型表现：对软件开发成本和进度的估计常常很不准确;用户对“已完成的”软件系统不满意的现象经常发生;软件的质量往往靠不住;软件常常是不可维护的;软件通常没有适当的文档资料;软件成本在计算机系统总成本中所占的比例逐年上升;软件开发生产率提高的速度，远远跟不上计算机应用迅速不及深入的趋势。
4. 产生软件危机的原因：在软件开发和维护的过程中存在这么多严重的问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
5. 在实践过称中或多或少的采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。
6. 软件不同与硬件，他是计算机系统中的逻辑部件而不是物理部件。
7. 软件不同于一般程序，他的一个显著特点是估摸庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
8. 软件本身独有的特点确实给开发和维护带来一些客观困难。 9. 对用户要求没有完整的认识就匆忙着手编写程序是软件开发功臣失败的主要原因之一。
10. 一个软件从定义、开发、使用和维护，直到最终被遗弃，要经历一个漫长的时期，通常把软件经历的这个漫长的时期称为生命周期。
11. 软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执的指令序列;数据是使程序能够适当的处理信息的数据结构;文档是开发、使用和维护程序所需要的图文资料。
12. 软件工程是指导计算机软件开发和维护的一门工程学科。 13. 软件工程是：把系统的、规范的、可度量的途径应用与软件开发、运行和维护过程，也就是吧工程应用与软件;研究前面所提到的途径。
14. 软件工程的本质特性：软件工程关注与大型程序的构造;软件工程的中心课题是控制复杂性;软件经常变化;开发软件的效率非常重要;和谐的合作是开发软件的关键;软件必须有效地支持他的用户;在软件工程领域中通常由具有一种文化背景的人体另一种具有文化背景的人创造产品。
15. 软件工程的基本原理：用分阶段的生命周期计划严格管理;坚持进行阶段评审;实行严格的产品控制;采用现代程序设计技术;结果应能清楚的审查;开发小组的人员应该少而精;承认不断该井软件工程的必要性。 16. 软件工程包括技术和管理两方面得内容，是技术与管理紧密结合所形成的工程学科。
17. 通常把在软件生命周期全过程中使用的一套技术方法的集合称为方法学，也称之为范型。 18. 方法学三要素：方法、工具和过程。
19. 传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
20. 面向对象方法学与传统方法学相反，它吧数据和行为看成是同等重要的，他是一种一数据为主线，把数据和对数据的操作紧密的结合起来的方法。
21. 棉线对象方法学的要点:把对象作为融合了数据及在数据上的操作行为的统一的软件构件;把所有的对象都划分成类;按照父类与子类的关系，把若干相关类组成一个层次结构的系统;对象彼此间仅能通过发送消息互相联系。
22. 传统方法学强调自顶而下顺序的完成软件开发的各项任务。 23. 面向方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。
24. 面向对象范型的优点：降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作;促进了软件重用。 25. 面向对象方法特有的继承性和多态性，进一步提高了可重用性。 26. 软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干个阶段。
27. 软件定义时期的任务：确定软件开发工程必须完成的总目标;确定工程的可行性;导出实现工程目标应该采用的策略及系统必须完成的功能;估计完成该工程需要的资源和成本，并且制定工程进度表。
28. 软件定义时期分为三个阶段：问题定义、可行性研究、需求分析。
29. 开发时期阶段组成：总体设计、详细设计、编码和单元测试、综合测试。
30. 维护时期的树妖任务是使软件持久的满足用户的需求。 31. 最基本的测试是集成测试和验收测试。
32. 通常的维护活动：改正性维护;适应性维护;完善性维护;预防性维护。
33. 软件过程是为了获得高质量软件所需要完成的一系列框架，它规定了完成各项的任务工作步骤。
34. 把过程定义为：使用资源将输入转化为输出的活动所构成的系统。
35. 系统是相互关联或相互作用的一组要素。
36. 过程定义了运用方法的顺序、应该交付的文档资料、为保证软件件质量和协调变化所需要的管理措施，以及标志软件开发各个阶段任务完成的里程碑。 37. 瀑布模型一直被广泛采用的生命周期模型，仍然是软件工程中应用的最广泛的过程模型。
38. 瀑布模型的特点：阶段间具有顺序性和依赖性;推迟延迟的观点;质量保证的观点。
39. 瀑布模型的优点：可强迫开发人员采用规范的方法;严格的规定了每个阶段必须提交的文档;要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
40. 所谓快速原型是快建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终端产品能完成的功能的一个子集。 41. 快速原型模型的主要优点：不带反馈环，软件产品的开发基本上是线性顺序进行的。 42. 增量模型也称渐进模型。
43. 增量模型的优点：能在短时间内向用户提交可完成部分工作产品;逐步增加产品功能可以使用户有充裕的时间学习和适应新产品从而减少一个全新的软件可能给客户组织带来的冲击。 44. 螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。可以把它看作是在每个阶段都增加了风险分析过程的快速模型。
45. 螺旋模型的优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件来发的一个重要目标;减少了过多测试或测试不足所带来的风险;更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
46. 喷泉模型是典型的面向对象的软件过程模型之一。 47. “喷泉”这个词体现了面向对象开发过程迭代和无缝的特性。
48. Ratioanal统一过程是一种完整而且完美的软件过程。 49. RUP软件开发生命周期是一个二维的生命周期模型。 50. RUP九个核心工作流：业务建模;需求;分析与设计;实现;测试;部署;配置与变更管理;项目管理;环境。
51. RUP工作阶段：初始阶段、精化阶段、构建阶段、移交阶段。 52. 极限编程：是敏捷过程中最富盛名的一个，“极限”含义是指把好的开发实践运用到极致。
53. 微软过程生命周期：规划阶段、设计阶段、开发阶段、稳定阶段、发布阶段。
54. 面向对象方法=对象+类+继承+用消息通信
可行性研究
1. 典型的可行性研究过程步骤：复查系统规模和目标;研究目前正在使用的系统;导出新系统的高岑逻辑模型;进一步定义问题;导出和评论供选择的解法;推荐行动方针;草拟开发计划;书写文档提交审查。
2. 系统流程图是概括的描绘物理系统的传统工具。他的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件(程序、文档、数据库、人工过程等)。
3. 系统流程图基本符号：处理(矩形)、输入输出(平行四边形)、连接(圆形)、换页连接(向下的五边形箭头)、数据流(箭头)。
4. 面对复杂的系统时，一个比较好的方法是分层次的描绘这个系统。
5. 数据流图(DFD)是一种图形化技术，他面会信息流和数据从输入移动到输出的过程中所经受的变换。 6. 数据流图是系统逻辑功能的图形表示。
7. 数据流图符号：正方形(或立体型)表示数据的源点或终点;圆角矩形(或圆形)代表数据变换的处理;开口矩形(或两条平行线)代表数据存储;箭头代表数据流，即特定数据流动的方向。 8. 数据存储和数据流都是数据，仅仅所处的状态不同，数据存储是处于静止状态的数据，数据流是处于运动中的数据。 9. 画数据流图的基本目的是利用它作为交流信息的工具。另一个主要的用途是作为分析和设计的工具。
10. 数据字典是关于数据信息的集合，也就是对数据流图中包含的所有元素的定义的集合。、
11. 数据流图和数据字典共同构成系统的逻辑模型，没有数据字典，数据流图就不严格，然而没有数据流图，数据字典也难以发挥作用。 12. 数据字典4类元素的定义组成：数据流;数据流分量(即数据元素);数据存储;处理。
13. 数据字典中记录数据元素的下列信息：一般信息;定义;使用特点;控制信息和分组信息。
14. 数据元素组陈的方式：顺序、选择、重复，可选。 15. “=”:等价于或定义为;“+”;和(即连接两个分量);“【】”：或(即，从方括弧内列出的若干分量中选择一个)，通常用“|”号隔开供选择的分量;“{}”：重复;“()”：可选。
16. 数据字典最重要的用途是作为分析阶段的工具。
17. 卡片形式书写数据字典：开片：名字、别名、描述、定义、位置。
18. 软软开发成本主要表现为人力消耗。
19. 估算技术：代码行技术;任务分解技术;自动估算成本技术。 20. 成本/效益分析地第一步是估计开发成本、运行费用和新系统将带来的经济效益。
21. 通常用利率的形式表示货币的时间价值。
22. 通常用投资回收期衡量一项开发工程的价值。所谓投资回收期就是使累计的经济效益等于最初投资所需要的时间。 23. 衡量工程价值的另一项经济指是工程的纯收入，也就是在整个生命周期之内系统的累计经济效益与投资之差。 需求分析 1. 软件系统的综合要求：功能需求;性能要求;可靠性和可用性需求;出错处理需求;接口需求;约束;你想需求;将来可能提出的要求。
2. 分析系统的数据要求，这是软件需求分析的一个重要任务，它通常采用建立数据模型的方法。
3. 复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。
4. 访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。他有两种基本形式，分别是正式的和非正式的访谈。
5. 软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。
6. 结构分析方法就是面向数据流自顶而下逐步求精进行需求分析的方法。
7. 面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同表示问题，提出解决方案要素，商讨不同方案并指定基本要求。
8. 面向团队的需求方法的优点：开发者与用用户不分彼此，齐心协力，密切合作;即时讨论并求精;有能导出规格说明的具体步骤。
9. 快速建立软件原型是最准确、最有效、最强大的需求分析技术。他是快速建立起来的旨在演示目标系统主要功能的可运行的程序。
10. 构建原型的要点是，他应该实现用户看得见的功能，省略系统“隐含”功能。
11. 快速模型的特性：快速;容易修改。
12. 快随构建和修改原型的方法和工具：第四代技术;可重构的软件构件;形式化规格说明和原型环境。
13. 通常，模型是由一组图形符号和组织这些符号的规则组成。 14. 结构化分析实质上是一种创建模型的活动。
15. 通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，他是需求分析阶段得出的最主要的文档。 16. 通常用自然语言完整、准确、具体的描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求
17. 概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。
18. 数据模型包含三种续相互关联的信息：数据对象、数据对象的属性、数据对象彼此间相互连接的关系。 19. 联系：一对一;一对多;多对多。
20. ER图(实体-联系图)包含了实体、关系、属性，通常用矩形代表实体，用连接相关实体的菱形表示关系，用椭圆形或圆角矩形表示实体的属性，并用直线把实体与其属性连接起来。 21. 通常用“范式”定义消除数据冗余的程度。第一范式(1NF)数据冗余程度最大，第五范式(5NF)数据冗余程度最小。 22. 状态转换图(简称状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统地行为。
23. 状态是任何可以被观察到得系统行为模式，一个状态代表系统的一种行为模式。
24. 在状态图中定义的状态主要有：初态、终态和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。 25. 事件就是引起系统动作或转换状态的控制信息。
26. 状态图中，初态用实心圆表示，终态用一对同心圆表示，中间状态用圆角矩形表示。
27. 活动表语法格式：事件名(参数表)/动作表达式;三种事件：entry(进入该状态的动作), exit(退出该状态的动作), do(该状态下的动作)。
28. 事件表达式的语法格式：事件说明【守卫条件】/动作表达式;守卫条件为真时，状态转换发生。
29. 层次方框图用树形结构的一系列多层次的矩形框描绘的数据的层次结构。
30. Warnier图和层次方框图相似，W图也用树形层次结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的秒胡手段。
31. IPO图是输入、处理、输出图的简称。一种图形工具，能够方便的描绘输入数据、对数据的处理和输出数据之间的关系。 32. 验证软件需求的4个方面：一致性、完整性、现实性、有效性。
33. PSL/PSA(问题陈述语言/问题陈述分析程序)系统：功能：描述任何应用领域的信息系统;创建一个数据库保存对该信息系统的描述符;对描述符施加增加、删除和更改等操作;产生格式化的文档和关于规格说明书的各种分析报告。
34. PSL/PSA系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和羡慕管理共8个方面描述信息系统。 第五章:总体设计
总体设计过程分为两个阶段: 1>.系统设计,确定系统的具体实现方案 2>.结构设计阶段,确定软件结构
总体设计的9个步骤: 1>.设想供选择的方案 2>.选取合理的方案 3>.推荐最佳方案 4>.功能分解 5>.设计软件结 6>.设计数据库 7>.制定测试计划 8>.书写文档 9>.审查和复查
书写文档(形成概要设计规格说明书): 1>.系统说明 2>.用户手册 3>.测试计划 4>.详细的实现计划 5>.数据库设计结果
模块是由边界元素限定相邻程序元素的序列,而且有一个总体标识符代表它.(模块式构成程序的基本构件) 根据模块数目和接口成本(模块间的联系成本)两个因素来决定模块的最适当数目. 抽象:就是抽出事物的本质特征而暂时不考虑他们的细节.(抽象层次的过程实际上也是逐步求精的过程). 抽象和求精是一对互补的概念,也是人类解决复杂问题时最常用,最有效的方法. 抽象使得设计者能够说明过程和数据，同时却忽略了低层细节，求精则帮助设计者在设计过程中逐步揭示出低层细节。
信息隐藏原理指出:应该这样设计和确定模块,使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说是不能访问的. 局部化,是指把一些关系密切的软件元素物理地放得彼此靠近,在模块中使用局部数据元素是局部化的一个例子. 模块独立性:使得每个模块完成一个相对独立的特定子功能,并且和其他模块之间的关系很简单. 模块的独立程序由两个标准度量：
1>.耦合:数据耦合，控制耦合，特征耦合，公共环境耦合，内容耦合
(尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合)
2>.内聚:功能内聚,信息内聚,通信内聚,过程内聚,时间内聚,逻辑内聚,偶然内聚. 启发式规则: 1>.改进软件结构提高模块独立性 2>.模块规模应该适中
3>.深度,宽度,扇出和扇入都应适当 4>.模块的作用或应该在控制域之内 5>.力争降低模块接口的复杂程度 6>.设计单入口单出的模块 7>.模块功能应该可以预测
层次图和HIPO图,结构图(描绘软件结构的图形工具).结构图:用尾部是空心圆表示传递的是数据,实心圆表示传递的是控制信息. 面向数据流的设计方法:把信息流映射成软件结构,信息流的类型决定了映射方法信息流类型:1>.交换流,2>.事务流 第六章:详细设计
在设计人机界面过程中,遇到的4个问题: 1>.系统影响时间(长度,易变性) 2>.用户帮助设施(集成的/附加的帮助设施) 3>.出错信息处理
4>.命令交互(一个命令对应单一的功能) 人机界面设计指南: 1>.一般交互指南涉及信息显示,数据输入和系统整体控制,因此这类指南是全局性的,忽略它们将承担较大的风险. 2>.信息显示指南:用文字,图形和声音按位置移动和大小,使用颜色,分辨率和省略
3>.数据输入指南:选择命令,输入数据和向系统提供输入
过程设计的 工具: 1.程序流程图
程序流程图的缺点: 1>.程序流程图本质上不是逐步求精的好工具,它诱使程序员过早的考虑程序的控制流程,而不去考虑程序的全局结构 2>.程序流程图中用箭头代表控制流,因此程序员不受任何约束,可以完全不顾结构程序设计的精神,随意转移控制 3>.程序流程图不容易表示数据结构 2.盒图 盒图的特点:克服了程序流程图的缺点,但自身缺点是不易扩展
1>.功能域(即一个特定控制结构的作用域)明确,可以从盒图上一眼就看出来 2>.不能任意转移控制
3>.很容易确定局部和全程数据的作用域
4>.很容易表现嵌套关系,也可以表示模块的层次结构
3.PAD图(问题分析图):是用二维树形结构的图来表示程序的控制流.将这种图翻译成程序代码比较容易
4.判断表:能够清晰的表示复杂的条件组合与应做的动作之间的对应关系.(在多重嵌套的条件选择时) 5.判定树:容易绘制,易于理解,但不能判断哪些组合不可能,叶子多
6.过程设计语言(伪码):是用正文形式表示的数据和处理过程的设计工具. 过程设计语言(PDL)的优点: 1>.可以作为注释直接插在源程序中间
2>.可以使用普通的正文编辑程序或文字处理系统,很方便的完成PDL的书写和编辑工作
3>.已经有自动处理PDL的程序存在,而且可以自动由PDL生成程序代码
程序复杂程序的定量度量 1.流图:只要顺序执行俄流向都能合并,忽略箭头,每个节点都是连通的(用圆表示节点代表一条或多条语句,箭头线成为边,代表控制流) 由边和结点围成的面积为区域,当计算区域数时应该包括图形外部为被围起来的那个区域. 计算环形复杂度的方法: 1>.流图的区域数等于环形复杂度
2>.流图G的环形复杂度V(G)=E-N+2,其中E是流图中边的条数,N是节点数
3>.流图G的环形复杂度V(G)=P+1,其中P是流图中判定节点的数目 第七章: 1.通常把编码和测试统称实现
2.所谓编码就是把软件设计结果翻译成某种程序设计语言书写的程序
3.为了使程序容易测试和维护以减少软件的总成本，所选用的高级语言有理想的模块化机制，以及可读性好的控制结构和数据结构。为了便于调试和提高软件可靠性，语言特点应该是编译程序能够多地发下程序中错的错误，为了降低软件开发和维护的成本，选用的高级语言应该有良好的独立编译机制。 4.选择程序设计语言的使用标准： 1).系统用户的要求 2).可以使用的编译程序 3).可以得到的软件工具 4).工程规模 5).程序员的知识
6).软件可移植性要求 7).软件的应用领域 5.编码的风格: 1).程序内部的文档 2).数据说明 3).语句说明 4).输入输出
5).效率(通算法提高和决定的) 提高效率 ：
1). 效率是性能的要求，因此应该在需求分析阶段效率方面的要求
2). 效率是靠设计来以高的
3). 程序的效率和程序的简单程序是一致的 6.讨论效率问题： 1).程序运行时间 2).存储器效率 3).输入输出效率 软件测试基础： 1. 测试方法：
1).黑盒：如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用。
2).白盒: 如果知道产品的内部工作过程，可以通过测试来检验产品内部动作是佛感召规格说明的规定正常进行
2.黑盒测试是在程序接口进行的 黑盒测试(功能测试) 3.测试步骤： 模块测试-》子系统测试-》系统测试-》验收测试-》平行运行
4.测试阶段的信息流： 1》软件配置 2》测试配置 5.单元测试主要使用白盒测试技术，而且对多个模块的测试可以并行的进行 6.测试重点： 1).模块接口 2).局部数据接口 3).重要的执行通路 4).出错处理器 5).边界条件
7.软件测试：为了发现错误而执行代码过程 8.程序调试：为了诊断和改正程序中错误的错误代码 9.集成测试是测试盒组装软件的系统化技术
10.验证指的是保证软件正确地实现了某个特定要求的一系列活动，而确认指的是为了保证软件确实满足了用户需求而进行的一系列活动
11.需求分析阶段产生的软件需求规格说明书。 第八章: 软件维护：在软件交付使用之后，为了改正错误或者满足新的需要而修改的过程
改正性维护：把诊断和改正错误的过程称为改正性维护
适应性维护：为了和变化了的环境适当的配合而进行的修改软件的活动是既必要而又经常性的活动
完善性维护：在软件使用的过程中，用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见
预防性维护：为了改进未来的标准性或可靠性或为了给未来奠定更好的基础而修改软件
软件维护的过程： 1.维护组织 2.维护报告：
⑴满足维护要求表中提出的要求所需要的工作量 ⑵维护要求的性质 ⑶这项要求的优先次序 ⑷与修改有关的事后数据 3.维护的事件流 4.保存维护记录 5.评价维护活动: ⑴每次程序运行平均失败的次数 ⑵用于每一类维护活动的总人时数
⑶平均每个程序每种语言每种维护类型，所做的程序变动数 ⑷维护过程中增加或删除一个原语句平均花费的人时数 ⑸维护每种语言所花费的人时数 ⑹一张维护要求表的平均周转时间 ⑺不同维护类型所占的百分比
软件的可维护性的定义：维护人员理解改动改正或改进这个软件的难易程度
决定软件可维护的因素主要有： 1).可理解性 2).可测试性 3).可修改性 4).可移植性 5).可重用性
重用指同一事物不做修改或稍加改动就在不同环境中多次重复使用
以下一个方面可以提高软件的可维护性: 1).软件中可使用的可重用的构件越多，软件的可靠性越高，改正性维护需求需求就越少
2).软件中可使用的可重用的构件越多，适应性和完整性就越容易， 文档影响软件可维护性的决定因素
软件系统的文档可分为用户文档和系统文档
软件文档应满足下数要求: 1).必须描述如何使用这个系统 2).必须描述怎样安装和管理这个系统 3).必须描述系统需求和设计 4).必须描述系统的实现和测试
用户文档至少包含下数: 1).功能描述 2).安装文档 3).使用手册 4).参考手册 5).操作员指南
所谓系统文档只从问题定义需求说明到验收测试计划，这样一系列和实现有关的文档
可维护性是所有软件都应该具备的基本特点
代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素
配置复审在测试结束是进行正式的可维护性复审
配置复审的目的是保证软件配置的所有成分都是完整的，一致的和可理解的
为了便于修改和管理已经编目归档了, 软件在工程过程模型的六类活动： 1).库存目录分析 2).文档重档 3).逆向工程 4).代码重构 5).数据重构 6).正向工程 第九章: 面向对象方法学的出发点和基本原则是尽可能模拟人类习惯的思维方式,使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法于过程，也就是使描述问题的问题空间与实现解决的解决空间在结构上尽可能一致
面向对象方法学具有以下4个要点: 1).认为客观世界是又各种对象组成，任何事物都是对象 2).把所有对象都划分成各种对象类，每个对象都定义了一组数据和一组方法
3).按照子类与父类的关系把若干个对象类组成一个层次结构的系统
4).对象彼此之间仅能通传递消息互相联系
面向对象方法学的优点有: 1).与人类习惯的思维方法一致 2).稳定性好 3).可重用性好
4).较易开发大型软件产品 5).可维护性好
由于以下因素使得面向对象方法所开发的软件可维护性好: 1).稳定性比较好 2).较容易修改 3).容易理解 4).易于测试和调试
面向对象方法学中的对象是由描述该对象性的数据以及可以对这些数据施加的所有操作封装在一起所构成的同意体
对象是封装了数据结构以及施加在这些数据结构上的操作的封装体
对象有如下基本特点: 1).以数据为中心 2).对象是主动的 3).实现了数据封装 4).本质上具有并行性 5).模块独立性好
类就是对具有相同数据和相同操作的一组相似对象的定义
类是支持继承的抽象数据类型而对象就是类的实例
实例就是由某个特定的类所描述的一个具体的对象
消息是要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明
消息由三部分组成 1).接受消息对象 2).消息选择符 3).零个或多个变元
方法就是对象所执行的操作，也就是类中所定义的服务
属性就是类中所定义的数据，它是对客观世界实体所具有的性质的抽象
对象具有封装性的条件如下: 1).有一个清晰的边界 2).有确定的接口 3).受保护的内部实现
继承是指直接获得已有的性质和特征而不必重复定义它们
多态性是指子类对象可以像父类对象那样使用同样的消息既可以发送给父类对象也可以发送给子类对象
函数重载是指同一个作用域内的若干个参数特征不同的函数可以使用相同的函数名字
运算符重载是指同一个运算符也可以施加于不同类型的操作数上面
所谓模型就是为了理解事物而对事物做出的一种抽象，是对事物一种无歧义的书面描述
用面向对象方法开发软件通常需要建立3中模式: 1).描述系统数据结构的对象模型 2).描述系统控制结构的动态模型 3).描述系统的功能的功能模型
关联是双向的，可在一个方向上为关联起一个名字，在另一个方向上起另一个名字
聚集也称聚合，是关联的特例聚集表示类与类之间的关系，是整体与部分的关系
共享聚集在聚集关系中处于部分个对象可同时参与多个属于整体对象的构成
泛化关系就是通常所说的继承关系，是通用元素和具体元素之间的一种分类关系
没有具体对象的类称为抽象类
预定义的类约束有四种: 1).多重 2).不相交 3).完全 4).不完全
多重继承指的是一个子类可以同时多次继承同一个上层基类
依赖关系描述两个模型元素之间的语意连接关系，其中一个模型元素是独立的，另一个模型元素不独立，它依赖于独立的独立的模型元素
当对同一个事物在不同抽象层次上描述时这些描述之间具有细化关系
细化用来协调不同模型之间的关系，表示各个开发阶段不同抽象层次之间的相关性 第十三章：
管理:通过计划组织和控制等一系列活动,合理地配置和使用各种资源,以达到既定目标的过程. 软件项目管理贯穿于软件的整个生命周期之中. 软件管理项目过程从一组项目计划活动开始,而制定计划的基础是工作量估算和完成期限估算.为了使估算项目的工作量和完成期限,首先需要估算软件的规模. 度量软件规模的技术: 1>.代码行技术:比较简单的定量估算软件规模的方法. 2>.功能点技术:依据对软件信息域特性和软件复杂性的评估结果估算软件规模,用功能点(FP)为单位. 信息域的五个特性:输入项数,数出项数,查询数,主文件数,我外部接口数. 估算功能点的步骤: 1>.计算未调整的功能点数UFP 2>.计算技术复杂性因子TCF 3>.计算功能点数FP 工作量：软件规模(KLOC或FP)的函数。单位：人月. 工作量估算常用模型：静态单变量模型，动态多变量模型，COCOMO2模型. COCOMO2构造性成本模型，给出了三个层次的软件开发工作量估算模型：
1>.应用系统组织模型：主要用于估算构建原型的工作量。 2>.早期设计模型：适用于体系结构设计阶段。
3>.后体系结构模型：适用于完成体系结构设计之后的软件开发阶段。
成本因素分为：产品因素、平台因素、人员因素、项目因素。 COCOMO2使用的5个分级因素：项目先例性、开发灵活性、风险排除度、项目组凝聚力、过程成熟度。
工程网络是系统分析和系统设计的强有力的工具，用箭头表示作业(即消耗资源又需要持续一定时间),用圆圈表示事件(并不消耗时间和资源). 制定进度计划的工具有Gantt图和工程网络。
机动时间=它结束事件的最迟时刻-它开始事件的最早时刻-持续时间. 人员组织： 1>.民主制程序员组
2>.主程序员组(特性：专业化、层次化) 3>.现代程序员组
软件质量：软件与明确的和隐含的定义的需求相一致的程序.具体地说是：软件与明确的叙述的功能和性能需求，文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度. 软件质量保证措施：(软件复审是最重要的之一) 1>.基于非执行的测试 2>.基于执行的测试 3>.程序正确性证明
正式技术复审包括走查和审查.走查有两种方式：参与者驱动法，文档驱动法。审查的基本步骤：综述，准备，审查，返工，跟踪。
软件配置管理员是应用于整个软件过程中的保护性活动，是在软件整个生命期内管理变化的一组活动。目标是使变化能够更正确且更容易被适应，在需要修改软件时减少为此而花费的工作量。
能力成熟度模型是改进软件过程的有效策略，以增量方式逐步引入变量，明确定义了5个成熟度级。一个软件开发组织可用一系列小的改良性步骤买入更高的成熟度等级。