軟件工程_第一次閱讀做業

項目	內容
課程	軟件工程（羅傑）
做業要求	第一次閱讀做業
個人課程目標	瞭解軟工開發流程，編程實踐
此做業幫助	閱讀《構建之法》，對軟工有基礎認識

1.閱讀教材後的問題

第4章 結對編程

總之，若是運用獲得，結對編程能夠取得更高的投入產出比（Return of Investment）。

• Q1
  此處的投入產出比彷彿是一個缺少定義的概念。結對編程的核心想法大概是一人領航一人實際操做，並經過頻繁交流迫使雙方共同努力提升自身水平，這種工做模式在參與者水平均較高且至關的狀況下必定程度上天然能減小錯誤、有必定督促效果，但考慮到磨合成本，以及現實中參與者每每存在水平、技能的差別，可否真的達到比兩人高效協同工做收益更高，我持懷疑態度。

第6章 敏捷流程

教材中對敏捷開發團隊成員提出了較高的要求：
1.以有進取心的人爲項目核心，充分支持信任他們。
2.自助管理、自我組織、多功能型。

對於團隊成員質量的保證，我有如下兩個問題：

• Q2
  這樣的團隊成員要求不說極高，但也算很高了。那麼，爲了持續保證成員質量，是否須要以某種形式進行團隊成員出入的管理？以何種標準合適呢？

• Q3
  敏捷開發以充分信任爲前提，但人和團隊每每是有惰性的。即使是每日例會平行比較工做量，若是全部人在安逸的條件下都有必定的惰性，那就失去了比較的價值。如此而來，是否應當引入外界篩選壓力從而督促團隊提升效率呢？外界壓力和信任是否存在必定衝突？

對於敏捷流程，我有如下問題：

• Q4
  敏捷開發以我的衝刺爲工做行爲單元，任務多零散。這樣的模式對於有複雜依賴關係的軟件系統，是否會致使在工做對接上致使效率下降呢？

第16章 IT行業的創新

兩三個專一於某一領域的匠人，用非大規模製造技術打造出來的東西還有價值麼？IT歷史告訴咱們，有不少成功的產品都是從小做坊開始的。

• Q5
  歷史中的成功和當下成功的條件是很不一樣的。現在，軟件行業的質量要求、用戶需求都比以往多得多（用戶容忍度低），在這種狀況下，小做坊形式的產物會不會更容易面臨因資源不足的問題難以達到當今環境的質量標準線，從而難以成功？

2.「軟件」 和 「軟件工程」 最初出現的場景

• 軟件
  Alan Turing於1935年在其論文「Computable numbers with an application to the Entscheidungsproblem (decision problem)」中提出。
• 軟件工程
  Margaret Hamilton於1968年在阿波羅計劃期間提出。

3.目前流行的源程序版本管理軟件和項目管理軟件用戶數量與優缺點比較

用戶數量 （維基百科）

Name	Users	Projects
Github	31,000,000	100,000,000
GitLab	100,000	546,000
Bitbucket	5000,000	Unknown
SourceForge	3,700,000	500,000
Launchpad	4,000,000	41,000

優缺點比較：

• Git
  • 優勢：
    1.適合分佈式開發，強調個體
    2.用戶項目多，利於交流
    3.很好的版本管理功能支持
    4.公共服務期壓力和數據量不會太大
    5.能夠離線工做
  • 缺點：
    1.概念較多，學習成本相對較高
    2.權限管理較複雜
• Bugzilla:
  • 優勢：
    1.檢索功能強大
    2.Bug跟蹤處理
    3.強大的後端數據庫支持
    4.免費開源
    5.有漢化版本
  • 缺點：
    1.安裝須要Mysql數據庫配置，修改配置文件也較繁瑣
    2.漢化亂碼
• Mercurial:
  • 優勢：
    1.服務器部署較容易
    2.命令兼容SVN
    3.多數命令有雙字母縮寫，命令行工做效率較高
  • 缺點：
    分支管理不靈活，相對於Git進行branch管理很不方便
• SVN:
  • 優勢：
    1.集中式服務器，更能保證安全性，易於管理
    2.使用相對簡單
  • 缺點： 1.若中心服務器出現問題，全部人的工做都會暫停，且恢復較麻煩 2.必須聯網才能提交、還原、對比 3.服務器壓力較大