實驗四 軟件項目案例分析
| 項目 | 內容 |
| 課程班級博客 | https://edu.cnblogs.com/campus/xbsf/nwnu2020SE |
| 作業要求 | https://www.cnblogs.com/nwnu-daizh/p/12616341.html |
| 課程學習目標 | 學習團隊軟件項目流程（TSP）、團隊成員協作要求並掌握敏捷流程原則及相關概念。 |
| 這個作業在哪些方面幫助我實現學習目標 | 體驗軟件項目開發中的兩人合作，練習結對編程，掌握Github協作開發程序的操作方法。 |
| 結對方學號-姓名 | 201771010135-楊蓉慶 |
| 結對方本次博客鏈接 | https://www.cnblogs.com/YRQY/p/12618697.html |
實驗內容和步驟：
任務一：實驗三優秀案例推薦：王之泰&韓臘梅組
案例作業博客鏈接：https://www.cnblogs.com/hanlamei/p/12574378.html
案例作業項目倉庫鏈接：https://github.com/YHwzt/Query-system-web
（1）對案例博文作業進行閱讀並進行評論評論要點包括：博文結構、博文內容、博文結構與PSP中“任務內容”列的關系，並將以上評論內容發布到案例作業的博客評論區。
（2）克隆案例項目源碼到本地機器，閱讀項目代碼規范文檔並運行代碼，總結代碼運行中存在的問題，體會案例博文是否有助於項目代碼理解。
1.系統運行截圖如下
- 登錄界面：
- 注冊界面：
- 信息填寫提交
- 高級查詢
- 信息錄入
- 信息填寫提交
- 可視化統計功能
- 信息導出
2.軟件功能總結
- 基本功能
- 系統可采集學生疫情有效信息；
- 學生在前端提交信息到管理員端；
- 各學院指定負責人登錄系統，可查看學生填報的所有匯總數據
- 負責人可根據學生的姓名，學院，地址查找相關信息
- 負責人可直接添加學生的信息
- 負責人也可將填寫有誤的學生信息進行修改及刪除
- 擴展功能
- 每日十點之后停止填報
- 負責人通過【導出】可獲取疫情數據的EXCEL文件
- 負責人可通過圖形化方式查看各學院已填報和未填報學生統計情況和關鍵疫情數據統計情況
- 填報提醒功能通過郵件的方式每天在九點半定時向學生及教職工發送疫情填報提醒
（3）總結本組實驗三博客作業及代碼設計存在問題與不足，列舉代碼中存在的bug，未實現的功能等等。
我的eclipse運行出錯，改為idea運行時，由於環境配置不同導致出錯，數據庫連接也出現了問題，最后通過搜索並請教同學解決了問題，成功運行出了結果。
該程序代碼也存在一些格式上的小問題，如下圖：
任務二：與實驗三結對伙伴協作學習：閱讀《現代軟件工程—構建之法》第5-6章內容，理解並掌握以下內容
軟件項目團隊的特點
（1）團隊有一致的集體目標，團隊成員要一起完成目標，一個團隊的成員不一定要一起工作。
（2）團隊成員有各自的分工，互相依賴合作，共同完成任務。
軟件團隊的模式：軟件團隊有各種模式，適用於不同的人員和需求，主要有以下幾種
- 蜂窩模式：是一種歡樂而隨意的形式。
- 主治醫師模式：各司其職，為主治醫師服務。
- 明星模式：主治醫師模式的極點。
- 社區模式：每個人參與自己感興趣的方向。
- 業余劇團模式:每個團隊在不同的項目會挑選不同的角色。
- 秘密團隊：每個人在秘密條件下進行。
- 特工團隊：有特殊技能的專業人士。
- 交響樂團模式：交響樂團的演奏模式。
- 爵士樂模式：與交響樂隊模式對立。
- 功能團隊模式：具備不同能力的人平等協作。
- 官僚模式：小頭目-->中頭目-->大頭目。
經過我們的討論，我們認為對於我們學生現如今而言，比較好的還是交響樂團模式以及功能團隊模式。交響樂團門類齊全，各司其職，演奏都靠譜，同時看指揮；當某個軟件領域處於穩定成長階段的時候，眾多大型軟件公司的開發團隊就會采取這種模式，例如微軟公司的office軟件。而功能團隊模式是指具備不同能力的同事們平等協作，共同完成一個功能，在這個功能完成以后，這些人又重新組織，和別的角色一起去完成下一個功能，他們之間沒有管理和被管理的關系。很多軟件公司的團隊最后都演變成功能團隊，大型軟件公司里的不少團隊也采用這種模式，但功能團隊也有一個弊端，即沒有決策者，適當的交流是好的，但一旦交流，就難免會出現分歧，眾口難調的話，就需要一位決策者了，決策者做的決定不可能遷就每一個小組，但至少可以讓利益最大化。。
我希望之后實踐時，我們的團隊模式可以是二者的結合形式，通過磨合，能夠協同作戰。團隊可以公開的討論流程和工作的方式，協商制定計划；PM可以得到廣泛尊重，有能力的成員也分擔一定的領導職責；大家各司其職，平等協作，最后匯總各部分，完成任務。
明確目標，合理分工，共同協作
典型軟件過程模型特點
一、瀑布模型（Waterfall Model）
瀑布模型（經典生命模型）提出了軟件開發的系統化的、順序的方法。其流程從用戶需求規格說明開始，通過策划、建模、構建和部署過程，最終提供一個完整的軟件並提供持續的技術支持。
- 模型特點：
- 必須等前一階段的工作完成之后，才能開始后一段的工作；
- 每一階段都必須完成規定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。
- 前一階段的輸出文檔就是后一階段的輸入文檔，因此，只有前一階段的輸出文檔正確，后一階段的工作才能得到正確的結果。
- 每個階段結束前都要對所完成的文檔進行評審，以便及早發現問題，改正錯誤。事實上越是早期階段犯下的錯誤，暴露出來的時間就越晚，排除故障改正錯誤所需付出的代價也越高。因此，及時審查，是保證軟件質量，降低軟件成本的重要措施。
理解：瀑布模型作為最早出現，應用最廣泛的軟件過程模型，適用於需求確定，無大的需求變更，工作能夠采用線性的方式完成的軟件。此模型強調了開發的階段性，各階段具有順序性和依賴性，並且提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。但其局限性在於要求項目嚴格按規程推進，必須等到所有開發工作全部完成以后才能獲得可以交付的軟件產品。不能對軟件系統進行快速創建，對於一些急於交付的軟件系統的開發很不方便。而且對於分析初期需求模糊的項目，瀑布模型也並不適合。
二、增量模型（Incremental Model）
增量模型融合了瀑布模型的基本成分和原型實現的迭代特征，它對軟件過程的考慮是：在整體上按照瀑布模型的流程實施項目開發，以方便對項目的管理；但在軟件的實際開發中，則將軟件系統按功能分解為許多增減構件，並以構件為單位逐個地創建與交付，直到全部增量構件創建完成，並都被集成到系統之中交付用戶使用。
- 模型特點：
- 當使用增量模型時，第一個增量往往是核心的產品；
- 客戶對每個增量的使用和評估都作為下一個增量發布的新特性和功能；
- 該模型采用隨着日程時間的進展而交錯的線性雪獵，每一個線性序列產生軟件的一個可發布的“增量”。
理解：增量模型適用於項目在既定的商業要求期限之前不可能找到足夠的開發人員的情況。優點是開發由增量表示的小系統所承擔的風險不大，但局限性是如果沒有對用戶的變更要求進行規划，那么產生的出事增量可能會造成后來增量的不穩定。
三、快速原型（Rapid Prototype）模型
軟件開發過程中，開發初期很難得到一個完整的、准確的需求規格說明，開發者往往對要解決的應用問題模糊不清，以至於形成的需求規格說明常常是不完整的、不准確的，有時甚至是有歧義的。此外，在整個開發過程中，用戶可能會產生新的要求，導致需求的變更。為了適應這種需求的不確定性和變化，於是出現了快速原型（Rapid Prototype）開發方法。
- 模型特點：
- 快速原型是用來獲取用戶需求的，或是用來試探設計是否有效的。一旦需求或設計確定下來了，原型就將被拋棄。因此，快速原型要求快速構件、容易修改，以節約原型創建的成本、加快開發速度；
- 快速原型是暫時適用使用的，因此並不要求完整。它往往針對某個局部問題建立專門原型，如界面原型、工作流原型等；
- 快速原型不能貫穿軟件的整個生命周期，它需要和其他的過程模型相結合才能產生作用。例如，在瀑布模型中應用快速原型，以解決瀑布模型在需求分析時期存在的不足。
理解:快速原型方法比較適用於用戶需求不清、需求經常變化的情況。當系統規模不是很大也不太復雜時，采用該方法比較好。而且 減少了開發風險，避免了因為需求不確定而在開發過程中浪費了大量的資源。但快速原型模型沒有考慮到軟件的整體和長期的可維護性。
四、漸進交付流程
漸進交付流程是史蒂夫.邁克康奈爾在1996年總結的，但是它其實已經很接近現在大家談論較多的迭代式開發流程。當系統的主要需求和架構明確之后，軟件團隊進入了一個不斷演進的循環中
[ 開發 → 發布 → 聽取反饋 → 根據反饋做改進 ]
通過資料的搜集，我發現漸進交付流程已經接近現在大家所說的開發流程。當系統的主需求和架構明確之后，軟件團隊進入了一個不斷演進的循環中。但漸進交付流程最大的弊端在於產品團隊得到用戶的反饋太晚了。為了讓用戶更早地給產品團隊反饋，把“盡早”推到極致，從2009年開始，MVP方法達到廣泛應用。
MVP一Minimum Viable Product：最小可行產品,又稱為Minimal Feature Set,最小功能集。
具體的做法是:把產品最核心的功能用最小的成本實現出來(或者描繪出來)，然后快速征求用戶意見。MVP的指導思想和漸進交付相似，但是它更強調更早獲得用戶反饋，為此可以在產品完成之前就發布，它也強調產品的核心價值(產品最區別於競爭產品的地方)，為了突出核心功能，別的輔助功能可以不考慮或者用別的平台提供的服務來代替。
MBP一Maximal BeautifulProduct :最強最美產品，對用戶的需求了然於心，產品團隊比用戶更了解用戶的需求，把產品最全、最美的形態展現出來，一舉征服用戶。
五、敏捷流程
敏捷流程圖如下所示
第一步:找出完成產品需要做的事情一Product Backlog。
Backlog翻譯成“積壓的工作”、“待解決的問題”、“產品訂單”，都可以。產品負責人領導大家對於這個Backlog中的條目進行分析、細化、理清相互關系、估計工作量等工作。每一項工作的時間估計單位為“天”。
第二步:決定當前的沖刺( Sprint )需要解決的事情一Sprint Backlog。
以小時為單位，如果一個任務的估計時間太長(如超過16個小時)，那么它就應該被進一步分解。訂單上的任務是團隊成員根據自己的情況來認領。如果團隊成員能主導任務的估計和分配，他們的能動性會得到較大的發揮。
第三步:沖刺。
沖刺期間，團隊通過每日例會(ScrumMeeting)來進行面對面的交流，每日立會強迫每個人向同伴報告進度，迫使大家把問題擺在明面上。同時團隊要啟動每日構建，讓大家每天都能看到一個逐漸完善的版本。
六、理解並體會卡內基梅隆大學（CMU）軟件工程學院總結的TSP原則
- 使用妥善定義的流程，流程中的每一步都是可以重復、可以衡量結果的。
- 團隊的各個成員對團隊的目標、角色、產品都有統一的理解。
- 盡量使用成熟的技術和做法。
- 盡量多地收集數據(也包括對團隊不利的數據),並用數據來幫助團隊做出理性的決定。
- 制定切合實際的計划和承諾，團隊計划要由負責具體執行的的角色來制定(而不是從上級而來)。
- 增加團隊的自我管理能力。
- 專注於提高質量，爭取在軟件生命周期的早期發現問題。最有效提高質量的辦法是做全面而細致的設計工作(而不是在后期匆忙修復問題)。
這些原則雖然抽象，但是每個團隊在做Postmortem的時候（Postmortem是指軟件項目結束以后，對產品的回顧以及讀開發過程的分析），可以對照檢查,看看自已的團隊在剛剛過去的軟件生命周期中到底提高了多少。
通過閱讀，我個人認為這幾個原則中最重要的是增加團隊的自我管理能力，在平常的軟件工程項目設計中，一定要首先制定好合理的進度計划，再去逐步做好。從逆向的思維方式來整理科學的管理方法對整個軟甲工程項目的推進至關重要。
任務三：與實驗三結對伙伴協商，在三個班級中選擇一個高質量的團隊項目案例進行協作學習，要求追蹤該團隊項目發布所有博客作業，下載項目軟件代碼。
1.團隊項目作業發布賬號鏈接：https://www.cnblogs.com/PureMan6/p/10739662.html#4
2.團隊項目倉庫github鏈接：https://github.com/swearitagain/EduCnblogs2.0
3.陳述你選擇該團隊項目進行分析的理由：
開始在考慮三個團隊項目選擇的問題上，和結對伙伴最終通過討論選擇了北京航空航天大學的班級博客客戶端項目設計，選擇這個項目主要有兩個原因，第一是我們通過瀏覽項目博客及相關內容，可以看到這個項目的完整度和復雜度都很高，深入學習的空間很大。第二點是這個項目的創新性很高，我們恰巧在學習軟件工程這門課的時候都是通過博客園來進行學習交流，如果可以在手機端方便地查看班級博客的相關內容，會使得平常使用起來更加便捷，此項目滿足了實用性的特點。
4.結合項目系列博客文檔，總結項目團隊成員的分工合作情況
項目團隊成員有六位成員構成，其中三位擔任開發人員，一位是開發/PM 另外兩位分別是測試人員和項目經理，分工較為合理，從博文中的成員貢獻和特殊加減分的部分可以看出整個設計過程的記錄非常完整，在之后的項目設計中會試着去學習運用。
5.結合項目系列博客文檔，評價項目的軟件項目過程特點（TSP）
首先可以看到團隊的各個成員對團隊的目標、角色、產品都有統一的理解，團隊成員的整體能力都較高，后期還通過用戶反饋情況和對機型、環境（機型，版本，分辨率）的測試來改進完善功能。團隊的自我管理能力較好。而且專注於提高質量，反復的測試能夠在軟件生命周期的早期發現問題，可以有效地提高質量設計工作全面而細致(而不是在后期匆忙修復問題)。
6.觀察該團隊項目github倉庫的源代碼文件結構，是否包含代碼規范文檔？
該團隊項目github倉庫中未包含代碼規范文檔
7.下載團隊項目代碼，嘗試部署項目運行環境並使用軟件，描述最簡單直觀的使用體驗，找出至少兩個比較嚴重的功能性bug，在博客中展示截圖；
- 部分功能截圖如圖所示
系統功能bug
①博客作業的提交列表不顯示
②提交的博文內容查看時Markdown的渲染和博客園的背景不顯示
8.評價該團隊項目是否值得繼續開發，並陳述理由？
我認為該團隊項目非常值得開發，就我個人對博客園的體驗來說，每次交作業都不知道截止時間是什么，但在手機端登錄博客園查看時很不方便，也沒必要每次都打開電腦查看，這樣一個手機端的應用不僅有提醒功能，還對班級博客園的相關部分都着重顯示出來，用戶體驗極好，方便且實用，從軟件的應用性來看非常值得開發。其次就是此項目的具體設計，基本功能實現和頁面設計都較為完善，其中存在的小問題以及頁面的美觀也可以通過后期的用戶體驗逐步完善改進。
各項任務實際花費的時間
| 任務內容 | 計划共完成需要的時間（min） | 實際完成需要的時間 |
| 任務一 | 180 | 200 |
| 任務二 | 120 | 120 |
| 任務三 | 180 | 240 |
小結感受
這次實驗的目的是學習團隊軟件項目流程（TSP）、團隊成員協作要求及敏捷流程原則及相關概念。通過閱讀《現代軟件工程—構建之法》第5-6章內容以及網上資料的搜集，對基本概念有了全面的了解，此外，此次實驗很重要的部分是優秀案例的學習，一個是同班同學的案例，由於之前的作業中也做過同樣的案例，理解起來較為容易，也能夠把我們的項目和他們的項目做個比較，學習他們的設計中的優點，對以后的學習很有幫助。第二個優秀案例的學習是北京航空航天大學的團隊項目案例，這是一個較為完整的團隊項目，不僅做出了實用度較高，質量較好的項目，而且從整體的設計過程中可以看出團隊成員的整體水平和協作能力都較高，我深刻地體會到了自己能力的欠缺，希望之后可以通過自己的努力慢慢進步。