author: 17373051 郭駿
專案內容
這個作業屬於哪個課程
2020春季計算機學院軟體工程(羅傑 任健)
這個作業的要求在**
個人部落格作業
我在這個課程的目標是
學習軟體工程的開發知識，培養工程化開發能力
這個作業在哪個具體方面幫助我實現目標
閱讀教材，對軟體工程有整體上的了解
1.快速看完整部教材，列出你仍然不懂的5到10個問題，發布在你的個人部落格上。
問題1
2.4.1 從hello world開始我在學習作業系統課程設計這門課的時候，被要求使用原生無外掛程式的vim進行作業系統開發。同樣的，編譯執行也是完全使用命令列介面。這樣的行為，首先無疑降低了我這種沒有vim使用經驗的人的程式設計效率，甚至到結課我都未能掌握vim的效率程式設計。此外，我們無法用各種單元測試等工具來評估自己的小作業系統的執行效率，出現bug也十分難找，甚至可能是語法錯誤導致無法通過編譯。這些問題在當今的ide中大多可以避免，甚至visual studio code由於其強大的外掛程式支援能力，已被譽為「除了不能生孩子什麼都行」。或許不使用ide，是一種極端而復古的開發學習，確實能體會上一輩人初學程式設計的感受，可我依然困惑，是否在當今的時代，還需要緊抱notepad去程式設計鍛鍊呢？下面的聯絡可以用來鍛鍊學生的程式設計基本功。
全部用命令列工具和notepad編輯器，不用visual studio等整合編輯環境，每人手工建立並編譯乙個c的命令列程式。
問題2
4.5.2 為什麼要結對程式設計雖然我沒有嘗試過真正的結對程式設計，但是我嘗試過按照書中的「結對」做過很多事情。關於書中所提到的結對程式設計理由，我感到疑惑。既然程式的質量「取決於各方面水平較高的那一位」，那結對程式設計和讓那個水平較高的人單獨程式設計，真的有很大的區別嗎？同樣的，如果兩個人的水平幾乎相同，那結對程式設計和兩個人分別自己寫，又真的有很大的區別嗎？在結對程式設計中，因為有隨時的複審和交流，程式各方面的質量取決於一對程式設計師中各方面水平較高的那一位，這樣，程式中的錯誤就會少得多，程式的初始質量會高很多，這樣會省下很多以後修改、測試的時間。
如果兩個人各有所長，而且長處不盡相交，或許這樣的行為成果比單獨程式設計更加顯著。但是，如果乙個程式可以被拆分成兩個不盡相交的領域，使得兩個人都可以發揮，那為什麼不讓這兩個人分開寫兩個模組呢？
上面我只是提到了結對程式設計好處不明顯，這樣的論證還不足以讓我提出疑問。在我的個人經歷中，我更多會看到結對的弊端，而這個弊端在結對程式設計中同樣不可避免。
因而，在我眼中，書中所提到的結對程式設計的「好處」可能沒那麼好，而弊端卻更加顯而易見，而且我深有體會。當我和別人結對解題的時候，也只是聰明人主導稍笨一點的人在解題而已，因而我提出疑問，結對程式設計的意義真的大嗎？是不是我們的合作方法不對？又或許是解題和程式設計有重大的區別？
不過也不用著急，我會在接下來的結對程式設計作業中，尋找屬於自己的答案。
問題3
8.4 競爭性需求分析的框架看到這個模型，我不由得開始思考，nabcd模型中，到底哪一項因素更重要？這裡的「重要」是指，哪一項因素可以使得使用者更多、使用者粘性更大？n：need，需求
b：benefit，好處
c：competitors，競爭
d：delivery，推廣
問題4
12.1.5 不讓使用者犯簡單的錯誤這種建議非常有必要。但同時，我不得不回想起一些軟體，他們的設計思路是想讓使用者犯簡單的錯誤。比如，特意把「取消」和「確定」按鈕交換左右位置，讓使用者故意選擇錯誤的選項。亦或是解除安裝某一軟體時，將解除安裝按鈕藏在最深處，需要折騰很久，導致使用者難以解除安裝……說白了，這些軟體利用了使用者的習慣，讓他們根據自己的習慣進行選擇，從而犯下錯誤。我的問題在於，如果大部分軟體都遵循同乙個使用習慣（例如確定在左，取消在右），那這種故意想讓使用者犯錯的軟體不就更加有機可乘了嗎？乙個叫西喬的同學為微軟學術搜尋ui提出了建議，將submit和cancel按鈕採用不同的樣式，降低使用者丟失操作的可能性。
進一步思考，我們是否需要有標準甚至法律來規定軟體在此方面的設計，從而防止出現這種「故意引導」式的錯誤呢？這種錯誤的產生，追根溯源就是軟體開發者的共識和習慣導致使用者也養成了這樣的思維慣性。那麼，我們何不將其以標準的形式公布，讓市面上軟體都強制性這樣做呢？尤其是那些涉及安全隱私和個人財產的軟體，這種方面的設計更是應該限制，不能讓他們利用使用者的習慣進行「慣性詐騙」。
問題5
16.1.5 迷思之五：要成為領域的專家，才能創新這個例子讓我感覺和前面的例子有點不同。專家們不是簡單地有想法認為隨身聽沒有市場，而是嘗試用市場調查去證明他們的觀點。而盛田昭夫只是用直覺來力排眾議，最終取得了成功。這個例子說明了什麼呢？另乙個例子是索尼公司的「單放機」（walkman）。公司的專家們認為隨身聽沒有市場，他們還做了多次市場調查，來證明大眾不會喜歡「只能放**，不能錄**的小玩意」。盛田昭夫基於自己對電子消費品的趨勢洞察和對未來的直覺，堅持推動研發。walkman最終吸引了眾多的消費者，這是許多專家當初想不到的。
這種創新更像是一種冒險，未必是內行想不到，而是內行在經過市場調查後選擇了放棄。但盛田昭夫還是要推行。雖然他成功了，我們在此對其予以讚揚，可萬一這是一款失敗的產品呢？我們只會批評他「思維怪異，特立獨行」，一點都不懂消費者，就像是之前案例中提到的銥星手機。事後諸葛亮大家都會當，可是我們真的應該把創新交由直覺嗎？
2.請問 「軟體」 和 「軟體工程」 這些詞彙是如何出現的 - 何時、何地、何人？
3.【附加題】：大家知道了軟體和軟體工程的起源，請問軟體工程發展的過程中有什麼你覺得有趣的冷知識和故事？
千年蟲問題與日本年號
「千年蟲問題」其實算不上是乙個冷知識。千年蟲問題是指，在某些使用了電腦程式的智慧型系統（包括計算機系統、自動控制晶元等）中，由於其中的年份只使用兩位十進位制數來表示，因此當系統進行（或涉及到）跨世紀的日期處理運算時（如多個日期之間的計算或比較等），就會出現錯誤的結果，進而引發各種各樣的系統功能紊亂甚至崩潰。
「千年蟲」問題的根源始於60年代。當時計算機儲存器的成本很高，如果用四位數字表示年份，就要多占用儲存器空間，就會使成本增加，因此為了節省儲存空間，計算機系統的程式設計人員採用兩位數字表示年份。隨著計算機技術的迅猛發展，雖然後來儲存器的**降低了， 但在計算機系統中使用兩位數字來表示年份的做法卻由於思維上的慣性勢力而被沿襲下來， 年復一年，直到新世紀即將來臨之際，大家才突然意識到用兩位數字表示年份將無法正確辨識公元2023年及其以後的年份。2023年，資訊界開始拉起了「千年蟲」警鐘，並很快引起了全球關注。
雖然後來各大公司想盡辦法或多或少的解決了這個問題，但在2023年時，日本有許多公司沒有被千年蟲問題所困擾。因為他們許多裝置年號並非按照公元年份來計時，而是按照日本天皇的年號來計時。2023年，只是平成12年，日本的許多裝置可以在這個基礎上繼續計時，用到平成99年。但沒想到的是，日本居然在2023年改元，年份從「令和元年」開始重新計時。這時候，日本許多公司不得不重新思考千年蟲問題的解決方案。當然，也有公司可以選擇繼續拖。不過拖到平成99年的時候，這個問題依然需要拿出來解決。
4.上網調查一下目前流行的源程式版本管理軟體和專案管理軟體都有哪些， 各有什麼優缺點？
5.(3.6更新)調查完目前流行的源程式版本管理軟體和專案管理軟體後，請你選擇其中至少2個軟體來進行動手實踐。
BUAA 2020 軟體工程 熱身作業
author 17373051 郭駿 專案內容 這個作業屬於哪個課程 2020春季計算機學院軟體工程 羅傑 任健 這個作業的要求在 第一次作業 熱身！我在這個課程的目標是 學習軟體工程的開發知識，培養工程化開發能力 這個作業在哪個具體方面幫助我實現目標 從過去 現在和將來剖析自己，更加了解自己 作業...
BUAA 軟體工程個人作業
專案內容 這個作業屬於哪個課程 2020春季計算機學院軟體工程 羅傑 任健 這個作業的要求在 個人專案作業 我在這個課程的目標是 學習軟體工程的開發知識，培養工程化開發能力 這個作業在哪個具體方面幫助我實現目標 通過實操掌握psp開發基礎 psp2.1 personal software proce...
BUAA2020軟工個人部落格作業2 軟體
專案 內容這個作業屬於哪個課程 2020計算機學院軟體工程 羅傑 任健 這個作業的要求在 軟體案例分析部落格作業 我在這個課程的目標是 進一步提高自己的工程能力，提高自己的團隊協作和表達能力 這個作業在哪個具體方面幫助我實現目標 對成熟的軟體分析，進一步了解軟體開發和維護的過程 1.使用10 30分...