201871010125-王玉江 實驗四 團隊作業1：軟件研發團隊組建
| 項目 | 內容 |
|---|---|
| 課程班級博客鏈接 | https://edu.cnblogs.com/campus/xbsf/2018CST |
| 這個作業要求鏈接 | http://www.rzrgm.cn/nwnu-daizh/p/14660499.html |
| 團隊名稱 | 孤寡老人 |
| 團隊的課程學習目標 | 1.建立團隊目標，培養團隊意識 2.在團隊隊長的領導下盡可能將圖案對每位組員的能力最大化 3.各組員在交流過程中盡可能地提出最優方案 |
| 這個作業在哪些方面幫助團隊實現學習目標 | 1.各組員之間相互配合提高了項目完成效率 2.組員之間的交流為項目的實現提供了更多的可能性 |
| 團隊博客鏈接 | http://www.rzrgm.cn/wwwsy/p/14683680.html |
-
一、實驗目的與要求
- （1）實驗三作業互評。
- （2）組建軟件項目研發團隊。
-
二、實驗內容與步驟
-
任務1：瀏覽班級博客園中提交《實驗三 軟件工程結對項目》作業，任選一個你認為完成質量較高的小組項目成果，繼續以實驗三結對學習方式完成以下任務，具體要求如下：
-
（1）對博文作業進行閱讀，并結合評分要求進行評論，評論要點包括：博文結構、博文內容、博文結構與PSP中“任務內容”列的關系、PSP中“計劃共完成需要的時間”與“實際完成需要的時間”兩列數據的差異化分析與原因探究，給出這個結對小組在進度計劃方面可以提高的具體建議。將以上評論內容發布到博客評論區。
- 評論博客鏈接：http://www.rzrgm.cn/20000910090X/p/14652372.html
- 評論內容：
-
-
-
（2）克隆任務3項目源碼到本地機器，閱讀并運行代碼，找出項目代碼的5個以上bug，參照《現代軟件工程—構建之法》4.4.3節核查表復審項目代碼并記錄。
-
| 說明 | 內 容 |
|---|---|
| 1.概要說明 | 代碼能符合需求和規格說明么？ |
| 代碼設計是否有周全的考慮？ | 代碼設計很周全 |
| 代碼可讀性如何？ | 可讀性較好 |
| 代碼容易維護么？ | |
| 代碼的每一行都執行并檢查過了嗎？ | 已檢查 |
| 2．設計規范部分 | 設計是否遵從已知的設計模式或項目中常用的模式？ |
| 有沒有硬編碼或字符串/數字等存在？ | 沒有 |
| 代碼有沒有依賴于某一平臺，是否會影響將來的移植？ | 代碼在pycharm上運行，但不依賴平臺 |
| 開發者新寫的代碼能否用已有的Library/SDK/Framework中的功能實現？在本項目中是否存在類似的功能可以調用而不用全部重新實現？ | 存在類似功能可以調用 |
| 有沒有無用的代碼可以清除？ | 沒有 |
| 3．代碼規范部分 | 修改的部分符合代碼標準和風格么? |
| 4．具體代碼部分 | 有沒有對錯誤進行處理？對于調用的外部函數，是否檢查了返回值或處理了異常？ |
| 參數傳遞有無錯誤，字符串的長度是字節的長度還是字符（可能是單/雙字節）的長度，是以0開始計數還是以1開始計數？ | 無 |
| 邊界條件是如何處理的？Switch語句的Default是如何處理的？循環有沒有可能出現死循環？ | 未發現死循環 |
| 有沒有使用斷言（Assert）來保證我們認為不變的條件真的滿足？ | 沒有 |
| 對資源的利用，是在哪里申請，在哪里釋放的？有沒有可能導致資源泄露？有沒有可能優化？ | 沒有資源泄露 |
| 數據結構中是否有無用的元素？ | 沒有 |
| 5．效能 | 代碼的效能（Performance）如何？最壞的情況是怎樣的？ |
| 代碼中，特別是循環中是否有明顯可優化的部分？ | 沒有 |
| 對于系統和網絡調用是否會超時？如何處理? | 不會超時 |
| 6．可讀性 | 代碼可讀性如何？ |
| 有沒有足夠的注釋？ | 有充足的注釋 |
| 7．可測試性 | 可測試 |
- 閱讀《現代軟件工程—構建之法》第12章內容，完成以下分析任務：
? A. 體驗任務3實現軟件功能，簡要描述軟件的使用過程，上傳使用軟件的照片；
B. 總結任務3要求的功能軟件解決了嗎？軟件在數據量/界面/功能上各有什么優缺點？對該軟件產品功能有什么改進意見？
數據處理簡單有效，值得學習，但是界面友好程度不足，遺傳算法不夠成熟；
改進界面的友好程度，進一步改進遺傳算法，對于每個算法的時間復雜度較大，很是占用資源，希望可以改進；
? C. 從職業、學歷、年齡、專業、愛好、收入等方面概括任務3所研發軟件產品的典型用戶群特征，他們表面需求，潛在需求是什么？
職業：算法初學者
學歷：大學二年級
專業：計算機相關專業
收入：無要求
表面需求：D{0-1}KP算法求解以及前端設計；
任務2：團隊組建
1、在實驗三結對基礎上，結對小組兩兩自由組合，組建軟件項目研發團隊；申請開通團隊博客，點擊以下鏈接提交團隊信息，將團隊博客加入到班級博客；
2、閱讀《現代軟件工程—構建之法》第5章內容
3、團隊建設
-
團隊建設
-
隊名：孤寡老人
-
宣言：關愛孤寡老人，共創和諧社會
-
團隊成員組成
成員學號末五位 成員*名 個人博客地址 備注 10125 *玉江 http://www.rzrgm.cn/wswyj/ PM、開發、測試 10124 *生濤 http://www.rzrgm.cn/ws-t/ 文檔、測試 -
團隊成員風采
-
- 成員介紹
| 姓名 | 風格 | 擅長技術及編程興趣 | 承擔的軟工角色 |
|---|---|---|---|
| 王玉江 | 能力突出，性格低調 | 擅長C,python | PM、開發 |
| 王生濤 | 善于編寫文檔，PPT制作 | 擅長C,python | 文檔、測試 |
MSF的9點基本原則和團隊成員績效
MSF（Microsoft Solution Framework）：微軟解決方案框架，也就是微軟推薦的軟件開發方法。
9點基本原則
1、推動信息共享與溝通（Foster open communications）
2、為共同的遠景而工作（Work toward a shared vision）
3、充分授權和信任（Empower team members）
4、各司其職，為項目共同負責（Establish clear accountability and shared responsibility）
5、交付增量的價值（Deliver incremental value）
6、保持敏捷，預期和適應變化（Stay agile,expect and adapt change）
7、投資質量（Invest in quality）
8、學習所有的經驗（Learn from all experiences）
9、與顧客合作（Partner with internal and external customers）
任務三
| PSP | 任務內容 | 計劃共完成需要的時間（min） | 實際完成需要的時間（min） |
|---|---|---|---|
| Planning | 計劃 | 15 | 13 |
| Estimate | 估計這個任務需要多少時間，并規劃大致工作步驟 | 15 | 13 |
| Development | 開發 | 110 | 130 |
| Analysis | 需求分析（包括學習新技術） | 10 | 10 |
| Design Spec | 生成設計文檔 | 10 | 10 |
| Design Review | 設計復審（和同事審核設計文檔） | 10 | 15 |
| Coding Standard | 代碼規范（為目前的開發制定合適的規范） | 10 | 10 |
| Design | 具體設計 | 10 | 15 |
| Coding | 具體編碼 | 20 | 30 |
| Code Review | 代碼復審 | 20 | 15 |
| Test | 測試（自我測試，修改代碼，提交修改） | 20 | 20 |
| Reporting | 報告 | 35 | 45 |
| Test Report | 測試報告 | 15 | 15 |
| Size Measurement | 計算工作量 | 8 | 10 |
| Postmortem & Process Improvement Plan | 事后總結，并提出過程改進計劃 | 12 | 20 |
浙公網安備 33010602011771號