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

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

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

曾經以為程式就是軟體，軟體就是程式。現在知道了二者的不同之處，這是學習這門課程第一個收穫。事實上在軟體開發的早期階段這也不能說是錯誤的。那個時候開發的軟體都比較簡單。當然可以把軟體理解成程式，直到軟體作坊的出現，使軟體在程式的基礎上加了個說明。以前做過的一些小型的軟體比如加密軟體，我也只是在程式旁邊附上一個軟體的說明，看來已經很接近作坊了。不過大的專案沒有接觸過，用軟體工程的方法還是第一次。我想也是程式的不斷複雜化導致了軟體危機的發生，使得人們不得不探索新的解決方法。

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

我們為什麼需要軟體工程呢？上面已經給出了一些原因。專業點講，軟體工程最終是為了實現“軟體製造業”的社會化,工業化大生產,提高其勞動生產效率。只有如此,軟體業才能實現社會化,工業化大生產,才能“做大做強”。沒有管理的設計是失敗和混亂的設計，沒有設計指導的程式設計是無序的忙碌的。根據開發的軟體的規模，應該適當程度的運用軟體工程化的思想，需要靈活，畢竟我們開發的軟體大多數是中小型的，大型的並不多見（我是這麼認為的）。但只要涉及人員間的交流和溝通，或多或少都要需要軟體工程才能更有效率，工作成果更穩定。

掌握軟體工程化的思想 ，對於負責軟體開發的管理人員（領導）更為重要。曾經看到過這麼一句話，“坐在指揮台上，如果什麼也看不見，就不能叫領導。坐在指揮台上，只看見地平線上已經出現的大量的普遍的東西，那是平平常常的，也不能算領導。只有當還沒有出現大量的明顯的東西的時候，當桅杆頂剛剛露出的時候，就能看出這是要發展成為大量的普遍的東西，並能掌握住它，這才叫領導。” 軟體工程將有能力的人團結在一起，然後把他們變成工人，因為工業化的生產是效率最高的。這就是根本所在。沒有軟體工程管理，簡直就是亂來，就好象缺乏巨集觀控制的國家一樣，會亂七八糟。

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

軟體開發特別是大型軟體是一項浩大的工程,需要幾個人、十幾個人、幾十個人甚至幾百個人合作開發幾個月、十幾個月甚至幾年。要保證系統的協調性、統一性和連續性,就需要在開發之前制定嚴格、詳細的開發規範。開發規範的制定需要花費一定的時間和精力,但是"磨刀不誤砍柴功",它相當於把今後開發過程中開發人員都要遇到的問題提前做了一個考慮。有了開發規範,在後續的開發過程中,設計人員就不必每次考慮如何為一個欄位命名,程式設計人員也不必去想某個程式的結構和佈局應當 怎樣,測試人員也有了判斷程式對錯的標準。開發規範在專案開發工作中起著事前約定的作用,需要所有開發人員共同遵守。它約束開發人員的行為和設計、程式設計風格,使不同子系統和模組的設計、程式設計人員達成默契,以便形成整個系統的和諧步調和統一風格,也便於今後的系統維護和擴充套件工作。

在實際中開發軟體首先應該考慮的是是否可行的問題。但在這個實習中其實根本沒必要，既然已經選好了題目，而最終也不要求能夠執行，錢、軟硬體資源不成問題，當然可行。主要考慮的技術問題。

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

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

設計過程就是將你確定的需求想辦法用程式碼去實現。這個過程是交給程式設計師做的。設計可能會用到很多方面的知識。軟體最終的目的是要使用者使用。因此在程式設計時必須立足於操作簡單、實用,並真正能為使用者解決實際的業務問題。不能因為怕程式設計麻煩而將程式功能設計得過於簡陋。這個過程可能會對已經完成的需求分析做些改進甚至推翻。為每個模組確定採用的演算法。然後就是根據演算法寫程式碼。以前覺得寫程式碼是最麻煩得事情，現在才發現寫程式碼原來只是軟體開發中最簡單的一個步驟。到目前為止學了C，C++，還有java，熟悉的還是面向過程的C，面向物件的軟體開發還有待於實踐。在這個小專案的開發中因為沒有要求寫程式碼，所以也沒有使用哪種程式設計語言的問題。但我想既然面向物件的軟體開發有著比傳統的開發無法比擬的優點加上現在java風靡全球，連比爾蓋茨都說java是目前為止最優秀的計算機語言，學著用java開發感覺好點。看來以後要好好的學java了。

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

我在實習小專案中做的是測試的工作。由於沒有原始碼，所以只能做靜態測試。測試過程感覺很不好。擺在我面前的只有個軟體需求文件和詳細設計文件，而且需求分析一大半也是我寫的。現在才發現需求分析當時寫的有多麼的差勁。很多的問題都沒有考慮到。而且發現設計文件中的軟體初始結構圖根本不是按照需求分析給出的資料流圖轉化過來的。詳細設計文件呢，跟總體設計差不多，甚至連總體設計的一些要求都沒有，比如介面的描述，從頭到尾沒有提到過。面對著那份詳細設計報告，我無從下手，什麼都沒有。每個模組的細節都沒有考慮。還是一個最最基本的框架。可事到如今又能怎麼辦，總不能把原來的拋棄自己在測試之前重新做個詳細設計吧，只好硬著頭皮測了。測試完成後感覺沒一點收穫。還不如看看書上的白盒子測試的例子體會多一點。報告列印了一點成就感沒有。

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

總的來說，軟體工程還是門不成熟的學科，在很多方面有不盡人意的地方，它在軟體開發領域的作用還沒有充分的發揮出來。尤其在我國，軟體產業發展滯後，只佔國民經濟的很小一部分。聽說在美國，軟體產業在國民經濟中的比重僅次於汽車產業。我從一些國內的一些論壇上考到有些程式設計師總抱怨說公司開發軟體根本不重視軟體工程的技術。所以有些人說軟體工程沒有用處。但我想隨著軟體規模的日益壯大，軟體工程技術一定會越來越受到開發人員的重視。當然軟體工程理論的成熟還有待於IT界廣大軟體開發人員的共同努力，需要從實踐中摸索規律總結經驗，但可以相信軟體開發工程化的思想絕對是先進的，科學的。相信以後軟體工程的技術和理論會為大型軟體的開發做出更大的貢獻。同時更希望我國的軟體開發者們為我國的軟體產業的發展做出傑出的貢獻。

需求分析：

不是具體的解決問題。而是準確地確定軟體系統必須做什麼，必須具備哪些功能等問題。

概要設計：

主要任務是確定軟體的總體結構和資料結構，並定義模組間的介面。也就是確定該軟體系統有哪些模組組成，每個模組的功能是什麼，這些模組的呼叫關係是怎樣的。同時還要設計總體資料結構和資料庫結構，即軟體系統要儲存什麼資料，這些資料的結構及他們之間的關係等。

詳細設計：

主要任務就是給出總體結構中每個模組完整的演算法描述，把功能描述轉變為精確的結構化的過程描述。即該模組的控制結構是怎樣的，先做什麼，後做什麼，有什麼樣的條件判定，有什麼重複處理等，用相應的表示工具把這些控制結構表示出來。

編碼：

就是把詳細設計說明書中每個模組的控制結構轉換成計算機可接受的程式程式碼，即按照選定的語言，把設計的過程性描述翻譯為源程式。

測試：

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

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

組裝測試時將各個模組按一定順序組裝起來進行的測試，主要是查詢哦啊各模組之間介面上存在的問題；

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

下面是在水木軟工上的對話。有興趣的可以看看，全文涉及工程與科學之間的差異，軟體工程的工程本身的分析，專案經理的行為和強弱勢專案經理的一些問題。

btw：裡面有著名的錢五哥的回覆，呵呵。

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

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

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

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

軟體工程的提法反映了當時軟體開發屢遭失控打擊的形勢下，永不停止學習的軟體人向傳統
行業借鑑經驗的決心。自此之後，估算技術測量技術地位急劇高升?

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

但是軟體工程中有方法論過程論，這算不算傳統工程理論的一部分？


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

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

【 在 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>
這本書有一章講工程和軟體工程，說的很好，我試著重複一下看看了。
過程中有創新的才是工程，沒有的話就是生產而已，在傳統領域，很多工程其實只是生產而已，沒有什麼難度。比如造房子，造第一座房子是工程，如果造同樣的第二座，那就是生產。造第一座的難度，肯定比第二座要大很多
軟體由於其獨特性，每一個軟體都不一樣，所以軟體工程，要和你造第一房子作對比，而不是第二座。
【 在 ihomd (ihomd) 的大作中提到: 】
: 別笑我弱大家討論討論，呵呵
: 我老聽說“要以工程的方法來開發軟體..."等等類似忠告。可以我怎麼也不能領會工程的真
: 正意義。
: ...................



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

這個對比似乎應該是科學研究與工程對比，科學研究是造第一座房子，然後工程才是重複後面的房子過程，呵呵。
我個人認為，這本書裡面講的這個工程的解釋應該是完全錯誤的。它混淆了科研與工程之間的差異。

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

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

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


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

但是軟體工程也是很困難的，測量到現在似乎也沒有什麼人提出來與時俱進的方法
工程化最終導致了文件化和僵化。因此出現了敏捷過程 - 出發點是簡化傳統的工程
思路，從而回歸到產品化的正確道路上。但是在解決規模擴大的問題方面還是有
些問題。早一些的CASE、元件化、軟體工廠等概念，雖然盛極而衰，但是留下了
包括pattern、UML在內的遺產，對工程化有不小的幫助。

工程化首先要求可以重用，如果至今一直用主機+Cobol+DB2，則我堅信現在已經
工程化好久了，可惜目前是Linux+虛擬化+雲端計算的時代，原先搞的那套玩意早就
過時了，工程化還受到技術成熟性的制約！

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

供討論

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


我再講些感想。

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

和傳統工程比 較，軟體工程的軌跡必然是守破離。大亂時代，我們需要一個框架，是以學習傳統工程，但由於上面兩點，慢慢的，軟體工程變異出自己的特性，我認為這裡可以分 為三個層次：過程論/方法論/最佳實踐和反模式，這些都是那些重視測量估算的傳統工程所沒有的。慢慢的最終發展出自己的一套理論，和傳統軟體工程完全不同 的理論。在這裡，測量不是最重要的，最重要的是革新，是重構，是抽象，是溝通是融合而不是分而治之不是人為構築壁壘。


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

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

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

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


 我覺得軟體中設計和編碼分開也是完全可以的，但並不表示這樣就可以降低編碼人員的水平，以及設計者可以不參與到編碼階段中。

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

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


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

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

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

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

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

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


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




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


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




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


 在考慮一個問題，一個好的汽車工程師不需要擁有技師的技能。
 一個好的服裝設計師不一定是個好裁縫。


 但是一個好的軟體設計師不是一個好的程式設計人員就不靠譜了

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




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

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

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



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


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




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

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




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

這 樣的實驗我做過，02年8月，南京地稅金力四期專案上，我從上海帶了5個人過去參加tp當年的團隊，後面給了我兩個星期做一個模組實用性原型，成都那邊給 了我一個美工，我這邊自己做模型開發，設計完成後，分給了一個做頁面，一個做資料庫，我做業務控制層，一個人做銀行介面的扣款，一共8天不到全部搞定，一 次性通過測試。
做介面和資料庫開發的人完全是在我給定的模型匯出的程式碼上進行的，我們做了一次設計變更，形成了一個獨立的直接物件資料的寫入類。
所以，我一直定義的編碼人員就是印度的那種編碼層次就足夠了。
不是說設計人員完全脫離編碼，而是對於一些創造性和創新性或者說有一定難度的編碼是需要設計人員寫好的，類似於過去傳統軟體工程中提出的微程式碼的開發階段所完成的內容。
這樣，就可以完整地實現程式碼設計的分離。實現我們的對印外包。

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



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

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

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



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

不管我們做什麼軟體，這個軟體大部分都是此前已經有人做過的，或者有過類似的，或者至少是在原理上已經被證明過的，如果非要強調，應該說，科學是對原理的驗證，而工程是對原理的實現。
難度有可能實現比推理過程更難，所以，在科學領域的很多學科上都有大量至今還無法驗證的假設，這是客觀存在的，假設往往需要很多條件滿足後才可能被驗證，所以，那本書上說的工程的所謂概念是完全錯誤的！！！

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



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

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

傳統工程真有這麼牛？

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

一部美國軍機發展史，就看見三個詞：延期，超出預算，專案取消。

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

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

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

諸多疑問，難以釐清。



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

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


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

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





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

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

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


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

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


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

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




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

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

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



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

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

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



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

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




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

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

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






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


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


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

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




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

這是因為不會說話啊...
做銷售的, 何至於這麼不會溝通

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




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

打羽毛球是很健康的事情

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






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

你們都喜歡髮長文 啊

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

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

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

軟體從本質上講，是個工程，但是一個複雜度極高的工程，以至於很難控制，所以需要一些理論和方法來控制這個工程。

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



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

有意思

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

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

但是其實工程這個概念是不需要嚴格界定的

【 在 finely (finely) 的大作中提到: 】
: 你們都喜歡髮長文 啊
: 我說個簡短的，主要就是“工程”和“研究”之區別
: 工程就是幹活，理論和工具都是現成的，用就是了
: ...................



☆─────────────────────────────────────☆
   zhangmike (秦月) 於  (Sun Jan 17 08:21:43 2010)  提到:

正確的短文的產生 是先有長文，再提煉,提煉完了後，短文就不完全對，一般95%的情況下是對的。還有5%的特殊情況下就不對。
然後就又有討論和爭論，焦點在5%的部分。
所以有時間也可以看看長文。