軟體作為一種邏輯組織，其發展趨勢是規模越來越龐大，複雜程度(時間複雜度，空間複雜度)越來越高，求解領域越來越廣泛。傳統的結構化軟體開發方法的求解能力已遠遠不能滿足自然界客觀存在的需求，因為面向結構的軟體過程所採用的方法是函式或子程式的呼叫，其所表示的關係是函式或子程式間的依賴關係，用這種方法很難描述自然界中客觀物件的屬性(attribute)，行為(behavior)和關係(relationship)，而且當用結構化方法所開發軟體的規模大到一定程度時，其維護和修改的難度、成本呈指數級增長趨勢，軟體的可維護性、穩定性、可靠性急劇下降，直至令人無法忍受。這就給面向物件的軟體開發方法和過程提供了生存空間、機遇和環境，因為面向物件的軟體開發方法是通過物件(object)這樣的邏輯實體，用類似於人類思維和自然語言的方式來摸擬和描述自然界中客觀實體的屬性、行為和相互關係。面向物件軟體開發方法的任務就是要表達物件的屬性、行為和物件間的相互關係，是對自然界的邏輯摸擬，但是，如果對面向物件的軟體開發過程不加以系統管理和有效控制，就很難保證軟體開發質量、進度和成本在可接受的控制範圍之內。軟體開發正在走向工程化，軟體被看成是軟體工廠生產、製造出來的產品，所以把ISO9001:2000過程質量控制的理念應用於軟體開發過程， 用工程化的方法來組織和運作軟體開發、控制軟體質量就水到渠成了。blog.mypm.net

　　按ISO9001:2000過程的定義，面向物件軟體過程需要有過程客戶、過程目標、過程環境、過程輸入、過程處理、質量檢驗、過程輸出等過程元素。專案管理者聯盟

　　面向物件的軟體開發過程可分為獲得需求、需求分析、架構設計、詳細設計、編碼、測試、維護七個階段，每個階段又可看成是一個子過程，每個子過程又包含了一系列的活動(activities)。七個子過程按順序依次相連，每個子過程的輸出是下一個子過程的輸入。每個子過程是其下一子過程的原料供應者，同時又是其上一子過程的客戶。關鍵子過程(KPA)是需求分析子過程、架構設計子過程和詳細設計子過程。

　　面向物件的軟體過程的最終目標是：軟體不但能夠滿足客戶的當前需求，而且還要能夠滿足未來客戶需求變化的需求，還要適應未來軟體執行支撐環境的發展和變化， 所以,開發的軟體要具有很好的演化能力來適應這些變化。 面向物件軟體過程的最終客戶是軟體使用者及相關利益人。專案經理圈子

　　子過程內部客戶是需求分析子過程中的系統分析師。內部目標是充分獲取客戶需求，可能是合理需求，也可能是不合理需求。參加人員有：客戶需求調查員，領域專家，系統分析師。子過程輸入是軟體開發合同、協議和可行性論證。子過程處理活動：調查員和系統分析師到甲方進行客戶需求調查和採訪，必要時請領域專家(可能來自第三方，也可能來自甲方)參加。獲得客戶需求的途徑有：採訪錄音(徵得甲方同意)，填表格，觀察甲方現場工作情景，畫用例圖(use case diagram)，製作原型(prototype)等。將獲得的客戶需求以文字、圖表的形式記錄下來，並讓客戶進行驗證和確認，可修改，直至客戶認可。獲取使用者需求過程中的一條原則就是不爭論，不分析，把使用者提出的需求都記錄下來。所獲得的原始客戶需求就是獲得需求子過程的輸出。

　　內部客戶是架構設計子過程的軟體架構師。內部目標是充分表達出客戶的必要合理需求。參加人員有系統分析員和領域專家。內部輸入是獲得需求子過程的輸出，即所獲得的原始客戶需求。需求分析活動有：系統分析員運用自己所掌握的系統分析技術、軟體工程知識、經驗、技巧，在領域專家的協助下，對原始客戶需求進行需求技術分析和論證，歸納客戶的合理需求，去掉不合理的需求，增添客戶沒提到的必要合理需求，並形成客戶需求規格說明書(requirement specification)。子過程的驗證和確認工作由客戶和系統分析員共同完成，驗證的指標是：分析得到的客戶需求的充分性、合理性、必要性、完整性、前瞻性。子過程的輸出是：用例圖(use case diagram)、協作圖(collaboration diagram)、分析類圖(analysis class diagram)、需求規格說明書。需求分析子過程是面向物件軟體過程的關鍵子過程(KPA)，因為面向物件軟體過程是用例(use case)驅動的，面向物件軟體過程的一切子過程都要圍繞滿足客戶需求(ISO9001:2000的客戶至上原則)來運作，而用例(use case)就是反映和描述客戶需求的，所以若需求分析做不好，將直接影響到軟體的最終質量，軟體無法滿足客戶需求，導致軟體開發失敗。

　　內部客戶是詳細設計子過程中的設計師。內部目標是獲得所開發軟體的健壯的(robust)軟體架構。參加人員是軟體架構師。內部輸入是需求分析子過程的輸出。子過程的處理活動包括：軟體架構師根據上一子過程生成的用例圖、協作圖、需求規格說明書、分析類圖，運用軟體架構設計知識和經驗設計出所要開發系統的軟體架構(software architecture)。軟體架構的設計粒度是構件(component)，構件是可分佈的物理單元，只要不同的構件實現了相同的介面，那麼構件可以相互替換。保證架構設計質量的準則有：構件本身要保持高內聚性(high cohesion);構件間要保持低耦合性(low coupling);定義構件間的通訊機制(同步、非同步、本地呼叫、遠端呼叫)和通訊協議;構件內部類與類間的依賴關係和方法呼叫要做到對構件外部來說是透明的;每個構件只留有適量的介面供其他構件呼叫;設計構件的介面時，既要使構件間的互動方便，又要隱蔽構件內部的細節資訊， 這樣做的好處是降低面向物件軟體過程的複雜度，提高對軟體過程的可控制程度和軟體的安全性，可運用代理(agent)或門面(facade)設計模式來設計和實現構件;把軟體相對較穩定部分做到架構裡，這包括軟體的核心功能性需求和大部分非功能性需求。軟體架構的設計準則可提高和保證軟體的健壯性，另外使用已有的軟體架構風格(software architecture style)也可提高軟體的健壯性，如：管道過濾器(pipe filter)、順序批處理(batch sequential)、分層(layers)、黑板(blackboard)、直譯器(interpreter)等。面向物件軟體過程是以架構為中心的，架構是軟體的生命基線和骨架。架構設計子過程所設計出的健壯的軟體架構能夠保證軟體的持續改善(continual improvement)，這是軟體開發的最高境界，也是具有挑戰性的領域。 因為客戶的需求是時間的函式，是隨著時間變化的，而且軟體執行的軟硬體支撐環境也在快速發展和變化著，如果軟體沒有一個健壯的架構，那麼軟體將很難根據客戶需求的變化進行擴充套件和維護，且軟體的安全性、穩定性、可靠性、可複用性也很難得到保證，這些都是客戶無法接受的，所以按ISO9001:2000的以客戶為中心、客戶至上的原則，設計健壯的軟體架構是極其必要和重要的。架構設計子過程的內部輸出有：構件圖(component diagram)、分佈圖(deployment diagram)。子過程的檢驗標準是軟體架構美好的可視性(安全性、穩定性、可靠性、可複用性、可維護性、可移植性)，驗證和確認由架構師和系統分析師做，方法是測試已生成的軟體架構，根據架構設計準則來衡量架構是否滿足終端使用者的主要的功能性需求和大部分非功能性需求。專案經理部落格

　　內部客戶是編碼子過程中的程式設計師。內部目標是設計良好的類、類與類間的關係。參加人員有設計師和架構師。子過程的輸入是架構設計子過程和需求分析子過程的輸出。 設計處理活動：設計師運用面向物件分析與設計知識、經驗和技術，設計結構良好的類、類與類間的關係。保證面向物件設計質量的經驗準則有：類(class)是一級抽象，即它可直接例項化出物件(object);類元(meta class如：模板類)是二級抽象，即它直接例項化出來的是類而不是物件;類要保持高內聚性(high cohesion)，類與類間關係要保持低耦合性(lowcoupling);類本身的介面是類的方法的可視性(public、protect、private);定義類間的訊息通訊機制(同步、非同步、本地呼叫、遠端呼叫)和協議;運用專家、控制者、建立者等類職責分配模式確定類的職責(類的方法);必要時使用設計模式，一設計模式是某類軟體設計問題的通用解決方案，如：介面卡、代理、裝飾器、門面、組合、抽象工廠等設計模式，使用設計模式可提高系統的安全性和效率，但同時也增加了系統的複雜性，所以，是否使用設計模式要根據實際情況，權衡利與弊;介面類的作用是推遲實現與繫結，為提高系統的靈活性和可擴充套件性，可適量使用介面，但使用介面會在某種程度上增加系統的複雜性和降低系統的效率;不要僅僅只為了程式碼複用而使用類繼承, 因為繼承是最強的類間耦合關係, 所以這種複用是最糟糕的複用, 得不償失;儘量避免使用多重類繼承和多層類繼承, 因為多重類繼承和多層類繼承在父類的方法重名時易導致混亂和難以理解;為類的方法設計演算法時，要衡量演算法的時間複雜度和空間複雜度，使兩者被控制在可接受的範圍之內;設計時用的建模語言，如UML在不斷地發展和完善，還有一定的侷限性，所以在設計時對UML目前還無法表達出的設計思想要採用適當的方式記錄下來，使設計不被建模語言的侷限性所限制;在詳細設計子過程做得足夠穩定後才過渡到編碼子過程， 因為設計結果的易揮發性會導致後續子過程的混亂不堪、危機重重，甚至無法繼續進行。詳細設計子過程的輸出是設計類圖(design class diagram)、物件狀態圖(object state diagram)以及相關設計文件。設計子過程的驗證和確認工作由架構師、系統分析師和設計師完成，根據設計準則來測試已生成的設計成果是否滿足終端使用者的功能性需求和非功能性需求，以檢驗設計的有效性。專案管理者聯盟