軟體過程主要指的是軟體工程過程，即在軟體開發的過程中組織內發生的各開發階段、各項開發活動的先後順序及其關係。這些活動有機的運轉即可以完成軟體開發過程。

有人將軟體生命週期當作軟體工程過程，這個觀點是有偏差的。軟體生命週期指的是軟體從無到有再到消亡的過程，是軟體本身的特性。軟體工程過程是建立軟體或者修改軟體過程中所經歷的分析、設計、實施、維護的過程，該過程的作用物件是軟體。對於一次性開發軟體，可能軟體工程過程近似於軟體生命週期中的從無到有的過程，但對於非一次性開發的軟體，即軟體需要通過多次版本的更新維持更長的生命週期的軟體，每一次新功能的開發過程都需要軟體工程過程。因此，有必要將二者的關係進行正確的區分。

軟體工程過程是以工程化的思維，通過可複用的過程來保障軟體開發工作能夠順利的、可重複的進行的過程。為達到這個目的，軟體工程過程的概念也隨著軟體規模的擴大、複雜性的提高在成熟並發展著。為了簡練的表達不同的過程，提出了軟體工程過程模型的方式，簡稱過程模型，用一些形象化的、標準的名稱來形成一套過程體系或方法論。目前常用的過程模型有瀑布模型、增量模型、統一過程模型、敏捷模型等等。

 任何過程模型，都是按照理想的環境定義的，企業要想採用過程模型來規範軟體開發過程，本人認為以下的過程和思路是非常重要的。

一．正確認識過程模型的作用

前文已經提到，過程是一個活動的序列，無論是否採用過程模型，只要在做軟體開發工作，就必然有一系列活動，這自然而然就是一個過程。可見，過程是客觀存在的，不因沒有采用過程模型而消亡。但是，強調並規範軟體開發過程可以使得原始的隨機的活動被規範到大家一致認可的階段和活動中，形成一個有機的流暢的過程，可以減少隨機的人為因素產生的不利影響，從而強化團隊的合作程度。這才是過程模型在約束、規範軟體開發活動中的作用所在。不是用來炫耀，也不是用來評級的。

二．正確認識過程模型的定製

任何一個過程模型，都有它的適用環境和不足之處，這是在進行模型選擇時必須重點關注的部分。不同的企業、不同的專案，甚至不同的團隊都可能需要不同的過程模型，一味的追求新定義的模型而不考慮實際情況，人員不適應，部門不協作，大多數情況下必然會走向失敗的。即使選好了過程模型，也務必要經過剪裁和定製，遵循過程建設的過程，去掉不適用的部分，按現實情況進行調整，通過長期的磨合，利用積累的過程經驗和資料，從而在不斷的完善和優化過程中形成最合適的自己的過程。

三．過程模型的推進要符合企業的文化

同過程模型的定製是一樣的，在企業範圍內，過程模型一定要與企業文化融為一體。如果是一家強調按部就班的企業，很可能採用傳統的瀑布或計劃驅動的模型會很合適，而換用敏捷模型則會與企業的文化形成背離，是不適合企業整體環境的。好的過程一定是與企業文化完美結合、相輔相承的，否則，過程就失去了生存的土壤，無法在企業內紮根。

四．過程的改進是要從上到下的

過程的改進對企業來講是具有變革性質的，當然，任何變革都會付出代價，都會遇到阻力。因此，企業應深刻的認識到，過程的改進不是成立一個過程改進小組那麼簡單，需要從企業的戰略高度出發，從上到下，整體進行。如果只是高層領導口裡說改進而無法落實，那就是空話；如果只是某些員工或某個部門在推動過程改進而高層領導不予配合，那也是毫無結果的。因此，對過程的改進要慎重，要補充必要的知識，要有變革的決心和勇氣並能堅持到底，最重要的是要從上到下全方位進行。

五．過程的改進要輔以工具

過程是一個複雜而又不具備可見性的事物，對過程的建設、管理和改進，需要引入適當的過程管理工具，尤其是配置管理工具和專案管理工具，前者用於記錄各種配置項的過程變化，可以形成有效的過程資料，後者用於進行視覺化的專案管理，變抽象為具體。

總之，軟體工程過程的引入，無疑會規範軟體開發過程，從而提高軟體產品的質量，減少失敗的風險。隨著軟體工程過程這一領域的進一步發展，越來越多的過程模型在產生，無論是敏捷方式的，還是計劃驅動的，在未來可能會有更加驅於二者結合的模型出現。在過程模型的發展中，也注意到軟體工程方法、軟體工程管理等其他學科的發展，這些是軟體開發工作中不可缺少的部分，是有機的整體，只是分別從不同的角度進行描述而已，是不可割裂的。銀彈不會出現，但是過程與企業文化的融合，能使軟體開發向更規範的方向發展，這是過程模型的深遠意義。