【文章內(nèi)容簡介】 bernate + Spring ，開發(fā)周期為6個(gè)月。本人在項(xiàng)目中進(jìn)行了前期的需求分析，系統(tǒng)架構(gòu)實(shí)現(xiàn)，數(shù)據(jù)庫建模，及部分編碼工作。問題之三、談?wù)勀銈兪窃趺磳@個(gè)項(xiàng)目進(jìn)行開發(fā)的？（談?wù)勀銈兪窃趺催M(jìn)行項(xiàng)目開發(fā)的?）分析：這個(gè)問題是考核你是否熟悉軟件開發(fā)的流程，同時(shí)也是考核你的項(xiàng)目經(jīng)驗(yàn)，你的專業(yè)素養(yǎng)，從這里可以判斷出你參與過多少項(xiàng)目，可以判斷你對軟件工程的理解和熟悉程度。這個(gè)問題是十分關(guān)鍵的，你需要準(zhǔn)備的知識點(diǎn)有：軟件項(xiàng)目的生命周期、軟件項(xiàng)目的開發(fā)模型、面向?qū)ο蟮姆治龊驮O(shè)計(jì)、軟件質(zhì)量保證等。軟件項(xiàng)目的生命周期: 項(xiàng)目計(jì)劃 需求分析設(shè)計(jì)(概要設(shè)計(jì)和詳細(xì)設(shè)計(jì))編碼 測試 發(fā)布 維護(hù)項(xiàng)目計(jì)劃階段：走訪客戶，進(jìn)行交流溝通，獲得客戶原始需求。對客戶的需求和市場等進(jìn)行調(diào)研，分析，編寫可行性分析報(bào)告。通過不斷的與客戶溝通，找客戶不同環(huán)節(jié)的用戶進(jìn)行交流來獲取需求。召開評審會(huì)議，報(bào)告可行性分析，報(bào)告用戶原始需求，報(bào)告項(xiàng)目遠(yuǎn)景規(guī)化。需求分析階段：在客戶原始需求的基礎(chǔ)上不斷與客戶溝通，充分的熟悉和深入客戶業(yè)務(wù)，獲得充分的業(yè)務(wù)需求，完善用戶需求和功能性需求，了解客戶的相關(guān)約束而獲得非功能性需求。最終編寫《需求規(guī)格說明書》；召開需求評審會(huì)議，客戶確定需求，并簽定合同；編寫項(xiàng)目計(jì)劃說明書；編寫測試計(jì)劃；召開項(xiàng)目啟動(dòng)會(huì)議，項(xiàng)目正式啟動(dòng)。概要設(shè)計(jì)階段：根據(jù)《需求分析說明書》，進(jìn)行用例分析,獲得充分而有效的用例。編寫界面原型，編寫編碼規(guī)范和界面風(fēng)格規(guī)范,數(shù)據(jù)庫設(shè)計(jì)規(guī)范。用uml工具畫用例圖，編寫有效的用例規(guī)約文檔。詳細(xì)設(shè)計(jì)階段：根據(jù)完整的用例及需求進(jìn)行分析，獲得數(shù)據(jù)庫所需的相關(guān)信息,畫數(shù)據(jù)庫ER圖。進(jìn)行詳細(xì)的分析，用uml工具畫類圖，確定每個(gè)功能模塊的子功能，抽取項(xiàng)目的公共部分成為一個(gè)公共模塊。確定項(xiàng)目的架構(gòu)基礎(chǔ)。確定需要用到的類及類成員和方法。確定一些輔助類及方法。對每一個(gè)用例都用uml工具畫出順序圖。編寫詳細(xì)設(shè)計(jì)說明書，評審詳細(xì)設(shè)計(jì)說明書, 進(jìn)行基礎(chǔ)框架搭建。列出任務(wù)清單，進(jìn)行任務(wù)分配。編碼階段：以小組的形式進(jìn)行代碼編寫，編寫單元測試用例，每完成一個(gè)類都要進(jìn)行單元測試。每完成一個(gè)功能點(diǎn)和模塊都要進(jìn)行集成測試。確保每一個(gè)功能點(diǎn)和模塊完成后都是一個(gè)可以看得見、摸得著的產(chǎn)品。而不是等到最后才進(jìn)行統(tǒng)一的調(diào)試和搭配。每天都要對代碼進(jìn)行檢查和優(yōu)化，也就是所謂的重構(gòu)。測試階段：根據(jù)測試計(jì)劃對項(xiàng)目進(jìn)行系統(tǒng)測試，以及用戶的驗(yàn)收測試產(chǎn)品發(fā)布：交付完整的產(chǎn)品和設(shè)計(jì)文檔。把產(chǎn)品布署到客戶的計(jì)算機(jī)上,確保產(chǎn)品的正常運(yùn)行?？蛻艉炇?。維護(hù)階段：為客戶提供技術(shù)保障，對產(chǎn)品進(jìn)行相應(yīng)的維護(hù)和升級工作 軟件常見開發(fā)模型瀑布模型：最經(jīng)典的過程模型，適用于需求明確，規(guī)模較小的項(xiàng)目 噴泉模型：迭代，無間隙特點(diǎn)，適用于面向?qū)ο蟮能浖_發(fā)過程 螺旋模型：MSF模型：微軟解決方案過程模型什么是極限(XP)編程：極限編程是對敏捷軟件開發(fā)方法的一種實(shí)現(xiàn)。它強(qiáng)調(diào)測試先行，也就是在編寫代碼的時(shí)候先編寫測試用例。循環(huán)迭代，每一次迭代都是一個(gè)可用的產(chǎn)品；重構(gòu)，不斷的對代碼進(jìn)行優(yōu)化；結(jié)對編程，兩個(gè)人為一對共同進(jìn)行代碼編寫；它強(qiáng)調(diào)團(tuán)隊(duì)之間的知識傳播，讓團(tuán)隊(duì)的每個(gè)人都能熟悉軟件開發(fā)的各種技術(shù)。如：支持熟悉數(shù)據(jù)庫的人去做界面，做界面的人去做數(shù)據(jù)庫等，通過不定期的角色轉(zhuǎn)換來增強(qiáng)團(tuán)隊(duì)的能力。要求客戶參與到軟件開發(fā)中來,開發(fā)出最適合客戶需求的產(chǎn)品。單元測試一般是在編碼的時(shí)候同步進(jìn)行的，一般是以類為單位進(jìn)行測試，當(dāng)一個(gè)類完成了編碼，并編譯正確后才進(jìn)行的測試，測試這個(gè)類是否已經(jīng)能夠?qū)崿F(xiàn)指定的功能。一個(gè)類能夠正常的編譯成功并不意味著這個(gè)類就已經(jīng)完成了，還要通過測試，設(shè)置斷言來確定他是否已經(jīng)達(dá)到了預(yù)期的效果，實(shí)現(xiàn)了特定的功能。調(diào)試，編譯通過只能證明代碼的語法沒有錯(cuò)誤。單元測試由程序員自己來進(jìn)行，也可以在項(xiàng)目小組內(nèi)交互進(jìn)行。單元測試是采用白盒測試 集成測試一般指實(shí)現(xiàn)了一個(gè)功能點(diǎn)或一個(gè)模塊后,為了測試這個(gè)模塊是否已經(jīng)實(shí)現(xiàn)了需求要求的功能。集成測試可能需要對多個(gè)類進(jìn)行組裝，也可能需要與以前已經(jīng)測試通過的模塊進(jìn)行組裝，是對產(chǎn)品組件的系統(tǒng)整合和執(zhí)行。集成測試可以根據(jù)模塊的大小分不同的級別，在現(xiàn)行的軟件開發(fā)中，每完成一個(gè)功能模塊都必須要進(jìn)行一次集成測試，使得你完成的模塊是一個(gè)可以運(yùn)行的產(chǎn)品。集成測試一般可以由項(xiàng)目小組的負(fù)責(zé)人（或指定一個(gè)小組成員）來完成。集成測試采用白盒式測試和黑盒測試系統(tǒng)測試一般指項(xiàng)完代碼已經(jīng)全部完成，交給測試小組來進(jìn)行測試。進(jìn)行系統(tǒng)測試的人員獨(dú)立于開發(fā)小組，系統(tǒng)測試人員把完成的產(chǎn)品布署在相應(yīng)的計(jì)算機(jī)環(huán)境中，按照測試計(jì)劃進(jìn)行測試，驗(yàn)證系統(tǒng)是否滿足了指定的需求。系統(tǒng)測試除了測試產(chǎn)品應(yīng)滿足基本的功能需求外，還要對產(chǎn)品的性能，用戶界面，安全性，壓力，可靠性，安裝和反安裝等幾個(gè)方面進(jìn)行測試 系統(tǒng)測試采用黑盒測試驗(yàn)收測試一般指產(chǎn)品交付給客戶，負(fù)責(zé)把產(chǎn)品布署在指定的計(jì)算機(jī)環(huán)境中。由用戶根據(jù)需求文檔，進(jìn)行的總體測試。驗(yàn)收測試的內(nèi)容和系統(tǒng)測試一樣，只是執(zhí)行者不同。都是除了測試系統(tǒng)完成基本功能外還要對性能，安全性，可靠性等進(jìn)行測試。驗(yàn)收測試也是采用黑盒測試 為什么需要測試？測試是對軟件質(zhì)量的保證，只能通過嚴(yán)格測試的軟件才是合格的軟件，測試并不是說讓軟件能夠編譯通過，測試是讓軟件產(chǎn)品最大程度的滿足客戶的需求度?；卮饘?shí)例：考官：令狐沖，能談?wù)勀銈兪窃趺礃訉@個(gè)項(xiàng)目開發(fā)的嗎？令狐沖：首先，我們這個(gè)項(xiàng)目已經(jīng)有了一個(gè)基本的用戶原始需求。但這是不夠的，我們都知道需求分析是十分重要的，所以我們在用戶原始需求文檔的基礎(chǔ)上，再次進(jìn)行了分析，通過不斷的與客戶溝通，充分的了解和熟悉用戶的業(yè)務(wù)，完