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