软件工程重点整理.docx
《软件工程重点整理.docx》由会员分享，可在线阅读，更多相关《软件工程重点整理.docx（22页珍藏版）》请在冰点文库上搜索。
软件工程重点整理
软件工程
第一章
1.软件=程序+数据+文档
2.软件危机及表现：
二十世纪六十年代中期，在美国就显现了软件危机（SoftwareCrisis），这种危机表此刻研发大型软件时，软件开发的本钱增大、进度延期、保护困难和质量得不到保障。
所谓软件危机，确实是在软件开发和保护进程中所碰到一系列难以操纵的问题。
3.软件工程概念：
权威杂志IEEE对软件工程的概念是：
软件工程是将系统化的、严格约束的、可量化的方式，应用于软件开发、运行和保护中去。
软件工程大师RogerSPressman对软件工程的概念是：
软件工程是一个进程、一组方式和一系列工具。
软件工程是研究软件开发和软件治理的一门工程学科。
4.软件工程大体原理：
（1）用分时期的生命周期打算严格治理软件开发。
时期划分为打算、分析、设计、编程、测试和运行保护。
（2）坚持进行时期评审。
上一时期评审不通过，就不能进入下一时期开发。
（3）实行严格的产品版本操纵。
（4）采纳现代程序设计技术。
（5）结果应能清楚地审查。
因此，对文档要有严格要求。
（6）开发小组的成员要少而精。
（7）要不断地改良软件工程实践的体会和技术，要与时俱进。
上述七条原理，尽管是在面向进程的程序设计时期（结构化时期）提出来的。
可是，直到今天，在面向元数据和面向对象的程序设计新时期，它仍然有效。
（8）二八定律
5.软件工程三要素：
适应上，人们常常把软件工程的方式（开发方式）、工具（支持方式的工具）、进程（治理进程）称为软件工程三要素。
6.4种开发方式的比较：
7.面向流程分析，确实是面向流程进行需求分析。
8.面向元数据设计，确实是面向元数据进行概要设计。
9.面向对象实现，确实是面向对象进行详细设计和编程实现。
10.面向功能测试，确实是面向功能进行模块测试、集成测试、Alpha测试和Beta测试。
11.面向进程治理，确实是面向软件生命周期进程，对软件生命周期各个时期进行进程治理与进程改良。
12.软件工程中的三类治理进程：
第二章
1.瀑布模型的特点：
（1）里程碑或基线驱动，或说文档驱动。
（2）进程逆转性很差或说不可逆转，因为依照上游的错误解在下游进行发散性传播的原理，因此逆转将会延误工期，增加本钱，造成重大损失。
2.迭代模型的四个时期：
（1）初始时期。
本时期要紧工作是确信系统的业务用况和概念项目的范围。
（2）精化时期。
本时期要紧工作是分析问题域、细化产品概念，概念系统的构架并成立基线，为构建时期的设计和实施工作提供一个稳固的基础。
（3）构建时期。
本时期要紧工作是反复地开发，以完善产品，达到用户的要求。
（4）产品化（移交）时期。
本时期要紧工作是将产品交付给用户，包括安装、培训、交付、保护等工作。
3.简述瀑布模型、增量模型、迭代模型、原型模型、XP等模型的优缺点。
序号
模型名称
优点
缺点
适用范围
1
瀑布模型
简单好学
逆转性差
面向过程开发
2
增量模型
可以分阶段提交
有时用户不同意
系统可拆卸和组装
3
迭代模型
需求可变
风险大
有高素质软件团队
4
原型模型
开发速度快
不利于创新
已有产品的原型
5
螺旋模型
需求可变
建设周期长
庞大、复杂、高风险项目
6
喷泉模型
提高开发效率
不利于项目的管理
面向对象开发
7
XP模型
提高开发效率
不适合大团队、大项目
小团队，小项目
第三章
1.什么是定单软件，什么是非定单软件？
答：
软件项目（或产品）来源有两个渠道
“非定单软件”：
通过市场调研以后，以为某产品将会有庞大的市场空间，而软件公司在人力资源、设备资源、抗击风险、资金和时刻上都具有开发该产品的能力，于是决定立项。
“定单软件”：
与固定的用户签定软件开发合同
2.下达任务的机会及三个条件，
（1）软件企业已签定了项目《合同》；
（2）《立项建议书》已通过了项目评审；
（3）作为特殊情形，软件组织的上级下达了某项目的指令性软件开发打算。
例如：
由跨组织跨部门的某个大系统项目，它的系统整体设计组分派给软件的需求。
3.下达任务书的三个条件
第四章
1．需求分析概念
1997年,IEEE软件工程标准辞汇表中概念需求为：
（1）.用户解决问题或达到目标所需的条件或能力（Capability）。
（2）.系统或系统部件要知足合同、标准、标准或其它正式规定文档所需具有的条件或能力。
（3）.一种反映上面
（1）或
（2）所描述的条件或能力的文档说明。
2.需求分析什么缘故重要
需求分析专门重要。
这是因为：
（1）.许多大型应用系统的失败，最后均归结到需求分析：
要么获取需求的方式不妥，使得需求分析不到位或不完全，致使开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不行，致使客户对需求不确认，或客户需求不断转变，一样致使设计、编码、测试无法顺利进行。
（2）.用户需求报告既是软件生命周期中的第一个里程碑，又是客户、软件开发人员、软件测试人员和项目治理人员四者一起工作的基线，是项目Alpha测试和Beta测试的准那么，是供方交付产品和需方验收产品的依据。
（3）.需求分析要占用整个软件开发时刻或工作量的30%左右。
（4）.需求获取中的错误，属于软件开发中的初期错误，将给项目成功带来极大风险，因为这些错误解在后续的设计和实现中进行发散式的传播。
依照以上四项缘故，IT企业的高层领导，对需求分析专门重视，常常派体会最丰硕的人员去作项目需求。
3.软件需求的三个层次：
软件需求包括三个不同层次：
高层领导的战略决策需求、中层治理的查询统计需求、基层人员的实时操作需求。
那个上中下三层需求，组成一个需求金字塔。
4.需求分析的目的、重点与难点
需求分析的重点是：
通过弄清业务流程和数据流程的手腕，达到与客户一起确信业务模型、功能模型、性能模型、接口模型的目标。
“开发者与客户达到完全一致的需求”，既是需求分析的目的，也是需求分析的难点
5.需求分析名词说明：
（1）基线：
基线是软件工作产品，它是要经内部和外部评审通过的，是下一时期工作的基础。
（2）里程碑：
里程碑是一个标记，只需要通过内部评审。
一个里程碑是一个检查点，但不必然对应一条基线。
（3）评审：
评审，是对软件工程产品质量的一次开会（或汇签）活动。
（4）审计：
审计，是复查评审活动程序的合法性，是不是按程序与标准进行等。
6.需求分析描述工具有：
（1）实体关系图。
（2）数据流图。
（3）用例图。
（会画用例图）
（4）活动图。
7.提取需求技术
（1）会谈
（2）场景
（3）原型
（4）实地观看
8.数据流图的符号：
9.“图书治理系统”顶层用例图：
10.“图书治理系统”的“借书记录”用例图
11.需求评审检查的项目包括：
（1）.需求是不是描述清楚，不存在歧义。
（2）.需求是不是是可量化的，可验证的。
（3）.需求间是不是存在冲突，和它们之间的依托关系。
（4）..非功能性需求是不是明确、合理。
（4）.需求是不是注明来源。
（5）.每一个需求是不是分派了唯一的标识。
12.同行评审，是软件工作产品验证的活动，其目的是为了及早和高效地从软件产品中识别并排除缺点。
与技术鉴定不同，同行评审的对象一样是部份软件产品，其重点在于发觉软件产品中的缺点。
13.所谓同行，是指在软件企业内部，与生产者在被评审的软件产品上有相同的开发体会和知识的人员。
第五章
1.软件策划，既是为软件开发者和治理者制定合理的工作打算，又是为软件项目跟踪和监控提供考核依据，属于软件治理和软件决策的范围，是项目领导以上人员的职责范围，是软件企业治理的重大事件之一。
2.软件策划的步骤
（1）估量软件工作产品的规模、工作量、费用及所需的资源
（2）制按时刻表（3）辨别和评估风险（4）与相关的组或人协商策划中的有关约定
3.软件策划的目标
（1）对供项目策划和跟踪用的三个软件估量已成立文档。
这三个估量是：
工作产品规模估量工作量及本钱估量运算机资源估量；
（2）软件项目活动和约定，是有打算的并巳成立文档。
那个地址的活动，包括开发活动和治理活动。
那个地址的约定，是指对项目的各类标准、标准、规程的约束；
（3）受阻碍的组和个人，同意他们对软件项目的约定。
4.所谓概念软件进程，确实是依照选定的生命周期模型，规定软件的开发时期，及每一时期的工作步骤和文档标准等内容
5.软件规模估量方式：
Delphi法、类比法、功能点估量法、无礼估量法
例题
7.软件策划文档确实是《软件开发打算书》
第六章
1.三个模型的概念及表示方式：
（1）功能模型FM（FunctionModel）实质上是用户需求模型，是描述系统能做什么，即对系统的功能、性能、接口和界面进行概念。
功能模型的表示方式为：
系统功能需求列表、性能需求列表、接口需求列表、界面需求列表。
UML规定要紧采纳“用例图”来描述功能模型。
（2）业务模型OM（OperationModel）实质上是业务逻辑模型，是描述系统在何时、何地、由何角色、按什么业务规那么去做，和做的步骤或流程，即对系统的操作流程进行概念。
在UML中，完整的业务模型由用例图、时序图、交互图、状态图、活动图来表述。
可是，时序图在表述中起到核心作用。
（3）数据模型DM（DataModel）实质上是实体或类的状态关系模型，即对系统的数据结构进行概念。
UML规定，要紧采纳“类图”来描述数据模型
第七章
1.模块独立性：
指每一个模块只完成系统要求的独立的子功能，并与其他模块的联系最少，且接口简单
2.
3.面向进程详细设计的描述工具五种：
1.程序流程图，图，3程序设计语言PDL，4.决策表，5,PAD
4.【例7-1】利用程序流程图，描述并打印N的阶乘，如下图
【例7-2】利用N-S图，描述并打印N的阶乘，如下图
【例7-3】利用程序设计语言描述打印N的阶乘。
读入N
置F的值为1，置M的值为1
当M<=N时，执行：
使F=F*M
使M=M+1
打印F
例7-5】利用PAD图描述打印N的阶乘，如图
5.习题
请用面向进程详细设计中的程序流程图，描述求
，和求
。
（1）利用程序流程图，描述求
。
（2）利用程序流程图，描述求
。
请用面向进程详细设计中的程序设计语言PDL和PAD图两种方式，来描述求
（N≥1）。
（1）程序设计语言PDL：
读入N
置S的值为0，置I的值为1
当I<=N时，执行：
使S=S+I*I*I
使I=I+1
打印S
（2）PAD图：
第八章
1.测试概念：
所谓测试，确实是通过必然的方式和工具，对被测试对象进行查验或考试，目的是发觉被测试对象具有某种属性或存在某些问题
2.软件测试不单单局限于测试程序代码，还能够测试软件数据与软件文档
3.软件调试是在有问题的程序中设置断点，通过观看断点处的程序运行状态，来缩小问题代码的范围，进而捕捉到问题的准确位置，并加以修正，最终解决问题。
4.静态测试要紧指不运行代码进行测试（例如代码走读），动态测试那么是指在运行代码中进行测试。
5.测试时期是在代码编写完成以后，先做单元测试，然后是集成测试，系统测试和验收测试。
6.
初期V模型
改良的V模型，如图实线部份
7.改良后的V模型，一是加入软件测试分析和测试设计时期，而是表现“及早”的思想。
改良后的V模型，形成了一个没有软件开发进程的，单独的软件测试V模型。
8.黑盒测试中，设计测试用例的五种方式：
（1）．等价类划分法；
（2）边界值分析法；
（3）错误推测法；
（4）因果图分析法；
（5）场景分析法。
9.黑盒测试的依据是软件的行为描述（要紧参考《产品说明书》、《业务说明书》或《需求规格说明书》等）；白盒测试方式的测定依据《详细设计说明书》。
10.语句覆盖（会设计），语句覆盖是最大体的覆盖，它要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
如表所示。
其中XX-V1-103-001代表一种测试用例的命名方式，它用“项目编号—项目版本号—模块号—测试用例编号”来表示用例序号。
语句覆盖用例参考表
从表中，能够看出一个测试用例就能够够使语句覆盖率达到100%。
现在，咱们是不是能够以为，白盒测试的任务完成了呢？
不能够，C判定中的两个条件“是/或”的关系，设计测试用例时只要知足判定为真即可，那么若是c的值取真，d的值能够是真也能够是假，假设d为零会引发系统异样，那么d取值的任意性就容易忽略这种情形，因此，100%的语句覆盖率也不能将C语句块进行完全测试。
11.设计测试用例
对应一个测试策略项，可能需要设计多个测试用例。
设计测试用例，能够采纳如下的一些技术：
（1）.对输入数据进行等价分派。
（2）.为每一个等价类，别离设计出通过测试用例和失败测试用例。
（3）.绘制状态转换图，分析状态测试，设计状态测试用例。
例如，分析出可能的状态，和从一种状态转入另一种状态所需的输入、条件、状态变量及输出结果。
（4）.从压力条件、重负条件两个方面考虑，设计测试用例，寻觅存在的竞争条件。
（5）.坚持二八定律，测试工作绝对不能安排得前松后紧。
（6）.积存体会，凭借直觉，设计测试用例。
12,习题
试论述软件测试V模型的思想、不足的地方和改良方式。
软件测试V模型的大体思想，如下图。
咱们能够初步了解，左侧是开发时期，右边是测试时期。
开发时期先从概念软件需求开始，然后要把这些需求不断地转换到概要设计和详细设计中去，最后形成程序代码。
测试时期是在代码编写完成以后，先作单元测试开始，然后是集成测试、系统测试和验收测试。
对V模型的进一步论述是：
当需求分析完成后，验收测试打算也应完成。
当概要设计完成后，系统测试打算也应完成。
当详细设计完成后，集成测试打算也应完成。
当编码完成后，单元测试打算也应完成。
可见，V模型提高了测试的时刻与地位。
软件测试V模型
以上的测试V模型，一样只适合于瀑布开发模型，假设对迭代开发模型，就显得不足了。
实际工作中，V模型只是提高了测试工作的地位，具体测试方式，仍然是黑白盒子法。
黑盒测试和白盒测试各自的依据是什么？
黑盒测试的依据是用户需求分析报告中的功能点列表、性能点列表和接口列表。
白盒测试的依据是软件详细设计说明书。
第九章
1.客户化是指依照客户的实际需求，对软件产品的功能、性能、接口做适当的改动。
初始化是指依照客户的实际情形，对软件产品的代码表（又称数据字典）进行初始化，即将客户的各类信息编码录入到相应的代码表中，如单位代码、部门代码、物资代码、设备代码、商品代码、科目代码、职位代码等。
2.习题软件项目与软件产品有什么不同？
软件产品是指不局限于特定业务领域、能被广大用户直接利用的软件系统，如操作系统、编译系统、工具系统、通用财务系统等。
软件项目是指针对特定业务领域、需提供业务流程重组与优化的软件系统，如MIS，ERP，电子商务、自动跟踪操纵系统等，它们一样叫做软件项目。
3.产品发布方式
软件企业市场与销售中心要通过各类媒体进行产品发布，以扩大阻碍、吸引客户、占据市场。
不管是哪一类软件产品，其产品发布的方式有下面几种：
（1）聘请各有关领导、新闻媒体记者和大客户代表，召开新闻公布会，宣布新产品的优势，描述其市场前景，现场演示介绍，厂商给佳宾和客人送产品资料和纪念品。
（2）在报纸、刊物、电视台、电台上做广告，宣传软件产品。
（3）在各类交易会、展览会、展览会上租用摊位，展现软件产品。
4.销售技术人员的工作职责及素养要求
5.所谓软件保护，确实是指软件项目或产品在安装、运行并交付给用户利用后，在新版本升级之前这段时刻里，软件厂商向客户提供的效劳工作。
6.软件保护分类
7.软件保护4个副作用
8.减少软件保护的副作用：
为了减少保护的工作量，避免保护的副作用，人们在长期的实践中积存了如下的体会：
（1）用CMMI框架体系的思想来改善软件企业的软件进程治理。
（2）在开发和保护中，尽可能利用CASE工具。
（3）保护完成后，必然要进行回归测试。
（4）自始至终维持文档、数据、程序三者的一致性。
第十章
1.CMMI有时期模型和持续模型两种表示形式
2.ISO9001与CMMI的联系与区别
答：
二者的相同点是：
CMMI和ISO9001标准都致力于质量和进程治理，都是为了解决一样的问题。
二者的不同点是：
（1）CMMI是动态的、开放的和持续改良的，它强调没有最好只有更好，强调不断改良，强调人在软件开发方面的主动性，超级适用于软件进程的改良。
CMMI模型要紧关注软件，它能解决“软件危机”那个世界性的问题。
（2）ISO9001是静态的质量操纵，只要达到20个关键指标或进程，就能够完成质量操纵，它更适用于硬件制造行业和第三产业（效劳行业）的质量操纵。
（3）CMMI与ISO9001的设计思路有不同：
CMMI是“专用”，ISO9001是“通用”。
ISO9001不覆盖CMMI，CMMI也不完全覆盖ISO9001。
3.配置治理活动的目标
配置治理活动的目标，确实是为了标识变更，操纵变更，确保变更，并向其他有关人员报告变更。
从某种角度讲，软件配置治理是一种标识、组织和操纵变更的技术，目的是使由变更而引发的错误将为最小，有效地保证软件产品的完整性和生产进程的可可视性。
4.配置治理中的存取操纵，通过配置治理效劳器中的三个库来实现
5.所谓软件质量，确实是供方提供的软件产品知足用户明确和隐含需求的能力特性的总和。
6.质量治理与操纵的三个层次
7.
（1）事前的预防方法：
制定软件进程开发标准和软件产品质量标准，对软件生产和治理人员进行这方面知识和技术的定向培训。
（2）事中的跟踪监控方法：
对软件进程和软件产品的质量操纵提供可视性治理。
（3）事后的纠错方法：
对软件工作产品和软件产品增强评审和检测。
评审是在宏观上把握方向，在微观上挑剔细节，找出不符合项。
检测是为了发觉Bug，更正错误。
这是软件质量保证进程的纠错方法。
软件质量保证方法，应以提早预防和实时跟踪为主，以事后测试和纠错为辅。
8.从五个方面来改良软件质量
（1）力图从编程语言上实现冲破。
已经从机械语言、汇编语言、面向进程的语言、面向元数据的语言进展到面向对象、面向构架的语言。
（2）力图从CASE工具或软件开发环境上实现冲破。
这些工具或软件开发环境有OracleDesigner，PowerDesigner，ERwin，Rose，业务基础平台等。
（3）力图从软件进程治理上实现冲破。
如CMMI，ISO9001，微软企业文化，IBM企业文化等。
（4）力图增强对软件工作产品的评审、审计和跟踪监控。
（5）力图从测试与纠错上实现冲破。
前后显现了各类测试方式、工具和纠错手腕。
9.项目是一次性的多任务工作，它具有确信的开始日期、终止日期、工作范围、经费预算、质量标准，和特定的功能、性能和接口要求。
项目治理是为了实现项目目标，运用相关的知识、技术、方式与工具，对项目的打算、进度、质量、本钱、资源进行治理和操纵的活动。
升级会员 