搜索
软件工程第一章软件工程介绍1、软件的特性：P3-4①软件是设计开发的，而不是传统意义上的生产制造；②软件不会磨损；③大多数软件仍是根据实际的客户需求制定的。2、计算机软件的七大分类：P5系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。3、遗留系统发生系统演化的原因：P6①软件需要修改其适应性，从而可以满足新的计算环境或技术的需求②软件必须根据新的业务需求进行升级③软件必须扩展以具有与更多现代系统和数据库的协作能力④软件架构必须进行改建以适应多样化的网络环境4、软件神话：管理者，用户，从业者P135、软件的定义：P3、P7教科书定义：①指令的集合，通过执行这些指令可以满足预期的特征，功能和性能需求；②数据结构，它使得程序可以充分利用信息；③描述程序操作和使用的文档。IEEE给出一个更全面的定义：软件工程是：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。第二章过程综述1、软件工程的三个要素：工具，过程，方法P8过程：软件过程将各个技术层次结合在一起，并实施合理地，及时地开发计算机软件方法：为建造软件提供技术上的解决方法。工具：为过程和方法提供自动化或半自动化的支持。支持软件工程的根基在于质量关注点。2、通用软件过程框架：沟通，策划，建模，构建，部署P9沟通：这个框架活动包含了与客户之间大量的交流和协作，还包括需求获取以及其他相关活动策划：指为后续的软件工程工作制定计划。建模：它包括创建模型和设计两方面。创建模型有助于客户和开发人员更好得理解软件需求；设计可以实现它。构建：它包括编码和测试。部署：软件交付到用户，用户对其进行评测并给出意见3、能力成熟度模型：第0级：不完全级；第1级：已执行级（初始级）；几乎没有过程定义，成功完全取决于个人能力。第2级：已管理级（可重复级）；建立了基本的项目管理过程，能够跟踪费用、进度和功能。有适当的必要的过程规范，可以重复与以前类似的项目的成功。第3级：已定义级（定义级）；使用统一的、文档化的、组织过程认可的版本来开发和维护软件第4级：已定量管理级（管理级）；关注软件过程和产品质量第5级：优化级；通过定量反馈进行不断的过程改进，这些反馈来自于过程或通过试验新的想法和技术而得到第三章过程模型1、简述惯例框架包含的主要活动：P19沟通、策划、建模、构建、部署2、简述瀑布模型所包含的主要框架活动：P24沟通、策划、建模、构建、部署3、简述瀑布模型在实际运用中所面临的问题（缺点）：P24-25实际的项目很少遵守瀑布模型提出的顺序客户通常难以清楚地描述所有的需求客户必须有耐心，因为只有在项目的后期，他们才能看到可执行的程序。导致“阻塞状态”，常发生在开始和结束时4、演化过程模型生产的背景：P26在开发工程中，业务和产品需求经常发生变化，直接导致最终的产品难以实现；严格的交付时间使得开发团队不可能圆满完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。5、简述基于原型开发模型的软件开发过程：P26原型开发范型开始于沟通，定义软件的整体目标，明确已知的需求，迅速策划一个原型开发迭代并进行建模，快速设计产生一个原型，对原型进行部署，然后由客户或者用户进行评价。根据反馈，进一步细化软件的需求。6、原型开发的缺点：P27为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性。为了使一个原型尽快运行起来，往往在实现过程采用折衷的手段。7、统一过程的三个特点：P34用例驱动，以架构为核心，迭代并且增量8、简述统一过程（UP）的5个阶段的主要内容：P34-35起始，细化，构建，转换和生产UP的起始阶段包括客户沟通和策划活动细化阶段包括用户沟通和通用过程模型的建模活动UP的构建阶段通用软件过程中的构建活动UP的转换阶段包括通用构建活动的后期阶段以及第一部分通用部署活动UP的生产阶段通用过程的部署活动9、螺旋模型强调了其他模型均忽略了的风险分析。P28-2910、横切关注点的定义：P33如果某个关注点设计系统多个方面的功能，特性和信息，这些关注点通常称为横切关注点。第四章敏捷视角下的过程1、软件工程的敏捷理念强调4个关键问题：P40①具有控制力的自我组织团队对所开展工作的重要性；②团队成员之间、开发参与者与客户之间的交流与合作；③对“变更代表机遇”的认识；④强调快速软件交付以让客户满意。2、简述极限编程（XP）过程模型所包含的4个主要框架活动：策划，设计，编码，测试P45-47策划：策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”设计：XP设计严格遵循KIS（KeepItSimple，保持简洁）原则，即使用简单而不是复杂的表述编码：XP推荐在故事开发和基本设计完成之后，团队不应该直接开始编码，而是开发一系列用于检测本次发布的包括所有故事的单元测试，一旦建立起单元测试，开发者就可以更集中精力于必须实现的内容以通过单元测试。测试：在编码之前开始建立单元测试是XP方法关键因素。第五章系统工程1、计算机系统的6个系统要素：软件、硬件、人员、数据库、文档、规程2、Hatley-Pirbhai建模：用户界面、输入、系统功能和控制、输出、维护和自检3、系统环境图的表示方法第六章需求工程1、需求工程的过程：P63起始、导出、精化、协商、规格说明、确认和管理2、在项目起始阶段，软件工程师会询问一些视乎与项目无直接关系的问题，目的是对问题、方案需求方、期望方案的本质、客户和开发人员之间初步的交流合作的效果建立基本的谅解。P643、为什么导出需求这么困难：范围问题、理解问题、易变问题P64范围问题：系统的边界不清楚，或客户/用户的说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标理解问题：客户/用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在要求沟通上有问题，省略那些他们认为是“明显的”信息，确认的需求和其他客户/用户的需求相冲突，需求说明有歧义或不可测试。易变问题：需求随时间变化。4、用例的定义：讲述了能表达场景的故事：最终用户如何在一特点环境下和系统交互P735、在需求工程的导出阶段，三个主要的需求收集活动是：主持人会议、QFD和用户场景开发P69-71第七章构建分析模型1、分析模型在系统描述和设计模型之间建立桥梁：P852、分析模型必须实现的目标：P85①客户描述需要什么②为软件设计奠定基础③定义在软件完成后可以被确认的一组需求3、分析模型的所有元素都可以直接跟踪到设计模型P854、分析模型的4个元素：基于场景的元素，面向信息流的元素，基于类的元素，行为元素P77-78（P88之后详细介绍）5、UML泳道图是活动图的一种变形，可以让建模人员表示用例所描述的活动流，同时指示哪个参与者或分析类对活动矩形所描述的活动负责。P94-956、UML状态图为每个类表现活动状态和导致这些活动状态变化的事件P118-1197、UML顺序图说明事件如何引发一个对象到另一个对象的转移P119-1208、简述CRC建模的内容P103CRC模型实际上表示类的标准索引卡片的集合。这些卡片被分为三部分，顶部写类名，下面左侧部分列出类的职责，右侧部分列出类的协作关系。9、使用UML类图来举例说明组合聚合之间的区别10、使用UML类图举例说明关联和依赖之间的区别P10711、系统分析的经验原则P86①模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高点。②分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域，功能和系统行为的深入理解③关于基础结构和其他非功能的模型应推延到设计阶段再考虑。④最小化整个系统内的关联。⑤确认分析模型为所有共利益者都带来价值。⑥尽可能保持模型简洁第八章设计工程1、简述良好设计的三个特征：设计必须实现所有包含在分析模型中的明确需求，而且必须满足客户希望的所有隐含需求。对于那些生成代码的人和那些进行测试以及随后维护软件的人而言，设计必须是可读的、可以理解的指南。设计必须提供软件的全貌，从实现的角度说明数据域、功能域、和行为域。2、设计模型包含的四种元素是什么：数据、体系结构、构件和接口。P1273、软件体系结构的定义：软件的整体结构和这种结构为系统提供概念上完整性的方式P1464、模块应该详细说明且精心设计以求在某个模块中包含的信息不被不需要这些信息的其他模块访问P134信息隐蔽：每个模块对其他所有模块都隐蔽自己的设计决策。隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块相互之间只交流实现软件功能所必须的那些信息。隐蔽定义并加强了模块内的过程细节和模块所使用的任何局部数据结构的访问约束。5、重构的定义：是使用这样一种方式改变软件系统的过程：不改变代码设计的外部行为而是改进其内部结构P1366、举例说明逐步求精P1357、框架和设计模式之间的区别？框架通常是代码重用，而设计模式是设计重用第九章进行体系结构设计1、简述软件体系结构的作用：P146①分析设计在满足规定需求方面的有效性；②在设计变更相对容易的阶段，考虑体系结构可能的选择方案；③降低与软件构造相关联的风险2、软件体系结构的典型分类：以数据为中心，数据流体系结构，调用和返回体系结构，面向对象体系结构，层次体系结构（以图例来说明）P151-152以数据为中心数据流体系结构调用和返回体系结构层次体系结构3、体系结构环境图所包含的要素，以图例来说明P154-155上级系统、下级系统、同级系统、参与者第十二章软件测试策略1、简述软件测试策略的螺旋模型：单元测试、集成测试、确认测试、系统测试P261-271单元测试：侧重于软件设计的最小单元的验证工作。集成测试：是构造软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。确认测试：始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正。系统测试：实际上是对整个基于计算机的系统进行一系列不同考验的测试。2、简述单元测试中驱动程序和桩程序的作用P262驱动程序只是一个“主程序”，它接受测试用例数据，将这些数据传递给构件并打印相关结果。桩程序的作用是替换那些从属于将要测试的构建或被其调用的构建。3、集成测试的两种方式：增量集成与一步到位P2634、试以图例描述自顶向下集成测试的方法过程P2645、简述确认测试的两种主要方法：α测试和β测试P269α测试是由最终用户在开发者的场所进行β测试在最终用户场所执行6、系统测试的主要方法：恢复测试、安全测试、压力测试、性能测试P270-2717、三种调试方法：蛮力法，回溯法，原因排除法P274第十三章测试战术1、好的测试所具有的特性P279（测试特征）①好的测试具有较高的发现错误的可能性②好的测试是不冗余的③好的测试应该是“最佳品种”④好的测试应该既不太简单也不太复杂2、黑盒测试的定义P287黑盒测试暗指在软件接口处执行测试3、白盒测试的定义P281白盒测试，有时也成为玻璃盒测试，是一种测试用例设计方法，它利用作为构件层设计的一部分而描述的控制结构来生成测试用例。4、基本路径测试的环境复杂计算方法和独立路径集合的识别P281-283基本路径测试：使测试用例设计者产生一种过程设计的逻辑复杂性测度，这种测度为执行路径的基本集的定义提供指导。独立路径是任何贯穿程序的，至少引入一组新的处理语句或一个新的条件的路径。5、控制结构测试的3个主要方法：条件测试，数据流测试，循环测试P285-286条件测试：通过检查程序模块中包含的逻辑条件进行测试用例设计。数据流测试：就是根据变量的定义和使用位置来选择程序测试路径的测试方法。循环测试：是一种白盒测试技术，它仅侧重于循环构成元素的有效性。6、黑盒测试的两个主要方法：等价类划分，边界值分析P287-288等价类划分：是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。边界值分析：多数错误出现在输入域的边界处，而不是在