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) - 談的有點遠了, 不是我要解決的主題 : 部署圖描述一個系統要如何部署到實際的硬體環境上, 它的目的是要表示系統裡面不同元件實際上所要運作的地點, 還有這些元件要如何互相溝通.

結束了嗎?

VISTA-日本BRICs經濟研究團隊所提出

者裡的 VISTA可不是 MS 的新作業系統, 而是 Vietnam, Indonesia, South Africa, Turkey, Argentina - (越南,印尼,南非,土耳其,阿根廷)最具發展的五個國家, 也有人稱新新興市場, 這是日本 BRICs經濟研究團隊於 2006 年底所提出的研究報告.
報告指出 : 未來50年內, 也就是於2056年前, VISTA 的 GDP 將成長 28 倍來到, 268兆美元, 超越七大工業國.
不過2006年的 GDP 約 1 兆美元(約為金磚四國的1/4), 為何有這樣的結果, 其動力如下.
1. 具天然資源 - 諸如石油, 鐵, 黃金..等.
2. 外資引進.
3. 內需強勁 - 2008年這五國的人口約為 5 億, 其中印尼就佔了一半.

迴歸測試（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. 對於新手可以快速的驗證. ->

輕鬆資產配置

1. 股債比率
債市的比率提高主要是降低資產配置的坡動性.
以2008年的狀況看來, 股債比約各半.
此外債市因為波動部大, 可以單筆投資, 定期的效益不大.
2. 區域分配平均
股票型的基金要做到防禦就是 : 區域分散, 產業也分散.
建議歐, 美, 亞, 新興, 主題產業 五等分.
3. 選擇減碼時機
選擇時機逐步減少應該要減碼的部位, 而非一次贖回.
4. 補足失衡部位

PS. 債市也會套牢
其實現在這總觀念大家都懂, 外加現況的慘狀, 從股票市場贖回的大筆資金一窩的網債市衝, 會不會行程追高殺低.
想想為何會有熱門的績金, 非常的熱賣, 這種熱賣的基金, 就好比熱門的商品, 只能短持, 是否能長抱就必須要思考清楚了.

多頭已經結束. 海外基金投資本由多頭攻擊, 轉為分散防禦投資

美國時間1/22, 聯準會主席柏南克宣佈25年來的最大減碼幅戶, 企圖拯救疲弱的美經濟. 政大金融系教授殷乃平斬釘截鐵的說 :多頭已經結束. 海外基金投資本由多頭攻擊, 轉為分散防禦投資.
這些引響短期內無法解決, 估計2-3年都屬於空頭時期, 固資產配置更顯重要. 至於定期定額的投資應作好分散區域, 股債配置, 選擇相對抗跌的市場.
美國市場應避免金融與房地產類股, 因為美國房市疲軟的情況, 至少要花上3-4年才能好轉.
英國市場因為金融與房地產占英國股市權重很高, 所以也要少碰.
日本的經濟則具有較多的虞慮, 建議出脫, 其他如印尼, 新加坡, 印度 比較有成長空間.

安裝升降式曬衣桿

很簡單的, 只要在天發版上鑽兩個洞, 然後鎖上即可.

這老舊的鑽洞機使用起來真吃力

就是這一支老舊的鑽洞機, 現在的工人已經沒有人再使用這一台了, 拿起來雖然不會吃力, 不過鑽起了就有點吃力了, 尤其是在光鑽出洞的時候, 老是亂跑無法好好定位.

利用採光照的空間曬衣

哈哈, 這一個點子實在太棒了, 不知道有沒有像我這樣子, 我的採光照是在後陽台, 而且是外推式的, 所以空間上有很大的運用空間, 沒有好好的運用真的是讓費了, 會有這樣的想法最主要是想要讓衣服曬到太陽, 裝置之後覺得太棒了, 而且全部 DIY 完成.

換裝大同氣密窗以及窗簾

新買的二手屋, 還沒搬進去住, 經過一個颱風的狂掃後, 地板是積水的, 慶幸的是還沒搬進去住, 氣的是怎買到這種房屋, 只好認命換裝了喔.... 換裝後的一兩天還可以, 第三天開始風變大了, 氣密窗就擋不住了, 一天到晚都是風切聲, 害我連主臥室都不能住人了, 因為尖銳的風切聲會使人受不了, 現在正在找尋方法解決中.....

也順便安裝一下窗簾, 窗簾是找窗簾工廠來裝的, 去店面的時候, 服務態度很好, 來裝的師傅剛好相反, 也隨便裝一裝, 盡然把動打在窗戶的框上, 差點沒有被氣死.

LG WT-Y122G 洗衣機

這是一台12公升的變頻洗衣機, 雖然我們家只有兩口子, 不過最後還是買12公升的, 為的是要可以洗被單, 以及薄被. 目前所使用的洗衣機, 就有洗不動的情況發生, 就以這個經驗, 所以....就敗下去了.

今天剛好利用假日的時間把新買的床罩組拿來試洗一下, 感覺還不錯, 可以正常的洗動, 洗衣機也蠻安靜的.

林內牌自動清洗除油煙機RH-8031S

這台抽油煙機和數位恆溫熱水器RU-1260FE 一樣是在新竹中山路的一家小店面購買, 價錢是$6,200元, 裝到好, 算是物超所值.

有試用自動清洗功能一下, 聲音很大, 而且有點刺耳, 說明書上說這是因為高壓所產生的聲音, 不知道這樣的功能將來實不實用...哈哈

林內大廈專用強制排氣數位恆溫熱水器RU-1260FE

為了熱水器的事情, 打聽了好久, 終於決定林內RU-1260FE, 我們最後在新竹中山路的一家小店面購買, 價錢是$9,500元, 外加安裝所需的排氣管$500元, 總共$10,000元.

我僅存的優點-勤能補拙

A:我對產業知識非常的瞭解, 系統開發也有多年的經驗, 不管是要管理多人的團隊, 或是分析複雜的系統, 甚至撰寫艱深的程式, 都可以輕易的應付.... 以上是我的個人簡介.
B:我覺得我不管在哪一方面, 表現的都是平平, 自覺沒有什麼優點, 唯一僅存的優點-勤能補拙.
這是出自兩個不同人的話, 要說什的好呢?
通常應該沒有人會說出像 B 這樣的話, B 會說出這樣的話, 可以看的出來他有問題. 要怎樣呢?
結果又會怎樣呢?

己所不欲，勿施於人

所謂「己所不欲，勿施於人」，就是用自己的心推及別人；

自己不願意別人怎樣對待自己，就不要那樣對待別人。「己所不欲，勿施於人」簡單地說就是推己及人，它和中國民間常說的將心比心，設身處地為別人想一想等等，指的都是一個意思。

最近公司裡時常聽見一些覺得很無聊的話，我真不懂這個人在講什麼，怎會這麼無趣，而且時常就會說出一些傷害別人的話，虧別人的話。

我相信他應該也不喜歡聽見別人講這種話，可是怎會這樣呢？他想掩飾心中的某些事情嗎，還是只會講這樣的冷笑話，而且有時候是傷害別人的話。

失去才知寶貴．到那時悔之晚矣。

在過一陣子, 就是Vendor合約到期的期限了...因為我們公司想樣換另一種理想化的合約, 卻有點不確實際.
合約的內容是這樣的 :
Vendor 必須在我們公司駐廠, 完成我們交予的工作.而我們支付 Vendor 費用的方式則是分成兩部分 :
1. 一為固定費用 X/2, 依據 Vendor 在我們公司駐廠時間給付;
2. 其二視 Vendor 是否完成工作再給付 X/2.這樣的方式看起來是非常的好, 公司具有制衡 Vendor 的力量, Vendor 如果提早完成交付的工作, 也可以提早或取得更多籌賞.
但真的這麼簡單嗎?
我個人困難點有...
1. 工作量難以衡量.
2. 工作品質難以界定.
3. 就算真的有能力提早, 一定有額外的工作嗎.
4. 目前我們這個行業, 市場沒有這樣的合約, 廠商何必屈就.
5. 會換約就是要改變現在的某些問題, 市場機制尚不到可以接受這麼大的劇烈改變.
6. 新約的內容沒有達到雙贏的目標.
我想我們將會失去這一個 Vendor...
失去才知寶貴．到那時悔之晚矣。

我對軟體的態度是龜毛

這是別人對我說的話.
一個平靜的湖泊來了一隻蜻蜓, 蜻蜓在這寧靜的湖面上輕點一下, 那蜻蜓至少距離我有 1 公里.
我很訝異, 我為何只有這樣的感覺.
"這蜻蜓點水" 只會成我的記憶, 還是會起我的記憶, 或是召換起我會軟體的作為.

人月神話 之 人月 (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 的任何資源。一星期後順利完成我們的目標。

2005 09 18 苗栗南庒, 蓬萊溪

沿路上的美麗花朵..