人們在探索軟體工程方法的幾十年裡，提出了許多軟體開發的方法，但這些方法都不是嚴密的理論。我們不應該教條地套用方法，更重要的是學會"選擇合適的方法"和"產生新方法"。
軟體開發中的三種基本策略：復用、分而治之、優化與折衷。
1.復用
對於建立軟體系統而言，所謂復用就是利用某些已開發的、對建立新系統有用的軟體元素來生成新的軟體系統。在乙個新系統中，大部分的內容是成熟的，只有小部分內容是創新的。一般地，可以相信成熟的東西總是比較可靠的，而大量成熟的工作可以通過復用來快速實現，人們應該把大部分的時間用在小比例的創新工作上，而把小部分的時間用在大比例的成熟工作中，這樣才能把工作做得既快又好。
我們將具有一定整合度並可以重複使用的軟體組成單元稱為軟構件（software component），軟體復用就是直接使用已有的軟構件，即可組裝（或加以合理修改）成新的系統，而可以不必每次從零做起。一方面，軟體復用方法合理化並簡化了軟體開發過程，減少了總的開發工作量與維護代價，既降低了軟體的成本又提高了生產率。另一方面，由於軟構件是經過反覆使用驗證的，自身具有較高的質量，因此由軟構件組成的新系統也具有較高的質量。
2.分而治之
分而治之是指把大而複雜的問題分解成若干個簡單的小問題，然後逐個解決。這種樸素的思想**於人們生活與工作的經驗，也完全適合於技術領域。諸如軟體的體系結構設計、模組化設計都是分而治之的具體表現。
3.優化與折衷
軟體的優化是指優化軟體的各個質量因素，如提高執行速度、提高對記憶體資源的利用率、使使用者介面更加友好、使三維圖形的真實感更強等等。我們應該樹立這樣的正確認識：優化工作不是可有可無的事情，而是必須要做的事情。
當優化工作成為一種責任時，程式設計師才會不斷改進軟體中的演算法，資料結構和程式組織，從而提高軟體質量。著名的3d遊戲軟體quake，能夠在pc機上實時地繪製高度真實感的複雜場景。quake的開發者能把很多成熟的圖形技術發揮到極致，例如把bresenham畫線、多邊形裁剪、樹遍歷等演算法的速度提高近乙個數量級，其技術水平已經遠勝於目前國內領先的圖形學相關科研成果。
優化工作是十分複雜的，有時很難實現所有目標的優化，這時就需要"折衷"策略。軟體的折衷策略是指通過協調各個質量因素，實現整體質量的最優。
軟體折衷的重要原則是不能使某一方損失關鍵的職能，更不可以象"舍魚而取熊掌"那樣拋棄一方。例如3d動畫軟體的瓶頸通常是速度，但如果為了提高速度而在程式中取消光照明計算，那麼場景就會喪失真實感，3d動畫也就不再有意義了。
折衷是有原則的，如果濫用折衷的話，那麼一旦碰到困難，人們就會用拆東牆補西牆的方式去折衷，不再下苦功去做有意義的優化。所以，我們應當堅持這樣的折衷立場：在保證其它因素不差的前提下，使某些因素變得更好。
人們對軟體存在著許多錯誤的觀點，這些觀點表面上看起來很有道理，符合人們的直覺，但實際上給管理者和開發人員帶來了嚴重的問題。許多人認識到下述觀點是錯誤的，但遺憾的是舊的觀念和方法培植了拙劣的管理和技術習慣。
觀點之一
我們擁有一套講述如何開發軟體的書籍，書中充滿了標準與示例，可以幫助我們解決軟體開發中遇到的任何問題。
客觀事實
好的參考書無疑能指導我們的工作，充分利用書籍中的方法、技術和技巧，可以有效地解決軟體開發中大量常見的問題。但實踐者並不能依賴於書籍，因為在現實工作中，由於條件千差萬別，即使是相當成熟的軟體工程規範，常常也無法套用。另外，軟體技術日新月異，沒有哪一種軟體標準能長盛不衰。
觀點之二
如果我們已經落後於計畫，可以增加更多的程式設計師來趕上進度。
客觀事實
軟體開發不同於傳統的機械製造，人多不見得力量大。如果給落後於計畫的專案增添新人，可能會更加延誤專案。因為新人會產生很多新的錯誤，使專案混亂，並且原有的開發人員向新人解釋工作和交流思想都要花費時間，使實際的開發時間更少，所以制定恰如其分的專案計畫是很重要的。
【講解】
假設乙個專案估計需要12人月工作量，指定由3個人在4個月內完成，如果第乙個月的任務花了兩個月才完成，那麼增加人力的結果如何？假設增加2個人參加專案，不論新增加的人適應能力有多強，總需要有人去幫助了解熟悉情況，如果這些工作占用了乙個月的時間，這樣又有3個人月工作量在新計畫之外。由於人員增加，工作任務需要重新劃分，到第3個月結束時雖然有5個人在工作，實際上餘留下7個人的工作量。
觀點之三
專案需求總是在不斷變化，但這些變化能夠很容易地滿足，因為軟體是靈活的。
客觀事實
軟體需求確實是經常變化的，但這些變化產生的影響會隨著其引入時間的不同而不同。對需求把握得越準確，軟體的修修補補就越少。有些需求在一開始時很難確定，在開發過程中要不斷地加以改正。軟體修改越早代價越少，修改越晚代價越大，就跟治病一樣道理。
觀點之四
有了對目標的一般描述就足以開始寫程式了，我們以後可以再補充細節。
客觀事實
不完善的系統定義是軟體專案失敗的主要原因。關於待開發軟體的應用領域、功能、效能、介面、設計約束和標準等需要詳細的描述，而這些只有通過使用者和開發人員之間的通訊交流才能確定。越早開始寫程式，就要花越長時間才能完成它。
觀點之五
一旦我們寫出了程式並使其正常執行，我們的工作就結束了。人們有時認為，只有差的軟體產品才需要維護。
客觀事實
從如圖1.12所示的統計資料來看，軟體投入的50%～70%是花費在交付給使用者之後。品質差的產品被丟棄，只有好的產品才需要維護和改進。
觀點之六
乙個成功的專案唯一應該提交的就是執行程式。
客觀事實
軟體包括程式、資料和文件，其中文件是成功開發的基礎，為軟體維護提供了指導。
總結基本的軟體開發模式
快速原型模型 需要迅速造乙個可以執行的軟體原型，以便理解和澄清問題 快速原型模型允許在需求分析階段對軟體的需求進行初步的非完全的分析和定義，快速設計開發出軟體系統的原型 展示待開發軟體的全部或部分功能和效能 過程 使用者對該原型進行測試評定，給出具體改善的意見以及豐富的細化軟體需求，開發人員進行修改...
軟體開發基本心得
開發軟體的基本心得 這學期做了很多簡單系統，從最初的特別簡易的 學生資訊管理，atm，通訊錄，到後來的圖書管理系統，這個過程讓我有了很多體會和心得。開發乙個軟體，我覺著首先要對這個軟體有乙個具體構思，有確切思路，先把大體結構想好，然後再去一步一步地實行。在寫 的過程中，要把類的封裝做好，哪些成員可以...
軟體開發基本概念
主要用於記錄軟體開發過程中遇到的專有名詞，以便能快速建立或看懂他人的專案結構 伺服器 nginx 測試預言 test oracle 蛻變測試 metamorphic testing,mt 蛻變關係 metamorphic relation,mr 軟體質量 software quality journ...