軟體工程的本質是管理複雜性

2021-09-07 20:28:12 字數 1236 閱讀 6391

為什麼軟體工程的本質是管理複雜性

軟體工程是軟體的形成過程,除了概念本身,涉及到了工具和人。主要是how,如何形成軟體,如果使用技術,人又如何。軟體工程的本質是複雜性

對軟體工程而言,不可避免的東西是(需求)變化;而軟體是的本質是概念和概念之間的關係,這個本質類似什麼,類似於中子會影響原子裂變。

所以,這導致了軟體的複雜性**。

這也是為什麼《人月神話》作者在論述到這個本質和變化的時候說:「如果這是事實,那麼終究沒有銀彈」。

這裡且不去論證他這個論斷是否正確,但是的確反應了人月神話描述的軟體工程面臨的諸多難題

1,軟體很容易陷入泥沼

2,陷入泥沼很難糾正調控

……複雜性有三類

1,問題域本身的複雜性

2,採用的技術方案引入的額外複雜性

3,涉及到的人和組織再引入的額外複雜性

理解了這三個複雜性,就理解了為什麼軟體容易陷入泥沼,因為不能控制變化發生,就不能控制複雜性**;

需求變化是變化,會引發複雜性**

不能盡然計畫可以視為一種計畫外的變化

技術變化也是變化

組織變化也是變化

這些都會極大引發複雜度變化

軟體工程 必須要解決這三個複雜性

成功的有效率的軟體工程,需要引入技術熵和組織熵的概念

熵是能量中不能做功的能量

技術熵和組織熵是技術和組織在解決問題中,額外多花費的能量。

很明顯,這兩者越少越好。

所以,軟體工程必須管理複雜性

1,技術熵越少越好

2,組織熵越少越好

3,良好的領域抽象,是真正的關鍵

4,如何去控制變化,隔離變化,適應變化

傳統的軟體工程理論是無法解決這個問題的,我們先來看一下傳統的軟體工程理論是個什麼東西

1,將軟體按照時間階段分為幾個步驟(需求,設計,開發,測試,維護),這個劃分是確保了完備性的

2,將每個步驟分配給乙個或者幾個角色,確保了這個劃分是可執行,可管理,可組織的

3,微觀上控制每乙個步驟和節點的時間,風險,降低整體複雜性;提公升可管理性

4,引入uml和工作協作方法(敏捷,瀑布……)來實現各個步驟之間的銜接和角色之間的銜接,確保整個理論是內洽的

這個理論,是乙個管理性的理論,但沒有解決任何軟體工程的本質問題,只是確保了可管理性。

嚴格按照這個理論做的話,大概率可以提公升軟體的成功率的,但是效率和靈活性就難以保證了——這也是微軟這種傳統型別的軟體公司和fg這種型別的軟體公司的差異

至於正確的方式,回頭慢慢聊

軟體工程的本質是管理複雜性

為什麼軟體工程的本質是管理複雜性 軟體工程是軟體的形成過程,除了概念本身,涉及到了工具和人。主要是how,如何形成軟體,如果使用技術,人又如何。軟體工程的本質是複雜性 對軟體工程而言,不可避免的東西是 需求 變化 而軟體是的本質是概念和概念之間的關係,這個本質類似什麼,類似於中子會影響原子裂變。所以...

軟體工程的本質

軟體工程的本質 問題域到不同抽象層之間概念和計算邏輯的對映.從問題域到開發平台直接進行對映,勢必存在一定的複雜性。為了控制這一複雜性,需要確定多個抽象層,例如需求 設計 實現 和部署等,每乙個抽象層均由自己特定的術語定義,形成該抽象層的乙個術語空間。如果按照自頂向下的途徑進行軟體開發的話,首先就是通...

造成軟體複雜性的原因

1 問題域的複雜性,造成這種複雜性的主要原因,還是使用者與開發者之間的 溝通問題 使用者常常對某個需求只存在 乙個模糊的概念,對具體要實現成乙個什麼樣子沒有特別明顯的想法。並且由於使用者與開發者思維的不一致,使用者很 難將他的意思很清晰的傳達給開發者。通常這種情況下,我們開發者也只能借助些工具,例如...