老闆只要軟體上線前要有另一位QA人員QQQ~~

最近被問到這樣一個案例:

因應系統穩定性, 不要有臭蟲的出現, 老闆要求系統上線前一定要有另一員工把關QA, 但是這位把關的QA人員根本不知到完整詳細的規格, 造成大家的困擾, 緊張.

我想這是老闆的本能, 老闆本來就這專門下這種指示, 細節就要看看下面的人怎樣制定與實作了, 至少老闆已經清楚的表達他要做到的事, 細節的部份當然要有員工去想.

問題的解法很簡單, 我們必須先將遊戲規則制定出來, 與老闆確認一下, 然後去執行即可. 但我想有幾個點一定要說說清楚.

1. 初次上線的軟體系統是不大可能保證沒有臭蟲的.  (如果要硬ㄠ可以做得到, 我也承認是可以做得到, 但這是一個具風險及成本問題.  以及不能說的秘密), 

2. 身為開發者可以做的是什麼? 要減少臭蟲的產生, 以其避面臭蟲的再現. 這是很重要的, 如果可以做到這兩點我想已經很了不起了.

3. 要有所本, 有所依據, QA要怎樣把關, 不是讓 QA 人員以自由心証的方式去做這件事就可以的, 但是不可缺少的. 就好比 微軟的軟體測試方法中所說的一樣. 除了要有明確的說明要測試哪些, 還要加上一些經驗法則.

一個系統可以沒有Owner嗎?

一個系統可以沒有Owner嗎?

系統大又多, 一個團隊有七個人的組織, 卻想要所有的人都要懂所有的系統細節, 這到底是好事還是痴人說夢話.

以事有專精, 效率的出發點來看, 這就是不被允許的, 事實就是這樣, 但卻又不敢面對, 如果目標是這樣, 那為何每次問不同的問題, 總是會早不同的特定人來問, 這不是心裡就擺明了, 也很清楚.

所想只有一個答案, 因為不願意面對自己錯誤的決策.

如果要達到, 所有的人都可以維護所有的系統, 只有一種方式可以達到, 就是把商業營運放一旁, 以學習為重.

軟體專案準時達交的風險控制

最近金融風暴席捲全球, 驚嚇中對於風險控制的討論逐漸變多了.

但今天我要想的是【軟體專案的風險控制】, 記得曾經有位大師說 : 專案永遠一定是延遲的, 不可能有提早或是準時的, 不是因為能力問題, 而是因為策略或運作面的問題. 問題是這樣看的, 今天老闆給100元的成本執行專案, 可是你最後只使用了90元就完成了專案, 下一次再一個新的專案成本需要200元, 這時老闆會允許給你200元或是只給你180元, 這就是一個很玩味的問題.

其實軟體專案的風險問題, 不管是在 Software Project Management, PMBOK 裡都有詳盡的說明, 主意大約是這樣的【透過管理，正視風險，預先規劃，過程監控,  並依據重要程度處理事件】.

我想作法大約就是 : 

1. 專案進行前, 先建立一個可能面臨的風險表格, 內含風險事件名稱, 風險等級, 處理方式. 

2. 專案進行中, 隨時依表監控, 當有表徵出現時, 依循處理.

3. 再來就是看看要不要定時或偶而來一個應變演練.

4. 當然所有事請過後一定要來個撿討與改善, 以便使得風險控制可以做的更好.

哎呀, 講了這麼多, 心裡就怕了起來, 要做真的很多事, 這樣專案怎可以如期完成了?

不過重點還是要想想一個軟體專案, 到底會面臨怎樣的風險這倒是要好好思考的.

軟體專案準時達交常見風險 : 

1. 人員異動. 這件事軟體公司, 小公司, 小專案, 真的很常見, 不過就我所知, 現在個客戶也都意識到這一個問題了, 所以很早以前我就已經有被某些客戶要求將人員異動加入合約中(這一召有夠狠 : A. 人員離職就要拿更多的資源來. B. 人力不可挪移. ...等).

2. 持續性的需求變動. 不知道有沒有人沒有遇過這一個問題, 如果有到要請教怎樣做到的? 

3. 不實際時程及預算. 如果遇到這一個問題, 包袱打包一下走人吧. 軟體產業真的是一個極度競爭的產業, 常常遇到一個標案, 底價可以差到10倍. 是大家的認知有這麼大的差異嗎? 還是另有因素, 當然都是有的. 

4. 使用者的程度不好(好傷人的話, 本身沒有責任嗎). 軟體系統開發者需不需要了解產業知識, 這個問題也很熱門, 那功能做錯了, 是使用者程度不好, 沒有說清楚, 或者是開法者太過膚淺, 沒有挖掘到真正的需求, 沒有引導好使用者. 本人覺得見仁見智, 不多說.

5. 專案團隊/領導者的經驗不足(專業能力不足).  常常有出道才一兩年的程式撰寫者搖身一變就成了專案管理者, 而那些倒楣的專案就成了試煉專案, 客戶賠上的不只是一個失敗的專案, 還有位專案所投入的額外成本. 當然一個領導者, 也不是這麼容易的.

6. 時程安排過於樂觀.

7. 軟體的可靠度、成熟度不理想.

8.資源的過度使用.

9.問題隱藏在良好的表象內.

10. 錯誤的功能及即時處理.

好的就到此為止, 在寫下去, 身為IT的我也要被唾棄了.

SDLC : 軟體開發生命週期

專案生命週期的四個階段.

1. 瀑布式

發展階段一段一段往下推, 一定要一個階段作完才能往下做, 因此要準備的文件相當多, 不適於小型專案開發.

2. 漸進式

每個階段的產出都是產品, 所以每個階段產出都非常明顯, 但完成的產品會一直因為上一階段的產出而有所變動. 可以減少產品需求更動的影響, 開發成果較易顯現.

3. V型

每個階段都有對等的關係, 從當初的設計, 開發, 架構…等, 都會對應到一個方法來驗證. 強調品管是最有助益的方式, 確保所開發的產品符合設計規格.





4. 原型快速開發
但每個階段都有強烈的回饋, 需求上的溝通確認較容易.






5. 螺旋型
將瀑布模型的最終結果導回源頭, 成為一個往復式的圓圈, 使整個流程具備回饋與檢驗機制, 改善傳統瀑布式的需求更動影響缺點, 結合風險管理與原型快速發展的觀念.
6. Extreme Program (XP)

從人的本質考慮如何讓程式設計師, 可以提高品質的軟體 . 主要的精神是『在客戶有系統需求時, 給予及時滿意的可執行程式』.

4 個核心價值觀, 5項最優先的原理及 12 項的基本實務作法.
4個核心價值觀 : 溝通, 簡單, 回饋, 勇氣.

5項最優先的原理

1.提供迅速的回饋
2.簡化,不為未來的可延展性而使程式架構變複雜
3.漸進式改變
4.擁抱改變
5.做有品質的工作

12 項的基本實務作法
1.規劃
2.小量發行
3.簡化設計
4.測試
5.持續性整合
6.程式碼重構
7.雙人程式設計
8.程式碼共享
9.每週40 工時
10.客戶駐點
11.客戶與程式人員使用相同術語
12.遵行程式碼慣例

7. Unified Process(RUP)
由 IBM 提出, 具三大特點, 四個階段和九個核心流程.

主要精神為：1. 專案進行採用 Iterative 程序分階段漸進地完成專案功能；2. 廣泛使用 Visual Modeling 於商業需求分析、系統分析與系統設計；3. 強調架構設計；4. 對每項工作所需要的技術、工具、做法、範本、檢查項目均有詳細的定義，架構完備且具有可調整的彈性。

三大特點

1. 軟體開發是一個疊代(Iteration)過程.
2. 軟體開發是由使用案例(Use Case)驅動.
3. 軟體開發是以構架設計(Architectural Design)為中心.

四個階段

1. 起始階段(Initial phase)：進行可行性研究, 定義專案大小及涵蓋範圍, 評估專案所需的能力, 時程與經費, 及資訊系統預期達到之效益, 了解商業模型及需求.
2. 精細規劃階段(Elaboration phase)：擬定專案計畫, 系統特性與架構, 確認商業模型及需求, 進行系統分析與設計.
3. 建構階段(Construction phase)：建構產品並進行單元, 整合測試.
4. 移轉階段(Transition phase)：將產品分批交付給客戶驗收測試, 並進行使用者訓練.

九個核心流程
1.商業建模
2.需求
3.分析和設計
4.實現
5.測試
6.部署
7.配置和變更管理
8.項目管理
9.環境

8. Agile Process
特色有
1. 強調客戶與開發人員形成密切合作的團隊, 因為客戶無法於初期定義完整的規格.
2. 採用 Iterative 與 Incremental 方式分階段進行, 密集 review 是否符合需求.
3. 強調團隊合作, 賦予高度的責任, 團隊有自主權得以因應變化做調整.
4. 流程可以簡單, 但規劃與執行必須嚴謹.

UML 有我需要的嗎

先說明情節好了...其實就是人家說的ETL.
我的程式都很小約三,四千行以內, 每一隻獨立運作, 有時可能會有關聯, 互相影響.

我的問題情境是這樣的, URL 我要使用嗎?
想來想去, 覺得我有一個困擾, 是這樣的 -
程式雖小, 但缺少概觀性的說明, 無論是文字或是圖表. 所謂的概觀就是粗略的說明輸入/出, 處理邏輯這樣就好. 但要達到可以讓新人快速的了解, 也可以協助資深人員追查問題.

那 UML 有哪些可以協助我呢...

1. 使用案例圖(Use-case diagram) - 這不是我的主題, 我不需要 : 一個使用案例可用來說明系統所提供的一項功能, 使用案例圖主要的目的在幫助開發團隊設想系統功能的需求, 其中包含了參與者（actor, 也就是跟系統互動的人）與基本處理程序的關係, 還有不同使用案例之間的關係.
2. 類別圖(Class diagram) - 看起來也不需要 : 類別圖描述不同的個體(人, 事物和資料)相互的關係, 換句話說它表示了系統的靜態結構.
3. 循序圖(Sequence diagram) - 沒有這麼複雜吧 : 循序圖描述特定使用案例或是特定使用案例的一部份詳細的流程, 它們大多能讓人望圖生義, 並可以依照順序描述不同物件之間的呼叫關係, 也能夠詳細地描述給不同物件的各種呼叫.
4. 狀態圖(Statechart diagram) - 我們的邏輯處理中好少 State 觀念 : 狀態圖為一個類別模擬了所有可能的狀態, 還有該類別要如何從一個狀態轉換到另一個狀態.
5. 活動圖(Activity diagram) - 有時可能只有一個 Class 呢, 那這要嗎? : 活動圖用來描述在進行一項活動時,兩個或是多個類別 件之間程序的控制流程.
6. 元件圖(Component diagram) - 哎呀到底有沒有我要的 : 元件圖描述系統的實體狀況, 它的目的在於描述該系統中的軟體跟其他軟體元件的依存關係.
7. 部署圖(Deployment diagram) - 談的有點遠了, 不是我要解決的主題 : 部署圖描述一個系統要如何部署到實際的硬體環境上, 它的目的是要表示系統裡面不同元件實際上所要運作的地點, 還有這些元件要如何互相溝通.

結束了嗎?

迴歸測試（Regression Test）

迴歸測試的目的在於測試之前(上一個版本)已經測試過的系統功能是否在系統變更之後, 仍然能夠保有運作的正常.

簡單的說就是常見的Ａ改好, 卻又另外出現了Ｂ的問題, 這種問題是寫程式的人都遇到的問題, 卻是主管最不願意看見的問題.

近來單元測試（unit test）的觀念已廣為接受, 如果單元測試的案例建立的足夠完整, 那麼進行迴歸測試的成本也就可以省起來, 這也是我認為 unit test 最大的優點, 這些案例就好比是一劑強心針濟一般, 可以讓我安心的上新版的程式.

如何確保軟體品質

如何確保軟體品質?這是每個作軟體系統的人都會遇到的問題, 但也許都還沒有時間做.
本人使用VS Studio + NUnit 已經有一年多的時間了, NUnit 其實是一個很簡單的工具.
重點還是在測試計畫這件事上到底做了怎樣才是? . 而不是有做Unit 就表示有做到軟體品質...
最近一直有一個想法, 可以不要做測試可以確保軟體品質? 如果有這樣實在太好了, 因為測試這件事真的很辛苦.
先來想想目的好了 : 簡單的一句話 : 確保軟體品質.
品質這件事所含的事太多了, 找 Google 問去, 不多說.
換個方式想, 先列出違反品質的事情, 行為, 如果這些事情我都可以避免, 那我是不是可以不要做測試了? 簡而言之 : 我有一個簡單的方式達到確保軟體品質. 哈哈~~ 這就是我最近一直想的.
或者說為達確保軟體品質, 創造一個制度, 有一定的制式步驟, 並且有防範的措施, 稽核, 但就是簡單.
...
想想目前的工作型態.
1. 維護的工作居多, 而且目前程式正確的在跑, 在被使用, 所以假設沒有Bug.
2. 既然沒有 Bug, 那我只是加一個小功能, 我夠 Quality, Careful, 我寫了程式就是一種保障.
居於以上兩項前提, 我需要做 Unit Test 嗎?
這樣的想法很像有點偏見, 再想想 Unit Test 有怎樣的好處好了.
1. 杜絕再犯.
2. 有Unit Test 就表示有一定的品質, 具有被認可性, 說服信.
3. 可以重複被使用.
4. 對於新手可以快速的驗證.
這些好處, 對我而言是好處嗎? 有其它方式可以彌補嗎?
1. 杜絕再犯. -> Review, 改善機制.
2. 有Unit Test 就表示有一定的品質, 具有被認可性, 說服信. -> 有時人就表示了, 好比信譽.
3. 可以重複被使用. -> 我需要嗎?
4. 對於新手可以快速的驗證. ->

人月神話 之 人月 (man-month)

案例一
記得大約四年前的一個專案，那個專案只有兩個人，一位是專案負責人兼系統分析師 Tim ，另一位是系統分析師兼程式撰寫也就是本人。
專案進行兩三個月後，專案負責人就把整個專案交給我一個人負責了，也就是說本人負責整個專案的系統分析及程式撰寫。專案接近尾聲的一個月左右，我估計不管我怎樣加班，怎樣順利的進行，我都無法在期限內完成。於是我向我的專案負責人提出這個問題，並且向他要取一個人力 Wendy 幫我寫報表，在我們協調後的結果，我只要 Wendy 協助撰寫報表的 SQL Code 的工作，以我對 Wendy 的能力認知，我相信這一個專案應該可以在時間內準時交件。
Day1 :
我利用大約 2 小時的時間向 Wendy 解說他的工作內容，並且向他解釋了資料庫中的部份 E-R ，我想這樣 Wendy 就可以開始工作了。
Day3 :
Wendy 完成了大約 5 隻 SQL Code，這裡面的幾隻 SQL Code 尚有部份欄位沒有擷取的，原因是因為 Wendy 還不是很清楚，這些欄位要從哪一個 Table 取得。當我看指細的檢查這 5 隻 SQL Code 後，我把沒有擷取的欄位補上。在這個過程中，我發現有些資料欄位的擷取連來源的 Tables 都錯誤了。當天我立刻決定把計畫取消，把這個工作拿回來自己做。
回想這整個過程。當我和 Tim 討論我的人力需求問題時，Tim 就告訴我，要安插一個人力進到專案中，會有一定的困難，沒有想像中的容意，要我先有心理準備。當事情結束後，我也終於體會到這其中的困難。
當專案已經延誤時，增加人力的投入，還必須付出教育順練，溝通，新手學習等的成本。是必需要詳細評估與計畫，這樣的投入才會有成果。不然就會如同我上面的經歷依樣徹底宣告失敗。
案例二
今天和客戶開完會議，客戶和我們再次確認下週行程。
1. 完成 N 個需求的功能.
2. 完成 1 張報表, 以 Crystal Report 製作.
問題來了，這個專案中，我們沒有人使用過 Crystal Report，並且所有的人力估計投入第 1 項工作已經吃力了。唯一的方法就是請求一位人力 judy 支援 ，專門完成工作項目 2 。Judy 具有開發 Crystal Report 的經驗，並且可以獨立與客戶溝通，是我們的不二人選。因為專案的某些特性，我決定使用客戶的資源，請客戶的 DBA 及 SA 向 Judy 解說資料擷取的細節及需求規格，使得這一件工作不會用到已經投入工作項目 1 的任何資源。一星期後順利完成我們的目標。