關於OOA的
果然薑是老的辣!
推!
有某位硬派的老師說SA用txt檔就可以搞定了
我想說我們用jpg 檔(<--數位相機拍白板)就搞定了 更酷
20080428補充
嗯後來看看只有5行的文字不太能表達我要說的是什麼(太混了吧你!!!)，來補一下
回憶起在四年前的這個月份，喵尾巴參與了一個大專案
當時它因為發標不順利，開始執行的時間已經比預期 delay 了三個月
但是上包商還是十分有種(拍拍手了不起)的承諾業主會如期交付 噹噹~~~ SA/SD文件
當時我們一天工作平均14~16個小時，可說在各系統(包括自己的)的責任都混沌不明的狀態下趕出一本厚達兩百多頁的報告
用的是神兵利器 rational rose (這玩意神到你裝起來用筆電都會軋軋叫)
不過，在這樣混沌的情況下
應該是先搞清楚你的子系統有些什麼樣的責任
要和其它系統如何介接，這時候怎麼會輪得到rose 這種東西出場?
錄音機、白版和筆記本加上充份的溝通(工程師 <--> PM<--> 使用者)才是王道啊
但是當年也是在交付時限的壓力下，十分神勇的用rose 搞了一些自已都不相信的鬼圖出來
啥咪use case, 繼承，啥咪design pattern 其實一筆一劃都是心虛啊，user 和其它client 怎麼用系統都不知道這些設計怎麼驗證。充其量只能說：「我們盡力滿足上包商的要求」，而不是「我們盡力做了系統分析設計」我記得當時真的很希望沒有人會認真看這東東：因為這種文件最厲害的地方是，即使它圖文並茂，頁數超多，你看很久，死了許多腦細胞還是不會了解它在幹麻(因為連原作者都淪陷了嘛啊哈哈~)。
我要說的是
不是UML不好 而是 「不是有 UML 畫出來的圖就好」
UML 在大系統中的確是可以幫助不同團隊間的溝通，但是個人認為它是輔助了解的工具，而不是SA/SD最終產物。系統分析設計做得好，的確用文字描述也可以達到溝通的效果，只不過沒有圖表那麼賞心悦目罷了；個人覺得，純文字的部份才是決定SA工作品質的關鍵，因為靠它才能見真章啊。到現在為止，我一直在猜，如果把那十幾個系統的系統文件濃縮成每系統三頁的文字檔，審查的人一定能一眼看出我們在鬼扯蛋，而不是對著那厚厚的文件山翻兩個月後挑些不關痛癢的偽審查意見回來。(嘿嘿結果那系統後來在實作階段，開會還是都在吵一些分析時就應該釐清的重點)
嗯回到上面推的文章，它把怎麼做一個OOA model, 怎麼驗證一個 OOA model 都講得很清楚。那是做「真的」SA的具體方法中的一種。
2008年4月24日 星期四
2008年4月23日 星期三
噢～沮喪斃了
最近幾天十分的苦惱
原因是來自一個審查論文的工作
這篇被交到我手上的論文，說真的只能用淒慘兩字來形容
從立論、建立模型的方法、到拼字、文法都非常有問題，有問題到真的會想敲敲這作者的頭，問他一聲你還好嗎?
要把這篇鬼東西看完，簡直是精神上的酷刑，看了兩頁之後，連再拿起這玩意的勇氣都沒有
tony 老師說要儘量審，儘量看懂
哎我明白這是對投稿者的誠意，也是一個學術工作者敬業的表現
但是哎喲喂，我真想逃跑
星期天我在百般無奈與無名大火燒起的情形下在這裏留了一篇發洩文，大意是說這篇文章有多差，還有我有多火大之類的
不過後來覺得不能隨便拿情緒丟大家所以就把那篇刪了
可是…可是…
我真的不甘願把時間花在這種沒事找事的爛東西上
我還有其它更多更該作的事啊...多寫幾個自動測試 多練一下演算法 陪女兒玩一下 都比這個有意義得多 這篇文章的學術貢獻是零，然後還連帶害reviewer 的產能降低 該死的…還有比這更笨的事嗎？
各位對不起了 我還是亂丟情緒 該死的 因為實在沮喪斃了
原因是來自一個審查論文的工作
這篇被交到我手上的論文，說真的只能用淒慘兩字來形容
從立論、建立模型的方法、到拼字、文法都非常有問題，有問題到真的會想敲敲這作者的頭，問他一聲你還好嗎?
要把這篇鬼東西看完，簡直是精神上的酷刑，看了兩頁之後，連再拿起這玩意的勇氣都沒有
tony 老師說要儘量審，儘量看懂
哎我明白這是對投稿者的誠意，也是一個學術工作者敬業的表現
但是哎喲喂，我真想逃跑
星期天我在百般無奈與無名大火燒起的情形下在這裏留了一篇發洩文，大意是說這篇文章有多差，還有我有多火大之類的
不過後來覺得不能隨便拿情緒丟大家所以就把那篇刪了
可是…可是…
我真的不甘願把時間花在這種沒事找事的爛東西上
我還有其它更多更該作的事啊...多寫幾個自動測試 多練一下演算法 陪女兒玩一下 都比這個有意義得多 這篇文章的學術貢獻是零，然後還連帶害reviewer 的產能降低 該死的…還有比這更笨的事嗎？
各位對不起了 我還是亂丟情緒 該死的 因為實在沮喪斃了
2008年4月6日 星期日
高網reading assignment 心得～
這學期修了一科高等網路，這門課蠻精采的，因為老師的學問十分淵博，而且也有王牌貝爾實驗室的實務經驗，所以也能夠透過一些實際上的例子，讓我們將複雜的網路理論、統計及數學和實務上要處理的問題連在一起。
不過像老師是這樣的強者，也是有一些令人傷腦筋的地方，比方說對強者而言，一些基礎的數學與統計是必備知識，上星期出了一篇reading assignment, 喵尾巴一看之下險些沒有昏倒，超多統計和積分的符號，不出幾秒就把acrobat關了，怕影響消化(當時在吃晚飯)，並且一面心想強者和弱者真的是差太多了~
不過這篇論文被擺了幾天之後，心裡還是隱隱覺得不安，想說難得修了高網，怎可輕易放過level up 的好機會? 所以再拿起來看，順便複習一些基礎的數學：
這篇文章要解的題目是，假設對於網路 QoS 的要求的Criteria 為end to end delay 對於某一延遲時間t(i.g., 5 sec) 的overdue probability(p) 的話；我們要如何將這樣的要求，allocate 在單一的network component 上? 而不用每一種可能的end to end path都做monitor ?
在這篇文章裏提到的數學武器有下列數種：
(0) 一個path 上關於end to end 的measure 由path 上element 貢獻所得
(1) Convolution
Convolution，這篇論文章的應用是：當有兩個random variable合成的時候，它們的probability distributed function (pdf)會形成何種分布? 答案即是此兩個變數的pdf 的Convolution.
單純用這個方法，配合(0)的定義，解得的解為:
每一個element 的delay 為t/k, 而每個element 的overdue probability 為 1- (1-p)^k。這樣的解簡單，但是太過保守。
(2) Laplace transform 是?
在通信領域中，是指將時間域中的函數轉換成在頻率域中的函數。在時間域中的捲積等於在頻率域中的乘積，可以簡化計算。在這篇文章中是應用重點。(其實是蠻古遠的記憶了，好像大二工程數學有教過嘿，不過全忘光光~)
本篇論文利用queue theory 的model，將interarrival time distribution 及 service time distribution作Laplace transform 之後，會很漂亮(神秘)的得到一個element 上waiting time pdf下限。這時卷積又可以派得上用場，大意是說函數下限的捲積是函數捲積的下限。利用對這個下限值的限制可以反推重要的參數，如，utilization.
(3) Markov inequality
Markov's inequality gives an upper bound for the probability that a non-negative function of a random variable is greater than or equal to some positive constant (– from wikipedia)
它的form 為：
Pr(|X|>=a) <= E(|X|)/a
就是說，如果知道一個random variable 的Mean值，就可以用上面的式子求取這個random variable 大於某正數的機率. 可以直接套來解這個問題。所得的參數為每個element 上的mean delay.
(4) Chebychev inequality
In probability theory, Chebyshev's inequality (also known as Tchebysheff's inequality, Chebyshev's theorem, or the Bienaymé-Chebyshev inequality), named after Pafnuty Chebyshev but first formulated by his friend and colleague Irénée-Jules Bienaymé[1], states that in any data sample or probability distribution, nearly all the values are close to the mean value, and provides a quantitative description of "nearly all" and "close to". (- from wikipedia) (寫到這裏不禁慶幸網路可以讓我們與世界接軌~)
它的form 可以表示如下：
P[X-E(X)>=t] <= 1/(1 + t2/Var(X)) 這是one side 的Chebychev inequality, 就是說如果t > E(X)的話可以這樣用。(t < E(X)的話稍稍做點變化就可以算了。) 如果知道一個random variable 的mean和variance 就可以用上式求取此數大於某值的機率。也可以直接應用來解題。
(5) Normal distribution
如果有k個random variable, 其分佈為normal distribution, 它們線性組合出的數的probability distribution function也為normal distribution. 可以直接套用解題。
由以上五種方法看來，可知要解這個問題，統計的觀念必須要好一點才行…拿出課本K吧!
不過像老師是這樣的強者，也是有一些令人傷腦筋的地方，比方說對強者而言，一些基礎的數學與統計是必備知識，上星期出了一篇reading assignment, 喵尾巴一看之下險些沒有昏倒，超多統計和積分的符號，不出幾秒就把acrobat關了，怕影響消化(當時在吃晚飯)，並且一面心想強者和弱者真的是差太多了~
不過這篇論文被擺了幾天之後，心裡還是隱隱覺得不安，想說難得修了高網，怎可輕易放過level up 的好機會? 所以再拿起來看，順便複習一些基礎的數學：
這篇文章要解的題目是，假設對於網路 QoS 的要求的Criteria 為end to end delay 對於某一延遲時間t(i.g., 5 sec) 的overdue probability(p) 的話；我們要如何將這樣的要求，allocate 在單一的network component 上? 而不用每一種可能的end to end path都做monitor ?
在這篇文章裏提到的數學武器有下列數種：
(0) 一個path 上關於end to end 的measure 由path 上element 貢獻所得
(1) Convolution
Convolution，這篇論文章的應用是：當有兩個random variable合成的時候，它們的probability distributed function (pdf)會形成何種分布? 答案即是此兩個變數的pdf 的Convolution.
單純用這個方法，配合(0)的定義，解得的解為:
每一個element 的delay 為t/k, 而每個element 的overdue probability 為 1- (1-p)^k。這樣的解簡單，但是太過保守。
(2) Laplace transform 是?
在通信領域中，是指將時間域中的函數轉換成在頻率域中的函數。在時間域中的捲積等於在頻率域中的乘積，可以簡化計算。在這篇文章中是應用重點。(其實是蠻古遠的記憶了，好像大二工程數學有教過嘿，不過全忘光光~)
本篇論文利用queue theory 的model，將interarrival time distribution 及 service time distribution作Laplace transform 之後，會很漂亮(神秘)的得到一個element 上waiting time pdf下限。這時卷積又可以派得上用場，大意是說函數下限的捲積是函數捲積的下限。利用對這個下限值的限制可以反推重要的參數，如，utilization.
(3) Markov inequality
Markov's inequality gives an upper bound for the probability that a non-negative function of a random variable is greater than or equal to some positive constant (– from wikipedia)
它的form 為：
Pr(|X|>=a) <= E(|X|)/a
就是說，如果知道一個random variable 的Mean值，就可以用上面的式子求取這個random variable 大於某正數的機率. 可以直接套來解這個問題。所得的參數為每個element 上的mean delay.
(4) Chebychev inequality
In probability theory, Chebyshev's inequality (also known as Tchebysheff's inequality, Chebyshev's theorem, or the Bienaymé-Chebyshev inequality), named after Pafnuty Chebyshev but first formulated by his friend and colleague Irénée-Jules Bienaymé[1], states that in any data sample or probability distribution, nearly all the values are close to the mean value, and provides a quantitative description of "nearly all" and "close to". (- from wikipedia) (寫到這裏不禁慶幸網路可以讓我們與世界接軌~)
它的form 可以表示如下：
P[X-E(X)>=t] <= 1/(1 + t2/Var(X)) 這是one side 的Chebychev inequality, 就是說如果t > E(X)的話可以這樣用。(t < E(X)的話稍稍做點變化就可以算了。) 如果知道一個random variable 的mean和variance 就可以用上式求取此數大於某值的機率。也可以直接應用來解題。
(5) Normal distribution
如果有k個random variable, 其分佈為normal distribution, 它們線性組合出的數的probability distribution function也為normal distribution. 可以直接套用解題。
由以上五種方法看來，可知要解這個問題，統計的觀念必須要好一點才行…拿出課本K吧!
2008年3月13日 星期四
Embrace change, embrace test automation
做研究没頭緒，來聊聊新的興趣~
最近常常很高興的和別人說
「你知道嗎?我轉QA了，在做自動測試喔~」
最通常的反應是：
「你用rational嗎? 還是 mercury?」
次常的反應是：
「UI一直變動，不是自動測試改起來很痛苦嗎?」
(還有人覺得很奇怪，啊網頁測試不就點來點去而已…(我踢~~~))
其實對於自動測試的偏執，有大部份的緣由是來自對Iterative 開發的相信。Iterative 開發解答了需求變更的及降低技術風險的問題，但的確帶來新的疑問
「那測試呢?」
如果你是用人工測試，很好，每次新的release 出來，不但要測試新功能，舊功能也要一併測- 加新功能的時候應該沒有一個工程師敢掛保證舊功能不會掛吧? (好吧，至少我不敢…) ，如果你對外宣稱要支援IE6.0, IE7.0, FF2.0，還有safari...喔喔，那變成所有功能要測四次，因為很讓人沒力的是，每種瀏覽器run 起javascript 和css就是同中求異，異中求同，除了乖乖測之外也沒有其它的方法呀~ 全部都用人工，這太慘了(也太累(笨?)了)。
所以自動測試(for acceptance test)對於長期的、Iterative 的開發是必要的。市面上的工具也蠻多，不過我依照個人的偏好，選了selenium當我的戰友。雖然說是偏好，但其實是有幾個重要的理由。個人(真的是個人)覺得，一個好的，用來做 acceptance 的自動測試工具應該要有下列特點：
(1)Ease of Use
通常測試人員花比較少的時間碰code，所以他們對頁面的dom結構不會太熟，此時可能需要一些工具的幫忙，如firefox 的dom inspector, XPather,甚至是可以錄製的工具試錄一小段，幫助測試人員降低一些門檻
(2)Compatible
Must be compatible with browsers you want your software to support. Crystal Clear.
(3)Programmable
因為你的要測的軟體會變(而且有可能是大變)。所以你的腳本一定要能夠跟著改(而且要用十分少的時間成本跟上)。而改…如果指的是重新再錄一次，那也不必了，因為每個Iteration都有可能改，可能你錄完都到下一個Iteration去了，來不及測試是也。一個有效、能跟上軟體進化的測試腳本，應該是高度模組化的東西，當程式的某一個模組改了，你對應相對的模組即可跟上去。所以，個人的感覺是這些腳本要像程式一樣，可以refactor，可以有架構，也就是說，它要能用programming 的方式drive.
第三點也同時帶出一個新問題，那如果要測試的軟體本身就沒有架構(所謂前端的架構)可言，怎麼辦?其實我也不知道，因為沒有經驗過。不過以本人的直覺來看，應該會測不下去吧，至少是蠻痛苦的或會沒有效率。
目前也只是個開頭，不知道以這樣的測試方法來做能否真的有好的助益(早期發現大bug 啦…提高品質啦…等等)，需要後續的努力和驗證才能見分曉囉。
最近常常很高興的和別人說
「你知道嗎?我轉QA了，在做自動測試喔~」
最通常的反應是：
「你用rational嗎? 還是 mercury?」
次常的反應是：
「UI一直變動，不是自動測試改起來很痛苦嗎?」
(還有人覺得很奇怪，啊網頁測試不就點來點去而已…(我踢~~~))
其實對於自動測試的偏執，有大部份的緣由是來自對Iterative 開發的相信。Iterative 開發解答了需求變更的及降低技術風險的問題，但的確帶來新的疑問
「那測試呢?」
如果你是用人工測試，很好，每次新的release 出來，不但要測試新功能，舊功能也要一併測- 加新功能的時候應該沒有一個工程師敢掛保證舊功能不會掛吧? (好吧，至少我不敢…) ，如果你對外宣稱要支援IE6.0, IE7.0, FF2.0，還有safari...喔喔，那變成所有功能要測四次，因為很讓人沒力的是，每種瀏覽器run 起javascript 和css就是同中求異，異中求同，除了乖乖測之外也沒有其它的方法呀~ 全部都用人工，這太慘了(也太累(笨?)了)。
所以自動測試(for acceptance test)對於長期的、Iterative 的開發是必要的。市面上的工具也蠻多，不過我依照個人的偏好，選了selenium當我的戰友。雖然說是偏好，但其實是有幾個重要的理由。個人(真的是個人)覺得，一個好的，用來做 acceptance 的自動測試工具應該要有下列特點：
(1)Ease of Use
通常測試人員花比較少的時間碰code，所以他們對頁面的dom結構不會太熟，此時可能需要一些工具的幫忙，如firefox 的dom inspector, XPather,甚至是可以錄製的工具試錄一小段，幫助測試人員降低一些門檻
(2)Compatible
Must be compatible with browsers you want your software to support. Crystal Clear.
(3)Programmable
因為你的要測的軟體會變(而且有可能是大變)。所以你的腳本一定要能夠跟著改(而且要用十分少的時間成本跟上)。而改…如果指的是重新再錄一次，那也不必了，因為每個Iteration都有可能改，可能你錄完都到下一個Iteration去了，來不及測試是也。一個有效、能跟上軟體進化的測試腳本，應該是高度模組化的東西，當程式的某一個模組改了，你對應相對的模組即可跟上去。所以，個人的感覺是這些腳本要像程式一樣，可以refactor，可以有架構，也就是說，它要能用programming 的方式drive.
第三點也同時帶出一個新問題，那如果要測試的軟體本身就沒有架構(所謂前端的架構)可言，怎麼辦?其實我也不知道，因為沒有經驗過。不過以本人的直覺來看，應該會測不下去吧，至少是蠻痛苦的或會沒有效率。
目前也只是個開頭，不知道以這樣的測試方法來做能否真的有好的助益(早期發現大bug 啦…提高品質啦…等等)，需要後續的努力和驗證才能見分曉囉。
2008年3月10日 星期一
2008年3月9日 星期日
論文論文你要何處去...
最近論文已經進行到跑真實資料的階段了；
任務即是從一堆的移動軌跡資料中找出「共同的」移動軌跡；希望用在有sensor network的賣場中分析hotspot等等資訊. 但是…現在sensor network 在國內的賣場中仍然是雷聲大雨點小的狀態；所以轉進求取其它的真實資料做分析；詭異的是；原本預期的應該不一定對「其它」的資料有意義，所以還要為了這個資料說說故事。
偏偏說一個 domain 的故事，從來不是件容易的事。 除非在該領域裏已經有足夠的浸潤，否則你對一件事觀察的角度失準與深度不夠是正常，畢竟不是精通 Tigerology (唬爛學)的人，足以寫出玄幻或奇想風格的文章，真困難。
星期五聽了一個 Tigerology 黑暗爪牙的演講，其實在台下都要爆走了，不過外在則是空靈的眼神逃避演講者的目光。希望之後我去某某研討會時，不要在台下看到類似的眼睛。
任務即是從一堆的移動軌跡資料中找出「共同的」移動軌跡；希望用在有sensor network的賣場中分析hotspot等等資訊. 但是…現在sensor network 在國內的賣場中仍然是雷聲大雨點小的狀態；所以轉進求取其它的真實資料做分析；詭異的是；原本預期的應該不一定對「其它」的資料有意義，所以還要為了這個資料說說故事。
偏偏說一個 domain 的故事，從來不是件容易的事。 除非在該領域裏已經有足夠的浸潤，否則你對一件事觀察的角度失準與深度不夠是正常，畢竟不是精通 Tigerology (唬爛學)的人，足以寫出玄幻或奇想風格的文章，真困難。
星期五聽了一個 Tigerology 黑暗爪牙的演講，其實在台下都要爆走了，不過外在則是空靈的眼神逃避演講者的目光。希望之後我去某某研討會時，不要在台下看到類似的眼睛。
2008年3月5日 星期三
自動測試竟然讓我眼盲了
年初的工作轉成QA之後，非常的興奮。最大的原因是可以投時間玩webapp的自動測試，超開心的。
花了約莫三星期的時間後，終於deploy 自動測試在新的build 上了。當然也捉到了一些bug，蠻有成就感。不過…
竟然在首頁的CSS Bug 被我忽略了
這種只依賴自動測試的睜眼瞎測試法十分危險，因為 layout 沒有半法自動測，即使CSS bug 導致頁面面目全非，只要DOM結構沒壞測試還是過得了啊啊啊… 目前所知的解法也只能用眼睛看了。
警惕一下
花了約莫三星期的時間後，終於deploy 自動測試在新的build 上了。當然也捉到了一些bug，蠻有成就感。不過…
竟然在首頁的CSS Bug 被我忽略了
這種只依賴自動測試的睜眼瞎測試法十分危險，因為 layout 沒有半法自動測，即使CSS bug 導致頁面面目全非，只要DOM結構沒壞測試還是過得了啊啊啊… 目前所知的解法也只能用眼睛看了。
警惕一下
訂閱：
文章 (Atom)