同濟大學軟件工程實習總結報告資料

生產(chǎn)實習報告

實習日程安排我從2004.8到2004.11在這家公司公司進行實習。剛開始的幾個星期，公司經(jīng)理安排我學習一些有關游戲方面的技術，幫我快速的對游戲行業(yè)入門。接下來的時間，經(jīng)理安排我進行一些實戰(zhàn)開發(fā)，難度從簡單到難。所進行開發(fā)的項目我會在實習收獲和體會這段中具體闡述。實習收獲和體會我在公司主要開發(fā)了一個圖形轉換器，制作一個InstallShiled安裝程序和關于3D處理的MMX技術，下面我將介紹我的工作情況和工作收獲。圖形轉換器：1.設計文檔 一：功能描述：此軟件能將TGA，BMP等圖形格式轉換為任意制定的格式功能細化：能顯示指定的圖片（TGA,RGBA等格式）能顯示指定圖片的參數(shù)（長度，寬度，圖片的格式）進行轉換的時候能檢查該圖片長，寬是否為2的冪次，如果不是則發(fā)出通知信息具有批處理功能，給定一個文件目錄，能將該目錄下的所有圖片轉換為DDS格式轉換為DDS時候可以指定MipMap值二：模塊劃分：UI界面+轉換模塊轉換模塊：以DLL的形式，針對不同的平臺各寫一個其接口為：boolChangeTo(constchar*SrcName,constchar*DestName,TYPEtype)enumTYPE{BMP=1,JPEG=2,DDS=3}；constchar*SrcName,constchar*DestName應該換成一個結構體SrcName：指定的圖片名字DestName:轉換的圖片名字UI界面：采取多文檔視圖結構三：重要結構structDDS_PIXELFORMAT{DWORDdwSize;DWORDdwFlags;DWORDdwFourCC;DWORDdwRGBBitCount;DWORDdwRBitMask;DWORDdwGBitMask;DWORDdwBBitMask;DWORDdwABitMask;};structDDS_HEADER{DWORDdwSize;DWORDdwHeaderFlags;DWORDdwHeight;DWORDdwWidth;DWORDdwPitchOrLinearSize;DWORDdwDepth;DWORDdwMipMapCount;DWORDdwReserved1[11];DDS_PIXELFORMATddspf;DWORDdwSurfaceFlags;DWORDdwCubemapFlags;DWORDdwReserved2[3];};四：開發(fā)平臺VC6.0+DX9.02.接口文檔接口說明一接口代碼：classIImageChange{public: virtualboolChangeTo(ImageInfo*pImageInfo)=0; virtualchar*GetDllName()=0; virtualvoidSetDirectory(constchar*szDirName)=0;};上面是一個接口類，這里模仿COM的方法，設計一個抽象類。任何ImageChangeDLL必須繼承以上接口類。Example:classCImageChangeToDDS:publicIImageChange{public: CImagaChangeToDDS(); ~CImageChangeToDDS(); virtualboolChangeTo(ImageInfo*pImageInfo); virtualchar*GetDllName(); virtualvoidSetDirectory(constchar*szDirName);};二接口類成員函數(shù)說明：virtualboolChangeTo(ImageInfo*pImageInfo)=0;該接口函數(shù)傳入一個ImageInfo結構的指針(ImageInfo是中間圖象數(shù)據(jù)類型，詳見《中間數(shù)據(jù)結構文檔》)。用戶可以在自己類中override該函數(shù)，該函數(shù)可以按自己意愿任意轉換為自己想要的格式。virtualchar*GetDllName()=0;該接口函數(shù)返回一個代表該該接口的字串，可以說明該接口類的功能和版本。virtualvoidSetDirectory(constchar*szDirName)=0;該接口函數(shù)設置批處理轉換功能時的目的文件夾。三DLL說明：DLL一共導出2個函數(shù)：extern"C"{ IImageChange*CreateInstance();}extern"C"{ voidReleaseInstance(IImageChange*pObj);}IImageChange*CreateInstance()產(chǎn)生一個派生自IimageChange的實例，該實例導入到應用程序進程中。voidReleaseInstance(IImageChange*pObj);釋放從CreateInstance()產(chǎn)生的實例資源。三接口實現(xiàn)#defineFILENAMELEN128#definePALNUM256typedefunsignedcharIMG_BYTE;typedefunsignedshortIMG_WORD;typedefunsignedlongIMG_DWORD;typedeflongIMG_LONG;typedefboolIMG_BOOL;typedefDWORDIMG_ARGB;typedefvoid*IMG_LPVOID;enumIMAGE_DATA_TYPE{ //depth32bit IDT_A8R8G8B8=1, IDT_X8B8G8R8=2, //depth24bit IDT_R8G8B8=3, //depth16bit IDT_R5G6B5=4, IDT_X1R5G5B5=5, IDT_A4R4G4B4=6, IDT_X4R4G4B4=7, //depth8bit IDT_A1R2G3B2=8, IDT_R3G3B2=9, IDT_INDEX8=10, //depth4bit IDT_A1R1G1B1=11, IDT_X1R1G1B1 =12, IDT_INDEX4=13, //depth1bit IDT_C1=14,//monochrome0:BLACK1：WHITE IDT_INDEX1 =15, IDT_UNKNOWN=-1,};structImageHeader{ IMG_DWORDdwSize; IMG_LONGlWidth; IMG_LONGlHeight; IMG_BYTEbDepth;//象素的深度 IMG_BYTEbReserve1[3]; IMAGE_DATA_TYPEIDT_TYPE; IMG_WORDwPlanes;//MustBeZero IMG_WORDwReserve2; IMG_DWORDdwReserve;//保留字，可以填充任意數(shù)據(jù)，如：指向用戶分配的一段內(nèi)存 IMG_DWORDdwPalClrNum;//調色板的顏色數(shù)，如果為-1，則不存在調色板；若為1，4，8，16 //代表調色板的顏色總數(shù) IMG_ARGBPalColors[PALNUM];//調色板的數(shù)據(jù)，dwPalClrNum如果為-1，則該數(shù)據(jù)無效};structImageInfo{ DWORDdwSize; LONGlOffset;//該結構與數(shù)據(jù)的偏移，以BYTE為單位 ImageHeaderiiInfo; LPVOID*pData;};轉換模塊：以DLL的形式，針對不同的平臺各寫一個其接口為：boolChangeImage(ImageHeader*pImageHeader)3.中間數(shù)據(jù)格式說明一中間數(shù)據(jù)格式：structImageInfo{ DWORDdwSize; //ImageInfo結構大小 LONGlOffset; //該結構與數(shù)據(jù)的偏移，以BYTE為單位 TCHARFileName[FILENAMELEN];//源圖形文件名 ImageHeaderheader;//圖形中間數(shù)據(jù)的頭信息 LONGlDataSize; //圖形的數(shù)據(jù)區(qū)大小 LPVOIDpData;//圖形的數(shù)據(jù)區(qū)指針};structImageHeader{ DWORDdwSize;//ImageHeader結構大小 LONGlWidth;//位圖的寬度,單位：pixel LONGlHeight;//位圖的高度,單位：pixel WORDwDepth;//象素的深度，代表一個象素占多少位 WORDwReserve1;//MustBeZero IMAGE_DATA_TYPEIDT_TYPE;//位圖數(shù)據(jù)存儲類型 WORDwPlanes; //MustBeZero WORDwReserve2;//MustBeZero DWORDdwReserve;//保留字，可以填充任意數(shù)據(jù)，如：指向用戶分配的一段內(nèi)存 DWORDdwPalClrNum;//調色板的顏色數(shù)，如果為0，則不存在調色板；若為1，4，//代表調色板的顏色總數(shù) ARGBPalColors[PALNUM];//調色板的數(shù)據(jù)dwPalClrNum如果為0，則該數(shù)據(jù)無效};enumIMAGE_DATA_TYPE{ //depth32bit IDT_A8R8G8B8 =1, IDT_X8B8G8R8 =2, //depth24bit IDT_R8G8B8 =3, //depth16bit IDT_R5G6B5 =4, IDT_X1R5G5B5 =5, IDT_A1R5G5B5 =6, IDT_A4R4G4B4 =7, IDT_X4R4G4B4 =8, //depth8bit IDT_R3G3B2 =9, IDT_INDEX8 =10, //depth4bit //IDT_A1R1G1B1=11, //IDT_X1R1G1B1=12, IDT_INDEX4 =13, //depth1bit IDT_INDEX1 =14, IDT_UNKNOWN=-1,};二.使用InstallShield制作安裝程序修改InstallShield對話框的過程：一：改變InstallShield自帶的對話框的方法1.首先用VC.NET打開_isres.dll資源DLL,該DLL是InstallShield自帶的DLL,里面存放了InstallShield中所有自帶對話框模板。2.在VC.NET中修改對話框（對話框ID可以通過DialogSampler工具得到）3.保存修改。注意：修改InstallShield自帶的對話框只能修改一些文本，和一些控件的相對位置，不能修改控件的ID和增加一些控件，不然會導致控件消息映射不正確。二：自制可以在InstallShield對話框：1.首先用VS.NET打開<InstallShieldlocation>\Examples\CustomDialog\VC++4Project\_isuser.rc，這是一個模板資源，可供用戶任意編輯.2.生成自己的對話框，保存DLL.3.寫對話框處理函數(shù)（跟windows下的對話框處理函數(shù)類似）注意：一定要保存所有的控件ID-ValueInstallShield總結文檔：1.制作自己的對話框作為自己的主界面（修改-isuser.dll,路徑為：C:\ProgramFiles\InstallShield\Professional-StandardEdition\Redistributable\CompressedFiles\0009-English\Intel32）2.設置背景圖3.按照InstallShield默認的流程進行安裝（也可以按照自己實際需求改動，比如加入自己的對話框）如果InstallShield提供的對話框不符合用戶要求，可以修改_isres.dll,（路徑為C:\ProgramFiles\InstallShield\Professional-StandardEdition\Redistributable\CompressedFiles\0009-English\Intel32）一些技巧：1.在修改InstallShield自帶的對話框時，我們可以用DialogSampler工具查看所要修改對話框的ID2.用InstallShield寫注冊表時，首先必須要調用RegDBSetDefaultRoot來設置rootkey3.如果要手工控制進度條，可以用SetStatusWindow和StatusUpdate函數(shù)來控制4.InstallShield函數(shù)調用順序：OnBegin-->OnFirstUIBefore-->OnMainUIBefore-->OnMoving-->OnInstallingFile-->OnUninstallingFile-->OnMoved-->OnFirstUIAfter-->OnMainUIAfter-->OnEnd5.反安裝程序制作：反安裝程序的路徑放在注冊表中（可在MSDN中搜索Uninstall可以查的該路徑），所以只要寫一個windows程序去調用這個反安裝程序。

三.關于3D處理的MMX技術 具有MMX?技術的處理器的在片高速緩存子系統(tǒng)，是由兩個16K的4路線長為32字節(jié)的關聯(lián)高速緩存體構成。高速緩存具有一個回寫機制和一個偽LRU的置換算法。數(shù)據(jù)的高速緩存由八個按四字節(jié)邊界交錯的存貯體構成。

在具有MMX?技術的奔騰處理器上，只要引用的數(shù)據(jù)不在同一個高速緩存體上，就可以被一條讀取指令和一條存貯指令同時訪問。在具有MMX?技術的奔騰處理器上，高速緩存訪問失敗的遲延為8個內(nèi)部時鐘周期。在具有MMX?技術的動態(tài)執(zhí)行處理器中，最小遲延是10個內(nèi)部時鐘周期。具有MMX?技術的奔騰處理器和動態(tài)執(zhí)行處理器在分支預測方面，除一個較小的異常處理外(本書2.3.1節(jié)中討論)，在功能上完全一樣。

分支目標緩沖區(qū)(BTB)存貯了預先所見的分支和它們的目標。當一個分支被預取后，BTB將目標地址直接填入到指令讀取單元(IFU)。一旦分支被執(zhí)行，BTB將隨著目標地址而改變。使用分支目標緩存時，預先所見的分支被動態(tài)預告。分支目標緩存的預測算法包括了模式匹配和每目標多達4位的預測歷史位。例如，一個具有4個迭代長度的循環(huán)將百分之百地被正確預測到。遵循下列原則將提高預測性能：

編寫條件分支(除循環(huán)外)可將最常執(zhí)行的分支緊接在分支指令后(即失敗)。

另外，具有MMX?技術的處理器有一個堆棧返回緩存(RSB,ReturnStackBuffer)，可以連續(xù)地為不同地址上調用的過程正確地預測其返回地址，進一步為展開具有函數(shù)調用的循環(huán)帶來了益處，并刪除了某些需要in-line的過程。另外，在具有MMX?技術的奔騰處理器上，如果兩個分支指令的最后一個字節(jié)在同一個按四字節(jié)對齊的內(nèi)存段內(nèi)，則分支不可預測。如下圖所示：圖2-5相連分支的例子這種情況，發(fā)生在兩個相連分支間沒有間隔指令且第二個指令只有兩個字節(jié)長的情況下(如+/-128字節(jié)的相對跳轉指令)。

為避免這種無法預測的情況，應使第二分支加長，在分支指令中用16位的相對位移代替8位的相對位移。具有MMX?技術的處理器具有4個寫緩存(相對無MMX?技術的奔騰處理器的兩個寫緩存)。另外，寫緩存可以被U管道使用，也可以被V管道使用(相對無MMX?技術的奔騰處理器的一個寫緩存對應一個管道的情況)。通過對內(nèi)存寫操作進行安排調度，可以提高關鍵循環(huán)的性能。如果你不想看到寫未命中，每組指令不能安排多于4條寫指令。并在安排另外的寫指令前調度其它指令。Intel的MMX?技術是對Intel體系結構(IA)指令集的擴展。該技術使用了單指令多數(shù)據(jù)技術(SIMD)技術，以并行方式處理多個數(shù)據(jù)元素，從而提高了多媒體和通訊軟件的運行速度。MMX?指令集增加了57條新的操作碼和一個新的64位四字數(shù)據(jù)類型。這種新的64位數(shù)據(jù)保持了可供MMX?指令操作的成組數(shù)據(jù)值……

MMX技術在16位高彩和24位真彩數(shù)據(jù)方面作的并不是最好。封裝好的加，乘邏輯運算符實際上已使得24位成了最具有吸引力的運算方式。它包含了3個8位（紅，綠，蘭）元素或？位固定點（48位是給RGB的）。完成運算之后（像Gouraud陰影，alpha，等），算法轉化成RGB16（555或565）以來更新緩存。MMX技術并沒有內(nèi)置的算法，也沒有為5位而封裝的塊。

24位的內(nèi)部運算符使得能提供用8位調色板無法得到的高質量的色彩。包括：

為霧化，透明化的alpha混合

為橙色火光的RGB（多色彩）的光亮，等等

擬鏡的加亮區(qū)

瞬間在屏幕上顯示多于256種顏色

真正平滑的陰影，隨意的混合色彩

少量（或沒有）抖動色彩

與其它應用的調色板沒有沖突或不協(xié)調

與高彩的容量和色彩可媲美，接近于HW加速器

當然，系統(tǒng)的圖像存儲器的容量決定了是能用16位還是24位彩色。對于1MB的顯卡，只能使用8位的調色板（640*480*2字節(jié)需要600KB，如果沒有雙倍緩沖，或后備緩沖在存儲系統(tǒng)中，這只能適應于1MB）。對于2MB或4MB的顯卡，16位就很誘人了。640*480雙倍緩沖后，占用1.2M，仍留下800KB給字符緩存或Z-緩沖。

8位色準許使用一個簡單的MOVQ指令來同時以東8個點。如果有了MMX技術的執(zhí)行單元和“pairing”指令，它也準許16個點的同時比較或（和）混合。不幸的是，8位的調色器處理需要在同一時間內(nèi)從調色板中讀出一個字節(jié)。

一直以來，老式處理器的8位處理代碼在新的CPU上實際上是扮演著“速度絆腳石”的角色來降低性能。為了奔騰處理器和DynamicExecution（TM）處理的高速度，這應被避免。例子如下：

自修改代碼，它用新的地址或即時值重寫了部分指令流。這使得避免使用其它注冊者來得到數(shù)據(jù)。在新的CPU中，每個被修改的指令會浪費許多的時鐘周期。因為深層的管道必須被清空，而且緩存必須要重寫重取。

隨機（不是順序）進入存儲區(qū)，作為乘法查找的結果，顏色變幻，陰影化或抖動

經(jīng)常的數(shù)據(jù)獨立分支，尤其當他們的順區(qū)不規(guī)則時

與8位或16位（AL，AH，AX，BL….）一樣，32位的注冊是很優(yōu)秀的，將8位像素點的乘法和簡單的32位寫或0溢出單獨字節(jié)結合起來

使用MMX指令開發(fā)時候需要注意的調整代碼，一般情況下不使用向前條件分支，通常使用向后的條件分支。按16字節(jié)邊界條件對齊頻繁執(zhí)行的分支目標。將循環(huán)展開來調度指令。使用軟件方式來安排流水線以調度遲延和功能單元。必須成對使用CALL和RET(return)指令。避免使用自修改代碼。避免把數(shù)據(jù)放在代碼段。盡可能快地計算出存貯地址。應避免使用包含三個或三個以上微操作代碼或指令長度超過7個字節(jié)的指令。如果可能，使用只有一個微操作的指令。不要使用兩個8位讀取指令來進行16位的讀取。在調用被調用保存(callee—save)過程前，先清除部分寄存器的內(nèi)容。解決阻塞條件，如存貯地址，盡可能地避免可能引起阻塞的讀取。一般情況下，一個可以直接由處理器支持的N-字節(jié)的數(shù)據(jù)(8位的字節(jié)，16值的字，32位的雙字，32位、64位及80位浮點數(shù))應該對齊在下一個最高的2的乘方邊界處，避免未對齊的數(shù)據(jù)。

——按任意邊界對齊8位數(shù)據(jù)。

——在已對齊的4-字節(jié)字數(shù)據(jù)內(nèi)對齊16位數(shù)據(jù)。

——以4的任意倍數(shù)為邊界，對齊32位數(shù)據(jù)。

——以8的任意倍數(shù)為邊界，對齊64位數(shù)據(jù)。

——以128位為邊界(即16字節(jié)的倍數(shù))，對齊80位數(shù)據(jù)。合理化建議 我覺得學院開的很多課程的順序不對，而且有的課程能放在實習結束后再上效果可能會更好，比如：軟件工程，軟件測試等，實習前只要將一些基礎的課程學好就行了。附錄1:軟件測試本人目前所在的項目組沒有專門的軟件測試人員，因此我們充當了雙重角色，即是開發(fā)人員也是測試人員，本人因此對測試有了更多更深入的了解，在實踐方面，除了做最基本的單元測試，功能測試外，還參與了集成測試，系統(tǒng)測試，用戶驗收測試。下面先介紹一些軟件測試的相關概念和方法，再結合本人的實踐談談我們是如何做軟件測試的，以及心得體會。軟件測試的基本概念和方法 軟件測試方法在不同的書籍中可能有不同的分類，不同的叫法和不同的解釋。比如，從測試人員角度看，可分為手動測試和自動測試。從源代碼的角度可分為單元測試和功能測試。從理論定義來分，可分為黑箱測試，白箱測試和灰箱測試。而實際項目主要側重于軟件功能的黑箱測試方法：功能測試（FunctionalityTest），驗收測試（AcceptanceTest），用戶界面(Userinterface)測試，性能測試（PerformanceTest），壓力測試（StressTest）。下面就簡單介紹一下這些測試方法的概念。 白箱測試：通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要從代碼句法發(fā)現(xiàn)內(nèi)部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。 黑箱測試：通過使用整個軟件或某種軟件功能來嚴格地測試，而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的。測試人員通過輸入他們的數(shù)據(jù)然后看輸出的結果從而了解軟件怎樣工作。 灰箱測試：就像黑箱測試一樣是通過用戶界面測試，但是測試人員已經(jīng)有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的。甚至于還讀過部分源代碼。因此測試人員可以有的放矢地進行某種確定的條件/功能的測試。 功能測試：驗證測試軟件功能能否正常按照它的設計工作?？催\行軟件時的期望行為是否符合原設計。 驗收測試：是在把測試的版本交付測試部門大范圍測試以前進行的對最基本功能的簡單測試。因為在把測試的版本交付測試部門大范圍測試以前應該先驗證該版本對于所測試的功能基本上比較穩(wěn)定。必須滿足一些最低要求 用戶界面測試：分析軟件用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單，對話框及對話框上所有按鈕，文字，出錯提示，幫助信息（Menu和Helpcontent）等方面的測試。 性能測試：通常驗證軟件的性能在正常環(huán)境和系統(tǒng)條件下重復使用是否還能滿足性能指標?；蛘邎?zhí)行同樣任務時新版本不比舊版本慢。一般還檢查系統(tǒng)內(nèi)存在運行程序時會不會泄漏。比如，驗證程序保存一個巨大的文件新版本不比舊版本慢。 壓力測試：它通常驗證軟件的性能在各種極端的環(huán)境和系統(tǒng)條件下是否還能正常工作?；蛘哒f是驗證軟件的性能在各種極端環(huán)境和系統(tǒng)條件下的承受能力。軟件測試的重要性 軟件測試是保證軟件產(chǎn)品質量的重要手段之一。它是測量、評估軟件產(chǎn)品特點和能力的活動?，F(xiàn)在，國內(nèi)一些軟件企業(yè)對于軟件測試的重視程度還很不夠，認為測試工作非常簡單，只是簡單地操作所測的軟件產(chǎn)品而已。這種錯誤的思想嚴重影響了國內(nèi)軟件質量，應該引起我們的高度重視。 下面就看一個例子。微軟公司是軟件行業(yè)的老大，他們對軟件測試的重視程度是許多同行無法比擬的。在微軟內(nèi)部，軟件測試人員與軟件開發(fā)人員的比率一般為1.5--2.5左右，微軟軟件開發(fā)的實踐過程已經(jīng)證明了這種人員結構的合理性與正確性。國內(nèi)公司顯然很難達到這種比率，沒關系我們剛剛起步，人多人少不是問題所在，關鍵在于觀念與態(tài)度，國內(nèi)軟件業(yè)和國外相比，最大的差異也許就在于產(chǎn)品質量和質量控制。而軟件測試才能為產(chǎn)品質量和質量控制提供保證。心得體會 本人覺得一個好的軟件測試員，應該培養(yǎng)以下一些素質：懷疑精神。世界上沒有絕對正確的，總有錯誤的地方，軟件也是。所以在測試時，不要輕易對自己說“這里肯定沒問題”。打破砂鍋問到底的精神，對于只出現(xiàn)過一次的bug，一定找出原因，不解決誓不罷休。保持一個良好的心情，否則可能無法把測試作好。不要把生活中的不愉快的情緒帶到工作中來。測試不像開發(fā)，很明顯有任務要去完成，測試似乎更具神秘性，需要你去發(fā)現(xiàn)，糟糕的心情無法讓你靜下心來，也就很難做好測試。

附錄2:軟件配置當今計算機信息技術產(chǎn)業(yè)的迅猛發(fā)展，促進了國內(nèi)的軟件開發(fā)在先進技術和產(chǎn)品方面的廣泛應用。但是，在先進的操作系統(tǒng)，開發(fā)工具為企業(yè)帶來高效益的同時，另一方面也使得我們的開發(fā)環(huán)境日趨復雜化而難以管理。如：團隊溝通困難，軟件重用率低下，代碼冗余度高，文檔不健全等，結果造成數(shù)據(jù)丟失，開發(fā)周期漫長，產(chǎn)品可靠性差，質量低劣，軟件維護困難，用戶抱怨使用不便，項目風險增加等。

事實已經(jīng)表明，隨著整個軟件業(yè)的迅速發(fā)展，沒有得到有效管理的軟件開發(fā)過程中所出現(xiàn)的風險和挑戰(zhàn)將越來越突出。加強軟件開發(fā)管理，通過管理和追蹤軟件開發(fā)環(huán)境中產(chǎn)生的變更，建立規(guī)范化的軟件開發(fā)環(huán)境，已成為軟件產(chǎn)業(yè)化的必要條件。軟件配置管理作為軟件開發(fā)過程中一個重要過程已經(jīng)逐漸受到各軟件企業(yè)的重視。

軟件配置管理（SoftwareConfigurationManagement），是一個控制軟件系統(tǒng)演變的學科。在IEEE標準729-1983中，軟件配置管理的定義包括：配置標識——產(chǎn)品的結構、產(chǎn)品的構件及其類型，為其分配唯一的標識符，并以某種形式提供對它們的存取。版本控制——通過建立產(chǎn)品基線，控制軟件產(chǎn)品的發(fā)布和在整個軟件生命周期中對軟件產(chǎn)品的修改。例如，它將解決哪些修改會在該產(chǎn)品的最新版本中實現(xiàn)的問題。狀態(tài)統(tǒng)計——記錄并報告構件和修改請求的狀態(tài)，并收集關于產(chǎn)品構件的重要統(tǒng)計信息。例如，它將解決修改這個錯誤會影響多少個文件的問題。審計和審查——確認產(chǎn)品的完整性并維護構件間的一致性，即確保產(chǎn)品是一個嚴格定義的構件集合。例如，它將解決目前發(fā)布的產(chǎn)品所用的文件的版本是否正確的問題。生產(chǎn)——對產(chǎn)品的生產(chǎn)進行優(yōu)化管理。它將解決最新發(fā)布的產(chǎn)品應由哪些版本的文件和工具來生成的問題。過程管理——確保軟件組織的規(guī)程、方針和軟件周期得以正確貫徹執(zhí)行。它將解決要交付給用戶的產(chǎn)品是否經(jīng)過測試和質量檢查的問題。小組協(xié)作——控制開發(fā)統(tǒng)一產(chǎn)品的多個開發(fā)人員之間的協(xié)作。例如，它將解決是否所有本地程序員所做的修改都已被加入到新版本的產(chǎn)品中的問題。 軟件配置管理的解決方案涉及面很廣，將影響軟件開發(fā)環(huán)境、軟件過程模型、配置管理系統(tǒng)的使用者、軟件產(chǎn)品的質量和用戶的組織機構。 軟件組織應該提出不同層次的配置管理視角，這些層次包括：公司級、項目級、程序員級和應用級。公司級視角提供組織的全貌圖和配置管理過程的描述；項目級視角是與項目相關的各項目組可以使用不同的配置管理方案；程序員級視角是專門為程序員提供的且具有某些特定的配置管理功能；應用級視角關心的是配置管理如何應用到具體的問題中去。軟件配置管理（SoftwareConfigurationManagement(SCM)），它為軟件開發(fā)提供了一套管理辦法和活動原則，成為貫穿軟件開發(fā)始終的重要質量保證活動。需要說明的是，從學術上講，軟件配置管理（SCM）只是變更管理（ChangeManagement(CM)）的一個方面；但從SCM工具的發(fā)展來看，越來越多的SCM工具開始集成變更管理（CM）的功能，甚至問題跟蹤（DefectTracking）的功能。附錄3:團隊軟件開發(fā)實踐喜歡足球的朋友應該非常清楚一件事情，那就是在一場足球賽中假如球員之間缺少默契的配合或教練的指導思想執(zhí)行不到位等情況下，那場比賽多半是以失敗告終的，因為這支球隊并不是優(yōu)秀的球隊。開發(fā)軟件項目就象一場進行中的足球賽，是靠項目管理、系統(tǒng)分析設計、程序編制、測試、市場營銷等不同角色人員共同協(xié)作完成的，不同角色的人執(zhí)行的工作相互促進和制約著其它角色的人的工作，因此一個高效的軟件開發(fā)團隊是高質量軟件項目或產(chǎn)品的保證，可如何才能營造高效軟件開發(fā)團隊呢？從以下幾個方面來說明：一、高效軟件開發(fā)團隊的特征

高效的軟件開發(fā)團隊是建立在合理的開發(fā)流程及團隊成員密切的合作的基礎之上的，成員共同的迎接挑戰(zhàn)、有效的計劃、協(xié)調和管理各自的工作以至完成明確的目標，高效的開發(fā)團隊具有如下特征：

1、具有明確且有挑戰(zhàn)性的共同目標

一個具有明確的而且有挑戰(zhàn)性目標的團隊比目標不明確或不具有很大的挑戰(zhàn)性目標的團隊效率高得多，通常技術人員往往會因為完成了某個明確的任務，而且這個任務的完成具有挑戰(zhàn)性的意義而感到自豪，反過來團隊成員為了獲取這種自豪的感覺而更加積極的工作從而帶來團隊開發(fā)的高效率，如作為系統(tǒng)設計人員很清楚的知道在什么時候要做到什么，什么時候開始做，什么時候必須完成，為了完成工作必須面臨哪些挑戰(zhàn)，怎么解決這些困難等為設計出一個高質量的軟件項目提供了重要保證，而模模糊糊的去設計一個系統(tǒng)或模模糊糊的就去編寫代碼是非常危險的，而且會為此付出高昂代價，因此高效的軟件開發(fā)團隊具有挑戰(zhàn)性的共同目標。2、團隊具有很強的凝聚力

在一個高效的軟件開發(fā)團隊中，成員們凝聚為一個整體共同進行工作，他們是相互支持、互相交流、互相尊重的，而不是相互推卸責任、保守、相互指責的，在一些散亂的開發(fā)團隊中往往存在這樣的問題，一些程序員是比較保守的，明明知道另外的模塊中需要用到一段與自己已經(jīng)編寫完成但有些難度的程序代碼，他也不愿拿出來給其它程序員共享，不愿與系統(tǒng)設計人員交流，這樣給項目的進度造成了些不可度量的因素。3、具有融洽的交流環(huán)境

在一個開發(fā)團隊中，每個人行使自己的職責，如需求分析人員制定需求規(guī)格說明、系統(tǒng)設計人員做系統(tǒng)概要設計和詳細設計、項目經(jīng)理配置項目開發(fā)環(huán)境并且制定項目計劃等，但每個人的工作不可能做到完美的，如系統(tǒng)概要設計的文檔可能有個別地方詞不達意，做詳細設計的時候就可能會造成誤解，項目經(jīng)理制定計劃時可能忽略了某種風險的存在而造成執(zhí)行者過于緊張的壓力等等情況都需要大家通過交流、反饋的手段然后協(xié)商解決的，因此高效的軟件開發(fā)團隊是具有融洽的交流環(huán)境的，而不是那種簡單的命令執(zhí)行式的。4、具有共同的工作規(guī)范和框架

高效軟件開發(fā)團隊具有規(guī)范性及共同框架的工作，對于項目管理具有規(guī)范的項目開發(fā)計劃，對于分析設計具有規(guī)范和統(tǒng)一框架的文檔及審評標準，對于代碼具有程序規(guī)范條例，對于測試有規(guī)范且可推理的測試計劃及測試報告等等。并且所有成員都明白自己的職責，知道必須完成什么計劃？由誰來完成？什么時候開始？什么時候結束？按什么順序？等，總之一個高效的開發(fā)團隊無論是工作內(nèi)容還是工作流程都具有不同程度的規(guī)范性和標準風格的框架。5、采用合理的開發(fā)過程

軟件的開發(fā)不同于一般商品的研發(fā)和生產(chǎn)，開發(fā)過程中會面臨著各種難以預測的風險，比如需求的變化、人員的異動、技術的瓶頸、同行的競爭等，高效的軟件開發(fā)團隊往往是采用了合理的開發(fā)過程去控制開發(fā)過程中的風險、提高軟件的質量、降低開發(fā)費用，這樣的團隊會根據(jù)自身的必要程度決定要執(zhí)行哪些工作？如配置管理、資源管理、版本控制、代碼控制等，團隊還合理的分劃并定義開發(fā)過程的里程碑，決定每項活動內(nèi)容的底線和審評標準，決定各項活動的先后關系或迭代的關系等?？傊咝У能浖_發(fā)團隊的開發(fā)過程的原則是高效率、高質量、低成本。

二、目前國內(nèi)軟件開發(fā)團隊容易存在的問題由于傳統(tǒng)的舊體制下的管理思想的沿襲、大部分中國人傳統(tǒng)的思維習慣及軟件行業(yè)在中國發(fā)展的處于初期階段等原因，使國內(nèi)的許多軟件開發(fā)團隊在領導、合作、質量、參與等方面存在一些問題，具體如下：

1、領導不力

有效的領導是高效率軟件開發(fā)團隊的基本要求，如果領導不力，工作計劃就不一定會合理，團隊成員也不一定會投入工作的熱情，使團隊的凝聚力大打折扣；如果領導不力，就不一定有明確且具有挑戰(zhàn)性的目標，團隊成員就無法完成高質量的項目產(chǎn)品，無法投入信心和激情。傳統(tǒng)的舊體制下的管理思想的沿襲，是部分領導還具有老大爺?shù)男膽B(tài)，于是貪功、推卸責任、明則保身等一系列現(xiàn)象也相繼而生；如果領導不力，就無法營造融洽的交流環(huán)境，團隊的工作便是死板的沒有生氣的；如果領導不力，就不知道采用什么樣的開發(fā)過程是合理的，就不可能高效率、高質量的完成軟件項目。領導不力還可能導致其它問題的出現(xiàn)。2、缺少必要的信心和激情

也許你會發(fā)現(xiàn)周圍的一些同事僅僅是為了薪水而工作，在執(zhí)行工作的時候即使發(fā)現(xiàn)了上層領導忽略的問題依然照糊涂畫瓢也不反饋問題所在，即便他是個天才，但成功不會屬于他的，因為成功垂青于有激情的人才，其實這些同事并不是一開始就缺少激情的，原因也許是失去了信心，而暫時做"糊涂人"而已，無論如何，缺少信心和激情的團隊，只會是一盤散沙。3、軟件質量的價值觀念模糊

軟