软件工程实践者的研究方法_背诵知识点.docxVIP

软件的定义： 软件是： 1）指令的集合， 通过执行这些指令可以满足预期的特征、 功能和性能需求； 2） 数据结构，使得程序可以充分利用信息； 3）软件描述信息，以硬拷贝和虚拟形式存在，描述程序操 作和使用。 软件与硬件的区别：软件是设计开发的；软件不会磨损；大多数软件是按需求定制的。 IEEE 定义： (1) 将系统化、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法 应用于软件； (2) 在(1) 中所述方法的研究。 软件工程的层次： 软件工程的根基在于质量关注点。 软件工程的基础是过程层。 过程将各个技术层次结合在一起， 使得合理地、 及时地开发计算机软件成为可能。 方法为构建软件提供技术上的解决方法 如何做 ）。工具为过程和方法提供自动化或半自动化的支持。通用过程模型的 5 种框架活动 : 沟通、策划、建模、构建、部署 个典型的普适性活动：软件项目跟踪与控制；风险管理；软件质量保证；技术评审；测量；软件配置管理；可复用管理；工作产品的准备和生产 软件神化：关于软件及其开发过程被人们盲目相信的一些说法， 它实际上误导了人们对软件开发的态度。 螺旋模型： 一种风险驱动型的过程模型，一种演进式软件过程模型。它结合了原型的迭代性质和瀑布模型的系统性和可控性特点。具有快速开发越来越完善软件版本的潜力。 统一过程（ UP）：以用例为驱动、以系统架构为核心，迭代式增量式开发过程。 RUP包括起始、细化、 构建、转换和生产 5 个阶段。五个 UP阶段并不是顺序地进行，而是阶段性地并发进行。 成熟度级别：第 0 级：不完全级、 1 已执行级、 2 已管理级、 3 已定义级、 4 已定量管理级、 5 优化级软件生命周期：软件计划与可行性研究、需求分析、软件设计、编码、软件测试、运行与维护 瀑布模型：一个系统的、顺序的软件开发方法。 缺点：实际项目开发中很少遵守瀑布模型提出的顺序； 客户难以清楚的描述所有的需求； 客户要等到开发周期的晚期才能得到可执行的程序； 在线性过程的 开始和结束，容易发生“阻塞状态” 。 敏捷团队成员特点：基本能力、共同目标、精诚合作、决策能力、模糊问题解决能力、 相互信任和 尊重、自我组织 极限编程过程包含 4 个框架活动：策划、设计、编码、测试 设计原则： KIS 重构：以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程 结对编程：两个人面对同一台计算机共同为一个故事开发代码。 优点：结对的两人完成其工作， 他们所开的代码将与其他人的工作集成。 这种集成作为集成团队的日 常工作实施。还有一些情况下，结对者自己负责集成，这种“连续集成”策略有助于避免兼容 性和接口问题，建立能及早发现错误的“冒烟测试”环境 需求工程过程的 7 个任务：启始、导出、求精、协商、规格说明、确认和需求管理 质量功能部署（ QFD）三类要求：正常需求、期望需求、令人兴奋的需求。 用户场景：用来识别对将要构建的系统的使用线索的描述――用例。场景通常称为用例。本质上，用 例定义了最终用户如何在以特定的环境下与系统交互。 UML用例建模（用例图、活动图、状态图和类图） 启动需求的过程：确认共利益者；识别多种观点；协同合作；首次提问 导出需求的过程：协作需求收集；质量功能部署；用户场景；导出工作产品需求收集遇到的问题：范围问题、理解问题、易变问题 协同需求收集会议的基本原则： 1）软件工程师和客户共同举办和参与； 2）制定筹备与参与会议的规则； 3）拟定一个会议议程：既涵盖重点，又鼓励自由交流； 4）由一个主持人控制会议； 5）使用某种“定义机制”：工作表、活动挂图、不干胶贴纸，电子公告牌、聊天室、虚拟论坛 分析模型的三个目标： 1）描述客户需要什么； 2）为软件设计奠定基础； 3）定义在软件完成后可以 被确认的一组需求 分析模型由 4 种建模元素构成：基于场景的模型、流模型、基于类的模型和行为模型。 设计质量的指导原则： 1）设计应展示出这样一种结构： a 已经使用可使别的系统风格或模式创建 b 由展示出良好设计特征的构件构成 c 能够以演化的形式实现，从而便于实现和测试 2）设计应该模块化 3）设计应该包括数据、体系结构、接口和构件的清楚的表示 4）设计应导出数据结构，这些数据结构适于要实现的类，并由可识别的数据模式提取 5）设计应导出显示独立功能特征的构件 6）设计应导出接口，这些接口降低了构件之间以及与外部环境连接的复杂性 7）设计的导出应根据软件需求分析过程中获取的信息采用可重复使用的方法进行 8）应使用有效传达其意义的表示法来表达设计 软件质量属性： FURPS代表功能性，易用性，可靠性，性能，可支持性。 体系结构模型元素的三个来源： 关于将要构建的软件的应用域信息； 特定的需求模型元素， 如数据流 图