為了確保事情或工作有序有效開(kāi)展,,通常需要提前準(zhǔn)備好一份方案,方案屬于計(jì)劃類文書的一種,。大家想知道怎么樣才能寫一篇比較優(yōu)質(zhì)的方案嗎,?下面是小編為大家收集的方案策劃范文,供大家參考借鑒,,希望可以幫助到有需要的朋友,。
軟件開(kāi)發(fā)項(xiàng)目實(shí)施方案篇一
作為一個(gè)項(xiàng)目管理者,如何要成功的做好項(xiàng)目管理;首先必須先要明白的是在特定的領(lǐng)域中賦予這個(gè)角色所要實(shí)現(xiàn)的目標(biāo)、承擔(dān)的職責(zé),、以及項(xiàng)目管理者的具體工作內(nèi)容是什么? 從我個(gè)人的淺見(jiàn)和角度以及我們所從事的it領(lǐng)域來(lái)分析回答以上三個(gè)問(wèn)題,。第一:目標(biāo)
作為一個(gè)項(xiàng)目的管理者,必須要明確的知道自己的工作目標(biāo);我個(gè)人認(rèn)為項(xiàng)目管理者的目標(biāo)無(wú)非就是以下兩點(diǎn):
1、就是清晰明確地了解項(xiàng)目利害關(guān)系者的需求和期望,努力做到滿足項(xiàng)目利害關(guān)系者的不同需求;項(xiàng)目利害關(guān)系者包括:項(xiàng)目團(tuán)隊(duì)成員和項(xiàng)目團(tuán)隊(duì)外成員(比如各部門的部門負(fù)責(zé)人和市場(chǎng)人員,客戶等,。
2,、就是保證開(kāi)發(fā)項(xiàng)目按需按時(shí)保質(zhì)的完成。 第二:職責(zé)
作為項(xiàng)目的管理者,首先要端正態(tài)度,要明確知道自己的工作職責(zé),認(rèn)識(shí)到這份工作職責(zé)的本質(zhì),。項(xiàng)目管理者不是來(lái)管人的,而是來(lái)支持人的,是來(lái)協(xié)調(diào)資源的,是來(lái)營(yíng)造一個(gè)適合團(tuán)隊(duì)成員比較認(rèn)同的工作環(huán)境和氛圍的,是來(lái)為一個(gè)共同的目標(biāo)和大家一起戰(zhàn)斗共同成長(zhǎng)的,。可以大概概括成以下幾點(diǎn):
1,、建立有效的工作流程保證項(xiàng)目的順利進(jìn)行,。
2、制定詳細(xì)周密的項(xiàng)目計(jì)劃,。
3,、跟蹤,推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行。
4,、積極解決項(xiàng)目過(guò)程中出現(xiàn)的問(wèn)題和沖突,。
5、調(diào)動(dòng)開(kāi)發(fā)團(tuán)隊(duì)的積極性,創(chuàng)造力,推動(dòng)團(tuán)隊(duì)成員在項(xiàng)目過(guò)程中不斷成長(zhǎng),。
6,、項(xiàng)目風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)評(píng)估,、風(fēng)險(xiǎn)解決和風(fēng)險(xiǎn)管理策略以及做好突發(fā)風(fēng)險(xiǎn)的應(yīng)急預(yù)案,。
7、實(shí)現(xiàn)目標(biāo)
第三:項(xiàng)目管理者的具體工作內(nèi)容
最后一個(gè)是項(xiàng)目管理者的具體工作內(nèi)容,作為項(xiàng)目管理者必須清晰的知道自己的工作范圍和所要做的工作內(nèi)容以及工作重心,分為以下六點(diǎn):
1,、項(xiàng)目前期階段
對(duì)項(xiàng)目進(jìn)行技術(shù)可行性分析,、技術(shù)評(píng)估、成本評(píng)估以及風(fēng)險(xiǎn)評(píng)估,。與需求提出方的代表進(jìn)行需求討論,明確項(xiàng)目的目標(biāo),、價(jià)值;確定項(xiàng)目范圍,、功能及優(yōu)先級(jí)。組建項(xiàng)目團(tuán)隊(duì),特別要搞清楚項(xiàng)目的key person(對(duì)產(chǎn)品有決定權(quán)的人,。項(xiàng)目啟動(dòng)會(huì)議,相關(guān)的利害關(guān)系人員都必須參加,。
該階段完成后的成果:確認(rèn)后的最終軟件需求規(guī)格說(shuō)明書文檔。
2,、分析設(shè)計(jì)階段
根據(jù)確認(rèn)后的軟件需求規(guī)格說(shuō)明書,制定項(xiàng)目進(jìn)度計(jì)劃,工作任務(wù)分解(wbs;資源申請(qǐng),項(xiàng)目涉及到的開(kāi)發(fā)資源,、測(cè)試資源、設(shè)計(jì)資源(包括人員和軟硬件資源;數(shù)據(jù)庫(kù)設(shè)計(jì);系統(tǒng)設(shè)計(jì);文檔(包括use case,、demo系統(tǒng)原型,、test case等;評(píng)審會(huì)議。
該階段完成后的成果: a,、user case(系統(tǒng)用例;b,、demo(系統(tǒng)原型;
c、系統(tǒng)設(shè)計(jì)文檔(概要設(shè)計(jì)和詳細(xì)設(shè)計(jì);d,、數(shù)據(jù)庫(kù)設(shè)計(jì)文檔,。
最后對(duì)完成的成果,包括user case和設(shè)計(jì)文檔等進(jìn)行評(píng)審。
3,、執(zhí)行階段(開(kāi)發(fā)和測(cè)試
準(zhǔn)備開(kāi)發(fā)環(huán)境,、測(cè)試環(huán)境;跟蹤,推動(dòng)項(xiàng)目按計(jì)劃進(jìn)行;以周報(bào)的形式通報(bào)項(xiàng)目的進(jìn)展情況。對(duì)項(xiàng)目的階段成果進(jìn)行評(píng)估,以確保該階段完成的質(zhì)量,包括代碼審核,、sql 審核等,。對(duì)需求變更進(jìn)行控制管理;對(duì)項(xiàng)目風(fēng)險(xiǎn)進(jìn)行管理;測(cè)試階段bug fixed及改進(jìn)、收集反饋意見(jiàn),。
4,、發(fā)布階段
包括制定項(xiàng)目發(fā)布計(jì)劃,用戶培訓(xùn),發(fā)布上線。
5,、上線后監(jiān)控
數(shù)據(jù)監(jiān)控(日志,、服務(wù)器狀態(tài),根據(jù)監(jiān)控出現(xiàn)的問(wèn)題,及時(shí)進(jìn)行bug fixed及改進(jìn)或做補(bǔ)丁升級(jí)。
6,、結(jié)束階段
產(chǎn)品交付,項(xiàng)目
總結(jié)
會(huì),。第四:基于以上三個(gè)問(wèn)題所做的應(yīng)對(duì)細(xì)則
要做好項(xiàng)目管理,并能確實(shí)解決好以上三個(gè)問(wèn)題,實(shí)現(xiàn)目標(biāo)、履行職責(zé),、完成工作中的具體內(nèi)容,從我個(gè)人這幾年的工作經(jīng)驗(yàn)和面臨的一些問(wèn)題,還有所積累的一些項(xiàng)目管理中的一些知識(shí)以及自己的觀察和思考的角度看,應(yīng)該要努力做好以下這幾個(gè)方面的具體工作:
1,、項(xiàng)目開(kāi)發(fā)時(shí)間的估算
制定項(xiàng)目進(jìn)度時(shí)間表的時(shí)候,需要估算每個(gè)任務(wù)所需的時(shí)間,其中開(kāi)發(fā)任務(wù)中模塊的分配和時(shí)間估算是其中最主要的部分;在分配模塊和估算開(kāi)發(fā)時(shí)間時(shí)需要遵循的原則和目標(biāo):
1、保證項(xiàng)目整體的進(jìn)度,。
2,、有助于確保開(kāi)發(fā)編碼的質(zhì)量。
3,、有助于提高開(kāi)發(fā)編碼的速度,。
在公司現(xiàn)有的技術(shù)框架下,開(kāi)發(fā)人員主要的工作是投入在具體的商業(yè)邏輯上。通常每個(gè)模塊所需的開(kāi)發(fā)時(shí)間取決于以下三個(gè)因素:
1,、所負(fù)責(zé)模塊的商業(yè)邏輯的復(fù)雜程度,。
2、開(kāi)發(fā)人員的技術(shù)水平和對(duì)項(xiàng)目所在應(yīng)用的熟悉程度(包括對(duì)框架和應(yīng)用的熟悉程度,。
3,、該模塊技術(shù)實(shí)現(xiàn)上是否有技術(shù)難點(diǎn);這里所謂的技術(shù)難點(diǎn)定義是:在現(xiàn)有系統(tǒng)中還未實(shí)現(xiàn)的、開(kāi)發(fā)人員自身也未沒(méi)接觸過(guò)的技術(shù),。對(duì)于這樣的難點(diǎn),開(kāi)發(fā)者沒(méi)有相關(guān)的代碼可以參考,自己也沒(méi)有經(jīng)驗(yàn),所以需要投入一些時(shí)間研究解決,。
模塊分配和開(kāi)發(fā)時(shí)間估算的步驟:
1、在劃分好模塊后,首先自己先估算一下每個(gè)模塊所需要的開(kāi)發(fā)時(shí)間,。
2,、然后召集所有開(kāi)發(fā)人員,討論模塊的分配和開(kāi)發(fā)時(shí)間估算。將劃分好的模塊,讓開(kāi)發(fā)人員從中挑選他們感興趣的模塊,。這樣做可以提高開(kāi)發(fā)人員的主動(dòng)性和參與性,。在分配模塊的時(shí)候還需從以下幾方面考慮,以確保開(kāi)發(fā)的速度和質(zhì)量: a、相同類似的模塊由同一人負(fù)責(zé)開(kāi)發(fā),比如用戶管理的增刪改由同一開(kāi)發(fā)者負(fù)責(zé),。
這樣做的好處就是開(kāi)發(fā)者對(duì)相關(guān)邏輯會(huì)更加熟悉,同時(shí)接口的定義也會(huì)比較明確,溝通的成本比較低,同時(shí)功能實(shí)現(xiàn)的缺陷也相應(yīng)的會(huì)降低,。
b、技術(shù)難度比較大的模塊由技術(shù)水平比較高的人負(fù)責(zé),。c,、業(yè)務(wù)邏輯比較復(fù)雜的由對(duì)這塊邏輯比較了解的人負(fù)責(zé)。
3,、模塊分配完后,開(kāi)發(fā)人員評(píng)估自己負(fù)責(zé)開(kāi)發(fā)的模塊所需要的時(shí)間,。在此過(guò)程中最好做到要和開(kāi)發(fā)者比較詳細(xì)的討論每個(gè)模塊的技術(shù)實(shí)現(xiàn),以便使時(shí)間的估算更加準(zhǔn)確。
4,、對(duì)開(kāi)發(fā)人員估算的時(shí)間進(jìn)行確認(rèn),。在確認(rèn)過(guò)程中作為項(xiàng)目管理者應(yīng)參考以上提到的三個(gè)因素,同時(shí)將自己估算的時(shí)間和開(kāi)發(fā)人員估算的時(shí)間進(jìn)行比較。這其中的差異當(dāng)然會(huì)存在的,。對(duì)于那些差異比較大的,將與技術(shù)人員探討其中的緣由,。對(duì)于時(shí)間周期比較長(zhǎng)的任務(wù),盡量將任務(wù)通過(guò)再細(xì)分的手段細(xì)化任務(wù),爭(zhēng)取每個(gè)任務(wù)的最長(zhǎng)時(shí)間不超過(guò)3天;時(shí)間周期越長(zhǎng)的任務(wù),不確定性越高,風(fēng)險(xiǎn)也越高,越有可能成為項(xiàng)目的瓶頸,影響項(xiàng)目的進(jìn)度。
2,、code review code review是保證項(xiàng)目中代碼質(zhì)量非常重要的一個(gè)環(huán)節(jié),在這一環(huán)中我們公司做的非常欠缺,把關(guān)不嚴(yán)格;這是導(dǎo)致每次測(cè)試后出現(xiàn)大量bug的主要原因,這一環(huán)需要納入績(jī)效考核中,實(shí)行責(zé)任追究制,實(shí)施重點(diǎn)監(jiān)控,。出現(xiàn)這樣的薄弱環(huán)節(jié),造成這樣的原因,我想也是有很多因素造成的;比如開(kāi)發(fā)人員對(duì)需求不是很明確,以自己比較主觀的因素去完成任務(wù)的;還有對(duì)整個(gè)系統(tǒng)業(yè)務(wù)邏輯沒(méi)有正確的清晰的認(rèn)識(shí)的原因,以及對(duì)項(xiàng)目組成員培訓(xùn)不到位的原因等眾多因素糾集在一起才產(chǎn)生的。
如何做好這方面的工作?首先編碼要有“編碼規(guī)范”文檔,code review要有“代碼審
核規(guī)范”文檔:記錄代碼實(shí)現(xiàn)應(yīng)該遵循的標(biāo)準(zhǔn),。通過(guò)這兩個(gè)文檔來(lái)規(guī)范開(kāi)發(fā)人員的代碼實(shí)現(xiàn),代碼編寫者必須要嚴(yán)格按照規(guī)范來(lái)進(jìn)行;代碼審核者根據(jù)這些標(biāo)準(zhǔn)來(lái)code review代碼,同時(shí)在code review過(guò)程中不斷完善該文檔,。
在做好這些前期工作的前提下,分以下幾個(gè)步驟來(lái)實(shí)施:
1、檢查開(kāi)發(fā)者的代碼實(shí)現(xiàn)是否遵循了編碼規(guī)范,。
2,、從代碼的易維護(hù)性,、可擴(kuò)展性角度考察代碼的質(zhì)量,提出修改建議。
3,、代碼編寫者和代碼審核者坐在一起,由代碼編寫者按照use case依次講解自己負(fù)責(zé)的代碼和相關(guān)邏輯,從web層-到manage層再到dao層;
4,、代碼審核者在此過(guò)程中可以隨時(shí)提出自己的疑問(wèn),同時(shí)積極發(fā)現(xiàn)隱藏的bug;對(duì)這
些bug記錄在案。
5,、代碼講解完畢后,代碼審核者給自己安排幾個(gè)小時(shí)再對(duì)代碼審核一遍,。代碼需要一
行一行靜下心來(lái)看。同時(shí)代碼又要全面的看,以確保代碼整體上設(shè)計(jì)優(yōu)良,。
6,、代碼審核者根據(jù)審核的結(jié)果編寫“代碼審核報(bào)告”,“審核報(bào)告”中記錄發(fā)現(xiàn)的問(wèn)題
及修改建議,然后把“審核報(bào)告”發(fā)送給相關(guān)人員。
7,、代碼編寫者根據(jù)“代碼審核報(bào)告”給出的修改意見(jiàn),修改好代碼,有不清楚的地方
可積極向代碼審核者提出,。
8、代碼編寫者bug fixed完畢之后給出反饋,。
9,、代碼審核者把code review中發(fā)現(xiàn)的有價(jià)值的問(wèn)題更新到"代碼審核規(guī)范"的文檔中, 對(duì)于特別值得提醒的問(wèn)題可群發(fā)email給所有技術(shù)人員。如果通過(guò)以上步驟,還因?yàn)槭谴a編寫者的原因而出現(xiàn)嚴(yán)重的缺陷問(wèn)題,將通過(guò)績(jī)效考核來(lái)加深代碼編寫者的印象,并在周報(bào)會(huì)議上做通報(bào)批評(píng),。
3,、需求變更管理
需求變更管理也是項(xiàng)目管理中最重要的一個(gè)環(huán)節(jié),對(duì)需求變更管理的有效性將直接影響項(xiàng)目的成功與否。
對(duì)待需求變更的態(tài)度:
1,、需求變更是不可避免的,。
2、需求變更要必須被管理,。
3,、積極發(fā)現(xiàn)引起變更的因素,促使變更盡可能早的出現(xiàn),減低變更帶來(lái)的風(fēng)險(xiǎn)。 需求變更管理的目標(biāo):
1,、相關(guān)的干系人必須清楚地了解發(fā)生的變更,。
2、變更處于有效的管理中,。
3,、盡量降低變更帶來(lái)的風(fēng)險(xiǎn)。
通過(guò)制定需求變更的流程,確保項(xiàng)目中的需求變更有效地進(jìn)行,實(shí)現(xiàn)上述的目標(biāo),。需求變更流程:
1,、確定需求的基準(zhǔn)線。將以u(píng)ser case作為需求基準(zhǔn)線,在user case確認(rèn)之后的任何需求改變,都需要走需求變更流程,這一環(huán)節(jié)我們基本沒(méi)有,期間有時(shí)候使的工
作很混亂,也就是因?yàn)闆](méi)有一個(gè)規(guī)范的變更流程而造成的;如果建立了這么一個(gè)流程規(guī)范和機(jī)制,需求變更沒(méi)有走這個(gè)流程的將不被認(rèn)可,。
2,、項(xiàng)目管理者接收到需求變更的要求。需求變更的提出者可以是項(xiàng)目中的任何人包括產(chǎn)品經(jīng)理,、市場(chǎng)人員,、開(kāi)發(fā)人員,、測(cè)試人員等。
3,、項(xiàng)目管理者評(píng)估該需求變更,。針對(duì)接收到的需求變更的要求,召集相關(guān)人員討論該需求變更的合理性、可行性,實(shí)施的代價(jià)以及對(duì)項(xiàng)目的影響,。包括可能影響的項(xiàng)目范圍,進(jìn)
度,費(fèi)用,質(zhì)量等計(jì)劃。項(xiàng)目管理者作為項(xiàng)目的負(fù)責(zé)人,對(duì)項(xiàng)目的成功與否負(fù)有主要的責(zé)任,。所以需求變更的決策者應(yīng)該由項(xiàng)目管理者承擔(dān),。
4、需求變更確認(rèn)后由專人將需求變更記錄下來(lái),通知給項(xiàng)目中所有成員,。其中以下人員對(duì)需求的變更是緊密相關(guān)的,他們必須知曉并認(rèn)可此需求變更,。包括(客戶方,需求分析人員,測(cè)試人員,相關(guān)開(kāi)發(fā)人員。需求變更記錄格式如下: 序號(hào)變更提出時(shí)間變更描述變更類型(是 對(duì)原有需求 的修改還是 新增需求 原因變更提出 者
開(kāi)發(fā)人員對(duì)進(jìn)度的 影響(工 作量
1 2
5,、確定變更的負(fù)責(zé)人,。承擔(dān)需求變更的具體工作,比如基線控制,對(duì)需求變更的記錄,并通知相關(guān)人員。
6,、相關(guān)人員接收到確認(rèn)的需求變更后,做以下事情,。需求分析人員修改需求說(shuō)明書和user case的相關(guān)內(nèi)容。測(cè)試人員修改測(cè)試用例的相關(guān)內(nèi)容,。開(kāi)發(fā)人員修改代碼中的相關(guān)部分,。
7、按照變更后的計(jì)劃實(shí)施項(xiàng)目,并進(jìn)行檢查,跟蹤,對(duì)變更后的實(shí)施反饋和可能出現(xiàn)的問(wèn)題及時(shí)溝通和處理,。
8,、需求凍結(jié)。項(xiàng)目越到后期,需求變更對(duì)項(xiàng)目的影響就越大,所以在一定時(shí)候要進(jìn)入需求凍結(jié)階段,不再接收新需求或需求的變更,。
4,、風(fēng)險(xiǎn)管理
風(fēng)險(xiǎn)管理是項(xiàng)目管理者最重要的工作之一。風(fēng)險(xiǎn)管理是一個(gè)持續(xù)的過(guò)程,貫穿于整個(gè)項(xiàng)目過(guò)程中,風(fēng)險(xiǎn)管理包括風(fēng)險(xiǎn)識(shí)別,、風(fēng)險(xiǎn)評(píng)估,、風(fēng)險(xiǎn)解決以及風(fēng)險(xiǎn)管理策略。
在項(xiàng)目的實(shí)施過(guò)程中需要不斷地識(shí)別和應(yīng)對(duì)風(fēng)險(xiǎn),并加以有效的控制,風(fēng)險(xiǎn)管理的好與壞直接影響項(xiàng)目的實(shí)施效果,從某種意義上講,項(xiàng)目實(shí)施對(duì)于項(xiàng)目管理者就是識(shí)別,、分析,、應(yīng)對(duì)、控制風(fēng)險(xiǎn)的過(guò)程,使項(xiàng)目的約束性目標(biāo)和質(zhì)量目標(biāo)朝有利的方向發(fā)展,。
項(xiàng)目不同于日常任務(wù),它有明確的起止時(shí)間和目標(biāo),要在明確的范圍,、時(shí)間和成本約束下,達(dá)到相應(yīng)的質(zhì)量標(biāo)準(zhǔn),并取得用戶的滿意。影響項(xiàng)目成敗的因素涉及方方面面,并且風(fēng)險(xiǎn)伴隨著項(xiàng)目的始終,是客觀存在的,作為一個(gè)項(xiàng)目管理者,應(yīng)該具備良好的風(fēng)險(xiǎn)控制意識(shí),善于識(shí)別風(fēng)險(xiǎn)并分析風(fēng)險(xiǎn)的影響,從中發(fā)現(xiàn)影響目標(biāo)的風(fēng)險(xiǎn)點(diǎn),并施
加影響或采取應(yīng)對(duì)措施,把風(fēng)險(xiǎn)的負(fù)面影響降到最低,并且風(fēng)險(xiǎn)控制應(yīng)該貫穿項(xiàng)目始終,。
風(fēng)險(xiǎn)引起的負(fù)面后果集中體現(xiàn)在進(jìn)度延后,、成本超支,、質(zhì)量不達(dá)標(biāo)等方面,導(dǎo)致這些問(wèn)題的因素主要包括目標(biāo)以及需求不明確、范圍蔓延以及需求變更,、代碼質(zhì)量或返工風(fēng)險(xiǎn),、人員技能和資源的不足、缺乏良好的團(tuán)隊(duì)協(xié)作等,。下面將詳細(xì)描述一下這些問(wèn)題以及出現(xiàn)這些問(wèn)題時(shí)的應(yīng)對(duì)方案:
1,、目標(biāo)以及需求不明確
為了市場(chǎng)競(jìng)爭(zhēng)或內(nèi)部管理決策的需要,業(yè)務(wù)部門提出的需求往往要求的時(shí)間比較緊迫,需求的提出大多停留在幾張紙或口頭的傳達(dá)上,沒(méi)有形成正式的業(yè)務(wù)需求文檔,在沒(méi)有明確的需求范圍的情況下,有時(shí)為了迎合業(yè)務(wù)部門的口味匆匆開(kāi)工,過(guò)程中用戶不斷地提出新的想法,技術(shù)人員開(kāi)始疲于奔命和應(yīng)付,很難保證項(xiàng)目的進(jìn)度和質(zhì)量,也難以取得業(yè)務(wù)部門的認(rèn)可。所以,在項(xiàng)目的前期一定要采取相應(yīng)的手段或措施,與業(yè)務(wù)部門共同明確項(xiàng)目目標(biāo),、需求范圍,充分考慮現(xiàn)有的時(shí)間和資源約束,將需求排定優(yōu)先級(jí), 對(duì)于關(guān)鍵的需求優(yōu)先實(shí)現(xiàn),,其他輔助性的根據(jù)過(guò)程中的具體情況進(jìn)行滾動(dòng)式計(jì)劃,并取 得業(yè)務(wù)部門的書面確認(rèn),。在此過(guò)程中要注重挖掘用戶的隱性需求,,可以通過(guò)引導(dǎo)、系統(tǒng) 原型等手段讓用戶在前期充分暴露自己的想法和需求,。
2,、范圍蔓延以及需求變更 在有了明確的目標(biāo)和需求范圍的情況下,需求的變更還是不可避免的,,業(yè)務(wù)部門在 看到具體系統(tǒng)的真實(shí)雛形之后,,源源不斷地要求、新想法隨之產(chǎn)生,,如果不對(duì)此加以控 制,,新的需求的加入通常會(huì)影響已實(shí)現(xiàn)的需求,并且對(duì)項(xiàng)目進(jìn)度和成本產(chǎn)生很大的影響,。項(xiàng)目管理者針對(duì)這種情況一定要采取嚴(yán)格的變更控制流程,,不能礙于面子,否則最終的 結(jié)果往往是出力不討好,。針對(duì)用戶提出的新需求,,按照正式流程提出變更申請(qǐng),組織相 關(guān)團(tuán)隊(duì)成員進(jìn)行分析及評(píng)估,,作為是否實(shí)施的依據(jù),,變更控制負(fù)責(zé)人根據(jù)分析結(jié)果判斷 是否批準(zhǔn),如果批準(zhǔn),,那項(xiàng)目組可以安排實(shí)施,,否則,正式拒絕用戶的請(qǐng)求,,當(dāng)然實(shí)際 情況下可以采取一些軟措施緩解矛盾,。需求變更風(fēng)險(xiǎn):需求已經(jīng)打上了基線,但此后仍然有變更
發(fā)生,對(duì)項(xiàng)目造成影響,。如何減少此類風(fēng)險(xiǎn)的發(fā)生,? 前期的需求討論要詳細(xì)、充分,。需求文檔中需求的范圍要明確,、功能描述要清楚。找出項(xiàng)目中需求的決策者(通常會(huì)是產(chǎn)品經(jīng)理,、相關(guān)職能主管,、客戶,所有的需求要經(jīng) 過(guò)他們的認(rèn)可,??蛻粼陧?xiàng)目過(guò)程中的全程參與有助于降低此類風(fēng)險(xiǎn)。需求討論,、需求確 認(rèn)、user case 確認(rèn),、測(cè)試階段的客戶驗(yàn)收等環(huán)節(jié),,都要要求客戶參與。在發(fā)生需求變 更時(shí),,嚴(yán)格按照需求變更流程執(zhí)行,。在分析設(shè)計(jì)階段的中的確認(rèn)和評(píng)審也是降低此類風(fēng) 險(xiǎn)的重要手段。
3,、代碼質(zhì)量或返工風(fēng)險(xiǎn) 質(zhì)量風(fēng)險(xiǎn)主要指開(kāi)發(fā)代碼的質(zhì)量,。如何提高開(kāi)發(fā)人員開(kāi)發(fā)的質(zhì)量?在制定項(xiàng)目計(jì)劃 時(shí),,對(duì)開(kāi)發(fā)時(shí)間的評(píng)估要盡可能的合適,。合理的開(kāi)發(fā)時(shí)間對(duì)開(kāi)發(fā)質(zhì)量的影響也很大。有 時(shí)開(kāi)發(fā)人員為了趕進(jìn)度在比較緊張的時(shí)間需要完成指定的任務(wù),,可能就存在很大的開(kāi)發(fā) 質(zhì)量問(wèn)題,。開(kāi)發(fā)要有一套嚴(yán)格可行的代碼規(guī)范,編碼時(shí)嚴(yán)格遵守,,到現(xiàn)在為止,,我們這 個(gè)方面做的不是很規(guī)范,做的也很不足,,大家編寫的代碼隨意性比較大,,代碼編寫者的 主觀意識(shí)性比較強(qiáng)。要建立一套大家認(rèn)可并且規(guī)范可行的編碼規(guī)范和考核規(guī)范,,code review 時(shí)嚴(yán)格考核,。在編碼前,開(kāi)發(fā)人員要對(duì)框架熟練掌握;一份好的系統(tǒng)設(shè)計(jì)文檔對(duì) 指導(dǎo)開(kāi)發(fā)非常重要,。返工是項(xiàng)目組最不愿意看到的,,既浪費(fèi)人力、物力和財(cái)力,,又影響團(tuán)隊(duì)積極性,。需 求不明確或范圍沒(méi)有有效控制都可能造成返工,另外造成返工的原因是質(zhì)量沒(méi)有達(dá)到用 戶要求,。往往有這樣一種情況,,每個(gè)團(tuán)隊(duì)成員按照項(xiàng)目計(jì)劃報(bào)告進(jìn)度都是 100%完成,但一到最后系統(tǒng)交互測(cè)試或集成的時(shí)候就會(huì)發(fā)現(xiàn)一大堆問(wèn)題,,不得不花費(fèi)很大精力回頭 排查,、修改程序,造成這種情況的主要原因是過(guò)程中質(zhì)量保證沒(méi)有做到位,,把大部分問(wèn) 題留在了后面,。這就需要在項(xiàng)目實(shí)施過(guò)程中采取有效的措施來(lái)規(guī)避返工的風(fēng)險(xiǎn),通常的 做法有同行評(píng)審,,比如概要設(shè)計(jì)完成之后,,邀請(qǐng)其他項(xiàng)目組的技術(shù)專家進(jìn)行技術(shù)評(píng)審以 發(fā)現(xiàn)架構(gòu)設(shè)計(jì)問(wèn)題; 管理評(píng)審,,通過(guò)組織級(jí)的質(zhì)量審計(jì)看產(chǎn)品以及實(shí)施過(guò)程是否滿足質(zhì) 量要求,;代碼走查,在編碼過(guò)程中加入至少一次的代碼走查,,排查不符合規(guī)范或性能要 求的代碼,,走查通常能夠發(fā)現(xiàn) 50%-70%的錯(cuò)誤;每日構(gòu)建,,這是一種非常有效的方法,,可以避免把各部分的集成問(wèn)題拖到最后,并且能夠及時(shí)發(fā)現(xiàn)相應(yīng)的錯(cuò)誤,,日構(gòu)建一般在 項(xiàng)目的中后期開(kāi)始,,每天自動(dòng)從版本服務(wù)器上獲取源代碼進(jìn)行自動(dòng)編譯和測(cè)試。
4,、人員技能和資源的不足 項(xiàng)目實(shí)施過(guò)程中由于人員技能欠缺造成的進(jìn)
度延后和軟件質(zhì)量問(wèn)題并不少見(jiàn),,一個(gè) 熟練的技術(shù)人員完成同樣一個(gè)任務(wù)需要 3 天,但一個(gè)生手可能就需要 7-10 天,。項(xiàng)目管
理者應(yīng)該在前期就分析清楚項(xiàng)目所要采用的技術(shù)以及相應(yīng)的人員技能要求,,針對(duì)不同的 角色,及時(shí)采取相應(yīng)的技能培訓(xùn),,以保證項(xiàng)目的順利實(shí)施,。如果對(duì)于項(xiàng)目中某些部分專 業(yè)性特別強(qiáng)或新技術(shù),,短期內(nèi)又不能快速建立技能的情況,可以考慮將該塊任務(wù)外包,,借鑒合作商的力量降低實(shí)施風(fēng)險(xiǎn),,當(dāng)然要進(jìn)行外購(gòu)人力成本與自建人力成本的效益分 析。開(kāi)發(fā)過(guò)程中遇到技術(shù)難題,,導(dǎo)致開(kāi)發(fā)時(shí)間延遲或者需求不得不發(fā)生變更,。如何減少 此類風(fēng)險(xiǎn)的發(fā)生?在項(xiàng)目開(kāi)始前的技術(shù)評(píng)估階段,,明確技術(shù)難點(diǎn),,提前安排人員進(jìn)行攻 克。如果在可預(yù)期的時(shí)間內(nèi)無(wú)法解決,,如果可以,,將向需求提出方要求變更需求或?qū)ふ?可替代方案。這樣的風(fēng)險(xiǎn)應(yīng)該在項(xiàng)目的前期階段就應(yīng)該解決在萌芽狀態(tài)來(lái)避免這樣的風(fēng) 險(xiǎn)在后期或中期出現(xiàn),。項(xiàng)目所需人力資源無(wú)法按時(shí)到位,,導(dǎo)致資源風(fēng)險(xiǎn)。如何減少此類風(fēng)險(xiǎn)的發(fā)生,?這個(gè) 就需要在項(xiàng)目計(jì)劃制定的時(shí)候提前申請(qǐng)確認(rèn)資源,,并在項(xiàng)目過(guò)程中不斷溝通協(xié)調(diào)。
5,、缺乏良好的團(tuán)隊(duì)協(xié)作 軟件項(xiàng)目實(shí)施屬于知識(shí)型,要發(fā)揮團(tuán)隊(duì)成員的創(chuàng)造力,,不同于制造業(yè)計(jì)件生產(chǎn),,各 模塊最終要集成在一起形成一個(gè)有機(jī)的整體,這就需要各小組之間的密切配合,,界定清 楚工作界面及接口關(guān)系,,并在實(shí)施過(guò)程中持續(xù)地溝通交流和共享,首先團(tuán)隊(duì)要融為一體,,產(chǎn)出的軟件才能融為一體,。這是一個(gè)團(tuán)隊(duì)的軟實(shí)力,團(tuán)隊(duì)之間的協(xié)作好壞也將是個(gè)潛在 的風(fēng)險(xiǎn)問(wèn)題,,在項(xiàng)目啟動(dòng)和團(tuán)隊(duì)組建的時(shí)候就應(yīng)該加以規(guī)避這樣的風(fēng)險(xiǎn)出現(xiàn),。項(xiàng)目風(fēng)險(xiǎn)管理的要點(diǎn):
1、上述我們所說(shuō)的風(fēng)險(xiǎn)管理都是指可以預(yù)期將要發(fā)生的風(fēng)險(xiǎn),,那些不可預(yù)期將要發(fā)生 的風(fēng)險(xiǎn)不屬于風(fēng)險(xiǎn)管理的范疇,。這也將是考驗(yàn)一個(gè)項(xiàng)目管理者的經(jīng)驗(yàn)和知識(shí)對(duì)能否 管理好風(fēng)險(xiǎn)至關(guān)重要的內(nèi)容。
2,、對(duì)不可預(yù)期的風(fēng)險(xiǎn),,項(xiàng)目管理者要有潛在的風(fēng)險(xiǎn)意識(shí)評(píng)估,做好一些可操作性的預(yù) 案準(zhǔn)備。
3,、詳細(xì)明確的項(xiàng)目計(jì)劃,、以及項(xiàng)目執(zhí)行過(guò)程中每個(gè)要點(diǎn)的質(zhì)量保證是降低項(xiàng)目風(fēng)險(xiǎn)的 必要條件。
4,、風(fēng)險(xiǎn)報(bào)告是項(xiàng)目團(tuán)隊(duì)以及領(lǐng)導(dǎo)了解項(xiàng)目風(fēng)險(xiǎn)的一個(gè)有效手段,。 風(fēng)險(xiǎn)報(bào)告的格式: 序號(hào) 風(fēng)險(xiǎn)簡(jiǎn)介 對(duì)項(xiàng)目的影響 解決方案或?qū)Σ?/p>
5、團(tuán)隊(duì)管理 團(tuán)隊(duì)就是一組個(gè)體為實(shí)現(xiàn)共同的目標(biāo)而相互依賴,、一起工作的共同體,。團(tuán)隊(duì)工作顧名思 義就是團(tuán)隊(duì)成員為實(shí)現(xiàn)這個(gè)共同的目標(biāo)而付出的共同努力,項(xiàng)目團(tuán)隊(duì)的工作是否有效直接關(guān) 系到
項(xiàng)目的成敗,。團(tuán)隊(duì)管理是個(gè)漸進(jìn)的過(guò)程,。世界上只有完美的團(tuán)隊(duì),沒(méi)有完美的個(gè)人,。好的高效的團(tuán)隊(duì) 不是管理出來(lái)的,,而是營(yíng)造出來(lái)的。團(tuán)隊(duì)成員需要有大家可認(rèn)同的團(tuán)隊(duì)文化,,這需要大家共 同的努力,。
1、營(yíng)造良好的工作環(huán)境和氛圍,。
2,、建設(shè)優(yōu)秀或鮮明的團(tuán)隊(duì)文化。
3,、保持高效的溝通,。
6、項(xiàng)目會(huì)議 組織會(huì)議是項(xiàng)目管理者日常工作中一項(xiàng)非常重要的工作任務(wù),,項(xiàng)目過(guò)程中很多重要的決 定都是在會(huì)議中做出的,,也有很多由于不成功的會(huì)議而對(duì)項(xiàng)目本身造成了不好的影響。首先看看不成功的會(huì)議常常表現(xiàn)為哪些形式:
1,、會(huì)議氛圍不好,,參與者發(fā)言不踴躍;
2,、會(huì)議討論常常偏離主題,;
3、會(huì)議沒(méi)有取得預(yù)期的結(jié)果,;
4,、會(huì)議時(shí)間常常一拖再拖。 這些不成功的會(huì)議最終的結(jié)果就是:既浪費(fèi)了大家的寶貴時(shí)間又沒(méi)有達(dá)到會(huì)議的目的,,很多人都對(duì)這樣的會(huì)議都有抵觸情緒,,對(duì)此也是深惡痛絕,。以下是組織會(huì)議時(shí)應(yīng)該注意的問(wèn) 題,也可看作組織會(huì)議的最佳實(shí)踐,。在列出最佳實(shí)踐之前有三點(diǎn)我們必須要清楚:
1,、會(huì)議是否會(huì)取得成功很大程度上取決于會(huì)議的組織者。只有組織得有力,,會(huì)議才有 可能取得成功,,這是會(huì)議成功的充分條件。
2,、會(huì)議的組織者和參與者的想法通常是不一致的,,有時(shí)候甚至?xí)笙鄰酵ァK圆灰?希望會(huì)議的參與者和你一樣,,對(duì)會(huì)議有著如此的期待,,對(duì)大多數(shù)參與者而言,在會(huì)議中他只 是一個(gè)發(fā)表想法的人,,他不用對(duì)會(huì)議的成功承擔(dān)責(zé)任,。
3、以下十一條最佳實(shí)踐是形式上的約定,,具體的實(shí)施可以根據(jù)實(shí)際情況來(lái)做,。 組織會(huì)議的十一條最佳實(shí)踐:
1、只有需要開(kāi)會(huì)時(shí)才開(kāi)會(huì),。有時(shí)候兩三個(gè)人單獨(dú)小范圍溝通會(huì)更加有效,。
2、提前發(fā)出會(huì)議議程,,以便會(huì)議參與者知道他們來(lái)做什么,。
3、請(qǐng)對(duì)人很重要,,不要把非必要的人召來(lái)開(kāi)會(huì),當(dāng)然也不要漏掉那些關(guān)鍵人物,。在確 保必要人物都在的情況下一次會(huì)議參與者越少效果越好,。
4、提前預(yù)約參與者的時(shí)間,,以確保他們能按時(shí)到場(chǎng),。
5、會(huì)議的開(kāi)場(chǎng)很重要,。會(huì)議組織者要在開(kāi)始前做好幾件事情,。通常我建議有幾點(diǎn)要在 開(kāi)場(chǎng)時(shí)說(shuō): a、再一次強(qiáng)調(diào)會(huì)議的目標(biāo),,我們來(lái)做什么,。b,、強(qiáng)調(diào)會(huì)議的主題與基調(diào)。比如:本次會(huì)議是一個(gè)需求確認(rèn)會(huì),,而非需求討論會(huì),,主要是討論做還是不做以及告知大家我們要做什么,而不要把太多的精力放在討論 如何做上面,。c,、說(shuō)明一下會(huì)議的規(guī)則。如要發(fā)言,,請(qǐng)舉手,;不要有小圈子討論;不要打斷別人 的講 話,,等別人說(shuō)完你再說(shuō)等等,。
6、會(huì)議過(guò)程中時(shí)刻注意引導(dǎo)和控制會(huì)議,,以確保會(huì)議按照目
標(biāo)進(jìn)行,。一次會(huì)議的氛圍 是否良好,討論是否充分,,好的引導(dǎo)至關(guān)重要。比如多提一些開(kāi)放式的問(wèn)題,。
7,、會(huì)議記錄很重要,把一些結(jié)論和有價(jià)值的內(nèi)容記錄下來(lái),,這些是本次會(huì)議的重要成 果之一,。
8、會(huì)議要有結(jié)論,。我們常在會(huì)議上聽(tīng)到有人說(shuō):"大家討論了這么半天,,結(jié)論呢?",。沒(méi)有結(jié)論的會(huì)議是沒(méi)有意義的,。
9、會(huì)議后別忘發(fā)會(huì)議紀(jì)要,,以及一些 action,,什么人什么時(shí)候做什么。
10,、會(huì)議后的 action 執(zhí)行情況的反饋很重要,。反饋是對(duì)會(huì)議參與者的尊重,同時(shí)也告知 了會(huì)議的效果,。否則會(huì)讓大家感覺(jué)到這是一個(gè)可無(wú)可無(wú)的會(huì)議,,大家以后參與的積極性 也會(huì)降低,。很多會(huì)議往往都不注意這一點(diǎn)。
11,、按時(shí)結(jié)束的會(huì)議會(huì)受到所有人的歡迎,。
7、版本控制 版本控制也是項(xiàng)目管理者的一個(gè)重要工作內(nèi)容之一,,一個(gè)項(xiàng)目或產(chǎn)品的完成不可能是一 步到位的,,在項(xiàng)目完成的后期可能會(huì)有多個(gè)不同的版本的發(fā)布(開(kāi)發(fā)版本,測(cè)試版本,,發(fā)布 版本等),。需要做好版本的管理和控制。
8,、項(xiàng)目總結(jié) 在項(xiàng)目完成后,,總結(jié)整個(gè)完成項(xiàng)目的過(guò)程和經(jīng)歷,為下一次的項(xiàng)目啟動(dòng)提供參考經(jīng)驗(yàn),,完善不足,,避免在類似的項(xiàng)目中出現(xiàn)可能存在的相同的錯(cuò)誤發(fā)生。
軟件開(kāi)發(fā)項(xiàng)目實(shí)施方案篇二
1 軟件開(kāi)發(fā)實(shí)施方案
系統(tǒng)開(kāi)發(fā)嚴(yán)格按照軟件工程的方法進(jìn)行組織,,系統(tǒng)的開(kāi)發(fā)過(guò)程按
照需求分析,、系統(tǒng)分析與設(shè)計(jì)要求、系統(tǒng)編碼,、系統(tǒng)測(cè)試幾個(gè)過(guò)程有 序推進(jìn),。下表所示系統(tǒng)開(kāi)發(fā)流程圖,采用原型及迭代方式開(kāi)發(fā),,根據(jù) 用戶需求持續(xù)改進(jìn),,直到最終用戶確認(rèn)滿意。
1.1 開(kāi)發(fā)流程總述
如下圖示流程定義了我公司內(nèi)部的軟件開(kāi)發(fā)過(guò)程,,以指導(dǎo)和規(guī)范軟件項(xiàng)目中開(kāi)發(fā)過(guò)程的定義和相應(yīng)的實(shí)施,。
該過(guò)程可劃分為一系列子過(guò)程,包括:軟件需求分析,、設(shè)計(jì),、編
碼、測(cè)試,、驗(yàn)收、維護(hù),,每個(gè)子過(guò)程又由一系列任務(wù)和活動(dòng)組成,,如 設(shè)計(jì)過(guò)程又可分為結(jié)構(gòu)設(shè)計(jì)和詳細(xì)設(shè)計(jì)。但是在實(shí)際開(kāi)發(fā)項(xiàng)目中,,情 況仍然會(huì)是千變?nèi)f化的,,因此我們也并不是一成不變的死板執(zhí)行一個(gè) 僵化的工作流程,,我們的原則是在一個(gè)規(guī)范流程的指導(dǎo)和約束下,根 據(jù)具體工程項(xiàng)目的實(shí)際要求,,為每一個(gè)項(xiàng)目評(píng)估并制定真正能夠最好 的滿足該項(xiàng)目要求的開(kāi)發(fā)流程,。
開(kāi)始
軟件需求分析
y
n:改進(jìn)
y
n:改進(jìn)
y
n:改進(jìn)
《軟件需求規(guī)格說(shuō)明書》(初稿)
《系統(tǒng)測(cè)試計(jì)劃》《系統(tǒng)測(cè)試案例》
(初稿)
《用戶手冊(cè)》(概要)《追溯表一》
《軟件需求規(guī)格說(shuō)明書》
《系統(tǒng)測(cè)試計(jì)劃》《系統(tǒng)測(cè)試案例》
《個(gè)人評(píng)審記錄》
《評(píng)審報(bào)告》
同行評(píng)審
通過(guò)
結(jié)構(gòu)設(shè)計(jì)
評(píng)審?fù)ㄟ^(guò)
《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》(初稿)
《集成測(cè)試計(jì)劃》《集成測(cè)試案例》
(初稿)
《用戶手冊(cè)》(初稿)《追溯表一》
《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》
《集成測(cè)試計(jì)劃》《集成測(cè)試案例》
《個(gè)人評(píng)審記錄》 《評(píng)審報(bào)告》
《詳細(xì)設(shè)計(jì)說(shuō)明書》(初稿)
《單元測(cè)試計(jì)劃》《單元測(cè)試案例》
(初稿)
《用戶手冊(cè)》(修改稿)《追溯表一》
《詳細(xì)設(shè)計(jì)說(shuō)明書》
《單元測(cè)試計(jì)劃》《單元測(cè)試案例》
《用戶手冊(cè)》(修改稿)
《個(gè)人評(píng)審記錄》
《評(píng)審報(bào)告》
源代碼、源代碼文件清單
《單元測(cè)試報(bào)告》(經(jīng)過(guò)審批)
《軟件問(wèn)題狀態(tài)登記表》 《軟件問(wèn)題報(bào)告單》
《集成工作單》
《集成測(cè)試工作單》
《集成測(cè)試報(bào)告》(經(jīng)過(guò)審批)
《軟件問(wèn)題狀態(tài)登記表》
《軟件問(wèn)題報(bào)告單》 集成的軟件系統(tǒng)
《系統(tǒng)測(cè)試報(bào)告》(經(jīng)過(guò)審批)
《軟件問(wèn)題狀態(tài)登記表》
《軟件問(wèn)題報(bào)告單》
《系統(tǒng)管理員使用說(shuō)明書》(經(jīng)過(guò)審批)
《安裝手冊(cè)》(經(jīng)過(guò)審批)
《用戶手冊(cè)》(經(jīng)過(guò)審批 軟件系統(tǒng)(系統(tǒng)測(cè)試通過(guò))
驗(yàn)收測(cè)試報(bào)告
《軟件問(wèn)題報(bào)告單》
《軟件問(wèn)題狀態(tài)登記表》
驗(yàn)收?qǐng)?bào)告 可交付產(chǎn)品
《軟件需求規(guī)格說(shuō)明書》(升級(jí)版)
《客戶需求登記表》
《客戶需求統(tǒng)計(jì)表》
《設(shè)計(jì)說(shuō)明書》(升級(jí)版)
《軟件問(wèn)題報(bào)告單》
《軟件問(wèn)題狀態(tài)登記表》
《軟件維護(hù)實(shí)施計(jì)劃》 維護(hù)后的軟件系統(tǒng)
詳細(xì)設(shè)計(jì)
評(píng)審?fù)ㄟ^(guò)
編碼
集成測(cè)試
系統(tǒng)測(cè)試
驗(yàn)收
維護(hù)
結(jié)束
圖 1.1-1 軟件開(kāi)發(fā)流程總圖
在應(yīng)用系統(tǒng)軟件開(kāi)發(fā)項(xiàng)目中,,我們?nèi)詫⒆裱@一思想,,這一點(diǎn)將在隨后的項(xiàng)目開(kāi)發(fā)實(shí)施計(jì)劃部分有具體的體現(xiàn),在這里和下面的相關(guān)章節(jié)中,,我們?nèi)詫@著這個(gè)完整的開(kāi)發(fā)流程來(lái)分析說(shuō)明,,以此來(lái)闡明我們對(duì)項(xiàng)目開(kāi)發(fā)的完整過(guò)程管理思想和相關(guān)實(shí)踐。下面我們對(duì)這個(gè)軟件開(kāi)發(fā)工作流程進(jìn)行簡(jiǎn)要地分解說(shuō)明,。
1.2 軟件需求分析
(1)概述
由于應(yīng)用系統(tǒng)與眾多相關(guān)應(yīng)用軟件需要進(jìn)行交互,,因此需要先對(duì)這些應(yīng)用系統(tǒng)進(jìn)行分別梳理,充分做好需求調(diào)研工作,,編寫經(jīng)項(xiàng)目單位認(rèn)可并評(píng)審?fù)ㄟ^(guò)的《系統(tǒng)需求規(guī)格說(shuō)明書》,。
軟件需求分析是按照項(xiàng)目定義的軟件開(kāi)發(fā)過(guò)程,根據(jù)系統(tǒng)分配給軟件的需求(見(jiàn) 《系統(tǒng)需求規(guī)格說(shuō)明書》),,進(jìn)行軟件質(zhì)量特性規(guī)格說(shuō)明的過(guò)程,。該過(guò)程包括進(jìn)一步明確軟件運(yùn)行環(huán)境,明確對(duì)軟件的功能,、性能和數(shù)據(jù)要求,,以及軟件與硬件、軟件與軟件之間的接口要求等,,并對(duì)軟件需求進(jìn)行驗(yàn)證和文檔化,,即完成對(duì)軟件需求的分析與規(guī)格定義。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
系統(tǒng)分配給軟
件的需求
軟件需求分析 結(jié)構(gòu)設(shè)計(jì)
圖示:軟件需求分析在軟件開(kāi)發(fā)過(guò)程中的位置
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則
客戶需求(《系統(tǒng)需求規(guī)格
已由 ccb批準(zhǔn)為基線
說(shuō)明書》)
已進(jìn)入配置庫(kù)
2)出口準(zhǔn)則
要素
判斷準(zhǔn)則
已經(jīng)過(guò)審查
軟件需求規(guī)格說(shuō)明書
已批準(zhǔn)為基線
已進(jìn)入配置庫(kù)
系統(tǒng)測(cè)試計(jì)劃
已經(jīng)過(guò)審查
已獲得批準(zhǔn)
系統(tǒng)測(cè)試案例
已進(jìn)入配置庫(kù)
用戶手冊(cè)(概要)追溯表一
已編寫
已填寫
(3)評(píng)審
評(píng)審《軟件需求規(guī)格說(shuō)明書》,,具體評(píng)審過(guò)程見(jiàn)《評(píng)審程序文件》,,對(duì)軟件需求的評(píng)審準(zhǔn)則包括:
● 系統(tǒng)需求和系統(tǒng)設(shè)計(jì)的可追溯性;
● 與系統(tǒng)需求的一致性,;
● 內(nèi)部一致性,;
● 可測(cè)試性;
● 軟件設(shè)計(jì)的可行性,;
● 運(yùn)作和維護(hù)的可行性,。
對(duì)軟件需求中的問(wèn)題,與系統(tǒng)工程組或客戶一起確定和審查,,根據(jù)審查結(jié)果對(duì)軟件需求進(jìn)行適當(dāng)?shù)男薷?,必要時(shí)按基線變更控制的要求對(duì)客戶需求進(jìn)行相應(yīng)的修改。對(duì)軟件需求規(guī)格說(shuō)明書進(jìn)行同行評(píng)審,。
審查,、批準(zhǔn)軟件需求規(guī)格說(shuō)明書,。
將軟件需求規(guī)格說(shuō)明書置于配置管理之下。
(4)工作產(chǎn)品
● 《軟件需求規(guī)格說(shuō)明書》 ● 《系統(tǒng)測(cè)試計(jì)劃》 ● 《系統(tǒng)測(cè)試案例》 ● 《用戶手冊(cè)》 ● 《追溯表》(5)職責(zé)
● 項(xiàng)目經(jīng)理:負(fù)責(zé)組建軟件需求分析組,;確定是否需要對(duì)有關(guān)
人員進(jìn)行培訓(xùn),;負(fù)責(zé)軟件需求規(guī)格說(shuō)明書的審查和批準(zhǔn)。
● 軟件需求分析組:軟件需求分析的主要承擔(dān)者,,負(fù)責(zé)完成本
過(guò)程元素要求產(chǎn)生的所有工作產(chǎn)品,。
● 系統(tǒng)測(cè)試負(fù)責(zé)人:負(fù)責(zé)組織軟件系統(tǒng)測(cè)試組對(duì)軟件需求進(jìn)行
分析,審查軟件需求的可測(cè)試性,;參與軟件需求規(guī)格說(shuō)明書的審查和批準(zhǔn),。
● 質(zhì)量保證人員:參與工作產(chǎn)品的審查,統(tǒng)計(jì)缺陷,,并對(duì)軟件
需求分析過(guò)程進(jìn)行審計(jì),。
● 系統(tǒng)開(kāi)發(fā)組:配合處理涉及客戶需求的軟件需求問(wèn)題?!?客戶:必要時(shí)參與軟件需求規(guī)格說(shuō)明書的審查和批準(zhǔn),。
1.3 結(jié)構(gòu)設(shè)計(jì)
(1)概述
結(jié)構(gòu)設(shè)計(jì)是指按照《軟件需求規(guī)格說(shuō)明書》,設(shè)計(jì)軟件系統(tǒng)的體系結(jié)構(gòu),,即模塊結(jié)構(gòu),,定義每個(gè)模塊的主要功能和模塊之間的聯(lián)系(即接口),并確定軟件系統(tǒng)的數(shù)據(jù)體系結(jié)構(gòu),。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
軟件需求分析
結(jié)構(gòu)設(shè)計(jì) 詳細(xì)設(shè)計(jì)
圖示:軟件需求分析在軟件開(kāi)發(fā)過(guò)程中的位置圖
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則
軟件需求規(guī)格說(shuō)明書 經(jīng)過(guò)審查
審查獲得批準(zhǔn)
進(jìn)入配置庫(kù)
2)出口準(zhǔn)則
要素
結(jié)構(gòu)設(shè)計(jì)說(shuō)明書 集成測(cè)試計(jì)劃 集成測(cè)試案例 用戶手冊(cè)(初稿)
判斷準(zhǔn)則
經(jīng)過(guò)審查
審查獲得批準(zhǔn)
進(jìn)入配置庫(kù)
已完善
追溯表一
(3)評(píng)審
● 對(duì)《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》和《集成測(cè)試計(jì)劃》進(jìn)行同行評(píng)審,。
● 對(duì)結(jié)構(gòu)設(shè)計(jì)中的問(wèn)題,與軟件需求分析人員一起確定和審查,,并對(duì)結(jié)構(gòu)設(shè)計(jì)進(jìn)行適當(dāng)?shù)母摹?/p>
● 審查,、批準(zhǔn)《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》,,必要時(shí),,對(duì)其進(jìn)行設(shè)計(jì)評(píng)審,。● 將《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》,、《集成測(cè)試計(jì)劃》 和《集成測(cè)試案例》
置于配置管理之下,。
(4)工作產(chǎn)品
● 《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》 ● 《集成測(cè)試計(jì)劃》 ● 《集成測(cè)試案例》 ● 《用戶手冊(cè)》 ● 《追溯表》(5)職責(zé)
1)項(xiàng)目經(jīng)理
負(fù)責(zé)選擇合適的設(shè)計(jì)人員,組建結(jié)構(gòu)設(shè)計(jì)工作組,;負(fù)責(zé)《結(jié)構(gòu)設(shè)
計(jì)說(shuō)明書》和《集成測(cè)試計(jì)劃》的審查和批準(zhǔn),。
2)結(jié)構(gòu)設(shè)計(jì)人員
結(jié)構(gòu)設(shè)計(jì)階段工作的主要承擔(dān)者,負(fù)責(zé)完成本過(guò)程元素產(chǎn)生的所
有工作產(chǎn)品,。
3)系統(tǒng)分析員
配合處理涉及軟件需求的問(wèn)題,。
4)系統(tǒng)開(kāi)發(fā)負(fù)責(zé)人
負(fù)責(zé)組織系統(tǒng)工程組對(duì)結(jié)構(gòu)設(shè)計(jì)進(jìn)行分析,審查結(jié)構(gòu)設(shè)計(jì)的可測(cè)
試性;負(fù)責(zé)協(xié)調(diào)處理涉及軟件需求的問(wèn)題,;參與《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》
和《集成測(cè)試計(jì)劃》的審查和批準(zhǔn)。
5)軟件測(cè)試負(fù)責(zé)人
負(fù)責(zé)組織軟件測(cè)試組對(duì)結(jié)構(gòu)設(shè)計(jì)進(jìn)行分析,,審查結(jié)構(gòu)設(shè)計(jì)的可測(cè)
試性,;參與《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》和《集成測(cè)試計(jì)劃》的審查和批準(zhǔn)。
1.4 詳細(xì)設(shè)計(jì)
(1)概述
詳細(xì)設(shè)計(jì)是根據(jù) 《結(jié)構(gòu)設(shè)計(jì)說(shuō)明書》進(jìn)行模塊設(shè)計(jì),,將結(jié)構(gòu)設(shè)計(jì)所獲得的模塊按照單元,、程序、規(guī)程的順序逐步細(xì)化,。詳細(xì)定義各個(gè)單元的數(shù)據(jù)結(jié)構(gòu),、程序的實(shí)現(xiàn)算法以及程序、單元,、模塊之間的接口等,,作為以后編碼工作的依據(jù)。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
結(jié)構(gòu)設(shè)計(jì)
詳細(xì)設(shè)計(jì) 編碼
圖示:詳細(xì)設(shè)計(jì)在軟件開(kāi)發(fā)過(guò)程中的位置
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則 經(jīng)過(guò)審查 審查獲得批準(zhǔn)
結(jié)構(gòu)設(shè)計(jì)說(shuō)明書
進(jìn)入配置庫(kù)
2)出口準(zhǔn)則
要素 判斷準(zhǔn)則
要素
判斷準(zhǔn)則 經(jīng)過(guò)審查 審查獲得批準(zhǔn)
詳細(xì)設(shè)計(jì)說(shuō)明書
進(jìn)入配置庫(kù)
(3)評(píng)審
對(duì)《詳細(xì)設(shè)計(jì)說(shuō)明書》和《單元測(cè)試計(jì)劃》可進(jìn)行走查或(和)
同行評(píng)審,;
對(duì)詳細(xì)設(shè)計(jì)中的問(wèn)題,,與結(jié)構(gòu)設(shè)計(jì)人員一起確定和審查,并對(duì)詳細(xì)設(shè)計(jì)做出適當(dāng)?shù)母模?/p>
審查,、批準(zhǔn)《詳細(xì)設(shè)計(jì)說(shuō)明書》,,必要時(shí),對(duì)其進(jìn)行設(shè)計(jì)評(píng)審,;將《詳細(xì)設(shè)計(jì)說(shuō)明書》和《單元測(cè)試計(jì)劃》置于配置管理之下,。
(4)工作產(chǎn)品
● 《詳細(xì)設(shè)計(jì)說(shuō)明書》 ● 《單元測(cè)試計(jì)劃》 ● 《單元測(cè)試案例》 ● 《用戶手冊(cè)》 ● 《追溯表》(5)職責(zé)
1)項(xiàng)目經(jīng)理
負(fù)責(zé)選擇合適的設(shè)計(jì)人員,組建詳細(xì)設(shè)計(jì)組,;負(fù)責(zé)《詳細(xì)設(shè)計(jì)說(shuō)
明書》和《單元測(cè)試計(jì)劃》的審查和批準(zhǔn),。
2)詳細(xì)設(shè)計(jì)人員
詳細(xì)設(shè)計(jì)階段工作的主要承擔(dān)者。負(fù)責(zé)完成本過(guò)程元素產(chǎn)生的所
有工作產(chǎn)品,。
3)系統(tǒng)分析員
配合處理涉及軟件需求的問(wèn)題,。
4)系統(tǒng)開(kāi)發(fā)負(fù)責(zé)人
負(fù)責(zé)組織系統(tǒng)工程組對(duì)詳細(xì)設(shè)計(jì)進(jìn)行分析,審查詳細(xì)設(shè)計(jì)的可測(cè)
試性,;負(fù)責(zé)協(xié)調(diào)處理涉及軟件需求的問(wèn)題,;參與《詳細(xì)設(shè)計(jì)說(shuō)明書》
和《單元測(cè)試計(jì)劃》的審查和批準(zhǔn)。
5)軟件測(cè)試負(fù)責(zé)人
負(fù)責(zé)組織軟件測(cè)試組對(duì)詳細(xì)設(shè)計(jì)進(jìn)行分析,,審查詳細(xì)設(shè)計(jì)的可測(cè)
試性,;參與《詳細(xì)設(shè)計(jì)說(shuō)明書》和《單元測(cè)試計(jì)劃》的審查和批準(zhǔn)。
1.5 編碼
(1)概述
編碼階段主要完成的工作是根據(jù)詳細(xì)設(shè)計(jì)說(shuō)明書編寫程序源代
碼,,包括必要的數(shù)據(jù)文件,,并進(jìn)行單元測(cè)試,單元測(cè)試的內(nèi)容包括模
塊內(nèi)程序的邏輯、功能,、參數(shù)傳遞,、變量引用、出錯(cuò)處理等方面,。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
詳細(xì)設(shè)計(jì)
編碼 集成測(cè)試
圖示:編碼階段在軟件開(kāi)發(fā)過(guò)程中的位置
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則
詳細(xì)設(shè)計(jì)說(shuō)明書
經(jīng)過(guò)審查
單元測(cè)試計(jì)劃 獲得批準(zhǔn)
進(jìn)入配置庫(kù)
2)出口準(zhǔn)則
要素
判斷準(zhǔn)則
源代碼文件
源代碼文件獲得批準(zhǔn)
源代碼文件清單
源代碼文件進(jìn)入配置庫(kù)的源代碼區(qū)
單元測(cè)試報(bào)告
提交測(cè)試負(fù)責(zé)人
軟件問(wèn)題報(bào)告單
提交問(wèn)題管理渠道
(3)評(píng)審
對(duì)源代碼文件進(jìn)行同行評(píng)審,,主要的方法為對(duì)照詳細(xì)設(shè)計(jì)說(shuō)明書對(duì)代碼進(jìn)行查閱,也可根據(jù)編程者的經(jīng)驗(yàn)或程序的難度,、重要程度,,選擇走查評(píng)審方式,但目的都是發(fā)現(xiàn)程序存在的問(wèn)題,。
(4)工作產(chǎn)品
● 源代碼文件 ● 《單元測(cè)試報(bào)告》 ● 《軟件問(wèn)題報(bào)告單》 ● 《軟件問(wèn)題狀態(tài)登記表》(5)職責(zé)
1)項(xiàng)目經(jīng)理
建立編碼組,、測(cè)試組或相應(yīng)崗位,并進(jìn)行必要的培訓(xùn),;跟蹤進(jìn)度
和問(wèn)題解決狀態(tài),; 對(duì)提交的源代碼進(jìn)行批準(zhǔn)(或指定負(fù)責(zé)人進(jìn)行批準(zhǔn)
工作)。
2)程序員
編寫程序代碼,;測(cè)試程序代碼,;修改程序代碼;提交工作產(chǎn)品,,批準(zhǔn)后將其導(dǎo)入配置區(qū)的源碼庫(kù),。
3)單元測(cè)試人員
測(cè)試源代碼;提交測(cè)試報(bào)告和軟件問(wèn)題報(bào)告單,。
4)評(píng)審人員
對(duì)指定源代碼文件進(jìn)行閱讀,,發(fā)現(xiàn)缺陷和問(wèn)題,填寫評(píng)審報(bào)告,。
1.6 模塊集成測(cè)試
(1)概述
集成測(cè)試階段主要完成的工作是集成和集成測(cè)試,。集成是參考結(jié)構(gòu)設(shè)計(jì)說(shuō)明書并根據(jù)詳細(xì)說(shuō)明書中規(guī)定的系統(tǒng)集成方案將不同的經(jīng)
測(cè)試的程序單元進(jìn)行構(gòu)造,并逐步構(gòu)造成一個(gè)完整的軟件產(chǎn)品的過(guò)程,;集成測(cè)試則是在集成完成之后,,對(duì)各單元、模塊之間接口的正確性和集成后功能的正確性進(jìn)行驗(yàn)證,。
對(duì)于大型軟件,,集成測(cè)試可以采取分步進(jìn)行的方法,可以先對(duì)各子系統(tǒng)進(jìn)行集成測(cè)試,,然后在子系統(tǒng)之間進(jìn)行集成測(cè)試,。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
編碼
集成測(cè)試 系統(tǒng)測(cè)試
圖示:集成測(cè)試在軟件開(kāi)發(fā)過(guò)程中的位置
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則 經(jīng)過(guò)審查 獲得批準(zhǔn) 進(jìn)入配置庫(kù)
結(jié)構(gòu)設(shè)計(jì)說(shuō)明書
詳細(xì)設(shè)計(jì)說(shuō)明書
集成測(cè)試計(jì)劃
源代碼文件
2)出口準(zhǔn)則
要素
判斷準(zhǔn)則 獲得批準(zhǔn) 進(jìn)入配置庫(kù)
提交集成測(cè)試負(fù)責(zé)人 已進(jìn)入軟件問(wèn)題管理流程
集成的軟件系統(tǒng)
(完整的源代碼和目標(biāo)代碼)
集成測(cè)試報(bào)告
軟件問(wèn)題報(bào)告單
(3)審查階段
核查集成狀態(tài)和結(jié)果,并進(jìn)行批準(zhǔn),;
批準(zhǔn)后,,將目標(biāo)程序和程序清單進(jìn)入目標(biāo)代碼庫(kù),。
(4)工作產(chǎn)品
● 集成后的系統(tǒng)目標(biāo)代碼(包括文件清單),及相應(yīng)的源代碼
(包括文件清單)● 集成測(cè)試報(bào)告 ● 《軟件問(wèn)題報(bào)告單》 ● 《軟件問(wèn)題狀態(tài)登記表》 ● 《集成工作單》 ● 《集成測(cè)試工作單》(5)職責(zé)
● 項(xiàng)目經(jīng)理:建立集成組,、集成測(cè)試組或相應(yīng)崗位,,并進(jìn)行必
要的培訓(xùn);跟蹤進(jìn)度和問(wèn)題解決狀態(tài),;對(duì)集成后的系統(tǒng)目標(biāo)
碼進(jìn)行批準(zhǔn)(或指定負(fù)責(zé)人進(jìn)行批準(zhǔn)工作),。
● 集成負(fù)責(zé)人員:負(fù)責(zé)集成過(guò)程的實(shí)施。
● 集成人員:負(fù)責(zé)環(huán)境構(gòu)建,,集成的過(guò)程操作,并將集成后的目標(biāo)代碼提交批準(zhǔn),。
● 程序員,、設(shè)計(jì)人員:修改源碼或設(shè)計(jì),解決集成過(guò)程中出現(xiàn)的與源碼有關(guān)的問(wèn)題,。
● 測(cè)試人員:測(cè)試系統(tǒng)目標(biāo)碼,,將測(cè)試報(bào)告和軟件問(wèn)題報(bào)告單
提交測(cè)試負(fù)責(zé)人。
1.7 系統(tǒng)測(cè)試
(1)概述
系統(tǒng)測(cè)試的主要任務(wù)是從系統(tǒng)需求的角度對(duì)系統(tǒng)運(yùn)行的正確性和性能進(jìn)行驗(yàn)證,。系統(tǒng)測(cè)試的依據(jù)為系統(tǒng)測(cè)試計(jì)劃,。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
集成測(cè)試
系統(tǒng)測(cè)試 驗(yàn)收
圖示:系統(tǒng)測(cè)試在軟件開(kāi)發(fā)過(guò)程中的位置
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則 經(jīng)過(guò)審查
系統(tǒng)需求
要素
判斷準(zhǔn)則 獲得批準(zhǔn) 進(jìn)入配置庫(kù) 編寫完成系統(tǒng)的目標(biāo)代碼
系統(tǒng)測(cè)試計(jì)劃
用戶手冊(cè)
2)出口準(zhǔn)則
要素
判斷準(zhǔn)則 獲得批準(zhǔn)
系統(tǒng)測(cè)試報(bào)告
軟件問(wèn)題報(bào)告單
(3)工作產(chǎn)品
● 《系統(tǒng)測(cè)試報(bào)告》 ● 《軟件問(wèn)題報(bào)告單》 ● 《軟件問(wèn)題狀態(tài)登記表》(4)職責(zé)
● 項(xiàng)目經(jīng)理:負(fù)責(zé)建立系統(tǒng)測(cè)試組或相關(guān)的崗位,并進(jìn)行必要的培訓(xùn),;跟蹤進(jìn)度和問(wèn)題解決狀態(tài),;對(duì)最終的目標(biāo)代碼進(jìn)行
批準(zhǔn)(或指定負(fù)責(zé)人進(jìn)行批準(zhǔn)工作)。
● 程序員,、設(shè)計(jì)人員:修改源碼或設(shè)計(jì),,解決集成過(guò)程中出現(xiàn)的與源碼有關(guān)的問(wèn)題。
● 測(cè)試人員:測(cè)試系統(tǒng)目標(biāo)碼,,將測(cè)試報(bào)告提交測(cè)試負(fù)責(zé)人,,將軟件問(wèn)題報(bào)告單提交問(wèn)題管理渠道。
1.8 驗(yàn)收
(1)概述
驗(yàn)收階段主要由驗(yàn)收測(cè)試,、驗(yàn)收測(cè)試問(wèn)題改正和驗(yàn)收三部分組成:
驗(yàn)收測(cè)試的主要目的是驗(yàn)證所開(kāi)發(fā)的系統(tǒng)在用戶的使用環(huán)境下
(或模擬的使用環(huán)境下)是否滿足系統(tǒng)需求,,從用戶的角度驗(yàn)證整個(gè)
系統(tǒng)運(yùn)行的正確性。
驗(yàn)收測(cè)試問(wèn)題改正是對(duì)驗(yàn)收測(cè)試中發(fā)現(xiàn)的差異性問(wèn)題進(jìn)行修改,。
驗(yàn)收則是在驗(yàn)收測(cè)試的基礎(chǔ)上,,依據(jù)項(xiàng)目合同或項(xiàng)目任務(wù)書對(duì)項(xiàng)
目的完成情況進(jìn)行綜合評(píng)價(jià)。
本元素在整個(gè)過(guò)程中的位置如下圖所示:
系統(tǒng)測(cè)試
驗(yàn)收 維護(hù)
圖示:驗(yàn)收在軟件開(kāi)發(fā)過(guò)程中的位置
驗(yàn)收的三個(gè)組成部分視項(xiàng)目立項(xiàng)類型和客戶的要求選擇執(zhí)行,。
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則
驗(yàn)收測(cè)試前完成評(píng)審,。
驗(yàn)收測(cè)試計(jì)劃(有驗(yàn)收測(cè)試要求的項(xiàng)目)
測(cè)試(系統(tǒng)測(cè)試、集成測(cè)試,、單
已完成元測(cè)試)
2)出口準(zhǔn)則
要素
判斷準(zhǔn)則 已提交 已關(guān)閉 已提交
驗(yàn)收測(cè)試報(bào)告
驗(yàn)收測(cè)試問(wèn)題報(bào)告單
驗(yàn)收?qǐng)?bào)告
(3)工作產(chǎn)品
● 驗(yàn)收測(cè)試報(bào)告
● 《軟件問(wèn)題報(bào)告單》
● 《軟件問(wèn)題狀態(tài)登記表》
● 驗(yàn)收?qǐng)?bào)告
● 可交付產(chǎn)品
(4)職責(zé)
● 驗(yàn)收測(cè)試組:負(fù)責(zé)驗(yàn)收測(cè)試的各項(xiàng)活動(dòng),。
● 開(kāi)發(fā)組人員:負(fù)責(zé)驗(yàn)收測(cè)試中發(fā)現(xiàn)問(wèn)題的改正和測(cè)試輔助,。● 項(xiàng)目管理人員:負(fù)責(zé)指派驗(yàn)收測(cè)試責(zé)任和完成測(cè)試規(guī)程,;確
保測(cè)試質(zhì)量和進(jìn)程,;確保組間協(xié)調(diào)?!?驗(yàn)收組:具體進(jìn)行驗(yàn)收,。● ccb:批準(zhǔn)運(yùn)行基線,。
1.9 維護(hù)
(1)概述
維護(hù)期是指: 軟件產(chǎn)品 / 系統(tǒng)驗(yàn)收后,,進(jìn)入軟件運(yùn)行 / 系統(tǒng)維護(hù)階段,直至軟件產(chǎn)品下一個(gè)版本的發(fā)布或系統(tǒng)維護(hù)期終止,;
本元素在整個(gè)軟件開(kāi)發(fā)過(guò)程中的位置如下圖所示:
驗(yàn)收
維護(hù)
圖示:維護(hù)在軟件開(kāi)發(fā)過(guò)程中的位置
(2)入口準(zhǔn)則和出口準(zhǔn)則
1)入口準(zhǔn)則
要素
判斷準(zhǔn)則
軟件產(chǎn)品 / 系統(tǒng)
已驗(yàn)收
2)出口準(zhǔn)則
要素
判斷準(zhǔn)則
軟件產(chǎn)品
已退役
合同約定的維護(hù)期限
已到期
合同約定的維護(hù)范圍
已超出,,須另簽協(xié)議
(3)工作產(chǎn)品
《軟件需求規(guī)格說(shuō)明書》
《客戶需求登記表》
《客戶需求統(tǒng)計(jì)表》
《設(shè)計(jì)說(shuō)明書》
《軟件問(wèn)題報(bào)告單》
《軟件問(wèn)題狀態(tài)登記表》
《軟件維護(hù)實(shí)施計(jì)劃》
維護(hù)后的軟件系統(tǒng)
(4)職責(zé)
維護(hù)負(fù)責(zé)人:制定軟件維護(hù)實(shí)施計(jì)劃,確認(rèn)維護(hù)類型,、需求范圍,,分配維護(hù)任務(wù),追蹤任務(wù)的完成情況及其他項(xiàng)目管理工作,。
軟件維護(hù)人員:負(fù)責(zé)進(jìn)行軟件維護(hù)任務(wù)的執(zhí)行,。
qa人員:負(fù)責(zé)協(xié)助維護(hù)負(fù)責(zé)人根據(jù)實(shí)際情況剪裁標(biāo)準(zhǔn)流程。