我們要做一個 Web 介面供人員查詢資料檢核結果。原來的 Web 設計是用JSP讀取資料庫資料，然後 output 成 XML 直接回傳給 Client 的 Browser。而這個回傳的 XML 有標記搭配的 XSL，Browser 在讀取這個 XML 後，會去找到搭配的 XSL 以產出 Html 型態顯示。也就是說，將 XML & XSL 的處理交給 Client Browser。
這樣的方法發現一些問題，會有一些 IE Browser 無法正常顯示 (Mozilla Firefox 好像就沒這種問題)。我們推測是 Browser 對 XML 與 XSL 的支援上有問題 (可是找不出問題在哪!?)。後來，我們決定修改設計，將 XML & XSL 的結合，改由 Server 處理，所以我們在 Tomcat Web Server 上 加裝了 xtags library。
用 xtags library 處理 XML 其實很容易，只要在 JSP 程式裏加上一些 TAG 就好。
例 1 : 直接處理一個已存在的 XML File
<xtags:style xml="test.xml" xsl="test.xsl>>
</xtags:style>
例 2 : 內嵌 XML
<xtags:style xsl="test.xsl">
<root>
<childnode></childnode>
</root>
</xtags:style>
也可以這樣 :
<xtags:style xsl="test.xsl">
<%
out.println("<root>");
%>
<childnode><% =varible %></childnode><br /> </root>
</xtags:style>
然而，如果是用"例 2"的方法，會有怪問題
JSP 的結果會問隔性的出現 "IOException : Stream Closed"
也就是說，執行第一次會成功，第二次失敗，第三次又成功，第四次又失敗....
這個問題是 Tomcat 與 xtags library 的問題，目前無解。但可以改用以下方法來避開這個問題：
<xtags:parse id="myreport">
<root>
> <childnode></childnode>
</root>
</xtags:parse>
<xtags:style document="<%" %>"">
這樣就不會有 Stream Closed 的錯誤，也解決了之前 Browser 的問題....
2006/11/22
2006/09/10
應該有的心結
最近，客戶希望我幫忙整理一下系統文件，並且也為系統維護人員做一下教育訓練；他希望，如果發生一些問題，可以做一些簡單、初步的處理。其實，這件事他跟我提過好幾次，我同意他的看法，我也認為這是我應該做的事 (而且，如果做的好，還可以減少我的負擔)；然而，實際的工作執行進展，卻與理想差距甚遠。為什麼呢?
理論上，一個系統開發完成後，應該就會有系統文件的產出。所以，所謂的"整理一下系統文件"應該也只不過是把原來的文件做一下整理修改就好；很可惜，不是這樣的，我所產出的系統文件，大概只述說了系統 10% 的事實，而一份只有 10% 的文件，在經過一段時間之後，對我而言，其實用性可能接近於零。要了解為什麼會有這樣的結果，必須了解我的工作流程；不過，在解釋我的工作流程之前，我可以先預測客戶要我"整理一下系統文件"這個工作的最後結果：再做一份涵蓋度只有 10%的系統文件....
OK，下面開始用圖形的方式介紹我的工作流程。這裏不特別對圖形符號多做說明，因為，我好懶。反正，第一張圖是當接到一個工作時，決定執行策略的流程。我們幾乎都是走"分散"的路線，除非這個工作真的被細分到非常的小(1、2個小時)...
接下的第一張圖，就是工作的基礎流程。在這張圖裏面會有一些 "進入：[XX]模式" 的方塊，代表會進入 [XX] 子流程。其中真實的工作模式有四種，也只有經過這四種模式，才會達到工作完成的結果。這四種模式為：[隨便]>顧名思義，就是，隨便了啦...；[決鬥]>就是時間很趕，所以，也有一點隨便了啦...；[真的做]>這種情形，幾乎只發生在程式撰寫的時候(不包括debug)...；[實作練習]>這是我這幾年最常使用的模式。[隨便]、[決鬥]、[真的做]這三種都很容易明白，所以我只對 [實作練習]模式做另外的說明。
接下來，我們來看一下[實作練習]模式。實作練習其是就是因為我們對某項技術的掌握度不足，卻又沒有足夠的練習空間與時間，所以只好用實際的工作來練習。這種運作情形，通常都沒有什麼好結果；比方說以我的情形來看，我的路線通常會變成：沒有把握->很煩->時程逼近->找人討論更煩->隨便啦...
為什麼"找人討論"會更煩呢，那就要看一下接下來的兩張圖。第一張是"準備找人"：
第二張是"討論中"：
有沒發現，我好像常常會進入[煩燥]模式。下面這一張[煩燥]模式的圖；也就是因為經常進入[煩燥]狀態，所以，其實我有一大半的時間都在"發發呆，做雜事"的情形下渡過。
最後，來看一下讓人更加無奈的流程，[下次再說]。這個流程本來就充滿不得已，而且，記住，因為之前的工作被打斷了，所以，就算想起來要從哪裏繼續下去，也都免不了的必須讓腦袋瓜從頭開始。差別只再於，上一次的工作，是否有讓自己了解工作要怎麼做 (有果有的話，可以快樂的進入[真的做])。
好了，回到最上面的問題，今天客戶要我整理系統文件，並且對系統維護人員做教育訓練...如果是要寫使用手冊，並且對使用人員做教育練訓，我大概還有 6成的把握。可是，系統文件到底該怎麼寫，系統維護人員到底該怎麼教，我怎麼可能知道 (有誰知道的，可不可以分享一下呀!?)。好吧，我想我已經進入[煩燥]模式了。我猜，最後大概還是會不得已的進入[決鬥]模式，隨便交差了事...
PS：我在第一張"工作基礎流程圖"的說明，有這麼一段話：「在這張圖裏面會有一些 "進入：[XX]模式" 的方塊，代表會進入 [XX] 子流程」。大家不會想，既然是"子流程"，為什麼不叫"[XX]子流程"就好，偏要叫"[XX]模式"。這是因為，我一開始畫圖的時候，還不清楚我該怎麼畫才好，等到我畫到一個程度，我才發現到原來我的圖的結構會有這樣的階層性，可是，我已經懶得回去改字了。其實，我有一大堆的文件都有這種情形，甚至，我所開發的系統也有這種情形 (原本應該只是雛形，卻愈加愈大，最後還被趕鴉子上架)。這些東西，都會自然的、必然的被我丟到思想的垃圾筒...
2006/09/07
颱瘋天
颱瘋天，被叫來加班
原因是塌非斯系統的產品發不出去 (塌非斯系統 Product 程式會當掉)。查了半天，終於找到了原因，以下說明之：
塌非斯系統有關產品的部分，我們有設計各相關產品的Template
在Template裏有各式 Tag，例:中心位置在北緯[lat00]度
上述由中括號 '[' ']' 包圍的就是資訊 Tag
程式找到資訊 Tag，然後會代換成正確的資料
例:中心位置在北緯[lat00]度 --> 中心位置在北緯21.5度
然而，當天發生了如下的情形：
1: while (String.Pos("[") > 0)
2: {
3: tagstart = String.Pos("[");
4: tagend = String.Pos("]");
5: String = String.Delete
(tagstart,tagend-tagstart+1); //將Tag的字串刪除
6: String = String.Insert
(value,tagstart); //將刪除的字串處插入實際值
7: }
上述是一個 while loop 的程式，在找出 '[' & ']'，並將中間的Tag代換。
下面說明一下，出問題的 Template 與實際資料
Template裏的某一行:
[its] [tyname_ch] [tyname]
上面那一行代換成這次這個颱瘋的實際資料時，應該會是:
三十午度颱瘋 阿珠 ANNCHU
然而，程式在跑的時候，卻是以下的情形
進入loop前：
String="[its] [tyname_ch] [tyname]"
第一次的Loop跑完：
tagstart=1
tagend=5
String="三十五度颱瘋 [tyname_ch] [tyname]"
第二次
tagstart=10
tagend=19
String="三十五度颱瘋 阿珠 [tyname]"
第三次
tagstart=15
tagend=12
String="三十五度颱瘋 阿珠 [tyname]"
第三次跑完時，String 的值沒改變
而且 tagstart > tagend !!!??
接下來，程式就進入無窮迴圈了
(我們的 code review，目的之一就是要避免可能的無窮迴圈)
接下來的問題是，為什麼會進入無窮迴圈!?
原來，"珠"這個字的前半碼，這個BYTE的編碼與 '[' 相同
所以程式第四行處理 "三十五度颱瘋 阿珠 [tyname]" 時
tagend = String.Pos("]") = 12
........................
後來，加班，連夜趕工
把Template裏的Tag通通改成 '[{' '}]'
這樣子的雙位元處理，就不會有這種問題了...
這個事件給我們三個重要經驗
1.中文字的處理
中文字的編碼問題本來就是相當複雜的問題
像之前有同事的做法，將 BCB 的 AnsiString 轉成 WideString
(雙位元字串) 然後再來處理...事實上，也許我們可以考慮
統一使用 UTF-8 來處理字串問題 (包括資料庫的儲存)
大家思考看看吧!!
2.Code Review
這個就是另外提議的項目，可以把文字處理，當做 Code review
的一個項目。
3.客戶服務
這次的這個問題，真的是一開始設計時未思考到的問題。雖然
大多數的時候，客戶有提出的問題，可能都不是問題；或是說
大多數的時候，客戶其實也說不清楚問題是什麼。所以，這時候
乖乖來加班吧...
原因是塌非斯系統的產品發不出去 (塌非斯系統 Product 程式會當掉)。查了半天，終於找到了原因，以下說明之：
塌非斯系統有關產品的部分，我們有設計各相關產品的Template
在Template裏有各式 Tag，例:中心位置在北緯[lat00]度
上述由中括號 '[' ']' 包圍的就是資訊 Tag
程式找到資訊 Tag，然後會代換成正確的資料
例:中心位置在北緯[lat00]度 --> 中心位置在北緯21.5度
然而，當天發生了如下的情形：
1: while (String.Pos("[") > 0)
2: {
3: tagstart = String.Pos("[");
4: tagend = String.Pos("]");
5: String = String.Delete
(tagstart,tagend-tagstart+1); //將Tag的字串刪除
6: String = String.Insert
(value,tagstart); //將刪除的字串處插入實際值
7: }
上述是一個 while loop 的程式，在找出 '[' & ']'，並將中間的Tag代換。
下面說明一下，出問題的 Template 與實際資料
Template裏的某一行:
[its] [tyname_ch] [tyname]
上面那一行代換成這次這個颱瘋的實際資料時，應該會是:
三十午度颱瘋 阿珠 ANNCHU
然而，程式在跑的時候，卻是以下的情形
進入loop前：
String="[its] [tyname_ch] [tyname]"
第一次的Loop跑完：
tagstart=1
tagend=5
String="三十五度颱瘋 [tyname_ch] [tyname]"
第二次
tagstart=10
tagend=19
String="三十五度颱瘋 阿珠 [tyname]"
第三次
tagstart=15
tagend=12
String="三十五度颱瘋 阿珠 [tyname]"
第三次跑完時，String 的值沒改變
而且 tagstart > tagend !!!??
接下來，程式就進入無窮迴圈了
(我們的 code review，目的之一就是要避免可能的無窮迴圈)
接下來的問題是，為什麼會進入無窮迴圈!?
原來，"珠"這個字的前半碼，這個BYTE的編碼與 '[' 相同
所以程式第四行處理 "三十五度颱瘋 阿珠 [tyname]" 時
tagend = String.Pos("]") = 12
........................
後來，加班，連夜趕工
把Template裏的Tag通通改成 '[{' '}]'
這樣子的雙位元處理，就不會有這種問題了...
這個事件給我們三個重要經驗
1.中文字的處理
中文字的編碼問題本來就是相當複雜的問題
像之前有同事的做法，將 BCB 的 AnsiString 轉成 WideString
(雙位元字串) 然後再來處理...事實上，也許我們可以考慮
統一使用 UTF-8 來處理字串問題 (包括資料庫的儲存)
大家思考看看吧!!
2.Code Review
這個就是另外提議的項目，可以把文字處理，當做 Code review
的一個項目。
3.客戶服務
這次的這個問題，真的是一開始設計時未思考到的問題。雖然
大多數的時候，客戶有提出的問題，可能都不是問題；或是說
大多數的時候，客戶其實也說不清楚問題是什麼。所以，這時候
乖乖來加班吧...
2006/08/31
整合服務的初淺想法
網站、EMail、新聞、BLOG、相簿、行事曆、網拍，這幾個服務可以說是這幾年網路服務的主軸；然而，如果只是單以提供這些服務作為述求，似乎都會進入一個瓶頸:"只能搶免費會員，卻收不到錢"。未來，這些服務應該會走向整合，可是怎麼走呢!?個人覺得，應該會以一些前端技術(如AJAX)，讓使用者作自我發揮的個性化整合，而後端則是提供獨立的服務資訊，也就是走向SOA (服務導向架構)。開水這裏只是幻想一個可能情形，來試著思考這個所謂SOA的東東的可能方向。
先假設一個情形：用WebMail的好處在於可以在不同的地方、用不同的機器，只要能上網，就可以使用；而缺點就是整體介面的使用上較不方便。如果是用一般郵件程式處理信件(如outlook)，是比較方便，可是就不能到處用。於是，開水想，用 FireFox 的擴充套件技術，配上 AJAX 技術，整合一個具有前端程式功能的 Web Mail 服務。下圖是用這個想法做出來的介面示意圖：
左上角是信件的資料夾，左下角還加上了一週行事曆，其他的操作就跟一般的 outlook express 一樣，真好! 如果要對信件作歸類，直接用滑鼠拖曳信件到指定的資料夾即可；如果要刪除信件，直接按delete；如果要看信，就直接 Double Click，如下圖：
如果要編輯郵件呢!?就像 outlook 一樣編輯就行啦! 最厲害的是，用滑鼠從檔案總管直接拖曳"附加檔案" (使用Web Mail 要附加檔案是很痛苦的)。
當然，不只這樣，現在的人可不是寄寄文字郵件就滿足的了，要就要"圖文並茂"；下圖是直接從檔案總管拉圖檔，而郵件編輯時，還可以有點像Frontpage，編出圖繞文效果：
還有更厲害的，直接從網路相簿拉圖：
而且，只要配合Blog提供的功能(Post Mail Address)，就可以把這封E-Mail，Post 到個人的 Blog 上，真是太棒了....
要作到上述功能，基本上就必須整合"EMail"、"行事曆"、"網路相簿"與"Blog"服務，實際發展起來，是有難度的。這裏面有三個不同向面的關鍵軸：(1).前端介面：例用如Web2.0或是AJAX技術，以開放源碼方式，建立個性化能量。(2).後端服務：由服務提供源提供具可整合性的獨立服務產品(也是可以賺錢的地方)。(3).中間媒介：這個應該就是建立某種XML標準，讓後端服務具有可整合性，而前端可以容易整合；然而，這個中間媒介也是目前最無所施力的地方(尤其是台灣中小企業居多的情形)；除非有人有力量領導中小企業整合發展(不要再在紅海裏廝殺)，不然的話....是不是應該會是"資訊化社會的推手"的責任!!??
先假設一個情形：用WebMail的好處在於可以在不同的地方、用不同的機器，只要能上網，就可以使用；而缺點就是整體介面的使用上較不方便。如果是用一般郵件程式處理信件(如outlook)，是比較方便，可是就不能到處用。於是，開水想，用 FireFox 的擴充套件技術，配上 AJAX 技術，整合一個具有前端程式功能的 Web Mail 服務。下圖是用這個想法做出來的介面示意圖：
左上角是信件的資料夾，左下角還加上了一週行事曆，其他的操作就跟一般的 outlook express 一樣，真好! 如果要對信件作歸類，直接用滑鼠拖曳信件到指定的資料夾即可；如果要刪除信件，直接按delete；如果要看信，就直接 Double Click，如下圖：
如果要編輯郵件呢!?就像 outlook 一樣編輯就行啦! 最厲害的是，用滑鼠從檔案總管直接拖曳"附加檔案" (使用Web Mail 要附加檔案是很痛苦的)。
當然，不只這樣，現在的人可不是寄寄文字郵件就滿足的了，要就要"圖文並茂"；下圖是直接從檔案總管拉圖檔，而郵件編輯時，還可以有點像Frontpage，編出圖繞文效果：
還有更厲害的，直接從網路相簿拉圖：
而且，只要配合Blog提供的功能(Post Mail Address)，就可以把這封E-Mail，Post 到個人的 Blog 上，真是太棒了....
要作到上述功能，基本上就必須整合"EMail"、"行事曆"、"網路相簿"與"Blog"服務，實際發展起來，是有難度的。這裏面有三個不同向面的關鍵軸：(1).前端介面：例用如Web2.0或是AJAX技術，以開放源碼方式，建立個性化能量。(2).後端服務：由服務提供源提供具可整合性的獨立服務產品(也是可以賺錢的地方)。(3).中間媒介：這個應該就是建立某種XML標準，讓後端服務具有可整合性，而前端可以容易整合；然而，這個中間媒介也是目前最無所施力的地方(尤其是台灣中小企業居多的情形)；除非有人有力量領導中小企業整合發展(不要再在紅海裏廝殺)，不然的話....是不是應該會是"資訊化社會的推手"的責任!!??
Powered by ScribeFire.
2006/01/20
前置需求分析作業
背景
客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。
需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…
運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
(1).先討論這件事的程度，意思是說，也許根本可以不理他…
(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
(1).系統需求分析 (這個步驟可能也會重覆好幾次)
將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
A.對四個面向分別討論已知及未知項目
B.連結各面向關係，檢視彼此衝突
C.重覆A、B動作，直到沒有疑慮
D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…
參考事項－需求分析
需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。
1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。
2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。
3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。
4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…
客戶想要幹什麼的時候! 有時候，也有可能是，老闆想要幹什麼的時候! 最常發生的時機，大概都會是在年度快結束，準備要談下年度的工作的時候。
需求內容
也就是客戶說他想要幹什麼的內容，通常會包含有三種資訊：
1.故事：誰想做什麼?
過去怎麼做的；現在我們想要改成什麼樣子，或是增加什麼功能；未來最好可以保留什麼彈性，以方便增加什麼東西。
2.限制：誰? 什麼時候? 在哪裏? 跟什麼搭配?
預報員於預報作業時間，在預報中心的主機，讀取GFE的資料，編輯產品後，送給機務課負責傳送…
3.相關配合工作：
請你們幫忙Survey什麼技術，幫我們的人做教育訓練，還要有一些文件可以給我們…
運作執行
好了，我們接到客戶提出來的需求了，接下來呢…
1.先開一個會，擬定策略
(1).先討論這件事的程度，意思是說，也許根本可以不理他…
(2).確立權責與關鍵人員：這項工作的對象包括我方與對方；誰是這項任務的負責人與關鍵人員，這很重要!!
(3).建立溝通管道：對於這樣子的負責人與關鍵人員，應該有什麼樣的管道；是要集合所有關鍵人員一起開會，還是各個擊破，還是對單一窗口就好?
(4).訂立時程規劃：以上確定後，就可以來訂定時程，時程的規劃，主要會包含[步驟2.]，而且可能會重覆3~4次；時程人力的預估，應該會依需求內容之不同而有不同。不過，我們現在還沒有足夠的統計資訊，所以可以先憑經驗，大家有共識即可。
2.開始認真工作 (這個步驟可能會重覆3~4次)
(1).系統需求分析 (這個步驟可能也會重覆好幾次)
將客戶提出的故事、限制等等東東，分解成為四種圖，可以看一下本文件後面 [參考事項-需求分析] 一節。
A.對四個面向分別討論已知及未知項目
B.連結各面向關係，檢視彼此衝突
C.重覆A、B動作，直到沒有疑慮
D.討論相關配合工作：這個項目的討論，跟上面的系統開發，好像比較沒有什麼關係，似乎只要能釐清就好…
E.整理記錄，安排下一階段工作，可能的工作像是：找哪一個客戶確認什麼事情；了解一下什麼技術…
(2).人力預估：對上面討論的結果，主要是已知的部份，包括模組與元件的開發以及配合的工作項目，估計人力成本。因為，在與客戶反覆討論與確認的過程中，人力資訊可能會是客戶做決定的一個參考指標。
(3).與客戶討論與確認：最好都能留下會議記錄。
3.撰寫規格書&建議書：到了這個階段，寫這些東西應該就不是什麼難事了…
參考事項－需求分析
需求分析的工作，應該會要有下面的四種圖，而這四種圖之間會有連結與衝突之關係，實際的需求分析工作，其實就在於了解之間的關連並解決彼此的衝突。每一個圖都應該會有已知的部份以及未知的部分，所以實際畫圖時，可能會畫出不只一張圖；例如，對於未知的使用者操作流程，我們可能就可以先行假設2~3種不同的建議。
1.使用案例圖：即是UML裏的UseCase，一個系統可能會有好幾個不同的UseCase，每一個UseCase應該會是一個獨立的作業流程。以QPF為例：[預報編輯]與[預報校驗]會是兩個不同的UseCase。當然，系統夠大才會需要UseCase；像TED系統，預報員的作業是一次從頭做到尾(選擇條件、編輯、傳送)，其實就只有一個UseCase，所以也就不需要案例圖了。
2.作業流程圖：這是從使用者角度觀看的操作流程，只要把使用者會知道、會看到的部份寫上去就行了。建議可以是UML的Activity Diagram。
3.資料流程圖：以氣象局為例，客戶很重視資料(包含產品)如何流動；所以，必需將資料流程清楚表現。建議可以用DFD，但是，最好是與 [作業流程圖] 搭配，不要把圖畫的太複雜。
4.模組元件圖：這個會是以系統開發人員的角度來畫的圖，也是以後系統開發設計時，主要的參考資料。所以，必須十分注意，模組與元件的完整性，以及介面的相關性。因為，這些資訊會變成一個系統的架構，也就是說，以後如果有新的需求是要變更這個架構，會累死人的…
2006/01/05
從實務到理論-2
在上一篇文章中，雖然強調了「第一步，先將自己的實務理論化」，不過卻沒有明確指出「實務理論化」這件事情，在整個論述裏所佔有之地位。所以，本篇補述希望試著說明所提之論述之整體架構意象，讓大家能對這篇文章有更深入的了解。
先談談這份論述所希望表達的事項。這裏其實是先假設，「從理論到實務」是很重要的 (或是說，不斷的改革與創新是很重要的) ，而為了這個很重要的事，我們 (公司或是個人) ，真實面對理論實務化之執行時，對於所遇到之障礙、困擾，反省檢討策略之執行改進方向之際，應該可以從更深層的原點而反思。或是這麼說吧：「如果我們反省檢討時發現，相似的問題總是不斷被發現，而相似的解決方法也總是被當成策略結論，那麼，很有可能，這個問題是來自於更深層的關鍵原因」。
另外，在前一篇文章「從數學而上」裏，隱含著一種「危機與轉機」的意念，而這個意念背後，其所想要表達的，即在於「觀念轉換」的重要性與困難性。觀念轉換本身就是一個意味不明之表徵；要轉什麼? 要換什麼? 怎麼轉? 怎麼換? 上述幾個問號，對於我們這群以舊有的「行為取向主義」之教學方式所教出來的學生，要求重新反思原有先備知識的建構過程與動機，進而從中推尋出資訊鏈結關係之可行的不同架構模式 (創新與創意) ，這幾乎可以說是強人所難。所以，說台灣人創意不足，或是說台灣產業不願投資研發，唯一可以根治的方法，大概也只能期待 "十年樹木，百年樹人" 了。
當然，這樣想太悲觀，也許可以試著找尋其他的方法，來幫助我們思考「從危機到轉機的關鍵轉捩點」。什麼方法呢? 假設，關鍵轉捩點之所以不易被發覺，其實是因為這個轉捩點被隱藏在資訊與資訊的鏈結之中：從一個資訊單體演生轉化成為另一個資訊單體的鏈結過程，我稱為"知識跳躍" (也許也可以稱為"成見"，只是覺得單就"成見"二字的原意，似乎不足以表達) 。如果，假設，"知識跳躍"之問題的解決，可以改善"觀念轉換擁塞"之情形，那麼，希望，"實務理論化"，可以幫助思考與發現我們的"知識跳躍"問題，進而幫助改善我們創新思考不足的情形，從而幫助我們找尋「從危機到轉機的關鍵轉捩點」。至於，什麼是"知識跳躍"，建議可以從"建構式數學"裏去思考答案，如果有機會，再討論吧....
先談談這份論述所希望表達的事項。這裏其實是先假設，「從理論到實務」是很重要的 (或是說，不斷的改革與創新是很重要的) ，而為了這個很重要的事，我們 (公司或是個人) ，真實面對理論實務化之執行時，對於所遇到之障礙、困擾，反省檢討策略之執行改進方向之際，應該可以從更深層的原點而反思。或是這麼說吧：「如果我們反省檢討時發現，相似的問題總是不斷被發現，而相似的解決方法也總是被當成策略結論，那麼，很有可能，這個問題是來自於更深層的關鍵原因」。
另外，在前一篇文章「從數學而上」裏，隱含著一種「危機與轉機」的意念，而這個意念背後，其所想要表達的，即在於「觀念轉換」的重要性與困難性。觀念轉換本身就是一個意味不明之表徵；要轉什麼? 要換什麼? 怎麼轉? 怎麼換? 上述幾個問號，對於我們這群以舊有的「行為取向主義」之教學方式所教出來的學生，要求重新反思原有先備知識的建構過程與動機，進而從中推尋出資訊鏈結關係之可行的不同架構模式 (創新與創意) ，這幾乎可以說是強人所難。所以，說台灣人創意不足，或是說台灣產業不願投資研發，唯一可以根治的方法，大概也只能期待 "十年樹木，百年樹人" 了。
當然，這樣想太悲觀，也許可以試著找尋其他的方法，來幫助我們思考「從危機到轉機的關鍵轉捩點」。什麼方法呢? 假設，關鍵轉捩點之所以不易被發覺，其實是因為這個轉捩點被隱藏在資訊與資訊的鏈結之中：從一個資訊單體演生轉化成為另一個資訊單體的鏈結過程，我稱為"知識跳躍" (也許也可以稱為"成見"，只是覺得單就"成見"二字的原意，似乎不足以表達) 。如果，假設，"知識跳躍"之問題的解決，可以改善"觀念轉換擁塞"之情形，那麼，希望，"實務理論化"，可以幫助思考與發現我們的"知識跳躍"問題，進而幫助改善我們創新思考不足的情形，從而幫助我們找尋「從危機到轉機的關鍵轉捩點」。至於，什麼是"知識跳躍"，建議可以從"建構式數學"裏去思考答案，如果有機會，再討論吧....
從實務到理論-1
只要有人類的生活，就會有問題的產生；只要有問題，就會有人思考如果解決問題。於是，當人們在思考問題之解決時，或是在尋找改進的方向時，最初最原始的開始，一定是從實務處理上，做抽絲剝繭的分析，將問題發生的進程，切割成為各自小的單元体，然後再逐一找尋問題發生所觸動之關鍵因子，從而尋求問題解決或改進之方法。事實上，對應在程式撰寫，當發現程式有問題，不也是用相類似的方法除蟲嗎!?
好了，當問題能夠獲致解決，接下來的思考方向便是「如何將這個問題的解決方法傳承下去」。在過去，智慧還不算是財產的時候，多數人大都是抱著藏私之心，守著祖傳祕方，等著後繼有。到了現代，情形當然是大有不同，可是，有關「如何傳承」這個基本的問題仍然存在。寫下來，大概是最快最有效的方法了。其實，打從人類有文字以來，用這個方法所傳承下來的過去的知識與經驗，在在與我們生活有著切合的相依性。打從我們開始學習，從小學開始，歷史、地理、國文、數學，都是文字傳承經驗的確切實例。所以，寫文件，很重要...(不過，我討厭寫文件)
再繼續衍生下去，當我們處理了傳承的問題，接下來遇到的就是「如何有效的傳承」。我們從「寫文件」這件事來思考 (假設寫文件真的是有益的) ，「如何寫一篇他人看得懂的文件」、「他人是否能依照文件內之描述來處理問題」、「他人是否能快速的從文章裏找到所需的解」。寫作文，我們講求「起承轉合」。之所以如此要求，是因為這樣子的效果，最能夠迎合人類接收訊息時的情緒轉化，使得訊息的傳達與吸收，能得到最高效率 (有關學習與教育的問題，在很多知識建構主義理論裏，可以找到論証，這裏先不細說) 。回過頭來，不討論作文怎麼寫，而來討論一份「資訊系統技術文件」，從我們現行的作業裏，就可以找到我們的解決之道「文件格式化」。我想，我們不需要在這裏多做說明，為什麼文件要有標準格式；為什麼文件規定要有某某章節...(雖然，我覺得，很煩!)
我們再回頭來看，在上一段的論述中，討論「如何有效的傳承」論點時，我們舉了例子「文件格式化」。在這個例子裏，其實就隱藏著本文的重點論述：「文件如何被格式化」，或是這麼說「如何決定文件要有哪些章節」。假設，我們是時代的先驅；假設，我們是全世界第一家資訊系統開發公司；假設，我們是第一群發現與思考「文件格式化」問題的人。我們該怎麼做? 分析實務進程，切割領域單元，釐清個體關係，然後為不同的單元個體命名，而這些單元體的名稱，就成了文件章節名稱的基礎。
理論必需搭配實務，我想，這句話，大家應該多能心有所感。理論研究的起始，本就是從實務而生，即便有些理論是架構在其他的理論上而演生，其最原始的基礎，依然在於實務。對現代社會而言，「實務理論化」本身就是一種專門學問的研究。通常、一般、大多數人，多是只知如何用，而不知為何可以用 (反過來，一般人在面對理論時，則容易有 "知道 Why，卻不知 How" 的感慨) 。記得以前求學時，好像曾經聽過這麼一個故事 (我不記得是從哪裏聽到的了) --當年，孫中山先生在倡導三民主義時，曾提倡「知難行易」說，因為當時很多人反應聽不懂三民主義，所以不知如何執行。國父舉了這麼一個例子：「大家都知道錢可以用，但很少人知道錢為何可以用」。當初聽到這個例子的時候，我還真的想了很久，思考著錢為何可以用。當然，後來是有想通為什麼，不過，在這個例子的後面，值得我們反思的問題在於，我們的實務作業上，是不是有很多情形，都是知 How，但不知 Why?
「理論必需搭配實務」，所可以反思的方向，即是「實務是否可以理論化」。當然，在上一段的論述裏說「實務理論化本身就是一種專門學問的研究」，這其實是社會分工精緻化的必然結果。所以，真的想把實務經驗化做理論論述，不是一件簡單的事。畢竟，實務情形總是複雜的，幾乎不可能 (絕對不可能) 用單一的理論構面架構而成。所以，一個「策略規劃」理論，可以有五、有九說，相不相信還可以有十三說、八百說....如前面所述，理論的研究可以說是實務的分解過程，至於這項理論的論述是否足夠完整，則取決於實務項目的採樣數與有效性。所以理論不可能完整表述實務過程，正因為如此，一個人的實務經驗，才會擁有超越書本、超越文件、超越理論研究的終極價值。 (終極價值：在人類被機器淘汰前，都應該不至抹滅的價值)
再一次強調，理論研究的目的，本就不是用來取代實務，而是為了提高知識傳承效率、降低學習門檻、加快進入實務的速度，所產生的實務改進方向指標，這個指標，才是理論存在的目的。什麼是理論，而什麼是實務? 就現代角度來看，理論研究應是學者、教授所處理之事務，而實務則被認為執行者所擔負的責任。這個論點，個人覺得並沒有錯。當我們思考「錢為何可用」的時，就應該會發現，分工的細緻化，是這個社會不斷演進的必然過程。只是，這樣子分工的結果，容易導至"好高騖遠"的理論對上"表面功夫"的實務情形，就是我們現在這個樣子!!
好了，不管我們同不同意上一段論述的結論，我們都應該可以、懂得省思自己。我們問自己，什麼樣的理論是會讓人可以實務的理論：答案應該很簡單，有實務經驗的人所提出的理論。反過，怎麼做可以做到理論實務化：第一步，先將自己的實務理論化。
後記：為何要思考「從實務到理論」
假設我們收到一個客戶提出的需求，希望我們幫忙改進客戶的資訊系統。接到這樣的需求訊息，第一步應該會先考量：是要修改原有系統，還是要重新建立新的系統!? (假設我們已經確定必需接受這個需求) 。做系統開發的人，應該多有感觸，有時候，重新建立一個系統，可能要比修改原有系統來的有效率。可惜，這樣子的情形，不大可能發生在組織身上。假設，今天組織要有所變革、組織要有所進步、組織要有所成長，直接把人換掉說不定是最有效的方法，卻也是最難以實現的方法。化做個人來看，成年人學習效率一般都不如年青人，其中的最大障礙，其實是在於「既有成見」。二十世紀以後，受到胡塞爾的現象學、海德洛的存在哲學、高達美的詮釋學等等的影嚮，產生了有別於以往實証主義學習法的「建構主義」論 (有興趣者，建議可先看看皮亞傑的認知建構論) 。「建構主義提出知識是由學習者所自行主動建構的，而非被動的由外界灌輸；知識是建構的歷程，並強調學生先前或先備知識的重要性，主張學習者學習時，應整理統合新的與舊有先備的知識。」 (以上文章取自「科技與學習--理論與實務」一書，心理出版社--沈中偉著)。 上述文章所提的先備知識，其實也就是既有成見的原始相貌，而新舊知識的統整能力，其實也就是一個人學習能力的指標。所以一個年紀愈大的人，擁有的先備知識愈豐富，其新舊知識的統合自然就必需花費更多的時間與精力。所以，很多老師在面對成人教學前，常會希望學員能拋棄成見，將心思放空，就是期望能減少新舊知識的統合所產生的摩擦，以增加學習效率。只是，以現在新的建構主義理論來看，這是不應該也不可能辦到的。這就像是公司要學習一個新的理論技術，要求公司放棄現有的執行模式一樣，乾脆另外開一家新公司算了....
好了，當問題能夠獲致解決，接下來的思考方向便是「如何將這個問題的解決方法傳承下去」。在過去，智慧還不算是財產的時候，多數人大都是抱著藏私之心，守著祖傳祕方，等著後繼有。到了現代，情形當然是大有不同，可是，有關「如何傳承」這個基本的問題仍然存在。寫下來，大概是最快最有效的方法了。其實，打從人類有文字以來，用這個方法所傳承下來的過去的知識與經驗，在在與我們生活有著切合的相依性。打從我們開始學習，從小學開始，歷史、地理、國文、數學，都是文字傳承經驗的確切實例。所以，寫文件，很重要...(不過，我討厭寫文件)
再繼續衍生下去，當我們處理了傳承的問題，接下來遇到的就是「如何有效的傳承」。我們從「寫文件」這件事來思考 (假設寫文件真的是有益的) ，「如何寫一篇他人看得懂的文件」、「他人是否能依照文件內之描述來處理問題」、「他人是否能快速的從文章裏找到所需的解」。寫作文，我們講求「起承轉合」。之所以如此要求，是因為這樣子的效果，最能夠迎合人類接收訊息時的情緒轉化，使得訊息的傳達與吸收，能得到最高效率 (有關學習與教育的問題，在很多知識建構主義理論裏，可以找到論証，這裏先不細說) 。回過頭來，不討論作文怎麼寫，而來討論一份「資訊系統技術文件」，從我們現行的作業裏，就可以找到我們的解決之道「文件格式化」。我想，我們不需要在這裏多做說明，為什麼文件要有標準格式；為什麼文件規定要有某某章節...(雖然，我覺得，很煩!)
我們再回頭來看，在上一段的論述中，討論「如何有效的傳承」論點時，我們舉了例子「文件格式化」。在這個例子裏，其實就隱藏著本文的重點論述：「文件如何被格式化」，或是這麼說「如何決定文件要有哪些章節」。假設，我們是時代的先驅；假設，我們是全世界第一家資訊系統開發公司；假設，我們是第一群發現與思考「文件格式化」問題的人。我們該怎麼做? 分析實務進程，切割領域單元，釐清個體關係，然後為不同的單元個體命名，而這些單元體的名稱，就成了文件章節名稱的基礎。
理論必需搭配實務，我想，這句話，大家應該多能心有所感。理論研究的起始，本就是從實務而生，即便有些理論是架構在其他的理論上而演生，其最原始的基礎，依然在於實務。對現代社會而言，「實務理論化」本身就是一種專門學問的研究。通常、一般、大多數人，多是只知如何用，而不知為何可以用 (反過來，一般人在面對理論時，則容易有 "知道 Why，卻不知 How" 的感慨) 。記得以前求學時，好像曾經聽過這麼一個故事 (我不記得是從哪裏聽到的了) --當年，孫中山先生在倡導三民主義時，曾提倡「知難行易」說，因為當時很多人反應聽不懂三民主義，所以不知如何執行。國父舉了這麼一個例子：「大家都知道錢可以用，但很少人知道錢為何可以用」。當初聽到這個例子的時候，我還真的想了很久，思考著錢為何可以用。當然，後來是有想通為什麼，不過，在這個例子的後面，值得我們反思的問題在於，我們的實務作業上，是不是有很多情形，都是知 How，但不知 Why?
「理論必需搭配實務」，所可以反思的方向，即是「實務是否可以理論化」。當然，在上一段的論述裏說「實務理論化本身就是一種專門學問的研究」，這其實是社會分工精緻化的必然結果。所以，真的想把實務經驗化做理論論述，不是一件簡單的事。畢竟，實務情形總是複雜的，幾乎不可能 (絕對不可能) 用單一的理論構面架構而成。所以，一個「策略規劃」理論，可以有五、有九說，相不相信還可以有十三說、八百說....如前面所述，理論的研究可以說是實務的分解過程，至於這項理論的論述是否足夠完整，則取決於實務項目的採樣數與有效性。所以理論不可能完整表述實務過程，正因為如此，一個人的實務經驗，才會擁有超越書本、超越文件、超越理論研究的終極價值。 (終極價值：在人類被機器淘汰前，都應該不至抹滅的價值)
再一次強調，理論研究的目的，本就不是用來取代實務，而是為了提高知識傳承效率、降低學習門檻、加快進入實務的速度，所產生的實務改進方向指標，這個指標，才是理論存在的目的。什麼是理論，而什麼是實務? 就現代角度來看，理論研究應是學者、教授所處理之事務，而實務則被認為執行者所擔負的責任。這個論點，個人覺得並沒有錯。當我們思考「錢為何可用」的時，就應該會發現，分工的細緻化，是這個社會不斷演進的必然過程。只是，這樣子分工的結果，容易導至"好高騖遠"的理論對上"表面功夫"的實務情形，就是我們現在這個樣子!!
好了，不管我們同不同意上一段論述的結論，我們都應該可以、懂得省思自己。我們問自己，什麼樣的理論是會讓人可以實務的理論：答案應該很簡單，有實務經驗的人所提出的理論。反過，怎麼做可以做到理論實務化：第一步，先將自己的實務理論化。
後記：為何要思考「從實務到理論」
假設我們收到一個客戶提出的需求，希望我們幫忙改進客戶的資訊系統。接到這樣的需求訊息，第一步應該會先考量：是要修改原有系統，還是要重新建立新的系統!? (假設我們已經確定必需接受這個需求) 。做系統開發的人，應該多有感觸，有時候，重新建立一個系統，可能要比修改原有系統來的有效率。可惜，這樣子的情形，不大可能發生在組織身上。假設，今天組織要有所變革、組織要有所進步、組織要有所成長，直接把人換掉說不定是最有效的方法，卻也是最難以實現的方法。化做個人來看，成年人學習效率一般都不如年青人，其中的最大障礙，其實是在於「既有成見」。二十世紀以後，受到胡塞爾的現象學、海德洛的存在哲學、高達美的詮釋學等等的影嚮，產生了有別於以往實証主義學習法的「建構主義」論 (有興趣者，建議可先看看皮亞傑的認知建構論) 。「建構主義提出知識是由學習者所自行主動建構的，而非被動的由外界灌輸；知識是建構的歷程，並強調學生先前或先備知識的重要性，主張學習者學習時，應整理統合新的與舊有先備的知識。」 (以上文章取自「科技與學習--理論與實務」一書，心理出版社--沈中偉著)。 上述文章所提的先備知識，其實也就是既有成見的原始相貌，而新舊知識的統整能力，其實也就是一個人學習能力的指標。所以一個年紀愈大的人，擁有的先備知識愈豐富，其新舊知識的統合自然就必需花費更多的時間與精力。所以，很多老師在面對成人教學前，常會希望學員能拋棄成見，將心思放空，就是期望能減少新舊知識的統合所產生的摩擦，以增加學習效率。只是，以現在新的建構主義理論來看，這是不應該也不可能辦到的。這就像是公司要學習一個新的理論技術，要求公司放棄現有的執行模式一樣，乾脆另外開一家新公司算了....
訂閱：
文章 (Atom)
