软件工程论文Word格式.doc
- 文档编号:3612696
- 上传时间:2023-05-02
- 格式:DOC
- 页数:5
- 大小:26.50KB
软件工程论文Word格式.doc
《软件工程论文Word格式.doc》由会员分享,可在线阅读,更多相关《软件工程论文Word格式.doc(5页珍藏版)》请在冰点文库上搜索。
就目前来看,我国的软件产业正处于关键的转型阶段,而鉴于软件产业在中国发展的不少得天独厚的优势,相信我国的软件产业必然能够把握住前所未有的机遇,在不久的将来傲然崛起!
软件开发是一门科学,更是一艺术。
微软公司在二十几年的发展过程中形成了其独特的软件开发与设计的企业文化。
而相比之下,目前我国软件业的发展却是喜忧参半,我国虽拥有高素质,基础扎实,学习能力强且思维敏锐的软件专业人员,但大规模的软件生产在我国尚处于初期发展阶段,软件的研究与开发过程中尚有许多亟待解决的问题。
在这样的大环境下如何借鉴国外的先进管理技术经验就变得十分重要了,以微软为例,我觉得主要可以概括为以下几点:
1.独具魅力的企业文化与软件开发人员的培养。
2.从差别中寻找解决方案。
3.扎实的基础和创新,独立的工作能力。
4.主人翁精神和团队精神5.锲而不舍,从错误中学习的精神。
曾经,软件工程这四个字对于我来说是十分陌生的,但在接触后,我发现其中还是有许多有趣,深奥却又与生活共通之处的(如在风险管理的阶段,下文中会就风险管理进行详细的说明)。
软件工程看似浩大,但其实亦是由许多细小的部分堆砌而成的。
或许有人会说,软件工程没有什么用,但我觉得完全不是这样的,而且说出这种话的人一定也不了解(至少不会真正明白)软件工程的意义与优势。
根据长久以来的趋势,我们可以看到,在不久的将来,和软件的价格相比,硬件价格将是微不足道的,也就是说在购买了软件产品时,其运行所需的硬件产品则会免费提供,在这种时候,软件工程技术有助于降低成本,这种以高效率方式开发出高质量的软件亦是解决上述软件危机的一个最佳可行方案。
软件工程又是一个十分复杂的问题,因为影响因素不胜枚举。
一般来说一个工程项目的课题大小,接手工程的工程师的能力高低等等都会对它产生很大的影响。
直到现在仍然有很多人会认为软件工程就是编程而已,其实这也是一种错误的认识。
在软件工程中编程只是一个很小的部分,它所占用的时间,资源也远远不及需求分析,概念设计,测试等阶段的工作。
总的来说软件工程是一门讲述如何将应用系统的,训练有素的,可计量的方法来设计,操作,维护软件;
也就是一门将工程化方法应用到软件开发过程中的学问。
随着人们对于经济效益,工作效率的不断追求,软件工程也越来越受到人们的关注,也由此形成了许多软件工程专有名词,技术。
对于一个软件的生成过程也有了更为严格的要求。
就历史来看,在软件设计的技术发展过程中,一共经历了探索式,面向控制流式,面向数据结构式,面向数据流式,面向对象式五个阶段。
而每一个阶段都逐渐加速了软件工程作为一门学科的发展。
在软件工程中项目管理可以说是一项最为重要的内容了,它作为一种广泛应用于各种工程,金融甚至农业生产中的技术管理过程,在IT行业中常常决定产品或企业能否成功。
软件项目管理的主要目的是确保软件工程师能够高效地顺利完成该项目,软件项目经理是全面负责指导一个项目以使其成功的人,他的存在能使开发人员集中精力做开发,而不被管理琐事所困扰;
能让项目组内部不同角色人员间做好沟通协调;
能扩展开发队伍的视野;
能连接和平衡工程开发和商业运作之间的差别;
能作为开发队伍与外界联系沟通的管理和协调员。
软件项目管理包含许多具体的步骤:
设定优先级,分析能力差距,定义质量,鼓励所取得的进步,从历史中学习,设定改进目标,规划项目,评估工作,跟踪进度,构建使用模型,了解竞争对手的动态,从工具使用中找出最高效的方法等等。
对于如何才能进行成功的软件管理,有经验的软件管理员们往往都有自己的一套见解,但归根结底总会包含如下几点:
1.对项目管理的重要性有清醒深刻的认识。
2.有一定的开发经验(即使只是作为一个旁听者这样的接触也是必要的。
3.了解你的对手并且永远不要认为对手比你弱(知己知彼,百战百胜)。
4.为每一个项目制定最合适的规划准则。
5.从失败中吸取教训。
6.尝试把握全局。
没有一个成功的,有经验的管理者是从来没有犯过错或失败的,相反,一个真正有能力的管理者是能够从一次次的失败中总结经验教训并将其运用与今后的管理之中,失败就如同是一块块基石,将未来的成功变得更加牢固。
在项目管理中,风险管理又可以称得上是其中最为重要的部分了(因为管理的最终目的就是要减少或者说避免不可预知的和可预知的一系列可能影响软件成败的因素),风险简单说来就是
(1)未来可能发生的某一事件,该事件将导致不好的结果。
(2)不好的结果本身。
风险管理亦可以定义为风险发现,暴露分析,应急计划,风险缓解和持续的转化监控的总和。
在开发所有的软件之前,进行开发前景的预测都是不可忽视的工作,例如某个公司要开发一个新的卡拉ok点歌系统,那么他首先要考虑的就是这个软件有没有开发的价值,即它可以在现有的点歌系统中脱颖而出吗?
它有哪些优势?
开发的成本与收益如何?
能否在规定的时间内完成?
完成不了又会怎样?
可以说,对风险的预测是决定此软件是否值得开发的决定性因素。
优秀的软件管理员一般都会在进行软件开发前思考这样的问题:
这个软件是否值得开发?
如果开发,在此过程中会遇到什么样的困难?
企业是否有能力克服这样的困难?
软件的投资与回报是否成比例?
是否值得花时间等等。
正因为这样软件开发经验才会显得如此重要。
风险管理是贯穿整个软件开发过程的一条纽带,它既包含前期的风险预测,中期的分析评估和后期的验收运行交付。
因此决不是有些人想像的那样只要在前期罗列出可能的风险并记录下来就万事大吉了的,风险报告需要在进行项目开发的每一步之前都仔细斟酌,必要时添加新的可能的风险进入风险管理列表中,在进行需求分析,编码,测试等具体操作时也不能忘记时刻跟踪。
这样,风险管理才能发挥它应有的作用。
如果我们把软件开发中的风险因素比作一只难以克制的野兽(好比是一只狮子,熊一类的猛兽),风险管理就如同是教导我们如何在不被野兽伤害甚至吃掉的情况下获得最大收益的方法。
对于任何企业来说,忽视或不进行风险管理都是极为危险的,即使偶尔一次因为得到了幸运女神的眷顾而项目成功,这样的好运也不会持续很久,而且当幸运女神不再帮助你的时候,软件成功也失去了可能性。
“既然风险管理如此重要,那我们就做吧。
”就我看来,这是一种最要不得的态度,因为当你没有进行风险管理的时候,失败可以轻而易举地被预见,所以你可能很早就放弃了(或许你自己发觉,或许受到别人的提醒),故你虽然得不到利益,却也不会因此而损失惨重。
但是如果你进行了风险管理(可事实上你并没有认真对待它),并认为该项目一直都是可行的,那你可能直到最后才发现软件的失败,可此时你已经为此付出了众多的辛劳和努力,公司也可能已经投入了大量的人力,物力和财力,这时一个软件的失败所造成的影响就是难以预计的了。
当一个企业或一个软件工作团队首先明确了风险管理的重要性后,他们首先要做的就是如何着手管理风险。
优秀的管理者们往往都拥有对风险敏锐的嗅觉,这并不是说他们能解决所有可能的风险,而是说他们能发现一般人无法发现的潜在风险。
同样,对不同的风险进行危险评估也是前期风险管理最重要的部分之一。
当然,或许有人会问,我怎么知道什么才是我的软件项目中的风险,即使知道了,对于那些看不见,摸不着的东西又要如何进行优先级的取舍呢?
我觉得,这要视具体情况而定。
以一个聊天程序为例,如果客户有明确的提交期限,那么这一条件就应该被列入风险列表中,时刻提醒工作团队不在规定时间内完成任务的结果就是软件的失败。
因此,在决定是否签约时,首先应该考虑公司的人员,技术,资源是否可能在规定的时间内完成软件的提交,即按时提交的可能性有多高。
不过,诸如某个团队成员在此期间生病,他的进度无法跟上就可以作为次要的风险考量,因为你完全可以在第一时间用替补人选替换他。
还有类似陨石撞击地球,地震导致工程无法继续则可以完全不在考量范围之内,那是即使预知也难以靠你(或你身边所有人)的力量挽救的风险事件。
由于风险的种种不确定性,风险管理也常常让人们因为害怕而诟病。
的确,风险管理的存在破坏了破坏了某些既有的管理方式(虽然那些方式可能并不能为软件开发带来实际的利益,但由于历史原因,想要追随的人还是不缺乏的。
正是在这样一个背景下才产生了“可以犯错,但不能不确定”的病态的企业文化,在翻阅了一些关于软件风险管理的书籍后,我深感这种文化对风险管理的致命。
可以说,正是这样一种想法,让一个公司或一个软件项目的风险管理形同虚设,或者更确切的说,会导致风险管理的负利益化。
设想一个很希望做好风险管理的人进入了这样的公司,或是在这样的公司里进行着风险管理工作,这真是一场恶梦。
积极性被完全打压,并且即使你明确地意识到了成功的未知,在截止日期前你仍然需不断的保证完成任务,因为你知道,如果说推迟提交日期是可以被原谅的话,那么一句“不确定”或“不知道”就一定会要了你的命。
在这样的情况下,人们的选择当然就是显而易见的了。
所以假如你想继续留在那里的话最好的方法就是放弃风险管理,要是做不到,那离开就只能是唯一的选择了(永远不要试图凭一己之力尝试改变一个企业的文化)。
在日常生活中人们往往会有意,无意地进行“赌博”(当然是抽象意义上的,这里对“赌博”的理解好比一个船主在出海前检查船时发现船可能发生沉掉的危险,但面对取消出航带来的损失,他最终选择了前者;
又如同赛车手在已经意识到油箱里的汽油快要用尽,维修站的工作人员也已招手示意进站加油,但想到近在眼前的终点,以及进站加油就意味着将第一拱手相送,于是,赛车手决定相信赛车能挺到终点。
这样的“赌博”与风险管理的初衷是截然相反的。
船主的最后一次航行可能会中途遭遇风暴导致全员丧生,这时来自四面八方的评论也许都是指责他作出了错误的风险预测;
那如果他带着乘客们顺利返航又如何呢?
是不是因此他就能免去指责呢?
答案当然是否定的,因为他没有资格作出航行一定会顺利的预测(以正船人的性命作赌注)。
同样,那个赛车手也是一样,虽然他可能取得第一,但在风险管理中“控制失败的后果”往往比“取得更大的成功”要来得重要。
一个软件开发的结果只有成功与失败,没有转圜的余地,而输了一场比赛总有第二场,第三场比赛在等着你。
风险管理决不是一场赌博,而是未雨绸缪,就像卡车司机们的格言一样“每一个皮球后面都有一个孩子。
”事实当然并不是所有皮球后都会有一个追逐着它的孩子,但必须清醒地认识到不采取任何措施所导致的后果将是严重的,不可挽回的。
因此,当司机们看到皮球的同时自然而然就会踩下刹车,这就是一种风险机制,即:
为了可能出现的坏情况先采取措施。
当然,这样的措施最后未必被证明是必要的,皮球的后面可能没有任何人,那仅仅是一个滚到马路上来的皮球,但正是由于没有人能在事件发生前肯定一切,风险管理才会显得如此重要。
也正是因为这样,未知才会显得如同猛兽一般可怕,令人畏惧。
如何进行有效的,高效的风险管理是一门深奥的学问,我没有具体接触过大型软件开发,但就理论来说我觉得主要还是要结合项目的实际情况,可以考虑进行如下步骤
(1)通过风险发现过程调查出项目面临的风险。
(2)确认软件项目所有的核心风险都已进入列表中。
(3)针对每项风险列出其具现的可能性,估计可能的损失,记录模板。
(4)在软件开发过程中时刻跟踪风险管理列表,进行及时反馈。
有时估算器的使用也会给风险管理带来便捷。
可以将软件成功交付的可能性结合风险以各种图形的方式表现出来,不同的图有不同的优点和缺点,好像增量图可以清晰地展现成功率随时间的变化,累积图可以很方便地让我们看到在特定成功率下所需要的最可能的时间。
在这次的软件工程大作业的完成过程中,很幸运的我负责的其中一部分就是风险管理的模块。
虽然我们小组仅仅是制作了一款聊天工具,因此所遇到的风险不可能像那些大型的软件工程项目那样庞大,充满挑战,但这毕竟是我第一次尝试对风险管理的实际把握。
在实际的操作过程中,我们小组通过讨论分别罗列出了拥有不同优先级的诸如时间不足,技术水平不足,管理水平不足,软件构架可能不合理,代码可读性可能不高,测试可能覆盖不完整,文档管理混乱等风险可能,并就这些风险一一阐明了列写原因(包括评判优先级)和监控方法(诸如:
1.在选择项目时就进行了慎重考虑,选择合适的(在规定时间内完成可能性较高的)项目。
软件项目正式开始后,每个人每周都会通过例会上报组长进度情况,在进度未达到预期时由整个小组共同协商解决(进度落后的组员需要花费更多时间在项目上或者进度超前的组员帮助完成更多内容),在每一阶段都保证不会有任何拖队,掉队的情况发生。
2.首先由组长整理所有可能需要的知识储备再由小组成员按照个人喜好进行自主和互动相协调的学习方式。
对于在软件开发过程中遇到的困难及时上报组长进行小组讨论(期间可以发挥主观能动性求助于软院学长,编程高手,网上资料等),争取在第一时间解决问题。
3.首先项目管理员(即队长)进行系统的项目管理理论知识的培训,在每周一次的小组会议上将心得体会结合小组目前进度快慢进行评估,组员间讨论找出存在的,正在影响管理的因素,及时防止由于管理的缺乏导致软件项目秩序混乱,停滞不前。
4.在每一次的版本出现后,由测试人员第一时间进行测试,按照项目设计,需求分析的要求指出软件仍然存在的问题并通知程序员进行修改。
5.在软件开发的每一步都必须有文档的记录,组长时刻保持与各组员的联系,掌握当天进度并时刻提醒文档跟进工作。
在每周一次的小组会议后进行文档与现有资料的整理分类工作,一旦发现文档产生混乱当即停止所有事件进行会议研究,再解决问题后重新开始软件开发工作。
)。
在这次软件实践过程中,由于我们的风险意识的强化以及风险的实现预测,使得即使在软件开发过程中遇到问题我们小组也能从容应对(的确,在实践过程中如对于建模工具使用 上的不熟悉让我们小组的进度有过停滞,但因为在风险管理列表中已经明确指出过,我们自然而然就按照那样去做,通过加倍的努力,战胜了这一难关)。
在进行测试工作的时候(我还负责进行测试),我会随时保持和程序员的联系,在测试中一旦发生问题就立刻通知她,并在我的测试报告中用不同颜色的字表明需要进行修改的部分,并且在每周一次的例会上提交当前的成果。
测试过程的确需要测试员对于整体软件的充分把握(在完成了一次又一次的项目测试文档后我更深刻体会到了这一点),一开始对于界面中各个键的使用测试需要完全的仔细耐心,其后对于运行过程中可能出现的各种突发状况则更是如此。
在进行健壮性测试前,我首先将自己所能想到的状况进行汇总,又询问了小组成员是否有所补充,最后又请教了一些常年与聊天程序打交道的同学,向他们了解可能产生的问题(这些建议的确非常有用,弥补了许多一开始我没有考虑到的情况所导致的不足)。
在最后的测试列表中,我惊讶地发现小小的一个聊天程序竟然也可以有一百多个测试点并且测试也不是一蹴而就的,既有功能方面的,也有差错管理方面的。
在进行各健壮性测试时,我将自己设想成了一个专搞破坏的分子,将列表中所有可能的突发情况进行尝试,果然出现了部分问题。
这些问题又在一次一次的修改——测试的循环中得到了解决。
虽然即使已经做过了多次测试,但我仍不能保证该聊天程序能够承受所有突发情况。
不过有一点我可以确定的就是,测试大大加强了软件的总体质量同时也减小了它的风险。
可以说,正是由于测试让我越发看到软件风险管理的重要性。
当然,在我们的项目执行过程中,风险管理并不仅仅存在于初期和末期,可以说每一个阶段都有它的身影。
这一事实也证明了前面强调的“风险管理是整个软件开发过程的一条纽带”以及“任何成功的软件开发都离不开好的风险管理”这两条真理。
其实,
这样一种对风险时刻警惕的态度,以及预防胜于亡羊补牢的心态即使应用于我们大家的日常生活中也是有百利而无一害的(就好像我们在买房子的时候会考虑房价是否在我们能够承受的范围之内,房子的地段是否有增值空间,房子的建筑方能否提供房子牢固的保障,其它还有诸如交通是否便利,周围有没有配套的居住设施,这些种种因素都一定会在你决定是否买下这套房子前被经过仔细的考虑。
而其实这些事先的考察就是为了预防风险发生,或者说使风险发生的可能性降到最低(房子的风险可以概括为安全因素和升值潜力两方面))。
如果你不懂得如何处理风险,不仅是在软件工程中难以立足,在现实生活中也必然会遭受重创。
总体来说,风险管理要求我们不仅具有单方面的技巧和知识,更需要我们用一种缜密的而非随性的,勇敢的而非恐惧的,诚实的而非虚假的态度来面对它。
因为它是一只野兽,一只外表凶狠,破坏力极强的野兽;
同时它的身后又藏着太多的金银财宝,令我们无法视而不见。
所以我们必须以一种谦虚谨慎的态度与它交往,任何油嘴滑舌的言语或是漫不经心的表现都可能会让它找到伤害我们的机会(这或许只是因为它是一只野兽,它的本性就是杀戮,也可能是它早已把我们当成了盘中的美餐,只是在利用那些我们想获得的东西来引诱我们而已)。
所以,最好的方法就是小心翼翼(如果有人因为可能发生的灾难而拒绝利益,那也没什么可说的了,只是人们往往都不会愿意这么做),做好防护工作,你可以穿上铁甲般足以抵抗攻击的衣服,也可以在这之前学习这只野兽所有的习性及应对方法。
当我们仔细的检查过所有可能的情况并逐一进行分析后,到那时我们将信心十足地接受任务,而且,即使我们仍不幸被其所伤,我们仍可以微笑着面对伤口——那抓痕正是光荣的见证,我们可以在这样的失败中汲取到宝贵的经验财富(而这从某种程度上说或许比利益本身更为重要)。
风险管理是一门学无止尽的哲学,但又是我们(尤其是软件开发人员)不得不正面的事情(如同我们每一个人在日常的生活中也随时面临着风险与抉择)。
因为任何人都希望能够在交易的过程中获得最大的收益,任何人又都希望能够通过最小的付出取得最大的收益。
但收益总是与风险并存,如果你不能很好的处理风险就不能得到相应的收益,相反可能只有付出而没有回报。
在软件工程管理的领域里我还只是略知皮毛,但是,当我越深入了解,我就觉得越发被它所吸引,尤其是对于风险管理这一块。
或许是因为对于未知的领域人类都有一种好奇心,对于难以把握的事件人们都有一种想要征服的欲望,我始终相信这样一个事实也为风险管理的不断深化改进提供了有效的支撑。
相信随着信息技术的发展,软件工程得到越来越多的重视,各种管理技术的完善,这一场与熊虎谋皮的战斗(当然也可以认为是一场美女与野兽间惊心动魄的华尔兹)会涌现出更多或美丽或残酷的场面,软件管理——一把风险与利益共存的双刃剑!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 论文
![提示](https://static.bingdoc.com/images/bang_tan.gif)