软件工程：第一章笔记

第一章 软件工程概述

1.1软件工程

1、软件工程定义：是指导计算机软件开发和维护的一门工程学科。

2、软件的定义：软件是由程序、数据和文档组成的集合。

​ 程序:是按事先设计的功能和性能要求执行的指令序列

​ 数据：使程序能正常操纵信息的数据结构

​ 文档：是与程序开发，维护和使用有关的图文资料

3、软件工程三要素：方法、工具、过程

1.2

软件开发最重要的是，考虑到客户需求以及社会发展的需要，不能脱离实际

1.3软件危机

1.3.1软件危机

软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题

涉及：

如何开发软件

如何维护数量不断膨胀的已有软件

1.3.2面临的问题

应用的扩大：软件需求量增加，规模增加

软件的复杂度增加，数万行，数百万行

人员数量的增加，组织、协调、通讯、管理

项目超出预算，花费越来越多，完成超期
$$\begin{array}{c}程序运行错误\\ 用户新的需求\\ 硬件，OS的更新\end{array}\}=程序$$

1.3.3产生软件危机的原因及应对

1.3.3.1**客观原因：**软件本身的特点

a)软件不同于硬件，它是计算机系统中的逻辑部件

1、产品开发和生产过程上的不同：

硬件设计与制造并重，制造需要质量管理

软件重开发，需要质量管理，生产只是复制

2、产品维护不同：

b)软件规模跨度大

软件不同于一般程序，复杂性将随程序规模的增加而呈指数上升。

c)软件的分类（按功能）

系统软件、支撑软件、应用软件

1.3.3.2**主观原因：**软件开发与维护的方法不正确

软件开发无计划行（成本和进度估计不足）

软件需求不充分（用户，开发人员）

软件开发过程没有统一、公认的规范

软件产品测试阶段检测不充分（大量用户涌入，极限负荷，自动刷票，买票时间错误）

缺乏有效的大型软件项目管理

轻视软件维护

• 消除软件开发人员对软件产品的个性影响的措施可能为：

  制定编码规范——统一代码的编写习惯与命名习惯（在参考文档中提供范本）。

  统一需求表达方式（UML）——学习并应用UML，用文字与图表来表达需求与设计，让所有开发人员有统一认识，特别要理解团队的习惯性概念与假定。

  制定界面规范——统一界面表现的字体，排列习惯，操作习惯等（在参考文档中提供范本）。软件常用工具积累（Utility）——归类整理常用软件工具程序，提升开发速度与质量。

  开发并应用通用软件基础设施——发展应用框架通用基础设施，不断复用前人的开发成果，降低应用难度，降低维护成本。

  提供开发示例——新人入职时使用开发示例培训，统一开发习惯与思维模式。

1.3.3.3清除软件危机的途径

（1）客观——正确认识计算机软件

软件=程序+数据+文档

（2）主管——软件工程

把软件当成一种工业产品，采用工程化的原理和方法对软件进行计划、开发和维护。

软件的文档：

管理人员：可行性研究报高，项目开发计划，模块开发卷宗，开发进度月报，项目开发总结报告； 开发人员：可行性研究报告，项目开发计划，软件需求说明书，数据要求说明书，概要设计说明书，详细设计说明书，数据库设计说明书，测试计划，测试分析报告； 维护人员：设计说明书，测试分析报告，模块开发卷宗； 用户：用户手册，操作手册。

1.4软件开发模型

• 瀑布模型
• 快速原型模型
• 增量模型
• 螺旋模型
• 基于构件的开发方法
• 净室模型
  

软件有生命周期（生存周期）：是指从制定软件计划开始，经过软件需求分析、软件设计、编码、软件测试（开发）、运行和维护直到软件被弃的全过程。

1.4.1瀑布模型

也称典型生存周期模型或线性顺序模型

①　计划阶段：目标定义+可行性研究+软件计划

②　开发阶段：需求分析+软件设计+编码+测试

③　运行阶段：维护

1.4.1.1计划时期

a、问题定义：确定系统总目标

文档：目标和范围说明书

b、可行性研究：时间，投资，解决方案

文档：可行性论证报告

c、软件计划：制定软件计划，分配角色

文档：软件计划

1.4.1.2开发阶段

设计(需求分析＋软件设计)＋实现(编码＋测试)）

a、需求分析：用户对软件系统的全部需求

文档：需求规格说明书

文档内容：软件的功能需求、性能需求、环境和外部接口、约束条件

b、软件设计：将需求–>软件的表现形式

1、总体设计

软件的总体结构

数据设计

字段名	数据类型	数据长度	描述	含义
ACHIEVEMENTID	INT	11	不允许为空,主键	成绩ID号
STUDENTID	CHAR	12	不允许为空,外键	学号
COURSEID	VARCHAR	10	不允许为空，外键	成绩的课程号
COURSENUMBER	INT	11	不允许为空	成绩的课序号
MARK	INT	11	允许为空	分数
MARKTYPE	VARCHAR	6	不允许为空	成绩类型
HAVEIF	VARCHAR	2	允许为空	是否已有成绩

接口设计

2、详细设计（流程图）

详细设计每个模块

文档：设计文档（软件的总体结构，数据设计，接口设计，详细设计）

c、编码：设计–>产生计算机源程序

d、测试：发现错误

单元测试，集成测试，确认测试，系统测试

文档：测试报告：测试计划+测试用例+测试结果

测试用例：

成绩修改模块测试1）测试目的：测试修改成绩模块的各个选项是否已经填好，若有错误或为空，则提示错误信息2）测试方法和测试软件： 1） 测试方法：黑盒测试 2） 测试软件：RTF3）测试用例

测试页面	功能	输入	期望结果	说明
marUpdate.jsp	成绩修改	成绩为空成绩：	提示成绩为空	成绩为1-100的整数
正确的成绩成绩：80	转到相应的页面	成绩为1-100的整数
错误的成绩成绩：说道	提示成绩格式错误	成绩为1-100的整数

1.4.1.3运行时期

软件维护：使软件在整个生存期内满足用户的需求，并延长寿命

改正性维护：诊断和改正使用过程中发现的错误

适应性维护：修改软件以适应环境的变化

完善性维护：根据用户要求改进或扩充软件使它更完善

预防性维护：修改软件为将来维护活动预先做准备

1.4.1.4瀑布模型特点

①　文档驱动，阶段间具有顺序性和依赖性

前—阶段的工作完成之后，才能开始后一阶段的工作

前一阶段的输出文档就是后一阶段的输入文档

前一阶段输出文档正确，后一阶段工作才能获得正确的结果

②　推迟实现

区分逻辑设计与物理设计尽可能推迟程序物理实现

③　质量保证

每个阶段都必须完成规格的文档，没有交出合格的文档就是没有完成该阶段的任务。

每个阶段结束前都进行评审，若确认，则进行下一阶段，否则返回前项。尽早发现问题改正错误。

1.4.1.5瀑布模型存在的问题

基于准确需求的假设：

只有当分析员能够做出准确的需求分析时，才能得到预期的正确结果。

顺序性太过理想化，时文档驱动：

在对软件产品试用前，用户只能从静态的文档来了解产品，要用户完全精确和正确的对一个软件产品提出确切的需求，实际上是不可能的。

瀑布模型适合：

软件需求比较明确，需求反复性小，开发技术比较成熟的场合

1.4.2快速原型模型

1.4.2.1原型

1.什么是原型：

原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。

2.原型的主要价值：

原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，原型通过充分和客户交流，还可以提高客户满意度。

3.基本要求：

体现主要的功能；

提供基本的界面风格；

展示比较模糊的部分，以便于确认或进一步明确，防患于未然。

原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。

4.处理方法：

抛弃型：抛弃原型，在取得的明确需求基础上重新开始设计与开发；用于试验某些概念，试验完系统将无用处

演化型：在原型的基础上继续开发；原型系统不断被开发和被修正，最终它变为一个真正的系统。

5.表达工具：

原型的表达工具可以有很多，如果是演化型的原型，当然优先选用软件本身的开发工具。否则还可以应用各种快速显示的工具，例如，HTML，Powerpoint等等，只要能够充分而形象地表达就可以了。

1.4.2.2原型在软件过程中的地位

软件的根本目的是实现用户的需求，提供用户日常使用，解决用户工作中有所不便的问题，提高其工作效率，改进质量，加强管理控制，最终直接或间接地提高其效益。因此软件开发本质上就是需求的处理和实现，而软件原型对需求确定来说具有非常重要的意义。

软件过程划分：

需求收集和分析、提供原型并进行评价、实现需求（对迭代的次数，每次迭代的里程碑，要实现的目标，及可提交的成果必须有可验证的清晰的计划）、需求变更

1.4.2.3原型模型

1原型开发模型：

开发人员根据用户的需求，先开发一个原型，让用户试用，用户提出改进、精化及增强系统能力的需求。开发人员根据用户的反馈意见，实施开发的迭代过程。这一过程反复进行，逐渐演化成最终的系统。每一迭代过程均由需求、设计、编码、测试、集成等阶段组成，如果在一次迭代中，有的需求不能满足用户的要求，可在下一次迭代中进行修正。

2存在的问题：

用户误解原型的角色：他们认为原型应该和真实系统一样

缺少控制：由于用户可能不断提出新要求，因而原型迭代的周期很难控制

额外的花费：研究结果表明构造一个原型可能需要10%额外花费。

为了尽快实现原型，采用了不合适的技术，没有修改，运行效率会受到影响

原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。

1.4.2.4原型系统的注意事项（功能大致实现，突出可现部分）

原型应充分展示软件的可见部分。

本质是快速，尽量缩短开发原型的时间：

使用快速原型语言、采用软件重用技术、在算法的时/空开销方面也可以让步

原型系统：类似的相关系统、已有系统、现场（手绘）

1.4.3软件演化模型

挑战：软件需求不断变化、紧迫的市场压力

思想：渐增式或者迭代开发

演化模型是利用一种迭代的思想方法，它的特征是使软件工程师渐进地开发逐步完善的软件版本。

• 增量模型
• 螺旋模型

1.4.3.1增量模型（增加功能）

把软件产品看作一系列增量构件，在开发过程的各次迭代中，每次完成一个增量。

融合了快速原型开发模型和瀑布模型

特点：

优点：

• 分批逐步提交产品，短时间内提交部分功能产品
• 逐步增加产品功能，用户有时间学习适应新产品
• 可以把难度大的构件放在后期增量中开发，避免用户长时间等待。

困难：

• 构件集成问题–>软件体系结构必须是开放的（在把每次新增量构件集成到现有的软件体系结构中时，必须不破坏原来已经开发的产品）
• 本身具有矛盾性，一方面要求开发人员把软件看作一个整体，另一方面要求开发人员把软件看作构件序列，且构件间彼此独立

1.4.3.2螺旋模型

1背景：“软件风险”是任何软件开发项目中都普遍存在的

2风险（Risk）项目风险：

在预算、进度、人力、资源、客户及需求方面潜在的问题->成本、时间上升

技术风险：在设计、实现、接口、维护方面的问题 ->质量下降，甚至无法完工

商业风险：市场、商业策略、推销策略->软件的生存能力项目越大，软件越复杂，所冒风险越大

3螺旋模型:

瀑布模型+快速原型+风险分析(risk analysis)

迭代过程沿螺旋线顺时针迭代，每迭代一次，螺旋线前进一周

每一轮周期均包含风险分析

每一轮都采用原型作为减少风险的机制

4过程：

1.确定计划

确定该阶段的目标、为完成这些目标选择的方案和设定这些方案的约束条件

2.风险分析

从风险的角度分析上一步（本阶段指定的目标、方案。。）的工作成果，必要时建立一个原型来确定风险的大小，然后据此决定是按照原目标执行，还是修改或终止项目。若成功排除所有风险，则启动下一个步骤（

3.实施工程：

实施软件开发开发验证下一产品，这个象限相当于纯粹的瀑布模型。比如，如果用户界面是最主要的风险，则选择原型法开发

若安全性是最主要的风险，则选用形式化模型开发

若子系统集成成为主要考虑的风险，则应选用瀑布模型开发。。。

4.客户评估，评价前一步的工作，提出修改意见，计划下一轮的工作

5特点：

优势：

风险驱动：在项目所有阶段考虑技术风险，能够在风险变成问题前降低它的危害

适合大型软件系统开发

缺陷：

比较复杂，需要且成功依赖于风险评估技术

主要适用于内部大型开发（若风险分析的费用接近整个项目预算，则风险分析是不可行的，只有内部开发的项目，风险过大时，才能方便停止。）

1.4.4迭代模型（完善功能）

1.4.5面向对象开发模型

软件规模庞大，或者需求是模糊或者随时间变化时，传统方法开发软件往往不成功。

1.4.5.1喷泉模型

“喷泉” 一词体现了面向对象软件开发过程的迭代和无缝

圆圈重叠： 不同阶段的重叠，各活动存在交迭——无缝

中轴线：总目标，避免开发无序

向下的箭头：该阶段内的迭代

维护圈较小

无缝——各阶段都使用统一的概念和表示符号——对象

迭代——容易实现各步骤的多次反复迭代

喷泉模型是一种迭代的开发模型，它强调用户需求的驱动和面向对象的开发过程。喷泉模型认为软件开发过程是一个自下而上的循环过程，各个开发阶段之间可以相互重叠和多次反复。喷泉模型的特点是各个开发阶段没有特定的次序要求，可以交互进行，且可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。这种模型适用于需求不稳定、项目规模较大、开发团队需要灵活应对变化的项目。

1.4.5.2基于构建的软件开发

思想：参照硬件标准零部件生产、组装

依据：应用软件系统的开发经历需求～维护， 若每天系统均从头开发，则必然存在大量重复工作 －－构件？复用？

软件复用：将已有的软件成分用于构造新系统 ——“开发伴随复用，开发为了复用”

构件：可以复用，相对独立的部件

• 需求规格说明
• 设计文档
• 测试计划和用例
• 源代码…

CBD：利用预先封装好的软件来构造应用