软件工程重点知识.docVIP

第一章 1．软件的定义（P4） 软件是计算机系统中与硬件相互依存的另一部分,它包括程序 、数据、相关文档的完整集合以及完善的售后服务。 2．软件与硬件的区别（P4） 软件是设计开发的；软件不会磨损；大部分软件是按需定制的 第二章 1.如何定义软件工程（P14） 简言之：工程方法+管理技术+技术方法 书上定义：(1)将系统化、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。(2)在(1)中所述方法的研究。 2.五个最基本的过程框架活动时什么？（P18） 沟通 这个框架活动包含了客户（和其他共利益者）之间大量的交流和协作，还包括需求获取以及其他相关活动； 策划 指为后续的软件工程工作制定计划； 建模 它包括创建建模和设计； 构建 它包括编码和测试。 部署 第三章 1.瀑布模型的优缺点是什么（P34） 优点 消除非结构化软件。 降低软件的复杂度，促进软件开发工程化。 缺点 实际的项目大部分情况难以按照该模型给出的顺序进行 。 经常情况下客户难以表达真正的需求 。 客户要等到开发周期的晚期才能看到程序运行的测试版本 。 可能会产生“堵塞状况” 2. RAD模型的缺点是什么（P36） 1对于大型项目，需要大量人力资源来创建RAD团队； 2如果开发者和客户没有做好短时间急速完成系统的准备，则可能导致失败； 3如果一个系统不能合理的模块化，会带来很多问题； 4如果系统需求是高性能的，并且需要通过调整构件接口的方式来提高性能，则不能采用RAD模型； 5技术风险高的情况下（使用大量新技术），也不宜采用。 第四章 1.有效的软件团队，其成员必须具备哪些显著特点（P56） 团队应该具备的特点： 基本能力 共同目标 精诚合作 决策能力 模糊问题解决能力 相互信任和尊重 自我组织 2.什么是结对编程（P59） XP编码活动中的关键概念之一是结对编程。即XP推荐/建议两个人面对同一台计算机共同为一个故事开发代码。 第五章 1.系统工程模型要完成什么工作？（P75） 定义在所考虑视图中满足需要的过程； 描述过程行为和该行为所依据的假设； 明确定义模型的外在和内在输入 外在输入连接给定视图中某一成分与同层或别层的其他成分，内在输入连接特定视图中相关的孤立部件 描述有助于工程师理解视图的全部联系（包括输出）。 2 .BPE中要定义和开发哪些架构？（P77） 三种不同的、存在于业务目标内容中的架构必须予以分析和设计: 数据架构 应用架构 技术基础设施 数据架构 为业务或业务功能的信息需求提供了框架，单独建立的框架模块是被业务所用到的数据对象。 应用架构 包含那些为了某些业务目的而在数据架构范围内进行转换的系统要素。 技术基础设施 为数据架构和应用架构提供了基础。 第六章 清晰地理解客户需求为什么很困难？（P89） 范围问题：系统的边界不清楚，或客户/用户的说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标。 理解问题：客户/用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在要求沟通上有问题，省略那些他们认为是“明显的”信息，确定的需求和其他客户/用户的需求相冲突，需求说明有歧义或不可测试。 易变问题：需求随时间变化。 举办一个协同需求收集会议的基本原则是什么？（P95） 软件工程师和客户共同举办和参与 制定筹备与参与会议的规则 建议拟定一个会议议程 由一个主持人控制会议 使用某种“定义机制” 目的是识别问题，提出解决方案的要素 第七章 1.数据对象如何在一个应用的环境内表现自己？（课本P111） 定义：由一组属性/特征描述，被软件（系统）管理的事物。 数据对象中没有操作。 数据对象可以是： 外部实体（打印机、用户、传感器……） 事物（报告、显示、信号……） 事件（警报……） 角色（销售人员、经理、工程师……） …… 书上：数据对象是几乎任何必须被软件理解的复合信息的表示。可以是外部实体、事物发生或事件、角色、组织单位、地点或结构。 2.如何确定某个潜在的类是否应该真的成为分析类？（课本P129） 保留信息：只有当相关信息必须被记录才能保证系统正常工作时，潜在类在分析过程中才是有用的。 所需服务：潜在类必须具有一组可确认的、能用某种方式改变类的属性值的操作。 多个属性：在需求分析过程中，焦点应在于“主”信息；事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，把它作为另一个类的某个属性可能更好。 公共属性：可以为潜在类定义一组属性，这些属性适应于类的所有实例。 公共操作：可以为潜在类定义一组操作，这些操作适应于类的所有实例。 必要需求：在问题空间中出现的外部实体，或者任何系统解决方案的运行所必需的 信息，几乎都被定义为需求模型中的类。 第八章