系统架构设计师教程（五）软件工程基础知识

5.1 软件工程

5.1.1 软件工程定义

软件工程过程是指为获得软件产品在软件工具的支持下由软件工程师完成的一系列软件工程活动包括以下4个方面。

1. P(Plan)——软件规格说明。规定软件的功能及其运行时的限制。
2. D(Do)——软件开发。开发出满足规格说明的软件。
3. C(Check)——软件确认。确认开发的软件能够满足用户的需求。
4. A(Action)——软件演进。软件在运行过程中不断改进以满足客户新的需求。

5.1.2 软件过程模型

软件要经历从需求分析、软件设计、软件开发、运行维护直至被淘汰这样的全过程这个全过程称为软件的生命周期。

1. 瀑布模型
   已经有了蓝图按部就班地去完成中间客户的需求根本不会改变。
2. 原型化模型
   这个就比较惯着客户了先给出一个小样不断地去修改完善有时候也不会完善了就是给客户一个灵感来源。
   
3. 螺旋模型
   螺旋模型 (Spiral Model) 是在快速原型的基础上扩展而成。不断地修修补补。
   

5.1.3 敏捷模型

敏捷开发的特点

敏捷型方法是“适应性” (adaptive) 而非“预设性” (predictive)
敏捷型方法是“面向人的” (People-oriented) 而非“面向过程的” (Process-oriented)

敏捷方法的核心思想

1. 敏捷方法是适应变化的方法强调利用变化来发展和完善自身与传统方法的可预测性不同。
2. 敏捷方法以人为核心注重充分发挥人的特性而不是过于强调过程的限制。
3. 敏捷方法采用迭代增量式的开发过程通过制订版本发行计划和小型化发布版本来满足客户需求。每个发行版都在前一版本的基础上进行功能需求扩充。

主要敏捷方法简介

1. 极限编程 (Extreme Programming,XP)强调快速适应变化注重团队协作和高质量软件交付。
2. 水晶系列方法以阶段性发布为特点注重需求的不断修订和完善迭代开发。
3. Scrum基于迭代、循序渐进的敏捷开发框架强调团队协作、适应变化和持续交付价值。
4. 特征驱动开发方法 (Feature Driven Development,FDD)侧重于对软件需求的分析和设计通过特征列表来组织和规划开发过程。

5.1.4 统一过程模型 (RUP)

RUP的生命周期

RUP的软件开发生命周期是一个二维模型包括9个核心工作流。这些核心工作流包括

• 业务建模理解待开发系统所在机构及其商业运作并评估待开发系统对机构的影响。
• 需求定义系统功能和用户界面使客户和开发人员理解系统需求为项目预算和计划提供基础。
• 分析与设计将需求分析结果转化为分析与设计模型。
• 实现将设计模型转换为实现结果对开发的代码进行单元测试并将不同模块集成为可执行系统。
• 测试检查子系统之间的交互和集成验证是否正确实现所有需求并对发现的质量缺陷提出改进建议。
• 部署打包、分发和安装软件升级旧系统培训用户和销售人员并提供技术支持。
• 配置与变更管理跟踪和维护系统开发过程中产生的所有制品的完整性和一致性。
• 项目管理为软件开发项目提供计划、人员分配、执行和监控的指导为风险管理提供框架。
• 环境为软件开发机构提供过程管理和工具支持的软件开发环境。

RUP将软件开发生命周期划分为多个循环每个循环生成一个新版本的产品。每个循环由4个连续的阶段组成

• 初始阶段定义最终产品视图和业务模型并确定系统范围。
• 细化阶段设计和确定系统的体系结构制定工作计划和资源要求。
• 构造阶段构建产品并进一步演化需求、体系结构和计划直至提交产品。
• 移交阶段将产品交付给用户使用。

每个阶段由一个或多个连续的迭代组成迭代不是重复做相同的事情而是针对不同用例的细化和实现。每个迭代都是一个完整的开发过程需要根据当前阶段和上次迭代的结果适当裁剪核心工作流中的行为。

在每个阶段结束前有一个里程碑评估工作进展。如果未能通过里程碑评估决策者需要决定是取消项目还是继续该阶段的工作。

RUP中的核心概念

RUP中定义了一些核心概念这些概念对于理解RUP方法非常重要

1. 角色Role描述某个人或小组在软件开发过程中的行为和责任。RUP预定义了多种角色如体系结构师、设计人员、实现人员、测试员和配置管理人员并详细说明了每个角色的工作和责任。
2. 活动Activity是具有明确目的的独立工作单元描述了软件开发过程中的具体行动。
3. 制品Artifact指活动生成、创建或修改的信息也可翻译为产品或工件。制品包括各种文档、模型和代码等。
4. 工作流Workflow描述了有意义的连续活动序列每个工作流产生有价值的产品并展示了角色之间的关系。

除了这四个核心概念外RUP还涉及其他基本概念如工具教程Tool Mentor、检查点Checkpoints、模板Template和报告Report等。这些概念之间的关系可以用类图来描述帮助理解RUP方法的运作方式。 RUP 2003版本对这些概念有更详细的解释有助于理解这些概念在软件开发过程中的实际应用。

RUP的特点

RUPRational Unified Process是一种用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。它具有以下特点

1. 用例驱动RUP中的开发活动都以用例作为驱动包括需求分析、设计、实现和测试等。通过用例来定义和描述系统的功能需求从而指导开发过程。
2. 以体系结构为中心RUP将开发活动围绕软件体系结构展开。软件体系结构是软件设计过程中的一个重要层次涉及系统的总体组织、通信协议、数据存取等方面的设计。RUP强调在设计阶段独立于具体的编程语言关注系统整体的组织和控制。
3. 迭代与增量RUP采用迭代和增量的方式进行软件开发。项目被分为多个迭代过程每次迭代只关注部分需求进行分析、设计、实现、测试和部署等活动。每次迭代都在已完成部分的基础上增加新功能直至最终完成整个项目。这种方式有助于早期处理风险、指导开发、应对需求变更、提供可运行系统和提高开发效率。

通过上述特点RUP能够更灵活地应对需求变化和风险管理提高开发效率和项目成功的信心。同时它也强调了用例驱动、体系结构设计和迭代增量开发这些在软件开发中的重要原则。

5.1.5 软件能力成熟度模型

软件能力成熟度模型CMM和软件能力成熟度模型集成CMMI旨在提高软件生产率和质量。CMMI是基于CMM开发而来的包括5个成熟度级别共18个关键过程域52个过程目标和3168种关键时间。不同级别代表着企业在软件开发过程中的成熟度水平从初始级到优化级。CMMI可以指导软件开发过程的改进和评估。

5.2 需求工程

需求工程是软件工程领域中的一个重要子领域其目标是通过系统地描述待开发系统及其行为特征和相关约束从而确定客户需求定义设想中系统的所有外部特征。软件需求的定义包括了业务需求、用户需求和功能需求包括非功能需求。在经典的瀑布软件过程模型中将需求分析作为软件开发的第1个阶段明确指出该阶段的输出成果为用户原始需求说明书和软件需求描述规约。软件需求开发的最终文档经过评审批准后则定义了开发工作的需求基线构筑了计划产品功能需求和非功能需求的一个约定。需求管理是一个对系统需求变更、了解和控制的过程其主要活动包括控制对需求基线的变动、保持项目计划与需求一致、控制单个需求和需求文档的版本情况、管理需求和联系链以及跟踪基线中的需求状态。

5.2.1 需求获取

需求获取的基本步骤

需求获取是软件开发过程中非常重要的一步下面是需求获取的基本步骤

1. 开发高层的业务模型了解目标系统的应用领域并建立业务模型来描述用户的业务过程确定初始需求。
2. 定义项目范围和高层需求在项目开始之前与所有涉众共同确定项目范围和高层需求描述系统边界和参与者关系。
3. 识别用户角色和用户代表确定所有涉众并选出每类涉众的用户代表与其一起工作包括传统用户、客户、测试人员、维护人员、市场人员等。
4. 获取具体的需求针对每个涉众获取具体、完整和详细的需求确保对系统的需求理解准确。
5. 确定目标系统的业务工作流具体到待开发的应用系统确定系统的业务工作流和主要的业务规则采取多种方法获取所需信息。
6. 需求整理与总结整理和总结获取的需求资料确定软件系统的综合要求包括功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求等。

需求获取的目标是明确“做什么”而不是“怎样做”以确保开发出满足用户需求的软件系统。在整个过程中与用户和其他利益攸关方的密切合作和沟通至关重要以避免理解错误或遗漏的需求确保项目的成功交付。

需求获取方法

需求获取是软件开发中非常重要的一步不同类型的软件项目需要采用不同的需求获取方法。常见的需求获取方法包括用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法和头脑风暴法。

1. 用户面谈是最常见也是最有效的需求获取方法通过与用户直接交流能够深入理解用户需求。在进行面谈前需要做好充分的准备并将收集到的信息转化为适当的模型和文档。
2. 需求专题讨论会是通过集中相关涉众进行集体讨论的方式可以在短时间内达成共识并统一意见。有助于建立高效团队、揭露和解决问题并快速产生初步的系统定义。
3. 问卷调查可用于确认假设和收集统计倾向数据但在设计问卷时需注意问题不能事先决定问题背后的假设对答案造成偏颇。
4. 现场观察是通过观察用户实际执行业务的过程来全面了解需求细节可以进行手工操作或在原有业务系统上执行。
5. 原型化方法适用于需求不确定的情况通过开发系统原型并与用户多次迭代反馈解决需求不确定性问题特别是在人机交互界面等方面。
6. 头脑风暴法适用于新业务拓展的软件项目通过多人发散思维产生新观点和设想确定具体需求。

根据具体项目需求和情况软件开发团队可以选择合适的需求获取方法或结合多种方法进行需求获取。

5.2.2 需求变更

需求变更在软件开发中是常见的但需要控制变更的范围和影响。如果变更不加控制地持续进行会导致项目混乱、进度延误和质量问题。为了控制需求变更以下几点是重要的原则

1. 评估变更对已提出的需求变更进行仔细评估判断其合理性和影响范围。只有经过评估后的合理变更才应该被采纳。
2. 选择决策者在决定是否采纳变更时选择合适的人员来进行判定。这些人员需要具备相关领域的知识和经验能够全面评估变更的影响。
3. 及时通知变更应及时通知所有相关人员包括开发团队、测试团队和相关的利益相关者。这样可以确保所有人了解变更并根据需要做出相应调整。
4. 控制过程需求变更应按照一定的程序进行确保变更过程被控制和记录。这可以包括变更请求的提交、评审和批准流程以及变更状态的跟踪和管理。

通过以上控制措施软件开发组织可以更好地管理需求变更确保项目的进展和质量。同时精确描述软件需求并进行适当的评估和控制也是重要的原则。

变更控制过程

变更控制委员会

变更控制委员会CCB是由项目中涉及到的各方共同组成的决策机构负责裁定接受哪些变更。CCB应该有一个总则用于描述其目的、授权范围、成员构成、做出决策的过程及操作步骤。CCB应包括项目所有者代表、用户代表、实施方的决策人员等。

在决策变更时CCB需要考虑变更的利弊并做出合理的决定。制定决策过程的描述应包括必须到会的人数或做出有效决定必须出席的人数、决策的方法、主席是否可以否决该集体的决定等。一旦做出决策应指派相应的人员及时更新请求的状态。

当项目接受重要的需求变更时需要重新协商约定。协商的内容可能包括推迟交货时间、要求增加人手、推迟实现较低优先级的需求或者质量上进行折中。

综上所述CCB是一个重要的决策机构需要根据总则和操作步骤来制定决策、交流情况并重新协商约定。通过CCB的管理可以更好地控制需求变更确保项目的进展和质量。

5.2.3 需求追踪

需求跟踪是一个重要的过程旨在建立和维护需求与产品实现之间的一致性。它包括正向跟踪和逆向跟踪两种方式并通过需求跟踪矩阵来保存需求与后继工作成果的对应关系。跟踪能力的信息使得变更影响分析更加便利有利于确认和评估需求变更所需的工作量。

需求跟踪的目的是确保所有工作成果符合用户需求并提供明确查阅需求到产品实现整个过程的能力。为了实现可跟踪能力需求需要统一标识以便进行准确查阅。需求跟踪是一项手工操作任务需要组织提供支持。

在实际项目中通常采用专门的配置管理工具来实现需求跟踪。这些工具可以帮助组织管理和更新跟踪信息确保其与实际情况保持一致。需求跟踪是一个劳动强度较大的任务但对于优秀的需求规格说明书来说具备跟踪能力是一个重要特征。

5.3 系统分析与设计

系统分析阶段是将复杂的对象分解为简单的组成部分找出它们之间的关系的过程其目标是将用户需求表达为系统需求规格说明书。系统设计的目标是根据系统分析结果完成系统构建包括绘制系统蓝图、权衡各种技术和资源、制定详细的设计方案等其主要内容包括概要设计和详细设计。

5.3.1 结构化方法

结构化分析

结构化分析是一种系统分析方法通过使用数据流图和数据字典等工具对系统的功能需求进行分析和描述。下面是结构化分析的主要步骤和工具

1. 分析业务情况绘制数据流图

• 根据当前的物理模型绘制反映业务流程的数据流图。
• 通过分析输入、加工和输出数据流将问题清晰地展现出来。

2. 推导逻辑模型

• 基于物理模型的数据流图推导出等价的逻辑模型的数据流图。
• 这一步骤将问题从物理层面抽象到逻辑层面更好地描述系统的功能需求。

3. 设计逻辑系统生成数据字典

• 设计新的逻辑系统生成数据字典和基元描述。
• 数据字典对系统中使用的数据项、数据结构、数据流、数据存储等进行定义和描述。

4. 建立人机接口提出物理模型的数据流图

• 建立人机接口根据需求提出可供选择的目标系统的物理模型的数据流图。
• 这一步骤关注系统与用户的交互和界面设计。

5. 分析各种方案的成本和风险

• 对各种方案进行成本和风险的分析和评估。
• 根据成本和风险等级对各种方案进行比较和选择。

6. 选择一种方案

• 根据成本、风险和其他因素选择一个最合适的方案。

7. 建立完整的需求规约

• 建立完整的需求规约描述系统的功能需求。
• 需求规约是后续设计、编码和实现系统的基础。

数据流图和数据字典是结构化分析中常用的工具。数据流图通过图形化方式描述数据的流向和加工过程而数据字典则定义和描述了系统中使用的所有数据元素。通过结构化分析可以更清晰地理解系统的功能需求并为后续的设计和开发提供指导。

结构化设计

结构化设计Structured Design, SD是一种面向数据流的设计方法主要分为概要设计和详细设计两个阶段。概要设计阶段的任务是确定软件系统的结构对系统进行模块划分并确定每个模块的功能、接口和模块之间的调用关系。详细设计阶段则是为每个模块设计实现的细节。

在结构化设计中模块是系统的基本单位具有相对独立且单一功能的特点。模块的设计应遵循信息隐藏和抽象原则即将模块的实现细节封装起来对外部只暴露简单的接口信息。模块之间应该具有低耦合、高内聚的特性即模块之间联系较弱、模块内部联系紧密。

系统结构图Structure Chart, SC是概要设计阶段的工具用于反映系统的功能实现和模块之间的联系与通信。系统结构图展示了系统的总体结构和模块之间的层次关系。在详细设计阶段可以使用图形工具、表格工具或语言工具来描述模块的实现细节。图形工具包括程序流程图、PAD图和NS流程图表格工具可以列出操作和条件的详细信息语言工具如PDL可以用于描述具体算法。

详细设计的目标是实现模块功能的正确逻辑算法并保证算法描述简明易懂。设计过程中需要分析确定输入/输出数据的逻辑结构找出输入和输出数据之间的对应关系根据一定的规则导出程序结构图并将基本操作和条件分配到程序结构图中。设计结果可以使用图形工具、表格工具或语言工具进行表示如程序流程图、PAD图、NS流程图、表格等。

总而言之结构化设计是一种以模块为基本单位的设计方法通过模块划分和模块之间的联系来实现系统的功能。概要设计阶段确定系统结构和模块划分详细设计阶段设计模块的实现细节。设计过程中遵循高内聚、低耦合的原则并使用合适的工具来表示设计结果。

结构化编程

结构化程序设计Structured Programming, SP是一种由E.W. Dijikstra在1965年提出的程序设计方法。它将软件系统划分为若干功能模块强调程序的结构性易读易懂并且能够减少出错率和维护费用。

结构化程序设计采用自顶向下、逐步求精的设计方法各个模块通过“顺序、选择、循环”的控制结构进行连接并且只有一个入口和一个出口。

其原则可概括为程序=(算法)+(数据结构)即算法和数据结构分开设计以算法为主体。

结构化程序设计的原则可以归纳为32个字自顶向下逐步细化清晰第一效率第二书写规范缩进格式基本结构组合而成。

数据库设计

数据库设计是根据用户需求在特定的数据库管理系统上建立数据库结构的过程。它包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施以及数据库的运行和维护。本节主要讨论数据库的概念结构设计。

概念结构设计 概念结构设计是根据用户需求描述的现实世界通过对实体事物进行分类、聚集和概括建立抽象的概念数据模型反映各部门的信息结构、信息流动情况、信息间的互相制约关系以及信息的储存、查询和加工要求。通常使用实体-联系图E-R图表示。

• 实体具体可区分的事物可以是人、物也可以是抽象的概念与联系用矩形框表示。
• 属性实体所具有的特性用椭圆形表示并用无向边与相应的实体连接起来。
• 联系反映实体内部或实体之间的关联用菱形表示用无向边与有关实体连接起来同时标明联系的类型1:1, 1:n 或 m:n。

E-R图的基本作图步骤包括确定实体集合、选择每个实体集包含的属性、确定实体集之间的联系、确定实体集的关键字、确定联系的类型。

E-R图中的联系存在一对一约束、一对多约束和多对多约束用来描述实体集之间的数量约束。一对一联系表示两个实体集具有一对一的联系一对多联系表示一个实体集的值与另一个实体集的多个值对应而多对多联系表示两个实体集的值彼此对应。联系也可能有属性如学生选修某门课程所取得的成绩。

以上是数据库概念结构设计的基本内容。

5.3.2 面向对象方法

面向对象Object-Oriented, OO开发方法是一种建立在“对象”概念基础上的软件开发方法学其本质是参照人们认识现实系统的方法完成软件系统的分析、设计与实现。该方法强调使用人类在现实生活中常用的思维方法来认识和描述客观事物使得最终建立的系统能够映射问题域反映问题域中固有的事物及其关系。

面向对象开发方法的核心观点包括

1. 对象组成认为客观世界由对象组成对象具有属性和操作。
2. 分类、联系对象可以根据其属性进行分类对象之间的联系通过传递消息来实现。
3. 封装、继承和多态对象具有封装性将数据和操作封装在一个单元内、继承性子类可以继承父类的属性和行为、以及多态性不同对象对相同消息作出不同响应。

面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程。

其主要包括需求分析、系统分析、系统设计和系统实现4个阶段但各个阶段的划分不像结构化开发方法那样清晰而是在各个阶段之间迭代进行的。

面向对象分析

面向对象的分析方法Object-Oriented Analysis, OOA是一种根据面向对象思想来分析问题的方法。它与结构化分析有较大区别。OOA强调在系统调查资料的基础上针对面向对象方法所需素材进行归类分析和整理而不是对管理业务现状和方法的分析。

OOA模型由5个层次主题层、对象类层、结构层、属性层和服务层和5个活动标识对象类、标识结构、定义主题、定义属性和定义服务组成。它定义了两种对象类之间的结构分类结构和组装结构。分类结构描述一般类和特殊类之间的关系而组装结构反映对象之间的整体和部分关系。

OOA的基本原则包括抽象、封装、继承、分类、聚合、关联、消息通信和粒度控制。抽象是从多个事物中抽取共同的本质特征封装将对象的属性和服务结合为一个不可分的单位并隐藏内部细节继承使得特殊类拥有一般类的全部属性和服务分类划分具有相同属性和服务的对象为一类聚合将复杂事物看作简单事物的组装体关联表示事物之间的联系消息通信要求对象只能通过消息进行通信粒度控制是控制问题域视野的原则。

OOA大致上遵循确定对象和类、确定结构、确定主题、确定属性和确定方法这5个基本步骤。确定对象和类包括抽象出数据及其处理方式的对象和描述多个对象共同属性和方法的类。确定结构涉及问题域的复杂性和连接关系。确定主题是对事物总体概貌和总体分析模型的确定。确定属性是指数据元素用来描述对象或分类结构的实例。确定方法是在收到消息后进行的处理方法。

需要注意的是以上总结仅为面向对象分析方法的一般概述并不详尽。具体实施时还需要考虑其他细节和技术。

面向对象设计

在OOD中还需要注意以下几点

1. 继承和多态是实现可扩展性的重要手段。通过继承可以将相同的属性和方法在父类中定义然后在子类中进行扩展和修改通过多态可以以统一的方式处理不同类型的对象。
2. OOD强调模块化和分层设计。模块化设计可以降低系统的复杂度易于维护和修改分层设计可以将系统划分为不同的层次使得不同的层次之间关注点不同提高了系统的可维护性和可扩展性。
3. OOD还强调设计模式的使用。设计模式是一种被反复使用的、普遍认可的解决特定问题的方法或套路。合理使用设计模式可以提高代码的可读性、可维护性和可复用性。
4. 最后要注意OOD的实现要考虑系统的性能、安全和可靠性等方面如数据结构和算法的选择、异常处理、日志记录等。

面向对象编程

面向对象程序设计Object Oriented ProgrammingOOP是一种编程架构其基本原则是将计算机程序组合成单个能够起到子程序作用的对象。OOP的目标是实现软件工程的重用性、灵活性和扩展性。OOP由对象、类、继承、多态和消息构成其中核心概念是类和对象。

面向对象程序设计方法模拟人类的思维方式使得软件开发方法尽可能接近人类解决现实问题的方式将客观世界中的实体抽象为问题域中的对象从而使描述问题的问题空间与问题的解决方案空间在结构上尽可能一致。

OOP以对象为核心认为程序由一系列对象组成。类是对现实世界的抽象包括表示静态属性的数据和对数据的操作而对象是类的实例化。对象通过消息传递相互通信模拟现实世界中不同实体间的联系是面向对象程序设计的基本模块。

OOP的基本特点包括封装、继承和多态

1. 封装将数据及与数据相关的操作语言组装到一起封装在一个类中实现软件结构的高内聚、低耦合。
2. 继承指一个对象针对另一个对象的独有特点、能力进行复制或延续分为单继承和多继承以及取代继承、包含继承、受限继承和特化继承。
3. 多态当不同对象同时接收到相同消息时所表现出的动作是各不相同的或者在一组对象的一个类中可以使用相同调用方式对相同函数名进行调用即便这些函数所执行的动作是不同的。

数据持久化与数据库

面向对象开发方法中的对象只存在于内存中如果需要永久保存对象的状态就需要进行对象的持久化。对象持久化是将对象保存到数据库或其他可永久保存的存储设备中。为了降低系统的耦合度多层软件设计中引入了持久层负责实现数据持久化的逻辑。关系数据库是目前最常用的数据库类型因此将对象持久化到关系数据库中需要进行对象和关系的映射这就是对象关系映射ORM的概念。主流的持久化技术框架包括Hibernate、iBatis和JDO等。Hibernate是一个全自动的ORM框架可以使用对象编程思维操作数据库iBatis是一个小巧且灵活的解决方案需要手动编写SQL实现JDO是一种描述对象持久化语义的标准API可以在不同数据底层上运行提供了透明的对象存储功能。

5.4 软件测试

软件测试是通过人工或自动化手段对软件系统进行运行和测定的过程。其主要目的是验证软件是否满足规定的需求并发现实际结果与预期结果之间的差异。

软件测试的工作主要包括以下几个方面

1. 发现软件错误通过执行各种测试用例包括功能测试、性能测试、安全测试等发现软件中存在的错误和缺陷以便及时修复。
2. 定义和实现软件组装过程有效地定义和实施软件的组装过程将各个组件从低层到高层有机地组合在一起确保软件的正确性和完整性。
3. 验证软件是否满足技术要求根据任务书和系统定义文档中规定的技术要求验证软件是否达到了这些要求包括功能、性能、安全等各个方面。
4. 提供风险评估依据软件测试可以为开发人员提供信息帮助他们评估软件的风险并做出相应的准备和调整以确保软件的质量和稳定性。
5. 贯穿整个软件开发过程软件测试应该贯穿整个软件开发的过程从需求分析、设计、编码到测试和维护保证整个过程都是高质量的。

总之软件测试的目的是确保软件的质量确认软件按照用户期望的方式进行工作。它不仅发现软件错误还为开发人员提供风险评估依据并贯穿于整个软件开发过程中。这样能够确保软件达到预期要求并具备高质量。

5.4.1 测试方法

软件测试方法可以根据不同的分类标准进行划分。以下是几种常见的分类方法

1. 根据程序执行状态

• 静态测试Static Testing, ST在不运行软件的情况下通过检查源代码、文档和设计等静态元素来评估软件的质量。
• 动态测试Dynamic Testing, DT在运行软件时通过执行测试用例并观察程序的实际执行结果来评估软件的质量。

2. 根据测试对象的知识

• 黑盒测试Black Box Testing测试人员只关注软件的输入和输出而不考虑内部实现细节主要验证软件功能是否符合规格说明。
• 白盒测试White Box Testing测试人员具有对软件内部结构和实现的了解根据程序的逻辑路径和数据流来设计测试用例主要验证软件的逻辑正确性和代码覆盖率。
• 灰盒测试Gray Box Testing介于黑盒测试和白盒测试之间测试人员部分了解软件的内部结构和实现以此为基础设计测试用例。

3. 根据测试的执行方式

• 人工测试Manual Testing, MT测试人员通过手动执行测试用例来评估软件的质量包括手动输入测试数据、观察输出结果等。
• 自动化测试Automatic Testing, AT利用测试工具和脚本自动执行测试用例收集和分析测试结果提高测试效率和准确性。

总之根据不同的分类标准软件测试方法可以被划分为静态测试和动态测试、黑盒测试、白盒测试和灰盒测试以及人工测试和自动化测试。这些分类方法可根据具体的测试需求和目标选择适合的测试方法。

5.4.2 测试阶段

• 单元测试是对软件模块进行测试集中在功能单一、结构简单的模块上。
• 集成测试验证模块组装的正确性和需求功能的实现性。
• 系统测试则是对整个软件系统进行测试包括功能测试、性能测试、验收测试等。
• 性能测试是通过模拟多种负载条件来测试系统性能指标。
• 验收测试是最后一个阶段的测试验证软件是否符合用户需求和合同要求。

除了传统的测试种类外还有一些新型测试种类如AB测试、Web测试中的链接测试、表单测试等。

5.5 净室软件工程

净室软件工程是一种以经济方式生产高质量软件的工程技术其理念在于通过严格的工程过程在规约和设计阶段消除错误并以“净”的方式制作软件。这种方法强调在开发过程中建立正确性的需要避免依赖于成本高昂的错误消除过程。净室软件工程的过程模型是在代码增量积聚到系统的过程中进行统计质量验证甚至提倡开发者不需要进行单元测试而是进行正确性验证和统计质量控制。它是基于理论、面向工作组、经济实用和高质量软件生产的方法。

5.5.1 理论基础

净室软件工程的理论基础主要包括函数理论和抽样理论。

函数理论将程序视为从定义域到值域的映射强调完备性、一致性和正确性的特性通过函数理论的推理来验证程序的正确性。

抽样理论则提出由于不可能对软件的所有可能应用进行测试因此可以通过统计学手段对软件的所有可能使用情况进行抽样并对样本进行测试根据结果分析软件的性能和可靠性。

5.5.2 技术手段

净室软件工程应用的技术手段主要有以下四种

1. 统计过程控制下的增量式开发将整个开发过程划分为一系列较小的累积增量通过受控迭代的工程原理来控制开发过程使开发人员能够集中精力在工作的一部分上而无需同时考虑所有事情。

2. 基于函数的规范与设计采用盒子结构方法根据函数理论定义了行为视图、有限状态机视图和过程视图这三个抽象层次。规范从外部行为视图开始经过状态机视图转化为过程视图实现了信息隐藏和实现分离的软件工程原则。

3. 正确性验证将正确性验证视为净室软件工程的核心。通过使用正确性验证技术净室项目的软件质量得到极大提高。

4. 统计测试和软件认证净室测试方法采用统计学原理通过确定使用模型来代表系统所有可能的使用情况并从中生成测试用例。由于测试用例是总体的随机样本可以进行有效的统计推导评估系统的操作性能。

净室软件工程是一种形式化的软件开发方法能够生成高质量的软件。它利用盒子结构规约进行分析和设计建模并将正确性验证作为主要机制来发现和消除错误而不是依赖于传统的测试方法。

5.5.3 应用与缺点

净室软件工程在20世纪90年代初取得了一系列成功案例包括IBM生产的海量存储控制单元适配器、NASA哥达德飞行控制中心的软件工程实验室以及美国陆军的项目都取得了显著的投资回报和质量提升。然而净室软件工程也存在一些缺点

1. 需要较多数学知识正确性验证步骤困难且耗时开发成本较高
2. 开发小组不进行传统的模块测试可能导致未预期的错误
3. 净室软件工程仍带有传统软件工程的一些弊端。

5.6 基于构件的软件工程

基于构件的软件工程CBSE是一种通过使用可复用构件来设计和构建软件系统的方法强调软件复用和分布对象技术。CBSE的理念是购买已有构件而不是重新构建将软件开发的重点从编写程序转移到组装构件以加快系统构建速度、减轻维护负担并降低开发成本。CBSE正在改变大型软件系统的开发方式将工程师的关注点从实现转移到集成基于对大型软件系统的共性假设通过开发可复用的软件组件来满足这些共性。

5.6.1 构件和构件模型

在软件复用领域构件Component-Based Software Engineering, CBSE被认为是一个独立的软件单元可以与其他构件组成一个软件系统。不同的专家对构件的定义存在一些差异但无论如何定义用于CBSE的构件应该具备以下特征

1. 可组装型构件必须通过公开定义的接口进行外部交互并对自身信息进行外部访问。
2. 可部署性构件必须是自包含的能够作为独立实体在提供其构件模型实现的构件平台上运行且无需在部署前编译。
3. 文档化构件必须完全文档化用户可以根据文档来判断构件是否满足需求。
4. 独立性构件应该是独立的可以在无其他特殊构件的情况下进行组装和部署如果需要其他构件提供服务则应当有显示声明。
5. 标准化在CBSE过程中使用的构件必须符合某种标准化的构件模型。

构件模型定义了构件实现、文档化以及开发的标准为构件开发者确保构件的互操作性和为中间件的构件执行基础设施供应商支持构件操作而设立。目前主流的构件模型包括Web Services模型、Sun公司的EJB模型和微软的.NET模型。

构件模型包含以下要素信息

1. 接口构件通过构件接口来定义包括操作名、参数以及异常等。
2. 使用信息为使构件远程分布和访问必须给构件一个特定的、全局唯一的名字或句柄并包括构件的元数据。
3. 部署规定构件如何打包使其部署成为一个独立的可执行实体包括有关包中内容的信息和它的二进制构成的信息。

构件模型还提供了一组被构件使用的通用服务包括平台服务和支持服务。平台服务允许构件在分布式环境下通信和互操作而支持服务是很多构件需要的共性服务例如身份认证服务。

中间件实现共性的构件服务并提供这些服务的接口构件被部署在一个容器中容器是支持服务的一个实现加上一个接口定义构件必须提供该接口定义以便和容器整合在一起。

5.6.2 CBSE过程

CBSE过程的主要目标是通过构件复用来提高软件开发的效率和质量。它强调在开发过程中识别、选择和集成可复用的构件并在不同的阶段进行适配和定制以满足系统需求。与传统的软件开发过程相比CBSE过程具有以下几点不同之处

1. 需求分析CBSE过程要求在早期阶段完整地定义系统需求以便尽可能多地识别出可复用的构件。而在增量式开发中需求可以逐步完善。
2. 需求修改CBSE过程中根据已发现的可复用构件可以对需求进行修改和细化。如果可复用构件无法满足用户需求可以考虑调整需求或寻找其他支持相关需求的构件。
3. 系统体系结构设计CBSE过程在系统体系结构设计完成后会进一步进行构件搜索和设计精化的活动。可能需要寻找备选构件或对构件进行修改以适应功能和架构需求。
4. 构件集成CBSE过程中的开发阶段主要是将已找到的构件进行组装。这涉及将构件与构件模型基础设施集成并可能需要开发适配器来协调不匹配的构件接口。

在CBSE过程中系统体系结构设计阶段尤为重要因为选择合适的构件模型和实现平台将决定可选构件的范围和限制。通过CBSE过程可以更好地利用已有的构件资源加快开发速度提高软件质量并促进软件复用的可持续性。

5.6.3 构件组装

构件组装是将可复用的构件通过直接集成或编写适配器来创建系统或其他构件的过程。常见的组装方式有顺序组装、层次组装和叠加组装。

1. 顺序组装按照顺序调用已存在的构件将它们组装在一起创建新的构件。需要编写适配器代码来确保构件之间的接口兼容性。

2. 层次组装一个构件直接调用另一个构件提供的服务。被调用构件必须提供调用构件所需的服务需要编写适配器代码进行接口转换。

3. 叠加组装将两个或多个构件组合在一起创建新构件新构件具备原构件的功能并提供新的接口。原构件之间不相互依赖或调用。

在构件组装过程中可能会遇到接口不兼容的情况包括参数不兼容、操作不兼容和操作不完备。为了解决这些问题可以编写适配器构件来使两个构件的接口一致。

在选择组装方式时需要考虑系统的功能需求、非功能需求以及构件替换的难易程度以确保系统能够满足需求并具有良好的可扩展性。

5.7 软件项目管理

5.7.1 项目管理概述

在软件项目管理中进度管理是关键的一环它涉及到软件开发过程中每个阶段的时间安排和任务分配以确保项目按时完成。配置管理则是为了控制软件开发过程中的变更包括版本控制、配置项管理和变更控制等方面。质量管理则是为了保证软件开发过程中的质量包括需求分析、设计、编码、测试和维护等方面。风险管理则是为了识别和评估项目中的各种风险并采取相应的措施来降低风险影响。

5.7.2 软件进度管理

软件项目进度管理中的两个关键概念工作分解结构和任务活动图。

1. 工作分解结构WBS
   工作分解结构是将项目按一定原则分解成任务再将任务分解为具体工作的过程。WBS树形结构以可交付成果为导向对项目要素进行分组并是制订进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。WBS的常见分解方式包括按产品的物理结构、功能、实施过程、实施单位、项目目标等分解方式并指出了任务分解的基本要求。
   

2. 任务活动图
   任务活动图是在完成工作分解结构之后根据每个活动的定义和活动间的关系得到的图表用于确定活动之间的相互关系和活动执行的前后顺序。活动定义包括确定完成项目所必须进行的具体活动明确活动的前驱、持续时间、必须完成日期、里程碑或交付成果。根据活动顺序可以得到对应的任务活动图通常采用甘特图等方式来展示和管理项目活动。

5.7.3 软件配置管理

软件配置管理Software Configuration Management, SCM是一种技术旨在标识、组织和控制软件变更。它应用于整个软件工程过程以应对软件开发中不可避免的变更减少混乱并提高生产效率。SCM的核心内容包括版本控制和变更控制。

1. 版本控制Version Control

• 追踪程序代码、配置文件和说明文档等文件变更。
• 记录变更的时间、负责人和内容每次变更都会增加文件的版本号。
• 有效解决多人协同开发中的版本同步和开发通信问题提高协同开发效率。
• 通过分支与合并的方法解决不同版本软件的错误修正问题。

2. 变更控制Change Control

• 管理变更流程确保变更有序进行。
• 处理来自外部和内部的变更要求如客户需求变更和内部错误修正。
• 处理来自外部的需求变更可能更具挑战性因为IT项目中需求变更的概率大且工作量巨大。

通过版本控制和变更控制SCM能够使错误降到最低并提高生产效率从而确保软件开发过程的有序进行。

5.7.4 软件质量管理

软件质量是指软件与明确和隐含的需求相一致的程度。它包括软件符合功能和性能需求、开发标准以及专业软件应具备的隐含特征的程度。

从管理角度来看影响软件质量的因素可分为三组反映了用户在使用软件产品时的不同倾向和观点

1. 产品运行

• 关注软件在运行过程中的稳定性、可靠性和性能表现。
• 包括对软件的功能是否正确、响应时间是否合理、资源利用是否高效等方面的评估。
• 目标是确保软件能够按照预期运行满足用户的实际需求。

2. 产品修改

• 关注软件的可维护性和可扩展性。
• 包括对软件代码结构的清晰性、模块化程度、文档化程度等方面的评估。
• 目标是使软件易于修改和扩展以适应不断变化的需求和环境。

3. 产品转移

• 关注软件的可移植性和可部署性。
• 包括对软件在不同操作系统、平台或环境下的适应性和兼容性的评估。
• 目标是确保软件可以顺利地转移到不同的环境中并能够正常工作。

通过关注这三个方面管理者可以综合考虑软件质量的多个维度从而提高软件的质量水平满足用户的需求。

软件质量保证

软件质量保证Software Quality AssuranceSQA是通过建立有计划、系统化的方法向管理层保证制定的标准、步骤、实践和方法能够正确地被所有项目采用的过程。其目的在于使软件过程对管理人员可见并通过对软件产品和活动进行评审和审计来验证软件是否符合标准。SQA致力于一开始就避免缺陷产生主要目标包括事前预防工作、在缺陷引入时捕获、作用于过程而不是最终产品、以及贯穿于所有活动。

软件质量保证的关注点主要在于预防缺陷的产生并且以独立审查的方式监控软件开发任务的执行提供反映产品和过程质量的信息和数据以提高项目透明度并辅助软件工程取得高质量的软件产品。SQA的主要作用是给管理者提供预定义的软件过程的保证确保选定的开发方法、标准和规程得到遵循和执行。

软件质量保证的主要任务包括SQA审计与评审SQA报告以及处理不符合问题。SQA审计涉及对软件工作产品、软件工具和设备的审计评价其是否符合组织规定的标准SQA评审旨在确保软件工作组的活动与预定的软件过程一致以及确保软件过程在软件产品的生产中得到遵循。SQA报告应记录工作结果并向相关人员发布处理不符合问题也是SQA的重要任务需要及时向有关人员和高级管理者反映。

软件质量认证

质量认证是用来检验企业整体质量水平的ISO 9000和CMM是目前国内软件企业主要采用的质量认证标准。ISO 9001认证是指组织具有提供满足顾客要求和适用法规要求的产品的能力CMM是软件生产过程标准和软件企业成熟度等级认证标准。

5.7.5 软件风险管理

软件项目风险管理是软件项目管理的重要内容其主要目标是预防风险。风险管理包括风险估计风险辨识、风险分析、风险排序和风险控制风险管理计划、风险处理、风险监督两大阶段。美国Boehm、Charette以及卡内基梅隆大学软件研究所提出了不同的软件风险管理体系其中卡内基梅隆大学的风险管理体系是一个基于实践的全面风险管理体系并将软件需求方作为软件风险管理的要素。