其他

對組織圖建模的一點改進想法     為了建立Enterprise Architect,其中關鍵的模型包括企業的組織圖，以及在組織圖的基礎上建立的組織之間的關係圖。大約包括如下層次：    頂層：          組織圖    第二層          組織單元之間的關聯式模式    第三層         某個組織單元中的角色關係圖            這三層模型明顯存在層次關係，現在的建模工具完全不能很好的 表達這些關係。通過使用GoogleEarth，我覺得完全可以使用同樣的形式來表達。

 我們在項目中採用了NHibernate作為ERMaping的解決方案，目前NHibernate發布了0.300版本，可以參見:NHibernate.sourceforge.net ;可NHibernate目前沒有自動的配置產生工具，要一個一個的組建組態檔案非常的煩人，通過研究，開發了一個配置產生工具。

        進行代碼處理的時候,我們往往發現很多代碼有所相似,而又有不同,如何求同存異?        預先處理先行,將處理相同邏輯代碼的部分合并.        適用環境包括:        1.某段程式啟動時,需要預先處理一些資料,用於顯示,處理這些資料的代碼與使用者在介面上操作產生的某段代碼非常相似。合并兩段代碼勢在必行，為此需要將代碼中不同的邏輯區分出來，並進行預先處理。       

　　森林舉行運動會，馬得了長跑第一，被森林之王老虎任命為體育部長，心裡非常得意。馬認為跑是最重要的事，除了跑以外，任何事都可以看作跑，老虎出去狩獵也是跑，老鷹在天上也可以看作跑，兔子逃避追捕也是跑，小螞蟻天天在跑。因此馬決定以老虎的名義召集全體動物關於全面開展奔跑運動的會議。馬提出，任何東西都離不開跑，跑是最重要工作，任何東西都是跑的一種形式，只要跑好了，就可以生存，才可以生存，從今天起，大家都要跑，如果不跑的，就以違反老虎的名義被殺掉。老鷹不高興，說我不會跑，我也沒有必要跑，馬決定給老鷹一個下

      現在是一個戰略的時代，對於每個企業，在完成了從創業到生存的階段後，都想飛速發展壯大，為了飛速的發展壯大，他們需要有一個原則、指導方針來引導自己的企業前進。這個指導方針最好能夠管個3年5年，在這個指導方針之下，對自己的企業進行改造－－流程重組、產品調整、管理變革、資源變換、人才改變。這個指導方針我們可以稱為戰略。     

一個小訊息，沒有引起多少人的注意，那就是Borland旗下的所有IDE工具，一股腦賣給了Embarcadero(易博龍)。   這裡涉及到Delphi、C++ Builder、JBuilder、甚至最新的PHP和Ruby的開發平台。   一代英雄，從此謝幕。   英雄謝幕，要不就是戰死沙場，馬革裹屍；要不就是金盆洗手，榮歸故裡。   不論是哪種，都應該轟轟烈烈，路人皆知。   不想Borland 的IDE，竟然悄無聲息，惶惶然，有如嫁出具有醜事的媳婦，驚怕別人知曉。  

一直研究外包管理方法論，各種各樣的資料都看過了。現在想回到最原始的問題，就是外包的目的。一個企業的外包，一定有其戰略意義在，如果是因為有些工作忙不過來進行外包，那我就簡單的成為戰術外包，原因就是忙不過來，目的就是找人來協助忙乎。那麼戰略外包的目的是不是包括： 1.與使用自己的員工相比，可獲得更多的利潤；2.專註於公司盈利的主業；3.獲得更加專業的服務；4.與服務提供者一起分擔風險。  儘管我很不想承認1是最主要的原因，但我不得不承認，這個原因比我們想像的還要重要。如果不是降低成本，增加利潤的需要

   使用AxWebBrowser或者WebBrowser的方法將Office嵌入我們的.Net系統問題有幾個，1是WebBrowser控制項是一個比較重的控制項，2是通過WebBrowser去控制Office如果出現問題沒有辦法進行調試與判斷，也無法修改，3是Office對應的菜單沒有辦法控制。為此我們決定需求新的解決方案，使用微軟提供的dsoFramer控制項例子，這個例子使用VC＋＋編寫，本身是可以使用的，可以參見：   http://support.microsoft.com/defau

通過不斷的研究對比目前外包管理的有關標準，以及網上的有關外包原因、風險、失敗的原因的分析。大致得出下面的結論：(站在發包方的角度，只提供大綱，研究資料請參見：eSCM，ISO20000，ITIL CMMI V1.2,以及網上的資料）1 原因 1.1 減少與控製成本 1.2 聚焦戰略事務聚焦在價值鏈的高端擺脫低級的重複性勞動加快戰略重組釋放內部資源，以轉移到高附加值工作1.3 獲得更專業的服務品質、技術、業務領域、效率1.4 降低與共用風險專門技術、大規模1.5

自動產生NHibernate設定檔工具的使用執行個體各位，由於最近研究NHibernate的朋友多起來了，很多人問到我那個自動產生NHibernate設定檔的工具如何使用，這裡貼出一段代碼，請大家自己看。幾點說明：1.我這裡產生的設定檔，假設和資料庫欄位一致，因此沒有複雜的配置頁面，產生後，大家可以根據自己的情況，簡單修改一下設定檔。2.由於該工具是在Nhibernate0.3的時候做的，後來一直沒有時間更新，因此可能有部分功能在現在的NHibernate中得到了增強或者修改，不過組建組態的方法

     孩子病了，腹瀉。去了兒童醫院，開了藥，吃了幾天，沒用。去了醫大二院，也沒用。昨天再去醫大二院，換一大夫。大夫仔細的詢問了病的情況，藥的情況。     

     今天是設計培訓的最後一天，在講依賴倒置的問題的時候，突然說出一句話：No User，No Interface     此時想起一個問題，那就是介面查詢中條件和結果應該如何傳遞給後台服務類的問題，一時不禁呆住。     前提：        介面知道查詢條件和需要什麼樣的結果，因此必須要由他將有關的需求傳遞給後台服務類。     例如：我們需要根據工齡查詢工齡在10年以上的員工，需要顯示員工的姓名、部門、編號。    

文章目錄 1.1 基本要求1.2 進階要求4.1 基本要求4.2 進階要求     為了研究外包服務提供者的管理應該關注哪些方面，在分析了客戶作為發包方的考慮包括外包的原因、面臨的風險、失敗的原因、有關的期望以外，現在站在服務提供者的角度來考慮。 主要考慮客戶、員工、投資者、社會四個方面對服務提供者的要求。在eSCM中，為了證明其所總結的服務管理領域師出有名，一共列舉了23條要求。我這雷根據四個方面，列出26條要求。1 客戶的要求1.1

這8－9年時間，開發、設計、管理、客戶溝通、市場都在做，都做過，覺得做的總有很多差距，回想起來，真是感慨萬千。最近一個項目的第二個開發階段結束，組織進行程式碼檢閱，回想很多事情，其中態度、細節、習慣決定成敗的感覺越來越深刻了。態度決定成敗，自米盧後，被中國人高度的認可。一個人的態度決定了很多事情，在部隊，你的態度就決定了你將來是到連長，還是師長，哪個首長願意提拔一個不安心做事的兵。在公司，哪個經理願意給一個不想在公司好好乾的人機會。態度就代表了機會，代表了努力，代表了被人認可。態度不好，處處碰壁

在多年以後，我不得不再次正視這個話題。我們單純的從情感角度來講，我們是從事技術的公司。但是現實卻是外語能力更吃香一些。為什麼呢？說點宏觀的：先看一個國家的例子，印度、中國和菲律賓。印度在外包領域是理所當然的老大，持續了很多年。但他們最初靠的並不是技術，而是溝通能力，包括：語言、理解對方文化、溝通技巧、理解對方業務等幾個方面。這些方面是由於他們殖民時代後帶來的，也可以說是歐美這些國家的補償印度而導致的（這個只能說是一個內在的，沒人會承認的）。而菲律賓在最近幾年外包突飛猛進，也是有益於這個因素。他們

木匠與總管－－－－一則專案管理的小故事        原來農村蓋房子，一般都有兩個總管，一個管建築，一個管木工，因為木工活在農村和土建活差不多，許多柱子、梁、房頂、樓梯、樓板等等都是木頭做的。        這次，木工總管手下新來了一個非常厲害的木工，什麼活都會幹，乾淨利落，總管非常喜歡他，大家都誇他，時間長了，這個木工就有點飄飄然了。他每天看著總管在工地上走來走去，什麼也不幹，盡吆喝別人幹活，有點不服氣，心裡想：這種事我也會幹，看樣子他的技術還不如我呢？        大梁是房子最重要的部分，

合約範圍與需求分析範圍不符的一個原因是我們沒有秉承啟動這個項目的核心價值。導致這個問題的原因可能包括：     1.根本就沒有分析核心價值是什麼。     2.分析了核心價值，但沒有獲得客戶的認同。     3.獲得了客戶的認同，但在分析中偏離了核心價值，並且沒有採取措施。     為此，我覺得在進入需求分析之前，必須要分析該項目的核心價值，可以通過分析啟動該項目的原因來獲得；也可以通過分析項目成功的標誌來獲得。    

使用NHibernate的系統體繫結構 根據James的意見，我重新調整了基於NHibernate系統的體繫結構 大致的建模原則為：     用例基本上有對應的服務層的類來提供服務。     根據介面，建立介面、服務類、領域類，以及DAO層之間的分層類圖     根據介面、用例建立動態模型     有關儲存、刪除、Load、建立等都由服務層的類，調用DAO來執行，有關查詢，由服務層的類調用Native SQL Dao來執行。 有關問題： 1.

做為軟體開發商，每到需求分析結束的時候，我們就會有感歎，這個需求怎麼和合約上的完全不一樣呢？做為客戶卻不能理解，我們不是還是做1－2－3－4這四個事情嘛，有啥不一樣的？     為什麼會出現這個問題，我想首先的問題就是，客戶的需求是解決其業務問題，從大的方面來說假設分成1－2－3－4，這個一般沒有問題，如果出了問題客戶也能夠同意進行調整。而做需求分析的時候除了業務問題以外，最主要加入進來的確實操作習慣，那麼我們可以大致這樣來進行劃分：