2006年7月19日 星期三

[JAVA] 常用的檢查機制

JAVA 常用的檢查機制
身分證字號,IP,Email,門號,關鍵字過濾等檢查功能

package com.info.website.util;

import java.util.regex.Pattern;
/**
*
* <p>Title: 常用的檢查機制</p>
* <p>Description:身分證字號,IP,Email,門號,關鍵字過濾等檢查功能 </p>
* <p>Copyright: Copyright (c) 2006</p>
* <p>Company:InfoTech Ltd. http://www.info.com.tw</p>
*
* @author Tommy Kao, PMP <tommy@info.com.tw>
* @version 1.0
* @since 2006/07/19
*/

public class Validator {
private static final Pattern ASCII_PATTERN = Pattern
.compile("[\x00-\x7F]*");
public static boolean isPureASCII(String msg) {
boolean result = false;
if (ASCII_PATTERN.matcher(msg).matches()) {
result = true;
}
return result;
}

/**
* IP Address 檢查程式
* @since 2006/07/19
**/

public static boolean isValidIPAddr(String msg) {
boolean result = true;
String []tmp = msg.split(".");
if (tmp.length<=4) {
for (int i = 0; i < tmp.length; i++) {
if (Integer.parseInt(tmp[i]) > 255) {
result = false;
}
}
}
return result;
}

/**
* 手機門號檢查程式
* @since 2006/07/19
**/

public static final Pattern MSISDN_PATTERN = Pattern
.compile("[+-]?\d{10,12}");
public static boolean isValidMSISDN(String msisdn) {
boolean result = false;
if (MSISDN_PATTERN.matcher(msisdn).matches()) {
result = true;
}
return result;
}

public static final Pattern EMAIL_PATTERN = Pattern
.compile("^\w+\.*\w+@(\w+\.){1,5}[a-zA-Z]{2,3}$");
/**
* Email 格式檢查程式
* @since 2006/07/19
**/

public static boolean isValidEmail(String email) {
boolean result = false;
if (EMAIL_PATTERN.matcher(email).matches()) {
result = true;
}
return result;
}

public static final Pattern TWPID_PATTERN = Pattern
.compile("[ABCDEFGHJKLMNPQRSTUVXYWZIO][12]\d{8}");
/**
* 身分證字號檢查程式,身分證字號規則:
* 字母(ABCDEFGHJKLMNPQRSTUVXYWZIO)對應一組數(10~35),
* 令其十位數為X1,個位數為X2;( 如A:X1=1 , X2=0 );D表示2~9數字
* Y = X1 + 9*X2 + 8*D1 + 7*D2 + 6*D3 + 5*D4 + 4*D5 + 3*D6 + 2*D7+ 1*D8 + D9
* 如Y能被10整除,則表示該身分證號碼為正確,否則為錯誤。
* 臺北市(A)、臺中市(B)、基隆市(C)、臺南市(D)、高雄市(E)、臺北縣(F)、
* 宜蘭縣(G)、桃園縣(H)、嘉義市(I)、新竹縣(J)、苗栗縣(K)、臺中縣(L)、
* 南投縣(M)、彰化縣(N)、新竹市(O)、雲林縣(P)、嘉義縣(Q)、臺南縣(R)、
* 高雄縣(S)、屏東縣(T)、花蓮縣(U)、臺東縣(V)、金門縣(W)、澎湖縣(X)、
* 陽明山(Y)、連江縣(Z)
* @since 2006/07/19
*/

public static boolean isValidTWPID(String twpid) {
boolean result = false;
String pattern = "ABCDEFGHJKLMNPQRSTUVXYWZIO";
if (TWPID_PATTERN.matcher(twpid.toUpperCase()).matches()) {
int code = pattern.indexOf(twpid.toUpperCase().charAt(0)) + 10;
int sum = 0;
sum = (int) (code / 10) + 9 * (code % 10) + 8 * (twpid.charAt(1) - '0')
+ 7 * (twpid.charAt(2) - '0') + 6 * (twpid.charAt(3) - '0')
+ 5 * (twpid.charAt(4) - '0') + 4 * (twpid.charAt(5) - '0')
+ 3 * (twpid.charAt(6) - '0') + 2 * (twpid.charAt(7) - '0')
+ 1 * (twpid.charAt(8) - '0') + (twpid.charAt(9) - '0');
if ( (sum % 10) == 0) {
result = true;
}
}
return result;
}

public static final Pattern TWBID_PATTERN = Pattern
.compile("^[0-9]{8}$");
/**
* 營利事業統一編號檢查程式
* 可至 http://www.etax.nat.gov.tw/ 查詢營業登記資料
* @since 2006/07/19
*/

public static boolean isValidTWBID(String twbid) {
boolean result = false;
String weight = "12121241";
boolean type2 = false; //第七個數是否為七
if (TWBID_PATTERN.matcher(twbid).matches()) {
int tmp = 0, sum = 0;
for (int i = 0; i < 8; i++) {
tmp = (twbid.charAt(i) - '0') * (weight.charAt(i) - '0');
sum += (int) (tmp / 10) + (tmp % 10); //取出十位數和個位數相加
if (i == 6 && twbid.charAt(i) == '7') {
type2 = true;
}
}
if (type2) {
if ( (sum % 10) == 0 || ( (sum + 1) % 10) == 0) { //如果第七位數為7
result = true;
}
} else {
if ( (sum % 10) == 0) {
result = true;
}
}
}
return result;
}

public static boolean isValidQueryString(String sqlStr) {
if (sqlStr == null || sqlStr.length() <= 0 || sqlStr.indexOf("@") >= 0 ||
sqlStr.indexOf("'") >= 0 || sqlStr.indexOf("_") >= 0 ||
sqlStr.indexOf(""") >= 0 || sqlStr.indexOf("%") >= 0 ||
sqlStr.indexOf("=") >= 0) {
// "關鍵字不可包含 ( @ ' % _ = ) 等字元n";
return false;
}
return true;
}
}

2006年4月21日 星期五

建構管理概念

建構管理 (Configuration Management) 概念

建構管理概念

2006年4月1日 星期六

研發基本能力 <4>

怎樣擬定建構管理計畫呢?建議的做法是:
1. 了解需求
2. 進行系統架構規劃並完成一份系統發展計畫
3. 依據系統發展計畫思考並規劃符合本研發專案的建構管理作業方式

假設我們需要研發一套系統,系統本身必須處理客戶訂單、管理庫存與進出貨物,當需求交到研發單位後,我們依照經驗將系統架構切割成進貨管理、庫存管理與銷貨管理三個子系統(進、銷、存),有了系統架構後,我們便以此資料擬訂建構管理計畫,透過建構計畫說明本研發專案建構管理準則,計畫內容包含:建構管理的目的、工作環境(工具)、人員權責、變更管理流程、建構項目(Configuration Item)、版本基線(Baseline)、建構稽核(Audit)與稽核報告格式等;


建構項目(Configuration Item)指的就是我們打算要管理的項目,例如:需求清單、專案計畫、系統分析文件、系統設計文件、原始程式碼、測試計劃、測試報告、使用者操作手冊…等,在本案例中,我們可以將全系統當作是一個大的建構項目,也可以將進、銷、存分成三個建構項目,甚至再往下繼續分割,分割方式端看怎樣管理比較有效率而定。在此,筆者建議各位,配合系統架構規劃建構項目是比較好的方式,本案例中,筆者為了說明方便把進、銷、存當作三個不同的建構項目來管理研發過程中的所有變動。

產品研發的參考基準就是所謂的基線(Baseline),基線的概念有點類似拍照留念,基線的用意主要在彰顯產品研發過程的特定工作成果或里程碑,當研發單位完成重大階段性任務如:分析、設計、開發、測試、整合、上線…等,可以利用建構管理的版本管理機制,將各個工作成果統合起來並拉出一條參考基線,所有研發工程師便可以站在基線(巨人)的肩膀上看世界。

本案例的建構管理過程可以參考下圖,研發專案剛開始的時候,主要的工作內容在於收集與確認各項需求,一但需求明確定義後,我們就可以建立需求的參考基線(需求凍結)然後著手進行分析設計工作;分析設計完成並透過審查與追溯機制確認滿足需求後,我們就可以建立另一條基線-Design Baseline,作為後續開發與測試的基礎;完成研發、整合測試後,我們一樣也可以建立 Development Baseline、Test Baseline …;當產品研發完成並確認各項功能與相關文件都備齊後,我們就可以建立Product Baseline,這時不要忘了要大聲歡呼並恭喜老闆喔 ^_^。




還記得前一篇文章當中的變更管理機制?專案受理變更後,專案成員就必須執行變更任務並確認變更成果,結合建構管理的具體實行步驟如下:

1. 確認變更任務的內容,找出要變更的建構項目是哪一個
2. 簽出(Checkout)該建構項目,
簽出的動作就像預約KTV 的包廂一樣,其目的主要是要提醒其他專案成員你正在這一區施工,避免同時施做造成資源浪費。
3. 依照任務內容執行變更並確認變更成果符合需求。(開始唱歌)
4. 變更完成後,將工作成果簽入(Check-in)到建構管理環境中,簽入跟簽出是相對的動作,目的就是告訴其他專案成員你已經離開,簽入後建構管理工具會同時保留新舊版本的工作成果。(包廂空出來了,可以開放給其他人預約)

提醒各位,簽入的動作必須嚴謹,簽入前必須透過審查、檢驗或測試的方法來確認變更任務已經完成,而簽入時必須加入時戳、修改內容註解並維護工作成果之間的追溯性

建構管理不但是研發單位的重大基礎能力,更是公司智慧資產評估的重要工具,因為「凡走過必留下痕跡」將成為研發單位的知識管理基礎,人員可以透過前輩的案例學習、成長;「站在巨人的肩膀上看世界」,配合系統架構擬定的建構項目有更多的機會用在其他專案上,除了重複使用、節省成本的效益外,部分建構項目還可以申請智慧財產權與各項專利,成為公司永續發展的一環喔。

相信各位讀者都聽過「計劃永遠趕不上變化」這句話吧,或許有些讀者看到這句話還會在內心深處發出心有戚戚焉之感!我想這句話突顯的正是變化的事實,為了迎接變化我們需要更有效率的管理機制-建構管理。

衍生思考:
「計劃永遠趕不上變化」這句話突顯的正是變化的事實,但難道因為變化的存在我們就不需要計畫了嗎?關於這點,筆者聽過一位好朋友說過「計畫就是為了要迎接變化」,我個人滿認同這樣的觀點,因為這是認同變化並積極面對的思維,也是身為工程研發單位除了基本能力之外應具備的思維,因此研發一定要有計畫,而且計畫本身應積極迎接變化-與時俱進。

2006年3月23日 星期四

研發基本能力 <3>

在上回的文章中,我們提到了需求管理是研發單位應具備的基本能力之一,這一回我們要聊聊研發單位的另一個重要能力-建構管理(Configuration Management),建構管理有很多的別稱如:型態管理、組態管理、構型管理、中國大陸稱為「配置管理」…指的都是CM這個作業規範(Discipline)。

簡單來說,建構管理就是產品研發過程的變動管理,也就是系統架構、版本管控加上變更管理(關於變更管理部份請讀者參閱前一篇文章),確實執行建構管理不但對有助於研發專案的快速進展,加速上市時間,更對公司整體營運有正面的加分效果-尤其是重視智慧資本的21世紀。筆者認為建構管理對公司的影響是至為深遠的,不但是研發單位的命脈之一,更是公司從A邁入A+ 的重大里程碑,怎麼說呢?請各位看官聽小弟我娓娓道來

先說明一下建構管理跟系統架構之間的關連性吧,各位有沒有吃過歐式自助餐呢?各位有沒有發現,只要稍具規模的歐式自助餐聽都會將取餐區域畫分成:生食區、熟食區、糕點區、飲料區…等,這樣分區的結果不但方便顧客取餐(客戶滿意度),更讓廚房能精準掌握各餐區的上菜時機與菜色內容(經營成本),達到顧客與餐廳雙贏(Win-Win)的局面。聰慧的讀者應該已經發現,取餐區的配置其實就是系統規劃,有了系統規劃後,餐廳的經營管理也能提升效率,收到事半功倍的效果喔!在這裡,筆者要提醒各位讀者,取餐區的動線規劃也是系統規劃的重要環節之一,這點請各位下次到歐式自助餐用餐的時候自己留意一下囉。

從產品研發的案例來看,取餐區的劃分就等同於產品分成硬體機構、韌體跟軟體的區隔,其中硬體機構還會再分解成不同的單元,而韌體跟軟體也還會再分解成不同的子系統或是模組,這就是系統規劃的一部份,也是建構管理的重大參考資料,唯有如此我們才能有效的管理研發過程當中的變化。左圖是系統規劃的簡單範例,是不是一目了然且便於管理呢!

給研發主管&經營者的建議:系統規劃的優劣與否將是影響產品研發進程的領先指標,然而系統規劃人員(系統架構師)的養成卻是實務經驗跟時間累積而程的,建議各位可以放些資源在系統規劃人員的養成。

各位讀者應該都寫過履歷表吧!相信大多數讀者在騎驢找馬的時候都會重新檢視自己的履歷並加以更新,通常我們都會複製一份舊的履歷,然後才著手進行更新動作,因此我們會有新舊履歷兩份檔案,有些比較精明的讀者還會在履歷上加上日期甚至註解做為區隔,這樣做的讀者讓我忍不住要讚賞一翻(您真內行),您知道這樣做,正是在實踐建構管理的精隨之一『版本管控』嗎?有沒有發現因為自己留存著不同版本的履歷,也多了些機會省思現在跟過往的輝煌戰績呢!

回到產品研發的案例去看,新舊版本的履歷就等同於不階段發行的產品,作業系統從 98 升級到 2000 又升級到 2003 是一個明顯的案例,然而改版代表的實質意義又是什麼呢?究竟是系統本身的整體規劃更動(大改版),還是只有單一子系統的更動(小改版)?要回答這個問題真的很簡單,從個人履歷的例子中讀者就可以猜到十之八九了,只要在每次更動前後加上時間戳記與註解,就可以很快瞭解新舊版本之間的差異,建構管理作業規範也有類似的要求-「凡走過(異動)必留下痕跡(註解)」,能做到這點的人大多都是對自我期許頗高的人,相信各位讀者也是。

注重公司經營的研發單位主管都希望了解建構管理到底對公司會有哪些正面或負面影響?相對地又要投資多少資源?…尤其是有關投資報酬率(ROI)的問題;關於這點我必須清楚答覆各位,就像「信我者得永生」一樣,要發揮建構管理的優勢,首重執行力,能落實制度者,必然能夠得到滿意的報酬,有形的報酬將會反應在產品上市速度(獲利率)、專利與智慧財產權…等,無形的報酬將會反應在團隊的研發能力、知識傳承與產業提昇…等,相對投資則是九牛一毛,請各位主管自行盤算是否有投資的價值。

建構管理的投資 = 伺服器主機 + CM軟體工具 + 教育訓練
建構管理的報酬 = 產品上市速度 + 專利與智慧財產權 + 研發能力提昇
建構管理的 ROI = (執行力 X 建構管理的報酬) / 建構管理的投資

讀到這裡,相信各位對於系統架構(例:餐廳分區)跟版本管控(例:新舊履歷)都具備初步的概念了...待續

2006年3月22日 星期三

研發基本能力 <2>

需求清單、雙向追溯機制與變更請求(Change Request)等基本要素包括 :

1. 需求清單
需求清單顧名思義就是羅列各項需求的清單,不過除了羅列各項需求外,有一些輔助性的資料包括:需求來源、時間、需求狀態、優先等級、負責人員與變更記錄等,這些輔助性資料在複雜的研發環境當中將更為重要,能讓所有專案成員據焦在清單的工作項目上因而達到事半功倍的效果。

2. 雙向追溯機制
雙向追溯機制最主要的目的就是鑑別專案計畫、工作成果是否能滿足顧客的需求,因此必須管理的項目自然就包括:需求清單、專案計畫(任務清單)、工作成果等各項資料,尤其是資料之間的相關連性-稱之為追溯,有了資料間的追溯性後,我們就能夠的清楚地知道自己執行的任務、工作成果跟哪些需求有關,也可以回答需求滿足度的相關議題,如果運用得當,我們還可以利用這些資料作為評估專案預算與工時…等佐證資訊。

3. 變更請求(Change Request)
需求變更簡稱CR 是專案執行過程中必然會碰到的狀況,變更請求基本上可以分為要求修正除錯錯誤的故障申告、衍生性需求、原始需求改變(需求變更)…等,顧客或專案成員提出變更請求須經過內部的變更管理機制去處理,並將各項變更反映到需求清單、專案計畫
(任務清單)等,這樣的運行模式才能正確反映事實,也為有著種運行模式才具有實質意義。


變更管制委員會(CCB:Change (or Configuration) Control Board) 主要的任務就是從各個面向去評估變更請求的適切性,評估的面向包括:
1)變更請求的內容是否在本專案的範疇內,
2)變更請求的內容是否跟現階段的專案任務有關,
3)評估各項資源、預算與時程的異動程度,
4)評估整體風險與影響範圍,
5)若受理變更請求,則需要調整並分配專案任務給相關的成員

以上說明需求管理的基本概念與作業流程,下次將介紹跟需求管理息息相關的建構管理作業,請
各位讀者給點時間,讓我好好整理腦裡的資料囉,如有疑問歡迎與本人連繫

2006年3月20日 星期一

研發基本能力 <1>

在現今的 IT 產業中,時間是最奢侈的消耗品,為了搶攻市場,系統必須快速完成研發上市,一
切跟品質有關的問題,只要不危及生命財產安全,都可以等到產品上市後再說!這樣的思維並非
錯誤,因為公司的經營本來就是以營利為目標,產品如果沒辦法獲利,公司都經營不下去了,哪
有多餘的資金投入大量人力、物力去維護品質!

公司的經營者當然也清楚,產品上市後,品質終將影響客戶對公司的整體印象,公司形象與客戶
滿意度也會進一步反應在公司的財務報表之上,因此,站在中長期的角度看來,品質與客戶滿意
肯定又是非常重要的,到底是要先顧好品質還是上市時間(Time to market)?這要怎樣評估呢?

除了基本的財務槓桿考量外,筆者建議各位還必須考慮到產品的特性,最重要的還是市場的現況
(Current Status);如果市場已經有類似的產品,那麼品質與價格必定會站比較大的成份,產品本
身必須在價格與品質上都具有競爭力才可能獲得青睞;如果市場並不存在類似的產品,那麼就需
要從上市時間與技術門檻這兩個角度去思考合理的品質水準,理想的方式就是擬定產品的上市時
間表,然後在有限的時間內進行研發與反覆測試,以期達到能力範圍所及的最佳品質水準。

產品研發就是在有限的時間內達到能力範圍所及的最佳品質,然而,產品研發的過程當中要注意
的事情實在太多,如果沒有妥善的管理對策,品質似乎也變成了中樂透一般的隨機事件,碰到認
真負責的工程師品質自然好,碰到迷糊的工程師就只能祈求老天保佑了(希望自己能被閃電打
中)。

從工程師的角度思考,主管這些日子以來關愛的眼神不斷,一件任務還沒完成,主管又派了新的
工作,只能安慰自己說:『天將降大任於斯人也,必先苦其心志…說著說著又有新的任務來了,
疑,這不是以前做過的系統,怎麼又要搞一套…』,難道這就是工程師的宿命?或許建構管理
(Configuration Management)可以幫各位解決一點疑問。

建構管理是研發單位的重大基礎能力,它本身是一種作業規範,也是公司智慧資產評估的重要工
具,建構管理具備的優點包括:
1. 協同作業與任務追蹤
2. 知識累積與智慧資產
3. 品質管理與變更控制

品質的基本定義就是滿足顧客需求,但需求也有顧客群與輕重緩急的差異,因此品質的等級也會
有所不同,符合特定等級的產品,就是符合特定顧客群需要的產品,因此,產品開發過程當中,
最重要的任務就在於掌握與滿足特定客群的需求

掌握需求是極具挑戰的任務,這任務通常由行銷或業務人員負責蒐集調查,當客戶需求進到工程研發單位後,如何妥善的管理各項需求,並在時限內研發出一套符合需求的產品,就成為研發工程師的基本工作了。

建構管理規範的作業方法,便是以需求管理作為起點,透過嚴謹的工作規範,有效掌握產品研發過程,到最後研製完成出一套符合需求的產品。

舉例來說,如果我們要辦一場生日宴會,我們會希望知道宴會的目的、邀請的對象、時間、地點、預算…,這就是所謂的需求,因此,我們的產品就這一場宴會,怎樣衡量我們費心籌辦的宴會是否成功呢?通常我們會把列出一張檢核清單,上頭列出所有大大小小需要注意的事項,然後在宴會的籌備過程中不斷的核對清單上頭的所有事項,看看是否有遺漏掉未完成的事情(任務)並加以補強,過程中,經常會有新的需求加到清單上頭,也有些不重要的需求會被忽略,加上經常性地核對清單上的項目,這樣做的目的就是為了要確保宴會成功。

從工程研發的角度思考,需求管理就跟籌辦生日宴會一樣,我們需要一個清單去紀錄各項需求,在研發過程中,也會不斷地檢視各項需求是否已經被滿足,過程中也經常有需求變更的情況發生,這些不都是現實生活中最正常不過的事件?唯有認清需求變動的事實,跟需求變動妥協,才能創造雙贏的局面。

讀者可以利用能力成熟度模型(CMMI)當中的需求管理要點來評估公司是否已具備妥善的需求管理作業規範,需求管理要點(Specific Practice)如下:

SP 1.1 瞭解與收集需求,並就需求的內涵取得共識
Develop an understanding with the requirements providers on the meaning of the requirements.

SP 1.2 取得所有專案成員盡力滿足需求的基本承諾
Obtain commitment to the requirements from the project participants.

SP 1.3 管理專案執行過程中的需求變更
Manage changes to the requirements as they evolve during the project.

SP 1.4 建立需求與工作成果之間的追溯機制(協助了解哪些需求已滿足)Maintain bi-directional tractability among the requirements and the project plans and work products.

SP 1.5 鑑別專案計畫、工作成果與需求之差異Identify inconsistencies between the project plans and work products and the requirements.

需求管理是人與人之間的溝通過程(軟性知識),需求清單與雙向追溯機制只是幫忙判斷與釐清需求是否被滿足的工具(硬性知識),因此,需求管理應側重於溝通的有效性,怎樣才是最有效果又能跟客戶達成共識的溝通方式反而是比較重要的,關於這點我推薦各位讀者可以學習卡內基的溝通訓練課程,相信一定會對各位有所助益。

但需求清單與雙向追溯機制等硬性知識又要怎樣做才洽當呢? ...待續