敏捷開發的一些后勤工作對我們也是很有用的，例如日常的進度會議或者Scrum會議。但是，由于開發的目的是構建可以用對象而不是獨一無二的單用對象，因此也會使用其他重視并且度量質量的技術。例如，團隊軟件過程和個體軟件過程方法已經展示了非常高的質量控制水平。由于新應用有非常嚴格的安全和質量要求。因此這些可重用組件必須經過認證，達到零缺陷的水平才行。如果不能提供這樣的認證，那么候選的可重用組件必須通過一系列非常全面的檢查，這些檢查包括自動靜態分析、動態分析、測試，或許還應包括審查。除此之外，還會收集并分析所有可重用組件的歷史記錄。以評估任何先前可能已經報道過的質最和安全漏洞。
由于應用的新功能并不打算設計成單用，而是打算設計成可重用組件，因此，很明顯，開發這些組件就需要格外仔細。對于新功能所使用的開發方法，團隊軟件過程和個體軟件過程對創建可重用構件似乎有嚴格要求。像敏捷開發或者其他途徑的一些后勤方法都可以使用，但是嚴格和高質量水平是成功重用的主要目標。由于需要高質量的組件.因此自動的靜態和動態分析、仔細測試、現場檢查等方法都是必需的。特別是，特殊類型的審查也是必需的，如專注于安全漏洞和缺陷的審查。
由于安全問題，例如支持安全的E語言可能會用來開發。然而，一些舊的可重用組件毫無疑問是用其他的語育編寫的，例如C，Java，C++等，因此可能需要進行語言轉換。然而，希望到了2049年，針對任何一門語言，所有可重用組件都有一個對應的安全版本。例子中討論了一種類型的軟件成本評估應用，在2009年時它一般只有約2500個功能點。構建并實現這些應用通常需要兩年半的時間，生產率約為每人每月I0-15個功能點。這些應用潛在的平均缺陷個數為4.5個/功能點，然而缺陷去除效率只有87%。結果.在軟件第一次交付用戶的時候，軟件中大約還存在1400個缺陷。在這1400個缺陷中，約有20%的缺陷，或者280個缺陷，會導致用戶使用該軟件的時候出現相當嚴重的問題。