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

欢迎登录课件网

  课件简介
 

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

Meiler Page-Jones:
   我拜访了很多商业公司,我也观察了很多数据处理的管理者,我常常恐惧地看到这些管理者徒劳地与恶梦般的项目斗争着,在根本不可能的最后期限下苦苦挣扎,或是在交付了使其用户极为不满的系统之后,又继续花费大量的时间去维护该系统。

软件项目管理
           软件项目管理是软件工程的保护性活动,它先于任何技术活动之前开始,并且持续贯穿于整个计算机软件的定义、开发和维护之中。
软件范围
        软件项目管理的第一个活动是软件范围的确定。范围是通过回答下列问题来定义的:
背景:待开发的软件如何适应大型的系统、产品或商业的背景,在该背景下要加什么约束?
信息目标:软件要产生什么样的客户可见的数据对象来作为输出使用?需要什么样的数据对象作为输入?
功能和性能:软件要执行什么样的功能使得输入数据才能变换为输出数据?需要满足什么特殊的性能特征吗?
软件范围
           软件项目范围在管理层和技术层都必须是无二义性的和可理解的。对软件范围的描述必须是确定的。即,
明确给出定量的数据(如并发用户数目、邮件列表的大小、允许的最大响应时间);
说明约束和/或限制(如产品成本、内存大小);
描述其他的特殊因素(如要用的算法能够很好地理解,并写成C++程序)。
管理的范围
有效的项目管理集中于三个P 上:
People
项目参与者
项目负责人
软件项目组
协调和通讯
项目开发——有机体
项目控制的问题?
项目跟踪的难题?
与国外的软件开发相比
缺乏规范的管理
缺乏管理所造成的问题
软件项目管理
软件项目计划
风险管理
项目成本预算
软件项目计划 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
提供一个框架,使得管理者能够对资源、成本及进度进行合理的估算。
一个限定的时间框架内
“最好的情况” 及“最坏的情况”
通过一个信息发现的过程实现的


软件项目计划—Project Planning Objectives
Advice:

 The more you know, the better you estimate. Therefore, update your estimates as the project progresses.

软件项目计划—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模型,包含了能够的所有特性,并结合了成本驱动因子对软件工程过程中每一步骤的影响评估。
软件项目计划 Software Project Planning
对估算的观察 Observations on Estimating
项目计划目标 Project Planning Objectives
软件范围 Software Scope
资源 Resources
软件项目估算 Software Project Estimation
分解技术  Decomposition
经验估算模型 Empirical Estimation Models
自行开发或购买的决策 The Make/Buy Decision
最常见的进度计划风险
功能无限蔓延
需求镀金或开发人员镀金
质量不定
计划过于乐观
设计欠佳
银弹综合症
研发导向的开发
人员薄弱
签约商失败
研发人员与客户的摩擦
风险管理 Risk Management
风险管理要素 Risk Management Principles
风险识别 Risk Identification
风险分析 Risk Analysis
风险的优先级 Risk Prioritization
风险管理计划 Risk Management planning
风险化解 Risk Resolution
风险监视 Risk Monitoring

Risk Management Principles


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

风险控制
风险管理计划—制定一个应对每个重要风险的方案,同时确保每一个单独的风险管理计划之间以及与整体项目计划之间相一致。
风险化解—每个重要风险所对应计划的执行。
风险监控—对解决风险的过程进行监控,还可以包括识别新的风险并将其反馈到正在进行的风险管理进程中。
软件项目风险管理五种状态
危机管理—风险已经造成麻烦后才处理。
失败处理—觉察到风险并迅速处理。
风险缓解—事先制订好风险发生后的补救       措施,但不作任何防范措施。
着力预防—将识别和防范作为项目一部分       加以规划和执行。
消灭根源—识别和消除风险根源。
软件项目风险管理原则
区分风险和已存在的现有问题
通过风险的管理变被动的面对风险,即消防状态为主动面对风险,即钓鱼状态
最小化项目失败的潜在可能
创造风险管理的气氛
Risk Identification
 

  如果你不问关于风险的问题,
 你就可能是正在问所遇到麻烦的
 问题

      — Tom Gilb
风险检查列表
产品规模—与要建造或要修改的软件的总体规模相关的风险。
商业影响—与管理或市场所加诸的约束相关的风险。
客户特性—与客户的素质以及开发者和客户定期通信的能力相关的风险。
过程定义—与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
开发环境—与用以建造产品的工具的可用性及质量相关的风险。
建造的技术—与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
人员数目与经验—与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
风险因素
性能风险—产品能够满足需求且符合于其       使用目的的不确定的程度。
成本风险—项目预算能够被维持的不确定       的程度。
支持风险—软件易于纠错、适应及增强的       不确定的程度。
进度风险—项目进度能够被维持且产品能       按时交付的不确定的程度。


软件成本
软件报价


涉及到软件成本的常见问题

软件成本的构成

历史经验:
人员规模越大,成本系数越高。
技术水平越高,成本系数越高。
开发周期越长,成本系数越高。

一般系数为:1.5~3.0之间。


历史经验:
系统越复杂,开发难度系数越高
开发架构与语言越高级,开发难度越高
功能点越精细,准确度越高
团队开发历史越久,准确度越高

功能点单价除了根据历史经验外可参考同等规模的同行报价。

软件报价的相关因素
软件成本
销售模式
市场战略

软件的销售办法

软件的报价原则
个性化定制的越多,成本加权越高
产品化成熟度越低,成本加权越高
行业与专业特征越明显,成本加权越高

同样功能和性能的软件产品,因为销售方式的不同,报价很可能相差巨大!
项目管理的人员
项目参与者
项目负责人
软件项目组
项目参与者
高级管理者:负责确定商业问题,这些问题往往对项目产生很大影响。
项目(技术)管理者:必须计划、激励、组织和控制软件开发人员。
开发人员:负责开发一个产品或应用软件所需的专门技术人员。
客户:负责说明待开发软件的需求的人员。
最终用户:一旦软件发布成为产品,最终用户是直接与软件进行交互的人。
项目负责人
解决问题:一个有效的软件项目负责人应该能够准确地诊断出技术的和管理的问题;系统地计划解决方案;适当地激励其他开发人员实现解决方案;把从以前的项目中学到的经验应用到新的环境下;如果最初的解决方案没有结果,能够灵活地改变方向。
管理能力:一个好的项目负责人必须掌管整个项目,他在必要时必须有信心进行控制,必须保证让优秀的技术人员能够按照他们的本性行事。
项目负责人
激励能力:为了提高项目组的生产率,项目负责人必须奖励具有主动性和作出成绩的人。并通过自己的行为表明约束下的冒险不会受到惩罚。
理解和控制能力:一个有效的项目负责人必须能够“读懂”人;他必须能够理解语言的和非语言的信号,并对发出这些信号的人的要求做出反应。项目负责人必须在高压力环境下保持良好的控制能力。

软件项目组
    项目分配人力资源的若干可选方案,设该项目需要n个人工作k年:
n个人被分配来完成m个不同的功能任务,相对而言几乎没有合作的情况发生;协调是软件管理者的责任,而他可能同时还有六个其他项目要管。
n个人被分配来完成m个不同的功能任务(m<n),建立非正式的小组;指定一个专门的小组负责人;小组之间的协调由软件管理者负责。
n个人被分成t个小组;每一个小组完成一个或多个功能任务;每一个小组有一个特定的结构,该结构是为同一个项目的所有小组定义的;协调工作由小组和软件项目管理者共同控制。
软件项目组
软件工程小组的组织方式:
民主分权式(Democratic Decentralized, DD):这种软件工程小组没有固定的负责人。任务协调者是短期指定的,之后就由其他协调不同任务的人取代。问题和解决方法的确定是由小组讨论决策的。
控制分权式(Controlled Decentralized, CD):这种软件工程小组有一个固定的负责人,他协调特定的任务及负责子任务的二级负责人关系。问题解决仍是一个群体活动,但解决方案的实现是有小组负责人在子组之间进行划分的。子组和个人间的通信是平行的,但也会发生沿着控制层产生的上下级的通信。
控制集权式(Controlled Centralized, CC):顶层的问题解决和内部小组协调是由小组负责人管理的。负责人和小组成员之间的通信是上下级式的。

软件项目组
计划软件工程小组结构时应该考虑的因素:
待解决问题的困难程度;
要生成的程序的规模,以代码行或功能点来衡量;
小组成员需要待在一起的时间(小组生命期);
问题能够被模块化的程度;
待开发系统所要求的质量和可靠性;
交付日期的严格程度;
项目所需要的社交性(通信)的程度。

软件项目组
因为集中式的结构能够更快地完成任务,因此最适合处理简单问题。而分散式的小组比起个人而言能够产生更多更好的解决方案,因此这种小组在处理复杂问题时成功的可能性更大。因为CD小组是集中式地解决问题,所以CD或CC小组结构能够成功地用来解决简单的问题。而DD结构则适合于解决难度较大的问题。
因为小组的性能与必须进行的通信量成反比,所以如果子组很容易协调的话,很大的项目最好采用CC或CD结构的小组组织方式。

软件项目组
因为小组的性能与必须进行的通信量成反比,所以如果子组很容易协调的话,很大的项目最好采用CC或CD结构的小组组织方式。
DD小组结构最适合于解决模块化程度较低的问题,因为它需要更多的通信。如果有可能要较高的模块化程度,则CC或CD结构更加合适。
CC和CD小组已被发现能够产生比DD小组更少的缺陷,但这与小组所采用的质量保证活动密切相关。分散式结构通常需要比集中式结构更多的时间来完成一个项目,但是如果要求高社交性,它是最合适的。
软件项目组
软件工程小组的组织范型:
封闭式范型:按照传统的权利层次来组织小组(类似CC小组)。这种小组在开发与过去已经做过的产品类似的软件时十分有效,但这种封闭式范型下难以进行创新式的工作。
随机式范型:松散地组织小组,并依赖于小组成员个人的主动性。当需要创新或技术上的突破时,按照这种随机式范型组织的小组很有优势。但当需要“有次序的执行”才能完成工作时,这种小组组织范型就会陷入困境。
软件项目组
软件工程小组的组织范型:
开放式范型:试图以一种既具有封闭式范型的控制性、又包含随机式范型的创新性的方式来组织小组。工作的执行结合了大量的通信和基于小组一致意见的决策。开放式范型小组结构特别适合于解决复杂问题,但可能不象其他类型小组那么效率高。
同步式范型:依赖于问题的自然划分,组织小组成员各自解决问题的片段,他们之间没有什么主动的通信需求。
协调和通信问题
有很多原因会使软件项目陷入困境。许多开发项目规模宏大,以至于使小组成员间的关系复杂性高混乱、难以协调。不确定性是经常存在的,它会引起困扰项目组的一连串的改变。
软件工程小组必须建立有效的方法,以协调参与工作的人员之间的关系。要完成这项任务,必须建立小组成员之间及多个小组之间的正式的和非正式的通信机制。
正式的通信是通过文字、会议及其他相对而言非交互和非个人的通信渠道来实现。非正式的通信则更加个人化。软件工程小组的成员在一个特别的基础上共享想法,出现问题时相互帮助,且每天相互交流。
项目协调技术
正式的、非个人的方法:包括软件工程文档和交付物(如源程序)、技术备忘录、项目里程碑、进度和项目控制工具、修改请求及相关文档、错误跟踪报告、中心库数据。
正式的、个人间的规程:集中表现于软件工程工作中产品的质量保证活动中,包括状态复审会议及设计和代码检查。
非正式的、个人间的规程:包括信息传播、问题解决的小组会议。
电子通信:包括电子邮件、电子公告栏、Web站点以及基于视频的会议系统。
个人间的网络:与项目组之外的人进行的非正式的讨论,这些人可能有足够的经验或见解,能够帮助项目组成员。
项目管理的问题
           软件项目管理者从软件项目一开始就面临着进退两难的局面。需要定量的估算成本和有组织的计划项目的进展,但却没有可靠的信息可以使用。对软件需求的详细分析可以提供必要的估算信息,但分析常常要花数周甚至数月的时间才能完成。更糟糕的是,随着项目的进展经常发生改变,需求可能是不固定的。
项目管理中的常见问题
项目管理中的常见问题(Cont.)
产生问题的根源
解决问题的最佳途径
问题分解
问题分解,有时称为划分,是一个软件需求分析的核心活动。在确定软件范围的活动中并没有完全分解问题。分解一般用于两个主要领域:
         (1)必须交付的功能;(2)交付所用的过程。
面对复杂的问题人们常常采用分而治之的策略。简单讲,就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在估算开始之前,范围中所描述的软件功能必须被评估和精化,以提供更多的细节。因为成本和进度估算都是面向功能的,所以某种程度的分解是很有用的。
项目管理的过程
软件过程的一般阶段(定义、开发和维护)适用于所有软件项目。问题在于如何选择一个合适项目组要开发的软件过程模型。
项目管理者必须决定哪一个过程模型最适合待开发项目,然后基于公共过程框架活动集合,定义一个初步的计划,便可以开始进行过程分解,即建立一个完整的计划,以反映框架活动中所需要的工作任务。
工作内容
收集跟踪数据的时机
跟踪数据域值
合并问题和过程
           项目计划开始于问题和过程的合并。软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合来完成。
项         目
           疲惫不堪的产业专家们在讨论特别困难的软件项目时,常常提及90-90规则:

一个系统的第一个90%花费了所分配工作量和时间的90%,系统最后10%也会花费所分配工作量和时间的90%。
项         目
评估进度所采用的方法是有缺陷的(很显然,如果90-90规则是真的,90%的完成度就不是一个准确的指标)。
没有办法测定进度,因为没有可用的、量化的度量。
项目计划在项目结束时没有考虑协调所需要的资源。
没有明确地考虑风险,没有建立缓解、监控和管理风险的计划。
进度计划是不现实或有缺陷的。
         为了克服这些问题,在项目开始时必须花时间建立一个现实的计划,在项目进行中监控该计划,并在项目整个过程中控制质量和变化。
环境并不简单
开发环境这一术语是指在开发和部署系统时所需的全部工件,其中包括工具、指南、流程、模板和基础设施。
环境包括:
组织的开发环境
项目的开发环境
组织的开发环境 & 项目的开发环境
组织的开发环境
开发组织内的不同项目之间通常会存在许多相似之处。各项目以相似的方法使用同样的工具。对于不同的项目,流程大致相似,某些指南也可能一样。因此,如果开发组织让一个团队来开发和维护组织的开发环境(即由组织范围的流程、工具使用和基础设施组成的开发环境),就可以提高开发效率。
项目的开发环境
就软件开发项目而言,是指在项目开发和部署系统时所需的全部工件,其中包括工具、指南、流程、模板和基础设施。
组织的开发环境 VS 项目的开发环境
软件配置管理
当开发软件系统的过程中,变化是不可避免的。这些变化使得在同一个项目中工作的软件开发人员之间的彼此不理解程度更加增大。当变化进行前没有经过分析、变化实现前没有被记录、没有向那些需要知道的人报告变化、或变化没有以可以改善质量及减少错误的方式被控制时,大量的不理解问题将会产生。

协调软件开发以减少由变化带来的不理解性到最小程度的技术称为配置管理。软件配置管理(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,可应用于商业软件,并被向大型的和小型的软件工程组织推荐。
软件质量
软件质量定义
           明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。
软件质量
软件质量定义
软件需求是进行“质量”度量的基础。与需求不符就是质量不高。
指定的标准定义了一组指导软件开发的准则。如果不能遵守这些准则,就极有可能导致质量不高。
通常有一组“隐含需求”是不被提及的(如对维护性的需求)。如果软件符合了明确的需求却没有满足隐含需求,软件质量仍然值得怀疑。
软件质量的定义
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模型中的软件质量要素
软件质量保证
          软件质量保证(SQA)是一种应用于整个软件过程的保护性活动。SQA包括:
一种质量管理方法
有效的软件工程技术(方法和工具)
在整个软件过程中采用的正式技术复审
一种多层次的测试策略
对软件文档及其修改的控制
保证遵从软件开发标准的规程
度量和报告机制
SQA小组
 在一个组织中有多个机构负有保证软件质量的责任,包括软件工程师、项目管理者、客户、销售人员和SQA小组成员。
SQA小组负责质量保证的计划、监督、记录、分析及报告工作。
SQA小组充当客户在公司内部的代表。这就是说,SQA小组的成员必须以客户的观点看待软件。
SQA计划
           SQA计划为建立软件质量保证提供一张行路图,其由SQA小组和项目组共同制定,充当软件项目中SQA活动的模板。
需要进行的评价;
需要进行的审计和复审;
项目可采用的标准;
错误报告和跟踪过程;
由SQA小组产生的文挡;
为软件项目组提供的反馈数量。
SQA活动
为项目准备SQA计划;
参与开发该项目的软件过程描述;
复审各项软件工程活动、对其是否符合定义好的软件过程进行核实;
审计指定的软件工作产品、对其是否符合定义好的软件过程中的相应部分进行核实;
确保软件工作及工作产品产品中的偏差已被记录在案,并根据预定规程进行处理;
记录所有不符合的部分,并报告给高级管理者;
协调变化的控制和管理,并帮助收集和分析软件度量信息。
总         结
           任何工程方法(包括软件工程)必须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的过程改进,正是这种改进导致了更加成熟的软件工程方法的不断出现。支持软件工程的根基就在于对质量的关注。

 
  下载地址
  点这里下载 → 本地高速下载 点这里下载 → 迅雷专用下载 点这里下载 → 迅雷离线链下载  
点这里下载 → 本地高速下载 点这里下载 → 迅雷专用下载 点这里下载 → 迅雷离线链下载
·上一课件:软件质量与项目管理.ppt
·下一课件:抗日战争
  课件评论
 

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

   评论摘要(共 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号