软件工程——笔记(一)

  • 时间:
  • 浏览:
  • 来源:互联网

软件工程

​ 知道计算机开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发和维护软件,把经过时间考验而证明正确的管理技术和当前嫩个够得到的最好的技术方法结合起来,经济的开发出高质量的软件并且有效的维护它。

包括了

  1. 软件工程概述
  2. 结构化分析、设计与实现
  3. 面向对象方法概述和分析
  4. 面向对象软件设计与实现
  5. 软件计划、组织和控制
  6. 软件维护和软件文档
  7. 形式化方法和软件重用

软件危机

计算机软件开发中的问题。软件数量急剧增加,硬件或操作系统更新通常导致程序修改。

导致问题:软件维护耗费资源,甚至导致软件不可维护

  1. 对然间开发成本和进度的估计常常很不准确
  2. 用户对已完成的软件系统不满意的现象经常发生
  3. 软件产品的质量往往靠不住
  4. 软件常常是不可维护的
  5. 软件常常没有适当的文档资料
  6. 软件成本在计算机系统总成本中的比例逐年上升
  7. 软件开发生产率提高的速度,跟不上硬件的发展速度也跟不上计算机应用迅速普及深入的趋势

软件危机产生的原因

  1. 软件本身的特点:
    • 软件不同于硬件,管理和控制软件 开发过程相当困难。
    • 软件在运行时不会因为使用时间过长而被“用坏”如果运行中发现了错误,很可能是遇到了一个在开发时期引入的在测试阶段没能检测出来的错误。
    • 软件不用于一般程序,他的一个显著特点是规模庞大,而且程序复杂性随着程序规模的增加呈指数上升。
    • 对用户要求没有完整准确的认识就匆忙着手编写程序。
    • 目前相当多的软件专业人员对软件开发和维护还有不少糊涂的概念。在实践过程中或多或少的采用了错误的方法和技术,这可能是使用软件问题发展成为软件危机的重要原因。
    • 错误的认识和做法主要表现为护士软件需求分析的重要性,认为软件开发就是写程序并且设法使之运行,轻视软件维护等。
  2. 软件开发和维护:
    • 只重视程序而忽视软件配置其余成分的糊涂概念。
    • 软件开发人员在定义时期没有正确的理解用户的需求,知道测试阶段或软件交付使用后才发现“已经完成的”软件其实完全不符合用户的需求。
    • 严重的问题是在软件开发的不同阶段进行修改需要付出的代价是很不相同的。

消除软件危机的途径

  1. 对软件有正确清楚的认知
  2. 认清什么是软件开发
  3. 开发使用更好的软件工具

软件统一过程

制定前景:按照计划管理,降低风险并跟踪相关问题,检验业务案例,设计组建架构,增量的构建和测试产品,定期评估结果,管理并控制变更,部署可用的产品,采用适合项目的过程


软件工程的十个常用领域

  1. 软件需求:软件需求表达了为解决某些真实世界的问题而示爱在产品上的要求和约束。
  2. 软件设计:软件设计是一个过程和这个过程的结果,此过程对一个系统或者组建定义架构、组建、接口以及其他的特征。
  3. 软件构建:软件构建指的是如何创建产生软件的详细步骤。
  4. 软件测试:软件测试是一个标识产品的缺陷和问题的活动,目的是为了评估和改进产品的品质。
  5. 软件维护:针对软件开发中对应的问题进行相应的修改或者演化。
  6. 软件配置管理:是一项跟踪和控制软件变更的活动。
  7. 软件工程过程:可以从生命周期过程和元层次来考虑。
  8. 软件工程工具和方法:工具是辅助,方法更高效。
  9. 软件质量:一组内在特征满足需求的程度。

软件的过程

软件生命周期的基本任务:

​ 软件生命周期由软件定义、软件开发、运行维护 三个阶段。软件定义周期又分为:问题定义,可行性研究,需求分析。软件开发时期分为了概要设计、详细设计、编码和单元测试、综合测试。运行维护时期:主要任务使软件持久的满足用户的需要。


瀑布模型(文档驱动)[面向模型]:

  1. 收集需求->分析->设计->编码->测试->维护。
  2. 阶段间具有顺序性和依赖性:如果后阶段出问题往往要追溯到前面阶段的问题重新开始。
  3. 推迟实现的观点
  4. 质量保证的观点:每个阶段都要提交文档,对文档进行分析评分等。

优点

  1. 可以强迫开发人员采用规范的方法。
  2. 严格的规定了每个阶段必须提交的文档。
  3. 要求每个极端交出的产品都必须经过质量保证小组的仔细检查。

缺点

正是因为文档驱动的,所以这也造就了它的缺点,可运行的软件交付给用户致歉,用户只能通过文档来了解产品是什么样子的。


快速原型模型

收集需求->快速原型->构建->移交部署,移交部署后又再收集需求。(软件产品和用户的交互比较好)

软件一旦交付之后,维护就开始了。根据用户使用过程中的反馈,可能需要返回到收集需求阶段。快速原型模型本质是“快速”,所以开发人员应该尽可能快的建造出原型系统,加快软件的开发过程,节约软件开发成本。


增量模型

也叫做渐增模型。使用增量模型开发软件时,把软件产品作为一系列的增量构建来设计、编码、集成和测试。每个构建由多个相互作用的模块构建成,并且能够完成特定的功能。

步骤为:不断地 分析-> 设计-> 编码-> 测试。

对比和区别快速原型模型:快速原型是一次性交付给用户,再多次修改,增量模型则是分批次的交付。

优点

  1. 能在较短的时间内向用户提交可完成一些有用的产品。
  2. 逐步增加产品功能可以使用户有充裕的时间学习和适应新的产品,从而减少一个全新的软件可能给用户组织带来的冲击。

缺点

  1. 在把每个新的增量构建继承到现有的软件体系结构中时,必须破坏原来已经开发的产品。
  2. 软件体系结构必须是开放的,从长远看的话也拥有真正的课维护性的优势。

螺旋模型(风险驱动)

使用原型及其他的方法来尽量减低风险(可以它看作是每个阶段都加入了风险分析过程的快速原型模型)

优点 :对于可选方案和约束条件的强调有利于已有软件的重用,也助于把软件质量作为软件开发的一个重要目标;减少了过多的测试(浪费资金)或者测试不足(产品故障多)所带来的风险;更重要的是,在螺旋模型中维护知识模型的另一个周期,在维护和开发之间并没有本质的区别。

缺点:除非软件开发人员具有丰富的风险评估经验和这方面的专门的知识,否则将出现真正的风险:当项目实际上正在走向灾难时,开发人员可能还认为一切正常。


喷泉模型

喷泉体现的是面向对象的软件开发过程中的迭代和无缝的特性,喷泉模型是典型的面向对象声明周期模型。


能力成熟模型:🌟(并不是软件生命周期模型)

主要包括以下几个部分:

  • 成熟度等级
  • 过程能力
  • 关键过程域
  • 目标
  • 公共特性
  • 关键实践

敏捷开发和极限编程

极限编程是敏捷过程中最有名的一个,其名字中的极限二字含义是指把好的开发实践运用到极致。目前,极限编程已经成为了一种典型的开发方法,广泛应用于需求模糊且经常改变的场合。

敏捷开发:简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

本文链接http://www.dzjqx.cn/news/show-617029.html