如何學習軟件工程

3、軟件咨詢：新興的行業，不過要有實力和廣交朋友才行。

========================================================================================================

學了1個學期的軟件工程課，終究知道了個軟件工程的大概。學的時候總覺得很抽象，理解起來好像不難，但總是摸不著頭腦1種很茫然的感覺。學習的進程中和1個宿舍的同學1起做了個小型管理系統的開發，覺得還是有點收獲的，對開設這門課的意義也有所領悟，現在就將我對這門課的體會和在項目開發進程中遇到的1些問題簡單的歸納1下。希望在以后的學習中不斷的提高吧。

曾以為程序就是軟件，軟件就是程序。現在知道了2者的不同的地方，這是學習這門課程第1個收獲。事實上在軟件開發的初期階段這也不能說是毛病的。那個時候開發的軟件都比較簡單。固然可以把軟件理解成程序，直到軟件作坊的出現，使軟件在程序的基礎上加了個說明。之前做過的1些小型的軟件比如加密軟件，我也只是在程序旁邊附上1個軟件的說明，看來已很接近作坊了。不過大的項目沒有接觸過，用軟件工程的方法還是第1次。我想也是程序的不斷復雜化致使了軟件危機的產生，使得人們不能不探索新的解決方法。

這個時候軟件工程應運而生了。

我們為何需要軟件工程呢？上面已給出了1些緣由。專業點講，軟件工程終究是為了實現“軟件制造業”的社會化,工業化大生產,提高其勞動生產效力。只有如此,軟件業才能實現社會化,工業化大生產,才能“做大做強”。沒有管理的設計是失敗和混亂的設計，沒有設計指點的編程是無序的繁忙的。根據開發的軟件的范圍，應當適當程度的應用軟件工程化的思想，需要靈活，畢竟我們開發的軟件大多數是中小型的，大型的其實不多見（我是這么認為的）。但只要觸及人員間的交換和溝通，或多或少都要需要軟件工程才能更有效力，工作成果更穩定。

掌握軟件工程化的思想 ，對負責軟件開發的管理人員（領導）更加重要。曾看到過這么1句話，“坐在指揮臺上，如果甚么也看不見，就不能叫領導。坐在指揮臺上，只看見地平線上已出現的大量的普遍的東西，那是平平常常的，也不能算領導。只有當還沒有出現大量的明顯的東西的時候，當桅桿頂剛剛露出的時候，就可以看出這是要發展成為大量的普遍的東西，并能掌握住它，這才叫領導。” 軟件工程將有能力的人團結在1起，然后把他們變成工人，由于工業化的生產是效力最高的。這就是根本所在。沒有軟件工程管理，簡直就是亂來，就好象缺少宏觀控制的國家1樣，會亂78糟。

我們已知道軟件和程序是兩個不同的概念，軟件除程序還要有使用和保護該程序所需要的全部文檔。包括需求文檔、設計文檔、測試文檔、保護文檔和使用手冊。

軟件開發特別是大型軟件是1項浩大的工程,需要幾個人、10幾個人、幾10個人乃至幾百個人合作開發幾個月、10幾個月乃至幾年。要保證系統的調和性、統1性和連續性,就需要在開發之前制定嚴格、詳細的開發規范。開發規范的制定需要花費1定的時間和精力,但是"磨刀不誤砍柴功",它相當于把今后開發進程中開發人員都要遇到的問題提早做了1個斟酌。有了開發規范,在后續的開發進程中,設計人員就沒必要每次斟酌如作甚1個字段命名,編程人員也沒必要去想某個程序的結構和布局應當 怎樣,測試人員也有了判斷程序對錯的標準。開發規范在項目開發工作中起著事前約定的作用,需要所有開發人員共同遵照。它束縛開發人員的行動和設計、編程風格,使不同子系統和模塊的設計、編程人員達成默契,以便構成全部系統的和諧步調和統1風格,也便于今后的系統保護和擴大工作。

在實際中開發軟件首先應當斟酌的是是不是可行的問題。但在這個實習中其實根本沒必要，既然已選好了題目，而終究也不要求能夠運行，錢、軟硬件資源不成問題，固然可行。主要斟酌的技術問題。

下面就軟件開發的各個階段分別談點看法。

需求分析就是要肯定自己要做甚么，應當怎樣做，心里有個底。需求是通過與用戶充分交換和自己的創造力,去發明軟件規格說明的進程。如果沒有雙方對需求進行分析，可能出現項目設計出來的東西或終究提交的可交付物根本就不是客戶所需要的，或有相當的差距。所以用戶和開發人員在需求上要達成1致性。在這個實習項目中只是給了幾個要實現的功能。也沒有真實的用戶。憑大家的想象給出1個比較好的需求有點難。

設計進程就是將你肯定的需求想辦法用代碼去實現。這個進程是交給程序員做的。設計可能會用到很多方面的知識。軟件終究的目的是要用戶使用。因此在程序設計時必須立足于操作簡單、實用,并真正能為用戶解決實際的業務問題。不能由于怕編程麻煩而將程序功能設計得過于簡陋。這個進程可能會對已完成的需求分析做些改進乃至顛覆。為每一個模塊肯定采取的算法。然后就是根據算法寫代碼。之前覺得寫代碼是最麻煩得事情，現在才發現寫代碼原來只是軟件開發中最簡單的1個步驟。到目前為止學了C，C++，還有java，熟習的還是面向進程的C，面向對象的軟件開發回有待于實踐。在這個小項目的開發中由于沒有要求寫代碼，所以也沒有使用哪一種程序設計語言的問題。但我想既然面向對象的軟件開發有著比傳統的開發沒法比擬的優點加上現在java風行全球，連比爾蓋茨都說java是目前為止最優秀的計算機語言，學著用java開發感覺好點。看來以后要好好的學java了。

軟件交付之前必須要測試。測試是保證程序質量的1項重要工作。但測試只能證明程序有錯,而不能證明程序無錯。所以任何軟件系統都不能保證內部沒有毛病。為了確保軟件系統的安全與可靠性,1方面要加大測試力度,另外一方面要捉住測試重點。程序又是測試的重點。1個合格的測試員應當很熟習他人的思惟。但感覺程序員應當很反感測試員。軟件開發是1項建設性工作而軟件測試是1項破壞性工作。1個曾做過測試的如是說，“做測試，我感到最多是在和程序員在吵架”。我覺得測試的基本要求就是找生產品的缺點，用簡單明了的方式表達給開發人員，心平氣和才好辦事。不管怎樣，有了破壞才能使軟件的免疫能力強起來。測試占了開發1半以上的時間和資源。

我在實習小項目中做的是測試的工作。由于沒有源代碼，所以只能做靜態測試。測試進程感覺很不好。擺在我眼前的只有個軟件需求文檔和詳細設計文檔，而且需求分析1大半也是我寫的。現在才發現需求分析當時寫的有多么的低劣。很多的問題都沒有斟酌到。而且發現設計文檔中的軟件初始結構圖根本不是依照需求分析給出的數據流圖轉化過來的。詳細設計文檔呢，跟整體設計差不多，乃至連整體設計的1些要求都沒有，比如接口的描寫，從頭到尾沒有提到過。面對著那份詳細設計報告，我無從下手，甚么都沒有。每一個模塊的細節都沒有斟酌。還是1個最最基本的框架。可事到如今又能怎樣辦，總不能把原來的拋棄自己在測試之前重新做個詳細設計吧，只好硬著頭皮測了。測試完成后感覺沒1點收獲。還不如看看書上的白盒子測試的例子體會多1點。報告打印了1點成績感沒有。

軟件保護是軟件生存期中的最后1個階段。實習沒有這方面的要求。保護也不像其前面的幾個階段理論成熟。但保護不是1天兩天就可以解決的問題。自從軟件開始工作，保護就歷來沒有停止過。所以保護是1個耗人力物力最多的1個階段。具體保護的方法應當根據軟件的開發方法來具體肯定。保護是為了軟件能健康準確更好的運行，但在保護的同時也可能由于開發方法的缺點致使保護產生1大堆的副作用乃至可能使得情況變得更糟，會得不償失。所以保護馬虎不得1定要慎重對待。

總的來講，軟件工程還是門不成熟的學科，在很多方面有不盡人意的地方，它在軟件開發領域的作用還沒有充分的發揮出來。特別在我國，軟件產業發展滯后，只占國民經濟的很小1部份。聽說在美國，軟件產業在國民經濟中的比重僅次于汽車產業。我從1些國內的1些論壇上考到有些程序員總抱怨說公司開發軟件根本不重視軟件工程的技術。所以有些人說軟件工程沒有用途。但我想隨著軟件范圍的日趨壯大，軟件工程技術1定會愈來愈遭到開發人員的重視。固然軟件工程理論的成熟還有待于IT界廣大軟件開發人員的共同努力，需要從實踐中摸索規律總結經驗，但可以相信軟件開發工程化的思想絕對是先進的，科學的。相信以后軟件工程的技術和理論會為大型軟件的開發做出更大的貢獻。同時更希望我國的軟件開發者們為我國的軟件產業的發展做出杰出的貢獻。

軟件工程各個階段的任務

需求分析：

不是具體的解決問題。而是準確地肯定軟件系統必須做甚么，必須具有哪些功能等問題。

概要設計：

主要任務是肯定軟件的整體結構和數據結構，并定義模塊間的接口。也就是肯定該軟件系統有哪些模塊組成，每一個模塊的功能是甚么，這些模塊的調用關系是怎樣的。同時還要設計整體數據結構和數據庫結構，即軟件系統要貯存甚么數據，這些數據的結構及他們之間的關系等。

詳細設計：

主要任務就是給出整體結構中每一個模塊完全的算法描寫，把功能描寫轉變成精確的結構化的進程描寫。即該模塊的控制結構是怎樣的，先做甚么，后做甚么，有甚么樣的條件判定，有甚么重復處理等，用相應的表示工具把這些控制結構表示出來。

編碼：

就是把詳細設計說明書中每一個模塊的控制結構轉換成計算機可接受的程序代碼，即依照選定的語言，把設計的進程性描寫翻譯為源程序。

測試：

測試按不同的層次可分為單元測試、組裝測試、確認測試和系統測試幾個步驟。

單元測試是查找各模塊在功能和結構上存在的問題；

組裝測試時將各個模塊按1定順序組裝起來進行的測試，主要是查找哦啊各模塊之間接口上存在的問題；

確認測試時按說明書上的功能逐項進行的測試，決定開發的軟件是不是合格、能否交付用戶使用等。

下面是在水木軟工上的對話。有興趣的可以看看，全文觸及工程與科學之間的差異，軟件工程的工程本身的分析，項目經理的行動和強弱勢項目經理的1些問題。

btw：里面有著名的錢5哥的回復，呵呵。

☆─────────────────────────────────────☆

別笑我弱大家討論討論，呵呵

我老聽說“要以工程的方法來開發軟件..."等等類似忠告。可以我怎樣也不能領會工程的真
正意義。
我能想到的就是"more pratical"和理性。由于在我的理解中傳統的工程(就是類似于建小區
)的產物都是實證的都必須是可行的都必須是經得起考驗的。與之相對的就是夸夸其談的藝
術的創意的只需要設計不重實現的，這些方向要的是縱橫捭闔天馬行空。
兩項相較：1邊是海水1邊是火焰，1邊是理性與冷靜，1邊則是感性與豪情。1邊是控制
1邊是縱情。

而我們研發軟件，同建房子1樣，不但要設計，更要能實現。終究的工件必須是經過客戶用
戶檢驗的，這個檢驗也是有標準的，不存在公說公有理婆說婆有理的情況。

軟件工程的提法反應了當時軟件開發屢遭失控打擊的情勢下，永不停止學習的軟件人向傳統
行業鑒戒經驗的決心。自此以后，估算技術丈量技術地位急劇高升?

各位是怎樣理解這個軟件工程中的“工程”的？有無人講講來龍去脈，freestyle。^_^

但是軟件工程中有方法論進程論，這算不算傳統工程理論的1部份？


☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Thu Jan 14 21:10:42 2010)  提到:

不弱。能深入思考工程兩個字的含義是很有必要的。
不思考工程兩個字就來做軟件開發的人，容易形而上學，更容易僵化的處理新的概念和新的方法論，借用老毛同志的話就是，容易本本主義。呵呵
不過，你這個話題太大，bbs上做這樣的討論，需要大量的文字輸入，得不償失，呵呵。
辯論或討論的時候，思辯進程和響應回途經長，價值不大，這樣的問題應當斟酌別的討論情勢會比較好1些。

【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵 
: 我老聽說“要以工程的方法來開發軟件..."等等類似忠告。可以我怎樣也不能領會工程的真 
: 正意義。 
: ................... 
☆─────────────────────────────────────☆
   blueslc (Thomas) 于  (Thu Jan 14 23:04:41 2010)  提到:

Engineering is a cooperative game of invention and communication.
from <Agile software development - the cooperative game>
這本書有1章講工程和軟件工程，說的很好，我試側重復1下看看了。
進程中有創新的才是工程，沒有的話就是生產而已，在傳統領域，很多工程其實只是生產而已，沒有甚么難度。比如造房子，造第1座房子是工程，如果造一樣的第2座，那就是生產。造第1座的難度，肯定比第2座要大很多
軟件由于其獨特性，每個軟件都不1樣，所以軟件工程，要和你造第1房子作對照，而不是第2座。
【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵 
: 我老聽說“要以工程的方法來開發軟件..."等等類似忠告。可以我怎樣也不能領會工程的真 
: 正意義。 
: ................... 



☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Thu Jan 14 23:23:36 2010)  提到:

這個對照似乎應當是科學研究與工程對照，科學研究是造第1座房子，然后工程才是重復后面的房子進程，呵呵。
我個人認為，這本書里面講的這個工程的解釋應當是完全毛病的。它混淆了科研與工程之間的差異。

☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Thu Jan 14 23:27:44 2010)  提到:

評論1下這句話：但是軟件工程中有方法論進程論，這算不算傳統工程理論的1部份？
我記得我的blog上有1片關于軟件工程重新定義的文字上（我對軟件工程領域劃分的認識之1，地址：http://blog.csdn.net/qingrun/archive/2006/12/21/1451598.aspx ），和1個在河南某大學的老師產生了爭辯，通過評論和評論回復的方式爭辯了幾近1整天，其實說的就是1兩個小時就能夠說完的東西。
對這個話題和這個話題中各方面包括的內容做了比較深入的討論。

☆─────────────────────────────────────☆
   qlw (錢5哥) 于  (Thu Jan 14 23:43:55 2010)  提到:


工程和技能相對應。工程的基礎是可以丈量，曾復印過1張施工隊的進度和報價
上面將投入、工時、本錢算的清清楚楚。這和動輒可能延期的軟件開發有天壤之別

但是軟件工程也是很困難的，丈量到現在似乎也沒有甚么人提出來與時俱進的方法
工程化終究致使了文檔化和僵化。因此出現了敏捷進程 - 動身點是簡化傳統的工程
思路，從而回歸到產品化的正確道路上。但是在解決范圍擴大的問題方面還是有
些問題。早1些的CASE、組件化、軟件工廠等概念，雖然盛極而衰，但是留下了
包括pattern、UML在內的遺產，對工程化有不小的幫助。

工程化首先要求可以重用，如果至今1直用主機+Cobol+DB2，則我深信現在已
工程化好久了，惋惜目前是Linux+虛擬化+云計算的時期，本來弄的那套玩意早就
過時了，工程化還遭到技術成熟性的制約！

可以看看Gartner的Hyper Cycle，現在M2M已開始預熱了。看到這類玩意，不由
心說，“工程化又遠了”

供討論

☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Thu Jan 14 23:58:08 2010)  提到:


我再講些感想。

軟件工程是如此的復雜，風險是如此的高，弄到65%的軟件項目延期，30%的項目直接取消。
跟傳統工程的按時交付率差別如此之大。
緣由有2：
第1是軟字，軟的就像女人的奶子客戶都想捏成自己想要的形狀。很多客戶都不知道到達隨意捏的程度需要吃多少木瓜，這類客戶和軟件提供商的溝通有點巴別塔。
其 2在原軟件工程固有的復雜性。傳統工程正如我開始所說，設計和實現相分離，勞斯萊斯的design和implementation是完全個裂開的。而軟件 項目中design和implementtation是如此的不可分家，每個實現者都在自己的范圍內進行design。

和傳統工程比 較，軟件工程的軌跡必定是守破離。大亂時期，我們需要1個框架，是以學習傳統工程，但由于上面兩點，漸漸的，軟件工程變異出自己的特性，我認為這里可以分 為3個層次：進程論/方法論/最好實踐和反模式，這些都是那些重視丈量估算的傳統工程所沒有的。漸漸的終究發展出自己的1套理論，和傳統軟件工程完全不同 的理論。在這里，丈量不是最重要的，最重要的是革新，是重構，是抽象，是溝通是融會而不是分而治之不是人為構筑壁壘。


☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Fri Jan 15 00:21:24 2010)  提到:

那肯定啊，但是主要指點思想還是IOC和分而治之。
說起這個就想起而2戰的通用，短時間內就是用IOC理念造就了如此多的飛機。。。。

【 在 canper (洗衣粉) 的大作中提到: 】
:  車盲，不了解，不過我想造車設計師也不是畫完圖紙就完事的吧，也要參與樣品車的組裝，調試。 

☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:26:47 2010)  提到:


 我覺得軟件中設計和編碼分開也是完全可以的，但其實不表示這樣就能夠下降編碼人員的水平，和設計者可以不參與到編碼階段中。

  我想配合設計師1起組織樣品車的技術的工資也不是和普通工人1個檔次的。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 那肯定啊，但是主要指點思想還是IOC和分而治之。 
: 說起這個就想起而2戰的通用，短時間內就是用IOC理念造就了如此多的飛機。。。。 


☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Fri Jan 15 00:31:14 2010)  提到:

我覺得軟件行業革新的動力就是融會相互學習沒法剝奪的學習，而傳統行業是分而治之，缺少對流缺少溝通。軟件行業如果沒融會沒溝通，基本上就夕陽了。
我們之所以如此酷愛這個行業，就在于我們喜歡溝通交換喜歡延續改進而不是得過且過。

【 在 canper (洗衣粉) 的大作中提到: 】
:  我覺得軟件中設計和編碼分開也是完全可以的，但其實不表示這樣就能夠下降編碼人員的水平，和設計者可以不參與到編碼階段中。 
:   我想配合設計師1起組織樣品車的技術的工資也不是和普通工人1個檔次的。 

☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:32:05 2010)  提到:

 不過一樣的事情如果放到建筑業就不是那末回事了，設計師畫完圖紙就完了，沒有必要建1棟房子來驗證自己的設計。

  如果是服裝業呢，好像也要做出樣品來看看效果。


【 在 canper (洗衣粉) 的大作中提到: 】
:  我覺得軟件中設計和編碼分開也是完全可以的，但其實不表示這樣就能夠下降編碼人員的水平，和設計者可以不參與到編碼階段中。 
:   我想配合設計師1起組織樣品車的技術的工資也不是和普通工人1個檔次的。 




☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:33:10 2010)  提到:


 這個，我還真說不上酷愛
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 我覺得軟件行業革新的動力就是融會相互學習沒法剝奪的學習，而傳統行業是分而治之，缺少對流缺少溝通。軟件行業如果沒融會沒溝通，基本上就夕陽了。 
: 我們之所以如此酷愛這個行業，就在于我們喜歡溝通交換喜歡延續改進而不是得過且過。 




☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:35:22 2010)  提到:


 在斟酌1個問題，1個好的汽車工程師不需要具有技師的技能。
 1個好的服裝設計師不1定是個好裁縫。


 但是1個好的軟件設計師不是1個好的編程人員就不靠譜了

【 在 canper (洗衣粉) 的大作中提到: 】
:  不過一樣的事情如果放到建筑業就不是那末回事了，設計師畫完圖紙就完了，沒有必要建1棟房子來驗證自己的設計。 
:   如果是服裝業呢，好像也要做出樣品來看看效果。 




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Fri Jan 15 00:36:00 2010)  提到:

這就是軟件業的design和implementation不可分離的特點啊。

【 在 canper (洗衣粉) 的大作中提到: 】
:  在斟酌1個問題，1個好的汽車工程師不需要具有技師的技能。 
:  1個好的服裝設計師不1定是個好裁縫。 
:  但是1個好的軟件設計師不是1個好的編程人員就不靠譜了 
: ................... 



☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:38:02 2010)  提到:


 但是1個好的軟件工程師不需要是1個好美工，哈哈
【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 這就是軟件業的design和implementation不可分離的特點啊。 




☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Fri Jan 15 00:39:49 2010)  提到:

這里的design不是指UI design,而是指 architecture啊。
【 在 canper (洗衣粉) 的大作中提到: 】
:  但是1個好的軟件工程師不需要是1個好美工，哈哈 




☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Fri Jan 15 14:25:48 2010)  提到:

這 樣的實驗我做過，02年8月，南京地稅金力4期項目上，我從上海帶了5個人過去參加tp當年的團隊，后面給了我兩個星期做1個模塊實用性原型，成都那邊給 了我1個美工，我這邊自己做模型開發，設計完成后，分給了1個做頁面，1個做數據庫，我做業務控制層，1個人做銀行接口的扣款，1共8天不到全部弄定，1 次性通過測試。
做界面和數據庫開發的人完全是在我給定的模型導出的代碼上進行的，我們做了1次設計變更，構成了1個獨立的直接對象數據的寫入類。
所以，我1直定義的編碼人員就是印度的那種編碼層次就足夠了。
不是說設計人員完全脫離編碼，而是對1些創造性和創新性或說有1定難度的編碼是需要設計人員寫好的，類似于過去傳統軟件工程中提出的微代碼的開發階段所完成的內容。
這樣，就能夠完全地實現代碼設計的分離。實現我們的對印外包。

【 在 canper (洗衣粉) 的大作中提到: 】
:  我覺得軟件中設計和編碼分開也是完全可以的，但其實不表示這樣就能夠下降編碼人員的水平，和設計者可以不參與到編碼階段中。 
:   我想配合設計師1起組織樣品車的技術的工資也不是和普通工人1個檔次的。 



☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Fri Jan 15 14:28:53 2010)  提到:

1個好的汽車工程師也需要好的技師的配合，在做1些設計的時候，需要他們才實現設計，然落后行驗證，取得驗證結果后，對設計進行調劑和優化――我的本專業材料學就是干這個的，現在大多數同學都在汽車行業，嘿嘿。

【 在 canper (洗衣粉) 的大作中提到: 】
:  在斟酌1個問題，1個好的汽車工程師不需要具有技師的技能。 
:  1個好的服裝設計師不1定是個好裁縫。 
:  但是1個好的軟件設計師不是1個好的編程人員就不靠譜了 



☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Fri Jan 15 18:10:17 2010)  提到:

不管我們做甚么軟件，這個軟件大部份都是此前已有人做過的，或有過類似的，或最少是在原理上已被證明過的，如果非要強調，應當說，科學是對原理的驗證，而工程是對原理的實現。
難度有可能實現比推理進程更難，所以，在科學領域的很多學科上都有大量至今還沒法驗證的假定，這是客觀存在的，假定常常需要很多條件滿足后才可能被驗證，所以，那本書上說的工程的所謂概念是完全毛病的！！！

【 在 blueslc (Thomas) 的大作中提到: 】
: 但對軟件開發，對開發者來講，我們常常都是在造第1座房子，有時候還是在原來房子的基礎上加層，更加困難



☆─────────────────────────────────────☆
   ilovecpp (cpp) 于  (Fri Jan 15 23:48:23 2010)  提到:

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 我再講些感想。 
: 軟件工程是如此的復雜，風險是如此的高，弄到65%的軟件項目延期，30%的項目 
: 直接取消。 
: 跟傳統工程的按時交付率差別如此之大。 

傳統工程真有這么牛？

787的延期，Larabee的延期，業界巨頭數10億美元輕易打水漂。

1部美國軍機發展史，就看見3個詞：延期，超越預算，項目取消。

軟件工程喜歡拿蓋房子作比。蓋房子真是這個時期最接近軟件工程的傳統工程？

我父母是電子工程師。我的直觀印象是，電子產品的開發決不像蓋房子，倒是和
軟件開發的進程頗多相似的地方。

和傳統工程比，我們做得真的更差嗎？

諸多疑問，難以厘清。



☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Sat Jan 16 11:23:17 2010)  提到:

對 于國內來講，我們和國外的差距主要在管理意識上，而不是技術層面；由于管理意識的差異，引發的投資方對軟件系統的渴望和要求有了非常大的變化，國內的傳媒 方面對國外軟件項目的報導，也包括國外對自己的軟件工程實行的報導也都大多集中于成功的例子，加上隨著大家對科技進步的奢望，總認為軟件應當能做到甚么什 么模樣，應當能解決甚么甚么問題，卻忽視了軟件本身最需要解決的根本問題：數據積累。
國外的軟件行業走過了超過我們3倍以上的時間，他們積累的數據基礎遠遠不是我們目前能夠比擬的。
對 美國來講，由于幾次世界大戰都沒有到他的本土，他的企業和經濟的延續性在全球范圍內都可以算是最好的，其數據的保持也是最好的，而我國，大部份企業都是 80年以后重建的，更多的數據在2戰，文革中全面毀滅，沒有剩下甚么，我們所能研究到的數據積累能超過10年的都不多，而且大部份是未信息化處理的原始數 據，但是同時，國內的宣揚為了取得眼球的注意力，更多的關注在國外已成功地項目和目前的技術積累和產品狀態下，所以，附帶而來，傳統行業在信息化的時候對 我們的期望就處于1個相對太高的水平線上，因而就帶來了意識與技術現實的直接沖突，加上可投入研發資金和積累的時間問題，因而這個矛盾就更加劇烈了。
所以，不是我們做得不夠努力，而是環境太過于刻薄了。
雖然說解決這些問題不是不可能但是，需要多方面的配合和引導，涉足點太多，就超越了這個話題了。呵呵


☆─────────────────────────────────────☆
   blueslc (Thomas) 于  (Sat Jan 16 11:40:07 2010)  提到:

那軟件的開發算是科學？還是算是社會學？很多事情都沒有這么絕對的。
【 在 qingrun (青潤) 的大作中提到: 】
: 不管我們做甚么軟件，這個軟件大部份都是此前已有人做過的，或有過類似的，或最少是在原理上已被證明過的，如果非要強調，應當說，科學是對原理的驗證，而工程是對原理的實現。 
: 難度有可能實現比推理進程更難，所以，在科學領域的很多學科上都有大量至今還沒法驗證的假定，這是客觀存在的，假定常常需要很多條件滿足后才可能被驗證，所以，那本書上說的工程的所謂概念是完全毛病的！！！ 





☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Sat Jan 16 11:56:03 2010)  提到:

軟件開發是工程學的內容，絕對不是科學領域直接關聯的內容，固然，1切都是在科學理論的指點或指引下完成的，這個事情，可以說是絕對的。
科學的概念和范疇是可以明確地東西。這個問題也是可以明確地，呵呵。

【 在 blueslc (Thomas) 的大作中提到: 】
: 那軟件的開發算是科學？還是算是社會學？很多事情都沒有這么絕對的。 


☆─────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Sat Jan 16 12:20:57 2010)  提到:

說起這個來，確切在管理意識上有些不匹配，舉個很弱的例子
我之前有個非it的老大，買了個2w的asp源代碼，后來幾個項目非要我用這個asp源代碼，1個項目下來用“不要改”阻擊了我最少快20次提議。
他很難理解有現成的東西為啥不用，恍如另起爐灶或升級給就算是把他那小2w給浪費了會給他造成很多本錢費用似的。雖然我解釋過很屢次。
弄軟件有時候對本錢對質量的貢獻，管理人員在管理層面上進程成層面上的運作不見得比技術人員關鍵。
此時，我想起1本書（應當是《軟件工程的事實與錯誤》）前言中提到作者說過的1句話，大意是說他喜歡弄技術，很享受這類技術人的意見壓倒管理者命令的狀態。當時我覺得很可笑，我心想在中國你有立錐之地嗎？


☆────────────────────────────────────☆
   timshaw (寫啥呢？真矛盾) 于  (Sat Jan 16 12:22:05 2010)  提到:

昨晚上看到1本用友人寫的書，說很多技術顧問不愿意隨著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。..
【 在 canper (洗衣粉) 的大作中提到: 】
:  我就1個寫代碼兼做工程的，整天和客戶打交道 




☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Sat Jan 16 12:25:42 2010)  提到:

我去年年初就拍死了1個合作公司的市場，對技術人員太不尊重了，后來他們還過來找了我1次，希望我繼續提供咨詢和培訓，我沒理他，就沒有再找我了。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到1本用友人寫的書，說很多技術顧問不愿意隨著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。.. 



☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Sat Jan 16 12:26:50 2010)  提到:

所以，在中國，有技術基礎，又能謙虛做事的項目管理人員才可能把項目做的很好，單純的強勢或弱勢項目經理都是不好當的。呵呵。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 說起這個來，確切在管理意識上有些不匹配，舉個很弱的例子 
: 我之前有個非it的老大，買了個2w的asp源代碼，后來幾個項目非要我用這個asp源代碼，1個項目下來用“不要改”阻擊了我最少快20次提議。 
: 他很難理解有現成的東西為啥不用，恍如另起爐灶或升級給就算是把他那小2w給浪費了會給他造成很多本錢費用似的。雖然我解釋過很屢次。 
: ................... 



☆─────────────────────────────────────☆
   keygen (貧賤夫妻百事哀) 于  (Sat Jan 16 12:29:09 2010)  提到:

技術牛的項目管理人員強勢點，大家倒是很愿意接受的。哈哈
【 在 qingrun (青潤) 的大作中提到: 】
: 所以，在中國，有技術基礎，又能謙虛做事的項目管理人員才可能把項目做的很好，單純的強勢或弱勢項目經理都是不好當的。呵呵。 




☆─────────────────────────────────────☆
   qingrun (青潤) 于  (Sat Jan 16 12:34:02 2010)  提到:

那樣會有1個問題出現，而且這個問題根本沒法解決，那就是：
如果團隊內有1個差不多1樣牛的技術人員存在的話。

我曾在自動化所跟隨過1個技術很牛的研究員，離開后，寫了1系列好像是5篇相干文字在我的blog上，就是談如何和1個純技術的老板合作的話題。
和他的合作就存在1個很嚴重的問題，那就是：他情商太低，低到了公認的負值――有人說這還不夠。
1個例子08年底到09年中期，他產生了兩次學生集體叛逃的事件，第1次18個學生9個集體提出換導師，其中有兩個博士，是我在的時候的弟兄，人很老實，都已博士第3或第4年了，你想一想，能把人家壓迫成甚么模樣才能逼人家做出這樣的選擇。呵呵。
技術上大家都服氣，都認為他很牛，我出來后，提到他也都說，他技術上的確很牛，別的，大都1帶而過，偶爾用類似上面的事件作證明來講明1些，呵呵。
【 在 keygen (貧賤夫妻百事哀) 的大作中提到: 】
: 技術牛的項目管理人員強勢點，大家倒是很愿意接受的。哈哈 






☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Sat Jan 16 13:41:40 2010)  提到:


 沒有，每次出來他們都用力的和我說這是很健康的事情，不要想歪了等等。


 天地良知，我歷來都認為這是很健康很健康的事情，但是健康的事情多了去了，又不見得1定要做。話說每星期打羽毛球我都沒去，怎樣就沒人來和我解釋：打羽毛球是很健康的事情。

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 所以你在洗腳房里睡覺，他們估計在嘀咕:難道是要把妞送到他房里去? @_@ 
: 開個玩笑。 




☆─────────────────────────────────────☆
   SPQR (蒼狼) 于  (Sat Jan 16 17:52:51 2010)  提到:

這是由于不會說話啊...
做銷售的, 何至于這么不會溝通

【 在 timshaw (寫啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到1本用友人寫的書，說很多技術顧問不愿意隨著銷售出去吃喝玩樂，而銷售經理又不好意思不叫，怕得罪啊。.. 




☆─────────────────────────────────────☆
   SPQR (蒼狼) 于  (Sat Jan 16 17:54:29 2010)  提到:

打羽毛球是很健康的事情

【 在 canper (洗衣粉) 的大作中提到: 】
:  沒有，每次出來他們都用力的和我說這是很健康的事情，不要想歪了等等。 
:  天地良知，我歷來都認為這是很健康很健康的事情，但是健康的事情多了去了，又不見得1定要做。話說每星期打羽毛球我都沒去，怎樣就沒人來和我解釋：打羽毛球是很健康的事情。 






☆─────────────────────────────────────☆
   finely (finely) 于  (Sat Jan 16 20:55:03 2010)  提到:

你們都喜歡發長文 啊

我說個簡短的，主要就是“工程”和“研究”之區分

工程就是干活，理論和工具都是現成的，用就是了

研究是高難度的創新，是制造理論和新工具的

軟件從本質上講，是個工程，但是1個復雜度極高的工程，以致于很難控制，所以需要1些理論和方法來控制這個工程。

【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵 
: 我老聽說“要以工程的方法來開發軟件..."等等類似忠告。可以我怎樣也不能領會工程的真 
: 正意義。 
: ................... 



☆─────────────────────────────────────☆
   SPQR (蒼狼) 于  (Sat Jan 16 22:43:39 2010)  提到:

成心思

所以工程大致是(關鍵字)
1) 利用/制造 (輸出是可以直接使用的實物)
2) 系統化的/方法論的

不是;
1) 研究 (輸出是研究報告)

但是其實工程這個概念是不需要

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈