《软件工程》北京大学

  软件工程是北京大学在Coursera上发布的一套学习课程，该课程系统性的讲述了软件工程相关知识，有意向往数据产品经理发展的朋友可以学习一下。

课程介绍

知识结构：
软件开发本质=>软件生存周期过程=>软件生存周期模型=>项目生存周期过程（选择软件开发方法，例如结构化、面向对象，选择相应的支持和管理技术与方法）
课程内容安排：
1.软件工程概论：软件与程序的关系，如何从问题域中的问题，映射到运行平台上的软件。
2.软件过程：软件生存周期过程（软件开发有哪些活动），软件生存周期模型（如何组织这类活动）
3.软件需求与软件需求规约：需求定义、需求描述（产品需求文档），项目需求与软件需求区别
4.结构化分析：结构化分析的软件需求规约（产品需求约束文档）
5.结构化设计：软件体系结构设计（概要设计），设计每一模块内部的算法及数据结构（详细设计）
6.面向对象方法：UML概念，面向对象设计编程
7.敏捷开发方法：SCRUM 8.软件测试：软件测试方法及软件测试步骤
9.软件项目管理：项目管理目标、体系和框架
10.软件开发工具
参考书目：
《软件工程》北京大学
《软件工程》 Sommervile
《软件工程实践者的指南》Pressman
《面向对象的分析和设计》
《IT 项目管理》施瓦尔贝
《软件测试》Patton

软件工程概论

软件工程定义及特点
软件定义：程序+文档（软件需求规约、软件设计规约、软件测试文档）；特定人群 or 特定市场开发
软件特点：无形的、不可见的逻辑实体；设计开发的、不是生产制造的 ；软件是复杂的；软件开发成本很高；软件易于复制；成本集中在软件测试和维护
软件种类：系统软件、支撑软件（平台软件）、应用软件
软件工程的起源和概念
微电子基础，计算机网络是载体，软件是核心
软件开发阶段：个人程序时期（硬件价格昂贵，软件作为附属品）；软件作坊时期（高级程序设计语言，软件独立存在）；软件工程（70年至今，危机：软件质量差、开发成本难以控制、维护费用很高）
软件工程定义： 应用计算机科学、 数学及管理科学等原理，以工程化方法制作软件的工程；
是用来建立和使用合理的工程原则，以经济地获取可靠的且在真实机器上可高效工作的软件；
将系统化、规范的、可量化的方法应用到软件开发中；
软件开发的本质和基本手段
软件开发本质：问题域=>需求层=>设计层=>实现层，自下而上的映射 软件开发基本手段：系统建模（从问题域中的概念和处理逻辑到需求分析和设计层次的概念和处理逻辑的映射）、应用框架（更好的设计软件）、设计模型（设计质量和效率）
软件工程框架
软件工程可定义为三元组：目标、活动、原则 软件工程目标：正确性，可用性（文档规范易读），开销
软件工程活动：需求（需求获取、需求定义、需求规约、需求验证）、设计（总体设计、详细设计）、实现（设计结果=>程序代码）、确认（整个开发过程，需求、设计复审）、支持（完善性、纠错性、适应性维护）等活动
软件工程原则：选择适宜开发模型、提供高质量工程支持、重视开发过程的管理

软件过程

软件生存周期过程的概念
软件开发有哪些活动，要做哪些映射？
应如何正确组织开发活动？
软件周期：从概念开始，历经开发、交付使用，在使用中不断修订、演化最终淘汰。
软件开发需要做什么：过程是活动的集合，活动是任务的集合，任务是把输入转化成输出的操作
软件生存周期过程的分类
ISO软件生命周期过程：基本过程（软件生产直接相关的活动集：开发、获取、维护）、支持过程（各方面人员、开发组织、客户）、组织过程（软件生产组织有关的活动集：管理）
基本过程：获取过程（定义客户要求的所需的产品）；供应过程（供应商提供满足需求的产品）；开发过程（软件需求转化为系统）；运行过程（运行并测试）；维护过程（纠错性修改、完善性修改）
开发过程：系统需求分析（哪些软件、哪些硬件）、系统结构设计、软件需求分析、软件体系结构设计、软件编码、测试、安装及验收
支持过程：文档、配置管理、质量保证、验证、确认（评价产品状态）、联合评审（评价活动/产品状态）、审计、问题解决
组织过程：管理、基础设施、人力资源、改进、资产管理、复用程序管理、领域软件工程
各类过程之间的关系：需求及供应方（获取、供应过程）、管理者（管理过程）、运行者（运行过程）、开发及维护者（开发/维护过程、支持过程、组织过程）
软件生存周期模型的概念
一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖从系统需求定义到系统使用终止
软件过程、活动、任务的结构框架。（过程是活动的集合、活动是任务的集合，任务是输入转化为输出）
常见的软件生存周期模型
瀑布模型：系统需求、软件需求、需求分析、设计、编码、测试、运行（P为真，Q为真，那么P且Q为真）
优点：
（1）存在需求阶段，鼓励对系统“做什么”进行规约
（2）存在设计极端，鼓励规划系统结构
（3）在每一阶段进行复审
（4）前一工作产品可作为下一步认可的基线
缺点：
（1）必须完整、清晰表达需求
（2）缺乏灵活性
（3）浪费文档资源
（4）直到项目结束前，都不能演示
增量模型：增量规约、增量设计、增量实现、纠错性分析
优点：
（1）第一个可交付版本成本和时间很少
（2）开发由增量小系统承担风险
（3）用户需求变更限制
（4）增量投资
缺点：
（1）初始增量可能造成后续不稳定
（2）需求早期不完整，增量重新开发、发布
（3）管理成本、进度、配置复杂 演化模型：需求不明确，先做一个小版本反馈修改需求，再做一个小版本反馈修改，以此迭代输出。
喷泉模型：无缝迭代，两个阶段无严格界限（例如面向对象需求分析、系统设计）

软件需求与软件需求规约

软件需求的定义？在项目开展过程中处于什么位置？怎么样去捕获需求？捕获需求过程中有哪些手段？捕获后的需求如何描述？
软件需求作用：控制作用，耦合作用，利用自身提供服务
系统分析=>系统设计=>系统测试=>系统集成测试
系统规约中分配给软件的需求，软件规约中的软件需求进行细化
软件开发：自顶向下（瀑布模型：需求=>规约=>解决方案=>详细设计=>编码=>测试）和自底向上（软件单元构件=>满足目标）
需求定义：一个需求呢是一个有关要义构造的这个陈述，包括功能、性能、设计约束
需求性质：必要的、无歧义的、可测的、可跟踪的（从一个开发阶段到另一个开发阶段可跟踪么）、可测量的
需求分类：功能、性能、外部接口、设计约束、质量属性
功能：功能需求是整个需求的主体；非功能需求对功能需求而言可以一对多
性能需求：规约一个系统具有的性能特性
外部接口：系统与系统构建之间交互的硬件、软件和数据库元素（包括系统接口：应用如何与其他系统进行交互；用户接口：软件产品与用户间交互；硬件接口；软件接口；通讯接口）
设计约束：限制系统设计方案
质量属性：可靠性、存活性、可维护性、友好性、安全性、可移植性
需求发现：自悟（用户视角）、交谈（提出问题、回答问题）、观察（执行任务的过程）、小组会（客户、开发人员联合会议）、提炼（需求陈述）、综合运用
需求规约的概念和格式：需求规约是软件产品正式文档，也是软件产品概念模型
基本性质：重要性和稳定性程度，可修改，完整的，一致的
需求规约格式：
引言：目的、范围、定义、参考文献、概述（项目范围）
总体描述：产品概念、产品功能、用户特性、约束、假设和依赖
特定需求：重要非功能性需求
附录和索引
需求规约作用：
（1）软件开发组织和用户之间的技术合同
（2）一个管理控制点
（3）一个正式、受控的起始点
（4）创建验收测试计划和用户指南的基础
软件测试计划：（单元测试：详细设计）=>（集成测试：总体设计）=>（有效性测试：需求分析）
用户系统操作描述：初步用户使用手册
项目需求及需求规约：项目范围

结构化分析

结构化分析方法概论：结构化分析方法（需求分析、需求规约）、结构化设计方法（总体设计、详细设计）、结构化描述方法
软件需求与需求规约的区别？获取到的需求叫软件需求陈述，需求规范性的描述叫做软件需求规约。
结构化分析模型：
基本术语：数据流、加工（数据变化的单元）、数据存储（数据静态结构）、数据源、数据潭
注：数据流、数据存储（数据抽象），数据源、数据潭（系统边界抽象）
模型表达工具：数据流图（DFD图，表达系统功能模型的工具，包括基本术语）、数据字典（定义数据流与数据存储，例：现金额=余额，销售文件={销售商品}）、加工小说明（描述底层叶子加工，例如结构化自然语言：if 20<订票量 then 订票折扣为10%，判定表：类别、条件组合，判定树）
结构化分析过程：顶层数据流图（确立系统边界）=>自顶向下逐层分解=>建立数据字典>给出加工小说明
自顶向下：按人和部门的功能要求=>“分派”数据流=>引入文件，形成有机整体
数据字典：数据流、数据存储、数据项
加工小说明
注意：结构化分析方法是半形式化的规约方法，在表达上必须遵守一些约定
（1）模型平衡的问题（父图、子图边界一致，数据流、数据字典一致，叶加工与小说明一致）
（2）信息组织复杂性控制（上层数据可打包，一幅图应控制在7+-2以内）
需求规格说明书：引言、概述、数据流图、数据字典、加工小说明、接口、性能需求、属性、其他需求
引言：编写目的（需求说明书的编写目的），背景说明（待开发软件名称、本项目提出者、开发者及用户、软件将做什么、不做什么），术语定义（领域相关术语），参考文献
概述：功能概述（待开发产品主要功能）、约束（对系统设计产生影响的限制条件，管理模式、硬件限制、安全等），数据流图与数据字典加工说明 数据字典：文件说明、数据项说明
接口：用户接口、硬件接口、软件接口
性能需求：精度（输入及输出数据精度）、时间特征（响应时间、更新处理时间）、灵活性（操作环境、运行环境、时间特征）
属性：可使用性、保密性、可维护性、可移植性
数据库：数据库、操作、故障及处理
需求验证： 正确性、无二义性、完整性、可验证性、一致性、可理解性、可修改性、可跟踪、可被跟踪、设计无关性、注释

结构化设计

结构化设计概念：一种软件开发活动，定义实现需求规约所需的软件结构，包括总体设计（概要设计）和详细设计。
总体设计：体系结构设计（包括哪些模块、模块之间的关系）、接口设计（外部接口、内部接口）、数据设计
详细设计：模块内部设计（算法和数据结构）
总体设计阶段：初始设计（将DFD转化成MSD）；精华设计（高内聚低耦合）；设计复审
初始模块结构图设计：
数据流图分类：变化型DFD（物理输入/输出需要进行转换），事务性DFD
变化设计基本步骤：设计准备（复审并精化系统模型），确定输入、变化、输出三部分界限，第一层分解（系统模块结构图顶层和第一层设计），第二层分解（自顶向下，逐步求精）
事物设计基本步骤：设计准备（复审并精化系统模型），确定事物处理中心，第一级分解，第二级分解
初始模块结构图精华原则：模块、模块化、高内聚低耦合
模块（执行一个特殊任务的一组例程和数据结构）和模块化（把系统分解成若干模块的过程）
基本原则：高内聚（一个模块之内各成分之间相互依赖程度，由低到高：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚）、低耦合（不同模块之间相互依赖程度度量，由强到弱：内容耦合、公共耦合、控制耦合、标记耦合、数据耦合，尽量使用数据耦合，少用控制耦合，限制公共耦合，避免内容耦合）
初始模块结构化精细启发式规则：高内聚、低耦合；模块最好能够写在一页内（60行）；进一步分解过大模块，频繁调用小模块到上级中；深度、宽度、扇入（表示有多少个上级模块直接调用）和扇出（一个模块直接控制下级模块数目）适中；
输入部分精化、输出部分精化（将相似或类似的物理输出合并为一个模块）、变化部分精化（根据设计准则，根据实践经验）
接口设计：内部接口设计、外部接口设计，穿越系统边界的数据流定义
人机交互界面：必须根据需求把交互细节加入到用户界面设计中，包括人机交互所必须的实际显示和输入。
用户界面特性：可使用性（简单、界面一致、help帮助、快速系统响应、低系统成本、具有容错能力）、灵活性（满足不同的用户要求）、可靠性（无故障使用的间隔时间）
用户类型：外行型、初学型（需要很多界面支持）、熟练型（需要较少界面，不能处理意外错误）、专家型（需要为他们提供能够修改和扩充系统能力的复杂界面）。
界面设计类型：使用的难易程度、学习的难易程度、操作速度、复杂程度、控制、开发的难易程度。
设计原则：一致性、操作步骤少、不要“哑播放”（表明系统运行）、提供Undo功能（回溯功能）、减少人脑的记忆负担、提高学习效率（help帮助格式设计）
数据格式设计：文件设计、数据库设计
文件设计：数据量大非结构化数据、数据量大信息松散（历史记录、档案文件）、非关系层次数据（系统配置文件）、对数据存储速度要求极高
数据库设计：数据对象映射、关系的映射
详细设计工具：定义每一个模块
结构化程序设计概念：一个程序代码块仅通过顺序、选择和循环3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口。
伪代码：外部采用形式语言定义控制结构和数据结构，内部使用自然语言
程序流程图：顺序、选择、循环
PAD图：顺序、选择、循环（支持逐步求精设计：def）
N-S图（盒图）：顺序、选择、循环（支持自顶向下逐步求精）
判定表、判定树
软件设计规约：对软件组织或其组成部分内部结构描述，满足系统需求规约所指定的全部功能和性能需求。
概要设计规约：系统环境（硬件、软件接口和人机界面、外部定义数据库、设计有关的限定条件）、设计描述（数据流、模块结构、模块接口）、对每个模块的描述、文件结构和全局数据、软件测试方面要求和说明（集成测试）
详细设计规约：对软件各组成部分内部属性描述，概要设计的细化，软件设计人员与程序员之间交流的媒体。
设计规约格式：
引言：编写目的、背景说明、术语定义、参考资料
总体设计：需求规定、运行环境、处理流程、软件结构（在DFD图基础上，用模块结构图来划分）
运行设计：运行模块组合、运行控制
系统出错处理：出错/故障状况、出错处理方法及补救措施（后备技术、性能降级、恢复和再启动）
模块设计说明
结构化设计方法总结：一切系统都是由信息流组成的，每个信息流都有自己的起点-数据源，归宿-数据潭，有驱动信息流动的加工。
基本原则：自顶向下功能分解、数据抽象、功能/过程抽象、模块化
结构化方法是一种系统化的软件系统建模方法，例如：需求分析层=>设计层=>实现层
软件设计评审：
软件设计评审方法：非正式评审、正式技术评审
软件设计评审指南：概要设计评审、详细设计评审分开来做，建立一个议事日程，评审设计文档，评审提出问题应详细记录。
概要设计评审检查表：软件体系结构是否反映软件需求？模块功能独立？模块与外部接口定义？数据结构与软件需求一致么？考虑系统可维护性？是否直接评价了质量因素？
详细设计评审检查表：算法能否完成功能？算法逻辑正确？接口与体系结构设计一致？逻辑复杂性合理么？错误处理与反错误处理？

面向对象概念

面向对象的概念：以对象，对象之间关系构造软件的系统化的方法（面向对象的设计方法），包括：UML统一建模语言、USDP统一软件开发过程。
面向对象不仅是一种程序开发方法，面向对象是一种软件方法学。
例如：现实世界看到一辆车，计算机世界发动机、底盘、开关车门、启动…
面向对象方法主要特点：系统基本构成单位（对象），对象具有静态特征（属性），动态特征（操作）
对象属性和操作合为一体，构成一个独立的实体（封装）
对事物进行分类，相同属性相同操作封为一类
通过不同抽象原则，较多或较少忽视事物之间的差异
复杂的对象可以用简单的对象聚合
对象之间只能通过消息进行通信
用关联表达类之间的静态关系
基本思想：从现实世界中客观存在的事物出发建立软件系统；充分运用人类日常的思维方法。
面向对象方法意义适合解决分析与设计期间的复杂性并实现分析与设计的复用。
学习内容：
1.基本知识：概念、分析设计原则
2.面向对象分析(OOA)
3.面向对象设计(OOD)
4.面向对象程序设计(OOP)
UML概念：可视化语言，规约系统的制品（UML适用于对所有重要的分析、设计和实现决策进行详细描述），构造系统的制品（UML描述的模型可与各种编程语言直接关联）
需求获取层（USE-CASE图）
需求分析层（类图、交互图）
设计层（类图、交互图）
面向对象方法术语/符号：表达客观事物的术语、客观事物相互影响的术语
表达客观的术语表——类：类与对象，体现数据抽象
类：一组具有相同属性、操作的对象的描述；
对象：对象是类的一个实例；
属性：类的一个静态特征，属性相同属性值可不同；
操作：一个类所有对象要做的事情得抽象；
表达客观事物术语——接口和其他
接口：模型化系统中的“接缝”，接口只能被其他类目使用，而本身不能访问其他项目
协作：一组类、接口和其他元素的群体，共同工作以提供比各组成部分总和更强的合作行为。
用况：是对一组动作序列的描述
主动类：一种至少具有一个进程或线程的类
构件：系统中逻辑可替换的部分
制品： 节点：物理元素
基本模型化元素：接口、协作、用况、主动类、构件、制品、节点
类的变体：参与者、信号、实用程序
主动类的变体：进程和线程
制品的变体：应用、文档、库、页和表等
在UML中，把以上结构化概念统称为类目
控制复杂性术语——包
包之间关系：访问依赖、引入依赖（较多，第三个包引入源包，但不能够输出）
对成组的元素建模策略
表达关系的术语
关联：一组具有相同结构、相同语义的量，包括关联名、角色名、多重性、聚合（组合）、限定符
泛化：一般性事物和特殊父类
实现（细化）：类目之间的一种语义关系
依赖：用于描述一个事物使用另一个事物的信息和服务，有向虚线表示
UML基本关系的一般用法：
模型化简单依赖：一个类与另一个人就一种关系
模型化单继承：一组类，共同责任、属性和操作放到一个层次中，画出泛化关系
模型化结构关系：标识关联、标识的每一个关联添加描述、标识“整体/部分”
UML关系遵循策略：
仅当要建模的关系不是结构关系时，才使用依赖
仅当是“is-a-kind-of”关系时，才使用泛化
一般不要引入循环的泛化关系
应保持泛化关系的平衡，继承层次不要多深，不要多宽
UML的模型表达工具概述
系统静态部分建模工具：系统相对稳定的骨架，例如房屋的静态方面是墙、门、窗户等组成
一共有6种静态部分建模工具
类图：显示类、类的内部结构及与其他类的关系，最重要的工具
构件图：表达了系统有哪些构建，构建有哪些依赖关系
组合结构图：类和协作内部结构
对象图：一组对象及对象之间的关系，事物实例包含的数据结构
部署图：运行时要处理节点及制品的对应关系
制品图：一组制品之间的依赖关系
系统动态部分建模工具 ：系统变化的部分，如房屋动态包含了气流和人在房间走动。
一共有7种动态部分建模工具
用况图：需求模型
状态图：对象状态及对象状态间转移关系
活动图：从活动到活动控制流，特别像流程图，例如用户业务流程
顺序图：消息的时序，对象之间的交互情况
通信图：注重哪些对象之间有交互关系
交互概率图：非常少，描述用户宏观行为
定时图：消息跨越不同对象角色实际的时间
UML的模型表达工具——静态工具-类图：显示类、类的内部结构及与其他类的关系，最重要的工具
类图作用：可视化的表达系统的静态结构模型
类图内容：类、接口、依赖、泛化和关联关系，还包含注解、约束以及包和子系统
类图用法：
1.对系统中的概念建模，形成类图中的基本元素
2.对待建系统中的各种关系建模，形成该系统的初始类图
关联关系 依赖关系是使用关系，类与类之间具有操作关系 泛化关系“is-a-kind-of”关系，特殊类继承一般类 3.模型化系统中的协作，给出该系统的最终类图
UML的模型表达工具——动态工具-用况图：对行为的抽象
用况图内容：主题、用况、参与者、依赖、泛化、关联
用况图术语：例如做一次拼写检查、对一个文档建立索引
1.是系统分析和设计阶段的输入之一
2.是制定开发计划、测试计划的依据之一
3.可以划分系统与外部实体的界限
参与者：可以是人或其他的软硬件
关系：关联关系（操作者和use case之间唯一联系），扩展、包含、泛化
用况图使用：
1.对系统语境建模：任意一个系统，均有其内部事务和外部事务
基本策略： （1）区分系统内部和外部执行者，划分系统边界，并定义主题
（2）考虑谁需要得到系统帮助，谁执行系统功能，系统与哪些硬件交互，谁负责进行维护
（3）将相似的参与者放到一个结构中 （4）需要加深理解的地方，提供一个衍型
2.对需求建模：
基本策略：
（1）标识参与者建立语境
（2）考虑每个参与者系统提供的功能、行为
（3）分解公共行为，形成必要泛化关系
（4）模型化用况图中各种关系
（5）通过注解和约束给出非功能需求
UML的模型表达工具——动态工具-顺序图：交互图，一组对象以及这些对象之间的关系组成
顺序图内容：对象生命线、消息、控制结构
顺序图控制类型：选择执行、条件执行、并发执行、迭代执行
UML的模型表达工具——动态工具-状态图：强调一个状态到另一个状态的控制流
状态图包含：简单状态和组合状态、事件、转换
状态规约：命名、事件（内部事件、外部事件）、效应、目标状态
状态图用法：
1.建立一个系统动态方面的模型
2.建立一个场景的模型
UML总结：
UML作用： 1.从上到下，问题和解之间、产品与开发之间认知保持一致
2.提供相应的模型表示工具
需求描述：use case图
需求细化：类图（静态组织结构）、交互图（顺序图，对象间复杂关系）、活动图、状态机图（状态之间的关系）
具体来看： 8个基本术语：类、接口、协作、用况、主动类、构件、制品、结点（过程抽象、数据抽象）
关系4种术语：关联、泛化、细化、依赖，以及一些变体
控制信息复杂性：包
可使用注解、约束进行辅助说明

面向对象分析与设计

面向对象分析概述：OOA对问题域和系统责任进行分析和理解
OOA模型：需求模型（用况图）=>基本模型（类图：对象层、特征层、关系层）=>辅助模型（包图、顺序图、状态图）
OOA过程：定义use case=>发现对象=>定义属性与操作=>建立对象之间的关系=>划分包=>建立顺序图、状态机图、活动图等
识别类：
1.研究问题域和用户需求
（1）研究用户需求，明确系统责任
（2）研究问题域
（3）确定系统边界
2.策略和启发
（1）考虑问题域：人员、组织、物品、设备、抽象事物、事件、文件、结构
（2）考虑系统边界：启发分析员发现一些系统边界以外的参与者，包括人员、设备、外系统
（3）考虑系统责任：每一项需求是否有相应的对象提供
3.审查与筛选
（1）舍弃无用的对象：通过属性判断、通过操作判断
（2）对象的精简：只有一个属性的对象、只有一个操作的对象
（3）与实现条件有关的对象
4.识别主动对象
5.对象分类，建立类图中的类
（1）对象分类
（2）异常情况的检查和调整
识别属性和操作：
识别属性：
1.策略与启发
按常识这个对象应该有哪些属性，例如人的姓名、职业
当前域，对象应该有哪些属性，例如商品条形码
根据系统责任，这些对象需要有哪些属性，例如持卡人地点
对象为了实现操作，需要增设哪些属性？
2.审查与筛选
是否体现了以系统责任为目标的对象
是否描述对象本身的特征
是否破坏了对象特征的原子性
是否可通过继承得到
可以从其他属性中导出属性
3.与实现条件有关的问题都推迟到OOD考虑
4.属性的命名
5.属性的详细说明
识别操作：
1.区分对象行为的类型 ：系统行为、读写属性值、复杂操作计算
2.发现操作的策略与启发：考虑系统责任、问题域、分析对象状态、追踪操作的执行路线
3.审查与调整：是否真的有用（取消无效操作），是不是高内聚（拆分、合并）
4.认识对象的主动行为：考虑问题域，与系统外界进行交互的对象操作
5.操作的命名和定位 6.操作的详细说明:文字解释、操作名、输入及输出、消息发送、约束条件、操作流程
识别对象之间的关系：
识别继承（泛化）： 1.策略：当前领域的分类学知识，按常识考虑事物的分类，使用继承的定义（把每个类看作是一个对象集合，或者看一个类是不是具有另一个类全部的特征），考察属性和操作的适用范围，考虑领域范围内的复用
2.审查与调整：问题域中是否需要这样的分类，系统责任是否需要这样的分类，是否符合分类学的常识
3.继承关系的简化
4.调整对象层和特征层
识别关联：
1.策略
2.命名与定位命名：关联可用动词或动宾结构命名
3.调整对象层和特征层
识别聚合：
1.策略 2.审查和筛选
3.调整对象层和属性层
识别依赖：依赖是一种使用关系，用于描述一个事物使用另一事物的信息和服务。

面向对象的设计概述：OOD模型四个部分：问题域部分、人机交互部分、控制驱动部分、数据接口部分
目的是产生一个符合实现要求的面向对象的设计模型，提高软件生产效率和软件质量
面向对象分析是考虑做什么，面向对象的设计是考虑怎么做
面向对象分析考虑是问题域和系统责任，面向对象设计进一步考虑与实现有关的因素
OOD：按实现条件对OOA模型进行调整，并补充几个新的组成部分（也是由对象构成）
与实现相关：图形用户界面、硬件、操作系统、数据管理
OOA与OOD是调整和增补，不是简单的细化关系
问题域部分的设计：在OOA模型基础上，按实现条件进行必要的修改、调整和细节补充
为什么？
1.OOA只考虑问题域和系统责任，OOD则考虑具体实现有关的问题；
2.稳定部分和可变部分分开
3.有利于不同的设计与实现
4.使一个成功的系统具有其超过生存期的可拓展性
怎么做？
（1）为复用设计与编程的类而增加结构（尽可能复用的成分多，新开发的成分少）
（2）增加一般类以建立共同协议
（3）按编程语言调整继承和多态
（4）提高性能
（5）为实现对象永久存储所做的修改
（6）为编程方便增加底层细节
人机交互部分的设计：满足人机交互基本需求，同时让人具有更好的体验感
OOA：人机界面反应需求
OOD：设计人机交互的细节
1.使用人员的细化
区分人员的类型：熟练程度、职业、与系统关系、年龄
统计各类人员的比例
2.输入输出的细化
3.容错性的考虑
4.体验感好的用户界面
控制驱动部分的设计：是OOD模型组成部分之一，该部分由系统全部主动类构成
数据管理部分的设计：是OOD模型中负责与具体数据管理系统衔接外围的组成部分
1.选择数据管理系统
2.数据存放设计
为了存储自己，对象要知道：本类对象属性数据结构；本类对象对应哪个数据库表；对象实例对应数据库表的哪一行

面向对象编程：OOPL 如何选择编程语言？语言选择从实际出发，提供类和对象，提供封装机制
C++是一种混合OOPL，保持C语言高效、可移植
JAVA纯面向对象

敏捷开发

敏捷开发概念：是一种应对快速变化的需求的一种软件开发能力，强调程序员团队和业务专家之间、客户与团队之间的紧密合作，需要简洁的开发和设计。
敏捷联盟：个体和交互胜过过程和工具；可工作软件胜过面面俱到文档；客户合作胜过合同谈判；响应变化胜过遵循计划；
敏捷原则：获取有质量软件的理念；关于态度的声明；项目规划的理念（交付时间短）；团队组成和精神问题（业务+研发）；激励开发人员；获取开发信息的途径；进度度量的概念；项目“持续发展”的能力（反对快速拖向疲倦，保持恒定持续开发速度）；提高敏捷能力（设计能力）；自我调整和适应；
极限编程：XP通过一系列的实践去落实这样一个过程。
极限编程包含的实践：
（1）客户作为团队的成员，定义产品的特征，并对这些特征进行排序
（2）“用户素材” 一种规划工具
（3）短的交付周期
（4）验收测试
（5）结对编程
（6）测试驱动开发
（7）集体所有权（新代码与已有代码合并；和检入的程序员进行协商）
XP编程过程：包含策划（用户故事、验收测试标准）、设计（开发人员+客户：简单的CRC）、编码（结对编程、连续集成）、测试（单元测试、验收测试）4个阶段
敏捷设计：
避免问题：僵化性（难以对软件设计进行改动）、脆弱性（改动一个地方，其他地方出现问题，高耦合）、粘固性（设计难以复用）、粘滞性（软件、环境）、不必要复杂性、不必要复制
基本途径：
1.不需要一个完全成熟的初始设计，尽量简单的设计
2.团队通过多次单元/验收测试反复对设计进行优化
3.设计有一个持续改进的过程
敏捷过程模型Scrum：
Scrum三个阶段：规划纲要阶段；一系列的冲刺循环；项目结束总结项目；
Scrum过程流：30天内完成，待定项（为用户提供商业价值的项目需求）、冲刺（达到待定项所需的一些工作单元）、演示（向客户交付软件增量）
重要性：强调中间小组会议的控制，强调对于整体工作的划分，从而控制整个项目的复杂性。

项目管理

项目管理的概念：有开始结束时间，独特的生命周期，有自己的目的，项目包含不确定性。
《现在可以说了》曼哈顿计划：组织管理、人员配备、工程建设、保全保密措施、军事和科技情报
CPM关键路径法、统筹法=>PERT（引入风险分析，最乐观、最悲观、正常）
项目管理的定义：在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和预期。
项目管理的框架：范围、时间、成本、质量、人力、沟通、风险、采购
项目干系人：项目经理、客户、执行组织、团队、赞助者、竞争对手
知识领域：核心（范围、时间、成本、质量），辅助（人力、沟通、风险、采购），整体管理（项目计划制定、计划执行、整体变更控制）
管理工具和技术：WBS工作分解结构、甘特图、网络图值法、净值图、关键路径法
项目管理要素：范围、进度、成本、质量
项目生命周期：概念期、开发期、实施期、验收期
软件项目管理的概念：项目全过程和相应管理内容
管理工具和技术：集成管理：项目管理软件、变更请求，四大核心（范围：范围说明、工作分解结构、需求分析、时间：甘特图、成本：净限值、质量），人力资源，沟通，风险，采购

CMM和ISO9000

CMM概念：软件质量包括人员、技术设备、软件过程（持续）
CMM是软件能力成熟度模型，软件过程的评估模型
CMM基本内容：整个软件任务可以看做是一个过程，该过程可以予以控制、测量和改进。
CMM基本概念：
过程：通过该手段把人、规程、方法、设备以及工具进行集成
过程能力：高过程：定义了过程、开发管理遵循一个确定路径、过程得到很好的控制、过程制度化并不断改进
过程性能：一个是能够实现预期结果的程度，一个是得到实际结果；一个项目的实际过程性能，并不充分反应组织过程能力
过程成熟度：一个特定软件过程被明确和有效定义、管理、测量和控制的程度
组织成熟度
能力成熟度
CMM五级标准：初始级=>可重复级（严格过程）=>已定义级（标准的过程）=>已管理级（可预言的过程）=>持续优化级（持续改善）
初始级：没有提供开发和软件维护的稳定环境，过程能力不可预测
可重复级：软件项目有效管理过程制度化，组织可重复以前项目中的实践，过程能力可重复、基本可控、有效、稳定的、有纪律的
实现关键过程域：软件配置管理、软件质量保证、软件子合同管理、软件项目跟踪和监督、软件项目规划、需求管理
已定义级：过程域：过程焦点、过程定义、培训大纲、集成软件管理
定量管理级：定量过程管理和软件质量管理，过程能力：可预言、受控稳定、可定量估计、可定量预测
持续优化级：缺陷预防、技术变化管理、过程变化管理
ISO9000标准：质量保证体系，用于实现质量管理的组织结构、责任、规划、过程和资源
ISO9000标准是独立开发的，与CMM相比是一种完全不同的控制软件过程质量的途径。
ISO9000核心过程：产品交付过程（业务获取、设计和开发、测试、生产和交付、服务和支持），支持过程（业务管理、供应商管理、库存管理、配置管理）

软件测试

软件测试的概念：检测和评价软件，以确定其质量的过程和方法。软件测试可分为静态分析（检查和审阅）和动态测试（运行和使用软件）
软件测试的目标：预防错误、发现错误（未达到说明书的功能、说明书上指明的错误、超出说明书范围、虽未指出但应达到的目标、最终用户认为不好）
软件调试与软件测试区别：
（1）测试证明程序员“失败”，而调试是为了证明程序员正确；
（2）测试以已知条件开始，预先定义程序，预知结果；
（3）测试是有计划的；
（4）测试是一个发现、修改、重新测试过程；
（5）测试执行有规律；
（6）测试由测试组独立完成；
（7）大多数测试执行和设计可由工具完成；
软件测试过程模型：环境（硬件、固件、软件）、被测对象（控制结构-白盒测试，处理过程-黑盒测试）、错误模型（统一认识，定义什么是错误）
关键性概念：错误、失效、故障（一个或多个错误表现）
软件测试原则：
（1）所有测试都应该追溯到用户需求；
（2） 测试工作开始前，要进行测试计划的设计；
（3）测试应从小模块开始，逐步转向大规模；
（4）穷举测试是不可能的；
（5）为了尽可能发现错误，应由独立第三方来测试；
（6）测试只能保证尽可能发现错误，无法保证能够发现所有错误；
白盒测试：结构测试或逻辑驱动测试，检测产品内部动作是否按照规格说明书的规定正常运行。
（1）建立被测对象模型：控制流程图
（2）路径测试，严格限制所有可能的入口/出口路径
（3）语句测试：至少执行程序中所有语句一次
（4）分支测试：至少执行程序中每一分支一次
（5）条件组合测试：设计足够测试用例，使每个判定中所有可能条件取值组合至少执行一次。
语句覆盖<分支覆盖<条件组合覆盖<路径覆盖
（6）循环测试：主要功能路径、没有功能路径、最短路径
黑盒测试：功能测试或数据驱动测试，已知产品所应具有的功能，通过测试来检测每个功能是否正常使用。
测试方法：等价类划分、边界值分析、因果图、错误推测等，主要用于软件确认测试。
五大错误：功能不对或遗漏；界面错误；性能错误；初始化终止错误；数据结构或外部数据访问错误
事物流测试：用户角度所见的一个单元，步骤：获取事物流程图，浏览与复审，用例设计，测试设备开发，测试执行，测试结果比较
等价类划分：等价类、有效等价类、无效等价类，为每一个等价类规定唯一的编号；设计一个新的用例，使其尽可能多的覆盖尚未覆盖的有效等价类；设计一个新的用户，使其仅覆盖一个尚未覆盖的无效等价类（一个错误只对一个）；
边界值分析：边界值和超出边界值测试、第一个元素和最后一个元素
软件测试步骤：单元测试（采用白盒技术，参考详细设计文档）、集成测试（参考总体设计文档）、确认测试（采用黑盒技术，有效性测试，参考定义文档）、系统测试
单元测试：在代码编写完成后完成单元测试计划；代码审查（checklist）；静态测试（代码走查）；动态测试（单元测试用例）；执行单元测试；书写《缺陷跟踪报告》；书写《测试总结报告》；
集成测试：各模块链接，穿越模块接口数据是否丢失；一个模块功能是否对另一个模块功能产生影响；各子功能组合能否达到预期要求父功能；全局数据结构是否有问题；单个模块误差累加是否达到不可接受；
确认测试：验证软件有效性测试、软件配置审查、用户验证测试
系统测试：功能测试、恢复测试、安全性测试、强度测试、性能测试、可用性测试、部署测试

软件开发工具

软件开发工具及环境定义：计算机辅助软件工程CASE=软件工程+自动化工具
CASE狭义：一类特殊的软件工具，用于辅助开发、分析、测试、维护另一计算机程序或文档
CASE广义：除OS外所有软件工具的总称
CASE工具：工具（编辑器、编译器、文件比较器）、工作台（分析和设计、编程、测试）、环境（集成环境、以过程为中心环境）
工作台：程序设计工作台、分析工作台、测试工作台
软件开发环境SED与软件开发环境SEE
工具集成模型：
1.五级模型：平台集成、数据集成、表示集成（用户界面集成）、控制集成（工具之间相互调用）、过程集成（过程活动、约束和支持活动所需的工具）
2.APSE模型：基本上是一个程序设计工作台
3.层次模型：根据项目需要，提供不同支持，则环境需要接纳更多的case工具
平台服务：文件服务、进程管理服务、网络通信服务、窗口管理服务、打印服务
框架服务：建立在平台服务至上，支持CASE工具集成，包括数据仓库服务、数据集成服务、消息服务、用户界面
4.PCTE模型
常用的软件开发工具及环境：
主流应用软件：桌面应用、web应用、移动应用、其他工程领域
主流软件开发平台：windows，linux，安卓，ios