软件工程相关-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_50379618/article/details/142377278

一、软件

1.1软件定义

在计算机系统支持下，能够完成特定功能和性能的程序、数据和相关的文档，程序仅仅占开发的10%-20%

1.2软件危机

软件危机是指在计算机软件开发和维护过程中所遇到的一系列严重问题，包含两个方面
①如何开发软件
②如何维护软件

1.3软件危机的表现

①计划不准确:对软件开发成本和进度的估计常常很不准确

②用户不满意:用户对“已完成”软件系统不满意
③质量不可靠:软件产品的质量往往靠不住
④系统难维护:软件常常是不可维护
⑤文档不适合:软件通常没有适当的文档资料
⑥成本上升:软件成本所占比例逐年上升
⑦开发效率低:软件开发生产率低，软件需求增长得不到满足。

1.4产生软件危机的原因

(1)与软件本身的特点有关
①软件缺乏可见性
②可能存在测试阶段没能检测出来的错误③软件维护通常意味着改正或修改原来的设计，使得软件较难维护
④软件规模庞大，随着规模增加复杂性呈指数上升

(2)软件开发维护方法不正确

①忽视软件需求分析重要性，匆忙着手编程(主因)

②程序只是完整的软件产品的一个组成部分

③需要清除只重视程序而忽视软件配置其余成分的错误观念

④轻视维护是最大错误

1.5消除软件危机的方法

①对计算软件有正确的认识
②积累有效的原理、概念、技术和方法

③积极开发和使用计算机辅助开发软件

④探索更好的管理措施对开发过程进行管控

软件危机-------诞生------------>软件工程---------目的---------->解决软件危机

二、软件工程

2.1 软件工程定义

软件工程是指导计算机软件开发和维护的工程学科
①它采用工程的概念、原理、技术和方法来开发和维护软件;

②它将管理技术与当前经过时间考验的而证明是正确的技术方法结合起来，

③它强调使用生存周期方法学和结构化技术;

2.2 软件工程基本原理

①用分阶段的软件生命周期计划进行严格的质量管理、
②坚持进行阶段评审。
③实行严格的产品控制。
④采用现代程序设计技术。
⑤软件工程结果应能清楚地审查
⑥开发小组的人员应该少而精。
⑦承认不断改进软件工程实践的必要性

2.3 软件方法学(范型)

软件生命周期中使用的一整套技术方法的集合称为软件工程方法学，

2.3.1、三要素:方法（怎么做）、工具（自动化或者半自动化的支撑环境）和过程（任务框架）。

2.3.2、分类:
(1)结构化方法学(结构化分析SA，结构化设计SD，结构化程序设计SP)
①采用结构化技术
②把软件生命周期的全过程依次划分为若干个阶段

③每一阶段的开始和结束都有严格标准
④每一阶段结束前需严格审查和复审

(2)面向对象方法学
(面向对象分析OOA，面向对象设计OOD面向对象程序设计OOP)①用对象分解取代传统方法学的功能分解
②把所有对象都划分成类
③按照父类和子类的关系，把若干相关类组成一个层级结构的系统

④对象间仅通过发送消息互相联系

2.4 软件生命周期(掌握)

一、定义
软件生命周期是指软件产品或软件系统从设计、投入使用到被淘汰的全过程。
3时期，8阶段

2.4.1、软件定义时期
①问题定义:弄清楚客户要解决什么问题

②可行性研究:确定软件开发的可行性，输出《可行性研究报告》

③需求分析:明确客户需求，输出标准化《需求规格说明书》

2.4.2、软件开发时期
①总体设计(概要设计):设计软件结构，确定功能模块及模块间关系，输出《总体设计说明书》

②详细设计:详细设计每个模块，确定所需算法和数据结构，输出《详细设计说明书》

③编码和单元测试:将详细设计用语言实现，并测试每个模块，输出软件产品

④综合测试:编写详细测试计划并严格按计划进行

2.4.3、软件维护时期
①运行和维护

2.5 软件开发模型(记忆)

2.5.1 软件过程

在整个软件生命周期的系统开发、运行和维护过程所实施的全部过程、活动和任务的结构框架。通常用软件过程模型来描述软件过程。

2.5.2、软件过程模型

传统软件过程模型1
①瀑布模型(线性顺序模型)②原型模型 ③増量型 ④螺旋型⑤喷泉模型
2、现代软件过程模型
①Rational统一过程(UML)②敏捷过程与极限编程 ③微软过程④基于构件的开发模型

2.5.3 传统软件模型

2.5.3.1、瀑布模型

将软件生命周期的各项活动规定为按固定顺序而连接的若干工作阶段，形如瀑布流水，最终得到的软件产品。
瀑布模型是以文档为驱动、适合于软件需求确定的软件项目的开发

1、特点
①阶段间具有顺序性和依赖性，自上而下，相互衔接，前阶段的输出文本是后一阶段的输入文本
②推迟实现的观点:编码前的分析和设计各个阶段主要考虑逻辑模型不涉及具体实现

③质量保证的观点:每个阶段必须完成规定的文档，每个阶段结束都要对所完成文档进行评审，发现问题，保证质量。

2、优点
①强迫开发人员采用规范化的方法
②严格地规定了每个阶段必须提交的文档，
③要求每个阶段交出的所有产品都必须是经过验证的。
3、缺点
①仅通过静态规格说明，无法及时验证需求是否正确、完整

②几乎完全依赖书面说明，很易导致软件产品不能真正满足用户需求

③不支持产品演化，缺乏灵活性，使软件产品难以维护。

2.5.3.2、增量迭代模型

1、特点

增量迭代模型需要在项目早期就确定项目的目标和范围，因此项目需求要比较成熟和稳定，不能出现数量太多的不确定性和影响太大的需求变更。少量的不确定性和影响不大的需求变更可以通过迭代的方式加以有效解决，即在前导迭代中明确后续选代的不确定需求、在后续迭代中完成前导迭代的需求变更。
增量迭代模型中每个选代的增量需求相对独立，可以被开发为产品的独立部分交付给用户。不同的增量迭代形成渐进交付和并行开发的效果。在实际开发中，第一个迭代完成的往往是产品的核心部分，满足基本需求，但是很多附带特性还需要后续迭代完成。增量需求是增量迭代模型进行迭代规划、开发活动组织和控制的主要依据，因此它是“需求驱动”(requirement-driven)的。

2、优点:
①迭代式开发更加符合软件开发的实践情况，具有更好的适用性;并行开发可以帮助缩短软件产品的开发时间;
②渐进交付可以加强用户反馈，降低开发风险。

3、缺点:
①由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
②增量迭代模型需要一个完备、清晰的项目前景和范围以进行并行开发规划，但是在一
些不稳定的领域，不确定性太多或者需求变化非常频繁，很难在项目开始就确定前景和范围。

因为能够很好地适用于大规模软件系统的开发，所以增量迭代模型在实践中有着广泛的应用，尤其是比较成熟和稳定的领域。

2.5.3.3、演化模型

1、特点

演化模型与增量迭代模型相比，相同点是它们都使用迭代式组织开发活动并且都适合大规模软件开发，不同点是增量选代模型适用于比较成熟、稳定的领域，而演化模型主要用在需求变更比较频繁或不确定性较多的领域。

演化模型将软件开发活动组织为多个迭代、并行的瀑布式开发活动在初始开发迭代中，主要任务是澄清和明确系统的核心需求，建立和交付核心系统。在得到核心系统后，用户在使用中发现变更需求、澄清不确定需求，并反馈给开发人员。软件开发人员根据用户反馈规划后续选代，精化和增强系统。所以，演化模型每次迭代的需求不是独立的，设计和实现工作也是在前导迭代基础上进行修改和扩展。演化模型的多个迭代联合起来可以实现渐进交付和并行开发的效果

2、优点:
①使用了迭代式开发，具有更好的适用性，尤其是其演化式迭代安排能够适用于那些需求变更比较频繁或不确定性较多的软件系统的开发;
②并行开发可以帮助缩短软件产品的开发时间;
③渐进交付可以加强用户反馈，降低开发风险，

3、缺点:
①无法在项目早期阶段确定项目范围，所以项目的整体计划、进度调度，尤其是商务协商事宜无法准确把握;
②后续迭代的开发活动是在前导迭代基础上进行修改和扩展的，这容易让后续选代忽略分析与设计工作，蜕变为构建-修复方式。

在实践中，不稳定领域的大规模软件系统开发适合使用演化模型进行组织。

2.5.3.4、原型模型

1、特点

原型方法是软件开发中广泛使用的方法，不论是探索需求、构建体系结构，还是试验技术细节，都会使用原型方法。但使用原型方法的软件开发活动并不就是原型模型的过程组织方式，关键要看原型方法在软件开发活动组织中的定位。
要理解原型模型就要区分原型的不同类型。[Nauman1982]认为:“原型是一个系统，它内化(capture)了一个更迟系统(latersystem)的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。”简单地说，原型产生于真正产品构建之前，一种情况是，它被扩展之后成为真正的产品;另一种情况是，它模拟真正产品但不会出现在真正产品中，而在真正产品中出现的是比原型质量更好的改进和替代。

第一种原型被称为演化式原型，它将成为真正产品的一部分，所以必须具有很好的质量。在迭代式开发中，通常会在第一个迭代中构建一个核心的体系结构演化式原型，并在后续选代中不断扩充，最终成为真正的软件产品。
第二种原型被称为抛弃式原型，它存在的原因是不确定性--对未来知识的有限性。它通过模拟“未来”的产品，能够将“未来”的知识置于“现在”进行推敲，以解决不确定性。因为构建原型时面临不确定性，那么在澄清的过程中就难免会调整和修改原型，最终使得原型的质量无法保障，所以这一类原型通常不出现在真正的产品中，需要抛弃后另行开发质量更好的改进或替代。
原型模型的基本特征并不是注重使用演化式原型，而是注重使用抛弃式原型，所以原型模型适用于不确定性较多情况下的软件开发。

驱动原型模型的可以是需求一-按照需求的重要性进行迭代规划、开发活动组织和控制，也可以是风险--按照风险程度(因为不确定性而可能造成的损害程度)进行选代规划、开发活动组织和控制。

原型模型具有演化模型的特点，所以它也具有演化模型的优点和缺点。

2、优点:
①对原型方法的使用加强了与客户、用户的交流，可以让最终产品取得更好的满意度:·适用于非常新颖的领域，这些领域因为新颖所以有着大量的不确定性。

3、缺点:
①原型方法能够解决风险，但是自身也能带来新的风险，例如原型开发的成本较高，可能会耗尽项目的费用和时间;
②实践中，很多项目负责人不舍得抛弃“抛弃式原型”，使得质量较差的代码进入了最终产品，导致了最终产品的低质量。

实践中，原型模型主要用于在有着大量不确定性的新颖领域进行开发活动组织。

2.5.3.5、螺旋模型

螺旋模型的基本思想是尽早解决比较高的风险，如果有些问题实在无法解决，那么早发现比项目结束时再发现要好，至少损失要小得多。
1、特点
螺旋模型是风险驱动(risk-driven)的，完全按照风险解决的方式组织软件开发活动。风险解决的基本思路是:确定目标、解决方案和约束一评估方案，发现风险一寻找风险解决方法一落实风险解决方案。围绕这个思路，螺旋模型将软件开发活动组织为风险解决的选代:确定目标、解决方案和约束一评估方案，发现风险一寻找风险解决方法一落实风险解决方案→计划下一个迭代……所以，螺旋模型的4个象限反映了风险解决的思路，其中“评估方案，发现风险”和“寻找风险解决方法”被置于一个象限。

2、优点

①可以降低风险，减少项目因风险造成的损失。

3、缺点:
①风险解决需要使用原型手段，也就会存在原型自身带来的风险，这一点与原型模型相同:

②模型过于复杂，不利于管理者依据其组织软件开发活动;

在实践中，螺旋模型在高风险的大规模软件系统开发中有着较多的应用。

2.5.3.6 喷泉模型

1、特点
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

2、优点

①喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发可以提高软件项目开发效率，节省开发时间适应于面向对象的软件开发过程。

3、缺点

①由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。
②喷泉模型要求严格管理文档使得审核的难度加大，尤其是面对可能随时加入的各种信息、需求与资料的情况。

开发模型	特点	使用场合
瀑布模型	线性模型，每一阶段必须完成规定的文档	需求明确的中、小型软件开发
原型模型	用户介入早，通过迭代完善用户需求，应用快速开发工具	需求模糊的小型软件开发
增量模型	每次迭代完成一个增量，可用于对象（oo）开发	容易分块的大型软件开发
螺旋模型	典型迭代模型，重视风险分析，可用于对象（oo）开发	具有不确定性的大型软件开发
喷泉模型	典型的对象（oo）过程模型，体现迭代和无缝的特性	需求明确的中小型软件开发

2.5.4、现代软件模型

2.5.4.1、Rational统一过程

1、RUP注重对最佳实践方法的吸收和应用，尤其是它提出了6个必须要应用的核心实践方法（最佳实验），它们体现了 RUP的基础思想:
1)迭代式开发，这是过去被反复证明的最佳实践方法;
2)管理需求，重视需求工程中除了需求开发之外的需求管理活动;

3)使用基于组件的体系结构，它帮助建立一个可维护、易开发、易复用的软件体系结构;

4)可视化建模，利用 UML进行建模;
5)验证软件质量，尽早和持续地开展验证，以尽早发现缺陷，降低风险和成本;

6)控制软件变更，适应 20世纪 90年代以后需求变更越来越重要的事实。
2、RUP最重要的它有三大特点：

1）软件开发是一个迭代过程，

2）软件开发是由Use Case驱动的，

3）软件开发是以架构设计（Architectural Design）为中心的。

3、RUP 的优点:
1）吸收和借鉴了传统的最佳实践方法，尤其是其核心的6个实践方法，能够保证软件开发过程的组织是基本有效和合理的。
2）RUP依据其定制机制的不同，可以适用于小型项目，也可以适用于大型项目的开发，适用面广泛。
3）RUP有一套软件工程工具的支持，这可以帮助RUP有效地实施。

4、RUP 的缺点有以下两点:
1）没有考虑交付之后的软件维护问题。
2）裁剪和配置工作不是一个简单的任务，无法保证每个项目都能定制一个有效的RUP过程。

2.5.4.2、敏捷过程与极限编程

(1)敏捷思想与原则
敏捷过程并不是要为软件开发活动组织提供一种特定的过程模而是倡导一些指导性的思想和原则。刑
最为重要的敏捷思想是敏捷联盟宣言所声明的价值观:

个体和互动 高于流程和工具。
工作的软件 高于详尽的文档。
客户合作 高于合同谈判。
响应变化 高于遵循计划。

也就是说，尽管右项有其价值，敏捷方法更重视左项的价值。
除了上述4条核心价值观之外，敏捷宣言还提出了12条原则:

我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目，提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。

很多践行敏捷思想与原则的过程方法都属于敏捷过程，包括极限编程(eXtremeProgramming，XP)、Scrum、特性驱动开发(Feature Driven Development，FDD)、自适应软件开发(Adaptive Software Development,ASD)、动态系统开发方法(Dynamic SystemsDevelopment Method，DSDM)等，其中极限编程和 Scrum 应用较为广泛。

极限编程

极限编程的一个重要思想是极限利用简单、有效的方法解决问题(这也是它被称为极限编程的原因)，例如:

如果单元测试好用，那么就让所有人一直做单元测试(测试驱动);
如果集成测试好用，那么就一直做集成测试(持续集成);
如果代码评审好用，那么就一直做评审(结对编程);
如果简洁性好用，那么就只做最简洁的事情(简单设计);如果设计好用，那么就一直设计(重构);
如果短迭代好用，那么就把迭代做得足够小(小版本发布);
如果用户参与好用，那么就让用户始终参与(现场客户)。

敏捷过程包含的方法众多，各有特点，除了共同的思想和原则之外，很难准确描述它们的共同点，所以也无法确切界定它们的优缺点。从敏捷联盟声明的思想和原则来看，它们反映了 20世纪 90年代之后软件工程的发展趋势，所以得到了广泛的应用，尤其是能够适应于快速变化或者时间压力较大的项目。

2.6 可行性研究

2.6.1、目的

用最小代价在最短时间内确定问题是否能解决->行或者不行

2.6.2、任务

1、定义问题:分析和澄清问题定义
2、导出系统模型
①物理模型:系统流程图SFD
②逻辑模型:数据流图DFD、数据字典DD
3、探索解法:根据逻辑模型探索若干可供选择解法
4、研究可行性:研究每种解法的可行性
①技术可行性:系统能否实现
②经济可行性:进行成本效益分析，评估项目的成本
③操作可行性(运行可行性)
④其他:法律，社会等