《软件工程管理》PPT课件
合集下载
软件工程PPT课件
本课程的安排 Course Planning
授课时间：54学时 考核方式（平时+作业）20分+（闭卷考
试）80分
1
整体概述
概况一
点击此处输入相关文本内容 点击此处输入相关文本内容
概况二
点击此处输入相关文本内容 点击此处输入相关文本内容
概况三
点击此处输入相关文本内容 点击此处输入相关文本内容
2
讲授的内容 Contents
4
1.1 软件 Software
软件的概念与特征 软件的发展历程 软件的分类 软件开发的案例分析
5
软件的概念与特征
软件的定义
软件是程序和所有 使程序正确运行所需 要的相关文档和配置 信息。
Software = Program + Data + Document
软件的特征
➢ 软件是无形的 (intangible)
1950
1960
1970
1980
1990
2000
7
软件的分类
基于不同工程对象划分 基于软件规模的划分软件产品 Generic -由软件开发机构制 作，市场上公开销售，独立使用。
（ developed to be sold to a range of different customers）
➢ 软件副本制作简 单
➢ 软件无磨损
6
软件的发展历程
早期 •面向批处理 •有限的分布 •自定义软件
第二阶段 •多用户 •实时 •数据库 •软件产品
第三阶段 •分布式系统 •嵌入“智能” •低成本硬件 •消费者的影响
第四阶段 •强大的桌面系统 •面向对象技术 •专家系统 •人工神经网络 •并行计算 •网路计算机
授课时间：54学时 考核方式（平时+作业）20分+（闭卷考
试）80分
1
整体概述
概况一
点击此处输入相关文本内容 点击此处输入相关文本内容
概况二
点击此处输入相关文本内容 点击此处输入相关文本内容
概况三
点击此处输入相关文本内容 点击此处输入相关文本内容
2
讲授的内容 Contents
4
1.1 软件 Software
软件的概念与特征 软件的发展历程 软件的分类 软件开发的案例分析
5
软件的概念与特征
软件的定义
软件是程序和所有 使程序正确运行所需 要的相关文档和配置 信息。
Software = Program + Data + Document
软件的特征
➢ 软件是无形的 (intangible)
1950
1960
1970
1980
1990
2000
7
软件的分类
基于不同工程对象划分 基于软件规模的划分软件产品 Generic -由软件开发机构制 作，市场上公开销售，独立使用。
（ developed to be sold to a range of different customers）
➢ 软件副本制作简 单
➢ 软件无磨损
6
软件的发展历程
早期 •面向批处理 •有限的分布 •自定义软件
第二阶段 •多用户 •实时 •数据库 •软件产品
第三阶段 •分布式系统 •嵌入“智能” •低成本硬件 •消费者的影响
第四阶段 •强大的桌面系统 •面向对象技术 •专家系统 •人工神经网络 •并行计算 •网路计算机
软件工程PPT课件
02
需求分析的方法包括功能分析 、数据流图、实体关系图等。
03
需求分析过程中需要关注需求 的可实现性和可验证性，以确 保开发的软件能够满足用户的 需求。
需求规格说明
01
需求规格说明是软件需求工程的重要输出，它详细描述了软件 系统的功能、性能、安全等方面的要求。
02
需求规格说明应该清晰、准确、完整，并且易于理解和验证。
软件架构的重要性
软件架构决定了软件系统的性能、 可维护性、可扩展性和安全性等 关键特性，是软件设计过程中最 重要的环节之一。
常见的软件架构
常见的软件架构包括单体应用架 构、微服务架构、服务导向架构 等，不同的架构适用于不同的应 用场景。
数据设计
数据设计概述
数据设计是指对软件系统中的 数据进行规划、组织、存储和
06
软件维护工程
软件维护的定义与分类
总结词
软件维护是软件工程的重要环节，涉及对已交付软件产品的修改、完善和优化。
详细描述
软件维护是指在软件交付后，为了改正错误、改进性能或其他目的，对软件进行的修改活动。根据维护活动的内 容和性质，软件维护可分为纠错性维护、适应性维护、完善性维护和预防性维护。
软件维护的过程
管理的方法和过程。
数据模型
数据模型是数据设计的核心， 包括概念数据模型、逻辑数据 模型和物理数据模型等。
数据存储
数据存储是数据设计的关键环节 ，需要考虑数据的存储介质、存 储方式和存储容量等因素。
数据安全
数据安全是数据设计的重要考 虑因素，包括数据的加密、备
份、恢复和访问控制等。
界面设计
界面设计概述
需求规格说明
将收集到的需求整理成文档，明确软件的功能、性能、安全 性等要求。
软件工程完整教程ppt课件
敏捷开发模型
敏捷开发模型是一种轻量级的软 件开发过程模型，它强调团队合 作、快速响应变化和持续交付。
敏捷开发模型的优点是能够快速 响应需求变更，提高开发效率和 质量，适用于需求不稳定、变化 快的项目。
敏捷开发模型的主要实践包括： 短周期迭代、持续集成、自动化 测试、重构和持续改进等。
缺点是需要高素质的开发团队和 成熟的开发环境支持，且对项目 管理的要求较高。
去中心化应用开发
基于区块链技术，开发去中心化应用（DApps），实现数据的分 布式存储和处理。
智能合约编写与部署
利用区块链平台提供的智能合约编写工具，编写并部署智能合约， 实现自动化执行和信任保障。
区块链安全与隐私保护
针对区块链应用的安全和隐私需求，采用密码学、访问控制等技术 手段进行保护。
THANKS
界面设计规范
设计语言规范、组件规范、交互规范 等
编码实现
环境搭建、框架选择、模块划分 、编码实现等
IDE（如IntelliJ IDEA、Eclipse等 ）、版本控制工具（如Git）等
编码实现原则 编码实现步骤 编码实现规范 编码实现工具
可读性、可维护性、可扩展性、 性能等
命名规范、注释规范、代码风格 规范等
软件开发模型
软件开发模型包括瀑布模型、迭 代模型、螺旋模型等，不同的模 型适用于不同的项目需求。
软件开发方法
软件开发方法包括面向对象方法 、敏捷开发方法等，不同的方法 有不同的开发理念和实践。
软件质量管理
软件质量管理包括质量保证和质 量控制两个方面，旨在确保软件 的质量符合预期的标准和要求。
02
软件开发过程模型
组件化方法
将软件拆分为独立组件，便于单独维护和升级 。
软件工程课件(全)
03
识别项目中的关键路径，确保项目按计划进 行
04
及时调整项目计划，应对项目变更和不确定 性
风险管理策略制定
识别项目中的潜在风险， 包括技术风险、市场风险、 资源风险等
制定相应的风险应对策略 和措施，如风险规避、减 轻、转移和接受等
评估风险的概率和影响程 度，制定风险优先级列表
监控风险状态，及时调整 风险管理计划
质量改进
根据质量评估结果，制定相应的改进措施， 如优化性能、增强安全性等。
经验教训总结
对测试过程中遇到的问题进行总结，形成经 验教训，为后续项目提供参考。
06
项目管理与团队协作
项目计划制定与监控
01 制定详细的项目计划，包括项目目标、范围 、时间表、资源需求、成本估算等
02 设立项目里程碑，对项目进度进行阶段性监 控
开发方向。
持续集成和测试
03
迭代增量模型强调持续集成和测试的重要性，以确保每个迭代
周期都能交付高质量的软件产品。
03
需求分析与管理
需求获取与整理
确定需求来源
与客户、利益相关者、业务领 域专家等进行沟通，收集原始
需求。
需求分类
将收集到的需求按照功能、性 能、安全、易用性等方面进行 分类。
需求筛选
去除重复、模糊、不切实际的 需求，确保需求的准确性和可 行性。
处理变更请求
根据实际情况，决定是否接受变更请求，并 制定相应的实施计划。
跟踪和验证变更
对实施的变更进行跟踪和验证，确保变更的 正确性和完整性。
04
系统设计与实现
系统架构设计
分层架构
将系统划分为表示层、业务逻辑层和数据访问层，实现高内聚、 低耦合的设计。
软件工程课件PPT模板
软件工程思维导图
演讲人
202x-11-11
part one
01 默
认
章
a
第1章软 件工程概
述
d
第1章软 件工程概
述
默认章
b
第1章软 件工程概
述
e
第2章软 件需求工
程
c
第2章软 件需求工
程
f
第1章软 件工程概
述
a
第1章软 件工程概
述
d
第Байду номын сангаас章软 件设计基
础
默认章
b
第2章软 件需求工
程
e
第4章结 构化设计
方法
c
第2章软 件需求工
程
f
第5章软 件实现
默认章
0 1
第6章软件测 试
0 4
第7章uml建 模语言
0 2
第6章软件测 试
0 5
第7章uml建 模语言
0 3
第6章软件测 试
0 6
第8章面向对 象分析
默认章
0 1
第9章面向对 象设计
0 4
第10章软件维 护
0 2
第9章面向对 象设计
0 5
第10章软件维 护
0 3
第10章软件维 护
0 6
第11章软件项 目管理
默认章
第11章软件项目管理 第1章软件工程概述 期末演练测试卷 2019-2020学年第二学期期末考 试软件工程试卷
感谢聆听
演讲人
202x-11-11
part one
01 默
认
章
a
第1章软 件工程概
述
d
第1章软 件工程概
述
默认章
b
第1章软 件工程概
述
e
第2章软 件需求工
程
c
第2章软 件需求工
程
f
第1章软 件工程概
述
a
第1章软 件工程概
述
d
第Байду номын сангаас章软 件设计基
础
默认章
b
第2章软 件需求工
程
e
第4章结 构化设计
方法
c
第2章软 件需求工
程
f
第5章软 件实现
默认章
0 1
第6章软件测 试
0 4
第7章uml建 模语言
0 2
第6章软件测 试
0 5
第7章uml建 模语言
0 3
第6章软件测 试
0 6
第8章面向对 象分析
默认章
0 1
第9章面向对 象设计
0 4
第10章软件维 护
0 2
第9章面向对 象设计
0 5
第10章软件维 护
0 3
第10章软件维 护
0 6
第11章软件项 目管理
默认章
第11章软件项目管理 第1章软件工程概述 期末演练测试卷 2019-2020学年第二学期期末考 试软件工程试卷
感谢聆听
《软件工程资料》课件
数据库设计
根据业务需求，设计数据库结构、表关系和数据 类型等。
设计评审
对设计结果进行审查，确保其满足需求并具有可 实现性。
编码
选择编程语言和开发工具
根据设计结果和开发团队技术栈选择合适的 编程语言和开发工具。
代码审查
对编码结果进行审查，确保其符合编码规范 和设计要求。
编码实现
按照设计文档进行编码，实现软件功能。
单元测试
对每个模块进行测试，确保其功能正常。
测试
测试计划
制定详细的测试计划，明确测试目标、范围 、方法和资源等。
测试用例设计
根据测试计划设计具体的测试用例，包括输 入、预期输出和执行条件等。
测试执行
按照测试计划和测试用例进行测试，记录测 试结果和问题。
缺陷跟踪与管理
对测试过程中发现的问题进行跟踪和管理， 确保其得到及时修复。
设计评审定义
设计评审是指由一组专家和利益 相关者对软件设计进行评估和审 查的过程。
设计验证与评审的
目标
确保设计的正确性和可行性，及 时发现和纠正设计中的缺陷和错 误，提高软件质量。
设计模式与重构
设计模式定义
设计模式是一种解决常见问题的最佳实践，提供了 一种可重用的解决方案。
重构定义
重构是在不改变软件系统外部行为的前提下，对内 部结构进行改进和调整，以提高代码质量和可维护 性。
详细描述
通过自动化测试与性能测试，开发人 员可以快速发现和修复软件中存在的 问题和缺陷，提高
07
软件项目管理
项目计划与估算
项目计划制定
制定详细的项目计划，明确项目目标 、任务分配、时间安排等。
资源估算
根据项目需求，估算所需的人力、物 力、财力等资源，确保项目顺利进行 。
第13章 软件工程管理
a 4m b L 6
6
一、代码行技术（续）
优点：代码行较容易计算，现有许多软件估算模型基 于代码行 缺点： 仅用代码行代表整个软件不太合理； 用不同语言实现时代码行差别很大； 不适用于非过程语言。
7
13.1 度量软件规模（续）
二、功能点技术 功能点技术依据对软件信息域特性和软件复杂 性的评估结果，估算软件规模。这种方法用功能点 (FP)为单位，度量软件的规模。
25
三、COCOMO模型（续） (3)详细COCOMO模型(COCOMO2)：
估算公式
E a KLOC f i
b i 1
17
，T=3.0E0.33+0.2×(b-1.01)
其中E＝开发所需的人力(人月)； a＝模型系数(开发模式：组织式、嵌入式、半独立式)； KLOC＝估计的代码行数； b＝模型指数(对应着开发模式)； fi(i=1…17)是成本因素，包括生产因素、计算机因素、人员因素、工程 因素等17个方面。
9
二、功能点技术（续）
2、估算功能点的步骤 (1)计算未调整的功能点数UFP 把产品信息域的每个特性(即Inp、Out、Inq、Maf和Inf) 都分类成简单级、平均级或复杂级。根据其等级，为每个特 性都分配一个功能点数。用下式计算未调整的功能点数UFP UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf其中， ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级 别决定，如表13.1所示。
26
三、COCOMO模型（续）
模型系数 开发模式 组织式 半独立式 嵌入式 模型系数 a 3.2 3.0 2.8
27
三、COCOMO模型（续） COCOMO2采用了更加精细得多的b分级模型，这个模 型使用5个分级因素Wi(1≤i≤5): 划分成从甚低（Wi=5) 到特高（Wi=0)的6个级别 b= 1.01 1.01 Wi b的取值范围为1.01~1.26。 5个分级因素如下所述： （1） 项目先例性: 该项目的新奇程度。 （2） 开发灵活性: 约束多少。 （3） 风险排除度: 重大风险已被消除的比例。 （4） 项目组凝聚力: 开发人员相互协作度。 （5） 过程成熟度: 按照能力成熟度模型
软件项目管理基础课程(PPT-61张)可编辑全文
甘特图是做项目进度计划方法的重要方法，其 他方法有：
关键日期表：这是最简单的一种进度计划表， 它只列出一些关键活动和进行的日期。
关键路线法
计划评审技术（Program Evaluation and Review Technique，简称PERT）。
Gantt图能很形象地描绘任务分解情况，以及每 个子任务(作业)的开始时间和结束时间，因此 是进度计划和进度管理的有力工具。它具有直 观简明和容易掌握、容易绘制的优点。
这种管理在技术工作开始之前就应开始，在软 件从概念到实现的过程中继续进行，当软件工 程过程最后结束时才终止。
项目管理分九个知识领域，分别是成本 管理、质量管理、时间管理、范围管理、 人力资源管理、沟通管理、风险管理、 采购管理和整体管理。
其中时间，质量和成本管理构成了三角 形
项目管理包括5种基本活动
项目管理概述
软件项目管理是为了使软件项目能够按照预定 的成本、进度、质量顺利完成，而对成本、人 员、进度、质量、风险等进行分析和管理的活 动。
软件项目管理的根本目的是为了让软件项目， 尤其是大型项目的整个软件生命周期（从分析、 设计、编码到测试、维护全过程）都能在管理 者的控制之下，以预定成本，按期、按质的完 成软件，然后交付用户使用。
项目终止：提交项目结果并收集项目历史。主 要活动有
交付：由客户验收测试和系统安装 2个子活动组 成。
客户验收测试：软件系统由客户按照项目协议中 制定的验收准则进行评价。
安装：系统被配置在目标环境中，并且交付文档。 安装可能包括用户培训和实施阶段。
事后分析：项目经理和团队领导收集项目历史资 料以获得经验。
初始的软件体系结构:它关注于软件体系结构， 特别是把系统分解成子系统。
软件工程培训课件(PPT)
编码效率技巧：在保证代 码质量的前提下，应该尽 可能提高编码效率，减少 不必要的重复工作。
单元测试的方法与工具
测试用例设 计
执行测试流 程
测试工具选 择
测试结果分 析和报告
集成测试的方法与工具
测试方法：自 下而上、自上
而下
测试工具： JUnit、
Te s t N G 、 Selenium等
测试目的：检 测模块之间的 接口是否正确
方法：采用版本控制、变更 控制、状态报告等手段进行
管理
感谢观看
汇报人：
软件风险管理的方法与策略
风险识别：识别潜在的风险和 问题
风险评估：评估风险的大小和 影响
风险应对：制定应对策略和措 施
风险监控：持续监控风险的变 化和进展
软件配置管理的基本概念与方法
目的：确保软件产品的完整 性、一致性和可追溯性
范围：包括文档、程序、数 据等所有软件工程产品
定义：软件配置管理是一种 标识、组织和控制修改的技 术
质量控制：通过测试、统计等方 法，对软件开发过程中的质量进 行监控和评估，及时发现和解决 问题。
添加标题
添加标题
添加标题
添加标题
质量保证：通过一系列的质量保 证活动，如代码审查、测试、文 档编写等，确保软件质量的稳定 性和可靠性。
工具和技术：使用一些工具和技 术来辅助软件质量管理，如代码 审查工具、测试工具、项目管理 工具等。
编写要求：清晰明了，易于理解，方便查阅，及时更新
编写目的：方便用户和系统管理员使用和维护系统
06
软件工程管理
软件项目计划与进度安排
定义项目目标和范围 确定关键路径和里程碑 分配资源和工作任务 监控和控制项目进度
软件工程课件(全)ppt
第1章 1.2软件工程
1.2.1 软件工程的定义和目标
为了克服软件危机，1968年10月在北大西洋公约组织（NATO）召开的计 算机科学会议上，Fritz Bauer首次提出“软件工程”的概念。
按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一 条主要出路。
软件工程的主要思想是强调软件开发过程中应用工程化原则的重要性。软 件工程的目标是实现软件的优质高产。软件工程的目的是在经费的预算范围内， 按期交付出用户满意的、质量合格的软件产品。
第1章 1.1软件与软件危机
1.1.3 软件危机
2. 软件危机产生的原因
（1）忽视软件开发前期的调研和需求分析工作。 （2）缺乏软件开发的经验和有关软件开发数据的积累，使得开发计划很难制定。 （3）开发过程缺乏统一的、规范化的方法论指导。 （4）忽视与用户、开发组成员间的及时有效的沟通。 （5）文档资料不规范或不准确。导致开发者失去工作的基础，管理者失去管理的依据。 （6）没有完善的质量保证体系。
第1章 1.1软件与软件危机
1.1.1 软件的定义及其特点
2.软件具有下列特点：
比硬件发展慢
是逻辑产品
软件
生产与硬件不同 不会磨损和老化
成本高、风险高
手工开发为主
依赖硬件
第1章 1.1软件与软件危机
1.1.2 软件的发展及其分类
1.软件技术的发展
程序设计
程序系统
软件工程
第1章 1.1软件与软件危机
第1章 1.1软件与软件危机
1.1.3 软件危机
3. 软件危机解决途径
要解决软件危机问题，需要采取以下措施： （1）使用好的软件开发技术和方法。 （2）使用好的软件开发工具，提高软件生产率。 （3）有良好的组织、严密的管理，各方面人员相互配合共同完成任务。 为了解决软件危机，既要有技术措施（好的方法和工具），也要有组织管理措施。软件工 程正是从技术和管理两方面来研究如何更好地开发和维护计算机软件的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
①项目进度安排； ②人员的分配与组织。
11.2 软件估算模型 (Resource Estimation Model)
11.2.1 资源估算模型 (Resource Estimation Model)
●资源模型用来估算软件在开发中花费的 资源，如开发时间、开发人数以及工作量 等（人-月 或 人- 年）。
●基本COCOMO模型是静态单变量模型，它 将软件分类为：组织型、半独立型和嵌入型 3 种类型，每类分别使用一组不同的模型方程
（见表11.1）。 例11.1 有一个嵌入型的电信处理程序，程序
规模为10000行。计算所需的工作量与开发时间。 E = 2.8 × 10 1.20 = 44.4 (人-月) T = 2.5 × 44.4 0.32 = 8.4 (月)
法); ●特尔斐( Delphi )法: ①多个专家各自填“成本估计表”; ②综合专家意见，把摘要意见通知大家; ③开始新一轮估计; ④多次反复，直到专家意见接近。
(2)然后在项目内部（按阶段或任务单元）进 行成本分配。 ●自顶向下成本估计的缺点是：对某些局部问 题或特殊困难容易低估；如果所开发的软件缺 乏可以借鉴的经验，估计时就可能出现较大的 误差。
PROGRAM DESIGN
PROGRAM IMPLEMENTATION
UNIT TESTING
INTEGRATION TESTING
SYSTEM TESTING
SYSTEM DELIVERY
MAINTENANCE
调节因子
调节值范围
例11.1中 使用的值
要求的可靠性等级
0.75 - 1.40
1.00
数据库规模
0.94 - 1.16
0.94
产品复杂度
0.70 - 1.65
1.30
对程序执行时间的约束
1.00 - 1.66
1.11
对程序占用存储容量的约束
1.00 - 1.56
1.06
开发环境的变动
0.87 - 1.30
1.静态单变量资源模型 资源 = c1 × (估计的软件特征) c2
其中: ●资源为开发工作量 E(人-月)、开发时间 T(月) 或开发人数 P； ●“估计的软件特征”通常用源程序长度L(千 行)表示; ● c1、c2为依赖于开发环境和应用领域的2个 经验常数。
如： E = 5.1 × L 0.91 (人-月) T = 2.47 × E 0.35 (月)
1.00
开发环境的响应时间
0.87 - 1.15
1.00
分析员水平
1.46 - 0.71
0.86
程序员水平
1.42 - 0.70
0.86
对应用领域的熟悉程度
1.29 - 0.82
1.00
对开发环境的熟悉程度
1.21 - 0.90
1.10
对所用语言的熟悉程度
1.14 - 0.95
1.00
开发方法的现代化
2. Putnam (普特南)资源模型 ●Putnam 资源模型是动态多变量资源模型。 用以下的方程式表示：
K = L3 / ( c3 T4 ) 其中: L (行)：源程序长度。 T (年)：开发时间。 K (人-年)： 全生存周期工作量。
c: 与开发环境有关的常数。
11.2.2 COCOMO模型 （COnstructive COst MOdel，结构性 成本模型） ●COCOMO模型分为基本COCOMO模 型、中间COCOMO模型 和 详细 COCOMO模型三种。
人力
②
①
③
td
t
图11.5 Rayleigh - Norden 曲线
● td 相当于软件开发完成的时间; ● 用虚线画出来的矩形,显示了平均使用人力的问题
：①浪费的人力 ②不足的人力 ③过晚的人力。
SOFTWARE DEVELOPMENT STEPS
REQUIREMENTS ANALYSIS
SYSTEM DESIGN
11.4 人员的分配与组织 ●各个开发阶段需要的人力并不相同。 一般地说, 计划与分析阶段只需要很少 的人; 概要设计的人多一些; 详细设计 的人又多一些; 编码和测试阶段的人数 最多; 在运行初期, 需要较多的人参加 维护, 但很快就可以减少下来, 只需保 Rayleigh-Norden 曲线
1.24 - 0.82
0.91
软件工具的数质量
1.24 - 0.83
1.10
完成时间的限制
1.23 - 1.10
1.00
11.3 软件成本估计 ●软件成本估计方法有主要３类：自顶 向下成本估计、由底向上成本估计和算 法模型估计。
１. 自顶向下成本估计 (1)首先估算总成本(可以采用特尔斐专家估计
第十一章 软件工程管理
Chapter 11 Software Engineering
Management
11.1 管理的目的与内容
●管理的目的：按预定的时间和费用，成功地 完成软件的计划、开发和维护任务。 ●管理的内容
1.费用管理 ①估算软件的开发费用; ②管理开发费用的有效使用。
2.质量管理（包括配置管理） 3.项目的其它管理
●中间COCOMO模型以静态单变量模型为基 础，增加15个工作量调节因子，是静态多变量 模型。
表11.1 不同类型软件的 COCOMO模型
软件 类别
组织型
半独立 型
嵌入型
模型 方程
适用范围
E=3.2×L1.05 T=2.5×E0.38
高级语言应用程序，如科学 计算、数据处理、企业管理 程序等规模较小的软件产品
2. 由底向上成本估计
(1)先将开发任务分解为许多子任务; (2)子任务再分成子子任务,直到每一个任务单元; (3)估计各个任务单元的成本; (4)汇合成项目总成本。 ●由底向上成本估计的缺点是：具体工作人员往往 只注意到自己范围内的工作，对涉及全局的花费可能 估计不足，可能使成本估计偏低。 3. 算法模型估计 ●算法模型就是资源模型，要选择适用的模型。 ●算法模型估计法常与自顶向下估计或由底向上估 计结合使用。
E=3.0×L1.12 T=2.5×E0.35
大多数实用程序，如编辑程 序、连接程序、编译程序等。 （规模较大的软件产品）
E=2.8×L1.20 T=2.5×E0.32
与硬件关系密切的程序，如 操作系统、 数据库管理系统、 实时处理与控制程序等。
属性
产品 属性
计算机 属性
人员 属性
项目 属性
表11.2 调节因子和它的值范围
11.2 软件估算模型 (Resource Estimation Model)
11.2.1 资源估算模型 (Resource Estimation Model)
●资源模型用来估算软件在开发中花费的 资源，如开发时间、开发人数以及工作量 等（人-月 或 人- 年）。
●基本COCOMO模型是静态单变量模型，它 将软件分类为：组织型、半独立型和嵌入型 3 种类型，每类分别使用一组不同的模型方程
（见表11.1）。 例11.1 有一个嵌入型的电信处理程序，程序
规模为10000行。计算所需的工作量与开发时间。 E = 2.8 × 10 1.20 = 44.4 (人-月) T = 2.5 × 44.4 0.32 = 8.4 (月)
法); ●特尔斐( Delphi )法: ①多个专家各自填“成本估计表”; ②综合专家意见，把摘要意见通知大家; ③开始新一轮估计; ④多次反复，直到专家意见接近。
(2)然后在项目内部（按阶段或任务单元）进 行成本分配。 ●自顶向下成本估计的缺点是：对某些局部问 题或特殊困难容易低估；如果所开发的软件缺 乏可以借鉴的经验，估计时就可能出现较大的 误差。
PROGRAM DESIGN
PROGRAM IMPLEMENTATION
UNIT TESTING
INTEGRATION TESTING
SYSTEM TESTING
SYSTEM DELIVERY
MAINTENANCE
调节因子
调节值范围
例11.1中 使用的值
要求的可靠性等级
0.75 - 1.40
1.00
数据库规模
0.94 - 1.16
0.94
产品复杂度
0.70 - 1.65
1.30
对程序执行时间的约束
1.00 - 1.66
1.11
对程序占用存储容量的约束
1.00 - 1.56
1.06
开发环境的变动
0.87 - 1.30
1.静态单变量资源模型 资源 = c1 × (估计的软件特征) c2
其中: ●资源为开发工作量 E(人-月)、开发时间 T(月) 或开发人数 P； ●“估计的软件特征”通常用源程序长度L(千 行)表示; ● c1、c2为依赖于开发环境和应用领域的2个 经验常数。
如： E = 5.1 × L 0.91 (人-月) T = 2.47 × E 0.35 (月)
1.00
开发环境的响应时间
0.87 - 1.15
1.00
分析员水平
1.46 - 0.71
0.86
程序员水平
1.42 - 0.70
0.86
对应用领域的熟悉程度
1.29 - 0.82
1.00
对开发环境的熟悉程度
1.21 - 0.90
1.10
对所用语言的熟悉程度
1.14 - 0.95
1.00
开发方法的现代化
2. Putnam (普特南)资源模型 ●Putnam 资源模型是动态多变量资源模型。 用以下的方程式表示：
K = L3 / ( c3 T4 ) 其中: L (行)：源程序长度。 T (年)：开发时间。 K (人-年)： 全生存周期工作量。
c: 与开发环境有关的常数。
11.2.2 COCOMO模型 （COnstructive COst MOdel，结构性 成本模型） ●COCOMO模型分为基本COCOMO模 型、中间COCOMO模型 和 详细 COCOMO模型三种。
人力
②
①
③
td
t
图11.5 Rayleigh - Norden 曲线
● td 相当于软件开发完成的时间; ● 用虚线画出来的矩形,显示了平均使用人力的问题
：①浪费的人力 ②不足的人力 ③过晚的人力。
SOFTWARE DEVELOPMENT STEPS
REQUIREMENTS ANALYSIS
SYSTEM DESIGN
11.4 人员的分配与组织 ●各个开发阶段需要的人力并不相同。 一般地说, 计划与分析阶段只需要很少 的人; 概要设计的人多一些; 详细设计 的人又多一些; 编码和测试阶段的人数 最多; 在运行初期, 需要较多的人参加 维护, 但很快就可以减少下来, 只需保 Rayleigh-Norden 曲线
1.24 - 0.82
0.91
软件工具的数质量
1.24 - 0.83
1.10
完成时间的限制
1.23 - 1.10
1.00
11.3 软件成本估计 ●软件成本估计方法有主要３类：自顶 向下成本估计、由底向上成本估计和算 法模型估计。
１. 自顶向下成本估计 (1)首先估算总成本(可以采用特尔斐专家估计
第十一章 软件工程管理
Chapter 11 Software Engineering
Management
11.1 管理的目的与内容
●管理的目的：按预定的时间和费用，成功地 完成软件的计划、开发和维护任务。 ●管理的内容
1.费用管理 ①估算软件的开发费用; ②管理开发费用的有效使用。
2.质量管理（包括配置管理） 3.项目的其它管理
●中间COCOMO模型以静态单变量模型为基 础，增加15个工作量调节因子，是静态多变量 模型。
表11.1 不同类型软件的 COCOMO模型
软件 类别
组织型
半独立 型
嵌入型
模型 方程
适用范围
E=3.2×L1.05 T=2.5×E0.38
高级语言应用程序，如科学 计算、数据处理、企业管理 程序等规模较小的软件产品
2. 由底向上成本估计
(1)先将开发任务分解为许多子任务; (2)子任务再分成子子任务,直到每一个任务单元; (3)估计各个任务单元的成本; (4)汇合成项目总成本。 ●由底向上成本估计的缺点是：具体工作人员往往 只注意到自己范围内的工作，对涉及全局的花费可能 估计不足，可能使成本估计偏低。 3. 算法模型估计 ●算法模型就是资源模型，要选择适用的模型。 ●算法模型估计法常与自顶向下估计或由底向上估 计结合使用。
E=3.0×L1.12 T=2.5×E0.35
大多数实用程序，如编辑程 序、连接程序、编译程序等。 （规模较大的软件产品）
E=2.8×L1.20 T=2.5×E0.32
与硬件关系密切的程序，如 操作系统、 数据库管理系统、 实时处理与控制程序等。
属性
产品 属性
计算机 属性
人员 属性
项目 属性
表11.2 调节因子和它的值范围