软件工程期末复习自我总结（一） 概述，软件过程及问题定义，面向过程分析基础

第一讲 课程介绍和概述

软件=程序+数据+文档
程序是按事先设计的功能和性能要求执行的指令序列
程序=算法+数据结构
数据是指程序初始化数据、测试数据、以及研发数据、
维护数据等
文档是与程序开发、维护和使用有关的图文材料

软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。
软件是被开发或设计的，而不是传统意义上的被制造。
软件不会磨损。
虽然软件产业正在向基于构件的组装前进，大多数软件仍然是定制。

软件的本质特性：复杂性
软件是人类思想的外延，人们将自己的思想传送给计算机，当产生的可执
行文件被激活运行时，软件便重现人类的意图。

软件的本质特性：演化性
• 人们总是认为软件是容易修改的，但忽视了修改所带来的副作用
• 不断的修改最终导致软件的退化，从而结束其生命周期

软件的本质特性：不可见性
软件人员太像“皇帝的新衣”故事中的裁缝了。当我来检查软件开发工作时，所得到的回答好象对我说：我们正忙于编织这件带有魔法的织物。只要等一会儿，你就会看到这件织物是及其美丽的。但是我什么也看不到，什么也摸不到，也说不出任何一个有关的数字，没有任何办法得到一些信息说明事情确实进行得非常顺利，而且我已经知道许多人最终已经编织了一大堆昂贵的废物而离去，还有不少人最终什么也没有做出来。

软件危机的定义
指在软件的开发和维护过程中所遇到的一系列严重问题。
典型表现：
• 开发成本和进度的估计常常不准确；
• 用户对交付的软件系统不满意的现象经常发生；
• 软件质量无保证、可靠性差；
• 软件常常是不可维护的；
• 软件通常没有适当的文档资料； • 软件成本在计算机系统总成本中所占比例逐年上升； • 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
总之开发成本高，周期长，质量差，满足不了市场需求

产生软件危机的原因
软件本身的特点；
• 软件的规模越来越大，结构越来越复杂；
• 软件开发的管理困难；
• 轻视软件维护的重要性，占总费用的55-70%； • 软件开发费用不断增加；
• 软件开发技术落后. 生产管理方式
• 生产方式落后，开发工具落后；
• 仅仅重视程序而忽略软件配置其余成分；
• 忽略软件定义时期的工作；

消除软件危机的途径
• 充分认识到软件的定义；
• 认识到：软件开发不是某种个体劳动的神秘技巧，而应该是一种组
织良好、管理严密、各类人员协同配合、共同完成的工程项目； • 必须充分吸取和借鉴各种工程项目所积累的行之有效的原理、概念、
技术和方法；
• 开发和使用更好的软件工具；
总之，从管理和技术（方法和工具）两方面解决软件危机。

软件工程诞生：1968年北大西洋公约组织（NATO）召开国际会议，提出
“软件工程”概念和术语。

什么是软件工程
软件工程是为了经济地获得能在实际机器上高效运行的可靠软件，而确立一系列工程
原理（方法）。 ----- Fritz Bauer(弗里茨·鲍尔)，NATO，1968
软件工程是 ① 将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护
，即工程化应用到软件上；② 对①中所述方法的研究。------IEEE【IEE93】

软件工程的基本目标：
• 较低的开发成本
• 按时完成开发任务并及时交付
• 实现客户要求的功能
• 所开发软件具有良好的性能
• 较高的可靠性、可扩展性、可移植性
• 软件维护费用低

软件工程是一项建模活动，通过抽象找到事物的重要特征而忽略非本质的细节，从不同侧面
建立系统模型，有效地简化和处理复杂性。

软件工程是一项解决问题的工程活动，它不仅限于算法设计，还要通过试验、设计复用、
系统评估等手段找到一个客户可接受的方案

软件工程方法（范型）
面向服务：在应用表现层次上将软件构件化，即应用业务过程由
服务组成，而服务由构件组装而成。
面向构件：寻求比类的粒度更大的且易于复用的构件，期望实现
软件的再工程 。
面向对象：以类为基本程序单元，对象是类的实例化，对象之间
以消息传递为基本手段。
面向过程：以算法作为基本构造单元，强调自顶向下的功能分解，
将功能和数据进行一定程度的分离。

小结
 软件、软件危机、软件工程
 软件工程的发展来源于软件危机，而软件危机指的是在20世纪60年代软
件开发和维护过程中出现了一系列难以控制的问题
 软件工程指的为了经济地获得能在实际机器上高效运行的可靠软件，而确
立的一系列工程原理（方法）
 软件工程方法指的是在软件生命周期内，使用的一整套技术方法的集合

第二讲 软件过程和问题定义

软件生命周期

软件生命周期的定义：
软件产品从考虑其概念开始到交付使用，直至最终退役为止的整个过程
***个人补充
在软件生命周期中最长的是维护阶段
最重要的阶段是需求分析 考点哈 ***

软件过程(process)
软件过程(process)
描述、开发、维护软件制品，创建、管理和支持软件项目的一系列活动和任务

软件过程模型
什么是模型？
模型：对现实世界的抽象，是对现实世界的物、或者现象的抽象
抽象：提取所关注的信息，而忽略不重要、次要的信息
模型的作用：有助于人们对现实世界的认识
模型的表示：任何形式（数学公式、图像、文本）

什么是软件过程模型？
软件过程模型：
对软件开发全部过程的抽象
是对软件全部开发过程中所涉及的活动（或者任务）、以及活动之间的关系的抽象
过程、活动和任务的结构框架
软件过程模型的作用：
明确规定要完成的活动、任务和开发策略
告诉人们应该去遵循一个什么样的过程去开发软件系统
为软件工程管理提供里程碑和进度表
为软件开发提供框架和方法

软件过程评估

1 传统软件过程模型
瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型
2 现代软件过程模型
• 基于构件的开发模型
• 统一过程模型
• 敏捷开发

原型模型

增量模型

软件过程模型：增量模型
优点： • 短时间内提交部分产品，降低开发风险
缺点：
• 增量规模不能大（开发不要超过20k行代码），否则会暴露瀑布模型的缺点；
• 将客户需求分解成增量序列必须对系统需求十分了解，并有顶层设计的经验；
• 多数系统都需要基本服务，如何为基本服务定义增量，何时实现这些增量，处理起来比较
困难

螺旋模型



喷泉模型

优点：
 提高效率，节省开发时间
缺点：
 没有严格的阶段区分，不便于管理

现代软件过程模型

基于构件的开发模型
• Component-based development model
• 近年来得到广泛应用，改变大型软件开发方式
• 考虑的焦点是集成，而非实现
• 构件/组件（Component） • 系统中模块化的、可更换的部分
• 实现特定的功能
• 对实现进行封装，暴露一组接口
• 例如：动态链接库（.dll），浏览器插件

Rational统一过程模型
• Rational公司推出的完整且完美的软件工程方法，开发了软件工具支持用UML开
发软件的统一过程（Rational Unified Process，RUP） • 基于面向对象方法学
• 使用同一建模语言UML（ Unified Modeling Language）
从三个视角描述软件开发过程

1. 动态视角：随时间变化的各个阶段
2. 静态视角：所进行的活动
3. 实践视角：可采用的良好实践建议

敏捷开发

问题定义
目的：弄清“要解决的问题是什么？”
可行性研究的目的
用最小的代价在尽可能短的时间内研究并确定客户提出
的问题是否有行得通的解决办法
系统分析师的工作！！！
可行性研究的内容
技术可行性
经济可行性
操作可行性
社会可行性

可行性研究的过程
1：确定系统的规模和目标
2：研究目前正在使用的系统
3：导出新系统的高层逻辑模型
4：重新定义问题
5：导出和评价选择的解决方案
6：推荐行动方针
7：草拟开发计划
8：书写文档提交审查

成本-效益分析技术
目的：从经济角度分析开发一个特定的新系统是
否划算，从而帮助客户组织的负责人正确地做出
是否投资于这项开发工程的决定。
两方面内容：
成本估算技术、效益估算方法

任务分解（自上向下）
单个任务的成本=人力（人月数）每人每月平均工资
代码行技术（自底向上）
软件功能成本=源代码行数每行代码的平均成本
差别估算

货币的时间价值
同样数量的货币随时间的不同具有不同的价值
货币在不同时间的价值可用年利率（i）来折算

初始投资P，n年后的收益：

n年后的能收益F元，那这些钱的现在价值P为：


纯收入
整个生命周期之内系统的累计经济效益（折合成
现值）与投资之差

投资回收期
工程累计经济效益(折现之后)等于最初投资所需的
时间

投资回收率
设想把数量等于投资额的资金存入银行
每年年底从银行取回的钱等于系统每年预期可以获得的效益
在时间等于系统寿命时，正好把在银行中的存款全部取光
此时的银行年利率就是假想的投资回收率

小结
 软件生命周期：软件定义、软件开发、软件维护；每个阶段的任务
 基本概念：软件过程、软件过程模型、软件成熟度模型
 传统软件过程模型
 现代软件过程模型
 系统可行性分析

第三讲 需求工程及面向过程分析基础

需求的概念与内容
定位：
可行性研究阶段后，系统设计之前（承上启下）
任务：
最终形成一份经开发方和用户认可或达成共识的软件需
求规格说明书
关注：系统必须做什么?

需求的定义与分类
(1)用户解决问题或达到目标所需的条件或能力；
(2)系统或系统部件为满足合同、标准、规范或其他正式文
档所需具有的条件或能力；
(3)一种反映上述(1)和(2)两种条件或能力的文档描述。
-----IEEE
事实上：
并没有一个清晰、毫无二义性的“需求”术语存在
真正的“需求”实际上在人们的脑海中
任何文档形式的需求仅是一个模型，一种叙述

需求的层次

需求工程
软件工程的子领域
 定义：
应用已经证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一个学科.
 输出：软件系统的需求规格说明（requirements specification ）

需求建模
用清晰、简明的方式将需求分析获得的信息记录下来的过程，建模结果是一个逻辑模型，是对问题对理解的专业化描述，描述系统必须做什么，不解决如何做。
模型的角色：

1. 帮助分析员理解系统的信息、功能和行为，使得需求分析认为更加容易实现，结果更加系统化。
2. 评审焦点，成为确定需求规格说明的完整性、一致性和精确性的重要依据。
3. 设计的基础，为设计者提供了软件要素的表示视图。

结构化需求建模：自顶向下、逐层分解的系统分析方法来定义系统的需求。工具：数据流图、数据字典、加工说明、状态变迁图、实体-关系图等等。
面向对象建模：把系统看做是相互协作的对象，这对象是结构和行为的封装，系统所有功能通过对象之间相互发送消息来获得。由三个独立模型构成：
功能模型：用例图
分析对象模型：类图和对象图
动态模型：由状态图和顺序图表示

需求规格说明
需求开发的结果，它描述了一个软件系统必须实现的功能和性能，以及影响该系统开发的约束。
软件开发过程中非常重要的文档，是软件系统的逻辑模型的重要组成部分

需求的改变是合理的、不可避免的。然而，需求变更
通常会对项目的进度、人力资源产生很大的影响。因此，
控制好需求变更显得十分重要

需求变更控制步骤：
对提出的变更请求进行评审
由项目变更控制委员会或相关职能的类似组织对变更请求进行裁定
按照需求变更控制流程实施变更

需求变更控制原则：
建立需求基线
定义明确的需求变更控制流程
变更应及时通知所有涉及的人员
变更后受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致

需求工程小结
 需求分析是承上启下（衔接可行性分析与系统设计）的重要活动
 在项目需求阶段发现并修复错误所花费的成本与维护阶段发现并修复错误的成本比例可能达：1：200
 需求工程是建立并使用完善的工程化方法，以较经济的手段获得准确表达用户需求的软件需求规格说明的一个学科
 需求工程的主要关注点：需求开发和需求管理
 需求开发的四步：需求获取、需求建模与分析、需求文档化、需求评审
 需求管理主要包括：需求变更控制、需求版本控制、需求跟踪、需求状态跟踪

分层的原则

1. 加工个数大致控制在“7加减2”的范围
2. 分解应自然、均匀，概念上合理、清晰
3. 为减少层数，每层适当多分解几个加工
4. 上层分解得快些，下层分解得慢些

图和加工的编号
顶层图：不必编号
1层图：编号为1，2，3，… 子图中加工的编号：x.1、x.2、x.3… 子图号：标记该子图号记为“图x

数据流图示例—
资格和水平考试的考务处理系统
系统说明：
 分成多个级别（初级程序员、程序员、高级程序员、系统分析员等），凡
满足一定条件的考生都可参加某一级别的考试
 考试的合格标准由考试中心根据每年的考试成绩确定
 阅卷工作在软件系统外，由阅卷站进行。

资格和水平考试的考务处理系统
—功能需求
1．对考生送来的报名单进行检查
2．对合格的报名单编好准考证号后将准考证送给考生，并将
汇总后的考生名单送给阅卷站
3．对阅卷站送来的成绩清单进行检查，并根据考试中心制订
的合格标准审定合格者
4．制作考生通知单送给考生
5．进行成绩分类统计(按地区、年龄、文化程度、职业、考试
级别等分类)和试题难度分析，产生统计

顶层图唯一的加工：软件系统(考务处理系统)
2. 确定源或宿：系统之外的外部实体，数据的源点
或终点


面向过程分析基础小结
 面向过程分析
 数据模型：ER图  功能模型：数据流图
 行为模型：状态变迁图

本来是想打算一个文章写完结果到这里发现有点多就拆了好几份，总结持续更新中。