發表文章

目前顯示的是有「系統分析」標籤的文章

Draw.io使用教學_ERD繪製

圖片
接續 前篇章 ,我們完成系統分析需求擷取過程。 定義資料表也就是實體會有哪些? 倉庫:一個倉庫下會有多個原物料存放。 原物料分類:原物料會有不同分類 系統使用者:控管倉儲人員才能使用 出入庫單:紀錄入庫跟出庫時間點 Draw.io旁邊有一個Entity Relation中文叫做「實體關係」 點選既有的屬性後Ctrl+Enter可自動多增加下一個屬性 比方除了倉庫名稱(庫別) 多擴充建檔時間、建檔者員工編號、修改時間、修改者員工編號 多新建一個用戶實體 用戶角色會再細分有普通用戶、管理員兩種身份 再來就是密碼 將Warehouse實體中c_usr_id,m_usr_id前面多註記為FK 將1對多或無的關聯線段拖曳兩個並自行去對照 藉此就能透過此ERD來描述 某一個用戶可以新建/修改0或多筆倉庫。 接續是 原物料跟原物料分類 其中原物料本身具有兩個外來鍵 倉庫ID跟物料分類ID 出入庫單 欄位:操作人ID、物品ID、操作類型(入庫/出庫)、操作數量、操作時間、備註

Draw.io使用教學_流程圖&泳道圖繪製

圖片
跟老闆或委外發案的仲介訪談: 某一間中小企業,採購買進來的原物料要做入庫,老闆很苦惱倉儲管理。 有時候會有領料庫存水位管控不穩情況,要馬就是庫存備料不夠耽擱生產,要馬就是過多變成放到佔位子或變質過期。 跟倉儲主管做需求訪談: 現況人員都用excel在進行管理紀錄,但離職流動率十分高,資料維護則是5個倉管不同格式excel在維護,在交由倉儲主管每天來統一整併。而且每次領料都要自己去維護excel,很容易因為請假代班忘記維護,或是走很遠到指定放置地點又要回到電腦桌去維護excel。庫存無法做到即時的增減,此外也很難知道某個物料放置位置,要找到存放位置都要再去excel核對查找。 現況公司內有2~3個倉庫,所以都會分不同excel sheet來控管,每次都花很多時間去維護進、退(領)料,而且都要自己樞紐做excel統計分類圖表分析。 目前怎麼領料的? 倉儲主管:生管寄信約時間,來樓下庫房跟倉庫領取,然後excel登打扣除指定品項數量。 所以聽起來採買進來的原物料會編列一個料號? 倉儲主管:是的。 那只有一個倉庫嗎?還是有多個呢? 倉儲主管:有3~5個倉庫,分別放不同類型,針對原物料去區別出不同庫別。 目前怎麼入庫的? 倉儲主管:通常倉儲會根據採購訂單下的數量先核對包裝與數量確認,有檢核不對就直接退貨給供應商。若初步檢查通過,後續再交由品質管理部門來進行品質檢驗(外觀電性測試或是化學檢驗)。確認都沒問題後,就excel方式登打紀錄然後放到特定庫存儲位。 https://www.drawio.com/ 可以選擇雲端硬碟在此先選設備 選空白的圖表 可以從隔壁通用拖曳放進來。 流程圖 也可以空白處,滑鼠左鍵快點兩下產生圖案。 https://www.osp.de/tw/resources/articles/what-is-a-warehouse-process-flow-chart 流程圖順序一般由上至下,由左至右。 長方形:代表一個流程,是最常用於基本任務的符號。 菱形:代表要根據問題做出一個決定。 圓圈/圓弧矩形:代表起始符號,用於流程圖的開始和結束。 流程線:用箭頭指示步驟的執行方向。 平行四邊形 : 資料輸入&輸出 波浪矩形 : 列印文件 流程線線段快點滑鼠左鍵兩下可編輯文字。 匯出 泳道圖( swimlane diagram) 用於釐清各部門或角色工作職...

系統分析的相關手法及細節

需求分析: 指的是在建立一個新的或改變一個既有的系統、服務或產品時,為確定新系統的目的、範圍、功能及定義所需要做的所有工作。 分析過程中常見的挑戰: 無利害關係人參與 利害關係人未必知道自己需要捨麼->開出一長串清單、甚至相互矛盾 利害關係人未必可清晰表達出自己的需求 需求分析不明確->用到模稜量可陳述或過多形容詞 專案範圍蔓延 需求一改再改導致重工 分析步驟 採集需求->分析需求->確認需求->製作需求規格書->管理需求 需求涵蓋範圍分類 (1)業務面: 一般性需求(業務限制、政策、法規、文化、品牌、語言) 技術性需求(軟硬體、網路、infra) (2)解決策略面: 功能性需求(數據輸入、編修維護、檢索) 非功能性需求(可用性、可維護性、存檔及保留、備份和還原、效能、容量、安全性) 採集跟分析需求常見手法(相互搭配使用) (1)文件分析:公司內部文件、先前案例、相關系統說明及規格書、會議記錄 風險:可能過時、有可能在其他mail loop有微調 (2)訪談、觀察 (3)問卷調查->採匿名、量較大 (4)Wireframe線框設計->手繪草稿 (5)Prototype模型製作->更趨近真實 需求訪談重點 1.寄出會議邀請(人數6~8人)。 2.參與名單建議是可以做決策的人、是利害關係人、派各部門代表。 3.規模小的會議較好(1對1、1對2較願意將真實想法透露) 缺點就是更耗時,還是建議一次約齊所有關鍵人。 4.讓大家有機會發言,不要會後才來補充。 5.引導與紀錄交談步驟 訪談後再次確認 1.製作流程圖(draw.io , visio)。 2.寄給相關人確認無誤或有無要再更動。 3.再次根據反饋更新 需求管理方式 需求規格書(清單)/User Story Mapping 需求ID 需求種類 身份(角色)->可能是部門、不同職務、消費者端還是商家端 需求名 目的 驗收標準 優先順序 企業(業務)相關功能 負責人職稱 需求負責人姓名

系統分析筆記_物件角色建模ORM (Object Role Modeling)_part1

圖片
在 1970 年代,特別是在歐洲,重要的研究都集中在如何提供一種高階的語法來為資訊系統建模,由Falkenberg 提出了物件角色建模(Object Role Model)為資料庫設計提出一不同的建模方法。 物件角色建模(Object-Role Modeling; ORM)是一種以概念模式(Conceptual Model)設計資料庫的方法。 所謂的概念模式即是以一般任何人都容易理解的層次,如:語言、文章句子、圖形符號 等,來表達與互相進行溝通。進行資料庫分析或設計時,分析與設計者透過ORM 使用企業內常用的名詞來描述資料,進而與使用者溝通,以免讓分析者、設計者與使用者之間產生誤解。 可以一般的語言或事實(facts)來描述資料, 如: Person visited City on Date. Person works in City. Person was born in City. Person was born on Date  等四個句子用以描述人的工作、出生地與日期等資料。 圖1.ORM 資料模式的表達例子1 可進一步使用不同的標記(notation)來把事實(facts)圖形化(symbolizing),即可對應至ORM 的符號,ORM 強調其許多表達意義的符號與限制條件。 最後,根據ORM 制訂的法則將符號轉換成關聯式資料模型,並可實作出資料庫系統。 以一個客戶訂購產品的資料庫為例,產品(Product)具有類別(Product Type)及產品名稱(Product Name),而且這些資料是一定要存在的資料,而產品是由訂單(Order)所訂購的,由此可知整個ORM 是以這些符號環環相扣。 圖2.ORM 資料模式的表達例子2 為物件格式(object type),有實線與虛線兩種橢圓。 實線橢圓表示實體類別(Entity type),表達真實世界存在的事物或一種概念如訂單(Order),圖中的括號表示為參考模式(reference mode)的資料類別,必須填入定義的資料類別,在資料整合時,可作為資料內容的判斷依據,如日期的表達(YYMMDD) 虛線橢圓表示值類別(Value type),如圖中的id 可定義各種字串,無法由id 指出真實世界存在的實體,因此定義為值 此外,若值類別中有符號(+),表示該值為數字,可進行數學運算的資料。 物件所扮...

Domain Know How裝潢室內設計_系統家具業_系統櫃材料與裝潢計價單位

圖片
摘自:  https://www.100.com.tw/article/1344 無論哪個行業只要有涉及材料,成本估價則必定是一項難題和必定要管控的課題。 可在參考之前文章 何謂商品?可以賣的東西就叫商品嗎?_原料與物料如何區分? BOM產品結構中低階碼的應用與概念 中小型系統家具業主要時常遇到的困難就在於 每一個材料的經銷商、廠商都不同,還涉及需要客製化訂做的問題。 所以資料建檔跟以往可能固定製造商產業PDM系統有固定產品種類對應規格維護比較不同 也跟3C產業製造業固定電腦產品規格組一台一樣,因為每個屋主(客戶)都有不同的空間環境。 所以也沒辦法用類似製造業BOM概念來去思考 因為不像製造業固定規格大量製造,是每次都要訂做的。 而且不同廠牌對應材積價格是會浮動的,稅也是....(稅的問題可能暫時先不考慮進來>~<) 那excel會因為不同權限控管和不同時段維護超多份... 再來資料聯動困難性 系統家具業軟體層面系統導入會涉及到的電子單據-估價單 系統家具業通常於估價單單身中每一筆代表著所謂施作項目(會有對應不同施作工法) 每一個施作項目會有不同建材(在科技、製造業稱為 : 料件、原料) 每一個建材會有不同規格屬性、不同的品牌會去影響其單價 這個產業中會有一些不同設計師權限 總監設計師 店長設計師 (每一間分店會有細分不同小組,每一個設計師會分別去負責不同估價單, 每一個主任設計師負責他那一組的業績) 組1.[主任設計師>專案設計師>助理設計師] 組2.[主任設計師>專案設計師>助理設計師] 組3.[主任設計師>專案設計師>助理設計師] ... 組N.[主任設計師>專案設計師>助理設計師] 裝潢估價通常會有以下SOP Step1.確認施作範圍 Step2.確認公司名稱、地址與聯絡電話 Step3.確認客戶名稱 Step4.確認數量 Step5.確認單位 Step6.確認規格 Step7.確認建材等級 Step8.確認施作工法 Step9.確認單價無誤 所以估價單單頭通常就會列像是 哪位設計師、設計師電話、哪個屋主(客戶)、聯絡方式(電話,Email)、地址 、工地地址(可能需額外訂出來通常不一定就等同聯絡地址)、報價日期等等 以下面估價單單身為例後可能就有 像是衣櫃、書桌等等施作項目各自有對應不同施...