聚焦重點，系統為提供服務，而服務是從需求而來，所以分析需求即為重點
ex. 咖啡廳的需求為何？
咖啡廳提供服務有
- 餐點
- 設備
問：咖啡機也是組成元素，為何沒列入？
因為重點在Service，咖啡機有如framework(基礎建設),很重要，但不會自己做，將重點放在滿足需求，而不是自己再造輪子
三大構面
依使用者角度不同，分析出來的需求也不同
PG Skill
分析 (SA )
著重功能、需求
設計
內部結構元素
實作
Infrastructure
當三者有技術衝突時，靠Architect講合
PM 人、客戶的溝通、時程的掌握
Ch1. 軟體開發方法論(Methodology)
1.1.1 方法論的組成元素 - 溝通語言與開發流程(Process)
軟體開發會有PM,Architect, SA/D, Programmer組成的團隊，在一定的時程內、運用有麥的資源，來達成有效率的系統開發。如果做有效率的專案控管，「溝通」與「開發製程」即為影影專案成敗的最重要關鍵 。
- 開發流程: Waterfall, RUP, XP, agile
因project的性質、團隊素質不同，不可能適用每次的project - Notation: UML
統一溝通的語言，讓PM,SA/D, Architect, Programmer有共同的語言
1.1.2 什麼是有效的開發流程
軟體開發失敗原因，不外乎
- 溝通的障礙
- 無法處理需求的變更
- 脆弱的架構
- 難處理的複雜性(團隊合作造成的複雜 ex.維護別人的code)
- 不一致的需求、設計和實作 (分析文件太多，不易維護)
- 無法分析並克服風險 (讓風險儘早發現)
- 無法建立標準化的測試環境
最佳實務
- 以反覆式開發方式去開發軟體
每個開發流程的目的都是期望在專案的四大變數：成本、品質、時程與規模達成一定的均衡
但前三樣由客戶決定，能夠控制的只有「規模」，將規模分階段完成 - 需求的變動管理
- 以元件為基礎(Component-based)的架構
- 用視覺化方式製作軟體模型(Visually Model Software)
- 持續驗證軟體品質
軟體系統的專案開發，特別的是，需求往往不明確，更何況是經常處於變動中，所以導
致專案的範圍與規模無法界定，連帶也引起時程無法估算。能做的只有將變動抑制或收斂在某一程度可被控管的範圍
專案四大變數：成本、時程、品質與規模中，前兩樣都控制在客戶，能夠控制的只有「規模」=> 將規模分階段完成 ( I & I)
1.1.4 典型開發模式 - 瀑布式 (Waterfall)
因軟體「變動無常」，所以想要「凍結」，再開發出系統，如同建築工程，但軟體開發與建構大樓的差異在於瀑布式兩個基本假設點
- 需求會固定不變
- 更多的使用者
- IKIWIS效應(I'll Know It When I See It)
只有到實作完成，有了畫面，使用者才能知道他是否為他要的 - 無法捕抓需求足夠的細節和精確度
- 紙上談兵 - 從設計圖就可以導出正確的實作 (Implementation)
軟體工程的基礎理論很薄弱而且缺乏瞭解，探索的方法也非常糙。直到實作時，發現設計有嚴重瑕疵，造成系統崩潰。
1.1.5 I&I(Iteration and Incremental)的開發模式
Iteration就是將整個專案生命周期，分成好幾個迷你專案，每個專案有自己的開發循環，包括分析、設計、實作與測試。
有多迷你？
以「使用案例(Use Case)」或「功能點(Functioinal Point)」為功能單位，大約一星期，最晚不超過兩個星期。每個功能單位，依複雜度切為2~5個Iteration，從第一固Iteration對框奇目標的建立，然後逐漸加入細節，從低精確度往高精確度，到最終完成定案的產出。
好處？開發時間會縮短？
其實沒有，因為重點在提早揭露風險(Risk)，而儘早處理掉。開發人員可在一個Iteration看到具體成果，從中得到Feedback，隨時回頭修正，時間不會離得太遠，而不會等到整個系統完成了，使用者才說這不是我要的，或是架構要調整。
優點：
- 提早降低風險
- 較早能具有可視性(Visible)的進展(Progress)。
- 較早能得到回饋，較可以得到使用者的保證(engagement)及適應性(adaptation)由此再精緻由此再精緻(refine)系統的設計，以更進一步契合使用者的需求。
- 增加團隊的信心，並且可以一直持續學習。
- 產品的整體品質較佳
沒有留言:
張貼留言