一、個人履歷
代碼連結：https://github.com/fayanddream/resume.git
二、讨論
1.解釋一個軟體生命周期的概念并提供一個例子，解釋它的各階段，包括生産傳遞（不僅限于瀑布模型生命周期）。
答：
軟體生命周期是軟體的産生直到報廢或停止使用的生命周期。軟體生命周期内有問題定義、可行性分析、總體描述、系統設計、編碼、調試和測試、驗收與運作、維護更新到廢棄等階段。
增量模型是遵循遞增方式來進行軟體開發的。軟體産品被作為一組增量的構件，每次需求分析、設計、實作、內建、測試和傳遞一塊構件，直到所有構件全部實作。
以一個商務網站為例進行分析：
需求分析：首先需要對企業的需求進行調查，明确電子商務網站需要做什麼，做到什麼程度，并通過查閱資料，實地觀察等方法，将網站的需求歸納為功能需求和性能需求。功能需求：店家釋出産品資訊，整理網上商品，管理訂單等；消費者選購、線上支付，通過物流最後達成交易。性能需求：系統運作要穩定，具有較強的适應性，可移植性。
設計：系統設計階段就是根據系統說明書的要求，設計新系統的實體模型，主要完成系統劃分和資料庫設計的工作。本項目中，可以劃分為登陸賬戶子產品、浏覽商品子產品、購物車子產品、訂單管理子產品、背景管理子產品。資料庫的設計可以建立4個基本表：産品資訊表、使用者表、訂單表、管理者表。
實作：從實作開始，增量模型開始差別于瀑布模型。在具體的開發中，依據系統設計階段的劃分情況，完成核心子產品的頁面代碼。
內建: 在完成了對一個增量構件的開發之後，需要将該構件內建到系統中去。
測試：當把新構件內建到現有構件中時，所形成的産品即已經發生了改變的系統重新進行有效性驗證。
增量傳遞：按照增量構件的功能安排開發的優先順序，逐個實作和傳遞使用。不僅有利于使用者盡早用上系統，能夠更好地适應新的軟體環境。
2.查閱軟體災難相關資料，給軟體災難從頭到尾排序。
答：軟體災難的嚴重性可以概括為以下四種級别：
（1）微小的（Minor）：一些小問題如有個别錯别字、文字排版不整齊等，對功能幾乎沒有影響，軟體産品仍可使用。
（2）一般的（Major）：不太嚴重的錯誤，如次要功能子產品喪失、提示資訊不夠準确、使用者界面差和操作時間長等。
（3）嚴重的（Critical）：嚴重錯誤，指功能子產品或特性沒有實作，主要功能部分喪失，次要功能全部喪失，或緻命的錯誤聲明。
（4）緻命的（Fatal）：緻命的錯誤，造成系統崩潰、當機，或造成資料丢失、主要功能完全喪失等。
軟體災難的例子：
1962年，水手号火箭的緻命bug。1962年，攜帶空間探測器的水手1号火箭前往金星。起飛後偏離預定航線，任務控制在起飛293s後摧毀火箭，原因是程式員把一條手寫的公式抄為錯誤的計算機代碼。
1987年，哈特福德體育館倒塌，原因是分析受力的程式錯誤的假設鋼結構屋頂的支撐僅承受純壓力，一個支撐倒塌後，導緻連鎖反應。
1983年，蘇聯飛彈預警系統錯誤的報告遭到美國發射的5枚飛彈攻擊，幾乎引發第三次世界大戰。
2003年數天内美國“愛國者”飛彈接連出現問題，引發人們對該系統瞄準軟體存在問題的關注。
2003年發生在美國及加拿大大部分地區史上最大停電事故是由電力監測與控制管理系統出錯導緻。
2009年暴風影音“召回”全部軟體，引發六省斷網事故。南方六省斷網事件中，DNSpod伺服器遭到黑客攻擊，導緻暴風影音海量使用者服務請求無法解析，造成連鎖反應。
2010年豐田汽車表示，用于對黑匣子進行讀取的閱讀器存在一個軟體方面的故障，可能導緻資料記錄子產品出現記錄錯誤，誤導了事故發生時司機對于車速的判斷。