對文件的理解：

歷經大量的借鑑，我的第一次文件生涯就這樣結束了。整個過程下來，自己對機房收費系統的整體脈絡和業務流程有了更加深刻清晰的認識。而且有這樣一個感悟：一個不會寫文件的程式設計師和一個不會寫文件的程式設計師兩者之間的行業地位又好比武林高手和武學宗師的關係。但凡武學宗師必定是一名武林高手甚至超級武林高手，而武林高手就不一定是武學宗師了。

從上面的小比喻，我們不難看出來文件的重要性。確實，文件幫助我們加深了對軟體工程各個階段的理解，並且幫助我們將一整個繁瑣複雜的軟體開發過程細分為一個個具體的額階段，明確了每個階段的任務和注意事項。正是通過這樣一個自頂向下逐層分解的過程，一個難以下嚥的軟體開發就變成了一道美味。就好像我們的培養計劃那樣，將整個事件對策脈絡清晰明瞭的展現在每個人的面前，讓所有人知道什麼時間進行什麼階段，每個階段該做些什麼。一句話，文件解決了我們在面對繁瑣事務的茫然不知所措的問題，讓我們明確的下一個落腳點在哪裡。藉此機會，和大家分享一下通過編寫文件我獲得的對軟體工程的最新理解。

對軟體工程的新理解：

概要：

之前寫過一篇介紹軟體生命週期的文章，但是那篇文章內容基本上屬於那種人雲亦云的被動接受。編寫過一整套軟體開發的文件後，對軟體工程我終於有了自己的理解。藉助文件這個線索，我將軟體工程分為戰略和戰術這兩部分。戰略和戰術的關係，相信大家都有了一定的瞭解，在這裡我們就不在贅述了。具體來說，我定義的軟體工程的戰略階段主要包括問題定義階段和可行性分析階段。換言之，即相當於一場戰役或者異常博弈的謀劃階段；而我所謂的軟體工程的戰術階段則是確定可行之後的具體實施階段，即需求分析、軟體設計、軟體實現、軟體測試、執行維護等具體的步驟。下面請看具體的介紹。

戰略階段：

沒有無緣無故的愛，同樣這個世界上沒有不問青紅皁白的戰爭。每一件可以用理智丈量的事情，都有它迫不得已的利益訴求。而為了利益的最大化，開始之前的分析謀劃是必不可少的。相對於軟體開發來說，問題定義和可行性分析應運而生。我們需要確定我們將要做的是一件怎樣的狂歡，需要知道這樣一場我們締造的狂歡的可行性以及其的投入、風險和收益。 幫助我們瞭解現行系統的狀況、遇到的問題，現行系統與新需求的之間的矛盾；以及對新系統的具體期望，新系統應在怎樣一個環境下使用那些必要的裝置執行以滿足實現怎樣的功能。這兩者就是問題定義階段的使命。 而在明確新系統的開發已經勢不可擋後，我們需要對新系統的開發進行一個理智的分析。我們需要知道開發一個設想中的新系統在技術上、道德上、法律上有多大的可行性；需要多大的人力、物力和財力的投入；可能會產生怎樣的風險以及新系統是否能帶來一個讓人滿意的收益。這些都是需要在可行性分析階段逐一解決的問題。每一個問題都需要引起我們百分之一百的重視。

戰術階段：

在經過戰略階段的分析解讀後，我們隊新系統的開發已經明確了大概的方向。下面就需要我們就需要我們解決一個個具體的問題，進而向著確定的大方向邁進。首先，我們需要有一個階段和客戶進行良好有效的階段，即大家約定俗稱的需求分析階段。我個人認為這個階段是繼可行性分析階段後的一個最重要的階段，沒有之一。我們都清楚，如果沒有客戶的需要，就沒有所謂的軟體開發，更沒有所謂的軟體工程。在這一階段，我們需要準確的獲取客戶的需求並進行分析,確定概念模型並將其以圖形這種可理解的形式展示給客戶，與客戶進行修正。所以個人認為，需求分析階段是一個重中之重。客戶的需求理解不好，何談開發軟體的優良品質？ 明確了客戶需求並與客戶交流確定無誤後，我們就要將概念模型轉化為邏輯模型了。這個任務需要在軟體設計階段完成。相對於需求分析，軟體設計的難度大大降低。因為這一階段不再是兩個團體之間的碰撞，而是一個團體內部之間的溝通。良好的專業知識和共同的專業語言，使得軟體設計比需求分析要來的輕鬆。設計人員只需要將具體的資料流程圖、模組的內部結構、模組之間的關係清晰的表述出來並交付給程式設計人員即可。 而具體實現軟體的過程，就是一些重複性質的工作了，沒有多大的創新性。（PS：從中也可以看出程式設計師和開發管理人員有所區別的原因）。軟體實現後，我們將迎來另一個不容忽視的大傢伙：測試。曾經天真的我一直以為所謂測試就是為了向大家證明自己編寫的程式可以流暢執行。現在看來，當初的自己天真的可愛。軟體測試，不是為了證明一個軟體可以流暢五無阻的執行；相反，對軟體進行測試，是為了找出開發階段沒有被我們發現的問題並進行相應的除錯以確保軟體在交付給客戶後可以良好的執行。而在將軟體交付給使用者使用前，我們需要編寫相應的使用說明並對客戶進行一些必要的培訓，以確保客戶可以得心應手的使用開發出來的軟體。 也許大多數人認為軟體交付給客戶使用後，開發方的認為就結束了。沒有系統學習軟體工程之前的我也是這樣認為的。但是現在我不在這樣認為了。開發方的任務結束是在客戶淘汰新系統後而非將軟體交付給客戶。客戶在使用新系統後，開發方還應負責新系統的維護工作。怎麼理解呢，這個關係就好像淘寶的客服和買家之間的關係。

總結：

怎麼說呢，機房收費系統的系列文件是在借鑑了大量資料之後才完成的。儘管自己對如何編寫一個軟體開發的系列文件以及負責各個階段的工作有了一個清晰的認識，但是這些都還在停留在一個初步的階段。一句話，菜鳥雖然進步了，但還沒進化，仍需努力！ 感謝您的寶貴時間，謝謝~~~