LoveUnix » 行业应用 项目实施 » 软件开发中的风险(未完)
让LU留住您的每

一天 让LU博客留住您的每一天
2004-6-3 09:56 threehair
软件开发中的风险<br /><br />一 风险综述<br />   <br />    同任何工程项目一样,软件开发项目中也存在着风险。由于风险是在项目开始之后才开始对项目的开发起负面的影响,所以风险分析的不足,或是风险回避措施不得力,都很有可能造成软件开发的失败。风险分析是在事前的一种估计,凭借一定的技术手段和丰富的经验,基本能够对项目的风险做出比较准确的估计,经过慎重的考虑提出可行的风险回避措施,是避免损失的重要环节。

2004-6-3 10:17 threehair
二 风险分类<br />任何软件的开发,其主要风险均来自于两个方面,一是软件管理,二是软件体系结构。<br /><br />1 软件管理风险<br /><br />    软件管理是保证软件开发工程化的手段。软件管理将影响到软件的下列因素:  <br /><br />(1)软件是否能够按工期的要求完成<br />    软件的工期常常是制约软件质量的主要因素。软件的开发不同于其他的工程,在不同的工程阶段,需要的人员不同,需要配合的方面也不同,所有这些都需要行之有效的软件管理的保证。  <br /><br />(2)软件需求的调研是否深入透彻<br />    软件的需求是确保软件正确反映用户的对软件使用的重要的文档,探讨软件需求是软件开发的起始点,但软件的需求却会贯穿整个软件的开发过程,软件管理需要对软件需求的变化进行控制和管理,一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成;同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度,不能过细造成时间的浪费,也不能过粗,造成软件缺陷。  <br /><br />(3)软件的实现技术手段是否能够同时满足性能要求<br />    软件的构造需要对软件构造过程中的使用的各种技术进行评估。软件构造技术通常是这样:最成熟的技术,往往不能体现最好的软件性能;先进的技术,往往人员对其熟悉程度不够,对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素,并做出合理的权衡决策。  <br /><br />(4)软件质量体系是否能够被有效地保证<br />任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系,是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础,也是开发商和用户进行交流的基础和依据。  <br /><br /><br />2 软件体系结构影响到软件的如下质量因素:  <br /><br />(1)软件的可伸缩性<br />    指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和软件开发周期较长的矛盾,软件升级的需要显得非常迫切。如果软件的升级和移植非常困难,软件的生命期必定很短,使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行,甚至被废弃不用,造成巨大的浪费。  <br /><br />(2)软件的可维护性<br />    软件的维护也是必然的事情,为了保证软件的较长使用寿命,软件就必须适应不断的业务需求变化,根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上,即软件代码无需修改,仅仅是在系统提供的配置文件中进行适当的修改,然后软件重新加载进入运行状态,就完成了系统部分功能和性能要求的变化。对于重大改动,需要打开源代码进行修改的,也仅仅是先继承原先的代码,然后用新的功能接替原先的调用接口,这样将把软件改动量减小到最低。  <br /><br />(3)软件易用性<br />    软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中,设计复杂,功能强大而完备,但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面,缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。

2004-6-3 15:54 threehair
三项目管理风险<br />项目管理按照PMI的定义如下:<br />Project management is the applications of knowledge, skills,tools, techniques to project activities in order to meet or exceed stakeholder needs and expectations from the project. <br />(在项目活中运用一系列的知识、技能、工具和技术,以满足或超过相关利益者对项目的要求)<br />此定义指出了项目管理所涉及的范畴和达到的目标。为了满足或超过相关利益者对项目的要求,只有在项目管理中考虑到项目的方方面,尽量最小化风险,才能使利润最大化。<br /><br /><br />以下引自《软件开发项目失败原因分析》(中国计算机报-杨立群 2001年11月06日)<br /><br /><!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->需求内容不明确,把握不充分 <br /><br />这是我们经常遇到的问题。一方面,由于客户(需求方)IT知识缺乏,一开始自己也不知道要开发什么样的系统,或者懒于系统地整理出来,经常是走一步算一步,不断地提出和更改需求,使得实现方叫苦连天。另一方面,实现方由于行业知识的缺乏和设计人员水平的低下,不能完全理解客户的需求说明,而又没有加以严格的确认,经常是以想当然的方法进行系统设计,结果是推倒重来。因此,需求分析必须注重双方理解和认识的一致,逐项逐条地进行确认。<br /><br />工数估算过少 <br /><br />软件开发的工数估算是一项很重要的工作,必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素,将一些定性的内容定量化。对工数的重要性认识不足,经常用拍脑袋的方式草算,是最常见的问题。还有,软件开发经常会出现一些平时不可见的工作量,如人员的培训时间、各个开发阶段的评审时间等,经验不足的项目经理经常会遗漏。同时,还有如下一些原因也是很典型的:<br />(1)出于客户和公司上层的压力在工数估算上予以妥协。例如,客户威胁要用工数更少的开发商,公司因经营困难必须削减费用、缩短工期,最后只能妥协,寄希望于员工加班。<br />(2)设计者过于自信或出于自尊心问题,对一些技术问题不够重视,或者担心估算多被嘲笑。<br />(3)过分凭经验。由于有过去的成功经验,没有具体分析就认为这次项目估计也差不多,而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多,而且是一个新的行业。<br /><br />项目组织过小 <br /><br />每个公司都希望以最少的成本完成项目,人手不足是大多数项目都会面临的问题。还有一种情况是项目组成员的技术水平达不到项目的要求,公司只能提供这些分配好的技术人员,或者由于项目经理的失误,在项目工数估算时没有明确要求技术水平,寄希望于员工自己努力。还有一些项目经理认为,在项目启动时不需要高水平的技术人员。<br /><br />开发计划不充分 <br /><br />没有良好的开发计划和开发目标,项目的成功就无从谈起。开发计划太粗略,主要反映在以下几个方面:<br />(1)工作分担(责任范围)不明确,工作分割结构(WBS)与项目组织结构不明确或者不相对应,各成员之间的接口不明确,导致有一些工作根本无人负责。<br />(2)每个开发阶段的提交结果定义不明确,中间结果是否已经完成,完成了多少模糊不清,结果是到了项目后期堆积了大量工作。<br />(3)开发计划没有指定里程碑或检查点,也没有规定设计评审期。<br />(4)开发计划没有规定进度管理方法和职责,导致无法正常进行进度管理。 <br /><br />设计能力不足 <br /><br />项目组设计人员能力的低下是项目失败的原因之一。一方面,由于对技术问题的难度未能正确评价,将设计任务交给了与要求水平不相称的人员,造成设计结果无法实现。另一方面,随着资源外包现象的日益普遍,一些公司经常因工期紧而匆忙将中标的项目部分转包给其他协作公司,这些公司的设计能力如不加仔细评价,就会对整个项目造成影响。<br /><br />项目经理的管理能力不足 <br /><br />没有及时把握进度。项目经理自己也不知道项目的状态,下属人员报喜不报忧,害怕报告问题后给自己添麻烦。进度管理必须随时收集有关项目管理的数据,开发人员总是担心管理工作会增加自己的工作量,不愿配合。管理人员甚至不知道应该收集哪些数据。 <br />由于没有进行定期的项目评审报告会,表面上进展顺利而实际上隐藏着危机。管理人员总是轻信下属的报告而没有加以核实。 <br />出现严重问题时,管理人员没有根据现阶段状况重新评价需求分析结果、工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚的措施,致使问题更严重。 <br /><br />以上谈到了项目失败的几方面原因,实际上还有很多原因,很难一一列举。在这里我们没有篇幅提出如何避免这些问题的对策,但是通过这些原因的列举,希望能激起读者的共鸣。<!--QuoteEnd--></div><!--QuoteEEnd--><br /><br /><br />由以上可以看出项目管理风险来自于软件项目自身的特点: 软件产品不可见。开发的进展以及软件的质量是否符合要求难于度量,从而使软件的管理难于把握。

2004-6-7 19:08 threehair
四软件体系结构的风险<br /><br /><br />以下引自《软件体系结构的概念 》张友生(转载自程序员) <br /><br /><!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin--> <br /> 虽然软件体系结构已经在软件工程领域中有着广泛的应用,但迄今为止还没有一个被大家所公认的定义。许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画,较为典型的定义有:<br /><br />  (1)Dewayne Perry和A1ex Wo1f曾这样定义:软件体系结构是具有一定形式的结构化元素,即构件的集合,包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分处理构件、数据构件和连接构件,这一方法在其他的定义和方法中基本上得到保持。 <br /><br /><br />  (2)Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次,这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取,给设计元素分配特定功能,设计元素的组织,规模和性能,在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题,如全局组织和全局控制结构、关于通讯、同步与数据存取的协议,设计构件功能定义,物理分布与合成,设计方案的选择、评估与实现等。 <br /><br /><br />  (3)Kruchten指出,软件体系结构有四个角度,它们从不同方面对系统进行描述:概念角度描述系统的主要构件及它们之间的关系;模块角度包含功能分解与层次结构;运行角度描述了一个系统的动态结构;代码角度描述了各种代码和库函数在开发环境中的组织。<br /><br /><br />  (4)Hayes Roth则认为软件体系结构是一个抽象的系统规范,主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。<br /><br /><br />  (5)David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下的定义:软件体系结构是一个程序/系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。<br /><br /><br />  (6)Barry Boehm和他的学生提出,一个软件体系结构包括一个软件和系统构件,互联及约束的集合;一个系统需求说明的集合;一个基本原理用以说明这一构件,互联和约束能够满足系统需求。<br /><br /><br />  (7)1997年,Bass,Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义:一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中,&quot;软件外部的可见特性&quot;是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。<br /><br /><br />  总之,软件体系结构的研究正在发展,软件体系结构的定义也必然随之完善。在以后的文章里,如果不特别指出,我们将使用软件体系结构的下列定义:<br /><br /><br />  软件体系结构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构,并且显示了系统需求和构成系统的元素之间的对应关系,提供了一些设计决策的基本原理。<!--QuoteEnd--></div><!--QuoteEEnd--><br /><br />软件体系结构是软件开发过程中的存在的技术风险。在项目分类中,已经详细说明软件体系结构对软件质量的那些方面产生影响。<br /><br /><br /><!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin-->  六十年代的软件危机使得人们开始重视软件工程的研究。起初,人们把软件设计的重点放在数据结构和算法的选择上,随着软件系统规模越来越大、越来越复杂,整个系统的结构和规格说明显得越来越重要。软件危机的程度日益加剧,现有的软件工程方法对此显得力不从心。对于大规模的复杂软件系统来说,对总体的系统结构设计和规格说明比起对计算的算法和数据结构的选择已经变得明显重要得多。在此种背景下,人们认识到软件体系结构的重要性,并认为对软件体系结构的系统、深入的研究将会成为提高软件生产率和解决软件维护问题的新的最有希望的途径。<br /><br /><br />  自从软件系统首次被分成许多模块,模块之间有相互作用,组合起来有整体的属性,就具有了体系结构。好的开发者常常会使用一些体系结构模式作为软件系统结构设计策略,但他们并没有规范地、明确地表达出来,这样就无法将他们的知识与别人交流。软件体系结构是设计抽象的进一步发展,满足了更好地理解软件系统,更方便地开发更大、更复杂的软件系统的需要。<br /><br /><br />  事实上,软件总是有体系结构的,不存在没有体系结构的软件。体系结构(Architecture)一词在英文里就是&quot;建筑&quot;的意思。把软件比作一座楼房,从整体上讲,是因为它有基础、主体和装饰,即操作系统之上的基础设施软件、实现计算逻辑的主体应用程序、方便使用的用户界面程序。从细节上来看每一个程序也是有结构的。早期的结构化程序就是以语句组成模块,模块的聚集和嵌套形成层层调用的程序结构,也就是体系结构。结构化程序的程序(表达)结构和(计算的)逻辑结构的一致性及自顶向下开发方法自然而然地形成了体系结构。由于结构化程序设计时代程序规模不大,通过强调结构化程序设计方法学,自顶向下、逐步求精,并注意模块的耦合性就可以得到相对良好的结构,所以,并未特别研究软件体系结构。<br /><br /><br />  我们可以作个简单的比喻,结构化程序设计时代是以砖、瓦、灰、沙、石、预制梁、柱、屋面板盖平房和小楼,而面向对象时代以整面墙、整间房、一层楼梯的预制件盖高楼大厦。构件怎样搭配才合理?体系结构怎样构造容易?重要构件有了更改后,如何保证整栋高楼不倒?每种应用领域需要什么构件(医院、工厂、旅馆)?有哪些实用、美观、强度、造价合理的构件骨架使建造出来的建筑(即体系结构)更能满足用户的需求?如同土木工程进入到现代建筑学一样,软件也从传统的软件工程进入到现代面向对象的软件工程,研究整个软件系统的体系结构,寻求建构最快、成本最低、质量最好的构造过程。<br /><br /><br />  软件体系结构虽脱胎于软件工程,但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法,最近几年软件体系结构研究已完全独立于软件工程的研究,成为计算机科学的一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维护问题,是研究软件体系结构的根本目的。<!--QuoteEnd--></div><!--QuoteEEnd-->

2004-6-8 08:38 shala
<!--emo&:o--><img src='style_emoticons/default/ohmy.gif' border='0' style='vertical-align:middle' alt='ohmy.gif' /><!--endemo-->

页: [1]


Powered by Discuz! Archiver 5.5.0  © 2001-2006 Comsenz Inc.