顯示具有 Software Engineer 標籤的文章。 顯示所有文章
顯示具有 Software Engineer 標籤的文章。 顯示所有文章

2010-02-24

Metaphor: Pig & Chicken


在Scrum裡面有用到一個 pig & chicken 的隱喻 來說明 project 內的參與者

pig - 指的是犧牲、奉獻並對project最終成敗負責的相關角色

chicken - 指的是project的參與者,不必負最終成敗的相關角色

還有 rooster / gamecock 的角色(鬥雞),這些人 光放屁 提出的意見對project的產出有負效果

--

以下是這個metaphor 的緣由

A number of roles are defined in Scrum. All roles fall into two distinct groups—pigs and chickens—based on the nature of their involvement in the development process. These groups get their names from a joke about a pig and a chicken opening a restaurant:[5]

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

So the “pigs” are committed to building software regularly and frequently, while everyone else is a “chicken”—interested in the project but really indifferent because if it fails they’re not the pigs—that is, they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but are not in any way allowed to affect, distort or get in the way of the actual Scrum project.

ref: wiki Scrum


閱讀全文...

2010-01-05

XML element 與 attribute 的使用時機 (元素 v.s. 屬性)


基本上 XML 的標準裡面,並沒有說明何時該用 element, 何時該用 attribute
所以,會出現一種狀況,就是資料有多種表示方式,如:
<person id="123" name="REX"></person> 或
<person id="123"><name>REX</name></person>

下列是看到的兩篇相關文章,各別有建議判斷準則:

1. w3school 中的文章 http://www.w3schools.com/DTD/dtd_el_vs_attr.asp

總而言之,建議 data 放 element, metadata 放 attribute

2. IBM Developerworks 中的文章 http://www.ibm.com/developerworks/xml/library/x-eleatt.html

提到了四類原則:

1. 核心內容原則 (priciple of core content)
屬於主要內容 用來表達所欲傳達資訊時,放在 element
屬於附帶內容或是便於application處理實際的主要內容之用途時,放在 attribute
這個原則,基本上就是 w3school 文章內提到的 data/metadata 的原則

2. 結構化資訊原則 (priciple of structured information)
當資訊必需以結構化方式表示(如, parent/child 的關係) 或結構未來可能會擴充時,使用element
當資訊用最基本方式即可表達時(atomic token),使用 attribute

3. 可讀性原則 (principle of readability)
當資訊是提供給人時,使用element
當資訊是提供給系統以利處理時,使用attribute

4. 元素/屬性繫結原則 (principle of element/attribute binding)
當資訊會因其它attribute值改變 而必然隨之改變時,使用element
(即, 避免一個attribute的變動 連帶變動另一個attribute的狀況發生, 或可說為 避免 attribute 與 attribute 間有binding的關係)

上述的四個原則,在考量採 element or attribute 時,應一併納入進行總體考量

--
以上~ 希望對各位有幫助


閱讀全文...

2009-05-08

Software Testing - 談軟體測試


在軟體發展生命週期中,測試是相當重要的一環

整個測試的目的 是要做到驗證(verification)及確認(validation)的作業

以在下列兩個主要的構面,確認軟體成品的品質
驗證(verification): do the thing right - 把事情做好, 即 驗證軟體是否依技術規格開發
確認(validation): do the right thing - 做對的事情,即 驗證軟體是否滿足開發的初衷(intend)

就軟體價值而言,通過驗證以證明軟體的技術品質是最基本的事
但,能讓軟體發恢價值 則是透過確認的動作 ...

確認的作業,一般發生在需求發展(requirement development)及 使用者驗收階段(User Acceptance Testing, UAT),在需求發展階段 是要透過各種不同的方法 將軟體的需求誘導出來,並儘可能在該階段 就將需求確認好,因為 在整個軟體生命週期中 需求發展 - 需求分析 - 系統分析 - 開發 - 系統測試 - 驗收 - 上線
越是在後期發現問題、修改需求 所需的effort/cost愈高
所以,這個階段 其實 是最最最重要的

在使用者驗收階段中,則是透過檢視、使用者操作測試的方法 來確認最終產品符合客戶需求

驗證的作業,則強調 軟體生命週期中的各項產出(artifact) 互相間的一致性
即 需求-設計 的一致性,設計-開發 的一致性.. 等
透過層層的驗證檢查,以確保 所有最初的需求都有被完善的被滿足

不論是 驗證(verification)、確認(validation),我們都會在其中的部分活動面臨到軟體成品的測試

特別在 RUP(Rational Unified Process), XP(eXtreme Programming)等agile development process的概念風行之後

所倡導的 Continuous Integration觀念、Test Spec as requirement 觀念
都在在的強調測試的重要性!!

唯有讓程式(自動化的測試工具/腳本)來驗證程式,才是通往agile development & continuous integration的唯一途徑

否則,在快速且反覆的整合過程當中,若缺乏自動、快速的測式方法,而由人力進行測試的話,將會花費許多時間人力、難以掌握測試的品質及一致性、亦會扼殺了人類的價值 (讓人一直做重複的事情跟操作)

一般軟體的測試工具 不勝枚舉,個人知道的有下列的工具
做Unit Test的有: JUnit, NUnit, ...等 *Unit 系列
做Functional Test的: QTP, WebDriver, Selenium Core/IDE/RC, ... 等
做Performance Test的: Rational Robots, Load Runner, ACT, Selenium Grid, ... 等

其中,WebDriver, Selenium 是專門進行 Web 測試的工具
都是伴隨著 Web 2.0 的成長,所發展出來的 opensource 免錢軟體

因為,這兩個產品在 google 內部也被大量的使用到

所以,後續 將會有針對這些tools的一些的介紹


閱讀全文...