1、Word 軟件開發(fā)項目實施方案篇：軟件開發(fā)項目管理實施方案. 項目管理實施方案 作為一個項目管理者,如何要勝利的做好項目管理;首先必需先要明白的是在特定的領(lǐng)域中給予這個角色所要實現(xiàn)的目標(biāo)、擔(dān)當(dāng)?shù)穆氊?zé)、以及項目管理者的詳細(xì)工作內(nèi)容是什么? 從我個人的淺見和角度以及我們所從事的IT領(lǐng)域來分析回答以上三個問題。 第一:目標(biāo) 作為一個項目的管理者,必需要明確的知道自己的工作目標(biāo);我個人認(rèn)為項目管理者的目標(biāo)無非就是以下兩點: 1、就是清楚明確地了解項目利害關(guān)系者的需求和期望,努力做到滿意項目利害關(guān)系者的不同需求;項目利害關(guān)系者包括:項目團(tuán)隊成員和項目團(tuán)隊外成員(比如各部門的部門負(fù)責(zé)人和市場人員,客戶等。

2、 2、就是保證開發(fā)項目按需按時保質(zhì)的完成。 其次:職責(zé) 作為項目的管理者,首先要端正態(tài)度,要明確知道自己的工作職責(zé),熟悉到這份工作職責(zé)的本質(zhì)。項目管理者不是來管人的,而是來支持人的,是來協(xié)調(diào)資源的,是來營造一個適合團(tuán)隊成員比較認(rèn)同的工作環(huán)境和氛圍的,是來為一個共同的目標(biāo)和大家一起戰(zhàn)斗共同成長的?？梢砸苍S概括成以下幾點: 1、建立有效的工作流程保證項目的順當(dāng)進(jìn)行。 2、制定具體周密的項目方案。 3、跟蹤,推動項目按方案進(jìn)行。 4、樂觀解決項目過程中消失的問題和沖突。 5、調(diào)動開發(fā)團(tuán)隊的樂觀性,制造力,推動團(tuán)隊成員在項目過程中不斷成長。 6、項目風(fēng)險識別、風(fēng)險評估、風(fēng)險解決和風(fēng)險管理策略以及做好突

3、發(fā)風(fēng)險的應(yīng)急預(yù)案。 7、實現(xiàn)目標(biāo) 第三:項目管理者的詳細(xì)工作內(nèi)容 最終一個是項目管理者的詳細(xì)工作內(nèi)容,作為項目管理者必需清楚的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心,分為以下六點: 1、項目前期階段 對項目進(jìn)行技術(shù)可行性分析、技術(shù)評估、成本評估以及風(fēng)險評估。與需求提出方的代表進(jìn)行需求爭論,明確項目的目標(biāo)、價值;確定項目范圍、功能及優(yōu)先級。組建項目團(tuán)隊,特殊要搞清晰項目的key person(對產(chǎn)品有打算權(quán)的人。項目啟動會議,相關(guān)的 利害關(guān)系人員都必需參與。 該階段完成后的成果:確認(rèn)后的最終軟件需求規(guī)格說明書文檔。 2、分析設(shè)計階段 依據(jù)確認(rèn)后的軟件需求規(guī)格說明書,制定項目進(jìn)度方案,工

4、作任務(wù)分解(WBS;資源申請,項目涉及到的開發(fā)資源、測試資源、設(shè)計資源(包括人員和軟硬件資源;數(shù)據(jù)庫設(shè)計;系統(tǒng)設(shè)計;文檔(包括Use Case、Demo系統(tǒng)原型、Test Case等;評審會議。 該階段完成后的成果: A、User Case(系統(tǒng)用例; B、DEMO(系統(tǒng)原型; C、系統(tǒng)設(shè)計文檔(概要設(shè)計和具體設(shè)計; D、數(shù)據(jù)庫設(shè)計文檔。 最終對完成的成果,包括User Case和設(shè)計文檔等進(jìn)行評審。 3、執(zhí)行階段(開發(fā)和測試 預(yù)備開發(fā)環(huán)境、測試環(huán)境;跟蹤,推動項目按方案進(jìn)行;以周報的形式通報項目的進(jìn)展?fàn)顩r。對項目的階段成果進(jìn)行評估,以確保該階段完成的質(zhì)量,包括代碼審核、SQL 審核等。對需求

5、變更進(jìn)行掌握管理;對項目風(fēng)險進(jìn)行管理;測試階段BUG FIXED及改進(jìn)、收集反饋看法。 4、發(fā)布階段 包括制定項目發(fā)布方案,用戶培訓(xùn),發(fā)布上線。 5、上線后監(jiān)控 數(shù)據(jù)監(jiān)控(日志、服務(wù)器狀態(tài),依據(jù)監(jiān)控消失的問題,準(zhǔn)時進(jìn)行BUG FIXED及改進(jìn)或做補丁升級。 6、結(jié)束階段 產(chǎn)品交付,項目會。 第四:基于以上三個問題所做的應(yīng)對細(xì)則 要做好項目管理,并能的確解決好以上三個問題,實現(xiàn)目標(biāo)、履行職責(zé)、完成工作中的詳細(xì)內(nèi)容,從我個人這幾年的工作閱歷和面臨的一些問題,還有所積累的一些項目管理中的 一些學(xué)問以及自己的觀看和思索的角度看,應(yīng)當(dāng)要努力做好以下這幾個方面的詳細(xì)工作: 1、項目開發(fā)時間的估算 制定項目

6、進(jìn)度時間表的時候,需要估算每個任務(wù)所需的時間,其中開發(fā)任務(wù)中模塊的安排和時間估算是其中最主要的部分;在安排模塊和估算開發(fā)時間時需要遵循的原則和目標(biāo): 1、保證項目整體的進(jìn)度。 2、有助于確保開發(fā)編碼的質(zhì)量。 3、有助于提高開發(fā)編碼的速度。 在公司現(xiàn)有的技術(shù)框架下,開發(fā)人員主要的工作是投入在詳細(xì)的商業(yè)規(guī)律上。通常每個模塊所需的開發(fā)時間取決于以下三個因素: 1、所負(fù)責(zé)模塊的商業(yè)規(guī)律的簡單程度。 2、開發(fā)人員的技術(shù)水平和對項目所在應(yīng)用的熟識程度(包括對框架和應(yīng)用的熟識程度。 3、該模塊技術(shù)實現(xiàn)上是否有技術(shù)難點;這里所謂的技術(shù)難點定義是:在現(xiàn)有系統(tǒng)中還未實現(xiàn)的、開發(fā)人員自身也未沒接觸過的技術(shù)。對于這樣

7、的難點,開發(fā)者沒有相關(guān)的代碼可以參考,自己也沒有閱歷,所以需要投入一些時間討論解決。 模塊安排和開發(fā)時間估算的步驟: 1、在劃分好模塊后,首先自己先估算一下每個模塊所需要的開發(fā)時間。 2、然后召集全部開發(fā)人員,爭論模塊的安排和開發(fā)時間估算。將劃分好的模塊,讓開發(fā)人員從中選擇他們感愛好的模塊。這樣做可以提高開發(fā)人員的主動性和參加性。在安排模塊的時候還需從以下幾方面考慮,以確保開發(fā)的速度和質(zhì)量: A、相同類似的模塊由同一人負(fù)責(zé)開發(fā),比如用戶管理的增刪改由同一開發(fā)者負(fù)責(zé)。 這樣做的好處就是開發(fā)者對相關(guān)規(guī)律會更加熟識,同時接口的定義也會比較明確,溝通的成本比較低,同時功能實現(xiàn)的缺陷也相應(yīng)的會降低。 B

8、、技術(shù)難度比較大的模塊由技術(shù)水平比較高的人負(fù)責(zé)。 C、業(yè)務(wù)規(guī)律比較簡單的由對這塊規(guī)律比較了解的人負(fù)責(zé)。 3、模塊安排完后,開發(fā)人員評估自己負(fù)責(zé)開發(fā)的模塊所需要的時間。在此過程中最好做到要和開發(fā)者比較具體的爭論每個模塊的技術(shù)實現(xiàn),以便使時間的估算更加精確 。 4、對開發(fā)人員估算的時間進(jìn)行確認(rèn)。在確認(rèn)過程中作為項目管理者應(yīng)參考以上提到的三個因素,同時將自己估算的時間和開發(fā)人員估算的時間進(jìn)行比較。這其中的差異當(dāng)然會存在的。對于那些差異比較大的,將與技術(shù)人員探討其中的緣由。對于時間周期比較長的任務(wù),盡量將任務(wù)通過再細(xì)分的手段細(xì)化任務(wù),爭取每個任務(wù)的最長時間不超過3天;時間周期越長的任務(wù),不確定性越高,

9、風(fēng)險也越高,越有可能成為項目的瓶頸,影響項目的進(jìn)度。 2、Code Review Code Review是保證項目中代碼質(zhì)量特別重要的一個環(huán)節(jié),在這一環(huán)中我們公司做的特別欠缺,把關(guān)不嚴(yán)格;這是導(dǎo)致每次測試后消失大量bug的主要緣由,這一環(huán)需要納入績效考核中,實行責(zé)任追究制,實施重點監(jiān)控。消失這樣的薄弱環(huán)節(jié),造成這樣的緣由,我想也是有許多因素造成的;比如開發(fā)人員對需求不是很明確,以自己比較主觀的因素去完成任務(wù)的;還有對整個系統(tǒng)業(yè)務(wù)規(guī)律沒有正確的清楚的熟悉的緣由,以及對項目組成員培訓(xùn)不到位的緣由等眾多因素糾集在一起才產(chǎn)生的。 如何做好這方面的工作?首先編碼要有“編碼規(guī)范”文檔,Code Revie

10、w要有“代碼審 核規(guī)范”文檔:記錄代碼實現(xiàn)應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)。通過這兩個文檔來規(guī)范開發(fā)人員的代碼實現(xiàn),代碼編寫者必需要嚴(yán)格根據(jù)規(guī)范來進(jìn)行;代碼審核者依據(jù)這些標(biāo)準(zhǔn)來Code Review代碼,同時在Code Review過程中不斷完善該文檔。 在做好這些前期工作的前提下,分以下幾個步驟來實施: 1、檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。 2、從代碼的易維護(hù)性、可擴展性角度考察代碼的質(zhì)量,提出修改建議。 3、代碼編寫者和代碼審核者坐在一起,由代碼編寫者根據(jù)Use Case依次講解自己負(fù)責(zé) 的代碼和相關(guān)規(guī)律,從Web層-到Manage層再到Dao層; 4、代碼審核者在此過程中可以隨時提出自己的疑問,同

11、時樂觀發(fā)覺隱蔽的bug;對這 些bug記錄在案。 5、代碼講解完畢后,代碼審核者給自己支配幾個小時再對代碼審核一遍。代碼需要一 行一行靜下心來看。同時代碼又要全面的看,以確保代碼整體上設(shè)計優(yōu)良。 6、代碼審核者依據(jù)審核的結(jié)果編寫“代碼審核報告”,“審核報告”中記錄發(fā)覺的問題 及修改建議,然后把“審核報告”發(fā)送給相關(guān)人員。 7、代碼編寫者依據(jù)“代碼審核報告”給出的修改看法,修改好代碼,有不清晰的地方 可樂觀向代碼審核者提出。 8、代碼編寫者bug fixed完畢之后給出反饋。 9、代碼審核者把Code Review中發(fā)覺的有價值的問題更新到代碼審核規(guī)范的文檔中, 對于特殊值得提示的問題可群發(fā)em

12、ail給全部技術(shù)人員。假如通過以上步驟,還由于是代碼編寫者的緣由而消失嚴(yán)峻的缺陷問題,將通過績效考核來加深代碼編寫者的印象,并在周報會議上做通報批判。 3、需求變更管理 需求變更管理也是項目管理中最重要的一個環(huán)節(jié),對需求變更管理的有效性將直接影響項目的勝利與否。 對待需求變更的態(tài)度: 1、需求變更是不行避開的。 2、需求變更要必需被管理。 3、樂觀發(fā)覺引起變更的因素,促使變更盡可能早的消失,減低變更帶來的風(fēng)險。 需求變更管理的目標(biāo): 1、相關(guān)的干系人必需清晰地了解發(fā)生的變更。 2、變更處于有效的管理中。 3、盡量降低變更帶來的風(fēng)險。 通過制定需求變更的流程,確保項目中的需求變更有效地進(jìn)行,實現(xiàn)

13、上述的目標(biāo)。需求變更流程: 1、確定需求的基準(zhǔn)線。將以User Case作為需求基準(zhǔn)線,在User Case確認(rèn)之后的任何需求轉(zhuǎn)變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒有,期間有時候使的工 作很混亂,也就是由于沒有一個規(guī)范的變更流程而造成的;假如建立了這么一個流程規(guī)范和機制,需求變更沒有走這個流程的將不被認(rèn)可。 2、項目管理者接收到需求變更的要求。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。 3、項目管理者評估該需求變更。針對接收到的需求變更的要求,召集相關(guān)人員爭論該需求變更的合理性、可行性,實施的代價以及對項目的影響。包括可能影響的項目范圍,進(jìn) 度,

14、費用,質(zhì)量等方案。項目管理者作為項目的負(fù)責(zé)人,對項目的勝利與否負(fù)有主要的責(zé)任。所以需求變更的決策者應(yīng)當(dāng)由項目管理者擔(dān)當(dāng)。 4、需求變更確認(rèn)后由專人將需求變更記錄下來,通知給項目中全部成員。其中以下人員對需求的變更是緊密相關(guān)的,他們必需知曉并認(rèn)可此需求變更。包括(客戶方,需求分析人員,測試人員,相關(guān)開發(fā)人員。需求變更記錄格式如下: 序號變更提出時間變更描述變更類型(是 對原有需求 的修改還是 新增需求 緣由變更提出 者 開發(fā)人員對進(jìn)度的 影響(工 作量 1 2 5、確定變更的負(fù)責(zé)人。擔(dān)當(dāng)需求變更的詳細(xì)工作,比如基線掌握,對需求變更的記錄,并通知相關(guān)人員。 6、相關(guān)人員接收到確認(rèn)的需求變更后,做以

15、下事情。需求分析人員修改需求說明書和User Case的相關(guān)內(nèi)容。測試人員修改測試用例的相關(guān)內(nèi)容。開發(fā)人員修改代碼中的相關(guān)部分。 7、根據(jù)變更后的方案實施項目,并進(jìn)行檢查,跟蹤,對變更后的實施反饋和可能消失的問題準(zhǔn)時溝通和處理。 8、需求凍結(jié)。項目越到后期,需求變更對項目的影響就越大,所以在肯定時候要進(jìn)入需求凍結(jié)階段,不再接收新需求或需求的變更。 4、風(fēng)險管理 風(fēng)險管理是項目管理者最重要的工作之一。風(fēng)險管理是一個持續(xù)的過程,貫穿于整個項目過程中,風(fēng)險管理包括風(fēng)險識別、風(fēng)險評估、風(fēng)險解決以及風(fēng)險管理策略。 在項目的實施過程中需要不斷地識別和應(yīng)對風(fēng)險,并加以有效的掌握,風(fēng)險管理的好與壞直接影響項目

16、的實施效果,從某種意義上講,項目實施對于項目管理者就是識別、分析、應(yīng)對、掌握風(fēng)險的過程,使項目的約束性目標(biāo)和質(zhì)量目標(biāo)朝有利的方向進(jìn)展。 項目不同于日常任務(wù),它有明確的起止時間和目標(biāo),要在明確的范圍、時間和成本約束下,達(dá)到相應(yīng)的質(zhì)量標(biāo)準(zhǔn),并取得用戶的滿足。影響項目成敗的因素涉及方方面面,并且風(fēng)險伴隨著項目的始終,是客觀存在的,作為一個項目管理者,應(yīng)當(dāng)具備良好的風(fēng)險掌握意識,擅長識別風(fēng)險并分析風(fēng)險的影響,從中發(fā)覺影響目標(biāo)的風(fēng)險點,并施 加影響或?qū)嵭袘?yīng)對措施,把風(fēng)險的負(fù)面影響降到最低,并且風(fēng)險掌握應(yīng)當(dāng)貫穿項目始終。 風(fēng)險引起的負(fù)面后果集中體現(xiàn)在進(jìn)度延后、成本超支、質(zhì)量不達(dá)標(biāo)等方面,導(dǎo)致這些問題的因素

17、主要包括目標(biāo)以及需求不明確、范圍擴散以及需求變更、代碼質(zhì)量或返工風(fēng)險、人員技能和資源的不足、缺乏良好的團(tuán)隊協(xié)作等。下面將具體描述一下這些問題以及消失這些問題時的應(yīng)對方案: 1、目標(biāo)以及需求不明確 為了市場競爭或內(nèi)部管理決策的需要,業(yè)務(wù)部門提出的需求往往要求的時間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達(dá)上,沒有形成正式的業(yè)務(wù)需求文檔,在沒有明確的需求范圍的狀況下,有時為了迎合業(yè)務(wù)部門的口味匆忙開工,過程中用戶不斷地提出新的想法,技術(shù)人員開頭疲于奔命和應(yīng)付,很難保證項目的進(jìn)度和質(zhì)量,也難以取得業(yè)務(wù)部門的認(rèn)可。所以,在項目的前期肯定要實行相應(yīng)的手段或措施,與業(yè)務(wù)部門共同明確項目目標(biāo)、需求范圍

18、,充分考慮現(xiàn)有的時間和資源約束,將需求排定優(yōu)先級, 對于關(guān)鍵的需求優(yōu)先實現(xiàn)， 其他幫助性的依據(jù)過程中的詳細(xì)狀況進(jìn)行滾動式方案， 并取 得業(yè)務(wù)部門的書面確認(rèn)。在此過程中要注意挖掘用戶的隱性需求，可以通過引導(dǎo)、系統(tǒng) 原型等手段讓用戶在前期充分暴露自己的想法和需求。 2、范圍擴散以及需求變更 在有了明確的目標(biāo)和需求范圍的狀況下， 需求的變更還是不行避開的， 業(yè)務(wù)部門在 看到詳細(xì)系統(tǒng)的真實雛形之后，源源不斷地要求、新想法隨之產(chǎn)生，假如不對此加以控 制， 新的需求的加入通常會影響已實現(xiàn)的需求， 并且對項目進(jìn)度和成本產(chǎn)生很大的影響。 項目管理者針對這種狀況肯定要實行嚴(yán)格的變更掌握流程， 不能礙于面子， 否

19、則最終的 結(jié)果往往是出力不討好。針對用戶提出的新需求，根據(jù)正式流程提出變更申請，組織相 關(guān)團(tuán)隊成員進(jìn)行分析及評估， 作為是否實施的依據(jù)， 變更掌握負(fù)責(zé)人依據(jù)分析結(jié)果推斷 是否批準(zhǔn)，假如批準(zhǔn)，那項目組可以支配實施，否則，正式拒絕用戶的懇求，當(dāng)然實際 狀況下可以實行一些軟措施緩解沖突。 需求變更風(fēng)險：需求已經(jīng)打上了基線，但此后仍舊有變更 發(fā)生，對項目造成影響。 如何削減此類風(fēng)險的發(fā)生？ 前期的需求爭論要具體、充分。需求文檔中需求的范圍要明確、功能描述要清晰。 找出項目中需求的決策者(通常會是產(chǎn)品經(jīng)理、相關(guān)職能主管、客戶，全部的需求要經(jīng) 過他們的認(rèn)可?？蛻粼陧椖窟^程中的全程參加有助于降低此類風(fēng)險。需

20、求爭論、需求確 認(rèn)、User Case 確認(rèn)、測試階段的客戶驗收等環(huán)節(jié)，都要要求客戶參加。在發(fā)生需求變 更時， 嚴(yán)格根據(jù)需求變更流程執(zhí)行。 在分析設(shè)計階段的中的確認(rèn)和評審也是降低此類風(fēng) 險的重要手段。 3、代碼質(zhì)量或返工風(fēng)險 質(zhì)量風(fēng)險主要指開發(fā)代碼的質(zhì)量。 如何提高開發(fā)人員開發(fā)的質(zhì)量？在制定項目方案 時，對開發(fā)時間的評估要盡可能的合適。合理的開發(fā)時間對開發(fā)質(zhì)量的影響也很大。有 時開發(fā)人員為了趕進(jìn)度在比較緊急的時間需要完成指定的任務(wù)， 可能就存在很大的開發(fā) 質(zhì)量問題。開發(fā)要有一套嚴(yán)格可行的代碼規(guī)范，編碼時嚴(yán)格遵守，到現(xiàn)在為止，我們這 個方面做的不是很規(guī)范，做的也很不足，大家編寫的代碼隨便性比較大

21、，代碼編寫者的 主觀意識性比較強。要建立一套大家認(rèn)可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范，code review 時嚴(yán)格考核。在編碼前，開發(fā)人員要對框架嫻熟把握；一份好的系統(tǒng)設(shè)計文檔對 指導(dǎo)開發(fā)特別重要。 返工是項目組最不情愿看到的，既鋪張人力、物力和財力，又影響團(tuán)隊樂觀性。需 求不明確或范圍沒有有效掌握都可能造成返工， 另外造成返工的緣由是質(zhì)量沒有達(dá)到用 戶要求。往往有這樣一種狀況，每個團(tuán)隊成員根據(jù)項目方案報告進(jìn)度都是 100%完成， 但一到最終系統(tǒng)交互測試或集成的時候就會發(fā)覺一大堆問題， 不得不花費很大精力回頭 排查、修改程序，造成這種狀況的主要緣由是過程中質(zhì)量保證沒有做到位，把大部分問 題留

22、在了后面。 這就需要在項目實施過程中實行有效的措施來規(guī)避返工的風(fēng)險， 通常的 做法有同行評審， 比如概要設(shè)計完成之后， 邀請其他項目組的技術(shù)專家進(jìn)行技術(shù)評審以 發(fā)覺架構(gòu)設(shè)計問題； 管理評審， 通過組織級的質(zhì)量審計看產(chǎn)品以及實施過程是否滿意質(zhì) 量要求；代碼走查，在編碼過程中加入至少一次的代碼走查，排查不符合規(guī)范或性能要 求的代碼，走查通常能夠發(fā)覺 50%-70%的錯誤；每日構(gòu)建，這是一種特別有效的方法， 可以避開把各部分的集成問題拖到最終， 并且能夠準(zhǔn)時發(fā)覺相應(yīng)的錯誤， 日構(gòu)建一般在 項目的中后期開頭，每天自動從版本服務(wù)器上獵取源代碼進(jìn)行自動編譯和測試。 4、人員技能和資源的不足 項目實施過程中

23、由于人員技能欠缺造成的進(jìn) 度延后和軟件質(zhì)量問題并不少見， 一個 嫻熟的技術(shù)人員完成同樣一個任務(wù)需要 3 天，但一個生手可能就需要 7-10 天。項目管 理者應(yīng)當(dāng)在前期就分析清晰項目所要采納的技術(shù)以及相應(yīng)的人員技能要求， 針對不同的 角色，準(zhǔn)時實行相應(yīng)的技能培訓(xùn)，以保證項目的順當(dāng)實施。假如對于項目中某些部分專 業(yè)性特殊強或新技術(shù)，短期內(nèi)又不能快速建立技能的狀況，可以考慮將該塊任務(wù)外包， 借鑒合作商的力氣降低實施風(fēng)險，當(dāng)然要進(jìn)行外購人力成本與自建人力成本的效益分 析。開發(fā)過程中遇到技術(shù)難題，導(dǎo)致開發(fā)時間延遲或者需求不得不發(fā)生變更。如何削減 此類風(fēng)險的發(fā)生？在項目開頭前的技術(shù)評估階段， 明確技術(shù)難點

24、， 提前支配人員進(jìn)行攻 克。假如在可預(yù)期的時間內(nèi)無法解決，假如可以，將向需求提出方要求變更需求或查找 可替代方案。 這樣的風(fēng)險應(yīng)當(dāng)在項目的前期階段就應(yīng)當(dāng)解決在萌芽狀態(tài)來避開這樣的風(fēng) 險在后期或中期消失。 項目所需人力資源無法按時到位， 導(dǎo)致資源風(fēng)險。 如何削減此類風(fēng)險的發(fā)生？這個 就需要在項目方案制定的時候提前申請確認(rèn)資源，并在項目過程中不斷溝通協(xié)調(diào)。 5、缺乏良好的團(tuán)隊協(xié)作 軟件項目實施屬于學(xué)問型，要發(fā)揮團(tuán)隊成員的制造力，不同于制造業(yè)計件生產(chǎn)，各 模塊最終要集成在一起形成一個有機的整體， 這就需要各小組之間的親密協(xié)作， 界定清 楚工作界面及接口關(guān)系， 并在實施過程中持續(xù)地溝通溝通和共享， 首

25、先團(tuán)隊要融為一體， 產(chǎn)出的軟件才能融為一體。 這是一個團(tuán)隊的軟實力， 團(tuán)隊之間的協(xié)作好壞也將是個潛在 的風(fēng)險問題，在項目啟動和團(tuán)隊組建的時候就應(yīng)當(dāng)加以規(guī)避這樣的風(fēng)險消失。 項目風(fēng)險管理的要點： 1、上述我們所說的風(fēng)險管理都是指可以預(yù)期將要發(fā)生的風(fēng)險，那些不行預(yù)期將要發(fā)生 的風(fēng)險不屬于風(fēng)險管理的范疇。這也將是考驗一個項目管理者的閱歷和學(xué)問對能否 管理好風(fēng)險至關(guān)重要的內(nèi)容。 2、對不行預(yù)期的風(fēng)險，項目管理者要有潛在的風(fēng)險意識評估，做好一些可操作性的預(yù) 案預(yù)備。 3、具體明確的項目方案、以及項目執(zhí)行過程中每個要點的質(zhì)量保證是降低項目風(fēng)險的 必要條件。 4、風(fēng)險報告是項目團(tuán)隊以及領(lǐng)導(dǎo)了解項目風(fēng)險的一個

26、有效手段。 風(fēng)險報告的格式： 序號 風(fēng)險簡介 對項目的影響 解決方案或?qū)Σ?5、團(tuán)隊管理 團(tuán)隊就是一組個體為實現(xiàn)共同的目標(biāo)而相互依靠、一起工作的共同體。 團(tuán)隊工作顧名思 義就是團(tuán)隊成員為實現(xiàn)這個共同的目標(biāo)而付出的共同努力， 項目團(tuán)隊的工作是否有效直接關(guān) 系到 項目的成敗。 團(tuán)隊管理是個漸進(jìn)的過程。世界上只有完善的團(tuán)隊，沒有完善的個人。好的高效的團(tuán)隊 不是管理出來的，而是營造出來的。團(tuán)隊成員需要有大家可認(rèn)同的團(tuán)隊文化，這需要大家共 同的努力。 1、營造良好的工作環(huán)境和氛圍。 2、建設(shè)優(yōu)秀或鮮亮的團(tuán)隊文化。 3、保持高效的溝通。 6、項目會議 組織會議是項目管理者日常工作中一項特別重要的工作任務(wù)，

27、 項目過程中許多重要的決 定都是在會議中做出的，也有許多由于不勝利的會議而對項目本身造成了不好的影響。 首先看看不勝利的會議經(jīng)常表現(xiàn)為哪些形式： 1、會議氛圍不好，參加者發(fā)言不踴躍； 2、會議爭論經(jīng)常偏離主題； 3、會議沒有取得預(yù)期的結(jié)果； 4、會議時間經(jīng)常一拖再拖。 這些不勝利的會議最終的結(jié)果就是：既鋪張了大家的珍貴時間又沒有達(dá)到會議的目的， 許多人都對這樣的會議都有抵觸心情， 對此也是深惡痛絕。 以下是組織會議時應(yīng)當(dāng)留意的問 題，也可看作組織會議的最佳實踐。在列出最佳實踐之前有三點我們必需要清晰： 1、會議是否會取得勝利很大程度上取決于會議的組織者。只有組織得有力，會議才有 可能取得勝利，

28、這是會議勝利的充分條件。 2、會議的組織者和參加者的想法通常是不全都的，有時候甚至?xí)笙鄰酵ァＫ圆灰?盼望會議的參加者和你一樣，對會議有著如此的期盼，對大多數(shù)參加者而言，在會議中他只 是一個發(fā)表想法的人，他不用對會議的勝利擔(dān)當(dāng)責(zé)任。 3、以下十一條最佳實踐是形式上的商定，詳細(xì)的實施可以依據(jù)實際狀況來做。 組織會議的十一條最佳實踐： 1、只有需要開會時才開會。有時候兩三個人單獨小范圍溝通會更加有效。 2、提前發(fā)出會議議程，以便會議參加者知道他們來做什么。 3、請對人很重要，不要把非必要的人召來開會，當(dāng)然也不要漏掉那些關(guān)鍵人物。在確 保必要人物都在的狀況下一次會議參加者越少效果越好。 4、提前預(yù)

29、約參加者的時間，以確保他們能按時到場。 5、會議的開場很重要。會議組織者要在開頭前做好幾件事情。通常我建議有幾點要在 開場時說： A、再一次強調(diào)會議的目標(biāo)，我們來做什么。 B、強調(diào)會議的主題與基調(diào)。比如：本次會議是一個需求確認(rèn)會，而非需求爭論會， 主要是爭論做還是不做以及告知大家我們要做什么， 而不要把太多的精力放在爭論 如何做上面。 C、說明一下會議的規(guī)章。如要發(fā)言，請舉手；不要有小圈子爭論；不要打斷別人 的講 話，等別人說完你再說等等。 6、會議過程中時刻留意引導(dǎo)和掌握會議，以確保會議根據(jù)目 標(biāo)進(jìn)行。一次會議的氛圍 是否良好，爭論是否充分，好的引導(dǎo)至關(guān)重要。比如多提一些開放式的問題。 7、

30、會議記錄很重要，把一些結(jié)論和有價值的內(nèi)容記錄下來，這些是本次會議的重要成 果之一。 8、會議要有結(jié)論。我們常在會議上聽到有人說：大家爭論了這么半天，結(jié)論呢？。 沒有結(jié)論的會議是沒有意義的。 9、會議后別忘發(fā)會議紀(jì)要，以及一些 Action，什么人什么時候做什么。 10、會議后的 action 執(zhí)行狀況的反饋很重要。反饋是對會議參加者的敬重，同時也告知 了會議的效果。 否則會讓大家感覺到這是一個可無可無的會議， 大家以后參加的樂觀性 也會降低。許多會議往往都不留意這一點。 11、按時結(jié)束的會議會受到全部人的歡迎。 7、版本掌握 版本掌握也是項目管理者的一個重要工作內(nèi)容之一， 一個項目或產(chǎn)品的完成

31、不行能是一 步到位的，在項目完成的后期可能會有多個不同的版本的發(fā)布（開發(fā)版本，測試版本，發(fā)布 版本等） 。需要做好版本的管理和掌握。 8、項目總結(jié) 在項目完成后，總結(jié)整個完成項目的過程和經(jīng)受，為下一次的項目啟動供應(yīng)參考閱歷， 完善不足，避開在類似的項目中消失可能存在的相同的錯誤發(fā)生。 第2篇：軟件開發(fā)實施方案 1 軟件開發(fā)實施方案 系統(tǒng)開發(fā)嚴(yán)格根據(jù)軟件工程的方法進(jìn)行組織， 系統(tǒng)的開發(fā)過程按 照需求分析、系統(tǒng)分析與設(shè)計要求、系統(tǒng)編碼、系統(tǒng)測試幾個過程有 序推動。下表所示系統(tǒng)開發(fā)流程圖，采納原型及迭代方式開發(fā)，依據(jù) 用戶需求持續(xù)改進(jìn)，直到最終用戶確認(rèn)滿足。 1.1 開發(fā)流程總述 如下圖示流程定義了

32、我公司內(nèi)部的軟件開發(fā)過程， 以指導(dǎo)和規(guī)范軟件項目中開發(fā)過程的定義和相應(yīng)的實施。 該過程可劃分為一系列子過程，包括：軟件需求分析、設(shè)計、編 碼、測試、驗收、維護(hù)，每個子過程又由一系列任務(wù)和活動組成，如 設(shè)計過程又可分為結(jié)構(gòu)設(shè)計和具體設(shè)計。 但是在實際開發(fā)項目中， 情 況仍舊會是千變?nèi)f化的， 因此我們也并不是一成不變的死板執(zhí)行一個 僵化的工作流程， 我們的原則是在一個規(guī)范流程的指導(dǎo)和約束下， 根 據(jù)詳細(xì)工程項目的實際要求， 為每一個項目評估并制定真正能夠最好 的滿意該項目要求的開發(fā)流程。 開頭 軟件需求分析 Y N：改進(jìn) Y N：改進(jìn) Y N：改進(jìn) 軟件需求規(guī)格說明書（初稿） 系統(tǒng)測試方案系統(tǒng)測試

33、案例 （初稿） 用戶手冊（概要） 追溯表一 軟件需求規(guī)格說明書 系統(tǒng)測試方案系統(tǒng)測試案例 個人評審記錄 評審報告 同行評審 通過 結(jié)構(gòu)設(shè)計 評審?fù)ㄟ^ 結(jié)構(gòu)設(shè)計說明書（初稿） 集成測試方案集成測試案例 （初稿） 用戶手冊（初稿） 追溯表一 結(jié)構(gòu)設(shè)計說明書 集成測試方案集成測試案例 個人評審記錄 評審報告 具體設(shè)計說明書（初稿） 單元測試方案單元測試案例 （初稿） 用戶手冊（修改稿） 追溯表一 具體設(shè)計說明書 單元測試方案單元測試案例 用戶手冊（修改稿） 個人評審記錄 評審報告 源代碼、源代碼文件清單 單元測試報告（經(jīng)過審批） 軟件問題狀態(tài)登記表 軟件問題報告單 集成工作單 集成測試工作單 集成測

34、試報告（經(jīng)過審批） 軟件問題狀態(tài)登記表 軟件問題報告單 集成的軟件系統(tǒng) 系統(tǒng)測試報告（經(jīng)過審批） 軟件問題狀態(tài)登記表 軟件問題報告單 系統(tǒng)管理員使用說明書 ( 經(jīng)過審批) 安裝手冊（經(jīng)過審批） 用戶手冊（經(jīng)過審批 軟件系統(tǒng)（系統(tǒng)測試通過） 驗收測試報告 軟件問題報告單 軟件問題狀態(tài)登記表 驗收報告 可交付產(chǎn)品 軟件需求規(guī)格說明書（升級版） 客戶需求登記表 客戶需求統(tǒng)計表 設(shè)計說明書（升級版） 軟件問題報告單 軟件問題狀態(tài)登記表 軟件維護(hù)實施方案 維護(hù)后的軟件系統(tǒng) 具體設(shè)計 評審?fù)ㄟ^ 編碼 集成測試 系統(tǒng)測試 驗收 維護(hù) 結(jié)束 圖 1.1-1 軟件開發(fā)流程總圖 在應(yīng)用系統(tǒng)軟件開發(fā)項目中， 我們?nèi)?/p>

35、將遵循這一思想， 這一點將在隨后的項目開發(fā)實施方案部分有詳細(xì)的體現(xiàn)， 在這里和下面的相關(guān)章節(jié)中，我們?nèi)詫鷩@個完整的開發(fā)流程來分析說明， 以此來闡明我們對項目開發(fā)的完整過程管理思想和相關(guān)實踐。 下面我們對這個軟件開發(fā)工作流程進(jìn)行簡要地分解說明。 1.2 軟件需求分析 （1）概述 由于應(yīng)用系統(tǒng)與眾多相關(guān)應(yīng)用軟件需要進(jìn)行交互， 因此需要先對這些應(yīng)用系統(tǒng)進(jìn)行分別梳理， 充分做好需求調(diào)研工作， 編寫經(jīng)項目單位認(rèn)可并評審?fù)ㄟ^的系統(tǒng)需求規(guī)格說明書 。 軟件需求分析是根據(jù)項目定義的軟件開發(fā)過程， 依據(jù)系統(tǒng)安排給軟件的需求（見 系統(tǒng)需求規(guī)格說明書），進(jìn)行軟件質(zhì)量特性規(guī)格說明的過程。該過程包括進(jìn)一步明確軟件

36、運行環(huán)境， 明確對軟件的功能、性能和數(shù)據(jù)要求，以及軟件與硬件、軟件與軟件之間的接口要求等，并對軟件需求進(jìn)行驗證和文檔化， 即完成對軟件需求的分析與規(guī)格定義。 本元素在整個過程中的位置如下圖所示： 系統(tǒng)安排給軟 件的需求 軟件需求分析 結(jié)構(gòu)設(shè)計 圖示：軟件需求分析在軟件開發(fā)過程中的位置 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 客戶需求（系統(tǒng)需求規(guī)格 已由 CCB批準(zhǔn)為基線 說明書） 已進(jìn)入配置庫 2）出口準(zhǔn)則 要素 推斷準(zhǔn)則 已經(jīng)過審查 軟件需求規(guī)格說明書 已批準(zhǔn)為基線 已進(jìn)入配置庫 系統(tǒng)測試方案 已經(jīng)過審查 已獲得批準(zhǔn) 系統(tǒng)測試案例 已進(jìn)入配置庫 用戶手冊（概要） 追溯表一 已

37、編寫 已填寫 （3）評審 評審軟件需求規(guī)格說明書 ，詳細(xì)評審過程見評審程序文件，對軟件需求的評審準(zhǔn)則包括： 系統(tǒng)需求和系統(tǒng)設(shè)計的可追溯性； 與系統(tǒng)需求的全都性； 內(nèi)部全都性； 可測試性； 軟件設(shè)計的可行性； 運作和維護(hù)的可行性。 對軟件需求中的問題， 與系統(tǒng)工程組或客戶一起確定和審查， 依據(jù)審查結(jié)果對軟件需求進(jìn)行適當(dāng)?shù)男薷模?必要時按基線變更掌握的要求對客戶需求進(jìn)行相應(yīng)的修改。 對軟件需求規(guī)格說明書進(jìn)行同行評審。 審查、批準(zhǔn)軟件需求規(guī)格說明書。 將軟件需求規(guī)格說明書置于配置管理之下。 （ 4）工作產(chǎn)品 軟件需求規(guī)格說明書 系統(tǒng)測試方案 系統(tǒng)測試案例 用戶手冊 追溯表 （ 5）職責(zé) 項目經(jīng)理：負(fù)

38、責(zé)組建軟件需求分析組；確定是否需要對有關(guān) 人員進(jìn)行培訓(xùn)；負(fù)責(zé)軟件需求規(guī)格說明書的審查和批準(zhǔn)。 軟件需求分析組：軟件需求分析的主要擔(dān)當(dāng)者，負(fù)責(zé)完成本 過程元素要求產(chǎn)生的全部工作產(chǎn)品。 系統(tǒng)測試負(fù)責(zé)人：負(fù)責(zé)組織軟件系統(tǒng)測試組對軟件需求進(jìn)行 分析，審查軟件需求的可測試性；參加軟件需求規(guī)格說明書 的審查和批準(zhǔn)。 質(zhì)量保證人員：參加工作產(chǎn)品的審查，統(tǒng)計缺陷，并對軟件 需求分析過程進(jìn)行審計。 系統(tǒng)開發(fā)組：協(xié)作處理涉及客戶需求的軟件需求問題。 客戶：必要時參加軟件需求規(guī)格說明書的審查和批準(zhǔn)。 1.3 結(jié)構(gòu)設(shè)計 （1）概述 結(jié)構(gòu)設(shè)計是指根據(jù)軟件需求規(guī)格說明書 ，設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)，即模塊結(jié)構(gòu)，定義每個模塊

39、的主要功能和模塊之間的聯(lián)系 （即接口），并確定軟件系統(tǒng)的數(shù)據(jù)體系結(jié)構(gòu)。 本元素在整個過程中的位置如下圖所示： 軟件需求分析 結(jié)構(gòu)設(shè)計 具體設(shè)計 圖示：軟件需求分析在軟件開發(fā)過程中的位置圖 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 軟件需求規(guī)格說明書 經(jīng)過審查 審查獲得批準(zhǔn) 進(jìn)入配置庫 2）出口準(zhǔn)則 要素 結(jié)構(gòu)設(shè)計說明書 集成測試方案 集成測試案例 用戶手冊（初稿） 推斷準(zhǔn)則 經(jīng)過審查 審查獲得批準(zhǔn) 進(jìn)入配置庫 已完善 追溯表一 （ 3）評審 對結(jié)構(gòu)設(shè)計說明書和集成測試方案進(jìn)行同行評審。 對結(jié)構(gòu)設(shè)計中的問題，與軟件需求分析人員一起確定和審查， 并對結(jié)構(gòu)設(shè)計進(jìn)行適當(dāng)?shù)母摹?審查、批

40、準(zhǔn)結(jié)構(gòu)設(shè)計說明書，必要時，對其進(jìn)行設(shè)計評審。 將結(jié)構(gòu)設(shè)計說明書、集成測試方案 和集成測試案例 置于配置管理之下。 （ 4）工作產(chǎn)品 結(jié)構(gòu)設(shè)計說明書 集成測試方案 集成測試案例 用戶手冊 追溯表 （ 5）職責(zé) 1）項目經(jīng)理 負(fù)責(zé)選擇合適的設(shè)計人員，組建結(jié)構(gòu)設(shè)計工作組；負(fù)責(zé)結(jié)構(gòu)設(shè) 計說明書和集成測試方案的審查和批準(zhǔn)。 2）結(jié)構(gòu)設(shè)計人員 結(jié)構(gòu)設(shè)計階段工作的主要擔(dān)當(dāng)者， 負(fù)責(zé)完成本過程元素產(chǎn)生的所 有工作產(chǎn)品。 3）系統(tǒng)分析員 協(xié)作處理涉及軟件需求的問題。 4）系統(tǒng)開發(fā)負(fù)責(zé)人 負(fù)責(zé)組織系統(tǒng)工程組對結(jié)構(gòu)設(shè)計進(jìn)行分析， 審查結(jié)構(gòu)設(shè)計的可測 試性；負(fù)責(zé)協(xié)調(diào)處理涉及軟件需求的問題；參加結(jié)構(gòu)設(shè)計說明書 和集成測

41、試方案的審查和批準(zhǔn)。 5）軟件測試負(fù)責(zé)人 負(fù)責(zé)組織軟件測試組對結(jié)構(gòu)設(shè)計進(jìn)行分析， 審查結(jié)構(gòu)設(shè)計的可測 試性；參加結(jié)構(gòu)設(shè)計說明書和集成測試方案的審查和批準(zhǔn)。 1.4 具體設(shè)計 （1）概述 具體設(shè)計是依據(jù) 結(jié)構(gòu)設(shè)計說明書進(jìn)行模塊設(shè)計，將結(jié)構(gòu)設(shè)計所獲得的模塊根據(jù)單元、程序、規(guī)程的挨次逐步細(xì)化。具體定義各個單元的數(shù)據(jù)結(jié)構(gòu)、程序的實現(xiàn)算法以及程序、單元、模塊之間的接口等，作為以后編碼工作的依據(jù)。 本元素在整個過程中的位置如下圖所示： 結(jié)構(gòu)設(shè)計 具體設(shè)計 編碼 圖示：具體設(shè)計在軟件開發(fā)過程中的位置 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 經(jīng)過審查 審查獲得批準(zhǔn) 結(jié)構(gòu)設(shè)計說明書 進(jìn)入配置庫

42、2）出口準(zhǔn)則 要素 推斷準(zhǔn)則 要素 推斷準(zhǔn)則 經(jīng)過審查 審查獲得批準(zhǔn) 具體設(shè)計說明書 進(jìn)入配置庫 （3）評審 對具體設(shè)計說明書和單元測試方案可進(jìn)行走查或（和） 同行評審； 對具體設(shè)計中的問題， 與結(jié)構(gòu)設(shè)計人員一起確定和審查， 并對具體設(shè)計做出適當(dāng)?shù)母模?審查、批準(zhǔn)具體設(shè)計說明書 ，必要時，對其進(jìn)行設(shè)計評審；將具體設(shè)計說明書和單元測試方案置于配置管理之下。 （ 4）工作產(chǎn)品 具體設(shè)計說明書 單元測試方案 單元測試案例 用戶手冊 追溯表 （ 5）職責(zé) 1）項目經(jīng)理 負(fù)責(zé)選擇合適的設(shè)計人員，組建具體設(shè)計組；負(fù)責(zé)具體設(shè)計說 明書和單元測試方案的審查和批準(zhǔn)。 2）具體設(shè)計人員 具體設(shè)計階段工作的主要擔(dān)

43、當(dāng)者。 負(fù)責(zé)完成本過程元素產(chǎn)生的所 有工作產(chǎn)品。 3）系統(tǒng)分析員 協(xié)作處理涉及軟件需求的問題。 4）系統(tǒng)開發(fā)負(fù)責(zé)人 負(fù)責(zé)組織系統(tǒng)工程組對具體設(shè)計進(jìn)行分析， 審查具體設(shè)計的可測 試性；負(fù)責(zé)協(xié)調(diào)處理涉及軟件需求的問題；參加具體設(shè)計說明書 和單元測試方案的審查和批準(zhǔn)。 5）軟件測試負(fù)責(zé)人 負(fù)責(zé)組織軟件測試組對具體設(shè)計進(jìn)行分析， 審查具體設(shè)計的可測 試性；參加具體設(shè)計說明書和單元測試方案的審查和批準(zhǔn)。 1.5 編碼 （1）概述 編碼階段主要完成的工作是依據(jù)具體設(shè)計說明書編寫程序源代 碼，包括必要的數(shù)據(jù)文件， 并進(jìn)行單元測試，單元測試的內(nèi)容包括模 塊內(nèi)程序的規(guī)律、功能、參數(shù)傳遞、變量引用、出錯處理等方面

44、。 本元素在整個過程中的位置如下圖所示： 具體設(shè)計 編碼 集成測試 圖示：編碼階段在軟件開發(fā)過程中的位置 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 具體設(shè)計說明書 經(jīng)過審查 單元測試方案 獲得批準(zhǔn) 進(jìn)入配置庫 2）出口準(zhǔn)則 要素 推斷準(zhǔn)則 源代碼文件 源代碼文件獲得批準(zhǔn) 源代碼文件清單 源代碼文件進(jìn)入配置庫的源代碼區(qū) 單元測試報告 提交測試負(fù)責(zé)人 軟件問題報告單 提交問題管理渠道 （3）評審 對源代碼文件進(jìn)行同行評審， 主要的方法為對比具體設(shè)計說明書對代碼進(jìn)行查閱，也可依據(jù)編程者的閱歷或程序的難度、重要程度，選擇走查評審方式，但目的都是發(fā)覺程序存在的問題。 （ 4）工作產(chǎn)品 源代

45、碼文件 單元測試報告 軟件問題報告單 軟件問題狀態(tài)登記表 （ 5）職責(zé) 1）項目經(jīng)理 建立編碼組、測試組或相應(yīng)崗位，并進(jìn)行必要的培訓(xùn)；跟蹤進(jìn)度 和問題解決狀態(tài)； 對提交的源代碼進(jìn)行批準(zhǔn) （或指定負(fù)責(zé)人進(jìn)行批準(zhǔn) 工作）。 2）程序員 編寫程序代碼；測試程序代碼；修改程序代碼；提交工作產(chǎn)品， 批準(zhǔn)后將其導(dǎo)入配置區(qū)的源碼庫。 3）單元測試人員 測試源代碼；提交測試報告和軟件問題報告單。 4）評審人員 對指定源代碼文件進(jìn)行閱讀，發(fā)覺缺陷和問題，填寫評審報告。 1.6 模塊集成測試 （1）概述 集成測試階段主要完成的工作是集成和集成測試。 集成是參考結(jié)構(gòu)設(shè)計說明書并依據(jù)具體說明書中規(guī)定的系統(tǒng)集成方案將不

46、同的經(jīng) 測試的程序單元進(jìn)行構(gòu)造， 并逐步構(gòu)造成一個完整的軟件產(chǎn)品的過程；集成測試則是在集成完成之后， 對各單元、模塊之間接口的正確性和集成后功能的正確性進(jìn)行驗證。 對于大型軟件， 集成測試可以實行分步進(jìn)行的方法， 可以先對各子系統(tǒng)進(jìn)行集成測試，然后在子系統(tǒng)之間進(jìn)行集成測試。 本元素在整個過程中的位置如下圖所示： 編碼 集成測試 系統(tǒng)測試 圖示：集成測試在軟件開發(fā)過程中的位置 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 經(jīng)過審查 獲得批準(zhǔn) 進(jìn)入配置庫 結(jié)構(gòu)設(shè)計說明書 具體設(shè)計說明書 集成測試方案 源代碼文件 2）出口準(zhǔn)則 要素 推斷準(zhǔn)則 獲得批準(zhǔn) 進(jìn)入配置庫 提交集成測試負(fù)責(zé)人 已進(jìn)

47、入軟件問題管理流程 集成的軟件系統(tǒng) （完整的源代碼和目標(biāo)代碼） 集成測試報告 軟件問題報告單 （3）審查階段 核查集成狀態(tài)和結(jié)果，并進(jìn)行批準(zhǔn)； 批準(zhǔn)后，將目標(biāo)程序和程序清單進(jìn)入目標(biāo)代碼庫。 （ 4）工作產(chǎn)品 集成后的系統(tǒng)目標(biāo)代碼 （包括文件清單），及相應(yīng)的源代碼 （包括文件清單） 集成測試報告 軟件問題報告單 軟件問題狀態(tài)登記表 集成工作單 集成測試工作單 （5）職責(zé) 項目經(jīng)理：建立集成組、集成測試組或相應(yīng)崗位，并進(jìn)行必 要的培訓(xùn)；跟蹤進(jìn)度和問題解決狀態(tài)；對集成后的系統(tǒng)目標(biāo) 碼進(jìn)行批準(zhǔn)（或指定負(fù)責(zé)人進(jìn)行批準(zhǔn)工作） 。 集成負(fù)責(zé)人員：負(fù)責(zé)集成過程的實施。 集成人員：負(fù)責(zé)環(huán)境構(gòu)建，集成的過程操作，

48、并將集成后的 目標(biāo)代碼提交批準(zhǔn)。 程序員、設(shè)計人員：修改源碼或設(shè)計，解決集成過程中消失 的與源碼有關(guān)的問題。 測試人員：測試系統(tǒng)目標(biāo)碼，將測試報告和軟件問題報告單 提交測試負(fù)責(zé)人。 1.7 系統(tǒng)測試 （1）概述 系統(tǒng)測試的主要任務(wù)是從系統(tǒng)需求的角度對系統(tǒng)運行的正確性和性能進(jìn)行驗證。系統(tǒng)測試的依據(jù)為系統(tǒng)測試方案。 本元素在整個過程中的位置如下圖所示： 集成測試 系統(tǒng)測試 驗收 圖示：系統(tǒng)測試在軟件開發(fā)過程中的位置 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 經(jīng)過審查 系統(tǒng)需求 要素 推斷準(zhǔn)則 獲得批準(zhǔn) 進(jìn)入配置庫 編寫完成 系統(tǒng)的目標(biāo)代碼 系統(tǒng)測試方案 用戶手冊 2）出口準(zhǔn)則 要素

49、推斷準(zhǔn)則 獲得批準(zhǔn) 系統(tǒng)測試報告 軟件問題報告單 （ 3）工作產(chǎn)品 系統(tǒng)測試報告 軟件問題報告單 軟件問題狀態(tài)登記表 （ 4）職責(zé) 項目經(jīng)理：負(fù)責(zé)建立系統(tǒng)測試組或相關(guān)的崗位，并進(jìn)行必要 的培訓(xùn)；跟蹤進(jìn)度和問題解決狀態(tài)；對最終的目標(biāo)代碼進(jìn)行 批準(zhǔn)（或指定負(fù)責(zé)人進(jìn)行批準(zhǔn)工作） 。 程序員、設(shè)計人員：修改源碼或設(shè)計，解決集成過程中消失 的與源碼有關(guān)的問題。 測試人員：測試系統(tǒng)目標(biāo)碼，將測試報告提交測試負(fù)責(zé)人， 將軟件問題報告單提交問題管理渠道。 1.8 驗收 （1）概述 驗收階段主要由驗收測試、驗收測試問題改正和驗收三部分組成： 驗收測試的主要目的是驗證所開發(fā)的系統(tǒng)在用戶的使用環(huán)境下 （或模擬的使用

50、環(huán)境下） 是否滿意系統(tǒng)需求， 從用戶的角度驗證整個 系統(tǒng)運行的正確性。 驗收測試問題改正是對驗收測試中發(fā)覺的差異性問題進(jìn)行修改。 驗收則是在驗收測試的基礎(chǔ)上， 依據(jù)項目合同或項目任務(wù)書對項 目的完成狀況進(jìn)行綜合評價。 本元素在整個過程中的位置如下圖所示： 系統(tǒng)測試 驗收 維護(hù) 圖示：驗收在軟件開發(fā)過程中的位置 驗收的三個組成部分視項目立項類型和客戶的要求選擇執(zhí)行。 （2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 驗收測試前完成評審。 驗收測試方案（有驗收測試要求 的項目） 測試（系統(tǒng)測試、集成測試、單 已完成 元測試） 2）出口準(zhǔn)則 要素 推斷準(zhǔn)則 已提交 已關(guān)閉 已提交 驗收測試報告

51、 驗收測試問題報告單 驗收報告 （3）工作產(chǎn)品 驗收測試報告 軟件問題報告單 軟件問題狀態(tài)登記表 驗收報告 可交付產(chǎn)品 （ 4）職責(zé) 驗收測試組：負(fù)責(zé)驗收測試的各項活動。 開發(fā)組人員：負(fù)責(zé)驗收測試中發(fā)覺問題的改正和測試幫助。 項目管理人員：負(fù)責(zé)指派驗收測試責(zé)任和完成測試規(guī)程；確 保測試質(zhì)量和進(jìn)程；確保組間協(xié)調(diào)。 驗收組：詳細(xì)進(jìn)行驗收。 CCB：批準(zhǔn)運行基線。 1.9 維護(hù) （1）概述 維護(hù)期是指： 軟件產(chǎn)品 / 系統(tǒng)驗收后，進(jìn)入軟件運行 / 系統(tǒng)維護(hù)階段，直至軟件產(chǎn)品下一個版本的發(fā)布或系統(tǒng)維護(hù)期終止； 本元素在整個軟件開發(fā)過程中的位置如下圖所示： 驗收 維護(hù) 圖示：維護(hù)在軟件開發(fā)過程中的位置

52、（2）入口準(zhǔn)則和出口準(zhǔn)則 1）入口準(zhǔn)則 要素 推斷準(zhǔn)則 軟件產(chǎn)品 / 系統(tǒng) 已驗收 2）出口準(zhǔn)則 要素 推斷準(zhǔn)則 軟件產(chǎn)品 已退役 合同商定的維護(hù)期限 已到期 合同商定的維護(hù)范圍 已超出，須另簽協(xié)議 （3）工作產(chǎn)品 軟件需求規(guī)格說明書 客戶需求登記表 客戶需求統(tǒng)計表 設(shè)計說明書 軟件問題報告單 軟件問題狀態(tài)登記表 軟件維護(hù)實施方案 維護(hù)后的軟件系統(tǒng) （4）職責(zé) 維護(hù)負(fù)責(zé)人：制定軟件維護(hù)實施方案， 確認(rèn)維護(hù)類型、需求范圍，安排維護(hù)任務(wù)，追蹤任務(wù)的完成狀況及其他項目管理工作。 軟件維護(hù)人員：負(fù)責(zé)進(jìn)行軟件維護(hù)任務(wù)的執(zhí)行。 QA人員：負(fù)責(zé)幫助維護(hù)負(fù)責(zé)人依據(jù)實際狀況剪裁標(biāo)準(zhǔn)流程。 第3篇：軟件項目實施方

53、案 b 2.8 項目實施 2.8.1 項目實施概況 依據(jù)項目建設(shè)要求，對中山農(nóng)情統(tǒng)計分析系統(tǒng)進(jìn)行整體規(guī)劃設(shè)計更新維護(hù)， 對系統(tǒng)運行的平安性、牢靠性、易用性以及穩(wěn)健性進(jìn)行全新設(shè)計， 并將全部的應(yīng) 用系統(tǒng)進(jìn)行部署實施和軟件使用培訓(xùn)以及技術(shù)支持。項目組承諾項目自立完成， 不轉(zhuǎn)包外包。 2.8.1.1 項目實施管理原則 項目開發(fā)維護(hù)的實施中，嚴(yán)格根據(jù) ISO9001 國際質(zhì)量體系進(jìn)行掌握，保證為用戶供應(yīng)優(yōu)質(zhì)的產(chǎn)品、嚴(yán)密的工程實施、高效的服務(wù)支持。為此，要遵循下列工程實施管理原則和保證體系。 （1）有閱歷、成熟的技術(shù)隊伍是工程實施的前提條件 完成任何項目工程，必需擁有一支有閱歷的、勇于探究的、高水平的、

54、具有嚴(yán)謹(jǐn)工作作風(fēng)的技術(shù)隊伍， 在工程實施的過程中發(fā)揮團(tuán)隊協(xié)作精神和用戶親密協(xié)作的力量。 （2）管理層次分明、職責(zé)清楚是工程實施的基礎(chǔ) 建立層次分明的項目工程實施管理機構(gòu)， 明晰各層的管理職責(zé)， 從組織管理的角度保證項目實施方案落到實處。 （3）確定過程掌握點，以過程質(zhì)量保證整體工程質(zhì)量 整體都是由局部和詳細(xì)的細(xì)節(jié)構(gòu)成， 項目由一個個過程環(huán)節(jié)組成， 只有仔細(xì)對待每一個過程細(xì)節(jié)，才能保證項目工程整體的實施質(zhì)量。 （4）用戶參加是項目工程勝利的保證 從項目開頭到項目的結(jié)束， 每個階段都強調(diào)用戶的參加。 開發(fā)商只有和用戶相結(jié)合才能使開發(fā)出的系統(tǒng)為用戶所用， 發(fā)揮出系統(tǒng)的最大效益， 而用戶的參加也是系統(tǒng)

55、順當(dāng)進(jìn)行的保證。 對本項目短時間、大范圍的配置安裝來說， 假如有用戶的高度參加，項目工程的實施將大大加快。 b b 2.8.1.2 項目組織結(jié)構(gòu) 本項目是一項涉及面廣、影響大、平安運行要求高，集數(shù)據(jù)處理、信息發(fā)布、資源整合于一體的政府信息化項目。為了更好的執(zhí)行該項目，將實行統(tǒng)一指揮、并行實施、相互支援的實施方法。 為了使該項目能順當(dāng)實施， 便于項目的管理和協(xié)調(diào)， 使工作職責(zé)更加清楚明白，建立項目組織實施小組，建立由項目領(lǐng)導(dǎo)小組、項目管理辦公室、項目監(jiān)理公司、顧問詢問組、項目經(jīng)理、項目詳細(xì)實施小組組成的實施管理掌握組織體系。 項目實施組織詳細(xì)職責(zé)如下： （1）項目領(lǐng)導(dǎo)小組 負(fù)責(zé)項目實施過程中的重

56、大大事決策； 依據(jù)項目的進(jìn)度、質(zhì)量、技術(shù)、資源、風(fēng)險等實行宏觀監(jiān)控； 負(fù)責(zé)組建驗收小組，主持驗收工作； 協(xié)調(diào)參加項目各方的工作關(guān)系。 （2）項目管理辦公室 組織各方統(tǒng)一制定工程管理方案； 組織總體實施方案評審，組織測試驗收； 負(fù)責(zé)項目進(jìn)度方案與成本掌握； 協(xié)調(diào)解決項目實施過程中消失的各種問題。 （3）顧問詢問組 1）人員組成 農(nóng)業(yè)信息化相關(guān)領(lǐng)域的業(yè)務(wù)專家； 多年從事 IT 行業(yè)和展廳建設(shè)的信息技術(shù)專家。 2）主要職責(zé) 系統(tǒng)總體設(shè)計指導(dǎo)； 對各子系統(tǒng)深化設(shè)計進(jìn)行審核并提出優(yōu)化建議； 對各子系統(tǒng)進(jìn)行技術(shù)協(xié)調(diào)； 幫助客戶對系統(tǒng)的設(shè)備配置予以確認(rèn)； 對現(xiàn)場系統(tǒng)安裝、調(diào)試供應(yīng)必要的技術(shù)支持服務(wù)； 工程文

57、檔審核。 b b （4）項目經(jīng)理 1)人員組成 項目經(jīng)理由具有豐富項目管理閱歷的高級工程師擔(dān)當(dāng)。 2）主要職責(zé) 制定項目方案：牽頭制定項目方案。 項目執(zhí)行：對總體方案設(shè)計及工程設(shè)計；配置確認(rèn)；工程質(zhì)量保證；系統(tǒng)設(shè)計、開發(fā)、測試、安裝及調(diào)試；系統(tǒng)培訓(xùn)、驗收。 項目檢查：通過其下屬各工作組供應(yīng)的工程進(jìn)展匯報，將項目進(jìn)展?fàn)顟B(tài)與項目方案進(jìn)度進(jìn)行比較，發(fā)覺過程誤差，提出整改措施。 項目掌握：審核項目進(jìn)展?fàn)顟B(tài)，必要時調(diào)集各種備用資源，確保項目按方案進(jìn)度實施。 項目協(xié)調(diào)：與客戶、各分系統(tǒng)建設(shè)部門進(jìn)行協(xié)調(diào)，解決工程組織接口及技術(shù)接口問題；定期主持系統(tǒng)建設(shè)協(xié)調(diào)會，準(zhǔn)時解決各系統(tǒng)間消失的相關(guān)問題。 項目匯報：定期

58、向項目選購單位匯報整個項目的進(jìn)展?fàn)顩r，匯報在系統(tǒng)建設(shè)過程中消失的重大問題，聽取指導(dǎo)和建議。 （5）總體方案組 1）人員組成 由從事過多名基層電子政務(wù)項目的系統(tǒng)架構(gòu)師、系統(tǒng)分析員和需求分析工程 師組成。 2）主要職責(zé) 對項目經(jīng)理負(fù)責(zé)； 進(jìn)行系統(tǒng)的需求分析調(diào)研； 負(fù)責(zé)系統(tǒng)的總體設(shè)計； 策劃系統(tǒng)的模塊功能結(jié)構(gòu)； 協(xié)作業(yè)主方進(jìn)行系統(tǒng)驗收。 （6）軟件開發(fā)組 對業(yè)主需求分析進(jìn)行全面細(xì)致的了解或確認(rèn)，深化描述軟件的功能和性能， 劃分系統(tǒng)的軟件功能需求和硬件功能需求， 確定軟件同其它系統(tǒng)元素的接口細(xì)節(jié)， b b 并與客戶一起爭論打算系統(tǒng)驗收方案。 1）人員組成 高級程序員； 具有豐富產(chǎn)品開發(fā)閱歷的產(chǎn)品開發(fā)設(shè)

59、計人員。 2）主要職責(zé) 負(fù)責(zé)項目應(yīng)用軟件的系統(tǒng)設(shè)計； 負(fù)責(zé)項目應(yīng)用軟件的程序編碼； 負(fù)責(zé)項目應(yīng)用軟件的運行調(diào)試； 協(xié)作業(yè)主方進(jìn)行系統(tǒng)驗收。 （7）系統(tǒng)測試組 從使用者的角度完成系統(tǒng)操作步驟的設(shè)計， 在實施過程中監(jiān)控測試系統(tǒng)是否達(dá)到最初制定的操作目標(biāo)，并編寫業(yè)主操作手冊。檢驗系統(tǒng)開發(fā)質(zhì)量，并進(jìn)行功能測試。 當(dāng)開頭試運行階段后，還要對項目的各個方面指標(biāo)進(jìn)行測試和評估。 （8）系統(tǒng)實施組 1）人員組成 由具有豐富閱歷的系統(tǒng)工程師和參與系統(tǒng)開發(fā)的軟件工程師組成。 2）主要職責(zé) 負(fù)責(zé)各個實施區(qū)域的實施方案的設(shè)計與建議； 組織系統(tǒng)安裝及調(diào)試； 負(fù)責(zé)系統(tǒng)配置修改，安裝技術(shù)支持； 2.8.1.3 項目團(tuán)隊 依

60、據(jù)上述項目組織結(jié)構(gòu)和職能分解， 北京派得偉業(yè)科技進(jìn)展有限公司方案投 入高級顧問 1 人，項目經(jīng)理 2 人、技術(shù)負(fù)責(zé)人 1 人、實施經(jīng)理 1 人、系統(tǒng)設(shè)計組 4 人、軟件開發(fā)組 13 人、系統(tǒng)測試組 3 人、系統(tǒng)實施組 3 人。共計 28 人。形成 特地服務(wù)本項目的技術(shù)開發(fā)實施隊伍。 隨著開發(fā)層次的深化、開發(fā)量的增加， 北 京派得偉業(yè)科技進(jìn)展有限公司投入的人力資源將隨之增加和不斷進(jìn)行調(diào)整。 未經(jīng) 招標(biāo)人同意，項目總負(fù)責(zé)人及各分項目負(fù)責(zé)人在項目結(jié)束前不得變更。 b b 詳細(xì)人員組成安排狀況分別如下表所示： 表 1.項目實施人員一覽表 序號 本項目職責(zé) 姓名 職務(wù) 公司副總、農(nóng)業(yè)生產(chǎn) 本項目詳細(xì)分工