软件工程(一)_概述

软件工程概述

软件

定义： 计算机程序、方法、规则、相关的文档资料以及计算机上运行程序时所必须的数据

软件 = 程序 + 数据 + 文档

软件危机

定义： (IEEE)软件开发和维护过程中遇到的一系列问题，主要包括两个方面：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的有用软件

表现： 1. 开发成本和进度估计不准确 2. 开发产品与用户需求不匹配 3. 软件质量不行还不可维护 4. 软件没有适当的文档资料 5. 软件成本在整个计算机系统总成本比重上升 6. 开发速度跟不上需求速度 等

原因： 一方面与软件本身的特点有关，另一方面也与软件开发和维护方法不正确有关。 软件被发现错误后，维护时往往需要修改原本的设计 软件具有规模庞大的特点，对分工到组合、分析方法、设计方法、形式说明方法、版本控制等都需要可科学管理

软件开发不是个体劳动，更多的时候是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目

软件工程

定义： (IEEE)1. 把系统的、规范的、可度量的途径应用于软件按开发、运行和维护过程，也就是把工程应用于软件；2. 研究1.中提到的途径

特征： 1. 软件工程关注于大型系统的构造 2. 软件工程的中心课题是控制复杂性（问题本身的复杂性和协调的复杂性） 3. 软件开发需要考虑更新维护的便捷性 4. 软件开发需要寻求开发和维护的更好更有效的方法和工具 5. 有效地协同合作 6. 软件需要有效地支持它的用户 7. 软件工程往往是跨领域跨文化背景地去创造产品

基本原理： 1. 用分阶段的生命周期规划管理(分周期，制计划) 2. 坚持进行阶段审评(防止错误滚雪球) 3. 严格实行产品控制(实行基准配置管理，不随意修改软件) 4. 采用现代程序设计技术 5. 结果应能清楚地审查(量化工作进展情况) 6. 开发小组的人员应该少而精 7. 不断改进软件工程实践(采纳新软件技术，不断总结经验，优化软件开发)

软件工程方法学

通常把软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为泛型，软件工程方法学使用最广泛的是传统方法学和面向对象方法学

软件工程方法学包含3个要素：方法、工具和过程。方法：完成软件开发的各项任务的技术方法 工具： 为运用方法而提供的自动的或半自动的软件工程支撑环境（软件开发各阶段使用的软件工具集合） 过程：获得高质量的软件所需要完成的一系列任务的框架

• 传统方法学

  自顶而下顺序开发；采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务；面向行为或数据；前阶段是后阶段的前提和基础，后阶段是前阶段的具化和实现；

  问题抽象逻辑分析—>分阶段顺序开发

• 面向对象方法学

  对象：静态属性 + 动态行为

  面向对象将数据和行为紧密结合，用对象分解取代传统方法的功能分解，需求不明确或有变化的开发适合这种面向对象方法学

  对象是相对独立的主体，容易重复使用

软件生命周期

定义： 软件产品或系统的一系列活动的全周期

内容：

• 软件定义时期
  • 问题定义
  • 可行性分析
  • 需求分析
• 软件开发时期
  • 系统设计
    • 总体设计
    • 详细设计
  • 系统实现
    • 编码和单元测试：针对每个模块分工、编码和测试
    • 综合测试
      • 组装测试
      • 验收测试
      • 评审交付
• 软件维护时期
  • 改正性维护
  • 适应性维护
  • 完善性维护
  • 预防性维护

软件过程

软件生命周期中的一系列相关过程，完成一系列任务的框架和工作步骤，使用资源将输入转化为输出的活动所构成的系统

过程 > 活动 > 任务

软件过程 = 软件生命周期过程 != 软件开发过程

八种经典软件过程模型

• 瀑布模型

  传统瀑布模型：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-loqsEtX4-1592581859239)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/传统瀑布模型.png)]

  实际瀑布模型：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ixxFheD8-1592581859240)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/实际瀑布模型.png)]

  特点：

  1. 阶段间具有顺序性和依耐性

  2. 推迟实现的观点，充分分析和设计

     前阶段过早的考虑进行程序实现，往往造成大量返工，有时甚至导致灾难性后果，瀑布模型再编码之前设置了系统分析和系统设计的个阶段

  3. 质量保证的观点，文档 + 阶段性审查

     软件工程的基本目标是优质、高产，阶段性评审以便尽早发现问题，纠正错误，防止雪球滚大，实际的瀑布模型是带反馈环的

  优点：

  1. 强迫开发人员使用规范的方法，如机构化技术
  2. 严格规定了每个阶段必须提交的文档
  3. 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细检验

  瀑布模型基本上是一种文档驱动型的模型

  缺点：

  1. 不能很好地挖掘用户的需求

• 快速原型模型

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KnUkW4Gi-1592581859243)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/快速原型模型.png)]

  快速建立原型供用户来完善需求

  第一步，快速建立一个能反映用户主要需求的原型系统，用户根据原型系统完善用户需求；第二步：开发人员根据用户确定的需求撰写规格说明文档，在根据这份文档开发软件

  软件产品的开发基本上是线性顺序开发的，原因如下：

  1. 原型系统的每个功能都是用户认可的
  2. 通过建立原型已经规避了很多错误

  快速原型的本质是“快速”。尽可能快地建造原型系统，以加速软件开发工程，节约软件开发成本。原型的用途是获得用户的真正需求，一旦需求确定，原型将抛弃，所以原型系统的内部结构并不重要，重要的是快速构建出原型供用户修改需求

• 增量模型

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uVII1fdH-1592581859246)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/增量模型.png)]

  并发的增量模型(风险更大)：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ve8mLQU0-1592581859251)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/并发增量模型.png)]

  增量模型也称为渐增模型

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

  把软件产品分解成一系列的增量构件时，应该是构件的规模大小适中，当把新构件集成到现有软件中时，所形成的产品必须是可测试的

  分批地逐步向用户提交产品，整个软件产品被分解成许多增量构件，开发人员一个构件一个构件地向用户提交产品

  优点：能再较短时间内向用户提交可完成部分工作的产品；逐步增加产品功能可以降低用户的学习使用软件的成本

  难点：把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原本已开发出来的产品

  从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件

• 螺旋模型

  简化的螺旋模型：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R4LGwezR-1592581859254)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/简化的螺旋模型.png)]

  完整的螺旋模型：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c2we5EgB-1592581859255)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/完整的螺旋模型.png)]

  构件原型是一种能使某些类型的风险降至最低的方法，但对于某些类型的风险，原型方法也无能为力，如关键开发人员跳槽等

  螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险，可把它看作在每个阶段之前都增加了风险分析过程的快速原型模型

  完整的螺旋模型中，螺旋线每个周期对应一个开发阶段

  优点：对可选方案和约束条件的强调有利于已有软件的重用，有助于包软件质量看作软件开发的重要目标； 减少了过多测试(浪费资金)和测试不足(产品故障多)所带来的风险；最重要的是，螺旋模型的维护只是模型的另一个周期，在维护和开发之间并没有本质的区别

  螺旋模型主要适用于内部开发的大规模软件项目，这样才能当风险过大时方便地终止项目

  螺旋模型是风险驱动的

• 喷泉模型

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5nhiFocC-1592581859256)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/喷泉模型.png)]

  迭代是软件开发过程中普遍存在的一种内在属性，使用面向对象方法学开发软件时，工作重点应该放在生命周期中的分析阶段，喷泉模型是经典的面向对象的软件过程模型之一

  图中向下的箭头代表该阶段内的迭代，为了避免喷泉模型过于无序，应该把一个线性过程作为总目标，面向对象范型本身要求经常对开发活动进行迭代和求精

• Rational 统一过程(Ratuinal Unified Process, RUP)

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QjRZ4X7x-1592581859258)(https://raw.githubusercontent.com/MajicGao/BlogImg/master/blog-imgs/软件工程/RUP软件开发生命周期.png)]

  由Rational 软件公司提出的一种完整而且完美的软件过程

  初始阶段：建立业务模型，定义最终产品视图，确定项目范围

  精化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需求

  构建阶段：开发构件，集成产品，测试功能

  移交阶段：把开发出的产品提交用户使用

  6条最佳实践经验：

  1. 迭代式开发

     事实上，在整个软件开发过程中客户的需求会经常变化，迭代式开发允许在每次迭代过程中需求都可以变化，采用迭代式开发方法，每迭代过程以完成可执行版本结束，这不仅使最终用户可以不断介入和提反馈意见，而且开发人员也因随时有一个可交付的版本提高了士气

  2. 管理需求

     确定系统的需求，使用用例和脚本是捕获功能性需求的有效方法，RUP采用用例分析来捕获需求，并由它们驱动设计和实现

  3. 使用基于构件的体系结构

     所谓构件就是功能清晰的模块和子系统，RUP提供了使用现有的或新开的发的构件定义体系结构的系统化方法，从而有助于降低软件开发的复杂性，提高软件重用率

  4. 可视化建模(UML)

     所谓模型，就是为了理解事物而对事情作出的一种抽象，是对事物的一种无歧义的书面描述。RUP使用可视化建模语言UML建立软件系统的可视化模型，提高管理软件复杂性的能力

  5. 验证软件质量

     软件质量评估不再是事后型的或由单独小组进行的孤立活动，而是内建在贯穿于整个开发过程的、由全体成员参与的所有活动中

  6. 控制软件变更

     版本控制，有效地对软件修改进行控制、追踪和监控，以确保迭代开发的成功

  RUP软件开发生命周期中，包含9个核心工作流，其中前6个为核心过程工作流程，后3个为核心支持工作流程，并把生命周期划分为4个阶段

  RUP强调采用迭代和渐增的方式开发软件，在每个阶段结束前有一个里程碑来评估该阶段的目标是否已经实现，如果评估结果令人满意，则可开始下一阶段的工作

• 敏捷过程和极限编程

  敏捷过程声明：

  1. 个体和交互胜于过程和工具

     团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更重要。首先应致力于构件软件开发团队(包括成员和交互方式)，然后再根据需求为团队配置项目环境(包括过程和工具)

  2. 可以工作的软件胜过面面俱到的文档

     软件开发的主要目标是向用户提供可以工作的软件而不是文档，但完全没有文档也是一种灾难

  3. 客户合作胜于合同谈判

     客户通常不可能做到一次性地将需求完整准确地表达在合同中，开发团队与客户密切和合作，能指导开发团队与客户协同工作的合同才是好合同

  4. 响应变化胜过遵循计划

     软件过程应该有足够的能力计时响应变化，但没有计划的项目也会陷入混乱而失败

  这些声明只是对不同因素在保证软件开发成功方面所起到的大小做了比较，说一个因素更重要并不是说其他因素不重要，更不是说某个因素可以被其他因素所替代

  极限编程：

  极限编程(eXtreme Programming, XP)是敏捷过程的代表之一，其中极限二字是指将好的开发实践运用到极限

  极限编程广泛应用于需求模糊且经常变化的场景

  敏捷开发能够比较好的适应商业竞争环境下对小型项目提出的有限资源和有限时间的约束环境

• 微软过程

没有计划的项目也会陷入混乱而失败

这些声明只是对不同因素在保证软件开发成功方面所起到的大小做了比较，说一个因素更重要并不是说其他因素不重要，更不是说某个因素可以被其他因素所替代

极限编程：

极限编程(eXtreme Programming, XP)是敏捷过程的代表之一，其中极限二字是指将好的开发实践运用到极限

极限编程广泛应用于需求模糊且经常变化的场景

敏捷开发能够比较好的适应商业竞争环境下对小型项目提出的有限资源和有限时间的约束环境

• 微软过程