jim yeh on 五月 18th, 2007

喲哪桑提出軟體維護的 Rule of Thumb:「解鈴還須繫鈴人,解bug要找寫bug的人」。有網友對於這個看法發表評論,他認為喲哪桑的想法太不切實際,因為公司人員會來來去去,所以,公司營運不可能把相同一件事都一直由某個人處理。然而,喲哪桑學長說的卻真的是軟體開發的常見問題,很多軟體常常會找不到人來維護及修改,寫程式不難,但要看懂別人的程式然後知道如何去修改它卻不是一件容易的事呀。

但公司卻不能忽略現實因素,如果軟體開發者無法負起維護軟體的責任,那麼程式是否就註定無法修改與維護呢?那倒不見得,同人就曾經接手過一個專案,該專案是某省屬行庫的銀行行內整合服務系統因應銀行加值網(VAB)的上線,程式必須配合修改。

然而,困難的是該系統原設計者乃至於開發團隊早已離開公司,也沒有留下任何相關文件,我僅能從曾參與該系統討論過的同仁片斷印象拼湊出斷簡殘章中找線索,然後再追踪原始程式碼以重建此系統的設計知識,而且,我只有一個月的時間把程式改完,如果做不到,那麼公司將會失去此重要客戶。

有人告訴我,這個系統的設計方式是很有彈性的,但也因為這樣,在缺乏文件的情形下,沒有人看得懂高明的設計者的設計意圖,只好靠有經驗的開發者(就是才剛進公司不久的我啦)的幫忙了。結果「臨危受命,幸未辱命」,我成功地把此套系統承接下來,寫下說明文件並且陸續擴展其功能,使客戶對專案成果感到滿意也讓我得到績優員工的殊榮。

但當我離開那家公司時,我發現此系統仍然會有維護的問題,而其真正的原因其實是在於管理高層忽視知識管理的重要性,而不是系統難以維護修改。

雖然,正如 Kenming 所說,軟體系統的開發,絕大部分是以專案(Project)的型態來進行的;但也別忘了執行專案的真正目的,不外乎是能增加組織的機會或降低環境對組織的威脅。所以,規劃專案成本,要用生命週期成本的觀點來看,而不要只是一味地降低專案開發成本。正如下圖所示,降低開發成本對增加維護成本會產生非線性的影響。

表面上降低開發成本可以減少軟體取得成本而降低公司的財務風險,但卻會因為其設計未考慮將來軟體的維護修改而造成軟體維護成本的增加,這正是為了節省軟體開發成本常見的捨本逐末基模。

在軟體專案的成本規劃中,不應該只考慮軟體的開發成本,而是要考量軟體的生命週期中,因為軟體為組織所帶來的淨現金流量,因此除了軟體開發的研發費用與成本以外,還必須思考軟體的維護修改成本與費用,這樣的成本規劃才是有用的專案成本規劃。

可惜,大多數只著眼於近利的管理者卻常把焦點放在「如期如質交出符合客戶需求及使用者需要的軟體」,以為軟體系統的成功就是專案的成功,但卻忘了,未來無法維護的軟體其實是無助於符合組織策略目標的。所以站在目標管理的立場來看,開發出軟體系統符合需求但沒有考慮後續維護的軟體專案,不能算是成功的軟體專案。

我們回過頭來看學長的觀點吧,喲哪桑說:

要讓軟體活得快樂活得好,就要便於修改與維護,就得讓軟體開發者負起維護軟體的責任,承擔軟體維護的工作。不能專叫別人來擦屁股呀!

看了學長的這一段話,我以為對於專案的成功而言,軟體便於修改和維護是必須要有的條件,但卻不見得一定要讓軟體開發者來維護程式,因為公司常會因為某些不可抗力的因素,使開發者無法負起維護軟體的責任。那怎麼辦呢?先來思考為什麼開發者無法開發出便於維護與修改的軟體吧,請看下圖。

軟體價格是由市場供需機制所決定的,所以當市場競爭愈激烈時,軟體的價格就相對地會降低。而開發者為了獲利,於是就必須想辦法降低開發成本,才能獲取相當的利潤,於是軟體便於維護的想法就會愈來愈難實現了,因為軟體價格實在太低了,當我們想使軟體便於維護時,軟體的價格卻低到讓我們沒辦法實現這個理想。

其實,這樣的思考模式正是專案成本估算之軟體價格的迷思,把軟體價格當做成本估算的基礎,這樣一來,軟體開發就沒辦法重視專業,只能讓外行(市場因素)領導內行(研發設計專業),這可是軟體專發者痛苦夢魘的開始呀。

當然,不能忽略市場競爭,但開發者應該用更有效的方法來回應嚴苛的挑戰,而非自暴自棄呀。面對獲利的困難度,要思考如何可以增加邊際效益,才會有足夠的空間思考軟體必須便於維護及修改,所以即使降低軟體的價格,我們依然要有能力要讓軟體便於修改及維護。

雖然,專案所要開發的軟體只是「一次性」的努力,整個專案沒有邊際效益可言,但站在一個專門提供軟體開發的專業資訊服務提供者而言,集合多個專案的開發經驗與智慧,整合開發流程及共用元件的模組化及回應客戶差異需求的能力,要提昇邊際效益並不是問題。而更進一步地,運用設計的延緩策略,在軟體的設計階段,就先思考到要如何使軟體便於維護。

以軟體設計的語言來說,就是設計良好的軟體架構,落實設計與實作分開的設計理念。雖然,好的設計需要花較多的開發成本,但它卻是專業資訊服務提供者能否產生邊際效益的關鍵,同時也大幅降低了軟體的維護成本,其所花費的人力、物力與時間,可真的是非常值得投資的哦。

Powered by ScribeFire.



     

4 Responses to “專案成本估算之軟體價格的迷思”

  1. Ming 說道:

    我就是那個網友。:)

    你這篇分析得很詳細,也十分中肯。

    [...真正的原因其實是在於管理高層忽視知識管理的重要性,而不是系統難以維護修改。]

    [...大多數只著眼於近利的管理者卻常把焦點放在「如期如質交出符合客戶需求及使用者需要的軟體」,以為軟體系統的成功就是專案的成功,但卻忘了,未來無法維護的軟體其實是無助於符合組織策略目標的。]

    這都點出,所有的問題都是管理性問題,完全跟技術無關。不幸的,這些都是普遍存在,國內外皆然。好的設計很重要,重複使用元件很重要,但是沒有管理,怎麼推動「好的設計」、「確保重複使用元件」?所以,身為管理者要負起全部的責任。

    沒有好的管理,就算制定良好的工作流程、作業流程,僅有規劃、紙上作業,沒有執行與監督,一切都是空談、作夢。

  2. 喲哪桑 說道:

    我很喜歡這一篇,很久沒看到這麼過癮的分析了!我也明白Ming所說的, 許多管理者未必重視維護, 不過這些不中聽的話, 還是要有人說! 因此, 我斗膽又寫了一篇為了維護而設計, 請同人與Ming指教.

  3. windlove 說道:

    我覺得在軟體裡,特別是台灣,管理上的問題遠超過技術的問題
    包括在軟體公司裡,看到專案的進行,常會發生問題不是管理上就是政治上
    我還是覺得在軟體不管是專案或是產品的進行,其實要養成不能只考慮技術的習慣

  4. [...] 喲哪桑提出為了軟體維護的二種設計策略,在設計的彈性策略方面,提到我〈專案成本估算之軟體價格的迷思〉某種程度上也說明了為何開發者難以達到彈性這個理想。既然學長提到了,我也好藉這個機會表達我在這方面的看法與經驗。 [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">