使用
**💡**标记的是期末考点！
软件工程发展历程
软件危机
所谓软件危机指的是计算机软件在开发和维护中遇到的一系列严重的问题， 表现在以下几个方面：
软件开发进度和成本难以控制(快、省)
软件项目的进度和估算经常不一致，导致项目成本会比预估的高。
软件产品难以满足用户的需求 (好)
用户、产品经理、程序员三 者沟通不畅，经常撕逼。
软件质量难以得到保证 (好)
难以给出客观的，一致的软件质量评价系统
软件产品难以进行维护(多)
一杯茶，一盏灯，一个bug，找一天
软件的文档资料难以管理 (多)
写代码不写文档，耶稣来了都看不懂。
软件产品的生产率难以得到提高(多)
硬件生产力跟不上。
💡软件危机出现的原因
- 对软件开发缺乏正确的理论指导
- 软件人员与用户缺乏充分的交流(无形、抽象、泛域)
- 对软件开发过程缺乏整体认识(依赖、重用、非损)
- 对软件产品缺乏有效一致的质量评价标准，使得交付的软件质量差，在运行过程中出现错误，不符合用户的操作习惯等一系列问题
精简记忆：
- 方法
- 工具
- 过程
涉及软件开发活动的两个主要方面：
- 工程学：提供工程化的过程和方法
- 软件生产过程：把软件生产，扩展到软件的需求、设计和维护，扩展项目管理、过程管理等一系列活动
所谓软件工程就是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度(工程化)，实现满足用户要求的软件产品的定义、开发、发布和维护(过程)的工程或进行研究的学科。
简单来说，就是分别定义软件（计算机科学技术） + 工程（工程管理） 软件的周期可以简单的理解为：定义，开发、发布、维护。
目标
软件工程的目标为：
- 跟踪最新的软件技术发展
- 修改和定制行的软件开发活动规则
- 提高和规范软件管理的效率和操作性
- 确保软件质量，提高软件生产率
💡基本原理
用分阶段的生命周期计划严格管理
软件从开发到上线，需要定制严格的分阶段划分，每个阶段完成不同的任务。
坚持进行阶段评审
再上面定制的阶段中，在每一个阶段完成相应的任务之后，需要对本阶段的成果进行评审，以保证每个阶段的开发质量。
执行严格的产品质量控制
保证软件产品的质量。
采用现代化程序设计技术
如何设计软件的整体架构很重要，选取现代化和成熟的设计技术，可以让软件的开发事半功倍。
结果应能清楚地审查
保证每次开发出来的结果，不仅是程序猿能看懂，用户、测试人员、产品经理都需要能直观的了解到。
开发人员应少而精
开发人员多了就不容易协调统一。
-
💡软件工程的实施原则
- 做好全面的用户需求分析
- 选取适宜的开发模型
- 采用成熟的设计方法（技术选型）
- 选取高效的开发环境（软件开发工具）
- 保证有效的维护过程
- 重视软件过程管理（软件和文档的版本管理）
简单概括为：
- 系统软件
支撑协会
可行性与计划：分析整个软件是否可以做的出来需求分析：分析客户的具体需求，剖析这个软件需要哪些功能或者服务内容设计：就是把具体的需求设计成为编码内容实现：把需求转换为代码测试：对写完的代码进行测试，看看是不是符合要求运行和维护：一个项目上线之后，可能会存在bug等问题，需要定时的去修bug软件的过程
这里就只是吧运行和维护之前的内容再细分了一下而已，了解即可。
💡软件的过程模型
经典的开发模型有：瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型、敏捷过程模型、渐进式交互过程模型、微软解决框架模型等。
考试的时候只需要说出这8个名字即可。
瀑布模型
瀑布模型也叫线性顺序模型：
瀑布模型整个流程是自顶向下的，各个阶段相互分离又相互依赖。简单的来说，就是按照软件的生命周期线性执行。这里看的出来，瀑布模型根据生命周期把整个软件的开发分为了6个周期，3个阶段。每个周期一旦有问题都会回溯到上一个周期进行修改，如果上一个周期没有解决问题，就继续回溯，直到回到最初的周期。
瀑布模型的特点：
- 简单：模型简单易用
- 严格：因为每一个周期结束之后，都会进行审查
- 顺序性：严格按照生命周期顺讯进行开发
- 一次性：没有迭代开发，需求模型确定了基本就是一路开发到结束
- 质量保证：瀑布模型强调文档，这样十分便于查验
基于上面的几个特点，可以看出瀑布模型不适用于大型项目开发，因为大型项目的需求会经常变更或者添加，不可能一次性就开发的完。
原型模型
由于在软件开发的需求分析阶段，难以确定用户需求，因而软件人员根据用户初步的、不明确的需求快速开发出系统原型。
如图所示：
简单来说，原型模型就是程序猿先写一个满足用户最核心要求的demo，给用户看了之后，用户再以此为基础就行提出需求进行开发。
原型模型的特点：
- 快速：相比较瀑布模型，由于核心要求被优先满足，所以能最快的实现相应的核心系统，用户也能更快直观看到系统是怎么样的。
- 符合用户的预测：用户需求的添加实际就类似于后期软件的维护，模型的演化用户能参与其中，能更早的把一些问题发现并解决。
原型模型同样不适用于大型项目的开发，因为原型系统的设计有可能会被抛弃，增大开发成本，且改模型主要是在用户不清楚需求的情况下使用，所以核心需求一旦变更，等于白做。
增量模型
增量模型是对软件项目中功能以一系列增量的方式来开发，也被称为渐增式开发模型。增量模型是一种非整体开发模型，对于系统整体需求，增量模型先将需求分解为若干部分，每个部分都按照瀑布模型方法进行开发。 
简单来说，增量模型是分步提出需求进行开发，把一整个软件系统划分为很多个子集进行开发，也就是每次只会开发部分功能。
优点：灵活、低风险。
螺旋模型
螺旋模型结合了瀑布模型和快速原型模型，要求不断迭代，同时要像螺旋一样不断前进，即每次迭代都不是在原水平上进行，是对整个开发过程进行迭代，而不仅仅对编码、测试进行迭代。
螺旋模型强调风险分析，要求开发人员，在每次迭代开发之前都需要评估开发的风险，从而提前的采取相对应的策略。如上图所示，整个模型分为了四个阶段：
计划管理阶段：分析如何实现现阶段的功能和服务风险管理阶段：分析按照计划实现功能和服务的风险开发设计阶段：把控好风险之后，对计划的内容进行实际的开发用户验证阶段：每次阶段性开发完，就让用户测评是否满足用户需求
每次螺旋都需要经过这四个阶段，直到最终软件开发完毕。
螺旋模型十分适合大型项目开发，原因就在于这里的风险分析，能够提早的规避开发过程中的风险或者给出消除风险的方案。
喷泉模型
喷泉模型最大的特点在于软件过程的每个阶段相互重叠，而不像其它过程模型每阶段有明显界线。
其特点如下：
- 开发阶段的相互重叠
- 支持重用
- 不严格的阶段划分，增量式开发
- 对象驱动
喷泉模型中，各个阶段都是并行执行的，所以需要的开发人员就会比较多，增大了人员管理和文档管理的难度。
说一下文档的作用，可以理解为开发过程中的代码说明书，不同人写代码的习惯不一样，可能会出现代码互相之间看不懂的问题。为了便于团队协作需要更新维护这个说明书，以确保别人和自己一看文档就知道代码的含义和作用。
敏捷过程模型
凡是满足敏捷价值、遵循敏捷原则的过程都是敏捷过程。
敏捷价值体现为：
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循计划
敏捷模型的五大原则：简单、变化、建模、交流、反馈。
敏捷模型致力于快速获取需求和搭建原型，同时也引入了风险分析。
渐进交互模型
面对不明确的需求（原型模型）、非整体的开发（增量模型）、影响软件质量的风险（螺旋模型），渐进交付迭代模型通过对软件不断演进的循环往复，完成软件系统的实施过程。
微软解决框架过程模型
分为四个主要阶段：
- 创想阶段C
- 计划阶段D
- 开发阶段E
- 稳定阶段F
软件开发方法
结构化开发方法
结构化开发方法也称为面向功能的软件开发方法或面向数据流的软件开发方法。
主要过程如下：
若有收获，就点个赞吧
0 人点赞
