在現實生活中的軟件工程,對於未學過或者初學者來講是一個謎,對於這方面的大神來講軟件工程什麼都不是,分分鐘搞定。編程
對於一個大公司而言,要在那麼激烈的市場競爭中脫穎而出,公司管理者怎麼可能沒點腦子,他們很瞭解市場和本身須要的是什麼。IBM購併Rational的真實緣由在於IBM 須要構建一個完整的軟件工程體系,對於 IBM 來講,Rational 有着 UML 語言的很是豐富的實踐經驗,還有着 RUP 做爲理論框架,,這 些對 IBM 在確立大型軟件工程應用方案提供商的行業形象,都是極大的支持。 數據結構
因爲商業因素,大公司們的爭奪戰已經開始把軟件工程,從原始的「自生演進」狀態,逐漸推動到「它激發展」的狀態上了。它激發展的狀態使開發者軟件工程漸漸地遠離最初的狀態成爲更具備商業化。框架
工程在完成過程當中,項目經理須要考慮一個很重要的問題:項目成本。在一個公司裏,不計成本的項目計劃不會獲得老闆的支持,毫無目的地消耗成本是項目中的慢性毒藥。不能像愚公同樣「子又生孫,孫又生子,子子孫孫,何苦不平乎?」,完成移山這項工程已通過了幾百年了,社會歷史早變革到哪裏去了,這樣的作法所付出的代價也太大了。工具
對於AOP,我瞭解的很少,AOP不是語言,姑且能夠說AOP是方法論,就象 OOP 是 「面向對象的編程方法」是方法論同樣,OOP所基於的數據結構是對象(Object), 而AOP所基於的數據結構就是方面(Aspect)。spa
工具、方法與過程被稱爲軟件工程的三個要素。它們是相互做用、相互制約的。 例如「過程」問題,就既有實施過程的工具,也有相關的過程方法理論。對象
在完成工程過程當中,,項目經理是一箇中間的角色,有了一種使命:協調經營者與開發者之間的溝通。通常來講,沒幾個經營者懂軟件技術。也許在 EHM 模型中,他所處於的位置在最右端,而開發者在最左端,在兩者之間沒有相同的關注界面。開發者所面臨的矛盾:實現目標與保障質量。在實現工程目標過程當中,與此相反的是咱們會在項目交付和試用時纔會碰到客戶在質量上的投訴。客戶會把全部的責任歸咎到開發人員,而開發人員又不停地埋怨需求的不清不楚或者變動的沒完沒了,這是工程的質量問題。開發
與此同時,無論是項目經理仍是開發人員,都須要注意的問題就是「枝節與細節」,不少人都喜歡把不要在意這種細節,細節決定成敗,最好懂得一個道理:無論它是細節仍是枝節,只要你感到你的腳趾已經沾上了泥淖,就快點回頭。io
開發一個逆天的的軟件是多麼不容易!無論怎麼玩,系統都能運行,永不崩潰!!!那樣的軟件屌爆了有木有,若是那個程序是你或者你帶領的團隊開發的,你說你一點都不自豪我「葉良辰」表示不信。軟件