-
软件工程三要素
-
过程
-
方法
-
工具
-
-
软件过程的定义
软件过程是用于软件开发及维护的一系列活动、方法及实践。
-
常见软件过程分类(五大类)
-
客户-供应商过程:内部直接影响到客户、外部直接影响开发、向客户交付软件以及软件正确操作与使用的过程。
-
工程过程:软件系统、产品的定义、设计、实现以及维护的过程。
-
支持过程
-
管理过程:整个软件生命周期中为工程过程、支持过程和客户-供应商过程的实践活动提供指导、跟踪和监控的过程。
-
组织过程
-
-
常见软件过程(主要列举管理过程)
-
项目管理:计划、跟踪和协调项目执行及生产所需资源的管理过程。(主要关注时间、成本)
-
质量管理:对项目产品和服务的质量加以管理,从而获得最大的客户满意度。(主要关注质量)
-
风险管理:整个项目的生命周期中对风险不断的识别、诊断和分析,回避风险、降低风险或消除风险,并在项目以及组织层次上建立有效的风险管理机制。
-
子合同管理:选择合格的子合同商并对其进行管理的过程。
-
-
定义:软件质量是软件产品满足明确或隐含需要能力的性能和特性的总体。
-
软件质量度量模型的组成:
-
软件质量特性
-
软件质量子特性
-
软件质量度量评价标准
-
-
六个一级质量特性
-
功能性
-
可靠性
-
易用性
-
效率
-
可维护性
-
可移植性
-
-
一级特性对应的二级特性(选择题)
-
质量计划:确定项目应达到的质量标准,以及如何满足质量标准的计划安排和方法。
-
质量成本:为达到产品或服务质量而付出所有努力的总成本。
-
预防成本
-
评价成本
-
失效成本
-
-
-
质量保证:确保项目达到有关标准而开展的有计划、有组织的工作活动。
-
正规的质量评价:质量审计
-
总结性的质量评价:质量改进
-
-
质量控制:确定项目结果与质量标准是否相符,并及时纠正产品缺陷的过程。
-
静态方法:审计
-
动态方法:测试
-
-
项目:项目是为完成某一独特的产品、服务或成果所做的一次性努力。
-
项目管理:项目管理(PM)就是在项目活动中运用相关知识, 技能, 工具和技术满足项目的要求。
-
项目管理的五大过程组:启动、计划、执行、控制和收尾。
-
项目管理的十大知识领域:
-
项目集成管理
-
项目范围管理
-
项目时间管理
-
项目成本管理
-
项目质量管理
-
项目人力资源管理
-
项目沟通管理
-
项目风险管理
-
项目采购管理
-
项目相关利益者管理
-
-
可行性分析——净现值
-
定义:净现值是成本效益分析的有力工具之一。
-
优点:
-
适用性强,能基本满足项目年限相同的互斥投资方案决策。
-
能灵活地考虑投资风险。
-
-
-
WBS:WBS是面向可交付成果的对项目任务的分组,它组织并定义了整个项目范围。它是一个分级的树型结构,是对项目由粗到细的分解过程。
-
算法模型
-
专家判断
-
类比
-
自顶向下
-
自底向上
-
甘特图
-
缺点:无法描述任务的逻辑关系
-
-
关键路径法(CPM)
-
定义
-
关键路径:项目网络图中花费时间最长的活动路线叫做关键路径。
-
关键活动;组成关键路径的活动。
-
关键路径法的缺点:关键路径法中的活动周期是确定的,固定不变的,这与现实不太符合。
-
-
关键路径的特点:
-
关键路径上活动持续时间总和是项目的工期。
-
关键路径上任何一个活动的延迟都会导致整个项目完工时间延迟。
-
关键路径是相对的,也是变化的,非关键路径可能变为关键路径,关键路径也可能变为非关键路径。
-
-
计算
-
核心:正向求最早开始时间和最早结束时间,二者取大作为最早开始时间;反向求最晚开始时间和最晚结束时间,二者取小作为最晚结束时间。
-
$$
自由时差(空闲缓冲期)=后续活动的最早开始时间-当前活动的最早完成时间
$$
$$
总时差(总缓冲期)=最晚完成时间-最早完成时间
$$
$$
干预缓冲期=总缓冲期-空闲缓冲期
$$
-
-
-
PERT技术(工程评估评审技术)的步骤:
-
估计每个活动的最可能的时间,乐观的时间,悲观的时间,计算活动的期望周期与标准偏差;
-
正向遍历得到期望达到事件的日期;
-
满足目标的可能性。
-
-
关键链法(CCPM)步骤:
-
资源:资源是执行项目所需要的任何项和人。
-
资源分配直方图
-
风险的定义:一个不确定的事件或者情况,若其一旦发生,会对项目的目标,例如:进度、成本和质量,产生积极或消极的影响。
-
风险管理的框架
-
风险处理方法
软件项目的监督和控制
-
挣值分析(计算题)
-
挣值:赋予每个任务一个“挣值”,表示完成这个任务需要的支出,一般用时间或金钱衡量。
-
赋值方法:0/100
-
三个数值:
-
计划价值(PV):已计划工作的预测成本
-
挣值(EV):已执行工作的预测成本
-
实际成本(AC):已执行工作的实际成本
-
-
两个偏差:
-
进度偏差(SV):挣值与计划价值的差
$$
SV=EV-PV
$$ -
成本偏差(CV):挣值与实际成本的差
CV=EV-AC
$$ -
-
两个性能比:
-
进度性能指标(SPI):SPI < 1——进度落后
$$
SPI=EV/PV
$$ -
成本性能指标:CPI < 1——成本超支
$$
CPI=EV/AC
$$
-
-
完成时间的估计值(TEAC):按照当前进度项目的完成时间估计
项目的计划周期(SAC)
$$
TEAC = SAC / SPI
$$项目成本预算(EAC):按照当前的进度,项目的总支出的估计
全部工作的预算(按照原计划,完成所有工作所需的预算成本)(BAC)
$$
EAC = BAC / CPI
$$
-
-
例题:
-
挣值法参数分析与对应措施表
序号 * 三参数关系 分析(含义) 措施 1 AC > PV > EV SV<0 CV<O 效率低 速度较慢 投入超前 用工作效率高的人员更换一批工作效率低的人员 2 EV > PV > AC SV>0 CV>0 效率高 速度较快 投入延后 若偏离不大,维持现状 3 EV > AC > PV SV>0 CV>0 效率较高 速度快 投入超前 抽出部分人员,放慢进度 4 AC > EV > PV SV>0 CV<0 效率较低 速度较快 投入超前 抽出部分人员,增加少量骨干人员 5 PV > AC > EV SV<0 CV<0 效率较低 速度慢 投入延后 增加高效人员投入
-
配置管理的任务
-
-
控制变更
-
确保变更正确实现
-
向受变更影响的组织和个人报告变更
-
-
配置项:软件配置管理的对象,一个软件配置项是项目中一个特定的、可文档化的工作产品集。
-
CMM——软件过程能力成熟度模型
-
出发点:CMM描述软件组织一条从无序的、混乱的过程到成熟的、有纪律的过程的改进途径,描绘出软件组织如何增加对软件开发和维护的过程控制,如何向软件工程和管理的优秀文化演变等方面的指导 。
-
CMM不是过程,不是技术,不是方法,它是一种指导思想。
-
体系结构
-
CMM由5个成熟度级别组成。
-
初始级:软件过程不稳定,项目执行无序、混乱,没有稳定的开发环境。
-
可重复级:规则化的
-
已定义级:标准的、一致的
-
已管理级:可预测的
-
优化级:不断改进
-
-
每个成熟度级别(除级别1)包含了实现该级别的若干个关键过程域(KPA)。
-
每一个KPA进一步被分为称为公共特征的5个部分:执行约定、执行能力、执行活动、测量和分析、验证实施。
-
这些公共特征包括了关键实践(KP),即每一个KPA包括5类KP,实现了这些KP后,就实现了关键过程域的目标。
-
-
关键过程域
-
定义:一系列相互关联的操作活动,标识了达到某个成熟度级别时所必须满足的条件。
一个软件企业如果希望达到某一个成熟度级别,就必须完全满足该级别的关键过程域的要求,即满足每个关键过程域的目标。
-
CMM共有18个KPA,每一级都有自己的KPA,KPA分为三大类:管理过程、组织过程和工程过程。
-
-
关键实践
-
定义:描述对KPA的有效实施和制度化起最重要作用的基础设施和活动。
-
-
CMMI的两种表示方法:
-
阶段式表示法:作为整个组织已建立的一个过程域集合
-
连续式表示法:作为单一过程域或者过程域集合
-
-
CMM和CMMI的区别与联系
-
区别:
-
CMM适用于软件的组织成熟度测评。CMMI适用于多种组织成熟度测评。CMMI相对CMM更完整,更适用于大环境。
-
-
联系:CMMI有两种表示方法,一种就是与CMM一样的阶段式表现方法(把CMMI中的若干个过程区域分成5个成熟度级别);
另一种是连续式的表现方法(将CMMI中过程区域分为四大类,过程管理,项目管理,工程以及支持)
-
-
体系结构
-
PSP成熟度模型:PSP具有4个等级,7个台阶组成的成熟度框架 。4个等级分别为个体度量过程、个体计划过程、个体质量管理过程和个体循环过程。
-
PSP过程框架:PSP过程由一系列方法、表格、脚本等组成,用以指导软件开发人员计划、度量和管理他们的工作。
-
-
两种日志
-
时间日志
-
缺陷日志
-
-
评审比测试有效的原因:在评审时发现的错误比测试时发现的多;成本低。缺陷发现的越早,修复的花费越低;且避免缺陷比发现和修复缺陷更有效。
-
四个设计模板:
-
操作规格模板(UML:用例图):描述了系统与外界的交互;描述了用户与待设计系统的正常情况下和异常情况下的交互。
-
功能规格模板(UML:类图):描述系统与外界的接口。
-
状态规格模板:可以精确定义程序的所有状态、状态之间转换以及伴随每次状态转换的动作。
-
逻辑规格模板:可以精确描述系统的内部逻辑状态。
-
-
瀑布模型
-
特点:
-
开发阶段严格按照线性方式进行
-
阶段间有因果关系
-
每个阶段需评审确认
-
允许反馈
-
强调文档
-
-
适用场所:需求易于完善定义的软件
-
缺点:
-
各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量
-
开发过程中很难响应客户的变更要求
-
早期的错误可能要等到开发后期的测试阶段才能发现,进而带来 严重的后果
-
-
-
快速原型模型
-
优点:
-
加强用户和软件人员之间的沟通,明确系统的需求
-
尽早得到系统可用性的反馈信息,及时修改以获得完整、正确需求
-
-
缺点:
-
用户会由于看到的原型系统不完善,而对产品产生怀疑
-
可能为了快速开发原型系统,而采用未经充分论证的技术(如操作系统平台、主要的算法)导致质量低下
-
-
-
增量模型
-
优点:
-
整个产品被分解成若干个构件逐步交付,用户可以不断地看到所开发软件的可运行中间版本
-
将早期增量作为原型有助于明确后期增量的需求
-
降低开发风险
-
重要功能被首先交付,从而使其得到最多的测试
-
-
缺点:
-
需要软件具备开放式的体系结构,以便各个构件逐步进入
-
需求难以在增量实现之前详细定义,因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难,容易退化为边做边改方式,使软件过程的控制失去整体性
-
-
-
螺旋模型
-
优点:(风险驱动)
-
关注软件的重用
-
关注早期错误的消除
-
将质量目标放在首位
-
将开发阶段与维护阶段结合在一起
-
-
缺点:
-
需要风险评估的经验
-
只适应内部大规模软件开发
-
-
-
形式化方法模型
-
优点:
-
由于数学方法具有严密性和准确性,形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性
-
-
缺点:
-
开发人员需要具备一定技能并经过特殊训练
-
形式化描述和转换是一项费时费力的工作,成本高,质量不一定高
-
现实应用的系统大多数是交互性强的软件,但是这些系统难以用形式化方法进行描述
-
-
-
基于组件的开发模型
-
优点:
-
充分体现软件复用的思想
-
实现快速交付软件
-
利用开源组件与软件
-
-
缺点:
-
商业组件的修改受到限制,影响系统的演化
-
-
-
六个角色:产品管理,程序管理,开发,测试,发布管理,用户体验
-
过程模型中的五个阶段:构思阶段,计划阶段,开发阶段,稳定阶段,部署阶段
-
九个软件过程
-
6个核心过程流:商业建模,需求,分析和设计,实现,测试,部署
-
3个辅助过程流:配置和变更管理,项目管理,环境
-
-
四个阶段:
-
初始阶段:里程碑:生命期目标
-
细化阶段:里程碑:生命期构架
-
构造阶段:里程碑:初始运作功能。构造阶段的结束是项目开发的第三个重要的里程碑。这个阶段产生的版本通常被称为β版。
-
交付阶段:里程碑:产品发布
-
-
六大经验:迭代式开发,管理需求,基于组件的体系结构,可视化建模,验证软件质量,控制软件变更
-
敏捷宣言
-
注重个人及互动胜于过程和工具
-
注重可用的软件胜于详尽的文档
-
注重客户协作胜于合同谈判
-
注重响应变化胜于恪守计划
-
-
Scrum:一个敏捷开发框架,是一个增量的、迭代的开发过程
-
极限编程(XP):一种全新而快捷的软件开发方法。XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流。这可以帮助团队最大化地发挥他们的价值。
-
XP认为沟通是项目成功的关键
-
实践:现场客户,计划游戏,系统隐喻,简单设计,代码集体所有
-
XP特别适合于小型的有责任心的、自觉自励的团队开发需求不确定或者迅速变化的软件
-