我已經編程了幾年，現在正在大學學習計算機科學。每次我編寫代碼時，都是通過啓動編輯器和即興創作來實現的。寫作方法，我去的課程。當然，我事先考慮過，我拿出草圖紙，寫下我的想法，做一些事情要做的事情等等。這可以用於編寫一點代碼或者簡單和相對較小的軟件，但是怎麼樣複雜的？您如何設計，繪製和製作複雜的軟件藍圖？什麼是可用於這樣做的一些工作流程或工具？
當你想製作一個複雜的軟件時，你如何制定藍圖？在開始任何實際工作之前，建築師會對建築進行藍圖設計，並且遵循標準進行。我希望程序員這樣做，但我從來沒有聽說過。有哪些方法，工具和步驟正在被用來做到這一點。
我不想要意見。
我想要特別的東西：圖表？地圖？工具？技術？逐步過程？ ...
標準答案nowdays是相當簡單：畫UML圖。
早在幾年的答案對子級已經「畫流程圖」，「畫Nassi-Shneiderman的圖表」，「畫Warnier /奧爾圖」，「繪製數據流圖」 ...等
他們在同一時間都會是好的答案和不好的答案。現實是，沒有單一的正確答案的問題，原因很簡單，沒有人真正知道什麼軟件實際上是。
在人們跳上我的喉嚨之前，讓我解釋一下我的意思。
當建築師爲建築物打印藍圖時，最終產品是清晰的：它將是一個具有牆，門，窗等的物理結構。我們的建築師將畫出一條線並說：「這是一堵牆「;將畫另一條線，並說，「這是從屋頂到地下室的電視天線電纜」。使用一些有關尺寸（比例尺），顏色和線條類型的約定，他將能夠向他人傳達需要建立的內容以及如何組合在一起。
細節上可能存在一些誤解，但沒有人會懷疑他們正在查看的2D模型實際上代表了建築物。即使需要多個圖表（例如每層一個圖表），將它們聯繫起來也相當容易。
對於一個軟件系統我們還沒有達到那個水平！第一個問題是「你將如何建模軟件」？
如果您使用面向對象的方法，您會將您的軟件描述爲一組屬於「對象」的「對象」，它們彼此相關（如「類圖」中所述），並具有給定的行爲（一種「狀態圖」）並以某種方式相互作用（如一組「協作圖」中所述）。
沒有任何一個圖表可以顯示軟件系統的所有方面。這就是爲什麼UML包含許多不同類型的圖表。
如果您使用的是結構化方法，您將會將您的系統描述爲將其輸入轉換爲輸出（DFD）和作爲集合數據實體（作爲ER圖）的一組處理組件。
只要所有相關方都清楚其含義，任何圖都可以使用。實際上，通過在白板上畫兩個盒子並在它們之間插入一條線來開始設計會話是很常見的：「好的，那就是瀏覽器連接到我們的網絡服務器......」。
問題在於每個圖表的含義。實際上，我們有一種很好的表示系統數據部分的常見方式：實體關係圖（或類圖的「靜態部分」）可以直接轉換爲實時數據庫。我認爲這是因爲關係數據庫對關係代數有充分的理由，同時它們使用任何人都可以掌握的簡單概念（表，外鍵，連接......）。所有其他數據表示已被清除（不再有更多的層狀數據庫！）。
我們缺乏的是軟件動態方面常見的公認觀點;一些統一的觀點認爲，理論上既合理又不難使用。
這就是我的建議。
建築師在開始任何實際工作之前對建築進行藍圖，他們按照以下標準進行建設。
那是因爲有很多領域事先都有確切的知識。涉及到什麼，哪些規則，哪些物理定律，哪些規則要考慮。這就是爲什麼有可能把整個事情設計到最後一個釘子。
與軟件有很大的不同。你想做什麼，就可以做什麼。你可以找到任何東西，但沒有人能告訴你它是好還是壞。因爲沒有標準。只有主觀意見。
每次我編寫了一些東西的時候，我都是通過啓動我的編輯器並且即興創作的。寫作方法，我去的課程。當然，我事先考慮過，我拿出草圖紙，寫下我的想法，做點事情要做的事情等等。
這就是它通常的做法。在開始項目之前，您可以嘗試一些框架，工具，體系結構。例如，做一些測試項目來學習你需要嘗試「藍圖」你的未來軟件。
我不想要意見。
這裏的每個答案都將是一個意見。因爲沒有可以回溯到的標準。經驗和意見。
我想要特別的東西：圖表？地圖？工具？技術？逐步過程？
什麼已經爲大多數工作是：
包括從一開始的用戶到你的項目。收集定期反饋來調整課程。
變得敏捷並遵循某種迭代過程。首先，您勾畫UI。獲取反饋。然後你實現一些通用功能。得到反饋。調整你的課程。實施更多功能。等等。遲早會有足夠的肉去v.1。
如果你確實需要一些嚴格的準則，然後用UML (Unified Modeling Language)圖表和圖表，並採用RUP (Rational Unified Process)或其類似物。您可以按照Scrum，也有一些組織活動的參與。
首先，我喜歡Mind-Maps，以便可視化該軟件應該做什麼以及相關約束條件（技術，性能，集成點等）。我喜歡使用FreeMind（OSS）來達到此目的。我認爲在討論需求和寫下需求之間存在很大的差異，因爲後者迫使你更精確地考慮需求。特別是如果你不熟悉問題領域。
當我完成這件事的時候，我通常會在腦海中有一個很好的藍圖，並開始編碼。如果不是，我開始用僞UML符號在紙上畫出一些東西。 UML是一種建模語言，專門用於此目的。它爲類，方法，交互流等定義了常見的可視化表示。隨着編寫代碼時對問題的洞察力增加，隨着時間的推移，您的設計會發生一些變化，這並不罕見。每次發生這種情況時不要猶豫，以適應您的設計。
根據要建模的問題的大小，您可能會發現使用UML工具很有幫助。但通常他們是非常嚴謹和不靈活的。特別是當我決定改變我的代碼的設計時，我的UML圖很快就失去了同步。我真正喜歡的是Visual Studio類設計器，因爲它反過來，我可以放下我的代碼，並生成它的可視化（簡單的UML）表示。
+1思維導圖很棒 – munch 2010-02-13 10:07:02
如果您對軟件的設計和開發過程感興趣，那麼您應該就軟件工程進行講座。
其他答案已經提供了這方面的一些提示;然而，不容忽視的一個重要方面是，開始你的設計之前，你其實應該寫下來你的軟件應該在software requirements specification的形式做：
軟件需求規格的完整描述 系統的行爲是由 開發的。它包括一組使用 的案例，描述用戶將與 軟件進行的所有 交互。作爲功能要求，用例也被稱爲 。除 除用例外，SRS還包含 包含非功能（或 補充）要求。 非功能性要求是 要求，其在設計或實現（例如性能工程 要求，質量標準或 設計約束）上施加約束 。
這樣的文檔可以幫助您保持專注，清楚實際使用案例，找出潛在缺陷，定義特定目標（例如關於性能）。規範也將成爲驗證最終實現的基礎（你的軟件是否按照它應該做的那樣做）並幫助你創建測試場景。
我的「一步一步」的過程是這樣的：
書提示：Release It
每個人的回答都很有用，但是因爲我只能選擇一個，所以你是最完整的。我想我會嘗試學習UML和你提到的一些圖表。那麼我認爲重要的一點是，你有一種方法可以清楚地爲自己和團隊中的其他人表達自己的計劃。 – 2010-02-14 22:59:30