軟件項目開發過程中國科學院軟件研究所高級技術培訓中心軟件項目什么是軟件項目完成特定目的、符合用戶特定需求的軟件所需的組織結構和過程、規范的集合軟件項目的實施需要周密的部署，合理的規章制度，符合項目的路線（軟件過程），良好的項目管理和人員安排。相關流程軟件管理特點 軟件生存期過程確定需求開發策劃需求分析概要設計詳細設計編碼與調試測試軟件集成、聯調內部確認復制、交付、安裝試運行、用戶驗收運行、維護退役軟件管理配置與變更管理環境、工具和技術有關軟件的法規和標準周密策劃以保證 軟件質量管理體系八項質量管理原則過程方法基于過程的質量管理體系模式實施質量管理體系的意義實施質量管理體系工作重點企業發展力量分析軟件管理特點軟件產品的特點軟件產品的質量，完全取決于其設計和開發水平軟件需求的模糊性、變化性使軟件產品難以成熟任何一個軟件產品，或多或少總會存在一些故障(BUG)軟件人員廣泛存在的不規范的開發習慣使開發過程難以管理軟件質量指標難以量化軟件測試理論和技術尚未解決軟件產品正確性的驗證問題軟件產品質量特性：滿足需求能力的一系列特性總和功能、可靠性、易用性、效率、維護性、可移植性軟件管理必須在市場(用戶)需求和軟件成熟性之間進行權衡 軟件生存期過程確定需求開發策劃需求分析概要設計詳細設計編碼與調試測試軟件集成、聯調內部確認復制、交付、安裝試運行、用戶驗收運行、維護退役確定需求確定外部用戶需求上級下達的軟件開發課題本單位根據市場需要確定的開發課題用戶合同要求的軟件開發任務輸出可行性分析報告技術、經濟、社會可行性，風險對策合同及評審記錄產品要求得到規定和滿足單位有能力滿足規定的要求 開發策劃確定開發目標確定項目開發的技術路線(開發的出發基線、對現有產品的復用、委托開發等)確定應遵循的標準、法律和法規選任開發項目經理劃分開發階段確定各階段的輸入和輸出文件確定質量控制點(評審點、驗證點和確認點)及其實施的責任人、實施方式等設計項目開發進度確定開發人員并分配職責提出開發所需資源(軟件、硬件開發環境及工具軟件、設備、資金等)要求并予以落實制定配置管理計劃和質量保證計劃開發策劃(續)輸出策劃報告開發項目實施計劃配置管理計劃質量保證計劃等需求分析確保項目的開發符合用戶的需求(可測試性)確定設計輸入任務委托書/招標書前期對用戶的需求調研資料可行性分析報告/投標書合同等 編制內部需求規格(說明)書需求變更控制需求的層次-業務需求、用戶需求和功能需求需求的開發和管理需求驗證驗證是為了確保需求說明準確、完整地表達必要的質量特點客戶的參與在需求驗證中占有重要的位置審查需求文檔以需求為依據編寫測試用例編寫用戶手冊確定合格的標準測試需求測試需求有很多分類方法，最普通的一種就是按照商業功能分類把需求分解成單元的好處：測試需求是測試用例的基礎，分成單元可以更好地進行設計詳細的測試需求是用來衡量測試覆蓋率的重要指標測試需求包括各種測試設計和開發以及所需資源 最好分解到功能點概要設計確保產品的總體結構和模塊間的關系與用戶需求的一致性 內容總體方案設計邏輯框圖接口及通訊協議選用現有產品軟件的選用邊界(約束)條件的設計運行環境設計等輸出概要設計說明書詳細設計詳細設計說明書與概要設計說明書是否相一致 內容算法設計數據格式設計實現流程設計人機界面設計測試用例設計操作設計等輸出詳細設計說明書軟件組裝計劃測試計劃及測試用例安裝手冊(初稿)使用說明書(初稿)產品標準(初稿)編碼與調試內容編寫程序代碼：源代碼→目標代碼→可執行代碼此階段還包括部分軟件模塊的局部測試、集成與聯調根據待開發軟件的規模、控制點及人員安排，可細分為多個小階段輸出軟件(源代碼、目標代碼、可執行代碼及相關數據文件)文檔(幫助文件等)保證編碼風格的一致性，易讀性；增強軟件源碼的可維護性測試按測試發生的順序劃分模塊測試：是對單個軟件模塊的測試單元測試：是對各個軟件功能單元的測試組裝測試：是對各軟件單元之間的互聯測試集成測試：是對硬件裝置、設備和軟件的加入性測試系統測試：項目組所在部門組織的對完成集成的系統的測試(是否滿足產品規格要)確認測試：單位質量控制部門進行的測試(是否滿足產品規格要求)驗收測試：在現場安裝、調試結束并經試運行后，與顧客一起，就滿足合同情況進行的測試(是否滿足合同要求)測試(續)與順序無關的測試聯合測試：當軟、硬件分頭開發完成時，對其組合體進行的測試回歸測試：對因排除不符合項而采取的措施是否產生了其他副作用而進行的確認性測試專項測試：針對某些具體測試項進行的確認性測試。
例如：邊界條件測試等。應根據開發規模，盡可能進行獨立測試。為了保證測試的可信性，被測試的軟件應以源代碼的形式提交，同時說明生成可執行代碼的環境和方法。由測試人員生成可執行代碼，進行測試。 軟件開發的V字模型不可能在需求開發階段真正進行任何測試，因為還沒有可執行的軟件可以在開發組編寫代碼之前，以需求為基礎建立概念性測試用例，并使用它們發現軟件需求規格說明中的錯誤、二義性和遺漏，還可以進行模型分析對V模型的質疑在部分階段延遲進行單元測試和集成測試在不同階段上提前進行測試設計X模型適應現實單元測試、集成測試不斷迭代強調探索性測試統計數字每千行源代碼所包含的bug數，cmm1級為個，cmm2為個，cmm3為個，cmm4為個,而cmm5則只有個軟件集成、聯調應按計劃對所開發的軟件模塊進行組裝并與硬件一起聯調根據需要，規定應填寫的調試記錄內部確認在模擬環境下運行，并監視、記錄運行情況根據任務書或合同的要求進行比照，檢查其是否滿足使用要求對運行情況、測試結果及文檔的齊套性、正確性和一致性進行評審軟件過程有哪些，達到確認復制、交付、安裝軟盤復制、光盤刻錄交付時的版本標識和登記安裝(派技術人員安裝或由用戶自行安裝)記錄軟件安裝實施計劃軟件安裝環境最低需求軟件安裝記錄試運行、用戶驗收以用戶驗收的方式進行最終確認結論軟件設計與需求的一致性程序編碼與軟件設計的一致性文件描述與程序的一致性文件的成套性、完整性、準確性和標準化程度是否通過驗收運行、維護收集使用中發現的問題和顧客意見針對運行中出現的問題，按設計更改程序進行控制記錄用戶服務記錄表退役編寫軟件退役報告，并進行評審配置與變更管理控制對構成軟件產品的各配置項的標識、管理、更改活動，保證軟件配置項的完全性和正確性，防止非預期的使用軟件配置項的范圍合同、技術文檔、質量記錄等基線的確立配置項的存取配置管理實施配置項的標識配置項的變更控制配置項的狀態記錄配置項的檢查和評審媒體控制對軟件存放介質(媒體)的要求和規定軟件的復制(軟件的生產過程)媒體的標識：規則、執行者媒體的貯存(防潮、防火、防磁、防靜電、防病毒)媒體的包裝、運輸文檔資料控制各開發階段應形成的文檔軟件過程有哪些，對其擬、審、批的規定編制文檔資料所依據的標準和規范開發過程中應形成的質量記錄文檔與軟件之間的一致性檢查文檔資料的歸檔與發放版本管理分類開發過程中的版本交付軟件產品的版本管理對象軟件文檔為該產品開發的工具軟件操作配置管理人員，配備一臺計算機(或服務器)開設開發庫、受控庫和產品庫訪問權限對入庫和出庫軟件的控制版本管理(續)開發庫存放正在開發(編寫)或調試(修改)、自測的軟件和文檔受控庫存放開發各階段測試通過的軟件、文檔和工具軟件的版本并給以標識。
轉入下一階段時，從此處發放用作下一階段開始工作的初始版本產品庫存放可交付及已交付軟件、文檔及支持文件的版本各庫內所存放的軟件和文檔，應定期備份，以防止開發成果的意外丟失(文件重寫、介質損壞、意外事故、非法訪問——病毒，黑客，故意破壞等)并保證可追溯性環境、工具和技術開發所需的硬件環境測試所需的硬件環境(包括模擬用戶環境所必要的輸入、輸出設備)開發平臺軟件(操作系統、編程語言、編譯環境、調試工具等)管理軟件診斷軟件測試軟件輔助性軟件(防病毒軟件等) 有關軟件的法規和標準《軟件產品管理辦法》《計算機信息系統集成資質管理辦法(試行)》《計算機軟件保護條例》ISO／IEC 12207—1995信息技術軟件生存周期過程ISO／IECTR 15504軟件過程評估GB／．3—2001質量管理和質量保證標準第3部分：GB信息技術軟件生存周期過程GB／—1994在軟件開發，供應、安裝和維護中的使用指南GB／—90計算機軟件質量保證計劃規范GB／—90計算機軟件配置管理計劃規范等周密策劃以保證 開發人員應具備一定的資格或能力開發環境(軟件和硬件平臺)是適用的編制足夠的控制程序和工作規范(例如開發過程控制程序、變量命名規則、代碼書寫規范、注釋規范等)編制測試用例并在使用前對用例本身進行驗證編制各階段測試計劃，明確規定測試方法以及測試結果的記錄要求、評價方式和接收準則實施配置管理，控制軟件產品(代碼和文檔)版本和更改過程軟件質量管理體系質量體系文件質量手冊 文件控制 記錄控制 管理職責 質量方針、質量目標 職責、權限與溝通 管理評審 資源管理 人力資源 基礎設施和工作環境 產品實現 產品實現的策劃 與顧客有關的過程 設計和開發 采購 開發和服務提供 監視和測量裝置的控制 測量、分析和改進 監視和測量 不合格品控制 數據分析 改進 八項質量管理原則以顧客為關注焦點領導作用全員參與過程方法管理的系統方法持續改進基于事實的決策方法與供方互利的關系過程方法 基于過程的質量管理體系模式實施質量管理體系的意義管理法治化職責更分明接口更明確監督機制加強焦點得到控制競爭能力增強實施質量管理體系工作重點規范管理制度增進內部溝通提高服務質量增強社會信心小結小結軟件開發中的困境如何指定符合項目的計劃項目應該如何去完成如何按期提交項目如何降低項目的風險項目中的人員流動很頻繁怎么辦如何合理的安排已有人員項目不斷變大，文檔和程序不斷的增多用戶的需求在不斷的變化項目中的人員在增加，如何管理好項目的質量如何控制軟件開發過程的模型簡單式(構建＋維護)瀑布式敏捷開發統一軟件開發過程簡單式修改直到用戶滿意系統使用消亡思路或者客戶需求構建第一個版本簡單式過程開發特征系統在沒有任何規范和規則的情況下就開發沒有明確的設計，設計思路都在開發者的頭腦中這種開發方法對于使用周期很短的小項目可用隨著時間的推移，系統的維護越來越困難系統在交付使用時，有可能會出現一系列的錯誤，前期和后期維護成本都很高在大型項目和商用項目中極少使用瀑布式設計階段實現階段集成階段需求階段細化階段使用階段消亡每個階段做完時進行驗證瀑布式開發70年代流行的開發方法自上而下的開發方法每個階段都有軟件質量管理組核實后再進行下一階段的開發每一階段都有測試每個階段都形成了明確的文檔文檔并不總能和系統相符合細化的文檔使得系統的用戶和開發人員難于理解和分辨系統的關系階段之間的對應和檢查變得困難、維護代價高變更應對能力差敏捷開發快速適應系統需求的變化提高軟件生產率突出企業自身特點，體現企業核心能力支持動態聯盟和虛擬組織面向業務目標持續改進和重組敏捷開發的特征輕量級的開發過程基于時間Just 并行基于組件的軟件工程敏捷開發過程軟件的需求是難以預期的，開發方法必需適應變化的需求，在快速的迭代中不斷改進小組成員并不完全按照完整的方法進行開發，而根據具體問題和情況，靈活地去除非增值活動僅僅執行一些必須的活動，使用必須的規則，編寫必須的文檔人的因素被放在第一適合互聯網時代的開發要求主要敏捷開發方法 (XP) (ASD) (FDD) RUP & UML統一軟件開發過程用例驅動用例:能向用戶提供有價值的系統的某種功能以架構為中心軟件架構：系統的最重要的靜態和動態特征迭代和增量式迭代：工作流程的重復、每次的活動都以上次的活動為基礎用例驅動用戶所希望和需要的是什么系統能為每個用戶提供什么功能用例所描述和代表的是用戶與系統交互的一個過程，而這個過程滿足了用戶的某些需求所強調的是系統的功能以架構為中心刻畫了系統的整體設計，忽略了細節設計，刻畫最重要的部分。
什么是最重要的呢？依賴于判斷。判斷的依據是經驗。構架的設計價值取決于執行該任務的人的素質受用戶需求（用戶可能會增加那方面的需求）、軟件應用平臺（計算機硬件、操作系統、數據庫、網絡等）、實施問題、遺留系統集成等的影響用例和架構用例是系統的功能和外衣架構是系統的內在形式兩方面必須并行進化架構只考慮核心功能(5-10%)架構設計原則：先考慮與用例無關的不會變動的方面考慮考慮最重要的功能需求子集迭代和增量式控制迭代過程，劃分每次迭代的目標迭代原則：架構上先實現最粗略的部分功能上先實現最重要的每次迭代盡可能的劃分的細，迭代數量不能太少每次迭代要有規范的檢查機制增量式每次迭代增加一部分設計和實現統一軟件過程的生命周期在軟件過程中，不斷的向用戶提供新的版本每次形成的版本構成了一個循環每個版本形成的過程每次循環由四個階段構成初始想法-->產品系統向用戶提供的功能是什么系統的架構是什么樣子的開發計劃、開支如何、人員安排細化詳細說明產品的功能設計系統的架構構造構造能運行的產品移交產品手冊、測試手冊、用戶培訓、技術支持產品版本形成的迭代過程核心工作流程和四個階段產品版本的相關模型用例模型：系統的功能和用戶的關系分析模型：提煉用例，將用例的實現分配給一組對象設計模型：靜態結構和動態結構子系統、類、接口實現模型：類、接口到組件的映射實施模型：組件到部署物理節點的映射測試模型：測試用例和用例的映射產品版本的相關模型模型間的依賴關系迭代的過程使得每次迭代過程中依賴關系的復雜程度降低軟件過程具體化沒有通用的軟件過程組織因素：組織結構、文化、管理、能力、經驗等領域因素：應用領域的熟悉、競爭對手的提供產品的影響生命周期因素：時間、專業技能技術因素：程序設計語言、開發工具、數據庫系統、框架等 Model軟件能力成熟度模型迄今為止學術界和工業界公認的有關軟件工程和管理實踐的最好的評價模型。
為評估軟件組織的生產能力提供了標準。為提高軟件組織的生產過程指明了方向。CMM概述一個成熟軟件組織具有在全組織范圍內管理軟件、開發過程和維護過程的能力規定的軟件過程被正確無誤地通知到所有員工工作活動均按照已規劃的過程進行，并通過可控的先導性試驗和費效分析使這些過程得到改進對已定義過程中的所有崗位及其職責都有清楚的描述通過文檔與培訓使全組織有關人員對已定義的軟件過程都有很好的理解，從而使其軟件過程所導致的生產率和質量能隨時間的推移得到改進。CMM基本概念軟件過程：人們用于開發和維護軟件及其相關過程的一系列活動，包括軟件工程活動和軟件管理活動。軟件過程能力：描述（開發組織或項目組）遵循其軟件過程能夠實現預期結果的程度，它既可對整個軟件開發組織而言，也可對一個軟件項目而言。軟件過程性能：表示（開發組織或項目組）遵循其軟件過程所得到的實際結果，軟件過程性能描述的是已得到的實際結果，而軟件過程能力則描述的是最可能的預期結果，它既可對整個軟件開發組織而言，也可對一個特定項目而言。軟件過程成熟：一個特定軟件過程被明確和有效地定義，管理測量和控制的程度。CMM基本概念軟件能力成熟度等級：軟件開發組織在走向成熟的途中幾個具有明確定義的表示軟件過程能力成熟度的平臺。
關鍵過程域：每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程域，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目標不起關鍵作用。歸納為：互相關聯的若干軟件實踐活動和有關基礎設施的一個集合。CMM基本概念關鍵實踐：對關鍵過程域的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述“做什么”而不強制規定“如何做”。整個軟件過程的改進是基于許多小的、漸進的步驟，而不是通過一次革命性的創新來實現的，這些小的漸進步驟就是通過一些關鍵實踐來實現。 軟件能力成熟度模型：隨著軟件組織定義、實施、測量、控制和改進其軟件過程，軟件組織的能力也伴隨著這些階段逐步前進，完成對軟件組織進化階段的描述模型。CMM1第一級：初始級 在初始級，企業一般不具備穩定的軟件開發與維護的環境。常常在遇到問題的時候，就放棄原定的計劃而只專注于編程與測試。 CMM2第二級：可重復級 在這一級，建立了管理軟件項目的政策以及為貫徹執行這些政策而定的措施。基于過往的項目的經驗來計劃與管理新的項目。 CMM3第三級：定義級 在這一級，有關軟件工程與管理工程的一個特定的、面對整個企業的軟件開發與維護的過程的文件將被制訂出來。
同時，這些過程是集成到一個協調的整體。這就稱為企業的標準軟件過程。 CMM4第四級：定量管理級 在這一級，企業對產品與過程建立起定量的質量目標，同時在過程中加入規定得很清楚的連續的度量。作為企業的度量方案，要對所有項目的重要的過程活動進行生產率和質量的度量。軟件產品因此具有可預期的高質量。CMM5第五級：（不斷）優化級 在這個等級，整個企業將會把重點放在對過程進行不斷的優化。企業會采取，以達到預防缺陷的目標。同時，分析主動去找出過程的弱點與長處有關過程的有效性的資料，作出對新技術的成本與收益的分析，以及提出對過程進行修改的建議。CMM五級項目－自動取款機系統構建需求儲蓄用戶使用三種功能系統關鍵用例關鍵功能點的關注取款分析用例系統分析模型－靜態建模系統分析模型－動態建模系統設計模型三種模型的關系設計模型－類設計(靜態)設計模型－動態建模設計模型－子系統分組實現模型測試模型對V模型的最主要批評是V模型無法引導項目的全部過程。他認為一個模型必須能處理開發的所有方面，包括交接，頻繁重復的集成，以及需求文檔的缺乏等等。 解決交接和頻繁集成的周期的問題 認為一個模型不應該規定那些和當前所公認的實踐不一致的行為。
我也很認同這一點。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終合成為可執行的程序。(右上半部分），這些可執行程序還需要進行測試。已通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規模和范圍內集成的一部分。多根并行的曲線表示變更可以在各個部分發生。 由上圖中可見，X模型還定位了探索性測試（右下方）。這是不進行事先計劃的特殊類型的測試，諸如“我這么測一下結果會怎么樣？”，這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟件錯誤。雖然沒有對此進行明確的說明，但一定很樂意看到該方法的界定。 然而，關注于這樣的低級別的行為可能會引起不同的議論。一個模型和一個單獨的項目計劃有所不同。模型不應該描述每個項目的具體細節，模型應該對項目進行指導和支持。當然，代碼的交接也可以簡單地認為是一種集成的形式。而V模型也并沒有限制各種創建周期的發生次數。 和都一致認同，應該在執行測試之前進行測試設計。建議：“在你掌握相關知識時進行設計，在你手頭有交付內容時進行測試。”X模型包含了測試設計的步驟，就象使用不同的測試工具所要包含的步驟一樣，而V模型沒有這么做。但是，的例子提示，X模型在這層意義上看也并不是一個真的模型，取而代之的是，應該允許在任何時候選擇使用測試設計步驟。