现代软件工程复习题

# 仅供学习交流，严禁用于商业用途，请于24小时内删除

1.名词解释相关

软件的服从性？并举一个表现软件服从性的例子（日常生活）

服从性（Conformity） 软件不能独立存在，它总是要运行在硬件上面，它要服从系统中其他组成部分的要求，它还要服从用户的要求、行业系统的要求（例如银行利率的变化）。

2.简答题相关

软件工程师的思维误区，在实习过程中遇到的类似情况并说明

1.分析麻痹:篮球场上，有100%的把握再出手
2.依赖链条过长: 不分主次，想解决所有问题 
3.思维误区 – 过早优化
4.过早泛化

三种代码复审的名称和目的

1.自我复审 (self review) 自己 vs. 自己 用同伴复审的标准来要求自己。不一定最有效，因为开发者对自己总是过于自信。如果能持之以恒，则对个人有很大好处
2.同伴复审 (Peer Review) 复审者 vs. 开发者 简便易行
3.团队复审 (Team Review) 团队 vs. 开发者 有比较严格的规定和流程，用于关键的代码，以及复审后不再更新的代码。
覆盖率高——有很多双眼睛盯着程序。但是有可能效率不高（全体人员都要到会）

瀑布模型、生鱼片模型、螺旋模型概述

1.瀑布模型：它反映了软件开发的串行的，连贯的步骤 每一步的结果都是可验证的减少风险 给团队提供稳定的流程支持 产品定义非常稳定，正确性重要，每一步都要被验证 使用的技术非常成熟，团队成员对这些技术也非常熟悉 子团队在不同的地理位置，不可能做到频繁的交流
2.生鱼片模型：解决各个步骤分离的缺点
3.螺旋模型:在每一个版本都要衡量并控制风险 随着投入的增加和产品的运行，产品失败的风险在降低 需要高水平的管理团队 很难明确定义目标和稳定的里程碑

调研方法焦点小组和调查问卷的优缺点

焦点小组：找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等。
弱点： 一群人在一起，往往大家会出于讨好其他人的心理来发表意见，避免不一致的意见或冲突。参与讨论的人士表达能力也会有差异，有可能会出现一些善于表达的人士控制讨论议程的倾向。讨论者对于他们不熟悉的事物（例如全新的市场、颠覆式的创新）不能表达有价值的想法：
—在汽车出现之前，我们找一帮马车夫来畅想“未来的交通工具”，他们未必会贡献很有价值的想法。 
讨论者容易受到主持人有意或无意的影响。 研究者往往从不同意见中挑选最符合自己利益的那些条目，然后对外号称这就是大家的共识。
以上这些特点要求会议的组织者要有很强的组织能力，能让不同角色都充分表达意见，并如实地总结这些意见。
调查问卷：常见毛病 定义不明确， 使用含混的形容词 让用户花额外的努力来回答问题带有引导性的问题 过于开放式的问题 选择过于狭窄的问题

3.软件测试相关大题

根据题目情景划分有效等价类和无效等价类 有效集合 无效集合 以及生成最终测试用例
PS:题目中是否选择同意协议也算作条件
等价类划分-Example新浪邮箱
1.  4~16个字符
2.  支持英文小写、数字、下划线
3.  不支持全部为数字或下划线
输入条件	有效等价类	         无效等价类
用户名字符数	4~16(1)	          0(2)、0<个数<4(3)、>16(4)
用户名组成	英文小写(5)、数字(6)、下划线(7)	非英文小写、数字、下划线(8)
用户名支持格式	不全为数字(9)、不全为下划线(10)	    全为数字(11)、全为下划线(12)
生成最终测试用例：
1	57huang_hzm	符合要求
2	邮箱名为空		用户名字符数	3	hzm			    不符合要求
4	huzhaoming_1999_12_24
5	胡照名			  用户名组成
6	@#%……			
7	HZM				不符合要求
8	1234567890	     用户名支持格式
9	__________      不符合要求

4.分析燃尽图成因

考试考的ppt里这一类：产品后期 “Resolved” 的工作项太多，来不及转移到 “关闭” 的状态。  
可能的原因：测试人员不够？不能进行测试？

5.绘制 从代码完成到最终发布软件的流程图

6.UML大题根据一个产品完整的绘制用例图类图顺序图和部分活动图

用例图使用 include extend 泛化关系
类图 题目强调产品有软件、硬件之分 聚合组合关联关系 属性
活动图 泳道
顺序图  涉及对象的create destroy 循环 时间条件 激活区  控制流替代

# 仅供学习交流，严禁用于商业用途，请于24小时内删除

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！