201771010124-王海珍-實驗四 軟件項目案例分析

項目	內容
課程班級博客	https://edu.cnblogs.com/campus/xbsf/nwnu2020SE
做業要求	http://www.javashuo.com/article/p-bkupgxcc-ns.html
課程學習目標	經過分析優秀的做業案例，掌握本身的不足之處。經過合做學習，理解合做的重要性
這個做業在哪些方面幫助我實現學習目標	體驗軟件項目開發中的兩人合做，練習結對編程，掌握Github協做開發程序的操做方法。
結對方學號-姓名	201771010126-王燕
結對方本次博客連接	<https://www.cnblogs.com/wy201771010126/p/12677569.html>

實驗內容和步驟：

任務一：實驗三優秀案例推薦：王之泰&韓臘梅組

案例做業博客連接：http://www.javashuo.com/article/p-rpvmwiux-ns.html

案例做業項目倉庫連接：https://github.com/YHwzt/Query-system-web

（1）對案例博文做業進行閱讀並進行評論評論要點包括：博文結構、博文內容、博文結構與PSP中「任務內容」列的關係，並將以上評論內容發佈到案例做業的博客評論區。

（2）克隆案例項目源碼到本地機器，閱讀項目代碼規範文檔並運行代碼，總結代碼運行中存在的問題，體會案例博文是否有助於項目代碼理解。

將案例方的代碼克隆至本地進行運行

 

 

而後進行代碼運行，截圖以下

上面是登陸界面

進行信息的添加

進行採集信息的統計

信息的展現

 以上案例實現的功能：

1，可採集全校各種師生員工疫情信息；

2，各二級部門疫情防控工做負責人可查看本部門人員疫情彙總，並提供高級查詢功能進行多屬性組合查詢和可視化統計功能；

3，學校防控辦指定負責人登陸《西北師範大學疫情防控信息統計》子系統，可瀏覽全部人員填報彙總數據清單，利用【高級查詢】可進行數據組合篩選，系統以圖形化方式展現各學院已填報和未填報學生統計狀況和關鍵疫情數據統計狀況，可【導出】查詢列表的EXCEL文件；

4，附加功能：定時填報提醒

此案例的功能實現全面，徹底按照老師的要求，實現了全部的功能，另外還實現 了附加功能，相比較 來講 算是作得很完美的，因此相比來講，我認爲此案例是很值得我來參考學習一下的。

（3）總結本組實驗三博客做業及代碼設計存在問題與不足，列舉代碼中存在的bug，未實現的功能等等。

我認爲此案例很完美沒有多少不足，可是也有一些不完美的地方，好比，倉庫中的代碼在clone以後沒有出現問題可是在導入eclipse的時候有一些問題，導不進去，最後在請教同窗和查詢相關資料以後直接在 idea打開才行，着讓不少參考者有了很大 的問題，由於打不開，會認爲本身的eclipse配置有問題，或者代碼有問題。

 

代碼規範基本沒有問題，功能實現也比較全面。

任務2：與實驗三結對夥伴協做學習：閱讀《現代軟件工程—構建之法》第5-6章內容，理解並掌握軟件項目團隊的特色、瞭解軟件團隊的模式、結合理論課學習內容理解瀑布模型及其變形、漸進交付流程、敏捷流程等典型軟件過程模型特色，理解並體會卡內基梅隆大學（CMU）軟件工程學院總結的TSP原則；

1，軟件項目團隊的特色

（1）團隊應該擁有共同的目標；

（2）團隊應該合理分工協做；

（3）高度的凝聚力是是團結的保證；

（4）團隊成員相互信息；

（5）有效的溝通；

2，軟件團隊的模式：軟件團隊有不少不一樣的模式。

（1），如下是幾種模式以及他們的優缺點：

1.一窩蜂模式：像小朋友踢球同樣，球在哪裏，人就一窩蜂跟在哪裏

優勢：歡樂而隨意

缺點：這種團隊模式很難存活，並非一種好的團隊模式

2.主治醫師模式：像在手術檯同樣，有一個主刀醫師，其餘人負責協助主刀醫師

優勢：初衷很好，一個軟件團隊中，有首席程序員，負責主要模塊的設計和編碼，其餘人儘量從各個方面支持他的工做

缺點：在一些學校的軟工課上，這種模式逐漸退化成「一個學生幹活，其餘學生打醬油」

3.明星模式：主治醫師模式運用到極點

優勢：對「明星」我的的成長進步可能會有所幫助

缺點：團隊模式強調的是團隊的做用，而不是我的的獨角戲，這種模式顯然違背了團隊模式的初衷，效率也很低

4.社區模式：由不少志願者參與，每一個人參與本身感興趣的項目，貢獻力量，大部分人不拿報酬

優勢：「衆人拾柴火焰高」，成功案例：開發和維護Linux操做系統的社區，成功案例每每須要嚴格的代碼複審和簽入的質量控制

缺點：「只烤火，不拾柴」，「拾到的柴火質量太差」

5.業餘劇團模式：團隊中各人扮演各人的角色

優勢：在業餘玩票、培訓的環境中，每一個人均可以嘗試不一樣角色，你們能夠比較平等地討論

缺點：在競爭性強烈、創造性要求高的團隊，不會存在完美主義的民主氣氛。

6.祕密團隊：有一些軟件項目在祕密狀態下進行，別人不知道他們具體在作什麼

優勢：團隊內部有極大的自由，較高的熱情，沒有外界的干擾。

缺點：不可能成爲廣泛模式，只會針對個別項目。

7.特工團隊：軟件團隊由一些有特殊技能的專業人士組成，負責解決一些棘手而有緊迫性的問題

優勢：效率高

缺點：對成員的知識面要求十分廣，較爲針對技術人員，不可能成爲廣泛模式

8.交響樂團模式：各司其職，想交響樂隊同樣

優勢：各司其職，重在執行

缺點：呆板

9.爵士樂模式：與交響樂模式存在至關多的對立

優勢：領導給出一個主題，而後成員們百花齊放，各顯本領，快收尾時再總結

缺點：人員不能太多

10.功能團隊模式：具有不一樣能力的同事們平等協做公共完成一個功能

優勢：效率高

缺點：每一個小組必須與其餘小組就編程規範達成一致

11.官僚模式：脫胎於大機構的組織架構，幾我的報告給一個小頭目，幾個小頭目報告給中頭目，依次向上

優勢：有助於技術的交替與互補

缺點：容易摻雜一些追名逐利，每每會使團隊效率大打折扣

（2），和小組成員討論團對模式

3，典型軟件過程模型特色

所謂軟件過程模型就是一種開發策略，這種策略針對軟件工程的各個階段提供了一套範形，使工程的進展達到預期的目的。對一個軟件的開發不管其大小，咱們都須要選擇一個合適的軟件過程模型，這種選擇基於項目和應用的性質、採用的方法、須要的控制，以及要交付的產品的特色。一個錯誤模型的選擇，將迷失咱們的開發方向。

模型名稱	技術特色	適用範圍
瀑布模型	簡單，分階段，階段間存在因果關係，各個階段完成後都有評審，容許反饋，不支持，用戶參與，要求預先肯定需求	需求易於完善定義且不易變動的軟件系統
快速原型模型	型 不要求需求預先完備定義，支持用戶參與，支持需求的漸進式完善和確認，可以適應用戶需求的變化	需求複雜、難以肯定、動態變化的軟件系統
增量模型	軟件產品是被增量式地一塊塊開發的，容許開發活動並行和重疊	技術風險較大、用戶需求較爲穩定的軟件系統
迭代模型	不要求一次性地開發出完整的軟件系統，將軟件開發視爲一個逐步獲取用廣需求、完善軟件產品的過程	需求難以肯定、不斷變動的軟件系統
螺旋模型	結合瀑布模型、快速原型模型和迭代模型的思想，並引進了風險分析活動	需求難以獲取和肯定、軟件開發風險較大的軟件系統
RUP	可改造、擴展和剪裁：能夠對它進行設計、開發、維護和發佈；強調迭代開發	複雜和需求難以獲取和肯定的軟件系統；軟件開發項目組擁有豐富的軟件開發和管理經驗

 

瀑布模型 

瀑布模型（經典生命週期）提出了軟件開發的系統化的、順序的方法。其流 程從用戶需求規格說明開始，經過策劃、建模、構建和部署的過程，最終提供一 個完整的軟件並提供持續的技術支持。

優勢：

1. 強調開發的階段性，各階段具備順序性和依賴性

2. 強調早期調研和需求分析，推遲編碼實現的觀點

3.  提供了一個摸板，這個摸板使得分析、設計、編碼、測試和支持的方法能夠 在該摸板下有一個共同的指導

 

缺點：

1. 文檔驅動，用戶沒法及時瞭解產品的狀況

2. 依賴早期調研和需求分析，很難適應在許多項目開始階段必然存在的不肯定 性。

3.  流程單一，必需要完成前一階段的任務，才能進行下一階段，開發過程當中的 成功經驗沒法用於本產品。

4.  測試在後期引入，對於系統存在的重大缺陷，若是在可執行程序評審以前沒 有被發現，將可能形成重大損失。

5. 組織龐大，人員閒置。

增量過程模型

 

增量過程模型包括增量模型、RAD 模型。

（一）增量模型 增量過程模型以迭代的方式運用瀑布模型，把軟件產品做爲一系列的增量構件來設計、編碼、集成和測試。

每一個構件由多個相互做用的模塊構成，而且可以完成特定的功能。使用增量模型時，第一個增量每每是核心功能。

 

優勢：

1.能在較短的時間內向用戶提交可完成部分工做的產品。

2.逐步增長產品功能可使用戶有充裕的時間學習和適應新產品，從而減小一個 全新的軟件可能給客戶組織帶來的衝擊。

3. 規避技術風險

4. 可並行開發構件，加快開發的進度

 

缺點：

1.  沒有考慮軟件的總體質量和長期的可維護性。

2.  大部分狀況是不合適的操做算法被採用目的爲了演示功能，不合適的開發工 具被採用僅僅爲了它的方便，還有不合適的操做系統被選擇等等。

3.  因爲達不到質量要求產品可能被拋棄，而採用新的模型從新設計

 

RAD模型

RAD  模型是一種側重於短暫的開發週期的增量軟件過程模型，它是瀑布模 型的「高速」變體，經過基於構建的構建方法實現快速開發。

開發團隊可以在很是短的時間內創造出「全功能系統」

 

優勢：

1．開發速度快，質量有保證。

2．對信息系統特別有效。

 

缺點：

1.  對於大型的可伸縮的項目，RAD 須要大量的人力資源來建立多個相對的獨立 的 RAD 團隊

2.  若是開發者和用戶沒有爲短期內急速完成整個系統作好準備，RAD 項目將會失敗。

3.  若是一個系統不能合理的模塊化，RAD 構件創建會有不少問題。

4.  若是系統需求是高性能，而且須要經過調整構件接口的方式來提升性能，不 能採用 RAD 模型

5.  技術風險很高的狀況下

 

演化過程模型

 

演化過程模型包括原型開發，螺旋模型，協同開發模型。

（一）原型開發 從需求收集開始，開發者和客戶在一塊兒定義軟件的整體目標，標識已知的需求而且規劃出須要進一步定義的區域。

而後是「快速設計」，它集中於軟件中那些 對客戶可見的部分的表示，這將致使原型的建立，並由客戶評估並進一步精化待 開發軟件的需求。

逐步調整原型使其知足客戶的需求，這個過程是迭代的。其流 程從聽取客戶意見開始、隨後是建造/修改原型、客戶測試運行原型、而後回頭 往復循環直到客戶對原型滿意爲止。

因爲這種模型可讓客戶快速的感覺到實際 的系統（雖然這個系統不帶有任何質量的保證），因此客戶和開發者都比較喜歡 這種過程模型（對於那些僅僅用來演示軟件功能的公司而言或歷來不考慮軟件質

量和不懼怕長期維護的公司而言）。

優勢：

一、能讓人（開發者或客戶）很快見到產品，有成就感。

二、能漸進地啓發客戶提出新的要求或任務。

 

缺點：

一、 沒有考慮軟件的總體質量和長期的可維護性。

二、 大部分狀況是不合適的操做算法被採用目的爲了演示功能，不合適的開發工具被採用僅僅爲了它的方便，還有不合適的操做系統被選擇等等。

三、 因爲達不到質量要求產品可能被拋棄，而採用新的模型從新設計。

 

螺旋模型

螺旋模型是一種演進式軟件過程模型，結合了原型的迭代性質和瀑布模型的系統性和可控性的特色，具備快速開發愈來愈完善軟件版本的潛力。

開發步驟：沿螺線自內向外，每旋轉一圈便開發出更爲完善的一個新的軟件版本。

例如，在第一圈，肯定了初步的目標、方案和限制條件之後，轉入右上象限，對風險進行識別和分析。

若是風險分析代表，需求有不肯定性，那麼在右下 的工程象限內，所建的原型會幫助開發人員和客戶，考慮其它開發模型，並對需求作進一步修正。客戶對工程成果作出評價以後，給出修正建議。

在此基礎上需 再次計劃，並進行風險分析。在每一圈螺線上，風險分析的終點作出是否繼續下 去的判斷。

假如風險過大，開發者和用戶沒法承受，項目有可能終止。多數狀況 下沿螺線的活動會繼續下去，自內向外，逐步延伸，最終獲得所指望的系統。

 

優勢：

1. 強調風險

2. 強調階段質量

3. 提供糾錯的機會

 

缺點：

1. 每一個階段都要提出被選方案，進行風險分析，研發週期長，效率低

2. 必需要轉業的風險分析人員的參與

 

 

 

統一過程模型

 

統一過程模型是一種「用例驅動、以體系結構爲核心、迭代及增量」的軟件 過程框架，由 UML 方法和工具支持。它是一種增量模型，定義了五個階段：

 

a、起始階段，包括用戶溝通和計劃活動，強調定義和細化用例

b、 細化階段，包括用戶溝通和建模活動，重點是建立分析和設計模型。

c、構件階段，細化模型設計，並將設計模型轉化爲軟件構件實現

d、 轉化階段，將軟件從開發人員傳遞給最終用戶，並由用戶完成 beta 測試和驗 收測試 

e、生產階段，持續地監控軟件的運行，並提供技術支持。

 

優勢：

1. 任何功能開發後就進入測試過程，及早進行驗證

2. 早期風險識別，採起預防措施

 

缺點：

1. 需求必須在開始以前徹底弄清楚，否怎有可能在架構上出現錯誤

2. 必須有嚴格的過程管理，以避免使過程退化爲原始的試→錯→改模式

3．若是不加控制的讓用戶過早接觸沒有測試徹底，版本不穩定的產品可能對用 戶和開發團隊都帶來負面的影響

四、理解並體會卡內基梅隆大學（CMU）軟件工程學院總結的TSP原則

（1）使用妥善定義的流程，流程中的每一步都是能夠重複、能夠衡量結果的。

（2）團隊的各個成員對團隊的目標、角色、產品都有統一的理解。

（3）儘可能使用成熟的技術和作法。

（4）儘可能多地收集數據(也包括對團隊不利的數據),並用數據來幫助團隊作出理性的決定。

（5）制定切合實際的計劃和承諾，團隊計劃要由負責具體執行的的角色來制定(而不是從上級而來)。

（6）增長團隊的自我管理能力。

 任務3：請與實驗三結對夥伴協商，在如下三個班級中選擇一個高質量的團隊項目案例進行協做學習，要求追蹤該團隊項目發佈全部博客做業，下載項目軟件代碼。

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

2. 2019秋福大軟件工程實踐Z班 (福州大學)

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

 用過討論決定選擇西北師範大學的的進行學習，選擇的緣由主要是，相比較來講，第一是本身學校的，學習水平差距不是很大，容易理解，相比較其餘兩個學校的本身學校的更能理解。

 

 

 

 

 

結合項目系列博客文檔，總結項目團隊成員的分工合做狀況（4分）；

這個分工看似合理，可是每一個人參與的環節不同，有的同窗除了文檔部分其餘部分，沒有參與，而有些同窗除了編碼部分爲參與文檔部分，者相對來講也是一種重心偏移的現象。

結合項目系列博客文檔，評價項目的軟件項目過程特色（TSP):

TSP把人員分紅小組領導者、開發經理、計劃經理、質量／生產經理，以及技術支持經理(注意這點和RUP的雷同）,要求各我的員嚴格記錄在軟件開發過程當中的每一步，好比程序的Bug率，使用的時間等等。

觀察該團隊項目github倉庫的源代碼文件結構，是否包含代碼規範文檔？

clone該團隊的代碼查看，發現包含代碼規範文檔。

下載團隊項目代碼，嘗試部署項目運行環境並使用軟件，描述最簡單直觀的使用體驗，找出至少兩個比較嚴重的功能性bug，在博客中展現截圖

以上是代碼運行的結果截圖。咱們討論運行發現的bug有：

（1）.在功能展現部分：請假管理模塊中，請假審覈狀態修改顯示成功，可是並無發生改變，多是功能不完整或者不健全的緣由。
（2）.在數據鏈接部分：當看到老師經過請假審覈後，學生卻沒法看到請假已經經過的狀態。
（3）.性能部分：學生能夠自行修改權限，沒有將 老師的權限展現出來，也沒有完善學生的權限。

評價該團隊項目是否值得繼續開發，並陳述理由？

項目值得繼續開發，可是此項目的完成度較低，在功能，數據鏈接，性能等部分都有或多或少的問題，建議先完善問題，再進一步作好更進一步的開發工做，學生考勤管理系統，加一些簽到打卡的功能。

 

 

 

 以上是我和夥伴兒一塊兒添加修改的管理系統，以此作個對照。

 

記錄完成《實驗四 軟件項目案例分析》各項任務實際花費的時間

 

實驗任務	花費時間
任務一	3h
任務二	2h
任務三	5.5h
任務四	1h

5，請談談完成本次做業的感覺和體會。

本次做業主要學習其餘的優秀做業爲主，而學習優秀做業的同時也是對本身的能力的一種提高和進步，看了優秀做業的代碼和博文結構內容等等，以爲本身仍是有不少須要學習的地方，本身的代碼也不夠完整，並且也沒有優秀案例的規範，如此這些都是須要在後期增強的地方，因此這次優秀案例分析也讓我瞭解到了本身的欠缺，須要在什麼地方下功夫。