中国教育课件网-GOODPPT.COM
首 页教学教案课件下载
  首页 教学教案课件下载 | 语文| 数学| 英语| 物理| 化学| 政治| 生物| 地理| 音乐| 美术| 历史| 计算机| 课件素材| 其他课件| 考试题库 更多»  
 
热门标签:计算机(8)  Authorware(5)  课件设计制作技巧(1)
 
我要上传课件
共享您的课件,轻松获取积分!
 
当前位置:中国教育课件网课件下载计算机
 软件质量与项目管理
 
运行环境: Win9X/Win2000/WinXP/Win2003/
课件语言: 简体中文
课件类型: PPT - 计算机
授权方式: 共享版
课件大小: 30.3 MB
推荐星级:
更新时间: 2011-09-01 21:51:51
联系方式: 暂无联系方式
官方主页: Home Page
图片预览: 没有预览图片     论坛转帖
解压密码: 本站默认解压密码:www.goodppt.com
下载统计:
 

欢迎登录课件网

  课件简介
 


软件质量与项目管理
软件质量
软件质量定义
           明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。
软件质量
软件质量定义
软件需求是进行“质量”度量的基础。与需求不符就是质量不高。
指定的标准定义了一组指导软件开发的准则。如果不能遵守这些准则,就极有可能导致质量不高。
通常有一组“隐含需求”是不被提及的(如对维护性的需求)。如果软件符合了明确的需求却没有满足隐含需求,软件质量仍然值得怀疑。
软件质量的定义
ANSI/IEEE Std 729-1983定义软件质量为“与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体”。
M.J. Fisher 定义软件质量为“所有描述计算机软件优秀程度的特性的组合”。
软件质量
软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。
标准定义了一组开发准则,用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则,软件质量就得不到保证。
软件质量是各种特性的复杂组合。它随着应用的不同而不同,随着用户提出的质量要求不同而不同。
软件质量特性
软件质量特性,反映了软件的本质。讨论一个软件的质量,问题最终要归结到定义软件的质量特性。
定义一个软件的质量,就等价于为该软件定义一系列质量特性。
人们通常把影响软件质量的特性用软件质量模型来描述。


软件质量模型
软件质量特性定义成分层模型
最基本的叫做基本质量特性,它可以由一些子质量特性定义和度量。
二次特性在必要时又可由它的一些子质量特性定义和度量。
1976年  Boehm质量模型
1979年  McCall质量模型
1985年  ISO质量模型

ISO的软件质量评价模型
按照ISO/TC97/SC7/WG3/1985-1-30/N382,软件质量度量模型由三层组成
软件质量需求评价准则(SQRC)
软件质量设计评价准则(SQDC)
软件质量度量评价准则(SQMC)
高层和中层建立国际标准,低层可由各使用单位视实际情况制定

软件质量
McCall模型中的软件质量要素
McCall提出的表明软件质量的11个质量特性
▲使用性            ▲测试性
▲正确性            ▲维护性
▲可靠性            ▲ 移植性
▲效率                ▲重用性
▲完整性            ▲互操作性
▲适应性(灵活性)
能用于软件质量定量评价的软件度量
美国国防部AD报告:把质量表现形式归纳        
                  为190多个问题;

IEEE质量标准词典规定:39组度量公式
39个度量项分为四级:
0级:已公式化,尚未被运行有效确认
1级:已为软件界采用,应用范围有限
2级:已被软件界接受,已取得一定经验
3级:软件界已广泛使用,已取得相当经验
3级的8个度量项
(1)缺陷密度
(2)需求可追踪性
(3)Halstead软件科学
(4)McCabe复杂性度量
(5)发现k个缺陷的平均时间
(6)按耗时作故障分析
(7)平均故障时间
(8)故障率
 软件可靠性基本概念
软件可靠性定义
   在给定时间间隔内和特定的
环境下,软件按规格说明成功
运行的概率。

软件可靠性的主要指标
 借用硬件可靠性的定量度量方法来度量软件的可靠性:
 MTBF:平均故障间隔时间
 MTTF:平均故障时间
软件可靠性定义的要素
(1)环境条件
   规定软件的使用环境
   (输入数据要求和环境)
(2)规定时间
   时间t是随机变量。
(3)规定的功能
(4)成功运行

软件质量保证体系的研究和主要技术
           目前国际上软件过程质量管理最主要的三个典型代表:
CMM /PSP/TSP
ISO9000系列
ISO/IEC15504
软件质量与项目管理


什么是软件项目管理?
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对成本、人员、进度、质量、风险等进行分析和管理的活动。
软件项目管理的对象是软件工程项目,他所涉及的范围覆盖了整个软件工程过程。
 

    

    

    

     

软件项目管理
           软件项目管理是软件工程的保护性活动,它先于任何技术活动之前开始,并且持续贯穿于整个计算机软件的定义、开发和维护之中。
项目开发——有机体
项目控制的问题?
项目跟踪的难题?
与国外的软件开发相比
缺乏规范的管理
缺乏管理所造成的问题
软件项目管理
软件项目计划
风险管理
项目成本预算
软件项目计划 Software Project Planning
对估算的观察 Observations on Estimating
项目计划目标 Project Planning Objectives
软件范围 Software Scope
资源 Resources
软件项目估算 Software Project Estimation
分解技术  Decomposition
经验估算模型 Empirical Estimation Models
自行开发或购买的决策 The Make/Buy Decision
软件项目计划—Project Planning Objectives
提供一个框架,使得管理者能够对资源、成本及进度进行合理的估算。
一个限定的时间框架内
“最好的情况” 及“最坏的情况”
通过一个信息发现的过程实现的


软件项目计划—Software Scope
软件项目计划的第一个活动是软件范围的确定。
软件范围描述了功能、性能、约束条件、接口及可靠性。
软件项目计划—Software Scope
范围是通过回答下列问题来定义的:
背景:待建造的软件如何适应于大型的系统、产品或商业的背景,在该背景下要加什么约束?
信息目标:软件要产生什么样的客户可见的数据对象输出,需要什么样的数据对象输入?
功能和性能:软件执行什么样的功能使得输入数据才能变换成为输出数据?需要满足什么特殊的性能特征吗?
软件项目计划—Resources
软件项目计划—Resources
人力资源
描述组织的职位及专业技能等
可复用软件资源
可直接使用的构件; 具有完全经验的构件
具有部分经验的构件;新构件
环境资源
硬件及软件
软件项目计划—Resources
资源说明四特征
资源描述
可用性说明
需要该资源的时间
被使用的持续时间
软件项目计划—Resources
软件成本及工作量估算永远不会是一门精确的科学。
可以从神秘的技巧向一系列系统化的步骤转化
软件项目计划—Software Project Estimation
几种可考虑的选择
将估算拖延到项目的最后
基于已经完成的类似项目
使用简单的分解技术
使用经验模型

软件项目计划—Decomposition
分解问题, 将项目分解成若干主要功能及相关的软件工程活动,通过逐步求精的方式进行成本及工作量的估算.
问题分解
“分而治之”
过程分解
回答“如何完成公共过程框架?”

软件项目计划—Empirical Estimation Models
COCOMO 模型(Constructive Cost MOdel)
软件估算模型的层次体系
模型1:基本COCOMO模型,将软件开发工作量及成本作为程序规模的函数进行计算,程序规模已估算的代码来表示。
模型2:中级COCOMO模型,将软件开发工作量及成本作为程序规模及一组“成本驱动因子”的函数来进行计算,其中“成本驱动因子”包括对产品、硬件、人员、及项目属性的主管评估。
模型3:高级COCOMO模型,包含了能够的所有特性,并结合了成本驱动因子对软件工程过程中每一步骤的影响评估。
最常见的进度计划风险
功能无限蔓延
需求镀金或开发人员镀金
质量不定
计划过于乐观
设计欠佳
银弹综合症
研发导向的开发
人员薄弱
签约商失败
研发人员与客户的摩擦
风险管理 Risk Management
风险管理要素 Risk Management Principles
风险识别 Risk Identification
风险分析 Risk Analysis
风险的优先级 Risk Prioritization
风险管理计划 Risk Management planning
风险化解 Risk Resolution
风险监视 Risk Monitoring

风险管理 Risk Management
风险评估
风险识别—提出一个潜在破坏项目进度的风险列表。
风险分析—评估每一个风险出现的可能性及其影响,判定风险的级别。
风险优先级—按风险影响大小排出一个风险优先级,这个风险列表将作为风险控制的基础。

风险控制
风险管理计划—制定一个应对每个重要风险的方案,同时确保每一个单独的风险管理计划之间以及与整体项目计划之间相一致。
风险化解—每个重要风险所对应计划的执行。
风险监控—对解决风险的过程进行监控,还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中。
软件项目风险管理五种状态
危机管理—风险已经造成麻烦后才处理。
失败处理—觉察到风险并迅速处理。
风险缓解—事先制订好风险发生后的补救       措施,但不作任何防范措施。
着力预防—将识别和防范作为项目一部分       加以规划和执行。
消灭根源—识别和消除风险根源。
软件项目风险管理原则
区分风险和已存在的现有问题
通过风险的管理变被动的面对风险,即消防状态为主动面对风险,即钓鱼状态
最小化项目失败的潜在可能
创造风险管理的气氛
风险检查列表
产品规模—与要建造或要修改的软件的总体规模相关的风险。
商业影响—与管理或市场所加诸的约束相关的风险。
客户特性—与客户的素质以及开发者和客户定期通信的能力相关的风险。
过程定义—与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
开发环境—与用以建造产品的工具的可用性及质量相关的风险。
建造的技术—与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
人员数目与经验—与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
风险因素
性能风险—产品能够满足需求且符合于其       使用目的的不确定的程度。
成本风险—项目预算能够被维持的不确定       的程度。
支持风险—软件易于纠错、适应及增强的       不确定的程度。
进度风险—项目进度能够被维持且产品能       按时交付的不确定的程度。
风险因素
项目参与者
高级管理者:负责确定商业问题,这些问题往往对项目产生很大影响。
项目(技术)管理者:必须计划、激励、组织和控制软件开发人员。
开发人员:负责开发一个产品或应用软件所需的专门技术人员。
客户:负责说明待开发软件的需求的人员。
最终用户:一旦软件发布成为产品,最终用户是直接与软件进行交互的人。
项目负责人
解决问题:一个有效的软件项目负责人应该能够准确地诊断出技术的和管理的问题;系统地计划解决方案;适当地激励其他开发人员实现解决方案;把从以前的项目中学到的经验应用到新的环境下;如果最初的解决方案没有结果,能够灵活地改变方向。
管理能力:一个好的项目负责人必须掌管整个项目,他在必要时必须有信心进行控制,必须保证让优秀的技术人员能够按照他们的本性行事。
项目负责人
激励能力:为了提高项目组的生产率,项目负责人必须奖励具有主动性和作出成绩的人。并通过自己的行为表明约束下的冒险不会受到惩罚。
理解和控制能力:一个有效的项目负责人必须能够“读懂”人;他必须能够理解语言的和非语言的信号,并对发出这些信号的人的要求做出反应。项目负责人必须在高压力环境下保持良好的控制能力。

软件项目组
软件工程小组的组织方式:
民主分权式(Democratic Decentralized, DD):这种软件工程小组没有固定的负责人。任务协调者是短期指定的,之后就由其他协调不同任务的人取代。问题和解决方法的确定是由小组讨论决策的。
控制分权式(Controlled Decentralized, CD):这种软件工程小组有一个固定的负责人,他协调特定的任务及负责子任务的二级负责人关系。问题解决仍是一个群体活动,但解决方案的实现是有小组负责人在子组之间进行划分的。子组和个人间的通信是平行的,但也会发生沿着控制层产生的上下级的通信。
控制集权式(Controlled Centralized, CC):顶层的问题解决和内部小组协调是由小组负责人管理的。负责人和小组成员之间的通信是上下级式的。

协调和通信问题
有很多原因会使软件项目陷入困境。许多开发项目规模宏大,以至于使小组成员间的关系复杂性高混乱、难以协调。不确定性是经常存在的,它会引起困扰项目组的一连串的改变。
软件工程小组必须建立有效的方法,以协调参与工作的人员之间的关系。要完成这项任务,必须建立小组成员之间及多个小组之间的正式的和非正式的通信机制。
正式的通信是通过文字、会议及其他相对而言非交互和非个人的通信渠道来实现。非正式的通信则更加个人化。软件工程小组的成员在一个特别的基础上共享想法,出现问题时相互帮助,且每天相互交流。
项目协调技术
正式的、非个人的方法:包括软件工程文档和交付物(如源程序)、技术备忘录、项目里程碑、进度和项目控制工具、修改请求及相关文档、错误跟踪报告、中心库数据。
正式的、个人间的规程:集中表现于软件工程工作中产品的质量保证活动中,包括状态复审会议及设计和代码检查。
非正式的、个人间的规程:包括信息传播、问题解决的小组会议。
电子通信:包括电子邮件、电子公告栏、Web站点以及基于视频的会议系统。
个人间的网络:与项目组之外的人进行的非正式的讨论,这些人可能有足够的经验或见解,能够帮助项目组成员。
项目管理的问题
           软件项目管理者从软件项目一开始就面临着进退两难的局面。需要定量的估算成本和有组织的计划项目的进展,但却没有可靠的信息可以使用。对软件需求的详细分析可以提供必要的估算信息,但分析常常要花数周甚至数月的时间才能完成。更糟糕的是,随着项目的进展经常发生改变,需求可能是不固定的。
项目管理中的常见问题
项目管理中的常见问题(Cont.)
产生问题的根源
解决问题的最佳途径
问题分解
问题分解,有时称为划分,是一个软件需求分析的核心活动。在确定软件范围的活动中并没有完全分解问题。分解一般用于两个主要领域:
         (1)必须交付的功能;(2)交付所用的过程。
面对复杂的问题人们常常采用分而治之的策略。简单讲,就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在估算开始之前,范围中所描述的软件功能必须被评估和精化,以提供更多的细节。因为成本和进度估算都是面向功能的,所以某种程度的分解是很有用的。
项目管理的过程
软件过程的一般阶段(定义、开发和维护)适用于所有软件项目。问题在于如何选择一个合适项目组要开发的软件过程模型。
项目管理者必须决定哪一个过程模型最适合待开发项目,然后基于公共过程框架活动集合,定义一个初步的计划,便可以开始进行过程分解,即建立一个完整的计划,以反映框架活动中所需要的工作任务。
工作内容
合并问题和过程
           项目计划开始于问题和过程的合并。软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合来完成。
软件质量与项目管理
       软件质量管理与配置管理
影响软件质量的因素
人的因素
软件需求
测试的局限性
质量管理的困难
软件人员的传统习惯
开发规范
开发工具支持不够
软件配置管理(SCM)
什么是软件配置管理
(1)ISO 9000-3 :1997
       配置管理是一个管理学科,它对配置项(包括软件项)的开发和支持生存期给与技术上的和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。
(2) W.Babich 的解释
       软件配置管理能协调软件开发,使混乱减少到最小。软件配置管理是一种标识、组织和控制修改的技术,目的是最有效的提高生产率。
(3) GB/T 11457 :1995《软件工程术语》国家标准
  A.表示和确定系统中配置项的过程,在系统整个生存期内控制这些配置项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。
  B.对下列工作进行技术和行动指导与监督的一套规范:
    ——对配置项的功能特性和物理特性进行标识和文件编制工作;
    ——控制这些特性的更动情况;
    ——记录并报告这些更动进行的处理和实现的状态。
软件配置管理的任务
  ——制定软件配置管理计划
——确定配置标识规则
——实施变更控制
——报告配置状态
——进行配置审核
——进行版本管理和发行管理
软件配置管理
        明确地区分软件维护和软件配置管理是很重要的:
维护是发生在软件已经被交付给客户、并且投入运行后的一系列软件工程活动。
软件配置管理则是当软件项目开始时就开始、并且仅仅当软件退出运行后才终止的一组跟踪和控制活动。

软件配置
           软件过程的输出信息可以分为三个主要的类别:
计算机程序(源代码和可执行程序)
描述计算机程序的文档(针对技术开发者和用户)
数据(包含在程序内部和程序外部)。
            它们包含了所有在软件过程中产生的信息,总称为软件配置。
软件配置管理
当开发软件系统的过程中,变化是不可避免的。这些变化使得在同一个项目中工作的软件开发人员之间的彼此不理解程度更加增大。当变化进行前没有经过分析、变化实现前没有被记录、没有向那些需要知道的人报告变化、或变化没有以可以改善质量及减少错误的方式被控制时,大量的不理解问题将会产生。

协调软件开发以减少由变化带来的不理解性到最小程度的技术称为配置管理。软件配置管理(SCM)是贯穿于整个软件过程中的保护性活动。
软件配置管理
SCM活动内容:
标识变化
控制变化
保证变化被适当地实现
向其他可能感兴趣的人报告变化。

变化的起源
有四种基本的变化源:
新的商业或市场条件,引起产品需求和业务规则的变化。
新的客户需要,要求修改信息系统产生的数据、产品提供的功能、或基于计算机的系统提供的服务。
改组和/或企业规模减小,导致项目优先级或软件工程队伍结构的变化。
预算或进度的限制,导致系统或产品的重定义。

软件配置项
            软件配置项(Software Configuration Items, SCI)定义为部分软件工程过程中创建的信息,在极端情况下,一个SCI可被考虑为某个大的规约中的某个单独段落,或在某个大的测试用例集中的某种测试用例,更实际地,一个SCI是一个文档、一个全套的测试用例、或一个已命名的程序构件(例如,C++函数或Ada95软件包)。
基    线
基线是一个软件配置管理的概念,它帮助我们在不严重阻碍合理变化的情况下来控制变化。
IEEE(IEEE Std.610.12-1990)定义基线如下:已经通过正式复审审核批准的某规约或产品,它因此可以作为进一步开发的基础,并且只能通过正式的变化控制过程而改变。

基    线
在软件配置项变成基线前,变化可以迅速而非正式地进行,然而,一旦基线已经建立,我们就得象通过一个单向开的门那样,变化可以进行,但是,必须应用特定的、正式的规程来评估和验证每个变化。
在软件工程的范围内,基线是软件开发中的里程碑,其标志是有一个或多个软件配置项的交付,且这些SCI已经经过正式技术复审而获得认可。
常见的软件基线
产生基线的流程
成为基线的SCIs
系统规约
软件项目计划
软件需求规约
      图形分析模型;处理规约;原型;数学规约
初步的用户手册


成为基线的SCIs
设计规约
   数据设计描述;体系结构设计描述;模块设计描述;界面设计描述;对象描述(如果使用面向对象技术)
源代码清单
测试规约
    测试计划和过程;测试用例和结果记录
操作和安装手册
成为基线的SCIs
可执行程序
    模块的可执行代码;链接的模块
数据库描述
    模式和文件结构;初始内容
联机用户手册
维护文档
    软件问题报告;维护请求;工程变化命令
软件工程的标准和规约
成为基线的SCIs
除了上面列出的SCI,很多软件工程组织也将软件工具列入配置管理之下,即,特定版本的编辑器、编译器和其他CASE工具被“固定”作为软件配置的一部分。因为这些工具被用于生成文档。源代码和数据,所以当对软件配置进行改变时,必然要用到它们。虽然问题并不多见,但有可能某工具的新版本(如,编译器)可能产生和原版本不同的结果。为此,工具就象它们辅助生产的软件一样,可以被基线化,并做为综合的配置管理过程的一部分。

基线SCI和项目数据库
SCM过程
        软件配置管理是软件质量保证的重要一环,其主要责任是控制变化。然而,SCM也负责个体SCI和软件的各种版本的标识、软件配置的审计(以保证它已被适当地开发)、以及配置中所有变化的报告。

SCM过程
任何关于SCM的讨论均涉及一系列复杂问题:
一个组织如何标识和管理程序(及其文档)的很多现存版本,以使得变化可以高效地进行?
一个组织如何在软件被发布给客户之前和之后控制变化?
谁负责批准变化,并给变化确定优先级?
我们如何保证变化已经被恰当地进行?
采用什么机制去告知其他人员已经实行的变化?
SCM过程
SCM五大任务:
标识
版本控制
变化控制
配置审计
报告。

SCM中对象的标识
为了控制和管理软件配置项,每个配置项必须被独立命名,然后用面向对象的方法组织。
有两种类型的对象可以被标识:基本对象和聚集对象。
基本对象是软件工程师在分析、设计、编码或测试中创建的“文本单元(unit of text)” ,例如,一个基本对象可能是需求规约的一个段落、模块的源程序清单或一组用于测试代码的测试用例。
一个聚集对象是基本对象和其他聚集对象的集合。
SCM中对象的标识
每个对象均具有一组唯一地标识它的、独特的特征:名字、描述、资源表、以及“现实” 。
对象名是无二义性地标识对象的一个字符串;对象描述是一个数据项的列表,它们标识:
         该对象所表示的SCI类型(如,文档、程序、数据);
         项目标识符;以及变化和/或版本信息;
资源是由对象提供、处理、引用或需要的实体,例如,数据类型、特定函数、或甚至变量名也可以作为对象资源;
现实是一个指针,对基本对象而言指向“文本单元” ,对聚集对象而言则指向null。
SCM中对象的标识
配置对象的标识也必须考虑存在于命名对象之间的关系,一个对象可被标识为某聚集对象的<part-of>,关系<part-of>定义了一个对象层次。
对于软件对象的标识模式必须认可对象在整个软件过程中的演化,在一个对象被确定为基线前,它可能会变化很多次,甚至在基线已经建立后,变化也可能经常发生。有可能为任意对象创建一个演化图,演化图描速了对象的变化历史。
SCM中对象的标识
SCM中的版本控制
版本控制结合了规程和工具以管理在软件工程中所创建的配置对象的不同版本。

SCM中的版本控制可以描述如下:配置管理使得用户能够通过对适当版本的选择来指定可选的软件系统的配置,这一点的实现是通过将属性关联到每个软件版本上,然后通过描述一组所期望的属性来指定(和构造)配置的。
SCM中的变化控制
            对于大型的软件开发项目,无控制的变化将迅速导致混乱,SCM变化控制结合人的规程和自动化工具以提供一个变化控制的机制。
SCM中的变化控制
一个变化请求被提交和评估,以评价技术指标、潜在副作用、对其他配置对象和系统功能的整体影响、以及对于变化的成本预测。
评估的结果以变化报告的形式给出,该报告被变化控制审核者(change control authority, CCA)----对变化的状态及优先级作最终决策的人或小组----使用。对每个被批准的变化生成一个过程变化命令(engineering change order, ECO),ECO描述了将要进行的变化、必须注意的约束、以及复审和审计的标准。
将被修改的对象从项目数据库“提取(check out)”出来,进行修改,并应用于合适的SQA活动,然后,将对象“提交(check in)”进数据库,并使用合适的版本控制机制去建立软件的下一个版本。
SCM中的变化控制
           “提交”和“提取”过程实现了两个主要的变化控制要素----访问控制和同步控制:
访问控制管理哪个软件工程师有权限去访问和修改某特定的配置对象。
同步控制帮助保证由两个不同人员完成的并行修改不会互相覆盖。
SCM中的变化控制
           基于一个被批准的变化请求和ECO,软件工程师提取出配置对象,访问控制功能保证该软件工程师有权限提取该对象,而同步控制对项目数据库中的该对象加锁,使得当前提取出的版本在被放回以前不能对它作任何其他修改。注意,可以提取出其他的备份,但是,不能进行其他修改。
SCM中的变化控制
非正式变化控制:
             在SCI变成基线以前,只需要进行非正式的变化控制。配置对象(SCI)的开发者可以进行任何被管理和技术需求证明是合适的修改(只要修改不会影响到在开发者工作范围之外的更广的系统需求),一旦对象已经经过正式的技术复审并已被认可,则创建了一个基线。

SCM中的变化控制
项目级变化控制:
               一旦SCI变成基线,则项目级的变化控制就开始实施了。这时,为了进行修改,开发者必须获得项目管理者的批准(如果变化是“局部的” ),或CCA的批准(如果该变化影响到其他SCI)。在某些情况下,变化需求、变化报告和ECO的正式生成可以省略,然而,需要管理对每个变化的评价,并对所有变化进行跟踪和复审。

SCM中的变化控制
正式的变化控制:
        当软件产品发布给客户时,正式的变化控制就开始实施了

SCM中的变化控制
           变化控制审核者(CCA)在第二和第三层控制上扮演了活跃的角色,依赖于软件项目的规模和性质,CCA可能包含一个人----项目管理者----或一组人(如,来自软件、硬件、数据库工程、支持、市场等五方面的代表)。CCA的角色是从全局的观点来评估变化对SCI之外的事务的影响:
变化将如何影响硬件?
变化将如何影响性能?
变化将如何改变客户对产品的感觉?
变化将如何影响产品的质量和可靠性?
    这些和很多其他的问题需被CCA处理。
SCM中的配置审计
        标识、版本控制和变化控制帮助软件开发者维持秩序,否则情况可能将是混乱和不固定的。然而,即使最成功的控制机制也只能在ECO产生后才可以跟踪变化。我们如何帮助变化被合适的实现呢?回答是两方面的:

   (1)正式的技术复审;
   (2)软件配置审计。

SCM中的配置审计
        正式的技术复审关注已经被修改的配置对象的技术正确性,复审者评估SCI以确定它与其他SCI的一致性、遗漏、及潜在的副作用,正式的复审应该对所有的变化进行,除了那些最琐碎的变化之外。

SCM中的配置审计
          软件配置审计通过评估配置对象的通常不在复审中考虑的特征,而形成正式复审的补充。审计询问并回答如下问题:
在ECO中说明的变化已经完成了吗?加入了任意附加的修改吗?
是否已经进行了正式的技术复审,以评估技术的正确性?
是否适当地遵循了软件工程标准?
变化在SCI中被“显著地强调(highlighted)”了吗?是否指出了变化的日期和变化的作者?配置对象的属性反应了变化吗?
是否遵循了标注变化、记录变化并报告变化的SCM规程?
所有相关的SCI被适当修改了吗?
            在某些情况下,审计问题被作为正式的技术复审的一部分而询问,然而,当SCM是一个正式的活动时,SCM审计由质量保证组单独进行。
SCM中的状态报告
           配置状态报告(Configuration status reporting, 有时称为status accounting)是一个SCM任务,它回答下列问题:
发生了什么事?
谁做的此事?
此事是什么时候发生的?
将影响别的什么吗?
SCM中的状态报告
配置状态报告(CSR)的信息流如下:
每次当一个SCI被赋上新的和修改后的标识时,则一个CSR条目被创建;
每次当一个变化被CCA批准时(即,一个ECO产生),一个CSR条目被创建;
每次当配置审计进行时,其结果作为CSR任务的一部分被报告。
CSR的输出可以放置到一个联机数据库中,使得软件开发者或维护者可以通过关键词分类访问变化信息。此外,CSR报告被定期生成,并允许管理者和开发者评估重要的变化。
SCM中的状态报告
         配置状况报告在大型软件开发项目的成功中扮演了重要角色,当涉及到很多人员时,有可能会发生“左手不知道右手在做什么”的综合症:
两个开发者可能试图以不同的或冲突的意图去修改同一个SCI;
软件工程队伍可能花费几个月的工作量针对过时的硬件规约建造软件;
能认识到被建议的修改有严重副作用的人并不知道该修改已经进行。
       CSR通过改善所有相关人员之间的通信,帮助排除这些问题。
SCM标准
            在过去20年中,已经提出了一系列的软件配置管理标准。很多早期的SCM标准,如MIL-STD-483、DOD-STD-480A、和MIL-STD—1521A,主要用于为军事用途而开发的软件。然而,最近的ANSI/IEEE标准,如ANSI/IEEE Std. No. 828-1983,No. 1042-1987,和Std. No.1028-1988,可应用于商业软件,并被向大型的和小型的软件工程组织推荐。
软件质量与项目管理
SQA是什么
ISO/IEC 12207:1995指出:“软件质量保证过程(SQA)是恰当保证为项目生存周期中的软件产品和过程符合规定需求和已制订的计划提供足够保证的过程”。“质量保证可以是内部的,也可以是外部的,取决于向供方还是顾客管理部门演示产品或过程质量的证据。”
软件质量保证
          软件质量保证(SQA)是一种应用于整个软件过程的保护性活动。SQA包括:
一种质量管理方法
有效的软件工程技术(方法和工具)
在整个软件过程中采用的正式技术复审
一种多层次的测试策略
对软件文档及其修改的控制
保证遵从软件开发标准的规程
度量和报告机制


SQA主要具体方法
按照PDCA;
早期阶段,制定SQAP,并与SDP紧密结合;
帮助项目使过程规范化,传播项目成功经验;
注重开发过程,评审注重实效;
首先在软件项目内部处理符合性问题;
注意人员沟通方法;
利用其它活动的结果(验证、确认、测试……)。


软件质量保证(目的)
向管理者提供适当的关于所用过程和所构造产品的可视性。为此执行下列任务:
1)在软件项目的早期阶段,与软件项目一起制定计划、标准和规程等。
2)在整个生存周期评审项目活动,审核软件工作产品,以验证它们符合性;
3)给项目经理和其它有关经理提供这些评审和审核的结果;
4)处理符合性问题,直至得到解决。
软件质量保证(目标)
目标1     软件质量保证活动是有计划的。
目标2  软件产品和活动遵守适用的标准、规程和需求的情况得到客观的验证。
目标3  受影响的组和个人接到软件质量保证活动和结果的通知。
目标4  高级管理者处理在软件项目内部不能解决的不符合问题。
SQA计划
           SQA计划为建立软件质量保证提供一张行路图,其由SQA小组和项目组共同制定,充当软件项目中SQA活动的模板。
需要进行的评价;
需要进行的审计和复审;
项目可采用的标准;
错误报告和跟踪过程;
由SQA小组产生的文挡;
为软件项目组提供的反馈数量。


SQA小组
 在一个组织中有多个机构负有保证软件质量的责任,包括软件工程师、项目管理者、客户、销售人员和SQA小组成员。
SQA小组负责质量保证的计划、监督、记录、分析及报告工作。
SQA小组充当客户在公司内部的代表。这就是说,SQA小组的成员必须以客户的观点看待软件。
SQA活动流程说明
1)按规程为软件项目制订SQA计划。
2)按计划进行SQA组的活动。
3)参与制定软件开发计划、标准和规程
4)评审软件工程活动。
5)审核指定的软件工作产品。
6)定期向软件工程组报告其活动结果。
7)按规程处理评审和审核中发现的偏差建立文档。
8)必要时SQA组与顾客的SQA组一起评审自己的活动和发现。
SQA过程活动输出
项目软件质量保证计划
项目采用的标准和规程
各种评审和审核活动的记录和报告
问题报告和问题解决报告
软件质量有关的数据

SQA活动
为项目准备SQA计划;
参与开发该项目的软件过程描述;
复审各项软件工程活动、对其是否符合定义好的软件过程进行核实;
审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实;
确保软件工作及工作产品产品中的偏差已被记录在案,并根据预定规程进行处理;
记录所有不符合的部分,并报告给高级管理者;
协调变化的控制和管理,并帮助收集和分析软件度量信息。
测量和分析
进行测量,以便分析和确定SQA活动的成本和进度状态。测量内容例如:
SQA活动里程碑完成情况与计划比较;
SQA所完成的工作、花费的工作量和消耗的资金与计划比较;
产品审核和活动评审的次数与计划比较。

妨碍软件质量保证的因素
软件质量与项目管理
软件过程管理
改进软件过程
研究软件过程本质上是为了突出关键过程以改善软件的质量。人们已经得到共识,要提高软件质量必须改进软件过程。
软件过程管理
改进软件过程
软件机构形成一套完整而成熟的软件过程不是一蹴而就的,它需要一个从无序到有序,从特殊到一般,从定性到定量,最后再从静态到动态的历程,或者说软件机构在形成成熟的软件过程之前必须经历一系列的成熟阶段。
软件过程管理
改进软件过程
因此有必要建立一个软件过程成熟度模型来对过程作出一个客观、公正的评价,以促进软件开发组织改进软件过程。

过程与工程?
What is Software Process?
What is Software Process?
过程改进
过程改进
有效的软件过程环境
软件过程改进框架

技术架构
软件过程改进规划图
软件过程评估
软件过程改进计划
过程改进的6项基本原则
软件过程的重大改变必须从高层开始
必须人人参与
树立明确的目标并对当前的过程了解
持续改进
没有有意识的努力和周期性的增强,软件过程的变化就不会持久
软件过程改进需要投资

一些常见的误解
必须从确定的需求开始
只要通过测试,产品就不会有问题
软件质量无法度量
软件问题是技术问题
需要好的开发人员
软件管理与其他管理不同

找到一条适合自己的
过程改进的方法
组织和准备
执行组织审查
建立技术工作组
了解项目当前状态
重新定义过程
开发解决方案
执行过程试点和评价结果
支持组织级的经验和实践学习
历史情况总结
成功的过程改进程序一般是:
所有公司长期进行过程改进
对需要的改变保持持续的承诺
都具有较深入的度量程序
都将焦点放在过程改进,使度量的改进朝着基于商业目标努力
重点放在质量和相关的过程性能问题上
软件业务线组织的缺省角色
软件过程管理
软件过程成熟度
            指一个特定的软件过程被显式定义、管理、度量、控制和能行的程度。成熟度可以用于指示企业加强其软件过程能力的潜力。 当一个企业达到了一定的软件过程成熟级别后,它将通过制定策略、建立标准和确立机构结构使它的软件过程制度化。而制度化又促使企业通过建立基础设施和公司文化来支持相关的方法、实践和过程。从而使之可以持续并维持一个良性循环。
CMM模 型 简 介
在 美 国 国 防 部 资 助 下, 由 卡 内 基 梅 隆 大 学 软 件 工 程 研 究 所 (SEI) 建 立, 用 于 评 价 软 件 开 发 组 织 软 件 过 程 能 力 成 熟 度 的 模 型。
后 来 此 模 型 被 用 于 软 件 开 发 组 织 内 部 的 软 件 过 程 改 进。

CMM模型简介
CMM 的 五 级 模 型
CMM历史
CMM模型简介
CMM 模 型 的 构 成 
软件过程管理
不成熟企业的标志:
缺乏确定的软件过程和相应的管理和控制;
即使给出了软件过程,也不严格的遵循和强制执行;
管理是完全被动的,管理者采用的策略是救火式的,即出了事才去解决,解决的时候也难以纵观全局,往往只顾眼前;
软件过程管理
不成熟企业的标志:
由于缺乏有依据的估算,制订软件预算和生产计划时往往跟着感觉走,实际生产时则常常超标;
如果强制在预定期限内完成,那么软件的功能和质量肯定是得不到保证;
缺乏评价软件产品质量和解决产品缺陷和过程问题的客观基础。
软件过程管理
成熟企业的标志:
具有在企业范围内管理、控制软件开发和维护过程的能力;
现有人员和新进人员均了解所遵循的软件过程,且工作活动均按照事先的计划完成;
在定义好的软件过程中,所有项目和机构中的角色和责任分明;
软件过程管理
成熟企业的标志:
制定的计划是有效的且与实际的工作进展一致;
软件过程在必要时可按照一定规则和程序加以修改;
软件过程管理
成熟企业的标志:
软件产品和过程具有一定的可控性:
     1. 管理者能够监督软件产品的质量和生产过程;
     2. 具有客观的和定量化的措施来判断产品质量并分析产品与生产
         过程中的问题;
     3. 计划和预算有章可循,它是基于历史数据的,从而是实际可行
         的;
     4. 预算的结果,包括成本、时间表、产品功能和质量等,通常能
         够达到;
     5. 有关的参与者完全理解遵循软件过程的价值并认真地遵循之;
     6. 具有支撑软件过程的基础设施,如标准过程库、历史数据库等。
软件过程管理
软件能力成熟度模型
( Capability Maturity Model,CMM)
软件能力成熟度模型提美国大学Carnegie Mellon University软件工程研究所出的一套系统、规范的对软件生产过程进行管理的模型,其有效性已为大量实践所证实,并已成为对一个软件企业的生产能力和产品质量进行衡量的事实标准。
软件过程管理
定义了当一个组织达到不同的过程成熟度时应该具有的软件工程能力。
使用了一个评估调查表和一个五分的等级方案。
定义不同的过程成熟级别上所需要的关键活动。


软件过程管理
初始级—软件过程的特征是无序的,有时甚至是混乱的。几乎没有过程定义,成功完全取决于个人能力。
可重复级—建立了基本的项目管理过程,能够追踪费用、进度和能力。有适当的必要的过程规范,使得可以重现以前类似项目的成功。
定义级—用于管理和工程活动的软件过程已经文档化、标准化,并与整个组织的软件过程相集成。所有项目都使用文档华的、组织认可的过程来开发和维护软件。
管理级—软件过程和产品质量的详细度量数据被收集,通过这些度量数据,软件过程和产品能够被定量地理解和控制。
优化级—通过定量的反馈,进行不断的过程改进,这些反馈来自于过程或通过测试新的想法和技术而得到。

软件过程管理
软件能力成熟度模型(CMM)
CMM被用来确定一个机构的软件过程的成熟程度以及指明如何提高该成熟度的参考模型。
CMM描述了软件过程从无序到有序、从特殊到一般、从定性管理到定量管理、最终到达可动态优化的成熟过程,给出了该过程中五个成熟阶段的基本特征和应遵循的原则、 采取的行动,以帮助软件机构改进其软件过程。


软件过程管理
CMM的主要作用
        CMM可以指导软件机构如何控制软件产品的开发和维护过程,以及如何向成熟的软件工程体系演化,并形成一套良性循环的管理文化。具体说来,一个企业要想改进其生产过程,应该采取如下策略和步骤:
确定软件企业当前所处的过程成熟级别;
了解对改进软件生产质量和加强生产过程控制起关键作用的因素;
将工作重点集中在有限几个关键目标上,有效达到改进机构软件生产过程的效果,进而可持续地改进其软件生产能力。
软件过程管理
CMM的基本前提
软件质量在很大程度上取决于产生软件的软件过程的质量和能力;
软件过程是一个可管理、可度量并不断改进的过程;
软件过程的质量受到用以支撑它的技术和设施的影响;
企业在软件过程中所采用的技术层次应适应于软件过程的成熟度。
软件过程管理
CMM的基本原理
CMM强调连续的软件过程改进。该连续的改进基于多个演化步骤。CMM将这些演化步骤划分成五个级别。这种分级结构的理论依据是软件质量原理。
每一级别都包括若干目标。当满足某一目标后,软件过程的相应部分便确定下来。
五级成熟度定义了一个标准,用以度量机构的软件过程成熟度和评价其软件过程能力。
软件过程管理
CMM的基本内容
机构和资源的管理:涉及机构本身的责任,人员和其它资源设施。
软件工程过程及其管理:涉及软件工程过程,即软件过程的深度、范围和完整性以及如何度量、管理和改进这样的过程。
工具和技术:软件工程过程中使用的开发工具和技术。

软件过程管理

KPAs
软件过程管理
CMM1.1版经典, 但尚存不足。
CMM1.1版从1992年诞生至今已有12个年头
标准太多,有必要集成。                                                    
CMM相关标准

    1998年SEI启动了CMMI (CMM Integration)
CMMI通过提供统一的过程改进框架,消除了不同
模型之间的不一致和重复性,可望成为今后软件过
程改进领域比较稳定的一个实用模型。
目前SEI正在进行二个方面的扩充:
将质量管理的理念和思想向人力资源管理方面扩展(PSP/TSP/P-CMM);
将过程技术与产品线技术融合;
   如2000年推出的软件产品线PLP(Products Line Practice)和COTS(Commercial Off The Shelf)
软件过程管理
如何看待CMM:
梯子
镜子
补药
小         结
           任何工程方法(包括软件工程)必须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的过程改进,正是这种改进导致了更加成熟的软件工程方法的不断出现。支持软件工程的根基就在于对质量的关注。


 

 
  下载地址
  点这里下载 → 本地高速下载 点这里下载 → 迅雷专用下载 点这里下载 → 迅雷离线链下载  
点这里下载 → 本地高速下载 点这里下载 → 迅雷专用下载 点这里下载 → 迅雷离线链下载
·上一课件:项目管理培训系列--实施方法论
·下一课件:企业级软件架构技术_SOA引论
  课件评论
 

评论内容只代表网友观点,与本站立场无关!

   评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
 
  下载说明
  * 为了达到最快的下载速度,推荐使用网际快车迅雷下载本站软件。
* 请一定升级到最新版WinRAR3.80才能正常解压本站提供的软件!
* 如果您发现下载链接错误,请点击报告错误谢谢!
* 站内提供的所有软件包含破解及注册码均是由网上搜集,若侵犯了你的版权利益,敬请来信通知我们!
 
 
  本类热门下载
 
  • 1Authorware课件下载
  • 2Photoshop课件下载
  • 3第6章 用Director MX 11.0制作 演示多
  • 4Flash 8.0课件下载
  • 5第4章 用Authorware 7制作交互式多媒体
  • 6Flash 8.0ppt课件下载
  • 7网站建设流程.ppt
  • 8网络的利弊
  •  
      相关下载
     
  • 软件质量与项目管理.ppt
  • 软件质量与项目管理
  • 软件质量与项目管理
  •  
      下载栏目导航
     
  • 语文
  • 数学
  • 英语
  • 物理
  • 化学
  • 政治
  • 生物
  • 地理
  • 音乐
  • 美术
  • 历史
  • 计算机
  • 课件素材
  • 其他课件
  • 考试题库
  •  

    Copyright © 2005-2010 Goodppt.Com. All Rights Reserved .
    站长QQ:65036487 豫ICP备05024667号