軟件

讀了Sumtec的繼續思考，感觸很多，隨便寫點東西。Sumtec在他的post裡面談到了一個問題，就是軟體開發要以客戶為導向，而不是技術為導向；換句話說，就是要做面向客戶的軟體開發。客戶是對產品或項目買單的人，我們辛苦的努力，最後能換回多少人民幣，關鍵就是客戶了。面向客戶的開發，能夠維繫和客戶的良好關係，減少返工次數，降低風險，最終提高開發效率，保證按時交付。那麼如何做好面向客戶的軟體開發呢？我認為要把握住下面這幾點：1、把滿足客戶的需求作為團隊共同的願景通常，項目組內不同分工的人員都把完成自己

星期一, 四月 3rd, 2006 @ 17:05 · 由 Samuel Chen 分類： Career|Motivate, Articles本文April 03, 2006發於

以前做過的各個項目中，都存在資料庫管理不好的問題，想能不能也象編碼規範一樣，做一個資料庫管理規範？原則：整個開發過程中的資料庫管理維護由項目組中專人進行。     下面描述會分為兩種角色：     1）專門負責項目中資料庫管理維護人員，簡稱DBA；     2）項目群組成員（項目組所有成員，包括專門負責資料庫維護的人員DBA），簡稱PM；     涉及到三個資料庫執行個體：     項目標準庫：<PROJECT>_STD：只有DBA可以管理操作   

題外話：      由于思維的混亂，於是寫本文之前，我先做了張思維導圖是這樣的。 做到一半的時候，我發現這樣下去，每個點展開來寫，就太大太多了，況且每個點都可以有好多個點，這樣一級級展開的話，差不多都可以寫本書了。於是決定把範圍縮小一些，可是當我用思維導圖工具去畫的時候，怎麼畫都會把問題搞大搞多，最終，我決定，從幾個點管中窺豹，來談一談中外軟體職場的一些差異。最終的思維導圖就畫成了下面的這個樣子。1.生態環境所謂生態環境，

今天在串連Oracle的時候碰到一個問題，我的機器裝的是Oracle9.2用戶端，當在asp.net應用中使用資料訪問的組件（調用System.Data.OracleClient）時，程式報“System.Exception: System.Data.OracleClient requires Oracle client software version 8.1.7 or

我們期待自己成為一個優秀的軟體模型設計者，但是，要怎樣做，又從哪裡開始呢？ 將下列原則應用到你的軟體工程中，你會獲得立杆見影的成果。 1. 人遠比技術重要 你開發軟體是為了供別人使用，沒有人使用的軟體只是沒有意義的資料的集合而已。許多在軟體方面很有成就的行家在他們事業的初期卻表現平平，因為他們那時侯將主要精力都集中在技術上。顯然，構件（components），EJB（Enterprise Java

    來園子有不少時日了,也搜了一些相關的軟體品質保證方面的文章，發現討論這方面的文章比較少，而且給我感覺是：這些所謂的體系，部門機構在國內的企業似乎很難建立起來。    我們公司今年初，成立了網路部，給的資源十分有限，我自己在管理過程中發現軟體的品質很難保證，所以想向大家求教一下，希望大家都能談談各自己公司，軟體品質這一塊都是如何來建立的。不知道這是不是屬於公司的機密？    下面這一幅軟體品質保證體系是出自《軟體工程》，我重新用WORD畫了一下。不知道有多少公司按照這種體系流程來做的？  

     “蟬鳴林愈靜，鳥鳴山更幽”，這是中國古代純山水詩的絕句，在動與靜的映襯下別具一番優美。在軟體的領域，其實也存在這種動與靜的境界。如果軟體設計得當，也可以使軟體的設計具有雕塑一般的美。對於雕塑我不是很懂，對於這種凝固的美，我一直都是十分敬畏的。    時下非常紅火的是敏捷式軟體開發 (Agile Software Development)，討論得最熱鬧的是設計模式。敏捷式軟體開發 (Agile Software

價格根據功能具體調整，如果長期合作，可以面議！連絡方式： 13764567708  徐羽功能介紹如下：1. 線上客服定點客服採用最先進的網頁交談技術，網站訪客不需要下載安裝任何軟體，在瀏覽器的視窗就可以進行即時交談。客戶通系統會在網站中產生相應的表徵圖（可以是浮動表徵圖、靜態圖片、文字連結），吸引使用者點擊。使用者在訪問網站的時候，如果有什麼問題的話，只需要點擊該表徵圖，即可向網站的後台客服人員發起對話請求後，即可進行即時對話。2. 主動洽談一般情況下，網站的訪客在訪問網站時僅僅是作為“訪問者”

幾種常見的FTP軟體的二進位設定說明：1、FlashFXP：開啟 FlashFXP：在工具列中，選項 => 參數（也可以直接按F6鍵），在彈出來的視窗中，選擇“傳輸(T)”卡，在傳輸模式中選擇“二進位”。2、LeapFTP：開啟 LeapFTP： 在 Options（選項）菜單中選擇 Parameters（參數設定），選擇其中的（ASCII 副檔名），出現列表後，選中其中的“*.PHP”，點右邊的（刪除），再點右邊的（確定）即可。如果“*.PHP”項目不存在的話，可直接使用，不需另行設定。

在這個行業，幹了7年了。有這麼個感受：程式看起來都寫完了。但是如何讓客戶用起來，是一個很大的問題。產品不管是正式發版，還是項目編碼結束，到客戶能夠接受，都有一個很長的時間擺在那裡。程式碼完成之後，還有部署、實施、維護、突發問題解決等一堆問題。偶稱這些問題為“代碼後”問題。這幾年，見了很多這種“代碼後”的問題，也解決了不少。總結起來，大致有這些（基本上和業務無關）：1、   Server環境的問題。如：RAC、Linux、win2003、DTC、LoadBalance等。2、  

 推薦一本書給大家吧，算不上書評，只能是自己的一些感想。 《軟體城堡》—企業結構建模 高等教育出版社 作者: Roger Sessions 定價: 18.00 RMB 英文名: Software Fortresses: Modeling Enterprise Architectures 我自己給它的評級在3星半多少於4星，也就是准4星，我希望下面的評論能說明我的這個評價 Fortress

確實存在一定難度，不，應該是很大難度，在豬八戒招標由1000升到了1500元，無數人嘗試，卻無數人未果，認為很容易或者認為可以破解的事實上結果無數嘗試還是無法完成。C++開發。軟體運行機制分析：軟體運行首先出現帳號和註冊碼的輸入框，最頂端是電腦資訊碼，把電腦資訊碼發給開發人員，他會給出使用者名稱和註冊碼，通過輸入正確的使用者名稱和註冊碼就可以運行了，沒有任何功能限制的。軟體是asprotect帶sdk加殼，無數的VM，甚至把註冊資訊都寫進了SDK。每一次安裝系統都會導致資訊碼不同。最好的結果是可

因為系統運行越來越慢，前天從down了一個windows最佳化大師，按照其提供的功能作了最佳化註冊表等操作，結果導致vs.Net2005不能使用，導致登出系統的時候，系統提示正在運行登出指令碼，然後彈出一個錯誤提示：找不到檔案“/idlist,xxxx,c:\”的檔案，其中xxxx是一個號碼，本能的反應是在註冊表中查有idlist的項或者值，最後確定是在Folder項下面出錯，將command子項下的值刪除，就沒有提示了，但是在運行對話方塊中，當我輸入“\\IP地址”的時候卻提示找不到\\ip地

 1.卡巴就好象西毒，兇猛強悍，神功蓋世，對敵決不留情，出手狠辣，招招奪命，絕少失手，不愧為一代梟雄，但畢竟練的不是純正內功，容易走火入魔，導致系統出問題。2,麥咖啡就象東邪，玉樹臨風，俊朗瀟洒，對敵招式繁多，機關重重，殺伐決斷從不遲疑，為江湖第一機智聰明之人，但因其心機太深，令人難以掌握。3,諾頓就象南帝，雍容華貴，穩沉厚重，胸懷博大，練的是純正內功，靠的是教化感人，對敵有慈悲心腸，一般採取隔離教化，使其不在作惡，很少殺人，稱的上是一代宗師，但因其過於敦厚，不僅自己活的累，別人也為他感到累。4

 可能由於大家沒有環境，因此很少能接觸到SAP系統，當我第一次使用SAP時，我就感覺到SAP優秀的介面控制，我想我們應該從中可以學到點什麼。 一個經常被開發人員與設計者們忽略的問題，那就是系統介面的友好性，就象我前段時間跟大家討論的“Web上高效能分頁的必要性”，竟然有這麼多朋友贊同我的意見：不提倡那種所謂的多資料分頁。可是我們從網上可以找到那麼多討論高效能分頁的問題，可想而知，這分頁的問題困擾了這麼多人，可當我們進行深入的思考後才發現，有些是完全沒有必要的。主要是大家沒有深入思考，一貫的認為分

  隨著電腦硬體水平的不斷提高，電腦軟體的規模和複雜度也隨之增加。電腦軟體開發從“個人英雄”時代向團隊時代邁進，電腦軟體項目的管理也從“作坊式”管理向“軟體工廠式”管理邁進。這就要求軟體開發人員特別是軟體專案管理人員更深一步地理解和掌握現代軟體工程的理論方法，完成思想觀念上的轉變。筆者在此分析了10個在現代專案管理中思想觀念上容易陷入的誤區，希望能夠拋磚引玉，引發大家更多的思索和討論。

隨著軟體規模的不斷擴大、軟體涉及的領域越來越廣，客戶對軟體要求也越來複雜，這一點的最直接的體現就是軟體需求的變化越來越頻繁。敏捷式軟體開發 (Agile Software Development)正是為了應對這一問題而誕生的軟體工程學方法。它以適應性的過程代替傳統的預測型的過程代替傳統的預測性的過程，在很大程度上滿足了現代商業軟體業務複雜、需求多變、時間要求緊迫等特點。 敏捷式軟體開發 (Agile Software

軟體開發的時候總是面臨著各種決策，大到模組的劃分，小到函數體的寫法，這些都是設計的問題。做設計不難，難的是做一個好的設計。然而什麼是好的設計？標準是什嗎？軍事上常說“戰術是為戰略服務的”。這句話換到軟體上來可以變成很多說法：函數是為物件服務的；對象是為底層設計服務的；底層設計是為構架服務的；構架是為需求服務的；需求是為了客戶的生產生活服務的……不同的抽象層次上對應不同的戰略與戰術。做好一個設計的根本就在於不僅僅著眼於當前的工作層面，而應該能夠很好的理解當前工作服務的那個層面！比如寫函數體吧，就需

最近eddie迷上了溫伯格，瘋狂地買了所能找到的他在國內所有已出版的書探索需求——設計前的品質 品質軟體管理1——系統思維諮詢的奧秘I——成功提出和獲得建議的指南   諮詢的奧秘II——諮詢師的百寶箱（預訂）  系統設計的一般原理 走查、審查與技術複審手冊——對程式、項目與產品進行評估（第3版） 系統化思維導論（銀年紀念版）  你的燈亮著嗎？——如何找到問題的真正所在  成為技術領導者——解決問題的有機方法    程式開發心理學（銀年紀念版）  看來我也受了他的影響，雖然我只看過他的一本《你的燈