軟件項目開發(fā)—管理措施

1、軟件項目開發(fā)一一管理措施在一個軟件產(chǎn)品發(fā)布并使用之后，其屮肯定有許多地方不如意和值得改進的地方?？蛻?在使用的過程小會發(fā)現(xiàn)一些問題，提出更高的需求，市場也在發(fā)生變化，我們的競爭對手也 在發(fā)展，新的技術不斷地產(chǎn)牛，這些因素推動著我們的產(chǎn)品不斷地向前發(fā)展，使軟件版本不 停地往上增長。這些發(fā)展的需求不是一卜子提出來的，在客戶使用的過程屮發(fā)現(xiàn)某些不如意 不方便的地方，他們會向我們提出寶貴的意見，而技術人員會把這些需求記錄下來，以便修 改或成為下一個版木的新特性或需求。一個軟件的開發(fā)主要分為需求、設計、編碼、測試、維護幾個重要的階段，下面就每個 階段的一些管理措施提點愚見：1. 需求管理在進入正式開發(fā)之

2、詢，必須先從用八處獲取準確的需求。在這上而花費相當時間是很必 要的。在軟件項目的開發(fā)過程中，需求變更貫穿了軟件項目的整個牛命周期，從軟件的項目 立項，研發(fā)，維護，用戶的經(jīng)驗在增加，對使用軟件的感受冇變化，以及整個行業(yè)的新動態(tài), 都為軟件帶來不斷完善功能,優(yōu)化性能，提高用八友好性的要求。在軟件項目管理過程中，項目經(jīng) 理經(jīng)常而對用戶的需求變更。如果不能有效處理這些需求變更，項tj計劃會一再調(diào)整，軟件 交付li期一再拖延，項1=1研發(fā)人員的士氣將越來越低落，將直接導致項1=1成本增加、質(zhì)量下 降及項目交付h期推后。這決尬了項目組必須擁有需求管理策略。在整個開發(fā)周期中期望用戶的需求一 克保持不變是不大

3、可能的，因為用 戶對于如何應用計算機軟件并沒有一個成熟的經(jīng)驗。需求變化的原因很多，女ii：一開始沒冇調(diào)研全，盂要增加需求； 客戶需求發(fā)牛了變化，需求必須變化； 需求錯謀；需求不清楚。基于上述的問題，必須對需求進行管理，使需求能夠其正成為軟件 工程和管理的棊線。一種比較明押的方法是在簽定開發(fā)合同（i辦議）時把用戶需求的改動和 經(jīng)濟利益掛鉤，如果用八增加或改動了需求，那么軟件的交付日期町以推遲，費用也應增加。需求是一項復雜的工作，使用的方法也很多，不同的開發(fā)方式有不 同的方法，這里簡單介紹一些相關的方法：可行性分析：在允許的成本、性能耍求下，分析每項需求實施的可行性, 提出需求實現(xiàn)相關風險，包括與

4、其它需求的沖突，對外界因素的依賴和技術障礙。快速原型：當用戶自身對有的需求不十分清楚時，我們可以建立一 個系統(tǒng)原型，用戶通過評價原型更好地理解所要解決的問題。圖形分析模型：繪制圖形分析模型是編制軟件需求規(guī)格說明重要手段。 它們能幫助分析人員理清數(shù)據(jù)、業(yè)務模式、工作流程以及他們之間的關系，找出遺漏、兀余 和不一致的需求。這樣的模型包括數(shù)據(jù)流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類 及交互作用圖。數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保 開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項，確?？蛻襞c 開發(fā)小組是使用一致的定義和術語。2. 設計管理項目經(jīng)理

5、把功能模塊分配給每個開發(fā)人員，每個開發(fā)人員把自己相關的 功能模塊收集起來，同時預估時間，其中主要包括寫文檔的時間、開發(fā)時間和單元測試的時 間，一般要求精確到丄作日。這些信息返回給項冃經(jīng)理，項冃經(jīng)理再把本小組人員的任務和 預估時間發(fā)送給管理層，由管理層對此任務及進度進行評估審核，管理層會根據(jù)產(chǎn)殆發(fā)布時 間及客戶蠱求、市場因索等方面作出選擇，可能某些功能市-丁時間緊急會被推遲到下一個版 本小去。若預估出來的時間同預計的產(chǎn)品發(fā)布時間冇較大沖突，而fu匕功能是本版本中必須 得做的，則開發(fā)小組會被耍求重新預佔時間，加快開發(fā)速度來達到這個耍求。雖然這個開發(fā)進度時間是一個人概的估計時間，但我們要盡力按照這個

6、 開發(fā)進度來執(zhí)行。作為開發(fā)人員每個星期寫一篇周記，描述自己本周所做的工作，根據(jù)自己 的描述來評估我們口 c的工作，每個人手上的工作是否按照這個進度在走，是否有人延后了, 是否延謀了別人的工作。在周記里每個人都要報告自己的進度，同時還要報告上個星期做了 什么，止在做什么，以及下個星期打算做什么。通過這個周記，會讓你覺得有人在監(jiān)督你, 無形之中迫使你不斷地督促自己不要使任務延厲，如果有延厲的跡象也會盡早發(fā)現(xiàn)而趕上。 若某些經(jīng)過努力不能趕上，那也沒有辦法，只能修改原先的進度表，因為那是我們的估計與 現(xiàn)實發(fā)生了偏差，我們必須使我們的進度表符合實際情況。3. 編碼管理進入編碼工作z后，可能會發(fā)現(xiàn)前面分析

7、或設計階段的某些錯誤，這時 應返冋到前面的階段進行必要的修改。由于我們用(c#)語言進行開發(fā)，因此我們借助 t vs2005 i具。關于代碼風格，我們基本上套用vs2005中自動的代碼格式編排。良好的 編碼習慣有利于我們捉高整個團対的開發(fā)效率，比如變量的命名、寫代碼時要對類及函數(shù)提 供詳細的注釋及說明等，基本做到看它們的說明就能知道這個變量、類或函數(shù)的功能以及主 要算法的實現(xiàn)原理。在開發(fā)過程中對主要的模塊要編寫單-元測試，同時要單-元測試先行，當 所有的單元測試代碼通過時，此功能也就基本上完成了。我們采用vss進行代碼管理控制，其中存放了此產(chǎn)品的所有源代碼， 各個部分存放在不同的目錄中。每天早

8、上要求開發(fā)人員從vss中獲取最新的源代碼，然后 進行編譯并開始一天的工作。在下班之詢理論上要求員工簽入所有當天修改的代碼，在簽入 z前要保證編譯是能通過的。若有誰簽入的代碼導致運行失敗則會被要求某些懲罰措施或警 告。冇時我們編寫的代碼涉及到多個文件，而此改動是比較復雜需要尼費多天的工作量, 如果現(xiàn)在簽入進去可能會導致項目測試通不過，因為有些代碼沒有完全完成，而之前的代碼 能測試通過，而h這些代碼基本上不會涉及到他人，在這種情況下可以不簽入進去，直到全 部代碼完成能提交測試時再一起簽入進去。我們的開發(fā)是基于網(wǎng)絡的，在互聯(lián)網(wǎng)高速發(fā)展的今天，代碼的安全也是 一個不容忽視的問題，我們要注意代碼的泄漏和

9、丟火，除了掌握一些基本的女全知識以外, 還耍進行代碼的備份(局域網(wǎng)備份和存儲設備備份)，這樣在出現(xiàn)意外的情況下可以及時的 恢復系統(tǒng)的正常運行。4. 測試管理在開發(fā)人員完成了功能模塊后，測試人員開始了測試規(guī)劃，確定需耍測 試哪些方面，如何測試及進度安排。測試人員需要寫許多測試用例、測試報告等，有些測試 代碼需要集成測試，有些可能需要進行單-獨的測試，tj的都是為了使產(chǎn)品符合要求，使開發(fā) 人員容易找出問題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測試人員決定 的，因此測試人員也比較辛苦，責任重大。通過了每天的測試，還冇一些性能測試、兼容性 測試、災難測試等需要在產(chǎn)品發(fā)布前進行。在完成這些

10、測試z后由測試人員決定本產(chǎn)品是否 能發(fā)布出去了。市于我們每天進行著測試，因此經(jīng)常有bug被測試人員發(fā)現(xiàn)，一旦發(fā) 現(xiàn)了新的bug,就會被添加進測試報告中，同時注明緊急程度，以便開發(fā)人員可以及時進 行錯誤bug的修改。需要指出的是我們對bug的定義比較廣泛，一些新功能也町以作為 bug被提出，只不過這些bug級別比較低，讓它們進入到下一個版本中去實現(xiàn)。因此bug 的創(chuàng)建者也可以是技術支持人員、審場人員其至開發(fā)人員木身。關于開發(fā)人員本身，因為他 可能會找出一些bug,有些是其他開發(fā)者的，有些可能是此開發(fā)者本身的，把這個bug添 加進測試報告中可以幫助開發(fā)人員在以后產(chǎn)生新問題時或類似的bug時有一個借

11、鑒和思 路。5. 維護管理后期的軟件維護和管理也是一個非常重要的任務。定期的升級服務 和培訓會讓客戶對軟件有個良好的映像。6. 組織（團隊）管理軟件項目開發(fā)過程屮注重的是團隊精神的發(fā)揮，我們的目標是一個軟 件、系統(tǒng)而不是幾個模塊的簡單組合。在軟件開發(fā)傳理中，不能采用明令制度的方式來要求 何限制開發(fā)人員，必須要有辦法激勵人的內(nèi)動力，而激勵人的內(nèi)動力最好的辦法是將付出和 收益緊密的結合。團隊精神的凝聚主要的是信任與尊重。正所謂“用人不疑，疑人不用”， 如果沒有基本的尊重與信任，哪里來的凝聚力，何謂團隊精神？軟件項1=1開發(fā)人員應該本著態(tài)度第一、效率優(yōu)先的工作原則，在平時的 fi常工作和?；钪?，大腦

12、的休息和充足的睡眠可以保證開發(fā)人員有個良好的心態(tài)和精力。也 許在it行業(yè)來說，程序員加班已經(jīng)成為-種佳話，-種習俗，但我們要制止長期的加班和 無效率的加班，在項目不緊張或者無項目的情況下可以適當?shù)姆潘?、休息來調(diào)節(jié)個人的情緒 和精力。作為軟件開發(fā)人員的人部分時間是在公司里度過的，因此公司的生活成 了大家主要組成部分。員工z間關系的融洽，交流的暢通顯得非常重要，同時大家也不想自 己的生活這樣枯燥乏味，一直同機器打交道。溝通無處不在，交流隨時發(fā)生，有許多關系是 在工作之外建立起來的。軟件公司內(nèi)是很容易產(chǎn)生各種矛質(zhì)的，因為這是由你的工作性質(zhì)所 決定的，比如測試人員或用戶會對你的實現(xiàn)不滿意，提出各種要求

13、時，我相信你有時會有所 抱怨的，無形z中就產(chǎn)生了對立，發(fā)展到后來會有抵觸心理。我相信大部分人都會有此感受, 這不是你的錯，這主要是由我們的工作性質(zhì)決定的。如果你的工作是把財富帶給對方，則對 方會非常歡迎你的到來，把你奉為財神爺來對待，同你的關系會非常融洽友好。因此我們需 要在工作之外來消除這種對立才盾的關系，建立一種融洽的工作氛i羽。我們在平時吃飯的時 候飯桌上大家互相聊天溝通，說一些幽默笑話z類的，給我們緊張的工作增加點輕松的氛圍。 隔斷時間大家可以組織一下活動，增加了公司的凝聚力。一個產(chǎn)品發(fā)布后組織一次活動，讓 繃緊的神經(jīng)松弛一下，更好地迎接下一個挑戰(zhàn)。團隊的每個成員都會養(yǎng)成寫blog的習

14、慣。經(jīng)常寫寫blog, 一是可以讓 人家都知道自己在做什么事情，二是項日結束時方便寫最后的工作總結（許多工作自己當時 不紀錄也忘記了），三是利于提高自己的水平（工作和學習寫點總結會系統(tǒng)的總結和歸納思 路，進步很快）。附件：1. c#編碼規(guī)范.doc2. 個人周記.doc3. 項目組周報.doc4. 項目總結報告.doc5. 測試文件.xls軟件項目開發(fā)管理措施e立方丄作室（）收藏于2010-01 -22閱讀數(shù)：275被轉藏：5公眾公開轉藏到我的圖書館 推薦給朋友舉報如果您在該網(wǎng)頁中發(fā)現(xiàn)冇色情、暴力、反動等不良內(nèi)容，請聯(lián)系我們：最近老板讓我做一 個軟件項目組的管理措施，搜集了多方資料和平時的 一

15、些經(jīng)驗得出以下的一些知識：在一個軟件產(chǎn)品發(fā)布并使用之后，其中肯定有許多地方不如意和值得改 進的地方?？蛻粼谑褂玫倪^程屮會發(fā)現(xiàn)一些問題，提出更高的需求，市場也在發(fā)生變化，我 們的競爭對手也在發(fā)展,新的技術不斷地產(chǎn)生，這些因素推動著我們的產(chǎn)品不斷地向前發(fā)展, 使軟件版本不停地往上增長。這些發(fā)展的需求不是一下子提出來的，在客八使用的過程中發(fā) 現(xiàn)某些不如意不方便的地方，他們會向我們提出寶貴的意見，而技術人員會把這些需求記錄 下來，以便修改或成為下一個版本的新特性或需求。一個軟件的開發(fā)主要分為需求、設計、編碼、測試、維護兒個重要 的階段，下面就每個階段的一些管理措施提點愚見：1. 需求管理在進入正式開發(fā)

16、之前，必須先從用戶處獲取準確的需求。在這上而花費 相當時間是很必要的。在軟件項目的開發(fā)過程屮，需求變更貫穿了軟件項目的整個生命周期, 從軟件的項目立項，研發(fā)，維護，用戶的經(jīng)驗在增加，對使用軟件的感受有變化，以及整個 行業(yè)的新動態(tài)，都為軟件帶來不斷完善功能,優(yōu)化性能，提髙用八友好性的要求。在軟件項tj管理過程中，項目經(jīng) 理經(jīng)常面對用戶的需求變更。如果不能有效處理這些需求變更，項id計劃會一再調(diào)整，軟件 交付口期一再拖延，項h研發(fā)人員的士氣將越來越低落，將直接導致項h成本增加、質(zhì)量下 降及項目交付口期推后。這決定了項目組必須擁有需求管理策略。在整個開發(fā)周期中期望用戶的需求一直保持不變是不人可能的，

17、因為用 戶對于如何應用計算機軟件并沒有一個成熟的經(jīng)驗。需求變化的原因很多，女口：一開始沒有調(diào)研全，需耍增加需求； 客戶需求發(fā)生了變化，需求必須變化； 需求錯謀；需求不清楚?；谏鲜龅膯栴}，必須對需求進行管理，使需求能夠真止成為軟件 工程和管理的基線。一種比較明智的方法是在簽定開發(fā)合同（協(xié)議）時把用戶需求的改動和 經(jīng)濟利益掛鉤，如來用八增加或改動了需求，那么軟件的交付日期可以推遲，費用也應增加。需求是一項復雜的工作，使用的方法也很多，不同的開發(fā)方式有不 同的方法，這里簡單介紹一些相關的方法：可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性, 提出需求實現(xiàn)相關風險，包括與其它需求的沖

18、突，對外界因索的依賴和技術障礙。快速原型：當用戶口身對有的需求不十分清楚時，我們可以建立一 個系統(tǒng)原型，用戶通過評價原型更好地理解所要解決的問題。圖形分析模型：繪制圖形分析模型是編制軟件需求規(guī)格說明重要手段。 它們能幫助分析人員理清數(shù)據(jù)、業(yè)務模式、工作流程以及他們z間的關系，找出遺漏、冗余 和不一致的需求。這樣的模型包括數(shù)據(jù)流圖、實體關系圖、狀態(tài)變換圖、對話框圖、對象類 及交互作用圖。數(shù)據(jù)字典：數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保 開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在盂求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項，確?？蛻襞c 開發(fā)小組是使用一致的定義和術語。2. 設計管理項目經(jīng)理把功能模塊分

19、配給每個開發(fā)人員，每個開發(fā)人員把自己相關的 功能模塊收集起來，同時預估時間，其中主要包括寫文檔的時間、開發(fā)時間和單元測試的時 間，一般要求精確到工作日。這些信息返冋給項tj經(jīng)理，項1=1經(jīng)理再把木小纟r人員的任務和 預估時問發(fā)送給管理層，由管理層對此任務及進度進行評估審核，管理層會根據(jù)產(chǎn)吊發(fā)布時 間及客戶需求、市場因素等方面作出選擇，可能某些功能由于時間緊急會被推遲到下一個版 本中去。若預估出來的時間同預計的產(chǎn)品發(fā)布時間有較大沖突，而口此功能是本版本中必須 得做的，則開發(fā)小組會被要求重新預估時間，加快開發(fā)速度來達到這個要求。雖然這個開發(fā)進度時間是一個人概的估計時間，但我們要盡力按照這個 開發(fā)進

20、度來執(zhí)行。作為開發(fā)人員每個星期寫一篇周記，描述自己本周所做的工作，根據(jù)自己 的描述來評佔我們口己的工作,每個人手上的工作是否按照這個進度在走，是否有人延后了, 是否延誤了別人的工作。在周記里每個人都要報告口 c的進度，同時述要報告上個星期做了 什么，正在做什么，以及下個星期打算做什么。通過這個周記，會讓你覺得有人在監(jiān)督你, 無形z中迫使你不斷地督促口己不要使任務延后，如果有延后的跡彖也會盡早發(fā)現(xiàn)而趕上。 若某些經(jīng)過努力不能趕上，那也沒冇辦法，只能修改原先的進度表，因為那是我們的估計與 現(xiàn)實發(fā)牛了偏差，我們必須使我們的進度表符合實際情況。3. 編碼管理進入編碼工作之后，可能會發(fā)現(xiàn)前而分析或設計階

21、段的某些錯謀，這時 應返冋到前而的階段進行必要的修改。山于我們用(c#)語言進行開發(fā)，因此我們借助 t vs2005 i具。關于代碼風格，我們基本上套用vs2005中自動的代碼格式編排。良好的 編碼習慣有利于我們提高整個團對的開發(fā)效率，比如變量的命名、寫代碼時耍對類及函數(shù)提 供詳細的注釋及說明等，基本做到看它們的說明就能知道這個變量、類或函數(shù)的功能以及主 要算法的實現(xiàn)原理。在開發(fā)過程中對主要的模塊要編寫單元測試，同時要單元測試先行，當 所冇的單元測試代碼通過時，此功能也就棊本上完成了。我們采用vss進行代碼管理控制，其中存放了此產(chǎn)品的所有源代碼， 各個部分存放在不同的目錄中。每天早上要求開發(fā)人

22、員從vss中獲取最新的源代碼，然后 進行編譯并開始一天的工作。在下班z前理論上要求員工簽入所有當入修改的代碼，在簽入 z前要保證編譯是能通過的。若冇誰簽入的代碼導致運行失敗則會被要求某些懲罰扭施或警 告。有時我們編寫的代碼涉及到多個文件，而口此改動是比較復雜需?；ㄙM多天的工作量, 如果現(xiàn)在簽入進去對能會導致項目測試通不過，因為有些代碼沒有完全完成，而之前的代碼 能測試通過，而且這些代碼基木上不會涉及到他人，在這種情況下可以不簽入進去，直到全 部代碼完成能提交測試時再一起簽入進去。我們的開發(fā)是基于網(wǎng)絡的，在互聯(lián)網(wǎng)高速發(fā)展的今天，代碼的安全也是 一個不容忽視的問題，我們耍注意代碼的泄漏和丟失，除了

23、拿握一些基本的安全知識以外, 述要進行代碼的備份(局域網(wǎng)備份和存儲設備備份)，這樣在出現(xiàn)意外的情況卜以及時的 恢復系統(tǒng)的正常運行。4. 測試管理在開發(fā)人員完成了功能模塊后，測試人員開始了測試規(guī)劃，確定需要測 試哪些方面，如何測試及進度安排。測試人員需要寫許多測試用例、測試報告等，有些測試 代碼需要集成測試，有些可能需要進行單-獨的測試，tj的都是為了使產(chǎn)品符合要求，使開發(fā) 人員容易找出問題所在并改正。產(chǎn)品功能是否符合了要求，是否能被發(fā)布是由測試人員決定 的，因此測試人員也比較辛苦，責任重大。通過了每天的測試，還冇一些性能測試、兼容性 測試、災難測試等需要在產(chǎn)品發(fā)布前進行。在完成這些測試z后由測

24、試人員決定本產(chǎn)品是否能發(fā)布出去了。由于我們每天進行著測試，因此經(jīng)常有bug被測試人員發(fā)現(xiàn)，一旦發(fā) 現(xiàn)了新的bug,就會被添加進測試報告中，同時注明緊急程度，以便開發(fā)人員可以及時進 行錯謀bug的修改。需要指出的是我們對bug的定義比較廣泛，一些新功能也可以作為 bug被提出，只不過這些bug級別比較低，讓它們進入到下一個版本中去實現(xiàn)。因此bug 的創(chuàng)建者也可以是技術支持人員、市場人員甚至開發(fā)人員木身。關于開發(fā)人員本少，因為他 可能會找出一些bug,冇些是其他開發(fā)者的，冇些可能是此開發(fā)者本身的，把這個bug添 加進測試報告中可以幫助開發(fā)人員在以后產(chǎn)牛新問題時或類似的bug時有一個借鑒和思 路。5

25、. 維護管理后期的軟件維護和管理也是一個非常重要的任務。定期的升級服務 和培訓會讓客戶對軟件冇個良好的映像。6. 組織（團隊）管理軟件項目開發(fā)過程中注重的是團隊精神的發(fā)揮，我們的bl標是一個軟 件、系統(tǒng)而不是兒個模塊的簡單組介。在軟件開發(fā)管理屮，不能采用明令制度的方式來要求 何限制開發(fā)人員，必須要有辦法激勵人的內(nèi)動力，而激勵人的內(nèi)動力最好的辦法是將付出和 收益緊密的結合。團隊精神的凝聚主要的是信任與尊重。正所謂“用人不疑，疑人不用”， 如果沒有基本的尊重與信任，哪里來的凝聚力，何謂團隊精神？軟件項1=1開發(fā)人員應該木著態(tài)度第一、效率優(yōu)先的工作原則，在平時的 口常工作和生活中，大腦的休息和充足的

26、睡眠可以保證開發(fā)人員冇個良好的心態(tài)和精力。也 許在1t行業(yè)來說，程序員加班已經(jīng)成為一種佳話，一種習俗，但我們耍制止長期的加班和 無效率的加班，在項目不緊張或者無項目的情況卜-可以適當?shù)姆潘?、休息來調(diào)節(jié)個人的情緒 和精力。作為軟件開發(fā)人員的大部分時間是在公司里度過的，因此公司的生活成 了大家主要組成部分。員工z間關系的融洽，交流的暢通顯得非常重要，同時大家也不想口 c的生活這樣枯燥乏味，一百同機器打交道。溝通無處不在，交流隨時發(fā)生，有許多關系是 在工作之外建立起來的。軟件公司內(nèi)是很容易產(chǎn)生各種才盾的，因為這是由你的工作性質(zhì)所 決定的，比如測試人員或用戶會對你的實現(xiàn)不滿意，提出各種耍求時，我相信你

27、有時會有所 抱怨的，無形z中就產(chǎn)牛了對立，發(fā)展到后來會有抵觸心理。我相信大部分人都會有此感受, 這不是你的錯，這主要是由我們的工作性質(zhì)決定的。如果你的工作是把財富帶給對方，則対 方會非常歡迎你的到來，把你奉為財神爺來對待，同你的關系會非常融洽友好。因此我們需 要在工作之外來消除這種對立才盾的關系，建立一種融洽的工作氛圍。我們在平時吃飯的時 候飯桌上大家互相聊天溝通，說一些幽默笑話z類的，給我們緊張的工作增加點輕松的氛圍。 隔斷時間大家可以組織一下活動，增加了公司的凝聚力。一個產(chǎn)品發(fā)布后組織一次活動，讓 繃緊的神經(jīng)松弛一下，更好地迎接下一個挑戰(zhàn)。團隊的每個成員都會養(yǎng)成寫blog的習慣。經(jīng)常寫寫b

28、log, 一是可以讓 人家都知道自己在做什么事情，二是項日結束時方便寫最后的工作總結（許多工作自己當時 不紀錄也忘記了），三是利于提高自己的水平（工作和學習寫點總結會系統(tǒng)的總結和歸納思 路，進步很快）。附件：1. c#編碼規(guī)范.doc2. 個人周記.doc3. 項目組周報doc4. 項日總結報告.doc5. 測試文件.xls軟件項目開發(fā)流程以及人員職責實行軟件工程項目管理： 項目經(jīng)理（負責人）：項目經(jīng)理（負責人）對整個項目負完全責任，是指導、控制、管 理和規(guī)范某個軟件和軟/硬件系統(tǒng)建設的人，項目經(jīng)理（負責人）是授終對客戶負責的人。 軟件項日經(jīng)理（負責人）：軟件項目經(jīng)理（負責人）對一個項目的所有

29、軟件活動負完全 責任，控制一個項id的所有軟件資源，按照軟件約定與項id經(jīng)理（負責人）打交道。 軟件工程組：軟件工程組是負責一個項目的軟件開發(fā)和維護活動（例如：需求分析、 設計、編程和測試）的人員（包括管理人員和技術人員）。系統(tǒng)工程組：系統(tǒng)工程組是負責下列工作的人（既有經(jīng)理也有技術人員）的集團：規(guī) 定系統(tǒng)需求；將系統(tǒng)盂求分配給碩件、軟件和其它成分；規(guī)定破件、軟件和其它成分z間的 界面；以及監(jiān)控這些成分的設計和開發(fā)以保證它們符介其規(guī)格說明。 系統(tǒng)測試纟也系統(tǒng)測試組是一些負責策劃和完成獨立的軟件系統(tǒng)測試的個人（既有經(jīng)理 又有技術人員）的集團，測試的目的是為了確處軟件產(chǎn)品是否滿足對它的要求。 軟件質(zhì)

30、量保證組：軟件質(zhì)量保證組是一些計劃和實施項目的質(zhì)量保證活動的個人（既 冇經(jīng)理又冇技術人員）的集團，其工作的目的是保證軟件過程的步驟和標準得到遵守。 軟件配置管理組：軟件配置管理組是一些負責策劃、協(xié)調(diào)和實施軟件項1=1的正式配置管理 活動的個人（既有經(jīng)理乂有技術人員）的集團總體流程如下：計劃階段一需求分析階段一軟件開發(fā)階段一測試階段一完成一、項目計劃階段項目計劃草案和風險管理計劃作為第一步，當有一個商業(yè)機會厲，根據(jù)公司高層負責制定的 初步商業(yè)計劃書來完成項目的計劃草案，確處、分析項冃風險并確尬其優(yōu)先級，述耍制定風險解決方案。本階段的目的是確立產(chǎn)品開發(fā)的經(jīng)濟理由。當確定開發(fā)之后則制處軟件開發(fā)計劃、

31、人員組織結構處義及配備、過程控制計劃。（1）項目計劃草案項目計劃草案應包括產(chǎn)品簡介、產(chǎn)品11標及功能說明、開發(fā)所需的資源、開發(fā)時間和里程碑。（2）風險管理計劃也就是把有可能出錯或現(xiàn)在還不能確定的東西列出來，并制定出相應的解決方案。風險發(fā)現(xiàn) 得越早對項目越有利。（3）軟件開發(fā)計劃軟件開發(fā)計劃的目的是收集控制項目時所需的所冇信息，項h經(jīng)理根據(jù)項忖計劃來女排 資源需求并根據(jù)時問表跟蹤項口進度。項h團隊成員根據(jù)項日計劃以了解他們的工作任務、 工作時間以及他們所依賴的其他活動?？蓪⒂媱澐殖煽傮w計劃和詳細計劃，總體計劃中每個任務為一個里程碑，詳細計劃中必須將 任務落實到個人。軟件開發(fā)計劃還應包括產(chǎn)品的應收標準及應收任務（包括確定需要制訂的測試用例）。（4）人員組織結構定義及配備常見的人員纟r織結構有垂直方案、水平方案、混合方案。垂直方案中每個成員充當多 重角色。水平方案中每個成員充當一到兩個角色?；旌戏桨竸t包括了經(jīng)驗豐富的人員與新手 相互融合。具體選擇根據(jù)人員實際技能情況進行選擇。（5）過程控制計劃過程控制計劃的h的是收集項日計劃正常執(zhí)行所需的所有信息，用來指導項日進度的監(jiān)控、 計劃的調(diào)整，確保項目按時完