2005年後被廣泛討論的東東…DNOWBA接觸程式設計後總覺得程式設計少了些東西…這陣子發現原來這個還有理論…於是乎搬出來好好研究一番，以下是閱讀巨匠電腦相關課程後的心得筆記…了解不深…純供參考 
◎軟體開發方法論的起因：因為資訊工具蓬勃發展，但是應用在企業中成效卻往往不如預期，癥結在「需求認知」的問題，這也是我關注的問題，金門內小學的資訊環境就有這種現象，隨著資訊發展，國小裡許多教學計畫，其審核和成果都開始要求上傳到網站。但金門縣老是要外包一些或著自已架一些網站，每一案子都有不同的網站，這對於使用者來說，要記不同的網頁、不同的帳號密碼…然後這個網站會隨著時間慢慢的消失
金門縣教育單位說：「有網站給你們呈現成果、審核計畫」怎麼沒人要用」
金門縣國小老師說：「你來用用看…難用的要命」
這就是「使用者需求 ≠ 開發者認知」
教育主管機關的認知是「整合」，但卻忽略了使用者真正的需求。東整西整的…整不起來還反倒製造麻煩。
然後又請了一堆三流的廠商，老是用「雲端」「整合」的字眼來矇混…做一些爛平台…
企業看來早就關注到這個問題了，畢竟效率=MONEY，於是提出「應用軟體開發必須熟悉商業流程」的概念…並進一步的推出方法，其中MDA最受人關注。他們探究了不如預期的原因，如下 
唉…「應用軟體必須熟悉教育單位流程啊…」，這張圖就是我的心聲，給我一個真正可以盪的秋千吧 
◎MDA
喔…在解釋MDA是什麼時，巨匠用了一個比喻一聽就懂 
MDA就像是樂高積木一樣，每一小塊的積木都是一個模組，且透過標準化的機器生產…有了這些小積木，不同的使用者就可以利用它們做成各式各樣不同且符合使用者期待的大模型…喔…難怪我會對MDA有興趣…原來是樂高啊。不過這裡我會覺得樂高積木在我想要設計跑車的時候，我想要的流線形是受積木限制的…也就是說…模組有辦法應對各行各業嗎…有辦法追得上也同時在改變的各行業的速度嗎。
至於MDA的三階段模型…這裡聽到我怎麼又覺得關注的東西失焦了…參考一下就好 
◎MDA的塑模
「塑模」就是要做模組前先要做一台射出機器，這塑模工具(CASE TOOL)MDA提出了用地圖的方式呈現，唯有具象化的呈現才可讓程式開發者、需求者之間有些共識。不過地圖呈現方式我覺得MDA又多此一舉，又提出了做地圖的工具，但我老覺得這類型的工具好像也沒有使用者需求導向(= =，看來我還是比較中意另一個開發方法論SOA) 
如下圖就是一個case tool的範例，左圖是一般需求者提供的企業內流程圖，而右圖則由系統開發者、系統分析者加以揣述的地圖…二者間以彼此能交流，如此彼此間的認知度才不致差異過大 
◎開發者對於需求的真正認知
開發者要從老闆+員工的角度多層了解…但往往開發期程的限制會導致認知不全的問題，這裡MDA倒提出了一個好點子-「從該公司現有的文件」來輔助認知，開發中就可以節省許多討論的時間。就企業而言，常有的文件有，這企業和學校倒是相仿
．工作規章(學校管理規章)
．工作說明書(學校章則)
．標準作業程序(這個可作學校參考，一般來說是逐級上報，但是細部的作業程序其實可以擬定)
．內部稽核標準作業(有點像是督學訪視、評鑑之類)
．各項各類表單(申請書、檢核表、日誌、週報表之類)
．系統操作手冊(BINGO…這是我的目標)
一般開發者根本沒法短時間了解教育系統(別分國中小了，就連不同縣市的國小都有其差異)…所以像是SFS3的開發就是由學校教育工作者來發起…
◎對於企業的標準作業程序和文件的編制法…不外乎「規範→作業管理辦法→作業辦法」：由規範、作業管理辦法中可以揣摩老闆的心態、作業辦法可力求提出符合辦法又對實際操作者友善的介面人員。 
看完後有個感覺，這MDA理論當初是由IBM的大佬提出，讓我很好奇的是，他是由一般企業需求和IBM系統開發的角度來想的，還是由IBM企業需求和IBM系統開發這個角度來想…這個想法舉例來說，如果拿 微軟來說，不知道他們的企業內部員工有沒有真正從自家開發的sharepoint中獲得效益…還是其實他們的員工在被逼著用的時候是不是一邊幹譙著好難用啊。再簡單一點的來說，MDA是照顧老闆還是照顧員工…個人覺得唯有提出員工層級好用的系統，才能真正的提高效率(當然老闆要求的效率是兼顧MONEY和員工的心情為出發點)
沒有留言:
張貼留言