2011年有关第三四章节内容.docVIP

2011年有关第三第四章节内容 ISO/IEC 9126《软件工程 产品质量》统一了多种质量模型。其中，下述关于软件使用质量描述，不正确的是（19）。 （19） A、它测量用户在特定环境中能达到其目标的程度，不是测量软件自身的属性 B、使用质量的属性分为四个特性：有效性，生产率，安全性和满意度 C、使用质量是基于用户、开发者、维护者观点的质量 D、使用质量的获得依赖于取得必须的外部质量，而外部质量的获得则依赖于取得必须的内部质量 解析(课本P90)：影响软件质量可分为：可直接测量、间接度量包括：质量模型、外部度量、内部度量、使用质量度量。 外部、内部质量的质量模型：质量属性包括：功能性、可靠性、易用性、效率、可维护性和可移植性 评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。 　　评审的分类 　　一般来说，评审（Peer Review）包括下面几种 　　检视（Inspection） 　　团队评审（Team Review/Technical Review） 　　走读（WalkThough） 　　成对编程（Pair Programming） 　　同行检查（Peer DeskCheck） 　　特别检查（Ad hoc Review） 　　评审方法间的区别（1） 　　评审方法间的区别（2） 　　选择正确的评审方法 　　评审中的误区（1） 　　误区一：评审参与者不了解评审过程 　　如果评审参与者不了解整个的评审过程，就会有一种自然的抗拒情绪，因为大家看不到做这件事情的效果，感觉到很迷茫，这样会严重的影响大家参与评审的积极性。 　　评审中的误区（2） 　　误区二：评审人员评论开发人员，而不是产品 　　评审的主要目的是发现产品中的问题，而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情，于是评审变了“味”，变成了“批斗大会”，极大的打击了开发人员的自尊心，以至严重的影响了评审的效果。 　　评审中的误区（3） 　　误区三：评审没有被安排进入项目计划 　　参与评审需要投入大量的时间和精力，应该被安排进入项目计划中。但是现实的情况往往是，评审变成了“义务工”，参与评审的人员必须加班加点才能完成评审任务。如此一来，出现评审人员对评审对象不了解的情况也就不足为奇了。 　　评审中的误区（4） 　　误区四：评审会议变成了问题解决方案讨论会 　　评审会议主要的目的是发现问题，而不是解决问题，问题的解决是评审会议之后需要做的事情。但是，由于开发人员对技术的追求，评审会议往往变成了问题研讨会，大量的占用了评审会议的时间，导致大量评审内容被忽略，留下无数的隐患。 　　评审中的误区（5） 　　误区五：评审人员事先对评审材料没有足够了解 　　任何一份评审材料都是他人智慧和心血的结晶，需要花足够的时间去了解、熟悉和思考。只有这样，才能在评审会议上发现有价值的深层次问题。在很多的评审中，评审人员因为各种的原因，在评审会议之前对评审材料没有足够的了解，于是出现了评审会议变成了技术报告的怪现象。 　　评审中的误区（6） 　　误区六：评审人员关注于非实质性问题 　　经常会出现这样的问题，在评审中，评审人员过多的关注于一些非实质性的问题，比如文档的格式，措词，而不是产品的设计。出现这样的情况，可能的原因有：没有选择合适的人参加评审；评审人员对评审对象没有足够的了解，无法发现深层次的问题。 　　评审中的误区（7） 　　误区七：忽视细节 　　在组织评审的过程中，很多人不太注意细节。比如会议时间的设定，会议的通知，会议场所的选择，会场环境的布置，会议设施的提供，会议上气氛的调节和控制等等，而实际上这样的细节会大大影响评审会议的效果。比如，很难想象，大家在一个空气混浊、噪音很大的会议室里面能够全身心的投入。 参考答案：C 软件设计要遵循的基本原则包括（30） 模块化 (.抽象 (.封装 (.信息隐蔽 (30) A. (((( B. ((( C. ((( D. ((( 关于软件质量，（31）的叙述是正确的。 软件满足规定或潜在用户需求特性的总和 软件特性的总和，软件满足规定用户需求的能力 是关于软件特性具备“能力”的体现 软件质量包括“代码质量”、“外部质量”和“使用质量”三部分 （31）A．(( B．(( C．(( D．(( 解析：软件质量是系统完成事务执行准备后所采集的时间戳和系统完成待执行事务后所采集的时间戳之间的时间间隔，是衡量特定类型应用事务性能的重要指标，标志了用户执行一项操作大致需要多长时间。交易吞吐量：系统服务器每秒能够处理通过的交易数。当系统达到饱和点，服