2000/04/23

軟體開發過程的重要性
分類:管理


上週我們討論軟體開發的知識庫,大家反應的意見很多,我也深深地感覺到現在軟體業在開發的過程因為人力及時間的不足,所以經常日夜趕工,而造成非常多的惡性循環,這一次我們討論軟體開發的過程經常性會發生的錯誤,這些錯誤有必要讓各單位能充分的了解並互相配合。

一般在軟體系統開發最重要的就是開發的過程,我提出三點最重要的相關過程,不但是經理人每日要提醒自己的,也是程式開發者避免要犯的錯誤,第一是不紮實的系統規劃,第二是日夜趕工的開發方式,第三是品質確認。

不紮實的系統規劃:系統分析師往往是由資深的程式設計師來擔任,往往一個案子在開始開發之前,要經過需求分析、建構雛形、客戶訪談......,這些過程是不能被省略的,這些系統分析師或是專案負責人,往往會忽略掉這些重要的過程,而跳到直接撰寫程式的錯誤結果,如果我們無法在一開始的五個小時就做好先期的規劃與設計工作,未來可能會花五十個小時來彌補。

日夜趕工的開發:有一些公司有短期趕工方式來快速的建構核心及雛形,他們認為如果讓開發人員有足夠的動機,他們就可以克服任何困難,完成系統開發的工作,但是這種快速短期開發的過程往往不符合市場或者是客戶的需要,除非在日夜趕工之出就能規劃出目標來,不然往往會趕出一個短期不成熟的產品。

品質確認:在一個匆忙的專案最會省略的就是設計與程式碼的審查確認,只做表面性的測試,這一點大家總認為只要把這一些工作交給測試單位就完成了,但是測試單位知道程式碼在哪裡?他知道所有的設計細節嗎?這也是兩個單位溝通最多的地方,而不是只是把成品丟給測試單位,然後設計與測試兩個單位就開始反反覆覆的皮球丟來丟去,所以品質的確認不但要做到系統模組設計的確認,也要做到程式碼的審查。

上述的三點是我認為程式開發重要的三項工作,也是最容易忽略的三個過程,系統開發者最自負的也是這三個過程,但是這三個過程並非在自己的腦中流過,而是在一個團隊中確認的過程。

2000/04/15

建立軟體開發的知識庫
分類:管理


現在的企業非常重視學習與成長的環境,這兩個月有關企業知識庫的建立有很多的書籍及雜誌都在討論,但是至於如何建立知識庫的方法,往往過於概念性或者是針對大企業在討論......

軟體開發的領域中有很多文件化的分析方式,例如從最早的資料庫系統(Dbase)就把資料表,輸出表格,輸入表單做了做標準化的規格建置,讓系統的開發過程中的溝通,可以很容易的透過開發工具本身完成,而早期的結構化分析方式,也是強調要利用功能性的需求來分析一整套的系統,分析完成後只要照著表格來寫程式(Coding),就可以完成,但是這些方式往往因為要有相當經驗的系統分析師來作業,開發時程況日費時,經常做出不可操作的系統。

所以現在的開發工具強調即視性(Visual)與物件導向,利用雛形法來減少開發錯誤的流程(但是不一定可以快速的開發),而開發的過程中就一定要分階段的檢討模組的適當性與合理性,不斷地修正,而這個修正也是知識的累積,所以最好能把這些開發的過程分門別類,整理後隨時輸入一個大的資料庫,這個資料庫以傳統的二維的欄位(專案名稱、功能分類)已經達不到檢索的需要,因為不是資料量太大,就是找不到資料,所以我建議以增加一個使用的模型分類,例如是網路上的通訊協定,作業系統檔案,作業系統多工等等,用系統模型來建立這個資料庫的Index,可以有效的縮小檢索的範圍,也可以跨越不同的專案來學習相關的知識,但是這個Index很重要的是要隨時間來改變,要經常性的討論修正。

如果學習型組織擅長創造、取得、傳遞知識,而做達成這個目的就必須配合這些新的知識和見解而改變行為,我們建立的這個Index就是這個行為。

同樣的,如果沒有配合調整工作的方式,這些新的Index就只是創造了改變的可能性,而非真正造成改變。

2000/04/09

用最簡單的方法
分類:創新


開發軟體系統經常會有沉重的包袱,就是要維護以前的系統,所以我們的思考方式經常會被限制住,久而久之就會用舊的方法來解決新的問題,有時候會事倍功半,用最簡單最笨的方法有時後也是最好最具創意的做法,所以常常把自己的頭腦規零,有一定的好處喔!

舉一個簡單的例子,通常我們寫很多機房傳遞訊息的程式都想到就是用Socket來傳遞,然後用資料庫來記錄傳遞的訊息或是過程,光光這兩個包袱,我們就要先寫Client/Server的程式兩支,然後在設法要利用ODBC取出資料庫的資料然後傳給Server,中間牽扯非常多的關卡,如果有任何一個關卡出現了問題,整件事情就是失敗的設計,雖然這個系統的時效性及架構非常的好!

如果上面的例子是每日的批次作業的話,我們可以考慮用文字檔案的模式,產生要發送的訊息,然後透過FTP Server或者EMail Server來傳遞資料,雖然時效性不是最好,但是都是用現成的系統來傳遞訊息,只要系統夠穩定,應該是最快也是最好的解決方式,但是同時解決傳遞訊息的問題時,我們要考量的不只是程式設計或系統分析的方便性,還要全面考量到其他單位的系統維護操作,客戶服務或者甚至客戶本身是否會有影響到操作的問題。

現階段的軟體開發工具非常的多,程式設計師的困擾應該是在開發工具的熟悉度,我們應該利用開放的心胸各方面去學習,DOS的批次檔執行編寫也可以解決很多很多的問題,現在電腦應用系統,已經不一定限制在Windows 的作業平台了,學習任何一種電腦程式語言,一定要了解並且多方運用,有時候你會發現為什麼10分鐘可以完成的事情,以前的人要用10小時做完,只要有充分的理由,最笨的做法是有時候是解決問題最好的方法,您隨時要有革命的創新理念。

一個系統最有價值的地方我們通常是看的不清楚,現在流行成立新的網站,成立之初只要把同類型的網站複製一份過來即可,但是要成功的經營,一定要持續不斷地在核心技術以及自己的價值鏈上提昇競爭能力,簡單地突出自己的地位是很好的做法喔!

2000/04/03

心智分枝圖
分類:創新





有時候經常會忘東忘西的,跟朋友聊天也會時常忘記重要的關鍵,這個時候應該是應用分類的方式來記憶與創造一些新的思考方向,最近也因為工作的關係,回去看看別人寫過的程式,感覺獲益不少,雖然已經了解其中的運作過程,但是,所謂溫故知新可能就是這個道理吧!

於是今日把創意FORMAT(Business Beyond The Box)這本書拿出來研讀,再研究一下如何創意思考,其中有一個方法就是心智分枝圖,把問題寫在一張紙的中央,並且畫了一個圓圈,然後想一些分類的方式畫出分支,然後從這些分支中找出答案,這個方法雖然天馬行空,但是是很好找出這個問題的解答,或是相關的話題。

人的思考方式,思緒經常是變換不定的,由直線的思考方式來看,這種分支方式的思考模式有更大的空間,但不至於把討論的主題拋開,可以有效的拉回來,當我們開始思考的時候一個念頭會觸發另一個念頭,這種思考的模式有助於思緒的組織性與結構性,當你的腦海中有一些具體事件或是關聯的圖像的時候,都可以很快的畫在紙上,並且有效的作一些分類。

以前寫程式總是先在紙上或是心理構思完成後才開始動手寫,但是經常發現,寫出來的東西擴充性很差,不然就是錯誤一大堆,一直補東補西的修改,結果就認為這個系統是一個大怪獸,物件導向的程式語言的語法雖然避免掉了一些我們常犯的錯誤,所以應用這種心智分支的思考模式,可以預先把所有的問題先找出來,並想出良好分類的方式。

我們時常會落入自己工作習慣領域的迷思,總覺得自己是很重要的,透過這個簡單的訓練,或許也可以想想每一個人在分工合作的重要性。