软件设计 -（五）软件工程基础知识

iuhart

已于 2024-04-29 17:34:30 修改

阅读量810

点赞数 23

分类专栏：软件设计师文章标签：设计规范

于 2024-04-28 18:06:56 首次发布

本文链接：https://blog.csdn.net/iuhart/article/details/138225335

版权

软件设计师专栏收录该内容

17 篇文章 0 订阅

订阅专栏

文章目录

概述
一、软件过程
- 软件过程模型（软件开发模型）
二、需求分析
三、系统设计
四、系统测试
五、运行和维护
六、软件项目管理
- 进度管理
- 风险管理
七、软件质量
- ISO/IEC 9126 软件质量模型
八、软件度量
- 软件复杂性度量
- McCabe 度量法
九、软件工具与软件开发环境

概述

软件生存周期

生存周期阶段	说明	参与人员	产生的文档
可行性分析与项目开发计划	确定软件的开发目标及可行性。	用户、项目负责人、系统分析师	可行性分析报告，项目开发计划
需求分析	确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。	用户，项目负责人、系统分析师	需求说明书
概要设计	把确定的各项功能转换成需要的体系结构。明确有哪些模块组成，模块的层次结构、调用关系，每个模块的功能；设计数据结构和数据库结构。	系统分析师、软件设计师	概要设计说明书
详细设计	对每个功能进行具体描述，把功能免食宿转变为精确的、结构化的过程描述。	软件设计师、程序员	详细设计文档
编码	编写程序代码	程序员
测试	在设计测试用例的基础上检查软件的各个组成部分。	测试人员	软件测试计划、测试用例、软件测试报告
维护	生存周期中最长的阶段。

一、软件过程

能力成熟度模型（CMM）：阶段式模型（表示方法）

成熟度级别	说明
初始级	软件过程杂乱无章，甚至很混乱，几乎没有明确定义的步，项目完成完全依赖个人的努力和英雄式核心人物的作用
可重复级	`建立了基本的项目管理过程和实践`来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
已定义级	管理和工程两方面的软件过程已经`文档化、标准化`，组织标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发个维护软件。
已管理级	制定了软件过程和产品质量的`详细度量标准`。产品质量都被开发组织的成员所理解和控制。
优化级	加了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

能力成熟度模型集成（CMMI）

阶段式模型：关注组织的成熟度。
连续式模型：关注每个过程域的能力，一个组织对不同的过程域可达到不同的过程域能力等级。

阶段模式	说明	连续模式	说明
初始的	过程不可预测且缺乏控制	$CL_0$ （未完成的）	过程域未执行或未得到 $CL_1$ 中定义的所有目标
已管理的	过程为项目服务	$CL_1$ （已执行的）	过程将可标识的输入工作产品转换成可标识输出工作产
已定义的	过程为组织服务	$CL_2$ （已管理的）	其共性目标集中于已管理的过程的制度化。
已定量管理的	过程已度量和控制	$CL_3$ （已定义级的）	其共性目标集中于已定义的过程的制度化。
优化的	集中于过程改进	$CL_4$ （定量管理的）	其共性目标集中于可定量管理的过程的制度化。
-	-	$CL_5$ 优化的）	使用量化（统计学）手段改变和优化过程域。

软件过程模型（软件开发模型）

模型	说明	优缺点
瀑布模型	定义：将软件生存周期中的各个活动规定为以线性顺序连接的若干阶段的模型。以项目阶段评审和文档控制为手段有效地对整个开发过程进行指导，是一个以文档作为驱动、适合于软件需求明确的软件项目。	优点：容易理解，管理成本低；强调研发的阶段性早期计划及需求调查和产品测试。缺点：客户必须能完整、正确和清晰地表达他们的意思；需求或设计中的错误往往只有到了项目后期才能够被发现，项目风险控制能力弱。
V模型	瀑布模型的一个变体。描述了质量保证活动和沟通、建模相关活动以及早期构建相关活动之间的关系。	提供了一种将验证确认活动应用有早期软件工程工作中的方法。
增量模型	融合了瀑布模型的基本成份和原型实现的迭代特征。它假设可以将需求分段为系列增量产品，每一个增量可以分别开发。强调每一个增量均发布一个可操作的产品。	优点：拥有瀑布模型的所有优点；第一个可交付的版本所需要的成本和时间很小。缺点：1、若没有对用户的变更要求进行规划，产生的初始增量可能会造成后来增量的不稳定；2、若需求不想早期思考的那样稳定和完整，一些增量可能需要重新开发，重新发布；3、管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
原型模型 (演化模型)	原型是预期系统的一个可执行的版本。适用于用户需求不清、需求经常变化（系统规模不是很大也不太复杂时）。	原型模型开始于沟通，被开发的原型交付给客户，并收集客户的反馈意见，可在下一轮中对原型进行改进。在前一个原型需要改进、或扩展的时候，进入下一轮原型迭代开发。
螺旋模型 (演化模型)	将瀑布模型和演化模型结合起来，加入风险分析。强调风险分析，适合庞大、复杂并且具有高风险的系统。每个螺旋周期分为：制定计划、风险分析、实施工程、用户评估。	优点：与瀑布模型相比，支持用户`需求动态化`，为用户参与软件开发所有关键决策提供，提高了软件的适应能力，降低了开发的风险缺点：需开发人员具有相当丰富的风险评估经验和专门知识；过多的迭代会增加开发成本，延迟提交时间。
喷泉模型	以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有： `迭代性`：开发活动常常需要重复多次，在迭代的过程中不断完善； `无间隙性`：指在开发活动之间不存在明显的边界。	优点：提高软件开发效率，节省开发时间（喷泉模型各个阶段没有明显的界限，开发人员可以同步进行）。缺点：需要大量开发人员；要求严格管理文档，使得审核难度加大。
基于构件的开发模型	指利用预先包装的构建来构造应用系统。	领域工程：目的是构建领域模型、领域基准体系结构和可复用构件库。应用系统工程：目的是使用可复用构建组装应用系统。
形式化方法模型	是建立在`严格的数学基础`上的一种软件开发方法。主要活动是生成计算机软件形式化的数学规格说明。	易于发现需求的歧义性、不完整性和不一致性。
`统一过程（UP）模型`	“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。迭代的意思是将整个软件开发项目划分为许多个小的“袖珍项目”。	起始阶段（生命周期目标），专注于项目的初创活动。精化阶段（生命周期架构），理解最初的领域范围后进行需求分析和架构演进。构建阶段（初始运作功能），关注系统的构建，产生实现模型。移交阶段（产品发布）。关注软件提交方面的工作，产生软件增量。
敏捷方法	有以下方法	通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。
极限编程（XP）	4 大价值观，5 个原则，12 个最佳实践	XP 是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。
水晶法	认为每个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件的质量有重要的影响。	随项目质量和开发人员素质的提高，项目过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。
并列争求法	使用迭代方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。	迭代、增量交付。多个组织和自治小组并行地递增实现产品。
自适应开发	6 个基本原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的， “重做” 与 “做” 同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整。确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。	猜测、合作、学习
敏捷统一过程	大型上连续，小型上迭代。

二、需求分析

需求	说明
功能需求	系统要做什么，在何时做，在何时以及如何修改或升级。
性能需求	软件开发的技术型指标。如：存储容量限制、执行速度、响应时间及吞吐量。
用户或人的因素	用户类型。如：用户对计算机的熟练程度，需要接受的训练，理解、使用系统的难度，错误操作系统的可能性等。
环境需求	未来软件应用的环境，包括硬件和软件。
界面需求	考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。
文档需求	需要哪些文档，文档针对哪些读者。
数据需求	输入、输出数据的格式，接收、发送数据的频率，数据准确性和精度，数据流量，数据需保持的时间。
资源使用需求	软件运行所需要的数据、其它软件、内存看空间等资源；软件开发、维护所需的人力、支撑软件、开发设备等。
安全保密需求	是否对访问系统或系统信息加以控制，隔离用户数据的方法，如何与其他程序和操作系统隔离以及系统备份要求等。
可靠性需求	系统可靠性的要求，是否必须检测和隔离错误；出错后，重启系统允许的时间等。
软件成本消耗与开发进度需求	开发是否有规定的时间表，软/硬件投资有无限制等。
其他非功能性需求

三、系统设计

系统设计的主要内容：总体结构设计、代码设计、输入设计、输出设计、处理过程设计、数据存储设计、用户界面设计、安全控制设计等。

概要设计
- 设计软件系统的总体结构
  
  将一个复杂的系统按功能划分模块；确定每个模块的功能、模块间的调用关系、模块间的接口（即模块间传递的信息）；评价模块结构的质量。
- 数据结构及数据库设计
- 编写概要设计文档
  文档主要有概要设计说明书、数据库设计说明书、用户手册及修订测试计划。
- 评审
  对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方法的可行性，关键的处理及内外部接口定义的正确性、有效性、各部分之间的一致性等都要一一进行评审。
详细设计
- 对每个模块进行详细的算法设计
- 对模块内的数据结构进行设计
- 对数据库进行物理设计
- 其他设计（代码设计，输入/输出格式设计，用户界面设计）
- 编写详细设计说明书
- 评审

四、系统测试

成功的测试：是发现了至今尚未发现的错误的测试。
目的：希望能以最少的人力和时间发现潜在的各种错误和缺陷。
信息系统测试基本原则：
- 应尽早并不断地进行测试。测试不是在系统开发完成之后才进行的；测试应贯穿在开发的各个阶段。
- 测试工作应该避免由原开发人员或小组承担。测试工作应由专门人员来进行，这样会更客观、更效率。
- 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出的结果。
- 在设计测试时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。
- 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。
- 严格按照测试计划来进行，避免测试的随意性。
- 妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便。
- 测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。

有效的软件测试上分为 4 个步骤：单元测试、集成测试、确认测试、系统测试。

单元测试

单元测试主要检查模块的以下 5 个特征。

模块接口主要测试调用模块、模块间及标准函数时，实参和形参在属性、数目和顺序上是否相等；全局变量在各模块中的定义和用法是否一致。
局部数据结构 变量的说明是否合适，是否使用了尚未赋值（或初始化）的变量，变量的初始值和默认值是否正确，变量名是否有错。
重要的执行路径
出错处理
边界条件

黑盒测试（功能测试）

也成功能测试，在完全不考虑软件内部结构和特性的情况，测试软件外部特征。

白盒测试（结构测试）

也成结构测试，根据程序内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。

白盒测试常用技术
- 逻辑覆盖：语句覆盖、判断覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。
- 循环覆盖：使循环中的每个条件都得到验证。
- 基本路径测试
白盒测试原则
- 程序模块中的所有独立路径至少执行一次。
- 在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
- 每个循环都应在边界条件和一般条件下各执行一次。
- 测试程序内部数据结构的有效性。

五、运行和维护

可维护性的评价指标：可理解性、可测试性、可修改性。
系统维护主要包括：
- 硬件维护
  硬件保养，突发故障维护（花费时间不能过长）。
- 软件维护
  - 正确性维护。改正测试阶段未发现的错误。
  - 适应性维护。适应信息计数变化和管理需求变化而进行的修改。
  - 完善性维护。为扩充功能和改善性能而进行的修改。
  - 预防性维护。为了改进软件的可靠性和可维护性，及适应未来的软/硬件环境的变化，而主动增加预防性的新的功能，使系统适应各类变化而不被淘汰。
- 数据维护
  主要进行数据库的安全性、完整性、及并发性控制。

六、软件项目管理

软件项目估算常用方法
1. 基于已完成的类型项目进行估算。
2. 基于分解技术进行估算。
3. 基于经验估算模型的估算。

进度管理

Gantt 图
- Gantt 图能清晰描述每个任务从何时开始，到何时结束；任务进展情况及各任务间的并行关系。
- 不能清晰地反映各任务之间的依赖关系，难以确定整个项目的关键所在，不能反映计划中有潜力的部分。
PERT 图
- 关键路径：用时最长的路经。
- 关键活动：关键路径上的活动
- 不能反映任务之间的并行关系。

风险管理

软件风险特性：不确定性（指风险可能发生也可能不发生）、损失（风险发生就会产生恶性后果）。

项目风险：预算、进度、人员、资源、利益相关者、需求等方面。
技术风险：设计、接口、实现、验证、维护等，及规格说明的歧义性、技术的不确定性、技术陈旧及“前沿”技术。
商业风险：市场风险、策略风险、销售风险、管理风险、预算风险。

风险识别
识别已知风险、可预测风险；回避这些风险，必要时控制这些风险。
风险因素：性能风险、成本风险、支持风险、进度风险。
风险预测
又称风险估计；从两方面评估一个风险：风险发生的可能性或概率；风险发生产生的后果。
风险控制
风险避免、风险监控、RMMM 计划。

七、软件质量

软件的质量是指反映系统或软件产品满足规定或隐含需求的能力的特征和特性全体。用户的满意程度。

ISO/IEC 9126 软件质量模型

质量特性	质量子特性	说明
功能性	适合性：对规定任务能否提供功能，及功能是否合适。准确性互用性：与其它指定系统交互操作的能力。依从性：服从有关标准、约定、法规等。安全性：避免非授权故意或意外访问的能力。	指满足规定或隐含需求的那些功能。
可靠性	成熟性：软件故障引起失效的频度。容错性易恢复性	在规定的一段时间内和规定的条件下软件维持在其性能水平有关的能力。
易使用性	易理解性易学性易操作性	使用所需要的努力。
效率	时间特性资源特性	在规定条件下，和软件的性能水平与所用资源量之间的关系有关的软件属性。
可维护性	易分析性：诊断缺陷或失效原因，及判定待修改部分所需要的努力。易改变性：进行修改、排错或适应环境变换所需要的努力。稳定性：修改造成未预料效果的风险。易测试性：确认修改软件所需努力。	与进行规定的修改所需要的努力有关的一组属性。
可移植性	适应性：与转移时的处理和手段有关。易安装性一致性：可移植性有关的标准或约定。易替换性	与从某一环境转移到另一环境的能力有关的一组属性。

八、软件度量

软件度量的分类：

第一种：分为面向规模的度量、面向功能的度量、面向人的度量。
- 面向规模的度量：软件规模通常用程序的代码行或千行代码来衡量。
- 面向功能的度量：集中在程序的“功能性”和“实用性”。
- 面向人的度量：人们开发软件所用方式及理解有关工具的方法和效率信息。
第二种：生产率度量、质量度量、技术度量。
- 生产率度量：主要关注软件工程活动的制品。
- 质量度量：指软件满足明确的和隐含的用户需求的程度。
- 技术度量：主要集中在软件产品的某些特性（如，逻辑复杂度、模块化程度等）上，而不是软件开发的全过程。