基於構件的軟體開發（Component-Based Software Development, CBSD，有時也稱為基於構件的軟體工程CBSE）是一種基於分佈物件技術、強調透過可複用構件設計與構造軟體系統的軟體複用途徑。基於構件的軟體系統中的構件可以是COTS（Commercial-Off-the-Shelf）構件，也可以是透過其它途徑獲得的構件（如自行開發）。CBSD體現了“購買而不是重新構造”的哲學，將軟體開發的重點從程式編寫轉移到了基於已有構件的組裝，以更快地構造系統，減輕用來支援和升級大型系統所需要的維護負擔 ，從而降低軟體開發的費用。 開發基於構件的軟體系統受到以下幾方面因素的影響：
1）COTS構件質量的提高和種類的增加；
2）要求降低系統開發和維護成本的經濟壓力；
3）構件整合技術的出現；
4）軟體開發組織內可以用於新系統開發的已有軟體製品的數量增加。 CBSD整個過程從需求開始，由開發團隊使用傳統的需求獲取技術建立系統的需求規約。在完成體系結構設計後，並不立即開始詳細設計，而是確定哪些部分可由構件組裝而成。此時開發人員面臨的設計決策包括“是否存在滿足某種需求的COTS 構件”，“是否存在滿足某種需求的內部開發的可複用構件”，“這些可用構件的介面與體系結構的設計是否匹配”等。對於那些無法透過已有構件滿足的需求，就只能採用傳統的或面向物件的軟體工程方法開發新構件。對於那些滿足需求的可用構件，開發人員通常需要進行如下活動： 構件鑑定（qualification）：透過介面以及其它約束判斷COTS 構件是否可在新系統中複用。構件鑑定分為發現和評估兩個階段。發現階段需要確定COTS 構件的各種屬性，如構件介面的功能性（構件能夠提供什麼服務）及其附加屬性（如，是否遵循某種標準）、構件的質量屬性（如，可靠性）等。構件發現難度較大，因為構件的屬性往往難以獲取、無法量化。評估階段根據COTS 構件屬性以及新系統的需求判斷構件是否可在系統中複用。評估方法常常涉及分析構件文件、與構件已有使用者交流經驗、甚至開發系統原型。構件鑑定有時還需要考慮非技術因素，如構件提供商的市場佔有率、構件開發商的過程成熟度等級等。 構件適配（adaptation）：獨立開發的可複用構件滿足不同的應用需求，並對執行上下文做出了某些假設。系統的軟體體系結構定義了系統中所有構件的設計規則、連線模式和互動模式。如果被複用的構件不符合目標系統的軟體體系結構就可能導致該構件無法正常工作，甚至影響整個系統的執行，這種情形稱為失配（mismatch）。調整構件使之滿足體系結構要求的行為就是構件適配。構件適配可透過白盒、灰盒或黑盒的方式對構件進行修改或配置。白盒方式允許直接修改構件原始碼；灰盒方式不允許直接修改構件原始碼，但提供了可修改構件行為的擴充套件語言或程式設計介面；黑盒方式是指調整那些只有可執行程式碼且沒有任何擴充套件機制的構件。如果構件無法適配，就不得不尋找其它適合的構件。 構件組裝（composition）：構件必須透過某些良好定義的基礎設施才能組裝成目標系統。體系風格決定了構件之間連線或協調的機制，是構件組裝成功與否的關鍵因素之一。典型的體系風格包括黑板、訊息匯流排、物件請求代理等。 構件更新（update）：基於構件的系統演化往往表現為構件的替換或增加，其關鍵在於如何充分測試新構件以保證其正確工作且不對其它構件的執行產生副面影響，對於由COTS 構件組裝而成的系統，其更新的工作往往由提供COTS 構件的第三方完成。
基於構件的軟體開發（Component-Based Software Development, CBSD，有時也稱為基於構件的軟體工程CBSE）是一種基於分佈物件技術、強調透過可複用構件設計與構造軟體系統的軟體複用途徑。基於構件的軟體系統中的構件可以是COTS（Commercial-Off-the-Shelf）構件，也可以是透過其它途徑獲得的構件（如自行開發）。CBSD體現了“購買而不是重新構造”的哲學，將軟體開發的重點從程式編寫轉移到了基於已有構件的組裝，以更快地構造系統，減輕用來支援和升級大型系統所需要的維護負擔 ，從而降低軟體開發的費用。 開發基於構件的軟體系統受到以下幾方面因素的影響：
1）COTS構件質量的提高和種類的增加；
2）要求降低系統開發和維護成本的經濟壓力；
3）構件整合技術的出現；
4）軟體開發組織內可以用於新系統開發的已有軟體製品的數量增加。 CBSD整個過程從需求開始，由開發團隊使用傳統的需求獲取技術建立系統的需求規約。在完成體系結構設計後，並不立即開始詳細設計，而是確定哪些部分可由構件組裝而成。此時開發人員面臨的設計決策包括“是否存在滿足某種需求的COTS 構件”，“是否存在滿足某種需求的內部開發的可複用構件”，“這些可用構件的介面與體系結構的設計是否匹配”等。對於那些無法透過已有構件滿足的需求，就只能採用傳統的或面向物件的軟體工程方法開發新構件。對於那些滿足需求的可用構件，開發人員通常需要進行如下活動： 構件鑑定（qualification）：透過介面以及其它約束判斷COTS 構件是否可在新系統中複用。構件鑑定分為發現和評估兩個階段。發現階段需要確定COTS 構件的各種屬性，如構件介面的功能性（構件能夠提供什麼服務）及其附加屬性（如，是否遵循某種標準）、構件的質量屬性（如，可靠性）等。構件發現難度較大，因為構件的屬性往往難以獲取、無法量化。評估階段根據COTS 構件屬性以及新系統的需求判斷構件是否可在系統中複用。評估方法常常涉及分析構件文件、與構件已有使用者交流經驗、甚至開發系統原型。構件鑑定有時還需要考慮非技術因素，如構件提供商的市場佔有率、構件開發商的過程成熟度等級等。 構件適配（adaptation）：獨立開發的可複用構件滿足不同的應用需求，並對執行上下文做出了某些假設。系統的軟體體系結構定義了系統中所有構件的設計規則、連線模式和互動模式。如果被複用的構件不符合目標系統的軟體體系結構就可能導致該構件無法正常工作，甚至影響整個系統的執行，這種情形稱為失配（mismatch）。調整構件使之滿足體系結構要求的行為就是構件適配。構件適配可透過白盒、灰盒或黑盒的方式對構件進行修改或配置。白盒方式允許直接修改構件原始碼；灰盒方式不允許直接修改構件原始碼，但提供了可修改構件行為的擴充套件語言或程式設計介面；黑盒方式是指調整那些只有可執行程式碼且沒有任何擴充套件機制的構件。如果構件無法適配，就不得不尋找其它適合的構件。 構件組裝（composition）：構件必須透過某些良好定義的基礎設施才能組裝成目標系統。體系風格決定了構件之間連線或協調的機制，是構件組裝成功與否的關鍵因素之一。典型的體系風格包括黑板、訊息匯流排、物件請求代理等。 構件更新（update）：基於構件的系統演化往往表現為構件的替換或增加，其關鍵在於如何充分測試新構件以保證其正確工作且不對其它構件的執行產生副面影響，對於由COTS 構件組裝而成的系統，其更新的工作往往由提供COTS 構件的第三方完成。