201971010101-阿麗米拉實驗四軟體研發團隊組建

阿新 • • 發佈：2022-04-09

專案	內容
課程班級部落格連結	2019級卓越班
作業要求連結	實驗四
團隊名稱	待宰的高羊
我的課程學習目標	1. 執行其他小組實驗三的專案，並進行評價 2. 對比他人的軟體專案，總結反思自己的不足，並加以修正 3. 繼續熟練github的相關操作 4. 掌握部落格園建立團隊的方法 5. 學會團隊合作，加深元件交流
這個作業在哪些方面幫助我實現學習目標	1. 深深感悟到自己的不足，需要在今後多加努力 2.明白了團隊合作開發對軟體專案的幫助 3. 理解了一個團隊中目標統一的重要性
團隊部落格連結	待宰的高羊

實驗內容

任務一：瀏覽班級部落格園中提交《實驗三軟體工程結對專案》作業，任選一個你認為完成質量較高的小組專案成果，繼續以實驗三結對學習方式完成以下任務，具體要求如下：

（1）對博文作業進行閱讀，並結合評分要求進行評論，評論要點包括：博文結構、博文內容、博文結構與PSP中“任務內容”列的關係、PSP中“計劃共完成需要的時間”與“實際完成需要的時間”兩列資料的差異化分析與原因探究，給出這個結對小組在進度計劃方面可以提高的具體建議。將以上評論內容釋出到部落格評論區。

評論已提交。

（2）克隆任務3專案原始碼到本地機器，閱讀並執行程式碼，參照《現代軟體工程—構建之法》4.4.3節核查表複審專案程式碼並記錄。

程式碼核查表

專案部分	完成情況
概要部分
程式碼能符合需求和規格說明麼？	是
程式碼設計是否有周全的考慮？	是
程式碼的可讀性？	簡單易讀
程式碼是否容易維護？	易維護
程式碼的每一行是否都執行並檢查過？	是
設計規範部分
設計是否遵從已知的設計模式或專案中常用的模式？	是
有沒有硬編碼或字串/數字等存在？	沒有
程式碼有沒有依賴於某一平臺，是否會影響將來的移植？	否
開發者新寫的程式碼是否用已有的Library/SDK/Framework中的功能實現？在本專案中是否存在類似的功能可以通過呼叫而不用全部重新實現？	否
有沒有無用的程式碼可以清除？	否
程式碼規範部分
修改的部分符合程式碼標準和風格麼？	符合
具體程式碼部分
有沒有對錯誤進行處理？對於呼叫的外部函式，是否檢查了返回值或處理了異常？	已處理
引數傳遞有無錯誤，字串的長度是位元組的長度還是字元的長度，是從0開始計數還是從1開始計數	無錯誤
邊界條件是如何處理的？switch語句和default分支是如何處理的？迴圈有沒有可能出現死迴圈？	沒有出現死迴圈
有沒有使用斷言來保證我們認為不變的條件真的得到滿足？	否
資料結構中有沒有用不到的元素？	否
效能
程式碼的效能如何？最壞的情況是怎麼樣的？	效能高
程式碼中，特別是迴圈中是否有明顯可優化的部分？	有
對於系統和網路的呼叫是否會超時？如何處理？	否
可讀性
程式碼可讀性如何？有沒有足夠的註釋？	程式碼有較好的可讀性
可測試性
程式碼是否需要更新或建立新的單元測試？	否

（3）閱讀《現代軟體工程—構建之法》第12章內容，完成以下分析任務：

A. 體驗任務3實現軟體功能，簡要描述軟體的使用過程，上傳使用軟體的照片；
- 對方小組所使用python完成此次的作業，將對方的專案clone到本地後，開啟PyCharm後的部分結果

（1）GUI介面

（2）散點圖

B. 總結任務3要求的功能軟體解決了嗎？軟體在資料量/介面/功能上各有什麼優缺點？對該軟體產品功能有什麼改進意見？
- 要求的功能大體上實現了，資料的讀取很清晰，正確率也很成功，介面雖然直觀清晰，但是缺少一點色彩的美感，排版非常整齊、功能實現齊全。

優點	缺點
1.資料成功讀入，可以實現基本功能。 2.介面簡潔，排版整齊。 3.合作成功，功能克服困難。	介面缺少色彩的美感。

C. 從學歷、年齡、專業、愛好、收入等方面概括實驗三任務3所研發軟體產品的典型使用者群特徵，他們表面需求，潛在需求都是什麼？

職業	學歷	年齡	專業	愛好	收入	表面需求	潛在需求
學生和從事軟體開發的人	一般為大專及以上	18-35	計算機專業	愛好計算機程式設計、網站開發、偏愛演算法研究	2000-5000	解決揹包問題	學習計算機方面的知識，提高自己的程式設計能力

（4）經過（1）-（3）的工作，你們一定有充分的理由給評價作業選擇一個結論:a) 非常不推薦 b) 不推薦 c) 一般 d) 好，不錯 e) 非常推薦

專案認真完成，符合專案所有要求；非常推薦。

（5）結合（1）—（3）的評論體會，迭代改進本小組實驗三的任務3。

本小組任務3迭代改進要點說明，專案倉庫的Fork、Clone、Push、Pull request、Merge pull request資料變化情況如下

任務二：團隊組建

團隊名稱：待宰的高羊
團隊成員組成

成員學號	成員姓名	個人部落格地址	備註
201971010111	何晨澤	部落格	PM
201971010110	高楊	部落格
201971010160	謝家俊	部落格
201971010101	阿麗米拉	部落格

成員風采

成員姓名	風格	擅長技術	程式設計興趣	希望的承擔的軟工角色	宣言
何晨澤	求是	擅長主流程式語言，演算法、前端等	對演算法、資料探勘等方面興趣較高	PM（開發）	我要上浙江大三本
高楊	知術欲圓，行旨須直	C/C++	前端、Python	測試	好好學習，天天向上
謝家俊	積極思考，擅於發現	Web前端開發	喜歡前端開發	開發	堅持不懈，加油
阿麗米拉	喜歡動手，善於查詢	C	前端開發	文件	知識就是力量

請閱讀《現代軟體工程—構建之法》第7章，理解MSF的9點基本原則
- 1.推動資訊共享與溝通（Foster open communications）
所有的資訊都保留，並公開。
- 2.為共同的遠景而工作（Work toward a shared vision）
這個目標必須是明確的，沒有二義性；這個目標不是當前就能達到，必須是通過努力才能達到的；這個目標不是空泛的，它應該對專案成員每天的工作都有指導作用。每天你來上班，如果發現你做的事情對專案的遠景沒有幫助，你應該和老闆提出來。
- 3.充分授權和信任（Empower team members）
平等協作---成員之間、團隊之間是平等協作的關係；充分授權給團隊和成員。
- 4.各司其職，對專案共同負責（Establish clear accountability and shared responsibility）
無責任的旁觀者和有重大責任的當局者的看法自然是不一樣的。對此事負責的角色要自己拿主意。
- 5.重視商業價值（Focus on delivering business value）
如果你還沒有能說清楚你的產品解決了什麼問題，為誰解決問題，為什麼你的產品會解決這些問題，以及客戶怎樣付錢讓你解決問題，那你就不應該貿然創業。
- 6.保持敏捷，預期變化（Stay agile,expect change）
軟體工程，唯一不變的是變化。所以乾脆別幻想客戶的需求會在第一-時刻很明確，然後保持不會變。但要注意，我們是預期變化，不是期望變化。
- 7.投資質量（Invest in quality）
不是質量第一，而是解決使用者的問題第一。
- 8.學習所有的經驗（Learn from all experiences）
把經驗總結出來；分享經驗。是為了：讓團隊成員從別人的成果和失敗的例子中學到東西；幫助新專案重複以往成功的做法；培育團隊總結的習慣和“批評與自我批評”的文化。
- 9.與顧客合作（Partner with internal and external customers)
MSF強調產品團隊與顧客的交流與合作，並不是產品團隊拿到合同之後，就閉門造車，直到產品完成才告訴使用者，給他們一個驚喜。
組建團隊企業微信群