201671010412 郭佳 實驗三 做業互評與改進

任務一：做業互評

1.  2019春季計算機學院軟件工程(羅傑)(北京航空航天大學)

評論連接：《BUAA軟工 —— 第一次閱讀做業》
https://www.cnblogs.com/fondoger/p/buaa-software-engineering-homework-1.html

評論內容：
       關於讀《構建之法》後的思考，這位同窗非常謙虛，可是根據後面同窗用生活中的實際例子來看，你是善於觀察和思考的，好比關於結對編程，從假期與姐姐玩遊戲這件事能夠聯想到結對編程，並對結對編程有必定的思考與疑問。我以爲關於結對編程首先要知足必定條件的：首先結對成員必須在編程觀念上達成一致，其次成員之間應當保持良好的交流，願意合做，再次結對成員中的技術知識應該是具備可比性的，這樣的結對編程纔是有價值有效率的。

2.  軟件工程1916|W(福州大學)

評論連接：軟工實踐（三）——結對第一次做業（原型設計）
http://www.javashuo.com/article/p-vrokbklr-nk.html

評論內容：
       看了幾個同窗的結對做業，我以爲你的做業是最吸引人的，其餘同窗可能一上來就開始按照NABCD模型開始講本身的做品了，而你是虛構了很是有趣的一個情節，講述了開發這款產品的背景需求，接着在講述了具體的設計過程。 這樣作挺好的，值得借鑑。

3.  2016級計算機科學與工程學院軟件工程(西北師範大學)

評論連接：讀《構建之法》有感
http://www.javashuo.com/article/p-yxkbzijm-hr.html

評論內容：
       確實這樣，在使用傳統的訪談時，會出現用戶處於被動地位而每每有意無心的與開發者區分彼此，不能像一個團隊的人那樣齊心合力的識別和精化需求，爲了解決這種問題，能夠採用一種面向團隊的需求收集方法，稱爲簡易的應用規格說明技術。這種方法提倡用戶與開發者密切合做，共同標識問題，提出解決方案要素，商討不一樣方案並指定基本需求。這位同窗能夠深刻學習一下簡易應用說明技術。

做業互評閱讀心得：

       剛看到這個做業時以爲這不就是相似「商業互誇」嘛，以爲沒多大意思。但在實際來作這件事時會發現，個人認識太片面了，這實際上是一項很是有意義的任務。首先在互評以前得肯定評哪一個博文，爲何評這個博文，這就先得去閱讀大量的不一樣同窗的博文，閱讀時會發現對於同一個做業問題，有一百我的就會有一百種見解和思考，這也會使咱們對待同一個問題有了更多的認識，有了想要和這些同窗的思想的交流，天然而然就會進行評論，這也就不會產生評論商業互捧的話，或者是些大話空話。閱讀過這些同窗們的博文，也讓咱們看到了咱們與這些優秀同窗的區別，更促使咱們應該跟努力去學習。

---

任務二： 軟件生存週期各階段中的文件編制

       軟件文檔是軟件開發過程當中產生的軟件產品，與軟件生存週期有着密切關係。根據國家標準中GB/T8567-2006標準關於軟件產品文件規範內容與軟件生存週期各階段的關係說明：

在需求分析階段內,由系統分析人員對被設計的系統進行系統分析,肯定對該軟件的各項功能、性能需求和設計約束,肯定對文檔編制的要求,做爲本階段I做的結果,通常地說軟件需求規格說明(也稱爲:軟件需求說明.軟件規格說明).數據要求說明和初步的用戶手冊應該編寫出來
。

在設計階設內，系統設計人員和程序設計人員應該在反覆理解軟件需求的基礎上,提出多個設計,分析每一個設計能履行的功能並進行相互比較,最後肯定-一個設計,包括該軟件的結構.模塊(或CSCI)的劃分功能的分配,以及處理流程。在被設計系統比較複雜的狀況下,設計階段應分解成既要設計階段和詳細設計階段兩個步驟。在通常狀況下,應完式的文當包括:結構設計說明、詳細設計說明和測試計劃初稿。

在實現階段內,要完成源程序的編碼.編譯(或彙編)和排錯調試獲得無語法錯的程序清單,要開始編寫進度日報、週報和月報(是否要有日報或週報,取決於項目的重要性和規模),而且要完成用戶手冊、操做手冊等面向用戶的文檔的編寫工做,還要完成測試計劃的編制。

在測試階段:該程序將被全面地測試,已編制的文檔將被檢查審閱。-般要完成測試分析報告。做爲開發工做的結束，所生產的程序、文檔以及開發工做自己將逐項被評價,最後寫出項目開發總結報告.

在整個開發過程當中(即前五個階段中) ,開發集體要按月編寫開發進度月報。

在運行和維護階段,軟件將在運行使用中不斷地被維護,根據新提出的需求進行必要並且可能的擴充和刪改.更新和升級。

由此，得出軟件生命週期各階段中的文件編制，以下圖所示：

                                               表1 軟件生命週期各階段中的文件編制

文件/階段	可行性分析	開發計劃	需求分析	設計	實現	測試	使用與維護
可行性研究報告	√	√
項目開發計劃	√	√
軟件需求書			√
數據要求說明書			√
測試計劃				√	√
概要設計說明書				√
詳細設計說明書				√
數據庫設計書說明書				√
模塊開發卷宗				√
用戶手冊			√		√
操做手冊					√
測試分析報告						√
開發進度報告	√	√	√	√	√	√
項目開發總結						√

---

任務三：採訪一個高年級同窗在軟件工程實踐課中作過的項目

• 項目名稱：電子商城購物系統
• 項目簡介：該項目是仿照京東商城作的，有前臺後臺，管理員能夠經過後臺向前臺對前臺內容進行增刪改查，用戶能夠查詢瀏覽商品，加購物車，下單及後臺審覈訂單，能夠實現商品的退換貨，對購買商品進行評價，平常新聞資訊的推送等等。
• 採訪問題：
          問題1：項目如今有用戶嗎？
          回答：這個項目是課程設計時的做品，只是用來練習和測驗的，因此暫時沒有用戶。
          問題2：項目可否繼續開發，源代碼/文檔還有嗎？
          回答：應該是能夠繼續開發的，由於當時作的這個項目由於技術問題，雖然能夠加購購物車下單，可是用戶沒法進行支付，沒有微信，支付寶等的支付接口。關於文檔，當時也是寫了的，應當是還在。
          問題3：項目開發有什麼經驗和教訓？
          回答：前期的需求分析真的是相當重要的，需求分析弄不明白或者弄得不詳細，會給後期的開發形成很大的麻煩。
          問題4：對學好軟件工程有什麼建議？
          回答：寫代碼不是最難的，需求分析才最困難，但也是最終重要的。
• 採訪心得：        在此次對同窗的採訪中，咱們聊了不少，其中我以爲開發最重要的就是需求分析，同窗說拿到一個項目時，若是對需求功能潦草的分析，而急於編寫代碼，需求分析的不完全的，在後面的開發中就會遇到許許多多的問題，此時又得從新來分析需求，嚴重的可能還須要從新作。因此對於需求分析千萬不能大意，要經過各類方式詳盡的進行分析考慮。只有嚴格按照軟件工程的要求來作，才能開發出好的項目。