软件工程

前言

本文用于预习考研复试需要考的《软件工程》一文，本文不具备任何原创性

软件工程

计算机软件

软件

计算机软件是指计算机系统中的程序以及文档，程序是计算任务处理对象和处理规则的描述

软件特点

• 一种逻辑实体
• 维护工作量大
• 维护软件过程中会引入副作用

软件分类

系统软件

最靠近硬件的一层，比如操作系统

支撑软件

软件开发、维护于运行的软件，比如各种IDE等

应用软件

应用于特定领域的软件

软件语言

软件语言主要包括需求定义语言、功能性语言、设计性语言、程序设计语言和文档语言

需求定义语言

用于书写软件需求定义的语言，包括功能需求与非功能需求，典型的语言如PSL

功能性语言

书写软件功能规约的语言，描述软件做什么以及只做什么，典型语言有广谱语言、Z语言

设计性语言

书写软件设计规约的语言，是软件设计的严格而完整的描述，典型语言有PDL

程序设计语言

即编程语言，可以分为低级语言与高级语言，过程式语言与非过程式语言，通用语言与专用语言，交互式语言与非交互式语言，顺序语言与并发语言与分布语言

文档语言

书写软件文档使用的语言，如Z语言

软件工程

软件工程是建立和使用一套合理的工程原则,以便获得经济的软件。这种软件是可靠的,可以在实际机器上高效地运行

软件工程是应用计算机科学理论以及工程管理原则的方法,按预算与进度实现满足用户要求的软件产品的工程,或以此为研究对象的学科

软件工程的基本原则

适宜的开发规范

选用适宜的开发规范，以保证软件开发的可持续性，并使最终的软件产品满足客户的需求

合适的设计方法

要考虑软件的模块化，信息隐藏，局部化，一致性以及适应性等问题，采用合适的设计方法有助于支持问题的解决与实现

高质量的工程支持

需要提供高质量的工程支持，如配置管理、质量保证

有效的软件工程管理

软件工程的管理直接影响可用资源的有效利用，以提高软件组织的生产能力

软件生存周期

1. 计算机系统工程
   计算机系统工程的任务是确定待开发软件的总体要求与范围，以及该软件与其他计算机系统元素之间的关系，进行成本估算，做出进度安排，并进行可行性分析
2. 需求分析
   需求分析主要解决待开发软件要做什么的问题，确定软件的功能、性能、数据、界面等要求，生成软件需求规约
3. 设计
   软件设计主要解决待开发软件怎么做的问题，通常可以分为系统设计与详细设计，系统设计的任务是设计软件系统的体系结构，详细设计的任务是设计各个组成成分的实现细节
4. 编码
   利用程序设计语言进行编码
5. 测试
   发现并纠正软件中的错误与缺陷，包括单元测试、集成测试、确认测试与系统测试
6. 运行与维护
   软件运行期间需要进行维护，对软件进行修改

CMM

CMM是能力成熟度模型，定义了5哥软件过程成熟度等级，包括初始级、可重复级、已定义级、已管理级、优化级

• 初始级
  软件过程的特点是无秩序的，甚至是混乱的，几乎没有什么过程是经过妥善定义的
• 可重复级
  建立了基本的项目管理过程来跟踪成本、进度与功能特性，制定了必要的过程纪律，能重复澡先类似应用项目取得的成功
• 已定义级
  已将管理和工程活动两方面的软件工程文档化，标准化，并综合成该组织的标准软件过程，所有项目均使用经批准、剪裁的标准软件工程来开发与维护软件
• 已管理级
  收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解与控制
• 优化级
  过程的量化反馈和先进的新思想、新技术促使过程不断改进

CMMI

CMMI是若干过程模型的综合与改进，是支撑多个工程学科和领域的系统的、一致的过程改进框架，能适应现代工程的特点与需求，能提高过程的质量与工作效率。

CMMI有两种表示：阶段式模型和连续式模型

阶段式模型

阶段式模型的结构类似于CMM，分为五个成熟度等级

• 初始的
  过程不可预测且缺乏控制
• 已管理的
  过程为项目服务
• 已定义的
  过程为组织服务
• 定量管理的
  过程已度量和控制
• 优化的
  集中与过程改进

连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级

CMMI包含了6哥过程域能力等级，等级号为0-5，能力等级表明了单个过程域中组织执行的好坏成都，能力等级包括共性目标及相关的共性实践，可以独立地应用于任何单独的过程域

• CL0
  未完成的，过程域未执行或未达到CL1中定义的所有目标
• CL1
  已执行的，其共性目标是过程可以将标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标
• CL2
  已管理的，共性目标是集中于已管理的过程的制度化。根据组织政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的组员，所有工作任务和工作产品都被监督、控制和评审
• CL3
  已定义的，共性目标是集中于已定义的过程的制度化，过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对该过程的改进上
• CL4
  定量管理的，共性目标是集中于可定量管理的过程的制度化，使用测量与质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则
• CL5
  优化的，使用量化手段改变和优化过程域，以应对客户的要求的改变与持续改进计划的过程域的功效

软件过程模型

软件过程模型习惯上也叫软件开发模型，是软件开发全部过程、活动和任务的结构框架

瀑布模型

1970年由W.Royce提出,给出了软件生存周期活动的固定顺序,上一阶段的活动完成后向下一阶段活动过渡,最终得到开发的软件产品

瀑布模型中上一阶段的活动完成并经过评审后才能开始下一阶段的活动,特征如下

• 接受上一阶段活动的结果作为本阶段活动的输入
• 依据上一阶段活动的结果实施本阶段应完成的活动
• 对本阶段的活动进行评审
• 将本阶段活动的结果作为输出，传递给下一阶段

优点

最早出现应用最广泛的模型,确保软件开发的顺利进行,对提高软件项目的质量和开发效率起到重要作用

缺点

• 用户难以清晰描述所有需求，开发过程中需要也有可能发生改变
• 发现错误时，为了改正错误要回到前一阶段，造成瀑布倒流
• 在测试完成后，才可以看到可运行的软件，发现问题的修改代价极大

增量模型

增量模型将软件的开发过程分成若干个日程时间交错的线性序列,每个线性序列产生一个可发布的增量版本,后一个版本是对前一个版本的修改和补充,重复增量发布的过程,直至产生最终的完善产品

有点

适用于需求经常发生变化的软件开发,以后的增量中可以逐渐加入需求,另外可以有计划地管理技术风险.

缺点

需要良好的架构设计,避免加入的构件破坏已构造好的系统部分,需要对系统有好的全盘分析,否则容易退化成边做边改模型

原型模型

原型是预期系统的一个可执行版本,反映了系统性质的一个选定的子集.一个原型不必满足目标软件的所有约束,目的是可以快速,低成本地构建原型.步骤是:

定义总体目标 –> 标识需求 –> 指定原型开发计划–> 确定原型目标和范围–> 快速设计建模–>构建原型 –> 交付使用–> 收集反馈意见 – > 下一轮原型迭代开发–> 定义总体目标

优点

用户与开发者在原型上达成一致,减少错误,缩短开发周期,加快进度,降低成本

缺点

不利于原型系统作为最终产品,原型被建造仅仅是用户用来定义需求,之后便会被部分或全部抛弃,准确的原型设计比较困难,不利于开发人员创新

螺旋模型

螺旋模型将原型实现的迭代特征与瀑布模型中的控制的和系统化的方面结合起来,增加了风险分析.螺旋模型沿着螺线自内向外旋转,4个任务区域(4个象限)内分别完成以下任务:

• 第一象限：风险分析、评价所选方案、识别风险、清楚风险
• 第二象限：制订计划，确定软件目标，选定实施方案，弄清项目开发的限制条件
• 第三象限：客户评估，评价开发工作，提出修正建议
• 第四象限：工程实施，实施软件开发，验证工作产品

优点

设计灵活，成本计算容易，客户始终参与每个阶段的开发，可以进行有效的互动

缺点

周期长，需要丰富的风险评估经验以及专门知识，如果未能及时标识风险，势必造成重大损失

喷泉模型

喷泉模型是一种支持面向对象开发的过程模型，体现了面向对象的迭代与无间隙特性

优点

各个阶段没有明显的边界,开发人员可以进行同步开发,提高软件项目的开发效率,节省开发时间

缺点

不利于项目管理,要求严格编写文档,审核难度大

基于构件的开发模型

利用预先包装的构件来构造应用系统.构件可以是内部开发的构件,也可以是商业化的构件

优点

构件可重用,易于维护,对提高软件生产率,提高软件质量,降低成本有很大的帮助

缺点

很难找到100%合适的构件,就是现有的构件不一定很适合使用,但基于已有构件构造出的构件未必经过100%的测试,难以保证质量.

形式化方法模型

形式化方法是建立在严格的数学基础上的一种软件开发方法,用严格的数学语言和语义描述功能规约与设计规约,通过数学的分析与推导,易于发现需求的歧义性,不完整性与不一致性,易于对分析模型,设计模型和程序进行验证.通过数学的演算,使得从形式化功能规约到形式化设计规约,以及从形式化设计规约到程序代码的转换成为可能

优点

用数学语言解决了规格说明的二义性问题,提高了精确性用数学提供了确认手段,使得证明与验证软件按程序满足用户和系统的需求成为可能,可以可视化地模拟/执行模型

缺点

形式化的方法比其他技术的抽象级别要低,容易陷入细节,需要提早确定系统边界,通常限于正确一致的模型,但大多数情况下模型并非正确与一致

系统工程

系统工程

软件工程中的系统是指基于计算机的系统,而基于计算机的系统是指通过完成处理某些预定义目标而组织在一起的元素的集合或排列

系统工程过程依赖于应用领域而呈现不同的形式,当工作的语境集中于业务企业时,进行业务过程工程,当关注产品生产的过程时,称为产品工程

系统工程的任务

主要有五个方面

• 识别用户的要求
  系统工程的第一步就是识别用户对基于计算机的系统的总体要求,标识系统的功能和性能范围,确定系统的功能,性能,约束和接口
• 系统建模与模拟
  系统模型通常可用图形来描述,配合相应的文字说明,必要时在系统建模后可构造原型,进行系统模拟,以分析所建的模型是否满足整个基于计算机的系统的要求.一个基于计算机的系统通常可以考虑一下的模型
  • 硬件系统模型
    硬件系统模型描述基于计算机系统中的硬件配置,通信协议,拓扑结构,以及确保基于计算机系统的安全性,可靠性,性能等要求的措施
  • 软件系统模型
    基于计算机系统中的软件部分可以分为若干个子系统,软件系统模型描述各个子系统的功能,性能等要求,各软件子系统在硬件系统中的部署情况,以及软件子系统之间的交互
  • 人机接口模型
    人机接口模型描述人如何与基于计算机的系统进行交互,包括用户环境,用户的活动,人机交互的语法与语义等
  • 数据模型
    数据模型主要描述基于计算机的系统使用了哪些数据库管理系统,如果使用多个数据库管理系统还应描述它们之间的数据转换方式,必要时可给出主要的数据结构
• 成本估算及进度安排
  开发一个基于计算机的系统需要一定的资金投入和时间约束,因此在系统工程阶段对需开发的基于计算机的系统进行成本估算,并作出进度安排
• 可行性分析
  基本从以下三方面进行
  • 经济可行性
    主要进行成本效益分析，从经济角度确定系统是否值得开发
    • 成本
      • 购置硬件、软件和设备的费用
      • 系统的开发费用
      • 系统安装、运行和维护费用
      • 人员培训费用
    • 效益
      效益可以分为社会效益与经济效益,经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用。社会效益指使用基于计算机的系统后对社会产生的影响,通常社会效益只能定性地估计,经济效益通常可用货币的时间价值,投资回收期和纯收入来度量
    • 货币的时间价值
      通常可以利用年利率来衡量货币的时间价值，设银行储蓄的年利率为i，现存入钱p，在n年后可得到的钱为F，则
      $F = P(1 + i)^n$
      所以n年后得到的F，折合成现在的钱P公式为
      $P=\frac{F}{(1 + i)^n}$
    • 投资回收期
      投资回收期是指累计的经济效益正好等于投资成本所需的时间,投资回收期通常是用于评价开发一个工程的价值的重要经济指标
    • 纯收入
      纯收入指出了若干年扣除成本后的实际收入: 纯收入 = 累计经济效益 - 成本
  • 技术可行性
    技术可行性主要根据系统的功能,性能,约束条件等,分析在现有资源和技术条件系统下能否实现.主要包括
    • 风险分析
      风险分析主要分析在给定的约束条件下设计和实现系统的风险,在可行性分析时,风险分析的目的是找出风险,评价风险的大小,分析能否有效地控制和缓解风险
    • 资源分析
      资源分析主要论证是否具备系统开发所需的各类人员,软件,硬件等资源和相应的工作环境
    • 技术分析
      技术分析主要分析当前的科学技术是否支持系统开发的各项活动.在技术分析过程中,分析员收集系统的性能,可靠性,可维护性和生产率方面的信息,分析实现系统功能,性能所需的技术,方法,算法或过程,从技术角度分析可能存在的风险,以及这些技术问题对成本的影响
  • 法律可行性
    法律可行性主要研究系统开发过程中可能涉及到的合同,侵权,责任以及各种与法律相关抵触的问题.《中华人民共和国著作权法》与《计算机软件保护条例》是可行性分析的主要依据
• 生成系统规格说明
  完成以上任务后应生成一份系统规格说明,作为以后开发基于计算机的系统的依据.系统规格说明描述基于计算机的系统的功能,性能与约束条件,描述系统的输入与输出控制信息给出各系统元素的模型,进行可行性分析,最后给出成本估算以及进度安排计划.

需求工程

概述

需求工程是应用已证实有效的技术与方法开展需求分析,确定客户需求,帮助分析人员理解问题,评估可行性,协商合理的解决方案,无歧义地规约方案,确认规约以及将规约转换到可运行系统时的需求管理

需求工程是一个不断反复的需求定义,文档记录,需求演进的过程,并最终在验证的基础上冻结需求

需求工程可以分为六个阶段:需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理

需求获取

需求获取阶段分析人员通过与用户的交流,对现有系统的观察以及对任务进行分析,确定系统或产品范围的限制性描述,与系统或产品有关的人员及特征列表,系统的技术环境的描述,系统功能列表及应用于每个需求的领域限制,描述不同运行条件下系统或产品使用状况的应用场景等,为需求分析打下基础

软件需求

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，包括如下几个方面

• 功能需求：考虑系统要做什么，在何时做，在何时以及如何修改或升级等
• 性能需求：考虑软件开发的技术性指标，如存储容量限制，执行速度，响应时家那一集吞吐量
• 用户或人的因素：考虑用户的类型,例如用户对使用计算机的熟练程度,需要接受的训练,用户理解,使用系统的难度,用户错误操纵系统的可能性等
• 环境需求：考虑未来软件应用的环境,包括硬件和软件,对硬件设备的需求包括机型,外设,接口,地点,分布,温度,湿度,磁场干扰等.对软件的需求包括操作系统,网络,数据库等
• 界面需求：考虑来自其他系统的输入,到其他系统的输出,对数据格式的特殊规定,对数据存储介质的规定
• 文档需求：考虑需要哪些文档,文档针对的读者
• 数据需求：考虑输入,输出数据的格式,接受,发送数据的频率,数据的准确度与精度,数据流量,数据需保持的时间等
• 资源使用需求：考虑软件运行时所需要的数据,其他软件,内存空间等资源.软件开发,维护所需的人力,支撑软件,开发设备等
• 安全保密需求：考虑是否需要对访问系统或系统信息加以控制,隔离用户数据与方法,用户程序如何与其他程序和操作系统隔离以及系统备份要求等等
• 可靠性需求：考虑系统的可靠性技术,系统是否必须监测和隔离错误,出错后重启系统允许的时间等
• 软件成本消耗与开发进度需求：考虑开发是否有规定的时间表,软硬件投资有无限制等
• 其他非功能性需求：如采用某种开发模式,确定质量控制标准,里程碑和评审,验收标准,各种质量要求的优先级等,以及可维护性方面的需求

需求获取的方法即策略

• 建立顺畅的通信途径
  在用户,系统分析人员,软件开发小组,管理人员之间建立良好的沟通方式,以保证能顺利地对问题进行分析.
• 访谈与调查
  分析人员要从分析已经存在的同类的软件产品,或从行业标准,规则中提取初步需求,然后以个别访谈的形式或小组会议的形式开始与用户进行初步的沟通.除了进行面谈外,可以进行市场调查,了解市场对将开发的软件有什么样的要求,可以采取多种调查方式,指定调查提纲,向不同层次的用户发调查表,或访问用户和领域专家
• 观察用户操作流程
  到用户的实际工作环境中对用户的工作流程进行观察,了解用户的实际操作环境,操作过程与操作要求,对照用户提交的问题陈述,对用户需求可以有更全面细致的认识
• 成立联合小组
  采用一种叫FAST(facilitated application sepcification techniques)的技术用户与开发方成立一个联合小组,发挥各自的长处,共同负责项目的推进.FAST鼓励建立用户与开发者队伍之间的合作,共同工作来标识问题,提出解决方法的要素,商议不同的方法以及刻画初步的解决方案.
  它已经成为信息系统使用的主流技术,该技术为改善各种应用中的相互通信提供了潜在的可能.FAST团队由来自市场,软件与硬件工程以及制造方的代表组成,并选择外来人员作为协调者.该方法有一下基本原则
  • 在中立的地点举行由开发者和用户出席的会议
  • 建立准备和参与会议的规则
  • 建立一个足够正式的议程以便可以进行自由的交流
  • 由一个协调者（用户、开发者或其他人）来控制会议
  • 使用一种定义机制（工作表、图标等）
  • 目标是标识问题，提出解决方案的要素，商议不同的方法以及在有利于完成目标的氛围中刻画出初步的需求
• 用况
  用况常被称为用例，有以下几点
  • 执行者完成的主要任务或功能
  • 执行者将获取、生产或改变什么信息
  • 执行者是否必须通知系统关于外部环境的变化
  • 执行者希望从系统获得什么信息
  • 执行者是否希望被通知未预期的变化

需求分析

原则

• 必须能够表示和理解问题的信息域
• 必须能够定义软件将完成的功能
• 必须能够表示软件的行为
• 必须划分描述的数据,功能和行为的模型
• 分析过程应该从要素信息移向细节信息

信息域

信息域包括信息内容、信息流以及信息结构

信息内容

信息内容表示了单个数据和控制对象,目标软件所有处理的信息集合由它们构成

信息流

信息流表示了数据和控制在系统中流动时的变化方式,输入对象被变换为中间信息,然后进一步被变换为输出.

信息结构

信息结构表示了各种数据和控制项的内部组织形式

需求协商

需求很容易出现冲突,这就需要进行协商,讨论需求冲突,通常会议是解决冲突最快的方式

需求建模

创建模型是需求分析的重要活动.模型以一种简洁,准确,结构清晰的方式系统地描述了软件需求,从而帮助分析员理解系统的信息,功能与行为,模型还将成为软件设计的基础,为设计者提供软件要素的表示视图

需求规约

需求规约是分析任务的最终产物,通过建立完整的信息描述,详细的功能和行为描述,性能需求和设计约束的说明,合适的验收标准,给出对目标软件的各种需求.软件需求规约的框架主要分为5部分:

引言

引言陈述软件目标,在基于计算机的系统语境内进行描述,包括系统参考文献,整体描述,软件项目约束等

信息描述

信息描述给出软件必须解决的问题的详细描述,记录信息内容,信息流,信息结构.

功能描述

功能描述用以描述解决问题所需要的每个功能,其中包括为每个功能说明一个处理过程,叙述设计约束,叙述性能特征,用一个或多个图形来形象地表示软件的整体结构和软件功能与其他元素间的相互影响

行为描述

行为描述用以描述作为外部事件和内部产生的控制特征的软件操作

检验标准

检验标准描述检验系统成功的标志,即对系统进行什么样的测试,得到什么样的结果,就表示系统已经成功实现了.检验标准是确认测试的基础

参考书目

对所有和该软件相关文档的引用,包括其他的软件工程的文档,技术参考文献,厂商文献和标准.

附录

包含了规约的补充信息,表格数据,算法的详细描述,图表和其他材料

需求验证

需求验证的目的是检验是否能够反映用户的意愿,需要对需求文档中定义的需求执行多种检查,评审团队应该检查需求的有效性,一致性和作为一个整体的完备性.包括系统定义的目标是否与用户的要求一致,系统需求分析阶段提供的文档资料是否齐全,被开发的数据流与数据结构是否确定且充足,主要功能是否已包括在规定的软件范围之内,是否都已充分说明,设计的约束条件或限制条件是否符合实际,开发的技术风险是什么,是否详细制定了检验标准,它们能否对系统定义进行确认

需求管理

需求管理是一组用于帮助项目组在项目进展中的任何时候去标识,控制和跟踪需求的活动.在需求管理中,每个需求被赋予唯一的标识符,一旦标示出需求,就可以为需求建立跟踪表,每个跟踪表标示需求与其他需求或设计文档,代码,测试用例的不同版本间的关系.这些跟踪表可以用于需求跟踪,在整个开发过程中,进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性.确保所有的实现是以用户需求为基础,所有的输出符合用户需求,并且全面覆盖了用户需求

参考文献

[]: https://www.imooc.com/u/7934247/articles?page=3
[]: https://blog.csdn.net/lmq_buaa/article/details/88551374?utm_medium=distribute.pc_relevant.none-task-blog-baidujs_baidulandingword-0&spm=1001.2101.3001.4242