软件工程第2章
软件工程第二章-软件过程
编码
运行 时期
1. 瀑布模型
瀑布模型(waterfall model)是软件工程最早的范例，
也称经典生命周期，它提出了一个系统的、顺序的软 件开发方法，从用户需求规格说明开始，通过计划、 建模、构建和部署的过程，最终提供一个完整的软件 并提供持续的技术支持。
沟通 项目启动 需求获取 策划 项目估算 进度计划 项目跟踪
… 框架活动 # n 动作 # n.1 任务集 …… 动作 # n.m 任务集 工作任务、工作产品、 质量保证点、项目里程碑
工作任务、工作产品、 质量保证点、项目里程碑
只有一种软件过程吗？
软件过程的种类很多，区别主要体现在几个方面： 组成过程的各个活动(包括普适性活动)、动作和任务，及其相互依 赖的关系都可能不同； 动作和任务的细化程度可能不同； 工作产品的定义和要求可能不同； 质量保证活动的应用方式可能不同； 项目跟踪和控制活动的应用方式可能不同； 过程描述的详细程度和严谨程度可能不同； 客户和利益相关者对项目参与的程度可能不同； 软件团队所赋予的自主权可能不同； 队伍组织和角色的明确程度可能不同。
下优先级进行增量开发：
第一个增量实现基本的文件管理、编辑和文档生成功能
； 第二个增量实现更加完善的编辑和文档生成功能； 第三个增量实现拼写和文法检查功能； 第四个增量完成高级的页面布局功能； ……
增量模型的特点
增量过程模型综合了线性、并行、演化三种过程流的
特征。
对于每个增量，使用的是线性过程流；
过程流
过程流(process flow)：描述了在执行顺序和执行时
间上，如何组织框架中的活动、动作和任务。 大致有四大类不同的过程流：
软件工程第二章(可行性分析)
（5） 交付的产品清单。
项目开发计划书供软件开发单位使用。
小结：
1、项目的问题定义、可行性分析和项目计划是总体 规划阶段的工作，重点是项目的可行性分析。
2、可行性分析主要从技术可行性、经济可行性和操 作可行性三方面来分析该项目是否值得开发。
3、可行性分析最后形成的成果是可行性分析报告。
项目的筹备、规划与准备是软件项目实施的前
期工作，它由两个重要的工作阶段构成：一是
项目规划及可行性分析；二是项目需求分析。
一、可行性分析的概念
可行性分析就是解决一个项目是否有可行解以及是
否值得去解的问题。该阶段的主要任务就是用最小
的代价在尽可能短的时间内确定问题是否能够得到 解决。
二、可行性分析的目标和内容
等。
(6) 技术可行性(技术风险评价)：技术实力分析、已有的 工作及技术基础和设备条件等等。 (7) 法律可行性分析结果描述。 (8) 可用性评价：汇报用户的工作制度和人员的素质，确 定人机交互功能界面需求。
(9) 其他项目相关的问题：如可能会发生的变更等等。
可行性研究报告由系统分析员撰写，交由项目负责人审查， 再上报给上级主管审阅。 在可行性研究报告中，应当明确项目“可行还是不可行”， 如果认为可行，接下来还要制定项目开发计划书。
识别用户要求 评价系统的可行性 进行经济分析和技术分析 把功能分配给硬件、软件、人、数据库和其它系 统元素 建立成本和进度限制 生成系统规格说明，形成所有后续工程的基础
三、 可行性分析的主要任务
具体地说，分析员应从下面三个方面对项目做出可行性分 析： （1）技术可行性：使用现有的技术能实现这个系统吗? （2）经济可行性：这个系统的经济效益能超过它的开发成本 吗?（详细在后面介绍成本/效益分析） （3）操作可行性：系统的操作方式在该用户组织内行得通吗?
《软件工程学》第2章 可行性研究-答案
2.1 可行性研究的目标与任务1．可行性分析是在系统开发的早期所做的一项重要的论证工作，它是决定该系统是否开发的决策依据，因此必须给出（ B ）的回答。
A．确定B．行或不行C．正确D．无二义2．技术可行性是可行性研究的关键，其主要内容一般不包括（ C ）。
A．风险分析B．资源分析C．人员分析D．技术分析3．可行性研究的任务是从技术、经济、操作、社会等4个方面研究。
4．可行性研究完成后最终生成的文档是《可行性研究报告》。
（√ ）5．软件可行性研究的目的是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得去开发。
（√ ）2.2 可行性研究过程1．简述可行性研究的过程。
答：（1）复查并确定系统规模和目标（2）研究目前正在使用的系统（3）建立新系统的高层逻辑模型（4）导出和评价各种方案（5）推荐可行性方案（6）草拟初步开发计划（7）编写可行性研究报告提交复查2.3 可行性研究工具1．描绘物理系统的传统工具是系统流程图。
2．画出数据流图目前住院病人主要由护士护理，这样做不仅需要大量护士，而且由于不能随时观察危重病人的病情变化，还会延误抢救时机。
某医院打算开发一个以计算机为中心的患者监护系统，请分层次的画出描述本系统功能的数据流图。
医院对患者监护系统的基本要求是随时接收每个病人的生理信号（脉搏、体温、血压、心电图等），定时记录病人情况以形成患者日志。
当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息。
此外，护士在需要时还可以要求系统输出某个指定病人的病情报告。
答：从问题陈述容易看出，本系统的数据源点是“病人”和“护士”，他们分别提供生理信号和要求病情报告的信息。
进一步分析问题陈述，从系统应该“定时记录病人情况以形成患者日志”这项要求可以想到，还应该有一个提供日期和时间信息的“时钟”作为数据源点。
从问题陈述容易看出，系统的数据终点是接收警告信息和病情报告的护士。
系统对病人生理信号的处理功能主要是“接收信号”、“分析信号”和“产生警告信息”。
软件工程导论 第2章 可行性分析
(2) 经济可行性 (3) 操作可行性 (4)法律可行性等
复习回顾
1、可行性研究的目的是什么？ 用最小的代价在尽可能短的时间内确定问题是否能够解决。 2、可行性研究的任务主要是什么？ 了解客户的要求 及现实环境
分析技术、经济和社会因素可行性 编写可行性研究报告 制定初步项目开发计划
按照系统的层次结构进行逐步分解，并以分层的
数据流图反映这种结构关系，能清楚地表达和容
易理解整个系统。
首先画“顶层DFD”
描绘系统的整体逻辑概貌
外部实体 软件 系统
……
外部实体
……
外部实体
外部实体
顶层流图仅包含一个加工，它代表被开发系统。它的输入流
是该系统的输入数据，输出流是系统所输出数据。
其次画中间层流图：对上层父图的处理的细化，形成子图。
没有数据字典数据流图就不严格，没有数据流图
数据字典也难于发挥作用。
数据字典的内容
一般说来，数据字典应该由对下列4类元素 的定义组成： (1) 数据流 (2) 数据流分量(即数据元素)
(3) 数据存储
(4) 处理
2.5.2定义数据的方法
符号 = + [ ]与 | { } m
被定义为
+订货数量+目前价格+主要供应者
+次要供应者
位置：输出到打印机
•例如：
名字：零件编号 别名： 描述：唯一地标识库存清单中 一个特定零件的关键域 定义：零件编号=8{字符}8 位置：订货报表 订货信息 库存清单 事务
名字：订货数量 别名： 描述：某个零件一次订货的数量 定义：订货数量=1{数字}5
位置：订货报表
《软件工程实用教程》第2章软件生存周期及开发模型
本章學習內容： 1．掌握軟體的生存（生命）週期的概念 2．明確學習軟體過程模型的意義 3．掌握各種過程模型的特點與適用範圍 4．掌握面向對象軟體過程模型的內容與過 程
第2章軟體生存週期及開發模型
2. 1 軟體過程概述
2.1.1 軟體生存週期
軟體的生存週期指軟體產品從功能確 定、設計、開發成功、投入使用，並 在使用中不斷修改、完善，直至被新 的軟體所替代而停止該軟體的使用的 全過程。
第2章軟體生存週期及開發模型
2.2.4 螺旋模型
第2章軟體生存週期及開發模型
改進的瀑布模型
第2章軟體生存週期及開發模型
2.2.2 原型模型
1．快速原型方法 快速原型方法是原型模型在軟體分析、設計 階段的應用，用來解決用戶對軟體系統在需 求分析上的模糊認識。 快速原型法的特點： 快速原型是用來獲取用戶需求的，或是用來 試探某種設計是否有效。一旦需求或設計確 定下來，原型就將被拋棄。
第2章軟體生存週期及開發模型
瀑布模型的缺點 階段與階段劃分固定，階段間產生大量的文檔， 極大地增加了工作量； 由於開發模型呈線性，當開發成果尚未經過測試 時，用戶無法看到軟體的效果，這些問題往往會 導致開發出來的軟體不是用戶真正需要的軟體； 無法通過開發活動澄清本來不夠確切的軟體需求， 因此，需要返工或者不得不在維護中糾正需求的 偏差； 由於固定順序，前期工作中造成的差錯越到後期 階段所造成的損失越大，為了糾正偏差，需要付 出高昂的代價。
第2章軟體生存週期及開發模型
2.2 典型的軟體過程模型
軟體過程模型 把軟體生存週期中各項開發活動的流程用一 個合理的框架——開發模型來規範描述，這 就是軟體過程模型 。 軟體過程模型是從一個特定的角度表現一個 過程，主要根據軟體的類型、規模，特別是 軟體的開發方法、開發環境等多種因素確立 過程模型。
软件工程第二章软件过程
第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。
所有的软件过程都必须具有4种对软件工程来说是基本的活动。
它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。
2.软件设计和实现：必须生产符合描述的软件。
3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。
4.软件进化：软件必须进化以满足不断变化的客户需要。
2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。
2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统开发过程着重于集成这些组件到新系统中，而非从头开发。
2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。
这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。
它的主要问题在于它将项目生硬地分解成这些清晰的阶段。
关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。
所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。
瀑布模型的一个重要变形是形式化系统开发。
软件工程第2章-系统工程
软件工程第2章-系统工程软件工程第2章-系统工程2.1 系统工程概述系统工程是一种系统性和综合性的工程方法，旨在设计、开发和维护复杂的软件系统。
系统工程的主要目标是满足用户需求，并确保系统的有效性、可靠性和可维护性。
2.1.1 系统工程定义系统工程是一个跨学科的领域，涉及到多个专业领域的知识和技术。
它集成了工程学、计算机科学、信息技术等多个学科的理论与实践，以解决大规模软件系统开发和维护过程中的各种问题。
2.1.2 系统工程过程系统工程的过程涵盖了软件系统的整个生命周期，包括需求分析、设计、开发、测试、部署和维护等阶段。
每个阶段都有特定的任务和活动，并且需要进行严格的管理和控制。
2.1.2.1 需求分析阶段需求分析阶段是系统工程的起点，通过与用户沟通和交流，收集和整理用户需求，并将其转化为系统的功能和性能要求。
2.1.2.2 设计阶段在设计阶段，系统工程师会根据需求分析阶段的成果，设计整个系统的结构和组件之间的关系。
这包括系统架构设计、模块设计和接口设计等。
2.1.2.3 开发阶段开发阶段是系统工程中最为关键的阶段，主要是根据设计阶段的成果，进行软件编码、集成和测试。
开发人员需要按照设计规范和编码标准进行开发工作，并保证代码的质量和可维护性。
2.1.2.4 测试阶段测试阶段是为了验证系统是否满足用户需求，并发现和修复潜在的缺陷和问题。
测试人员会执行各种测试活动，包括单元测试、集成测试和系统测试等。
2.1.2.5 部署阶段在部署阶段，系统工程师会将已经通过测试的系统部署到目标环境中，并进行安装、配置和调优等工作，确保系统能够正常运行。
2.1.2.6 维护阶段维护阶段是系统工程的最后一个阶段，主要是为了确保系统能够持续地运行和满足用户的需求。
维护人员会定期检查系统的性能和可靠性，并进行必要的修复和优化等工作。
2.2 系统工程的关键技术2.2.1 需求工程需求工程是系统工程中非常重要的一环，它主要涉及到需求获取、需求分析、需求验证和需求管理等方面的内容。
软件工程(第3版)第2章 人民邮电出版社PPT课件
6条“最佳实践” 10个“流程要素”
可重用方法内容及流程构建块的框架
可以在定义自己的开发方法和过程
底层方法及流程定义语言
统一方法架构元模型 UML
RUP最佳实践
迭代式开发 需求管理 使用基于组件的架构 可视化建模 验证软件质量 控制软件变更
问题定义 可行性研究 需求分析 概要设计 详细设计 编码和单元测试 集成测试（综合测试） 软件维护
瀑布模型
收集需求 分析 设计 编码 测试 维护
瀑布模型 - 加入迭代过程
收集需求 分析 设计 编码 测试 维护
快速原型法
快速建立一个反映用户 主要需求的原型系统
可视化编程工具的广泛 使用
架构和组件
软件架构（Software Architecture）
构成系统的组件 组件之间的关联和交互
架构刻画了系统的整体设计
去掉了细节部分 突出了系统的重要特征
可视化建模
由于应用领域不同，模型可以有文字、图形或数学 表达式等多种形式，一般说来，使用可视化的图形 更容易令人理解。
验证软件质量
用户故事 需求
测试用例 新用户故事
差错
隐喻 架构试探
制定交付 交付计划 计划
不确定的估计
确定的估计
最新版本
用户认可
迭代开发
验收测试
下一次迭代
小交付
难点试探
XP(极限编程Extreme Programming)的整体开发过程
极限编程
未完成的任务 用户故事 交付计划 项目速率
新用户故事 新项目速率
共享的信息
能力成熟度模型的结构
能力成熟度等级
初始级 可重复级 已定义级 已管理级 优化级
软件工程课件第2章
精选ppt
6
可行性研究的内容： 首先进一步分析和澄清问题定义，导出系统的
逻辑模型； 然后从系统逻辑模型出发，探索若干种可供选
择的主要解法(即系统实现方案)； 对每种解法都研究它的可行性，至少应该从三
方面研究每种解法的可行性 。
精选ppt
3
关于系统规模和目标的报告书
1.项目名称：教材销售系统 2.问题：人工发售教材手续繁杂，且易出错。 3.项目目标：建立一个高效率、无差错的微机教材销售
系统。 4.项目规模：利用现有微型计算机，软件开发费用不超
过5000元。 5.初步想法：建议在系统中增加对缺书的统计与采购功
能。 6.可行性研究：建议进行大约10天的可行性研究，研究
该装配厂使用一台小型计算机，处理更新库存清单主文 件和产生定货报告。零件库存量的每一次变化称为一个事务， 由放在仓库中CRT终端输入到计算机中；系统中的库存清单 程序对事务进行处理，更新存储在磁盘上的库存清单主文件， 并且把必要的订货信息写在磁带上。最后，每天由报告生成 程序读一次磁带，并且打印出订货报告。
包括开发和运行该系统所需要的各种资源 如硬件、软件、人员和组织机构等 3. 费用预算：分阶段的人员费用、机时费用及其他费用 4. 进度安排：各阶段起始时间、完成文档及验证方式 5. 要交付的产品清单
精选ppt
16
8. 书写文档提交审查 把可行性研究各个步骤的工作结果写成清晰的
文档，请用户、客户组织的负责人及评审组审 查，以决定是否继续这项工程及是否接受分析 员推荐的方案。
库存清单 主文件
报告生成程序
定货报告
第三层：合成后的系统流程图
软件工程(邓良松)第二章
第2章 软件要求定义
应该收集、研究和分析现有系统的文档资料，实地考察现 有系统，在考察的基础上，访问有关人员，然后描绘现在系统 的高层系统流程图(见2.1.3节)， 与有关人员一起审查该系统流 程图是否正确。系统流程图反映了现有系统的基本功能和处理 流程。 (3) 建立新系统的高层逻辑模型。根据对现有系统的分析 研究，逐渐明确新系统的功能、处理流程以及所受的约束，然 后使用建立逻辑模型的工具——数据流图和数据字典(见8.3、8.4 节)来描述数据在系统中的流动和处理情况。注意，现在还不是 软件需求分析阶段，不是完整、详细的描述，只是概括地描述 高层的数据处理和流动。
第2章 软件要求定义
1. 技术可行性 技术可行性 对要开发项目的功能、 性能和限制条件进行分析， 确定在 现有的资源条件下，技术风险有多大，项目是否能实现，这些 即为技术可行性研究的内容。这里的资源包括已有的或可以搞 到的硬件、软件资源，现有技术人员的技术水平和已有的工作 基础。 技术可行性常常是最难解决的方法，因为项目的目标、功 能和性能比较模糊。技术可行性一般要考虑的情况包括： (1) 开发的风险： 在给出的限制范围内， 能否设计出系统 并实现必须的功能和性能? (2) 资源的有效性： 可用于开发的人员是否存在问题? 可用 于建立系统的其他资源是否具备?
第2章 软件要求定义
输入变更记录
库存管理模块
订货信息
报告生成模块 订货报告
库存
图 2.1 库存管理系统的系统流程图
第2章 软件要求定义
2.1.4 成本 效益分析 成本—效益分析
成本—效益分析的目的是从经济角度评价开发一个新的软 件项目是否可行。成本一效益分析首先是估算将要开发的系统 的开发成本，然后与可能取得效益进行比较和权衡。效益分有 形效益和无形效益两种。有形效益可以用货币的时间价值、 投资回收期和纯收入等指标进行度量；无形效益主要从性质上、 心理上进行衡量，很难直接进行量的比较。系统的经济效益等 于因使用新的系统而增加的收入加上使用新的系统可以节省的 运行费用。运行费用包括操作人员人数、工作时间和消耗的物 资等。下面主要介绍有形效益的分析。
软件工程-第2章
第2章可行性研究 2.5.4 数据字典的实现
2.5 数据字典
34
第2章可行性研究 2.5.4 数据字典的实现
主要内容
35
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析
正方形表示数据的源点或终点 圆角矩形代表变换数据的处理 开口矩形代表数据存储
箭头表示数据流，即特定数据的流 动方向
第2章可行性研究
2.4 数据流图
2.4 数据流图
15
2.4.2 例子
以简单例子说明怎样画数据流图
假设一家工厂的采购部每天需要一张订货报表，报表按零件编 号排序，表中列出所有需要再次订货的零件。对于每个需要再 次订货的零件应该列出下述数据：零件编号，零件名称，订货 数量，目前价格，主要供应者，次要供应者。零件入库或出库 称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。 当某种零件的库存数量少于库存量临界值时就应该再次订货。
如右图所示。
第2章可行性研究
2.3.2 例子
主要内容
13
2.1 可行性研究的任务 2.2 可行性研究过程 2.3 系统流程图 2.4 数据流图 2.5 数据字典 2.6 成本/效益分析
第2章可行性研究
2.4 数据流图
2.4 数据流图
14
概念：
数据流图(DFD)是一种图形 化技术，它描绘信息流和 数据从输入移动到输出的 过程中所经受的变换。
第2章可行性研究 2.5.2 定义数据的方法
2.5 数据字典
31
2.5.3 数据字典的用途
软件工程-第2章-数据流图
Data flow diagram of the main graphic elements （主要图形元素）
编号 加工 名称
Example of DFD:
DFD of Bank Withdrawals Process
描述银行取款过程的数据流图
Example of DFD:
Each element must have a name DFD can not be attached to control flow In the beginning, the trivial details could be ignored, in order to concentrate on the main data stream
图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节，以集中精力于主要数据流
Naming for each elements of DFD If it is difficult to give a name, it is possible because DFD decomposition problem Data Flow (Database): Using data noun Processing: using verb-object phrase. Data source: using normal noun
Tools of Software Need Analyzing 需求分析工具
Ning Hong-yun 2009.8
Tools of Software Need Analyzing 需求分析工具
Data flow diagram ( DFD, 数据流图)
软件工程讲义_第二章
演化过程模型评述[NOG00]
首先，原型开发（和其他更加复杂的演化过程） 由于构建产品需要的周期数目不确定，给项目策 划带来了困难。 其次，演化软件过程没有确定演进的最快速度。 如果演进的速度太快，完全没有间歇时间，项目 肯定会陷入混乱；反之，如果演进速度太慢，则 会影响生产率…… 再次，软件过程应该侧重于灵活性和可扩展性， 而不是高质量。为了追求高质量而延长开发时间 势必造成产品推迟交付，从而失去进入市场的良 机。
过程模式
过程模式提供了一种有效的机制来描述各 种软件过程。模式使得软件工程组织能够 从高层抽象开始，开发层次化的过程描述。 高层抽象描述又进一步细化为一系列步骤 模式以描述框架活动，然后每一个步骤模 式又进一步逐层细化为更详细的任务模式。 过程模式一旦建立起来，就可以在过程变 体的定义中复用——即软件开发队伍可以 将模式作为过程模式的构建模块，定制特 定的过程模型。
演化过程模型评述
演化模型的初衷是采用迭代或者增量的方式开 发高质量软件。可是，用演化模型也可以做到强 调灵活性、可扩展性和开发速度。软件开发团队 及其经理所面临的挑战就是在这些严格的项目和 产品参数与客户（软件质量的最终仲裁者）满意 度之间找到一个合理的平衡点。
专用过程模型
专用过程模型具有传统过程模型的一些特 点，但是，专用过程模型往往应用面较窄， 只适用于某些特定的软件工程方法。 在某些情况下，这些专用过程也许更确切 地应该称为技术的集合或方法论，是为了 实现某一特定的软件开发目标而制定的。 但它们确实也提出了一种过程。
模式名称：应能清楚地表述该模式在软件过程中的功能。 驱动力：模式使用环境及主要问题， 以明确主要难点 并可能影响解决方案。 类型：定义模式类型。 启动条件：描述模式应用的前提条件。 问题：描述模式将要解决的问题。 解决办法：描述模式的实现。 结束条件：描述模式成功执行之后的结果。 相关模式：以层次或其他图的方式列举与该模式相关的 其他模式。 已知应用实例：介绍该模式的具体实例。
《软件工程》第二章软件生命周期及软件开发模型
•2。2软件开发生命周期过程和活动
• 最早出现的软件开发模型是 1970年W．Royce提出的瀑布模型， 而后随着软件工程学科的发展和软件 开发的实践，相继提出了原型模型、 演化模型、增量模型、喷泉模型等。
•
•2.2.1 瀑布模型
•问• 题定义
•
• 问题计划•可行性
•
•需求分析
• 开发时期
• • • • 运行时期 •
•（3）总体设计
•（4）详细设计
•（5）编码（实现） •（6）软件测试、运行／维护
•
•2。2软件开发生命周期过程和活动
• 软件生命周期过程的IEEE（美国电气电子工程师学 会 IEEE）标准描述了一系列活动和过程，对于[IEEE Std．1074-1995]的软件的开发和和维护来说这些活动 是强制性的。它的目标是为开发生命周期模型建立一 个通用框架。在这一节，我们描述由这一标准引入的 主要过程和活动。 • 过程是一系列朝着特定目标（例如，需求、管理、 发布）执行的活动。IEEE标准一共列出了17个过程（ 见表2.1）。把过程分组成更高层的抽象称为过程组（ process group）。 •过程组的例子是项目管理、前期开发、开发和后期开 发。
•总体设计 •详细设计
• 图2.2 瀑布模型
•编码
•测试
•维护
•
•2.2.2 演化模型
•需
•求 •设 计 •编 •码
•测 试
•集 成
•需 求
•设 计
•编 码
•测 试
•集 成
•需 求
•设 计
•编 码
•测 试
•集 成
•
•2.2.3 原型模型
•
•2.2.4 螺旋模型
软件工程 第2章 习题
第2章软件可行性研究例题分析与解答一、填空题1.可行性研究实质上是进行一次简化、压缩了的___需求分析和设计_____。
2.可行性研究的三个方面是技术可行性、社会可行性和____经济可行性_____。
3.可行性研究的第一个具体步骤是____确定项目的规模和目标______。
4.若年利率为i，不计复利，P元在n年后的价值F是______p*(1+n*i)___。
5.可行性研究中描述系统高层物理模型的工具是__系统流程图_____。
二、选择题1.可行性研究的目的是决定( B )。
A.开发项目B.项目值得开发否C.规划项目D.维护项目2.技术可行性要研究的问题之一是( D )。
A.存在侵权否B.成本效益问题C.运行方式可行否D.技术风险问题3.纯收入是累计效益现在值与投资之( B )。
A.和B.差C.积D.商4.项目开发计划这类文档是一种( B )。
A.技术性文档B.管理性文档C.需求分析文档D.设计文档答案一、填空题1.[答案]需求分析和设计2.[答案]经济可行性3.[答案]确定项目的规模和目标4.[答案]p×（1＋n×i)5.[答案]系统流程图二、选择题1.B2.D3.B4.B第二章仿真试题1、在软件的可行性研究中，可以从不同的角度对软件的可行性进行研究，其中是从软件的功能可行性角度考虑的是( B )A、经济可行性B、技术可行性C、操作可行性D、法律可行性2、在软件工程项目中，不随参与人数的增加而使软件的生产率增加的主要问题是( D )A、工作阶段间的等待时间B、生产原型的复杂性C、参与人员所需的工作站数D、参与人员之间的通信困难3、制定软件计划的目的在于尽早对欲开发的软件进行合理估价，软件计划的任务是( D )A、组织与管理B、分析与估算C、设计与测试D、规划与调度答案1.B2.D3.D第二章1.可行性研究的任务是什么?可行研究的任务：首先需要进行概要的分析研究，初步确定项目的规模，目标，约束和限制。
软件工程第2章-系统工程
软件工程第2章-系统工程软件工程第2章-系统工程本章将介绍软件工程中的系统工程概念和相关知识。
系统工程是软件开发过程中的关键环节，它涉及到对软件系统进行全面的规划、设计、建立和维护的过程。
以下是系统工程的详细内容。
1.系统工程概述系统工程是一种以系统思维为基础的工程方法，它通过对整个软件系统进行分析、设计和管理，以满足用户需求并达到预期目标。
系统工程关注整个软件生命周期，包括系统需求、设计、实现、部署和维护等各个阶段。
1.1 系统工程的基本原理系统工程遵循一系列基本原理，包括系统思维、综合性、阶段性、可行性和可靠性。
系统思维强调整体观念，综合性要求综合考虑各方面因素，阶段性强调分阶段开发，可行性要求方案可行，可靠性关注系统的可信度和稳定性。
1.2 系统工程的主要任务系统工程的主要任务包括需求分析、系统设计、系统实现、系统测试、系统部署和系统维护等。
需求分析阶段通过与用户沟通明确用户需求，系统设计阶段确定系统的整体架构和模块划分，系统实现阶段进行编码和集成，系统测试阶段验证系统功能和性能，系统部署阶段将系统交付给用户使用，并在系统维护阶段对系统进行维护和改进。
2.系统需求分析系统需求分析是系统工程的第一步，它确定系统需要实现的功能和性能要求。
在系统需求分析中，要对用户需求进行收集、分析和明确，同时要识别系统约束条件和非功能性需求。
2.1 用户需求收集用户需求收集通过与用户沟通、面谈和调查问卷等方式进行。
可以采用需求工作坊、原型演示和用户故事等方法来帮助收集用户需求。
2.2 用户需求分析用户需求分析是对用户需求进行整理和分类，识别出用户需求中的关键、重要和常见的部分，同时排除冗余和不合理的需求。
2.3 系统需求规格说明书在用户需求分析的基础上，可以编写系统需求规格说明书，明确系统的功能需求、性能要求和约束条件。
该文档是系统设计和开发的基础。
3.系统设计系统设计是基于系统需求规格说明书进行的，它主要包括系统架构设计、模块设计和界面设计等方面。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2.4 软件项目的调度
2.4.1 项目进度确定 2.4.2 项目调度的技术
2.4.1
项目进度确定
1、COCOMO模型估算 有组织方式： 半独立方式： 嵌 入 式： T＝2.5（MM）0.38 T＝2.5（MM）0.35 T＝2.5（MM）0.32
例：某程序的规模为32000条应交付的源指令，由已开发过类似程序 的内部分析员和程序员承担。该项目属于有组织方式，估算如下： 工作量：MM＝2.4（32）1.05＝91人-月
3、插值法估算
当某个软件项目的设计规模不能在表中直接查到时，需要使用插值法 求解。假如（x0,y0)和（x1,y1）是平面坐标系的两点，令（x,y）位于（x0,y0) 和（x1,y1）的连线上。当x0≤x≤x1时，
x x0 y y0 ( y1 y 0) x1 x0
例：设某项目规模为12800DSI，求其程序设计阶段的工作量与进度。 1）先求总工作量与进度： MM＝2.4（12.8）1.05＝35人-月 T＝2.5（35）0.38＝9.7个月 2）用插值公式求解编程阶段的工作量和进度百分比m和t。 m=65+((12.8-8)/(32-8))(62-65)=64.4 t=59+((12.8-8)/(32-8))(55-59)=58.2 3）计算编程阶段工作量、进度及人员数。 工作量：0.64 35pm=22pm 进 度：0.582 9.7m=5.6m FSP:22pm/5.6m=4.0FSP
1）事件最早时间EET：该事件可以发生的最早时间（图中圆圈内右上角 数字为EET）。计算规则如下：
考虑进入该事件的所有作业； 对于每个作业都计算它的持续时间与起始事件的EET之和； 选取上述和中的最大值作为该事件的最早时间EET。 例：对于上图中的事件4有两个作业（2－4和3－4），已知事件2的最早时间为2， 作业2－4的持续时间3小时，二者和为2＋3；事件3的最早时间为6，作业3－4的持 续时间为0（这是一个虚作业），和为6＋0，按照上述三条原则，事件4的最早间 为： EET=max{2+3,6+0}=6
MM＝2.8（KLOC）1.20
2、中级COCOMO模型
也有三种方式，并引入了15个开发成本因子，公式基本形式如下：
MM＝C.KLOCa. fi
i 1 15
C和a分别代表基本模型中的系数和指数，fi是成本因素，包括产 品因素、计算机因素、人员因素、项目因素等。当fi＝1时，中级 模型变为基本模型。 例题：一个嵌入式软件项目，估计有10000条可交付的源指令， 成本因子的乘积为1.35，其工作量为： MM＝2.8（10）1.201.35＝59人-月
2）事件最迟时间LET：在不影响工程进度的前提下，该事件可以发生的 最晚时间（图中圆圈内右下角数字为LET）。计算规则如下： 考虑离开该事件的所有作业； 从每个作业结束事件的最迟时间中减去该作业的持续时间； 选取上述差中的最小值作为该事件的最迟时间LET。 例：对于上图中的事件8最迟时间为： LET=min{21-6,20-0}=15 3）机动时间：某一作业可以晚发生或延长期限而不影响整个工期的时间 （写在图中代表该作业箭头下的括号内）。计算方法如下： 机动时间＝（LET）结束-（EET）开始-持续时间 例：作业2－4的（LET）结束为6， （EET）开始为2，持续时间3小时， 机动时间＝6-2-3＝1小时 4）关键路径：网络图中事件最早时间和最迟时间相同的路径。例如上图 中的关键路径为：1－2－3－4－6－8－10－11。
2.3 软件成本估计
2.3.1 参数方程法 2.3.2 COCOMO模型
2.3.1
参数方程法
1、静态单变量模型 Walston和Felix模型： E＝5.2L0.9 其中E是以人-月为单位的工作量，L是交付源码的千行数。 Doty Associates模型：
MM＝5.258I1.057
面向FP模型： E＝－13.39＋0.0545FP E＝60.627.72810－8FP3 E＝585.7＋15.12FP
第二章 软件工程管理技术
2.1 软件特征量 2.2 软件规模估计 2.3 软件成本估计
2.4 软件项目的调度 2.5 人员组织 2.6 软件质量管理
2. 1 软件特征量
2.1.1 特征量和指示器 2.1.2 面向尺寸的特征量 2.1.3 面向功能的特征量
2.1.1 特征量和指示器
1、特征量的定义（IEEE）：一个系统、部件或者过程的 一个给定属性的程度的定量度量。
2、动态多变量模型
LOC 3 B.( ) P E t4
又叫Putnam模型，其中E为工作量，单位为人-月，t为项 目期限，单位为月，B为特殊技术因子，P为生产率参数。 该模型的工作量与开发时间的4次方成反比，因此应合理 确定开发最小时间，公式如下：
tmin=8.14(LOC/P)0.43
2.3.2
加权因子 度量参数 用户输入数 用户输出数 用户查询数 文 件 数 外部接口数 总 计 计数 2 9 9 3 2 简单 3 4 3 7 5 一般 4 5 4 10 7 复杂 6 7 6 15 10 ＝6 ＝36 ＝27 ＝21 ＝10 100
FP＝ count-total(0.65+0.01Fi)＝107，其中Fi＝42
2、五类常见特征量： 软件规模：通常以程序的行数、千行数或功能点表示。 开发成本：软件开发与维护所需的资金数（RMB或$）。 开发期限：从开始设计到交付使用所需的时间。 开发工作量：通常以人-月或人-年表示。 软件质量：指开发过程中已检测的缺陷数和产品安装后平 均无故障运行时间。 3、指示器：一个指示器是由一个特征量或一组特征量构成， 能够提供软件开发过程、软件项目或产品自身状态的指示。
(1)该系统需要可靠的后备及恢复吗? (2)要求数据通讯吗? (3)有分布处理功能吗? (4)性能是关键的吗? (5)该系统将运行在一个现存的重负载的操作环境吗? (6)该系统需要在线数据输入吗? (7)在线数据输入要求输入事务是多屏幕或多个操作的吗？ (8)主文件是在线更新的吗? (9)输入、输出、文件和查询是复杂的吗? (10)内部处理是复杂的吗? (11)设计的编码是可再使用的吗? (12)转换和安装包括在设计中了吗? (13)该系统的设计是准备在不同组织的多处安装的吗? (14)该应用的设计是为了方便修改和用户容易使用的吗? 在标度0~5之间确定因子的值
表2.7 工作量及 量 小型（2KDSI） 中等（8KDSI） 中大（32KDSI） 大型（128KDSI）
规化和需求
产品设计 程序设计 详细设计 编程单元测试 集成测试
6%
16 68 26 42 16
6%
16 65 25 40 19
6%
16 62 24 38 22
20 12 16 4 2
24 15 22 4 2
30 22 28 5 3
24 16 22 4 2
4 5 4 10 7
96 80 88 40 14 318
FP＝ count-total(0.65+0.01Fi)＝372，其中Fi＝52
2、分析模型方法
从某一系统的分析模型（数据流程图）得出信息域的值， 然后计算FP特征量。
2.2.2
基于FP的估计
1、粗略估计方法 此方法首先要获得估计信息域的估计计数值、加权因子、 FP计数值以及总计计数值。 然后利用公式FP＝count-total(0.65+0.01Fi)计算功能点 数量。
表2.4 信息域值 乐观 可能 估计信息域的值 保守 估计计数 权值 FP计数
输入数量 输出数量 查询数量 文件数量 外部接口数量 计数总计
2.1.2 面向尺寸的特征量
面向尺寸的特征量是在正常的质量与生产率度量的前提下，用 已产生的软件编码的尺寸导出的特征量。
表2.1 面向尺寸的特征量
项目 项目1 项目2 项目3 ┇ 行 12100 27200 20200 工作量 人民币（万元） 文档页数 错误数 24 62 43 16.8 44.0 31.4 ┇ 365 1224 1050 134 321 256 缺陷数 29 86 64 人员数 3 5 6 ┇
生产率：32000DSI/91人-月＝352DSI/人-月
项目期限：T＝2.5（91）0.38＝14个月 平均人员配备：91人-月/14个月＝6.5FSP 其中DSI为应用交付的源指令数，FSP为等价全时软件人员数。
2、工作量与进度的阶段分布
主要讨论一个软件项目在不同阶段的工作量、时间及人员数目。
2.5 人员组织
2.5.1 项目组织机构 2.5.2 程序设计小组的组织
2.5.3 主程序员组
2.5.1
项目组织机构
1、广义组织机构图
2、组织图制作准则
1）合并广义图中相邻的功能，将人员配备少于2FSP的功能合并到相邻的功 能，除非：第一，它代表下属功能的管理；第二，它至少配备0.5FSP以上。 2）如果一个功能有7FSP以上，把它分解成一个管理者和一系列附属功能。 3）把任何管理者的控制面体质在7以下。 4）如果上述准则与经验常识冲突，则使用经验常识。
COCOMO模型
全称为可构造的成本模型（Constructive Cost Model)， 简称COCOMO模型 1、基本COCOMO模型
有组织方式。相对较小和简单的软件项目并由小的开发队伍进行。 MM＝2.4（KLOC）1.05 半独立方式。中等规模和复杂程度的软件项目，开发队伍有经验。 MM＝3.0（KLOC）1.12 嵌入方式。须在一组严格的硬件、软件和操作约束之内进行开发。
由上表可以推导出一些常用的面向尺寸的特征量： 错误数/KLOC 缺陷数/KLOC 元数/LOC LOC/人-月 错误数/人-月 其中元数/LOC和LOC/人-月代表了软件开发成本和软件的生产率。
2.1.3 面向功能的特征量
面向功能的特征量是使 用应用程序交付的功能度 的度量作为规范化值。一 般使用功能点作为面向功 能的特征量的度量。 功能点是根据软件信息 域内的直接度量的量和对 软件复杂程度的估计值计 算出来的。 功能点FP＝count-total(0.65+0.01Fi) 根据功能点可以得到一些面向功能的特征量： 错误数/FP 缺陷数/FP 文档页数/FP FP/人-月