每到期末我就会发病,对于我这种不上课的人来说,复习是真的难受,但又不得不复习。内心啊!快点强大起来吧!

软件

软件的定义

software = program + data +document

程序就是按照事先设计的功能和性能执行的指令序列

数据就是使程序能正常操作信息的数据结构

文档就是与软件开发、维护、使用有关的图文资料

软件的特点

  • 软件是无形的,逻辑的,具有抽象性

  • 软件没有明显的制作过程,且副本制作简单

  • 软件无磨损,无老化

    软件虽然无磨损,但是会退化,失效

    image-20200730201255994

软件危机

什么是软件危机?

软件危机指软件在开发维护过程中遇到的一系列严重问题

软件危机的主要表现

主要表现在开发和维护两方面

如何开发软件,以应对日益增长的软件需求

如何维护数量不断膨胀的已有软件

  • 软件不符合用户的需求

  • 软件质量差

  • 软件文档资料不完整和不合格

    从用户角度看,不符合需求,质量差,难以学习使用

  • 软件可维护性差

  • 软件开发成本和进度估计不准确

    从开发者角度看,维护难,开发过程超出预期

  • 软件开发生产率低,不符合客观需求

  • 软件开发成本逐年上升

    从企业角度看,生产率低,成本高

产生软件危机的原因

宏观上:

  • 缺乏总体考虑,没有软件工程学或系统工程学的思想

  • 业务了解支离破碎,需求分析不准确

从软件开发的角度

  • 企业依赖激情指挥,企业管理缺少科学化、规范化,不能成功地应用“死板”的软件,业务需要规范化、流程化
  • 企业信息化程度和计算机应用水平低,无法准确描述业务需求
  • 企业一把手不重视信息管理
  • 缺少相互交流,没法将业务详尽描述到有基本生活常识的人都能理解的程度

从企业的角度

微观上:

  • 软件规模大,开发维护相当困难

  • 开发者有一定开发经验,但存在不少观点错误,没有完全执行工程化方法

  • 没法与用户即时沟通,没法了解用户的实际需求

  • 没有统一的软件质量管理规范

  • 不能根据环境的变化随时对产品进行改正

从软件本身的特性来看:

  • 软件是逻辑的
  • 软件规模较大,开发和维护困难

从开发和维护的角度来看,使用了不正确的开发和维护方法:

  • 忽视了软件定义时期的重要性,尤其是忽视了需求分析的重要性
  • 误以为开发软件只需要提交能运行的程序就好
  • 轻视了软件维护

各个资料关于这部分的说法都有些差别

软件工程

何谓软件工程?

软件工程的概念

软件工程即指导计算机软件开发和维护的一门工程学科,分为管理和技术两方面

软件工程的本质特性

  • 软件工程关注大型程序的够造
  • 软件工程的中心课题是控制复杂性
  • 软件经常变化
  • 开发软件的效率非常重要
  • 和谐地合作是开发软件的关键
  • 软件必须有效地支持它的用户
  • 在软件工程领域通常由具有一种文化背景的人为另一种文化背景的人创造产品

软件工程的基本原理

  • 用分阶段的生命周期计划严格管理

  • 坚持每个阶段进行评审

    检查错误,防止错误进入下一阶段并扩大

  • 实行严格的产品控制

    以应对需求的实时变化

  • 使用现代的程序设计技术

    提高开发维护效率和质量

  • 结果应能清楚地审查

    提高可见性,方便管理,制定开发组织地责任和产品标准

  • 开发团队小而精

  • 承认不断改进软件工程实践的重要性

软件工程方法学

软件工程方法学三要素

方法、工具、过程

方法指解决软件开发过程中各种问题的技术手段

工具为方法提供软件环境支持

过程是为了获得高质量软件所需要完成的一系列任务的框架,他规定了完成各项任务的工作步骤

传统方法学、面向对象方法学各自的优势

传统方法方法学(生命周期方法学、结构化泛型):

  • 采用结构化技术

  • 把软件生命周期分为若干个阶段,每个阶段开始和结束都有严格的标准,需要审查

    优点:

    • 把生命周期分为若干阶段,降低了软件开发的难度
    • 每个阶段进行审查,提高了软件质量,增强了可维护性

    问题:

    • 对于规模庞大的软件开发项目或需求频发变更的项目,传统方法学往往难以成功

      原因:传统方法学将数据和操作进行了割裂

面向对象方法学:

  • 以数据为主线,将数据和对数据的操作紧密地结合起来的方法

  • 四个要点:对象+类+继承+通信

  • 尽量模拟人类习惯的思维方式

    优点:

    • 降低了软件产品的复杂性

    • 增强了软件产品的可理解性

    • 简化了开发和维护的工作

    • 促进了软件重用

软件工程涉及的人员角色

客户:花钱开发软件系统的公司、组织或个人

开发者:为客户构建软件系统的公司、组织或个人

用户:使用该软件系统的公司、组织或个人

软件工程与其他学科的关系

计算机学科:构建模型

数学学科:分析算法

工程学科:用于制定规范、明确泛型、评估成本、确定权衡

管理学科:进度、资源、质量、成本等的管理

软件生命周期

软件生命周期由软件定义、软件开发、运行维护三个时期组成

软件定义:

  • 问题定义阶段
  • 可行性分析
  • 需求分析

软件开发:

  • 总体设计
  • 详细设计
  • 编码/单元测试
  • 综合测试

运行维护:

  • 改正性维护

改正错误

  • 适应性维护

适应不同环境

  • 完善性维护

根据用户需求,扩充功能使其完善

  • 预防性维护

软件开发团队的成员

需求分析师

弄清客户想要什么

设计师

根据需求设计系统

程序员

将系统用代码实现

测试员

根据需求测试系统

培训人员

教用户使用系统

维护人员

可能是以上任何一种来担任

文档库管理员

组织和维护项目文档、记录软件的开发过程

配置管理小组

维护变更、控制变更、确保变更正确实现、报告变更

软件过程

何为软件过程?

软件过程是为了获得高质量软件所需要完成的一系列任务的框架,他规定了完成各项任务的工作步骤

ISO 9000对过程的定义:

使用资源将输入转为输出的活动所构成的系统

经典软件过程模型(基本生命周期模型)

瀑布模型(文档驱动)

20世纪80年代之前,瀑布模型一直是唯一被广泛采用的生命周期模型,现在它仍是软件工程中应用的最广泛的过程模型。

image-20200731200056248_传统的瀑布模型定义和实际的瀑布模型定义_(各个环节带有反馈,发现前一阶段的错误要返回前一阶段)

瀑布模型的特点:文档驱动,关注文档和工作产品

  • 强调阶段性和顺序性

    必须等前一阶段完成后才开始下一阶段,前一阶段的文档输出是下一阶段的输入

  • 推迟实现的观点

    注重系统和逻辑设计,尽可能晚的物理实现

  • 质量保证的观点

    每个阶段结束时对文档进行评审

瀑布模型的优点:

  • 可强迫开发人员采用规范的方法
  • 严格规定了每阶段要提交的文档
  • 每个阶段交出的所有产品都有质量保证小组验证
  • 对文档的约束,使软件维护变得容易一些,且能降低维护预算

瀑布模型的缺点:

  • 用户不经过实践就提出完整准确的需求,在许多情况下是不切实际的

  • 开发时间长,可运行版本后期才能拿到

  • 软件开发本身是一个非线性的过程,人为地加以线性化,不符合实际情况

  • 完全文档驱动,在软件交付之前,用户只能通过文档来了解产品,静态的纸面规格说明,很难全面正确地认识动态的软件产品,很可能导致最终开发出的软件不能满足用户的需求

V模型(活动驱动)

image-20200801093429866V模型定义

V模型是瀑布模型的改进,强调测试活动分析和设计之间的关联,关注点是软件开发各阶段的活动和正确性,以活动驱动

单元和集成测试→校验(verify)程序设计

系统测试→校验(verify)系统设计

验证设计是否正确,是否可以正常工作,检查软件质量

验收测试→确认(validate)需求

确认是否完成了所有的用户需求

V模型的改良之处与存在的问题

  • V模型本质是把瀑布模型隐含的迭代过程明确出来,使开发和验证活动的相关性更加明显

  • V模型使抽象等级的概念也更加明显:所有从需求到实现部分的活动关注的是建立更多的系统详细表述,而所有从实现到交付运行的活动关注的是对系统的验证和确认

    需求→实现→运行交付

    →关注系统详细表述

    →关注系统的验证和确认

  • 和瀑布模型一样,都是理想化的模型,难以应对需求的变化

原型/快速原型模型(原型驱动)

原型:一个可以实际运行的模型,功能上可看作最终产品的一个子集(展示了目标系统的关键功能)

image-20200801095919186快速原型模型的定义

※快速原型相比于实际的瀑布模型是不带反馈环,线性执行,将需求分析用原型模型来替代

快速原型的优势:

  • 快速原型模型是不带反馈环的,软件产品的开发基本上是线性顺序进行的:原因如下

    • 原型系统已经通过与用户交互而得到验证
    • 开发人员通过建立原型系统已经学到了许多东西
  • 利用原型能统一客户和开发人员对软件项目需求的理解,有助于需求的定义和确认

    利用原型可以帮助需求分析,统一客户和开发人员对需求的理解

  • 可以考虑结合瀑布模型,二者互补性强。用快速原型做为需求分析的一种技术,用于收集客户的真实需求,然后把客户满意了的原型再作为瀑布模型的输入,从而达到优势互补

快速原型需要注意的问题:

  • 由于要求能够快速建立可供运行的模型,原型不可能象最终产品一样面面俱到
  • 客户:不可把原型当作软件的正式运行版本
  • 开发人员:同上。还必须牢记原型中没有考虑质量因素的部分
  • 使用前要与用户达成一致:原型只是模型而已

螺旋模型(风险驱动)

image-20200801100843193螺旋模型的定义

软件项目中的风险:

  • 人员

    关键人员突然跳槽,或者猝死

  • 硬件设备

    罢工抗议

  • 项目的生存能力

    项目拉跨,直接被砍

螺旋模型的基本思想是通过原型和其他方法来尽量降低风险,螺旋模型是风险驱动的

image-20200801102536887完整的螺旋模型

制定计划→风险分析→实施工程→客户评估,如此螺旋

螺旋模型的优点:

  • 由客户对阶段性产品做出评审,这对保证软件产品质量十分有利

  • 引入风险分析,增强了测试活动的确定性

  • 外层相当于维护,把维护和开发放在了同等地位重视

螺旋模型的缺点:

  • 主要适合内部软件开发,否则风险分析必须在签订合同前完成,或者争取客户的最大理解
  • 只适合大型软件项目的开发,否则,每个阶段的风险分析将占用很大一部分资源,增加成本
  • 很考验开发人员的风险分析能力,否则模型将退化成瀑布模型,甚至更糟

现代软件过程模型

RUP软件开发生命周期

RUP的4大阶段、9种工作流

image-20200801105009316RUP软件开发生命周期,横轴表示阶段,纵轴表示工作流

四大阶段及大致目标:

  • 初始

    建立业务模型,定义最终产品视图,并确定项目的范围

  • 精化

    设计并确定系统的体系结构,制定项目计划,确定资源需求

  • 构建

    开发出所有构建和应用程序,把它们集成为客户需要的产品,并详尽地测试所有功能

  • 移交

    产品提交给用户使用

九种工作流:

  • 业务建模

    深入了解使用目标系统的机构及其商业运作,评估系统对使用它的机构的影响

  • 需求

    捕获客户的需求,并且使开发人员和用户达成对需求描述的共识

  • 分析与设计

    把需求分析的结果转化为分析模型与设计模型

  • 实现

    把设计模型转化成实现结果

  • 测试

    检查各个子系统的交互与集成,校验与确认

  • 部署

    成功地生成目标系统的可运行版本,并把软件移交给最终用户

  • 配置与变更管理

    跟踪和维护软件开发过程中产生的所有制品的完整性和一致性

  • 项目管理

    为项目提供管理框架,为软件开发项目制定计划、人员配备、执行和监控等方面的实用准则,并为风险管理提供框架

  • 环境

    向软件开发机构提供软件开发环境,包括过程管理和工具支持

RUP迭代式开发,实际上RUP重复一系列组成软件生命周期的循环,每次循环都经历一个完整的生命周期,每次循环结束都向用户交付产品的一个可运行版本。同时每个生命周期的每一个阶段又细分为一次或多次迭代,每个阶段结束前有一个里程碑来评估该阶段的目标是否已经实现。

在不同的迭代过程中是以不同的工作重点和强度对这些核心工作流程进行访问的

敏捷过程

敏捷过程的价值观

敏捷软件开发宣言

  • 个体和交互胜过过程和工具
  • 可以工作的软件胜过面面俱到的文档
  • 客户合作胜过合同谈判
  • 响应变化胜过遵循计划

敏捷过程的原则

  • 我们最优先要做的是通过尽早的,持续的交付有价值的软件来使客户满意
  • 即使到了开发的后期,也欢迎改变需求.敏捷过程利用变化来为客户创造竞争优势
  • 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好
  • 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作
  • 围绕被激励起来的个人来构建项目.给他们提供所需要的环境和支持,并且信任他们能够完成工作
  • 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈
  • 工作的软件是首要的进度度量标准
  • 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
  • 不断地关注优秀的技能和好的设计会增强敏捷能力
  • 简单是根本的
  • 最好的架构、需求和设计出自于自组织的团队
  • 每隔一段时间,团队就会在如何才能更有效地工作方面进行反省,然后相应地对自己的行为进行调整

极限编程(eXtreme Programming,XP)的特点

  • 对变化和不确定性反应更快速,更敏捷
  • 快速的同时保持可持续的开发速度

极限编程的有效实践

  • 客户作为开发团队的成员

  • 使用用户素材

  • 短交付周期(每两周完成一次迭代)

  • 验收测试

  • 结对编程

  • 测试驱动的开发

  • 集体所有(程序代码属于整个开发小组,每个成员都有修改代码的权利,都对全部代码负责)

  • 持续集成(一日内多次集成,不断回归测试)

  • 可持续的开发速度(周工作时间不超过40小时,连续加班不超过两周)

  • 开放的工作空间

  • 及时调整计划

  • 重构

  • 使用隐喻(隐喻是把整个系统联系在一起的全局视图,描述系统如何运做,如何把新功能加入到系统中)

微软过程

微软软件生命周期

image-20200801115701903微软软件生命周期

微软过程的不足

  • 方法工具和产品等方面的论述不如RUP和XP全面

  • 人们对它的某些准则本身也有不同意见