说实话，第一章基础综合知识挺多的，而且偏向技术方向，对于非技术方向人员来说多少有些劝退作用，不过学习嘛，不就这样，激流勇进方式正途！
一，软件需求层次
1. 业务需求：业务需求是指反应企业或客户对系统高层次的目标要求，通常来自项目投资人，购买产品的客户，客户单位的相关人员等，通过业务需求可以确定项目的范围。
2.用户需求：指用户的具体需求，或者用户对系统必须完成的任务，如系统必须支持一键分享功能等，通常通过用户访谈和问卷调查方式收集用户需求
3.系统需求：系统需求是从系统的角度出发，说明软件的需求，包括功能需求，非功能需求和设计约束等；功能需求也称之为行为需求，它规定了开发人员必须在系统中实现的软件功能；非功能需求指系统北徐具备的属性和品质，如可维护性，可靠性等；设计约束也称之为限制条件，通常是对系统的一些约束说明，如系统数据库必须采用Mysql等。
二，质量功能部署QFD
是一种将用户要求转化为需求的技术，目的是最大限度提升软件工程中有用户的满意度。
1.常规需求：用户认为系统应该做到哪些功能，实现越多用户越满意（意思是越少的支出实现越多的功能…嗯就是这样）。
2.期望需求：用户想当然人为系统应该具备的功能或者性能，但不能正确描述自己想要得到这些功能需求，如果没实现这些需求，用户将会感到不满意。
3.意外需求：也称之为兴奋需求(镀金需求)，是用户要求范围外的功能，一般是开发人员乐意赋予的一些技术特性，实现这些需求客户将感到更高兴，但不实现也不影响其购买的决策。
三，软件需求规格说明书
需求开发活动的产物，编制该文档目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。一般包括以下内容：1)范围 2)引用文件 3)需求 4)合格规定 5)需求可追踪性 6)尚未解决的问题 7)注解 8)附录
四，UML统一建模语言
一种定义良好，易于表达，功能强大的建模语言。可以支持从需求分析开始的软件开发全过程，是一个通用的可视化建模语言，用于对软件进行描述，可视化处理，构造和建立软件系统的文档
1.UML中的关系
1.1 依赖：依赖是两个事务之间的语义关系，其中一个事务发生变化会影响另外一个事务
1.2关联：关联描述一组对象之间连接的结构关系
1.3泛化：泛化是一般化与特殊化的关系，描述特殊元素的对象可替换一般元素的对象
1.4实现：实现时类之间的语义关系，其中一个类制定了由一个类保证执行的契约
2.UML2.0常见的12种图
2.1 类图：描述一组类，接口，协作和他们之间的关系，是静态设计视图，如下图
2.2对象图：描述一组对象及他们之间的关系，是静态设计视图，如下图：
2.3构件图：描述一个分装的类和他的接口，端口，以及由内嵌的构建和链接构建的内部结构，是类图的变体，如下图
2.4顺序图：是一种交互图，交互图展现一种交互，他由一组对象或参与者以及它们之间可能发送的消息构成，交互图注重系统的动态视图，强调消息时间次序交互图，如下图
2.5定时图：定时图也是一种交互图，强调消息跨越不同对象或参与者的实际时间，不仅仅关心消息顺序
2.6通信图：一种交互图，也称为协作图。强调收发消息的对象或参与者结构组织，顺序图和通信图表达了类似的基本概念，但他们所强调的概念不同，顺序图强调时序，通信图强调对象之间的组织结构
2.7状态图：描述一个状态机，由状态，转移，事件和活动组成。状态图给出了对象的动态视图，强调事件导致的对象行为
2.8活动图：将进程或其他计算结构展示为计算内部一步步的控制流数和数据流活动图专注系统的动态视图，强调对象之间的控制流程
2.9 部署图：描述对运行时的处理节点及在其生存的构件配置，部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图
2.10交互图：活动图与顺序图的混合物
2.11 包图：描述由模型本身分解而形成的组织单元，以及它们之间的关系
2.12 用例图：描述一组用例，参与者以及它们之间的关系，是静态视图，对系统的行为进行组织和建模时非常重要
3.UML视图
3.1.逻辑视图：也称之为设计视图，表示设计模型中在架构方面具有重要意义的部分，既类，子系统，包和用例实现的子集（设计人员，开发人员）
3.2进程视图：进程视图是可执行线程和进程作为活动类的建模，他是逻辑视图的一次执行实例，描述了并发与同步结构（开发人员，系统集成人员使用）
3.3实现视图：对组成基于系统的人物理代码的文件和构件进行建模（开发人员使用）
3.4部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构（开发，系统维护，测试人员使用）
3.5用例视图：最基本的需求分析模型（需求人员，用户使用）
五，类与类之间的关系
1关联关系：提供不同类的对象之间结构关系
2依赖关系：对于两个类，其中一个发生变化可能会引起另外一个类的变化
3.泛化关系：一般事务与该事务中的特殊种类之间的关系
4.共享聚集：聚合关系，表示类之间的整体和部分的关系，“部分”可能同时属于多个“整体”
5.组合聚集：组合关系，表示类之间的整体与部分的关系，“部分”只能属于一个“整体的部分
，随着整体消亡，部分也会消亡
6.实现关系：将说明和实现联系起来，接口是对行为而非实现的说明
六，软件架构风格
1.数据流风格：包括批处理序列和管道，过滤器两种风格
2.调用/返回风格：包括主程序/子程序，数据抽象和面向对象，以及层次结构
3.独立构件风格：包括进程通信和事件驱动的系统
4.虚拟机风格：包括解释器和基于规则的系统
5.仓库风格：包括数据库，黑板系统和超文本系统
七，常见设计模式
设计模式是前人总结的经验，它使人可以方便的复用软件设计
1.根据处理范围不同分为：类模式(静态)，对象模式(动态)
2.根据用途不同分为：创建型模式，结构型模式，行为型模式
八，CMMI成熟度模型（重要）
1.阶段式成熟度模型：对整个组织进行统一评级，当组织通过某一等级过程域的全部过程，意味着该组织的成熟度达到了这一等级
| 等级 | 过程域 |
| 第二级：可管理级 | 需求管理，项目计划，配置管理，项目监督与控制，供应商合同管理，度量和分析 过程和产品质量保证 |
| 第三级：已定义级 | 需求开发，技术解决方案，产品集成，验证，确认，组织级过程焦点，组织级过程 定义，组织级培训，集成项目管理，风险管理，集成化团队，决策分析和解决方案 组织级集成环境 |
| 第四级：量化管理 | 组织级过程性能，定量项目管理 |
| 第五级：优化管理 | 组织级改革与实施，因果分析和解决方案 |
2.连续式表达：针对组织的某些过程度评级，如评价组织的某个PA的能力为2级或3级，与阶段式相比，连续式模型没有与组织成熟度相关的几个阶段，连续式模型按24个过程域按照功能划分为过程管理，项目管理，工程和支持四个过程组
| 分组 | 过程域 |
| 第二级：过程管理 | 组织级过程焦点，组织级过程定义，组织级培训，组织级过程性能，组织级改革与实施 |
| 第三级：项目管理 | 项目计划，项目监督与控制，合同管理，集成项目管理，风险管理，集成化团队，定量项目管理 |
| 第四级：工程 | 需求管理，需求开发，技术解决方案，产品集成，验证，确认 |
| 第五级：支持 | 配置管理，度量和分析，过程和产品质量，决策分析和解决方案，组织级成环境，因果分析和解决方案 |
九，测试方法和分类
1. 测试方法
1.1 静态测试：被测试的程序不再机器上运行，采用人工检测或者计算机辅助静态分析等手段进行检测，一般包括文档静态测试，代码静态测试（桌前检查，走查，ide工具静态检查）
1.2 动态测试：在机器上实际运行程序进行测试，一般采用白盒（需要对程序内部实现逻辑进行测试），黑盒进行测试（不考虑程序内部具体实现，只测试表现接口功能是否正常）
2.测试分类
2.1 单元测试：也称为模块测试，测试的对象是可独立编译的程序模块，检查模块是否正确，一般有开发人员执行完成
2.2 集成测试：检查模块与模块之间，以及模块和已集成的软件之间的正确性，验证是否符合规格
2.3 确认测试：主要用于验证软件功能，性能和其他特性是否与用户需求一致
2.4 系统测试：对完整的，集成好的系统进行整体测试，目的是在真实环境下，验证完整的软件配置项是否能和系统正常链接
2.5 配置项测试：配置项测试是对软件配置项，配置项测试的目的是检测软件配置项与SRS的一致性
2.6 回归测试：测试软件变更后，变更部分的正确性和对变更需求的符合性，以及软件原有功能的正确性，功能性和其他规定的要求的不损害性。
十，企业应用集成
1. 表示集成：也称为界面集成，这是比较原始的集成方式，将用户界面作为公共的集成点，将原有零散的入口进行集中到一个新页面中。表示集成是一种黑盒集成
2.数据集成：未来完成控制集成和业务流集成，必须首先解决数据和数据库的集成问题，数据集成是白盒集成
3.控制集成：也成为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成。控制集成的集成电点存在于代码中，控制集成是一种黑盒集成
4.业务流程集成：也称为过程集成，这种集成超越了数据和系统，由一系列基于标准的，统一数据格式的工作流组成。
集成难度从上到下为难度逐级增加，灵活程度也是逐级增加。