軟件研發(fā)管理問題和解決方案ppt課件_第1頁(yè)
軟件研發(fā)管理問題和解決方案ppt課件_第2頁(yè)
軟件研發(fā)管理問題和解決方案ppt課件_第3頁(yè)
軟件研發(fā)管理問題和解決方案ppt課件_第4頁(yè)
軟件研發(fā)管理問題和解決方案ppt課件_第5頁(yè)
已閱讀5頁(yè),還剩33頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、軟件研發(fā)管理問題和處理方案常見問題分析根底方法論引見整體處理方案林 銳 博士目錄1. 企業(yè)研發(fā)管理的理念2. 常見問題分析3. 中型企業(yè)的研發(fā)管理需求4. 根底方法論引見CMM5. 根底方法論引見 PMBOK6. 根底方法論引見矯捷開發(fā)7. 根底方法論引見 RUP8. 面向企業(yè)的軟件研發(fā)管理處理方案9. 基于Web的集成化工程管理系統(tǒng) Future3.01. 企業(yè)研發(fā)管理的理念1.1 目的企業(yè)的根本目的是“合法地賺取盡能夠多的利潤(rùn),使企業(yè)利益最大化。企業(yè)一切的特定目的和行動(dòng)都是圍繞根本目的開展的。根本目的進(jìn)一步?jīng)Q議了企業(yè)研發(fā)管理的目的和戰(zhàn)略。企業(yè)研發(fā)管理的根本目的是:讓一切人員有條不紊地開展任

2、務(wù),在預(yù)定的時(shí)間和本錢之內(nèi),開發(fā)完成質(zhì)量合格的產(chǎn)品,從而使企業(yè)和個(gè)人獲得預(yù)定的利益。企業(yè)研發(fā)管理的斗爭(zhēng)目的是:調(diào)動(dòng)一切積極要素,努力提高產(chǎn)質(zhì)量量、提高任務(wù)效率并且降低本錢,使企業(yè)和個(gè)人獲得比預(yù)定目的更多的利益。1.2 質(zhì)量、進(jìn)度時(shí)間、本錢“質(zhì)量、進(jìn)度時(shí)間、本錢通常是衡量企業(yè)研發(fā)管理“優(yōu)劣的三個(gè)關(guān)鍵目的。不同的企業(yè),甚至同一企業(yè)在不同時(shí)期,對(duì)三者的重要性看法是不一樣的。 假設(shè)出現(xiàn)“三者難以同時(shí)兼得的情況,那么產(chǎn)品的決策者一定要搞清楚質(zhì)量、進(jìn)度時(shí)間、本錢之間的復(fù)雜關(guān)系,判別孰重孰輕,給出優(yōu)化和折衷的措施。 1.3 規(guī)范化 vs. 超越規(guī)范化在企業(yè)里,大部分的任務(wù)是成熟的,有勝利的方式可以套用,該當(dāng)

3、走規(guī)范化的道路;而另外小部分的任務(wù)能夠是獨(dú)特的,并不適宜套用規(guī)范也能夠沒有規(guī)范可以套用,那么該當(dāng)采用超越規(guī)范化的管理方式。通常前者約占80%,而后者約占20% 2.1 常見問題分析:立項(xiàng)管理2.1.1 自主研發(fā)產(chǎn)品的立項(xiàng)問題擁有決策權(quán)的指點(diǎn)人單獨(dú)決議,或者召集有關(guān)人員開會(huì)商議能否開發(fā)某個(gè)產(chǎn)品。決策過程中的客觀臆斷比較多,風(fēng)險(xiǎn)很高。假設(shè)斷策錯(cuò)誤,即使人們努力開發(fā)出功能很好的產(chǎn)品,卻能夠在商業(yè)上失敗。由于沒有進(jìn)展充分必要的調(diào)研、可行性分析、立項(xiàng)建議、立項(xiàng)評(píng)審等任務(wù),企業(yè)指點(diǎn)在組建開發(fā)團(tuán)隊(duì)時(shí)難以給出恰當(dāng)?shù)馁Y源和進(jìn)度方案。團(tuán)隊(duì)只知道干活,卻不了解產(chǎn)品的開發(fā)背景,不清楚用戶期望的產(chǎn)品應(yīng)該是什么樣的。在開

4、發(fā)過程中經(jīng)常迷失方向,導(dǎo)致進(jìn)度延誤、費(fèi)用超支等問題。 2.1.2 合同工程的立項(xiàng)問題 委托方客戶方和承包方開發(fā)方在簽署合同的時(shí)候,雙方對(duì)軟件需求的了解并不深化,合同中對(duì)“開發(fā)什么的描畫比較空洞。合同簽署之后,客戶經(jīng)常變卦需求,開發(fā)方被迫不斷修正軟件,弄得疲憊不堪。夸張地概括:除了合同金額不變,其它一切都能夠改動(dòng)。剛簽署合同時(shí)開發(fā)方似乎賺錢了,后頭卻能夠得不償失。雙方在簽署合同的過程中給出了一些空頭承諾例如對(duì)進(jìn)度、質(zhì)量、費(fèi)用的估計(jì)過于樂觀,在實(shí)踐執(zhí)行時(shí)卻難以兌現(xiàn)這些承諾。處置不好將引發(fā)合同糾紛,輕那么雙方提早終止合同,重那么雙方反目成仇。 2.1.3 建議創(chuàng)建一種群體決策的立項(xiàng)管理規(guī)范,不僅讓群

5、眾奉獻(xiàn)智慧,而且讓群眾分擔(dān)責(zé)任,使勝利的閱歷被企業(yè)不斷復(fù)用,并升華成為企業(yè)的制度。 2.2 常見問題分析: 結(jié)項(xiàng)管理2.2.1 共性問題某些工程由于進(jìn)度拖延,不能按方案結(jié)項(xiàng);某些工程即使開發(fā)完成了,由于利益關(guān)系也不愿結(jié)項(xiàng)。這些“不良工程或者曾經(jīng)完成的工程不斷占用企業(yè)資源如人力資源和設(shè)備,無疑違背企業(yè)利益最大化的目的。在結(jié)項(xiàng)時(shí),人們往往對(duì)財(cái)務(wù)和設(shè)備進(jìn)展了詳細(xì)的清算,卻忽視了對(duì)知識(shí)財(cái)富、閱歷教訓(xùn)的總結(jié)。殊不知設(shè)備越用越差,但是知識(shí)財(cái)富越用越好,可謂主次顛倒。沒有對(duì)工程的價(jià)值進(jìn)展評(píng)價(jià),開發(fā)人員干完活后,不知道本人的任務(wù)成果產(chǎn)生多大的效益,缺乏成就感。結(jié)項(xiàng)后,不能對(duì)員工的業(yè)績(jī)進(jìn)展公正考核,自然不能很好

6、地鼓勵(lì)員工。合同軟件工程在結(jié)項(xiàng)之前,還面臨“客戶驗(yàn)收的一些問題。例如缺乏雙方認(rèn)同的“驗(yàn)收規(guī)范,導(dǎo)致驗(yàn)收過程混亂,過多地耗費(fèi)雙方的精神。 2.2.2 建議首要措施是建立企業(yè)的“結(jié)項(xiàng)管理規(guī)范和“驗(yàn)收與發(fā)布規(guī)范。自主研發(fā)的軟件產(chǎn)品在結(jié)項(xiàng)之前,公司內(nèi)部要進(jìn)展類似的“驗(yàn)收,防止不良工程蒙混過關(guān)。 2.3 常見問題分析:工程規(guī)劃2.3.1 共性問題在工程剛開場(chǎng)階段,人們對(duì)產(chǎn)品需求和技術(shù)的了解還比較淺薄,工程不確定要素比較多,此時(shí)很難對(duì)任務(wù)量和進(jìn)度作出比較準(zhǔn)確的估算。軟件工程教科書和CMM引薦的COCOMO模型、代碼行估算方法等等,對(duì)大多數(shù)國(guó)內(nèi)工程無法適用,效果好像“電腦算命。由此制定的工程方案能夠不真實(shí)踐

7、,后面經(jīng)常發(fā)生工程方案的變卦所以業(yè)界流傳“方案快不如變化快,將導(dǎo)致工程管理的復(fù)雜性和風(fēng)險(xiǎn)提高。工程的人員曾經(jīng)被上級(jí)指點(diǎn)限定死了,再多的活也是那幾個(gè)人干;工程的終了日期早就被指點(diǎn)和客戶指定了,不論合理不合理,反正時(shí)間一到就要交付軟件;除了辦公計(jì)算機(jī)和工資外,這個(gè)工程沒有其它經(jīng)費(fèi),工程經(jīng)理只需干活的權(quán)益沒有用錢的權(quán)益。假設(shè)人員、資金、時(shí)間都曾經(jīng)被毫無道理地指定了,那么工程規(guī)劃就失去意義,這樣的工程在國(guó)內(nèi)非常普遍。 2.3.2 建議建立企業(yè)的“工程規(guī)劃規(guī)范,給出適宜的工程估算方法和工程方案模板。運(yùn)用方便的軟件工具,協(xié)助工程經(jīng)理進(jìn)展工程規(guī)劃。 2.4 常見問題分析:工程監(jiān)控2.4.1 共性問題許多工程

8、經(jīng)理肩負(fù)重要的軟件開發(fā)任務(wù),他們往往把留意力集中在開發(fā)上面,很少仔細(xì)思索如何進(jìn)展工程監(jiān)控 。沒有突出工程監(jiān)控的重點(diǎn),工程經(jīng)理要么什么都不監(jiān)控導(dǎo)致工程失控,要么監(jiān)控得太多而墮入瑣碎事務(wù)中。 工程經(jīng)理寫周期性工程進(jìn)展報(bào)告時(shí),記流水帳,或者復(fù)制上次的報(bào)告,應(yīng)付了事。懶得動(dòng)腦筋分析工程遇到的一些問題,例如某些義務(wù)的進(jìn)度延誤了,不分析為什么延誤了,就順延。導(dǎo)致問題越積越多。工程實(shí)踐執(zhí)行情況與原定的工程方案嚴(yán)重脫節(jié),指點(diǎn)、客戶、市場(chǎng)人員、開發(fā)團(tuán)隊(duì)不了解工程真正的情況,使工程方案行同虛設(shè)。 2.4.2 建議建立企業(yè)的“工程監(jiān)控規(guī)范,運(yùn)用方便的軟件工具,協(xié)助工程經(jīng)理進(jìn)展工程監(jiān)控。上級(jí)指點(diǎn)和相關(guān)人員每周都要檢查

9、工程的監(jiān)控要素,及時(shí)發(fā)現(xiàn)問題,及時(shí)處理問題,既要關(guān)懷結(jié)果也要關(guān)懷過程。 2.5 常見問題分析:配置管理和變卦管理2.5.1 共性問題有些軟件機(jī)構(gòu)竟然不運(yùn)用軟件配置管理工具,用最原始的方式手工管理代碼和文檔,經(jīng)常出現(xiàn)“成果喪失、版本混亂等問題。不少機(jī)構(gòu)按照的CMM的要求制定了配置管理規(guī)范。該規(guī)范在實(shí)際上比較完善,面面俱到,但是實(shí)踐操作比較費(fèi)事,沒有突出重點(diǎn)。久而久之,人們膩煩后就逐漸放棄了規(guī)范,按本人的習(xí)慣操作,留下了隱患。例如不少程序被 checkout 后長(zhǎng)久沒有 checkin;有些程序保管在開發(fā)者本機(jī),根本就沒有放入配置庫(kù)。維護(hù)期間修正了程序,但是沒有放入配置庫(kù)。沒有變卦控制流程,經(jīng)常隨

10、意變卦需求、設(shè)計(jì)、代碼等,嚴(yán)重影響工程的正常開發(fā)進(jìn)程。 2.5.2 建議建立簡(jiǎn)單有效的“配置管理規(guī)范和“變卦管理規(guī)范。并運(yùn)用方便的工具,協(xié)助團(tuán)隊(duì)進(jìn)展軟件配置管理和變卦管理。 2.6 常見問題分析:質(zhì)量管理2.6.1 共性問題雖然人們大都認(rèn)可軟件的質(zhì)量很重要,但是許多軟件人員并不懂得如何有效地改善軟件質(zhì)量屬性如正確性、強(qiáng)壯性、可靠性、性能、易用性、平安性、可擴(kuò)展性、可復(fù)用性、兼容性、可移植性等等。不會(huì)分析當(dāng)前軟件的質(zhì)量要素是什么,沒有把精神集中在改善對(duì)經(jīng)濟(jì)效益奉獻(xiàn)最大的質(zhì)量要素上面。 有些軟件機(jī)構(gòu)沒有軟件質(zhì)量管理的措施,開發(fā)人員把完勝利能當(dāng)成終極目的。用戶在運(yùn)用軟件的過程中發(fā)現(xiàn)許多Bug,導(dǎo)致開

11、發(fā)方的糾錯(cuò)性維護(hù)代價(jià)很高。 有些軟件機(jī)構(gòu)雖然很注重軟件質(zhì)量,按照ISO,CMM 的要求建立了管理規(guī)范,但是效果不明顯。人們搞不清楚軟件測(cè)試、技術(shù)評(píng)審、質(zhì)量保證的作用和關(guān)系。不懂得內(nèi)建質(zhì)量,主要靠修補(bǔ)錯(cuò)誤的方式提升質(zhì)量,代價(jià)比較高。 很多人誤以為提高軟件質(zhì)量是質(zhì)量保證人員和測(cè)試人員的責(zé)任,沒有認(rèn)識(shí)到任何開發(fā)人員、管理人員都會(huì)對(duì)質(zhì)量產(chǎn)生影響,都要對(duì)質(zhì)量擔(dān)任。另外,質(zhì)量保證人員的權(quán)益比較小,很難推進(jìn)質(zhì)量改良措施。 2.6.2 建議讓人們了解“什么是軟件質(zhì)量及常見的軟件質(zhì)量屬性,樹立全面軟件質(zhì)量管理的理念模型,制定軟件測(cè)試、技術(shù)評(píng)審、質(zhì)量保證的規(guī)范。并運(yùn)用方便的工具,協(xié)助團(tuán)隊(duì)進(jìn)展軟件質(zhì)量管理。 2.7

12、 常見問題分析:需求開發(fā)與管理2.7.1 共性問題對(duì)于大部分軟件機(jī)構(gòu)而言,需求開發(fā)與需求管理是問題最多、最難處理的過程域。 軟件機(jī)構(gòu)中,知曉需求調(diào)查、需求分析、需求定義、需求評(píng)審、需求跟蹤、需求變卦控制的人員本來就比較少,也不容易招聘和培育這樣的人才。 用戶說不清楚需求、用戶經(jīng)常變卦需求是普遍景象,令開發(fā)方非常頭痛。 開發(fā)人員不擅長(zhǎng)寫文檔,很難寫出清楚、完好的軟件需求規(guī)格闡明書。后續(xù)開發(fā)人員能夠誤解需求,做出與需求不一致的設(shè)計(jì)、代碼、測(cè)試用例等等,最后不得不大量返工重做。 最難辦的事情是莫過于“回絕客戶提出的需求變卦懇求??蛻魰?huì)想當(dāng)然地以為變卦需求是他的權(quán)益,由于他付錢給開發(fā)方。通常情況下開發(fā)

13、方是不敢得罪客戶的,但是無原那么地退讓將使開發(fā)小組墮入姿態(tài)。 2.7.2 建議建立“需求開發(fā)與管理規(guī)范,給出適宜的文檔模板,采用方便的需求分析和管理工具。還要多請(qǐng)有閱歷的人來培訓(xùn)、教授實(shí)戰(zhàn)閱歷。 制定應(yīng)對(duì)需求變卦的方法,例如:(1)雙方簽署需求變卦管理協(xié)議;(2)將艱苦需求變卦延緩到下個(gè)軟件版本中實(shí)現(xiàn);(3)讓客戶欠下人情。 2.8 常見問題分析:軟件設(shè)計(jì)2.8.1 共性問題對(duì)于大部分軟件機(jī)構(gòu)而言,用戶界面設(shè)計(jì)是弱項(xiàng)。國(guó)內(nèi)絕大多數(shù)大學(xué)的計(jì)算機(jī)學(xué)科沒有開設(shè)人機(jī)工程學(xué)、美學(xué)、心思學(xué)這些必修課。由于學(xué)生們接受的教育幾乎全是科學(xué)與技術(shù),他們根本不知道怎樣才干設(shè)計(jì)出易用、美觀的用戶界面,很多人甚至想都沒

14、有想過。當(dāng)他們畢業(yè)后真正參與軟件產(chǎn)品開發(fā)時(shí),只好憑著個(gè)人的閱歷與覺得設(shè)計(jì)軟件的用戶界面,這樣產(chǎn)生的界面往往得不到群眾用戶的認(rèn)可。 大部分軟件機(jī)構(gòu)都有一些技術(shù)出色的軟件人員,他們?cè)谙到y(tǒng)構(gòu)架、數(shù)據(jù)庫(kù)方面的設(shè)計(jì)才干相當(dāng)不錯(cuò)。但是很多人不情愿、不擅長(zhǎng)寫系統(tǒng)設(shè)計(jì)報(bào)告,這不利于后續(xù)的軟件開發(fā)和維護(hù)。 軟件設(shè)計(jì)該當(dāng)“細(xì)到什么程度很難把握。太粗了的話,對(duì)后續(xù)開發(fā)任務(wù)的指點(diǎn)價(jià)值不高;反之倘假設(shè)太細(xì)的話,耗費(fèi)時(shí)間就比較多,假設(shè)后面不斷改良設(shè)計(jì)的話,前面的設(shè)計(jì)浪費(fèi)太多。 2.8.2 建議建立“軟件設(shè)計(jì)規(guī)范,給出適宜的文檔模板,采用方便的設(shè)計(jì)工具。 還要多請(qǐng)有閱歷的人來培訓(xùn)、教授實(shí)戰(zhàn)閱歷。 2.9 常見問題分析:編程

15、與調(diào)試2.9.1 共性問題軟件機(jī)構(gòu)的大部分程序員的技藝是合格的,但是他們編寫的程序風(fēng)格差別較大,代碼質(zhì)量有高有低。大多數(shù)軟件機(jī)構(gòu)沒有編程規(guī)范,即使有的話,開發(fā)人員也沒有很好地按規(guī)范編程。相當(dāng)多的程序員沒有養(yǎng)成對(duì)一切代碼進(jìn)展“單步跟蹤調(diào)試的習(xí)慣。嫌單元測(cè)試很費(fèi)事,懶得執(zhí)行,卻沒有替代方案。2.9.2 建議制定簡(jiǎn)單明了、重點(diǎn)突出的“編程規(guī)范,讓團(tuán)隊(duì)遵照此規(guī)范編寫程序。采用集成化的開發(fā)調(diào)試工具,提高編程質(zhì)量和效率。 2.10 常見問題分析:軟件測(cè)試2.10.1 共性問題許多軟件人員沒有系統(tǒng)地學(xué)習(xí)過軟件測(cè)試,搞不清楚各種測(cè)試的概念,例如單元測(cè)試、集成測(cè)試、驗(yàn)收測(cè)試、黑盒測(cè)試、白盒測(cè)試、功能測(cè)試、性能測(cè)

16、試等等,混為一談,不知如何下手。測(cè)試人員沒有掌握有效測(cè)試的方法,大多憑覺得測(cè)試,結(jié)果反復(fù)測(cè)試曾經(jīng)測(cè)試過的,那些深藏的bug卻發(fā)現(xiàn)不了??蛻粼谶\(yùn)用軟件的過程中發(fā)現(xiàn)的bug比公司內(nèi)部測(cè)試時(shí)發(fā)現(xiàn)的還多,不僅改錯(cuò)代價(jià)高,而且降低了客戶對(duì)產(chǎn)品的稱心度。團(tuán)隊(duì)沒有采用有效的缺陷跟蹤工具。測(cè)試人員發(fā)現(xiàn)bug時(shí),口頭告知有關(guān)人員或者記在Word、Excel文件中,修正bug信息或者測(cè)試報(bào)告時(shí)非常費(fèi)事。難以及時(shí)從bug列表中找出規(guī)律,測(cè)試的效率比較低。 2.9.2 建議建立“軟件測(cè)試規(guī)范,采用方便的測(cè)試管理工具。還要多請(qǐng)有閱歷的人來培訓(xùn)、教授實(shí)戰(zhàn)閱歷。 2.11 常見問題分析:軟件維護(hù)2.11.1 共性問題在維護(hù)

17、期間,除了糾錯(cuò)性維護(hù)外,客戶能夠提出需求變卦但是不支付費(fèi)用,維護(hù)人員對(duì)客戶妥協(xié),導(dǎo)致維護(hù)任務(wù)量增大、本錢添加。假設(shè)是合同軟件工程,用戶對(duì)開發(fā)方的依賴性比較大,不情愿本人處理粗淺的問題,經(jīng)常叫開發(fā)方“干這干那。開發(fā)方不敢得罪客戶,導(dǎo)致開發(fā)方做了許多不屬于維護(hù)的任務(wù),吃啞巴虧。開發(fā)人員一邊開發(fā)新工程,一邊維護(hù)老工程。而維護(hù)為表達(dá)不出業(yè)績(jī),又影響了新工程的進(jìn)度,開發(fā)人員比較心煩。 2.11.2 建議制定“軟件維護(hù)規(guī)范,界定什么是“免費(fèi)維護(hù)、什么是“有償維護(hù),以及相應(yīng)的操作規(guī)那么,提高維護(hù)效率并且降低維護(hù)本錢。 2.12 常見問題分析:其它問題2.12.1 技術(shù) vs. 市場(chǎng)許多開發(fā)人員喜歡技術(shù)研討和

18、技術(shù)挑戰(zhàn)。雖然嘴上說開發(fā)產(chǎn)品要以“客戶市場(chǎng)為中心,但是在開發(fā)軟件的時(shí)候,卻不知不覺以技術(shù)為中心,例如喜歡采用新技術(shù)、追求技術(shù)上的完美。導(dǎo)致進(jìn)度延誤,本錢添加,甚至能夠有質(zhì)量風(fēng)險(xiǎn)。他們開發(fā)出來的軟件在技術(shù)上能夠很先進(jìn),但是并不是用戶所關(guān)懷的。多數(shù)開發(fā)人員缺乏商業(yè)頭腦,經(jīng)常做出背叛企業(yè)根本目的的事情。企業(yè)指點(diǎn)該當(dāng)注重這個(gè)問題,要經(jīng)常性地向開發(fā)人員們灌輸商業(yè)理念。讓他們明白 “可以賺錢的技術(shù)才是好技術(shù)。在企業(yè)里,商業(yè)利益高于技術(shù)追求。 2.11.2 工程經(jīng)理的財(cái)務(wù)權(quán)國(guó)內(nèi)大部分企業(yè)的工程經(jīng)理有帶頭干活的權(quán)益和義務(wù),他們對(duì)工程的進(jìn)度和質(zhì)量負(fù)最大責(zé)任,但是沒有財(cái)務(wù)權(quán)。大部分工程沒有經(jīng)費(fèi),即使有經(jīng)費(fèi),也得由

19、上級(jí)指點(diǎn)審批運(yùn)用,不能本人作主。有時(shí)團(tuán)隊(duì)加班干了不少活,工程經(jīng)理卻沒有錢“意思意思,很沒有面子。沒有財(cái)務(wù)權(quán)的工程經(jīng)理,不是完好意義上的工程經(jīng)理。企業(yè)不給工程經(jīng)理財(cái)務(wù)權(quán)的初衷是為了控制本錢,防止工程經(jīng)理亂花錢。但是實(shí)踐上效果適得其反。由于工程經(jīng)理沒有財(cái)務(wù)權(quán),他們就不會(huì)關(guān)懷本錢也不懂得如何控制本錢。因管理不成熟、任務(wù)效率不高、進(jìn)度延誤等問題導(dǎo)致“隱性本錢不斷添加,錢在不知不覺地流失。企業(yè)指點(diǎn)該當(dāng)給予工程經(jīng)理“適當(dāng)?shù)呢?cái)務(wù)權(quán),只需確定工程財(cái)務(wù)制度并限定經(jīng)費(fèi)額度,就不會(huì)呵斥失控。既讓工程經(jīng)理“有點(diǎn)小錢慰勞團(tuán)隊(duì),有任務(wù)積極性;又讓他真正注重本錢控制,并付諸實(shí)際。用“小量胡蘿卜獲得大報(bào)答。 3. 中型企業(yè)的

20、研發(fā)管理需求3.1 需求特征必要性。假設(shè)軟件機(jī)構(gòu)只需數(shù)人或者十幾個(gè)人,即使沒有研發(fā)管理規(guī)范,才干強(qiáng)的機(jī)構(gòu)指點(diǎn)一個(gè)人也能從容指揮。當(dāng)軟件機(jī)構(gòu)的人數(shù)超越50人后,假設(shè)還沒有研發(fā)管理規(guī)范的話,那么機(jī)構(gòu)指點(diǎn)將會(huì)力不從心。人數(shù)越多,非規(guī)范化管理越容易產(chǎn)生混亂,迫使企業(yè)不得不走規(guī)范化管理的道路,以降低管理代價(jià)和風(fēng)險(xiǎn)。經(jīng)濟(jì)根底。建立規(guī)范化的研發(fā)管理是需求一定的投資的,例如咨詢、培訓(xùn)、購(gòu)買工具等等。小型軟件機(jī)構(gòu)通常沒有錢去做這件事情,望洋興嘆。中型機(jī)構(gòu)可以養(yǎng)活50200人,表示它們是有一定經(jīng)濟(jì)實(shí)力的,只需投資額適當(dāng)而且產(chǎn)生的效益高于投資,那么中型機(jī)構(gòu)普通都情愿做這件事情。 開展愿望。有些中型機(jī)構(gòu)的指點(diǎn)雄心勃勃

21、,高瞻遠(yuǎn)矚,他們迫切希望提高研發(fā)管理才干從而提升整個(gè)企業(yè)的中心競(jìng)爭(zhēng)力,產(chǎn)生源源不斷的推進(jìn)力,推進(jìn)企業(yè)繼續(xù)開展壯大。他們對(duì)研發(fā)管理的態(tài)度是自動(dòng)的,而不是被動(dòng)的。 3.2 費(fèi)用估算國(guó)內(nèi)一些大型IT企業(yè)建立了完好的研發(fā)管理體系,投資宏大。例如上海貝爾、華為分別請(qǐng)HP、IBM建立研發(fā)管理體系,投資額分別到達(dá)數(shù)千萬元、上億元。這種投資額是中型企業(yè)望塵莫及的。在研發(fā)管理方面,中型企業(yè)無法效仿大型企業(yè)的做法。國(guó)內(nèi)中型軟件機(jī)構(gòu)對(duì)研發(fā)管理的投資額大約在數(shù)萬元至元數(shù)十萬元。這點(diǎn)“小錢根本無法引入IBM、HP、Rational等公司的研發(fā)管理處理方案。 大部分國(guó)內(nèi)中型軟件機(jī)構(gòu)需求的是“輕量級(jí)的研發(fā)管理處理方案,包括

22、咨詢、培訓(xùn)、購(gòu)買工具,總費(fèi)用在5萬元至20萬元之間比較適宜。 4. 根底方法論引見CMM4.1 根本概念產(chǎn)品是在過程中研制出來的。普通地,好的過程才能夠得到好的產(chǎn)品,而差的過程只會(huì)得到差的產(chǎn)品。提高軟件過程才干的實(shí)際通稱為軟件過程改良Software Process Improvement。軟件過程改良的根本目的是:提高質(zhì)量、提高消費(fèi)率并且降低開發(fā)本錢。 CMM/CMMI是世界范圍內(nèi)用于衡量軟件過程才干的現(xiàn)實(shí)上的規(guī)范,同時(shí)也是軟件過程改良最權(quán)威的指南。 CMM等級(jí)評(píng)價(jià):從狂熱回歸理性。如今軟件業(yè)界普遍關(guān)注的是:企業(yè)如何以比較低的代價(jià)有效地提高軟件過程才干。CMM等級(jí)評(píng)價(jià)那么退居次要位置。 4.

23、2 CMM的盲區(qū)和常見運(yùn)用問題CMM本身不談如何賺錢的問題。它假設(shè)了愉快的前提條件,即企業(yè)有充足的人員、資金、時(shí)間從事軟件過程改良,當(dāng)軟件過程才干提高了,那么產(chǎn)品的質(zhì)量、消費(fèi)率自然上去了同時(shí)本錢也下降了,企業(yè)自然可以獲取更多的利潤(rùn)。軟件過程改良對(duì)企業(yè)經(jīng)濟(jì)效益的奉獻(xiàn)是間接的,從投入到產(chǎn)出,時(shí)間相對(duì)比較長(zhǎng)。 企業(yè)指點(diǎn)當(dāng)然想把資源用在“刀刃上,即賺錢最多最快的地方。當(dāng)軟件過程改良和其它直接賺錢的事情“發(fā)生資源沖突時(shí),人們只好“拆東墻,補(bǔ)西墻,往往減少軟件過程改良的資源。小結(jié):對(duì)于軟件過程改良而言,CMM/CMMI和ISO等等都是用來參考的,而不是用來迷信的。企業(yè)在參考業(yè)界引薦的規(guī)范或規(guī)范時(shí),要舍棄那

24、些聽起來很先進(jìn)但是對(duì)本企業(yè)無益處的東西,只選取對(duì)企業(yè)有適用價(jià)值的東西。 5. 根底方法論引見PMBOK5.1 根本概念工程管理協(xié)會(huì)PMI是目前全球影響最大的工程管理專業(yè)機(jī)構(gòu),該機(jī)構(gòu)的工程管理專家認(rèn)證PMP被廣泛認(rèn)同。PMI的突出奉獻(xiàn)是總結(jié)了一套工程管理知識(shí)體系PMBOK。 PMBOK把工程管理知識(shí)劃分為九個(gè)知識(shí)領(lǐng)域:綜合管理、范圍管理、時(shí)間管理、本錢管理、質(zhì)量管理、人力資源管理、溝通管理、風(fēng)險(xiǎn)管理和采購(gòu)管理。每個(gè)知識(shí)領(lǐng)域包括數(shù)量不等的工程管理過程。 5.2 PMBOK和CMM/CMMI對(duì)比簡(jiǎn)評(píng) CMM/CMMI論述的工程管理方法僅僅適用于軟件工程,但是不適用于其它行業(yè)的工程管理。PMBOK論述

25、的方法適用于任何行業(yè)的工程管理,但是對(duì)軟件工程管理而言,PMBOK的針對(duì)性不夠強(qiáng)。 CMM/CMMI不僅論述軟件工程管理,而且論述整個(gè)機(jī)構(gòu)的軟件研發(fā)管理。PMBOK的方法局限于工程管理,對(duì)于企業(yè)研發(fā)管理那么不夠用。 CMM/CMMI根本上不談“本錢管理和“人力資源管理,它先假設(shè)機(jī)構(gòu)有充足的資金和人力資源,通常不切合企業(yè)實(shí)踐情況。因此PMBOK的“本錢管理和“人力資源管理可以彌補(bǔ)CMM/CMMI的缺乏。 建議:對(duì)于軟件機(jī)構(gòu)研發(fā)管理或者軟件工程管理,采用CMM/CMMI為主導(dǎo)的方法論,并結(jié)合PMBOK的知識(shí),取長(zhǎng)補(bǔ)短。 6. 根底方法論引見矯捷開發(fā)6.1 根本概念2001年,為理處理許多公司的軟件

26、團(tuán)隊(duì)墮入不斷擴(kuò)展的過程泥潭,一批業(yè)界專家概括出了一些可以讓軟件開發(fā)團(tuán)隊(duì)具有快速任務(wù)、呼應(yīng)變化才干的價(jià)值觀和原那么,他們稱本人為矯捷聯(lián)盟Agile Alliance。他們起草了一個(gè)旨在鼓勵(lì)更好的軟件開發(fā)方法的宣言,稱為矯捷聯(lián)盟宣言The Manifesto of the Agile Alliance。然后在該宣言根底上制定了12條原那么用于指點(diǎn)實(shí)際。該宣言和12條原那么是矯捷軟件開發(fā)方法的中心。 6.2 我們的觀念矯捷軟件開發(fā)的宣言和12條原那么并非普遍適用。 矯捷開發(fā)方法表達(dá)了“簡(jiǎn)單、快速、適用的軟件開發(fā)思想,它不是成熟的實(shí)際、也不是現(xiàn)實(shí)上的規(guī)范不象CMM, PMBOK那樣具有嚴(yán)密的實(shí)際體系,

27、被企業(yè)廣泛接受。即使人們認(rèn)同某些原那么,但是不同的人往往有不同的了解,實(shí)際差別很大。 矯捷開發(fā)方法對(duì)于提高個(gè)人、小型團(tuán)隊(duì)的任務(wù)效率是很有協(xié)助的假設(shè)用對(duì)了的話。但是企圖用它指點(diǎn)大型、中型軟件機(jī)構(gòu)的研發(fā)管理是有很高風(fēng)險(xiǎn)的,它的某些主張是部分觀念而不是全局觀念,假設(shè)把握不好分寸的話能夠?qū)е抡w混亂,而“整體的混亂會(huì)淹沒“部分的益處。我們研制的“精簡(jiǎn)并行過程SPP的實(shí)際根底是“經(jīng)典軟件工程、CMM、PMBOK。為了提高效率,在部分地方自創(chuàng)了“矯捷軟件開發(fā)的思想,用于裁減過于冗長(zhǎng)、笨重的過程規(guī)范。 6. 根底方法論引見矯捷開發(fā)矯捷軟件開發(fā)的12條原那么:1我們最優(yōu)先要做的是經(jīng)過盡早地、繼續(xù)地交付有價(jià)值的

28、軟件來使客戶稱心。 2即使到了開發(fā)的后期,也歡迎改動(dòng)需求。矯捷過程利用變化來為客戶發(fā)明競(jìng)爭(zhēng)優(yōu)勢(shì)。3經(jīng)常性地交付可以任務(wù)的軟件,交付的間隔可以從幾個(gè)星期到幾個(gè)月,交付的時(shí)間間隔越短越好。 4在整個(gè)工程開發(fā)期間,業(yè)務(wù)人員和開發(fā)人員必需天天都在一同任務(wù)。 5圍繞被鼓勵(lì)起來的個(gè)人來構(gòu)建工程。給他們提供所需的環(huán)境和支持,并且信任他們可以完成任務(wù)。 6在團(tuán)隊(duì)內(nèi)部,最具有效果并富有效率的傳送信息的方法,就是面對(duì)面的交談。 7可以任務(wù)的軟件是首要的進(jìn)度度量規(guī)范。 8矯捷過程提倡可繼續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該可以堅(jiān)持一個(gè)長(zhǎng)期的、恒定的開發(fā)速度。 9不斷地關(guān)注優(yōu)秀的技藝和好的設(shè)計(jì)會(huì)加強(qiáng)矯捷才干。 10

29、簡(jiǎn)單把無需做的任務(wù)最大化的藝術(shù)是最根本的。 11最好的構(gòu)架、需求和設(shè)計(jì)出于自我組織的團(tuán)隊(duì)。 12每隔一定時(shí)間,團(tuán)隊(duì)會(huì)在如何才干更有效地任務(wù)方面進(jìn)展反省,然后相應(yīng)地對(duì)本人的行為進(jìn)展調(diào)整。 7. 根底方法論引見RUP7.1 根本概念RUPRational Unified Process是Rational公司推出的軟件過程模型,它是軟件業(yè)界迄今為止商品化最勝利的軟件過程模型。RUP的近千頁(yè)文檔可以從Rational公司的網(wǎng)站rational下載,RUP 2000中文版也曾經(jīng)發(fā)布。RUP的主要特征是:采用迭代的、增量式的開發(fā)過程。采用UML言語(yǔ)描畫軟件開發(fā)過程。有一系列功能強(qiáng)大的軟件工具支撐Ratio

30、nal公司的軟件產(chǎn)品。 7.2 我們的觀念RUP及其配套軟件工具是分量級(jí)的軟件研發(fā)管理處理方案,它面向的是高端用戶,對(duì)用戶的財(cái)力、開發(fā)和管理才干要求都很高:首先,用戶得有錢買Rational的軟件工具,否那么光有RUP方法論好像紙上談兵。 假設(shè)要運(yùn)用RUP方法,人們得先熟習(xí)UML,否那么除了RUP模型圖之外他根本上看不懂細(xì)節(jié)內(nèi)容??墒窃谄胀ㄆ髽I(yè)里,大部分人尤其是指點(diǎn)和管理人員不熟習(xí)UML。學(xué)習(xí)UML和RUP的難度遠(yuǎn)高于CMM和PMBOK。工程經(jīng)理和開發(fā)組長(zhǎng)要有才干控制迭代過程,否那么迭代式開發(fā)就變得混亂無序和漫無邊沿 RUP及其配套的軟件工具根本上不適宜于國(guó)內(nèi)中型和小型軟件機(jī)構(gòu)。 8. 面向企

31、業(yè)的軟件研發(fā)管理處理方案8.1 目的協(xié)助企業(yè)建立適宜于本身需求的軟件研發(fā)管理規(guī)范,并部署配套的軟件工具;經(jīng)過充分的培訓(xùn),協(xié)助員工們掌握提高質(zhì)量、提高消費(fèi)率、降低本錢的方法;協(xié)助企業(yè)根據(jù)規(guī)范開展軟件研發(fā)和管理任務(wù),繼續(xù)提升才干。 8.2 任務(wù)流程面向企業(yè)的軟件研發(fā)管理處理方案8. 面向企業(yè)的軟件研發(fā)管理處理方案 8.3 集成化研發(fā)管理方法Simplified Parallel Process, SPP8. 面向企業(yè)的軟件研發(fā)管理處理方案8.4 內(nèi)容和時(shí)間1.調(diào)查分析問題對(duì)企業(yè)研發(fā)管理的能力現(xiàn)狀進(jìn)行調(diào)查與分析,調(diào)查內(nèi)容要覆蓋所有工作領(lǐng)域(過程域),總結(jié)“強(qiáng)項(xiàng)”和“弱項(xiàng)”,給出建議。 預(yù)計(jì)時(shí)間跨度為

32、2個(gè)月,乙方到甲方現(xiàn)場(chǎng)工作和服務(wù)約20工作日。日程安排由雙方共同商定。2.制定研發(fā)管理規(guī)范 繪制研發(fā)管理的總體流程圖;繪制組織結(jié)構(gòu)圖,并確定角色職責(zé)表 ;定義每個(gè)過程域的規(guī)范(目的,關(guān)鍵活動(dòng)和流程,工作成果) 3.選用合適的工具選擇并部署合適的開發(fā)工具和管理工具。推薦管理工具是Future和CVS。含1年免費(fèi)維護(hù)和升級(jí)服務(wù)4.充分必要的培訓(xùn)為研發(fā)管理流程中的所有人員提供充分必要的培訓(xùn),包括軟件工程、項(xiàng)目管理等,讓人們掌握提高軟件質(zhì)量、提高生產(chǎn)率、降低成本的方法。 5.執(zhí)行、監(jiān)督與反饋協(xié)助客戶依據(jù)規(guī)范開展軟件研發(fā)和管理工作。跟蹤試點(diǎn)項(xiàng)目的執(zhí)行情況,及時(shí)解答執(zhí)行過程中遇到的問題,持續(xù)地提升客戶的軟件研發(fā)能力。 乙方提供一年的售后服務(wù)。解決方案的內(nèi)容視企業(yè)的實(shí)際情況而定。8.5 相關(guān)著作9. 集成化軟件工程管理系統(tǒng)Future9.1 什么是FutureFuture是基于Web的集成化工程管理系統(tǒng),目的是“讓工程管理變得簡(jiǎn)單有效。Future的主要客戶是國(guó)內(nèi)中型軟件機(jī)構(gòu),主要最終用戶是研發(fā)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論