軟件開發(fā)流程

1、快視信息軟件開發(fā)流程規(guī)范：用戶需求： 軟件項(xiàng)目首先由客戶經(jīng)理 （CM，Custom Management） 接洽客戶的較大的需求。 這時(shí)的需求叫市 場需求（或叫用戶需求） ，客戶經(jīng)理會(huì)進(jìn)行各個(gè)項(xiàng)目的安排，即對(duì)項(xiàng)目的啟動(dòng)時(shí)間和發(fā)布時(shí)間進(jìn)行規(guī)劃和 設(shè)置。項(xiàng)目經(jīng)理 （PM ，Project Management） 對(duì)客戶經(jīng)理負(fù)責(zé)。項(xiàng)目經(jīng)理的需求是根據(jù)客戶經(jīng)理給的，項(xiàng)目經(jīng)理不 和用戶（客戶）直接接觸（通過客戶經(jīng)理接觸） ，負(fù)責(zé)和用戶進(jìn)行需求洽談和溝通的是客戶經(jīng)理。一個(gè)項(xiàng) 目的需求在一般情況下是不準(zhǔn)變更的，如果有需求理解方面的不清楚可以進(jìn)行溝通，但是需求是不變更 的。如果用戶有新的需求，一般規(guī)劃在下一個(gè)

2、版本中。因?yàn)樾枨笞兏?，這個(gè)目的時(shí)間就要進(jìn)行調(diào)整， 就不能按計(jì)劃進(jìn)行和完成?？蛻艚?jīng)理提交給項(xiàng)目經(jīng)理的是 需求規(guī)格說明書 。一、項(xiàng)目開工會(huì) 在項(xiàng)目經(jīng)理領(lǐng)到客戶經(jīng)理分配給的需求后，做 項(xiàng)目計(jì)劃 ，具體做項(xiàng)目人員的確定、需求的分解（需求分 解到每個(gè)人） 、代碼量的估計(jì)，項(xiàng)目各個(gè)階段時(shí)間的劃分和工作量的計(jì)劃、質(zhì)量指標(biāo)的設(shè)定。這時(shí)項(xiàng)目經(jīng) 理需要輸出的文檔是 項(xiàng)目需求分解任務(wù)書、項(xiàng)目計(jì)劃PPT及做好整個(gè)項(xiàng)目需要填寫的一系列表格。然后組織項(xiàng)目組成員和客戶經(jīng)理 CM、QA（質(zhì)量審計(jì)經(jīng)理）進(jìn)行項(xiàng)目開工會(huì)。這時(shí)這個(gè)項(xiàng)目就算真正啟動(dòng)，計(jì)算 工作量時(shí)，即計(jì)算這個(gè)項(xiàng)目總共花了多少個(gè)工時(shí)，工時(shí)是項(xiàng)目經(jīng)理做計(jì)劃的時(shí)間也算在

3、內(nèi)，再加上項(xiàng)目 開工會(huì)和后續(xù)各個(gè)階段總共花的總工時(shí)數(shù)，還有各個(gè)階段開會(huì)所花的時(shí)間。在項(xiàng)目開工會(huì)上，各個(gè)成員 就明確了這個(gè)項(xiàng)目是屬于增強(qiáng)型項(xiàng)目，還是其他項(xiàng)目的項(xiàng)目性質(zhì)，增強(qiáng)型項(xiàng)目的意思是說在原來上一版 本的基礎(chǔ)上又根據(jù)新的需求進(jìn)行增強(qiáng)型開發(fā)。還有要明確項(xiàng)目最后開發(fā)出的新增代碼量有多少，最后要 明確每個(gè)人的需求任務(wù)，接下來著手進(jìn)行SRS的寫作。二、SRS階段： System/Software Requirment Specification軟件需求規(guī)格說明在項(xiàng)目開工會(huì)后，項(xiàng)目組就開始按照在項(xiàng)目開工會(huì)上項(xiàng)目經(jīng)理的需求任務(wù)分解的任務(wù)開始進(jìn)行SRS的寫作。一般項(xiàng)目經(jīng)理給你的一個(gè)子需求任務(wù)，你這時(shí)需要分解

4、為更小的需求。一般一個(gè)需求的寫作是按這樣進(jìn) 行的。先簡單介紹這個(gè)需求，然后把這個(gè)需求設(shè)計(jì)成黑盒的形式，即輸入，處理過程、輸出。這些都需 要寫詳細(xì)，任何一個(gè)需求都寫成這種形式，輸入是什么，處理過程是什么，輸出結(jié)果是什么。處理過程 需要用Visio或者PPT畫出處理流程圖，流程圖要很詳細(xì)。每一步的各種情況都要表示和考慮到。對(duì)異常 情況也要考慮和進(jìn)行處理。還有要說明在原來的基礎(chǔ)上怎么改動(dòng)，具體方法要進(jìn)行說明。設(shè)計(jì)的數(shù)據(jù)庫 表結(jié)構(gòu)，要給出腳本，SQL語句，表結(jié)構(gòu)需說明每個(gè)字段，哪些是主鍵，你在這個(gè)需求處理過程中哪里使 用了哪些表，需要進(jìn)行哪些操作，都需要說明。這里需要設(shè)計(jì)和編制數(shù)據(jù)庫設(shè)計(jì)說明書 文檔。

5、該文檔中描述該系統(tǒng)中設(shè)計(jì)出的所有的數(shù)據(jù)庫表結(jié)構(gòu)和各字段類型。還有多個(gè)操作對(duì)象要畫序列圖表示出按 時(shí)序的處理過程。這個(gè) SRS文檔就相當(dāng)于我們平時(shí)畢業(yè)設(shè)計(jì)或者一個(gè)題目的詳細(xì)設(shè)計(jì)階段達(dá)到的水平， 甚至比它更詳細(xì)。每個(gè)項(xiàng)目組成員都把自己的需求的SRS文檔寫出來之后放到配置庫中，然后每個(gè)人對(duì)項(xiàng)目組其他成員的（非自己的）SRS文檔進(jìn)行Review（評(píng)審），對(duì)每個(gè)SRS文檔在每頁發(fā)現(xiàn)或者糾正的錯(cuò)誤數(shù)不能低于一定的數(shù)目， 而且要保留批注記錄，經(jīng)過Review的（保留批注的）文檔要放到配置庫的 Review 文件夾下，這是進(jìn)行項(xiàng)目質(zhì)量指標(biāo)收集的重要依據(jù)，是QA 進(jìn)行調(diào)閱和審計(jì)的資料。項(xiàng)目經(jīng)理要對(duì) SRS文檔、

6、SRS Review文檔進(jìn)行匯總。在匯總后組織項(xiàng)目組全體成員進(jìn)行SRS階段會(huì)議，對(duì)每個(gè)人寫的 SRS進(jìn)行評(píng)審會(huì)議（討論和提意見） ，對(duì)別人給你提的修改意見你要一一進(jìn)行說明，說明為什么不改，怎么改 的，是什么問題，問題嚴(yán)重程度屬于什么級(jí)別，而且都要填表，也是QA進(jìn)行審計(jì)的內(nèi)容。開完會(huì)后如果每個(gè)人完成的都差不多，然后安排半天或者一天的時(shí)間進(jìn)行返工，主要是進(jìn)行修改文檔，按在會(huì)上討論 的結(jié)果和別人給你的 Review文檔結(jié)果（評(píng)審結(jié)果）進(jìn)行準(zhǔn)一修改和完善。然后再進(jìn)行SRS階段開會(huì)，如果都做的比較到位和具體、符合要求，即關(guān)閉SRS階段。這時(shí)SRS階段的花費(fèi)的工時(shí)數(shù)和一些質(zhì)量活動(dòng)指標(biāo)就出來了，比如你這個(gè)

7、SRS文檔寫了幾頁，每頁的錯(cuò)誤數(shù)是多少，返工修改用了多少時(shí)間，然后這 些這個(gè)比率也會(huì)自動(dòng)計(jì)算出來。進(jìn)而可以判斷這個(gè)階段的質(zhì)量。每個(gè)項(xiàng)目組成員在每天工作完畢后都要 進(jìn)行 Time Sheet 的填寫，必須具體到半個(gè)小時(shí)，這是統(tǒng)計(jì)和分析的需要。填寫必須真實(shí)。三、UTP、STP階段（UTP、STP寫作）UTPUnit Test Plan 單元測試計(jì)劃STPSystem Test Plan 系統(tǒng)測試計(jì)劃在SRS階段完成后一般安排比較很短的時(shí)間進(jìn)行UTP、STP的寫作。即單元測試計(jì)劃、系統(tǒng)測試計(jì)劃。這兩個(gè)需要輸出提交的是兩個(gè)表格。單元測試計(jì)劃按預(yù)置條件（即需要設(shè)置的先決條件）、輸入、期望的輸出、實(shí)際的輸

8、出這樣設(shè)計(jì)的表格來填。即每個(gè)單元測試用例都按這樣的黑盒測試方法來寫。另外還有一 種需要編寫測試代碼來進(jìn)行測試用例的設(shè)計(jì)，即對(duì)每個(gè)被測類需要設(shè)計(jì)一個(gè)測試類，用這個(gè)測試類來調(diào) 用和驅(qū)動(dòng)被測類的數(shù)據(jù)成員和方法，然后給出斷言。測試用例的設(shè)計(jì)同一個(gè)主要功能的要多設(shè)計(jì)幾個(gè)例 子，對(duì)異常也要設(shè)計(jì)用例進(jìn)行測試。盡可能多的覆蓋。STP 是在單元測試基礎(chǔ)之后用的，是項(xiàng)目組把產(chǎn)品交到專門的測試部門前的項(xiàng)目組的聯(lián)調(diào)和測試。這時(shí)需要寫出系統(tǒng)測試計(jì)劃。為了到后面單元測試階 段和系統(tǒng)聯(lián)調(diào)階段使用。 這兩個(gè)文檔也需要按照前面的方法和流程進(jìn)行Review（評(píng)審）、匯總、會(huì)議評(píng)審、修改返工、定稿。最后關(guān)閉這個(gè)階段。也按前面的方法

9、需要進(jìn)行所用工時(shí)的填寫。QA和PM進(jìn)行分析。QAQuality Assurance質(zhì)量保證四、SD階段System Design系統(tǒng)設(shè)計(jì)這個(gè)階段是邏輯設(shè)計(jì)階段。按照前面的SRS文檔，一般一個(gè)人連續(xù)性地負(fù)責(zé)前面PM在項(xiàng)目開工會(huì)分配給你的一個(gè)需求的各個(gè)階段的設(shè)計(jì)和其他工作。進(jìn)行LD文檔的寫作。要非常具體，比如按照前面設(shè)計(jì)出的SRS文檔中的一個(gè)需求，這個(gè)階段你需要設(shè)計(jì)出具體的數(shù)據(jù)結(jié)構(gòu)，要設(shè)計(jì)出哪些類，每個(gè)類的各個(gè)數(shù)據(jù)成員是什么，是什么類型的，每個(gè)類要設(shè)計(jì)哪些函數(shù)，函數(shù)要很具體，函數(shù)名稱、返回值，參數(shù)（輸入?yún)?數(shù)、輸出參數(shù)），該函數(shù)由誰來調(diào)用它， 它又由調(diào)用了哪些函數(shù)， 函數(shù)的具體處理過程要寫成偽碼的

10、形式。 這個(gè)階段需要使用 Ratio nal Rose畫出設(shè)計(jì)出的每個(gè)類的成員和函數(shù)。以及類之間的關(guān)系。這個(gè)階段的輸 出就是LD文檔。也按前面的方法進(jìn)行Review （評(píng)審）、匯總、會(huì)議評(píng)審、修改返工、定稿。也進(jìn)行工時(shí)的記錄和統(tǒng)計(jì)、分析。五、CODE階段SRS LD階段完成后，在 CODE編寫代碼階段）就比較容易和輕松了。只需要找到添加代碼的地方，然后 寫上標(biāo)志，比如Begin infoX - MDSP V200102 29D0I6liuyongping add（modify,delete）代碼End infoX - MDSP V200102 2-006 liuyongping add（mod

11、ify,delete）Add 表示中間這段代碼是你寫的， modify 表示是你修改的， delete 表示你把這段代碼刪除了。 然后參照前 面設(shè)計(jì)的LD文檔，編寫代碼。對(duì)每個(gè)類、每個(gè)類成員的命名都要符合規(guī)范，比如類成員以m_開頭。對(duì)每個(gè)類對(duì)象 （變量） 命名也要符合規(guī)范。 尤其需要注意指針的使用， 好的程序也是靈活使用指針的程序， 對(duì)內(nèi)存的申請、釋放一定要小心。最后編出的代碼自己首先要進(jìn)行編譯、調(diào)試、保證自己添加和負(fù)責(zé)的 這一部分編譯通過。然后正確無誤才能合入配置庫。要對(duì)合入配置庫的代碼進(jìn)行負(fù)責(zé)，因?yàn)榕渲脦熘械?代碼是大家一個(gè)項(xiàng)目一起使用的代碼，只要你的有編譯錯(cuò)誤，然后大家再此基礎(chǔ)上 Che

12、ck Out出來的代碼肯定不能編譯通過。但是邏輯錯(cuò)誤允許有，這些邏輯錯(cuò)誤在后面的單元測試和系統(tǒng)測試中會(huì)暴露出來， 到時(shí)修改掉錯(cuò)誤，重新合入配置庫。在 Code 階段，每個(gè)人完成自己的代碼寫作后，需要相互進(jìn)行代碼走 讀，代碼走讀階段能發(fā)現(xiàn)一些問題， 這些都要進(jìn)行記錄統(tǒng)計(jì)和分析， 然后要不允許留一個(gè)錯(cuò)誤地修改掉。 代碼的格式一定要符合規(guī)范，格式要對(duì)齊，需要有一個(gè)空格的地方不能沒有空格或者多一個(gè)空格。要求 很嚴(yán)，這樣代碼比較整齊、規(guī)范、可讀性強(qiáng)。對(duì)自己新設(shè)計(jì)的文件，在文件頭有說明，說明文件名，作 者，創(chuàng)建時(shí)間，修改時(shí)間，功能。對(duì)函數(shù)都要有說明：返回值，輸入?yún)?shù)、輸出參數(shù)（沒有輸出參數(shù)的 不寫該項(xiàng)），

13、功能。文件的命名也有規(guī)范。能不重新創(chuàng)建文件的就不進(jìn)行重新創(chuàng)建文件，完成同一功能的 放到同一文件中。對(duì)重要和難懂的地方可以簡明扼要地加點(diǎn)注釋說明。六、UT（ unit test ）：單元測試階段在產(chǎn)品所有代碼編譯通過的基礎(chǔ)上，按照前面的 UTP 設(shè)計(jì)的測試用例進(jìn)行測試。主要檢查主要功能性測 試用例和異常測試用例的測試結(jié)果，看是否達(dá)到了設(shè)計(jì)目的，與設(shè)計(jì)是否相否。對(duì)測試的結(jié)果要進(jìn)行記 錄和填表，反饋給代碼編寫人員，然后代碼編寫人員修改錯(cuò)誤，并把修改方法和修改結(jié)果報(bào)告給測試人 員。這個(gè)屬于項(xiàng)目組內(nèi)部自測，一般自己測自己的。一般自己測出來問題修改掉合入配置庫即可。七、ST：System Test 系統(tǒng)測

14、試階段 聯(lián)合測試，系統(tǒng)需要與其他系統(tǒng)進(jìn)行通信和連接的，這時(shí)把其他系統(tǒng)安裝好，然后與我們的系統(tǒng)進(jìn)行對(duì) 接，在配置好后，從其他系統(tǒng)進(jìn)行數(shù)據(jù)模擬和交互來測試所開發(fā)產(chǎn)品系統(tǒng)的功能和性能、結(jié)果等。記錄 測試結(jié)果，并修改錯(cuò)誤，最后合入配置庫。八、打包、歸檔、轉(zhuǎn)交測試部進(jìn)行測試 在以上各個(gè)階段完成后，且軟件系統(tǒng)的缺陷率滿足項(xiàng)目設(shè)定和要求的情況下，項(xiàng)目經(jīng)理進(jìn)行項(xiàng)目版本的 打包、歸檔，歸檔以后這個(gè)版本就不能更改了，在測試部測出 Bug 后，需要走測試電子流填單經(jīng)過測試 經(jīng)理審核、項(xiàng)目經(jīng)理審核、定位人員進(jìn)行問題定位、解決問題人員寫出修改 Bug 或者錯(cuò)誤的方法，然后 經(jīng)項(xiàng)目經(jīng)理審核修改意見和方法正確后，授權(quán)和指定

15、一個(gè)修改人員進(jìn)行修改，這時(shí)項(xiàng)目經(jīng)理會(huì)通知配置 管理人員給該修改人員開放配置庫修改權(quán)限。這個(gè)修改人修改后先自測、再讓測試部人員重新測試正確 后，最后才合入配置庫。歸檔后提交給測試部的有編譯過的代碼文件、用戶使用說明書（即如何安裝、 配置和環(huán)境的說明，讓測試部的人員模擬最終用戶使用該產(chǎn)品的軟件） 。一般測試部能發(fā)現(xiàn)很重要和大部 分Bug,在最后少于缺陷率的情況下，標(biāo)志著該產(chǎn)品軟件符合質(zhì)量。這個(gè)階段主要是測試部測試人員測試， 項(xiàng)目組人員進(jìn)行問題單的定位和修改。在經(jīng)過以上各個(gè)階段的嚴(yán)格流程后,在 QA 進(jìn)行文檔審計(jì)和質(zhì)量指標(biāo)收集、統(tǒng)計(jì)、分析后,認(rèn)為該產(chǎn)品軟 件滿足設(shè)計(jì)要求，符合 CMM質(zhì)量指標(biāo)之后，還需要有TM（測試經(jīng)理）的測試結(jié)果報(bào)告及產(chǎn)片合格報(bào)告之后,該產(chǎn)品軟件才可進(jìn)入市場,交于最終用戶使用。在產(chǎn)品上線運(yùn)行后,出現(xiàn)個(gè)別錯(cuò)誤后,可以填單, 項(xiàng)目組定位、修改后,可進(jìn)行打補(bǔ)丁。推薦使用的項(xiàng)目開發(fā)工具和管理工具如下：Visual Source Safe（VSS） 配置庫管理工具Source Insight 代碼編寫和閱讀工具,對(duì)每個(gè)類的視圖和函數(shù)代碼顯示和管理比較好。Visio 要熟練使用,會(huì)畫流程圖和對(duì)象序列圖。Rational Rose 要會(huì)使用此工具進(jìn)行畫出每個(gè)類的類圖（包括類數(shù)據(jù)成員和函數(shù)） ,及類之間的關(guān)系。Beyond Compare 代碼比較工具,查看代碼變化