软件工程背景知识及过程模型

一、背景知识:

软件开发的基本过程:

需求定义→软件设计→软件实现→软件测试→软件维护

软件的定义:

软件=程序+数据+文档

程序:可以按照设计好的功能和性能要求执行的指令序列

数据:程序能正确处理信息的数据结构

文档:与程序的开发、维护、使用有关的图文资料

软件的特点:

  1. 包含个人因素的大规模知识型工作
  2. 有工具辅助的软件开发也尚未实现自动化(即无法像硬件加工一样,机械组装已有部件,软件开发还未达到组装已有模块的程度)
  3. 对开发和运行的计算机软硬件环境具有依赖性
  4. 需求往往在变更,开发进度难估算
  5. 软件测试困难,覆盖所有路径的测试难实现。软件测试只能证明软件中有缺陷,不能证明软件中没有缺陷。
  6. 软件不会损耗,(参考硬件的磨损和老化),软件维护不再具有经济性时,软件即被淘汰

软件危机:

  • 1965年——1985年,20世纪60——80年代
  • 于1968年提出
  • 催生了软件工程这一学科
  • 没有化解软件危机的灵丹妙药,已知的技术和方法都是进一步改进

SWEBOK(软件工程知识体系指南)

PDCA环(戴明环):

  

二、软件过程:

以质量为中心,以软件工程,方法,工具为三要素。其中软件过程是基础,是联系各层的桥梁,工具为过程和方法提供支持。

软件过程的定义:软件过程定义了软件开发中的一系列活动,所以过程都具有下列活动:

  1. 沟通
  2. 建模
  3. 计划
  4. 构造
  5. 部署
  6. 项目管理(贯穿于以上所有活动)

软件生命周期:

  1. 定义时期:问题定义,可行性研究,需求分析
  2. 开发时期:概要设计,详细设计,编码,测试
  3. 运行/维护时期

软件过程模型:

  • 模型不是过程的直接描述,而是过程的抽象。可以用于解释软件产品不同的开发方法。
  • 从项目需求定义到运行维护为止,跨越整个生命周期的过程,活动和任务的结构框架。
  • 也被称为:软件生命周期模型,软件开发模型,软件工程范型

瀑布模型:

  • 20世纪80年代之前被广泛使用,因此被称为经典的生命周期模型。
  • 线性模型:软件开发过程与生命周期是一致的,规定了各项工程活动的自上而下,逐级下落的次序。
  • 以文档为驱动

传统的瀑布模型:

  • 各个阶段都按顺序执行
  • 每个阶段完成规定的文档
  • 每个阶段结束有一个验证环节,只有通过验证才能进入下一个阶段
  1. 阶段间具有顺序性和依赖性:前一阶段的输出文档就是后一阶段的输入文档
  2. 推迟实现的观点(重要思想):区分开逻辑设计和物理设计,推迟程序的物理实现
  3. 质量保证的观点:每个阶段必须完成规定的文档,并在阶段结束前进行审核

实际的(带反馈的)瀑布模型:

若后面的阶段发现前面阶段的错误,则返回前面阶段进行修改。

瀑布模型的优缺点:

  • 每个阶段交出的作品都是经过验证的,每个阶段都有文档
  • 能较好的与其它过程模型结合
  • 不够灵活:下一阶段开始前,当前阶段的结果需固定下来
  • 整体性太强:分析阶段出现任何失误,交互用户后才能发现,增加了开发的风险
  • 严格文档驱动,较为繁琐
  • 开发早期投入大量成本,难以应对用户需求变更

瀑布模型适用于:需求很明确且将来没有太大改变的情况。大型项目中一些部分的开发。


演化模型(分为原型模型和并行开发模型):

首先实现软件最核心,最重要的功能,待用户进一步了解软件后再实现细节。

相比瀑布模型能更高效地生产出符合要求的系统,灵活面对客户需求变更。

小型和中型系统:演化模型

大型系统:混合瀑布模型和演化模型(采用演化模型难以建立稳定的系统架构,不利于团队工作整合)

原型模型:

快速建立起可以在计算机上运行的程序,是最终产品的子集。

与用户确定下原型以后,再开始完整的开发过程。

原型确定后,下面的开发过程基本不带反馈。

原型模型的优缺点:

  • 有助于了解用户的真正需求
  • 不会因为需求规格说明文档的错误进行大规模返工
  • 开发人员在实现原型系统学到了东西,后续出错率降低
  • 为了快速开发出原型,开发人员可能不会长远考虑,而降低质量,放弃部分需求

并行开发模型(并发模型):

所有活动同时存在但是处于不同状态。


增量过程模型(分为增量模型,RAD模型,螺旋模型):

非整体开发的模型,从部分需求出发,建立一个不完整的系统——测试——添加增量。

增量模型:

增量:小而可用的软件

  • 增量模型与原型模型的不同在于:每个增量都是可运行的产品,能完成特定功能。
  • 每个增量的开发可以采用瀑布模型或快速原型模型。
  • 第一个增量通常是核心产品。
  • 在前面增量的基础上开发后面的增量。
  • 一个增量部署后,进入下一次迭代,直到出现最终产品。
  • XP极限编程:基于小增量的开发和交付

增量模型的优缺点:

  • 无需完整需求,只要一个增量包,开发即可进行。
  • 项目初始阶段无需大量人力资源,被认可后才投入。
  • 不能在ddl前完成项目,核心增量产品也能交付。
  • 很难根据需求给出大小合适的增量。
  • 加入新增量不能破坏已开发出的产品。
  • 需要比瀑布和原型模型更精心的设计。

RAD(Rapid Application Development)快速应用开发模型:

  • 强调短暂的开发周期,瀑布模型的“高速”变体
  • 主要用于信息系统的开发
  • 包括业务建模,数据建模,过程建模
  • 需要足够的人力资源
  • 并非所有系统都适合,不能合理模块化和技术风险高的系统都不适合

螺旋模型:

结合了瀑布模型和原型模型,加入了两种模型都没有的风险分析。

强调风险管理:适用于大型系统的开发。

基本思想:使用原型及其它方法来尽量降低风险。

理解为:在每个阶段都加入风险分析的快速原型模型

特点:

  • 能应对开发过程中的各种变化。
  • 仅适用于内部项目,不能用于合同性的软件开发,因为过程中有风险评估。
  • 风险驱动:要求开发人员具有丰富的风险评估经验和专业知识。
  • 只适用于大型软件的开发。

基于构件的模型:

  • 构件(也称组件):支持软件重用(复用)Software Reuse
  • 以重用为导向,以大量可用的组件及一些集成框架为基础。
  • 根据需求规格搜索可重用的组件,通常情况下没有,则对组件加以修改或构造新的组件,再将组件进行开发和集成。

敏捷过程模型:

基本原理和开发过程的结合。

如何选择过程模型?

  • 各种过程模型并不互相排斥,在开发中通常一起使用。
  • 软件过程决定了软件产品的质量。
  • 可根据实际创造新的模型。

软件开发中的两种倾向:以产品为中心/以过程为中心(以过程为中心更能生产高质量的产品)


能力成熟度模型:

软件过程成熟度:1.角色与职责 2.处理变更的方式 3.对发生问题的反应 4.可信性 5.对工作人员的奖励 6.预见性

CMM(Capibility Maturity Model):能力成熟度模型:

  • 最早提出时,它指的是软件过程能力成熟度模型。
  • 按照成熟度划分为5个等级。1级最低,5级最高。

SEI(Software Engineering Institute):软件工程研究所(发布CMM,CMMI)

CMMI(Capibility Maturity Model Integration):能力成熟度模型集成

CMMI 1.2:当前实施的有效版本

  • 将成熟度分为5个等级,只有达到某个等级后,才能进入下一等级。
  • 只定义要达到什么目标,不定义如何达到。
  1. 初始级:依赖于有能力的人
  2. 可重复级:有基本的项目管理
  3. 已定义级:过程标准化
  4. 量化管理级:收集分析数据,来支持决策。制定量化目标,以此作为管理过程的标准
  5. 优化级:持续地改进过程

过程域(Process Area PA):

CMMI每个等级都规定了过程域。即若干个值得重视的软件过程。

(0)

相关推荐