本學期一共留了六次作業，其中前兩次是個人作業，後四次是團隊作業。
前兩次作業分別是優秀博文閱讀和軟體案例分析。後四次團隊作業我將其分**和原型部份（團隊作業1,2,3,），以及最終的**部份（團隊作業4）。
第一次個人作業中，一大半同學表示自己並不喜歡計算機，當時選專業要麼是順從父母的心願，要麼是稀里糊塗選的，為了有更好的經濟收入等原因。幾乎全部的同學對問題的回答都實事求是，喜歡就給出理由，不喜歡就說不喜歡。很少有人說一些迎合的言不由衷的話。90%的同學在引用博文時沒有提到作者名字。
對未來的規劃，超過50%的同學還不是很清晰，有盡50%的同學有自己感興趣的方向和想做的事，或者直言自己想過簡單的生活，並沒有太高的追求。
幾乎100%的同學都認為學數學對學計算機是必要的，但表示自己並沒有完全理解數學知識如何幫助提高計算機學習水平。
第二次個人作業中，部分同學大段的貼上引用文件的內容，個別同學的作業中有80%的文字原封不動copy別人的文章，缺少自主內容。除了軟體發展史和一些資料部分作引用，文章最好還是表達自己的觀點，說自己的語言。引用部分要表明，切勿第一人稱引別人的對話，新聞稿，貼上到自己作業中。對主動思考，作業原創的同學提出表場。
對於教學方面的到的經驗就是，本次作業選擇的應用比較大，使得一些同學的文章基本上是在羅列功能和模組，而且網上參考的文件過多，東西引用一下就能寫好多。以後可以考慮小眾點的軟體，或者與軟體創作團隊有合作的軟體，或者流行應用的某方面功能。
團隊作業，文件部分，有一些團隊把作業當作創業專案來做，從選題開始就做了詳細的需求分析，競品分析，勝出的手段，甚至還做了市場分析，使用者調研。兩次大作業寫得都很認真，需求分析中就做了mock up。真是非常不錯。但也暴露了乙個問題，就是scope有點大，畢竟時間有限。有一些團隊把作業當作一次大作業，從一開始定位就定低了，作業完成得也不是很認真。有的團隊，第二次大作業的需求分析的題目和第一次大作業的選題完全不同，後來問了蘇老師，是有一些關於選題改變的私下的溝通。給我個人的經驗就是要和同學和老師多溝通。
團隊作業，**部分，最終提交的**跟需求分析相差較大。同學們的**完整性有待提高。個別組只提交了支離破碎的幾個檔案在git上。回過頭來看，coding的時間對於需求分析中的專案規模來說來太短了。跟之前的猜測吻合，專案scope過大，在非常有限的時間內，即使經驗豐富配合默契的開發 也很容易遇到問題，更何況初出茅廬沒有磨合的同學們了。以後這個團隊作業，我會推薦我們的團隊做乙個非常小的專案，哪怕是乙個手電筒，乙個小遊戲，把需求，原型，設計，**，測試，提高，發布，推廣，文件這套流程走下來，高質量的完成，應該比選乙個巨大無比的專案然後寫完分析和所謂的設計就拉倒要收益更多。師兄師姐傳給師弟師妹的傳承制我是不支援的。即使經驗豐富的軟體開發接下乙個現有專案也有相當的難度，而且需要不斷重構。如果文件不完整或是transfer不好，那在現有專案上繼續開發的難度就更大。所以我個人還是建議做乙個小專案，把它在有限的時間內做好，積累經驗和信心。
在一學期的時間裡，我也收穫很多寶貴經驗，謝謝老師們的幫助和同學們的支援。希望大家都能百尺高竿更進一步。
軟工 軟體測試
軟體測試的目的 測試是程式的執行過程，目的在於發現錯誤 乙個好的測試用例在於能發現至今未發現的錯誤 乙個成功的測試是發現了至今未發現的錯誤的測試 軟體測試的原則 盡早地和不斷地進行軟體測試 由測試輸入資料和對應的預期輸出結果組成 程式設計師應避免檢查自己的程式 在設計測試用例時，應合理的輸入條件和不...
軟工 軟體維護
一 軟體維護的型別 改正性維護 適應性維護 完善性維護 三類維護佔總維護比例 維護在軟體生存期所佔比例 二 維護的問題 理解別人寫的程式困難，困難程度隨軟體配置成分減少而迅速增加 要維護的軟體往往沒有合適的檔案或資料不全 絕大多數軟體設計時沒有考慮將來的修改 軟體維護不是一項吸引人的工作 軟體人員經...
軟工 軟體計畫
軟體計畫 軟體 估計 成本收益分析 制定軟體計畫是軟體工程的第乙個步驟，其中主要是問題的定義，也就是可行性研究，第二個是專案開發計畫任務 步驟複查系統規模和目標 研究目前正在使用的系統 匯出新系統的高層邏輯模型 重新定義系統 匯出和評價供選擇的方案 推薦乙個方案，並說明理由 推薦行動方針 書寫任務計...