目录
定义：工作产品构建时所执行的一系列活动 、动作和任务的集合。
增量模型（Incremental Process Model）
软件工程与过程
什么是软件：
1.指令的集合（程序）通过这些指令来满足预期的特性、功能、需求
2.数据结构。使程序可以良好的使用信息
3.软件描述信息。以硬拷贝和虚拟形式存在，用来描述程序的操作和使用
软件与硬件的区别（软件特征）
| 软件 | 硬件 | |
| 生产方式 | 设计开发 | 传统生产制造 |
| 失效率 | 退化，但不磨损 | 磨损（wear out） |
| 可复用性（reusability） | 根据客户需求定制，可复用性低 | 构件组成，可复用性高 |
| 复杂 | 相对简单 |
书上的曲线描述（硬件失效率和软件失效率）
在完整的软件生命周期，软件不会磨损，软件的缺陷将在程序的生命周期前期造成高失效率（infant mortality），随着错误被纠正失效率降低，但是软件会面临变更，每次变更引入新的错误，失效率陡然上升，最小失效率上升，变更是导致软件退化（Deteriorates）的根本原因。第一张是硬件失效率，第二张是软件失效率。
软件生命周期：
软件从产生到报废的整个生命周期
问题定义-可行性研究-需求分析-系统设计-编码实现-软件测试-运行维护
软件工程：
定义
（1）将系统化、规范化、可量化的方法应用于软件的开发、运行和维护），即：将工程化的方法应用于软件开发
（2）以及对上述方法的研究
软件工程层次结构：工具，方法，过程，质量关注点（上到下）
质量关注点：
根基，质量承诺；软件开发是一种层次化的技术，任何工程方法都必须构建在质量承诺的 基础上。
过程：
软件工程的基础，将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能。构成项目管理的基础
方法：
为构建软件提供技术上的解决方法，解决如何做。包括沟通、需求分析、设计建模、编程、测试等技术。软件工程方法依赖于一组基本原则，这些原则覆盖了软件工程所有技术领域，包括建模和其他描述性支持等。
工具：
为过程和方法提供自动化或半自动化的支持。这些工具集成起来，使得一个工具产生的信息可被另一个工具使用，这样建立了软件开发的支撑系统，成为计算机辅助软件工程
软件过程
定义：工作产品构建时所执行的一系列活动 、动作和任务的集合。
- 活动 实现宽泛目标(如与利益相关者沟通)
- 动作 如体系结构设计,包含很多任务
- 任务 小而具体,如一个单元测试
通用软件过程框架：（怎样用这个框架描述过程模型）
沟通
理解利益相关者的项目目标，收集需求及定义软件特性和功能。
计划
定义和描述软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品、工作进度计划
建模
进行软件设计，通过模型更好理解软件需求
构建
包括编码和测试以发现编码中的错误。
部署
软件交付到用户，用户对其进行评测并给出反馈意见。
一些Umbrella activity:
风险管理、软件质量保证、技术评审、测量、软件配置管理、可复用管理、工作产品的准备和生产。
软件危机
落后的软件生产方式无法满足用户增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列验证问题的现象。
过程模型种类
线性过程流：从沟通到部署顺序执行五个框架活动
迭代过程流：在执行下一个活动前，重复执行之前的一个或多个活动
演化过程流：采用循环的方式执行各个活动
并行过程流：将一个或多个活动与其他活动并行执行
瀑布模型
典型生命周期模型
沟通、策划、建模、构建、部署
Pro：
适用于需求准确定义和相对稳定，工作将以线性方式进行到完成。
Con：
1)真正的项目很少遵守瀑布模型提出的顺序。随着项目的推进，变更可能造成混乱
2)客户难以清楚描述所有需求，因此很难适应许多项目开始阶段必然存在的不确定性。
3)最后才能看到可执行程序，如果系统存在重大缺陷，会导致损失惨重
V-模型
与之相似提供了将验证确认动作应用于早期软件工程中的方法
增量模型（Incremental Process Model）
线性+并行
Pro：
1）每个增量都是可提交运行的产品，（第一个增量往往是核心产品core pro）
2）早期增量可由少量的人员实现，克服人手不足
3）可以规避技术风险
Con：关注每一个增量的操作产品的交付。早期的增量很容易被“忽略”。
原型模型（Prototypin Model）
演化过程模型
Pro：
适用于客户需求不明确，不断调整弄清和满足用户需求。
Con：
1)原型系统一般会被扔掉，随意搭建，没有考虑整体软件质量和长期的可维护性。
2)采用折衷手段使用了不合适的操作系统或程序设计语言，这些选择遗留在后续的系统。
螺旋模型（spiral model）
螺旋模型是一种演化过程模型，它结合了原型的迭代性质和瀑布模型的系统性和可控性，具有快速开发越来越完善软件版本的潜力。
特点
1）循环方式逐步加深系统定义和实现的深度，同时降低风险
2）确立一系列里程碑，确保利益相关者都支持可行的和令人满意的系统解决方案
Pro：
1）使用原型作为风险降低机制，任何时候都可以应用原型模型方法
2） 开发大型系统和软件的理想方法。（开发人员和客户更好地理解和应对每一个过程中的风险）
Con：
1）很难说服客户（特别是以合同的形式）项目演进的方法是可控的
2）依赖风险专家来保证项目成功，如果存在较大的风险没有被发现和管理，会发生问题
统一过程模型（UP）
“用例驱动、以架构为核心、迭代和增量”的软件开发过程，关注风险
统一过程模型尝试从传统的软件过程模型中挖掘最好的特征和性质，但是以敏捷软件开发中最好的原则来实现
统一过程模型是使用UML进行面向对象软件软件开发的理想的过程模型
起始阶段：
客户沟通和策划活动，通过与利益相关者协作定义软件的业务需求，提出系统大致的架构，并制定开发计划以保证项目开发具有迭代和增量的特性。
该阶段识别基本的业务需求，并初步用用例描述每一类用户所需要的主要特征和功能。
细化阶段：
包括沟通和通用过程模型的建模活动。
细化阶段扩展了初始阶段定义的五种视图-----用例模型、需求模型、设计模型、实现模型和部署模型。
UP构建阶段：
对细化阶段开始的需求模型和设计模型加以完善，以反映软件增量的最终版本；软件增量所必须要求的特性和功能在源代码中实现；对每个构件设计并实施单元测试；实施其他集成活动。
目的：采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例
UP转换阶段：
包括构建阶段后期和部署活动的第一部分，软件被提交给最终用户进行Beta测试，用户反馈报告缺陷及必要的变更；软件开发团队创建系统发布所必要的支持信息。
结束后，软件成为可用的发布版本
UP生产阶段
与部署活动一致。监控软件的持续使用，提供运行环境的支持，提交并评估缺陷报告和变更请求。
敏捷方法
敏捷是什么？
最简而言之：快速、增量（迭代）
- 快速交付产品
- 对变化的有效响应
- 客户加入团队，所有利益相关者之间的有效沟通
- 项目计划必须灵活
- 一个自组织团队，便于沟通
敏捷宣言
个人和这些个人之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
敏捷过程模型
Scrum
需求及建模
需求工程
定义
- 需求工程是指致力于不断理解需求的大量任务和技术。
- 建立了从设计到构建的桥梁
- 从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动并持续到建模活动
1) Inception（启示） ：Establish a basic understanding of the problem and the nature of the solution
2) Elicitation（导出） ：Draw out the requirements from stakeholders
3) Elaboration（精化） ：Create an analysis model that represents information, functional, and behavioral aspects of the requirements.
4) Negotiation（协商） ：Agree on a deliverable system that is realistic for developers and customers.
5) Specification（规格说明） ：Describe the requirements formally or informally.
6) Validation（确认）：Review the requirement specification for errors, ambiguities（模糊）, omissions（遗漏）, and conflicts
7) Requirements validation（需求管理）：Manage changing requirements.
需求模型
4种模型要素：
基于场景的元素
用户视角，如基本用例及其相应的用例图
用例图，活动图，泳道图
基于类的元素
当参与者和系统交互时所操作的一组对象，这些对象被分成类—具有相似属性和共同行为的事物集合。如类图
类图、CRC模型、collaboration图
行为元素
描述行为的建模元素。如状态图
状态图、时序图
面向数据流的元素
信息在系统中流动时会被转换，系统接收多种形式的输入，使用函数将其转换，生成多种形式的输出。
数据流图、控制流图、
三种模型
数据模型
WHY：
Examine the data objects of processing independently
Focus attention on the data domain
Create a model of abstraction at the customer’s level
Indicate how data objects relate to one another
E-R图；数据字典；
功能模型
DFD；
行为模型
显示软件如何对外部事件或激励做出响应
状态转换图、Control Specification、Process Specification、序列图
OOA（面向对象分析）
定义
is to develop a model that describes computer software as it works to satisfy a set of customer-defined requirements.
用例图：
Use-cases are simply 帮助定义系统外部存在的内容以及系统应该执行的内容。.
- A scenario that describes a “thread of usage” for a system
- Actors represent roles people or devices play as the system functions
- Users can play a member of different roles for a given scenario
用例图、活动图、时序图、状态图、分析类图、协作图
SA（结构化分析模型）
Structured analysis is a model building activity
- 1）The products of analysis must be highly maintainable.
- 2）The size of problems must be controlled.
- 3）Graphics have to be used whenever possible.
- 4）We have to differentiate between logical and physical.
数据模型：E-R、数据字典（DD）、DOD
为什么用数据模型：
1）Examine the data objects of processing independently.
2）Focus attention on the data domain.
3）Create a model of abstraction at the customer’s level
4）Indicate how data objects relate to one another
功能模型：DFD
行为模型：STD（状态转换图）、PSPEC、CSPEC
系统设计
设计概念
抽象：
对问题所处环境的语言以概括性的术语描述解决方案，在最高的抽象级上，使用问题所处环境的语言以概括性的术语描述解决方案，在较低的抽象级上，将提供更详细的解决方案说明。
过程抽象：暗示功能，隐藏细节
数据抽象：描述数据对象的冠名数据集合
体系结构：
软件整体结构和这种结构为系统提供概念完整性的方法。
属性：
结构特性：定义了系统的构件、系统被封装的方式以及构件之间相互作用的方式。
外部功能特性：指出体系结构如何满足需求，包括性能需求，能力需求，可靠性需求，安全需求，可适性需求以及其他系统特征需求。
相关系统簇：能抽取出一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。
模式：
设计模式描述了在某个特定场景可能影响模式应用和使用方式的“影响力”中解决某个特定的设计问题的设计结构
模块化：
关注点分离最常见的表现，软件被划分为独立命名、可处理的构建，把这些构建集成到一起可以满足问题的需求。
信息隐藏：
每块模块对其他所有模块隐藏自己的设计决策，模块规定并设计成为在模块中包含的信息不被不需要这些信息的其他模块访问。
关注点分离
设计概念，表面任何复杂的问题如歌被分解成可以独立解决和优化的若干块，该复杂问题能够更容易地被处理。
功能独立：
标准：内聚性和耦合性
重构
重新组织技术，可以简化构建设计而无需改变其功能或行为
内聚（cohesion）
信息隐藏概念的自然扩展，一个内聚的模块只有一个独立的任务。将内聚性描述为构件的专一性，在为面向对象系统进行构件级设计时，内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。内聚性显示了某个模块相关功能的强度；耦合性显示了模块间的相互依赖性。
巧合内聚：不相干的功能，过程或数据在同一个模块被发现
逻辑内聚：逻辑相关的功能湖泊数据被放在同一个模块
时间内聚：一个模块包含的任务必须在同一段时间内执行
过程内聚：模块内必须以特定次序执行。
通信内聚：访问相同数据的所有操作被定义在一个类中
顺序内聚：处理必须顺序执行
功能内聚：一个模块只完成某一组特定操作并返回结果
分层内聚：高层能访问低层，底层不能访问高层的服务
耦合（coupling）
软件结构中多个模块之间相互来连接。耦合性显示了模块间的相互依赖性。耦合是类之间彼此联系程度的一种定性的度量。随着类相互依赖越来越多，类之间的耦合程度亦会增加。
内容耦合：当一个构件暗中修改其他构件的内部数据------违反信息隐蔽原则
公共耦合：大量构件使用一个全局变量
控制耦合：A调用B，并向B传递控制标记。接着控制标记指引B的逻辑流程----------B的不相关变更导致A传递控制标记的意义变更。--------忽略，不会引起错误
数据耦合：需要传递长串的数据参数时。
特征耦合： 当把数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合
原则：尽量数据耦合，少控制耦合，限制公共耦合的范围，完全不用内容耦合。
数据设计：
或类的设计，将类模型转化为设计类的实现以及软件实现所要求的数据结构。
三个层次：
体系结构设计、构件设计、接口设计
体系结构设计（Architectural）
体系结构概念：
指系统的一个或者多个结构，它包括软件构件、构件的外部可见属性以及它们之间的相互关系
风格：
1）完成系统需要的某种功能的一组构件
2）能使构件间实现“通信、合作和协调”的一组连接件
3）定义构件如何集成为系统的约束
4）语义模型，能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质
体系结构风格的分类：
以数据为中心的体系结构
数据存储驻留在这种体系结构的中心，其他构件会经常访问该数据存储，并对存储中的数据进行更新、增加、删除或者修改
数据流体系结构
数据经过一系列的计算构件和操作构件的变换形成输出数据时可用。
管道-过滤器模式：构件通过管道连接，数据从一个构件传到下一个构件，过滤器独立于两个构件工作，过滤器的设计针对某种形式的数据输入。
调用和返回体系结构
子风格：
主程序/子程序体系结构：将功能分解为一个控制层次，“主”程序调用一组程序构件，这些程序构件又去调用其他构件。
远程过程调用体系结构。主程序/子程序体系结构的构件分布在网络的多台计算机上。
面向对象体系结构
系统的构件封装了数据和必须用于控制该数据的操作，构件间通过信息传递进行通信与合作。
层次体系结构
定义了一系列不同的层次，每个层次各自完成操作，这些操作逐渐接近机器的指令集。在外层，构件完成建立用户界面的操作，在内层，构件完成建立操作系统接口的操作；中间层提供各种实用工具服务和应用软件接口。
构件设计（component）
构件定义：
构件是计算机软件中的一个模块化的构造块。系统中的模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口
设计原则：
开闭原则：
对外延具有开放性，对修改具有封闭性，即无需对构建自身内部做修改就可以进行扩展
里氏替换：
子类可以替换它们的基类
依赖倒置：
依赖于抽象而非具体实现
接口分离：
为每个主要客户类型都设计一个特定的接口
接口设计（大题）
黄金准则
- 用户操纵控制
- 减少用户的记忆负担
- 保持界面一致
系统测试
软件测试：
以特定的目标执行程序，在交付给用户前发现错误。软件测试是软件质量保证的关键要素，代表了对规范、设计和代码生成的最终审查
测试目标：
发现软件设计和实现过程中的疏忽所造成的错误
测试过程：
最初，测试侧重于单个构件，确保它起到单元的作用，接下来组装或集成各个构件以形成完整的软件包。集成测试处理并验证与程序构造相关的问题，在集成过程中，普遍使用关注输入和输出的测试用例设计技术。在软件集成测试完成后，执行一系列高阶测试，必须评估确认准则。确认测试为软件满足所有的功能、行为和性能需求提供最终保证。
单元测试
侧重于软件设计的最小单元（模块）的验证工作。利用构件级设计描述作为指南，测试重要的控制路径以发现模块内的错误。
集成测试
旨在发现与接口相关的错误的测试
增量集成策略
目标：利用已通过单元测试的构件建立设计中描述的程序结构。
自顶向下的集成：
增量方法，从主控模块开始，沿着控制层次逐步向下，以深度优先或广度优先的方式将从属于主控模块的模块集成到结构中
步骤：
- 测试顶端模块，用存根程序(stub)代替直接附属的下层模块
- 根据深度优先或宽度优先的策略，每次用一个实际模块代换一个stub
- 在结合进一个模块的同时进行测试
- 回归测试(regression testing)——全部或部分地重复以前做过的测试
优点和问题：
优点：在早期即对主要控制及关键的抉择进行检验。
问题：Stub只是对低层模块的模拟，测试时没有重要的数据自下往上流，许多重要的测试须推迟进行，而且在早期不能充分展开人力。
自底向上的集成
从原子模块开始构造和测试。
步骤
- 把低层模块组合成族，每族实现一个子功能。
- 用驱动程序(Driver)协调测试数据的I\O，测试子功能族。
- 去掉Driver，自下而上把子功能族合成更大的子功能族。
两种策略的优、缺点刚好互补，但单用其中任一种都不实际，通常根据软件的特点将二者混用。
三明治测试
同时使用自底向上和自顶向下的测试方法，综合了两种方法的优点，也产生了新的缺点
- 选择一个层为中间层
- 对中间层以上的层使用自顶向下的测试
- 对中间层以下的层使用自底向上的测试
- 中间层不测试或者单独测试
优点：出来具有自顶向下和自底向上两种集成策略的优点之外，运用了一定的技巧，能够减少桩模块和驱动模块的开发
缺点：中间层不能尽早得到充分的测试，或者因为中间层如果选择不适当导致增加驱动模块的和桩模块工作量的设计负担
Big-Bang集成测试
大爆炸集成是属于非增值式集成的一种方法，也叫一次性组装或者整体拼装。该集成测试在辅助模块的辅助下，一次性把所有系统组件集合到被测系统中，不考虑组件之间的相互依赖性或者可能存在的风险，一般一次性成功的几率不大
大爆炸测试比较适合在原有稳定系统增加子模块或者系统较小时使用
优点：
成本低，测试用例少，幸运的话，可以不需要或者只需要开发少量的辅助模块，就可以完成测试
缺点：
这种一次性组装的方式图在辅助模块的协助下，在模块单元测试基础上，将所测模块连接起来进行测试。不可避免的存在模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大，即使运行成功，也很可能会存在隐患
回归测试：
重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用
冒烟测试：
对整个系统进行彻底的测试
验证与确认
验证：
确保软件正确的实现某一特定功能的一系列活动。--正确的构造软件
确认：
确保开发的软件可追溯到客户需求的另一系列活动。--构造正确的软件
确认测试：
始于集成测试结束。当软件可以按照用户合理的预期方式工作时，确认成功。软件确认是通过一系列表面与软件需求相符合的测试而获得的
α测试：
具有代表性的最终用户在开发者的场所进行，开发者通过用户来观察开发的软件， 是在受控的环境下进行的，在开发环境下进行
β测试：
在一个或多个最终用户场所进行“现场”应用，开发者不在现场，在用户环境下进行
系统测试
对整个计算机的系统进行一系列不同考验的测试
恢复测试
在系统出故障后，系统能否从故障中恢复过来，并在预定的时间间隔内从新开始处理
强使软件出现故障，系统应自动恢复
如需人工干预，应估算出修复的平均时间，确定出是否可接受
安全性测试
系统的预防机制（预防非法入侵:窃贼，报复，非法牟利……)
安全性测试，验证系统的预防机制
测试者扮演期望侵入系统的角色，通过一切可能的措施侵入系统
测试开销可能很大
压力测试
在一个非正常数量，频率或容量方式下运行系统
测试者想办法破坏程序
1）运行要求最大内存或其他资源的程序
2）按大小递增的顺序改变输入数据的速率，看系统怎样响应
性能测试
测试软件被组装进系统的环境下运行时的性能
性能测试覆盖测试过程中的每一步
部署测试
部署测试，又叫做配置测试（Configuration testing),测试不同的运行环境
黑盒测试与白盒测试
黑盒测试
就是功能测试,从外部执行测试用例,用以验证待测功能的正确性,而不考虑软件内部处理逻辑,外部测试
等价类划分
等价类划分是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。
边界值分析
一种测试用例设计技术，是对“等价划分”的补充。BVA不是选择等价类的任何元素，而是在等价类“边缘”上选择测试用例，其不是仅仅侧重于输入条件，也从输出域中导出测试用例
白盒测试
叫玻璃盒测试,是一种测试用例设计方法.它利用作为构件层设计的一部分所描述的控制结构来生成测试用例.白盒测试是基于过程细节的封闭测试.测试构建内部的数据结构,算法流程与接口,内部测试.
基本路径测试方法（大题）
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
