软件工程第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)的整体开发过程
极限编程
未完成的任务 用户故事 交付计划 项目速率
新用户故事 新项目速率
共享的信息
能力成熟度模型的结构
能力成熟度等级
初始级 可重复级 已定义级 已管理级 优化级
- 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/人-月