軟件工程管理問(wèn)題

時(shí)間:2022-04-22 08:36:00

導(dǎo)語(yǔ):軟件工程管理問(wèn)題一文來(lái)源于網(wǎng)友上傳,不代表本站觀點(diǎn),若需要原創(chuàng)文章可咨詢客服老師,歡迎參考。

軟件工程管理問(wèn)題

1時(shí)美國(guó)國(guó)防部曾立題專II研究軟件項(xiàng)日做不好的原因,發(fā)現(xiàn)70%的項(xiàng)日是因?yàn)楣芾聿簧埔鸬?,而并不是因?yàn)榧夹g(shù)實(shí)力不夠,進(jìn)而得出一個(gè)結(jié)論,即管理是影響軟件研發(fā)項(xiàng)目全局的因素,而技術(shù)只影響局部。這個(gè)結(jié)論仆常重要。到了90年代中期,軟件研發(fā)項(xiàng)目管理不善的問(wèn)題仍然存在。據(jù)美國(guó)軟件工程實(shí)施現(xiàn)狀的調(diào)查,軟件研發(fā)的情況仍然很難預(yù)測(cè),大約只有10%的項(xiàng)目能夠在預(yù)定的費(fèi)用和進(jìn)度下交付。針對(duì)軟件項(xiàng)目管理不善的局而,我簡(jiǎn)要談?wù)勈浖?xiàng)目管理中存在的一些問(wèn)題。1客戶干不份要全程參與不少軟件企業(yè)認(rèn)為客戶的參與主要在二件事情上:協(xié)議簽訂和需求調(diào)研、客戶需求變更和項(xiàng)目驗(yàn)收簽字,其它事情足企業(yè)內(nèi)部項(xiàng)日開發(fā)管理的事情,屬公司內(nèi)部行為,無(wú)需客戶參與。

結(jié)果,企業(yè)經(jīng)常發(fā)現(xiàn)客戶嚴(yán)重拖延驗(yàn)收,而Il在驗(yàn)收期間客戶大量的需求變史,致使項(xiàng)目的進(jìn)展嚴(yán)重推遲。經(jīng)常一個(gè)預(yù)期益利的項(xiàng)}」,最后拖的不堪重負(fù)口我認(rèn)為這里邊的一個(gè)重要原因就是客戶沒(méi)有參與項(xiàng)目的全過(guò)程。比方,項(xiàng)目初期的啟動(dòng)會(huì)議、項(xiàng)日過(guò)程中所有干系人的知情制度,每周的工作例會(huì)、項(xiàng)日階段性工作總結(jié)等等都需要客戶的參與和反饋。否則當(dāng)企業(yè)年之后提交一個(gè)無(wú)比龐人和復(fù)雜的最終方案時(shí),客戶方根本不了解你的方案的進(jìn)程,由誰(shuí)敢簽字驗(yàn)收昵?客戶只能花I幾兒個(gè)月來(lái)完全“肢解”消化整個(gè)方案,最終當(dāng)然是發(fā)現(xiàn)大堆問(wèn)題需要改進(jìn),企業(yè)只能再花上幾個(gè)月重新修改,如此往而復(fù)始,惡性循環(huán)。

2如果份求分析很困難,可不可以先做軟件對(duì)需求把握得越準(zhǔn)確,軟件的修修補(bǔ)補(bǔ)就越少。有些需求在一開始時(shí)很難確定,在開發(fā)過(guò)程中要不斷地加以改正。軟件修改越早代價(jià)越少,修改越晚代價(jià)越人,就跟治病一樣道理。一是在項(xiàng)日的需求分析階段,開發(fā)方與客戶方在各種的問(wèn)題的基本輪廓上達(dá)成一致即.IJ,具體細(xì)節(jié)可以在以后填充。軟件過(guò)程改善是一個(gè)持續(xù)改善的過(guò)程,需要不斷地學(xué)習(xí),需要知識(shí)的積累,特別是當(dāng)主客觀環(huán)境發(fā)生變化時(shí),需要對(duì)過(guò)程進(jìn)行修改,以適應(yīng)變化了的情況。無(wú)論多么細(xì)致的需求分析,兒乎都難以避免修改。實(shí)際上許多軟件項(xiàng)日失敗的最l要的原因就是需求階段對(duì)問(wèn)題的描述不夠細(xì)致,導(dǎo)致后來(lái)頂算超出或者時(shí)間進(jìn)度達(dá)不到要求。這就要求在項(xiàng)H需求分析階段,開發(fā)方與客戶方必須個(gè)面地盡可能細(xì)致地討論項(xiàng)目的應(yīng)用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求,以及對(duì)項(xiàng)目進(jìn)行評(píng)估的各種評(píng)價(jià)標(biāo)準(zhǔn)。并民,在需求分析結(jié)束以后,雙方還要建立可以直接聯(lián)系的渠道,以盡早地對(duì)需求變動(dòng)問(wèn)題進(jìn)行溝通。

3軟件項(xiàng)目份求的改變?nèi)菀讓?shí)現(xiàn)嗎在具體實(shí)際中由于種種原因客戶方很難在需求分析階段全面而準(zhǔn)確地描述所有問(wèn)題。隨著開發(fā)進(jìn)度的推進(jìn),往往會(huì)有一此需求的改變。而現(xiàn)代軟件工程理論也利用軟件的靈活性特點(diǎn)通過(guò)各種方式來(lái)適應(yīng)這種情況。不過(guò),這并不表明“軟件項(xiàng)目的需求可以持續(xù)不斷的改變,而且這此改變可很容易地被實(shí)現(xiàn)”。實(shí)踐表明,隨著開發(fā)進(jìn)度的推進(jìn),實(shí)現(xiàn)軟件需求更改所需要的代價(jià)呈指數(shù)形式增長(zhǎng)。假定在需求分析階段實(shí)現(xiàn)需求更改需要花費(fèi)1倍的代價(jià);那么,在系統(tǒng)設(shè)計(jì)和編碼階段,需要花費(fèi)1.5-6倍的代價(jià);在系統(tǒng)測(cè)試階段需要花費(fèi)10-20倍的代價(jià);在軟件版本以后,甚至可能要花費(fèi)60-100倍的代價(jià)。由此可見,在項(xiàng)日開展過(guò)程中,軟件需求的改變應(yīng)當(dāng)盡量早地提出。這樣才可能花費(fèi)少,容易被實(shí)現(xiàn)。

4項(xiàng)目的質(zhì)f提高是否要依救完普的質(zhì)fm試制度不少企業(yè)把軟件的測(cè)試工作定位于提高軟件開發(fā)項(xiàng)目的質(zhì)量。我認(rèn)為質(zhì)量測(cè)試制度只是」個(gè)補(bǔ)救措施,是來(lái)挑出各種因素造成的缺陷,但不能避免新的缺陷的出現(xiàn)。真正有效的質(zhì)量管理是建立在一套質(zhì)量保證體系l幾的全過(guò)程質(zhì)量管理方案,每一個(gè)環(huán)節(jié)的規(guī)范化管理是質(zhì)量保證的一個(gè)基礎(chǔ),除此之外,規(guī)范的項(xiàng)目方案評(píng)審制度也是質(zhì)量保證的必備步驟,經(jīng)??蛻魧?duì)質(zhì)量的評(píng)價(jià)首先是方案質(zhì)量的優(yōu)劣。有效的、科學(xué)的測(cè)試制度也將有助于在提交客戶之前發(fā)現(xiàn)設(shè)計(jì)中的問(wèn)題。

5所有的內(nèi)部洲試工作是不是全部應(yīng)該由洲試人員完成軟件程序測(cè)試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“自盒法”對(duì)測(cè)試人員各方面素質(zhì)的種種要求,在進(jìn)行程序測(cè)試時(shí)測(cè)試人員總是最優(yōu)先使用“黑盒法”。他們的上作方式往往是先對(duì)程序進(jìn)行“黑盒法”測(cè)試;如果測(cè)試沒(méi)有通過(guò),不得已這才考慮對(duì)程序代碼進(jìn)行“自盒法”測(cè)試。顯然,這種對(duì)“白盒法”有意無(wú)意的“逃避”,對(duì)軟件的可靠性和穩(wěn)定性構(gòu)成了威脅。如何解決這個(gè)問(wèn)題?一方面需要提高對(duì)測(cè)試人員的要求,另一方向也需要程序員完成部分的“白盒法”測(cè)試。

6如果我們落后于計(jì)劃,是否可以增加更多的程序員來(lái)解決客觀情況是軟件開發(fā)不同J二傳統(tǒng)的農(nóng)業(yè)生產(chǎn),人多不見得力量大。如果給落后于計(jì)劃的項(xiàng)日增添新手,可能會(huì)更加延誤項(xiàng)日。因?yàn)?

1)新手會(huì)產(chǎn)生很多新的錯(cuò)誤,使項(xiàng)目混亂。

2)老手向新手解釋上作以及交流思想都要花費(fèi)時(shí)間,使實(shí)際開發(fā)時(shí)間更少。所以科學(xué)的項(xiàng)I-I計(jì)劃很重要,不在乎計(jì)劃能提前多少,重在恰如其分。如果用“”的方式奔向共產(chǎn)卞義,只會(huì)產(chǎn)生倒退的后果。投入項(xiàng)目上的人力,多多益善。在某些業(yè)務(wù)項(xiàng)日卜確實(shí)如此。但在系統(tǒng)項(xiàng)目管理中卻很少是這樣的。人們的技能和知識(shí)是不能互換的。如果多一些人加入到系統(tǒng)項(xiàng)目中來(lái),由于協(xié)調(diào)不利和要培訓(xùn)人員以快速適應(yīng)丁:作,通常會(huì)減慢項(xiàng)日的進(jìn)度。

7技術(shù)骨千是否應(yīng)該成為項(xiàng)目的項(xiàng)目經(jīng)理項(xiàng)目經(jīng)理一定是所有項(xiàng)目成員中薪水最高的。在“軟件作坊”時(shí)代,這是一種普遍使用而目.效果不錯(cuò)的方法;而在“軟件”時(shí)代,這種方法卻帶來(lái)各種問(wèn)題,有時(shí)甚至直接導(dǎo)致項(xiàng)日失敗。究其原因這主要是因?yàn)殡S著現(xiàn)代軟件開發(fā)分工的細(xì)化,對(duì)項(xiàng)目經(jīng)理的要求也發(fā)生了根本的改變—最注重的不是其對(duì)某項(xiàng)專業(yè)技術(shù)的掌握程度,而是其組織、領(lǐng)導(dǎo)、協(xié)調(diào)開發(fā)團(tuán)隊(duì)的能力。至于項(xiàng)目經(jīng)理的薪水問(wèn)題,這和定薪制度有很大關(guān)系。通常,項(xiàng)目經(jīng)理執(zhí)行的是管理人員的薪酬體系,而其他人員執(zhí)行的是技術(shù)人員的薪酬體系。項(xiàng)目經(jīng)理的薪水在項(xiàng)目成員中是比較高的,但不-定是最高的。有時(shí)候,為了激勵(lì)技術(shù)人員,項(xiàng)目中的技術(shù)骨干得到的酬勞比項(xiàng)目經(jīng)理要高。