软件工程概述

本文是我个人在学习过程中搭建的学习框架，提取了一下这门课的重难点。文中括号的部分，存在大量个人理解和观点，希望大家辨别地阅读，有偏差之处也希望大家指出。

概述

软件危机

(我们为什么需要软件工程)
软件危机：软件在开发和维护过程中遇到的一系列严重问题。主要解决两个问题：
a.如何开发软件
b.如何维护已有软件

软件危机表现：
1.对软件开发成本和进度往往估计不准确
2.用户对“已完成”软件时常不满意
3.软件的质量往往不够稳定
4.软件常常不可维护
5.软件没有适当文本资料
6.软件成本逐年上升
7.软件开发效率无法跟上社会需求

软件危机产生原因：
1.软件是逻辑部件，缺乏可见性，管理和控制十分困难。
2.软件规模庞大
3.从业者对软件开发和维护有许多错误认识和做法，对用户需求未了解完备就开始编写程序
4.供求矛盾，技术发展不能适应社会的需求
（说白了咱效率太低，钱有点挣不过来了）

软件危机解决途径：
1.应该对计算机软件有正确认识，软件是程序、数据和文档的集合。
2.必须认识到软件开发不应依赖个人习惯，而应该是一种组织良好、管理严密、各类人员相互配合共同完成的工程项目。
3.推广使用现有成功的开发软件的技术和方法，并探索更好的技术和方法。
4.应善于开发利用软件工具。
总之，解决软件危机，既要有技术措施，又要有必要的组织管理措施。
注意：软件危机将一直存在，只可以尽量避免，无法彻底消除。

软件与软件工程

软件：程序 + 文档 + 数据
软件工程：将系统的、规范的、可量化的方法应用于软件的开发、运行和维护，并不断研究优化。

软件工程基本原理：
1.用分阶段的生命周期计划严格管理
2.坚持进行阶段评审
3.实行严格产品控制
4.采用现代程序设计技术
5.结果应清晰易于审查
6.开发小组人员应该少而精
7.承认不断改进软件工程实践的必要性

软件工程方法学

软件工程方法学：方法、工具和过程。

方法：完成软件开发各项任务的技术方法。
工具：为了运用方法而提供的自动的或半自动的软件工程支撑环境。
过程：为获得高质量软件所需完成的一系列任务的框架，规定了完成各项任务地工作步骤。

软件工程方法学分为：传统方法学和面向对象方法学。

传统方法学：

又称面向结构方法学、结构化范型。
a.采用结构化的技术完成软件开发（结构化分析、结构化设计、结构化实现）。
b.把软件的生命周期划分成若干个阶段，顺序完成各阶段任务。
c.每个阶段开始结束都有严格标准，对于相邻阶段，前一个阶段结束的标准就是后一个阶段开始标准。
d.每个阶段结束前都必须正式进行严格的技术审查和管理复审。

面向对象方法学（重点）

又称面向对象范型。
a.把对象作为融合数据以及在数据上操作的软件构件，即用对象分解取代了传统的功能分解。
b.把所有对象都划分成类。（这句话看着好难受，它应该想要表达我们要抽象的意思）
c.按照父类与子类关系，把若干相关类组织成一个 层次结构的系统。
d.对象间彼此仅能通过发送消息互相联系。

软件生命周期

软件生命周期包括：软件定义、软件开发和软件维护，三个时期。其中每个时期又分为若干阶段。

软件定义分为：问题定义、可行性研究和需求分析，三个阶段
软件开发分为：总体设计、详细设计、编码和单元测试、综合测试，四个阶段。

软件过程模型（重点）

瀑布模型

优点:
a.可强迫开发人员采用规范方法
b.严格规定了每个阶段必须提交的文档
c.要求每阶段交出所有产品都必须经过质量保证小组的仔细检验

缺点:
a.只能通过文档了解产品，不经过实践的需求是不切实际的
b.需求确定一段时间之后才能获得产品的最初版本(软件实际情况必须到项目开发后期客户才能看到)
c.完全依赖于规格说明导致不能满足用户需求;d.客户往往很难清楚地给出所有需求。

快速原型模型

优点:
a.使用这种软件过程开发的软件产品通常能满足用户的真实需求
b.软件产品开发过程基本是线性顺序的c.节省开发的投入，缩短整个软件开发周期d.改善用户参与
c.提高系统的实用性和可维护性

缺点:
a.用户和开发者对原型理解不同，用户有时误解原型角色，误以为其与真实系统一样可靠
b.准确的原型设计比较困难
c.由于用户不断提出新要求，原型迭代周期很难控制
d.为了尽快实现原型，采用不合适的技术会使运行效率受到影响

增量模型

优点:
a.能在较短时间内向用户提交可完成部分工作产品
b.逐步增加产品功能，从而使用户有充裕的时间学习和适应新产品，减少一个
全新软件给用户带来的冲击
c.开放式软件可维护性比较好
d.在第一次构建完成之前就已经完成总体设计，风.险较小

缺点:
a.为成功开发软件，软件工程师必须具有较高水平技术，能设计出开放的软件体系结构
b.把每一个新的增量构件集成到现有的软件体系结构中必须破坏原来的已经开发出的产品，使软件过程的控制失去整体性。

螺旋模型

螺旋模型：基本思想是使用原型及其他方法来尽量降低风险，可以把它看作在每个阶段之前都增加了风险分析过程的快速原型，模型适用于内部开发的大型软件项目

优点:
a.有利于已有软件的重用
b.有助于把软件质量作为软件开发的一个重要目标c.减少了过多测试或测试不足所带来的风险
d.软件维护与软件开发没有本质区别

缺点:使用螺旋模型开发软件，要求软件开发人员具有丰富的风险评估知识和经验

喷泉模型

喷泉模型是迭代和无缝的，面向对象。

敏捷模型

敏捷开发：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征，在此过程中软件一直处于可使用状态。

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

敏捷开发宣言
a.个体和交互胜过过程和工具
b.可以工作的软件胜过面面俱到的文档
c.客户合作胜过合同谈判
d.响应变化胜过遵循计划

可行性研究

研究当前项目是否有实现上的可能，一般我们关注以下三点：

1. 技术可行性
   从技术角度是否易于实现。
2. 经济可行性
   从经济角度成本是否符合预期。
3. 操作可行性
   从运营角度，是否具备相关配套设备、操作人员等。

具体过程：

(1)复查项目规模和目标。
描述：知道我们要干什么，并且要干个多大的事。

对有关人员进行调查访问,仔细阅读和分析有关的材料,对项目的规模和目标进行定义和确认,清晰地描述项目的一切限制和约束,确保分析员正在解决的问题确实是需要解决的问题。

(2)研究正在使用的系统。
描述：以前别人都是咋干的。

正在运行的系统可能是一个人工操作的系统,也可能是旧的计算机系统,现在要开发一个新的计算机系统来代替现有系统。因此,现有的系统是信息的重要来源,要研究它的基本功能,存在什么问题,运行现有系统需要多少费用,对新系统有什么新的功能要求,新系统运行时能否减少使用费用等等。

(3)得到新系统的概括的逻辑模型。
描述：我们应该做哪些改进。

根据对现有系统的分析研究,逐渐明确了新系统的功能、处理流程以及所受的约束,然后使用建立逻辑模型的工具——数据流图和数据字典来描述数据在系统中的流动和处理情况。

(4)导出和评价各种方案。
描述：用那三个指标估摸一下能不能干成。

分析员建立了新系统的概括逻辑模型之后,要从技术角度出发,提出实现概括逻辑模型的多种方案,即导出若干概括的物理解法。根据技术可行性、经济可行性、社会可行性对各种方案进行评估,去掉行不通的解法,确定可行的解法。

(5)推荐可行的方案。
描述：这事具体该咋干，怎么干省钱。

根据上述可行性研究的结果,应该决定该项目是否值得去开发。若值得开发,那么可行的解决方案是什么,并且说明该方案可行的原因。该项目是否值得开发的主要因素是从经济上看是否合算,这就要求分析员对推荐的可行方案进行成本——效益分析。

(6)编写可行性研究报告。
描述：整理资料，生成报告。

将上述可行性研究过程的结果写成相应的文档,即可行性研究报告,提请用户和使用部门仔细审查,从而决定该项目是否进行开发,是否接受可行的实现方案。

系统流程图（一般不考）

系统流程图：描述了数据在系统各部件（程序、数据库、文档）间的流动情况。

数据流图（重点、要会画）

数据流图（DFD）：是描述数据在软件中流动与被处理转化的过程。

数据字典

数据字典：数据的集合，包含数据流图中所有的元素。一般分为四类：数据流、数据元素（数据流分量）、数据存储、数据处理。

数据流图与数据字典：数据字典是对数据流图的标注和说明。二者共同构成数据系统的逻辑模型。

形式上类似正则表达式，具体语法如下：

成本效益分析

成本效益分析：从经济角度衡量开发的成本。

成本估计方法：
1.代码行技术
2.任务分解技术
3.自动估计成本技术（让计算器去做这个事）

相关指标：

a.货币时间价值 。
对应时间若干年后的这些收益，是否符合预期。P=F/(1+i)^n（若n年后可以收入F元钱，比当前利率，则这些钱现在的价值P）

b.投资回收期（前期投入需要多久回本）
c.利润（利润空间有多大）
d.投资回收率（总收入与投资的比率）

需求分析

基本准则：
1.必须理解并描述问题的信息域，根据这条准则应该建立数据模型;(实体联系图)
2.必须定义软件应完成的功能，这条规则要求建立功能模型;（数据流图）
3.必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型;（状态转换图）
4.必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。

需求分析任务：
1.确定对系统的综合要求
(功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、逆向需求和将来可能提出的要求)
2.分析系统的数据要求
3.导出系统逻辑模型
4.修正系统开发计划

与用户沟通获取需求的方法：
1.访谈(正式和非正式)
2.面向数据流自顶向下求精
3.简易的应用规格说明技术(面向团队的需求收集方法)
4.快速建立软件原型
快速原型两个特性:快速和容易修改
快速构建和修改原型方法和工具:第四代技术，可重用软件构件，形式化规格说明和原型环境

验证需求
1.一致性:所以需求必须是一致的，任何一条需求和其他需求相互不能矛盾。
2.完整性:需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
3.现实性:指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
4.有效性:必须证明需求是正确有效的，确实能解决用户面对的问题。

实体联系图

1.矩形框:实体，内写实体名
2.椭圆形:属性，内写属性名
3.菱形:联系，内写联系名(1:1或1:n或m:n)
4.直线:实体与属性之间;实体与联系之间;联系与属性之间用直线相连

总体设计（重点）

总体设计：又称概要设计，一般分为两个阶段：系统设计阶段、结构设计方案

系统设计阶段：
（1）提出所有可供选择方案
（2）选出合理方案
（3）推荐最佳方案

结构设计方案：
（4）功能分解
（5）设计软件结构
（6）设计数据库
（7）制定测试计划
（8）编写文档
（9）审查与复审

设计原理（重点中的 重点）

模块化

模块化：将程序划分成可以独立访问的模块。每个模块对应一个功能，最终通过模块的组合完成用户的需求。
（我读完感觉就是一句老话六个字——高内聚，低耦合）

优点:
1.使软件结构清晰，容易设计同时也容易阅读。
2.使软件容易测试和调试，更容易提升程序的可靠性。
3.模块化利于程序修改。
4.模块化有利于软件工程组织管理。

抽象

抽象：抽象出事物的普遍本质特性，而暂时不去考虑细节。
（这不就是类吗）

逐步求精

逐步求精：在抽象的基础上逐步细化。
（迭代开发？）

信息隐藏与局部化

信息隐藏：在设计模块时，对一个模块内的信息，通常对于不需要这些信息的其他模块，是不能访问的，也是不可见的。
（封装。。。）

局部化：把关系密切的软件元素放的彼此靠近，有助于实现信息隐藏。
（把相近的放一起，避免和其他无关的东西耦合，感觉应该是这个意思，就像分文件夹一样）

模块独立

模块独立：是模块化、抽象、信息隐藏和局部化的结果。

度量标准：
1.内聚：衡量一个模块内部各个元素彼此结合的紧密程度。
2.耦合：衡量不同模块间彼此互相依赖的紧密程度。

内聚种类：
1.偶然内聚：一个模块完成了一组任务，及时这些任务彼此间有关系，也是十分松散的。（意思是理论上其实可以再细分，但可能由于复用性的关系，没有再细化成更小的模块）

2.逻辑内聚：一个模块完成的任务逻辑上相同或相似。

3.时间内聚：一个模块的任务必须在同一段时间内执行。（这个解释不太好，我的理解应该是说，我们在模块划分的时候，要把需要完成的工作尽量放在同一个时间段完成。比如：我睡到中午要出门吃饭了，那在这个出门这个需求执行前，我需要干嘛，穿衣服、洗脸洗头刷牙。。。这些要应该放在出门之前这一段时间）

4.过程内聚：一个模块内处理的元素之间相关，并且必需按照某些特定次序执行。（讲的应该就是穿衣服和下楼吃饭这种前后特定执行顺序的模块）

5.通信内聚：模块中所有元素都使用同一输入或产生同一输出。

6.顺序内聚：一个模块内处理元素和同一功能密切相关，这些处理必须顺序执行。（这和过程内聚有什么区别吗。。。难道一个是某种次序，一个是顺序。。。）

7.功能内聚：一个模块所有处理元素属于一个整体，完成一个单一功能。（就是不可再分呗）

耦合种类：
1.数据耦合：两个模块之间仅仅通过参数交换信息，而且仅仅是数据。

2.控制耦合：两个模块之间传递的信息存在控制信息。（函数调用）

3.特征耦合：两个模块之间传递的是数据结构，而被调用的模块只需要使用其中一部分数据。（传个线性表）

4.公共环境耦合：多个模块通过一个公共区域相互作用。（临界区的意思吧）

5.内容耦合：包括以下几种情况（你干涉内政了）

• a.一个模块访问另一个模块的内部数据
• b.一个模块不通过正常入口进入另一个模块内部
• c.两个模块有部分程序代码重叠
• d.一个模块有多个入口（一个模块有多种功能）

内聚程度（越高越好）：功能>顺序>通信>过程>时间>逻辑>偶然（恭顺 通过 石螺呕）
耦合程度（越低越好）：数据<控制<特征<公共环境<内容（数控特工 内）

启发规则（面向结构的）

1.改进软件结构，以提高独立性。（奔高内聚，低耦合使劲）

2.模块的规模应该适中。

3.深度、宽度、扇出和扇入应适当。
深度：软件的层数
宽度：同一层模块总数最大值
扇出：一个模块直接控制的模块数（出度）
扇入：有多少个上级模块直接调用它。（入度）

4.模块的作用域应在控制域内。
作用域：一个模块所影响的所有模块的集合。
控制域：这个模块以及所有直接或间接从属它的模块的集合。

5.力求降低模块接口的复杂程度

6.尽量设计单入口、单出口的模块

7.模块功能应该可预测

描绘软件结构的图形工具

主要分为层次图、HIPO图、结构图，注意这里是总体设计使用的。

层次图：
（没错，就是大家想的那个，这种图说实话画太多了）

HIPO图：
层次图（H图）+IPO图。以模块分解的层次性以及模块内部输入、处理、输出三大基本部分为基础建立的。（看看得了，据说一般不考）

结构图（重点考察）：

（1）模块：矩形框表示，框内标注模块名或主要功能
（2）调用关系：直线，可不带箭头（因为默认自上而下）
（3）调用过程中传递的信息：带注释的箭头，尾部空心圆指传递的数据，实心圆指传递的控制信息
（学这么多的图，这写论文不得更有自信了）

• 根据数据流图画结构图：

此处引用另一位博主的帖子，写的特别好，图也十分美观。

转化后的结构图：

详细设计

实现

维护

未完待续。。。（例题+后续章节）