在學校授課"軟體工程"時我總是會將這個議題提出跟同學們說明，但為什麼要開宗明義地說明"軟體特性"，因為我在軟體公司任職20多年來經驗不論是老闆、主管、工程師與同事們都沒有很瞭解"軟體的特性"，所以我在軟體專案過程中需要不斷說明軟體的特徵，我舉例當主管常會說客戶只是改欄位名稱與輸入方式，為何你要改這久時間，它們不知道若沒瞭解這欄位的屬性或型態，貿然修改會造成修改窗戶結果窗戶好換大門壞的窘境，當這欄位是主鍵值(PK)那更要小心他所影響的相關程式，主管們不知道我們需要1個1個檢查，因此我才會將這觀念跟同學們分享並說明來避免產生這觀念落差。

何謂軟體的特性？

• 我簡單將它做初步整理他有下面的特性：
• 不容易看見程式撰寫的成果需要執行。 (程式碼實體看不見，需要有工具執行才能看出成果)
• 軟體技術高持續翻新，需要不斷學習。
• 程式碼度量非常不容易，不能只看程式行數就能判斷效能。
• 後續軟體轉寫所需知識繁多且密集，有些系統需要跨入不同領域的知識才能完成。
• 撰寫程式的工作目前很難有自動化工具來完整產出系統。
• 撰寫程式的能力成熟度會影響軟體品質很大。

因為有以上的特性，所以在軟體專案的專案管理就很難將專案進度、品質、成本管控都產生大小不一的問題，變成專案管理會很困難，一般來說通常我們很難一直盯看工程師開發程式，除非採用結對程式開發(Pair Programming )方式【1】或同仁審查(peer revuew)但這種方式成本很高，所以一般會採用1個工程師撰寫程式，假設當設計師1天撰寫1個功能為800行或1000行，初期我們很難判斷哪一個CP比較高，因為都達到客戶需求，除非做程式審查(code review)、同仁審查(peer review)或嚴謹的測試才能確認，這是因為程式有無法馬上看出成果的特性與其複雜度，所以沒法馬上告知工程師這程式寫好不好問題。加上程式技術不斷更新工程師採用技術是否穩定也很難度量。
在有規模的軟體公司會制訂軟體開發的規範與制度來解決這些問題的產生，如CMMI 軟體能力熟度、ISO9000、ITIL.等國際軟體規範【2】【3】，當然執行這些規定與紀律需要付出成本。
在程式設計師撰寫程式時所需要懂的技術知識越來越多，舉例撰寫網頁程式時，程式設計師需要懂網路運作如IP網址、DNS、SSL及需要質感設計(Material Design)讓使用者可以更舒適操作介面，當然沒有這些技能也寫出來網頁，但若碰到網路架構問題或使用者體驗問題那他就無法解決就需要有資深工程師來協助處理，這就會無法讓公司提升客戶滿意度且會增加這專案的成本。
目前有些程式產生器可以幫程式設計師產生程式，但要能實作到客戶身上還需要程式設計師的修改或新增元件才有辦法讓客戶順利使用，現行程式除錯的工具如開發軟體環境的除錯機制或Xdebug外掛工具，都可以幫忙我們加速程式除錯的進度，但還是沒法完全由工具取代程式設計師的除錯動作。
我們在撰寫程式也會發現同功能不同工程式師撰寫的程式，會因為其技術背景不同產生不同的程式碼與元件，舉例當在撰寫呼叫日曆來填寫日期時若沒有規範工程師採用哪個元件，就有可能造成每個人用日曆元件都不同造成日後維護的問題，這種問題跨區域開發團隊很容易產生，所以軟體會因為人的特質與能力成熟度程式品質會有影響。

最後做個人建議，當你同事(PM、SA、SD)不清楚軟體的特性時，他們在專案進行時做出的一些判斷會影響你的軟體開發的工作，尤其是專案經理(PM)或主管答應客戶或做不利於軟體開發的決策時，這會增加你執行軟體專案的時間與成本，所以在適當時間做這些觀念溝通時很值得。

資料補充與參考文獻

【1】結對程式開發(Pair Programming )這開發方式有1台電腦同時2人開發，這方式是一
人撰寫程式一人幫他檢查程式，這模式的開發成本很高，2人的程式水平建議要
相當，不然程式撰寫效益就會遞減。
【2】CMMI (Capability Maturity Model® Integration，能力成熟度模式整合) 起源於美
國國防部與卡內基美隆大學（Carnegie-Mellon University）合作所設立的軟體工
程學院（Software Engineering Institute，SEI）。
【3】資訊技術基礎架構庫（Information Technical Infrastructure Library，ITIL）