當專案發生延誤的時候 , 通常 PM 會召開會議 , 請專案成員參與 ,
然後請專案成員提出建議 看看要如何改善專案 ,
最糟糕的說法就是那種
(a)¨ 大家都是專案成員 , 專案的成敗大家都有責任¨
然後補上一句
(b)誰誰有沒有甚麼方法可以改善的
然後就開始大家大眼瞪小眼 ,呆著...
這個不是Brain Storming 好不好
更慘的就是 , 還會有那種不負責的人在旁邊說風涼話(所謂的不負責 , 就是他完全沒有能力可以解決那個問題 , 或是完全不知道怎麼作 , 又不用負任何責任的人)
風涼話例如:(c) ¨大家繼續撐著 ...¨ , 或是 (d)¨只要大家有信心 , 專案一定可以完成的¨
實際上 , 應該是要找出專案發生延誤的真正原因 , 真正問題 ,
唯有面對問題 , 才能找出問題的原因 , 也才能找出真正的解法 ,...
如果 PM 不能面對問題 , 則不論採行任何方案 , 該問題始終會一再出現 , 專案就會一再延誤
如果專案成員有人在說風涼話例如:(c) ¨大家繼續撐著 ...¨ , 或是 (d)¨只要大家有信心 , 專案一定可以完成的¨ ,
請問這樣的風涼話可以找出真正的問題嗎 ? 可以真的把問題解決嗎?
再說
(a)¨ 大家都是專案成員 , 專案的成敗大家都有責任¨ / (b)誰誰有沒有甚麼方法可以改善的
這個是不面對問題的說法 ,
應該是找出問題 , 該誰負責 , 誰就負責 , 如果誰的能力或技能不足 , 則應該對外(其他部門單位)或對上求援就該求援 , 儘速把問題解決 ,
一個問題會出現 , 不管如何 , 一定要指派一個人員負責去追蹤處理 , 打混仗是最糟糕的事(就是說是大家都有責任 , 但是完全不會有人撿起來作)
2009年1月5日 星期一
2009年1月3日 星期六
沒有軟體開發經驗的人去作SA會有甚麼問題?
我在 "OCUP UML初級認證攻略" 書上看到作者的一段話 ,
她提到要考UML認證的理由六:
"理由六: 資料的程式設計師 , 女性程式設計詩 , 或者是打算邁入軟體業的女性新鮮人 , 要趕快往UML轉型或投入 , 否則年紀越來越大 , 不僅敵不過年輕小伙子的熬夜拼命 , 女性朋友還會因為熬夜而青春難保"
看到這段話 , 我是深深的不以為然 , 因為這段話中 , 提到要往UML轉型的理由極度的牽強 , 且不合理 ,
我特別認為這段話會誤導很多人 , 這也就是為什麼 , UML 在台灣會呈現兩個極端 ,
(a)會用UML收集需求 , 進行分析設計 , 進而根據UML規劃去開發系統 的人 , 會認為UML是好東西
(b)不會用UML的人 , 只會認為這個對於他的軟體開發一點幫助都沒有 , 只是為了應付業主的要求為了文件而文件 , 只會讓自己開發系統的速度變得更慢 , 甚至乾脆就是等軟體開發完 , 再用反向工程去把程式碼轉為 UML 圖形....
我一直強調一點 , 完全沒有OOAD程式開發經驗的人 , 沒有資格去當SA , SD ...
因為軟體開發中 , 上游的產出是下游的輸入 ,
上游如果完全不了解下游的作業 , 或是下游的需要 , 那麼規格一定是亂開....
EX1:
我曾經碰到過廠商針對我們的需求 , 開出了這麼一個系統規格要求:
"系統需要把目前的報表紀錄匯出成為 EXCEL檔(.xls / or .csv ) , 要能使用 EXCEL 開啟"
實際上廠商也寫出來了 , 但是這樣的一個系統規格要求是由問題的 ,
因為他們發現EXCEL打不開檔案 , 為什麼 ,
因為 EXCEL的一個工作表的列數限制是 1~65536 列 ,
而要匯出的報表紀錄筆數超過了 65536 列 ,....
當然如果你匯出的是 .csv 檔 , 你可以用 記事本 notepad 開啟 , 但是你用 Excel 應該是打不開....
同理如果你是用 POI 匯出 .xls , 應該也是會有問題 , 因為 一個工作表的列數上限就是 65536 列
這個限制很簡單也很單純 , 但是打敗一堆人 , 一堆人在哪裡猛查程式哪裡有問題 , 查了很久沒有查出來...
(這樣的規格 , 到現在 , 你去看網路上 , 仍然有不少人在開這樣的系統規格 , 而且完全沒有理會到未來可能會有甚麼問題發生) ,
這樣的系統規格需求不能說它不對 , 而是它有限制 , 如果你知道你的系統匯出筆數永遠小於 65536 筆 , 一定沒有問題....
(這也是我對某些人員很感冒的一點 , 他們都很會說話 , 讓老闆認為他們做的很好 , 但是常常喇賽的時候 , ...就要我去幫忙查問題 , 看原因 , 最後還要把賽幫他們擦乾淨(特別是那些莫名其妙的SA))
這也就是為什麼我一直認為沒有軟體開發經驗的人去作SA會有很多問題發生 ,...
但是偏偏還是有一堆人以為只要考過 UML 就可以去作 SA , SD , 等到他們開始去開規格時 , 完全不理會系統是屬於 Client / Server , 或是 Rich Client / Thin Client 或者是 Internet / Intranet 等等需求 ,
反正就是亂畫一通 , 以為自己畫了圖 , 系統就會自己長出來 , 但是當下游的 Programmer 來問的時候 , 自己又完全講不來要如何把圖形轉換為程式碼 ,...
就這樣子 , 就會發生 , 新鮮人 雖然採用了 UML 進行系統開發 , 但是完全上下游無法串連 , 結果導致系統開發失敗 , 最後就會發生像是 "UML 對系統開發一點幫助都沒有 , 還不如直接寫程式的看法..."
又或者完全沒有寫過 Web App的人 , 只會AS400 , 然後又要去開出 Web App的系統需求跟規格 , 完全不了解 Java / .NET 架構的人在開規格,...連Web程式的限制是甚麼都搞不清楚 , 常常就會開出莫名其妙的規格...
(發現說著說著又離題了之二 )
2008年12月30日 星期二
UML概念說明
初學UML的人可能只是把UML當作是單純的繪圖表示法 ,
以為UML就是放上Use Case Diagram , Class Diagram , Sequence Diagram就是UML了 ,....
錯 , ....UML會跟你的方法論有關 , 會跟你的開發程序有關 ,
但是常常還是有人會誤以為UML只是繪圖表示法 ,
所以當你要求外包商 , 要針對他們正在開發的系統去繪製UML產出時 , 常常看到的是 上帝的歸上帝 ,
嗯 , 說錯 , 是UML文件歸UML文件 , 系統程式歸系統程式 , 兩者完全沒有關聯性 , 純粹只是為了文件而文件 , 這樣的狀況是最糟糕的 , 但是偏偏這種方式卻常常有不少人能夠接受 , 讓我完全無法理解 ,
基本概念一: UML就是系統的藍圖 , 系統的開發應該是根據規劃的藍圖去實做
這麼說好了 , UML , 你可以把它想像是房子的藍圖 , 房子的所有規劃 , 包含電線管路要怎麼拉 , 怎麼走 , 污水管理怎麼走 , 電梯要裝幾個 , 逃生梯開在房子的左邊或是房子的右邊 , 戶與戶之間的大門是向內開還是向外開(之前 , 有大陸的新聞說 , 有棟房子 , 住戶與住戶的大門是向外開的 , 所以 住戶A開了大門就會堵住住戶B的大門 ...) ,
那你可以想像說 , 明明是電梯大廈的藍圖 , 結果蓋出 18樓沒有電梯的房子嗎? ,
如果你能接受房子的實體應該是根據房子的藍圖蓋出來的 ,
那你怎會能接受 做出來的系統程式完全不根據藍圖(UML)去開發???
基本概念二: UML 的每個Diagram 是有關聯性 , 有可追蹤性的
舉例來說 , Use Case Diagram 談的是User Requirement的蒐集 ,
也就是說你在圖上畫的每個Use Case , 它都應該會被實現(Use Case Realization) , 而每個Use Case Realization 都會被轉化為 SA , (產生 Boundary , Control , Entity) , 再由此衍生出相關的SD , 而產生出 對應的Class , Class Diagram , Sequence Diagram , 等等 ,
這其中就衍生出可追蹤性(traceability) , 照道理來說 , 你可以正向由來源去追蹤每個項目的下一個產生是甚麼 ,
就舉 Use Case 來說 , 如果你的系統有畫了 10 個 Use Case , 那麼你可以看一下每個Use Case 是否有被實做 , 這個Use Case 實做的衍生物是哪些 , 一路追下去 , 保證你絕對不會短缺有任何該做的功能被遺漏沒有實現....(反向也是如此 , 你隨便挑出一個Class , 它一定是某個或某幾個use case實做必須的衍生物 , 絕對不會有那種無中生有的Class , 除非那是垃圾Class或是雞肋Class )
但是 , 一般人員很少有這樣的認知 , 多半是為了交文件而文件...
基本概念三: 是不是一定要畫UML才能開始作系統
這點我的答案是看狀況而定 , 如果你的系統很小 , 然後你也都明確的了解使用者的需求 , 然後要開發的功能與平台都十分明確 , 你也已經評估過程式碼不多 , 甚至你都不打算拆出系統階層 ,或是類別 ,
那根本就不需要UML的介入 ,
還有你是那種做到哪裡才想到哪裡的 , 也不需要 , 因為當你不作規劃 , 那UML對你也沒有幫助...
因為UML的開端就是 Use Case Diagram , 藉由 Use Case 去蒐集與釐清使用者的需求 , 系統的邊界 ,
有哪些系統外部的人或系統(這個就是Actor)會與我們的系統有互動 , 而那些Use Case 就是我們的系統會對外提供的服務(功能) , 也是我們的系統實做的清單 ,....
我看過廠商畫了 某些Actor , 我問廠商說 , XXX Actor , 它會跟我們的系統有互動嗎? , 如果 XXX Actor 是人 , 那他會登入我們的系統嗎? , 如果 XXX Actor 是另一個系統 , 那麼它跟我們的系統之間是如何溝通互動的....
廠商答不出來 , 因為他根本只是隨便亂畫 , 為了交文件而文件 ,
審閱這些為了交文件而文件 , 連寫文件的人自己都說不出個道理的文件 , 實在是浪費人生...
基本概念四：UML是否一定要畫的巨細靡遺?
我的答案是看你的開發模式是哪一種 , 或者說你是奉行或是採行哪一種方法論 ,
像如果你是採行MDA的開發模式 , 則UML Model 一定要畫的清清楚楚 ,
因為你的Model 就是要產生的系統程式碼的原始規格 ,
不過 MDA 一般也都會搭配類似程式碼產生器的工具 ,
舉例來說 , 像是 Eclipse 之下的 EMF , GEF , GMF 就是你先規劃好不同物件之間的關係 , 關聯 , 限制等等 . 就可透過工具轉換模型變成可執行的程式碼 , 所以有些類型繪圖工具 , 你只要詳細的設定好 Model , 幾乎就可以透過工具完成80%以上的工作 , 讓要寫的程式減少 ,
但是也有人堅持 , UML 只是單純的繪圖表示法 , 只要挑重點畫就可以 ,
這樣也不是不行 , 前提是: 你必須要了解你的系統的全貌 , 每個類別間的關係.. , ...之類的
另外要交接時 , 也可能會因為你畫的十分簡略 , 所以你會有很多東西不在UML圖形中 ,
如果你接手前人這樣的遺產時 , 當你要接手維護時 , 你想要知道某某Class有沒有XX功能 , 或是你想要換掉它 , 但是你又無法從前人留給你的UML中 , 看出端倪時 , 那你只好自求多福 , 或是拜託前人還在公司沒有離職可以讓你問....
或者是當幾年前你開發的系統 , 後續的系統維護者有問題需要詢問你的時候 , 最好是你的記憶好到可以記得 n 年你實做的系統明細....
突然發現又在離題 ...
以為UML就是放上Use Case Diagram , Class Diagram , Sequence Diagram就是UML了 ,....
錯 , ....UML會跟你的方法論有關 , 會跟你的開發程序有關 ,
但是常常還是有人會誤以為UML只是繪圖表示法 ,
所以當你要求外包商 , 要針對他們正在開發的系統去繪製UML產出時 , 常常看到的是 上帝的歸上帝 ,
嗯 , 說錯 , 是UML文件歸UML文件 , 系統程式歸系統程式 , 兩者完全沒有關聯性 , 純粹只是為了文件而文件 , 這樣的狀況是最糟糕的 , 但是偏偏這種方式卻常常有不少人能夠接受 , 讓我完全無法理解 ,
基本概念一: UML就是系統的藍圖 , 系統的開發應該是根據規劃的藍圖去實做
這麼說好了 , UML , 你可以把它想像是房子的藍圖 , 房子的所有規劃 , 包含電線管路要怎麼拉 , 怎麼走 , 污水管理怎麼走 , 電梯要裝幾個 , 逃生梯開在房子的左邊或是房子的右邊 , 戶與戶之間的大門是向內開還是向外開(之前 , 有大陸的新聞說 , 有棟房子 , 住戶與住戶的大門是向外開的 , 所以 住戶A開了大門就會堵住住戶B的大門 ...) ,
那你可以想像說 , 明明是電梯大廈的藍圖 , 結果蓋出 18樓沒有電梯的房子嗎? ,
如果你能接受房子的實體應該是根據房子的藍圖蓋出來的 ,
那你怎會能接受 做出來的系統程式完全不根據藍圖(UML)去開發???
基本概念二: UML 的每個Diagram 是有關聯性 , 有可追蹤性的
舉例來說 , Use Case Diagram 談的是User Requirement的蒐集 ,
也就是說你在圖上畫的每個Use Case , 它都應該會被實現(Use Case Realization) , 而每個Use Case Realization 都會被轉化為 SA , (產生 Boundary , Control , Entity) , 再由此衍生出相關的SD , 而產生出 對應的Class , Class Diagram , Sequence Diagram , 等等 ,
這其中就衍生出可追蹤性(traceability) , 照道理來說 , 你可以正向由來源去追蹤每個項目的下一個產生是甚麼 ,
就舉 Use Case 來說 , 如果你的系統有畫了 10 個 Use Case , 那麼你可以看一下每個Use Case 是否有被實做 , 這個Use Case 實做的衍生物是哪些 , 一路追下去 , 保證你絕對不會短缺有任何該做的功能被遺漏沒有實現....(反向也是如此 , 你隨便挑出一個Class , 它一定是某個或某幾個use case實做必須的衍生物 , 絕對不會有那種無中生有的Class , 除非那是垃圾Class或是雞肋Class )
但是 , 一般人員很少有這樣的認知 , 多半是為了交文件而文件...
基本概念三: 是不是一定要畫UML才能開始作系統
這點我的答案是看狀況而定 , 如果你的系統很小 , 然後你也都明確的了解使用者的需求 , 然後要開發的功能與平台都十分明確 , 你也已經評估過程式碼不多 , 甚至你都不打算拆出系統階層 ,或是類別 ,
那根本就不需要UML的介入 ,
還有你是那種做到哪裡才想到哪裡的 , 也不需要 , 因為當你不作規劃 , 那UML對你也沒有幫助...
因為UML的開端就是 Use Case Diagram , 藉由 Use Case 去蒐集與釐清使用者的需求 , 系統的邊界 ,
有哪些系統外部的人或系統(這個就是Actor)會與我們的系統有互動 , 而那些Use Case 就是我們的系統會對外提供的服務(功能) , 也是我們的系統實做的清單 ,....
我看過廠商畫了 某些Actor , 我問廠商說 , XXX Actor , 它會跟我們的系統有互動嗎? , 如果 XXX Actor 是人 , 那他會登入我們的系統嗎? , 如果 XXX Actor 是另一個系統 , 那麼它跟我們的系統之間是如何溝通互動的....
廠商答不出來 , 因為他根本只是隨便亂畫 , 為了交文件而文件 ,
審閱這些為了交文件而文件 , 連寫文件的人自己都說不出個道理的文件 , 實在是浪費人生...
基本概念四：UML是否一定要畫的巨細靡遺?
我的答案是看你的開發模式是哪一種 , 或者說你是奉行或是採行哪一種方法論 ,
像如果你是採行MDA的開發模式 , 則UML Model 一定要畫的清清楚楚 ,
因為你的Model 就是要產生的系統程式碼的原始規格 ,
不過 MDA 一般也都會搭配類似程式碼產生器的工具 ,
舉例來說 , 像是 Eclipse 之下的 EMF , GEF , GMF 就是你先規劃好不同物件之間的關係 , 關聯 , 限制等等 . 就可透過工具轉換模型變成可執行的程式碼 , 所以有些類型繪圖工具 , 你只要詳細的設定好 Model , 幾乎就可以透過工具完成80%以上的工作 , 讓要寫的程式減少 ,
但是也有人堅持 , UML 只是單純的繪圖表示法 , 只要挑重點畫就可以 ,
這樣也不是不行 , 前提是: 你必須要了解你的系統的全貌 , 每個類別間的關係.. , ...之類的
另外要交接時 , 也可能會因為你畫的十分簡略 , 所以你會有很多東西不在UML圖形中 ,
如果你接手前人這樣的遺產時 , 當你要接手維護時 , 你想要知道某某Class有沒有XX功能 , 或是你想要換掉它 , 但是你又無法從前人留給你的UML中 , 看出端倪時 , 那你只好自求多福 , 或是拜託前人還在公司沒有離職可以讓你問....
或者是當幾年前你開發的系統 , 後續的系統維護者有問題需要詢問你的時候 , 最好是你的記憶好到可以記得 n 年你實做的系統明細....
突然發現又在離題 ...
預計要寫的文章清單
在目前的這個部落格中 , 我的每一篇文章都是自己寫出來的 ,
每一篇都是自己的心得或是練習 ,
或者是針對某一個主題 ,
網路上沒有一篇文章可以簡單說明 , 而必須要四處搜尋參考不同文章來源的 , 那也是我撰寫的主題範圍...
(如果有相同題材 , 別人寫的比自己完整 , 比自己豐富 , 那我應該就不會寫了...)
反正想到了 , 就寫一寫 , ( 就是寫的不好 , 才要練習 )...
預計要寫的文章清單：(暫時想到的 , 不過要寫教學 , 要想情境 , 要操作 , 要抓圖 , ...有點懶)
1.GnuCash (Ubuntu) - 個人財務紀錄(記帳軟體) -- 目前已經紀錄幾個月了 , 記出一點使用心得了...
2.編碼 , 字碼 , 字集 觀念說明
每一篇都是自己的心得或是練習 ,
或者是針對某一個主題 ,
網路上沒有一篇文章可以簡單說明 , 而必須要四處搜尋參考不同文章來源的 , 那也是我撰寫的主題範圍...
(如果有相同題材 , 別人寫的比自己完整 , 比自己豐富 , 那我應該就不會寫了...)
反正想到了 , 就寫一寫 , ( 就是寫的不好 , 才要練習 )...
預計要寫的文章清單：(暫時想到的 , 不過要寫教學 , 要想情境 , 要操作 , 要抓圖 , ...有點懶)
1.GnuCash (Ubuntu) - 個人財務紀錄(記帳軟體) -- 目前已經紀錄幾個月了 , 記出一點使用心得了...
2.編碼 , 字碼 , 字集 觀念說明
Mediawiki 的導覽列設定位址
在我當初開始安裝 Mediawiki 在本機之後 , 我第一個想要做的就是 , 弄出一個 Menu在左方(就像在外面的Wiki 看到的一般...) , 有一陣子到處亂試 , 結果才發現
Mediawiki 的導覽列設定位址 會在你本機安裝的以下網址
http://localhost/wiki/index.php/MediaWiki:Sidebar
(要登入為 WikiSysop 帳號 , 或是有同等權限的 , 才能編輯修改)
2008年12月27日 星期六
VMWARE SERVER 2.0的討人厭的預設讀取目錄
VMWARE SERVER 2.0 在UBUNTU上預設會去讀取"/var/lib/vmware/Virtual Machines" 之下的目錄內容 ,
也就是說 , 如果你有要新增 VM 或是 新增虛擬硬碟(.vmdk)
都要放在這個位置之下 , ....
但是我不習慣放在此 , 我習慣把每個 VM 拆開目錄分開放
而且是放在自己的USER目錄下 ,....
後來發現一個 Linux 中手應該都要會的作法 , 就是設定軟連結 ,
把自己的VM目錄設定連結 , 對應到"/var/lib/vmware/Virtual Machines"
ln -s "/home/demo/vmware/myVM" "/var/lib/vmware/Virtual Machines/myVM"
"/home/demo/vmware/myVM" 指的是你的VM相關檔案放的真實目錄請把 demo 換成是你自己的帳號 , 我是在自己的帳號目錄下 , 把不同的VM目錄集中放到 vmware的目錄下
"/var/lib/vmware/Virtual Machines/myVM" 是軟連結的所在
就這樣的設定, 讓我可以直接在我自己的目錄下 對VM目錄檔案作搬移
但是又可以讓我在VMWARE SERVER 2.0的介面下可以抓的到VM的目錄新增虛擬硬碟檔案
在UBUNTU存取USB隨身碟不正常動作問題處理
然後再透過 UBUNTU去讀取USB隨身碟
這幾天碰到一個狀況就是 ,
USB 隨身碟插入後開始搬移檔案不久 , UBUNTU 就出現檔案存取錯誤的問題
然後檔案上得圖示加上"鎖"的圖示 ,
查了許久 , 只好 USB隨身碟 插 回 Windows ,
去對整個USB隨身碟作硬碟的錯誤掃描跟修復 , 修完了就OK了 ,
根 據先前把UBUNTU裝在這款USB隨身碟的推論應該是:
這款USB隨身碟 沒有辦法支援同時開兩個檔案的存取作業 , 所以導致錯誤發生....
因為之前也有把UBUNTU裝在這隻USB隨身碟上過 , 用了好一陣子 ,
但是也 是因為同時開多個檔案存取動作 , 導致 USB隨身碟上的UBUNTU就起不來了...
這幾天碰到一個狀況就是 ,
USB 隨身碟插入後開始搬移檔案不久 , UBUNTU 就出現檔案存取錯誤的問題
然後檔案上得圖示加上"鎖"的圖示 ,
查了許久 , 只好 USB隨身碟 插 回 Windows ,
去對整個USB隨身碟作硬碟的錯誤掃描跟修復 , 修完了就OK了 ,
根 據先前把UBUNTU裝在這款USB隨身碟的推論應該是:
這款USB隨身碟 沒有辦法支援同時開兩個檔案的存取作業 , 所以導致錯誤發生....
因為之前也有把UBUNTU裝在這隻USB隨身碟上過 , 用了好一陣子 ,
但是也 是因為同時開多個檔案存取動作 , 導致 USB隨身碟上的UBUNTU就起不來了...
訂閱：
文章 (Atom)