萬變不離其宗
— 筆記整理自 北京理工大學 計算機學院
軟件開發中的一則小故事
- 程序員寫出自認爲沒有Bug的代碼。
- 軟件測試，發現了20個Bug。
- 程序員修改了10個Bug，並告訴測試組另外10個不是Bug。
- 測試組發現其中5個改動根本無法工作，同時又發現了15個新 Bug。
- 重複n次步驟3和步驟4。
- 鑑於市場方面的壓力，爲了配合當初制定的過分樂觀的發佈時間表， 產品終於上市了。
- 用戶發現了137個新Bug。
- 已經領了項目獎金的程序員不知跑到哪裏去了。
- 新組建的項目組修正了全部137個Bug，但又發現了456個新Bug。
- 最初那個程序員從斐濟給飽受拖欠工資之苦的測試組寄來了一張明信片。整個測試組集體辭職。
- 公司被競爭對手惡意收購。收購時，最終版本包含783個Bug。
- 新CEO走馬上任。公司僱了一名 新程序員重寫該軟件。
- 程序員寫出自認爲沒有Bug的代碼。
軟件開發週期
軟件開發的基本活動相同，但組織方式不同，構成了不同的軟件生存(開發)週期模型。參考之前的項目管理博文
基本都是：需求分析，系統分析設計，編碼測試，無論怎麼開發，這些活動總得有
軟硬件(故障)生存曲線
備註：圖片託管於github，請確保網絡的可訪問性
第一種是浴缸模型，開始生產硬件的的時候各種問題，經過一段磨合之後逐漸趨於穩定，最後由於壽命快結束了，故障又多了起來
第二種是理想的軟件模型，開始的時候很多故障，隨着不斷的修復, 故障越來越少
第三種是實際的軟件模型，開始的時候很多故障，隨着不斷修復，故障少了起來，加入新的功能後，故障又多了起來，再次進行修復，再次加入新的功能，再次故障，再次修復等等
典型的開發週期模型
備註：圖片託管於github，請確保網絡的可訪問性
瀑布模型有一個特點，水往低處流，不能再回來，也就是順序進行的，一直往前走，不回頭
迭代模型的特點是，逐步完善，隨着迭代的增加，整個項目越來越完善
軟件開發的基本活動
備註：圖片託管於github，請確保網絡的可訪問性
這裏將一條直線變成了一個圓，將變更管理作爲軸心，滾動前進
階段一：可行性分析
解決的是做和不做的問題
要考慮的一些因素：
- 錢的問題，是否掙錢，以盈利爲目的，以及其他因素
- 技術問題，員工技術能力能否搞定，當今的技術能否可以實現，包括當前的一些，算法，AI, 大數據，雲計算, 區塊鏈等等
- 社會環境，市場是如何，國內國際相關政策是否支持，更多的是商業問題
- 人的問題：有四類：公司領軍人物，各個領域的精英人才，人手是否足夠，人精(公關營銷,售前售後等) 各司其職
階段二：需求分析
解決的是做什麼的問題
- 捕獲客戶心中到底要做什麼，一般很難捕獲，客戶可能自己都不知道要做什麼
- 捕獲後記錄下來，通過客戶反饋，反覆與客戶確認
- 開始進行分析，比如使用UML用例，非形式化的自然語言對需求的描述
階段三：系統分析與設計
解決的是怎麼做的問題
- 體系結構：比如北京的交通圖，用的是環路結構，還是棋盤設計，各有什麼優缺點
- 模塊：它是一種分解的思想，一開始解決不了，我們分解成模塊，每個模塊有什麼關係, 比如數據庫的設計，如何分庫，分表
- dsa：數據結構與算法，不同的數據結構，需要不用的算法支持，比如百度，谷歌，bing等的搜索引擎，他們的算法是不一樣的，結構也不一樣
- 界面：界面需要符合一定的規則, 比如鍵盤的設計, App的設計，環節的跳轉，遊戲界面的展示
階段四：詳細設計
解決的也是怎麼做的問題，這裏會更細化一些
備註：圖片託管於github，請確保網絡的可訪問性
可能包括：某個算法，某個僞代碼的實現，結構的明確等等
階段五：編碼階段
目前世界上存在各種編程語言，不同的語言又不同的特點，一個程序員想要精通各種編程語言，幾乎是不可能的，什麼樣的場景選擇使用什麼語言和相關框架
階段六：測試階段
這是一個亡羊補牢的階段！
給你一臺冰箱，你該如何測試？
常規(冰箱門是否可以正常打開, 是否能夠正常製冷等等) + 極端(電壓不穩，是否正常, 斷電後還能運行多久等等) = 通過
測試內容：單元測試(程序員來做)，集成測試，系統測試，功能測試，性能測試，壓力測試，迴歸測試
階段七：部署
開發環境與生產環境
軟件本身Bug
支持環境兼容性問題(OS，數據庫等)
自動化部署(降低部署成本)
階段八：維護
改正性：bug類
適應性：用戶環境變化, 做的調整
完善性：佔比越來越高，用戶需求變更，從開發階段到維護階段
預防性：千年蟲問題
管理活動貫穿整個週期
管理這個因素太重要了
二八理論：20%的高端用戶提供80%的利潤；技術人員應掌握80%的技術 + 20%的管理
被管理者也應具有管理的思維，學習軟件工程，管理與被管理的技巧
牧羊與牧貓：羊很乖，但貓不一樣，程序員就像是貓一樣，有激情，有個性，如何差異性管理
在一個小型敏捷開發團隊中，手下成員大概有5~9人，建議是7人是最合理的配比