软件开发的基本策略_精品文档.doc
- 文档编号:694141
- 上传时间:2022-10-12
- 格式:DOC
- 页数:18
- 大小:104.50KB
软件开发的基本策略_精品文档.doc
《软件开发的基本策略_精品文档.doc》由会员分享,可在线阅读,更多相关《软件开发的基本策略_精品文档.doc(18页珍藏版)》请在冰豆网上搜索。
软件开发的基本策略
人们在探索软件工程方法的几十年里,提出了许多软件开发的方法,但这些方法都不是严密的理论。
我们不应该教条地套用方法,更重要的是学会"选择合适的方法"和"产生新方法"。
软件开发中的三种基本策略:
复用、分而治之、优化与折衷
复用
对于建立软件系统而言,所谓复用就是利用某些已开发的、对建立新系统有用的软件元素来生成新的软件系统。
在一个新系统中,大部分的内容是成熟的,只有小部分内容是创新的。
一般地,可以相信成熟的东西总是比较可靠的,而大量成熟的工作可以通过复用来快速实现,人们应该把大部分的时间用在小比例的创新工作上,而把小部分的时间用在大比例的成熟工作中,这样才能把工作做得既快又好。
我们将具有一定集成度并可以重复使用的软件组成单元称为软构件(SoftwareComponent),软件复用就是直接使用已有的软构件,即可组装(或加以合理修改)成新的系统,而可以不必每次从零做起。
一方面,软件复用方法合理化并简化了软件开发过程,减少了总的开发工作量与维护代价,既降低了软件的成本又提高了生产率。
另一方面,由于软构件是经过反复使用验证的,自身具有较高的质量,因此由软构件组成的新系统也具有较高的质量。
分而治之
分而治之是指把大而复杂的问题分解成若干个简单的小问题,然后逐个解决。
这种朴素的思想来源于人们生活与工作的经验,也完全适合于技术领域。
诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。
优化与折衷
软件的优化是指优化软件的各个质量因素,如提高运行速度、提高对内存资源的利用率、使用户界面更加友好、使三维图形的真实感更强等等。
我们应该树立这样的正确认识:
优化工作不是可有可无的事情,而是必须要做的事情。
当优化工作成为一种责任时,程序员才会不断改进软件中的算法,数据结构和程序组织,从而提高软件质量。
著名的3D游戏软件Quake,能够在PC机上实时地绘制高度真实感的复杂场景。
Quake的开发者能把很多成熟的图形技术发挥到极致,例如把Bresenham画线、多边形裁剪、树遍历等算法的速度提高近一个数量级,其技术水平已经远胜于目前国内领先的图形学相关科研成果。
优化工作是十分复杂的,有时很难实现所有目标的优化,这时就需要"折衷"策略。
软件的折衷策略是指通过协调各个质量因素,实现整体质量的最优。
软件折衷的重要原则是不能使某一方损失关键的职能,更不可以象"舍鱼而取熊掌"那样抛弃一方。
例如3D动画软件的瓶颈通常是速度,但如果为了提高速度而在程序中取消光照明计算,那么场景就会丧失真实感,3D动画也就不再有意义了。
折衷是有原则的,如果滥用折衷的话,那么一旦碰到困难,人们就会用拆东墙补西墙的方式去折衷,不再下苦功去做有意义的优化。
所以,我们应当坚持这样的折衷立场:
在保证其它因素不差的前提下,使某些因素变得更好。
人们对软件存在着许多错误的观点,这些观点表面上看起来很有道理,符合人们的直觉,但实际上给管理者和开发人员带来了严重的问题。
许多人认识到下述观点是错误的,但遗憾的是旧的观念和方法培植了拙劣的管理和技术习惯。
观点之一
我们拥有一套讲述如何开发软件的书籍,书中充满了标准与示例,可以帮助我们解决软件开发中遇到的任何问题。
客观事实
好的参考书无疑能指导我们的工作,充分利用书籍中的方法、技术和技巧,可以有效地解决软件开发中大量常见的问题。
但实践者并不能依赖于书籍,因为在现实工作中,由于条件千差万别,即使是相当成熟的软件工程规范,常常也无法套用。
另外,软件技术日新月异,没有哪一种软件标准能长盛不衰。
观点之二
如果我们已经落后于计划,可以增加更多的程序员来赶上进度。
客观事实
软件开发不同于传统的机械制造,人多不见得力量大。
如果给落后于计划的项目增添新人,可能会更加延误项目。
因为新人会产生很多新的错误,使项目混乱,并且原有的开发人员向新人解释工作和交流思想都要花费时间,使实际的开发时间更少,所以制定恰如其分的项目计划是很重要的。
【讲解】假设一个项目估计需要12人月工作量,指定由3个人在4个月内完成,如果第一个月的任务花了两个月才完成,那么增加人力的结果如何?
假设增加2个人参加项目,不论新增加的人适应能力有多强,总需要有人去帮助了解熟悉情况,如果这些工作占用了一个月的时间,这样又有3个人月工作量在新计划之外。
由于人员增加,工作任务需要重新划分,到第3个月结束时虽然有5个人在工作,实际上余留下7个人的工作量。
观点之三
项目需求总是在不断变化,但这些变化能够很容易地满足,因为软件是灵活的。
客观事实
软件需求确实是经常变化的,但这些变化产生的影响会随着其引入时间的不同而不同。
对需求把握得越准确,软件的修修补补就越少。
有些需求在一开始时很难确定,在开发过程中要不断地加以改正。
软件修改越早代价越少,修改越晚代价越大,就跟治病一样道理。
观点之四
有了对目标的一般描述就足以开始写程序了,我们以后可以再补充细节。
客观事实
不完善的系统定义是软件项目失败的主要原因。
关于待开发软件的应用领域、功能、性能、接口、设计约束和标准等需要详细的描述,而这些只有通过用户和开发人员之间的通信交流才能确定。
越早开始写程序,就要花越长时间才能完成它。
一旦我们写出了程序并使其正常运行,我们的工作就结束了。
人们有时认为,只有差的软件产品才需要维护。
客观事实
从如图1.12所示的统计数据来看,软件投入的50%~70%是花费在交付给用户之后。
品质差的产品被丢弃,只有好的产品才需要维护和改进。
观点之六
一个成功的项目唯一应该提交的就是运行程序。
客观事实
软件包括程序、数据和文档,其中文档是成功开发的基础,为软件维护提供了指导。
早期的CMMI(CMMI-SE/SW/IPPD)1.02版本是应用于软件业项目的管理方法,SEI在部分国家和地区开始推广和试用。
随着应用的推广与模型本身的发展,演绎成为一种被广泛应用的综合性模型。
目录
简介
评估
1.预备工作
2.评估方法
3.cmm是项目管理
等级
1.1.初始级
2.2.可重复级
3.3.已定义级
4.4.量化管理级
5.5.优化管理级
评估方式
CMMI的基本思想
研发背景
源模型
原则
目标
方法
内容
与CMM差别
标准名词术语
实施
人员素质
实施流程
简介
评估
1.预备工作
2.评估方法
3.cmm是项目管理
等级
1.1.初始级
2.2.可重复级
3.3.已定义级
4.4.量化管理级
5.5.优化管理级
评估方式
CMMI的基本思想
研发背景
源模型
原则
·目标
·方法
·内容
·与CMM差别
·标准名词术语
·实施
·人员素质
·实施流程
展开
编辑本段简介
CMMI的全称为:
CapabilityMaturityModelIntegration,即能力成熟度模型集成。
CMMI家族包括CMMIforDevelopment,CMMIforService和CMMIforAcquisition三个套装产品。
自从1994年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。
虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。
这时他们就会发现存在一些问题,其中主要问题体现在:
n不能集中其不同过程改进的能力以取得更大成绩;
n要进行一些重复的培训、评估和改进活动,因而增加了许多成本;
n遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚至相抵触。
于是,希望整合不同CMM模型的需求产生了。
1997年,美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM),该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM和软件的SW-CMM三个模型中的所有原则、概念和实践。
该模型被认为是第一个集成化的模型。
编辑本段评估
预备工作
评估实践证明:
在进行CMMI评估之前,制定一个正确的评估计划并将其文档化,确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估,为执行评估过程做准备,是十分必要的。
我们所说的文档化CMMI评估计划的结果,包括:
要求,协定,估价,风险,剪裁方法,以及与评估相关的实际考虑(例如:
日程安排,后勤,组织的背景信息)。
此外,还应当获取并记录发起方对于CMMI评估计划的正式批准。
在制定评估计划之前,应对CMMI评估输入中反映出来的协议文档化,该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。
在对驱动计划过程的关键参数达成共同理解的基础上,CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致;发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。
这个计划在执行其他的计划和准备阶段活动中需要进一步细化。
而通过CMMI评估小组的准备工作,将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。
该小组的成员都应当获得了完成他们各自的任务所必备的知识,或者他们之前所拥有的知识被证实足以完成相关任务。
评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会,或者证实这些技能在过去已经得到了示范。
小组成员相互了解,同时开始计划他们如何协调一致的工作。
还应该做到:
准备好的小组是为评估目标而服务的,小组的成员已提供培训且培训结果被记录,在必要的时候,对他们所做的因知识或技能不足的补救工作已经完成。
我们认为,无论CMMI评估小组领导者是从头培训一支全新的评估小组,还是通过从富有经验的小组成员中选择来组建一个小组,确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。
此外,在对CMMI评估进行的预备工作的过程中,我们还应当对模型剪裁的原则有所了解:
1.在某些应用中,计划模板和例行的程序能够根据评估的需要进行调整,这和当地的过程所有权一样,有助于交流;
2.一个结构化的计划工艺组有利于只有有限的评估经验的组织,这样一个工艺就像缓和策略样,对于发现风险是一个很有价值的机会;
3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那些更需要培训的重点;
4.富有经验的评估小组领导者在没有案例分析的情况下,同样可以管理和模拟评估行为;
5.在小组所有已获得培训成员的集合中,对小组的建立工作进行管理以确保其团队凝聚力是十分重要的,因此,很多的小组建立练习是可以利用的,小组的规模、技能、组成部分都是本方法的裁剪内容;
6.所采用工具可以包括评估计划模板,样例,和计划模板中嵌入式的程序上的帮助,此外,为了估计评估约束的影响,估算工作表和方法也是很有用处的。
总之,CMMI评估是一个十分复杂的过程,更由于其具有的不确定性,在评估的实践中,一定要做到有备无患。
真理来自于实践,我们相信,随着越来越多的软件组织着手CMMI评估,越来越多的成功经验将为我们所利用和借鉴。
评估方法
自1991年起,CMM出现了很多模型,覆盖
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 基本 策略 精品 文档
![提示](https://static.bdocx.com/images/bang_tan.gif)