当前位置: 首页icon 51CTO软考 > 软考资讯 > >软考关系模式属性集 关系模式的主属性

软考关系模式属性集 关系模式的主属性

作者:Sister03212024-01-19 01:00:03
备考咨询 刷题指导
添加专属学姐
下载资料 2024上半年软考备考资料+考试大纲
下载按钮 下载
引号

0引言   项目管理是一项非常有挑战性的工作,尤其是软件项目管理。做项目管理的人都知道“项目三角形”法则,也就是制约项目的三个因素———时间、成本、范围各构成三角形的一边,其中一个因素的变化必然引起另一个或者两个同时发生变化, 例如项目要赶进度(缩短项目时间),可以投入成本、增加人力,或者将原定计划要实现的范围缩小,如何做取舍就要靠项目经理进行权衡选择。如果要做个譬喻,项目经理不亚于是“在针尖上跳

引号

0引言
  项目管理是一项非常有挑战性的工作,尤其是软件项目管理。做项目管理的人都知道“项目三角形”法则,也就是制约项目的三个因素———时间、成本、范围各构成三角形的一边,其中一个因素的变化必然引起另一个或者两个同时发生变化,
例如项目要赶进度(缩短项目时间),可以投入成本、增加人力,或者将原定计划要实现的范围缩小,如何做取舍就要靠项目经理进行权衡选择。如果要做个譬喻,项目经理不亚于是“在针尖上跳舞”的舞者,他甚至可能要在捉襟见肘的寸方三角形舞台上导出一段“不可能完成任务”(mission impossible)的“群舞”。
1 范围管理概论
  项目经理如此不幸,而软件项目经理就更可以说是“不幸中的不幸”,因为根据经典数据统计,软件开发项目的成功率目前不超过50%,如果时光回退十几年,这个数字会再低十个百分点,而且对于规模越大的项目,其成功率越低。
到底是哪些原因导致如此低的成功率,通过对过往失败项目案例进行整理和分析,人们生了问题才临时采取行动,试图迅速地解决问题。这样的管理方式往往让项目组很被动,也大大增加了管理成本,并使项目的进度面临很大的风险,所以必须采用主动式的风险管理模式,防患于未然。
发现其中一个主要的“败因”是范围管理失去了控制,从而引发“范围蔓延”(Scope Creep),以这种方式失败的项目表现为:项目已经比原定计划大大延期,客户仍在源源不断地有新需求,或者对已经完成的功能提出各种修改意见,开发团队士气低迷,总有完不成的开发任务,项目预算已几乎消耗殆尽,而距离项目收尾却遥遥无期。
范围管理难在何处?通过对以这类原因失败的项目进行分析和总结,大致可以归为客户方和开发方两大“责任方”。这里有两种观点。
(1) 责任在于客户。这类观点通常是由开发方“总结”得出的,经常从开发方的技术人员口中听到诸如此类的抱怨,“我们的客户从项目一开始就不清楚需要做什么”,“他们总是在变,今天想要这个,明天又想要那个,更难以忍受的是他们的要求又往往是矛盾的”,
这种来自于客户方的需求“模糊”以及“朝三暮四”,使得项目的范围充满了不确定性,而开发方头上悬着“范围”—“时间”—“成本”这一“项目三角形”达摩克利斯之剑,范围的变动就意味着项目开发周期的延长和成本增加,带来的严重后果就是项目严重超支、项目延期难以交付而导致最终的项目失败。
(2)责任在于开发方。幸运的是开放方的责任并不是客户“投桃报李”总结出来的,开发方拥有很好的自觉反省,自己道出了“苦水”。他们通常认为,项目失败很大的一个主因是范围的定义不够明确,做不到可量化、可验证的程度,因而在进度和成本的量度和控制上面引发了多米诺效应,最后导致项目的“滑铁卢”。
而为什么项目开发方的管理团队无法做到范围界定明确的程度,原因有以下几个:
1)开发方缺乏规范的项目范围管理过程是最主要的原因。比如缺少范围评审环节,开发方与客户方无法在项目开头就对项目范围进行很好的商讨、澄清,并达成共识而且共同签署范围确认书,给后来的范围蔓延埋下隐患;
又比如开发方没有对变更进行有效的管理控制,在项目进行过程中,面对客户方“漫天要价”提出的后续需求缺乏有效变更系统加以辨别、遴选、记录和处理,最终由“量变”引发“质变”,项目范围远远超出最初预计。
2)开发方缺乏正确的方法作为指导。这里的方法即指软件工程领域中的方法,比如需求采集方法,也指项目管理中的方法,比如在范围分解的时候,运用正确的工作分解结构(WBS)法进行范围划分。
3)没有使用必要的项目管理工具进一步加强范围管理以及其他管理活动,给项目成功带来更高的保险系数。典型的工具有微软的Project 2000,以及IBM的统一项目管理平台。
以上对范围管理失控原因的总结和分析都很有道理,从中拿出任何一条,都可以在众多失败的项目中找到支持的佐证。为了解决范围管理这个难题,项目管理协会(PMI)和软件工程协会(SEI)都提出相应的范围管理体系。
PMI的项目管理知识体系指南(PM-BOK)对范围管理的定义是“为了成功完成项目,需要确保项目包括所需的全部工作,但又只包括必须完成的工作的各个过程”,从这个定义可以得知PMI的范围管理是一个过程管理,它关注的是在项目进行过程中的各项工作活动需要围绕项目交付展开,既要包含所有必需的活动,
也不能包含不必要的活动,简而言之就是不多不少(just-in-time)。PMI的范围管理主要划分为五个过程展开,这五个过程分别是范围规划(planning)、范围定义(definition)、范围分解(break-down)、范围核实(verification)以及范围变更控制(con-trol),这五个过程是这么定义的。
(1)范围规划。规划主要指的是实现范围管理的策略,比如通过什么办法来采集需求以得到项目范围,以什么方式来进行范围分解等,范围规划相当于整个范围管理的一个计划,这个过程主要是得出一份项目范围管理计划书。
(2)范围定义。在范围管理计划的指导下,对要交付的项目制品进行分析,或者对历史同类项目制品进行识别,编写出一份项目范围说明书。
(3)范围分解。利用定义过程输出的项目范围说明书,按层次将项目制品分解成较小的可交付部分,同时也将项目工作分成较小和更便于管理的多项子工作,分解后得到一个树状分解结构,“根”代表项目,底层组成部分(“树叶”)的计划工作称作“工作包”,
这些工作包可以安排在进度表中,进行费用估算以及监控。
(4)范围核实。范围核实将对上述过程产生的成果进行评审,如开发方的项目管理委员会召开专家评审会议进行范围评估,范围核实也包括在项目收尾阶段客户对项目制品进行验收的过程。
(5)范围控制。范围控制将对造成项目范围变更的因素施加影响,并控制变更造成的后果,PMI认为变更是不可避免的,但是必须强制一定形式的变更控制过程,使得变更尽量可控。
综合而论,PMI的范围管理定义了一个过程栈,在这个过程栈中以上一个过程的输出(通常是一个或多个文档)作为输入,采用组织既有的资产(比如文档模板、表格、历史项目数据)以及方法(比如专家判断)进行处理,然后得到一份或多份结果文档,
而这些结果文档又可以作为下一过程的输入。通过有序的过程将项目利益相关方以及有关资源组织起来,并且通过专家判断、会议评审等方法,使项目范围定义渐进地得到明朗化,使其定义和分解较为全面与合理,达到可量化、可计划、可控制的一个良好管理状态。
2 软件项目中的范围管理
  PMI只对项目范围的管理提供指导,不涉及具体的应用领域,比如软件开发领域,因而PMBOK只是一个通用项目管理的指导体系,要完整地进行范围管理,还须结合特定的应用领域加以运用。对于软件开发项目来说,项目制品指项目要交付的软件产品,因为项目范围取决于产品范围,
所以软件的项目范围管理依赖于软件产品范围管理,软件产品范围则来源于软件的使用者———客户对软件所提出的需求。由于认识到软件需求的重要性,在20世纪80年代中期,从SEI中分离并形成了软件工程的子领域———需求工程(Require-ment Engineering,RE)。
进入到20世纪90年代,需求工程逐渐成为研究的热点之一,1993年起每两年举办一次需求工程国际研讨会(ISRE),1994年起每两年举办一次需求工程国际会议(ICRE)。此外一些关于需求工程的工作小组也相继成立,
如欧洲的RENOIR(Requirements Engineering Network of International Co-operating Research Groups),并开始开展与需求工程研究有关的各项工作。需求工程研究使用已证实有效的技术、方法进行需求分析,确定用户需求,帮助分析人员理解问题并定义目标系统的所有外部特征。
与软件工程提出的生命周期类似,需求工程也有需求生命周期,它将最初用户的设想和要求通过一系列过程,并采用适合的工程方法转化为可以指导软件开发的需求规格,并提出要对这些需求进行相应的管理以跟踪和控制。
从上述特征来看,需求工程与PMI的范围管理实质上都是过程管理,而且重点在于各种说明详尽的文档编制,通过文档来驱动和指导开发,以求做到任何的进展和变动都有文档记录和跟踪,在开发流程和开发文档的双重保险机制下,尽可能避免发生差错,提高过程控制能力。
但是依靠过程式的管理是否完全适合软件这样一种特别的项目制品?是否能够有效地对范围进行管理,以提高项目成功系数?回答这个问题可以从三个方面入手:第一,软件这种制品有什么特征;第二,如何衡量一个软件开发项目的成功;第三,管理的本质又是什么。
先来看软件这一特殊的项目制品,说它特殊是因为软件不同于可见的有形物品,有形物品比如房屋、桥梁可以用计量单位和计量方法进行描述和标识,比如建筑物的位置、高度、面积、体积及空间位置等,软件则不然,软件是运行于计算机中的代码,

免费刷题报考资讯 机考模拟 学习群