软件工程：
软件工程是：
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（2）在（1）中所述方法的研究
软件和硬件的区别/h2>
1.软件是设计开发的，而不是传统意义上生产制造的。
2.软件不会“磨损”
3.大多数软件根据实际的顾客需求定制的。
为什么软件需要改变和发展/h2>
软件必须适应新的计算环境或技术的需要。
必须增强软件来实现新的业务需求。
软件必须扩展到与其他更现代的系统或数据库进行互操作。
必须重新构建软件，使其在 络环境中可行。
任务集
任务集定义了为达到一个软件工程动作的目标所需要完成的工作。
比如需求获取就是发生在沟通活动中的一个重要的动作，其对应的任务集可能包括：
对于一个小型、相对简单的项目而言：
- 制定项目的利益相关者列表。
- 邀请所有的利益相关者参加一个非正式会议。
- 征询每个人对于软件特性和功能的需求。
- 讨论需求，并确定最终的需求列表。
- 划定需求优先级。
- 标出不确定域。
对于大型、复杂的软件工程项目而言： - 制定项目的利益相关者列表。
- 和利益相关者的每个成员分别单独讨论，获取所有的要求。
- 基于利益相关者的输入，建立初步的功能和特性列表。
- 安排一系列促进需求获取的会议。
- 组织会议。
- 在每次会议上建立非正式的用户场景。
- 根据利益相关者的反馈，进一步细化用户场景。
- 建立一个修正的利益相关者需求列表。
- 使用质量功能部署技术，划分需求优先级。
- 将需求打包以便于软件可以实施增量交付。
- 标注系统的约束和限制。
- 讨论系统验证方法。
惯用过程模型
惯用过程模型是为了改变软件开发的混乱状态，促使软件开发更加有序。
瀑布模型（waterfall model）：
又被称为经典生命周期（classic life cycle），它提出了一个系统的、顺序的软件开发方法。
优点：
有利于大型软件开发过程中人员的组织、管理，从而提高了大型软件项目开发的质量和效率。
当需求确定、工作采用线性的方式完成的时候瀑布模型是一个很有用的过程模型。
缺点:
过于理想，缺乏灵活性，容易产生需求偏差。
实际的项目很少遵守瀑布模型提出的顺序。
客户通常很难清楚的描述所有的需求。
客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能得到可以执行的程序。
适用范围： 需求确定，工作能够采用线性的方式完成的软件。
增量过程模型（Incremental Model）
增量过程模型侧重于每一个增量都提交一个可以运行的产品。
优点：
- 能在较短的时间内向用户提交可完成部分工作的产品。
- 逐步增加产品功能可以使用户有充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
- 规避技术风险
- 可并行开发构件，加快开发的进度
- 对于在业务截止日期之前完全实施的人员配置非常有用。
缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
适用范围：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的；
（2）对完成期限严格要求的产品，可以使用增量模型；
（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
（4）项目在既定的商业要求期限之前不可能找到足够的开发人员
统一过程（Unified Process）
统一过程模型
统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架，由 UML 方法和工具支持。它是一种增量模型，定义了五个阶段：
a、起始阶段，包括用户沟通和计划活动，强调定义和细化用例
b、细化阶段，包括用户沟通和建模活动，重点是创建分析和设计模型。
c、构件阶段，细化模型设计，并将设计模型转化为软件构件实现
d、转化阶段，将软件从开发人员传递给最终用户，并由用户完成 beta 测试和验收测试
e、生产阶段，持续地监控软件的运行，并提供技术支持。
优点：
1.任何功能开发后就进入测试过程，及早进行验证
2.早期风险识别，采取预防措施
缺点：
- 需求必须在开始之前完全弄清楚，否怎有可能在架构上出现错误
敏捷开发
敏捷宣言（Agile development manifesto）：
个人和他们之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
极限编程（Extreme Programming (XP)）
极限编程是敏捷软件开发使用最广泛的一个方法。
极限编程过程:
连续集成
有助于避免兼容性和接口问题，建立能及早发现错误的“冒烟测试”
需求工程（Requirement engineering）
七个任务：起始、获取、细化、协商、规格说明、确认、管理
1.起始（Inception）： 在项目起始阶段，要建立基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
2.获取（Elicitation –gathering requirements）： 询问客户、用户和其他人，系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何利用于日常工作。
3.细化（Elaboration-requirement modeling）： 在起始和导出阶段获得的信息将在精化阶段进行扩展和提炼该任务集中于开发一个精确的需求模型。
UML活动图在特定场景通过提供迭代流的图形表示来补充用例。
例：
基于类的建模
识别分析类
外部实体（其他系统、设备、人员），产生或实验基于计算机系统的信息。
事物（ 告、显示、字母、信 ），问题信息域的一部分。
偶发事件或事件（所有权转移或完成机器人的一组移动动作），在系统操作环境内发生。
角色（经理，工程师，销售人员），由和系统交互的人员扮演
组织单元（部门，组，团队），和某个应用系统相关
场地（制作车间或码头），建立问题的环境和系统的整体功能
结构（传感器、交通工具、计算机），定义了对象的类或与对象相关的类。
例：
顺序图：
表明事物引发从一个对象到另一个对象的转移。
数据流体系结构。
面向对象体系结构：
系统的构件封装了数据和必须用于控制该数据的操作，构件间通过信息传递进行通信与合作。
层次体系结构
界面设计的目标是定义一组界面对象和动作，使得用户能够以满足系统所定义的每个使用目标的方式完成所有定义对的任务。
界面分析
在用户界面的设计中，理解问题就意味着了解：
（1）通过界面和系统交互的人
（2）最终用户为完成工作要执行的任务
（3）作为界面的一部分而现实的内容
（4）任务处理的环境
界面分析：
（1）用户分析：
设计师能够将用户心理模型与设计模型聚合在一起的唯一办法就是努力了解用户，以及了解用户是如何使用系统的。
可以从各种途径获得信息
用户访谈：软件团队（代表）与用户讨论。
销售输入：销售人员与用户定期见面。
市场输入：市场分析，分析/理解市场每个部分使用软件的细微差别。
支持输入：技术支持人员与用户访谈。
（2）任务分析与建模
任务分析的目标就是将这些技术应用到用户界面：
a.用例： 用例描述了参与者和系统的交互方式。从用例描述中，软件工程师可以提炼出任务、对象和整个的交互过程。
b.任务细化： 改进了交互流程。任务细化有两种方法：
1.理解实现活动目标而必须完成的任务
2.研究已有的基于计算机的解决方案的规格说明，并且得到一个适应于用户模型、设计模型和系统感觉的用户任务集合。
逐步细化。
c.对象细化： 对象细化标识了接口对象
d.工作流分析： 工作流分析定义了涉及多个人（和角色）时工作流程是如何完成的。
e.层次分析：
用户任务：请求重新填写处方
提供识别信息。
指定名称。
指定用户ID。
指定PIN和密码。
指定处方 码。
指定日期重填是必需的。
质量概念：
实现软件质量：
软件工程方法：
需求和设计部分提供了一系列概念和方法，可帮助我们获得对问题:合理完整的理解和综合性设计，从而为构建活动建立了坚实的基础。如果应用这些概念，并采取适当的分析和设计方法，那么创建高质量软件的可能性将大大提高。
项目管理技术：
如果(1)项目经理使用估算以确认交付日期是可以达到的;(2)进度依赖关系是清楚的，团队能够抵抗走捷径的诱惑; (3)进行了风险规划，这样出了问题就不会引起混乱，软件质量将受到积极的影响。
此外，项目计划应该包括明确的质量管理和变更管理技术。导致良好项目管理实践的技术将在本书第四部分讨论。
质量控制：
质量控制包括一套软件工程活动，以帮助确保每个工作产品符合其质量目标。评审模型以确保它们是完整的和一致的。检查代码，以便在测试开始前发现和纠正错误。应用一系列的测试步骤以发现逻辑处理、数据处理以及接口通信中的错误。当这些工作成果中的任何-一个不符合质量目标时，测量和反馈的结合使用使软件团队可以调整软件过程。
软件质量保证：
MTBF = MTTF + MTTR
(即平均失效时间+平均维修时间)
软件可用性：
可用性 = MTTF/（MTTF+MTTR）* 100％
MTBF可靠性测量队MTTF和MTTR同样敏感。而可用性测量在某种程度上对MTTR更为敏感，MTTR是对软件可维护性的间接测量。
测试
测试：测试是在交付给最终用户之前以特定意图找出错误为目的来执行程序的过程。
验证与确认（Verification and Validation，V&V）：
验证是指确保软件正确地实现某一特定功能的一系列活动。也即“我们在正确的构建产品吗”
确认是指确保开发的软件可追溯到客户需求的另外一系列活动。也即“我们在构建正确的产品吗”
测试策略：从小到大
单元测试过程：
**面向对象软件的测试策略
面向对象软件的类测试等同于传统软件的单元测试。
不同的是：
传统软件单元测试侧重于模块的算法细节和模块接口数据；
面向对象类的测试侧重于封装在该类中的操作和类的状态行为。
封装的类是单元测试的重点，但不再孤立地对单个操作进行测试，而是将其作为类的一部分。
簇测试时面向对象软件集成测试中的一个步骤。
确认测试：
确认测试准则：软件确认是通过一系列表明与软件需求相符合的测试而获得的。
- α测试：α测试测试是由代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在用户的后面观看，并记录错误和使用问题。α测试在受控的环境下测试。
- β测试：β测试在一个或多个最终用户场所进行。与α测试不同，开发者通常不在场，因此，β测试是在不为开发者控制的环境下软件的“现场”应用。是在不可控的环境下测试。
- 客户验收测试：β测试的一种变体，有时是按照合同交付给客户时进行的。客户执行一系列的待定测试，试图从开发者那里接收软件之前发现错误。
系统测试：
系统测试实际上是对整个基于计算机的系统进行一系列不同考验的测试。所有测试都是为了验证系统成分已经正确地集成在一起，并且完成了指派的功能。
恢复测试：通过各种方式强制让软件以各种方式失败并验证恢复是否正确执行。
**安全测试：**安全测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。
**压力测试：**压力测试的目的是是软件面对非正常的情形。是一种要求以非正常数量、频率或容量的方式进行彻底评估。
**性能测试：**性能测试用来测试软件在集成环境中的运行性能。
**部署测试：**有时也将部署测试称为配置测试，是在软件将要在其中运行的每一种环境中测试软件。
调试
调试( debugging)出现在成功的测试之后。也就是说，当测试用例发现错误时，调试是使错误消除的过程。尽管调试可以是也应该是一个有序的过程，但它仍然需要很多技巧。当评估测试结果时，软件工程师经常面对的是软件问题表现出的“症状”，即错误的外部表现与其内在原因之间可能并没有明显的关系。调试就是探究错误的外部表现与其内在原因之间关系的智力过程。
测试是发现错误，调试是找错误的原因
测试传统的应用系统
白盒测试：白盒测试有时也称为玻璃盒测试，是一种测试用例设计方法，它利用作为构件层设计的一部分描述的控制结构来生成测试用例。（根据源代码来测试）
白盒测试是在了解模块内部结构的情况下进行的测试。
利用白盒测试方法导出的测试用例可以：
（1）保证一个模块中的所有独立路径至少被执行一次。
（2）对所有的逻辑判定均需要测试取真和取假两个方面。
（3）在上下边界及可操作的范围内执行所有的循环。
（4）检验内部数据结构以确保其有效性。
基本路径测试：基本路径测试是由TOM首先提出的一种白盒测试技术。
流图（程序图）是一种简单的控制流表示方法。
流程图用于描述程序的控制结构。
将流程图映射为相应的流图。
独立程序路径：
独立路径是指任何贯穿程序的、至少引入一组新语句或一个新条件的路径。
如果设计测试以强迫执行这些路径（基本集合：不唯一），则可以保证程序中的每条语句至少执行一次，且每个条件的取真和取假都被执行。
生成基本测试用例集的步骤：
以设计或源代码为基础，画出相应的流图。
确定所得流图的环复杂性。
V(G)=边-点+2=判定节点数+1=封闭区域数+1
确定线性独立路径的基本集合。
准备测试用例，强制执行基本集合中的每条路径。
黑盒测试：
黑盒测试也称为行为测试，侧重软件的功能需求。
黑盒测试使软件工程师能设计出将测试程序所有功能需求的输入条件集。
黑盒测试不是白盒测试的替代品，而是作为发现其他类型错误的辅助方法。
黑盒测试试图发现以下类型的错误：
（1）不正确或遗漏的功能
（2）接口错误
（3）数据用在测试的后期阶段
（4）行为或性能错误
（5）初始化和终止错误
等价类划分：是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。
等价类表示输入条件的一组有效的或无效的状态。
设计等价类的指导原则:
1.若输入条件指定一个范围，则可以定义一个有效等价类和两个无效等价类。
2.若输入条件需要特定的值，则可以定义一个有效等价类和两个无效等价类。
3.若输入条件指定集合的某个元素，则可以定义一个有效等价类和一个无效等价类。
4.若输入条件为布尔值，则可以定义一个有效等价类和一个无效等价类。
通过运用设计等价类的指导原则，可以为每个输入域数据对象设计测试用例并执行。选择测试用例以便一次测试一个等价类的尽可能多的属性。
边界值分析（BVA)：
原因：大量错误发生在输入域的边界处，而不是发生在输入域的“中间”。
边界值分析是对“等价划分”的补充，不是选择等价类的任何元素，而是在等价类“边缘”上选择测试用例。
软件配置管理（SCM）（也称变更管理）
基线：
基线是一个软件配置管理概念，它能帮助我们在不严重阻碍合理变更的条件下控制变更。
基线的定义：已经经过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制规程才能修改它。（即经过评审和批准，不能随意改变的规格说明或者产品）
软件配置项：
软件配置项是在软件工程
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！