负面情绪奶豆
范文一：2017年四川大学软件工程考研复试核心题库
目录
2017年四川大学软件工程考研复试核心题库(一) .............................................................. 2 2017年四川大学软件工程考研复试核心题库(二) .............................................................. 9 2017年四川大学软件工程考研复试核心题库(三) ............................................................ 14 2017年四川大学软件工程考研复试核心题库(四) ............................................................ 21 2017年四川大学软件工程考研复试核心题库(五) ............................................................ 26
2017年四川大学软件工程考研复试核心题库(一)
说明:本资料为学员内部使用,整理汇编了 2017考研复试重点题及历年复试常考题型。 ———————————————————————————————————————— 一、名词解释
1. 数据流图
【答案】 数据流图(DFD )是结构化分析方法中用于表示系统逻辑模型的一种工具 , 是一种 功能模型。 它以图形 的方式描绘数据在系统中流动和处理的过程 , 反映系统必须完成的逻辑功能。
二、简答题
2. 软件项目管理包括哪些内容?
【答案】 软件项目管理具体内容包括对开发人员、组织机构、用户、文档资料等方面的管理。 (1)开发人员
软件开发人员一般分为 :项目负责人、系统分析员、高级程序员、初级程序员、资料员和其 他辅助人员。软件生存期各个阶段的活动既要有分工又要互相联系。因此 , 要求各类人员既能胜 任工作 , 又要相互很好地配合 , 没有一个和谐的工作环境很难完成一个复杂的软件项目。 (2)组织机构
组织机构要求好的组织机构、合理的人员分工、有效的通信。软件开发的组织机构没有统一 的模式。主要有主程序员、专家组、民主组织三种组织机构。
(3)用户
软件是为用户而开发的 , 在开发过程中自始至终必须得到用户的密切合作和支持。作为项目 负责人 , 要特别注意与用户保持联系 , 掌握用户的心理和动态 , 防止来自用户的各种干扰和阻力。 (4)控制
控制包括进度控制、人员控制、经费控制和质量控制。为保证软件开发按预定的计划进行 , 对开发过程要实施以计划为基础。
(5)文档资料
软件工程管理很大程度上是通过对文档资料管理来实现的。因此 , 要把开发过程中的一切初 步设计、中间过程、最后结果建立成一套完整的文档资料。文档标准化是文档管理的重要方面。
3. 软件工程的净室方法为什么没有得到广泛的使用?
【答案】 (1)净室方法学太理论、太数学化 , 以至难于在真实的软件开发中使用。
(2) 不需要进行单元测试 , 而是进行正确性验证和统计质量控制 , 与当前大多数软件开发方 式背离。
(3) 软件开发产业的成熟度。 净室过程的使用需要在整个生命周期阶段定义的过程中严格的 应用 , 因为大多数软件企业的运作还处于特定的阶段(级别) , 因此 , 还没有准备好应用哪些技 术。
4. 根据瀑布模型为下列任务排序 :验收测试、项目计划、单元测试、需求复审、成本估计、总 体设计、设计复审、市场调研、详细设计、系统测试、实现、编制需求规格说明书。
【答案】 根据题意可以把上述任务分为 :
A. 市场调研
B. 项目计划、成本估计、编制需求规格说明书(同时进行)
C. 需求复审
D. 总体设计
E. 详细设计
F. 设计复审
G. 实现
H. 单元测试
I. 系统测试
J. 验收测试
根据瀑布模型的要求 , 上述任务正确的排序应为 ABCDEFGHIJ 。
5. 测试面向对象软件时 , 单元测试、集成测试和确认测试各有哪些新特点?
【答案】 (1)单元测试 , 是在类层面上的测试。由于继承和复合 , 类(或对象)在很多情况 下已不再是单纯意义上的单个操作。因此 , 具体的测试将在多有与操作有关的每个子类语境中进 行。
(2) 集成测试 , 由于面向对象软件中类的成分直接和间接交互 , 使得传统测试放法已经失去 意义。因此有两种策略可供选择 , 分别是基于线程的测试和基于使用的测试。
(3) 确认测试 , 关注与用户可见的动作和用户识别的系统输出 , 但基于场景的测试总是主宰 面向对象系统的确认测试。
6. 简述动态模型的特征 , 说明事件、事件跟踪图、状态、状态图的含义。
【答案】 (1)动态模型的特征
①动态模型是与时间和变化有关的系统性质 , 该模型描述了系统的控制结构。
②动态模型表示了瞬时的、行为化的系统控制性质。
③动态模型关心的是系统的控制 , 操作的执行顺序。
④动态模型从对象的事件和状态的角度出发 , 表现了对象的具体行为。
⑤动态模型描述的系统属性是触发事件、事件序列、状态、事件与状态的组织。使用状态图 作为描述工具。
(2)事件的含义
事件是指时刻发生的某件事情。它是某事情发生的信号 , 它没有持续时间 , 它是一种相对性 的快速事件。
(3)事件跟踪图的含义
①定义
事件跟踪图侧重于表达说明发生域系统执行过程中的一个特定 “ 场景 ” (即脚本) , 是完成系 统某个功能的事件序列。
②作用
事件跟踪图用来表示事件、事件的接收对象和发送对象。各种有关事件的序列关系及由此表 现出来的对象之间的交互作用可通过事件跟踪图来表达。
(4)状态的含义
对象在某个特定阶段所处的情形就是状态 , 它是对象行为的属性值的一种抽象。对象的属性 值按照影响对象显著行为的性质将其归并到一个状态中去。状态指明了对象对输入事件的响应。 事件和状态是孪生的 , 一事件分开两种状态 , 一个状态分开两个事件。
(5)状态图的含义
状态图反映了状态与事件的关系。当接收一事件时 , 下一状态就取决于当前状态和所接收的 事件 , 由该事件引起的状态变化称为转换。状态图确定了由事件序列引起的状态序列。状态图描 述了类中某个对象的行为 , 由于类的所有实例有相同的行为 , 那么这些实例共享同一状态图 , 正 如它们共享相同的类性质一样。 但因为各对象有 自己的属性值 , 因此各对象也有自己的状态 , 按 自己的步调前进。
图 图书馆的软件结构图
7. 什么是α测试和β测试?
【答案】 (1)α(Alpha )测试
α测试由用户在开发者的场所进行 , 并且在开发者对用户的 “ 指导 ” 下进行测试 , 且开发者负责 记录发现的错误和遇到的问题。即α测试是在受控的环境中进行的。
(2)β(Beta )测试
β测试由软件的最终用户们在一个或多个客户场所进行。 开发者通常不在β测试的现场 , 即 (β测试是软件在 开发者不能控制的环境中的 “ 真实 ” 应用。主要的实现步骤是 :
①用户记录在β测试过程中遇到的问题 , 并且定期把这些问题报告给开发者 ;
范文二：四川大学软件工程课后习题答案
第一章 1.1举出至少5个例子来说明“意外效应法则”在计算机软件方面的应用。 答：典型的例子包括使用“数字汽车仪表板”的软件，赋予高科技，高品质的图像的软件；如广泛的消费类电子产品的软件；个人电脑，工业仪器仪表和机器的软件。软件分化出的在电子商务方面的应用。
1.2举例说明软件对社会的影响（包括正面影响和负面影响）。
答：这是一个很好的课堂讨论问题（如果时间允许），而不是专注于老生常谈的（但很重要）隐私问题，生活质量等问题。您可能想要讨论关于”技术恐惧“方面的问题，软件也许会使它恶化但也可能减少”技术恐惧“。另一个有趣的方面是使用诺依曼的“风险”列在SEN中做重点讨论。你也可以考虑基于软件的“现金”经济，新模式的互动娱乐，虚拟现实，电子商务等方面来思考软件对社会的影响。
1.3针对1.1节提出的5个问题，请给出你的答案，并与同学讨论。
答：软件需要如此长的开发时间：
a）设施不上线
b）开发工具并不如预期般运作
c）客户提出的新要求，需要重新设计和返工
d）产品依赖于政府的规定，被意外更改。
e）严格的要求，与现有系统的兼容性需要超过预期更多的测试，设计和实现。 f）多个操作系统下运行的任务需求比预期需要更长的时间。
g）软件项目风险管理比预期需要更多的时间。
h）依赖的技术仍处于开发阶段，从而延长日程安排。
开发成本高：
a）比当时预期低得令人无法接受的质量，需要进行更多的测试，设计和实施工作。
b）制定了错误的软件功能需要重新设计和实施。
c）开发错误的用户界面，而导致重新设计和实施。
d）开发了不需要的额外的软件功能而延长了开发日程安排。
在将软件交付顾客使用之前，我们无法找到所有错误：
a）产品依赖于政府监管，意外而改变。
b）产品技术标准草案，会意外更改。
c）有时会在项目后期添加新的开发人员。
d）因为团队内的冲突有时会导致沟通不畅，而产生糟糕的设计。
e）破坏高效调度产生的项目管理成果和无效的规划
f）有时装备部件质量差，导致额外的测试，设计和集成工作和管理额外的客户关系。
软件开发和维护的过程仍旧难以度量：
a）有时该项目的目的是不明确。
b）有大量的业务所涉及的风险。
c）如果产品内置没有装好。
d）我们需要不断检讨我们的工作。
e）进行维护检查的时间。
f）在整个软件开发过程中要彻底组织项目团队。
1.4在交付最终用户之前，或者首个版本投入使用之后，许多应用程序都会有频繁的变更。为防止变更引起软件退化，请提出一些有效的解决措施。
答：许多现代应用程序在他们呈现给最终用户之前和第一个版本别使用后经常改变，以下几个方面来阻止软件恶化：
a)收集所需的信息。
b)设计师和客户定义软件的总体目标。
c)识别已知的需求。
d)使用现有的程序片段后，有助于建立原型的开发人员的工作计划快速完成。 e)只有通过合格的培训或经验和充分揭露相关的不足，才能保持和提高我们的技术能力和让
f)其他人承担技术任务
g)文件应该被及时制定出来，在文件中应该有标准定义和机制建立。 h)完成某一特定阶段的审查工作。
i)每一个关键团队成员应该配有一个后备人员 j)检查规避风险的步骤是否应用正确
k)对未来的风险分析中检查是否有必要收集必要的信息。
1.5思考1.1.2节中提到的7个软件分类。请问能否采用一个软件工程方法，应用于所有的软件分类？并就你的答案加以解释。
答：七个软件分类可应用于同样的方法。在这不确定的今天这些“新的挑战”，无疑有很大的影响（对于商务人士，软件工程师和最终用户来说）然而，软件工程师可以准备通过实例化一个过程，使其有足够的灵活性和适应性，以适应剧烈变化的技术，这技术一定要在未来的很长一段时间被商业规则所接受。
1.6图1-3中，将软件工程三个层次放在了“质量关注点”这层之上。这意味着在整个开发组织内采用质量管理活动，如“全面质量管理”。仔细研究，并列出全面质量管理活动中关键原则的大纲。 答：你也许建议同学阅读第十六章的知识来解决问题。
1.7随着软件的普及，由于程序错误所带来的公众风险已经成为一个愈加重要的问题。设想一个真实场景，由于软件错误而引起“世界末日”般重大危害（危害社会经济或是人类生命财产安全）。
答：确实有很多现实生活中的情况来选择，例如，软件错误，造成了重大的电话网络失败。
如在航空电子设备故障导致飞机坠毁。计算机病毒（如米开朗基罗）的攻击给主要的电子商务网站造成了重大的经济损失。
1.8用自己的话描述过程框架。当我们谈到框架活动适用于所有的项目时，是否意味着对于不同规模和复杂度的项目，可应用相同的工作任务？请解释。
答：过程框架适用于所有的项目，在相同的工作任务，适用于所有项目，无论其规模大小或复杂性。一个过程框架涉及大量的与客户沟通来收集需求；这个活动建立了一个软件工程工作计划。它涉及到创建模型，这将有助于开发人员
了解顾客的要求从而进行设计。从而涉及构建（代码生成和错误测试）。最后，它提供了基于评价的反馈。
1.9普适性活动存在于整个软件过程中，你认为他们均匀分布于软件过程中，还是会集中在某个或者某些框架活动中？
答：伞活动在整个软件过程中发生，它们被均匀地应用在整个过程中，分析还包含一系列的工作任务（例如需求收集，制定，协商规范和验证），一个过程框架有一组伞被应用在整个软件过程活动中。这些活动包括：软件项目跟踪和控制，风险管理，软件质量保证，和正式的技术审查，测量，软件配置管理，可重用性管理和工作产品的制作和生产。
1.10在1.5节所列举的神话中，增加两种软件神话，同时指出与其相对应的真实情况。
答：没有标准答案（例如测试可以解决所有的程序错误）。
第二章
2.1在本章的介绍中，Baetjer说过：“软件过程为用户和设计者之间、用户和开发工具之间以及设计者和开发工具之间提供交互的途径[技术]”。对于要构建的软件产品，在以下方面设计五个问题：（a）设计者应该问用户的问题；（b）用户应该问设计者的问题；（c）用户对将要构建的软件自问的问题；（d）设计者对于软件产品和建造该产品采取的软件过程自问的问题。 答：a）设计人员询问用户：
产品满意吗或者它需要重新设计或返工吗？
征求用户输入来避免产品不满意和要求返工。
有新要求的需要吗？ 该产品比估计的大吗？
与预期的相比模块需要更多的测试，设计和实行工作来纠正吗？
b) 用户询问设计者的问题：
范围明确吗？
我们是否有开发工具和人员开发软件所需的技能？
定义的需求是正确的吗？还有没有额外的需要？
特定领域的软件产品比平时的花费更多的时间吗？
该模块是否需要更多的设计测试？
c）用户对将要构建的软件自问的问题：
软件产品的范围和目的是什么? 该产品比估计的大吗？
有优秀的人可用吗？
工作人员可靠吗有没有具备所需要的技能？
能保持工作人员的离职率足够低吗？
d）设计者对于软件产品和建造该产品采取的软件过程自问的问题：
范围和目的文件是什么？
要使用什么样的工具？
有什么目标和规避风险的优先事项？
对风险分析，识别，估计，评价和管理会有什么样的步骤？
2.2为沟通活动设计一些列的动作，选定一个动作作为其设计一个任务集。 答：任务交流活动设置：任务组将定义实际的工作需要，以完成一个软件工程的行动。这些都是对于通信的活动：
a）利益相关者对项目做一个列表。
b）邀请所有利益相关者的非正式会议。
c）要求他们作出特性和功能列表。
d）讨论需求并建立一个最终的的列表。
e）他不确定的优先级的要求和要注意的地方。
这些任务可能是一个复杂的软件项目，然后，他们可能包括：
a)要进行一系列的规范会议，基于利益相关者的输入，建立了初步的功能和特性列表。
b)要建立一个股权持有人要求的修订清单。
c)使用质量功能展开技术来满足需求。
d)注意在系统上的约束和限制。
e)讨论验证系统的方法。
2.3在沟通过程中，遇到两位对软件如何做有着不同想法的利益相关者是很常见的问题。也就是说你得到了相互冲突的需求。设计一种过程模式（可以是步骤模式），利用2.13节中针对此类问题的模板，给出一种行之有效的解决方法。 答：
模式名：利益相关者的需求冲突。
意图：此模式描述的方式是解决利益相关者之间在通信框架活动中的冲突。 类型：阶段模式。
初始背景：(1)利益相关者已确定(2)利益相关者和软件工程师已经建立了协作通信(3) 软件要解决的主要问题由软件开发团队已建立。(4)对已开发的项目范围，基本的业务需求和项目的限制有了初步的了解。
问题：对正在开发的软件，利益相关者的需求出现了相互的矛盾。
解决办法：所有的利益相关者被要求区分需求的优先级，暂时保住利益相关者的优先级最高或投票的最多的需求从而解决这一问题。
结果：由利益相关方的确定的需求优先顺序列表来指导软件开发团队构件软件初始模型。
相关模式：定义指导和协作方针，范围隔离，需求收集，约束描述和混合需求。 已知用途/范例：必要的沟通是贯通整个软件工程中。
2.4阅读[Nog001]，然后写一篇2-3页的论文，讨论混乱对软件工程的影响。 答案略。
2.5详细描述三个适用于采用瀑布模型的软件项目。
答：适合瀑布模型的项目例如数据结构，软件架构，程序的细节和接口表征的对象。
2.6详细描述三个适用于采用原型模型的软件项目。
答：相对容易的原型模型几乎总是涉及人机交互和/或复杂计算机图形软件应用
程序，有时适合原型模型是某些类别的数学算法，命令驱动系统和其他应用在没有实时交互时结果可以很容易地检查。难以用原型模型的应用程序，包括控制和过程控制功能许多种类的实时应用程序和嵌入式软件。
2.7如果将原型变成一个可发布的系统或产品，应该如何调整过程？
答：如果将原型变成一个可发布的系统或产品，软件工程师和客户需要满足和定义软件的总体目标，识别已知的任何要求，对整体轮廓进一步的强制定义。原型作为一种机制，用于识别软件需求。如果一个工作原型被建立了，开发商会试图利用现有的程序片段或应用工具（例如，报表生成器，窗口管理等）使工作方案，可以快速生成。
2.8详细描述三个适于采用增量模型的软件项目。
答: 每一个线性序列产生的“增量”交付的软件，例如字处理软件开发使用增量范式可能会提供基本的文件管理，编辑和文件制作功能在第一增量，更复杂的编辑和文件制作能力在第二增量；拼写和语法检查在第三增量，先进的页面布局能力在第四增量。任何增量的处理流程
可以纳入原型范式。增量发展是特别有用当人员无法在经营期限为一个已成立的项目做完美的实施。
2.9当沿着螺旋过程流发展的时候，你对正在开发或者维护的软件的看法是什么？
答：随着工作的螺旋向外移动，产品走向一个更完整的状态，执行工作的抽象层次减少了。
2.10可以合用几种过程模型吗？如果可以，举例说明。
答：过程模型可以合用，每个模型都有个有点不同的处理流程，但都执行相同的通用框架活动集：沟通，规划，建模，施工和交付/反馈。例如线性顺序模型可以作为一个有用的过程模型，在被固定的情况下，要求工作以线性的方式继续进行，直至完成。在这情况下，开发者可能无法确定一种算法的效率，一个操作系统的适应性或应采取的人机交互的形式。在这之中，以及许多其他场合原型模型可以提供最好的办法。在其他情况下，以渐进的方式可能是有意义的和螺旋模型的流动可能是有效率，特殊过程模型具有许多的一个或多个传统的特性。
2.11协同过程模型定义了一套“状态”，用你自己的话描述一下这些状态表示什么，并指出他们在协同过程模型中的作用。
答：简而言之，并发进程模型假定不同的部分项目会有所不同阶段的完整性，因此，不同的软件工程活动都被同时执行。目前的挑战是管理的并发，并能够评估该项目的状态。
2.12开发质量“足够好”的软件，其优点和缺点是什么？也就是说，当我们追求开发速度胜过产品质量的时候，会产生什么后果？
答：开发质量“足够好”的软件可能会碰到死亡线（截止时间），但质量会是比
较好的。当追求开发速度超过了产品的质量，这可能会导致许多缺陷，该软件可能需要更多的测试，设计和实施工作。需求定以的不是很清楚，可能需要不断地改变。半调子和速度过快开发都可能导致无法检测到重大的项目风险。质量太差可能导致过多的质量问题和频繁的返工。
2.13详细描述三个适于采用基于构件模型的软件项目。
答：我会建议推迟这个问题直到“软件过程改进”这一章。
2.14我们可以证明一个软件构件甚至整个程序的正确性，可是为什么并不是每个人都这样做？
答：这是可能的用数学技术来证明软件组件，甚至整个程序的正确性。然而，对于复杂的程序，这是一个非常耗时的过程。用详尽的测试是不可能证明任何不平凡的程序的正确性，
2.15统一过程和UML是同一概念吗？解释你的答案。
答：UML提供了必要的技术支持和面向对象的软件工程实践。但它并不提供流程框架来指导项目团队，在他们的技术应用中。在近几年中，雅各布森， Rumbaugh和Booch制定的统一过程中框架使用UML的面向对象的软件工程。今天，统一的流程和UML被广泛应用于各种面向对象的项目。
第四章
4.1需求不断的改变，理解需求问题是软件工程师面临的最困难的工作之一，因此他们更少注意需求。在某些情况下，工程师们会化繁为简。其他情况下，工程师们必须严格地执行具体定义的需求。需求分析是设计和施工的桥梁,不能跳过。
4.2你可以尝试使用方法比如QFD（质量功能部署）通过客户访谈和观察、调查以及检查历史数据（如问题报告）为需求收集活动获取原始数据。然后把这些数据翻译成需求表——称为客户意见表，并由客户和利益相关者评审。接下来使用各种图表、矩阵和评估方法抽取期望的需求并尽可能导出令人兴奋的需求。
4.3事实上,客户和开发人员会有一个协商的过程，开发人员会要求客户权衡产品的性能与产品成本、上市时间之间的关系。这个协商的目的是开发一个项目计划，这个计划在满足客户需求的同时又能准确反映了软件开发过程中约束(如时间、人员、预算)。不幸的是,这样的项目计划很难达成,每个客户都有自己的观点。这些观点并不对其他客户都适用，此外时间是另一个重要的约束,客户可能没有时间与开发人员讨论需求，这使得问题更加复杂。
4.4需求模型的目的在于描述所需的信息、功能和计算机系统的工作领域。随着软件工程师对系统了解的深入以及利益相关者越来越了解他们真正的需求，这种需求模型是不断变化的。因此，分析模型在任何时候都是用户需求的简介
4.5最好的协商是争取“双赢”,这会使你成为是一位谈判大师。这些初期步骤的成功实施可以达到一个双赢的结果，这是继续开展后续的软件工程活动的关键。
4.6第一组上下文无关问题集主要关注的是客户、总体目标和利益。例如，需求工程师可能会问：
谁是这项工作的最初请求者？
谁将使用该解决方案？
成功的解决方案将带来什么样的经济收益？
对于这个解决方案你还需要其他资源吗？
4.7-4.9答案略。
4.10用例图描述了参与者所能观察到模型图。用例图鼓励系统的功能视图应该转换为面向对象的视图。在许多情况下，为了提供更多的相互作用，用例图需要做更详细的阐述。
4.11任何有一些软件项目需求工程经验的人都开始注意到，在特定的应用领域内某些事情在所有的项目中重复发生。这些分析模式在特定应用领域内提供了一些解决方案（如类、功能、行为），在为许多应用项目建模时可以重复使用。
4.13最好的协商是争取“双赢”的结果，即利益相关者的“赢”在于获得满足客户大多数需要的系统或产品，而作为软件团队一员的“赢”在于按照实际情况、在可实现的预算和时间期限内完成工作。
4.14当需求确认解释了一个错误时，每个需求有一个问题清单。之后会有评审小组寻找它。确认需求的评审小组包括软件工程师、客户、用户、和其他利益相关者，他们在检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性（这是建造大型产品或系统时遇到的主要问题）、冲突的需求或是不可实现的（不能达到的）需求。
第五章
5.1有没有可能在分析建模创建后立即开始编码？解释你的答案，然后说服反方。 答：分析模型作为领域对象的设计和结构的基础服务。在定义了对象和属性后，就可以开始进行编码，也就知道了对象之间的关系。
5.2 一个单凭经验的分析原则是：模型“应该关注在问题域或业务域中可见的需求”。在这些域中哪些类型的需求是不可见的？提供一些例子。
答：正如我们所知道的，在开始阶段很可能没有完整的需求规范。客户可能不是非常精确地确定他们的所有需求。开发者也没有把握使用一个具体的方法来正常的完成系统的功能和性能。为了需求分析和建模，不倾向使用迭代的方法。分析师所将认识到的东西进行建模，并使用此模型作为软件增量的设计的基础。软件增量作为流程迭代的一部分被制作出来。在这些领域中，需求的类型是不可见的，可能因为一些功能必须在系统中实现，系统展示的行为是什么，属性定义的接口有哪些，应用的约束有哪些？
5.3 域分析的目的是什么？如何将域分析与需求模式概念相联系？
答：域分析是持续的软件工程活动，不与任何的软件项目相关联。它与需求模式的概念相联系。域分析是通过一系列活动进行表征的过程。这些活动从识别域开始，以描述域中对象和类的规范为结束。
5.4 有没有可能不完成如图6-3所示的4种元素就开发出一个有效的分析模型？解释一下。
答：如果没有图6.3所示的4大元素，是不可能开发出一个有效的分析模型。分析模型作为域对象的设计和建造的基础。
5.5 构建如下系统中的一个：
a你所在大学基于网络的课程注册系统。
b一个计算机商店的基于Web的订单处理系统。
c一个小企业的简单发票系统。
d内置于电磁灶或微波炉的互联网食谱。
选择你感兴趣的系统开发一套试题关系图并说明数据对象、关系和属性。
答：需要强调的是，所有的数据对象和关系一定客户可见的。为了确认属性正确地反映出系统的需求，属性应该被检查。（无固定答案）
5.6-5.9答案略。
5.10 什么是分析包？如何使用分析包？
答：将分析模型的各种元素以包组的方式进行分类，成为分析包。为了说明分析包的作用，请思考一下视频游戏。作为视频游戏的分析模型，道出了大量的类。
第六章
6.1 对于需求分析，结构分析与面向对象策略有何本质区别？
答：结构分析，考虑把数据作为分离实体的变形的数据和过程。数据目标是被使用它们已被定义的属性和关系建模的。过程操作数据目标是被使用它们在系统中的数据流向建模的。面向对象分析，集中于类的定义和它们合作对用户需求所带来的效果的方式。
6.2 在数据流图中，一个箭头表示控制流还是其他？
答：DFD数据目标是用有标签的箭头所表示的。
6.3 什么是“信息流连续性”？当重新定义一个数据流时，如何应用它？
答：数据流动连续性意味着在同一等级中的输入和输出必须和它们的精确等级相同。
6.4 在生成DFD图时，如何使用图形化解析？
答：在第一次需求整合会议中，应用工程描述中分离所有名词和动词的第一步被导出。再文法解析中，动词时处理和可以被如DFD中的Bubbles描述的。名词是DFD中的外部实体（盒子），数据或控制目标（箭头），或数据存储（双实线）。
6.5 什么是控制规格说明？
答：控制规格（CSPEC）以两种不同的方式描述了系统的行为（在被提到的基准线上），CSPEC包括一系列行为的规格的状态图。它也包括程序行为表——组合的行为规格。
6.6 PSPEC和用例是同一事物吗？如果不是，请解释区别。
答：不是。过程规格被用于去描述所有现在最终精炼等级的流程模型过程（算法观点）。一个有用的情况描述一系列行为包括演员和系统（更着重于用户可见行为而非算法）。
6.7 表示行为建模时有两种不同“状态”类型，它们是什么？
答：被动状态展现出目标属性的正确情况。主动状态指明了目标在转化或执行过程中的正确情况。
6.8 如何从状态图区分顺序图？它们有何相似之处？
答：状态图描述了系统的状态并且展现了事件如何影响系统状态。
顺序图指明了事件如何引起目标的迁移。
6.9——6.10答案略。
第七章
7.1是的，但是设计是隐式进行的——通常以随意的方式进行的。在设计过程中，我们研究程序的表现形式，而非程序本身。
7.2软件设计的目的是运用一系列的原则、概念和实践导致高质量体系或产品的发展。设计的目标是创建一个可以正确地实现所有客户需求并有好的用户体验的软件模型。
7.3通过开展一系列的正式技术评审来评估质量。正式技术评审是由软件团队成员召开的会议。通常，根据将要评审的设计信息的范围，选择2人、3人或4人参与。每个人扮演一个角色：评判组长策划会议、拟定议程并主持会议；记录员记录笔记以保证没有遗漏；制作人是指其工作产品（例如某个软件构件的设计）被评审的人。在技术评审会议结束后，软件团队决定未来的行动以来完成最终的产品。
7.4为了开发一个完整的设计模型，软件团队反复地开发每个模块的元素。每次迭代提供额外的细节并且细化。此外，设计任务应用于一个项目可能不同于他们应用其他项目。团队必须适应一个通用的任务集去满足产品，人和项目的需
要。质量的评估在有被修改的错误的组件级的设计任务集。任务集在章节中给出。
7.5略
7.6软件体系结构是程序组件（模块）的结构或组织，这些组件相互作用的方式和数据结构被这些组件所使用。然而在更广泛的意义上讲，部件可以推广到代表主要的系统元件以及它们之间的交互。
7.7略
7.8分离关注点涉及通过将其分成单独解决的子问题解决一个复杂的问题，一个问题的不同部分是相互结合的方式，给与不同的考虑，而不是合并考虑更复杂的情况。高度耦合的问题表现出这一特征。然而，问题的部分继续组合，因为信息量超过了解一个人的能力不能无限期地进行下去，因此，当问题非真，模块化可以修改，但不能消除。
7.9在某些时间关键应用程序下,可能需要单块集成软件。然而,如果软件是模块化实现，设计可以而且应该实现的。“模块”是内联编码。
7.10信息隐藏与耦合和内聚概念有关，通过限制信息的可用性，只限于那些绝对需要的模块，模块之间的耦合在本质上是降低了。在一般情况下，信息隔离谓词有隔离功能，因此，各模块凝聚力也可以改善
7.11外部环境、编译器和操作系统耦合将对软件可移植性造成不利影响。例如,考虑一个程序,这个程序被设计用来充分利用智能终端的特殊图形的特征。如果没有终端的软件被搬到一个系统,主要设计和代码可能需要修改。
7.12我们创建一个功能体系由此来提炼问题。例如，考虑到检查写入，我们可能这样写：
Refinement 1:
Write dollar amount in words
Refinement 2:
Procedure write amount;
Validate amount is within bounds;
Parse to determine each dollar unit;
Generate alpha representation;
end write_amount
Refinement 3:
procedure write_amount;
do while checks remain to be printed
if dollar amount > upper amount bound
then print "amount too large error
message;
else set process flag true;
End if;
determine maximum significant digit;
do while (process flag true and
significant digits remain)
set for corresponded alpha phrase;
divide to determine whole number
value;
concatenate partial alpha string;
reduce significant digit count by one;
End do
print alpha string;
End do
end write_amount
细化1：
写出大写金额总数。
细化2：
写出大写金额数的程序：
验证金额数是否在允许范围内；
通过解析来确定美元单位;
用 来表示金额数，写出来;
结束写出大写金额数程序
细化3：
写出大写金额数的程序：
检查是否还有未打印的支票，如有进入下面的循环
判断支票金额数是否大于上面指定的金额数
如果大于打印“金额数太大”的错误信息
否则确定过程标志符为1。
结束判断。
当过程标志符为1和有效数字存在的话，进入下面的循环：
确定最高有效位;
设置对应阿尔法短语;
划分来确定整数值；
连接部分α字符串;
7.13略
7.14不，重构是一种不改变代码的外部行为和其功能而改善软件产品的内部质量的过程。他可能是提高了一个函数的处理速度或者在另一个系统中起到简化组件的作用。
7.15四个要素的设计模型：
设计模型的四个元素：
数据/类设计——建立由分析转化的基于类内元素的类模型和按数据结构要求实现的软件。
结构设计——定义大体软件元素结构件的关系。
接口设计——描述软件元素,硬件元素和用户终端通信。
组件等级设计——建立由软件组件的程序描述中的软件结构所定义的元素结构变形。
第八章
8.1用一个房屋或建筑结构作比喻，与软件体系结构作对照分析。经典建筑与软件体系结构的原则有什么相似之处？又有何区别？
答：建筑与软件在风格与模式的概念存在于宏观与微观层面。例如所有的方子都有总体风格（墙、顶、地基）。这些代表了房子的宏观风格。微观上的模式（房子）可以在木材的类别、壁炉的设计以及窗户上体现出来。软件体系结构也一样，不同部件通过不同方法的组装，形成了不同的系统。不同点：一个比较实际，另外一个比较抽象；房屋或建筑物可变化的空间比较小，软件体系结构变化跨度更大一点
8.2举出2到3个例子，说明8.3.1节中提到的每一种体系结构风格的应用。 答：数据中心体系结构:航空订票系统；图书馆目录系统；宾馆订阅系统。 数据流结构：任何工程或科学中主要功能是计算的应用程序。
调用和返回结构：任何I-P-O申请。
面对对象的体系结构：基于GUI的应用程序;任何面向对象的应用程序 。
分层体系结构：应用功能必须从底层操作系统或网络详细信息分离的应用程序。客户端服务器软件通常是分层的。
8.3 8.3.1节中提到的一些体系结构风格具有层次性，而另一些则没有。列出每种类型。没有层次的体系风格如何实现？
答:
层次：数据流，调用返回层。
非层次：数据中心，面向对象。
非分层体系结构可能是应用面对对象和驱动编程技术的最好实现。
8.4 在软件体系结构讨论中，经常会遇到体系结构风格、体系结构模式及框架（本书中没有讨论）等术语。研究并描述这些术语之间的不同。 答：许多人把建筑模式和建筑风格等价定义（把通用系统模型作为程序设计的起始点），尽管模式往往不太广泛。一个框架可能会被一些人定义为一组提供了一个通用的解决问题方案的类，被解决的问题可以被细化到创建一个应用程序。
8.5 选择一个你熟悉的应用，回答8.3.3节中对于控制与数据提出的每一个问题。 答：答案不固定。
8.6 研究ATAM（[Kaz98]）并对8.5.1节提出的6个步骤进行详细讨论。 答：答案不固定。
8.7 如果还没有完成习题5.6，请先完成它。使用本章描述的设计方法开发PHTRS的软件体系结构。
答：答案不固定。
8.8 使用数据流图和过程说明，描述一个有清楚变换流特征的计算机系统。定义流边界并使用8.6.1节描述的技术将DFD映射到软件体系结构中
答：答案不固定。
第九章 9.1构件级设计定义了数据结构、算法，界面特性以及分配给每个软件构件的通信机制。在面向对象语言中（JAVA或Smalltalk）构件为类或对象。在传统语言(C或Fortran)中构件式函数或操作过程。在混合语言中（如C++）构件可能是函数或类。
9.2像面向对象的构件一样，传统软件构件是由分析模型所导出的。然而在这种情况下，导出构件是以分析模型中面向数据流元素作为基础。数据流图的最低层的每个变换都被映射为某一层上的模块。控制构件（模块）位于层次结构（体系结构）顶层附近，而问题域构件则倾向位于层次结构的底层。为了获得有效的模块化，在构建细化的过程中采用了功能独立性的设计概念。
9.3OCP原则模块（构件）应该对外延具有开放性，对修改具有封闭性。设计者应该采用一种无需对结构自身内部（代码或内部逻辑）做修改就可以进行的扩展（在构建所确定的功能域内）的方式来说明构件。设计者进行抽象，在那些需要扩展的功能与设计类本身之间起到缓冲区作用。
9.4依赖性倒置原则(DIP)，依赖于抽象。不依赖于具体实现。构件依赖的其他具体构件（不是依赖抽象类，如接口）越多，扩展起来越困难。
9.5构件级设计中面向对象系统的上下文中，内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或者类自身有密切关系的属性和操作。高内聚的构件会与其他构件提供的服务“绝缘”，从而使其实施与维护更加容易。
9.6耦合是类之间彼此联系程度的一种定性度量。随着类（构件）相互依赖越来越多，类之间的耦合程度亦会增加。低耦合的好处是构件可以被修改但不会影响其他构件。
9.7外部耦合发生在组件通信或与基础设施组件(如。、操作系统功能、数据库功能、通信功能)。虽然这种类型的耦合是必要的,它应该是局限于一小部分系统组件或类。软件必须在内部和外部沟通。因此,耦合是一个不争的事实。然而,设计师应尽可能减少耦合和理解高耦合的影响不可避免。
9.8略
9.9 重构是系统决策集散控制的过程，目的是让顶层模块执行控制功能，而底层模块处理所有输入，执行和输出工作。逐步求精是通过连续精化过程细节层次来实现程序的开发。在传统软件开发中两者是很相似的。
9.10
WebAPP构件定义为以下两点之一：
定义良好的聚合功能，为最终用户处理内容，或提供计算或数据处理 内容和功能的聚合包，提供最终用户所需的功能。
9.11略
9.12略
9.13略
9.14 人可以短暂记忆一小部分东西，分块可以使评审者将相关概念组合成大的碎片或更大的分块。那些具有分块功能的构件（如果构件具有高内聚低耦合特性）可以使评审者在设计审查时更简单的追踪几个构件的相互作用而不是大量的单各类或方法。
第十章
10.1这道题应该不难！许多早期交互式系统都有糟糕的界面。在现代环境下，让你的学生们注重基于web的应用程序界面。许多web应用程序为了Flash牺牲易用性。
10.2例子如下：
在它们引起“可撤销的”损害之前抓住潜在的交互错误。
允许用户自定义屏幕布局以及命令。
利用分离菜单，以便通用功能。
10.3例子如下：
如果用户有需求，在屏幕上一直显示快捷键命令序列。
当一个web应用程序需要密码输入的时候，提供“密码提示”机制。
10.4例子如下：
使用一致的颜色，例如，红色用作警示信息，蓝色用作通知信息；
提供关键字驱动的在线帮助。
10.5答案略。
10.6如果你的学生在任务分析上出了问题，老的备用I-P-O将会有效。
问：使用者输入什么？它是怎么处理的？处理过程是如何通过界面表现出来的？产生的输出是什么？
10.7-10.11答案略。
10.12当响应时间无法预测的时候，使用者会很不耐烦并且重复尝试请求的命令或者尝试另一个命令。在某些情况下，这会产生（命令的）排队问题，并且在极端的情况下，会引起数据的丢失或者甚至是一个系统故障。研究表明，用户可以容忍他们熟悉的应用程序的响应率50%的变化。对于那些不熟悉的应用程序，使用者在15到30秒意外的延迟（也就是他们短期记忆的半衰期）后会很焦虑。
10.13答案略。
10.14如果你想要给你的学生一些工作项目表的范例，互联网是一个很好的可用性调查表的来源（大部分都应该有超过20道的问题，所以你的学生应该需要优先考虑他们的选择）
第十四章
14.1用自己的话描述验证与确认的区别。两者都要用测试用例的设计方法和测试策略吗？
答：“验证”是通过尝试在功能或性能上发现错误来保证程序的正确性，“确认”是保证软件与需求相一致——这也是质量的基本特征。
14.2列出一些可能与独立测试组（ITG）的创建相关的问题。IGT与SQA小组由相同的人员组成吗？
答：组建ITG（独立测试组）最常见的问题是获得并留住人才，除此之外，如果ITG与软件工程小组的交流组织地不恰当的话，两组之间可能会产生敌意。最后，ITG有可能太晚接手项目，导致没有时间完成一个周密测试的计划和执行。ITG和SQA（软件质量保证）小组不必是同一组人。ITG只关注测试，SQA小组则需要考虑到质量保证相关的所有方面。
14.3使用14.1.3节中描述的测试步骤来建立测试软件的策略总是可行的嘛？对于嵌入式系统，出现哪些可能的复杂情况？
答：它并不总是能够进行单元测试的测试环境，完成单元测试的复杂性（如复杂的驱动和存根）可能无法证明效益。集成测试是复杂的通过单元测试的模块合并计划的有效性（特别是当这些模块滞后的时候）。在很多情况下（尤其是嵌入式系统）软件不能充分进行验证测试硬件配置外的目标。因此，验证和系统测试要相结合。
14.4为什么对具有较高耦合度的模块进行单元测试？ 答：一个高度耦合的模块要与其他模块的数据和其他系统元素进行交互。因此，其功能往往是依赖于这些耦合元件的操作。为了彻底的单元测试这样一个模块，耦合因素的功能必须以某种方式模拟。这将会是困难和费时的。
14.5“防错法”的概念是一个非常有效的方法。当发现错误时，他提供了内置调试帮助：
a.为防错发开发一组知道原则。
b.讨论利用这种技术的优点。
c.讨论利用这种技术的缺点。
答：一个单一的规则涵盖了多种情况：所有数据在软件接口（外部和内部）应当经过验证（如果可能的话）。
优点：错误不会―滚雪球‖——越滚越大
缺点：需要额外的处理时间和内存（那通常只是一个很小的代价）。
14.6项目的进度安排是如何影响集成测试的？
答：完成模块的可用性的影响顺序和战略整合。项目状态必须是已知的，可以成功地实现整合规划。
14.7在所有的情况下，单元测试都是可能的或是值得做的吗？提供实例来说明你的理由。
答：如果一个模块有3或4个下属供应数据模块的一个有意义的评价是至关重要的，没有―聚类‖所有的模块作为一个单元，它可能无法进行单元测试。
14.8谁应该完成确认测试——是软件开发人员还是软件的使用者，说明你的理由。
答：开发商，如果客户验收测试计划。开发人员和客户（用户）如果没有进一步的测试计划。一个独立的测试组可能是这里最好的选择，但这不是一个选择。
14.9为本书讨论的safehouse系统开发一个完整的测试策略，并以测试规格说明的方式形成文档。
答：略
14.10作为一个班级项目，为你的安装开发调试指南。这个指南应该提供面向语言和面向系统的建议。这些建议是通过总结学校学习过程中所遇到的挫折得到的。从一个经过全班和老师评审过的大纲开始，并在你局部范围内将这个指南发布给其他人。
答：略
第十五章 15.1 Myers[mye79]用以下程序作为测试能力的自我评估：某程序读入三个整数值表示三角形的三条边。改程序打印信息表明三角形是不规则的，等腰的或等边的。开发一组测试用例测试改程序。
答：参考Myers[mye79]对此问题提出的极其详细的―解决方案‖。
15.2设计并实现15.1描述的程序（适当使用错误处理）。从该程序中导出流图并用基本路径测试方法设计测试，以保证程序中的所有语句都被测试到。执行测试用例并显示结果。
答：你可以选择发布程序源代码给您的学生（故意地嵌入一些错误）。 15.3你能够想出15.1.1节中没有讨论的其他测试目标吗？
答：除了那些目标之外还有：
a) 一个成功的测试显示功能和性能要求；
b) 一个成功的测试发现文件错误；
c) 一个成功的测试发现接口问题；
d) 一个成功的测试验证了程序结构，了解数据结构，界面设计和程序设计； e) 一个成功的测试，建立了一个进入一个测试案例数据库，以后可以用于回归测试。
15.4选择一个你最近设计和实现的构建。设计一组测试用例，保证利用基本路径测试执行所有语句。
答：略
15.5-15.8
答：进行一些拓展，这些问题可以被指定为一个长期的项目。
15.9至少给出三个例子，在这些例子中，黑盒测试能给人“一切正常”的印象，而白盒测试可能发现错误。再至少给出三个例子，在这些例子中白盒测试能给人“一切正常”的印象，而黑盒测试可能发现错误。
答：对于特定的输入，一个内部发生的错误导致：
1) 不恰当的数据被设在一个全局数据域里；
2) 不恰当的标记将在随后进行的一系列测试中被测试；
3) 不恰当硬件控制，只可能在系统测试时被发现；但是却产生了正确的输出。
15.10不，即使穷举测试（如果可能的话）也不能发现软件说明书中的性能问题和错误。在这种情况下需要同时考虑输入和输出的等价类。对每一个类来说，学生应当根据数值范围，集合的元素，系统命令等划定边界。这可以作为笔试以及一些著名应用GUI的测试用例的素材 15.11生成一系列用例来帮助测试用户的文件材料是一个好办法。
第十六章
16.1用自己的话，描述为什么在面向对象系统中，类是最小的合理测试单元。 答：类封装了数据以及处理数据的操作。由于数据和操作被打包成一个整体，一个一个地测试方法没有作用，不能发现与消息传送，职责和协作相关的错误。
16.2若现有类已进行了彻底的测试，为什么我们必须对从现有类 实例化的子类进行重新测试？我们可以使用为现有类设计的测试用例么？
答：由于每一个子类都继承了父类的私有属性和操作（事实上这些私有属性和操作会增加复杂度），这些子类必须在他们的操作环境中重新测试。测试用例可以重复使用，但需要针对子类的私有属性和操作进行扩充。
16.3为什么―测试‖应该从面向对象分析和设计开始？
答：在之后的开发过程中，面向对象分析和设计模型提供了大量与系统结构和行为相关的信息，因此，在生成代码之前，这些模型必须经过严格的审查。所有面向对象的模型应当在模型的语法，语义以及语用论的上下中经过正确性，
完整性，一致性的测试（包括技术评审）。这些评审有可能省去很多不必要的工作和修改（错误越早发现，维护的成本越低）。
16.4为SafeHome导出一组CRC索引卡片，按照16.2.2节讲述的步骤确定是否存在不一致性。
答：答案会有不同
16.5基于线程和基于使用的集成测试策略有什么不同？簇测试如何适应？
答：基于线程的测试用来集成一系列需要对单独一个程序输入或事件响应的类。基于使用的测试属于集成测试的一种，通过测试那些很少使用服务器类的类（称为独立类）开始系统的构造。测试完独立类之后，测试使用独立类的下一层类（称为依赖类），按照这样的顺序逐层测试依赖类直到整个系统构造完成。
16.6将随机测试和划分方法运用到设计SafeHome系统时定义的3个类。产生展示操作调用序列的测试用例。
答：答案会有不同
16.7运用多类测试及从SafeHome设计的行为模型中生成的测试。
答：答案会有不同
16.8运用随机测试、划分方法、多类测试及16.5节和16.6节所描述的银行应用的行为模型导出的测试，再生成另外生成4个测试。
答：答案会有不同
第十八章
18.1基于本章给出的信息和自己的经验，列举出能够增强软件工程师能力的“十条戒律”。即，列出10条指导原则，使得软件人员能够在工作中发挥其全部潜力。
答：
（1）你要变得更聪明。
（2）你要注重质量。
（3）你要倾听客户。
（4）你要了解问题
（5）你要对一个工作过程不断的重复。
（6）你不可同意荒唐的时间表。
（7）你要测量产品，过程和你自己。
（8）你要制定最有效的工作方法。
（9）你要记住，别人也会软件工作。
（10）你要不断地提高。
18.2 SEI的人员能力成熟度模型定义了培养优秀软件人员的“关键实践域”。你的老师将为你指派一个关键实践域，请你对它进行分析和总结。
答：略。
18.3描述3种现实生活中的实际情况，其中客户和最终用户是相同的人。也描述3种他们是不同人的情况。
答：相同的人：（1）一个工程师必须开发一个供个人使用的程序。（2）一个商人创建供个人使用的电子表格模型。（3）一个拥有迷人的手机客户端这一新概念的企业家。
不同的人：（1）一个通信部门的一些业务功能的服务。（2）一个软件开发团队服务营销的需求。（3）承包商建立的客户的规格。
18.4高级管理者所做的决策会对软件工程团队的效率产生重大影响。也描述3种他们是不同人的情况。
答：在今天的环境，裁员和外包有最直接的、重大的影响。此外，“减少开支的措施”，导致较低的产品质量；不切实际的项目最后期限；对用户的需求了解失败；或者，反过来说，对软件工程师的工作提出警告。
18.5温习Weiberg的书[Wei86]，并写出一份2-3页的总结，说明在使用MOI模型时应该考虑的问题。
答案：略。
18.6在一个信息系统组织中，你被指派为项目经理。你的工作是开发一个应用程序，该程序类似于你的团队已经做过的项目，只是规模更大而且更复杂。需求已经由用户改写成文档。你会选择哪种团队结构？为什么？你会选择哪（些）种软件过程模型？为什么？
答：一个封闭范型方法的团队结构是一种选择。由于需求明确，这可能会要求和配置多个分区小组。规模大的项目缓和了利于CD团队的方面。由于没有讨论日程，我们假设的交货日期是合理的。因此，有可能使用一个线性的顺序过程模型。然而，迭代模型（例如，螺旋）也是一个很好的可能性。
18.7你被指派为一个小型软件产品公司的项目经理。你的工作是开发一个有突破性的产品，该产品结合了虚拟现实的硬件和高超的软件。因为家庭娱乐市场的竞争非常激烈，完成这项工作的压力很大。你会选择哪种团队结构？为什么？你会选择哪种过程模型？为什么？
答：随机式范型的团队结构可能是唯一可行的选择，给出了模糊的要求和工作性质的实验。应该使用原型开发方法或者一个曾量的过程模型。
18.8你被指派为一个大型软件产品公司的项目经理。你的工作是管理该公司已被广泛使用的字处理软件的新版本的开发。由于竞争激烈，已经规定了紧迫的最后期限，并对外公布。你会选择哪种团队结构？为什么？你会选择哪些软件过程模型？为什么？
答：一个开放式范型团队结构可能是最好的，给定的时间压力和熟悉的工作（然而，封闭的方法范式团队可能也很好）。一个曾量过程模型被推动这项工作性质的最后期限所指明。
18.9在一个为基因工程领域服务的公司中，你被指派为软件项目经理。你的工作是管理一个软件新产品的开发，该产品能够加速基因分类的速度。这项工作是面向研究及开发的，但其目标是在下一年度内生产出产品。你会选择哪种团队结构？为什么？你会选择哪些软件过程模型？为什么？
答：一个随机式范型可能是最好的，是因为这项工作是实验性的，且有一个企业的最后期限。另一种可能性是使用一个开放式范型的团队结构。一个曾量过程模型和进化过程模型可以用于推动给予限期的这项工作。
18.10要求开发一个小型应用软件，它的作用是分析一所大学开设的每一门课程，并输出课程的平均成绩（针对某个学期）。写出该问题的范围陈述。 答：
分数分析应用程序将获得所有本科和研究生的学分课程的成绩和在某一学期课程注册数据库。分数分析应用程序会读每一门课程的所有等级和计算平均成绩，使用的数值范围在A = 4和其他等级分配值来作为等级值存到uc29-1文档。本程序会打印一个报告显示每门课的教师和平均成绩。这个报告可能会按平均成绩或者教师等其他类似的特征排序。本程序可能会运行在WindowsVista操作系统下。
18.11给出18.3.2节中讨论的页面布局功能的第一级功能分解。 答：
一个简单的分解：
页面布局
定义页面参数
分配文本区域
分配图形区域
强调定义（线，着色等）
输入/导入文本
输入/导入
编辑文本
编辑图形
出页/导出页面
最终页面布局
第十九章
19.1用自己的话描述过程度量和项目度量之间的区别。
答：过程度量是用来对设计和建造计算机软件的活动进行评估（为了在后续项目提高这些活动）。
项目度量是用来评估软件项目的状态。
19.2为什么有些软件度量是“私有的”？给出3个私有度量的例子，并给出3个公有度量的例子。
答：当待评估的特征无法被直接测量时一种间接的的测量方法将被使用，例如,―质量‖不能被直接测量所以只能测量软件其他的特征，软件的很多度量工作
都间接的，因为软件不是一个有形的可以用直接测量的实体。例子
能直接度量的物体
纸的数量
人的数量
不同文件的数量
不能直接度量的物体
可读性（利用模糊指数）
完整性（计算你收到的‖服务台‖问题的数量）
可维护性 (定时改变文档)
19.3什么是间接测量？为什么在软件度量工作中经常用到这类测量？ 答：没找到答案。
19.4Grady提出了一组软件度量规则，你能在19.1.1节所列的规则中在增加3个规则吗？
答：软件度量的额外规则：
不找完美的指标……它不存在。
保证测量的一致性，避免比较不同的事物。
注重质量，这是最重要的。
19.5产品交付之前，团队A在软件工程过程中发现了342个错误，团队B发现了184个错误。对于项目A和B，还需要做什么额外的测量，才能确定哪个团队能够更有效地排除错误？你建议采用什么度量能有助于做出判定？那些历史数据可能有用？
答：两个团队应该事先决定好要开发的软件的大小和功能，例如，errors/FP可以提供一个规范化的评估方法。此外，在两个团队的软件开发过程中一个度量标准例如DRE可以提供一个对SQA的效率指标。
19.6给出反对将代码行作为软件生产率度量的论据。当考虑几十个或几百个项目时，你说的情况还成立吗？
答：LOC的作用不大是因为它的奖励―verbose‖计划，同时他也很难用在可视化编程中，4GLs，代码生成器，或其他的代码生成器4gts的发展正在远离3gls
19.7根据下面的信息域特性，计算项目的功能点值：
用户人数：32
用户输出数：60
用户查询数：24
文件数：8
外部接口数：2
假定所有的复杂度校正值都取“中等”值。使用第十三章描述的算法。 答：
总计：32*4+60*5+24*4+8*10+2*7=618
FP=618*[0.65+0.01*3*14]=661
19.8利用19.2.3节中给出的表格，基于每行代码具有的功能性，提出一个反对使用汇编语言的论据。再参考该表，讨论为什么C++比C更好？
答：用汇编语言实现一个功能点需要的行数在91到694之间平均337行，这几项在表中都是最大的，一些行业分析师称：每天无论使用任何语言的程序员都交出相同数量的调试代码，如果开发一个项目真用了汇编语言那将比用其它语言花费更多的时间，以上比较方法可以用到C与C++得比较。
19.9用于控制影印机的软件需要32000行C语言代码和4200行Smalltalk语言代码。估算该影印机软件的功能点数。
答：
用C语言 = 162 LOC/FP
用Smalltalk = 26 LOC/FP
所以 32,000/162 + 4,200/26 = 197.53 + 161.54 = 359 FP (近似值)
19.10在一个项目结束时，确定在建模活动中发现了30个错误，在构造活动中发现了12个可以追溯到建模活动中没有发现的错误。那么，建模活动的DRE是多少？
答：DRE = E / (E + D) = 30 / (30 + 12) = 30 / 42 = 0.71.(近似值)
19.11软件团队将软件增量交付给最终用户。在第一个月的使用中，用户发现了8个缺陷。在交付之前，软件团队在正式技术评审和所有测试任务中发现了242个错误。那么在使用一个月之后，项目总的缺陷排除效率（DRE）是多少？ 答：DRE = E / (E + D) = 242 / (242 + 8) = 242 / 250 = 0.97(近似值)
第二十章
20.1假设你是一家开发家用机器人软件公司的项目经理，你已经承接了为草坪割草机器人开发软件的项目。写一个范围陈述来描述该软件，确定你的范围陈述是“界定的”。如果你对机器人不熟悉，在你开始写作之前先做一些调研工作。还要说明你对所需硬件的设想。或者，你也可以选择其他感兴趣的问题，而不做草坪割草机器人。
答：略
20.2在20.1节简要讨论了软件项目的复杂性。列出影响项目复杂性的软件特性（例如，并发操作、图形输出），按其对项目的影响程度顺次排列。
答：有时，复杂性来源于客户和软件开发人员之间建立的一个糟糕的接口，以此，以下性能应该被考虑
实时属性；
多处理要求(并发)；
算法的本质；
递归的需求；
输入的本质；
确定性的输入；
输出的本质；
语言特点；
知识/经验人员的使用。
20.3在计划过程中，性能是一个重要的考虑因素。针对不同的软件应用领域，分别讨论如何以不同的方式来解释性能。
答：实时操作--处理原始数据的CPU时间和可能产生中断服务的效率 工程/科学的应用--数值精度和大型系统,CPU时间。
商业的应用--I/ O效率
交互式的应用--用户“等待时间”
微处理器的应用--cpu时间和内存需要。
20.4对你在习题20.1中描述的机器人软件进行功能分解。估算每个功能的规模（用LOC）。假定你所在组织的平均生产率是450LOC/pm，劳动力价格是每人月7000美元，使用本章所讲的基于LOC的估算技术来估算构造该软件所需的工作量及成本。
答：用户交互(2400)
传感器监测(1100)
信息显示(850)
系统配置(1200)
系统控制(激活/失活)(900)
括号中指出了对每一项的LOC估计，通过估计一共是6450LOC 把数据用与这个问题6450 LOC / 450 LOC/pm = 14.3 pm
花费: 14.3 pm * $7,000/pm = $100,000 (估计值)
20.5使用COCOMOⅡ模型来估算构造一个简单的ATM软件所需的工作量，它产生12个屏幕、10个报表、将需要大约80个软件构件。假定该软件具有平均复杂度和平均开发者/环境成熟度。要求使用基于对象点的应用组装模型。 答：object point = 12 * 2 + 10 * 5 + 80 * 10 = 874
我们假设 80% reuse
NOP = (object points) * [(100 - %reuse)/100]
= (874) * [(100 – 80)/100] = 874 * 0.2 = 174.8
参考p362的图可知：
PROD = 13
工作量 = NOP/PROD = 174.8 / 13 = 13.45
20.6使用“软件方程”来估算草坪割草机器人软件。假设采用方程（20-4），p=8000。 答：假设 B=0.16 and P = 8,000
t.min = 8.14 * (LOC / P)0.43 =
= 8.14 * (6450/8000)0.43
t = t.min / 12 months/year
E = 180 * B * t3
20.7比较习题20.4和习题20.6中所得到的工作量估算值，求出标准偏差，它如何影响你对估算的确信程度？
答案和题目不一样。
20.8使用习题20.7中得到的结果，确定能否期望该软件在6个月内完成，以及完成该工作需要多少人员？
答：软件方程预测“不”但我们可能超出其边界，使用原始的COCOMO模型。
D = 2.5 E ^ 0.35 = 2.5 * 16.92 ^ 0.35
= 6.7人月
看来， 6月是积极的，但有可能给出（相当于3人工作项目）COCOMO的结果和项目的规模/复杂性。
20.9建立一个电子表格模型，实现本章所述的一种或多种估算技术。或者从基于Web的资源获取一个或多在线估算模型。
答：略。
20.10组建一个项目团队，开发软件工具来实现本章所介绍的每种估算技术。 答：略。
20.11有一点似乎很奇怪：成本和进度估算是在软件项目计划期间完成的——在详细的软件需求分析或设计之前进行。你认为为什么会这样？是否存在不需要这样做的情况？
答：很早对成本和进度的估计是因为管理层希望尽可能早的得到这些数据，如果这个项目有非常复杂的高级技术风险，所以一个固定价格的提议提交需要，项目的成本核算应该(如果可能)被推迟到需求分析之后，注意:只有需求的成本是可以尽早估计。
范文三：2015四川大学软件工程期末复习
Multiple choices
1. The rapid application development model is
Answer :c
a. Another name for component-based development.
b. A useful approach when a customer cannot define requirements
clearly.
c. A high speed adaptation of the linear sequential model.
d. All of the above.
1. Which of the following is not necessary to apply agility to a software process?
a. Eliminate the use of project planning and testing
b. Only essential work products are produced
c. Process allows team to streamline tasks
d. Uses incremental product delivery strategy Answer:a
2. How do you create agile processes to manage
unpredictability?
a. Requirements gathering must be conducted very carefully
b. Risk analysis must be conducted before
planning takes place
c. Software increments must be delivered in short time periods
d. Software processes must adapt to changes
incrementally
e. Both c and d
Answer: e
1. To construct a system model the engineer should consider
which of the following restraining factors? Answer: e
a. assumptions
b. budget
c. constraints
d. schedule
e. both a and c
2. During business process engineering, three different
architectures are examined. Answer: a
a. applications, data, technology infrastructure
b. communications, organization, financial
infrastructure
c. network, database, reporting structure
d. systems, requirements, data structure
3. Which of the following is not one of the context-free
questions that would be used during project inception?
a. What will be the economic benefit from a good
solution?
b. Who is against this project?
c. Who will pay for the work?
d. Who will use the solution?
Answer: b
1. During the process of modeling the system in context,
systems that interact with the target system are not represented
as Answer: d
a. Peer-level systems
b. Subordinate systems
c. Super-ordinate systems
d. Working systems
6. In transaction mapping the first level factoring results in the
Answer: b
a. creation of CFD.
b. derivation of control hierarchy
c. distribution of work modules
d. refinement of the module view
7. A successful application of transform or transaction mapping to
create an architectural design is supplemented by Answer: e
a. entity relationship diagram
b. module interface descriptions
c. processing narratives for each module
d. test case for each module
e. Both b and c
7. The OO testing integration strategy involves testing Answer: a
a. groups of classes that collaborate or communicate
in some way
b. single operations as they are added to the evolving
class implementation
c. operator programs derived from use-case scenarios
d. none of the above
Filllment 填空题
5 Framework activity
沟通 策划 建模 构建 部署
Process models
惯用过程模型:
线性:瀑布过程模型 &经典生命周期 V 模型
并行:增量过程模型
演化过程模型:原型开发模型 螺旋模型 (迭代 )
协同开发模型 (concurrent development model)
专用过程模型:
基于构建的开发模型 (conponent-based)
形式化方法模型(formal method) 应用数学分析
Process flow type
线性过程流 迭代过程流 演化过程流 evolutionary 并行过程流 Parallel Software process is a layered
过程 方法 工具
XP process model 极限编程过程
策划 设计 敏捷建模 重构 编码 结对编程 测试
UP (5 phases)
初始 inception 细化 elaboration 构建 转换 transition 生产 production
UI design golden rules
用户操纵控制 place the user to control
减少用户记忆负担 reduce the user‘ s memory load
保持界面一致 consisitenty
Design model
数据 /类设计 体系结构设计 接口设计 构建级设计 Requirement engineering
起始 导出 elicitation 精化 elaboration 协商 negotiation
规格说明 specifiction 确认 validation 需求管理 managment
Requirement modeling focuses on
基于场景的元素 基于类的元素 行为元素 面向数据流的元素
Manifesto for agile software development statement 敏捷宣言
个体交互胜过开发过程和工具
可运行的软件胜过宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
Testing strategy
单元测试 集成测试 确认测试 系统测试
CMMI Level names
不完全级 incomplete 已执行级 performed 已管理级 managed
已定义级 defined 已定量管理级 quantiatively managed优化级 optimized
Term Explanation 名词解释
Software engineering
软件工程是:1将系统化,规范化,可量化的方法应用于软件的开发、运行和维护,即将工 程化方法应用于软件。 2,在 1中所述方法的研究。
Software Architecture
软件体系结构:指系统的一个或者多个结构, 包括软件的构件, 构件的外部可见属性以及它 们之间的相互关系。
Couple and Cohesion
内聚性:显示了某个模块相关功能的强度
耦合性:显示了模块间相互依赖关系
UML
统一建模语言:是一种支持 模型化 和 软件系统开发 的 图形化语言 , 为软件开发的所有阶段提 供 模型化和可视化 支持,包括由需求分析到规格到构造和配置
Regression testing
回归测试:在集成测试策略环境下, 重新执行已测试的某个子集, 以确保変更没有传播不期 望的副作用。
Waterfall model
瀑布模型 经典生命周期模型:当需求很清楚时候。他提出一个系统的,顺序的软件开发方
法,从用户需求规格说明开始,通过策划、建模、构建和部署的过程,最终提供一个完整的 软件和持续的技术支持。
Information hiding
信息隐藏:指在设计和确定模块时, 使得一个模块内包含的 特定信息 , 对于 不需要这些信息 的其他模块来说是 不可访问 的。
Software testing
软件测试:在 规定的条件下 对程序进行操作, 以 发现程序错误 , 衡量软件质量 ,并对其是否 能 满足设计要求进行评估 的过程。
Requirement Engineering
需求工程:指致力于 不断理解需求 的大量 任务和技术 , 从软件工程的角度看, 需求工程就是 一个软件工程活动,开始于沟通活动并持续到建模活动
Usecase
用例:识别系统 使用线索的场景, 提供了 系统将如何被使用 的描述。 用户如何在一个特定的 环境下与系统 交互 。
Class
类:具有相似属性和共同行为的事务集合。
CRC model
类 -职责 -协作者模型:可以识别和组织与系统或产品需求相关的类。
实际上是表示类的标准索引卡片的集合,写有类名,类的职责,类的协作关系。 Incemental Model
增量模型:增量模型综合了线性过程流和并行过程流的特征, 随着时间的推移, 增量模型在 每个阶段运用线性序列,每个线性序列生产出一个软件的可交付增量。
Polymorphism
多态性:一种机制, 允许一个类层次结构中的几个对象有不同的方法内容但具有相同的名称。 CMMI
能力成熟度模型集成:一个全面的过程元模型, 当软件开发组织达到不同的过程能力和成熟 度水平时,该模型可以用来评估其所开发系统和软件工程能力。
0:incomplete不完全级; 1:performed 已执行; 2 managed 已管理; 3 defined 已定 义; 4 quantitatively managed 已定量管理级; 5 optimized 优化级
Prototype model
原型开发:演化过程模型的一种。即当需求很模糊的时候,帮助理解需要做什么。 开始于沟 通, 迅速策划一个原型开发迭代并进行建模, 快速设计出原型并进行部署, 根据反馈进一步 细化软件的需求。
Open-Closed Principle
开关原则:模块应该对 外延 具有开放性, 对修改 具有封闭性。
Software Myths
软件神话:即关于软件及其开发过程的一些说法被人盲目相信, 这可以追溯到信息处理技术 发展初期。看起来是事实的合理描述(管理神话,用户神话,从业者神话)
Q&A 问答题
How do software characteristics differ from hardware characteristics?
(1)软件是设计开发的,而不是传统意义上生产制造的;
(2)软件不会磨损,但会因为变更而退化;
(3)虽然整个工业向着基于构件的构造模式发展,然而大多数软件仍是根据顾客 实际需求定制的。
Describe the differences between software construction and software deployment.
软件的构建包括了编码和测试任务,从而为向客户和最终用户交付可运行软件做好准备。 部署则包括了三个动作:交付, 支持和反馈。 用于现代软件工程本质上是演变的, 因此部署 并不是只发生一次。
两者都是软件工程的通用框架活动, 但是构建肯定是发生在部署之前, 部署是构建的下一个 活动。
Describe the five framework activities involved in the software process. 沟通:包含了与客户之间大量的 交流和协作 , 理解利益相关者 的项目目标,并 收集 需求 以定义软件的特性和功能。
策划:指为后续的软件工程工作 制定计划 ,它描述了 需求执行的技术任务 ,可能的 风险 , 资源需求 , 工作产品和工作进度
建模:包括 创建模型 和 设计 两个方面,创建模型有助于客户和开发人员更好地理解 软件需求,设计可以实现需求
构建:包括编码和测试
部署:将软件交付到用户手中,用户对其进行评测并给出反馈意见。
Which UML (unified modeling language) diagrams are useful in object-oriented analysis modeling?
基于场景的模型:用例图 活动图 UML 泳道图
基于类的模型:类图 协作图
行为元素:状态图 顺序图
List the types of models that might be used in requirements modeling and explain the role of each type of model.
(1)基于场景的元素:表述用户如何与系统和 使用软件时 出现的 特定活动序列 进行 交互 。
(2)基于类的元素:表示了系统操作的 对象 、应用于对象间能有效控制的 操作 、对象间的 关系 以及已定义类之间的 协作 。
(3)行为元素:描述了 外部事件 如何 改变 系统或驻留在系统里的 类的状态 。
(4)面向流的元素:表示信息转换 的系统,描述了 数据对象 在流过各种系统功能时是如何 转换 的。
What are the six steps for requirements engineering?
起始:对问题、 方案需求方、期望方案的本质、客户和开发人员之间初步的交流和合作的效 果建立基本了解;
导出:开展需求收集活动;
精化:将信息进行扩展和提炼,开发一个精确的技术模型用以说明软件功能特征和约束; 协商:不同客户提出了冲突的需求,通过协商解决冲突,使各方达到一定满意度; 规格说明,描述了一个基于计算机系统的功能和性能,以及那些将影响系统开发的约束; 确认:对需求工程的工作产品进行质量评估;
Briefly describe the primary differences between structured analysis and object-oriented analysis.
结构化的分析:一种考虑数据和处理的需求建模方法, 其中处理将数据作为独立实体加以转 换。 数据对象建模定义了对象的属性和关系, 操作数据对象的处理建模应表明当数据对象在 系统内流动时处理如何转换数据
面向对象的分析:关注于定义类和影响客户需求的类之间的协作方式
Describe the differences between the software engineering terms coupling and cohesion?
内聚性:显示了某个模块相关功能的强度
耦合性:显示了模块间相互依赖关系
构件应该保持高内聚性,低耦合性。
Describe each role of the following design models of data, architecture, interface and component-level design required for a complete specification of a software design.
●数据 /类设计:
创建在高抽象级上(用户观点)表示的 数据模型和信息模型 / 将分析类模型转化为设计类 的实现以及软件实现所要求的数据结构
●体系结构设计:
等效于房屋的平面图,提供了软件的整体视图,定义了软件 主要结构元素 之间的联系 ●接口设计:
相当于一组房屋的门、 窗和外部设施的详细绘图, 描述了信息如何流入和流出系统 以及被定 义为体系结构一部分的 构件之间如何通信
●构件级设计 :
相当于房屋中每个房间的一组详图及规格说明 , 软件的构件级完整地描述了每个 软件构件的 内部细节
1. 为所有局部 数据对象定义数据结构 data structure
2. 为所有在构件内发生的 处理定义算法 细节 algorithmic detail
3. 定义访问所有构件操作的 接口 interface
How does the object-oriented view of component-level design differ from the traditional view?
面向对象观点:注重细化来自 问题域和基础域的设计类 。 构件包括 一组协作的类 。 构件 中的每个类都得到 详细阐述 , 包括所有的 属性 和与其相关的 操作 。 所有设计类相互通信协作 的 接口 必须定义,设计师从需求模型开始,详细描述 分析类和基础类
传统观点:构件就是程序的一个 功能要素 , 程序由 处理逻辑 及实现处理逻辑所需的内部 数据结构 以及能够保证构件被调用和实现数据传送的 接口 构成。 传统构件也称为模块, 作为 软件体系结构的一部分,可细化为 控制构件 基础设施构件 问题域构件
What are the key differences between validation testing goals and verification (or acceptance) testing goals?
确认:确保开发的软件可追溯到客户需求的一系列活动(是否构造正确的产品)
验证:确保软件正确地实现某一特定功能的一系列活动 (是否正确地构造产品)
Why is regression testing an important part of any integration testing procedure?
每加入一个新模块作为集成测试的一部分时, 软件发生变更, 这些变更可能会使原来可以正 常工作的功能产生问题。在集成测试的环境下,回归测试是重新执行已测试过的某些子集, 已确保变更没有传播不期望的副作用。
Describe the differences between black-box testing and white-box testing. 黑盒测试是指在软件 接口处 执行测试, 只检查系统的 功能方面 , 不考虑软件的内部结构 。 是一种采用外部观察的方法的测试。
白盒测试是 基于过程细节 的 封闭检查 ,通过 提交检查特定条件集合 或 循环的测试用例 , 测试贯穿软件的 逻辑路径 和 构件间的协作 ,是一种采用内部观察方法的测试。
What is equivalence partitioning as it applies to software testing? What is scenario-based testing?
等价划分测试:一种黑盒测试方法,将所有可能的 数据划分成若干个等价类 ,每类 中找出一个典型值代表这一类,对每个典型值进行测试,来发现程序错误。理想测 试用例可以单独发现一类错误。
基于场景的测试:关心用户做什么,捕获用户必须完成的任务,然后在测试时使用 他们及其变体,倾向于用 单一测试检查多个子系统 ,用于发 现交互错误 。
Problem Analysis 设计分析题
Basic path testing
起始点 (起点不算结点数) 箭头 Y/N 美观 判断菱形 执行矩形
环复杂度 判断结点数 +1 边 -结点 +2
独立路径 每个分支都要走过
测试数据每个变量都要有
Process model application
我们采用了瀑布模型的变体 V 模型
由于我们的需求具有准确定义和相对稳定的特点, 因此从沟通到部署我们都采用线性流的工 作方式, 并且我们将验证确认动作也应用于我们的软件开发, 在经过需求建模、 体系结构设 计、构件设计和代码生成后,进行了单元测试、集成测试、确认测试和系统测试等一系列测 试活动,因此我们采用的过程模型为 V 模型
DFD mapping to software chart
范文四：四川大学软件工程硕士(南京开班)
四川大学软件学院
2015年在职人员攻读软件工程硕士学位研究生 招生简章
在职硕士考题简单,通过率高,对于毕业多年,没太多精力复习的职场人士,肯 定是最佳选择。也请各位把握住在职硕士单独考试的最后一次机会。
四川大学是教育部直属全国重点大学,是国家“ 985工程”和“ 211工程” 重点建设的高水平研究型综合大学。四川大学计算机学院(软件学院) 1958年 即设立计算机专业, 50多年来为社会培养了众多优秀的计算机专业人才。四川 大学计算机学院 (软件学院) 继续招收在职软件工程领域工程硕士研究生并行使 学位授予权。
一、培养目标
软件工程硕士是面向国民经济信息化建设和发展需要、 面向企事业单位培养 的高层次实用型、复合型信息技术应用和管理人才。
二、报考条件
1、具有国民教育系列大学本科学历(学位)及以上学历的人员,所学专业 和年龄不限; (原则上没有学位者占总录取比例不超过 10%,条件特别突出者可 适当照顾) 。
三、报名、审核和考试
1、报名前须填写《考生报名资格审查表》 ,经我校审查报名资格后,由考生 本人凭审查合格后的《考生报名资格审查表》 、毕业证、学位证、有效身份证明 原件和复印件我校报名。
- 1 -
2、我校将在国家规定时间在“中国学位与研究生教育信息网”按要求填写、 提交报名信息和学员电子照片。网上报名成功后,打印报名系统生成的《在职人 员攻读硕士学位报名登记表》 。
3、按规定时间(7月 15日前) ,考生本人凭《在职人员攻读硕士学位报名 登记表》 、第二代身份证和其他规定证件在南京进行现场确认。
4、按规定时间(10月中旬)和地点,考生持准考证并参加 10月底由国家 统一组织的硕士专业学位研究生入学资格考试(简称 GCT ) 。科目:《语言表达能 力》 、 《数学基础能力》 、 《逻辑推理能力》 、 《外语运用能力》 。
5、达到录取线的考生参加学院组织的专业基础考试和面试(一般 12月份, 具体时间另行通知) 。
四、培养方式及学位授予
学校将按照全国工程硕士专业学位教育指导委员会提出的 《制订软件工程领 域工程硕士培养方案的指导意见》 进行培养。 参加 2015年 GCT 考试并录取学员, 于 2016年 3月正式开学, 2017年 3月左右开始分配导师撰写论文,学习期满, 各门课程成绩合格,通过四川大学组织的学位论文答辩,将于 2017年底授予四 川大学工程硕士学位。 2018年 1月发放。
五、培养费用
1、报名时交报名费和考前辅导费 3800元。
2、收到录取通知书后,交学费及异地培养费 3.8万元。第一年交 2.2万, 第二年交 1.6万。
3、书本杂费按实收取。
六、联系方式
南京市广州路 16号, 3楼 309
- 2 -
范文五：四川大学考研故事
四川大学考研故事
大四了，大家都忙着为未来的道路做准备，有出国的，有考研的，也有找工作的，各自为了自己的前程而努力奋斗。我刚上大学时成绩其实是不错的，上游水平。但是大二上学期，因为生病了回家一段时间，回到学校后发现落了不少课，自己觉得很有压力，当时又迷恋上了看电子书，于是开始逃课，上课也不听课，整天流连于电子书中的世界不可自拔，一直到大三上学期，挂科挂的很厉害，当时竟然挂了两门专业课，自己觉得很后悔，本来也是学习不错的学生，可是竟沦落到这种地步，心里很是难受，想想父母更是觉得对不起他们，于是在大三下学期开始就好好学习了，终于把成绩提了上来，但是也因为大二至大三上学期那段荒唐的日子，总成绩也被拖累了下来。
11年1月份的时候大家都早早的开始准备考研了，也有3、4月份开始的，自己备考实在是没信心，看同学都报了考研班，其中川大文都金榜的人数挺多，正好同宿舍有人也是报了川大文都金榜的三科全程，于是我也去报名了。后来就一直去听海天的课程，课下并没有自己复习。暑假上完川大文都金榜的课程就回家了，在家呆了几个月，感觉东西都忘得差不多了，然后回来后一直有想找工作的念头，觉得自己考研挺没希望的，压力特大。虽然是想找工作，但是也没有放弃去听川大文都金榜的课，自己想着钱都交了，不听不就浪费了嘛。后来在十月份的时候学校里开始有公司来招聘，然后去参加了利群旗下的软件公司的面试，初试复试，机试都过了，然后是那个公司打电话说是让签三方协议，这个时候的我又陷入了纠结，毕竟考研班都报了，不考研的话以后再后悔真的就来不及了，毕竟参加工作后肯定没有现在学习理论知识的效果好。然后在考研报名时间的最后一天报上了名，由于感觉自己的准备时间仓促，考别的学校的戏基本没有，最终选择的是报本校。然后在上考研班的课程的同时，自己也开始复习，但是毕竟是好久都没有学习了，做题也不多，上考研班的时候大家一起学时还觉得挺好，也能学进去，而且还有老师讲着，听课效率也比较高，所以但是一自己复习就感觉不太想学，一直拖拖拉拉的，12月份才真正感觉到了时间的紧张，当大家谈论考研的一些知识而自己却一头雾水的时候，真的是很后悔没有早早复习，幸好当初有报考研班，不然自己真的会什么也不知道。还好学习效率算是高的，而且有川大文都金榜的老师讲课，复习起来感觉挺快，但是我们大四上学期课挺多，15周才结课，16周期末考试完，17周英语6级考试，18周一周去老校做电子电工实习，20周就要参加研究生考试了，那段时间真的是恨不能把时间一下子掰成十瓣用，心里的弦真的是绷得紧紧的，特有紧迫感。
这个时候就真没什么时间复习英语政治了，英语就只是听听川大文都金榜老师说的一些考试技巧，政治看了川大文都金榜发的28题，专业课用了一个周的时间，能理解的就理解着记忆，这样记得也比较深点，然后数学就看了看川大文都金榜老师讲课时自己记的笔记，但是由于时间真的很紧迫，到考试之前几天里我
已经感觉挺慌了，笔记上的题没看，就看了看基础知识。考前我已经镇定了下来，其实考不上也没什么，大不了下一年接着考么，而且自己也有了考研的经验，下一年考肯定不会再这么仓促了。第一场考政治，考前看了看二十八题，考英语的时候主要是把宫东风老师给的作文模板背了背，考数学的时候又把不怎么记得数的各种公式，川大文都金榜老师讲的一些方法看了看。
纵观此次考研，我的准备其实是不充分的，但是因为报了考研班，我又相对的系统化学了些东西。我最后的考研分数是:总分335分，政治56，英语52，数学93，专业课134，虽然考得不是很好，但是这相对于我的准备来说，我真的很知足。纵观此次考研的全过程，我的感悟就是，考研一定要趁早准备，不要拖到最后时间仓促，连准备的时间都不够了，最好可以报个班，川大文都金榜就很不错，老师讲课很专业，尤其是讲数学的川大文都金榜老师，他在告诉你考研的重点的同时，还会讲一些解决比较复杂的数学问题的简单做法，讲英语的宫东风老师很幽默，他讲的很清楚明了又有侧重性，我的感觉是很能提高英语水平，作文中的好句和作文的分段结构也能提高作文水平，政治上感觉阮晔老师讲的挺有激情，能带动学生积极性，讲课也比较好，还有常红利老师，不仅讲课讲得好，而且也善于增加学生考研的信心，能让备受压力的考生放平心态。
其实说一千道一万，考研班也只是引路人，考研班教的再好，如果你自己不努力听，也不努力学，那么你考研能考上的可能性真的很小。再好的引路人也不能将不想前进的人带到目的地。所以你自己是必须要学的，而且考研复习一定要准备早点，这样才能考高分，我就是因为没有准备的早点，自己也没有太努力，所以只能考到这个水平。这就是我自己考研的一些经历，希望大家引以为戒，能从中得到启示。
转载请注明出处范文大全网 » 2017年四川大学软件工程考
