软件_需求_测试_质量_复用_架构_中间件_数据库_数据仓库

软件

软件的生命
（行划需概详码测维）

1.可行性分析与项目开发计划

确定问题有无可行的解决方案，是否值得解决

2.需求分析

确定要解决的问题，目标系统要具备哪些功能

3.概要设计

制定出实现该软件的详细计划

4.详细设计

把问题的求解具体化，设计出程序的详细规格说明

5.编码

6.测试

7.维护

软件需求

需求：描述了组织为什么要开发一个系统，即组织希望达到的目标

定义

软件需求是针对待解决问题的特性的描述

特性 -可验证性

1.所定义的需求必须 --可以被验证（可验证性）。

2.在资源有限时，可以通过优先级对需求进行权衡，通过需求分析，可以检测和解决需求之间的冲突;

3.发现系统的边界，并详细描述出系统需求。

需求分析设计分析需求的过程

1.检测和解决需求之间的冲突

2.发现软件的边界，以及软件与其环境如何交互

3.详细描述系统需求，以导出软件需求

需求的3个方面

1.功能需求

系统必须完成的那些事

2.非功能需求

产品必须具备的属性或品质，比如系统型性能、稳定性、可用性、可靠性、扩展性、可维护性、易用性、容错、对技术和业务的适应性等

3.设计约束

也称为限制条件、补充规约，例如必须采用国有自主知识版权的数据库系统，必须运行在特定系统下。

需求的3个层次

1.业务需求

表示组织或者客户高层次的目标。业务需求通常来自项目投资人，购买产品的客户、实际用户的管理者、市场营销部门或者产品策划部门

2.客户需求

是用户的目标，或者用户要求系统必须能完成的任务

3.功能需求

规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

常用需求分析法

1.结构化分析法（SA）

2.面向对象的分析法 (OOA)

软件需求说明书是需求分析阶段最后的成果之一

软件需求规格说明书

是系统分析阶段的输出，也是最后一阶段–软件设计或数据库设计阶段的依据。验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需求其验收的依据是需求规格说明书。

软件测试

定义

是为了评价和改进产品质量、识别产品的缺陷和问题而进行的活动。

是针对一个程序的行为，在有限测试用例集合上，-动态验证是否达到预期的行为。

应尽可能在实际运行环境下进行。

是一种应该包括在整个开发和维护过程中的活动，本身是实际产品构造的重要一部分。

测试人员认为程序出现错误，要对错误结果进行一个确认过程。

一般有A测试出来的错误，一定要由B来确认。

严重的错误可以召开 --评审会议进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题的以及严重程度等。

原则

1.软件开发人员即程序员应该避免测试自己的程序

2.应尽早地和不断地进行软件测试

3.对测试用例要有正确的态度：

第一：测试用例应当由测试输入数据和预期输出结果这两个组成部分

第二：在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件

4.要充分注意软件测试中的群集现象，也可以认为“80-20原则”。

不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。

5.严格执行测试计划，排除系统的随意性，以避免发生疏漏或者重复无效的工作。

6.应当对每一个测试结果进行全面检查

7.妥善保存测试用、测试计划、测试报告和最终分析报告。以备回归测试及维护之用。

软件测试类型

1.是否关心软件内部结构和具体实现的角度划分

为白盒测试、黑盒测试、灰盒测试

白盒测试：又称逻辑驱动测试，结构测试。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

2.是否执行程序的角度

静态测试动态测试

3.软件开发的过程按阶段划分

单元测试、集成测试、确认测试、系统测试、验收测试

4.测试管理过程

制定测试计划及用例、执行测试、发现并报告缺陷、修正缺陷、重新测试

按阶段分类

1.单元测试 2.集成测试 3.系统测试 4.验收测试

测试V模型

非常明确地标明了测试过程中存在的不同级别，并且清楚的描述了这些测试和开发各阶段的对应关系。换而言之，应该从信息系统项目需求分析阶段就开始谋划、编写验收测试计划。

回归测试

指发生修改之后重新测试先前的测试以保证修改的正确性。

目的在于验证以前出现过但已经修复好的缺陷不再重新重现。

通常确定所需的在测试的范围是比较困难的，特别当临近产品发布日期时。

鼓励对所有回归测试用例进行自动化测试。

模糊测试 Fuzz testing

是指将一个随机的、非预期的数据源作为程序的输入，然后系统地找出这个输入所引起的程序的失效。

通过模糊测试，你将会抢在别人之前来揭示软件易受攻击的的弱点。

模糊测试现在已经发展成为一种最有效的软件安全性能测试方法。

通常使用 LoadRunner 对集成的系统进行性能测试。

1.Bugzilla 缺陷管理工具
2.Truecoverage:覆盖率检查工具
3.TestManager 测试管理工具
4.Loadrunner 性能测试工具

测试验收标准

需求文档定义的功能全部实现，非功能指标达到设计要求

软件维护

类型

软件

软件的生命
（行划需概详码测维）

1.可行性分析与项目开发计划

确定问题有无可行的解决方案，是否值得解决

2.需求分析

确定要解决的问题，目标系统要具备哪些功能

3.概要设计

制定出实现该软件的详细计划

4.详细设计

把问题的求解具体化，设计出程序的详细规格说明

5.编码

6.测试

7.维护

软件需求

需求：描述了组织为什么要开发一个系统，即组织希望达到的目标

定义

软件需求是针对待解决问题的特性的描述

特性 -可验证性

1.所定义的需求必须 --可以被验证（可验证性）。

2.在资源有限时，可以通过优先级对需求进行权衡，通过需求分析，可以检测和解决需求之间的冲突;

3.发现系统的边界，并详细描述出系统需求。

需求分析设计分析需求的过程

1.检测和解决需求之间的冲突

2.发现软件的边界，以及软件与其环境如何交互

3.详细描述系统需求，以导出软件需求

需求的3个方面

1.功能需求

系统必须完成的那些事

2.非功能需求

产品必须具备的属性或品质，比如系统型性能、稳定性、可用性、可靠性、扩展性、可维护性、易用性、容错、对技术和业务的适应性等

3.设计约束

也称为限制条件、补充规约，例如必须采用国有自主知识版权的数据库系统，必须运行在特定系统下。

需求的3个层次

1.业务需求

表示组织或者客户高层次的目标。业务需求通常来自项目投资人，购买产品的客户、实际用户的管理者、市场营销部门或者产品策划部门

2.客户需求

是用户的目标，或者用户要求系统必须能完成的任务

3.功能需求

规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

常用需求分析法

1.结构化分析法（SA）

2.面向对象的分析法 (OOA)

软件需求说明书是需求分析阶段最后的成果之一

软件需求规格说明书

是系统分析阶段的输出，也是最后一阶段–软件设计或数据库设计阶段的依据。验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需求其验收的依据是需求规格说明书。

软件测试

定义

是为了评价和改进产品质量、识别产品的缺陷和问题而进行的活动。

是针对一个程序的行为，在有限测试用例集合上，-动态验证是否达到预期的行为。

应尽可能在实际运行环境下进行。

是一种应该包括在整个开发和维护过程中的活动，本身是实际产品构造的重要一部分。

测试人员认为程序出现错误，要对错误结果进行一个确认过程。

一般有A测试出来的错误，一定要由B来确认。

严重的错误可以召开 --评审会议进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题的以及严重程度等。

原则

1.软件开发人员即程序员应该避免测试自己的程序

2.应尽早地和不断地进行软件测试

3.对测试用例要有正确的态度：

第一：测试用例应当由测试输入数据和预期输出结果这两个组成部分

第二：在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件

4.要充分注意软件测试中的群集现象，也可以认为“80-20原则”。

不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。

5.严格执行测试计划，排除系统的随意性，以避免发生疏漏或者重复无效的工作。

6.应当对每一个测试结果进行全面检查

7.妥善保存测试用、测试计划、测试报告和最终分析报告。以备回归测试及维护之用。

软件测试类型

1.是否关心软件内部结构和具体实现的角度划分

为白盒测试、黑盒测试、灰盒测试

白盒测试：又称逻辑驱动测试，结构测试。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

2.是否执行程序的角度

静态测试动态测试

3.软件开发的过程按阶段划分

单元测试、集成测试、确认测试、系统测试、验收测试

4.测试管理过程

制定测试计划及用例、执行测试、发现并报告缺陷、修正缺陷、重新测试

按阶段分类

1.单元测试 2.集成测试 3.系统测试 4.验收测试

测试V模型

非常明确地标明了测试过程中存在的不同级别，并且清楚的描述了这些测试和开发各阶段的对应关系。换而言之，应该从信息系统项目需求分析阶段就开始谋划、编写验收测试计划。

回归测试

指发生修改之后重新测试先前的测试以保证修改的正确性。

目的在于验证以前出现过但已经修复好的缺陷不再重新重现。

通常确定所需的在测试的范围是比较困难的，特别当临近产品发布日期时。

鼓励对所有回归测试用例进行自动化测试。

模糊测试 Fuzz testing

是指将一个随机的、非预期的数据源作为程序的输入，然后系统地找出这个输入所引起的程序的失效。

通过模糊测试，你将会抢在别人之前来揭示软件易受攻击的的弱点。

模糊测试现在已经发展成为一种最有效的软件安全性能测试方法。

通常使用 LoadRunner 对集成的系统进行性能测试。

1.Bugzilla 缺陷管理工具
2.Truecoverage:覆盖率检查工具
3.TestManager 测试管理工具
4.Loadrunner 性能测试工具

测试验收标准

需求文档定义的功能全部实现，非功能指标达到设计要求

软件维护

软件维护包括如下类型 -交付软件产品后进行的修改是他们的共同特征

1.更正性维护

软件产品交付后进行的修改，已更正发现的问题
（BUG修改）其只要内容包括：1.设计错误、2程序错误、3.数据错误、4.文档错误

2.适应性维护

软件产品交付后进行的修改，以保持软件产品的能在变化后或者变化中的环境中可以继续使用（系统移植）

主要包括：
1.影响系统的规则或规律变化
2.硬件配置的变化，如机型、终端、外部设备的改变等
3.数据格式或文件结构的改变
4.软件支持环境的改变，如操作系统、编译器或者应用程序的变化等。

3.完善性维护

软件产品交付后进行的修改，以改进性能和可维护性（增加功能，工作量最大）

主要包括：
1.为扩充和增强功能而做的修改，如扩充解题范围和算法优化
2.为改善性能而做出的修改，如提高运行速度、节省存储空间等
3.为便于维护而做的修改，如为了改进易读性而增加的一些注解等。

4.预防性维护

软件交付后进行的修改，以在软件产品中的潜在错误册成为实际错误前，检测和更正他们（针对未来）

系统需求将软件服务定义为需要提供软件软件支持的全部活动。这些活动包括在交付前完成的活动，以及交付后完成的活动。

交付前要完成的活动包括交付后的运行计划和维护计划等

交付后的活动包括软件修改、培训、帮助资料等

软件质量保证和质量评价

软件质量管理过程

包括质量保证过程、验证过程、确认过程、评审过程、审计过程

软件质量

定义

软件特性的综合，软件满足规定或潜在用户需求的能力。

内部质量、外部质量、使用质量

验证与确认过程

确定某一活动的产品是否符合活动的需求，最终的软件产品是否达到了其意图并满足用户需求

验证：试图确保活动的输出产品已经被正确构造，及活动的输出产品满足活动的规范说明

确认：则试图确保构造了正确的产品，即产品满足特定的目的

软件质量保证过程

通过计划制定、实施、完成一组活动提供保证，这些活动保证项目生命周期中的软件产品和过程符合其规定的需求。

评审与审计过程

1.管理评审

监控进展，决定计划和进度状态，或评价用于达到目标所用管理方法的有效性

2.技术评审

评价软件产品，以确定其对使用意图的适合性

3.软件审计

提供软件产品和过程对于可应用的规则、标准、指南、计划和流程的遵从性的独立分析，审计是事后进行的。审计是正式组织的活动。

软件审计的目的

提供软件产品和过程对于可应用的规则、标准、指南、计划、流程的遵从性的独立评价

软件配置管理活动

包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理、交付等活动

软件过程管理

涉及技术过程和管理过程，通常包括

1.项目启动与范围定义

2.项目规划

3.项目实施

4.项目监控与评审

5.项目收尾与关闭

软件配置控制关注的是管理软件生命周期中的变更

软件配置状态记录标识、收维护并报告配置管理的配置状态信息。

软件配置审计是独立评价软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动。

软件发布管理和交付通常需要创建特定的交付版本，完成此任务的关键是软件库！

软件复用

定义

利用已有的软件的各种有关知识构造新的软件，以缩减软件开发和维护的费用。

软件复用是提高软件生产力和质量的一种重要技术（把以前重复的东西拿来用）

按抽象程度高低

代码级复用、设计的复用、分析的复用、测试信息的复用、知识、开发经验、设计决策、架构、需求、设计、代码、和文档等一切有关的方面。

软件复用可以减少软件开活动中大量的重复工作，可以提高效率，降低开发成本，缩短开发周期，也可以改善软件质量

面向对象

基本概念

对象、类、抽象、封装、集成、多态、接口、消息、组件、模式、复用

对象

是由数据及其操作所构成的封装体

用计算机语言来描述，对象是由一组属性和对这个组属性进行操的操作构成的。

三个基本要素

对象标识、对象状态、对象行为

对象系统中用来描述客观事物的一个模块，是构成系统的基本单位。

类

现实世界中实体的形式化描述，类将该实体的属性(数据)和操作(函数)封装在一起

类和对象的关系

1.每个对象都是某一个类的实例

2.每一个类在每一时刻都有0或更多的实例

3.类是静态的，对象是动态的

4.类是生成对象的模板

对象是类的实例，类是对象的模板

在UML类图中

类和类之间可能存在继承、泛化、聚集、组成、关联等关系

在统一构建语言的用例图中

用例和用例之间可能存在扩展、包含等关系。

抽象

通过特定的实例抽取共同特征后形成概念的过程。对象是现实世界中某个实体的抽象，劣势一组对象的抽象。

封装

封装是将相关的概念组成一个单元，然后通过一个名称来引用它，面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外界提供的接口进行。

继承

集成表示类之间的层次关系，继承又可分为单继承和多继承，继承自父类的属性特征，不需要在子类中进行重复说明

多态

使得多个类中可以定义同一个操作或属性名，并在每个类中可以有不同的实现。多态使得某个属性或操作在不同的时期可以表示不同的对象特征，

多态是面向对象的程序设计语言的最核心特征，多态意味着一个对象有着多重特征，可以在特定的情况下，表现不同的状态，从而对应着不同的属性和方法。

接口

接口就是对操作规范的说明，其只说明操作应该做什么

消息

体现对象间的交互，通过它向目标对象发送操作请求

组件

标识软件系统可替换的、物理的组成部分，封装了模块功能的实现，组件应当是内聚，并且有相对稳定的公开接口

模式

描述了一个不断重复发生的问题，以及该问题的解决方案。其包括 1.特定环境、2.问题、3.解决方案三个组成部分。应用设计模式可以更加简单和方便地去复用成功的软件设计和架构，从而帮助设计者更好的完成系统设计。

复用

软件复用是指将已有的软件及其有效成分用于构造新的软件和系统

扩展

面向对象分析中，分析过程的第一步是发现角色/参与者

软件架构

典型体系结构

1.管道/过滤器模式

体现了各功能模块 ——高内聚，低耦合的 “黑盒”特性，支持软件功能模块的重用，——便与系统维护。同时每个过滤器自己完成数据解析和合成工作(如加密、解密)，易导致系统性能下降，并增加了过滤器具体实现的复杂性。

典型应用 --批处理系统

2.面向对象模式

将模块数据的表示方法及其相应操作封装在更高抽象层次的数据类型或对象中，

典型应用 --基于组件的软件开发(CBD)

3.事件驱动模式

组件并不直接调用操作，而是触发一个或多个时间。系统中的其他组件可以注册相关的事件，触发一个事件时，系统会自动调用注册了该事件的组件，即触发事件会导致两一个组件中操作的调用

典型应用 --图像界面工具

4.分层模式

采用层次化的组织方式，每一层都为上一层提供服务，并使用下一层提供的功能。–该模式允许将一个复杂问题除部分层实现。其中的每一层最多只影响相邻两层，只要给相邻两层提供相同的接口，就允许每层用不同的方式实现，可以充分–支持软件的复用。

优点

1.有助于把复杂的问题按功能分解，是整体设计更为清晰
2.支持系统设计的逐级抽象
3.具有较好的可扩展性
4.支持复用

缺点

1.并不是每个系统都可以很容易的划分出层次来，同事各层功能的划分也没有一个统一的正确的抽象方法
2.层次的个数过多，系统性能下降、

典型应用 --分层通讯协议入ISO、OSI的7层网络模型

5.C/S模式

1.基于资源不对等,为–实现共享而提出的模式. C/S模式将应用一分为二.
–服务器(后台)负责–数据操作和事务处理,
客户(前台)–完成与用户的交互任务.

2.C/S模式中客户与服务器外离,允许网络分布操作,适用于–分布式系统。
为了解决C/S模式中客户端的问题,发展形成了浏览器/服务器(B/S)模式;
为了解决CS模式中服务器端的问题,发展形成了三层(多层)C/S.模式,即多层应用架构.

3.基于B/S架构的信息系统比基于C/S架构的系统更容易部署和升级维护:

4.微信平台属于肿服务器,搜客户端的模式,该模式降低了客户端系统开销,.而后台系统将承受巨大的并发访问吞吐量、存储、内存、CPU等利用率超高等的开销

编写需求规格说明书不属于软件架构设计的主要工作内容。

目前主流的数据库关系是 --关系数据库

HTML/HTTP(s)协议是实现Internet应用的重要技术

软件中间件 (Middleware)

定义

是位于硬件、操作系统等平台和应用之间的额通用服务。

位置和解决问题

它位于客户端/服务器的操作系统之上，借由中间件，解决分布系统的异构。

目的

主要目的是实现应用与平台无关

中间件服务具有标准的程序接口和协议，不同的应用、硬件、操作系统平台，可以提供符合接口和协议规范的多种实现。

借助中间件，屏蔽操作系统和网络协议的差异，为应用提供多种通讯机制，满足不同领域的应用高要求。

中间件是一类软件，而不是一种软件

特点

1.满足大量应用的需求

2.运行于多种硬件和操作系统平台上

3.支持分布计算

4.提供跨越网络、硬件、操作系统平台的应用或服务

5.支持标准的协议

6.支持标准的接口

主要中间件

1.数据库访问中间件

通过一个抽象层访问数据库，从而允许使用相同或者相似的代码访问不同的数据库资源

Windows平台的ODBC 和JAVA平台的JDBC

2.远程过程调用 (RPC)

广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来远程执行一个位于不同地址空间内的过程。效果上看执行本地调用相同

3.面向消息中间件（MOM）

利用高效可靠的消息传递机制负责进行平台无关的数据交流，并可基于数据通信进行分布系统的集成。

典型产品 IBM的MQSeries

4.分布式对象中间件

建立对象之间客户/服务器关系的中间件，结合了对象技术与分布式计算技术。该技术提供了一个通信框架，可在异步分布式计算环境中透明的传递对象请求。

典型产品 OMG的CORBA ，Sun 的 RIVE/EJB ,Microsoft 的DCOM

5.事务中间件

提供支持大规模事务处理的可靠运行环境，TPM位于客户和服务器之间，完成事务管理与协调、负载平衡、失效恢复等任务，以提高系统的整体性能

典型产品 IBM/BEA的 Tuxedo ，结合对象技术的对象事务监控器（OTM），支持EJB的 JavaEE等应用服务器

数据库和数据仓库

数据仓库（DW）

是一个面向主题、集成的、相对稳定的、反映历史变化的数据集合。

主题：是指用户使用数据仓库进行决策时所关心的某些方面，一个主题通常与多个操作型系统有关。

用于支持管理决策

是对多个异构数据源（包括历史数据）的有效集成，集成后按 --主题重组。

存放在数据仓库中的数据一般不在修改。

##数据仓库系统

数据仓库系统的基础 – 数据源

数据仓库系统的核心 – 数据的存储和管理

数据仓库系统分层

1.数据源

2.数据的存储与管理

3.OLAP（联机分析处理）服务器

数据仓库中间层–OLAP服务器对分析需要的数据进行有效集成、按多维模型组织、以便进行多角度、多层次的分析，并发现趋势，具体可分为 ROLAP、MOLAP、HOLAP

ROLAP Relational OLAP 基于关系数据库的OLAP实现

MOLAP Multidimensional OLAP 基于多维数据组织的OLAP实现

HOLAP Hybrid OLAP 表示基于混合数据组织的OLAP实现

4.前端分析工具

各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种机遇数据仓库或数据集市的应用开发工具。

数据分析工具主要针对 OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。

7)

大数据（BigData）

5个V

1.Volume 数据量大 2.Cariety 数据类型繁多 3.Velocity 处理速度快 4.Value 价值密度低 5.Veracity 真实性高

意义：不在于掌握庞大的数据信息，而在于对数据进行专业化处理，实现数据的“增值”

大数据对比数据仓库

大数据具有数量大、查询分析复杂等特点

技术上大数据必须依托云计算的分布式处理，分布式数据库、云存储、虚拟化技术

数据库

数据库技术以数据库为中心，进行实物处理，批处理、决策分析等各种数据处理工作。

主要由操作型处理和分析型处理。

操作型数据库系统：强调的事优化企业的日常事务处理工作，难以实现对数据的分析处理要求，无法满足数据处理多样性要求，从而演化出分析型数据库技术。

数据库管理系统（DBMS）

对数据库进行统一的管理和控制，已保证数据库的安全性和完整性。

可以使多个应用程序和用户不同的方法在同时去建立、修改、和询问数据库。

DMBS提供数据顶易语言DDL与数据操作语言DML，供用户定义数据库的模式结构和权限约束。实现对数据的追加、删除等操作

DBMS 和 OS 之间的关系：DBMS调用OS

DBMS选型：1.稳定可靠、2.可扩展性、3.安全性

Web Service

定义

是解决应用程序之间互相通信的一种技术，是描述一些列操作的接口，使用标准的、规范的XML描述接口，可以实现跨平台的通信，解决异构的问题

Web Application 是面向应用的，而Web Service是面向计算级的，是实现SOA架构的技术

Web Service定义了一种 --松散的、粗粒度的分布式就算模式。

使用标准的HTTP协议传送XML，表示及–封装的内容.

Web服务的典型技术包括

用于传递信息的简单对象访问协议SOAP
用于描述服务的web服务描述语言WSDL
用于web服务的注册的统一描述
发现及集成UDDI
用于数据交换的XML

Web服务允许重用代码，允许重用代码后面的数据

Web服务主要目标跨平台的操作性

适合使用：跨越防火请、应用程序集成、B2B集成、软件重用

不适合使用：单机应用程序、局域网上的同构应用程序

随着云计算的普及，Web Service逐渐融入到云计算SAAS服务中。

软件引擎技术

定义目的

通常是系统的核心组件，目的是封装某些过程方法，是的在开发的时候，不需要过多地关注其具体实现，从而可以将关注点聚焦在与业务的结合上

工作流引擎是工作管理系统的运行和控制中心

通过工作流程引擎，可以解释流程建模工具中定义的业务流程逻辑，进行过程、活动实例的创建，把任务分派给执行者，并根据任务执行返回的结果决定下一步的任务，控制并协调各种复杂工作流程的执行，实现对完整的业务流程生命周期的运行控制。

工作流程引擎的主要功能是流程调度和冲突检测

组件技术

定义

利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装，同时对各种业务逻辑规则进行了实现，用于处理用的内部操作细节，—这个封装体就是构件。

常用组件标准

COM/DCOM/COM+

1.COM

是开放的组件标准，有很强的扩充和扩展能力

2.DCOM

在COM的基础上添加了许多功能和特性，包括事务特性、安全模式、管理和配置，是COM成为一个完整的组件构架

2.COM+

综合各种技术形成的功能强大的组件架构，通过系统的各种支持，是组建对象模型建立在应用层上，把所有组件的底层细节留给了系统。

COM+ 并不是COM的新版本，是COM的新发展

CORBA 公共对象请求代理架构

是OMG组织指定的一种标准的面向对象的应用程序架构规范，为了解决 --分布式处理环境中硬件和软件系统的互联而提出的解决方案。

EJB

在JavaEE中用于封装中间层的业务功能。EJB组件部署在EJB容器中，客户应用通过接口访问它们，体现了接口和实现分离的原则。

软件_需求_测试_质量_复用_架构_中间件_数据库_数据仓库

软件

软件的生命（行划 需概详码测维）

1.可行性分析 与 项目开发计划

确定问题有无可行的解决方案，是否值得解决

2.需求分析

确定要解决的问题，目标系统要具备哪些功能

3.概要设计

制定出实现该软件的详细计划

4.详细设计

把问题的求解具体化，设计出程序的详细规格说明

5.编码

6.测试

7.维护

软件需求

需求：描述了组织为什么要开发一个系统，即组织希望达到的目标

定义

软件需求是针对待解决问题的特性的描述

特性 -可验证性

1.所定义的需求必须 --可以被验证（可验证性）。

2.在资源有限时，可以通过优先级对需求进行权衡，通过需求分析，可以检测和解决需求之间的冲突;

3.发现系统的边界，并详细描述出系统需求。

需求分析设计分析需求的过程

1.检测和解决需求之间的冲突

2.发现软件的边界，以及软件与其环境如何交互

3.详细描述系统需求，以导出软件需求

需求的3个方面

1.功能需求

系统必须完成的那些事

2.非功能需求

产品必须具备的属性或品质，比如系统型性能、稳定性、可用性、可靠性、扩展性、可维护性、易用性、容错、对技术和业务的适应性等

3.设计约束

也称为限制条件、补充规约，例如必须采用国有自主知识版权的数据库系统，必须运行在特定系统下。

需求的3个层次

1.业务需求

表示组织或者客户高层次的目标。业务需求通常来自项目投资人，购买产品的客户、实际用户的管理者、市场营销部门或者产品策划部门

2.客户需求

是用户的目标，或者用户要求系统必须能完成的任务

3.功能需求

规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

常用需求分析法

1.结构化分析法 （SA）

2.面向对象的分析法 (OOA)

软件需求说明书 是 需求分析阶段最后的成果之一

软件需求规格说明书

是系统分析阶段的输出，也是最后一阶段–软件设计或数据库设计 阶段的依据。验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需求其验收的依据是需求规格说明书。

软件测试

定义

是为了评价和改进产品质量、识别产品的缺陷和问题而进行的活动。

是针对一个程序的行为，在有限测试用例集合上，-动态验证是否达到预期的行为。

应尽可能在实际运行环境下进行。

是一种应该包括在整个开发和维护过程中的活动，本身是实际产品构造的重要一部分。

测试人员认为程序出现错误，要对错误结果进行一个确认过程。

一般有A测试出来的错误，一定要由B来确认。

严重的错误可以召开 --评审会议 进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题的以及严重程度等。

原则

1.软件开发人员即程序员应该避免测试自己的程序

2.应尽早地和不断地进行软件测试

3.对测试用例要有正确的态度：

第一：测试用例应当由测试输入数据和预期输出结果这两个组成部分

第二：在设计测试用例时，不仅要考虑合理的输入条件，更要注意不合理的输入条件

4.要充分注意软件测试中的群集现象，也可以认为“80-20原则”。

不要以为发现几个错误并且解决这些问题之后，就不需要测试了。反而这里是错误群集的地方，对这段程序要重点测试，以提高测试投资的效益。

5.严格执行测试计划，排除系统的随意性，以避免发生疏漏或者重复无效的工作。

6.应当对每一个测试结果进行全面检查

7.妥善保存测试用、测试计划、测试报告和最终分析报告。以备回归测试及维护之用。

软件测试类型

1.是否关心软件内部结构和具体实现的角度划分

为 白盒测试、黑盒测试、灰盒测试

白盒测试 ：又称逻辑驱动测试，结构测试。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括 语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

2.是否执行程序的角度

静态测试 动态测试

3.软件开发的过程按阶段划分

单元测试、集成测试、确认测试、系统测试、验收测试

4.测试管理过程

制定测试计划及用例、执行测试、发现并报告缺陷、修正缺陷、重新测试

按阶段分类

1.单元测试 2.集成测试 3.系统测试 4.验收测试

测试V模型

非常明确地标明了测试过程中存在的不同级别，并且清楚的描述了这些测试和开发各阶段的对应关系。换而言之，应该从信息系统项目需求分析阶段就开始谋划、编写验收测试计划。

软件的生命
（行划需概详码测维）

1.可行性分析与项目开发计划

1.结构化分析法（SA）

软件需求说明书是需求分析阶段最后的成果之一

是系统分析阶段的输出，也是最后一阶段–软件设计或数据库设计阶段的依据。验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需求其验收的依据是需求规格说明书。

严重的错误可以召开 --评审会议进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题的以及严重程度等。

为白盒测试、黑盒测试、灰盒测试

白盒测试：又称逻辑驱动测试，结构测试。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

静态测试动态测试

1.Bugzilla 缺陷管理工具
2.Truecoverage:覆盖率检查工具
3.TestManager 测试管理工具
4.Loadrunner 性能测试工具

软件的生命
（行划需概详码测维）

1.可行性分析与项目开发计划

1.结构化分析法（SA）

软件需求说明书是需求分析阶段最后的成果之一

是系统分析阶段的输出，也是最后一阶段–软件设计或数据库设计阶段的依据。验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需求其验收的依据是需求规格说明书。

严重的错误可以召开 --评审会议进行讨论和分析，对测试结果要进行严格的确认，是否真的存在这个问题的以及严重程度等。