一.软件工程学概述

1.1软件与软件危机

一.软件的概念，特点，与发展
(1)软件的概念:
软件是计算机系统中与硬件相互依存的另一部分，是包括程序、数据及其相关文档的完整集合。(软件=程序+数据+文档)
  程序:是能够完成预定功能的可执行指令序列。
  数据:是使程序能够适当处理信息的数据结构。
  文档:是开发、使用和维护过程中程序所需要的图文资料。
(2)软件的特点:
1.软件本身具有复杂性，软件成本高昂，软件是一种逻辑实体，不存在磨损
2.软件开发不是传统硬件制造过程，未摆脱手工开发方式
3.软件维护与硬件有本质差别，维护难度高
(3)软件发展经历三个阶段:
程序设计阶段一50至60年代
程序系统阶段—60至70年代
软件工程阶段一70年代以后
---------------------------------------------------------
二:软件危机
(1)软件危机的概念:
软件开发和维护过程中所遇到的一系列严重问题。
主要包含两方面内容:
一是：如何开发软件，以满足对软件日益增长的需求
二是：如何维护数量不断膨胀的已有软件
(2)软件危机的原因:
1、从主观看，与开发人员在软件开发与维护过程中的方法不正确有关
忽视需求分祈，轻视软件维护，没有认识到程序只是软件的一部分
没有认识到软件开发只是软件生命周期中一个比较次要的阶段
越到后期引入变动付出代价越高昂
2、从客观看，与软件本身特点有关
1.软件本身具有复杂性，软件成本高昂，软件是一种逻辑实体，不存在磨损
2.软件开发不是传统硬件制造过程，未摆脱手工开发方式
3.软件维护与硬件有本质差别，维护难度高
(3)软件危机的表现:
用户对已完成软件不满意，软件质量不可靠，软件成本在计算机系统中所占比例逐年上升
软件开发生产率低，对软件开发成本和进度估算不准确
软件不可维护，没有适当文档资料
(4)消除软件危机的途径:
1、对计算机软件要有正确认识，积极开发和使用辅助开发工具
2、采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和方法结合起来，经济的开发出高质量的软件并进行维护。

1.2软件工程

1.2软件工程(技术[软件工程方法学]+管理[软件项目管理])
(1)软件工程定义:
采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和技术方法结合起来，经济的开发出高质量的软件并进行维护。
(2)软件工程基本原理:
使用现代程序设计技术，实行严格的产品控制，坚持进行阶段评审，用分阶段的生命周期计划严格管理
开发小组人员应该少而精，结果能够得到清楚的审并且查承认不断改进软件工程实践的必要性
(3)软件工程的本质特性:
关注大型程序的构造，中心课题是控制复杂性
软件必须有效支持用户并且软件经常发生变化
开发效率非常重要，开发人员和谐合作非常关键，通常是具有一种文化背景的人替具有另一种文化背景的人创造产品
(4)软件工程方法学:
把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为泛型。
主要包括三个要素:方法、工具和过程。
方法:完成软件开发各项任务的技术方法，回答“怎么做”的问题
工具:为运用方法提供的自动或半自动软件工程支撑环境
过程:是为了获得高质量软件所需要完成的一系列任务框架，回答“何时做”的问题
(5)软件工程方法学分类:
传统方法学(生命周期方法学):
  采用结构化技术完成软件开发各项任务，把软件生命周期的全过程依次划分为若干阶段，每个阶段开始和结束有严格标准，每个阶段结束后进行严格审查
面向对象方法学:
  把对象作为融合了数据及操作的统一的软件构件，对象之间仅能通过发送消息进行联系
  把所有对象划分成类，按照父类与子类的关系，把若干相关类组成一个层次结构的系统，下层类可以继承上层类中的数据和操作。

1.3软件生命周期

1.软件生命周期：是指软件从生产到报废的整个生命周期，可以分为 软件定义时期，软件开发时期和运行维护时期
 软件定义时期：(分为)
  问题定义阶段:弄清用户要解决什么问题
  可行性研究:弄清确定的问题是否可行
  需求分析:弄清系统需要具备什么功能(用数据流图，数据字典，简要的算法表示系统逻辑模型，并得到规格说明书)
 软件开发时期  
  总体设计:设计软件结构，确定程序由哪些模块组成以及模块间的关系
  详细设计:针对每个模块设计详细规格说明，确定算法和数据结构
  编码和单元测试:将详细设计的内容用指定语言实现，并测试每个模块
  综合测试:通过各种类型测试使系统达到预定要求
运行维护时期(只有)
  运行维护:通过各种必要的维护使系统持久地满足用户需求

1.4软件过程

软件过程:是为了获得高质量软件所需要完成的一系列任务框架。
通常用软件生命周期模型描述软件过程。
主要包括:
 瀑布模型 
 快速原型模型
 增量模型
 螺旋模型
 喷泉模型
 其他模型

1.4.1 瀑布模型

1.瀑布模型：是将软件生命周期的各项活动依照固定顺序连接最终得到软件产品的过程。
 适用于需求明确或过去成功开发过类似的项目
3.瀑布模型特点：
  1.阶段间具有顺序性和依赖性。
  2.推迟实现的观点。(首先考虑的是它的逻辑模型，而不是物理模型)
  3.质量保证的观点(瀑布模型的优点)
3.瀑布模型的优点
严格规定了每个阶段都必须提交相应的文档;每个阶段提交的产品都必须经过质量保证小组的验证。可以强迫开发人员采用规范的方法;
4.瀑布模型的缺点
在开发初期就做出正确、全面、完整的需求分析是非常困难的。
在需求分析阶段，确定需求后无法及时验证需求是否正确。
由于不支持产品的演化缺乏灵活性，很多错误只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。

传统瀑布模型.png 改进的瀑布模型.png

1.4.2 快速原型模型

快速原型模型：快速建立可运行的程序，它完成的功能往往是最终产品功能的一个子集。
适用场合：适用于要求快速，用户对系统的目标不是很清楚的项目
优点:
  软件产品开发基本是线性过程，开发的软件产品通常满足用户需求
缺点:
  原型理解可能不同，准确原型设计困难，不利于开发人员创新

快速原型模型.png

1.4.3 增量模型

增量模型：先完成一个系统子集的开发，再按同样的步骤增加功能(系统子集),依次递增直至满足全部系统需求。
使用场合：对已有产品进行升级或期限严格要求的项目。
优点:
  短期内可提交完成部分功能，逐渐增加产品功能使用户适应产品更快。
缺点:
  软件体系结构必须是开放的,增量构件划分以及构件集成困难。

增量模型.png

1.4.4 螺旋模型

螺旋模型:增加了风险分析过程的快速原型模型。
适用场合：适用于内部开发的大规模软件项目。
优点:
  有利于把软件质量作为软件开发的目标。减少了过多测试或测试不足带来的风险
缺点:
  软件开发人员要有丰富的风险评估经验

简化的螺旋模型.png 完整的螺旋模型.png

1.4.5 喷泉模型

喷泉模型:典型的面向对象软件过程模型。
场合：适用于面向对象开发过程。
优点：体现迭代和无缝的特性。
缺点：各阶段同步开发不利于项目管理
迭代:系统某部分常被重复工作多次，相关功能在每次迭代中逐渐加入演进系统。
无缝:分析、设计、编码各阶段间不存在明显边界。

喷泉模型.png

1.4.6 其他模型

其他模型:
Rational统一过程
程敏捷过程与极限编程
微软过程

1641129091276.png

二.可行性研究

2.1可行性研究任务

(1)可行性研究目的:
目的是用最小的代价在最短的时间内确定问题是否能够解决。(5%-10%)
(2)可行性研究实质:
实质是简化分析和设计的过程，以较为抽象的方式在较高层次上进行系统的分析和设计。
(3)可行性研究任务:
 1.分析和澄清问题定义。
 2.导出系统的逻辑模型。
    数据流图+数据字典
 3.根据逻辑模型探索若干种可供选择解法
 4.研究每种解法可行性，包括
  经济可行性:经济效益是否大于开发成本
  技术可行性:现有技术能否实现
  操作可行性:系统操作方式是否可行(盲人不能用看的软件)
 以及法律和社会效益等方面的可行性。

2.2可行性研究内容步骤

可行性研究过程：
1.复查系统规模和目标。
对问题定义阶段初步确定的规模和目标进行肯定或改正，并列出对目标系统的约束和限制。
2.研究目前正在使用的系统。
了解现有系统能做什么，而不花费过多时间分析怎么实现这些功能。
3.导出新系统的高层逻辑模型。
现有物理系统》现有逻辑模型》目标逻辑模型》目标物理系统
4.进一步定义问题。
分析员和用户一起再次复查系统。前四个步骤构成一个循环。
5.导出和评价供选择的解法。
技术角度排除不可行方案
操作可行性排除用户不能接受方案
经济可行估算成本和收益
6.推荐行动方针。
给出是否继续的结论
7.草拟开发计划。
制定进度表
开发人员、计算机资源分析
估计每阶段成本、下阶段详细分析
8.书写文档提交审查。

2.3系统流程图

系统流程图：是描绘物理系统的传统工具，用图形符号以黑盒子形式描绘物理系统的各个部件，表达数据在系统各部件之间流动的情况。而不是对数据进行加工处理的控制过程。

image.png

2.4.1.数据流图

数据流图(DFD)：描述数据从输入到输出过程所经过的变换。只描绘数据在软件中流动和被处理的逻辑过程，没有任何具体物理部件。
数据流图画法:
(1)确定系统输入输出、源点以及终点
(2)画系统顶层数据流图
用加工将输入输出数据连接起来，给加工、数据等命名
(3)自顶向下分解，画出分层数据流图
  将加工细分，细分成几个数据流图表示

image.png
image.png

2.4.2数据字典

数据字典：是关于数据的信息集合
数据字典用途: 主要用于在分析和设计阶段给开发人员提供关于数据的描述信息。
①可以作为分析阶段的工具
②估计改变一个数据将产生的影响
③并且是数据库开发的第一步
1.数据字典包括的内容:数据流、数据流分量（数据元素)、数据存储、处理。
2.定义数据的方法:
 由数据元素定义数据的方式:顺序、选择、重复、可选

image.png image.png

2.5成本效益分析

一﹒分析目的
为了从经济角度分析新系统的开发是否能盈利，帮助使用部门正确做出是否投资的决定。
二.成本/效益分析的方法
要考虑到：
1.货币的时间价值 F =P(1+ i)
2.投资回收期
3.纯收入
4.投资回收率
三.成本估计(的技术有)
1.代码行技术
软件成本=每行代码的平均成本*源代码行数
2.任务分解技术:
按开发阶段将系统划分成任务每个任务的成本=人力*人平均工资
软件成本=∑独立任务的成本
3.自动估计成本技术

image.png

三.需求分析

3.1 需求分析任务

(1).首先确定对系统的综合要求
 功能需求:系统必须提供的服务功能
 性能需求:系统必须满足的约束条件(包括响应速度、安全性)
 可靠性和可用性需求:可靠性需求定量地指定系统的可靠性、可用性量化了用户可以使用系统的程度。
 出错处理需求:说明系统对环境错误应该怎样响应
 接口需求:包括硬件接口需求、软件接口需求、通信接口需求(以及应用系统与环境通信格式常见用户接口需求)
 约束:用户或环境强加的限制条件（包括工具、语言等)
 逆向需求:说明系统不应该做什么
 将来可能提出要求:将来可能需要实现的需求
(2).然后分析系统的数据要求(通常采用建立数据模型的方法来分析系统的数据要求，常用层次方框图和Warnier图等图形工具辅助描绘数据结构，为了减少数据冗余，通常需要把数据结构规范化)
(3).接着导出系统的逻辑模型(通常用数据流图，实体联系图，状态转换图，数据字典和主要的处理算法描述这个逻辑模型)
(4).最后修正系统的开发计划(成本和进度)

3.2 获取需求方法

 可以通过：访谈，
 面向数据流自顶向下求精(依靠数据流图，数据字典和IPO图向用户解释输入数据是怎样转变成输出数据的)
 或简易的应用规格说明技术(面向团队的需求搜集法，提倡用户和开发者密切合作)
 以及快速建立软件原型等方法 

3.3 分析建模并提交软件需求规格说明

1.分析建模
模型:是指为了理解事物而对事物做出的一种抽象
模型分类:
 数据模型:(实体-联系图)︰描绘对象与对象之间的关系。
 功能模型:(数据流图):描绘数据在系统中流动时被处理的逻辑过程
 行为模型:(状态转换图)︰描绘系统的各种行为模式和在不同状态间转换的方式。
2.软件需求规格说明
  是需求分析阶段得出的最主要的文档。

3.4实体联系图、状态转换图

3.4.1 实体联系图

用来建立数据模型，包含三种基本成分：实体，属性和联系
  实体:用来描述数据对象。
  属性:用来描述数据对象的性质。
  联系:用来描述数据对象之间的交互方式。分为
   ◆—对一联系1:1
   ◆—对多联系1:M
   ◆多对多联系M:N

image.png

3.4.2 状态转换图

■状态:是指系统的行为模式，包括初态、终态、中间状态。
 在一张状态图中只能有一个初态而终态可以有0至多个。
 表示方式：
    初态:实心圆o
    终态:同心圆，内为实心·
    状态:圆角矩形

■事件:是指在某个特定时刻发生的事情，是对系统从一个状态转换到另一个状态的事件抽象。

image.png

3.5 其他图形工具

3.5.1 层次方框图

表示方式:用树形结构的一系列矩形框描绘数据的层次结构。
优点:随着结构的逐步精细，对数据结构的描绘也越来越详细。

image.png

3.5.2 Warnier图

表示方式:用树形结构描绘信息的层次结构。
优点:可以表明信息的逻辑组织。可以表明某类信息出现的条件或是否重复出现。

image.png

3.5.3 IPO图

表示方式:是输入、处理、输出图的简称,能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。

image.png

3.6验证软件需求

(1)从哪些方面验证软件需求的正确性
■一致性:所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
■完整性:需求必须是完整的,规格说明书应该包括用户需要的每一个功能或性能。
■现实性:指定的需求应该能用现有的硬件和软件技术可以实现。
■有效性:必须证明需求是正确有效的，确实能解决用户面对的问题。
(2)验证软件需求的方法
■验证需求的一致性:通过自然语言描述需求、形式化语言描述需求、或用软件工具验证
■验证需求的现实性:参照开发经验
■验证需求的完整性和有效性:建立软件原型
(3)用于需求分析的软件工具
 PSL/PSA(问题陈述语言/问题陈述分析程序)系统