软件工程复习.docx
《软件工程复习.docx》由会员分享，可在线阅读，更多相关《软件工程复习.docx（39页珍藏版）》请在冰点文库上搜索。
软件工程复习
软件工程复习要点
一、专业术语单词表（要求认识英语单词意思，不要求默写）：
1、prototyping原型
2、reuse重用
3、datatype数据类型
4、specification规格
5、version版本
6、function功能
7、dataflow数据流
8、workflow工作流
9、model模型
10、operation操作
11、waterfall瀑布
12、V-modelV模型
13、Integer整型
14、SoftwareCrisis软件危机
15、Role角色
16、Cause导致
17、Risk风险
18、Phase周期阶段
19、clientreview客户评审
20、systemarchitect系统架构
21、activitydiagram活动图
22、Attribute属性
23、scope范围
24、statediagram状态图
25、configuration配置
26、product产品
27、defect缺陷
28、dataflow数据流
29、ganttchart甘特图
30、Betatesting贝塔测试
31、Unittesting单元测试
32、Exception异常
33、List列举出
34、branchingprocess分支过程
35、mainprocess主要过程
36、Briefdescription简要描述
37、Usecase用例
38、whiteboxtesting白盒测试
39、postcondition后续条件
40、description描述
41、Requirementsspecification需求规格
42、resource资源
43、implementation实施
44、enduser终端用户
45、interaction交互
46、refine精化
47、responsetime响应时间
48、resource资源
49、subsystem子系统
50、interface接口
51、usability可用性
52、validation验证
53、reliability可靠性
54、sequencediagram序列图
55、association关联
56、constraint约束
57、schedule时间表
58、modify修改
59、testcase测试用例
60、consistency一致性
61、release发布
62、algorithm算法
63、scenarios场景
64、include包括
65、extend扩展
66、instance实例
67、
二、软件工程术语（要求理解、掌握）
1、WBS工作任务分解
WorkBreakdownStructure：
创建WBS是把项目可交付成果和项目工作分解成较小的，更易于管理的组成部分的过程。
它是制定项目计划、资源需求、成本预算、风险管理计划的基础。
2、Riskanalysis风险分析
在开发新的软件系统过程中，由于存在许多不确定因素。
风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括：
风险识别、风险估计、风险解决策略、风险监控等。
3、Milestone里程碑
在进度时间表上设立一些重要的时间检查点，这样就可以在项目执行过程中利用这些重要的时间检查点来对项目的进程进行检查和控制。
它常常也作为用户评审的时间点。
4、requirementanalysis需求分析
对要解决的问题进行详细的分析，弄清楚问题的要求，即明确软件要交付的成果，它主要包括功能性需求和非功能性需求。
5、acceptancetest验收测试
验收测试是部署软件之前的最后一个测试操作。
在软件产品完成了功能测试和系统测试之后、产品发布之前所进行,也称为交付测试。
验收测试是向未来的用户表明系统能够像预定要求那样工作，即测试的标准是依据用户合同。
它主要包括α测试和β测试。
6、Softwarelifecycle软件生命周期
把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大的软件开发变的容易控制。
通常，软件生存周期包括可行性分析与计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动。
常见的生命周期模型包括瀑布模型、快速原型开发、迭代式开发（RUP）。
7、ganttchart甘特图
一种按照时间进度标出工作活动，常用于项目管理的图表。
以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。
8、CMMI
即软件能力成熟度模型集成，CMMI关注企业的软件开发能力，关注软件的开发过程，它包括一组评价软件开发过程的标准，依据CMMI的五级标准，可以用于对企业进行评估其软件开发能力。
9、Testcase测试用例
是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
10、SQA软件质量保证
软件质量保证的目的是使软件过程对于管理人员来说是可见的。
它通过对软件产品和活
动进行评审和审计来验证软件是合乎标准的。
软件质量保证组在项目开始时就一起参与建立计划、标准和过程。
11、软件危机
软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
主要表现在：
①软件开发费用和进度失控。
②软件的可靠性差。
③生产出来的软件难以维护。
④用户对“已完成”的系统不满意现象经常发生。
12、Prototype原型
开发人员对用户提出的问题进行总结，就系统的主要需求取得一致意见后，开发出一个原型并运行之，然后反复对原型进行修改，直到用户对系统完全满意为止。
13、softwaremaintenance软件维护
通常是软件生命周期的最后一个阶段，是指根据需求变化对应用程序进行部分或全部的修改，主要包括改正性维护、适应性维护、完善性维护、预防性维护。
14、whiteboxtesting白盒测试黑盒测试
白盒测试也称结构测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
16、Alfa测试与Beta测试
这是验收测试的两种方法，alfa测试是在开发者环境下，模拟实际使用环境，由开发人员控制引导单个用户进行的测试。
Beta测试是在没有开发者的环境下，完全由多个用户在真实的软件使用场景下进行的测试。
三、问题
1．软件项目的风险来源
2、软件文档包括哪些
3、项目的角色包括哪些，有哪些义务
参考教材86页3.3.2
4、项目管理主要包括哪些方面，简要描述
参考教材590页图14-8以及591页图14-9表述了项目管理的一个框架
技术管理、资金管理、人员与组织管理
5、测试的步骤（教材442页）
测试计划、单元测试、集成测试、系统测试。
单元测试（unittesting）主要是对每个开发模块进行的测试。
集成测试（integrationtesting）用于将多个模块进行组装后进行的测试，主要测试模块之间的接口。
系统测试（systemtesting）主要用于检验软件是否符合软件需求规格说明书，主要包括功能性测试（functionaltest）、非功能性测试（performancetesting），验收测试和安装测试。
验收测试又称为有效性测试，它的任务是检验软件的功能是否符合用户需求。
6、如何看待需求变
要点：
1、分析需求变更的原因
2、考虑需求变更对成本和时间以及对整个项目其它模块的影响
3、需求变更需要经过客户申请、确认、经理审批等流程
四、重点掌握用例图的画法及用例的描述方法，活动图、类图的画法。
习题：
designasimplemanagementinformationsystemofahumanresourceusingtheOOmethodology.Thesystemallowstheuserstomanageemployee（includingadding,deleting,searching，modifyingtheinformationofemployees）WriteoutthefollowingRequirementsspecificationsbriefly:
pleaseDrawtheusecasediagram；Givethemainusecasedescription（nolessthantwousecase）asfollows给出至少两个用例的用例描述:
Usecasename
用例名
Usecasename:
Briefdescription
简要描述
Briefdescription
Precondition
先决条件
precondition
postcondition
后置条件
postcondition
mainprocess
主要流程
mainprocess
Branchingprocess
分支流程
branchingprocess
Exception
异常处理
exception
异常处理反映用例执行过程中的异常情况
主要流程是一个用例常见的执行过程。
分支过程是一个用例其它可能执行的过程。
先决条件是进入一个用例的先进行的操作或应该满足的条件。
后置条件是该用例完成后产生的一些条件和一些影响
一般而言主要流程是必须填写的，而其它流程则视情况可以不用写，但最好能完善。
学会阅读类图。
菜单由菜单项（menuitem）组成（空心菱形表示聚合关系），订单由订单项构成（实心菱形组成关系）。
电话订单是订单的一种特殊情况（继承关系），所以为子类。
菜单和订单之间为关联关系（没有箭头表示双向关联），订单项目和菜单项目是单向关联关系。
活动图（注意开始、结束，分支，决策活动的画法）
中文补充阅读材料：
（了解）
一、需求分析
1.1需求分析的难处
（1）用户与开发人员很难进行交流
在软件生存周期中，其它四个阶段都是面向软件技术问题，只有本阶段是面向用户的。
需求分析是对用户的业务活动进行分析，明确在用户的业务环境中软件系统应该"做什么"。
但是在开始时，开发人员和用户双方都不能准确地提出系统要"做什么？
"。
因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。
由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。
（2）用户的需求是动态变化的
对于一个大型而复杂的软件系统，用户很难精确完整地提出它的功能和性能要求。
一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。
有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。
这无疑给软件开发带来困难。
1.2需求分析的任务
需求分析的任务是通过详细调查现实世界要处理的对象，充分了解原系统工作概况，明确用户的各种需求然后在此基础上确定新系统的功能。
虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求，通常对软件系统有下述几方面的综合要求。
1.功能需求
2.性能需求
3.可靠性和可用性需求
4.出错处理需求
5.接口需求
6.约束
7.逆向需求
8.将来可能提出的要求
1.3需求分析方法
常用的调查方法
⑴跟班作业
通过亲身参加业务工作来了解业务活动的情况。
这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会
通过与用户座谈来了解业务活动情况及用户需求。
座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问
对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写
如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录
即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
1.4需求分析的方法
需求分析的方法有很多.这里只强调原型化方法,其它的方法如:
结构化方法,动态分析法等.（从来没用过这些方法）在此不讨论.
原型化方法是十分重要的（是软考等常考的知识点）.原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
1.5需求分析的二十条法则
客户与开发人员交流需要好的方法。
下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。
如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。
客户应将有关术语（例如：
采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。
这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。
为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。
如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
3、分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。
通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。
报告应以一种客户认为易于翻阅和理解的方式组织编写。
客户要评审此报告，以确保报告内容准确完整地表达其需求。
一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。
共同合作能使大家“兼听则明”。
参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。
例如：
客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。
正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。
所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、要求对变更的代价提供真实可靠的评估
有不同的选择。
而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。
所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。
开发人员不能由于不想实施变更而随意夸大评估成本。
10、获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。
有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。
由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。
但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。
用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。
客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。
如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。
有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。
客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。
开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。
决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。
尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。
如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
更好的办法是先为产品开发一个原型。
这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。
变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。
所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。
这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。
也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
1.6“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。
“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。
”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：
“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。
”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：
“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。
”
这两种态度都是不对的。
因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应
升级会员 