嵌入式軟件開發(fā)流程知識講解

1、嵌入式軟件開發(fā)流程嵌入式軟件開發(fā)流程、嵌入式軟件開發(fā)流程1.1嵌入式系統(tǒng)開發(fā)概述由嵌入式系統(tǒng)本身的特性所影響，嵌入式系統(tǒng)開發(fā)與通用系統(tǒng)的開發(fā)有很大的區(qū)別。嵌入式系統(tǒng)的開發(fā)主要分為系統(tǒng)總體開發(fā)、嵌入式硬件開發(fā)和嵌入式軟件開發(fā)3大部分，其總體流程圖如圖1.1所示品戲或?qū)Ｓ嬇诌w計帶件MS41便*+越十14篩亭W舟謖耳玉爲(wèi)圖1.1嵌入式系統(tǒng)開發(fā)流程圖在系統(tǒng)總體開發(fā)中，由于嵌入式系統(tǒng)與硬件依賴非常緊密，往往某些需求只能通過特定的硬件才能實(shí)現(xiàn)，因此需要進(jìn)行處理器選型，以更好地滿足產(chǎn)品的需求。另外，對于有些硬件和軟件都可以實(shí)現(xiàn)的功能，就需要在成本和性能上做出抉擇。往往通過硬件實(shí)現(xiàn)會增加產(chǎn)品的成品，但能大大提

2、高產(chǎn)品的性能和可靠性。再次，開發(fā)環(huán)境的選擇對于嵌入式系統(tǒng)的開發(fā)也有很大的影響。這里的開發(fā)環(huán)境包括嵌入式操作系統(tǒng)的選擇以及開發(fā)工具的選擇等。本書在4.1.5節(jié)對各種不同的嵌入式操作系統(tǒng)進(jìn)行了比較，讀者可以以此為依據(jù)進(jìn)行相關(guān)的選擇。比如，對開發(fā)成本和進(jìn)度限制較大的產(chǎn)品可以選擇嵌入式Linux，對實(shí)時性要求非常高的產(chǎn)品可以選擇Vxworks等。由于本書主要討論嵌入式軟件的應(yīng)用開發(fā)，因此對硬件開發(fā)不做詳細(xì)講解，而主要討論嵌入式軟件開發(fā)的流程。嵌入式軟件開發(fā)概述嵌入式軟件開發(fā)總體流程為圖4.15中“軟件設(shè)計實(shí)現(xiàn)”部分所示，它同通用計算機(jī)軟件開發(fā)一樣，分為需求分析、軟件概要設(shè)計、軟件詳細(xì)設(shè)計、軟件實(shí)現(xiàn)和軟

3、件測試。其中嵌入式軟件需求分析與硬件的需求分析合二為一，故沒有分開畫出。由于在嵌入式軟件開發(fā)的工具非常多，為了更好地幫助讀者選擇開發(fā)工具，下面首先對嵌入式軟件開發(fā)過程中所使用的工具做一簡單歸納。嵌入式軟件的開發(fā)工具根據(jù)不同的開發(fā)過程而劃分，比如在需求分析階段，可以選擇IBM的RationalRose等軟件，而在程序開發(fā)階段可以采用CodeWarrior（下面要介紹的ADS的一個工具）等，在調(diào)試階段所用的Multi-ICE等。同時，不同的嵌入式操作系統(tǒng)往往會有配套的開發(fā)工具，比如Vxworks有集成開發(fā)環(huán)境Tornado，WindowsCE的集成開發(fā)環(huán)境WindowsCEPlatform等。此外

4、，不同的處理器可能還有對應(yīng)的開發(fā)工具，比如ARM的常用小知識與交叉編譯相對應(yīng)，平時常用的編譯稱為本地編譯。集成開發(fā)工具ADS、IAR和RealView等。在這里，大多數(shù)軟件都有比較高的使用費(fèi)用，但也可以大大加快產(chǎn)品的開發(fā)進(jìn)度，用戶可以根據(jù)需求自行選擇。圖4.16是嵌入式開發(fā)的不同階段的常用軟件。ItoiijztgRritliTLllRuSJL恥？iITinm-_口E口站哇-Kt呼曲-_T?IT-一Tixrado-LuD-tiiiLTUUL-PRISM+-抵冋-WiiCEPlcitf.TiiL.E：uil血Ci-ieV-taii-Lcigicijjr!-tfiitii-ICE-僉即jiroiL曰

5、江EtsiftLColiiizTestEliriie圖1.2嵌入式開發(fā)不同階段的常用軟件嵌入式系統(tǒng)的軟件開發(fā)與通常軟件開發(fā)的區(qū)別主要在于軟件實(shí)現(xiàn)部分，其中又可以分為編譯和調(diào)試兩部分，下面分別對這兩部分進(jìn)行講解。1.交叉編譯嵌入式軟件開發(fā)所采用的編譯為交叉編譯。所謂交叉編譯就是在一個平臺上生成可以在另一個平臺上執(zhí)行的代碼。在第3章中已經(jīng)提到，編譯的最主要的工作就在將程序轉(zhuǎn)化成運(yùn)行該程序的CPU所能識別的機(jī)器代碼，由于不同的體系結(jié)構(gòu)有不同的指令系統(tǒng)。因此，不同的CPU需要有相應(yīng)的編譯器，而交叉編譯就如同翻譯一樣，把相同的程序代碼翻譯成不同CPU的對應(yīng)可執(zhí)行二進(jìn)制文件。要注意的是，編譯器本身也是程序

6、，也要在與之對應(yīng)的某一個CPU平臺上運(yùn)行。嵌入式系統(tǒng)交叉編譯環(huán)境如圖4.17所示。這里一般將進(jìn)行交叉編譯的主機(jī)稱為宿主機(jī)，也就是普通的通用PC，而將程序?qū)嶋H的運(yùn)行環(huán)境稱為目標(biāo)機(jī)，也就是嵌入式系統(tǒng)環(huán)境。由于一般通用計算機(jī)擁有非常豐富的系統(tǒng)資源、使用方便的集成開發(fā)環(huán)境和調(diào)試工具等，而嵌入式系統(tǒng)的系統(tǒng)資源非常緊缺，無法在其上運(yùn)行相關(guān)的編譯工具，因此，嵌入式系統(tǒng)的開發(fā)需要借助宿主機(jī)（通用計算機(jī)）來編譯出目標(biāo)機(jī)的可執(zhí)行代碼。由于編譯的過程包括編譯、鏈接等幾個階段，因此，嵌入式的交叉編譯也包括交叉編譯、交叉鏈接等過程，通常ARM的交叉編譯器為arm-elf-gcc、arm-linux-gcc等，交叉鏈接器

7、為arm-elf-ld、arm-linux-ld等，交叉編譯過程如圖4.18所示。目牖尢廿ELF吋珂勺打序*圖4.18嵌入式交叉編譯過程2.交叉調(diào)試嵌入式軟件經(jīng)過編譯和鏈接后即進(jìn)入調(diào)試階段，調(diào)試是軟件開發(fā)過程中必不可少的一個環(huán)節(jié)，嵌入式軟件開發(fā)過程中的交叉調(diào)試與通用軟件開發(fā)過程中的調(diào)試方式有很大的差別。在常見軟件開發(fā)中，調(diào)試器與被調(diào)試的程序往往運(yùn)行在同一臺計算機(jī)上，調(diào)試器是一個單獨(dú)運(yùn)行著的進(jìn)程，它通過操作系統(tǒng)提供的調(diào)試接口來控制被調(diào)試的進(jìn)程。而在嵌入式軟件開發(fā)中，調(diào)試時采用的是在宿主機(jī)和目標(biāo)機(jī)之間進(jìn)行的交叉調(diào)試，調(diào)試器仍然運(yùn)行在宿主機(jī)的通用操作系統(tǒng)之上，但被調(diào)試的進(jìn)程卻是運(yùn)行在基于特定硬件平臺

8、的嵌入式操作系統(tǒng)中，調(diào)試器和被調(diào)試進(jìn)程通過串口或者網(wǎng)絡(luò)進(jìn)行通信，調(diào)試器可以控制、訪問被調(diào)試進(jìn)程，讀取被調(diào)試進(jìn)程的當(dāng)前狀態(tài)，并能夠改變被調(diào)試進(jìn)程的運(yùn)行狀態(tài)。嵌入式系統(tǒng)的交叉調(diào)試有多種方法，主要可分為軟件方式和硬件方式兩種。它們一般都具有如下一些典型特點(diǎn)。調(diào)試器和被調(diào)試進(jìn)程運(yùn)行在不同的機(jī)器上，調(diào)試器運(yùn)行在PC機(jī)（宿主機(jī)），而被調(diào)試的進(jìn)程則運(yùn)行在各種專業(yè)調(diào)試板上（目標(biāo)板）。調(diào)試器通過某種通信方式（串口、并口、網(wǎng)絡(luò)、JTAG等）控制被調(diào)試進(jìn)程。在目標(biāo)機(jī)上一般會具備某種形式的調(diào)試代理，它負(fù)責(zé)與調(diào)試器共同配合完成對目標(biāo)機(jī)上運(yùn)行著的進(jìn)程的調(diào)試。這種調(diào)試代理可能是某些支持調(diào)試功能的硬件設(shè)備，也可能是某些專門的

9、調(diào)試軟件（如gdbserver）。目標(biāo)機(jī)可能是某種形式的系統(tǒng)仿真器，通過在宿主機(jī)上運(yùn)行目標(biāo)機(jī)的仿真軟件，整個調(diào)試過程可以在一臺計算機(jī)上運(yùn)行。此時物理上雖然只有一臺計算機(jī)，但邏輯上仍然存在著宿主機(jī)和目標(biāo)機(jī)的區(qū)別。下面分別就軟件調(diào)試樁方式和硬件片上調(diào)試兩種方式進(jìn)行詳細(xì)介紹。（1）軟件方式。軟件調(diào)試主要是通過插入調(diào)試樁的方式來進(jìn)行的。調(diào)試樁方式進(jìn)行調(diào)試是通過目標(biāo)操作系統(tǒng)和調(diào)試器內(nèi)分別加入某些功能模塊，二者互通信息來進(jìn)行調(diào)試。該方式的典型調(diào)試器有g(shù)db調(diào)試器。gdb的交叉調(diào)試器分為GdbServer和GdbClient,其中的GdbServer就作為調(diào)試樁在安裝在目標(biāo)板上，GdbClient就是駐于本

10、地的gdb調(diào)試器。它們的調(diào)試原理圖如圖4.19所示圖4.19gdb遠(yuǎn)程調(diào)試原理圖gdb調(diào)試的工作流程。首先，建立調(diào)試器（本地gdb）與目標(biāo)操作系統(tǒng)的通信連接，可通過串口、網(wǎng)卡、并口等多種方式。然后，在目標(biāo)機(jī)上開啟GdbServer進(jìn)程，并監(jiān)聽對應(yīng)端口。在宿主機(jī)上運(yùn)行調(diào)試器gdb，這時，gdb就會自動尋找遠(yuǎn)端的通信進(jìn)程，也就是GdbServer的所在進(jìn)程。在宿主機(jī)上的gdb通過GdbServer請求對目標(biāo)機(jī)上的程序發(fā)出控制命令。這時，GdbServer將請求轉(zhuǎn)化為程序的地址空間或目標(biāo)平臺的某些寄存器的訪問，這對于沒有虛擬存儲器的簡單的嵌入式操作系統(tǒng)而言，是十分容易的。GdbServer把目標(biāo)操作

11、系統(tǒng)的所有異常處理轉(zhuǎn)向通信模塊，并告知宿主機(jī)上gdb當(dāng)前有異常。宿主機(jī)上的gdb向用戶顯示被調(diào)試程序產(chǎn)生了哪一類異常這樣就完成了調(diào)試的整個過程。這個方案的實(shí)質(zhì)是用軟件接管目標(biāo)機(jī)的全部異常處理及部分中斷處理，并在其中插入調(diào)試端口通信模塊，與主機(jī)的調(diào)試器進(jìn)行交互。但是它只能在目標(biāo)機(jī)系統(tǒng)初始化完畢、調(diào)試通信端口初始化完成后才能起作用，因此，一般只能用于調(diào)試運(yùn)行于目標(biāo)操作系統(tǒng)之上的應(yīng)用程序，而不宜用來調(diào)試目標(biāo)操作系統(tǒng)的內(nèi)核代碼及啟動代碼。而且，它必須改變目標(biāo)操作系統(tǒng)，因此，也就多了一個不用于正式發(fā)布的調(diào)試版。(2)硬件調(diào)試。相對于軟件調(diào)試而言，使用硬件調(diào)試器可以獲得更強(qiáng)大的調(diào)試功能和更優(yōu)秀的調(diào)試性能。

12、硬件調(diào)試器的基本原理是通過仿真硬件的執(zhí)行過程，讓開發(fā)者在調(diào)試時可以隨時了解到系統(tǒng)的當(dāng)前執(zhí)行情況。目前嵌入式系統(tǒng)開發(fā)中最常用到的硬件調(diào)試器是ROMMonitor、ROMEmulator、In-CircuitEmulator和In-CircuitDebugger。采用ROMMonitor方式進(jìn)行交叉調(diào)試需要在宿主機(jī)上運(yùn)行調(diào)試器，在宿主機(jī)上運(yùn)行ROM監(jiān)視器(ROMMonitor)和被調(diào)試程序，宿主機(jī)通過調(diào)試器與目標(biāo)機(jī)上的ROM監(jiān)視器遵循遠(yuǎn)程調(diào)試協(xié)議建立通信連接。ROM監(jiān)視器可以是一段運(yùn)行在目標(biāo)機(jī)ROM上的可執(zhí)行程序，也可以是一個專門的硬件調(diào)試設(shè)備，它負(fù)責(zé)監(jiān)控目標(biāo)機(jī)上被調(diào)試程序的運(yùn)行情況，能夠與宿主機(jī)

13、端的調(diào)試器一同完成對應(yīng)用程序的調(diào)試。在使用這種調(diào)試方式時，被調(diào)試程序首先通過ROM監(jiān)視器下載到目標(biāo)機(jī)，然后在ROM監(jiān)視器的監(jiān)控下完成調(diào)試。優(yōu)點(diǎn)：ROM監(jiān)視器功能強(qiáng)大，能夠完成設(shè)置斷點(diǎn)、單步執(zhí)行、查看寄存器、修改內(nèi)存空間等各項(xiàng)調(diào)試功能。確定：同軟件調(diào)試一樣，使用ROM監(jiān)視器目標(biāo)機(jī)和宿主機(jī)必須建立通信連其原理圖如圖4.20所示圖4.20ROMMonitor調(diào)試方式采用ROMEmulator方式進(jìn)行交叉調(diào)試時需要使用ROM仿真器，并且它通常被插入到目標(biāo)機(jī)上的ROM插槽中，專門用于仿真目標(biāo)機(jī)上的ROM芯片。在使用這種調(diào)試方式時，被調(diào)試程序首先下載到ROM仿真器中，因此等效于下載到目標(biāo)機(jī)的ROM芯片上，

14、然后在ROM仿真器中完成對目標(biāo)程序的調(diào)試。優(yōu)點(diǎn)：避免了每次修改程序后都必須重新燒寫到目標(biāo)機(jī)的ROM中。缺點(diǎn):ROM仿真器本身比較昂貴，功能相對來講又比較單一，只適應(yīng)于某些特定場合其原理如圖4.21所示。廠云1n廠崔1圖4.21ROMEmulator調(diào)試方式采用In-CircuitEmulator(ICE)方式進(jìn)行交叉調(diào)試時需要使用在線仿真器，它是目前最為有效的嵌入式系統(tǒng)的調(diào)試手段。它是仿照目標(biāo)機(jī)上的CPU而專門設(shè)計的硬件，可以完全仿真處理器芯片的行為。仿真器與目標(biāo)板可以通過仿真頭連接，與宿主機(jī)可以通過串口、并口、網(wǎng)線或USB口等連接方式。由于仿真器自成體系，所以調(diào)試時既可以連接目標(biāo)板，也可以不

15、連接目標(biāo)板。在線仿真器提供了非常豐富的調(diào)試功能。在使用在線仿真器進(jìn)行調(diào)試的過程中，可以按順序單步執(zhí)行，也可以倒退執(zhí)行，還可以實(shí)時查看所有需要的數(shù)據(jù)，從而給調(diào)試過程帶來了很多的便利。嵌入式系統(tǒng)應(yīng)用的一個顯著特點(diǎn)是與現(xiàn)實(shí)世界中的硬件直接相關(guān)，并存在各種異變和事先未知的變化，從而給微處理器的指令執(zhí)行帶來各種不確定因素，這種不確定性在目前情況下只有通過在線仿真器才有可能發(fā)現(xiàn)。優(yōu)點(diǎn)：功能強(qiáng)大，軟硬件都可做到完全實(shí)時在線調(diào)試。缺點(diǎn)：價格昂貴。其原理如圖4.22所示。圖4.22ICE調(diào)試方式采用In-CircuitDebugger(ICD)方式進(jìn)行交叉調(diào)試時需要使用在線調(diào)試器。由于ICE的價格非常昂貴，并且

16、每種CPU都需要一種與之對應(yīng)的ICE，使得開發(fā)成本非常高。一個比較好的解決辦法是讓CPU直接在其內(nèi)部實(shí)現(xiàn)調(diào)試功能，并通過在開發(fā)板上引出的調(diào)試端口發(fā)送調(diào)試命令和接收調(diào)試信息，完成調(diào)試過程。如使用非常廣泛的ARM處理器的JTAG端口技術(shù)就是由此而誕生的。JTAG是1985年指定的檢測PCB和IC芯片的一個標(biāo)準(zhǔn)。1990年被修改成為IEEE的一個標(biāo)準(zhǔn)，即IEEE1149.1。JTAG標(biāo)準(zhǔn)所采用的主要技術(shù)為邊界掃描技術(shù)，它的基本思想就是在靠近芯片的輸入輸出管腳上增加一個移位寄存器單元。因?yàn)檫@些移位寄存器單元都分布在芯片的邊界上（周圍），所以被稱為邊界掃描寄存器（Boundary-ScanRegiste

17、rCell）。當(dāng)芯片處于調(diào)試狀態(tài)時候，這些邊界掃描寄存器可以將芯片和外圍的輸入輸出隔離開來。通過這些邊界掃描寄存器單元，可以實(shí)現(xiàn)對芯片輸入輸出信號的觀察和控制。對于芯片的輸入管腳，可通過與之相連的邊界掃描寄存器單元把信號（數(shù)據(jù)）加載到該管腳中去；對于芯片的輸出管腳，可以通過與之相連的邊界掃描寄存器單元捕獲（CAPTURE）該管腳的輸出信號。這樣，邊界掃描寄存器提供了一個便捷的方式用于觀測和控制所需要調(diào)試的芯片?，F(xiàn)在較為高檔的微處理器都帶有JTAG接口，包括ARM7、ARM9、StrongARM、DSP等，通過JTAG接口可以方便地對目標(biāo)系統(tǒng)進(jìn)行測試，同時，還可以實(shí)現(xiàn)Flash編程，這是非常受歡

18、迎的。優(yōu)點(diǎn)：連接簡單，成本低。缺點(diǎn)：特性受制于芯片廠商。其原理如圖4.23所示。舊悴劇圖4.23JTAG調(diào)試方式需求分析評各部需求分項(xiàng)目總體規(guī)劃設(shè)計階段T1確定系統(tǒng)分析劃書風(fēng)險控制計劃!需求分析報告I需求分析評審報告I產(chǎn)品定義!產(chǎn)品技術(shù)規(guī)范!項(xiàng)目開發(fā)計劃I風(fēng)險控制計劃!質(zhì)量控制計劃!系統(tǒng)分析文檔系統(tǒng)分析評硬件結(jié)構(gòu)設(shè)計軟件軟件及制作，過程文PCBIT1工藝I產(chǎn)品技術(shù)總體設(shè)計方|案（包括工藝）I系統(tǒng)分析評審報告|軟件設(shè)計過程文檔I硬件設(shè)計過程文檔I結(jié)構(gòu)設(shè)計過程文檔i工藝設(shè)計過程文檔I軟件V1.0PCBV1.0|T1設(shè)計文檔|工藝說明|分單元測試報告設(shè)計驗(yàn)證階段T2FTAT3CTA|裝機(jī)報告|例試分

19、析報告|整機(jī)測試評估報告|軟件FTA版本|硬件FTA版本例試報告及分裝機(jī)報告整機(jī)測試及評裝機(jī)準(zhǔn)備少量裝機(jī)FTA準(zhǔn)備FTA例試、整機(jī)測試CTA修模第二次試軟硬件及工藝調(diào)試產(chǎn)準(zhǔn)備軟硬件及工藝?yán)?、整機(jī)測試軟硬件結(jié)構(gòu)及寸2設(shè)計文檔一試產(chǎn)報告例試分析報告1整機(jī)測試評估報告|軟件CTA版本|硬件CTA版本hr3設(shè)計文檔試產(chǎn)報告!例試分析報告I整機(jī)測試評估報告附錄1.結(jié)構(gòu)設(shè)計及制作流程階段一結(jié)構(gòu)tr可行iL評估i3D模型可行性評估*3D模型修改制定結(jié)構(gòu)設(shè)計進(jìn)度計劃|3D模型評估報告i結(jié)構(gòu)設(shè)計進(jìn)度表結(jié)構(gòu)T一詳細(xì)設(shè)計i|結(jié)構(gòu)設(shè)計進(jìn)度表詳細(xì)結(jié)構(gòu)設(shè)計艸結(jié)構(gòu)設(shè)計進(jìn)展匯IL結(jié)構(gòu)設(shè)計內(nèi)部評結(jié)構(gòu)設(shè)計修改結(jié)構(gòu)設(shè)計驗(yàn)證評審相

20、關(guān)模資料制準(zhǔn)作檢制作working4workingsample驗(yàn)5!簽訂商務(wù)合同開模參考文件：1結(jié)構(gòu)設(shè)計內(nèi)部評審記I錄workingsample配色i表workingsample驗(yàn)收I報告I結(jié)構(gòu)BOMI結(jié)構(gòu)設(shè)計外部評審記I錄i模具制作檢討記錄表I模具制作申請表|模具備品清單I模具制作注意事項(xiàng)表I工裝夾具制作清單|物料進(jìn)度按排需求表配色方案表|模具制作進(jìn)度表工業(yè)設(shè)計流程，ID設(shè)計流程階段-流程圖軟件I需求I分析I軟件需求分析（包括技術(shù)風(fēng)險評軟件開發(fā)計劃和配置件測試計劃軟件需求規(guī)格書i軟件開發(fā)計劃I軟件開發(fā)風(fēng)險控制計I劃i軟件測試計劃軟件I詳細(xì)I設(shè)計II軟件詳細(xì)設(shè)計說明書i軟件接口設(shè)計說明書|軟件

21、設(shè)計內(nèi)部評審記i錄附錄3.硬件設(shè)計流程階段T一流程圖硬件需求分析（包括技術(shù)風(fēng)險評硬件需求分析報告|硬件開發(fā)計劃丨硬件測試計劃件開發(fā)計劃和配硬i試計劃硬件詳細(xì)硬件設(shè)計詳細(xì)內(nèi)部設(shè)計評審設(shè)計1-PCB毛坯圖設(shè)計LCD關(guān)鍵器廠硬件詳細(xì)設(shè)計說明書硬件電路原理圖硬件BOM硬件設(shè)計內(nèi)部評審記錄硬件i實(shí)現(xiàn)i測試iPCB數(shù)據(jù)器件規(guī)格書硬件子系統(tǒng)軟件裝配圖硬件單元測試分析報吿電裝總結(jié)報吿硬件系統(tǒng)測試版本硬件系統(tǒng)測試分析報告硬件評審驗(yàn)證報告發(fā)布版本參考文件：-1、PCB布板流程圖2、LCD認(rèn)證流程PCB布板流程其他各部I表單階段硬件結(jié)構(gòu)布板項(xiàng)目需求/產(chǎn)需求設(shè)計PCBPCB確認(rèn)PCB投板參考文件:PCB布板設(shè)PCB投

22、板結(jié)構(gòu)尺寸要投板前審查LCD認(rèn)證流程硬件結(jié)構(gòu)其他各部表單SPEC樣品需求4尺寸LCD供應(yīng)商數(shù)據(jù)收集和提供I供應(yīng)商提供樣尺寸確認(rèn)軟件確認(rèn)勺各部提出修改要求各部j與供應(yīng)商溝供應(yīng)商供樣封樣各部確認(rèn)？軟件開發(fā)規(guī)范SoftwareDevelopmentSpecificationVersion:V1.0Date:2010-06-22PreparedbyDocumentRevisionHistory文檔修訂記錄VERSION版本DATE日期DESCRIPTION內(nèi)容說明INDIVIDUAL修訂人1.02010-06-22初稿Introduction簡介一個成熟穩(wěn)定的組織或者團(tuán)隊(duì)，能夠減少風(fēng)險，經(jīng)常地成功地達(dá)

23、成目標(biāo)。成功的含義是：按時、預(yù)算內(nèi)【即符合成本要求】、符合質(zhì)量要求。換言之，成熟穩(wěn)定的團(tuán)隊(duì)，能夠避免以下問題：組織方面出現(xiàn)問題對需求缺乏管理缺乏計劃和控制估算錯誤同時，還要在以下幾個方面做得比較出色：人員調(diào)度與工作安排工作量估計預(yù)算管理責(zé)權(quán)分配與平衡執(zhí)行與監(jiān)控溝通本文檔是軟件開發(fā)規(guī)范，力求使團(tuán)隊(duì)打下一個良好的基礎(chǔ)，以便逐步成長為成熟穩(wěn)定的團(tuán)隊(duì)。團(tuán)隊(duì)需要一個逐步標(biāo)準(zhǔn)、規(guī)范的開發(fā)過程，在這個過程中，團(tuán)隊(duì)得到鍛煉，成員能力得到提高，風(fēng)險得到控制。主要內(nèi)容是：A定義軟件開發(fā)的流程；定義軟件開發(fā)的文檔格式；定義涉及的角色；定義涉及的信息；A描述開發(fā)流程；Purpose目標(biāo)本文檔的目標(biāo)是：統(tǒng)一軟件開發(fā)團(tuán)隊(duì)

24、的流程、文檔；促進(jìn)團(tuán)隊(duì)成員的溝通，減少誤解；促使程序員書寫易維護(hù)的代碼；提高代碼編寫效率；A使每個成員成為一個高效的程序員；Scope范圍本文檔，包含：項(xiàng)目管理的流程；項(xiàng)目策劃項(xiàng)目追蹤配置管理質(zhì)量保證同行評審涉及文檔；項(xiàng)目計劃mpp需求規(guī)格說明書SRSDelphi估算項(xiàng)目狀態(tài)報告配置庫樣式CheckList評審表變更申請表開發(fā)工具的規(guī)范；數(shù)據(jù)庫設(shè)計工具功能設(shè)計工具IDE配置工具Defintions,Acronyms,andAbbreviations.術(shù)語，縮略詞SPP項(xiàng)目策劃SoftwareProjectPlanningSPTO項(xiàng)目追蹤SoftwareProjectTracking&Overs

25、ightSCM配置管理SoftwareConfigurationManagementSQA質(zhì)量保證SoftwareQualityAssurancePR同行評審PeerReviewBaseLine基線SCCB軟件配置控制委員會SoftwareConfigurationControlBoardCR變更請求ChangeRequestSDLC軟件開發(fā)生命周期SoftwareDevelopmentLifeCycleRUP統(tǒng)一開發(fā)過程RationalUnifiedProcessXP極限【敏捷方法】eXtremeProgrammingTDD測試驅(qū)動TestDrivenDevelopmentReference

26、s引用CMM2CMM3Overview文檔組織本文檔主要分為四大部分：概述；描述了團(tuán)隊(duì)組織開發(fā)過程的高層視圖；TSP和PSP；按照團(tuán)隊(duì)和個人描述流程規(guī)范；工具規(guī)范；描述了開發(fā)工具的詳細(xì)規(guī)范；文檔；涉及的文檔格式；TheOverallDescription概述本部分是開發(fā)團(tuán)隊(duì)開發(fā)過程的高層描述。它描述了開發(fā)過程規(guī)范的背景，用來和所有涉及各方就基本過程達(dá)成共識。SofwareDevelopmentOrganizing開發(fā)團(tuán)隊(duì)組織結(jié)構(gòu)團(tuán)團(tuán)團(tuán)說明：匚二表示公司的行政部門匚二1表示公司的邏輯部門實(shí)線表示參加產(chǎn)品實(shí)現(xiàn)的組織和人員（不表示所屬關(guān)系）虛線表示工作的匯報關(guān)系，如SQAE向SQA經(jīng)理匯報。Proj

27、ectBaseProcess項(xiàng)目基本流程需求建議書合同項(xiàng)目目標(biāo)可行性分析報告:結(jié)束項(xiàng)目識別需求執(zhí)行項(xiàng)提出解:決方案:項(xiàng)目定義制定計劃計劃實(shí)施項(xiàng)目終止投入力量時間基本流程說明：項(xiàng)目啟動：本階段主要是進(jìn)行可行性分析，定義項(xiàng)目，識別需求；制定計劃：本階段主要是計劃策劃，估算工作量，制定具體的可執(zhí)行的計劃；計劃實(shí)施：本階段主要是實(shí)施計劃，完成計劃中的各項(xiàng)任務(wù)，報告計劃狀態(tài)；項(xiàng)目終止：計劃執(zhí)行完畢，總結(jié)項(xiàng)目；CMMBaseProcessCMM基本過程基本過程說明：SCM:軟件配置管理，所有活動的基礎(chǔ)，一切制品必須放入配置庫；SPP:軟件項(xiàng)目策劃，估算工作量，制定詳細(xì)計劃【項(xiàng)目的制定計劃階段】；SPTO:

28、項(xiàng)目追蹤，報告項(xiàng)目狀態(tài)，評估并更新計劃【項(xiàng)目的計劃實(shí)施階段】；PR：同行評審，進(jìn)入基線的前提條件，降低風(fēng)險，提高質(zhì)量的有效手段；SQA:質(zhì)量保證，預(yù)防風(fēng)險的有效手段；SCM軟件配置管理配置管理主要解決：版本變更確定基線變更過2.3.2SPP計劃策劃計劃策劃的核心是工作量估算項(xiàng)冃啟動從公司的數(shù)據(jù)中識別項(xiàng)理解是否充分;的總結(jié)報告和其它的數(shù)J目相似的信息，如項(xiàng)目可F選擇項(xiàng)目生命周期人員介入項(xiàng)冃的方式；產(chǎn)品的交、付方式；項(xiàng)冃規(guī)識別項(xiàng)冃的特點(diǎn)分解時考慮的活動事項(xiàng)要詳盡，不要漏了解各個生命周期的特點(diǎn)掉：教育或培訓(xùn)的需;參與評審文檔；JRUPXP1r文檔制品如：計劃、_F依據(jù)定義的過程，識別必估算表規(guī)模估算

29、制定工作產(chǎn)品吊的評審計劃估算結(jié)果2.3.3SPTO項(xiàng)目追蹤2.3.4PR同行評審工作產(chǎn)品評審計劃評審?fù)ㄖ贫ū敬?，評審計劃要評審的文檔已經(jīng)完成且文檔符合標(biāo)準(zhǔn)模板要求，項(xiàng)目經(jīng)理指定評審組長，發(fā)放工作產(chǎn)品及參考資料，必要時確定評審重點(diǎn)（參見評審指南）心審人員進(jìn)行預(yù)審a個人評審項(xiàng)目經(jīng)理組織解決發(fā)現(xiàn)r將報告抄送相關(guān)人員評審準(zhǔn)備yr正式評宙Xr評審跟蹤指定的時間內(nèi)給出預(yù)審意見，反饋給評審組長M作者。評申報告的缺陷（或問題）J作者根據(jù)評審結(jié)果進(jìn)行J2.3.5SQA質(zhì)量保證2.4SDLC生命周期選擇當(dāng)前比較成熟穩(wěn)定的SDLC是:WaterFallRUPXP其中:RUP和XP是迭代式開發(fā)過程，風(fēng)險是可控的。R

30、UP的優(yōu)點(diǎn)是過程清晰、文檔齊全，但是過于龐雜，比較適合大規(guī)模的團(tuán)隊(duì)；XP的優(yōu)點(diǎn)是過程簡潔、推崇簡單，但是不注重文檔，難于交接，適合小規(guī)對于中等規(guī)模的團(tuán)隊(duì)來說，應(yīng)該基于RUP和XP,進(jìn)行裁剪，找到適合的SDLC:SDLC的核心是：迭代式和TDD從全局看：Use-CaseDriven用例驅(qū)動基于Architecture迭代和遞增的從微觀看：TDD測試驅(qū)動ReFactor重構(gòu)Pair結(jié)對編程2.5DevelopmentProcess開發(fā)過程2.5.1DevelopmentPhase開發(fā)階段需求分析階段需求收集需求總結(jié)總體設(shè)計階段總體架構(gòu)部署模型概要設(shè)計階段模塊劃分?jǐn)?shù)據(jù)庫設(shè)計詳細(xì)設(shè)計階段具體實(shí)現(xiàn)A編碼

31、階段測試用例Coding單元測試測試階段測試用例測試修正發(fā)布階段安裝測試安裝系統(tǒng)維護(hù)PhaseProduct階段制品A需求階段SRS：需求規(guī)格說明書總體設(shè)計階段總體設(shè)計說明書概要設(shè)計階段HLD：概要設(shè)計說明書DB:數(shù)據(jù)庫設(shè)計DFD：數(shù)據(jù)流圖UI：用戶界面詳細(xì)設(shè)計階段DD:詳細(xì)設(shè)計說明書A編碼階段TestCase：測試用例Coding：源代碼UTTestResult:單元測試報告測試階段TestTask:測試任務(wù)書TestCase:測試用例TestResult:測試報告TestApprovals:測試總結(jié)發(fā)布階段發(fā)布申請書RoleDuty角色職責(zé)角色責(zé)任研發(fā)經(jīng)理【研發(fā)團(tuán)隊(duì)】為軟件項(xiàng)目提供足夠的資

32、源.保證SQA小組的獨(dú)立性.解決SQA檢杳時發(fā)現(xiàn)的問題.審批對外的承諾。定期審查SCM、SQA、項(xiàng)目計劃和跟蹤的相關(guān)活動。規(guī)定系統(tǒng)需求；將系統(tǒng)需求分配給硬件、軟件和其他成分；規(guī)定硬件、軟件和其他成分的界面；監(jiān)控設(shè)計和開發(fā)以保證他們符合其規(guī)格說明；代表公司下達(dá)任務(wù)書。SA團(tuán)隊(duì)負(fù)責(zé)網(wǎng)絡(luò)工程計劃的制定及實(shí)施；負(fù)責(zé)對客戶的技術(shù)支持與培訓(xùn)；負(fù)責(zé)工程服務(wù)部內(nèi)部人員素質(zhì)與技術(shù)培訓(xùn)負(fù)責(zé)系統(tǒng)集成工程標(biāo)識、測試、驗(yàn)收及質(zhì)量保證；負(fù)責(zé)硬件、網(wǎng)絡(luò)和系統(tǒng)軟件產(chǎn)品的最后交付；負(fù)責(zé)組織自產(chǎn)軟件儲運(yùn)、防護(hù)、交付和安裝；負(fù)責(zé)工程項(xiàng)目的配置管理QA研究制定測試規(guī)范和方案；參加實(shí)施測試和質(zhì)量保證過程；對系統(tǒng)測試中發(fā)現(xiàn)的缺陷進(jìn)行驗(yàn)證

33、；負(fù)責(zé)組織軟件項(xiàng)目任務(wù)書、開發(fā)計劃、里程碑等管理評審；負(fù)責(zé)公司的配置管理；項(xiàng)目經(jīng)理負(fù)責(zé)軟件和硬件整個項(xiàng)目的協(xié)調(diào)、管理進(jìn)行需求分析，并進(jìn)行文檔的編寫組織技術(shù)評審等活動組織制定項(xiàng)目開發(fā)計劃（SDP）、風(fēng)險管理計劃等計劃配合與協(xié)調(diào)SQA和SCM小組的活動.管理項(xiàng)目組，執(zhí)行SQA方針和過程以及SDP.監(jiān)督和跟蹤SDP、項(xiàng)目估算SA負(fù)責(zé)硬件工程的實(shí)施；負(fù)責(zé)系統(tǒng)的上線；負(fù)責(zé)系統(tǒng)的維護(hù)；SCCB授權(quán)建立軟件基線和標(biāo)識配置項(xiàng)/單元；審查和審定對軟件基線的更改；審定由軟件基線庫制造的產(chǎn)品的生成。SCM協(xié)助軟件項(xiàng)目經(jīng)理制定SCM計劃、維護(hù)SCM計劃；制定并維護(hù)項(xiàng)目標(biāo)識規(guī)范；按時歸檔配置項(xiàng)；標(biāo)識并管理置于配置管理過

34、程之下的軟件工作產(chǎn)品集合；進(jìn)行軟件項(xiàng)目的軟件基線生成、管理和備份；軟件配置狀態(tài)的統(tǒng)計和審計，并向項(xiàng)目組、軟件項(xiàng)目經(jīng)理、高級管理者匯報有關(guān)活動情況；將基線的變更情況通知受影響的組和個人；保存并管理各項(xiàng)評審記錄、與項(xiàng)目相關(guān)的技術(shù)文檔、標(biāo)準(zhǔn)和規(guī)程。SQC依據(jù)測試計劃模板制定測試計劃執(zhí)行測試計劃進(jìn)行測試并記錄測試發(fā)現(xiàn)的缺陷提供測試報告.SQA主要是策劃軟件質(zhì)量保證活動、檢驗(yàn)軟件產(chǎn)品或活動對可用的標(biāo)準(zhǔn)、需求和規(guī)則的遵守程度、組織處理項(xiàng)目內(nèi)部不能解決的不一致問題；定期報告檢杳情況，發(fā)現(xiàn)偏差組織制定糾正、預(yù)防措施并監(jiān)督更正；參與制定SQA計劃，實(shí)施SQA活動，并向SQA經(jīng)理、軟件項(xiàng)目經(jīng)理項(xiàng)目組、高級管理者匯

35、報有關(guān)的情況。DBA負(fù)責(zé)DB的創(chuàng)建和維護(hù)；為DE提供一個穩(wěn)定的環(huán)境；DE按軟件開發(fā)計劃進(jìn)行開發(fā)，并記錄相關(guān)數(shù)據(jù)；遵守公司質(zhì)量管理體系的要求.Deployer根據(jù)發(fā)布申請，提取代碼，發(fā)布系統(tǒng)和SA、DBA起配置環(huán)境重構(gòu)和重建系統(tǒng)2.6Constraints限制SpecificRequirements詳細(xì)描述本部分按照角色劃分詳細(xì)描述開發(fā)過程。3.1Precondition前提3.1.1SCM配置庫目錄結(jié)構(gòu)開發(fā)庫：開發(fā)工作區(qū)文檔和代碼項(xiàng)目文檔項(xiàng)目啟動項(xiàng)目策劃項(xiàng)目計劃項(xiàng)目報告開發(fā)文檔需求設(shè)計測試代碼代碼目錄參考資料客戶資料等等基線庫：評審?fù)ㄟ^后的文檔文檔同開發(fā)庫測試庫：測試代碼和測試發(fā)布包文檔計劃用

36、例測試報告代碼版本1版本2參考資料產(chǎn)品庫：測試通過后的文檔和代碼項(xiàng)目交付制品項(xiàng)目總結(jié)驗(yàn)收報告。項(xiàng)目產(chǎn)品版本1版本2A權(quán)限測試庫：測試人員可以讀寫其它人員只能讀，不能增加、修改和刪除基線庫：只能增加，不能刪除和修改產(chǎn)品庫：只能增加，不能刪除和修改開發(fā)庫：TestEnvironment測試環(huán)境測試需要一個獨(dú)立的環(huán)境DB獨(dú)立FTP等資源獨(dú)立Pass9等外部系統(tǒng)獨(dú)立最好是一個單獨(dú)的局域網(wǎng)環(huán)境，完全和開發(fā)分開開發(fā)是環(huán)境測試是環(huán)境每次測試，應(yīng)當(dāng)是一個完整的測試過程安裝系統(tǒng)DBWebAppServerClient其它配置系統(tǒng)DB配置AppServer配置系統(tǒng)初始化清除所有歷史數(shù)據(jù)執(zhí)行初始化腳本，插入初始數(shù)據(jù)

37、測試系統(tǒng)DevelopmentControlProcess開發(fā)控制流程3.2.1項(xiàng)目啟動和策劃階段本階段的關(guān)鍵是定義項(xiàng)目、估算工作量和制定詳細(xì)計劃。一個軟件項(xiàng)目的正式啟動從軟件項(xiàng)目任務(wù)書的下達(dá)開始。任務(wù)書中寫明項(xiàng)目的基本信息及相關(guān)責(zé)任人和詳細(xì)分工，規(guī)定項(xiàng)目必須提交的產(chǎn)品清單。任務(wù)書由研發(fā)經(jīng)理或者項(xiàng)目負(fù)責(zé)人起草，研發(fā)經(jīng)理批準(zhǔn)后下達(dá)給相關(guān)負(fù)責(zé)人。項(xiàng)目任務(wù)書必須為打印紙質(zhì)文檔，由相關(guān)人員簽字確認(rèn)后，入配置管理庫歸檔。軟件項(xiàng)目任務(wù)書主要作用是明確項(xiàng)目人員職責(zé)以及各組之間的協(xié)調(diào)確認(rèn)。估算工作量，從確認(rèn)需求后開始。由項(xiàng)目經(jīng)理指定評估人員，先按照頭腦風(fēng)暴法估計各個子系統(tǒng)或者模塊的難易程度，然后按照Delph

38、i法估算各個部分的工作量。項(xiàng)目經(jīng)理和PMO成員，根據(jù)估算的工作量，制定項(xiàng)目計劃。SQA和SCM分別制定各自的計劃。SCM需要確定資源庫的目錄結(jié)構(gòu)和權(quán)限結(jié)構(gòu)。項(xiàng)目經(jīng)理召集PMO、SQA、SCM評審及審核項(xiàng)目計劃、SQA計劃、SQA審核計劃、SCM計劃和測試計劃。對于發(fā)布后的一般性程序修改，不需要下達(dá)軟件項(xiàng)目任務(wù)書。對于關(guān)系重大，需要各組人員協(xié)調(diào)工作的重大修改，項(xiàng)目負(fù)責(zé)人可以以任務(wù)書的形式明確職責(zé)、協(xié)調(diào)關(guān)系。測試負(fù)責(zé)人評估測試資源【人員及機(jī)器】，并決定測試人員是否介入項(xiàng)目的需求分析和設(shè)計階段。3.2.2需求分析、設(shè)計、編碼階段本階段的關(guān)鍵是評審和修訂控制，關(guān)鍵評審需要需求、設(shè)計、編碼、測試、項(xiàng)目管

39、理、用戶等的參與。需求階段，需求分析人員收集需求，根據(jù)SRS模版，作出需求規(guī)格說明書。設(shè)計階段，設(shè)計人員根據(jù)總體設(shè)計、概要設(shè)計、數(shù)據(jù)庫設(shè)計和詳細(xì)設(shè)計，作出設(shè)計文檔。編碼階段，編碼人員根據(jù)詳細(xì)設(shè)計，設(shè)計單元測試用例，編寫代碼，進(jìn)行單元測試。關(guān)鍵評審：SRS評審，設(shè)計評審，代碼走查3.2.3提交測試階段項(xiàng)目啟動后，項(xiàng)目經(jīng)理填寫測試任務(wù)通知單，將測試任務(wù)下達(dá)給測試組。概要設(shè)計評審?fù)瓿珊?，由各子系統(tǒng)或者模塊的負(fù)責(zé)人測算完成時間，在確定完成時間后（正式開始編碼前）將測試任務(wù)通知單提交給項(xiàng)目測試負(fù)責(zé)人，項(xiàng)目測試負(fù)責(zé)人審核通過在通知單上簽字后返回給子項(xiàng)目負(fù)責(zé)人。開發(fā)及單元測試完成后，由開發(fā)人員將測試內(nèi)容提交

40、配置管理員入測試庫后，將測試任務(wù)通知單提交給發(fā)布人員申請測試發(fā)布。發(fā)布人員將測試庫中本次測試的內(nèi)容發(fā)布到測試機(jī)后，在測試任務(wù)通知單上簽字后，提交給測試人員開始測試。測試完成后，測試人員在任務(wù)單上填寫測試意見后，交測試負(fù)責(zé)人確認(rèn)后，返還給開發(fā)人員。如測試沒有通過，開發(fā)人員修改測試內(nèi)容，進(jìn)入下一個測試流程。如通過測試，開發(fā)人員將測試任務(wù)通知單提交給項(xiàng)目負(fù)責(zé)人，由項(xiàng)目負(fù)責(zé)人、SCCB簽字確認(rèn)后，提交配置管理員將測試內(nèi)容入基線庫。過程關(guān)鍵：發(fā)布實(shí)施人員確保發(fā)布到測試機(jī)上的源程序在配置管理庫中得到了有效的標(biāo)識。3.2.4牛產(chǎn)發(fā)布、終測程序通過測試入庫以后，根據(jù)需要，由項(xiàng)目的負(fù)責(zé)人負(fù)責(zé)填寫發(fā)布申請單。發(fā)布

41、申請單由項(xiàng)目測試負(fù)責(zé)人、配置管理員、SCCB、客戶代表、研發(fā)經(jīng)理簽字確認(rèn)后，由項(xiàng)目負(fù)責(zé)人提交給實(shí)施發(fā)布人員。發(fā)布人員拿到簽完字的發(fā)布申請后，才能從基線庫中提取程序向生產(chǎn)機(jī)上發(fā)布。如以上發(fā)布確認(rèn)人員沒有全部簽字同意發(fā)布，必須由項(xiàng)目經(jīng)理簽字同意后發(fā)布。程序發(fā)布到生產(chǎn)機(jī)上以后，進(jìn)入終測【UAT】流程。測試人員和用戶代表要對生產(chǎn)機(jī)上的程序進(jìn)行最后測試，確保生產(chǎn)機(jī)上的系統(tǒng)符合需求。項(xiàng)目負(fù)責(zé)人負(fù)責(zé)同用戶協(xié)調(diào)，項(xiàng)目負(fù)責(zé)人、測試人員和用戶共同編寫測試用例。項(xiàng)目負(fù)責(zé)人將終測意見書提交三方簽字，根據(jù)簽字意見決定修訂系統(tǒng)或者提交正式發(fā)布。終測出現(xiàn)的問題修改按照基線變更流程進(jìn)行。實(shí)施人員只有拿到有三方簽字的終測意見書

42、后才能將系統(tǒng)正式公開發(fā)布。系統(tǒng)正式發(fā)布三天之后一周之內(nèi)，由實(shí)施人員負(fù)責(zé)到用戶處取得有用戶主要負(fù)責(zé)人簽字的系統(tǒng)運(yùn)行報告，項(xiàng)目負(fù)責(zé)人負(fù)責(zé)監(jiān)督執(zhí)行。根據(jù)系統(tǒng)運(yùn)行報告做相應(yīng)的處理。過程關(guān)鍵：發(fā)布到生產(chǎn)機(jī)上的程序都在基線庫中得到了有效的標(biāo)識。3.2.5發(fā)布后問題反饋修改過稈系統(tǒng)發(fā)布之后，用戶反饋的意見要形成問題清單或者變更申請單，記錄需要修改的地方，提交給項(xiàng)目負(fù)責(zé)人。項(xiàng)目負(fù)責(zé)人負(fù)責(zé)判斷改動是否會影響需求或者設(shè)計，負(fù)責(zé)將任務(wù)分配給相關(guān)人員進(jìn)行修改。修改完成后，提交測試直至發(fā)布。這個階段的最重要的是保證所做的修改（文檔、代碼）都在配置管理庫的基線庫中得到體現(xiàn)。即基線庫中的文檔和代碼要進(jìn)行同步更新，關(guān)鍵是發(fā)布

43、人員嚴(yán)格根據(jù)發(fā)布申請單進(jìn)行控制，并確保發(fā)布的代碼都是從基線庫中取出的。沒有經(jīng)過流程直接要求發(fā)布的，發(fā)布人員必須予以拒絕。3.3TSP團(tuán)隊(duì)軟件過程3.3.1會議組織會議前，確定會議主持人和記錄員向參與會議人員發(fā)送會議資料參與會議人員閱讀會議資料確定會議主題、日期時間和地點(diǎn)注意：留出閱讀資料的時間確定會議議程準(zhǔn)備會議用品【如投影儀等】重要會議，需要會議開始前，申明會議紀(jì)律發(fā)言時間限制發(fā)言順序除主持人外，不得打斷別人記錄員記錄會議紀(jì)要會議后，發(fā)送會議總結(jié)3.3.2溝通問題原則目標(biāo)明確明確反饋反復(fù)溝通A請求-答復(fù)當(dāng)有疑問時，發(fā)出請求明確求助對象，指定第一對象和輔助對象第一對象接收到請求后，不能及時答復(fù)

44、的應(yīng)當(dāng)轉(zhuǎn)發(fā)給自己認(rèn)為合適的答復(fù)人，并告知求助人求助方式【高低】：當(dāng)面，電話，郵件公告3.3.3代碼走杳項(xiàng)目負(fù)責(zé)人指定代碼走查對象相互走查循環(huán)走查代碼走查發(fā)現(xiàn)的問題首先記錄告知代碼作者更新CheckList3.3.4其它3.4PSP個人軟件過程3.4.1工作原則計劃管理：把你想做的寫下來行為管理：按照你寫下來的去做報告管理：把做的事情記錄下來跟蹤管理：出現(xiàn)的問題要設(shè)法解決3.4.2日常工作每日工作每日早晨，規(guī)劃當(dāng)日工作；計劃必須細(xì)化到一個明確的目標(biāo)計劃要有余地，比如會議等計劃是可執(zhí)行的，能夠完成的計劃是可監(jiān)控的每日下班，總結(jié)當(dāng)日工作；計劃完成情況未能完成原因個人心得：新的發(fā)現(xiàn)，新的方法，新的問題會議會議之前，仔細(xì)閱讀會議資料如有疑問，可以發(fā)郵件向會議主持人提出或者在會議上提出會議中，記錄會議要點(diǎn)如要參與討論，請?jiān)趧e人發(fā)言結(jié)束后發(fā)言，不要打斷別人會議后，如有新的想法，發(fā)郵件或者當(dāng)面向會議主持人提出求助如果一個問題20分鐘還不能理出一個頭緒，應(yīng)當(dāng)立即求助求助對象：個人認(rèn)為能夠解決該問題的人為第一對象不能確認(rèn)的，項(xiàng)目負(fù)責(zé)人為第一求助對象發(fā)出求助后，個人負(fù)責(zé)追蹤求助，