軟件工程博客做業1

這個做業屬於北航計算機學院軟件工程
這個做業的要求位於此連接
我在這個課程的目標是：積累軟件項目開發經驗，取得大於85分的成績。
這個做業在以下方面幫助我實現目標：快速瀏覽全書，掌握課程的總體結構。經過查閱資料，瞭解軟件工程的歷史。

1. 快速看完整部教材，列出你仍然不懂的5到10個問題，發佈在你的我的博客上。

（1）第33頁，將代碼段

for(int i = 0; i < m_wordList.Count; i++)

更改成

int count = m_wordList.Count;
for (int i = 0; i < count; i++)

第34頁寫道：「你們也要注意避免沒有作分析就過早地進行‘效能提升’。」
問：相似上述代碼的優化，是否能夠視爲必然可以提升效能，而無需每次都進行分析呢？

（2）第7章 第137頁
「有些團隊把開發和測試有意無心地對立起來，好像兩者是矛盾的。」 「這種對立情緒，也許在短時間內能刺激成員的工做熱情，而從長遠來看是有害的。」
北航計算機學院的「面向對象設計與構造」課程的每份做業都採用以下的評分標準：修課的同窗代碼隨機分配至其餘人手裏，找出別人的BUG會爲本身加分，而本身的程序被別人找出BUG會被減分。這種評分規則是否能夠看做違反了上述原則，而應被廢止或修改呢？

（3）第8章 需求分析 之中的內容，有一部分與北航經管教材上的知識重合。例如167頁的「用戶滿意度模型」、177頁的「分而治之」思想。
能否認爲軟件工程在進行需求分析時，較多地借鑑了傳統管理學知識？或者認爲軟件工程是管理學的一個分支？

（4）11.5.2 每日構建（235~237頁）
這一節的寫做有些漏洞。阿超與小飛的對話，主要論證的是「構建」的重要性，卻忽略了論述「每日」進行構建的必要性。
因此，每一天都進行構建工做是不是有必要的？若是不是，這一名稱是否有修改的必要？

（5）第14章 質量保障 第312頁
做者設想了第三方的軟件質量認證服務將爲人們的生活帶來的便利。那麼，第三方認證軟件質量爲何尚處於起步階段，其難點在哪裏？

2. 請問 「軟件」 和 「軟件工程」 這些詞彙是如何出現的 - 什麼時候、何地、何人？

根據百度百科「軟件工程」詞條的描述，軟件與軟件工程的發展經歷了以下階段：

• 程序設計階段：1946~1955年
  此階段的特色是：尚無軟件的概念，程序設計主要圍繞硬件進行開發，規模很小，工具簡單，無明確分工（開發者和用戶）。
• 軟件設計階段：1956~1970年
  此階段的特色是：硬件環境相對穩定，出現了「軟件做坊」的開發組織形式。開始普遍使用產品軟件（可購買），從而創建了軟件的概念。軟件系統的規模愈來愈龐大，高級編程語言層出不窮，應用領域不斷拓寬，開發者和用戶有了明確的分工，社會對軟件的需求量劇增。但軟件開發技術沒有重大突破，軟件產品的質量不高，生產效率低下，從而致使了「軟件危機」的產生。
• 軟件工程階段：1970年至今
  因爲「軟件危機」的產生，迫令人們不得不研究、改變軟件開發的技術手段和管理方法。今後軟件產生進入了軟件工程時代。此階段的特色有：
  第一代軟件技術：結構化程序設計在數值計算領域取得優異成績；
  第二代軟件技術：軟件測試技術、方法、原理用於軟件生產過程；
  第三代軟件技術：處理需求定義技術用於軟件需求分析和描述。

「軟件」一詞的提出者通常認爲是美國數學家John Tukey。他的維基百科中有以下論述：

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years.

而「軟件工程」的提出者和實踐者通常認爲是Margaret Hamilton。她開發了「阿波羅」飛船飛行控制軟件。在一次採訪中她提到：

軟件在這個計劃的初期還被看成初初學步的孩子通常對待，徹底不像其餘工程學科；例如像硬件工程那樣的受到重視，並且在你們的眼光中他就像是藝術、魔術通常，而不是一門科學。我一直以來堅信這項發明流着藝術與科學的血液，雖然當時不多人是這麼想。所以，我致力於爲軟件以及那些發明者爭取應有的正統性與尊重，因此我開始使用「軟件工程」這樣的字眼來將之與硬件還有其餘工程學類作出區別。

——引用自《就是她，寫出了讓阿姆斯壯成功登錄月球的代碼！》
事實上，儘管Hamilton是半路出家，可是她在軟件測試方面貢獻了一些卓有成效的思想。

一天，勞倫在擺弄 MIT 控制艙模擬器的顯示器鍵盤一體機 DSKY。當她在鍵盤上亂按的時候，一條錯誤信息忽然出現。勞倫不知怎地啓動了一個叫作 P01 的預運行程序，本來正在飛行狀態的模擬器一會兒崩潰了。
雖然通常來講宇航員不會犯這樣的錯，但瑪格麗特仍是想加一段代碼防止這種情況的發生。這一提議被 NASA 否決，「他們一遍又一遍地跟我說宇航員不會犯任何錯誤，他們被訓練得近乎完美，」瑪格麗特說。她轉而加了一句程序說明，全部 NASA 工程師和宇航員都能看到：「不要在飛行過程當中按下 P01」。她回憶說，「全部人都說，『那樣的事情永遠都不會發生』。」
但事情的的確確發生了。時間大約在 1968 年的聖誕節，進入阿波羅 8 號飛船的第五天飛行，宇航員吉姆·洛威爾 (Jim Lovell) 不當心在飛行中啓動了 P01 程序。當電話從休斯頓打來的時候，瑪格麗特正在儀器實驗室的 2 層會議室。啓動 P01 程序致使此的導航數據所有清空，阿波羅計算機沒法計算出如何返回地球。
瑪格麗特和 MIT 的程序員們須要想出一個補救的辦法，必須是無錯漏的完美辦法。在花費 9 小時鑽研過面前 8 英寸厚的程序列表後，他們有了一個計劃。休斯頓方面須要上傳一份新的導航數據，然後一切都會順利進行。

——引用自《代碼傳奇 | 明明能夠靠顏值 卻用代碼把人類送上了月球的女人——Margaret Hamilton》

4. 上網調查一下目前流行的源程序版本管理軟件和項目管理軟件都有哪些， 各有什麼優缺點？

git

Git是一個開源的分佈式版本控制系統，能夠有效、高速地處理從很小到很是大的項目版本管理。Git 是 Linus Torvalds 爲了幫助管理 Linux 內核開發而開發的一個開放源碼的版本控制軟件。
優勢：

• 適合分佈式開發，強調個體。
• 公共服務器壓力和數據量都不會太大。
• 速度快、靈活。
• 任意兩個開發者之間能夠很容易的解決衝突。
• 離線工做。

缺點：

• 資料少（起碼中文資料不多）。
• 學習週期相對而言比較長。
• 不符合常規思惟。（主要指遠程倉庫、分支等概念）
• 代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。

Mercurial

Mercurial 是一種輕量級分佈式版本控制系統，採用 Python 語言實現，易於學習和使用，擴展性強。其是基於 GNU General Public License (GPL) 受權的開源項目。
優勢：

• 更輕鬆的管理。傳統的版本控制系統使用集中式的 repository，一些和 repository相關的管理就只能由管理員一我的進行。因爲採用了分佈式的模型，Mercurial 中就沒有這樣的困擾，每一個用戶管理本身的 repository，管理員只需協調同步這些repository。
• 更健壯的系統。分佈式系統比集中式的單服務器系統更健壯，單服務器系統一旦服務器出現問題整個系統就不能運行了，分佈式系統一般不會由於一兩個節點而受到影響。 對網絡的依賴性更低。因爲同步能夠放在任意時刻進行，Mercurial 甚至能夠離線進行管理，只需在有網絡鏈接時同步。

缺點：

• 使用人數太少。

Trac

Trac是一個爲軟件開發項目須要而集成了Wiki和問題跟蹤管理系統的應用平臺，是一個開源軟件應用。Trac以簡單的方式創建了一個軟件項目管理的Web應用，以幫助開發人員更好地寫出高質量的軟件。

Bugzilla

Bugzilla 是一個開源的缺陷跟蹤系統（Bug-Tracking System），它能夠管理軟件開發中缺陷的提交（new），修復（resolve），關閉（close）等整個生命週期。
Bugzilla是一開源Bug Tracking System，是專門爲Unix定製開發的。

參考資料：

GIT
Mercurial
trac
Bugzilla