| 這個作業屬於哪個課程 | https://edu.cnblogs.com/campus/fzu/SE2024/ |
|---|---|
| 這個作業要求在哪裡 | https://edu.cnblogs.com/campus/fzu/SE2024/homework/13261 |
| 這個作業的目標 | 結對共同完成跨專業資訊化方案、學習使用原型軟體設計，學會團隊協作，加強對流程圖、用例圖的記憶與學習 |
| 學號 | 102202157 |
| 結對成員學號 | 102202156 |
| 原型設計連結 | https://app.uizard.io/prototypes/XO3yaqzPoXFnjWz8xnbd |
一、閱讀《構建之法》第3章和第8章內容的學習成果
1.第3章：軟體工程師的成長
1.軟體工程師能力衡量與發展
- 個人流程：瞭解軟體工程師在團隊中的個人流程，包括從理解問題、需求到提出解決方案，與團隊成員交流確定可行方案，執行方案並在測試環境中驗證和修復缺陷，最終對結果負責等一系列環節。
能力衡量方法 - 成長維度：軟體工程師的成長體現在積累軟體開發知識、問題領域知識和經驗，理解軟體設計和軟體工程思想，提升職業技能以及取得實際成果等多個方面。
- 工作量和質量衡量：軟體開發工作量和質量可從專案大小（如程式碼行數或功能點）、花費時間、質量（如缺陷數量或 “re - work” 次數，但 “re - work” 與最終質量不成正比）以及是否按時交付等維度衡量。穩定、一致的交付時間是衡量員工能力的重要方面，工程師不能按時交付可能源於想解決通用問題而非滿足當前需求。
- 團隊期望：在團隊環境中，工程師應具備交流、按時交付、接受並勝任團隊角色、投入團隊活動、遵循團隊流程、做好準備以及理性工作等能力。
2.思維誤區認知
認識到軟體工程師常見的思維誤區，如分析麻痺（過度關注細節和依賴關係導致無法開始工作）、不分主次（試圖解決所有依賴問題而忽視 “足夠好” 的方案）、過早最佳化（過度關注區域性最佳化而忽略全域性重要性）以及過早擴大化 / 泛化（過度追求軟體的通用性而不考慮實際情況）。
3.職業發展規劃 - 職業態度分級：瞭解軟體工程師可能持有的不同職業態度，包括臨時的寄託或工作（低動力、低技能）、工作（作為掙錢營生）、職業（有規劃和道德）、投身的事業（長期承諾）以及理想的呼喚（追求改變世界）。
發展路徑探索 - 考級：中國的軟體工程師考級途徑包括計算機等級考試和全國計算機技術與軟體專業技術資格考試等，同時瞭解到這些考級的利弊，以及一些公司和行業協會提供的職業認證專案。
- 企業模式：不同企業或專家提出的職業發展模式，如 Steve McConnell 版本的知識領域和能力階段劃分，微軟公司的軟體工程師職業等級設定，以及工程師自我評估時需結合行業特點考慮在不同方面追求的專業程度。
4.技能本質反思
理解技能的反面是 “Problem Solving”，透過面試和魔方技能的例子，明白不斷練習解決低層次問題，才能進階到解決更高層次問題，以及技能的不同層次劃分與教育理論中的舒適區、學習區、恐慌區的關聯。
第8章：需求分析
- 軟體需求的全面剖析
- 需求獲取與管理的流程
從獲取和引導需求入手，強調軟體團隊要從多方面挖掘需求，包括利益相關者（使用者、顧客、市場分析者等多類角色）的需求，以及來自商業模式、技術團隊自身等不同源頭的需求。
接著是分析和定義需求，對獲取的需求進行規整和量化，考慮實現期限、成本、優先順序和收益等要素。
驗證需求環節透過與利益相關者的多種形式溝通來確保對需求的準確理解。
強調在軟體生命週期中持續管理需求，因為需求會隨技術發展、團隊能力提升等因素而改變。 - 需求型別的多維劃分
明確了對產品功能性的需求、對產品開發過程的需求、非功能性需求（服務質量需求）以及綜合需求等不同型別，強調軟體團隊和客戶代表需在需求階段清晰定義這些需求。
- 使用者調研方法的深入探討
- 多種調研方法介紹
焦點小組：組織相關人員討論，但存在受多種因素影響導致結果可能不準確的問題。
深入面談：一對一深入瞭解使用者，但效果取決於採訪者能力，可用於軟體可用性研究。
卡片分類：有助於統一需求認識和定義軟體架構等。
使用者調查問卷：設計有講究，要避免常見錯誤，問題形式多樣。
使用者日誌研究：要求使用者記錄行為，需注意隱私保護和使用者自律。
人類學調查：透過和使用者 “同吃同住同勞動” 瞭解需求。
眼動跟蹤研究：研究使用者瀏覽規律以最佳化資訊展示。
快速原型調研：快速獲取使用者反饋。
A/B 測試：對產品不同設計進行測試，但有執行成本等弱點。 - 方法的綜合比較與反思
介紹了這些方法在態度和定量上的分野，提醒過度依賴資料可能帶來問題，如 Google 視覺設計主管的案例。
- 競爭性需求分析的關鍵框架
- 創新導向的需求分析思路
區分改良型和顛覆型創新，批判 “二拍” 式的錯誤需求分析做法，強調實用且創新的專案需求分析。
詳細闡述 NABCD 模型，包括需求（N）、做法（A）、好處（B）、競爭（C）和推廣（D）各個環節的要點和作用。 - 競爭產品的比較分析
透過與競爭對手比較，明確我方產品在滿足使用者需求方面的優勢和劣勢，為產品定位提供依據。
- 功能定位與優先順序的策略
- 功能分類與核心價值判斷
根據功能特點劃分為殺手功能 / 外圍功能、必要需求 / 輔助需求四個象限，以英漢詞典軟體為例說明不同象限功能的特點和地位。
強調資源應傾斜到能產生差異化和獨特使用者價值的地方，針對不同象限功能提出維持、抵消、最佳化、差異化和不做等處理策略。 - 功能與使用者滿意度的動態關係
探討不同型別功能（核心需求相關、衛生屬性、讓使用者驚喜）與使用者滿意度的關係，以及這些功能型別隨時間推移的變化，如手機多點觸控功能的演變。
- 計劃和估計的重要方法與技巧
- 目標、估計和決心的概念區分
透過軟體專案計劃中對時間估計的重要性，清晰區分目標、估計和決心，以歷史上 “大躍進” 為例說明混淆三者的危害，闡述軟體專案估計困難的原因。 - 提高估計能力的實用方法
介紹透過 Wideband Delphi 方法找出估計背後假設的步驟，以及參考前人經驗和採用快速原型法提高估計能力的思路。
提及軟體工程師的經驗公式，介紹影響軟體成本的多種因素（產品、平臺、人員、專案等方面）。 - 不同估計方法的靈活運用
包括自底向上、回溯等常規方法，以及敏捷開發中的估計撲克牌、划拳估計法、T 恤尺寸法等快速粗粒度估計方法，強調敏捷開發中應根據實際情況調整進度，“猜得準” 不是首要目標。
- 分而治之（WBS）的專案分解方法
介紹 WBS 方法的核心要點，即從最終產品開始逐步分解專案為可操作的工作，明確做好 WBS 的關鍵要點，如子節點覆蓋、不相互覆蓋、葉子節點合適以及從結果出發構建等。
解答關於 WBS 的常見問題，如文件和工作計劃的處理、開發活動的計入以及細枝末節的處理方式等。
NABCD模型
NABCD 模型是一個用於分析需求和說服別人創新想法可行性的有效方法
- N（Need，需求）
創意要解決使用者的需求，這個需求可能是明確的，也可能是潛在的。瞭解使用者需求可透過假設使用者需求已被滿足，檢視使用者反饋和不滿，以及找到 “不消費的使用者”，瞭解他們不使用相關 App 的原因等方式。同時要充分了解使用者的痛苦和對現有軟體、服務的不滿意之處，注意使用者可能不瞭解顛覆型創新，開發者也不應侷限於某種產品形式。 - A（Approach，做法）
找到需求後，要有獨特的招數來解決使用者的痛苦。這些招數不僅包括技術方面，還可以是商業模式、地域、人脈、行業或成本等方面的優勢。 - B（Benefit，好處）
獨特的做法要能給客戶 / 使用者帶來好處。當使用者已有解決方案時，要考慮新產品的優勢能否讓使用者願意遷移，包括考慮使用者遷移成本，如對硬體、網路等方面的要求。 - C（Competitors，競爭）
要了解市場競爭情況，包括競爭對手的先發優勢或後發優勢。透過分析與競爭對手在滿足使用者需求方面的差異，明確我方優勢和劣勢。 - D（Delivery，推廣）
要考慮如何把創新產品交到使用者手中，即產品的推廣方式。可以透過做廣告、公關活動、鼓勵有影響力的使用者介紹、設計高質量的功能讓使用者口口相傳等手段，還可以在產品本身設計相關功能，如把使用者生活中的好友拉進產品或在交流中自然宣傳產品。 - NABCD 模型優點
全面系統：涵蓋從需求到推廣各環節，邏輯清晰，引導團隊全面、系統思考產品，確保各環節不遺漏，提高產品成功率。
使用者導向：以使用者需求為核心，強調產品對使用者的價值，提升使用者滿意度和市場接受度。
競爭意識：促使團隊分析競爭環境，制定針對性策略，適應市場變化。 - NABCD 模型缺點
應用複雜：資訊收集難，分析繁瑣，對團隊知識經驗要求高。
主觀影響：需求和競爭分析易受主觀判斷左右，導致偏差。
動態不足：是靜態框架，難以及時反映市場動態變化。
方案設計
二、介面原型設計
1.原型設計演示圖
| 原型設計工具 | uizard |
|---|---|
| 原型連結 | https://app.uizard.io/prototypes/XO3yaqzPoXFnjWz8xnbd |
2.流程圖
3.用例圖
三、主要介面及功能顯示
1.註冊頁面
2.登陸頁面
3.功能頁面顯示
四、資訊化設計方案
需求分析
- 獲取和引導需求
利益相關者：有跨專業合作需求的學生、不同專業的老師（可能作為介紹人或資源提供者）。
需求挖掘：學生需要一個平臺來尋找跨專業合作伙伴，解決合作機會有限的問題；需要一種方式來協調不同專業學生在時間安排、專案目標和溝通方式上的差異；需要資源支援跨專業專案的持續發展。 - 分析和定義需求
需求內涵：開發一個跨專業專案合作平臺，具有專案釋出與搜尋功能，方便學生找到合適的合作伙伴；提供專案管理工具，用於協調時間、目標和溝通；整合校園資源，為專案提供支援。
量化需求
實現期限：可根據開發難度和資源情況設定合理期限
成本：考慮開發成本、伺服器維護成本等，可進行成本估算。
優先順序：專案釋出與搜尋功能優先順序較高，其次是專案管理工具，最後是資源整合。
收益：提高學生跨專業合作的機會和效率，促進學生綜合能力提升，對學校的學術和創業氛圍有積極影響。 - 驗證需求
透過與學生代表、老師進行訪談或問卷調查，瞭解他們對平臺功能的期望和建議，驗證需求的合理性和可行性。
設計與實現
功能設計
- 核心功能
使用者註冊與登入：支援學生和老師註冊登入，區分不同角色許可權。
專案釋出與搜尋：學生可以釋出專案需求，包括專案名稱、簡介、所需專業技能、時間安排等資訊；其他學生可以根據關鍵詞搜尋專案。
合作伙伴匹配：根據專案需求和學生個人資料，自動匹配可能的合作伙伴，並提供推薦列表。
專案管理：提供專案時間管理、目標設定、任務分配、溝通工具（如論壇、即時通訊）等功能。
資源整合：整合學校的實驗室資源、學術資料、創業基金等資訊，供專案團隊申請和使用。
介面設計：設計簡潔、易用的介面，符合學生和老師的使用習慣。 - 測試與釋出
測試計劃
制定詳細的測試計劃，包括單元測試、整合測試、系統測試和使用者體驗測試。
對各個功能模組進行測試，確保功能的正確性和穩定性。
釋出與推廣
選擇合適的時間釋出平臺，如在新學期開始或學校舉辦創業活動期間。
透過學校官方網站、學生會宣傳、老師推薦等方式進行推廣。 - 運營與維護
使用者支援
設立使用者反饋渠道，及時處理使用者在使用過程中遇到的問題。
平臺更新
根據使用者反饋和需求變化，定期對平臺進行更新和最佳化。
資料管理
對使用者資料、專案資料和資源資料進行安全管理和備份。
五、PSP表格
| PSP 階段 | 具體任務 | 時間估計（小時） | 實際時間（小時） |
|---|---|---|---|
| 計劃 | 確定學習《構建之法》相關章節的目標和計劃 | 1 | 1 |
| 需求分析 | 分析軟體工程師成長和需求分析相關內容 | 3 | 3.5 |
| 設計 | 構思介面原型設計方案 | 2 | 2.5 |
| 開發 | 建立介面原型、流程圖和用例圖 | 4 | 4.5 |
| 測試 | 檢查介面原型和功能設計的合理性 | 2 | 2 |
| 報告 | 撰寫學習成果總結 | 2 | 2 |
六、交流過程
七、總結
- 一、作業的意義
本次作業的意義在於針對大學校園內跨專業合作的實際難題，設計並構想了一套資訊化解決方案。透過構建一個集專案釋出、團隊組建、協作溝通、資源共享於一體的平臺（可以是軟體、APP或小程式），我們旨在打破傳統合作模式的侷限，為有志於跨專業合作的學生提供一個高效、便捷、安全且隱私保護的合作環境。這不僅有助於提升學生的綜合能力，拓寬知識面，還能有效促進不同專業之間的交流與融合，推動校園內創新專案的孵化與發展。 - 二、在本次結對完成作業中我的收穫
知識掌握與深化：在作業過程中，我深入學習了軟體設計、使用者體驗、資料安全等方面的知識，特別是關於如何設計一款既實用又符合使用者需求的產品。同時，我也對跨專業合作的重要性和挑戰有了更深刻的理解。
團隊協作能力提升：與搭檔緊密合作，共同完成了從需求分析、方案設計到原型製作的全過程。這個過程中，我們學會了如何有效溝通、分工協作以及相互支援，這對於我未來的學習和工作都將產生積極影響。
創新思維激發：在解決具體問題的過程中，我們不斷嘗試新的思路和方法，努力使設計方案更加完善。這種創新思維的培養對於我個人的成長具有重要意義。 - 三、掌握的知識
軟體設計原則：掌握了使用者中心設計、簡潔性、一致性等基本原則，確保設計出的產品既美觀又實用。
使用者體驗最佳化：學習瞭如何透過使用者調研、原型測試等方法來最佳化產品體驗，提高使用者滿意度。
資料安全與隱私保護：瞭解了資料加密、訪問控制等安全措施的重要性，並學會了如何在設計中融入這些元素以保護使用者隱私。 - 四、自己的不足
在作業完成過程中，我也發現了自己的一些不足之處。例如，在需求分析和方案設計階段，我有時過於關注細節而忽略了整體架構的合理性；在團隊協作中，我有時過於堅持己見而未能充分聽取搭檔的意見。為了克服這些不足，我計劃在未來的學習和工作中更加註重全域性思維的培養和團隊溝通能力的提升。 - 五、團隊的配合重要性
本次結對完成作業的經歷讓我深刻認識到團隊合作的重要性。一個優秀的團隊能夠集思廣益、優勢互補，共同面對挑戰並找到最佳解決方案。在作業過程中，我們互相學習、互相幫助，共同克服了一個又一個難題。這種緊密的合作不僅提高了我們的工作效率，也增強了我們的團隊凝聚力。因此，在未來的學習和工作中，我將更加註重與團隊成員的溝通和協作，努力成為一個更加優秀的團隊成員。