軟體需求溝通
Cynefin Framework => 2-2 需求分層 => 2-3 設計問題的產生因子 (Generators of design problems) => 2-5 穀倉效應
第2章 核心觀念 軟體需求
值得一看 - 單元三, 單元四 - 單元五, 單元六 - 單元七, 單元八
單元一
不曉得為什麼會提出跨職能團隊的說明, 脈絡不知從何而來
單元二
所用的問題分類框架感覺有點高大上, 理論, 不曉得實務上真正的情況
單元三
值得一看, 概念上就是External和Internal的感覺;
單元四
展示了單元三的實際範例, 先分類再分層的技巧可以學起來並套用在個人資訊系統v2關於任務的部分 單元三和單元四可以放在一起看
單元五
主要討論在時間和資源有限的條件下, prioritize something 的方法論, 透過設計問題的分層 (Hierarchy of design problems)
單元六
討論需求分層的各層之間對於軟體架構可能會造成的影響, 單元五和單元六可以放在一起看
單元七
討論功能性需求和非功能性需求的特性, 如何從需求去識別背後的技術風險, 相對單元三和四，覺得清楚的程度相對較低
功能性需求指定了軟體在某些輸入下，應該如何工作和表現。功能性需求可以是對輸入的內容、輸出的內容、或是行為操作等等的功能修改。 非功能性需求是那些為良好用戶體驗 (Good User Experience) 奠定基礎的需求。它保證了軟體的質量屬性並確保功能的有效性 從需求識別技術風險: - 整合點 - 容錯、可維護性、可靠性 - 持續不能中斷 - 可靠性 - 時間頻率 - 效能、準時、可靠 - 數量規模 by 數量, 處理數量, 地區的變化 - 可維護性, 效能, 可靠性 - 類別擴充 - 可維護性
單元八
從三個角度定義非功能性需求 - 業務容量要求 - Throughput: 單位時間內完成的次數 - Latency: 一次要花多久時間 - Concurrent - 用戶體驗 - 災難回復
Concurrent = Throughput * Latency
例子1: 商業目標是每個月活躍用戶 100 萬人, 伺服器吞吐量 用戶數量 => 用戶的每秒要完成的請求量 => 伺服器吞吐量 平均分散 vs 尖峰流量校正
例子2: 要求某件事在多久時間內完成, 計算排隊流程的容量 用戶的廣告送審後在24小時內完成 用戶發出忘記密碼要求後，要在3分鐘內發送認證簡訊
排隊數 = 處理速率 * 允許延遲 = 2 (次/分鐘) * 3(分鐘/次) = 6 3分鐘 => 處理速率 2 (次/分鐘) => 排隊數 6 3分鐘是已知，要能夠推估出未知的處理速率 2 (次/分鐘)和 排隊數 6
當排隊數過長的話，可以 - 提升處理效率 - 降低排隊壓力(透過priority)
例子3: 重要步驟數值量測 計算重要步驟的平均值，最大值以及最小值 計算重要步驟間花費的時間，設置警報
單元九
分享需求溝通討論過程中常見的承諾，衝突和和壓力的經驗和應對, 參考用，不一定要全信
第3章 核心觀念 軟體架構
值得一看 - 單元二 - 單元三 - 單元四 - 單元六
單元一
架構本質為元件之間的切分與溝通，給出內聚和耦合的說明，但小心迷失在其中
單元二
提到分層架構(Layers)與其優缺點，開放層(遊樂園的快速通道) 插件架構(Plugin-in Architecture), Plugin之間必須透過核心系統才能做溝通, 舉例來說: 瀏覽器擴充功能, iOS APP
單元三
講解管線與篩選器這個架構的特性
此軟體架構通常被應用在「數據流」等資料處理的系統，例如：報表系統的數據流處理、熱門關鍵字的數據流處理等等
使用的狀態應該盡量少且簡單，且避免狀態相依性 若是要起跑前要確認太多狀態 (State)，可能會導致在抽換/添加篩選器位置的時候，也要相對應地調整要確認的狀態 (State)，狀態過多或具有相依性的情況，便不適合使用此模式。
以大隊接力為例
:::info Allen．5 個月前03 老師好，
其實我也不知道跟這個主題有沒有關
目前我在處理以排程去彙整交易資料成報表資料
分別產生業務資料、金錢資料存入table
Q1.一般而言，這些資料能怎麼繼續處理?
假設我整理了50筆資料，處理完存入資料庫後，緊接者呼叫另一段程式，針對這50筆繼續處理像月營收或成長率之類的嗎?
Q2.報表的資料算是及時更動是常態嗎?
譬如，今天進了一筆交易，我就該在營收或成長率看到變動
從前輩經驗都是可能月中月底或每個禮拜才整理資料，但客戶的要求都是當日看到變化
Q3.因為業務資料可能會在一個月後或許久之後，進行改動
因為交易資料與報表資料的處理是不相干的，那報表資料脫鉤，有什麼建議的處理方式嗎?
(我有試過增加狀態與時間，譬如跑五年前到今天，或一年前到今天撈取變更狀態，但資料量一定會過大導致timeout) :::
:::success Hi Allen, 以下分別回覆問題：
Q1.一般而言，這些資料能怎麼繼續處理? 首先，報表資料儲存的位置通常是獨立的，如果資料量大的話，不會選擇傳統的 DBMS 做儲存，而是會選擇 Hive 等大數據的儲存方式。
資料會定期(例如：每一天)向報表系統的儲存空間送，在送的過程中會對資料做預先處理，例如：多份資料先 join 起來，或是做篩選 (filter)，或是加上 timestamp 等等訊息。簡單來說，先把資料整理成適合輸出成報表的樣子，當你在寫報表程式的時候，資料比較方便撈取。
Q2.報表的資料算是及時更動是常態嗎? 這一點主要看業務需求，時間需要精確到每分鐘？每小時？每天？或是每個月？各種不同的即時性更動都是有可能的。
以你的例子來說，客戶要求精確到每天的級別，可以參考 Apache Druid 的解決方案，它的原理是事前幫你把各個時間維度的資料先聚合 (Aggregate) 起來，例如：當你把每小時的資料定期送給 Druid，它可以幫你把每小時的資料計算成「每天」的營收，事先儲存在一個地方，當你要撈「每周」的營收時，因為它已經事前聚合好「每天」的資料，所以 Druid 可以很快地用「每天」的資料算出「每週」的資料。
Q3.因為業務資料可能會在一個月後或許久之後，進行改動
在報表的領域，資料有分 Dimension Data 與 Fact Data 兩種，如果是 Fact Data 通常是不會對原始數據做修改的。
聽起來你面對的問題是： 面對Dimension Data 的變動，希望報表系統與交易系統脫鉤。
在處理上，報表系統的 Dimention Data 也需要從交易系統複製一份出來到報表系統的儲存空間的。做法同樣是定期地把資料倒出來(例如：每一天)。這裡有個小細節需要注意，每一筆 Dimention Data 是有多個版本的，所以欄位要加上「載入時間」的維度，這個「載入時間」就是你把資料倒出來的時間，資料欄位類似：
客戶地址, 客戶名稱, 載入時間
如此一來，你在輸出報表的時候，就可以知道要去抓哪個時間的 Dimension Data 來和 Fact table 進行 join，輸出資料可以精確到一年前的某一天的 Dimension。如果你的資料太多，建議可以放到大數據相關的儲存空間來進行操作，例如：Hive 等等 :) :::
單元四
事件驅動架構，以郵局為例說明集中式和非集中式，
以廣告更新為例解釋集中式，需要有事件中介，事件之間無相依性，進入事件隊列後不保證何時執行
已刪除廣告為例解釋非集中式，事件之間有相依性
優勢: 事件處理器彼此獨立，容易擴充
劣勢: 事件相依性過多，出問題時難以追蹤；狀態一致性難達成
如何克服一致性議題:
- 讀取模型: 實作單純，僅能處理對於時間差較不敏感的資料類型，無法處理交易(transaction)類型的資料
- 分割事件隊列: 直接讀取隊列內容，但必須定期更新起始狀態
- 樂觀鎖: 處理資料寫入衝突問題，關鍵在於寫入前要確認，我寫的資料有沒有被其他人改過
單元五
衡量方式與實戰要點
軟體架構會揭露該軟體的重大設計決定
最終目的為降低修改成本
好的架構 ⇒ 成功降低修改成本的架構
架構與功能: 不一定總是相關
架構想傳遞的意圖
- 事件驅動架構比較難處理交易類的資料
- 管線與篩選器架構比較難處理與外部狀態的聯繫
架構要能促進開發、部屬與維護
單元六
學會評估系統限制
第4章 核心觀念 敏捷開發
值得一看
- 單元三
- 單元四(集大成)
單元三: 需求怎麼紀錄
產品需求規劃文件 1. 產品願景 2. 產品概述 3. 案例 4. 產品流程圖
有效的對話
透過使用案例、使用者故事、事件風暴
產出需求規格(功能性、非功能性)、產品驗收標準、產品流程圖(可透過事件風暴進行探索)
工程設計規劃文件 - API規格 - 資料模型設計 - 程式元件規劃 - 驗證條件 - 第三方串接
單元四: 軟體開發核心觀念
對抗風險 1. 商業 2. 團隊 3. 技術 4. 成本
創造價值