【软件工程】软件工程知识点提纲8
【软件工程】软件工程知识点提纲8
- 1. 软件规模的度量和估算
- 1.1 代码行技术
- 1.2 功能点技术
- 2. 软件工作量估算
- 2.1 分解技术
- 2.2 经验模型
- 3. 工作量估算
- 4. 进度计划
- 4.1 估算开发时间
- 4.2 Gantt图
- 4.3 工程网络
- 4.4 估算工程进度
- 4.5 关键路径
- 4.6 机动时间
- 5. 软件人员组织
- 6. 软件质量保证
- 7. 软件配置管理
1. 软件规模的度量和估算
代码行技术、功能点技术
1.1 代码行技术
为了使得对程序规模的估计值更接近实际值,可以由多名有经验的软件工程师分别做出估计。
每个人都估计程序的最小规模（a）、最大规模（b）和最可能的规模（m），分别算出这3种规模的平均值a ̅、b ̅、和m ̅之后，再用下式计算程序规模的估计值：
L=(a ̅+b ̅+4m ̅)/6
1.2 功能点技术
- 信息域特点
- 输入项数（Inp）：用户向软件输入的项数，这些输入给软件提供面向应用的数据。
- 输出项数（Out）：软件向用户输出的项数，它们向用户提供面向应用的信息。
- 查询数（Inq）：查询即是一次联机输入，它导致软件以联机输出方式产生某种即时响应。
- 主文件数（Maf）：逻辑主文件的数目。
- 外部接口数（Inf）：机器可读的全部接口的数量，用这些接口把信息传送给另一个系统。
- 估算功能点的步骤
- 计算未调整的功能点数UFP
首先，把产品信息域的上述五个特性（Inp、Out、Inq、Maf和Inf）都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如，一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，而一个复杂级的输入项分配6个功能点）。
UFP=a_1×Inp+a_2×Out+a_3×Inq+a_4×Maf+a_5×Inf
- 计算技术复杂性因子TCF
影响因素的确定：根据软件的特点，为每个因素分配一个从0（不存在或对软件规模无影响）到5（有很大影响）的值。然后，用下式计算技术因素对软件规模的综合影响程度DI（其中F_i表示该技术因素的影响因素）：
技术复杂性因子TCF由下式计算：
TCF=0.65+0.01×DI
因为DI的值在0～70之间,所以TCF的值在0.65～1.35之间。- 计算功能点数FP
FP=UFP×TCF
2. 软件工作量估算
分解技术、经验模型
2.1 分解技术
纵向为分解模块
横向为交流、计划、风险分析、设计、编程、测试等模块，单位为人月
2.2 经验模型
公式给出再进行计算
3. 工作量估算
- 静态单变量模型
E=A+B×（ev）^C
A、B、C经验数据导出的常数
E以人月为单位的工作量
ev估算变量（KLOC或FP）
KLOC千行代码数
- 面向KLOC的估算模型
- Walston_Felix模型
E=5.2×（KLOC）^0.91- Bailey_Basili模型
E=5.5+0.73×（KLOC）^1.16- Boehm简单模型
E=3.2×（KLOC）^1.05- Doty模型（在KLOC>9时使用）
E=5.288×（KLOC）^1.047- 面向FP的估算模型
- Albrecht&Gaffney模型
E=-13.39+0.0545EP- Maston，Barnett和Mellichamp模型
E=585.7+15.12EP- 动态多变量模型
E=（LOC×B0.333/P）3×（1/t）^4
E以人月或人年为单位的工作量
t以月或年为单位的项目持续时间
B特殊技术因子：对于较小的程序KLOC=5~15，B=0.16；对于超过70KLOC的程序，B=0.39
P是生产率参数：开发实时嵌入式软件P=2000；开发电信系统和系统软件P=10000；对于商用应用系统来说P=28000- COCOMO2模型
E开发工作量（以人月为单位）
a是参数模型
KLOC是估计的源代码行数（以千行为单位）
b是模型指数
f_i （i=1~17）是成本因素
为了确定工作量方程中模型指数b的值，原始的COCOMO模型把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值（分别是1.05，1.12和1.20）。COCOMO2采用了更加精细得多的b分级模型，这个模型使用5个分级因素W_i(1≤i≤5),其中每个因素都划分成从甚低（W_i=5）到特高（W_i=0）的6个级别，然后用下式计算b的数值：
因此，b的取值范围为1.01～1.26。
4. 进度计划
4.1 估算开发时间
- Walston_Felix模型
T=2.5E^0.35- 原始的COCOMO模型
T=2.5E^0.38- COCOMO2模型
T=3.0E^(0.33+0.2×（b-1.01）)- Putnam模型
T=2.4E^(1/3)
E是开发工作量（以人月为单位）
T是开发时间（以月为单位）
4.2 Gantt图
例子：油漆工刷墙
首先刮掉旧漆，然后刷上新漆，最后清除溅在窗户上的油漆。一共分配了15名工人去完成这项工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。
思路：由5名工人用刮板刮掉第1面墙上的旧漆（这时其余10名工人休息），当第1面墙刮净后，另外5名工人立即用刷子给这面墙刷新漆（与此同时拿刮板的5名工人转去刮第2面墙上的旧漆），一旦刮旧漆的工人转到第3面墙而且刷新漆的工人转到第2面墙以后，余下的5名工人立即拿起刮刀去清除溅在第1面墙窗户上的油漆……。这样安排使每个工人都有活干，因此能够在较短的时间内完成任务。
假设木板房的第2、4面墙的长度比第1、3面墙的长度长一倍，此外，不同工作需要用的时间长短也不同，刷新漆最费时间，其次是刮旧漆，清理油漆需要的时间最少。下表列出了估计每道工序需要用的时间。可以使用Gantt图描绘上述流水作业过程：
在时间为零时开始刮第1面墙上的旧漆，两小时后刮旧漆的工人转去刮第2面墙，同时另5名工人开始给，1面墙刷新漆，每当给一面墙刷完新漆之后，第3组的5名工人立即清除溅在这面墙窗户上的漆。从下图可以看出，12小时后刮完所有旧漆，20小时后完成所有墙壁的刷漆工作，再过2小时后清理工作结束。因此全部工程在22小时后结束，如果用前述的第一种做法，则需要36小时。
4.3 工程网络
上图事件2既是作业1—2（刮第1面墙上的旧漆）的结束，又是作业2—3（刮第2面墙上旧漆）和作业2—4（给第1面墙刷新漆）的开始。也就是说，只有第1面墙上的旧漆刮完之后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个作业。工程网络显式地表示了作业之间的依赖关系。
上图中还有一些虚线箭头，它们表示虚拟作业，也就是事实上并不存在的作业。例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始（作业4—6）。但是，在开始给第2面墙刷新漆之前，不仅必须已经给第1面墙刷完了新漆，而且第2面墙上的旧漆也必须已经刮净（事件3）。也就是说，在事件3和事件4之间有依赖关系，或者说在作业2—3（刮第2面墙上旧漆）和作业4—6（给第2面墙刷新漆）之间有依赖关系，虚拟作业3—4明确地表示了这种依赖关系。注意，虚拟作业既不消耗资源也不需要时间。
4.4 估算工程进度
先将每个作业分成开始和结束，连接关系，以最大值依赖关系顺序计算最早时刻，以最小值依赖关系逆序计算最迟时刻）
例：事件4的最早时刻：EET=max{2+3，6+0}=6
事件10的最迟时刻：LET=23-2=21
事件9的最迟时刻：LET=21-1=20
事件8的最迟时刻：LET=min{21-6，20-0}=15
4.5 关键路径
事件的最早时刻和最迟时刻相同
4.6 机动时间
动机时间=（LET）_结束-（EET）_开始-持续时间
5. 软件人员组织
- 民主制程序员组（非正式的组织方式）
小组成员完全平等，享有充分民主，通过协商做出技术决策。小组成员之间的通信是平行的，若小组内有n个成员﹐则可能的通信信道共有n（n-1）/2条。程序设计小组的人数不能太多，否则组员间彼此通信的时间将多于程序设计时间。优点：组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码；组员们享有充分民主，小组有高度凝聚力，组内学术空气浓厚，有利于攻克技术难关。- 主程序员组
因为软件开发人员多数比较缺乏经验；程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；多渠道通信很费时间，将降低程序员的生产率。- 现代程序员
6. 软件质量保证
- 软件质量：与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体。
- 功能与性能方面：软件应该能够按照既定的要求进行工作，与明确规定的功能和性能需求一致；软件要保证能够可靠的工作，合法的输入下正确运行，非法输入和意外事件可安全处理。
- 软件结构方面：
- 要求系统内部结构清晰，易于软件人员阅读和理解，方便对软件的修改和维护
- 要求系统具备良好的人机交互界面，方便用户使用
- 开发标准与文档方面：软件开发应该与明确成文的开发标准相一致，而且要遵循一些软件开发准则，软件文档资料也必须齐全。
- 软件质量保证
- 应用技术手段：软件质量保证活动开始于帮助分析员获得高质量的规格说明书，帮助设计员应用高效的技术方法和工具，并且始终贯穿整个开发过程。
- 组织技术评审：在软件开发过程的每个阶段结束后，都需要组织技术评审，可以及早发现软件开发过程中可能引起的潜在错误，并对质量进行评价。
- 加强软件测试：软件测试是软件质量保证的重要手段，可以发现软件中大多数隐蔽的错误。
- 推行软件工程标准：一旦标准确定，就应该重视标准，并在软件开发中统一遵循。
- 控制软件变更：软件质量的一个主要威胁来自于对软件的修改和变更。在修改的过程中常常会引起一些新的潜在错误。因此，应严格控制软件的修改和变更。
- 对软件质量进行度量：软件质量保证的一个重要目标也是对软件质量进行跟踪，这就需要对软件质量进行度量，并对软件质量情况及时记录和报告。
7. 软件配置管理
- 软件配置
- 软件配置项
- 基线
- 软件配置管理过程
- 标识软件配置中的对象
- 版本控制
- 变化控制
- 配置审计
- 状态报告
【软件工程】软件工程知识点提纲8相关推荐
- 【软件工程】软件工程知识点提纲7
[软件工程]软件工程知识点提纲7 1. 类与实例 2. 类与类之间的关系 3. 基于用例的需求分析,建立用例模型 4. 基于类的需求分析,建立对象模型 5. 面向对象的软件设计,用组件图描述软件结构 ...
- 软件工程详细知识点（上）
文章目录 一.软件工程概述 1.软件与软件危机 2.软件工程 3.软件开发模型 二.可行性研究 三.需求分析 1.结构化分析及建模(重点掌握) ++软件设计 四.概要设计 1.模块独立性 2.软件结构 ...
- TUT 2020年软件工程期末复习提纲
软件工程期末复习提月工 目录概览 第一章 软件工程的基础知识 1.软件危机 定义:软件危机是指再计算机软件的开发和维护过程中所遇到的一系列严重问题. 软件危机包含下述两方面的问题: 如何开发软件,以满 ...
- 软件工程期末复习提纲、主要内容
第一章 软件工程的范畴 软件工程 软件工程是一门学科 目的是生产出没有错误的软件 以工程学的思维去进行软件设计.软件开发.软件软件运维的一种方法论,按时并且在预算范围内交付,满足用户的需求. 软件危机 ...
- 软件工程导论知识点汇总
文章目录 一.填空题 二.简答题 专为大学生期末创造奇迹整理的知识点 一.填空题 1.软件是一种逻辑产品 2.软件开发方法是指导软件开发的一系列规则和约定 3.软件生存周期中花费最多的阶段是软件维护阶 ...
- 广州大学《软件工程》软件工程课程知识点
一.知识点列举: 软件工程:软件危机:软件模型:软件工程知识体系:软件需求:需求分析:UML:用例图:用例描述:类图:顺序图:状态图:活动图:ER图:软件测试:黑盒测试:白盒测试:软件维护:软件质量. ...
- 【软件工程】知识点梳理（全）
文章目录 (一)软件工程学概述 1.[软件] 2.[软件危机] 3.[软件工程] 4.[软件工程方法学] 5.[软件生命周期] 6.[软件过程] 7.[软件生命周期模型] 8.[可行性研究] 9.[需 ...
- 数据流图软件_软件工程导论知识点梳理之概念题
1. 软件的定义:软件是程序.数据及开发.使用和维护程序需要的所有文档的完整集合. 例:在信息处理和计算机领域内,一般认为软件是程序.文档和数据. 2.软件的分类: 按照应用场景:系统/应用软件 按照 ...
- 软件工程详细设计说明书_软件工程导论知识点梳理之简答题
1. 软件危机的表现形式 对软件开发成本和进度估计不准确 已完成的软件不符合用户需求 软件产品质量差,可靠性得不到保证 软件产品可维护性差 软件成本在计算机总成本中的比例逐渐变大 软件开发生产率提高速 ...
最新文章
- 删除时存在依赖_从一次线上故障来看redis删除机制
- python __init__ (初始化对象时候自动调用) 与代表class对象自身的self
- python添加excel模块_python操作Excel模块openpyxl
- nyoj 776 删除元素
- python事件触发机制_Python3-事件驱动、IO模型和触发方式
- 找出OData service出错根源的小技巧
- 篮球战术谈之1-2-2进攻法
- 余弦相似度 高维数据_海量高维数据与近似最近邻
- Kalman filter—直观理解
- mysql数据库隔离级别 实现原理_MySQL事务及Spring隔离级别实现原理详解
- db2如何锁定一张表_如何通过一张表，提高20%的工作效率？
- windows 8授权概览
- lora终端连接云服务器_云服务器如何连接LoRa网关
- 亲民地理-第39期-佛山（2）南风古灶_我是亲民_新浪博客
- 软件测试概述基本介绍
- 孙卫琴——缅怀张孝祥老师（原文）
- 页面提示“百度未授权使用地图API，可能是因为您提供的密钥不是有效的百度LBS开放平台密钥，或此密钥未对本应用的百度地图JavaScriptAPI授权。您可以访问如下网址了解如何获取有效的密钥：ht”
- Ubuntu分区扩容
- html给页面整体添加左右边距_打印html页面时的边距
- [小红猪]算法：人工智能的新曙光